컨텍스트 엔지니어링 실패모드 위키

멀티에이전트 반대 — Cognition 'Don't Build Multi-Agents' (Walden Yan, 2025)

10 min read

상위: 06_00_MOC

멀티에이전트 반대 — Cognition “Don’t Build Multi-Agents” (Walden Yan, 2025)

한 줄 요약

Devin을 만든 Cognition의 Walden Yan은 OpenAI Swarm, Microsoft AutoGen 같은 멀티에이전트 프레임워크가 “잘못된 방향”이라고 직격한다. 그가 지목하는 핵심 문제는 컨텍스트 단절(Context Fragmentation)이다. 서브에이전트는 메인 에이전트의 암묵적 결정을 보지 못하고, 그래서 결과가 서로 충돌한다.

“Actions carry implicit decisions, and conflicting decisions carry bad results.” — Walden Yan, Cognition, 2025

두 가지 핵심 원칙

Yan이 제시하는 신뢰할 수 있는 에이전트 설계의 두 원칙:

  1. “Share context, and share full agent traces, not just individual messages.”
  2. “Actions carry implicit decisions, and conflicting decisions carry bad results.” — Walden Yan, 2025

원칙 1 — 전체 트레이스 공유: 개별 메시지만 주고받지 말고 에이전트의 궤적 전체(multiturn conversations, tool call history)를 공유해야 한다.

원칙 2 — 암묵적 결정 충돌 방지: 모든 액션에는 겉으로 드러나지 않은 결정이 깔려 있다. 병렬 서브에이전트가 저마다 그런 결정을 내리고 나면, 결과를 합칠 때 충돌이 터진다.

Flappy Bird 예시 — 컨텍스트 단절의 구체적 실패

flowchart TD
    ORCH["오케스트레이터<br/>'Flappy Bird 게임 만들기'"]

    S1["서브에이전트 A<br/>'배경 만들기' 지시<br/>→ Super Mario 스타일 배경 생성<br/>(암묵적 결정: 마리오 아트 스타일)"]

    S2["서브에이전트 B<br/>'새 만들기' 지시<br/>→ 마리오 스타일과 맞지 않는 새 생성<br/>(서브에이전트 A의 결정을 모름)"]

    MERGE["통합 에이전트<br/>두 결과를 합쳐야 함<br/>→ 스타일 충돌 발생<br/>→ 수습 불가능한 불일치"]

    ORCH -->|"병렬"| S1
    ORCH -->|"병렬"| S2
    S1 --> MERGE
    S2 --> MERGE
    MERGE -->|"결과"| FAIL["불일치 에셋<br/>사용자 기대 불충족"]

핵심은 이렇다. 서브에이전트 B는 서브에이전트 A가 마리오 스타일을 골랐다는 사실, 곧 그 암묵적 결정을 알 길이 없었다. 둘 다 각자의 독립된 컨텍스트 안에서는 합리적으로 판단했지만, 막상 결합하면 어긋난다.

이것이 04 충돌가 멀티에이전트 병렬 실행에서 구조적으로 터지는 메커니즘이다.

왜 멀티에이전트가 현재 작동하기 어려운가

Yan이 제시하는 두 가지 근본 원인:

  • 결정 분산(Decision Dispersion): 의사결정이 여러 에이전트로 흩어지면 일관성을 지킬 수 없다.
  • 컨텍스트 공유 한계: “Context cannot be shared thoroughly enough between the agents”. 지금의 LLM은 “long-context proactive discourse”를 요구하는 협업에서 한계를 드러낸다.

Cognition이 권장하는 대안 아키텍처

멀티에이전트 대신 단일 스레드 선형 에이전트에 경계 압축을 더한 구조를 권장한다.

flowchart TD
    subgraph Recommended["Cognition 권장 아키텍처"]
        MAIN["Main Agent<br/>(전체 트레이스 보유)<br/>순차·선형 실행"]

        COMP["Compressor LLM<br/>히스토리 → 핵심 압축<br/>(도메인 파인튜닝 권장)"]

        SUB["Sub-task Agent<br/>질문 응답 전용<br/>비병렬<br/>(조사 결과 = 메인 히스토리 미포함)"]

        MAIN -->|"컨텍스트 초과 시"| COMP
        COMP -->|"핵심 압축 반환"| MAIN
        MAIN -->|"순차·조사 전용"| SUB
        SUB -->|"조사 결과만 반환"| MAIN
    end

핵심 설계 원칙은 다음과 같다.

  • Main Agent는 언제나 전체 트레이스를 들고 있다.
  • 서브에이전트는 병렬로 돌리지 않고 오직 조사(investigation)에만 쓴다.
  • 서브에이전트의 조사 결과는 메인 히스토리에 남기지 않는다. 이로써 Context Quarantine 효과를 얻는다.
  • 컨텍스트가 한계를 넘으면 압축 전용 LLM(필요하면 파인튜닝)으로 히스토리를 압축한다.

압축 전용 LLM — 상세

“We introduce a new LLM model whose key purpose is to compress a history of actions & conversation into key details, events, and decisions. This is hard to get right.” — Walden Yan, 2025

압축에서 가장 어려운 대목은 무엇을 버릴지 정하는 일이다.

접근평가
범용 LLM으로 요약”hard to get right”
도메인 특화 소형 모델 파인튜닝효과적 (Cognition이 실제 수행)

Yan은 이 작업이 무척 까다롭다는 점을 거듭 강조하면서, 그만큼 도메인 파인튜닝의 가치를 인정한다. 06_03-Compress전략-요약-프루닝-KV캐시최적화의 “압축 전용 LLM” 섹션과 연결된다.

Claude Code — 올바른 서브에이전트 패턴의 모범

흥미롭게도 Yan은 Claude Code를 반례가 아니라 모범 사례로 든다.

“Claude Code is an example of an agent that spawns subtasks. However, it never does work in parallel with the subtask agent… The designers of Claude Code took a purposefully simple approach.” — Walden Yan, 2025

Claude Code가 올바른 이유는 세 가지로 정리된다. 서브태스크를 만들되 그것과 병렬로 작업하지 않고 메인 에이전트가 기다린다는 점, 서브에이전트는 조사만 맡고 직접 실행은 하지 않는다는 점, 그 조사 결과가 메인 히스토리에 남지 않아 Context Quarantine 효과를 자동으로 얻는다는 점이다.

이런 Claude Code의 서브에이전트는 Isolate 전략(06_04-Isolate전략-멀티에이전트-서브에이전트-Context격리)을 최소한으로 구현한 형태라 할 수 있다.

Edit-Apply 모델 통합 사례

Yan은 또 다른 성공 사례로 edit-apply 모델 통합을 든다.

  • 이전: 결정 모델(어디를 수정할지)과 실행 모델(실제 수정)을 분리했다.
  • 이후: 단일 모델이 결정과 실행을 함께 처리한다.
  • 결과: 성능이 올라갔다.

분리가 늘 정답은 아니라는 사실을 보여주는 구체적인 역사례다.

Anthropic과의 대비 — 찬반 종합

항목Anthropic (찬성)Cognition (반대)
도메인리서치 (독립·병렬 가능)소프트웨어 엔지니어링 (상호의존)
핵심 가치성능 극대화 (90.2%)신뢰성·일관성 우선
서브에이전트 역할병렬 압축·탐색조사 전용·비병렬
태스크 구조독립적 서브태스크상호의존 결정 연쇄
컨텍스트 공유오케스트레이터가 결과 합성전체 트레이스 항상 공유

두 관점은 서로 모순되는 것이 아니라 도메인에 따라 갈리는 분기다. 갈림을 가르는 핵심 변수는 태스크 상호의존성(task interdependency)이다.

참고문헌

관련 노트

그래프 뷰

백링크