서론

Claude Fable 5의 프롬프트 가이드를 읽어보면 반복적으로 등장하는 주장이 있습니다. 구세대 모델을 위해 세세하게 작성한 지시는 Fable 5에게 오히려 규정적(prescriptive)이어서 출력 품질을 떨어뜨릴 수 있으니, 삭제를 검토하라는 것입니다. 요컨대 "똑똑해진 만큼, 사용자의 관리(management)를 뺄셈하라"는 뜻입니다.

읽으면서 저는 반대로 생각했습니다. 뺄셈을 통해 상위 모델이 발전한다면, 덧셈을 통해 현재 가진 모델을 어디까지 상위 모델에 근접시킬 수 있을까? 토큰은 대량으로 사용해도 좋고, 시간도 어느 정도 들여도 좋다. 대신 품질로 격차를 줄이겠다. 그러한 전제하에 Opus 4.8용 하네스(harness)를 구성하여 한동안 운용해 보았습니다.

이 기사에서는 그 하네스 세트(fable-emu라고 부릅니다)를 설계 방식부터, 도중에 발견된 설계상의 결함, 그리고 솔직한 한계까지 포함하여 작성합니다. Claude Code의 네이티브 기능(CLAUDE.md, 서브 에이전트, 슬래시 커맨드)만으로 동작하며, 추가 인프라는 필요하지 않습니다. 파일은 전문을 기사 내에 실었으므로, 복사하면 그대로 테스트할 수 있습니다.

결론

• 옮길 수 있는 것: 분해, 독립 검증, 진척의 근거, 장기적 일관성, 세션 간의 학습. 이것들은 가중치(weight)가 아니라 하네스 설계에서 유래하는 동작이므로, 공정(process)으로서 강제하면 현재 가진 모델로도 재현할 수 있다.
• 옮길 수 없는 것: 단일 패스(single-pass)의 정답률과 분해할 수 없는 종류의 통찰. 프롬프트는 모델을 가중치가 허용하는 수준 이상으로 똑똑하게 만들지 못한다.
• 소요되는 토큰: 검증 루프 사용 시 일반 실행의 1.5~3배, 중요 판단의 다안 비교 시 약 4배. 이를 능력을 얻기 위한 비용으로 지불한다.

무엇을 옮길 수 있고, 무엇을 옮길 수 없는가

Fable 5의 우위는 두 개의 층으로 나누어 생각할 수 있습니다.

층	내용	프롬프트로 옮길 수 있는가
가중치 유래	단일 패스의 정답률, 깊은 모호성의 자기 해결, 밀도 높은 기술 이미지 해석	불가
하네스 유래	장시간의 일관성, 진척의 근거, 경계 준수, 서브 에이전트 협업	가능

따라서 전략은 하나로 좁혀집니다. Fable 5가 가중치 내부에서 수행하는 추론(분해, 자기 검증, 장기적 일관성)을 하네스 측의 필수 공정으로 외부화한다. 단일 패스의 똑똑함은 살 수 없으므로, 다중 패스(multi-pass), 다중 에이전트(multi-agent), 외부 메모리로 대체합니다. fable-emu의 설계는 이것뿐입니다.

전체 구조는 다음과 같습니다.

사용자
│
▼
...

도입 전과 도입 후, 무엇이 변하는가

메커니즘의 내부로 들어가기 전에, 차이점을 구체적인 사례로 보여드리겠습니다. 둘 다 가상의 예시이지만, 전반부의 "도입 전"은 AI에게 태스크를 던져본 사람이라면 공감할 만한 내용일 것입니다.

사례 1: 컴포넌트 개수(엔지니어)

도입 전. "Button 컴포넌트에 loading 상태를 추가해 줘. 기존 variant는 망가뜨리지 말고."라고 의뢰합니다. 잠시 후 "완료했습니다. 기존 테스트도 모두 통과했습니다"라는 보고가 옵니다. 차이점(diff)을 대략 살펴보고 문제가 없어 보여 머지(merge)합니다. 다음 날, 이 Button을 전송 버튼으로 사용하는 화면에서 "연타하면 동일한 내용이 이중으로 등록된다"는 보고가 올라옵니다. 조사해 보니, loading 표시만 나올 뿐 버튼 자체는 계속 눌린 상태(loading을 표시하기만 하고 disabled 처리를 하지 않음)여서, onClick이 이중으로 발화되었습니다. 게다가 "테스트 통과"의 실체는 타입 체크뿐이었고, 실제 테스트는 한 번도 실행되지 않았습니다.

문제는 두 가지입니다. 발견 시점이 "다음 날, 인간의 눈"이라는 것. 그리고 "완료했습니다"라는 보고에 검증할 방법이 없다는 것입니다.

도입 후. 동일한 의뢰는 먼저 게이트 판정(gate judgment)에 걸러지며, planner가 계획 파일을 만듭니다.

- **ST-1: loading prop 추가 및 기존 variant의 비파괴 확인**
- 완료 조건: pnpm test button이 전건 PASS(출력 첨부).
Storybook의 기존 스토리가 모든 variant에서 에러 없이 렌더링됨
...

구현이 끝나면 verifier가 기동합니다. verifier는 구현 경위를 모릅니다. 완료 조건만을 읽고 "PASS라면 이렇게 되어 있어야 한다"를 먼저 작성한 뒤, 결과물을 확인합니다. 이때 적대적 경로(adversarial path, 이것을 망가뜨린다면 어디인가)로서 "loading 중의 조작"을 꼽고, loading 표시 중에 버튼이 클릭될 수 없는지를 실제로 확인하여 다음과 같이 응답합니다.

판정: FAIL

불일치

• 수정 필요 / loading 중에도 버튼이 disabled 되지 않고 onClick이
  ...

수정 후 재검증, PASS. 최종 보고에는 "pnpm test button 15건 PASS(출력 있음) / loading 중의 이중 전송은 재현 테스트를 추가하여 수정 완료 / visual regression은 미실시로 인해 미검증"이라고 작성됩니다. 발견 타이밍이 "다음 날·사람"에서 "수 분 후·기계"로 바뀌고, 보고가 검증 가능한 형식이 됩니다. 이것이 차이점입니다.

사례 2: 캠페인 LP 문구 (마케터)

코드가 없어도 동일한 루프가 돌아갑니다.

도입 전. 캠페인 LP의 헤드라인과 이메일 문구를 의뢰하면 깔끔한 문구가 돌아옵니다. 그대로 입고(入稿)를 진행했더니, 교열 단계에서 "도입 기업의 90%가 효과를 실감"이라는 수치의 근거 자료가 없다는 이유로 반려되었습니다. 자세히 보니 브랜드 톤 규약에서 금지하고 있는 자극적인 표현도 한 곳 섞여 있었습니다.

도입 후. planner가 만드는 완료 조건에 "사실·수치 주장에는 근거의 소재(URL 또는 사내 자료명)를 병기할 것", "톤 규약 체크리스트의 모든 항목을 대조할 것"이 포함됩니다. verifier는 문구를 요구 사항과 하나씩 대조하여, "근거의 소재 없음: 1건"으로 FAIL을 반환합니다. 반려가 교열 단계가 아닌 입고 전에, 사람이 아닌 기계적으로 일어나게 됩니다.

동일한 패턴은 경영 회의 자료(수치 출처 대조), 이사 절차 리스트(기한과 제출처 확인)와 같은 일상적인 태스크에도 그대로 사용할 수 있습니다. 요컨대 이것은 "완료 조건을 먼저 작성하고, 제삼자에게 대조하게 한다"라는 업무의 패턴을 AI에게 강제하는 메커니즘이며, 코드는 대상 중 하나일 뿐입니다.

메커니즘의 내부

구성 요소는 단 3 종류의 파일뿐입니다. 동작을 구속하는 운영 규칙(CLAUDE.md에 추가), 4체의 서브 에이전트(sub-agent), 4개의 슬래시 명령어(slash command).

운영 규칙 — 전체를 구속하는 약속

포인트는 3가지입니다. 비자명한(non-trivial) 태스크에 PLAN → EXECUTE → VERIFY → REPORT 순서를 강제하는 것. "완료"라고 말하기 전에 툴 출력값과의 대조를 의무화하고, 증명할 수 없는 주장은 "미검증"이라고 명시하게 하는 것. 그리고 임계값·횟수·경로 등은 서두의 §C 블록에 일원화하여, 리포지토리별 조정은 그곳을 덮어쓰는 것만으로 끝나도록 하는 것입니다.

## §0 게이트 판정
착수 전에 자문한다. 하나라도 Yes라면 게이트 대상:
1. 불가역적인 조작을 포함하는가
...

게이트 판정을 행 수 기준이 아닌 자문 형식으로 만든 데에는 이유가 있는데, 착수 시점에서는 모델이 변경된 행 수를 알 방법이 없기 때문입니다. 처음에는 행 수로 작성했으나, 제대로 작동하지 않는다는 것을 나중에 깨달았습니다(후술).

운영 규칙 전문(CLAUDE.snippet.md)

# fable-emu v2: Opus 4.8 운영 규칙
## §C 설정(리포지토리마다 조정하는 것은 이 블록뿐)
- `PLAN_DIR` = `plans/` — 계획 파일 저장소. 1태스크 = 1파일 `YYYYMMDD-slug.plan.md`. 기밀 / 공개 repo에서는 repo 외부에 둠(예: `~/.claude/projects/<repo>/plans/`)
...

verifier — 독립 검증을 담당하는 서브 에이전트

Fable 5의 가이드 자체에서도 "자기 비판(self-criticism)보다, 신선한 문맥을 가진 별도의 검증 서브 에이전트가 더 우수한 경향이 있다"라고 언급하고 있습니다. 단일 패스(single-pass)의 정답률로 이길 수 없다면, 독립 검증 루프로 잡아내면 됩니다. 추론 시의 계산량을 능력으로 변환하는 부분으로, fable-emu에서 가장 중요한 파일입니다.

---
name: verifier
description: 서브태스크 완료 후의 독립 검증. 구현자의 문맥을 가지지 않고, 완료 조건과 결과물만으로 PASS / FAIL / 조건부 PASS를 판정한다. 코드, 문서, 기사, 디자인 결과물, 설정 중 무엇이든, 결과물이 "완료되었다"라고 간주된 직후에 반드시 사용한다. 자기 검토(Self-review) 대신 항상 이것을 사용한다.
...

판정: PASS / FAIL / 조건부 PASS(육안 확인 N건 필요)

증거(각 항목에 3값 태그)

• [① 기계 대조 OK] 항목 / 확인 방법 → 결과(출력 요약 또는 발췌)
• [② 기계 대조 NG] 항목 / 확인 방법 → 결과
• [③ 육안 확인 필요] 항목 / 왜 기계 판정이 불가능한지 / 인간이 확인해야 할 점

불일치(②가 있는 경우)

각 ② 항목: 심각도(치명적 / 수정 필요 / 경미) / 현상 / 재현 방법

적대적 경로(Adversarial Path) 결과

육안 확인 필요 리스트(③)

인간이 확인해야 할 항목 목록(건수와 요점)

# 종합 판정 규칙
- ②가 하나라도 있으면 FAIL
- ②가 없고 ③가 있으면 → 조건부 PASS(③를 인간에게 넘긴다. ③를 임의로 PASS 처리하지 않는다)
...

설계에서 효과를 발휘하는 점은 3가지입니다. 첫 번째는 기대 리스트의 선제시입니다. 결과물을 보기 전에 "PASS라면 이렇게 되어 있어야 한다"를 작성하게 함으로써, 본 것을 나중에 정당화하려는 편향(Bias)을 구조적으로 방지합니다. 두 번째는 정보의 차단입니다. verifier에게 전달해도 되는 것은 완료 조건과 결과물에 대한 참조뿐이며, 구현 경위나 "아마 작동할 것이다"라는 소감을 전달하는 순간 독립 검증은 성립되지 않습니다. 세 번째는 판정을 3값(3-valued)으로 만드는 것입니다. PASS / FAIL의 2값(Binary)이라면 "도구로는 원리적으로 판정할 수 없는 항목(외관·주관)"이 FAIL 측에 섞여 위음성(False Negative)이 됩니다. ① 기계 대조 OK / ② 기계 대조 NG / ③ 육안 확인 필요로 나누고, ③은 FAIL로 치지 않고 인간에게 넘깁니다. 이 3값화는 당초 2값이었으나, 후술할 실운용에서 유효성을 확인하여 교체했습니다.

/bestof — 비용이 큰 판단만 여러 안으로

아키텍처 분기나 공개 API 설계와 같이, 단일 패스(Single pass)의 판단 실수가 큰 비용을 초래하는 상황에서는, N개의 안(기본값 3)을 병렬·독립적으로 생성시키고, 후보 생성에 관여하지 않은 judge가 판정하게 합니다.

• 각 생성체에는 사양과 판단 기준만 전달하며, 다른 후보의 존재를 알리지 않는다.
• 각 개체에 "중심 가설"을 한 줄 선언하게 하며, 가설이 실질적으로 같다면 재생성하여 다양성을 확보한다.
• judge는 선택한 안의 약점을 최소 하나 명시하게 한다. 약점이 없는 추천은 무효로 취급한다.

비용은 N+1배이므로, 자명한 판단에는 사용하지 않습니다. 사용처를 좁히는 것을 전제로 하는 도구입니다.

memory와 /checkpoint — 장기 일관성을 외부에 유지

긴 실행(Run) 과정에서 지시나 목표가 흐릿해지는 문제는 상태를 컨텍스트 외부로 내보냄으로써 보완합니다. 계획은 plans/날짜-슬러그.plan.md라는 외부 파일이 정답입니다. /checkpoint로 계획을 다시 읽고, 완료된 항목을 증거와 함께 재열거하며, 증거가 없는 것은 미검증 상태로 강등합니다. 교훈은 "1 교훈 = 1 파일, 도입부 첫 줄에 grep으로 잡을 수 있는 구체적인 단어"라는 규칙으로 저장합니다. 저장 위치는 리포지토리 직하가 아니라 Claude Code 네이티브의 project memory로 일원화합니다(이유는 후술할 실운용 절에서 설명).

checkpoint의 기동은 "서브태스크 완료 시마다 경량 버전, 컴팩션(Compaction) 전에는 풀 버전"으로 합니다. 시간 기반(30분마다 등)으로 하지 않는 이유는 모델이 시계(Wall clock)를 가지고 있지 않기 때문입니다.

남은 파일 전문(planner / scout / judge / 커맨드 4개 / 메모리 규칙)

---
name: planner
description: 비자명한(Non-trivial) 태스크의 분해 및 계획. 구현·집필·설계 전에 계획 파일을 만들 필요가 있을 때, 모호한 요구사항을 검증 가능한 서브태스크(Sub-task)로 변환할 때 반드시 사용한다. 코드에 국한되지 않고 문서·기사·디자인 결과물·조사 태스크에도 사용한다.
...

목적 및 배경

한 단락. 무엇을 위한 것인지·완성되면 무엇이 가능해지는지

전제(여기서 설정한 것)

번호 매기기. "이의가 없다면 이 전제로 진행한다"라고 명시

서브태스크

• ST-1: 제목
• 내용: 1~3행
• 완료 조건: 제삼자가 판정 가능한 기준
• 검증 수단: 실행할 커맨드 / 대조할 요구사항 리스트 / 육안 확인 항목 중 하나를 구체적으로
• 영향 범위: 수정하는 파일·문서·모듈
• ST-2: ...

하지 않는 것

이 태스크에서 의도적으로 스코프(Scope) 외로 두는 것

확인 필요(사용자만 답변 가능)

없다면 "없음"

진행 로그

(구현 측에서 ST 완료 시마다 추가하는 칸. 작성 시에는 비어 있음.
이 칸은 verifier에게 전달하지 않음 — 검증의 독립성을 지키기 위해)

# 금지 사항
- 요청받지 않은 기능·리팩토링·추상화를 서브태스크에 포함하지 말 것
- 일어날 수 없는 시나리오에 대한 대처를 계획하지 말 것
...

---
name: scout
description: 계획 전의 정찰. 미지 또는 오랜만에 접하는 대상 영역(코드뿐만 아니라 문서군·데이터·설정이라도)의 구조·규약·영향 범위를 조사하여, 구조화된 브리프(Brief)를 반환한다. 읽기 전용. /plan의 전 단계에서, 영역별로 병렬로 여러 개를 기동해도 좋다.
...

요약(3행 이내)

관련 파일 지도

경로 / 역할 / 1행 메모

기존 규약

검증 수단

영향 범위

함정·미해결 의문

# 규율
- 추측과 사실을 구분한다. 확인하지 않은 것은 "미확인:"이라고 서두에 붙인다
- 망라하기보다, 계획에 유효한 밀도를 우선한다. 브리프는 최대 1화면 정도
...

---
name: judge
description: best-of-N의 판정자. 독립적으로 생성된 여러 후보안을 사전 정의된 기준으로 비교하여, 근거와 함께 1안을 선택한다. /bestof의 최종 단계에서 반드시 사용한다. 후보 생성에는 관여하지 않는다.
...

판단 기준 및 가중치

채점(후보별)

비교표

결론: 후보 X

• 선정 이유(기준과 연계하여)
• X의 약점
• 이식 권장(있을 경우)

# 규율
- 제시 순서나 분량이 많은 것을 품질과 혼동하지 말 것
- 모든 후보가 기준에 미달하면 "해당 없음"으로 처리하고, 재생성 조건(어떤 기준을 어떻게 충족해야 하는지)을 반환해도 좋다

---
description: 비자명 태스크의 계획 페이즈를 시작한다 (scout 병렬 정찰 → planner → 승인 대기)
---
...

---
description: 현재의 결과물을 계획 파일의 완료 조건(또는 지정 사양)에 대해 독립 검증한다
---
...

---
description: 한 수의 무게가 무거운 판단을 N안 독립 생성 → judge 판정으로 결정한다 (N은 운용 규칙 §C의 BESTOF_N)
---
...

사양: <사양 본문 또는 참조>
판단 기준: <기준과 가중치>
첫 줄에 "중심 가설: ..."를 선언한 후, 안을 다음 형식으로 제시할 것:

개요

설계(또는 본문)

기준에 대한 자기 평가

기지(Known)의 트레이드오프(Trade-off)

다른 안의 존재는 고려하지 않아도 된다. 사양이 요구하는 것 이상의 것을 만들지 말 것.

- 중심 가설이 실질적으로 동일한 안이 있다면, 다양성을 위해 1개는 다른 가설로 재생성시킨다.
3. 모든 후보를 judge 서브 에이전트에게 전달하여 판정을 받는다.
4. 결론·약점·이식 권장을 사용자에게 보고한다. 구현으로 진행하는 것은 승인 후
...

---
description: 장시간 실행을 위한 재-그라운딩(Re-grounding). 목표를 재주입하고 드리프트(Drift)를 검출한다
---
...

# 메모리 운용 규칙
## 목적
과거 실행에서 확정된 교훈을 재도출하지 않고 사용한다. 세션 간의 학습을 외부 기억으로 대체한다.
...

직종을 불문하고 사용하기 위해 — 프로파일 메커니즘

이 하네스(Harness)는 엔지니어를 위해 만들기 시작했지만, 검증 루프의 형태 자체는 코드와 무관합니다. 그래서 운용 규칙에 §P라는 프로파일 칸을 마련하여, 사용하는 사람이 자신의 입장을 선언할 수 있도록 했습니다.

§P 프로파일

• 입장: 마케터 (코드는 작성하지 않음)
• 판단을 위임하는 범위: 문구 초안 작성은 위임함. 공개 및 입고 판단은 반드시 확인
  ...

이것이 효과를 발휘하는 곳은 두 군데입니다. planner는 계획의 전제와 검증 수단의 초기값으로 §P를 사용하므로, 마케터의 계획에는 처음부터 톤 규약 대조가 포함되고, 엔지니어의 계획에는 테스트 명령어가 포함됩니다. 또 다른 하나는 경계의 조정으로, '판단을 위임하는 범위'에 적힌 내용은 확인 없이 진행하며, 적지 않은 대외적 판단은 반드시 멈춰서 물어보게 됩니다. 공란이라면 기존 방식대로 동작하므로, 우선 빈 상태로 사용하기 시작해서 확인이 너무 많거나 적다고 느껴지면 채워 나가는 운용 방식이 용이합니다.

개인 이용이라면 "입장: 개인 이용 / 검증의 기본 수단: 기일과 제출처의 실재 확인"과 같은 방식으로 작성하여, 이사나 각종 절차와 같은 생활 태스크에도 그대로 유용할 수 있습니다.

이 설계는 정말로 성립하고 있는가

여기서 한 번, 자신의 설계를 의심해 둡니다. 작성하면서 깨달은 약점이 세 가지 있습니다.

1. verifier의 '독립'은 컨텍스트 독립이지, 모델 독립이 아니다. 생성하는 측과 검증하는 측은 동일한 가중치(weight)를 가집니다. 신선한 문맥(fresh context)이 제거해 주는 것은 매몰 비용이나 자기 정당화와 같은 문맥 유래의 편향(bias)이지, 모델 자체의 착각은 양측이 공유합니다. 생성자가 모르는 것은 검증자도 모릅니다. 즉, 이 루프가 확실히 잡아내는 것은 부주의에서 기인한 실수(실무에서는 이것이 대부분이지만)이며, 체계적인 오해는 그대로 통과할 수 있습니다. 완화책은 있으며, 검증 수단을 모델의 의견이 아닌 외부 도구(타입 체크, 테스트, 실제 대조)에 가깝게 가져갈수록 이 상관관계는 끊어집니다. planner에게 "검증 수단을 구체적으로 적으라"고 강제하는 것도 사실 이 때문입니다.

2. 어려움은 사라지지 않고, 장소를 옮긴다. 이 시스템은 구현의 어려움을 "검증 가능한 완료 조건을 작성하는 어려움"으로 이전시킵니다. 완료 조건을 작성하지 못하는 문제에는 무력합니다. 다만, 이 이전 자체에는 가치가 있다고 생각하는데, 완료 조건은 인간이 가장 저렴하게 개입할 수 있는 지점이기 때문입니다. 완성된 차분(diff)을 리뷰하는 것보다, 착수 전의 완료 조건 5줄에 태클을 거는 것이 훨씬 빠릅니다. 그렇지만 완료 조건을 작성하는 능력이 곧 이 시스템의 상한선이 된다는 점은 인정할 수밖에 없습니다.

3. 비용 추정은 성공했을 때의 숫자다. 1.5~3배라는 수치는 PASS까지 순조롭게 진행되었을 경우이며, FAIL 루프에 진입하면 급증하고, 검증이 직렬로 끼어들기 때문에 레이턴시(latency)도 확실히 늘어납니다. 대화를 나누며 몇 분 안에 답을 얻어야 하는 상황에는 적합하지 않습니다. 방치해 두고 돌려놓을 수 있는, 기다릴 수 있는 업무를 위한 메커니즘입니다.

설계 리뷰에서 수정한 미비점

초안을 작성한 후, 스스로 적대적으로 리뷰하여 네 가지를 다시 만들었습니다. 개인적으로는 이 부분이 가장 쓰고 싶었던 부분입니다. 모두 직접 실행해 보기 전까지는 깨닫기 어려웠고, 실제 운용에서는 확실히 겪게 되는 문제들이었습니다.

미비점 1: 진행 로그가 검증의 독립성을 해친다. 초안에서는 계획 파일에 구현 측이 진행 상황을 추가하는 설계였습니다. 그러면 verifier가 계획 파일을 읽는 시점에, 구현자의 "아마 작동할 것이다", "이 부분은 대응 완료"와 같은 경위와 자기변호가 증거로서 흘러 들어옵니다. 독립 검증을 의도했으나, 구현자의 주장을 추인하기만 하는 구조가 됩니다. 대책으로서 계획 파일에 "진행 로그" 칸을 분리하고, verifier에게는 해당 서브 태스크의 블록만 전달하도록 규율을 바꾸었습니다. 결과물도 본문을 붙여넣는 것이 아니라 경로 참조 방식으로 전달합니다. 요약에는 경위가 섞이기 때문입니다.

미비점 2: 착수 전에 판정할 수 없는 게이트 조건. 초안의 게이트 판정은 "3개 파일 초과 또는 50행 초과"였습니다. 그런데 모델은 착수 전에 변경 행수를 알 방법이 없으므로, 이 조건은 겉모습뿐인 기능이 됩니다. "비가역적인 조작을 포함하는가", "완료 조건을 지금 바로 한 줄로 쓸 수 있는가"와 같이 착수 전에 답할 수 있는 자문 형식으로 바꾸었습니다.

미비점 3: 병렬 세션에서의 계획 파일 충돌. 루트 직하에 plan.md를 하나 두는 설계는, 여러 세션이나 git worktree의 병렬 운용 시 확실히 충돌합니다. plans/날짜-슬러그.plan.md로 1세션 1파일 소유를 원칙으로 하고, 다른 세션의 계획 파일에는 쓰지 않는 것을 운용 규칙으로 명문화했습니다.

불완전점 4: 코드 전제에 너무 치우쳤다. 초기 버전의 verifier는 빌드와 테스트가 전제되어 문서나 디자인 결과물에는 사용할 수 없었습니다. 서브 태스크마다 '검증 수단'을 명시하도록 하고, verifier 측은 결과물 종류별 대응표로 판정하는 방식으로 변경했습니다. 툴로 판정할 수 없는 항목은 무리하게 PASS/FAIL을 내지 않고, '미확인(인간 육안 검사 필요)'으로 남기는 설계입니다. 이 부분을 수정함으로써 앞서 언급한 마케터 사례나 프로파일 메커니즘이 성립될 수 있었습니다.

공개 전에 실제로 자신의 프로젝트에서 돌려보며 고친 것들

앞 단락은 '쓰면서' 고친 불완전점들이었습니다. 여기부터는, 공개 전에 직접 보유한 여러 프로젝트(프론트엔드 라이브러리, Electron 앱, 디자인 시스템, 기밀성이 높은 업무 리포지토리 등)에서 실제로 돌려보며 알게 된 내용입니다. 기사대로 자신이 실천하지 않고 발표하는 것은 이 글이 경고하는 바로 그 행위이므로, 먼저 실행에 옮겼습니다. 그 결과, 설계를 3가지 수정하고 주장할 근거를 마련했습니다.

수정한 것들

A. memory의 주소를 통일했다. 초기 버전은 리포지토리 직하단에 memory/을 만들도록 설계되었으나, Claude Code는 원래 ~/.claude/projects/<repo>/memory/에 네이티브 프로젝트 메모리를 가지고 있습니다. 둘 다 존재하면 교훈(lesson)이 이중 관리되어 어느 것이 맞는지 알 수 없게 됩니다(split-brain). 네이티브 쪽에 통일하고 리포지토리 직하단에는 만들지 않기로 했습니다. PC 간에 교훈을 공유하고 싶을 때는 프로젝트의 git이 아닌 개인 동기화 채널(저는 claude-memory-sync를 사용합니다)에 올립니다. 교훈의 동기화는 프로젝트 리포지토리에서 분리하여 개인 측에서 완결시키는 것이 안전합니다. 작업 메모를 리포지토리 히스토리에 남기지 않는다는 일반적인 위생 문제입니다.

B. plans의 위치를 3단계로 나눴다. '팀이라면 커밋'만으로는 공개/공유 리포지토리에서 작업 메모가 PR이나 릴리스에 유입될 수 있습니다. private/team은 커밋(리뷰 자산이 됨), 공유/공개는 gitignore로 ephemeral, 기밀성이 높은 리포지토리는 애초에 리포지토리 외부에 두게 합니다. 유입은 되돌리기 어려우므로, 망설여질 때는 가장 보수적인 '리포지토리 외부'에 배치합니다.

C. verifier를 2값에서 3값으로 변경했다. 초기 버전의 판정은 PASS/FAIL의 2값이었으나, 디자인 결과물로 돌려보자 '툴로는 원리적으로 판정할 수 없는 항목(외관・주관적)'이 FAIL 쪽에 섞여서 위음성(false negative)이 되었습니다. ① 기계 대조 OK / ② 기계 대조 NG / ③ 툴 판정 불가=육안 검사 필요로 나누고, ③은 FAIL에 포함하지 않고 사람에게 넘깁니다. 실제로 대비율 감사 태스크를 거치자, verifier는 ③을 '알파 합성의 밑그림이 실제 UI와 일치하는지', '임계값 종류(4.5인지 3:1인지)의 타당성', '수정 후 색감 파손' 같은 카테고리로 스스로 분류했습니다. 툴로 해결할 수 없는 부분만 인간의 손에 남게 됩니다.

근거가 마련된 것들

• 독립 검증은 실제로 진짜 버그를 포착했다. 어느 UI 툴에서, 완료 조건만을 넘겨준 verifier가 production 빌드에서만 기능이 무반응이 되는 버그와 성능 저하를 감지했습니다. 구현자의 '작동합니다'를 증거로 삼지 않고, 자신이 직접 커맨드를 실행한 결과입니다. - '실측으로 ground truth를 만드는 것'이 구체적인 형태로 정립되었다. 수치를 검증할 때, verifier는 산출 함수 자체를 이미 알려진 정답값(대비율의 경우 #000/#fff = 21:1)으로 테스트하여 교정한 후에 사용했습니다. '교정되었기 때문에 자기 참조적인 속임수에 당하지 않는다'—이 판별이 독립 검증이

mkdir -p ~/.claude/agents ~/.claude/commands
# agents 4개 파일 → ~/.claude/agents/
# commands 4개 파일 → ~/.claude/commands/
...

동작 확인은 세션 내에서 /agents를 입력했을 때 planner / verifier / scout / judge 4개가 보이는지, 그리고 작은 태스크에서 /plan을 입력했을 때 plans/에 계획 파일이 생성되어 승인을 요청하는지, 이 두 가지 점을 확인합니다.

plans의 위치 (repo의 성격에 따라 3단계로 구분)

memory/는 repo에 만들지 않습니다 (네이티브 project memory로 일원화). 결정해야 할 것은 plans/의 위치뿐이며, 이는 repo의 성격에 따라 나뉩니다.

• private / team (유출되어도 문제가 없는 경우) → repo 직하의 plans/를 커밋 (commit). verifier의 증거 로그가 그대로 리뷰 자산 및 감사 추적(audit trail)이 됩니다.
• 공유 / 공개 (협업 또는 push 완료) → repo 직하의 plans/를 gitignore로 ephemeral (휘발성) 처리. 작업 메모가 PR diff나 배포물에 혼입되지 않도록 합니다.
• 기밀성이 높은 리포지토리 (유출 시 법적 리스크 발생) → repo 내에 만들지 않고, PLAN_DIR을 repo 외(~/.claude/projects/<repo>/plans/)로 지정합니다. 존재하지 않으면 유출 경로가 제로가 됩니다. 고민된다면 이 방식을 선택하세요.
• 영구적인 리뷰 자산도 필요하지만 유출은 안 되는 경우 → docs/plans/를 커밋 (공개해도 좋은 계획만 명시적으로 배치).

운영 규칙을 차이(diff) 없이 넣고 싶을 때는 CLAUDE.local.md (비커밋)에 추가합니다.

# 공유 / 공개 repo의 예 (ephemeral)
cd /path/to/repo
printf '%s\n' 'plans/' 'CLAUDE.local.md' >> .gitignore # 커밋하여 모든 협업자를 보호함
...

운영하며 알게 된 노하우

가장 중요한 것은 모든 태스크에 모든 게이트 (gate)를 부과하지 않는 것입니다. 질문에 대한 답변이나 자명한 소규모 수정까지 일일이 계획과 검증을 실행하면, 며칠 못 가 시스템 자체를 사용하지 않게 됩니다. 게이트 면제 조건(운영 규칙 §0)은 처음부터 포함되어 있지만, 효과는 환경에 따라 다르므로 도입 후 한동안은 "작은 태스크가 그대로 통과되고 있는가"를 관찰하십시오.

조정 신호(signal)를 미리 정해두면 편리합니다. verifier가 형식적인 PASS를 연발한다면 완료 조건이 느슨한 것입니다. 작은 태스크까지 /plan이 실행된다면 게이트의 임계값(threshold)이 너무 엄격한 것입니다. /checkpoint를 할 때마다 드리프트 (drift)가 검출된다면 계획의 입도(granularity)가 거친 것입니다. 이 모든 것의 수정 위치는 단 한 개의 파일입니다.

비용의 기준은 다음과 같습니다.

기구	토큰 비용 기준
verify 루프	일반 실행의 1.5~3배 (FAIL이 지속되면 더 증가)
/bestof N=3	약 4배 (생성 3 + 판정 1)

한계

마지막으로, 이 시스템의 한계를 명확히 해둡니다. 검증은 능력을 증폭시키지만, 창출하지는 않습니다. 분해(decomposition)든 루프든, 모델이 각 단계를 해결할 수 있다는 전제하에서만 효과가 있습니다. 완료 조건을 사전에 작성할 수 없는 문제나, 분해할 수 없는 종류의 통찰이 필요한 문제에서는 FAIL을 반복하거나, 확신에 찬 오답이 통과될 수 있습니다. 그 영역은 솔직하게 상위 모델을 사용해야 할 영역입니다.