페이블(Fable 5) 활용법: 좋은 모델 쓸 때 판단력을 영구 자산으로 남기는 5가지 클로드 코드 워크플로우

페이블(Fable 5)처럼 지금 쓸 수 있는 가장 똑똑한 모델의 판단력을, 나중에 값싼 모델로도 그대로 써먹을 수 있는 영구 자산으로 바꾸는 5가지 클로드 코드 워크플로우를 얻어갑니다. 각 워크플로우마다 바로 복사해서 붙여넣을 수 있는 프롬프트가 함께 있습니다. 이 페이블 활용법은 특정 모델이 요금제에서 빠지든 아니든 항상 유효한 원리입니다.

Photo by 8machine _ on Unsplash

왜 '결과물'이 아니라 '판단력'을 뽑아야 할까

프론티어 모델(그 시점에 가장 똑똑한 모델)을 하루 종일 쓸 수 있을 때, 대부분은 그 시간을 웹사이트 하나 만들기, 데모 앱 몇 개 찍어내기, 콘텐츠 한 달 치 뽑기에 씁니다. 문제는 이 작업들이 전부 같은 함정에 빠진다는 겁니다.

판단 기준은 딱 하나입니다. "더 싼 모델이 내일 이걸 다시 만들 수 있는가?"

웹사이트, 데모 앱, 게시글 한 묶음. 이런 건 평범한 등급의 모델도 다음 주에 거의 공짜로 다시 만들어냅니다. 가장 똑똑한 모델의 시간을 중급 모델이 처리할 수 있는 일에 쓰는 건, 혈압 재는 데 외과 전문의를 부르는 것과 같습니다.

반대로 값싼 모델이 내일 다시 못 만드는 건 이런 것들입니다. 만들려면 최상급 판단력이 필요하지만, 한 번 만들어두면 평범한 지능으로도 갖다 쓸 수 있는 자산.

  • 문서로 적힌 표준(standard)

  • 이미 추론이 끝난 로드맵

  • 이미 원자 단위로 정제된 지식 볼트

  • 알아서 발동하는 스킬

이 자산들은 뒤에 있던 모델이 손 닿지 않는 곳으로 가도 가치를 그대로 유지합니다. 실제로 초기 오픈소스 LLM 학습에서 가장 많이 복제된 데이터셋은, 당시 프론티어 모델에서 5만 2천 개의 답변을 뽑아내 작은 오픈 모델을 학습시킨 것이었습니다. 그 프론티어 모델은 은퇴했지만, 그걸로 학습된 모든 건 지금도 돌아갑니다. 가르친 모델은 사라져도, 추출해둔 건 남습니다.

그래서 전략은 대화가 아니라 추출입니다. 모델이 좋을 때, 내 업무에 대해 아는 걸 전부 문서로 적어두게 만드는 겁니다. 아래 5가지 워크플로우가 그 방법이고, 시간이 없다면 순서는 5번 → 4번 → 1번 → 2번 → 3번을 권합니다.

1. 워크스페이스에 모델의 판단력을 심기

프론티어 모델이 남기는 가장 값진 자산은 결과물이 아니라 표준(standard)입니다. 답변 하나는 나를 한 번 돕지만, 표준은 그 뒤에 나오는 모든 답변의 품질을 끌어올립니다.

CLAUDE.md, 스킬, 학습 기록 파일, 메모리 설정. 이 레이어는 앞으로 어떤 모델이 오든 내 작업을 건드리기 전에 먼저 읽는 층입니다. 지금은 좋은 모델이 이 층을, 나중에 올 덜 똑똑한 모델도 따라올 수 있는 수준으로 써줍니다.

중요한 프로젝트마다 아래 프롬프트를 실행하세요.

이 프로젝트 전체와 내가 여기서 일하는 방식을 읽어줘.

그다음 내 CLAUDE.md를, 너보다 덜 똑똑한 모델이
이곳에서 너 수준으로 일하려면 필요한 운영 매뉴얼로 다시 써줘:

- 내가 지키는 관례와, 네가 추가할 관례
- 이 코드베이스에서 약한 모델이 저지를 실수를, 이름 붙여서,
  각각을 막는 규칙과 함께
- 산출물별 품질 기준을, 형용사가 아니라 체크 가능한 조건으로
- 불확실할 때 뭘 해야 하는지: 정확한 에스컬레이션 규칙

그다음 내 시간을 가장 많이 아껴줄 스킬 3개를 제안하고, 전부 작성해줘

핵심은 "체크 가능한 품질 기준" 줄입니다. 값싼 모델은 품질 기준을 스스로 발명하지 못하지만, 적혀 있는 기준을 적용하는 건 잘합니다.

2. 컨설턴트 감사(audit)

성능 좋은 모델의 검증된 강점은 어렵고 지저분한 문제에 대한 판단입니다. 그러니 내가 가진 가장 어렵고 지저분한 문제, 즉 내 비즈니스 자체를 던지세요.

내 프로젝트, 숫자, 넣을 수 있는 모든 맥락에 접근할 수 있는 세션을 열고 아래를 실행합니다.

내가 고용할 수 없는 컨설턴트처럼 행동해줘.

전부 감사해줘: 프로젝트, 상품, 워크플로우, 가격, 내 시간이 어디로 가는지.

덜 똑똑한 모델로도 실행할 수 있는 로드맵으로 정리해줘:

- 기대 수익이 높은 순으로 정렬된 액션
- 액션마다: 왜 하는지, 정확한 실행 단계, 완료 상태가 어떤 모습인지,
  약한 모델이 실행하려면 뭘 알려줘야 하는지
- 지금 당장 그만둬야 할 3가지와, 그 이유를 전부 풀어서

여기서 가치를 만드는 건 "덜 똑똑한 모델로도 실행할 수 있게" 라는 조건입니다. 추론은 오늘, 좋은 모델이 붙어 있을 때 문서로 남깁니다. 나중에 실행 모델은 똑똑할 필요 없이, 똑똑한 문서를 따라가기만 하면 됩니다.

Photo by Markus Winkler on Unsplash

3. 세컨드 브레인 만들기

리서치는 추출이 가장 깊게 일어나는 영역입니다. 여러 단계에 걸친 긴 종합(synthesis)이 좋은 모델의 강점이기 때문입니다. 오늘 하루의 일부를 딥리서치에 쓰세요. 내 분야, 경쟁사, 고객의 문제, 계속 공부하려다 미룬 방법론.

그다음 모든 리서치 결과를 옵시디언(Obsidian) 볼트로 채굴합니다. 옵시디언은 노트끼리 서로 링크되는 무료 노트 앱이고, 원칙은 하나입니다. 노트 하나에 인사이트 하나.

이 볼트가 앞으로 모든 세션이 읽는 맥락이 됩니다. 여기서 흔히 하는 실수가 하나 있습니다.

  • 하지 말 것: 40페이지짜리 리포트 하나로 요약. → 저장되고 잊힙니다.

  • 할 것: 링크된 1인사이트 노트 100개로 원자화(atomize). → 검색되고 재사용됩니다.

지피터스 멤버라면 이 볼트를 스터디 노트, 뉴스레터 소스, 게시글 소재로 계속 재활용할 수 있습니다. 리서치를 한 번 쓰고 버리는 게 아니라, 축적되는 자산으로 바꾸는 겁니다.

4. 목표(goal)와 워크플로우로 무인 실행하기

좋은 모델의 대표 능력은 하나의 작업을 몇 시간 동안 흐트러지지 않고 붙잡는 지구력입니다. 클로드 코드의 두 기능이 이걸 활용합니다.

  • /goal: 프롬프트 대신 "완료 상태"를 정의합니다. 무엇이 끝난 모습인지 서술하면, 모델이 턴을 거듭하며 계속 작업하고, 별도의 작은 모델이 매 턴마다 조건 충족 여부를 확인해 조건이 맞을 때만 멈춥니다.

  • 다이나믹 워크플로우: 모델이 작업용 오케스트레이션 스크립트를 직접 작성하고, 그 스크립트가 백그라운드에서 수십 개의 서브에이전트를 병렬로 돌리며 서로의 결과를 교차 검증합니다. 그동안 내 세션은 자유롭습니다.

조합이 핵심입니다. /goal이 결승선을 붙잡고, 워크플로우가 팬아웃을 담당합니다.

/goal 이 저장소의 모든 모듈에 테스트 파일이 있고,
전체 테스트 스위트가 통과하며(완전한 green 실행 결과를 이 채팅에 붙여넣기),
migration-notes.md에 모든 변경을 문서화한다...
아니면 25턴 후에 실패 내역을 붙여넣고 멈춰라

이 워크플로우를 안전하게 쓰는 두 가지 규칙이 있습니다. 반드시 지키세요.

  • 완료 조건에 '붙여넣은 증거'를 요구할 것: 판정 모델은 대화 내용만 읽습니다. 테스트를 직접 돌리거나 파일을 열지 못합니다. 그래서 조건은 "green 실행 결과를 붙여넣기"를 요구해야 하고, "통과했다고 약속"은 안 됩니다.

  • 모든 실행에 상한(cap)을 걸 것: 턴 수든 벽시계 시간이든 조건에 명시하세요. 상한 없는 무인 루프 하나가 아침까지 돌면 비용이 크게 나올 수 있습니다.

무인 실행에 쓸 목표는 가장 가치가 묶여 있는 2~3개만 고르세요. 열 개를 한꺼번에 돌리는 게 아닙니다.

5. '어떻게 생각했는지'를 자동 기록하는 스킬

좋은 모델이 오늘 어려운 문제를 풀 때마다, 그 접근법은 세션이 끝나면 증발합니다. 이 마지막 워크플로우는 그걸 붙잡는 레코더를 설치합니다.

.claude/skills/extract-approach/SKILL.md 파일을 만들어 "어려운 문제를 풀고 난 뒤 그 접근법을 학습 노트로 남기는 스킬"로 정의한 다음, CLAUDE.md에 아래 규칙을 넣어 요청 없이도 발동되게 연결합니다.

## 학습 규칙
사소하지 않은 문제를 하나 풀 때마다, 다음으로 넘어가기 전에
extract-approach 스킬을 실행한다.
학습 노트가 없는 해결책은 미완성 작업으로 간주한다.

이제 나머지 시간을 진짜 백로그에 쏟으세요. 미뤄둔 까다로운 버그, 계속 맴돌던 아키텍처 결정. 문제를 풀 때마다 노트가 하나씩 남고, 이 노트들이 모델의 추론이 저장소에 앉아 있는 증류물이 됩니다. 뒤에 오는 어떤 모델이든 읽을 수 있는 형태로요.

이게 복리로 쌓이는 워크플로우이자, 시간이 한 시간밖에 없다면 가장 먼저 설치할 것입니다. 남은 모든 시간을 자동으로 영구 자산으로 바꿔주기 때문입니다.

마무리

정리하면 판단 기준은 하나입니다. "더 싼 모델이 내일 이걸 다시 만들 수 있는가?" 답이 '예'면 건너뛰세요.

  1. 워크스페이스: CLAUDE.md와 스킬을 체크 가능한 표준으로 다시 쓰기

  2. 감사: 컨설턴트 모드로 실행 로드맵 남기기

  3. 세컨드 브레인: 딥리서치를 원자화된 옵시디언 볼트로

  4. 목표: /goal과 워크플로우를 최고가치 백로그에, 붙여넣은 증거와 상한 걸고

  5. 레코더: extract-approach 스킬을 CLAUDE.md에 연결, 문제 하나당 학습 노트 하나

뉴스레터 무료 구독