DEVOCEAN

오늘의 트렌드

최근 IT 기술 생태계는 거대 언어 모델(LLM, Large Language Model)의 순수 성능 경쟁을 넘어, 실제 비즈니스 현장에 이를 어떻게 적용하고 최적화할 것인가에 집중하고 있습니다. 과거에는 AI가 얼마나 복잡한 추론을 해내는지, 즉 '지능의 높낮이'가 핵심 평가 기준이었습니다. 그러나 이제 시장의 흐름은 명확하게 바뀌고 있습니다. 실무 개발자들과 엔지니어들은 AI의 처리 속도와 함께, 여러 개의 AI 에이전트(Agent, 스스로 목표를 판단하고 작업을 수행하는 자율형 인공지능)를 조합하여 복잡한 업무를 자동화하는 실용적인 아키텍처 구축에 주목하고 있습니다.

이러한 변화는 현업의 다양한 지점 아래에서 구체적인 사례로 드러나고 있습니다. 슬랙(Slack) 채널에 쌓이는 수백 건의 운영 문의를 사람이 아닌 다중 에이전트 아키텍처로 자동 처리하거나, 업무 도구 내에서 직접 작동하는 소형 플러그인을 개발하는 등 AI와 개발 생산성 도구의 결합이 가속화되는 중입니다. 또한, 데이터 사이언티스트와 머신러닝 엔지니어 간의 협업 격차를 줄이기 위한 서빙 구조의 표준화 작업도 기술 조직의 주요 과제로 떠올랐습니다.

이번 글에서는 최근 공개된 기술 트렌드 사례들을 통해 AI 에이전트의 실제 구현 전략과 LLM 선택 기준의 변화, 그리고 조직 내 엔지니어링 효율화를 위한 다양한 접근 방안을 깊이 있게 분석해 보겠습니다.

AI 에이전트 기반의 운영 업무 자동화 실무

기업 내 운영 채널이나 고객 지원 인프라에 쌓이는 반복적인 문의는 개발팀과 운영팀의 시간을 지속적으로 소모시키는 주요 원인입니다. 최근 A1Mobilsoft의 운영 문의 자동화 사례는 이를 다중 에이전트(Multi-Agent) 아키텍처로 해결하며 큰 시사점을 던져주고 있습니다. A1Mobilsoft, 메가존클라우드(MegazoneCloud), AWS가 함께 참여한 이 프로젝트는 32개월 동안 슬랙의 #운영개발문의 채널에 수집된 846건의 문의 데이터를 분석하는 것에서 출발했습니다.

단일 AI 모델에게 모든 질문을 처리하게 할 경우 정확도가 떨어지고 환각(Hallucination, AI가 거짓 정보를 참인 것처럼 생성하는 현상) 위험이 커집니다. 이를 극복하기 위해 해당 시스템은 지식 검색을 담당하는 에이전트, 코드 분석을 담당하는 에이전트, 데이터베이스 조회를 담당하는 에이전트 등 총 세 개의 전담 에이전트(Knowledge·Code·DB 3-Agent)로 역할을 분담시켰습니다.

구현 과정에서는 AWS의 Bedrock AgentCore 및 Strands 프레임워크가 활용되었습니다. 특히 답변 생성 속도 향상과 비용 절감을 위해 프롬프트 캐시(Prompt Cache, 반복되는 프롬프트 입력을 미리 저장해 두어 재사용하는 기술) 기능을 도입하고, 실제 사람의 답변과 AI의 답변을 14건의 테스트 케이스로 병렬 비교 및 검증하는 단계를 거쳤습니다. 단순한 기술 실증(PoC)을 넘어 실무 프로세스에 직접 결합할 수 있는 수준의 시스템을 구축한 것입니다.

이와 같은 다중 에이전트 아키텍처는 향후 기업 내 내부 업무 자동화의 표준 아키텍처로 자리 잡을 가능성이 높습니다. 시스템의 안정성을 확보하기 위해서는 각 에이전트의 역할 범위를 명확히 규정하고, AI가 도출한 결과물을 사람의 검증 절차와 어떻게 연결할 것인지에 대한 설계가 필수적입니다.

LLM 평가 지표의 변화: 지능에서 속도로의 이동

AI 기술이 대중화됨에 따라 거대 언어 모델을 선택할 때 고려하는 가치 기준도 크게 변화하고 있습니다. 최근 모바일 및 웹 서비스 개발 환경의 LLM 선택 트렌드 분석에 따르면, 코딩, 리서치, 슬라이드 작성, 데이터베이스 분석과 같은 일상적인 업무 영역에서는 이미 Opus 4.6 수준의 지능 수준만으로도 대다수의 요구 사항을 충족하고 있는 것으로 나타났습니다.

이에 따라 사용자가 체감하는 가치는 '모델이 얼마나 더 똑똑한가'보다 '답변을 얼마나 빠르게 출력하는가'로 이동하고 있습니다. 실시간에 가까운 사용자 경험을 제공하기 위한 모델의 출력 속도 기준은 구체적으로 다음과 같이 형성되고 있습니다.

1. 답답함을 느끼는 구간 (50 tok/s 미만): 초당 토큰 생성량이 50개 이하일 경우, 사용자는 대화 도중 흐름이 끊기거나 시스템이 지연된다고 인식합니다.
2. 쾌적함을 느끼는 구간 (100 ~ 200 tok/s): 실시간으로 글자가 작성되는 것을 자연스럽게 읽을 수 있는 속도로, 대부분의 챗봇 및 에이전트 인터페이스에서 이상적으로 평가받는 구간입니다.
3. 인간의 읽기 한계를 넘어서는 구간 (200 tok/s 초과): 텍스트가 눈으로 따라가기 힘들 정도로 빠르게 출력되어 즉시 완결된 결과물을 받아보는 형태의 작업에 적합합니다.

이러한 속도 중심의 패러다임 변화는 AI 인프라 구성에도 직접적인 영향을 미칩니다. 개발자들은 이제 거대한 파라미터를 가진 무거운 모델 하나에 의존하기보다, 특정 업무에 특화된 소형 언어 모델(sLLM)을 경량화하여 추론 속도를 극대화하거나 캐싱 기술을 적극적으로 활용하는 방향으로 전환하고 있습니다.

조직 내 데이터 사이언티스트(DS)와 ML 엔지니어(MLE)의 협업 구조 개선

AI 에이전트나 모델을 서비스에 적용하는 과정에서 발생하는 기술적 병목은 단지 모델 자체의 문제에 그치지 않습니다. 조직 내부의 파이프라인과 엔지니어링 문화 역시 핵심 변수입니다. 토스뱅크 ML 서비스 팀의 경험 사례는 데이터 사이언티스트(DS)와 머신러닝 엔지니어(MLE) 간의 협업에서 자주 발생하는 고질적인 문제를 잘 보여줍니다.

DS가 자신의 로컬 환경이나 Jupyter Notebook에서 완벽하게 작동하는 모델을 개발하더라도, 이를 실제 운영 환경으로 이전하는 과정에서 라이브러리 버전 충돌, 의존성 파일 누락, 환경 설정 불일치 등으로 인해 서빙까지 수일 이상 지연되는 현상이 빈번하게 일어납니다. 모델이 업데이트될 때마다 이러한 소통 비용과 재작업이 반복되는 것은 기술 부채를 급격히 누적시킵니다.

이 문제를 해결하기 위해서는 모델 연구 단계에서부터 서빙 단계를 고려한 엔지니어링 표준이 정립되어야 합니다. 로컬 환경의 의존성을 컨테이너화하고, 모델 파일과 파라미터를 버전 관리 시스템에 통합하며, 테스트 파라미터를 자동화하는 MLOps(머신러닝 운영 자동화) 체계를 구축하는 것이 필수적입니다.

또한, 의료 및 바이오와 같은 특수 산업 분야에서도 기술과 현장의 융합이 가속화되고 있습니다. BioJapan 2024 참관기에서 언급된 바와 같이, HealthTECH JAPAN 등 다양한 엑스포를 통해 디지털 기술, AI, 생명과학 간의 접점이 늘어나고 있습니다. 이는 머신러닝 모델이 단순 IT 서비스를 넘어 전문 산업 현장으로 깊숙이 침투하고 있음을 보여주며, 이에 따른 안정적인 서빙 인프라의 필요성을 더욱 강조해 줍니다.

서비스 통합형 워크플로우 도구와 템플릿의 진화

엔지니어링 생산성을 높이기 위해 개발자들은 사내 도구나 개인 생산성 소프트웨어를 통합된 환경으로 구축하는 시도를 이어가고 있습니다. 외부 사이트를 왕복하는 불필요한 맥락 전환(Context Switching)을 줄이고, 작업 공간 내부에서 완결적인 경험을 제공하는 것이 핵심입니다.

예를 들어 디자인 및 협업 도구인 Figma 생태계에서는 외부 추첨 사이트를 이용하는 번거로움을 줄이기 위해 Figma Tools 기반 레트로 사다리타기 플러그인과 같은 내부 플러그인이 직접 개발되어 활용되고 있습니다. 팀 내에서 2명에서 최대 8명까지 참여하는 간단한 의사결정이나 이벤트를 협업 공간을 벗어나지 않고 해결할 수 있도록 돕는 도구입니다.

또한 개인 문서 및 도서 관리 영역에서도 효율화 시도가 이어지고 있습니다. Book Studio 사례는 기존의 단조로운 PDF 뷰어 환경에서 벗어나, PDF 책을 웹 문서 형태(Fumadocs 기반 디자인)로 전환하여 챕터별 탐색, 검색, 메모 및 하이라이트 기능을 제공하는 오픈소스 템플릿입니다. 이처럼 파편화된 정보를 사용자가 제어하기 쉬운 웹 환경으로 재구성하는 것은 지식 관리 체계의 중요한 흐름 중 하나입니다.

실무에서 바로 써보기

앞서 살펴본 다중 에이전트 시스템이나 MLOps 파라미터 관리를 실제 프로젝트에 도입하기 위해서는 구조화된 프롬프트 전달 체계와 환경 설정 관리가 필수적입니다. 아래 예시는 Node.js/TypeScript 환경에서 복수의 에이전트 요청을 직렬 및 병렬로 구성하고 프롬프트 캐시 레이어를 모의 구현한 코드 스니펫입니다.

import { AxiosInstance } from 'axios';

// 에이전트 역할 정의 인터페이스
interface AgentConfig {
  agentName: string;
  systemPrompt: string;
  temperature: number;
}

// 에이전트 응답 구조
interface AgentResponse {
  agentName: string;
  result: string;
  executionTimeMs: number;
}

// 간단한 In-Memory 프롬프트 캐시 클래스
class PromptCacheManager {
  private cache = new Map<string, string>();

  private generateKey(agentName: string, prompt: string): string {
    return `${agentName}:${prompt}`;
  }

  public get(agentName: string, prompt: string): string | undefined {
    return this.cache.get(this.generateKey(agentName, prompt));
  }

  public set(agentName: string, prompt: string, response: string): void {
    this.cache.set(this.generateKey(agentName, prompt), response);
  }
}

// 3-에이전트 아키텍처 실행기
export class MultiAgentOrchestrator {
  private cacheManager = new PromptCacheManager();

  // Knowledge, Code, DB 역할을 수행하는 에이전트 모의 호출
  public async executeTask(
    userQuery: string,
    agents: AgentConfig[]
  ): Promise<AgentResponse[]> {
    const startTime = Date.now();

    // 3개의 에이전트에 병렬로 요청 전달
    const agentPromises = agents.map(async (agent) => {
      const cached = this.cacheManager.get(agent.agentName, userQuery);
      if (cached) {
        return {
          agentName: agent.agentName,
          result: `[CACHE HIT] ${cached}`,
          executionTimeMs: Date.now() - startTime,
        };
      }

      // 실제 API 호출을 흉내 낸 비동기 처리
      const simulatedResult = await this.callAiModel(agent, userQuery);
      this.cacheManager.set(agent.agentName, userQuery, simulatedResult);

      return {
        agentName: agent.agentName,
        result: simulatedResult,
        executionTimeMs: Date.now() - startTime,
      };
    });

    return Promise.all(agentPromises);
  }

  private async callAiModel(agent: AgentConfig, query: string): Promise<string> {
    // LLM API 응답 대기 시간 시뮬레이션
    await new Promise((resolve) => setTimeout(resolve, 300));
    return `Agent [${agent.agentName}] processed query: "${query}" standard prompt applied.`;
  }
}

// 실행 예시
(async () => {
  const orchestrator = new MultiAgentOrchestrator();
  const agents: AgentConfig[] = [
    { agentName: 'KnowledgeAgent', systemPrompt: '문서 검색 담당', temperature: 0.2 },
    { agentName: 'CodeAgent', systemPrompt: '코드 분석 담당', temperature: 0.1 },
    { agentName: 'DbAgent', systemPrompt: 'DB 쿼리 담당', temperature: 0.0 },
  ];

  const results = await orchestrator.executeTask('슬랙 운영 권한 오류 처리 방법', agents);
  console.log('에이전트 처리 결과:', JSON.stringify(results, null, 2));
})();

실무 환경에서는 이와 같은 오케스트레이터 패턴을 적용할 때 다음 두 가지 주의점을 반드시 고려해야 합니다.

1. 상태 공유 및 컨텍스트 관리: 각 에이전트가 개별적으로 동작할 때 이전 에이전트의 출력이 다음 에이전트의 입력으로 매끄럽게 전달되는 체인(Chain) 구조인지, 아니면 병렬 수행 후 합쳐지는 구조인지를 명확히 설계해야 합니다.
2. 캐시 유효성 검증: 프롬프트 캐시를 활용할 때 기본 데이터베이스나 지식베이스(Knowledge Base)의 내용이 업데이트되면 기존 캐시를 즉시 만료(Invalidation)시키는 로직이 수반되어야 오답 출력을 방지할 수 있습니다.

앞으로의 전망

앞으로 AI와 인프라 생태계는 더욱 세분화되고 고도화될 것으로 예상됩니다. AI 분야에서는 단일 대형 모델에 의존하던 형태에서 벗어나, 특화된 역할을 가진 에이전트들이 유기적으로 통신하는 시스템이 주류를 이룰 것입니다. 이 과정에서 모델의 지능 차별화 요소는 줄어들고, 초당 토큰 생성 수(tok/s)로 대표되는 처리 속도 및 비용 효율성이 선택의 결정적인 기준이 될 것입니다.

또한 조직적 측면에서는 데이터 과학자(DS)와 머신러닝 엔지니어(MLE) 간의 경계를 허물어주는 자동화 패키징 도구와 MLOps 플랫폼이 필수 인프라로 자리잡게 됩니다. 개발 도구 분야 역시 사용자가 별도 사이트로 이동하지 않고 작업 환경 내에서 모든 로직을 완결할 수 있는 내장형 플러그인 및 커스텀 템플릿 중심으로 발전할 것입니다.

결국 미래의 기술 경쟁력은 고성능 AI 모델을 단순히 보유하고 있는가보다는, 이를 얼마나 정교한 아키텍처로 엮어내어 실무진의 작업 속도와 서비스 응답성을 극대화할 수 있는가에 달려 있습니다.

실무 적용 체크리스트

실제 서비스나 조직 내부 프로세스에 최신 트렌드를 적용하고자 할 때 검토해야 할 핵심 항목입니다.

• [ ] 다중 에이전트 설계 권한 분리: 단일 프롬프트 대신 지식 검색, 코드 분석, DB 조회 등 역할별로 에이전트가 세분화되어 있는가?
• [ ] 응답 속도 기반의 모델 평가: 실시간 대화형 서비스에서 모델의 출력 속도가 최소 100~200 tok/s 수준을 유지하는지 측정하고 있는가?
• [ ] 프롬프트 캐시 도입: 반복적인 시스템 프롬프트나 동일 문의에 대해 캐싱 레이어가 구축되어 비용과 지연 시간을 줄이고 있는가?
• [ ] DS-MLE 가교 환경 구축: 로컬에서 개발된 ML 모델이 운영 환경으로 배포될 때 환경 의존성 및 라이브러리가 표준화된 컨테이너로 관리되고 있는가?
• [ ] 작업 환경 일합화: 팀원들의 맥락 전환을 줄일 수 있도록 Figma, Slack 등 주요 협업 도구 내부용 플러그인이나 커스텀 템플릿을 도입했는가?