원문 제목: "삼성육부 환상: 왜 '가상 기업' 스타일 다중 Agent 아키텍처는 엔지니어링적으로 성립하지 않는가"

AI 커뮤니티에서 널리 퍼져있는 아키텍처 아이디어로 많은 팀이 잘못된 방향으로 향하고 있습니다.

결론 먼저 이야기하자면

여러분이 여러 AI Agent를 '제품 관리자', '아키텍트', '테스트 엔지니어'로 각각 명명하여 회사 부서처럼 문서를 전달하고 작업을 협업하도록 하는 것을 고려 중이라면, 멈추세요.

이 패턴은 직관적으로 보이고 논리적으로 합리적으로 보일 수 있지만, 엔지니어링적으로 근본적인 결함이 있습니다. 더 중요한 것은, Anthropic, OpenAI, Google 세 회사가 자사의 에이전트 시스템을 구축할 때 이러한 패턴을 사용하지 않았다는 것입니다.

이것이 우연이 아닙니다.

무엇이 "삼성육부" 아이디어인가

이 은유는 다중 Agent 디자인 아이디어를 가리키며, 다른 프레임워크와 논문에서는 role-based agents, virtual team, CrewAI 스타일의 분업, MetaGPT 스타일 조직 등 다양한 이름으로 불리지만, 이 글에서는 "삼성육부"로 통칭합니다.

핵심 패턴은 다음과 같습니다: 복잡한 작업을 여러 기능으로 분해하고, 각 Agent가 한 가지 역할을 수행합니다 - PM은 요구 사항을 담당하고, Tech Lead는 아키텍처를 담당하며, Dev는 구현을 담당하고, QA는 테스트를 담당합니다. 작업은 Agent 간에 흐르며, 마치 조립 라인처럼 동작합니다.

이 패턴은 시각적으로 매우 멋집니다. 인간들의 '분업 협업'에 대한 직관을 충족시키며, 'AI 팀'이라는 개념을 구체적이고 설명 가능하게 만듭니다. CrewAI 같은 프레임워크가 많은 사용자를 확보한 이유입니다.

문제는, 이것이 해결하는 것은 인간의 병목 현상이며, AI의 병목 현상이 아닙니다.

왜 이 비유가 근본적으로 잘못된가

인간들은 분업이 필요한 이유:

· 개인의 주의력은 한정되어 있어 모든 정보를 동시에 처리할 수 없음

· 인간은 전문가가 되기 위한 장벽이 높아 전환 비용이 높음

· 사람과 사람 간에는 조정을 위한 인터페이스가 필요합니다

그러나 LLM의 특성은 완전히 다릅니다:

· 동일한 모델이 PRD를 작성하고 코드를 작성할 수 있으며 "직업적 경계"가 없습니다

· 모델의 병목은 주의 범위가 아니라 추론 깊이와 정보 완전성입니다

· 모델 간에는 정보 손실을 보상하기 위한 "문화"나 "암묵적 이해관계"가 없습니다

에이전트에게 "제품 관리자" 레이블을 붙이면 더 전문적이지는 않지만 경계를 넘어서는 것을 거부합니다. "테스트 엔지니어" 역할에 갇힌 에이전트는 아키텍처 문제를 보고해도 "나의 업무 범위가 아니기 때문에" 직접 건너뜁니다. 가치 있는 추론은 종종 경계에서 발생하며 삼정육부 모델은 시스템 수준에서 이 가능성을 차단합니다.

역할극은 가짜 경계를 만들어냅니다. 이것이 첫 번째 문제입니다.

두 번째 문제: 정보가 전달 중에 손실됨

삼정육부 모델에서 A 에이전트가 문서를 작성하여 B 에이전트에게 전달합니다.

이 프로세스는 결론을 전달하는 것이며 추론 프로세스는 아닙니다.

B는 문서를 받아들이고 다시 이해하며 새로운 맥락을 구축합니다. 초기 의도가 저하되어 내포된 가정이 손실되며 각 전달마다 오차가 누적됩니다. 작업 흐름이 길어질수록 최종 결과물은 "지역적으로는 올바르지만 전체적으로 이탈"되며 각 노드는 합리적으로 보이지만 전체적으로 초기 목표에서 벗어납니다.

인간 조직은이 정보 손실을 보상하기 위해 회의, 문화, 비식식적인 소통을 의존합니다. 에이전트들 사이에는이러한 메커니즘이 없습니다.

여기서 일반적으로 제기되는 반론이 있습니다. 세 회사의 접근 방식 (진척 상황 보고서, 명세서 파일, 운영 가이드)도 "파일 전달"이 아닌가요? 차이점은 무엇입니까?

차이점은 누가 쓰고, 누구에게 쓰고, 어떻게 업데이트하는지에 있습니다.

삼정육부의 정보 전달은 역할 간의 일방적인 교환입니다: A가 완료하면 B에게 전달하고 B는 더 이상 되돌아보지 않으며 A는 B가이 문서를 어떻게 사용하는지 알지 못합니다. 정보는 결론으로 압축되며 추론 프로세스가 손실되며 역할 전달은 끊깁니다.

외부 상태 파일은 동일한 작업에 대한 증분 로그입니다：실행 주체가 각 체크포인트마다 동일한 레코드에 추가하며, 다음 세션에서 읽는 것은 작업의 전체 이력이며, 이전 "동료"의 출력 결론이 아닙니다. 상태를 쓰는 사람과 읽는 사람은 동일한 역할이지만 시간만 다릅니다. 정보는 "압축 전달"되는 것이 아니라 "연속적으로 누적"됩니다.

이 차이로 인해 추론 체인이 세션 간에 연속적으로 유지될 수 있는지가 결정됩니다.

대규모 토큰이 실제 추론에 사용되는 것이 아니라 에이전트 간의 "인수 파일"에 낭비됩니다. 당신이 얻는 것은 기업 행동을 시뮬레이션하는 시스템이며, 문제 해결 시스템이 아닙니다.

세 회사의 실제 구현

주목할 점은 Anthropic, OpenAI, Google이 자체 프로덕션급 에이전트 시스템을 구축할 때, 그들의 엔지니어링 문서에서 "역할 재현" 또는 "부서 역할 분담"이라는 용어를 거의 찾을 수 없다는 것입니다.

Anthropic: 콘텍스트 엔지니어링 + 명시적 상태 파일

Anthropic 내부에서 "프롬프트 엔지니어링"을 "콘텍스트 엔지니어링"으로 업그레이드했습니다: 핵심 문제는 프롬프트를 어떻게 작성하는 것이 아니라, 원하는 동작을 가장 잘 유발할 수 있는 토큰 구성이 무엇인가입니다.

Claude Code와 Research 시스템을 구축하는 동안 직면한 핵심 도전 과제는 다음의 사건을 기억하지 않고 이산적인 세션에서 에이전트가 작동해야 한다는 것입니다. 그들의 비유는 "교대 근무 엔지니어"입니다 — 새로운 교대의 엔지니어는 이전 교대에서의 작업을 모른 채 근무합니다.

해결책은 에이전트가 다른 역할을 하는 것이 아니라:

· claude-progress.txt: 세션이 끝날 때마다 에이전트가 업데이트하고, 다음 세션 시작 시에 읽음

· Git 히스토리: 상태 지점으로서, 각 증분 변경을 기록

· 초기화 에이전트: 첫 번째 세션에서만 실행되며 환경을 설정하고 피처 목록을 전개하고 실행 가이드를 작성하여 후속 모든 세션에서 사용

주요 인사이트: 추론 체인의 연속성은 모델이「기억」하는 것이 아니라 명시적인 외부 상태에 의존함을 나타냅니다.

그들은 또한 「모델 능력 가정」을 harness에 하드 코딩하는 것이 위험하다는 것을 발견했습니다. Sonnet 4.5는 「컨텍스트 불안」을 가지고 있었고——컨텍스트 한계에 다가갈 때 일찍 종료되어 harness에 컨텍스트 리셋이 추가되었습니다.

하지만 Opus 4.5에서 이 동작이 사라지고 reset이 dead weight으로 바뀌었습니다. 이는: harness가 모델의 발전에 따라 진화해야 하며, 어떤 『영구적인 해결책』도 현재 단계의 엔지니어링 타협에 불과하다는 것을 보여줍니다.

다중 에이전트의 연구 시스템에서 Anthropic의 아키텍처는 조정자-작업자입니다: 한 리드 에이전트가 작업을 분해하고 서브 에이전트를 조정하며, 서브 에이전트들은 서로 다른 방향을 병렬로 탐색하고 결과를 리드 에이전트에 종합합니다.

그들은 토큰 소비량 자체가 성능 차이의 80%를 설명한다는 것을 발견했습니다——다중 에이전트의 가치는「업무 분담」이 아니라 더 많은 토큰을 사용하여 더 넓은 탐색 공간을 커버하는 것입니다.

여기 혼란스러운 부분이 있습니다: Anthropic의 서브 에이전트는「업무 분담」처럼 보일 수 있지만, 본질적으로 완전히 다릅니다. 삼각형의 각 부분은 기능에 따른 분업입니다——다른 역할이 사용하는 다른 조각, PM이 작성하고 Dev에게 전달하고 Dev가 작업을 완료하여 QA에게 전달하는 구조로, 각 역할은 파이프라인의 한 부분만 처리합니다.

Anthropic의 서브 에이전트는 기능적으로 병렬로 실행됩니다——여러 개의 동일한 성질 에이전트가 동시에 서로 다른 방향으로 탐색하며, 「다음 전달자」가 없으며 결과가 모두 동일한 조정자에게 통합됩니다. 전자는 계주 경주이고, 후자는 동시에 그물을 뿌리는 낚시입니다.

OpenAI: Compaction + Skills + 구조화된 Spec 파일

OpenAI가 제시한 장기 작업 원칙은 더 직접적입니다: 작업을 시작할 때 continuity를 위한 계획을 세웁니다.

그들의 Codex 실험에서, 엔지니어는 에이전트에게 목표를 동결한 spec 파일을 주었고(agent가 "인상적이지만 잘못된 방향으로 행동하지 않도록 한 것"), 거기에 기반한 성취 기반 계획을 생성하도록 했으며, 그런 다음 에이전트에게 작동 방법을 알려주는 runbook 파일을 사용했습니다. 이 runbook은 동시에 공유 메모리 및 감사 로그도 됩니다.

결과: GPT-5.3-Codex는 연속 25시간을 달리며, 완전한 설계 도구를 완성하고 전체적인 일관성을 유지했습니다.

기본 원시인 서버 측 압축은 긴급한 대체 수단이 아니라 기본적인 원시입니다. 다단계 작업에서 previous_response_id는 모델이 매번 컨텍스트를 재구축하는 대신 동일한 스레드에서 작업을 계속할 수 있도록 합니다.

그들은 또한 Skills 개념을 소개했습니다 - 재사용 가능하고 버전 관리가 되는 명령어 세트를 컨테이너에 탑재하여, 특정 작업을 수행할 때 에이전트가 안정적인 작업 지침을 가지게 했습니다. 이것은 "역할"이 아니라 도구 및 작업 지침입니다. 본질적으로 다른 것입니다.

Google: 1M 콘텍스트 + 콘텍스트 주도 개발

Google의 방향은 확장된 창: Gemini의 1M 토큰 콘텍스트는 명확한 차별화 전략입니다. 그들의 논리는: 이전에 강제로 사용되던 RAG 조각, 이전 메시지 삭제 등 기술은 충분히 큰 창 아래에서 "직접적으로 삽입"될 수 있습니다.

하지만 그들 자신도 이것만으로 충분하지 않다고 인정합니다. Google은 Gemini CLI에 Conductor 확장을 출시했는데, 핵심 아이디어는 Anthropic과 똑같습니다: 프로젝트 의도를 채팅 창에서 제거하고, 영구적인 Markdown 파일에 들어 있는 공식적인 spec 및 계획 파일에 의존하는 것입니다. 그 철학은 "불안정한 채팅 기록에 의존하지 말고, 공식적인 spec 및 plan 파일에 의존하라"입니다.

젬니 3은 Thought Signatures 메커니즘도 소개했습니다: 추론 체인의 중요 노드를 장기 세션 동안 보존하여 「reasoning drift(추론 드리프트)」——장기적인 맥락에서 논리적인 일관성 문제를 방지합니다.

진정한 아키텍처 원칙은 무엇인가

세 조직의 엔지니어링 실천으로부터 몇 가지 공통 원칙을 도출할 수 있습니다:

추론 체인은 끊어질 수 없으며, 분기 후 다시 병합되어야 합니다. 다중 에이전트의 올바른 사용법은 파이프라인이 아니라 하나의 주요 에이전트가 완전한 의도를 보유하고, 하위 호출은 특정 하위 문제를 심층 조사하기 위한 것이며, 결과가 주요 에이전트로 다시 반환되어 다음 에이전트에 전달되는 것이 아닙니다.

명시적 외부 상태, 모델의 기억에 의존하지 않습니다. progress.txt, Git 기록, 사언 파일, 데이터베이스——형식은 중요하지 않으며, 원칙은 다중 에이전트의 중요 노드가 영구 저장소에 외부화되어야 하며, 컨텍스트 창에서 모델에 '기억되지 않아야 합니다.

다중 에이전트의 가치는 병렬 커버리지, 업무 분담이 아닙니다. 인류학 연구 시스템의 결론은 명확합니다: 성능 향상은 주로 "보다 많은 토큰을 사용함"에 기인하며, "더 합리적인 업무 분담"에 기인하는 것이 아닙니다. 다중 에이전트는 너비 우선 유형의 작업에 적합하며——다중 독립적인 방향을 동시에 탐색해야 하는 시나리오에 적합합니다. 연속적인 추론, 깊이 의존적 컨텍스트가 필요한 시나리오에는 적합하지 않습니다.

검증 에이전트는 부정자, 연장합은 아닙니다. 품질 통제를 위해 다중 에이전트를 사용해야 하는 경우, 올바른 설계는 한 에이전트가 다른 에이전트의 문제를 명시적으로 찾도록하고, "작업 결과를 전달하는 것이 아닙니다. 대립적인 검사는 파이프라인 전달이 아닙니다.

도구는 도구일 뿐이며, 역할이 아닙니다. 에이전트에 어떤 도구(배시, 파일 읽기/쓰기, 검색, 코드 실행)를 제공하는 것이 중요하며, 그것이 에이전트가 수행할 작업을 결정합니다. 역할 레이블은 에이전트가 무엇을 하길 원하는지에 대한 제한일 뿐입니다.

세 참, 육부는 왜 인기가 있을까요?

이유는 설명하기 좋기 때문입니다.

「이 에이전트는 PM이고, 그것은 QA입니다」 —— 이 문장은 누구나 이해할 수 있습니다. 이는 인간이 AI 시스템의 해석 가능성에 대한 열망을 충족시키며, 경영진이 'AI가 팀처럼 작동한다'는 상상을 충족합니다.

이는 또한 좋은 표시입니다. 프로세스 다이어그램으로 그려지면, 부서가 있고, 화살표가 있고, 이해하기 매우 직관적입니다.

하지만 좋은 해석과 좋은 표시는 공학적으로 타당한지 여부와는 다릅니다.

보다 깊은 이유는: 이러한 패턴을 채택한 대부분의 팀이 실제로 '다중 에이전트 간 문맥 전달 손실'이라는 문제에 직면해본 적이 없다는 것입니다. 그들의 작업이 충분히 복잡하지 않을 수 있거나 문제가 다른 요인에 의해 감춰졌을 수 있습니다. 작업 복잡도가 증가하고 시스템이 '지역적으로 올바르지만 전체적으로 잘못된' 미스를 보여주기 시작할 때, 문제가 드러납니다.

실용적인 제안

최고의 다중 에이전트 시스템은 회사처럼이 아닙니다. 그것은 오히려 하나의 사고자의 다양한 초고 상태입니다 — 동일한 두뇌가 다양한 차원에서 추론을 펼치고, 결국 일관된 결론으로 통합됩니다.

이 원칙에서 출발하여:

'나에게는 몇 개의 에이전트가 필요한가'가 아닌 '이 작업의 정보 의존 구조가 무엇인가'를 물어보세요.

작업이 연속적인 추론, 맥락에 높게 의존해야 하는 경우(예: 복잡한 기능의 설계 문서 작성), 단일 에이전트 + 좋은 문맥 엔지니어링이 일반적으로 다중 에이전트보다 우수합니다.

작업이 병렬로 여러 독립적인 방향을 탐구해야 하는 경우(예: 10가지 경쟁 제품의 서로 다른 모듈을 동시에 연구), 다중 에이전트 병렬 처리가 합리적입니다 — 각 하부 에이전트의 작업은 상호 독립적이며, 정보 손실 비용이 최소화됩니다. 이것이 바로 Anthropic Research 시스템에서 토큰 양이 80% 성능 차이의 이유를 설명하는 것입니다: 이는 작업 분배가 더 나아지게 한 것이 아니라, 더 많은 탐색 범위가 그것을 더 나아지게 한 것입니다.

작업이 여러 세션을 걸쳐야 하는 경우, 외부 상태 파일이 필수적입니다. 유효한 상태 파일은 네 가지 유형의 정보를 포함해야 합니다:

· 작업 목표(불변함, 세션이 시작될 때 읽고, 드리프트 방지)

· 완료된 단계(추가, 덮어쓰기 X, 전체적인 이력 유지)

· 현재 상태 (최신 개발을 반영하고 있음)

· 알려진 함정 (다음 세션에서 중복해서 발생하지 않도록 추가함)

이 네 가지 유형의 정보는 분리되어 유지되며, 모두 함께하면 "다음 단계"에 필요한 완전한 컨텍스트가 됩니다.

검증 단계를 추가하려면, 검증 에이전트의 유일한 임무는 문제를 찾는 것이어야 하며, "장바구니 전달"이 아닙니다. 적대적 검사는 생산 라인 전달이 아닙니다.

마지막으로, 모델 능력은 빠르게 향상되고 있으며, 오늘 하네스에서 필요로 하는 해결책은 6개월 후에는 쓸모없는 무게가 될 수 있습니다. Anthropic은 이미 이를 확인했습니다 — Sonnet 4.5의 컨텍스트 불안은 Opus 4.5에서 해결되었으며, 해당 컨텍스트 재설정은 쓸모없는 코드로 변해버렸습니다. 아키텍처의 진화 가능성을 유지하는 것이 "완벽한 아키텍처"를 선택하는 것보다 중요합니다.

삼성육부는 기술적으로 비용이 많이 드는 환상입니다. 진정한 비용은 직접적인 실패가 아니라 시스템이 복잡성이 증가할 때, 진단하기 어려운 방식으로 퇴화되는 것입니다 — 모든 노드가 "작동 중인 것 처럼" 보이지만 전체적으로 부정확합니다.

문제를 발견할 때까지, 생산 라인은 이미 아주 길어졌습니다.

참고 자료:

Anthropic 엔지니어링 블로그 (효과적인 에이전트 빌드, 효과적인 컨텍스트 엔지니어링, 다중 에이전트 연구 시스템, 장기간 실행 에이전트용 효과적인 하네스, 관리되는 에이전트); OpenAI 개발자 블로그 (코덱스를 사용한 장기간 과업 실행, 셸 + 스킬 + 압축); Google 개발자 블로그 (효율적인 컨텍스트 인지 다중 에이전트 프레임워크 설계, Gemini CLI용 컨덕터: 컨텍스트 주도 개발)

원문 링크

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia