🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

멀티 에이전트 시스템은 무조건 좋은 해법이 아니라, 충분한 컨텍스트 엔지니어링과 병렬화 가능한 읽기 중심 작업, 높은 작업 가치가 맞아떨어질 때 특히 유용하다는 글이다.

📌 핵심 요약

• 글은 Cognition의 “Don’t Build Multi-Agents”와 Anthropic의 “How we built our multi-agent research system”이 제목은 반대처럼 보이지만, 실제로는 멀티 에이전트 시스템을 언제 어떻게 써야 하는지에 대해 공통된 통찰을 준다고 본다.
• 핵심은 컨텍스트 엔지니어링이다. 모델이 아무리 지능적이어도 필요한 배경, 목표, 경계, 도구 사용 방식, 출력 형식을 제대로 전달받지 못하면 하위 에이전트가 중복 작업을 하거나 중요한 정보를 놓치기 쉽다.
• 읽기 중심 작업은 쓰기 중심 작업보다 멀티 에이전트화하기 쉽다. 여러 에이전트가 동시에 정보를 조사하는 것은 비교적 병렬화하기 좋지만, 여러 에이전트가 동시에 코드나 문서를 작성하면 암묵적 결정이 충돌해 결과 병합이 어려워질 수 있다.
• 실서비스 수준의 에이전트에는 긴 실행을 중단 없이 이어가는 내구 실행, 오류 복구, 전체 추적을 통한 디버깅과 관찰 가능성, 작은 데이터셋에서 시작하는 평가, LLM-as-a-judge와 인간 평가의 조합이 필요하다.
• 결론적으로 멀티 에이전트 시스템은 폭넓은 병렬 탐색, 단일 컨텍스트 창을 넘는 정보량, 여러 복잡한 도구 사용이 필요한 고가치 작업에 적합하지만, 모든 문제에 맞는 단일 해법은 아니며 문제 성격에 따라 단일 에이전트와 멀티 에이전트 사이에서 선택해야 한다.

🧩 주요 포인트

1. 글은 Cognition의 “Don’t Build Multi-Agents”와 Anthropic의 “How we built our multi-agent research system”이 제목은 반대처럼 보이지만, 실제로는 멀티 에이전트 시스템을 언제 어떻게 써야 하는지에 대해 공통된 통찰을 준다고 본다.
2. 핵심은 컨텍스트 엔지니어링이다. 모델이 아무리 지능적이어도 필요한 배경, 목표, 경계, 도구 사용 방식, 출력 형식을 제대로 전달받지 못하면 하위 에이전트가 중복 작업을 하거나 중요한 정보를 놓치기 쉽다.
3. 읽기 중심 작업은 쓰기 중심 작업보다 멀티 에이전트화하기 쉽다. 여러 에이전트가 동시에 정보를 조사하는 것은 비교적 병렬화하기 좋지만, 여러 에이전트가 동시에 코드나 문서를 작성하면 암묵적 결정이 충돌해 결과 병합이 어려워질 수 있다.
4. 실서비스 수준의 에이전트에는 긴 실행을 중단 없이 이어가는 내구 실행, 오류 복구, 전체 추적을 통한 디버깅과 관찰 가능성, 작은 데이터셋에서 시작하는 평가, LLM-as-a-judge와 인간 평가의 조합이 필요하다.
5. 결론적으로 멀티 에이전트 시스템은 폭넓은 병렬 탐색, 단일 컨텍스트 창을 넘는 정보량, 여러 복잡한 도구 사용이 필요한 고가치 작업에 적합하지만, 모든 문제에 맞는 단일 해법은 아니며 문제 성격에 따라 단일 에이전트와 멀티 에이전트 사이에서 선택해야 한다.

🧠 상세 정리

1. 상반된 제목의 두 글이 공유하는 문제의식

글은 Cognition 팀의 “Don’t Build Multi-Agents”와 Anthropic 팀의 “How we built our multi-agent research system”을 출발점으로 삼는다. 두 글의 제목은 하나는 멀티 에이전트를 만들지 말라는 쪽, 다른 하나는 실제 멀티 에이전트 연구 시스템을 구축한 경험담처럼 보이기 때문에 표면적으로는 반대 입장처럼 보인다. 그러나 저자는 두 글이 실제로는 멀티 에이전트 시스템을 언제 쓰고 어떻게 설계해야 하는지에 대해 상당히 비슷한 교훈을 제공한다고 해석한다. 그 공통점은 크게 컨텍스트 엔지니어링의 중요성과, 읽기 중심 작업이 쓰기 중심 작업보다 멀티 에이전트 구조에 더 잘 맞는다는 판단으로 정리된다.

2. 컨텍스트 엔지니어링이 에이전트 개발의 핵심이 된 이유

저자는 멀티 에이전트뿐 아니라 단일 에이전트 애플리케이션에서도 가장 어려운 문제 중 하나가 모델에게 해야 할 일의 맥락을 효과적으로 전달하는 것이라고 설명한다. 2025년의 모델들은 매우 지능적이지만, 아무리 똑똑한 사람이라도 주어진 업무의 배경과 목적을 모르면 일을 잘할 수 없다는 비유를 든다. 과거의 프롬프트 엔지니어링이 챗봇에게 작업을 이상적인 형식으로 쓰는 문제였다면, 컨텍스트 엔지니어링은 동적인 시스템 안에서 그 일을 자동으로 수행하는 더 높은 단계의 문제다. 특히 멀티 에이전트에서는 각 하위 에이전트가 적절한 정보를 받도록 보장하기가 더 어려워지므로, 이 작업이 에이전트 엔지니어의 가장 중요한 역할이 된다고 본다.

3. Anthropic 사례에서 드러난 긴 대화와 기억 관리

Anthropic의 글은 ‘컨텍스트 엔지니어링’이라는 용어를 직접 쓰지는 않지만, 실제 내용은 같은 문제를 반복해서 다룬다. 운영 환경의 에이전트는 수백 턴에 걸친 긴 대화를 처리할 수 있고, 일반적인 컨텍스트 창만으로는 부족하기 때문에 압축, 외부 메모리, 단계별 요약 같은 전략이 필요하다. Anthropic은 완료된 작업 단계를 요약해 중요한 정보를 외부 메모리에 저장하고, 새 작업으로 넘어갈 때 필요한 맥락을 다시 불러오는 패턴을 구현했다고 설명한다. 컨텍스트 한계에 가까워지면 깨끗한 컨텍스트를 가진 새 하위 에이전트를 만들되, 신중한 인수인계와 저장된 연구 계획 검색을 통해 연속성을 유지하는 방식도 소개된다.

4. 하위 에이전트에게 전달해야 하는 작업 설명의 구체성

멀티 에이전트 시스템에서는 리드 에이전트가 큰 질문을 하위 작업으로 나누고, 각 하위 에이전트에게 그 작업을 설명해야 한다. 이때 하위 에이전트는 단순한 주제 문장만이 아니라 명확한 목표, 기대되는 출력 형식, 사용할 도구와 정보원에 대한 안내, 그리고 어디까지가 자기 작업인지에 대한 경계를 받아야 한다. 설명이 충분히 구체적이지 않으면 여러 에이전트가 같은 검색을 반복하거나, 서로 다른 방향을 조사하지 못하거나, 필요한 정보를 찾지 못할 수 있다. 글에서는 ‘반도체 부족을 조사하라’ 같은 짧은 지시가 실제로는 하위 에이전트의 오해와 중복 작업을 낳았다는 사례를 통해 이 문제를 보여준다.

5. 프레임워크 선택과 제어권의 중요성

저자는 컨텍스트 엔지니어링을 제대로 하려면 프레임워크가 LLM에 무엇을 전달하는지, 어떤 단계가 어떤 순서로 실행되는지에 대한 충분한 제어권을 제공해야 한다고 주장한다. 이를 LangGraph의 설계 철학과 연결하면서, 숨겨진 프롬프트나 강제된 ‘인지 아키텍처’ 없이 낮은 수준의 오케스트레이션을 제공하는 접근을 강조한다. 핵심은 프레임워크가 개발자를 대신해 고정된 구조를 강요하는 것이 아니라, 개발자가 문제에 맞는 컨텍스트 생성 과정을 직접 설계할 수 있게 해야 한다는 점이다. 따라서 이 글에서 프레임워크는 단순한 실행 도구가 아니라, 컨텍스트 전달과 실행 순서를 세밀하게 구성하기 위한 기반으로 다뤄진다.

6. 읽기 중심 멀티 에이전트가 쓰기 중심보다 쉬운 이유

글은 멀티 에이전트 시스템이 주로 읽기 작업을 수행할 때, 쓰기 작업을 수행할 때보다 관리하기 쉽다고 설명한다. 연구와 코딩은 모두 읽기와 쓰기를 포함하지만, 연구 시스템은 여러 방향의 정보를 병렬로 조사하는 읽기 비중이 크고, 코딩 시스템은 변경 사항을 실제 산출물에 반영하는 쓰기 충돌 문제가 더 두드러진다. 읽기 작업은 여러 에이전트가 서로 다른 자료나 관점을 동시에 탐색하기 쉬운 반면, 쓰기 작업은 각 에이전트가 내린 암묵적 결정이 서로 맞지 않을 때 병합이 어렵다. Cognition 글의 표현처럼 행동에는 암묵적 결정이 따르며, 충돌하는 결정은 나쁜 결과를 낳을 수 있는데, 특히 코드나 콘텐츠를 동시에 작성할 때 그 위험이 커진다.

7. Claude Research가 보여준 역할 분리

Anthropic의 Claude Research 사례는 읽기와 쓰기의 역할 분리를 잘 보여주는 예로 제시된다. 이 시스템도 조사와 작성이라는 두 요소를 모두 포함하지만, 멀티 에이전트 구조가 주로 담당하는 부분은 여러 방향으로 정보를 수집하고 탐색하는 연구, 즉 읽기 영역이다. 반대로 조사 결과를 하나의 일관된 보고서로 종합하는 실제 작성은 여러 하위 에이전트가 나눠 쓰는 방식이 아니라, 하나의 메인 에이전트가 단일 호출에서 처리하도록 설계되었다. 저자는 이 설계가 협업적 글쓰기가 불필요한 복잡성을 만든다는 점을 인정한 선택이라고 본다. 즉 멀티 에이전트의 장점은 무조건 모든 단계를 나누는 데 있는 것이 아니라, 병렬화가 유리한 단계와 통합이 필요한 단계를 구분하는 데 있다.

8. 실서비스에서 필요한 내구 실행과 오류 처리

글은 멀티 에이전트든 복잡한 단일 에이전트든, 운영 환경에서는 신뢰성과 엔지니어링 문제가 반드시 등장한다고 설명한다. 에이전트는 상태를 가진 채 많은 도구 호출을 거치며 오래 실행될 수 있기 때문에, 작은 시스템 오류도 누적되면 전체 작업에 치명적인 영향을 줄 수 있다. 오류가 났다고 처음부터 다시 시작하는 방식은 비용이 크고 사용자에게도 불편하므로, 오류가 발생한 지점에서 재개할 수 있는 내구 실행이 필요하다. 저자는 LangGraph가 이러한 내구 실행을 핵심 기능으로 포함한다고 설명하며, 장시간 실행되는 에이전트에는 이런 기능이 오케스트레이션 프레임워크 차원에서 필요하다고 본다.

9. 관찰 가능성, 디버깅, 평가가 필요한 이유

에이전트는 동일한 프롬프트에서도 실행마다 동적으로 다른 결정을 내릴 수 있고 비결정적으로 행동하기 때문에 디버깅이 어렵다. 예를 들어 사용자가 에이전트가 명백한 정보를 찾지 못했다고 보고해도, 검색 쿼리가 나빴는지, 출처 선택이 부적절했는지, 도구 호출이 실패했는지를 추적할 수 없으면 원인을 알기 어렵다. 그래서 글은 전체 프로덕션 트레이싱을 통해 실패 원인을 진단하고 체계적으로 수정할 수 있어야 한다고 말한다. 평가 측면에서는 약 20개 정도의 작은 데이터포인트로 시작해도 충분하며, LLM-as-a-judge로 실험 점수를 자동화하되 인간 테스트는 여전히 필수라고 정리한다.

10. 멀티 에이전트가 잘 맞는 조건과 최종 결론

결론부에서 저자는 멀티 에이전트 시스템이 특히 폭넓은 탐색이 필요한 질문, 여러 독립 방향을 동시에 추적해야 하는 작업, 단일 에이전트의 컨텍스트 창을 초과하는 정보량을 다루는 작업에서 강점을 가진다고 정리한다. 멀티 에이전트 구조가 작동하는 이유 중 하나는 문제 해결에 충분한 토큰을 쓰도록 해주기 때문이며, 따라서 비용 증가를 정당화할 만큼 작업 가치가 높아야 경제성이 있다. 반대로 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나 의존성이 많은 영역, 실시간 조율과 위임이 중요한 영역은 현재의 멀티 에이전트에 잘 맞지 않을 수 있다. 저자는 에이전트 설계에는 만능 해법이 없으며, 문제에 따라 단일 에이전트와 멀티 에이전트 사이의 적절한 지점을 선택해야 한다고 결론짓는다.

🧾 핵심 주장 / 시사점

• 멀티 에이전트 설계의 핵심 판단 기준은 에이전트 수가 아니라, 작업을 독립적인 하위 탐색으로 나눌 수 있는지와 각 하위 에이전트에 충분한 컨텍스트를 줄 수 있는지이다.
• 쓰기 작업을 여러 에이전트에 병렬로 맡기는 것은 산출물 병합과 결정 충돌 때문에 위험할 수 있으므로, 조사와 종합처럼 병렬화 가능한 단계와 일관성이 필요한 단계를 분리하는 설계가 중요하다.
• 실제 제품 수준의 에이전트 시스템은 모델 성능만으로 완성되지 않으며, 내구 실행, 추적 기반 디버깅, 관찰 가능성, 평가 체계 같은 일반 인프라를 함께 갖춰야 안정적으로 운영될 수 있다.

✅ 액션 아이템

• 컨텍스트 엔지니어링 기준으로 배경·목표·도구 사용 방식·출력 형식을 사전 명세해 하위 에이전트의 중복 작업과 정보 누락을 줄인다.
• 읽기 병렬 탐색이 가능한 고가치 과제는 멀티 에이전트로 분해하고, 코드·문서 동시 작성 과제는 단일 에이전트로 묶어 충돌 위험을 낮춘다.
• 실서비스 에이전트는 장기 실행의 내구성, 오류 복구, 전 과정 추적, 소규모 데이터셋 평가, LLM-as-a-judge와 인간 평가의 병행 체계를 함께 둔다.

❓ 열린 질문

• 컨텍스트 엔지니어링이 충분하지 않을 때에도 멀티 에이전트를 써야 하는 임계 작업량은 어떤 기준으로 정의할 것인가?
• 읽기 중심과 쓰기 중심이 혼재된 과제에서 멀티 에이전트로 분해할 경계는 어떤 기준으로 설정해야 충돌을 줄일 수 있는가?
• 실서비스에서 오류 복구와 관측성 비용을 감안해 LLM-as-a-judge와 인간 평가의 비중은 어떤 방식으로 조정하는 것이 적절한가?