How and when to build multi-agent systems

https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/

최근, 제목이 상반된 두 개의 훌륭한 블로그 글이 공개되었습니다. Cognition 팀의 “Don’t Build Multi-Agents(멀티 에이전트 시스템을 만들지 마세요)”와 Anthropic 팀의 “How we built our multi-agent research system(우리가 멀티 에이전트 연구 시스템을 어떻게 구축했는가)”입니다.

제목은 상반되어 보이지만, 실제로는 두 글 모두 멀티 에이전트 시스템을 어떻게, 언제 구축해야 하는지에 대한 공통된 통찰을 담고 있습니다.

1. 컨텍스트 엔지니어링이 매우 중요하다
2. 주로 “읽기”에 집중하는 멀티 에이전트 시스템이 “쓰기”에 집중하는 시스템보다 더 쉽다

컨텍스트 엔지니어링이 중요하다

멀티 에이전트(혹은 단일 에이전트) 애플리케이션을 구축할 때 가장 어려운 부분 중 하나는 모델에게 요청받은 작업의 컨텍스트를 효과적으로 전달하는 것입니다. Cognition 블로그 글에서는 이 과제를 “컨텍스트 엔지니어링”이라는 용어로 소개합니다.

2025년 현재, 출시된 모델들은 매우 지능적입니다. 하지만 가장 똑똑한 인간이라도 자신이 무엇을 해야 하는지에 대한 컨텍스트가 없다면 효과적으로 일을 할 수 없습니다. “프롬프트 엔지니어링”은 LLM 챗봇에 작업을 이상적인 형식으로 작성해야 하는 노력을 설명하는 용어로 만들어졌습니다. “컨텍스트 엔지니어링”은 그 다음 단계입니다. 이는 동적 시스템에서 이를 자동으로 수행하는 것을 의미합니다. 더 많은 세밀함이 필요하며, AI 에이전트를 구축하는 엔지니어에게 사실상 가장 중요한 역할입니다.

몇 가지 예시를 통해 멀티 에이전트 시스템을 사용할 때 각 서브 에이전트가 적절한 컨텍스트를 갖추는 것이 더 어려워진다는 점을 보여줍니다.

Anthropic 블로그 글에서는 “컨텍스트 엔지니어링”이라는 용어를 명시적으로 사용하지는 않지만, 여러 부분에서 동일한 문제를 다룹니다. Anthropic 팀 역시 컨텍스트 엔지니어링에 상당한 시간을 투자한 것이 분명합니다. 주요 내용을 아래에 정리합니다.

장기 대화 관리. 프로덕션 에이전트는 수백 번의 턴에 걸친 대화를 진행하는 경우가 많아, 신중한 컨텍스트 관리 전략이 필요합니다. 대화가 길어질수록 표준 컨텍스트 윈도우는 부족해지므로, 지능적인 압축 및 메모리 메커니즘이 필요합니다. 우리는 에이전트가 완료된 작업 단계를 요약하고, 필수 정보를 외부 메모리에 저장한 후 새로운 작업을 진행하는 패턴을 구현했습니다. 컨텍스트 한계에 다다르면, 에이전트는 깨끗한 컨텍스트를 가진 새로운 서브에이전트를 생성하면서도, 신중한 인계 과정을 통해 연속성을 유지할 수 있습니다. 또한, 에이전트는 메모리에 저장된 연구 계획 등 이전 작업의 컨텍스트를 다시 불러올 수 있으므로, 컨텍스트 한계에 도달해도 이전 작업을 잃지 않습니다. 이러한 분산 접근 방식은 컨텍스트 오버플로우를 방지하면서도, 장기 상호작용의 일관성을 유지합니다.

우리 시스템에서 리드 에이전트는 쿼리를 하위 작업으로 분해하고, 이를 서브에이전트에게 설명합니다. 각 서브에이전트는 목표, 출력 형식, 사용할 도구와 소스에 대한 안내, 명확한 작업 경계가 필요합니다. 작업 설명이 충분히 상세하지 않으면, 에이전트가 작업을 중복하거나, 누락하거나, 필요한 정보를 찾지 못할 수 있습니다.

컨텍스트 엔지니어링은 에이전틱 시스템을 안정적으로 작동시키는 데 필수적입니다. 이 통찰은 LangGraph(우리의 에이전트 및 멀티 에이전트 프레임워크) 개발에 큰 영향을 주었습니다. 프레임워크를 사용할 때는 LLM에 전달되는 내용과 실행되는 단계, 순서를 완전히 제어할 수 있어야 합니다(LLM에 전달되는 컨텍스트를 생성하기 위해서). 우리는 LangGraph에서 이를 최우선으로 고려합니다. LangGraph는 숨겨진 프롬프트나 강제된 “인지적 아키텍처”가 없는 저수준 오케스트레이션 프레임워크입니다. 이를 통해 필요한 컨텍스트 엔지니어링을 완전히 제어할 수 있습니다.

주로 “읽기”에 집중하는 멀티 에이전트 시스템이 “쓰기”에 집중하는 시스템보다 더 쉽다

주로 “읽기” 작업에 집중하는 멀티 에이전트 시스템은 “쓰기” 작업에 집중하는 시스템보다 관리가 더 쉽습니다. 이 차이는 Cognition의 코딩 중심 시스템과 Anthropic의 연구 중심 접근 방식을 비교할 때 명확해집니다.

코딩과 연구 모두 읽기와 쓰기를 포함하지만, 각각 강조하는 부분이 다릅니다. 핵심 통찰은 읽기 작업이 본질적으로 쓰기 작업보다 병렬화가 더 쉽다는 점입니다. 쓰기 작업을 병렬화하려고 하면, 에이전트 간 컨텍스트를 효과적으로 전달하는 것과 결과물을 일관되게 병합하는 두 가지 과제에 직면하게 됩니다. Cognition 블로그 글에서 언급하듯이: “행동에는 암묵적인 결정이 포함되어 있고, 결정이 충돌하면 나쁜 결과가 발생한다.” 이는 읽기와 쓰기 모두에 적용되지만, 쓰기 작업에서의 충돌이 읽기 작업보다 훨씬 더 심각한 결과를 초래합니다. 여러 에이전트가 동시에 코드나 콘텐츠를 작성하면, 충돌하는 결정으로 인해 호환되지 않는 결과물이 생성되어 이를 조율하기 어렵습니다.

Anthropic의 Claude Research는 이 원칙을 잘 보여줍니다. 시스템은 읽기와 쓰기를 모두 포함하지만, 멀티 에이전트 아키텍처는 주로 연구(읽기) 부분을 처리합니다. 실제 쓰기—즉, 연구 결과를 하나의 일관된 보고서로 통합하는 작업—는 단일 메인 에이전트가 한 번에 처리합니다. 이 설계는 협업적 쓰기가 불필요한 복잡성을 초래한다는 점을 인식한 결과입니다.

하지만 읽기 중심의 멀티 에이전트 시스템도 구현이 쉽지는 않습니다. 여전히 정교한 컨텍스트 엔지니어링이 필요합니다. Anthropic 역시 이를 직접 경험했습니다.

우리는 리드 에이전트가 ‘반도체 부족 사태를 조사하라’와 같은 간단하고 짧은 지시만을 주는 방식으로 시작했지만, 이러한 지시가 너무 모호해서 서브에이전트가 작업을 오해하거나, 다른 에이전트와 동일한 검색을 반복하는 경우가 많았습니다. 예를 들어, 한 서브에이전트는 2021년 자동차용 칩 위기를 조사했고, 두 명은 2025년 현재의 공급망을 중복 조사하는 등, 효과적인 역할 분담이 이루어지지 않았습니다.

프로덕션 신뢰성과 엔지니어링 과제

멀티 에이전트 시스템이든 복잡한 단일 에이전트 시스템이든, 여러 신뢰성과 엔지니어링 과제가 발생합니다. Anthropic의 블로그 글은 이를 잘 설명합니다. 이러한 과제는 Anthropic의 사례에만 국한되지 않고, 매우 일반적입니다. 우리가 개발한 많은 툴 역시 이러한 문제를 일반적으로 해결하는 데 초점을 맞추고 있습니다.

지속적 실행과 오류 처리

에이전트는 상태를 유지하며, 오류가 누적됩니다. 에이전트는 오랜 시간 동안 실행되며, 여러 도구 호출에 걸쳐 상태를 유지합니다. 따라서 코드를 지속적으로 실행하고, 오류를 처리해야 합니다. 효과적인 완화책이 없다면, 작은 시스템 오류도 에이전트에게 치명적일 수 있습니다. 오류가 발생하면 처음부터 다시 시작할 수 없습니다. 재시작은 비용이 많이 들고, 사용자에게 불편을 줍니다. 대신, 우리는 에이전트가 오류가 발생한 지점에서 다시 시작할 수 있도록 시스템을 구축했습니다.

이러한 지속적 실행은 LangGraph(우리의 에이전트 오케스트레이션 프레임워크)의 핵심입니다. 모든 장기 실행 에이전트에 반드시 필요한 기능이라고 생각하며, 따라서 에이전트 오케스트레이션 프레임워크에 기본적으로 포함되어야 한다고 봅니다.

에이전트 디버깅과 가시성(Observability)

에이전트는 동적으로 결정을 내리며, 동일한 프롬프트를 사용해도 실행마다 결과가 달라집니다. 이로 인해 디버깅이 더 어려워집니다. 예를 들어, 사용자가 에이전트가 “명백한 정보를 찾지 못한다”고 보고했지만, 우리는 그 이유를 알 수 없었습니다. 에이전트가 잘못된 검색 쿼리를 사용했는지, 잘못된 소스를 선택했는지, 도구 오류가 발생했는지 알 수 없었습니다. 전체 프로덕션 트레이싱을 추가하자, 에이전트가 실패한 원인을 진단하고, 체계적으로 문제를 해결할 수 있었습니다.

우리는 LLM 시스템의 가시성이 기존 소프트웨어의 가시성과 다르다는 점을 오래전부터 인식해 왔습니다. 그 이유는 이러한 문제를 디버깅하는 데 최적화되어야 하기 때문입니다. 이게 정확히 무엇을 의미하는지 궁금하다면, LangSmith(에이전트 디버깅과 가시성 등 다양한 기능을 제공하는 플랫폼)를 확인해 보세요. 우리는 지난 2년간 LangSmith를 개발해 이러한 문제를 해결해 왔습니다. 직접 사용해 보면 왜 이 기능이 중요한지 알 수 있을 것입니다!

에이전트 평가(Evaluation)

Anthropic 글에는 “에이전트의 효과적 평가”에 대한 전체 섹션이 있습니다. 우리가 공감하는 몇 가지 주요 내용은 다음과 같습니다.

• 평가(evals)는 소규모로 시작해도 된다. 20개 정도의 데이터포인트로도 충분하다
• LLM을 심판(judge)으로 활용해 실험의 점수를 자동화할 수 있다
• 인간 테스트는 여전히 필수적이다

이는 우리의 평가 접근 방식과도 완전히 일치합니다. 우리는 LangSmith에 평가 기능을 오래전부터 내장해 왔으며, 다음과 같은 기능을 제공하고 있습니다.

• 데이터셋을 통해 데이터포인트를 쉽게 관리
• 서버 측에서 LLM을 심판으로 실행(곧 더 많은 기능 추가 예정!)
• 인간 평가를 조율하고 지원하는 주석(Annotation) 큐

결론

Anthropic의 블로그 글에는 멀티 에이전트 시스템이 어디에서 잘 작동하는지에 대한 통찰도 담겨 있습니다.

내부 평가 결과, 멀티 에이전트 연구 시스템은 여러 독립적인 방향을 동시에 추구하는 폭넓은(breadth-first) 쿼리에서 특히 뛰어난 성능을 보였습니다.

멀티 에이전트 시스템은 문제를 해결하기 위해 충분한 토큰을 사용할 수 있도록 돕기 때문에 효과적으로 작동합니다…. 멀티 에이전트 아키텍처는 단일 에이전트의 한계를 넘는 작업에서 토큰 사용을 효과적으로 확장합니다.

경제적 타당성을 위해서는, 멀티 에이전트 시스템이 성능 향상에 따른 비용을 감당할 만큼 가치가 높은 작업에 적용되어야 합니다.

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

에이전트를 구축하다 보면, “만능(one-size-fits-all)” 솔루션은 없다는 점이 점점 더 분명해집니다. 대신, 여러 옵션을 탐색하고, 해결하려는 문제에 따라 최적의 방식을 선택해야 합니다.

어떤 에이전트 프레임워크를 선택하든, 이 스펙트럼 어디든 자유롭게 이동할 수 있어야 합니다. 우리는 LangGraph에서 이를 독특하게 강조해 왔습니다.

멀티 에이전트(혹은 복잡한 단일 에이전트) 시스템을 제대로 작동시키려면 새로운 툴링이 필요합니다. 지속적 실행, 디버깅, 가시성, 평가 등은 모두 개발자의 삶을 더 쉽게 만들어주는 새로운 도구입니다. 다행히도, 이러한 도구들은 범용적입니다. 즉, LangGraph와 LangSmith 같은 툴을 활용해 이러한 기능을 바로 사용할 수 있으므로, 비즈니스 로직에 더 집중할 수 있습니다.