
Claude Code의 최상위 모델 Fable 5, 사용할 수 있을 때 똑똑함을 '규칙'으로 추출하기
요약
Claude Code에서 고비용 모델인 Fable 5의 선제적 판단 능력을 활용하여, 이를 저렴한 모델에서도 재사용 가능한 '규칙'으로 추출하는 2단계 운용 방식을 소개합니다. 깨달음을 즉시 규칙화하는 대신 '규칙 후보 풀'에 기록하고 실적을 검증하여 정식 규칙으로 승격시키는 프로세스를 다룹니다.
핵심 포인트
- Fable 5의 강점은 사고 발생 전 리스크를 예측하는 선제적 판단력에 있음
- 고비용 모델의 지능을 저비용 모델로 전이하기 위해 '규칙화' 전략 필요
- 규칙 후보 풀(Rule Candidate Pool)을 통한 단계적 검증 프로세스 도입
- 실제 실적(사고 방지 또는 반복 발생)을 기반으로 규칙 승격 결정
이 기사의 요점: Claude Code에서는 Anthropic의 최상위 모델 Fable 5를 사용할 수 있다 (본인은 구독을 통해 이용 중이다). 다만 단가는 Opus의 2배로 상시 사용하기는 어려우며, 해당 세션에서 발생한 '선제적인 깨달음'은 세션이 종료되면 사라진다. 이에 2026-07-09, 깨달음을 구속력 없는 '규칙 후보 풀(Rule Candidate Pool)'에 기록하고, 실적(사고·재작업을 방지한 1건, 또는 동일한 판단이 다른 세션에서 2회 이상 발생)이 쌓인 후에 승인을 거쳐 정식 규칙으로 승격시키는 2단계 운용 방식을 도입했다. 2일 후인 2026-07-11, 주간 리뷰에 포함된 대조 작업이 처음으로 작동하여, 후보 4건 중 1건(품질 게이트 fail 이후의 차분 재검토 절차. 89점→93점의 실적 포함)이 정식 규칙으로 승격되었다. 다만 '하위 모델(Sonnet 등)이 이 메커니즘 자체를 돌릴 수 있는가'는 아직 실증되지 않았다.
Fable 5는 똑똑하다. 하지만 비싸고, 똑똑함은 세션과 함께 사라진다
Claude Code에서는 Anthropic의 최상위 모델 Fable 5를 사용할 수 있다. 나는 구독을 통해 이용하고 있지만, 이 환경이 언제까지 지속될지는 솔직히 모르겠다. 실제로 2026년 6월에는 Fable 5에 대한 액세스가 일시적으로 중단되었다가 7월에 들어서야 복구되었다. "사용할 수 있을 때 마음껏 써보고 싶다"는 것이 본심이다.
그렇다고는 해도 단가는 Opus의 2배다. 아무 데나 쓸 수는 없다. 나는 Claude Code에서 여러 에이전트(Agent)에게 역할을 분담시켜 기사 작성이나 태스크 관리(Task Management)를 돌리고 있으며, 평소 실무는 Sonnet이나 Opus에 맡기고, Fable 5는 판단을 잘못하면 비용이 많이 드는 장면에만 투입하고 있다.
그런 방식으로 사용하다 보면 깨닫는 점이 있다. 상위 모델의 똑똑함은 결과물의 완성도 그 자체보다, 사고가 일어나기 전에 리스크를 알아차리는 부분에서 드러난다. 예를 들어 조사 담당 에이전트에게 "분석만 해줘"라고 부탁할 때, Fable 5는 요청받지 않아도 "이 에이전트는 내버려 두면 수정까지 자율적으로 수행할 수 있으니, 읽기 전용(Read-only)이라고 명시해 두자"라는 문장을 선제적으로 추가한다. 하위 모델은 사고가 터진 후에야 같은 것을 배운다.
이 '똑똑함'의 내용을 조금 더 분해하면, 서브 에이전트(Sub-agent)에 대한 지시문(Prompt)의 질로 나타난다.
| 관점 | 내용 |
|---|---|
| 실패 모드의 선제 대응 | 지시를 받은 상대가 어디서 실수할지를 예측하여 미리 제약 사항을 작성함 |
| ... |
농담이 아니라, 나의 운용 규칙 중 상당수는 실제로 '사고의 사후 처리'를 통해 만들어져 왔다. 조사만 부탁한 에이전트가 무단으로 파일을 수정했다 (2026-05-25). 처리 분할 설계를 잘못하여, 75건의 순차 처리 과정에서 1건씩 에이전트를 기동해 116개의 에이전트·4.28M 토큰·약 25.70달러(이상적인 설계 대비 5.7배)를 소모했다 (2026-06-20). 텍스트 처리 버그로 기사 아이디어 노트 파일 26개를 비워버렸다 (2026-05-11). 모두 사고가 일어난 후에 규칙이 되었다.
그렇다면 사고 전에 알아차릴 수 있는 두뇌가 모처럼 손에 있을 때, 그 깨달음을 일회성으로 버리지 않고 회수하고 싶다. 한 번의 실행에 쓰고 끝낸다면, 비싼 단가로 '답'을 하나 샀을 뿐이다. 내가 원하는 것은 답 그 자체가 아니라, 저렴한 모델에서도 재사용할 수 있는 '판단의 규칙'이다.
"깨달으면 즉시 규칙화"에는 두 가지 함정이 있다
발단은 내가 Claude Code와의 대화에서 던진 이 생각이었다.
"미지의 부분에 Fable이 알아차리면, 다른 모델에서도 이용할 수 있도록 규칙화하는 건 어떨까?"
나름 괜찮은 생각이라고 스스로 생각했다. 하지만 돌아온 분석은, "그대로 전부 규칙화"하는 것에는 두 가지 문제가 있다는 것이었다.
첫 번째는, 규칙 비대화의 비용이다. 규칙은 한 번 써두면 "모든 모델 × 모든 세션 × 영구적"으로 효력을 발휘한다. 모호한 훈계를 규칙화해도 하위 모델의 동작은 변하지 않고, 읽어야 할 규칙만 늘어난다. CLAUDE.md에 이것저것 써넣어 비대하게 만들었던 경험이 있는 사람이라면 이 감각을 이해할 것이다.
두 번째는, 사고 전의 통찰은 가설에 불과하다는 점이다. 사고 기록에서 태어난 규칙에는 실질적인 피해라는 뒷받침이 있지만, 상위 모델의 '선제적 대응'은 빗나갈 가능성이 있는 가설이다. 검증 없이 모든 에이전트를 구속하는 규칙으로 만들어 버릴 리스크가 있다.
"결국 규칙만 계속 늘어나는 것 아닌가?"라는 의구심은 타당하다. 해결책은 규칙화를 단일 프로세스로 두지 않고, 2단계로 나누는 것이었다.
규칙 후보 풀(Rule Candidate Pool)이란 무엇인가 —— 기록은 공짜, 승격에는 실적을 요구한다
구조는 간단하다. '규칙 후보 풀'이라고 해도, 내가 멋대로 그렇게 부르는 것일 뿐인 단순한 Markdown 파일이다.
- 깨달음은,
**구속력 없는 후보 풀 (Candidate Pool)**에 기록한다 -
실적 (사고·재작업을 방지한 1건, 또는 동일한 종류의 선제적 판단이 다른 세션에서 2회 이상)이 갖춰진 후보만을 승인을 거쳐 정식 규칙으로 승격시킨다.
미리 말해두자면, 이 핵심 부분은 모델을 몇 단계로 나누어 사용하는지에 의존하지 않는다. Claude Code를 하나의 모델로 평범하게 사용하고 있는 경우라도, "깨달은 것을 일단 메모해 두고, 실제로 효과가 있다고 확인된 후에 비로소 규칙화한다"라는 순서는 그대로 사용할 수 있다.
기록 포맷은 발화 조건, 액션, 배경, 기록 모델, 실적의 5개 항목으로 고정했다.
### YYYY-MM-DD <slug>
- **발화 조건**: (어떤 상황에서 발동하는가. 구체적으로)
- **액션**: (무엇을 하는가. 구체적으로)
...
기록은 구속력을 갖지 않으므로 실질적인 해가 없으며, 비용은 "풀을 읽는 몇 분"뿐이다. 풀 자체의 비대화에는 "기록 후 3개월간 실적이 없는 후보는 폐기를 검토한다"라는 재고(Inventory) 규칙으로 제동을 걸었다.
이렇게 하면 높은 모델을 사용하는 경제성이 달라진다. Fable 5의 단가는 일회성 지출이지만, 규칙화된 지식은 모든 모델과 모든 세션에서 영구적으로 효과를 발휘한다. 상위 모델을 '실행자'로서가 아니라 '규칙 생성기 (Rule Generator)'로서 사용한다는 발상이다. 게다가 "증거가 갖춰진 후에 규칙으로 만든다"라는 기존의 원칙은 무너뜨리지 않았다. 규칙이 탄생하는 기점을 "사고가 난 후"에서 "통찰이 일어난 시점"으로 앞당겼을 뿐이다.
단 한 가지, 만들자마자 설계상의 허점이 발견되었다. 기록하는 메커니즘은 만들었지만, 풀을 다시 읽을 기회가 어디에도 포함되어 있지 않았던 것이다. 도입 당일에 기록할 기회는 3번 있었지만, 3번 모두 나의 "이 위임에서 통찰은 없었나?"라는 짧은 한마디가 계기가 되었을 뿐, 메커니즘이 스스로 움직인 적은 단 한 번도 없었다. "잘 돌아갈까"라는 소박한 질문을 던지자 이 미연결 상태가 드러났다. 과거에 스스로 메모했던 교훈——"불리지 않는 규칙은 존재하지 않는 것과 같다" (2026-04-29)——가 그대로 적중한 형태다. 대책으로서 주간 리뷰 (Weekly Review, 일주일에 한 번 운영 전체를 재검토하는 정기 체크 절차)에 "후보 풀을 읽고 이번 주의 세션과 대조한다"라는 단계를 포함시켰다.
도입 2일 후, 후보 4건 중 1건이 정식 규칙으로 승격되었다
도입 2일 후인 2026-07-11, 주간 리뷰에 포함시킨 대조 단계가 처음으로 실행되었다. 그때까지의 기록이 모두 인간의 한마디에 의존했던 것과 달리, 처음으로 "메커니즘이 메커니즘을 호출"하게 된 것이다.
대조 결과는 후보 4건 중 승격 1건, 계속 관찰 3건, 폐기 0건이었다.
| 후보 | 판정 | 이유 |
|---|---|---|
| 품질 게이트(Quality Gate) fail 후의 차분 재리뷰(Differential Re-review) 절차 | 승격 | 재작업을 방지한 실적 1건 확인 |
| 위임 시 스코프(Scope) 제약 명시 | 계속 관찰 | 적용 2회이나, 효과를 판별할 수 없는 유보 상태 |
| 소재의 이중 공급 금지 | 계속 관찰 | 다른 세션에서의 2회차 적용 대기 중 |
| Workflow 사용 시 모델 지정 명시 | 계속 관찰 | 미검증 |
승격된 후보의 실적은 다음과 같다. 나는 기사를 공개하기 전에 '품질 게이트'라고 부르는 다각도 채점을 거치는데, 2026-07-09, Claude Code의 ToolSearch 기능을 다룬 기사의 첫 번째 집계가 89점으로 fail 되었다 (합격 라인 90점, 1점 부족). 다만 감점의 주된 원인은 리뷰가 수정 전 버전을 대상으로 했기 때문에 발생한 오감점이었으며, 지적 사항 자체는 채점 시점에 이미 반영되어 있었다. 그래서 모든 관점을 풀 재실행하는 대신, 해당 관점만의 **차분 재리뷰 (Differential Re-review)**로 점수 회복을 판정하여 93점 pass에 이르렀다. 풀 재실행에 비해 에이전트 2회 구동분을 절약하면서도, fail 기록도 이력으로 남길 수 있었다.
이 차분 재리뷰라는 절차 자체가 원래 Fable 5의 세션에서 즉석 설계되어 후보 풀에 "실적 포함" 상태로 기록되어 있던 것이었다. 이번 대조를 통해 승격 조건(재작업을 방지한 실적 1건)을 충족한다고 판정하였고, 승인을 거쳐 정식 절차서로 전기했다. Fable 5의 즉흥성이 어떤 모델의 세션에서도 참조되는 절차로 변한 순간이다.
적용 2회라도 승격되지 않는다——기준은 횟수보다 "효과를 관측할 수 있는가"입니다
개인적으로는 승격된 후보보다 승격되지 않은 후보가 더 흥미로웠다.
"위임 시 스코프 제약 명시" (서브 에이전트에게 하나의 결과물만 만들게 할 때, 대상 파일 이외의 수정·생성을 하지 않도록 명시하는 것)는 서로 다른 세션에서 2회 적용되었다. 승격 조건의 문구인 "동종 판단이 다른 세션에서 2회"를 형식적으로는 충족하고 있다.
하지만 두 번 모두 "제약이 효과가 있었던 것인지, 아니면 애초에 일탈하지 않는 케이스였는지 판별할 수 없다"라는 유보적인 적용이었다. 앞서 승격되었던 다른 후보(수임자에게 "자신 없는 부분"을 완료 보고 시 자기 신고하게 하는 절차. 신고가 다음 공정의 검증에 적절히 효과가 있었다고 구체적으로 확인됨)와 비교하면 증거의 질이 다르다. 그래서 지속 관찰을 선택했다.
즉, 승격 기준은 문면상 "적용 횟수"이지만, 실제로 작용하고 있는 것은 "효과가 관측 가능한지 여부"다. 횟수만 채운다고 해도, 효과가 있었는지 알 수 없는 적용은 승격을 뒷받침하지 않는다. 이는 운용을 해보고 나서야 비로소 보인 해석이며, 아이러니하게도 이 해석 자체가 다음 후보 풀(Pool)로 향하는 깨달음이 될 수 있다.
Sonnet은 Fable 5가 만든 메커니즘을 돌릴 수 있을까 —— 남은 숙제
여기까지로 기록 $\rightarrow$ 회상 $\rightarrow$ 승격 $\rightarrow$ 재고 정리의 경로는 한 바퀴를 돌았다. 다만 솔직히 말하자면, 아직 답하지 못한 의문이 두 가지 남아 있다.
하나는 2026-07-11의 주간 리뷰(Weekly Review)를 실행한 것도 Fable 5였다는 점이다. "하위 모델(Sonnet 등)이 후보 풀의 대조 및 승격 판단을 운용할 수 있는가"는 아직 실증되지 않았다. 또 다른 하나는 승격된 차분 재검토(Diff Re-review) 절차가 하위 모델의 품질 게이트(Quality Gate) 운용에서 실제로 기능할지 여부다. 이는 다음에 실패(fail)가 발생할 때까지 관측할 수 없다.
다음 관측 포인트는 명확하다. 다음에 품질 게이트의 실패가 발생했을 때, 그리고 주간 리뷰를 Sonnet에게 맡겼을 때다. 그 사이에 독자인 당신이 시도해 볼 수 있는 것은 훨씬 더 작아도 좋다. 구속력 없는 메모 파일을 하나 만들어서, 세션에서 나온 "오, 똑똑한데"라는 깨달음을 기록해 두었다가, 효과가 있었다고 확인된 것들만 CLAUDE.md나 규칙 파일(Rule file) 등으로 승격시키는 것이다. 그것만으로도 이 메커니즘의 핵심은 움직이기 시작한다.
마지막으로 한 가지 공개해 둔다. 이 기사의 초안은 하위 모델에 해당하는 Sonnet이 썼으며, 공개 전 팩트 체크(Fact check)에서는 사실 오인 지적이 제로였다. 그 상태에서 읽을거리로서의 최종 리라이트(Rewrite)는 Fable 5 자신에게 맡기고 있다. 즉, 이 문장은 "똑똑함을 짜내어지는 쪽"의 모델이 직접 쓴 것이다. 구독을 통해 Fable 5를 사용할 수 있는 동안 짜낼 수 있는 것은, 아무래도 규칙뿐만이 아닌 듯하다.
규칙을 어떻게 심을 것인가가 아니라, 심어진 메커니즘이 "누구에게나 똑같이 작동하는가"까지 설계하는 이야기를 하면 다음 질문이 나온다 —— 애초에 CLAUDE.md, 서브 에이전트(Sub-agent), 스킬(Skill), 플레이북(Playbook), 메모리(Memory), 권한 설정, MCP라는 7가지 부품을 어떻게 조합해야 "전달 가능한 메커니즘"이 되는가.
나는 이 7개 레이어의 부품론을 Zenn Book Vol.4 『코드를 작성할 수 없는 내가 Claude Code에 「메커니즘」을 전달하기까지』에 정리했다. 이번 규칙 후보 풀도 이 7개 레이어 중 어딘가(Playbook과 CLAUDE.md의 경계)에 위치하는 하나의 구체적인 예시에 불과하다.
이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기