지정해 주신 작성 원칙, 규칙 및 템플릿 구조를 엄격히 준수하여 ‘멀티 에이전트 6단계 검증 프레임워크’ 위키 노트를 성공적으로 작성했습니다.
작성된 위키 노트의 상세 내용 및 구조는 아래와 같습니다.
[작성된 위키 노트]
---
type: workflow
status: draft
core: false
tags:
- llm
- agent
- multi-agent
- code-agent
- verification
aliases:
- 6단계 협업 프레임워크
- otonashi-labs 6단계 프레임워크
sources:
- 'raw/Andrej Karpathy가 AI 코딩 에이전트의 고질병을 고치는 방법. 마크다운 파일 하나.md'
created: '2026-08-28'
updated: '2026-08-28'
---
# 멀티 에이전트 6단계 검증 프레임워크
## 한 줄 정의
단일 LLM의 편향과 조용한 가정을 방지하기 위해 탐색, 인간 승인, 구현, 적대적 검증 등 6개의 특화 에이전트/승인 단계를 분리하여 실행 및 검증 루프를 완성하는 AI 코딩 파이프라인.
## 핵심 요지
- **편향 분리 원칙**: 코드를 작성한 에이전트는 작성 시점의 맥락적 편향과 조용한 가정을 그대로 공유하므로 자기 코드의 오류나 맹점을 검증하기에 적합하지 않다.
- **역할 및 단계의 명확한 격리**: 시스템 탐색 및 상태 전이 매핑(Exploratory Agent) $\rightarrow$ 인간의 계획 검토 및 승인 $\rightarrow$ 구현(Implementation Agent) $\rightarrow$ 독립 검증(Validation Agent)으로 작업을 분할한다.
- **가정 심문(Assumption Interrogation)**: 최종 검증 단계의 Validator는 Builder(구현 에이전트)의 편향을 공유하지 않은 상태에서 구현 결과물이 세운 암묵적 가정을 역으로 심문하고 테스트한다.
- **Karpathy 4원칙의 확장**: `forrestchang/andrej-karpathy-skills` 이슈 #11(otonashi-labs 공유)에서 제시된 모델로, [[AI 에이전트 행동 제약 4원칙]]을 다중 에이전트 협업 체계로 고도화한 형태다.
## 상세
AI 코딩 에이전트(예: [[Claude Code]])가 단일 세션에서 코드 읽기, 계획 수립, 파일 수정, 자율 검증을 모두 도맡을 경우, 모델 특유의 '조용한 가정(Silent Assumptions)'과 과잉 신뢰가 작용하여 문제점이 저장소 전체로 연쇄 전파된다.
멀티 에이전트 6단계 검증 프레임워크는 이러한 단일 에이전트 루프의 한계를 극복하기 위해 **"코드를 쓴 에이전트는 그 코드가 맞는지 판단하기에 가장 나쁜 심판이다"**라는 핵심 통찰에 기반한다.
### 파이프라인 6단계 구조
1. **시스템 탐색 및 분석 (Exploratory Phase)**
- 탐색 전용 에이전트가 코드베이스 구조, 의존성 관계, 도메인 상태 전이(state transition)를 분석하고 경계 조건을 파악한다.
2. **계획 및 가시화 (Plan Generation)**
- 문제 해결 전략과 명확한 검증 기준(Goal-Driven criteria)을 담은 단기 실행 계획안을 작성한다.
3. **인간 리뷰 및 승인 (Human Review)**
- 개발자가 에이전트가 제시한 방향성과 가정 목록을 확인하고 최종 승인한다.
4. **목표 기반 코드 구현 (Implementation / Building)**
- 구현 에이전트(Builder Agent)가 최소한의 코드 수정과 정밀 변경([[Surgical Changes]]) 원칙에 맞춰 기능 구현을 수행한다.
5. **독립적 적대적 검증 (Adversarial Validation)**
- Builder의 콘텍스트나 편향을 공유하지 않는 별도의 검증 에이전트(Validation Agent)가 구현물과 기재된 가정을 심문하고 역발상 오해 검증 및 엣지 케이스 테스트를 집행한다.
6. **최종 통합 및 승인 (Final Integration)**
- 검증 통과 결과물만을 기존 테스트 수트와 통합하여 커밋 및 PR을 완성한다.
이 체계는 오토나시 랩스(otonashi-labs)가 `forrestchang/andrej-karpathy-skills` 레포지토리의 Issue #11에서 발의하면서 주목받았다 (raw/Andrej Karpathy가 AI 코딩 에이전트의 고질병을 고치는 방법. 마크다운 파일 하나.md).
## 예시
### Python 기반 멀티 에이전트 파이프라인 태스크 정의 예시
```python
from typing import TypedDict, List
from dataclasses import dataclass
@dataclass
class PlanStep:
step_id: int
description: str
verification_criteria: str
class AgentState(TypedDict):
task_prompt: str
architecture_map: dict
plan: List[PlanStep]
human_approved: bool
implemented_diff: str
validation_passed: bool
validation_feedback: str
def run_exploratory_agent(state: AgentState) -> AgentState:
"""1~2단계: 코드베이스 탐색 및 검증 가능한 계획 생성"""
# 탐색 에이전트가 상태 전이를 매핑하고 검증 조건 생성
state["plan"] = [
PlanStep(1, "Fix order status bug in DB transaction", "Run pytest tests/test_orders.py -k test_status_rollback")
]
return state
def run_validation_agent(state: AgentState) -> AgentState:
"""5단계: 독립된 검증 에이전트가 Builder의 가정을 역심문"""
# Builder와 독립된 컨텍스트 프롬프트 적용 (Claude 3.7 Sonnet 등 활용)
# Builder가 수정한 git diff 및 가정을 심문
diff = state["implemented_diff"]
# 별도 테스트 수트 실행 및 엣지케이스 심문 수행
state["validation_passed"] = True
return state활용 시나리오
- 결제/금융 로직 리팩터링: 단일 에이전트가 임의로 백엔드 트랜잭션 에러 처리를 생략하는 결함을 막기 위해, Validation Agent가 무작위 네트워크 지연 및 DB 롤백 시나리오를 주입해 가정을 검증함.
- 엔터프라이즈 레포지토리 오버홀: 사전에 정의된
CLAUDE.md규칙을 준수하면서, Exploratory Agent가 기존 아키텍처 및 AGENTS.md 문서를 파악한 후 인간 리뷰를 거쳐 안전하게 구현을 분할 집행함.
충돌
본 문서 내용 중 직접적인 충돌 요소는 보고되지 않았다. 단, 실행 인프라 측면에서 단일 에이전트 방식 대비 약 3~5배의 LLM API 토큰 비용 및 실행 시간 오버헤드가 발생하므로 단순 스크립트 작성 작업에는 단일 에이전트 원칙(AI 에이전트 행동 제약 4원칙)을 적용하고, 대규모 복합 리팩터링 시에 본 6단계 프레임워크를 사용하는 적응형 적용 전략이 요구된다.