7주차: 멀티에이전트 SDLC 설계

Phase 37주차고급강의일: 2026-04-14

이론 (Theory)

오늘의 학습 목표

개념 관점

전통적 SDLC와 에이전틱 SDLC의 구조적 차이를 4단계 비교표로 설명하고, 단일 에이전트가 막히는 지점을 식별한다.

설계 관점

Lead·Planner·Worker·Reviewer·Operator 역할 분배와 핸드오프 토폴로지(linear / hub-spoke / mesh)를 비교해 우리 팀에 맞는 형태를 결정한다.

구현 관점

artifact 기반 핸드오프 계약(spec.md, plan.md, worker_report.md)을 작성하고 한 사이클을 실행한다.

운영 관점

multi-agent 파이프라인의 quality gate를 통합하고, “어느 역할에서 실패했는가”를 telemetry로 추적할 수 있게 만든다.

왜 7주차에서 멀티에이전트 SDLC인가

6주차까지 우리는 단일 에이전트를 다뤘다 — CLAUDE.md로 행동을 규제하고(6주차), Context Rot을 방지하며(5주차), Ralph Loop로 반복 품질을 확보했다(4주차). 이제 질문은: 단일 에이전트의 한계는 어디인가?

DeepMind과 MIT의 공동 연구 “Towards a Science of Scaling Agent Systems” (2025년 12월)가 결정적 데이터를 제시한다:

비구조적 에이전트 집합(“bag of agents”)은 에러를 17.2배 증폭시킨다. 반면 중앙 집중형 조율(centralized coordination)은 에러 증폭을 4.4배로 감소시킨다.

SWE-Bench Pro에서도 같은 패턴이 나타난다 — 동일한 모델(Claude Opus 4.5)이 스캐폴딩(harness)에 따라 45.9%에서 55.4%까지 점수 차이를 보인다. 모델 자체보다 모델을 감싸는 시스템 설계가 성능을 결정한다.

이번 주에는 멀티에이전트 SDLC의 아키텍처와 설계 원칙을 다룬다. 코드 구현은 Week 8(플래너 에이전트)과 Week 9(QA 에이전트)에서 진행한다.

---

전통적 SDLC → 에이전틱 SDLC

전통적 역할	에이전틱 대응	도구 접근 (MCP)	산출 아티팩트
Product Manager	플래너 에이전트	웹 검색, 문서 읽기	requirement.md
Software Architect	아키텍트 에이전트	저장소 매핑, 의존성 분석	architecture.md, TASK 파일
Developer	코더 에이전트 (Ralph Loop)	파일 수정, 컴파일러, 테스트	코드 변경, PR
QA Engineer	QA 에이전트	pytest, diff viewer, 린터	리뷰 결과, 심각도 보고서
DevOps	배포 에이전트	Docker, CI/CD, 모니터링	배포 결과, 스모크 테스트
Release Manager	완료 에이전트	Git merge, 태깅	ship-summary, 릴리스 노트
Knowledge Manager	회고 에이전트	파일 읽기/쓰기	LESSON 파일, 가정 검증 결과

이 역할 분담은 학계에서도 검증된 패턴이다:

• MetaGPT (ICLR 2024): PM, Architect, Project Manager, Engineer, QA의 5역할을 SOP(Standard Operating Procedure) 기반 구조화 문서로 연결. 역할 간 자연어 대화 대신 구조화된 문서 핸드오프가 핵심이다.
• ChatDev (ACL 2024, v2.0 2026년 1월): chat-based phase execution으로 역할 특화가 monolithic prompting보다 일관되게 우월함을 실증했다.

Claude Code 내부에서는...

아래 파이프라인의 기술적 토대가 Claude Code의 Agent Orchestration 레이어다:

• Agent 도구: 서브에이전트를 별도 프로세스로 스폰. 모델 선택(sonnet/opus/haiku)으로 태스크 복잡도에 맞춰 라우팅
• Worktree 격리: isolation: "worktree" 옵션으로 git worktree에서 실행 — 부모 작업 영역에 영향 없음
• Task Packet: 자연어 대신 구조화된 패킷(objective, scope, acceptance_tests, escalation_policy)으로 에이전트에게 작업 지시
• 독립 컨텍스트: 서브에이전트는 부모 세션의 히스토리에 접근 불가 — 마이크로서비스 간 명시적 계약(API contract)과 같은 원리

→ 상세: 참고자료 > Claude Code 내부 구조

---

멀티에이전트 파이프라인 아키텍처

MULTI-AGENT PIPELINE

Human (HIC)요구사항 입력

↓

Planner Agent

• 요구사항 파싱
• spec.md 생성
• 우선순위 결정

↓spec.md 전달

Initializer Agent

• 코드베이스 분석
• 서브태스크 분해
• init.sh 생성

↓task_queue.json 전달

Coder Agent × N (Ralph Loop)

• 병렬 태스크 실행
• 로컬 테스트 통과 필수

↓PR 생성

QA Agent

• 독립 코드 리뷰
• 통합 테스트 실행
• 회귀 검증

↓승인/거부

Deploy Agent

• 스테이징 배포
• E2E 테스트
• Human 최종 승인 (Hard Interrupt)

↓

프로덕션 배포

에이전트 간 통신의 황금 규칙

에이전트 간 통신은 반드시 구조화된 아티팩트 (Markdown, JSON)를 통해 이루어져야 한다. 에이전트 A가 에이전트 B에게 직접 메시지를 보내는 방식은 비결정성을 극대화한다.

게이트드 파이프라인 — 프로덕션 사례

위의 다이어그램을 실제 프로덕션 시스템으로 구현하면 어떤 모습인가? 아래 다이어그램은 sdlc-toolkit의 전체 파이프라인 — 지식 피드백 루프, 검증 게이트, 교훈 캡처 — 을 시각화한다.

SDLC 파이프라인

지식 피드백 루프가 포함된 스펙(Spec) 기반 개발 수명 주기

1

/spec

교훈 참조

기능 요청을 바탕으로 요구사항 스펙을 작성합니다.

G

/validate

아키텍처 설계 전 스펙의 품질을 검증합니다.

2

/architect

교훈 참조

아키텍처를 설계하고 세부 작업(TASK)으로 분할합니다.

G

/validate

아키텍처 및 작업의 품질을 검증합니다.

3

Implement (구현)

종속성 순서에 따라 작업을 코딩하고 독립적인 작업은 병렬로 처리합니다.

4

/reflect

교훈 참조

구현 완료 후 자체 검토(Self-review)를 진행합니다.

5

/review

품질 및 정확성을 확보하기 위한 다중 에이전트(Multi-agent) 코드 리뷰를 수행합니다.

6

Create & Merge PR

풀 리퀘스트(PR)를 열고 최종 리뷰를 통과한 후 병합합니다.

7

/wrapup

배포 및 아티팩트를 업데이트하고, 개발 중 얻은 교훈과 가정들을 캡처합니다.

배운 교훈 (Lessons Learned)

.sdlc/knowledge/lessons/

모든 기능 개발의 마지막 단계에서 /wrapup을 통해 캡처됩니다. 각 교훈은 무슨 일이 있었는지, 왜 중요한지, 언제 적용되는지 기록합니다.

피드백 루프 (Feedback Loop)

세 가지 핵심 단계에서 작업 수행 전 교훈을 읽어들여 지속적인 개선 주기를 만듭니다:

• ← /spec 이전에 실패했던 접근 방식의 반복을 방지
• ← /architect 검증된 패턴을 재사용하고 과거 실수를 회피
• ← /reflect 현재 작업과 연관된 교훈이 반영되었는지 확인

검증 게이트 (Validation Gates)

주요 단계 사이에 품질 검사가 실행됩니다. 파이프라인 중단 전 최대 3회의 자동 수정 재시도를 수행합니다.

가정 (Assumptions)

.sdlc/knowledge/assumptions/

교훈과 함께 지속적으로 추적됩니다. 아키텍처 설계 결정 시 /architect가 이 내용을 참고합니다.

/proceed REQ-xxx

검증 게이트 및 자동 수정 재시도를 포함하여 위 전체 파이프라인을 자동으로 연속 실행합니다.

/bugfix

경량화 경로 — 빠른 버그 수정을 위해 스펙 및 아키텍처 단계를 건너뛰고 진행합니다.

sdlc-toolkit의 /proceed 파이프라인이 9단계 게이트드 실행을 구현한다.

L8 Workflow Plane 미리보기

이 9단계 게이트드 파이프라인은 Agent OS Runtime의 L8 Workflow Plane 어휘로 보면 “ship-cycle” 한 사례다 — 각 단계가 phase, 검증·승인·재시도 규칙이 policy, 코더/리뷰어/QA가 persona, spec.md·TASK 파일이 artifact다. 예를 들어 리뷰 심각도에 따른 분기는 severity-routing, 3회 재시도 후 인간 에스컬레이션은 loop-halt 정책으로 표현한다. L8 어휘를 알면 캡스톤에서 brainstorm-cycle, fix-cycle, ralph-cycle 같은 다른 파이프라인을 같은 frame으로 설계할 수 있다.

Phase Map

Phase	이름	에이전트	게이트
0	Worktree 생성	오케스트레이터	브랜치 격리 확인
1	Spec 검증	Validator	요구사항 완전성
2	아키텍처 + 태스크 분해	Architect	의존성 DAG 유효성
3	아키텍처 검증	Validator	패턴 호환성, 태스크 커버리지
4	구현 (병렬)	Coder × N	각 태스크 AC 충족
5	검증 (Reflect + Review)	QA	PASS/FAIL 판정
6	PR 생성	오케스트레이터	CI 통과
7	PR 정리 + CI	오케스트레이터	린트/테스트 통과
8	Wrapup (머지, 배포, 지식 캡처)	Wrapup	LESSON 파일 생성

핵심 원칙: 각 phase는 이전 phase의 완료를 명시적으로 확인한 후에만 시작한다. 건너뛰기 불가.

State Machine

{
  "req": "REQ-023",
  "branch": "feat/REQ-023-user-auth",
  "startedAt": "2026-04-14T10:00:00Z",
  "completed": false,
  "currentPhase": 4,
  "completedPhases": [0, 1, 2, 3],
  "phaseHistory": [
    { "phase": 0, "name": "Create Worktree", "completedAt": "2026-04-14T10:01:00Z" },
    { "phase": 1, "name": "Validate Spec", "completedAt": "2026-04-14T10:03:00Z" },
    { "phase": 2, "name": "Architect", "completedAt": "2026-04-14T10:08:00Z" },
    { "phase": 3, "name": "Validate Architecture", "completedAt": "2026-04-14T10:10:00Z" }
  ]
}

pipeline-state.json이 전체 파이프라인의 진행 상태를 추적한다. 중단 시 currentPhase에서 재개. 이 파일 자체가 에이전트 간 핸드오프의 동기화 메커니즘이다.

Error Recovery

각 검증 게이트에서 실패 시:

실패 감지 → 자동 수정 시도 (1회차)
     ↓ 실패
재검증 → 자동 수정 시도 (2회차)
     ↓ 실패
재검증 → 자동 수정 시도 (3회차)
     ↓ 실패
⚠️ 인간 에스컬레이션 — 파이프라인 일시 정지

3회 상한의 근거: 같은 오류를 3번 수정하지 못하면 에이전트가 문제를 이해하지 못하는 것이다. 추가 시도는 토큰만 소비하고 품질은 개선되지 않는다. PwC 연구에서 검증 루프 + judge agent 조합이 정확도를 10%에서 70%로 7배 개선한 것은 이 게이트 메커니즘 덕분이다.

게이트 없는 파이프라인의 위험

Gartner는 2027년까지 에이전트 프로젝트의 40% 이상이 실패할 것으로 전망한다. 주요 원인: 통합 복잡성(46%), 사이버보안(35%), 데이터 프라이버시(30%). 게이트드 파이프라인은 이 세 가지 모두에 대한 구조적 대응이다 — 각 단계에서 검증하고, 실패하면 멈춘다.

Week 8-9 미리보기

이 파이프라인의 Phase 1-3(Planner 영역)을 Week 8에서, Phase 5(QA 영역)를 Week 9에서 직접 Python으로 구현한다. 이번 주에는 전체 구조를 이해하는 것이 목표다.

---

에이전트 조율 토폴로지

멀티에이전트 시스템의 에이전트들은 어떻게 조율되는가? 세 가지 근본 토폴로지가 있다:

토폴로지	구조	사례	에러 증폭
중앙 집중형	단일 오케스트레이터가 순서 제어	sdlc-toolkit /proceed, Claude Code Agent Tool	4.4x (DeepMind)
계층형	오케스트레이터의 오케스트레이터	sdlc-toolkit /sprint (5개 /proceed 병렬 스폰)	4.4x × 관리 오버헤드
분산형 (peer-to-peer)	에이전트끼리 직접 통신	”bag of agents”	17.2x (DeepMind)

분산형의 함정

분산형은 이론적으로 가장 유연하지만, DeepMind+MIT 연구는 실증적으로 에러를 4배 더 증폭시킨다고 확인했다. 이유: 에이전트 A의 작은 오류가 에이전트 B의 입력이 되고, B의 출력에서 오류가 증폭되어 C에게 전달된다. 중앙 조율자가 없으면 이 cascade를 감지할 메커니즘이 없다.

에이전트 간 통신 프로토콜

에이전트가 외부 도구에 접근하는 방법과 에이전트끼리 소통하는 방법은 다른 문제다:

프로토콜	목적	규모	핵심 구조
MCP (Anthropic, 2024)	에이전트 → 도구 접근	97M+ 월간 SDK 다운로드, 6,400+ 서버	Server/Client, Tool/Resource
A2A (Google, 2025)	에이전트 → 에이전트 위임	150+ 파트너 조직	Task, Artifact, Agent Card
아티팩트 핸드오프 (이번 주)	에이전트 → 에이전트 (파일 기반)	프로젝트 로컬	Markdown/JSON 파일

MCP는 Linux Foundation에 기부되어(2025년 12월) 산업 표준으로 자리잡았다. A2A는 Google이 제안한 에이전트 간 위임 프로토콜로, Task/Artifact/Agent Card의 JSON 구조로 에이전트 능력을 선언하고 작업을 위임한다.

이번 주에서 다루는 아티팩트 핸드오프는 가장 단순하면서도 가장 결정론적인 방식이다 — 파일 시스템이 통신 채널이므로 디버깅, 감사, 재현이 모두 가능하다.

---

Claude Code 네이티브 멀티에이전트 — 경량 대안

위의 풀 파이프라인을 직접 구축하기 전에, Claude Code가 내장하는 경량 멀티에이전트 도구를 먼저 이해하자. Boris Cherny가 2026년 2월에 공개한 이 도구들은 파이프라인의 각 단계를 CLI 플래그 하나로 대체한다.

Plan Mode — 내장 플래너 에이전트

# Shift+Tab으로 Plan Mode 진입
# 계획 수립 → 사용자 확인 → 자동 실행

Shift+Tab을 누르면 Claude Code가 코드를 작성하기 전에 계획을 먼저 세운다. 계획이 확정되면 자동으로 구현에 들어간다. Boris: “Claude 1-shots the implementation when the plan is right.”

이것은 위의 플래너 에이전트(Planner Agent)가 하는 일 — 요구사항 파싱, spec.md 생성, 우선순위 결정 — 을 대화형으로 수행하는 것이다. Week 8에서 PlannerAgent를 직접 구현하면 이 과정의 내부 구조를 이해할 수 있다.

Custom Agents — 선언적 역할 특화

.claude/agents/ 디렉토리에 Markdown 파일을 추가하면 전문화된 에이전트를 정의할 수 있다:

code-simplifier.md

---
name: code-simplifier
description: 코드 단순화 전문 에이전트
tools: [Read, Edit, Grep, Glob]
---

변경된 코드를 검토하여:
1. 재사용 가능한 기존 함수가 있으면 활용
2. 불필요한 복잡성 제거
3. 일관된 패턴 적용

verify-app.md

---
name: verify-app
description: 애플리케이션 검증 에이전트
tools: [Read, Bash, Grep]
---

변경사항을 검증하여:
1. 모든 테스트 통과 확인
2. 빌드 성공 확인
3. 린트 에러 없음 확인

사용법

# 특정 에이전트로 실행
claude --agent code-simplifier "이 모듈 리팩터링"

# settings.json에서 기본 에이전트 지정
# { "defaultAgent": "code-simplifier" }

이것은 위의 역할 분담 설계 — 코더 에이전트, QA 에이전트 — 를 .md 파일 하나로 선언적으로 구현하는 방식이다. MCP를 통한 도구 접근 권한 관리와 동일한 원리가 tools 필드에 적용된다. sdlc-toolkit의 11개 스킬(/spec, /architect, /validate, /review 등)은 이 Skills 시스템을 활용한 프로덕션 사례다.

/simplify — 내장 QA 에이전트

# 코드 변경 후 자동 리뷰
claude /simplify

병렬 에이전트가 변경된 코드를 재사용성(reuse), 품질(quality), 효율성(efficiency) 세 관점에서 동시에 리뷰한다. Boris: “코드 리뷰 첫 5분에서 시니어 엔지니어가 잡을 수준의 구조적 이슈를 자동 포착한다.”

/simplify의 한계

도메인 특화 이슈 — API 계약 준수, DB 읽기 복제본 라우팅, 비즈니스 로직 정합성 — 는 잡지 못한다. /simplify는 코드 리뷰를 대체하는 것이 아니라, 리뷰의 시작점을 높이는 도구다.

/batch — 대규모 병렬 실행 엔진

# 대화형 계획 → 병렬 실행
claude /batch "src/ 디렉토리의 로깅을 새 구조화 로거로 마이그레이션"

/batch는 세 단계로 동작한다:

1. 대화형 계획: 사용자와 대화하며 태스크를 분해한다
2. 병렬 실행: 각 서브태스크를 독립 worktree에서 병렬로 실행한다
3. PR 생성: 각 에이전트가 테스트 통과 후 개별 PR을 올린다

Boris 팀 사례: 14개 파일의 로깅 마이그레이션에 6개 병렬 에이전트를 투입. 총 11분, 6개 중 5개 무수정 merge. 나머지 1개는 조건부 로깅의 엣지 케이스로 인간 판단이 필요했다.

이것이 위의 멀티에이전트 파이프라인과 같은 원리 — Planner → Coder × N → QA — 가 제품 수준으로 패키징된 것이다.

Skills 시스템 — 패키징된 인스트럭션 튜닝

# 스킬 설치 (예시 — 실제 URL은 스킬 배포처에서 확인)
mkdir -p ~/.claude/skills/boris
curl -L -o ~/.claude/skills/boris/SKILL.md \
  https://example.com/skills/boris/SKILL.md

# 또는 직접 SKILL.md 파일을 작성하여 배치
# 세션에서 스킬 로드
claude /skills boris

6주차에서 배운 인스트럭션 튜닝(PROMPT.md에 제약 추가)을 재사용 가능한 패키지로 확장한 것이다. Boris 자신의 42개 팁이 하나의 skill로 패키징되어 어떤 프로젝트에서든 로드할 수 있다.

풀 파이프라인 vs 네이티브 도구 — 언제 무엇을 쓰는가

항목	풀 파이프라인 (Week 7-9)	네이티브 도구 (Boris)
설정 비용	높음 — JSON 스키마, 에이전트 코드 구현	낮음 — .md 파일, CLI 플래그
유연성	무한 — 커스텀 핸드오프 로직, 피드백 루프	제한적 — 프리셋 기능 내에서만
에이전트 간 통신	아티팩트 기반 (JSON 스키마로 계약)	없음 — 각 에이전트가 독립 실행
검증	QA 에이전트가 통합 테스트 + 코드 리뷰	/simplify가 구조적 이슈만 포착
에러 복구	게이트드 재시도 (3회) + 인간 에스컬레이션	없음 — 실패 시 수동 재시작
적합 상황	복잡한 다단계 워크플로우, 커스텀 품질 기준	반복적 단일 태스크의 대규모 병렬 처리

둘 다 배워야 하는 이유

Boris는 단순한 마이그레이션에 /batch를, 복잡한 기능 개발에 커스텀 파이프라인을 사용한다. 네이티브 도구의 한계를 이해해야 풀 파이프라인이 왜 필요한지 체감할 수 있다. 이번 주에 네이티브 도구를 경험한 뒤, Week 8-9에서 풀 파이프라인을 직접 구축한다.

---

아티팩트 기반 핸드오프 설계

에이전트 간 통신의 핵심은 구조화된 아티팩트다. 자연어 메시지가 아니라, 스키마가 정의된 파일이 에이전트 사이를 이동한다.

Canonical Runtime Contract

이번 주의 handoff 기본형은 Agent OS Runtime의 Lead → Planner → Worker → Reviewer 흐름이다. Lead는 lead_directive_v1, Planner는 plan_v1, Worker는 worker_report_v1, Reviewer는 review_result_v1을 출력한다. 전체 계약과 role prompt는 Agent OS Contracts에 self-contained로 정리되어 있다.

Requirement Spec

---
id: REQ-023
title: "사용자 인증 기능 추가"
status: draft          # draft → approved → in-progress → complete
deployable: true
created: 2026-04-14
updated: 2026-04-14
---

## Description
JWT 기반 사용자 인증 시스템 구현. 로그인, 회원가입, 토큰 갱신 포함.

## Acceptance Criteria
- [ ] POST /auth/login 엔드포인트 동작
- [ ] JWT 토큰 발급 및 검증
- [ ] 비밀번호 bcrypt 해싱
- [ ] 토큰 만료 시 자동 갱신

## Assumptions
- PostgreSQL 사용 (기존 DB 연결 활용)
- 토큰 유효기간: access 15분, refresh 7일

## Out of Scope
- OAuth2 소셜 로그인 (별도 REQ)
- 2FA (별도 REQ)

Planner Agent가 생성 → Validator가 검증 → Architect Agent가 소비

Task + Dependencies

---
id: TASK-001
title: "JWT 토큰 생성 모듈"
status: draft
parent: REQ-023
created: 2026-04-14
updated: 2026-04-14
dependencies: []           # Tier 0: 의존성 없음 → 병렬 실행 가능
---

## Files to Create/Modify
- `auth/jwt.py` — 토큰 생성/검증 유틸리티
- `tests/test_jwt.py` — 단위 테스트

## Acceptance Criteria
- [ ] create_token(payload, secret) → JWT 문자열
- [ ] verify_token(token, secret) → payload 또는 예외
- [ ] 만료된 토큰 검증 시 TokenExpiredError

---
id: TASK-003
title: "로그인 API 엔드포인트"
status: draft
parent: REQ-023
dependencies: ["TASK-001", "TASK-002"]  # Tier 1: TASK-001, 002 완료 대기
---

Architect Agent가 생성 → dependencies 배열이 실행 순서를 결정

Knowledge Artifact

---
id: LESSON-042
title: "JWT 시크릿 로테이션 시 기존 토큰 무효화"
domain: "API"              # 넓은 영역
component: "API/auth"      # 좁은 영역
tags: [security, jwt]
req: REQ-023
created: 2026-04-14
---

## What Happened
시크릿 키를 로테이션했더니 기존 발급 토큰이 모두 무효화됨.

## Lesson
시크릿 로테이션 시 이전 키로 발급된 토큰도 유예 기간 동안 검증할 수 있도록
다중 키 검증 로직을 구현해야 한다.

## Applies When
JWT 시크릿 관리, 키 로테이션, 인증 시스템 변경

Wrapup Agent가 생성 → 미래 /spec과 /architect가 domain:API + component:API/auth로 grep하여 이 교훈을 자동 참조

의존성 DAG와 병렬화 전략

TASK 파일의 dependencies 배열이 실행 순서를 결정한다:

Tier 0 (의존성 없음):  TASK-001, TASK-002  → 동시 실행
         ↓ 완료 대기
Tier 1 (Tier 0 의존):  TASK-003, TASK-004  → 동시 실행
         ↓ 완료 대기
Tier 2 (Tier 1 의존):  TASK-005            → 단독 실행

이 tier 기반 병렬화가 파이프라인의 Phase 4(구현)에서 작동한다. 독립적인 태스크는 각각 별도 worktree에서 병렬 실행되고, 의존성이 있는 태스크는 선행 태스크 완료를 기다린다.

지식 관리 피드백 루프

LESSON 파일의 domain과 component 필드가 조직의 기억을 구현한다. 미래에 인증 관련 요구사항이 들어오면, Planner Agent가 domain:API + component:API/auth로 기존 교훈을 자동 검색하여 같은 실수를 반복하지 않는다. 이것이 에이전틱 SDLC가 반복할수록 나아지는 메커니즘이다.

아티팩트 직렬화 포맷 선택

에이전트 간 아티팩트를 JSON으로 설계할 때, compact JSON(공백/줄바꿈 제거)을 기본으로 사용하라. Week 5에서 다룬 것처럼 pretty-print JSON 대비 25-40% 토큰을 절약할 수 있다. 대규모 균일 배열(100+ rows)이 아티팩트에 포함되면 CSV나 TOON 같은 테이블 포맷을 검토하되, 토큰 효율과 정확도의 트레이드오프를 반드시 측정하라.

---

멀티에이전트 코드 리뷰 설계

단일 리뷰어는 편향이 있다 — 보안에 강한 리뷰어는 성능 이슈를 놓치고, 아키텍처에 집중하면 엣지 케이스를 간과한다. 프로덕션 시스템은 3명의 전문 리뷰어를 병렬로 실행한다:

리뷰어	검토 영역	심각도 기준
정확성 리뷰어	논리 오류, 레이스 컨디션, 보안 취약점, 엣지 케이스	Critical: 데이터 손실/보안 위반
품질 리뷰어	네이밍, 패턴 일관성, 중복 코드, 설정 하드코딩	Major: 유지보수성 저하
아키텍처 리뷰어	레이어 분리, 관심사 분리, 테스트 커버리지, API 준수	Major: 구조적 부채

심각도 체계: Critical > Major > Minor > Nit. Critical이 하나라도 있으면 FAIL — 자동으로 코더에게 피드백이 전달된다.

이 3-병렬 리뷰 패턴 위에 2단계 구조가 있다:

1. /reflect (자기 리뷰): 코더 에이전트가 자신의 코드를 먼저 리뷰. 명백한 실수를 스스로 잡아서 독립 리뷰의 부담을 줄인다.
2. /review (독립 리뷰): 코더의 reasoning을 전혀 모르는 상태에서 3명이 병렬 리뷰.

Boris의 /simplify는 이 패턴의 경량 버전이다 — 동일한 병렬 리뷰 원리지만, 도메인 특화 없이 구조적 이슈만 포착한다. Week 9에서 이 설계를 Python으로 구현한다.

PwC의 실증 데이터

PwC는 독립적인 judge agent를 추가하는 것만으로 에이전트 시스템의 정확도가 10%에서 70%로 7배 개선되었다고 보고했다. 리뷰어의 수가 아니라 독립성이 핵심이다 — 같은 컨텍스트를 공유하는 리뷰어 3명은 독립 리뷰어 1명보다 못하다.

---

실패 모드와 위험 관리

멀티에이전트 시스템은 단일 에이전트에 없는 고유한 실패 모드를 가진다:

실패 모드	설명	완화 전략
Context Rot 전파	핸드오프마다 맥락 손실 (Week 5 참조)	아티팩트 기반 핸드오프 — 구조화된 파일이 맥락을 보존
17x 에러 트랩	비구조적 에이전트 네트워크의 조용한 에러 복합	중앙 집중형 조율 + 게이트드 검증
환각 전파	한 에이전트의 환각이 다음 에이전트의 ground truth	각 phase의 독립 검증 게이트
무한 정제 루프	QA→Coder→QA가 수렴 없이 반복	반복 상한 (3회) + 인간 에스컬레이션
상태 비동기화	병렬 에이전트 간 파일 충돌	Git worktree 격리 — 각 에이전트 독립 작업 공간
비용 급증	통제 없는 에이전트 스폰	동시 실행 상한 (5개) + 모델 티어 라우팅 (탐색: haiku, 구현: sonnet, 리뷰: opus)

가장 위험한 실패 모드

환각 전파가 가장 탐지하기 어렵다. Planner가 존재하지 않는 API를 spec에 명시하면, Architect는 이를 사실로 받아들여 태스크를 분해하고, Coder는 해당 API를 호출하는 코드를 작성한다. 각 에이전트는 자신의 단계 기준으로는 정상 동작했지만 결과물은 잘못된다. 이것이 각 phase에 독립 검증 게이트가 필요한 근본 이유다.

---

강의 중 토론 질문

1. DeepMind 연구에서 “bag of agents”가 에러를 17.2배 증폭시키는 메커니즘을 설명하라. 구조화된 조율이 4.4배로 줄이는 이유는 무엇인가?

2. SWE-Bench Pro에서 동일 모델이 스캐폴딩에 따라 45.9%–55.4% 점수 차이를 보인다. “하네스가 모델만큼 중요하다”는 주장을 이 데이터로 논증하라.

3. 에이전트 간 자연어 메시지 전달과 구조화된 아티팩트(JSON/Markdown) 핸드오프의 장단점은? 어떤 상황에서 어느 쪽이 우월한가?

4. /proceed 파이프라인에서 각 게이트마다 최대 3회 재시도 후 인간에게 에스컬레이션하는 설계의 근거는? 재시도 횟수를 10회로 늘리면 어떤 문제가 발생하는가?

5. Week 6의 단일 에이전트 인스트럭션 튜닝(CLAUDE.md)을 멀티에이전트에 적용할 때, 공통 규칙과 역할별 규칙을 어떻게 분리 설계할 것인가? sdlc-toolkit의 conventions.md(공통)와 각 SKILL.md(역할별) 구조를 참고하라.

---

실습 (Practicum)

오늘 실습의 목표

멀티에이전트 파이프라인의 설계 문서를 완성한다. 코드 구현은 Week 8(Planner)과 Week 9(QA)에서 진행한다.

1. 역할 분담 설계

   프로젝트 명세를 받아 5개 에이전트(Planner, Architect, Coder, QA, Wrapup)의 역할, 책임, MCP 도구 접근 권한을 설계한다.

2. 아티팩트 스키마 정의

   에이전트 간 전달되는 모든 아티팩트의 스키마를 정의한다. 최소 3종: requirement spec, task file (with dependency array), pipeline state.

3. 의존성 DAG 설계

   주어진 요구사항을 TASK 파일로 분해하고, 의존성 그래프를 그려 병렬 실행 가능한 tier를 식별한다.

4. 검증 게이트 설계

   각 phase transition에서 검증할 체크리스트를 정의한다. 위의 /validate 체크리스트를 참고하여 프로젝트에 맞게 커스터마이즈한다.

5. 에러 복구 시나리오

   3가지 실패 시나리오(테스트 실패, 검증 3회 초과, 머지 충돌)에 대한 복구 전략을 문서화한다.

과제 (Assignment)

Lab 07: 멀티에이전트 파이프라인 설계

제출 마감: 2026-04-21 23:59

요구사항:

1. 5단계 멀티에이전트 아키텍처 다이어그램 (역할, 아티팩트, 게이트 포함)
2. 에이전트 간 아티팩트 JSON 스키마 정의 (최소 3종)
3. 의존성 DAG 설계 및 병렬화 tier 분석
4. 검증 게이트 체크리스트 (phase별)
5. 에러 복구 전략 문서 (3개 시나리오)

---

핵심 정리

1. 멀티에이전트 SDLC = 역할 분리 + 구조화된 핸드오프 + 게이트드 검증: 단순히 에이전트를 여러 개 실행하는 것이 아니라, 각 에이전트에 명확한 역할과 아티팩트 계약을 부여하는 것이 핵심
2. Bag of agents는 해롭다: DeepMind 연구 — 비구조적 에이전트 집합은 에러를 17.2배 증폭. 중앙 조율이 4.4배로 감소
3. 하네스가 모델만큼 중요하다: SWE-Bench Pro에서 동일 모델이 스캐폴딩에 따라 10%p 성능 차이
4. 아티팩트가 메시지를 대체한다: 에이전트 간 직접 메시지 대신 구조화된 파일(requirement.md, TASK-xxx.md, pipeline-state.json)로 핸드오프
5. 게이트드 파이프라인: 각 phase transition에 검증 게이트. 최대 3회 재시도 후 인간 에스컬레이션
6. 병렬화는 의존성 DAG로 제어: Tier 0(의존성 없음) 병렬 실행, Tier N(Tier N-1 완료 대기) 순차 진행
7. 지식 관리가 피드백 루프를 완성: LESSON 파일의 domain/component 태그로 미래 스펙과 아키텍처에 과거 교훈을 자동 주입

더 읽을거리

• Towards a Science of Scaling Agent Systems — DeepMind + MIT (2025) — 비구조적 에이전트 집합의 에러 증폭(17.2x)과 중앙 조율의 효과(4.4x)를 실증한 연구
• MetaGPT: Meta Programming for Multi-Agent Collaborative Framework (ICLR 2024) — 5역할 SOP 기반 멀티에이전트 프레임워크. 구조화된 문서 핸드오프의 원형
• ChatDev: Communicative Agents for Software Development (ACL 2024) — chat-based phase execution으로 역할 특화의 우월성을 실증
• A2A Protocol Specification — Google (2025) — Agent-to-Agent 통신 표준. Task/Artifact/Agent Card 구조
• Model Context Protocol — Anthropic — 97M+ 월간 SDK 다운로드. 에이전트 → 도구 접근의 산업 표준
• SWE-Bench Pro — 에이전트 코딩 벤치마크. 동일 모델의 스캐폴딩별 성능 차이를 정량적으로 측정