AI ESSAY 박종관· October 9, 2026 ·6 min

자율 에이전트의 환상을 넘어: 프로덕션 멀티 에이전트 오케스트레이션 실전 구축기

데스 스파이럴과 컨텍스트 오염을 넘어 실제 프로덕션에서 멀티 에이전트를 가동하기 위한 메인 컨텍스트 보호, 생각의 양 기반 모델 티어링, 반환 프로토콜과 비중복 병렬 슬라이싱 구축기.

“모든 것을 스스로 판단하는 자율 에이전트는 환상이다. 실제 프로덕션에서 에이전트를 움직이는 것은 정교하게 설계된 컨텍스트 위생(Hygiene), 생각의 양 기반 모델 라우팅, 그리고 결정론적인 병렬 슬라이싱이다.”

최근 멀티 에이전트 시스템을 구축할 때 가장 흔히 겪는 실패 패턴은 명확합니다. 에이전트에게 너무 넓은 자율성을 주어 토큰을 무한정 태우며 루프에 빠지는 데스 스파이럴(Death Spiral), 수만 줄의 로그와 파일 원문이 쌓여 추론 능력이 붕괴하는 컨텍스트 오염(Context Degradation), 그리고 무분별한 병렬 처리로 인한 **머지 충돌(Merge Conflict)**입니다.

이러한 문제를 해결하고 단단한 엔지니어링 규범 위에서 멀티 에이전트를 운영하기 위해 정립한 계정/프로젝트 단위 오케스트레이션 아키텍처와 실전 노하우를 공유합니다.

1. 메인 컨텍스트 보호: “메인은 지휘와 판단만 한다”

대화형 세션의 메인(Main) 에이전트는 프로젝트 전체의 방향을 쥐고 있는 지휘자입니다. 메인의 컨텍스트가 오염되면 전체 작업의 판단력이 흐려집니다. 따라서 메인 컨텍스트 보호는 시스템의 제1원칙입니다.

[메인 에이전트] (상급: 판단·설계·통합)
   │
   ├─► 위임 판정: "중간 산출물을 내가 직접 봐야 판단이 되는가?"
   │      ├─ No  ──► 서브에이전트 위임 (요약/경로 계약)
   │      └─ Yes ──► 메인 직접 수행 (타깃 리딩)
   │
   └─► 결과 형식 계약 (Output Contract) 회수
          └─ [경로 / 변경 요약 / 검증 결과]만 반환 (파일 원문 덤프 금지)

실전 운영 규범

결과 형식 계약 (Output Contract): 서브 에이전트 위임 시 파일 원문을 메인으로 덤프하지 못하도록 강제합니다. 100줄 이상의 대형 산출물은 자식이 디스크에 직접 쓰고 메인에는 [파일 경로 / 변경 요약 / 검증 결과]만 반환합니다.
대량 Read 사전 차단 신호: 메인에서 전체 파일 읽기가 3개 초과 또는 누적 400줄 이상 예상되면 직접 읽지 않고 탐색 서브에이전트를 띄워 결론만 받습니다.
읽기/쓰기 턴 분리: 한 턴 안에서 코드 탐색(Read)과 수정(Write)을 섞지 않고 턴을 엄격히 분리합니다.
40% 핸드오프 하드 게이트: 세션의 남은 컨텍스트 용량이 40% 미만으로 떨어지면 신규 작업을 멈추고, 핵심 진행 상태와 결정을 압축한 인계 프롬프트를 생성해 새 세션으로 전환(Handoff)합니다.
L4 히스토리 문서 접근 차단: 과거 기획서나 완료 보고서 같은 히스토리 문서(docs/reports/ 등)는 사용자가 명시적으로 지정하지 않는 한 AI가 임의로 탐색하지 못하도록 차단하여 컨텍스트 낭비와 환각을 방지합니다.

2. 모델 티어링: “규모나 위험도가 아닌 ’생각의 양’으로 결정”

단순히 “중요한 작업이니까 최상급 모델을 쓴다”는 식의 배정은 비용과 레이턴시 폭증의 주원인입니다. 모델 등급은 오직 ‘필요한 생각(추론)의 양’ 하나로만 분류합니다.

등급	주요 역할	배정 원칙 및 대표 모델
최상급	복합 의사결정, 난제 아키텍처, 최종 고난도 판정	명시 호출 전용 (자동 배정 절대 금지). 사용자가 명시하거나 작업자가 `[반환]`으로 요청할 때만 승인 후 호출
상급	지휘·감독, 방향 결정, 기획/설계, 원인 불명 디버깅	대화형 메인의 기본 등급. 판단이 남아있는 구현 및 조사에 배정 (Claude Opus, GPT Sol)
일반	명세·성공 기준이 확정된 실작업, 정형 조회, 반복 작업	슬라이스 단위 실작업 전담. 코드 구현, 기계적 치환, 대량 문서 갱신 (Claude Sonnet, DeepSeek Flash 등)

세션 상한(Session Cap)과 공식 교차 페어(Cross-Provider)

세션 상한: 메인의 등급(상급)이 해당 세션의 상한선입니다. 상급 세션에서 최상급 dispatch를 만나면 승격 오류를 내는 대신 같은 프로바이더의 상급으로 자동 대체 실행하여 세션 연속성을 보장합니다.
지휘 ↔ 실행 교차 페어 실전 사례: 일반적으로는 프로바이더 격리(Claude 메인은 Claude 자식만 호출)를 유지하지만, 속도와 비용 최적화를 위해 공식 교차 페어를 규범화했습니다.
- 지휘자 (메인): Gemini 3.8 Flash (빠른 오케스트레이션, 긴 컨텍스트 윈도우)
- 실행자 (일반 routine): DeepSeek 4.1 Flash (저비용, 고속 코드 생성)
- 이를 model-tiers.json 라우팅 테이블에 공식 등록하고 게이트웨이 필터를 걸어, 메인이 Gemini일 때 정형 실작업 슬라이스는 Paseo 데몬을 통해 DeepSeek으로 자연스럽게 교차 위임되도록 구성했습니다.

3. 서브 에이전트의 역설: “정보 부족이 아니라 ’컨텍스트 과다 주입’이 문제다”

흔히 서브 에이전트를 띄울 때 “배경지식이 부족해서 일을 못하면 어쩌지?“를 걱정합니다. 하지만 Claude Code나 OpenCode 같은 현대적 CLI/런타임 환경에서 서브 에이전트는 이미 수만 토큰의 거대한 배낭(시스템 프롬프트, 전역 규칙, 프로젝트 설정, 수십 개의 MCP 도구 스키마)을 메고 시작합니다.

[서브에이전트 진입 시점의 컨텍스트]
┌──────────────────────────────────────────────┐
│ 런타임 프롬프트 + 프로젝트 전역 룰 (수만 토큰)   │ ──► 주의력 분산 (Attention Dilution)
├──────────────────────────────────────────────┤
│ 🔍 브리핑의 역할: 선택적 시야 제한 (Focusing) │
│    - 정확한 수정 대상 (write_set)            │
│    - 품질 기준 1줄 (업계 표준 앵커)           │ ──► 잡음을 쳐내고 해당 작업에만 집중
│    - 결과 형식 계약                           │
└──────────────────────────────────────────────┘

따라서 서브 에이전트 브리핑의 핵심은 정보를 더 주는 것이 아니라, 배낭 안의 수많은 잡음을 쳐내고 시야를 좁혀주는 ‘선택적 렌즈(Focusing Lens)’ 역할을 하는 것입니다.

에이전트 폭주를 막는 3대 `[반환]` 프로토콜

서브 에이전트가 막혔을 때 억지로 해결하려다 환각에 빠지는 것을 막기 위해, 아래 3가지 상황에서는 즉시 실행을 멈추고 [반환]하도록 강제합니다.

① 명세에 없는 정책/설계 판단이 필요해진 경우
② 새 근거 없이 동일한 실패를 2회 반복한 경우
③ 외부 대기를 제외한 실행 시간이 예상 시간의 1.5배를 초과한 경우

[반환]은 실패가 아니라 “메인에게 등급이나 명세를 다시 분류해달라”는 신호입니다. 이 장치 하나만으로 무의미한 토큰 낭비와 엉뚱한 코드 수정을 99% 차단할 수 있습니다.

4. 병렬 위임과 슬라이싱: `same tree + write_set disjoint`

여러 작업을 병렬로 돌릴 때 git worktree를 남발하면 브랜치 병합 충돌, 종속성 설치 오버헤드, 로컬 포트 충돌로 시스템이 멈춥니다. 프로덕션에서는 가장 단순하고 가벼운 격리 방식을 택해야 합니다.

[작업 슬라이싱 및 병렬 디스패치]

메인: 전체 계획 수립 & 슬라이싱 (1회 계산)
  │
  ├─► [Wave 1] 선행 의존성 고정 (공유 인터페이스/타입 선언)
  │
  └─► [Wave 2] 독립 실작업 병렬 Dispatch (한 메시지에 동시 실행)
         ├─ Lane A: auth/login.ts      (write_set A)
         └─ Lane B: profile/user.ts    (write_set B)
         * 공유 파일(package.json 등)은 전담 레인 1개만 수정

병렬화의 핵심 원칙

단일 트리 내 비중복 파일 분할 (write_set disjoint): 동일한 작업 트리 내에서 에이전트별 수정 대상 파일 목록(write_set)이 절대 겹치지 않도록 분할합니다. worktree는 사용자의 명시적 요청이 있을 때만 예외적으로 씁니다.
사전 슬라이싱은 낭비가 아닌 ‘최고의 투자’: “어떻게 쪼갤 것인가”에 대한 계산은 메인 컨텍스트에서 지시마다 딱 1회만 수행합니다. 여기서 의존성을 깔끔히 묶어두면 서브 에이전트들이 충돌 없이 완주하므로 전체 롤백 비용이 제로가 됩니다.
공유 자원의 단일 레인 전담: package.json, 라우트 설정, 전역 스타일 등 공통 집약 파일은 반드시 1개 레인만 건드리도록 격리하고, 공통 타입/인터페이스 계약은 병렬 작업 착수 전 메인이 먼저 확정합니다.
시간 예산(Time Budget) 통제: 연쇄 실행 시 총 소요 시간을 먼저 사용자에게 승인받으며, 반나절(4시간)을 넘는 장기 체인은 제안하지 않고 1~2개 슬라이스로 자릅니다. 단일 슬라이스가 예상 시간의 1.5배를 넘기면 즉시 중단하고 사용자에게 계속 진행할지 범위를 축소할지 확인합니다.

5. 마치며: 프롬프트 튜닝에서 “시스템 엔지니어링”으로

멀티 에이전트의 성패는 모델의 ‘지능’ 그 자체보다 **‘컨텍스트와 실패를 어떻게 격리하는가’**에 달려 있습니다.

메인 컨텍스트는 결과 형식 계약과 핸드오프 게이트로 깨끗하게 보호하고,
모델은 규모가 아닌 생각의 양에 따라 적재적소(Gemini 지휘 ↔ DeepSeek 실행 등)에 배치하며,
서브 에이전트는 **비중복 write_set**과 [반환] 규범을 통해 탈선하지 않고 병렬로 달릴 수 있는 레일을 깔아주는 것.

이러한 규범이 시스템 수준(~/.agents/)과 프로젝트 수준(AGENTS.md)에 코드로 정착될 때, 비로소 AI 에이전트는 장난감이 아닌 진짜 주니어/미드레벨 엔지니어 팀처럼 동작하게 됩니다.

AI 에이전트 멀티 에이전트 오케스트레이션 컨텍스트 엔지니어링 모델 라우팅 시스템 아키텍처