이 글은 Anthropic의 엔지니어링 블로그 포스트 "Building effective agents"와 "Multi-agent research system"를 번역 & 정리한 글입니다. 개인 공부를 목적으로 번역하여 아래에 기록하였으며, Gemini 2.5 Pro 기반으로 초벌 번역을 진행하고 검수를 통해 글을 정리하였습니다. 해당 글들은 에이전트를 공부하시는 분들에게는 필독서와 같은 포스트이니 꼭 읽어보시는 것을 추천드립니다. 각 LLM workflow와 Agent에 대한 시각화 자료는 원문에서 확인하실 수 있습니다.

Agentic System?

에이전틱 시스템(Agentic System)은 단순히 대규모 언어 모델(LLM)을 호출하는 것을 넘어, LLM을 핵심 추론 엔진으로 활용하여 복잡하고 여러 단계에 걸친 목표를 자율적으로 달성하는 시스템을 의미합니다. 기존의 모델 활용 방식과 에이전틱 시스템을 구분하는 핵심적인 특징은 자율성(autonomy), 목표 지향성(goal-orientation), 그리고 사전 정의된 도구(tools)를 통해 외부 세계와 상호작용하는 능력입니다.

에이전트는 정해진 루프(loop) 안에서 작동합니다. 먼저 주어진 목표를 평가하고, 이를 달성하기 위한 일련의 행동 계획을 수립합니다. 그 후, 계획에 따라 도구를 호출하는 등의 행동을 실행하고, 그 결과를 관찰합니다. 에이전트는 이 새로운 정보를 바탕으로 기존의 계획을 수정하거나 새로운 계획을 세웁니다. 이러한 반복적인 프로세스를 통해 단일하고 정적인 프롬프트로는 해결하기 어려운 복잡한 과업을 효과적으로 처리할 수 있습니다.

이러한 변화는 프로그래밍 패러다임의 근본적인 전환을 의미합니다. 기존의 LLM 호출이 입력을 제공하고 출력을 받는 함수 호출과 유사했다면, 에이전틱 시스템은 상위 수준의 목표를 위임하는 것과 같습니다. 개발자는 더 이상 "어떻게"를 지시하는 상세한 명령어를 작성하는 것이 아니라, "무엇을" 달성해야 하는지를 명시합니다.

Workflows vs. Agents

"Agent"는 여러 가지 방식으로 정의될 수 있습니다. 일부 고객들은 에이전트를 다양한 도구를 사용해 복잡한 작업을 수행하며 장기간 독립적으로 작동하는 완전히 자율적인 시스템으로 정의합니다. 반면, 어떤 고객들은 미리 정의된 워크플로우를 따르는 보다 규범적인 구현을 가리키는 데 이 용어를 사용합니다. Anthropic에서는 이러한 모든 변형을 에이전트 시스템(agentic systems)으로 분류하지만, 워크플로우와 에이전트 사이에 중요한 아키텍처적 구분을 둡니다:

  • 워크플로우(Workflows)란 LLM과 도구들이 미리 정해진 코드 경로(코드 플로우)를 통해 오케스트레이션되는 시스템입니다.
  • 에이전트(Agents)는 반면에, LLM이 자신이 어떻게 과업을 수행할지, 어떤 도구를 사용할지 등을 스스로 동적으로 결정하면서 전체 과정을 주도적으로 제어하는 시스템입니다.
언제 'Agent'를 사용해야 하는가?

에이전틱 시스템의 도입이 특히 유리한 문제 유형은 다음과 같은 특징을 가집니다.

  • 실행 경로를 예측할 수 없는 task: 문제 해결에 필요한 정확한 단계를 사전에 모두 정의하거나 하드코딩하기 어려운 경우에 적합합니다. 예를 들어, 완전히 새로운 소프트웨어 버그를 디버깅하거나, 정답이 정해지지 않은 개방형 연구를 수행하는 경우가 이에 해당합니다.
  • 외부 환경과의 상호작용이 필요한 task: 실시간 정보에 접근(웹 검색, 데이터베이스 쿼리)하거나 외부 시스템의 상태를 변경(이메일 발송, CRM 업데이트)해야 하는 작업에 필수적입니다.
  • 장기적이고 여러 단계로 구성된 프로세스: 한 단계의 출력이 다음 단계의 입력으로 사용되는 긴 의존성 체인을 가진 과업을 처리하는 데 효과적입니다.
  • 동적인 적응이 요구되는 task: 시스템이 새로운 정보에 반응하여 중간에 전략을 수정해야 하는 경우, 에이전트의 자율적인 계획 수정 능력은 매우 중요합니다.
1. Building block: The augmented LLM

Augmented LLM은 모든 에이전틱 시스템의 가장 기본적인 구성 단위입니다. 이는 Claude와 같은 LLM에 외부 도구(tools) 세트가 결합된 형태입니다. 이 시스템의 작동 메커니즘은 다음과 같습니다. LLM은 사용자의 질의뿐만 아니라 사용 가능한 도구 목록과 그에 대한 설명을 함께 프롬프트로 입력받습니다. 모델은 자신의 추론 능력을 사용하여 사용자의 요청을 이행하기 위해 특정 도구를 언제, 어떻게 호출해야 할지를 결정합니다.

2. Workflow: Prompt chaining

Prompt chaining은 가장 단순한 워크플로우로, 한 LLM 호출의 출력이 프로그래밍 방식으로 다음 LLM 호출의 입력으로 사용되는 구조입니다. 이는 선형적이고 순차적인 작업 흐름을 생성합니다. "이 텍스트를 번역한 후, 번역된 내용을 요약하라"와 같이 고정된 일련의 변환 작업으로 분해할 수 있는 과업에 이상적입니다.

3. Workflow: Routing

Routing은 프롬프트 체이닝에 조건부 논리를 도입하여 발전시킨 형태입니다. 초기 LLM 호출이 '라우터' 역할을 하여 입력을 분석하고, 여러 가능한 다음 단계나 도구 중 어느 것을 호출할지 결정합니다. 고객 지원 시스템에서 초기 질의를 분석하여 청구 관련 부서 도구, 기술 지원 도구, 또는 일반 FAQ 도구로 연결하는 사례가 대표적입니다.

4. Workflow: Parallelization

Parallelization는 속도와 처리 범위를 넓히기 위해 설계된 워크플로우입니다. 단일 질의를 여러 개의 독립적인 하위 질의로 분해하여, 별도의 LLM 호출을 통해 동시에 실행할 수 있습니다. 예를 들어, "원자력 에너지에 대한 주요 찬반 논거는 무엇인가?"와 같은 광범위한 주제를 조사할 때, "찬성 논거", "반대 논거", "경제적 영향", "환경적 영향" 등으로 나누어 병렬적으로 검색을 수행할 수 있습니다.

5. Workflow: Orchestrator-workers

Orchestrator-workers는 중앙의 '오케스트레이터' 에이전트가 복잡한 과업을 분석하고, 이를 더 작고 전문화된 하위 과업으로 분해한 뒤, 각 하위 과업을 전담 '워커' 에이전트에게 위임합니다. 워커들은 각자 독립된 컨텍스트와 특화된 도구를 가지고 병렬적으로 작업을 수행한 후, 그 결과를 오케스트레이터에게 보고합니다. 오케스트레이터는 이 결과들을 종합하여 최종적인 일관된 답변을 생성합니다

6. Workflow: Evaluator-optimizer

Evaluator-optimizer 워크플로우는 반복적인 개선을 위한 피드백 루프를 도입합니다. 하나의 에이전트('워커' 또는 '생성자')가 코드나 이메일 초안과 같은 결과물을 생성하면, 두 번째 에이전트('평가자' 또는 '비평가')가 이 결과물을 정해진 기준이나 루브릭에 따라 평가하고 피드백을 제공합니다. 그러면 워커는 이 피드백을 바탕으로 개선된 버전을 다시 생성합니다.

7. Agents

진정한 의미의 '에이전트'는 위에서 설명한 Building block과 Workflow를 동적으로 결합하는 시스템으로 정의됩니다. 에이전트는 단일 워크플로우에 국한되지 않고, 장기간에 걸쳐 상위 수준의 목표를 달성하기 위해 상황에 맞는 적절한 워크플로우(또는 워크플로우의 조합)를 자율적으로 선택하고 실행하는 주체입니다.

Agents in practice

A. Customer support

고객 지원 에이전트는 지식 베이스 접근, CRM에서 고객 이력 조회, 지원 티켓 생성 및 업데이트와 같은 도구를 갖출 수 있습니다. 이 에이전트는 Routing 워크플로우를 활용할 수 있습니다. 고객의 문의를 받으면 먼저 지식 베이스를 검색합니다. 만약 적절한 답변을 찾지 못하면, 문의 내용의 키워드를 분석하여 올바른 담당자에게 배정될 지원 티켓을 생성하는 도구를 호출합니다.

B. Coding agents

코딩 에이전트는 파일 읽기/쓰기, 샌드박스 환경에서 코드 실행, 린터나 정적 분석 도구 접근과 같은 도구를 부여받을 수 있습니다. 이 에이전트는 Evaluator-optimizer 워크플로우를 사용할 수 있습니다. 사용자가 "이 함수를 더 효율적으로 리팩토링해 줘"라고 요청하면, 에이전트는 새로운 버전의 코드를 작성하고('워커'), 성능 테스트를 실행합니다('평가자'). 만약 새로운 버전이 더 빠르지 않다면, 에이전트는 테스트 결과를 분석하여 다른 접근법을 시도하며, 성능 목표가 충족될 때까지 이 과정을 반복합니다.

Prompt engineering your tools

에이전트와 도구(tool) 간의 인터페이스는 인간과 컴퓨터 간의 인터페이스만큼이나 중요합니다. 도구의 효과는 단순히 그 기능에 의해서만 결정되는 것이 아니라, 프롬프트 내에서 그 목적과 사용법이 에이전트에게 얼마나 명확하게 설명되는지에 따라 크게 달라집니다. Anthropic은 다음과 같은 실용적인 휴리스틱을 제시합니다.

  • 명시적인 가이드라인 제공: 에이전트에게 도구 선택 방법에 대한 명확한 지침을 제공해야 합니다. 예를 들어, "사용 가능한 경우 일반적인 도구보다 전문화된 도구를 우선적으로 사용하라" 또는 "광범위한 외부 탐색이 필요할 때는 항상 웹 검색 도구부터 시작하라"와 같은 지침을 포함할 수 있습니다.
  • 탐색 장려: 과업 시작 시 에이전트가 사용 가능한 모든 도구를 검토하도록 지시하여 더 나은 초기 계획을 수립하도록 유도합니다.
  • 사용자 의도와 도구 사용의 일치: 프롬프트는 도구 사용을 단순히 함수 목록으로 나열하는 것이 아니라, 사용자의 문제를 해결하는 맥락 안에서 구성해야 합니다.
  • Claude를 프롬프트 엔지니어로 활용: 모델 자체를 활용하여 도구 관련 프롬프트를 개선할 수 있습니다. 특정 프롬프트와 실패 사례를 모델에게 제공하고, 에이전트가 왜 실패했는지 진단하고 도구 설명이나 사용 지침에 대한 개선 사항을 제안하도록 요청할 수 있습니다.

Benefits of a multi-agent system

다중 에이전트 아키텍처는 단일 에이전트 시스템을 넘어서는 여러 가지 뚜렷한 이점을 제공하며, 이는 Anthropic의 research agent 시스템에서 명확히 드러납니다.

  • 개방형 문제 해결: 다중 에이전트 시스템은 정답으로 가는 경로가 미리 알려지지 않은 연구 과업에서 탁월한 성능을 보입니다. 오케스트레이터는 다른 에이전트가 발견한 흥미로운 단서를 조사하기 위해 새로운 에이전트를 동적으로 생성할 수 있습니다.
  • 유연성 및 적응성: 시스템은 중간 결과에 따라 접근 방식을 조정하고 예상치 못한 관련성을 탐색하는 등, 인간 연구자가 정보를 발견하며 연구 방향을 수정하는 것과 유사하게 작동할 수 있습니다.
  • 압축(Compression): 이는 다중 에이전트 시스템의 핵심적인 이점입니다. 각 워커 에이전트는 자신의 컨텍스트 창 내에서 깊이 있는 탐색을 수행한 후, 가장 중요한 정보만을 '압축'하여 오케스트레이터에게 간결한 요약 형태로 전달합니다. 이를 통해 시스템 전체는 단일 모델의 컨텍스트 한계를 훨씬 뛰어넘는 방대한 양의 정보를 처리하고 종합할 수 있습니다.
  • 관심사 분리(Separation of Concerns): 각 하위 에이전트는 고유한 프롬프트, 도구, 지침을 가질 수 있어 전문화된 전문가 역할을 수행합니다. 이는 단일 에이전트가 서로 상충하는 지침으로 인해 혼란을 겪을 위험을 줄이고, 시스템 전체의 견고성을 향상시킵니다.
  • 성능 확장: 특정 유형의 과업, 특히 광범위하고 병렬적인 조사가 필요한 경우, 다중 에이전트 시스템은 단일 모델의 지능만으로는 달성하기 어려운 수준으로 성능을 확장하는 핵심적인 방법이 됩니다.
  • 토큰 사용량 증가 (노력의 대리 지표): Anthropic의 분석에 따르면, 복잡한 브라우징 과업의 성능 분산 중 80%가 사용된 토큰의 양만으로 설명될 수 있었습니다. 다중 에이전트 시스템은 문제에 더 많은 연산 노력(즉, 더 많은 토큰 사용)을 효과적이고 병렬적으로 투입할 수 있는 구조화된 방법을 제공하여 더 높은 품질의 결과를 이끌어 냅니다.

특히 '압축'이라는 이점은 LLM의 근본적인 제약 조건인 유한한 컨텍스트 창 문제에 대한 직접적이고 우아한 해결책을 제시합니다. 단일 LLM은 한 번에 처리할 수 있는 정보의 양에 명백한 한계가 있습니다. 복잡한 연구 과제는 이 한계를 훌쩍 뛰어넘는 수십, 수백 개의 소스로부터 정보를 종합해야 합니다. 다중 에이전트 시스템은 이 문제를 병렬화하여 해결합니다.

예를 들어, 10개의 에이전트가 각각 5개의 문서를 자신의 컨텍스트 창 안에서 완벽하게 소화합니다. 각 에이전트는 이 5개 문서의 핵심 내용을 지능적으로 '압축'하여 요약 보고서를 생성합니다. 최종적으로 오케스트레이터는 이 10개의 요약 보고서만을 읽으면 되는데, 이는 오케스트레이터의 컨텍스트 창 안에 충분히 들어갈 수 있는 분량입니다. 이 아키텍처는 LLM을 단순히 정보의 한 '페이지'를 분석하는 도구에서, 전체 '도서관'을 효과적으로 읽고 종합할 수 있는 시스템으로 변모시킵니다.

Architecture overview for Research

Anthropic의 연구 에이전트는 Orchestrator-workers 패턴을 구체적으로 구현한 사례입니다. 그 실행 흐름은 다음과 같습니다.

  1. 질의 제출: 사용자가 복잡한 연구 질의를 시스템에 제출합니다.
  2. 분해 및 전략 수립: 선행하는 '오케스트레이터' 에이전트가 질의를 분석하고, 이를 3-5개의 병렬 실행 가능한 하위 과업으로 분해하며, 연구 전략을 수립합니다.
  3. 위임: 오케스트레이터는 여러 전문 '워커' 하위 에이전트를 생성하고, 각 에이전트에게 명확한 목표, 요구되는 결과물 형식, 그리고 웹 검색과 같은 필요한 도구 세트를 제공합니다.
  4. 병렬 실행: 워커 에이전트들은 각자의 과업을 동시에 수행하며, 독립적으로 도구를 사용하여 정보를 수집하고 분석합니다.
  5. 종합: 각 워커는 구조화된 형태의 연구 결과를 오케스트레이터에게 반환합니다.
  6. 최종 보고서 작성: 오케스트레이터는 모든 워커로부터 받은 입력 내용을 종합하고, 상충되는 정보가 있다면 해결하며, 최종적으로 포괄적인 답변을 작성하여 사용자에게 제공합니다.

Effective evaluation of agents

상태를 가지며 비결정적으로 작동하는 에이전틱 시스템을 평가하고 상용 환경에 배포하는 것은 기존 소프트웨어와는 다른 독특하고 중대한 과제를 수반합니다. 먼저, 엔지니어링 측면에서 해결해야 할 문제들이 있습니다.에이전트는 장기간 상태를 유지하며 작동하기 때문에, 초기에 발생한 사소한 오류가 시간이 지나면서 누적되어 결국 전체 과업의 실패로 이어질 수 있습니다. 따라서 견고한 오류 처리 및 복구 메커니즘이 필수적입니다. 또한, 동일한 프롬프트와 입력에 대해서도 실행할 때마다 다른 경로를 택할 수 있는 비결정성 때문에, 전통적인 디버깅 방식으로 실패를 재현하고 원인을 파악하기가 매우 어렵습니다. 이는 로깅, 관찰 가능성, 통계적 평가 중심으로의 전환을 요구합니다. 마지막으로, 이미 실행 중인 에이전트 시스템에 업데이트를 배포하는 것은 매우 복잡합니다. 개별 에이전트들이 다단계 프로세스의 각기 다른 지점에 있을 수 있기 때문입니다.

이러한 특성은 평가 전략에도 영향을 미칩니다.예를 들어, 여러 턴에 걸쳐 코드 베이스를 수정하는 코딩 에이전트를 평가할 때, 각 중간 단계의 품질을 점수화하는 것보다 최종 결과물의 품질, 즉 최종 상태를 평가하는 것이 더 의미 있고 신뢰할 수 있습니다. 또한, 상용 환경의 에이전트는 수백 턴에 달하는 긴 대화에 참여할 수 있으므로, 중요한 정보를 보존하면서 컨텍스트 창의 한계를 넘지 않도록 하는 정교한 컨텍스트 관리 전략(요약, 벡터 DB 검색 등)이 필요합니다. 이러한 엔지니어링 과제들은 에이전틱 AI가 단순히 머신러닝의 연장선이 아니라, 새로운 소프트웨어 엔지니어링 분야의 시작임을 시사합니다. 'AgentOps' 또는 'AIOps'로 불릴 수 있는 새로운 종류의 도구 스택을 필요로 합니다.

Appendix: Handoff vs. Tool

추가적으로 OpenAI Agent SDK를 많이 다뤄 보신 분께서 조언을 해주신 것이 있는데, 개인적으로 handoff와 tool을 이해하는데 큰 도움이 되었어서 아래에 기록합니다.

  • Handoff는 특정 작업의 주도권을 아예 다른 에이전트에게 넘겨버리는 것임. 이전에 수행했던 LLM/유저 사이의 conversation 기록을 모두 copy & paste 하여 다른 에이전트에게 넘기는 것이고 이에 따라 시스템 프롬프트나 사용 가능한 tool들이 변경됨

    • 만약 특정 conversation만 필터링해서 넘기고 싶다면 그 때에 input filter와 옵션을 활용해서 컨텍스트를 일부만 넘길 수 있음
  • Agent as tool은 에이전트가 특정 작업만 다른 sub agent에게 넘겨서 처리하고, 그 결과물을 다시 받아서 활용하고 싶을 때 사용. 따라서 아주 특정 conversation 맥락만 sub agent에게 공유되고, 주도권은 여전히 중앙 에이전트가 가짐
  • 이러한 이유로 생각보다 handoff를 사용해서 에이전트를 구축할 일은 많지 않고 agent as tool을 많이 쓰게 됨

References