**
AI 커뮤니티에서 널리 회자되는 아키텍처 아이디어가 많은 팀을 잘못된 길로 이끌고 있습니다.
결론부터 말하자면
여러 AI Agent에 "프로덕트 매니저", "아키텍트", "테스트 엔지니어"라는 이름을 붙이고, 회사 부서처럼 문서를 주고받으며 협업하게 하는 방식을 고려 중이라면 — 지금 당장 멈추세요.
이 모델은 직관적이고 논리적으로 보이지만, 엔지니어링 관점에서 근본적인 결함이 있습니다. 더 중요한 것은, Anthropic, OpenAI, Google 이 세 주요 제공업체 중 어느 곳도 자체 Agent 시스템을 구축할 때 이 모델을 사용하지 않는다는 점입니다.
이는 우연이 아닙니다.
"3부 6처" 아키텍처란 무엇인가?
이 비유는 커뮤니티에서 널리 유행하는 일종의 멀티 에이전트 설계 아이디어를 가리키며, 다양한 프레임워크와 글에서 역할 기반 에이전트, 가상 팀, CrewAI 스타일의 분업, 또는 MetaGPT 스타일의 조직 등으로 불립니다. 이 글에서는 이를 통틀어 "부서화(Departmentalized)" 모델이라고 부릅니다.
핵심 패턴은 다음과 같습니다: 복잡한 작업을 여러 기능으로 분해하고, 각 Agent가 역할을 수행합니다 — PM은 요구사항, Tech Lead는 아키텍처, Dev는 구현, QA는 테스트를 담당합니다. 작업은 컨베이어 벨트처럼 Agent 간에 흐릅니다.
이 모델은 다이어그램상으로는 훌륭해 보입니다. "분업"에 대한 인간의 직관을 만족시키고, "AI 팀"이라는 개념을 구체적이고 설명 가능하게 만듭니다. CrewAI와 같은 프레임워크가 이 때문에 많은 사용자를 확보했습니다.
문제는, 이것이 인간의 병목을 해결할 뿐, AI의 병목을 해결하지 못한다는 점입니다.
이 비유가 근본적으로 잘못된 이유
인간에게 분업이 필요한 이유는 다음과 같습니다:
- 한 사람의 주의력은 제한적이어서 모든 정보를 동시에 처리할 수 없습니다.
- 인간에게는 전문 분야의 장벽과 높은 학습/전환 비용이 있습니다.
- 인간은 서로 조율하기 위한 인터페이스가 필요합니다.
하지만 LLM의 특성은 완전히 다릅니다:
- 동일한 모델이 PRD와 코드를 모두 작성할 수 있으며, "전문 분야의 경계"가 없습니다.
- 모델의 병목은 주의력이 아니라 추론 깊이와 정보의 완전성입니다.
- 모델은 정보 손실을 보완할 "문화"와 "암묵적 이해"가 부족합니다.
Agent에 "프로덕트 매니저"라는 라벨을 붙인다고 해서 더 전문적으로 변하는 것이 아니라, 경계를 넘지 못하게 만듭니다. "테스트 엔지니어" 역할에 갇힌 Agent는 "제 범위가 아닙니다"라는 이유로 아키텍처 문제를 건너뛸 수 있습니다. 가장 가치 있는 추론은 종종 경계에서 발생하는데, 부서화 모델은 시스템 수준에서 이러한 가능성을 차단합니다.
역할 연기는 가짜 경계를 만듭니다. 이것이 첫 번째 문제입니다.
두 번째 문제: 정보가 전달 과정에서 죽는다
부서화 모델에서 Agent A는 문서를 생성하여 Agent B에게 전달합니다.
이 과정은 결론만 전달할 뿐, 추론 과정은 전달되지 않습니다.
B는 문서를 받아 다시 이해하고 컨텍스트를 재구축합니다. 원래 의도는 변질되고, 숨겨진 가정은 사라지며, 모든 핸드오프에서 오류가 누적됩니다. 워크플로우가 길어질수록 최종 출력은 "국지적으로는 올바르지만 전체적으로는 표류하는" 상태가 됩니다 — 각 노드는 합리적으로 보이지만, 전체는 원래 목표에서 벗어나 있습니다.
인간 조직은 회의, 문화, 비공식적 커뮤니케이션을 통해 이러한 정보 손실을 보완합니다. Agent에게는 이러한 메커니즘이 없습니다.
일반적인 반론이 있습니다: 세 주요 제공업체의 솔루션(progress.txt, spec 파일, runbook)도 "파일 전달"을 포함하지 않습니까? 차이점은 무엇입니까?
차이점은 누가 작성하고, 누구를 위한 것이며, 어떻게 업데이트되는지에 있습니다.
부서화된 정보 흐름은 역할 간 단방향 핸드오프입니다: A가 완료하면 B에게 전달하고, B는 되돌아보지 않으며, A는 B가 문서를 어떻게 사용했는지 알지 못합니다. 정보는 결론으로 압축되고, 추론 과정은 손실되며, 핸드오프는 중단점입니다.
외부 상태 파일은 동일한 작업의 증분 로그입니다: 실행 주체가 각 체크포인트에서 동일한 레코드에 추가하고, 다음 세션은 이전 "동료"의 출력 결론이 아닌 작업의 전체 이력을 읽습니다. 상태를 쓰는 사람과 상태를 읽는 사람은 동일한 역할이며, 단지 시간이 다를 뿐입니다. 정보는 "압축되어 전달"되는 것이 아니라 "지속적으로 축적"됩니다.
이 차이는 추론 체인이 세션 간에 연속성을 유지할 수 있는지 여부를 결정합니다.
엄청난 양의 토큰이 실제 추론이 아닌 Agent 간 "핸드오프 파일"에 낭비됩니다. 그 결과 회사 행동을 시뮬레이션하는 시스템이 탄생할 뿐, 문제를 해결하는 시스템은 아닙니다.
세 주요 제공업체가 실제로 하는 방식
주목할 점은, Anthropic, OpenAI, Google이 프로덕션 등급의 Agent 시스템을 구축할 때, 그들의 엔지니어링 문서에는 "역할 연기"나 "부서 분할"에 대한 언급이 거의 없다는 것입니다.
Anthropic: 컨텍스트 엔지니어링 + 명시적 상태 파일
Anthropic은 "프롬프트 엔지니어링"을 "컨텍스트 엔지니어링"으로 업그레이드했습니다: 문제는 좋은 프롬프트를 작성하는 방법이 아니라, 어떤 토큰 구성이 원하는 동작을 가장 잘 생성하는지입니다.
Claude Code 및 Research 시스템을 구축할 때, 핵심 과제는 다음과 같았습니다: Agent는 개별 세션에서 작업해야 하며, 각 새 세션은 이전에 발생한 일에 대한 메모리가 없습니다. 그들의 비유는 "교대 엔지니어"입니다 — 각 새로운 교대 엔지니어는 이전 교대 작업에 대해 아무것도 모릅니다.
해결책은 Agent가 다른 역할을 수행하게 하는 것이 아니라 다음과 같습니다:
- claude-progress.txt: 세션 간 작업 로그로, Agent가 각 세션 종료 시 업데이트하고 다음 세션 시작 시 읽습니다.
- Git 히스토리: 상태 앵커 역할을 하며, 모든 증분 변경 사항을 기록합니다.
- Initializer Agent: 첫 번째 세션에서만 실행되어 환경을 설정하고, 기능 목록을 확장하며, 모든 후속 세션을 위한 runbook을 작성합니다.
핵심 통찰: 추론 체인의 연속성은 모델이 "기억"하는 것에 의존하지 않으며, 명시적 외부 상태에 의존하여 고정됩니다.
또한 그들은 하네스에 "모델 기능 가정"을 하드코딩하는 것이 위험하다는 것을 발견했습니다. Sonnet 4.5는 "컨텍스트 불안"이 있었습니다 — 컨텍스트 한도에 가까워지면 일찍 마무리하려는 경향이 있어, 하네스에 컨텍스트 리셋을 추가했습니다. 그러나 Opus 4.5에서는 이 동작이 사라졌고, 리셋은 불필요한 부담이 되었습니다. 이는 하네스가 모델과 함께 진화해야 함을 보여줍니다. 어떤 "영구적인 해결책"도 현재 단계에 대한 엔지니어링 타협일 뿐입니다.
멀티 에이전트 Research 시스템에서 Anthropic의 아키텍처는 오케스트레이터-워커(orchestrator-worker) 입니다: 리드 에이전트가 작업을 분해하고 서브 에이전트를 조정하며, 서브 에이전트는 병렬로 다른 방향을 탐색하고, 결과는 리드 에이전트로 다시 흘러가 종합됩니다. 그들은 토큰 소비만으로 성능 차이의 80%를 설명할 수 있다는 것을 발견했습니다 — 멀티 에이전트의 가치는 "분업"이 아니라 더 많은 토큰을 사용하여 더 넓은 검색 공간을 커버하는 것입니다.
여기서 혼란스러운 점이 있습니다: Anthropic의 서브 에이전트가 "분업"처럼 보일 수 있지만, 본질은 다릅니다. 부서화는 기능적 분할입니다 — 다른 역할이 다른 유형의 작업을 처리합니다(PM에서 Dev로, QA로). Anthropic의 서브 에이전트는 기능적 병렬성입니다 — 여러 동일한 에이전트가 동시에 다른 방향을 검색하며, "다음 핸드오프"가 없고, 모든 결과는 동일한 오케스트레이터로 다시 수렴됩니다. 전자는 계주 경주이고, 후자는 광범위한 그물을 던지는 것입니다.
OpenAI: 압축 + 스킬 + 구조화된 Spec 파일
장기 작업에 대한 OpenAI의 원칙은 더욱 직접적입니다: 작업 시작 시 연속성을 계획하세요.
Codex 실험에서 엔지니어는 에이전트에게 spec 파일을 제공하고(목표를 고정하여 에이전트가 "인상적이지만 잘못된 방향"으로 무언가를 만드는 것을 방지), 마일스톤 기반 계획을 생성하게 한 다음, runbook 파일을 사용하여 에이전트에게 작동 방법을 알려주었습니다. 이 runbook은 또한 공유 메모리 및 감사 로그 역할을 합니다.
결과: GPT-5.3-Codex는 약 25시간 동안 연속 실행되어 전체 설계 도구를 완성했으며, 전체 과정에서 일관성을 유지했습니다.
서버 측 압축은 비상 대비책이 아닌 기본 프리미티브 역할을 합니다. 다단계 작업에서 previous_response_id를 사용하면 모델이 매번 컨텍스트를 재구축하는 대신 동일한 스레드에서 계속 작업할 수 있습니다.
또한 그들은 Skills 개념을 도입했습니다 — 컨테이너에 마운트된 재사용 가능한 버전 관리 명령어 세트로, 특정 작업에 대한 안정적인 운영 표준을 에이전트에 제공합니다. 이는 "역할"이 아니라 도구와 운영 절차이며, 근본적으로 다릅니다.
Google: 1M 컨텍스트 + 컨텍스트 기반 개발
Google의 방향은 윈도우를 무력화하는 것입니다: Gemini의 1M 토큰 컨텍스트는 명확한 차별화 전략입니다. 그들의 논리는 이전에 강제되었던 RAG 슬라이싱 및 오래된 메시지 폐기와 같은 기술이 충분히 큰 윈도우가 주어지면 "그냥 모두 넣는 것"으로 대체될 수 있다는 것입니다.
하지만 그들은 이것만으로는 충분하지 않다고 인정합니다. Google은 Gemini CLI용 Conductor 확장을 출시했으며, 핵심 아이디어는 Anthropic과 동일합니다: 프로젝트 의도를 채팅 창 밖으로 옮겨 코드베이스의 영구 Markdown 파일에 저장하는 것입니다. 철학: "불안정한 채팅 기록에 의존하지 말고, 공식 spec 및 계획 파일에 의존하세요."
Gemini 3는 또한 Thought Signatures를 도입했습니다: 긴 세션에서 추론 체인의 핵심 노드를 저장하여 "추론 드리프트" — 긴 컨텍스트에서 논리적 불일치 문제를 방지합니다.
실제 아키텍처 원칙은 무엇인가?
이 세 회사의 엔지니어링 관행에서 몇 가지 공통 원칙을 추출할 수 있습니다:
추론 체인은 끊어질 수 없으며, 분기되고 병합될 수만 있습니다. 멀티 에이전트의 올바른 사용은 컨베이어 벨트가 아니라, 전체 의도를 보유한 메인 에이전트가 하위 문제를 깊이 파고들기 위해 서브 호출을 사용하고, 결과가 다음 에이전트로 전달되지 않고 메인 에이전트로 다시 흘러가는 것입니다.
명시적 외부 상태, 모델 메모리에 의존하지 마세요. progress.txt, git 히스토리, spec 파일, 데이터베이스 등 형식은 중요하지 않습니다. 원칙은: 추론 체인의 핵심 노드는 영구 저장소로 외부화되어야 합니다.
멀티 에이전트의 가치는 병렬 커버리지이지, 분업이 아닙니다. Anthropic의 Research 시스템 결론은 명확합니다: 성능 향상은 "더 많은 토큰을 사용"하는 데서 오지, "더 나은 분업"에서 오지 않습니다. 멀티 에이전트는 너비 우선 작업 — 독립적인 방향을 동시에 탐색해야 하는 시나리오에 적합합니다. 지속적인 추론과 깊은 컨텍스트 의존성이 필요한 시나리오에는 적합하지 않습니다.
검증 Agent는 부정자(denier)이지, 계주가 아닙니다. 품질 관리를 위해 멀티 에이전트를 사용하는 경우, 올바른 설계는 한 Agent가 다른 Agent의 작업에서 문제를 찾는 데 전념하도록 하는 것이지, "작업 결과를 전달"하는 것이 아닙니다. 컨베이어 벨트 전송이 아닌 적대적 테스트입니다.
도구는 도구일 뿐, 역할이 아닙니다. Agent에 어떤 도구를 장착하는지(bash, 파일 I/O, 검색, 코드 실행)는 어떤 라벨을 붙이는지보다 훨씬 중요합니다. 도구는 Agent가 할 수 있는 것을 결정하고, 역할 라벨은 단지 할 의향이 있는 것을 제한할 뿐입니다.
"부서화" 모델이 인기 있는 이유는?
설명하기 쉽기 때문입니다.
"이 Agent는 PM이고, 저 Agent는 QA입니다" — 누구나 이해할 수 있습니다. 이는 AI 시스템 설명 가능성에 대한 인간의 욕구와 "AI가 팀처럼 일하는" 것에 대한 경영진의 상상을 만족시킵니다.
또한 시연하기 쉽습니다. 부서, 화살표, 핸드오프가 있는 플로우차트로 그리면 매우 직관적입니다.
하지만 설명하고 시연하기 쉬운 것과 엔지니어링적으로 건전한 것은 다릅니다.
더 깊은 이유는 이 모델을 채택하는 대부분의 팀이 "멀티 에이전트 전송 중 컨텍스트 손실" 문제를 실제로 직면하지 않았기 때문입니다. 그들의 작업이 충분히 복잡하지 않거나, 문제가 다른 요인에 의해 가려져 있을 수 있습니다. 작업 복잡성이 증가하고 시스템이 "국지적으로는 올바르지만 전체적으로는 잘못된" 오류를 보이기 시작하면 문제가 드러납니다.
실용적인 조언
최고의 멀티 에이전트 시스템은 회사처럼 보이지 않습니다. 오히려 사상가의 여러 초안처럼 보입니다 — 동일한 두뇌가 다른 차원에서 추론을 확장하고 마지막에 일관된 결론으로 병합하는 것입니다.
이 원칙에 기반하여:
"몇 개의 Agent가 필요합니까?"라고 묻지 말고, "이 작업의 정보 의존성 구조는 무엇입니까?"라고 물으세요.
작업이 지속적인 추론과 높은 컨텍스트 의존성을 요구하는 경우(예: 복잡한 기능에 대한 설계 문서 작성), 단일 Agent + 좋은 컨텍스트 엔지니어링이 일반적으로 멀티 에이전트보다 우수합니다.
작업이 독립적인 방향의 동시 탐색을 요구하는 경우(예: 10개 경쟁사 동시 조사), 멀티 에이전트 병렬 처리는 합리적입니다 — 각 서브 에이전트의 작업은 독립적이며, 정보 손실 비용이 최소화됩니다.
작업이 여러 세션에 걸쳐 있는 경우, 외부 상태 파일은 필수입니다. 효과적인 상태 파일에는 네 가지 유형의 정보가 포함되어야 합니다:
- 작업 목표 (불변, 세션 시작 시 읽어 드리프트 방지)
- 완료된 단계 (추가, 덮어쓰지 않음, 전체 이력 유지)
- 현재 상태 (덮어쓰기, 최신 진행 상황 반영)
- 알려진 함정 (추가, 다음 세션에서 실수 반복 방지)
이 네 가지 유형의 정보는 별도로 유지 관리되고 결합되어 "다음 자아"에게 필요한 전체 컨텍스트를 제공합니다.
검증 단계를 추가하는 경우, 검증 Agent의 유일한 작업은 문제를 찾는 것이어야 하며, "바통을 이어받아 계속"하는 것이 아닙니다. 컨베이어 벨트 전송이 아닌 적대적 테스트입니다.
마지막으로: 모델 기능은 빠르게 향상되고 있습니다. 오늘날 하네스에서 필요한 해결 방법은 6개월 후에는 불필요한 부담이 될 수 있습니다. Anthropic은 이미 이를 입증했습니다 — Sonnet 4.5의 컨텍스트 불안은 Opus 4.5에서 사라졌습니다. 아키텍처 진화 가능성을 유지하는 것이 "완벽한 아키텍처"를 선택하는 것보다 더 중요합니다.
부서화는 기분은 좋지만 엔지니어링 비용이 많이 드는 환상입니다. 그 진정한 비용은 직접적인 실패가 아니라, 복잡성이 증가함에 따라 시스템이 진단하기 어려운 방식으로 저하되게 만드는 것입니다 — 모든 노드가 "작동하는 것처럼 보이지만" 전체는 표류하고 있습니다.
문제를 발견할 때쯤이면, 컨베이어 벨트는 이미 매우 길어져 있습니다.
참고 자료: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
