멀티 에이전트는 거의 항상 틀린 답이다 — 단일 에이전트+컨텍스트 엔지니어링 반론
'전문 에이전트를 여러 개 두고 매니저가 위임한다'는 멀티 에이전트 환상에 대한 강한 반론이 업계 엔지니어링 블로그를 중심으로 굳어졌다. 핵심 비판은 두 가지다. 첫째, 서브에이전트끼리 컨텍스트를 공유하지 못하면 같은 사실을 서로 다르게 가정해 결과가 충돌하고(컨텍스트 단절), 둘째 한 에이전트의 출력을 다른 에이전트의 입력으로 넘기는 핸드오프 지점마다 정보가 압축·소실되어 오류가 누적된다. 결정은 분산되는데 결정에 필요한 맥락은 분산되지 않으므로, 병렬 작성자(writer) 여러 명이 서로 모순되는 보고서를 만드는 전형적 실패가 나온다. 대안으로 제시되는 건 '단일 스레드 에이전트 + 컨텍스트 엔지니어링'이다. 작업을 쪼개되 결정권은 한 곳에 모으고, 긴 컨텍스트를 압축·요약해 단일 에이전트가 전체 맥락을 유지하게 한다. 멀티 에이전트가 정당화되는 경우는 읽기 전용 병렬 조사처럼 결과를 합치기만 하면 되는, 쓰기 충돌이 없는 작업으로 좁혀진다.
한국 스타트업이 '에이전트 오케스트라'를 마케팅 문구로 앞세우지만, 실제로는 토큰 비용 N배에 디버깅 불가능한 분산 실패만 떠안는 경우가 많다. 이 반론의 실무 지침은 명확하다. 멀티 에이전트로 가기 전에 '이 작업에 진짜 쓰기 충돌이 없는 병렬성이 있는가'를 먼저 물어라. 대부분의 비즈니스 워크플로(고객 응대, 문서 생성, 코드 수정)는 결정이 한 곳에 모여야 일관성이 유지되며, 멀티 에이전트는 비용·지연·복잡도만 늘린다. 오케스트레이션 설계의 기본값은 단일 에이전트로 두고, 병렬화는 예외로 정당화하는 편이 안전하다.