Capstone 10 — 멀티 에이전트 소프트웨어 엔지니어링 팀

SWE-AF의 팩토리 아키텍처(factory architecture), MetaGPT의 역할 기반 프롬프팅(role-based prompting), AutoGen 0.4의 타입드 액터 그래프(typed actor graph), Cognition의 Devin, Factory의 Droids는 모두 2026년에 같은 형태로 수렴했습니다. 아키텍트(architect)가 계획을 세우고, N명의 코더(coder)가 병렬 워크트리(worktree)에서 작업하며, 리뷰어(reviewer)가 게이트(gate)를 세우고, 테스터(tester)가 검증합니다. 병렬 워크트리는 실제 경과 시간(wall-clock)을 처리량(throughput)으로 바꿔 줍니다. 공유 상태(shared state)와 핸드오프 프로토콜(handoff protocol)이 곧 실패 표면(failure surface)이 됩니다. 이 캡스톤(capstone)의 목표는 그러한 팀을 직접 만들고, SWE-bench Pro에서 평가하며, 어떤 핸드오프가 얼마나 자주 깨지는지를 보고하는 것입니다.

유형: Capstone 언어: Python / TypeScript(에이전트), Shell(워크트리 스크립트) 선수 지식: Phase 11(LLM 엔지니어링), Phase 13(도구), Phase 14(에이전트), Phase 15(자율 시스템), Phase 16(멀티 에이전트), Phase 17(인프라) 실습 Phase: P11 · P13 · P14 · P15 · P16 · P17 예상 시간: 40시간

문제

단일 에이전트(single-agent) 코딩 하네스(harness)는 큰 작업에서 한계에 부딪힙니다. 개별 에이전트의 능력이 부족해서가 아닙니다. 200k 토큰(token) 규모의 문맥(context) 한 곳에 아키텍처 계획과 네 개의 병렬 코드베이스 조각(slice), 그리고 리뷰어의 코멘트, 테스트 출력을 동시에 담을 수 없기 때문입니다. 멀티 에이전트 팩토리(multi-agent factory)는 이 문제를 분할해서 풉니다. 아키텍트는 계획을 책임지고, 코더는 병렬 워크트리에서 구현을 책임지며, 리뷰어는 통과 여부를 결정하는 게이트를 세우고, 테스터는 결과를 검증합니다. SWE-AF의 "팩토리" 아키텍처, MetaGPT의 역할(role), AutoGen의 타입드 액터 그래프는 모두 같은 구조를 다른 언어로 설명한 것입니다.

실제 실패는 대부분 핸드오프(handoff) 지점에서 발생합니다. 아키텍트가 코더가 구현할 수 없는 계획을 세울 수도 있고, 코더들이 서로 충돌하는 디프(diff)를 만들어낼 수도 있습니다. 리뷰어가 환각(hallucination)된 수정안을 그대로 승인하거나, 테스터가 아직 작성 중인 코더와 경쟁 조건(race condition)을 일으키기도 합니다. 이 캡스톤에서는 그러한 팀을 하나 직접 만들고, 50개의 SWE-bench Pro 이슈(issue)에서 실행하며, 모든 핸드오프를 추적하고 사후 분석(post-mortem)을 공개해야 합니다.

개념

역할은 타입드 에이전트(typed agent)로 정의됩니다. 아키텍트(Architect)(Claude Opus 4.7)는 이슈를 읽고 계획을 작성한 뒤, 명시적인 인터페이스(interface)를 가진 서브태스크(subtask)들로 나눕니다. 코더(Coders)(Claude Sonnet 4.7, N개의 병렬 인스턴스, 각자 git worktree와 Daytona 샌드박스(sandbox)에서 동작)는 서브태스크를 독립적으로 구현합니다. 리뷰어(Reviewer)(GPT-5.4)는 병합된 디프를 읽고 승인하거나 구체적인 변경 사항을 요청합니다. 테스터(Tester)(Gemini 2.5 Pro)는 격리된 환경에서 테스트 스위트(test suite)를 실행하고, 산출물(artifact)과 함께 통과/실패 결과를 보고합니다.

에이전트들 사이의 통신은 공유 태스크 보드(task board)를 통해 이뤄집니다. 태스크 보드는 파일 기반(file-backed)일 수도 있고 Redis로 구현될 수도 있습니다. 각 역할은 자신이 처리할 권한이 있는 메시지만 소비합니다. 핸드오프는 A2A 프로토콜(A2A protocol)에 따라 타입(type)이 정의된 메시지로 표현됩니다. 조정에서 특히 신경 써야 할 부분은 세 가지입니다. 첫째, 병합 충돌 해결(merge conflict resolution)입니다. 별도의 코디네이터(coordinator) 역할이나 자동 3-way 병합(three-way merge)이 필요합니다. 둘째, 공유 상태 동기화(shared-state synchronization)입니다. 코더들이 작업을 시작한 순간 계획은 동결(freeze)되며, 다시 계획을 짜는 일은 별도의 이벤트(event)로 처리합니다. 셋째, 리뷰어의 게이트키핑(gatekeeping)입니다. 리뷰어는 자신이 만든 변경이나 자신이 제안한 변경을 직접 승인할 수 없습니다.

이 구조에서 숨어 있는 비용은 토큰 증폭(token amplification)입니다. 모든 역할 경계마다 요약 프롬프트(summary prompt)와 핸드오프 컨텍스트가 추가되기 때문입니다. 단일 에이전트로 40턴(turn) 만에 끝나던 작업이 네 역할로 분산되면 전체 160턴까지 늘어날 수 있습니다. 그래서 평가 루브릭(rubric)은 단일 에이전트 기준선(baseline) 대비 토큰 효율성에 명시적으로 가중치를 둡니다. 질문은 "멀티 에이전트가 동작하느냐"가 아니라 "같은 비용을 들였을 때 더 좋은 결과를 내느냐"이기 때문입니다.

아키텍처

GitHub issue URL
      |
      v
Architect (Opus 4.7)
   reads issue, produces plan with subtasks + interfaces
      |
      v
Task board (file / Redis)
      |
   +-- subtask 1 ---+-- subtask 2 ---+-- subtask 3 ---+-- subtask 4 ---+
   v                v                v                v                v
Coder A          Coder B          Coder C          Coder D          (4 parallel)
 (Sonnet)         (Sonnet)         (Sonnet)         (Sonnet)
 worktree A       worktree B       worktree C       worktree D
 Daytona          Daytona          Daytona          Daytona
      |                |                |                |
      +--------+-------+-------+--------+
               v
           merge coordinator  (three-way merge + conflict resolution)
               |
               v
           Reviewer (GPT-5.4)
               |
               v
           Tester  (Gemini 2.5 Pro)  -> passes? -> open PR
                                     -> fails?  -> route back to coder

스택

• 오케스트레이션(Orchestration): 공유 상태와 에이전트별 서브그래프(sub-graph)를 함께 다룰 수 있는 LangGraph를 사용합니다.
• 메시징(Messaging): 에이전트 간 타입드 메시지에는 Google이 2025년에 공개한 A2A 프로토콜을 사용합니다.
• 모델(Models): 아키텍트에는 Opus 4.7, 코더에는 Sonnet 4.7, 리뷰어에는 GPT-5.4, 테스터에는 Gemini 2.5 Pro를 사용합니다.
• 워크트리 격리(Worktree isolation): 코더마다 git worktree add와 Daytona 샌드박스를 함께 사용합니다.
• 머지 코디네이터(Merge coordinator): 직접 구현한 3-way 병합과 LLM 중재 충돌 해결(LLM-mediated conflict resolution)을 사용합니다.
• 평가(Eval): SWE-bench Pro의 50개 이슈, SWE-AF 시나리오(scenario), 단위 테스트용 HumanEval++를 활용합니다.
• 관측성(Observability): 역할 태그(tag)가 붙은 스팬(span)과 에이전트별 토큰 회계(token accounting)를 Langfuse에 남깁니다.
• 배포(Deployment): 각 역할을 별도의 Kubernetes Deployment로 두고, 백로그(backlog)를 기준으로 HPA를 적용합니다.

직접 만들기

1. 태스크 보드(Task board). 타입드 메시지를 저장할 파일 기반 JSONL을 만듭니다. 사용하는 메시지 종류는 plan_request, subtask, diff_ready, review_needed, test_needed, approved, rejected, replan_needed입니다. 각 에이전트는 태그(tag)를 기준으로 구독합니다.

2. 아키텍트(Architect). GitHub 이슈를 읽고 Opus 4.7을 실행합니다. 계획 템플릿(template)은 서브태스크의 인터페이스를 명시적으로 요구하도록 만듭니다. 예를 들어 건드릴 파일 목록, 노출되는 공용 함수(public function), 테스트에 미치는 영향(test impact)을 포함합니다. 아키텍트는 서브태스크 DAG가 담긴 plan_request를 한 건 내보냅니다.

3. 코더(Coders). N명의 병렬 워커(worker)가 보드에서 서브태스크를 하나씩 차지(claim)합니다. 각 워커는 새 git worktree add 브랜치(branch)와 Daytona 샌드박스를 생성한 뒤 서브태스크를 구현합니다. 작업이 끝나면 패치(patch)와 테스트 변경(test delta)이 담긴 diff_ready를 내보냅니다.

4. 머지 코디네이터(Merge coordinator). 모든 코더가 끝나면 N개의 브랜치를 스테이징 브랜치(staging branch)로 3-way 병합합니다. 파일 단위로 겹치는(overlap) 경우에만 LLM 중재 충돌 해결을 사용합니다.

5. 리뷰어(Reviewer). GPT-5.4가 병합된 디프를 검토합니다. 자신이 작성한 디프는 승인할 수 없습니다. 문제가 없으면 approved를 내보내고, 변경이 필요하면 관련 코더에게 라우팅(routing)되는 구체적 요청이 담긴 review_feedback을 내보냅니다.

6. 테스터(Tester). Gemini 2.5 Pro가 깨끗한 샌드박스에서 테스트 스위트를 실행하고, 산출물을 캡처(capture)합니다. 결과는 test_passed로 내보내거나, 스택 트레이스(stacktrace)가 담긴 test_failed로 내보냅니다. 실패한 테스트는 해당 서브태스크를 맡았던 코더에게 되돌아갑니다.

7. 핸드오프 회계(Handoff accounting). 역할 경계를 넘는 모든 메시지는 Langfuse 스팬으로 남기고, 페이로드(payload) 크기와 사용한 모델을 함께 기록합니다. 서브태스크별 토큰 증폭은 (coder_tokens + reviewer_tokens + tester_tokens + architect_share) / coder_tokens 공식으로 계산합니다.

8. 평가(Eval). 50개의 SWE-bench Pro 이슈에서 실행합니다. 단일 에이전트 기준선, 즉 하나의 워크트리에서 Sonnet 4.7 한 개로 처리한 결과와 pass@1, 해결 이슈당 비용을 비교합니다.

9. 사후 분석(Post-mortem). 실패한 이슈마다 어떤 핸드오프가 깨졌는지 식별합니다. 계획이 모호했는지, 병합 충돌이었는지, 리뷰어의 잘못된 승인(false approval)이었는지, 테스터의 플레이키(flaky) 테스트였는지를 기록합니다. 마지막으로 핸드오프 실패 히스토그램(histogram)을 만듭니다.

사용해보기

$ team run --issue https://github.com/acme/widget/issues/842
[architect] plan: 4 subtasks (parser, cache, api, migration)
[board]     dispatched to 4 coders in parallel worktrees
[coder-A]   subtask parser  -> 42 lines, tests pass locally
[coder-B]   subtask cache   -> 88 lines, tests pass locally
[coder-C]   subtask api     -> 31 lines, tests pass locally
[coder-D]   subtask migration -> 19 lines, tests pass locally
[merge]     3-way merge: 0 conflicts
[reviewer]  comments on cache (thread pool sizing); routed to coder-B
[coder-B]   revision: 92 lines; submits
[reviewer]  approved
[tester]    all 412 tests pass
[pr]        opened #3382   4 coders, 1 revision, $4.90, 18m

산출물 만들기

outputs/skill-multi-agent-team.md가 이 캡스톤의 제출 산출물입니다. 이슈 URL과 병렬도(parallelism level)를 입력하면, 팀은 역할별 토큰 회계와 함께 병합 준비가 끝난 PR(merge-ready PR)을 만들어 내야 합니다.

연습문제

1. (쉬움) 실행 중인 디프에 누구나 알아챌 수 있는 버그를 일부러 주입해 봅시다. 예를 들어 본문 앞에 불필요한 return None을 끼워 넣어 봅니다. 리뷰어의 잘못된 승인 비율을 측정하고, 잘못된 승인이 5% 미만이 될 때까지 리뷰어 프롬프트를 조정해 봅니다.

2. (중간) 코더를 두 명으로 줄여 봅시다. 아키텍트 + 코더 + 리뷰어 + 테스터 구조에서 코더가 서브태스크 두 개를 순차적으로 처리하도록 합니다. 실제 경과 시간과 통과율을 단일 코더 N=4 구성과 비교해 봅니다.

3. (중간) 머지 코디네이터를 단일 작성자 제약(single-writer constraint)으로 교체해 봅시다. 서브태스크가 서로 다른 파일 집합만 건드리도록 제한합니다. 이때 아키텍트에게 추가로 얼마나 큰 계획 부담(planning burden)이 생기는지 측정합니다.

4. (중간) 리뷰어를 GPT-5.4에서 Claude Opus 4.7로 교체해 봅시다. 잘못된 승인 비율과 토큰 비용 변화량(token cost delta)을 측정합니다.

5. (어려움) 다섯 번째 역할인 다큐멘터(documenter, Haiku 4.5)를 추가해 봅시다. 리뷰가 끝난 뒤 changelog 항목(entry)을 만들게 합니다. 추가된 문서 품질이 늘어난 토큰 비용을 정당화하는지 평가합니다.

핵심 용어

더 읽을거리

• SWE-AF factory architecture — 2026년 기준 멀티 에이전트 팩토리의 참고 구현입니다.
• MetaGPT — 역할 기반 멀티 에이전트 프레임워크(framework)입니다.
• AutoGen v0.4 — Microsoft의 타입드 액터 프레임워크입니다.
• Cognition AI (Devin) — 참고할 만한 상용 제품 사례입니다.
• Factory Droids — 또 다른 상용 제품 사례입니다.
• Google A2A protocol — 에이전트 간 메시징 사양 문서입니다.
• git worktree documentation — 워크트리 격리의 기반 문서입니다.
• SWE-bench Pro — 평가 대상으로 사용할 벤치마크입니다.