research

Multi-Agent 구조 — 언제, 왜, 어떻게

Multi-Agent 구조 — 언제, 왜, 어떻게

Single Agent의 구조적 한계

지금 일반적인 Claude Code 사용 방식:

인간 → Claude Code (single agent) → 코드 작성 → 인간 검토 → 반복

두 가지 벽:

  • 컨텍스트 한계: 작업이 길어지면 앞 결정을 잊거나 일관성이 깨진다
  • 직렬 처리: 한 번에 한 가지 일만. A가 끝나야 B를 시작한다

Multi-Agent 구조

인간
 └→ Orchestrator agent
      ├→ Worker A (기능 구현)
      ├→ Worker B (테스트 작성)
      └→ Worker C (문서 정리)

각 worker는 자기 작업 범위의 컨텍스트만 가진다. → 각자 "스마트 존" 유지 + 병렬 처리 가능

Git Worktree가 여기서 나오는 이유

각 worker agent가 같은 repo의 다른 branch를 동시에 체크아웃해서 충돌 없이 병렬 작업하려고. Worktree 없이는 branch switching이 직렬로 일어난다.

git worktree add ../feature-a feature-a
git worktree add ../feature-b feature-b
# Worker A는 ../feature-a, Worker B는 ../feature-b에서 동시에 작업

탑다운 vs 바텀업

탑다운 (Orchestrator가 작업 분해)

  • 큰 목표를 Orchestrator가 알아서 분해
  • 현재 모델 수준에서 불안정: Orchestrator 자체가 설계 능력이 있어야 함
  • 아직 실용 단계가 아님

바텀업 (인간이 작업을 정의, worker가 실행)

  • 인간이 "기능 구현", "테스트", "문서화"를 정의
  • 각 piece를 worker에게 위임해서 병렬 처리
  • 지금 당장 실용적인 방식

"뭘 만들어야 하는지 모른다" 문제

Multi-agent는 작업을 잘게 쪼갤 수 있을 때 의미가 있다. 쪼개려면 뭘 만드는지를 알아야 한다.

"뭘 만들어야 하는지 모른다"는 상태에서 multi-agent는 복잡도만 올라간다. 작업이 명확하게 분해될 수 있을 때 비로소 의미가 생긴다.

비용 대비 효율이 나오는 구간

| 상황 | Single이 나음 | Multi가 나음 | |---|---|---| | 작업 크기 | 작고 명확 | 크고 분해 가능 | | 작업 간 의존성 | 높음 | 낮음 | | 반복성 | 낮음 | 높음 (같은 패턴 반복) |

Multi-agent의 진가: 이미 잘 정의된 작업을 대량으로 처리할 때

결론

설계 → 구현을 직접 하는 단계에서는 single agent가 더 효율적일 가능성이 높다. Multi-agent로 전환할 시점은:

  1. 작업 패턴이 반복되기 시작할 때
  2. 병렬로 처리하면 확실히 빠른 작업이 생겼을 때
  3. 단일 agent의 컨텍스트 한계가 실제로 문제가 됐을 때

관련 개념

v1 → v2 문제: 개발 맥락 유지

핵심 긴장

전통 개발에서 코드를 직접 짜는 행위는 두 가지를 동시에 한다:

  1. 기능을 구현한다
  2. 시스템에 대한 멘탈 모델을 머릿속에 쌓는다

AI에게 구현을 맡기면 1번은 해결되지만 2번이 빠진다.

v1 설계 → AI 구현 → 작동함
                       ↓
                  v2 요구사항 발생
                       ↓
            내부 구조를 모르니 설계가 표면적
                       ↓
            AI가 v1 위에 억지로 올림 → 기술 부채 폭발

읽는 것 vs 짜는 것

코드를 읽는 것과 직접 짜는 것은 다른 종류의 이해를 만든다. 읽어도 "왜 이 구조로 됐는가"의 맥락이 빠지면 멘탈 모델이 불완전하다. 특히 AI 코드는 패턴이 정확하고 읽기 쉬워 보이지만, 설계 의도가 내 결정이 아니었다면 나중에 "이게 왜 이렇게 됐지?"가 발생한다.

현실적인 접근: 맥락을 유지하면서 위임하기

ADR (Architecture Decision Record) 구현 결과가 아니라 "왜 이 구조를 선택했는가"를 코드 옆에 기록. v2에서 "이 결정이 아직 유효한가?"를 판단할 수 있게 된다.

계층화된 이해 모든 코드를 다 이해할 필요는 없다.

  • 깊이 이해: 모듈 간 경계, 데이터 흐름, 핵심 비즈니스 로직
  • 위임: 유틸리티, boilerplate → 테스트가 보장하면 내부 신뢰

짝 프로그래밍 방식 "이거 구현해줘" → "어떻게 구현할지 설명하고, 내가 이해하면 짜줘" 구현의 주도권은 AI, 이해의 책임은 인간.

현재 균형점

완전 위임: 단기 속도는 빠르지만 v2 문제 발생 완전 직접 구현: 속도를 못 따라감 → 맥락을 유지하면서 위임하는 균형점이 지금 시점의 정답

이건 Harness Engineering이 아직 완전히 해결하지 못한 부분.

Orchestration 위임의 한계 — 현재 미해결 문제

핵심 긴장

Orchestrator LLM에게 맡기면:

  • 인간이 추적하기 어려운 결정들이 내부에서 일어난다
  • 인간이 검토하려면 전체 컨텍스트를 다 읽어야 한다
  • → 형식적 y/n이 되거나, 역설적으로 더 많이 읽어야 하거나

둘 다 나쁜 상태.

왜 미해결인가

인간의 개입 지점을 설계하는 것 자체가 아직 정립되지 않았다.

| 방식 | 문제 | |---|---| | 체크포인트 (특정 지점 승인) | 인간이 실제로 판단하려면 맥락을 읽어야 함 → 속도 이점 사라짐 | | 예외 에스컬레이션 (문제 생기면 호출) | "문제"를 orchestrator가 판단 못 하면 인간은 모름 |

인식론적 문제

"내가 개입할 수 있는 게 y/n뿐이라면, 나는 그냥 승인자다. 새로운 문제가 생겼을 때 창의적인 해결을 내가 못 한다."

→ 내가 시스템을 이해하지 못하면, 내가 내리는 판단도 표면적일 수밖에 없다. → 이건 도구 문제가 아니라 인식론적 문제다.

현재 시점의 현실적 접근

Orchestrator 없는 병렬화:

인간이 작업을 직접 분해
  ↓
각 piece를 worker에게 개별 지시
  ↓
각 결과를 인간이 직접 검토 후 합침
  • 분해와 통합의 주체: 인간
  • 실행만 병렬화

완전 자율 orchestration은 현재 단계에서 맥락 손실이 실제로 발생한다. 업계도 인식하고 있으나 아직 미해결.

해결 시도들 — 현재까지 나온 접근

1. Initializer Agent + Feature List (Anthropic)

long-running agent의 context 단절 문제를 파일 기반 handoff로 우회.

1. Initializer agent가 첫 세션에서 feature 목록 작성 (전부 "failing" 상태)
2. 이후 coding agent들이 이 목록을 보며 무엇이 남았는지 파악
3. 완료된 feature는 "passing"으로 업데이트
4. 새 세션 agent도 파일만 읽으면 맥락 파악 가능

ADR과 feature list가 agent 간 handoff 프로토콜 역할을 한다. 인간이 맥락을 따라가야 하는 문제를, agent 자신이 맥락을 파일로 남기는 방식으로 우회.

출처: Anthropic Engineering — "Effective Harnesses for Long-Running Agents"

2. Self-Verify Loop 강제

흔한 실패 패턴: agent가 코드 작성 → 피상적 리뷰 → "괜찮다" 선언 → 종료. 해결: "build-verify loop"를 시스템 프롬프트 레벨에서 명시적으로 강제.

  • 구현 후 테스트 실행
  • 코드 리뷰가 아니라 스펙과 비교 검증

3. 진화하는 HITL (Human-in-the-Loop)

단순 승인 게이트 → 지능적 에스컬레이션으로 진화 중:

  • Agent가 루틴한 케이스는 스스로 처리
  • Edge case만 인간에게 에스컬레이션
  • 인간의 드문 감독 → agent의 학습 신호

4. Agentic Engineering (Karpathy, 2026)

Vibe coding 다음 단계의 패러다임. AI agent가 계획·구현·테스트·배포를 structured human oversight 하에서 수행. 캐주얼 프롬프팅이 아닌, AI-first 개발의 전문 방법론.

미해결: Context Durability

새로운 병목으로 떠오르는 문제.

  • Agent가 100번째 step 이후에도 올바르게 추론하는지 감지가 어렵다
  • Harness가 이를 감지하는 도구가 될 것으로 예측
  • 이 데이터를 다시 훈련에 넣어 "지치지 않는" 모델을 만드는 방향

현재 시점 결론

"완전 위임이 아니라, 인간 개입 지점을 설계하는 것 자체가 엔지니어링이다."

개인 개발자 레벨에서 가장 실용적인 현재 답: → Anthropic의 initializer + feature list 패턴 → 분해와 통합은 인간, 실행만 병렬화

엔터프라이즈 레벨의 완전한 해결책은 아직 없음.

← research 목록으로홈으로