[번역] 멀티 에이전트를 만들지 마세요 (Walden Yan)

이 글은 아래 Walden Yan 의 25년 6월 12일 포스트를 한글로 번역한 것입니다.

Cognition | Don’t Build Multi-Agents

멀티 에이전트를 만들지 마세요

LLM 에이전트 프레임워크는 놀라울 정도로 실망스러웠습니다. 저희가 직접 겪은 시행착오를 바탕으로 에이전트 구축을 위한 몇 가지 원칙을 제시하고, 왜 어떤 솔깃한 아이디어들이 실제로는 매우 나쁜 결과를 낳는지 설명하고자 합니다.

컨텍스트 엔지니어링(Context Engineering)의 원칙

우리는 다음 원칙들을 차근차근 살펴볼 것입니다:

• 컨텍스트를 공유하라

• 행동은 암묵적인 결정을 내포한다

왜 원칙에 대해 생각해야 하는가?

HTML은 1993년에 도입되었습니다. 2013년, 페이스북은 React를 세상에 공개했습니다. 그리고 지금 2025년, React(와 그 후속 기술들)는 개발자들이 사이트와 앱을 구축하는 방식을 지배하고 있습니다. 왜일까요? React는 단순히 코드를 작성하기 위한 비계(scaffold)가 아니기 때문입니다. 그것은 하나의 철학입니다. React를 사용함으로써, 당신은 반응성(reactivity)과 모듈성(modularity)이라는 패턴으로 애플리케이션을 구축하는 방식을 받아들이게 됩니다. 사람들은 이제 이를 표준적인 요구사항으로 여기지만, 초창기 웹 개발자들에게는 항상 명백한 것이 아니었습니다.

LLM과 AI 에이전트 구축의 시대에, 우리는 마치 날것의 HTML & CSS를 가지고 놀면서 어떻게 이들을 조합해야 좋은 경험을 만들 수 있을지 알아가는 단계에 있는 것 같습니다. 아직 몇 가지 절대적인 기본을 제외하고는 에이전트 구축에 대한 단일한 접근법이 표준으로 자리 잡지 못했습니다.

어떤 경우, OpenAI의 https://github.com/openai/swarm이나 Microsoft의 https://github.com/microsoft/autogen과 같은 라이브러리들은 제가 생각하기에 에이전트를 구축하는 잘못된 방식이라고 보는 개념들을 적극적으로 내세웁니다. 바로 멀티 에이전트 아키텍처를 사용하는 것인데, 그 이유를 설명하겠습니다.

그렇긴 하지만, 에이전트 구축이 처음이라면 기본적인 비계를 설정하는 방법에 대한 자료는 많이 있습니다]. 하지만 진지한 상용 애플리케이션을 구축하는 것은 다른 이야기입니다.

장기 실행 에이전트 구축에 대한 이론

신뢰성부터 시작하겠습니다. 에이전트가 오랜 시간 동안 실행되면서 일관된 대화를 유지하고 실제로 신뢰할 수 있어야 할 때, 복합적인 오류의 가능성을 억제하기 위해 반드시 해야 할 것들이 있습니다. 그렇지 않고 조심하지 않으면, 상황은 빠르게 무너집니다. 신뢰성의 핵심에는 컨텍스트 엔지니어링(Context Engineering)이 있습니다.

컨텍스트 엔지니어링

2025년 현재, 시중의 모델들은 극도로 지능적입니다. 하지만 아무리 똑똑한 사람이라도 자신이 요청받은 일에 대한 컨텍스트 없이는 업무를 효과적으로 수행할 수 없습니다. "프롬프트 엔지니어링"은 LLM 챗봇에 이상적인 형태로 작업을 작성하는 데 필요한 노력을 지칭하는 용어로 만들어졌습니다. "컨텍스트 엔지니어링"은 이보다 한 단계 위입니다. 이는 동적인 시스템에서 이 작업을 자동으로 수행하는 것에 관한 것입니다. 이것은 더 많은 미묘함을 요구하며, 사실상 AI 에이전트를 구축하는 엔지니어의 가장 중요한 직무입니다.

흔한 유형의 에이전트를 예로 들어보겠습니다. 이 에이전트는

1. 작업을 여러 부분으로 나눕니다.

2. 그 부분들을 처리할 하위 에이전트들을 시작합니다.

3. 마지막에 그 결과들을 조합합니다.

이것은 특히 여러 병렬 구성 요소를 가진 작업 영역에서 일하는 경우 솔깃한 아키텍처입니다. 하지만 이것은 매우 취약합니다. 핵심적인 실패 지점은 다음과 같습니다:

당신의 작업이 "플래피 버드(Flappy Bird) 클론 게임 만들기"라고 가정해 봅시다. 이것은 하위 작업 1 "녹색 파이프와 히트 박스가 있는 움직이는 게임 배경 만들기"와 하위 작업 2 "위아래로 움직일 수 있는 새 만들기"로 나뉩니다.

결과적으로 하위 에이전트 1은 당신의 하위 작업을 잘못 이해하고 슈퍼 마리오 브라더스처럼 보이는 배경을 만들기 시작했습니다. 하위 에이전트 2는 새를 만들었지만, 게임 애셋처럼 보이지도 않고 플래피 버드의 새처럼 움직이지도 않습니다. 이제 최종 에이전트에게는 이 두 가지 잘못된 소통의 결과물을 합쳐야 하는 바람직하지 않은 임무만 남게 됩니다.

이 예시가 작위적으로 보일 수 있지만, 대부분의 실제 작업에는 잘못 전달될 가능성이 있는 여러 겹의 미묘한 뉘앙스가 있습니다. 간단한 해결책으로 원래 작업을 하위 에이전트들에게도 컨텍스트로 복사해주면 된다고 생각할 수도 있습니다. 그렇게 하면 그들이 하위 작업을 오해하지 않을 것입니다. 하지만 실제 상용 시스템에서는 대화가 여러 차례 오가고, 에이전트는 작업을 나누는 방법을 결정하기 위해 도구 호출(tool calls)을 해야 했을 것이며, 어떤 사소한 세부사항이라도 작업의 해석에 영향을 미칠 수 있다는 점을 기억해야 합니다.

원칙 1

컨텍스트를 공유하고, 개별 메시지가 아닌 전체 에이전트 추적 기록을 공유하라

우리 에이전트를 다시 한번 수정해 봅시다. 이번에는 각 에이전트가 이전 에이전트들의 컨텍스트를 갖도록 확실히 합니다.

불행히도, 아직 문제가 완전히 해결된 것은 아닙니다. 에이전트에게 똑같은 플래피 버드 클론 제작 작업을 주었을 때, 이번에는 완전히 다른 시각적 스타일의 새와 배경을 얻게 될 수 있습니다. 하위 에이전트 1과 하위 에이전트 2는 서로가 무엇을 하고 있는지 볼 수 없었기 때문에, 그들의 작업물은 서로 일관성이 없게 됩니다.

하위 에이전트 1이 취한 행동과 하위 에이전트 2가 취한 행동은 사전에 명시되지 않은 상충하는 가정에 기반을 두고 있었습니다.

원칙 2

행동은 암묵적인 결정을 내포하며, 상충하는 결정은 나쁜 결과를 초래한다

저는 원칙 1과 2가 너무나 중요하고 위반할 가치가 거의 없기 때문에, 기본적으로 이 원칙들을 따르지 않는 모든 에이전트 아키텍처를 배제해야 한다고 주장합니다. 이것이 제약적이라고 생각할 수도 있지만, 실제로는 여전히 탐색할 수 있는 다양한 아키텍처의 넓은 공간이 있습니다.

원칙을 따르는 가장 간단한 방법은 단일 스레드 선형 에이전트를 사용하는 것입니다:

여기서는 컨텍스트가 연속적입니다. 하지만 매우 큰 작업에서 하위 부분이 너무 많아 컨텍스트 창이 넘치기 시작하는 문제에 부딪힐 수 있습니다.

솔직히, 이 간단한 아키텍처만으로도 아주 많은 것을 해낼 수 있습니다. 하지만 정말로 장시간 지속되는 작업을 다루고, 그 노력을 기꺼이 감수할 의향이 있는 분들을 위해, 더 나은 방법도 있습니다. 이를 해결할 여러 방법이 있겠지만, 오늘 저는 단 하나만 제시하겠습니다:

이 세계에서는, 행동과 대화의 기록을 핵심 세부사항, 이벤트, 결정으로 압축하는 것을 주요 목적으로 하는 새로운 LLM 모델을 도입합니다. 이것은 제대로 구현하기 어렵습니다. 무엇이 핵심 정보가 되는지 파악하고 이를 잘 수행하는 시스템을 만드는 데 투자가 필요합니다. 도메인에 따라서는 더 작은 모델을 파인튜닝하는 것을 고려할 수도 있습니다 (이것은 실제로 저희 Cognition에서 했던 일입니다).

이를 통해 얻는 이점은 더 긴 컨텍스트에서 효과적인 에이전트입니다. 하지만 결국에는 한계에 부딪히게 될 것입니다. 열정적인 독자라면, 임의로 긴 컨텍스트를 관리할 더 나은 방법을 생각해보시길 권합니다. 파고들수록 상당히 깊어지는 주제가 될 것입니다!

원칙의 적용

만약 당신이 에이전트 빌더라면, 당신의 에이전트가 취하는 모든 행동이 시스템의 다른 부분에서 내려진 모든 관련 결정의 컨텍스트에 기반하여 정보를 받도록 보장해야 합니다. 이상적으로는 모든 행동이 다른 모든 것을 볼 수 있어야 합니다. 불행히도, 제한된 컨텍스트 창과 현실적인 트레이드오프로 인해 이것이 항상 가능한 것은 아니며, 목표로 하는 신뢰성 수준에 맞춰 어느 정도의 복잡성을 감수할지 결정해야 할 수도 있습니다.

상충하는 의사 결정을 피하기 위해 에이전트를 설계할 때, 다음과 같은 실제 사례들을 숙고해 보십시오:

Claude Code 하위 에이전트

2025년 6월 현재, Claude Code는 하위 작업을 생성하는 에이전트의 한 예입니다. 하지만, 이 에이전트는 하위 작업 에이전트와 병렬로 작업을 수행하지 않으며, 하위 작업 에이전트는 보통 코드를 작성하는 것이 아니라 질문에 답하는 임무만 받습니다. 왜일까요? 하위 작업 에이전트는 잘 정의된 질문에 답하는 것 이상의 일을 하는 데 필요한 메인 에이전트의 컨텍스트가 부족하기 때문입니다. 그리고 만약 여러 병렬 하위 에이전트를 실행한다면, 그들은 상충하는 응답을 내놓을 수 있으며, 이는 우리가 앞서 본 에이전트 예시들에서 겪었던 신뢰성 문제로 이어질 것입니다. 이 경우 하위 에이전트를 두는 것의 이점은, 하위 에이전트의 모든 조사 작업이 메인 에이전트의 기록에 남을 필요가 없어져, 컨텍스트가 소진되기 전까지 더 긴 추적을 가능하게 한다는 것입니다. Claude Code의 설계자들은 의도적으로 단순한 접근 방식을 취했습니다.

편집-적용 모델 (Edit Apply Models)

2024년에는 많은 모델들이 코드 편집에 정말 서툴렀습니다. 코딩 에이전트, IDE, 앱 빌더 등(Devin 포함)에서 흔한 관행은 "편집-적용 모델"을 사용하는 것이었습니다. 핵심 아이디어는 큰 모델에게 올바른 형식의 diff를 출력하게 하는 것보다, 원하는 변경 사항에 대한 마크다운 설명을 기반으로 작은 모델에게 전체 파일을 다시 작성하게 하는 것이 실제로 더 신뢰할 수 있다는 것이었습니다. 그래서 빌더들은 큰 모델이 코드 편집에 대한 마크다운 설명을 출력하게 하고, 이 설명을 작은 모델에게 입력하여 실제로 파일을 다시 작성하게 했습니다. 하지만 이 시스템들은 여전히 결함이 많았습니다. 예를 들어, 지시문의 아주 작은 모호함 때문에 작은 모델이 큰 모델의 지시를 잘못 해석하여 부정확한 편집을 하는 경우가 많았습니다. 오늘날에는 편집 결정과 적용이 하나의 모델에 의해 단일 행동으로 이루어지는 경우가 더 많습니다.

멀티 에이전트

만약 우리가 정말로 시스템에서 병렬성을 얻고 싶다면, 의사 결정자들이 서로 "대화"하며 문제를 해결하게 하는 방법을 생각할 수 있습니다.

이것은 우리 인간이 의견이 다를 때 (이상적인 세상에서) 하는 방식입니다. 엔지니어 A의 코드가 엔지니어 B의 코드와 병합 충돌을 일으키면, 올바른 절차는 차이점에 대해 대화하고 합의에 이르는 것입니다. 그러나 오늘날의 에이전트들은 단일 에이전트로 얻을 수 있는 것보다 훨씬 더 높은 신뢰성을 가지고 이런 방식의 긴 컨텍스트를 가진 선제적 담화에 참여할 수 없습니다. 인간은 서로에게 가장 중요한 지식을 전달하는 데 매우 효율적이지만, 이 효율성에는 상당한 지능이 필요합니다.

ChatGPT 출시 직후부터 사람들은 목표 달성을 위해 여러 에이전트가 상호 작용하는 아이디어를 탐구해 왔습니다. 저는 에이전트들이 서로 협력하는 것의 장기적인 가능성에 대해 낙관적이지만, 2025년 현재 여러 에이전트를 협력하여 실행하는 것은 취약한 시스템을 낳을 뿐이라는 것이 분명합니다. 의사 결정이 너무 분산되고 컨텍스트가 에이전트들 간에 충분히 철저하게 공유될 수 없습니다. 현재로서는 이 어려운 교차-에이전트 컨텍스트 전달 문제를 해결하기 위해 헌신적인 노력을 기울이는 사람은 보이지 않습니다. 저는 개인적으로 우리가 단일 스레드 에이전트를 인간과 더 잘 소통하도록 만들면서 이 문제가 저절로 해결될 것이라고 생각합니다. 그날이 오면, 훨씬 더 큰 규모의 병렬성과 효율성이 열릴 것입니다.

더 일반적인 이론을 향하여

컨텍스트 엔지니어링에 대한 이러한 원칙들은 언젠가 우리가 에이전트 구축의 표준 원칙으로 여기게 될 것의 시작에 불과합니다. 그리고 여기에서 논의되지 않은 더 많은 도전과 기술들이 있습니다. Cognition에서 에이전트 구축은 우리가 고민하는 핵심 개척 분야입니다. 우리는 이러한 아이디어를 강제하는 방법으로, 우리가 반복해서 다시 배우게 되는 이 원칙들을 중심으로 내부 도구와 프레임워크를 구축합니다. 하지만 우리의 이론은 완벽하지 않을 수 있으며, 분야가 발전함에 따라 상황이 변할 것으로 예상하므로, 어느 정도의 유연성과 겸손함도 필요합니다.

app.devin.ai에서 저희의 작업을 시도해 보시기를 환영합니다. 그리고 만약 저희와 함께 이러한 에이전트 구축 원칙들을 발견하는 것을 즐기신다면, walden@cognition.ai로 연락 주십시오.

주석 (번역 과정 설명)

• 번역 접근법: 원문은 기술 블로그 형식이지만, 저자의 철학과 주장이 강하게 담겨 있어 독자의 이해와 공감을 돕기 위해 의역(semantic translation)의 비중을 70%로 설정했습니다. 딱딱한 직역보다 자연스러운 한국어 표현으로 저자의 의도를 전달하는 데 중점을 두었습니다.

• 전문성 및 용어: 대상 독자는 AI 및 소프트웨어 개발자이므로, 전문가 수준의 어휘를 사용했습니다. "Context Engineering", "Multi-Agents", "LLM", "React"와 같은 핵심 용어는 한국 IT 업계에서 통용되는 방식에 따라 영문 음차 표기 후 괄호 안에 원어를 병기하거나, 원어 그대로 사용하여 명확성을 높였습니다. "scaffold"는 '비계'로, "rabbit hole"은 '파고들수록 깊어지는 주제'로, "out of the woods"는 '문제가 완전히 해결된 것은 아니다'와 같이 문맥에 맞는 의역을 채택했습니다.

• 문체 및 어조: 저자의 설득력 있고 자신감 있는 어조를 살리기 위해, "~해야 한다", "~입니다", "~것입니다" 등 명확하고 단정적인 어미를 사용했습니다. 또한, "왜일까요?", "예를 들어보겠습니다"와 같은 표현을 추가하여 블로그 글의 자연스러운 흐름을 재현했습니다.

• 구조 및 최종 검토: 원문의 구조(제목, 소제목, 원칙 제시, 예시, 결론)를 그대로 따르면서 한국어 독자가 읽기 편하도록 문장 구조를 다듬었습니다. 최종적으로 소리 내어 읽어보며 어색한 부분을 수정하고, 원작의 논리와 감성이 잘 전달되는지 확인했습니다.