상용 LLM 서비스의 실제 멀티에이전트 조직화

우리는 흔히 강의나 이론서에서 Supervisor, Hierarchical, Network, Subgraph 같은 깔끔한 에이전트 패턴을 배웁니다. 이론적으로는 완벽해 보이지만, “실제 대규모 트래픽을 감당하는 프로덕션 환경에서도 이 패턴이 그대로 쓰일까?”라는 의문이 남습니다.

오늘은 실제 운영되고 있는 유명 LLM 기반 코딩 어시스턴트 서비스(이하 ‘서비스 X’)의 공개된 아키텍처 문서를 바탕으로, 실무진들이 컨텍스트 폭발 문제와 역할 전문화를 어떻게 해결했는지 그 핵심 트레이드오프와 설계 결정을 파헤쳐 봅니다.

0. 왜 이론과 실무는 다를까?

이론적인 Supervisor 패턴은 깔끔하지만, 실무에서 그대로 적용하면 메인 에이전트의 컨텍스트 윈도우(Context Window)가 순식간에 폭발하는 치명적인 한계가 있습니다. 수많은 파일의 코드를 읽고 분석하는 코딩 어시스턴트의 특성상, 중간 과정의 모든 메시지를 메인이 들고 있으면 비용도 기하급수적으로 늘고 모델의 추론 능력도 흐려지기 때문입니다.

서비스 X는 이 문제를 해결하기 위해 ‘격리와 요약’이라는 고도의 설계 전략을 선택했습니다.

1. 핵심 구조: Orchestrator와 Subagent

서비스 X의 전체적인 아키텍처는 메인 에이전트가 오케스트레이터(Orchestrator) 역할을 하고, 특정 작업에 특화된 서브 에이전트(Subagent)들을 도구(Tool) 형태로 호출하는 구조입니다.

• 메인 에이전트의 컨텍스트가 폭발하지 않게 하려면?
• 같은 도메인 작업을 어떻게 전문화할까?
• 왜 어떤 작업은 main 에이전트가 하고, 어떤 건 sub-agent 에 위임할까?

---

1-1. 핵심 구조 (한 그림)

        ┌─────────────────────────┐
        │   메인 에이전트          │   ← 사용자와 직접 대화
        │   (Orchestrator)        │     긴 컨텍스트 유지
        └──┬─────┬─────┬─────┬───┘
           │     │     │     │
           ▼     ▼     ▼     ▼      Task 도구로 subagent 호출
       ┌────┐┌────┐┌────┐┌────┐
       │Sub │ Sub │ Sub │ Sub │     각자 독립 컨텍스트
       │ A  ││ B  ││ C  ││ D  │     역할별 전문화
       └─┬──┘└─┬──┘└─┬──┘└─┬──┘     완료 시 요약만 반환
         │    │    │    │
         └────┴────┴────┘
              ↓
        결과 요약 (몇 줄)
              ↓
        메인 에이전트 (요약 받음, 풀 트랜스크립트 X)

1-2. 핵심 결정 5 가지

설계 결정	이유
Task 라는 단일 도구로 subagent 호출	메인 입장에선 도구 1개 호출. 상세 협업 흐름은 도구 안에 캡슐화
Subagent 는 독립 컨텍스트	메인의 메시지 히스토리를 안 봄. 컨텍스트 오염 방지
Subagent 는 요약만 반환	메인의 컨텍스트 윈도우 절약 (subagent 가 100 메시지 써도 메인엔 5 줄 요약만 들어옴)
Subagent 별 역할 (전문화)	“탐색”, “계획”, “보안 리뷰” 처럼 명시적 분업
읽기 전용 vs 쓰기 권한 분리	위험 도구 (파일 수정·git 커밋) 는 메인만, 읽기 (코드 검색·문서 fetch) 는 subagent

서브 에이전트들이 내부적으로 소모한 메시지는 총 130+개가 넘지만, 메인 에이전트의 컨텍스트에는 도구 호출 4개와 요약본 4개만 남습니다. 이 방식을 통해 컨텍스트를 90% 이상 절약하면서도 복잡한 미션을 완수합니다.

1-3. 실제 동작 시나리오 (재구성)

사용자: "tests/ 디렉토리의 실패하는 테스트 모두 찾아서 fix 해줘"

메인 에이전트의 결정:
  "테스트 결과 수집 + 실패 원인 분석 + 코드 수정 — 단계별로"

1. Task("Explore", "tests/ 의 모든 *.test.ts 찾기")
   ↓
   [Subagent A] 50 개 파일 탐색·읽기·분석 → 100 메시지
   ↓ 메인엔 "5 개 실패 테스트 발견 (auth, payment, ...)" 만 반환

2. Task("Plan", "위 5 개 실패 케이스의 fix 계획")
   ↓
   [Subagent B] 코드 분석·관계 추적 → 30 메시지
   ↓ 메인엔 "fix 계획: A→B→C 순서 / 각 단계 5 분 소요" 만 반환

3. 메인이 직접 파일 수정 (쓰기 도구는 메인 권한)

4. Task("Verify", "수정된 테스트 다시 실행")
   ↓
   [Subagent C] 테스트 실행·로그 분석
   ↓ 메인엔 "5/5 통과" 반환

메인 에이전트의 컨텍스트엔 도구 호출 4 개 + 요약 4 개만.
실제 작업은 100+ 메시지 분량이지만 컨텍스트 절약 90%+.

접기

1-4. 실제 등록된 Subagent 카탈로그 (예시)

서비스 X 가 메인 에이전트에서 호출 가능한 subagent 들의 실제 카탈로그 (재구성). 메인은 Task(subagent_type=..., prompt=...) 한 도구로 이 중 하나를 골라 호출.

subagent_type	역할	허용 도구	호출 시점
general-purpose	범용 멀티스텝 (광범위 검색·종합)	전체 도구	키워드 / 파일 위치를 자신 없을 때, 여러 단계 reasoning 필요할 때
Explore	빠른 read-only 검색 — 파일·심볼 grep	Read / Grep / Glob / WebFetch / Bash (read-only)	“X 정의 어디?”, “Y 참조하는 파일?” 같은 위치 추적
Plan	소프트웨어 아키텍트 — 구현 전 설계	모든 read 도구 + 분석 (Edit/Write 금지)	기능 추가 / 리팩토링 전 단계별 계획 + 트레이드오프 분석
claude-code-guide	Claude Code 자체 사용법 Q&A 도우미	Bash / Read / WebFetch / WebSearch	“이 CLI 의 hooks·MCP·slash command 어떻게?” 식 도구 자체 질문
statusline-setup	사용자 status line 설정 마법사	Read / Edit (settings.json 만)	상태바 커스터마이징 요청 시에만

핵심 관찰:

• general-purpose = 디폴트 fallback — 메인이 어떤 도메인인지 못 정할 때
• Explore 는 “검색만” — 크지만 빠른 문맥 윈도우 (수많은 파일 빠르게 훑되 cat-n 관점이라 깊이는 얕음)
• Plan 은 “쓰기 금지” — 메인이 직접 쓰기 권한 (위험 도구 분리 원칙 5)
• 도메인 특화 subagent (statusline-setup) — 작은 일이지만 자주 반복 / 명확 분리되는 task 만 별도 등록

1-5. Subagent 정의 형식 (재구성)

각 subagent 는 메인이 보는 카탈로그 항목 + 자기 자신만의 system prompt + 허용 도구 화이트리스트로 구성됨:

# 예시 — Explore subagent 정의
name: Explore
description: |
  Fast read-only search agent for locating code. Use it to find files
  by pattern, grep for symbols, or answer "where is X defined / which
  files reference Y." Do NOT use it for code review or open-ended analysis.tools: [Read, Grep, Glob, WebFetch, WebSearch, Bash]
system_prompt: |
  너는 코드 탐색 전문가. 키워드·심볼 빠르게 찾고 위치 + 짧은 발췌만 반환.
  설계 비평 / 리팩토링 제안 X — 그건 Plan / general-purpose 의 일.

메인 에이전트는 사용자 요청을 보고 “이건 Explore? Plan? general-purpose?” 를 LLM 추론으로 결정. 잘못 고르면 결과가 빈약 → 메인이 다시 다른 subagent 호출 (재시도).

1-6. 메인이 subagent 를 고르는 휴리스틱 (재구성)

사용자 요청
     ↓
"단순 조회/탐색이고 결과 위치만 알면 됨?"  →  YES → Explore
                  ↓ NO
"구현 전 큰 그림 / 단계별 계획이 필요?"      →  YES → Plan
                  ↓ NO
"여러 단계 reasoning + 다양한 도구 필요?"    →  YES → general-purpose
                  ↓ NO
"이 도구·CLI 자체에 대한 질문?"              →  YES → claude-code-guide
                  ↓ NO
                직접 처리 (메인이 도구 호출)

코드 전체 보기 (11줄)

휴리스틱은 prompt 에 인코딩 — 강제 분기 X. LLM 이 카탈로그 description 을 읽고 자체 판단.

---

2. Day 5 강의 4 패턴과 비교

항목	Day 5 Supervisor	서비스 X 패턴
위계	Supervisor (분배자) → Workers	Main (대화자) → Subagents (배치 작업자)
메시지 흐름	모든 메시지가 supervisor 거침	Subagent 의 messages 는 격리
컨텍스트 절약	Supervisor 가 전체 봄 → 길어짐	메인은 요약만 → 일정함
Subagent 호출	Command(goto=) 또는 handoff tool	Task 도구 호출 (도구 1개)
사용자 인지	어느 에이전트가 답했는지 명시	메인이 종합해서 답 (subagent 존재 안 보임)
적합 대상	명확한 도메인 분리 (검색/DB/보고서)	도구 많은 코딩·연구 어시스턴트

핵심 차이: 컨텍스트 절약 vs 흐름 추적성 트레이드오프.

이론적인 에이전트 아키텍처는 흐름의 ‘추적성(Traceability)’과 ‘명확한 도메인 분리’에 집중합니다. 반면 실제 대규모 서비스(프로덕션) 환경에서는 ‘컨텍스트 윈도우 절약’과 ‘안정성(권한 분리)’을 위해 추적성을 일부 포기하더라도 메시지를 격리하고 캡슐화하는 전략을 취합니다.