멀티 에이전트 시스템을 구축하는 방법과 시점

지난주 후반, 겉보기에 상반된 제목을 가진 두 개의 훌륭한 블로그 게시물이 공개되었습니다. Cognition 팀의 “멀티 에이전트를 구축하지 마세요 (Don’t Build Multi-Agents)”와 Anthropic 팀의 “우리가 멀티 에이전트 연구 시스템을 구축한 방법 (How we built our multi-agent research system)”입니다.

상반된 제목에도 불구하고, 저는 이 두 글이 실제로 많은 공통점을 가지고 있으며 멀티 에이전트 시스템을 어떻게, 그리고 언제 구축해야 하는지에 대한 몇 가지 통찰을 담고 있다고 주장하고 싶습니다.

• 컨텍스트 엔지니어링 (Context engineering)이 매우 중요하다
• 주로 "읽는" 멀티 에이전트 시스템이 "쓰는" 시스템보다 구축하기 쉽다

컨텍스트 엔지니어링 (Context engineering)이 핵심이다

멀티 에이전트(또는 단일 에이전트) 애플리케이션을 구축할 때 가장 어려운 부분 중 하나는 모델에게 수행해야 할 작업의 컨텍스트 (Context)를 효과적으로 전달하는 것입니다. Cognition 블로그 게시물은 이 과제를 설명하기 위해 “컨텍스트 엔지니어링 (Context engineering)”이라는 용어를 도입했습니다.

2025년 현재, 시중에 나와 있는 모델들은 매우 지능적입니다. 하지만 아무리 똑똑한 인간이라도 자신이 무엇을 해야 하는지에 대한 컨텍스트 (Context) 없이는 업무를 효과적으로 수행할 수 없습니다. “프롬프트 엔지니어링 (Prompt engineering)”은 LLM 챗봇이 이해하기 가장 이상적인 형식으로 작업을 작성하려는 노력을 일컫는 용어로 만들어졌습니다. “컨텍스트 엔지니어링 (Context engineering)”은 이것의 다음 단계입니다. 이는 동적인 시스템 내에서 이를 자동으로 수행하는 것에 관한 것입니다. 이는 더 많은 미묘한 차이 (Nuance)를 필요로 하며, 실질적으로 AI 에이전트를 구축하는 엔지니어들의 제1순위 업무입니다.

그들은 몇 가지 예시(Toy examples)를 통해 멀티 에이전트 시스템을 사용하는 것이 각 서브 에이전트 (Sub-agent)가 적절한 컨텍스트 (Context)를 갖도록 보장하는 것을 더 어렵게 만든다는 것을 보여줍니다.

Anthropic 블로그 게시물은 컨텍스트 엔지니어링 (Context engineering)이라는 용어를 명시적으로 사용하지는 않지만, 여러 지점에서 동일한 문제를 다루고 있습니다. Anthropic 팀이 컨텍스트 엔지니어링 (Context engineering)에 상당한 시간을 할애했다는 점은 분명합니다. 아래는 몇 가지 주요 내용입니다:

장기 대화 관리 (Long-horizon conversation management). 프로덕션 환경의 에이전트들은 종종 수백 번의 턴(turn)에 걸친 대화에 참여하며, 이는 세심한 컨텍스트 관리 (Context management) 전략을 요구합니다. 대화가 길어짐에 따라 표준적인 컨텍스트 창 (Context window)은 불충분해지며, 지능적인 압축 및 메모리 메커니즘이 필요해집니다. 저희는 에이전트가 완료된 작업 단계를 요약하고, 새로운 작업으로 넘어가기 전에 필수 정보를 외부 메모리 (External memory)에 저장하는 패턴을 구현했습니다. 컨텍스트 제한에 도달할 때, 에이전트는 신중한 핸드오프 (Handoff)를 통해 연속성을 유지하면서 깨끗한 컨텍스트를 가진 새로운 서브 에이전트 (Subagent)를 생성할 수 있습니다. 나아가, 에이전트는 컨텍스트 제한에 도달했을 때 이전 작업을 잃어버리는 대신, 메모리에서 연구 계획과 같은 저장된 컨텍스트를 검색할 수 있습니다. 이러한 분산형 접근 방식은 컨텍스트 오버플로 (Context overflow)를 방지하는 동시에 확장된 상호작용 전반에 걸쳐 대화의 일관성을 유지합니다.

저희 시스템에서 리드 에이전트 (Lead agent)는 쿼리를 서브태스크 (Subtask)로 분해하고 이를 서브 에이전트들에게 설명합니다. 각 서브 에이전트는 목표, 출력 형식, 사용할 도구 및 소스에 대한 안내, 그리고 명확한 작업 경계가 필요합니다. 상세한 작업 설명이 없으면 에이전트들은 작업을 중복하거나, 공백을 남기거나, 필요한 정보를 찾는 데 실패합니다.

컨텍스트 엔지니어링 (Context engineering)은 에이전트 시스템을 안정적으로 작동하게 만드는 데 매우 중요합니다. 이러한 통찰은 저희의 에이전트 및 멀티 에이전트 프레임워크인 LangGraph를 개발하는 지침이 되었습니다. 프레임워크를 사용할 때는 LLM에 무엇이 전달되는지, 그리고 어떤 단계가 어떤 순서로 실행되는지(LLM에 전달될 컨텍스트를 생성하기 위해)에 대해 완전한 제어권을 가져야 합니다. 저희는 숨겨진 프롬프트(Prompt)나 강제된 "인지 아키텍처 (Cognitive architectures)"가 없는 저수준 오케스트레이션 (Low-level orchestration) 프레임워크인 LangGraph를 통해 이를 우선시합니다. 이를 통해 귀하는 필요한 적절한 컨텍스트 엔지니어링을 수행할 수 있는 완전한 제어권을 갖게 됩니다.

주로 "읽는" 멀티 에이전트 시스템이 "쓰는" 시스템보다 더 쉽습니다

주로 "읽기" 작업을 위해 설계된 멀티 에이전트 시스템 (Multi-agent systems)은 "쓰기" 작업에 집중하는 시스템보다 관리하기가 더 쉬운 경향이 있습니다. 이러한 차이는 두 블로그 포스트, 즉 Cognition의 코딩 중심 시스템과 Anthropic의 연구 지향적 접근 방식을 비교할 때 명확해집니다.

코딩과 연구 모두 읽기와 쓰기를 포함하지만, 강조하는 측면이 다릅니다. 핵심적인 통찰은 읽기 동작 (read actions)이 본질적으로 쓰기 동작 (write actions)보다 병렬화 (parallelizable)하기 더 쉽다는 점입니다. 쓰기를 병렬화하려고 시도할 때, 에이전트 간에 컨텍스트 (context)를 효과적으로 전달하고 그 출력물들을 일관성 있게 병합해야 하는 이중의 과제에 직면하게 됩니다. Cognition 블로그 포스트에서 언급했듯이, "동작 (Actions)에는 암묵적인 결정이 포함되어 있으며, 충돌하는 결정은 나쁜 결과를 초래합니다." 이는 읽기와 쓰기 모두에 적용되지만, 충돌하는 쓰기 동작은 일반적으로 충돌하는 읽기 동작보다 훨씬 더 나쁜 결과를 생성합니다. 여러 에이전트가 동시에 코드나 콘텐츠를 작성할 때, 그들의 충돌하는 결정은 조정하기 어려운 호환되지 않는 출력물을 만들어낼 수 있습니다.

Anthropic의 Claude Research는 이 원칙을 잘 보여줍니다. 이 시스템은 읽기와 쓰기를 모두 포함하지만, 멀티 에이전트 아키텍처 (multi-agent architecture)는 주로 연구 (읽기) 구성 요소를 처리합니다. 실제 쓰기 작업—발견된 내용들을 일관된 보고서로 합성하는 작업—은 의도적으로 하나의 통합된 호출 (unified call) 내에서 단일 메인 에이전트에 의해 처리됩니다. 이러한 설계 선택은 협업 쓰기가 불필요한 복잡성을 초래한다는 점을 인지한 결과입니다.

하지만 읽기 비중이 높은 멀티 에이전트 시스템이라 할지라도 구현이 결코 간단하지는 않습니다. 이 역시 여전히 정교한 컨텍스트 엔지니어링 (context engineering)을 필요로 합니다. Anthropic은 이를 직접 경험하며 깨달았습니다:

우리는 리드 에이전트 (lead agent)가 '반도체 부족 현상을 조사하라'와 같이 단순하고 짧은 지침을 내리도록 허용하는 것부터 시작했습니다. 하지만 이러한 지침은 종종 하위 에이전트 (subagents)가 작업을 오해하거나, 다른 에이전트와 정확히 동일한 검색을 수행할 정도로 모호하다는 것을 발견했습니다. 예를 들어, 한 하위 에이전트는 2021년 자동차 칩 위기를 조사하는 동안, 다른 2개의 하위 에이전트는 효과적인 분업 없이 현재의 2025년 공급망을 조사하며 작업을 중복 수행했습니다.

프로덕션 신뢰성 및 엔지니어링 과제 (Production reliability and engineering challenges)

멀티 에이전트 시스템 (multi-agent systems)을 사용하든 복잡한 단일 에이전트 (single agent) 시스템을 사용하든, 몇 가지 신뢰성 및 엔지니어링 과제가 발생합니다. Anthropic의 블로그 포스트는 이러한 점을 아주 잘 강조하고 있습니다. 이러한 과제들은 Anthropic의 사용 사례에만 국한된 것이 아니라, 사실 상당히 일반적입니다. 우리가 구축해 온 많은 도구 (tooling)들은 이러한 문제들을 일반적인 방식으로 해결하는 것을 목표로 해왔습니다.

지속 가능한 실행 및 에러 핸들링 (Durable execution and error handling)

에이전트는 상태 유지 (stateful) 방식이며 에러는 누적됩니다. 에이전트는 많은 도구 호출 (tool calls)에 걸쳐 상태를 유지하며 오랜 기간 실행될 수 있습니다. 이는 우리가 코드를 지속 가능하게 실행 (durably execute)하고 진행 과정에서 발생하는 에러를 처리해야 함을 의미합니다. 효과적인 완화 조치가 없다면, 사소한 시스템 장애가 에이전트에게는 치명적일 수 있습니다. 에러가 발생했을 때 단순히 처음부터 다시 시작할 수는 없습니다. 재시작은 비용이 많이 들고 사용자에게 좌절감을 주기 때문입니다. 대신, 우리는 에러가 발생했을 당시 에이전트가 있던 지점부터 재개할 수 있는 시스템을 구축했습니다.

이러한 지속 가능한 실행 (durable execution)은 우리의 에이전트 오케스트레이션 프레임워크 (agent orchestration framework)인 LangGraph의 핵심 부분입니다. 우리는 모든 장기 실행 에이전트 (long running agents)에 이것이 필요할 것이라고 믿으며, 따라서 에이전트 오케스트레이션 프레임워크에 내장되어야 한다고 생각합니다.

에이전트 디버깅 및 관측 가능성 (Agent Debugging and Observability)

에이전트는 동적인 결정을 내리며, 동일한 프롬프트(Prompt)를 사용하더라도 실행 시마다 비결정론적 (Non-deterministic)인 특성을 보입니다. 이로 인해 디버깅이 더 어려워집니다. 예를 들어, 사용자들이 에이전트가 "명백한 정보를 찾지 못한다"라고 보고하더라도, 우리는 그 이유를 알 수 없었습니다. 에이전트가 잘못된 검색 쿼리 (Search queries)를 사용했나요? 부적절한 소스를 선택했나요? 아니면 도구 (Tool) 호출 실패가 발생했나요? 전체 프로덕션 트레이싱 (Production tracing)을 추가함으로써, 우리는 에이전트가 왜 실패했는지 진단하고 문제를 체계적으로 해결할 수 있게 되었습니다.

우리는 LLM 시스템을 위한 관측 가능성 (Observability)이 전통적인 소프트웨어의 관측 가능성과는 다르다는 점을 오래전부터 인식해 왔습니다. 그 주요 이유는 이러한 유형의 도전 과제들을 디버깅할 수 있도록 최적화되어야 하기 때문입니다. 이것이 정확히 무엇을 의미하는지 잘 모르겠다면, 에이전트 디버깅 및 관측 가능성 등을 제공하는 우리의 플랫폼인 LangSmith를 확인해 보세요. 우리는 지난 2년 동안 이러한 유형의 과제들을 처리하기 위해 LangSmith를 구축해 왔습니다. 직접 사용해 보시고 이것이 왜 그토록 중요한지 확인해 보세요!

에이전트 평가 (Evaluation of agents)

Anthropic의 포스트 중 한 섹션 전체가 "에이전트의 효과적인 평가"에 할애되어 있습니다. 우리가 선호하는 몇 가지 핵심 요점은 다음과 같습니다:

• 평가 (Evals)는 작게 시작하세요. 약 20개의 데이터 포인트 (Datapoints)만으로도 충분합니다.
• LLM-as-a-judge를 통해 실험의 점수 산정 (Scoring)을 자동화할 수 있습니다.
• 인간의 테스트 (Human testing)는 여전히 필수적입니다.

이는 우리의 평가 방식과 전적으로 일치합니다. 우리는 한동안 LangSmith에 평가 기능을 구축해 왔으며, 이러한 측면을 돕기 위한 몇 가지 기능들을 선보였습니다:

• 데이터 포인트 (Datapoints)를 쉽게 큐레이션할 수 있는 데이터셋 (Datasets)
• 서버 측에서 실행되는 LLM-as-a-judge (곧 더 많은 기능이 추가될 예정입니다!)
• 인간의 평가를 조정하고 용이하게 하는 어노테이션 큐 (Annotation queues)

결론

Anthropic의 블로그 포스트에는 멀티 에이전트 시스템이 어디에서 가장 잘 작동하거나 작동하지 않을 수 있는지에 대한 통찰도 포함되어 있습니다:

우리의 내부 평가에 따르면, 멀티 에이전트 연구 시스템은 여러 독립적인 방향을 동시에 추구해야 하는 너비 우선 (Breadth-first) 쿼리에 특히 탁월한 성능을 보입니다.

멀티 에이전트 시스템 (Multi-agent systems)이 효과적으로 작동하는 주요 이유는 문제를 해결하기 위해 충분한 토큰 (tokens)을 소비할 수 있도록 돕기 때문입니다. 멀티 에이전트 아키텍처 (Multi-agent architectures)는 단일 에이전트의 한계를 초과하는 작업에 대해 토큰 사용량을 효과적으로 확장(scale)합니다.

경제적 생존 가능성을 위해서는, 멀티 에이전트 시스템이 향상된 성능에 대한 비용을 지불할 수 있을 만큼 작업의 가치가 충분히 높은 작업이 필요합니다.

나아가, 모든 에이전트가 동일한 컨텍스트 (context)를 공유해야 하거나 에이전트 간의 의존성이 많은 일부 도메인은 현재의 멀티 에이전트 시스템에 적합하지 않습니다. 예를 들어, 대부분의 코딩 작업은 연구 작업보다 진정으로 병렬화 (parallelizable) 가능한 작업이 적으며, LLM 에이전트는 아직 실시간으로 다른 에이전트와 조정하거나 권한을 위임 (delegating)하는 데 능숙하지 않습니다. 우리는 멀티 에이전트 시스템이 과도한 병렬화가 필요하거나, 단일 컨텍스트 윈도우 (context windows)를 초과하는 정보가 포함되거나, 수많은 복잡한 도구와 인터페이스를 주고받아야 하는 가치 있는 작업에서 탁월한 성능을 보인다는 것을 발견했습니다.

에이전트를 구축할 때 빠르게 드러나듯, 모든 상황에 들어맞는