Don’t Build Multi-Agents
TMThttps://cognition.ai/blog/dont-build-multi-agents. LLM 에이전트 프레임워크는 놀라울 정도로 실망스러웠습니다. 우리는 직접 시행착오를 겪으며 얻은 에이전트 구축 원칙을 제시하고, 실제로는 꽤 나쁜 결과를 초래하는 몇 가지 유혹적인 아이디어에 대해 설명하고자 합니다.
컨텍스트 엔지니어링의 원칙
다음과 같은 원칙으로 차근차근 나아가겠습니다:
- 컨텍스트를 공유하라
- 행동에는 암묵적 결정이 담겨 있다
왜 원칙을 고민해야 할까요?
HTML은 1993년에 도입되었습니다. 2013년, Facebook은 React를 세상에 공개했습니다. 지금은 2025년이고, React(및 그 후손들)는 개발자들이 사이트와 앱을 만드는 방식을 지배하고 있습니다. 왜일까요? React는 단순히 코드를 작성하기 위한 뼈대가 아니라, 하나의 철학이기 때문입니다. React를 사용한다는 것은 반응성과 모듈성을 패턴으로 삼아 애플리케이션을 구축하는 방식을 받아들이는 것이고, 이는 이제 표준 요구사항으로 받아들여지지만, 초기 웹 개발자들에게는 결코 자명하지 않았습니다.
LLM과 AI 에이전트 구축의 시대에 우리는 여전히 원시적인 HTML & CSS를 가지고 좋은 경험을 만들기 위해 이리저리 맞춰보는 단계에 있는 것처럼 느껴집니다. 에이전트 구축에 있어 아직 표준이 된 접근법은, 몇 가지 절대적인 기본을 제외하면, 존재하지 않습니다.
어떤 경우에는 OpenAI의 https://github.com/openai/swarm 이나 Microsoft의 https://github.com/microsoft/autogen 같은 라이브러리들이 실제로는 잘못된 방식의 에이전트 구축 개념을 적극적으로 밀고 있다고 생각합니다. 즉, 멀티 에이전트 아키텍처를 사용하는 것인데, 그 이유를 설명하겠습니다.
에이전트 구축이 처음이라면, 기본적인 뼈대를 세팅하는 방법에 대한 자료는 많습니다[1][2]. 하지만 진지하게 프로덕션 애플리케이션을 구축할 때는 이야기가 완전히 달라집니다.
장시간 동작하는 에이전트 구축 이론
신뢰성부터 시작해봅시다. 에이전트가 오랜 시간 동안 실제로 신뢰성 있게 동작하고 일관된 대화를 유지해야 할 때, 누적되는 오류의 가능성을 통제하기 위해 반드시 해야 하는 일들이 있습니다. 그렇지 않으면, 조심하지 않으면 모든 것이 금방 무너집니다. 신뢰성의 핵심에는 컨텍스트 엔지니어링이 있습니다.
컨텍스트 엔지니어링
2025년 현재, 세상에 나온 모델들은 매우 지능적입니다. 하지만 아무리 똑똑한 사람이라도 자신이 해야 할 일의 컨텍스트가 없다면 효과적으로 일할 수 없습니다. “프롬프트 엔지니어링”은 LLM 챗봇에 최적의 형식으로 작업을 작성해야 하는 노력을 일컫는 용어로 등장했습니다. “컨텍스트 엔지니어링”은 그 다음 단계입니다. 이는 동적 시스템에서 이를 자동으로 수행하는 것입니다. 더 많은 뉘앙스가 필요하며, 사실상 AI 에이전트를 구축하는 엔지니어의 가장 중요한 역할입니다.
일반적인 유형의 에이전트를 예로 들어봅시다. 이 에이전트는
- 작업을 여러 부분으로 나눕니다
- 그 부분을 처리할 서브에이전트를 시작합니다
- 마지막에 그 결과를 합칩니다
이것은 특히 여러 병렬 컴포넌트가 있는 도메인에서 일할 때 유혹적인 아키텍처입니다. 하지만 매우 취약합니다. 핵심 실패 지점은 다음과 같습니다:
Task가 “Flappy Bird 클론 만들기”라고 합시다. 이것이 Subtask 1 “녹색 파이프와 히트박스가 있는 움직이는 게임 배경 만들기”와 Subtask 2 “상하로 움직일 수 있는 새 만들기”로 나뉩니다.
그런데 서브에이전트 1은 실제로 서브태스크를 오해해서 Super Mario Bros.처럼 보이는 배경을 만들기 시작합니다. 서브에이전트 2는 새를 만들었지만, 게임 에셋처럼 보이지도 않고 Flappy Bird의 새처럼 움직이지도 않습니다. 이제 최종 에이전트는 이 두 오해가 섞인 결과물을 합쳐야 하는 난감한 상황에 처합니다.
이것이 억지스러워 보일 수 있지만, 실제 현실의 대부분의 작업에는 수많은 뉘앙스가 존재하며, 모두 오해의 소지가 있습니다. 단순히 원래 작업을 서브에이전트에게도 컨텍스트로 복사해주면 오해를 막을 수 있다고 생각할 수 있습니다. 하지만 실제 프로덕션 시스템에서는 대화가 대부분 멀티턴이고, 에이전트가 작업을 분해하기 위해 여러 도구 호출을 했을 것이며, 수많은 세부사항이 작업 해석에 영향을 미칠 수 있습니다.
원칙 1
컨텍스트를 공유하라, 그리고 개별 메시지가 아니라 전체 에이전트 트레이스를 공유하라
이번에는 각 에이전트가 이전 에이전트의 컨텍스트를 갖도록 하여 에이전트를 다시 설계해봅시다.
불행히도, 아직 문제가 완전히 해결된 것은 아닙니다. 이번에는 Flappy Bird 클론 작업을 시켰더니, 새와 배경이 완전히 다른 시각적 스타일로 만들어질 수 있습니다. 서브에이전트 1과 2는 서로가 무엇을 하고 있는지 볼 수 없으므로, 결과물이 서로 일관성이 없게 됩니다.
서브에이전트 1이 내린 행동과 서브에이전트 2가 내린 행동은 처음에 명시되지 않은 상충되는 가정에 기반했습니다.
원칙 2
행동에는 암묵적 결정이 담겨 있고, 상충되는 결정은 나쁜 결과를 낳는다
저는 원칙 1과 2가 너무나도 중요하고, 거의 예외 없이 지켜야 하므로, 이 원칙을 지키지 않는 에이전트 아키텍처는 기본적으로 배제해야 한다고 생각합니다. 이것이 제약적으로 느껴질 수 있지만, 실제로는 여전히 다양한 아키텍처를 탐구할 수 있는 넓은 공간이 존재합니다.
이 원칙을 따르는 가장 단순한 방법은 단일 스레드의 선형 에이전트를 사용하는 것입니다:
여기서는 컨텍스트가 연속적입니다. 하지만 아주 많은 하위 작업이 있는 매우 큰 작업에서는 컨텍스트 윈도우가 넘쳐흐르는 문제가 발생할 수 있습니다.
사실, 이 단순한 아키텍처만으로도 상당히 많은 것을 할 수 있습니다. 하지만 정말로 장기 작업을 처리해야 하고, 그만큼의 노력을 기울일 의지가 있다면, 더 나은 방법도 있습니다. 여러 가지 방법이 있지만, 오늘은 그 중 하나만 소개하겠습니다:
이 경우, 새로운 LLM 모델을 도입합니다. 이 모델의 핵심 목적은 행동 및 대화의 이력을 주요 세부사항, 이벤트, 결정으로 압축하는 것입니다. 이것은 제대로 구현하기 어렵습니다. 어떤 정보가 핵심인지 파악하고, 이를 잘 처리하는 시스템을 만드는 데 투자해야 합니다. 도메인에 따라서는 소형 모델을 파인튜닝하는 것도 고려할 수 있습니다(실제로 Cognition에서 우리가 했던 일입니다).
이렇게 하면 더 긴 컨텍스트에서도 효과적으로 동작하는 에이전트를 만들 수 있습니다. 물론 결국 한계에 도달하게 됩니다. 관심 있는 독자라면 임의로 긴 컨텍스트를 관리하는 더 나은 방법을 고민해보시기 바랍니다. 이 문제는 정말 깊은 토끼굴입니다!
원칙 적용하기
에이전트 빌더라면, 시스템의 다른 부분에서 내린 모든 관련 결정의 컨텍스트를 바탕으로 에이전트의 모든 행동이 이루어지도록 해야 합니다. 이상적으로는 모든 행동이 다른 모든 것을 볼 수 있어야 합니다. 하지만 컨텍스트 윈도우의 한계와 실용적 트레이드오프 때문에 항상 가능한 것은 아니며, 원하는 신뢰성 수준에 따라 어느 정도의 복잡성을 감수할지 결정해야 할 수도 있습니다.
상충되는 의사결정을 피하기 위해 에이전트 아키텍처를 고민할 때, 다음과 같은 실제 사례를 생각해볼 수 있습니다:
Claude Code 서브에이전트
2025년 6월 기준, Claude Code는 서브태스크를 생성하는 에이전트의 예입니다. 하지만 메인 에이전트와 서브태스크 에이전트가 병렬로 작업하는 일은 결코 없으며, 서브태스크 에이전트는 대개 질문에 답하는 역할만 하고, 코드를 작성하지는 않습니다. 왜일까요? 서브태스크 에이전트는 메인 에이전트로부터 필요한 컨텍스트를 받지 못하기 때문에, 명확하게 정의된 질문에 답하는 것 이상의 작업을 할 수 없습니다. 만약 여러 병렬 서브에이전트를 실행한다면, 서로 상충되는 답변을 내놓아 앞서 본 신뢰성 문제로 이어질 수 있습니다. 이 경우 서브에이전트를 두는 이점은, 서브에이전트의 조사 작업이 메인 에이전트의 히스토리에 남지 않아 더 긴 트레이스를 확보할 수 있다는 점입니다. Claude Code의 설계자는 의도적으로 단순한 접근을 택한 것입니다.
Edit Apply 모델
2024년에는 많은 모델들이 코드 편집에 매우 취약했습니다. 코딩 에이전트, IDE, 앱 빌더 등(Devin 포함)에서 흔히 사용된 방법은 “edit apply 모델”이었습니다. 핵심 아이디어는, 대형 모델이 코드 변경 설명을 마크다운으로 출력하면, 소형 모델이 그 설명을 받아 전체 파일을 다시 작성하는 것이, 대형 모델이 제대로 포맷된 diff를 출력하는 것보다 더 신뢰할 수 있다는 것이었습니다. 하지만 이런 시스템도 여전히 매우 불안정했습니다. 예를 들어, 소형 모델이 대형 모델의 지시를 아주 사소한 모호함 때문에 잘못 해석해 잘못된 수정을 하는 경우가 많았습니다. 오늘날에는 편집 결정과 적용이 한 번의 액션에서 하나의 모델에 의해 이루어지는 경우가 많아졌습니다.
멀티 에이전트
시스템에서 병렬성을 얻고 싶다면, 의사결정자들이 서로 “대화”하며 문제를 해결하도록 하고 싶을 수 있습니다.
이것이 바로 우리가 인간으로서 의견이 다를 때(이상적인 세계에서) 하는 방식입니다. 엔지니어 A의 코드가 엔지니어 B의 코드와 머지 충돌을 일으키면, 올바른 절차는 차이점을 논의하고 합의에 도달하는 것입니다. 하지만 오늘날의 에이전트는, 인간이 하는 것만큼 신뢰성 있게 장기적이고 능동적인 담론을 펼칠 수 없습니다. 인간은 가장 중요한 지식을 서로에게 효율적으로 전달할 수 있지만, 이 효율성은 결코 사소하지 않은 지능을 필요로 합니다.
ChatGPT 출시 직후부터, 여러 에이전트가 상호작용하며 목표를 달성하는 아이디어가 꾸준히 연구되어 왔습니다[3][4]. 장기적으로는 에이전트 간 협업에 대해 낙관적이지만, 2025년 현재, 여러 에이전트를 협업시키면 시스템이 매우 취약해집니다. 의사결정이 지나치게 분산되고, 에이전트 간에 컨텍스트가 충분히 공유되지 않기 때문입니다. 현재로서는 이 어려운 크로스 에이전트 컨텍스트 전달 문제를 전념해서 해결하는 시도를 보지 못했습니다. 제 생각에는, 단일 스레드 에이전트가 인간과 더 잘 소통하게 되면, 이 문제는 자연스럽게 해결될 것이고, 그때가 되면 훨씬 더 큰 병렬성과 효율성이 열릴 것입니다.
더 일반적인 이론을 향하여
이러한 컨텍스트 엔지니어링에 대한 관찰은 언젠가 에이전트 구축의 표준 원칙이 될 수 있는 것의 시작에 불과합니다. 여기서 다루지 않은 더 많은 도전과 기법이 존재합니다. Cognition에서는 에이전트 구축이 우리가 집중하는 핵심 영역입니다. 우리는 반복적으로 깨닫게 되는 이러한 원칙을 강제하는 방식으로 내부 도구와 프레임워크를 구축합니다. 하지만 우리의 이론이 완벽하다고 생각하지 않으며, 분야가 발전함에 따라 변화가 있을 것이라 예상하기 때문에, 어느 정도의 유연성과 겸손함도 필요합니다.