Advisor–Worker 패턴 — 판단·구현 분리 위임¶

정의¶

에이전트 협업에서 판단(무엇을·왜)과 구현(어떻게)을 서로 다른 에이전트에 맡기고, 그 경계를 지시문이 아니라 도구 권한으로 강제하는 2-역할 패턴입니다. 판단 역할(Advisor)이 작업을 분해해 지시서(브리프)로 위임하고, 실행 역할(Worker)의 결과를 독립적으로 재검증한 뒤에만 승인합니다.

건설 감리에 비유하면: 감리자는 도면을 읽고 시공 지시서를 쓰고 시공 결과를 검측한 뒤 준공 도장을 찍습니다. 흙손은 들지 않습니다. 시공팀은 지시서대로 시공하고 결과를 정직하게 보고하되, 준공 판정은 하지 않습니다.

왜 필요한가 — 부탁은 새고, 구조는 샐 수 없다¶

역할 분리를 지시문("너는 검증만 해")으로만 하면 반드시 샙니다. 긴 세션에서 모델은 결국 직접 고치기 시작하고, 검증자가 구현자를 겸하는 순간 concept-loop-engineering이 경고하는 메아리방(자기 출력에 자기가 동의)이 됩니다. 이 패턴의 답은 concept-harness-engineering의 원칙 그대로, 경계를 물리적으로 만드는 것입니다.

여기에 두 가지 실익이 따라옵니다:

실익	메커니즘
컨텍스트 위생	구현 시행착오(파일 탐색·컴파일 에러·재시도)가 Worker의 컨텍스트에서 소모되고, Advisor에는 브리프와 결과 보고만 남음 — concept-multi-agent-pattern의 "컨텍스트 방화벽"
검증 독립성	구현하지 않은 주체가 검증하므로 "내가 짰으니 맞겠지" 편향이 구조적으로 차단됨

구성 요소 4가지¶

패턴은 네 개의 장치로 이루어집니다. 하나라도 빠지면 경계가 샙니다.

1. 도구 권한으로 역할 고정¶

각 역할이 "하면 안 되는 일"을 에이전트 정의 frontmatter의 tools 목록에서 빼는 방식으로 막습니다:

역할	없는 도구	막히는 행동
Advisor	`Write`	파일 생성 = 구현 노동 (사소한 마무리용 `Edit`만 허용)
Worker	`Task`	재위임 — 위임 사슬이 한 단으로 고정됨
Worker	(`git commit` 금지 규율)	승인 없는 저장소 반영

"부탁 대신 구조"의 전형입니다. Advisor에게 "구현하지 마"라고 말하는 대신 Write를 주지 않습니다.

2. 브리프 — 위임 인터페이스¶

위임의 품질은 지시서가 결정합니다. 핵심 설계 원칙은 위임받는 쪽이 재탐색하지 않게 하는 것 — Advisor가 이미 파악한 컨텍스트를 브리프에 담아 넘기면, Worker가 같은 파일을 다시 뒤지는 토큰·시간이 사라집니다. 6항목 골격([목표]·[컨텍스트]·[컨벤션]·[함정]·[완료 기준]·[범위 경계])은 src-ai-advisor-worker 참조.

여섯 항목 중 둘이 특히 구조적입니다:

[완료 기준] — 통과해야 할 테스트/명령어. "끝"의 정의를 실행 가능한 검증으로 바꿔, 최종 목표에서 역산하는 설계와 검증 게이트의 기준선을 겸합니다.
[범위 경계] — 건드리지 말 것. Worker의 "겸사겸사 리팩터링"을 막는 명시적 울타리입니다.

3. 검증 게이트 — 독립 재실행¶

실행 주체의 자기 보고는 검증 대상이지 승인 근거가 아닙니다. Advisor는 Worker가 "완료"를 보고해도 ① diff를 직접 읽고 ② 완료 기준 테스트를 자기 손으로 재실행합니다. Worker가 이미 실행했다는 사실은 면제 사유가 아닙니다 — 검증의 가치는 실행 여부가 아니라 주체의 독립성에서 나오기 때문입니다.

검증 실패의 처리도 패턴의 일부입니다: 직접 고치지 않고 무엇이 왜 실패했는지 담은 수정 브리프로 재위임합니다. 직접 고치기 시작하면 Advisor가 구현자를 겸하게 되어 다음 검증부터 독립성이 무너집니다.

4. 승인 권한의 한쪽 배치¶

되돌리기 어려운 결정(git commit)은 검증자 쪽에만 둡니다. Worker는 작업 트리만 변경한 채 두므로, 게이트를 통과하지 않은 변경이 저장소에 들어갈 경로 자체가 없습니다.

모델 티어링 — 역할별 이종 모델¶

판단과 구현은 요구 능력이 다르므로 모델도 다르게 배치할 수 있습니다. 원본 스크립트는 Advisor에 최상위 모델(Fable 5), Worker에 구현 모델(Opus 4.8)을 frontmatter model:로 고정합니다.

역할	모델 티어	근거
판단 (분해·설계·검증)	최상위	오판 1건의 비용이 큼 — 잘못된 분해·통과시킨 결함은 하류 전체를 오염
구현 (브리프대로 코딩)	한 단계 아래	브리프가 좁혀 준 문제를 푸는 일 — 호출 횟수가 많아 단가 민감

호출량이 많은 쪽에 저렴한 모델을 두는 구조라 src-copilot-token-pricing의 종량제 환경에서 비용 레버이기도 합니다. 단 환경변수(CLAUDE_CODE_SUBAGENT_MODEL)가 frontmatter 지정을 덮어쓰는 함정이 있습니다 — 상세는 src-ai-advisor-worker.

적용 기준 — 언제 쓰고, 언제 안 쓰나¶

위임에는 브리프 작성이라는 고정 비용이 있습니다. 패턴 자체가 예외 규정을 내장합니다:

상황	처리
구현·테스트 작성 등 노동량 있는 작업	Worker에 위임 (기본값)
서로 독립인 작업 여러 개	한 턴에 여러 Task로 병렬 위임, 의존 관계가 있으면 순차
오타·임포트 누락 같은 사소한 마무리	Advisor가 직접 Edit
한두 줄 수정 — 브리프 쓰는 게 더 비싼 일	Advisor가 직접 처리 (위임 오버헤드 역전)

단발 질문·소규모 수정이 주된 세션이라면 패턴 전체가 과합니다. 위임 사슬의 가치는 검증할 가치가 있는 규모의 구현이 반복될 때 나옵니다.

같은 인사이트 패턴 — 검증 주체의 독립성¶

"실행 주체와 검증 주체를 분리한다"는 원리는 위키 전반에 반복됩니다:

영역	실행 주체	독립 검증 주체	참조
Advisor–Worker	Worker (구현)	Advisor의 diff·테스트 재실행 (이 페이지)	src-ai-advisor-worker
3-tier 멀티 에이전트	Coder	Critic의 APPROVE / CONDITIONAL REJECT	concept-multi-agent-pattern
AI 루프	에이전트 (자기 보고)	테스트·타입체크의 exit code	concept-loop-engineering
Hooks	에이전트의 도구 호출	guard.sh의 결정적 차단	concept-claude-hooks
모델 교차 검증	Claude (구현)	Codex (리뷰) — 다른 모델이 검증	concept-multi-agent-pattern

→ 공통 원리: 검증이 실행 주체 안에 있으면 통과 편향이 생깁니다. 밖에 있어야 거부가 가능하고, 거부가 가능해야 신호입니다.

도입 체크리스트¶

역할의 금지 사항이 지시문이 아니라 도구 목록으로 표현돼 있는가?
브리프에 완료 기준이 실행 가능한 명령으로 들어 있는가?
검증자가 실행자의 보고를 재실행으로 확인하는가?
검증 실패 시 직접 수정이 아니라 수정 브리프 재위임으로 처리하는가?
커밋 권한이 검증자 쪽에만 있는가?
위임 오버헤드가 더 큰 사소한 작업의 예외 규정이 있는가?

원본 출처¶

raw/ai-engineering/ai-advisor/advisor_script.md · raw/ai-engineering/ai-advisor/worker_script.md — 역할 정의 원문
raw/ai-engineering/ai-advisor/claude_script.md — 프로젝트 CLAUDE.md 템플릿 (팀 규율 버전)