Fable 5의 무료 기간이 7월 7일에 종료됩니다.
오늘은 2026년 7월 3일입니다. 즉, "공짜니까 Fable을 쓴다"는 시간이 며칠 남지 않았고, 7월 8일부터는 사용량 기반 크레딧 시스템으로 전환됩니다.
그렇다면 7월 8일부터는 어떻게 해야 할까요?
Sonnet 5는 Free를 포함한 모든 요금제에서 사용할 수 있습니다.
8월 31일까지의 도입 가격은 입력 토큰 100만 개당 2달러, 출력 토큰 100만 개당 10달러입니다. 이후에는 입력 3달러, 출력 15달러가 됩니다. Fable 5는 입력 10달러, 출력 50달러입니다.
정상 가격에서도 약 3.3배 차이입니다. Sonnet 5의 도입 가격과 비교하면 5배 차이입니다.
게다가 Sonnet 5는 100만 컨텍스트 윈도우와 128k 출력을 제공합니다. 긴 문서와 코드를 읽는 능력은 Fable 5와 동일합니다.
그렇다면 정말 부족한 것은 "성능"뿐일까요?
제 결론은 조금 다릅니다. Fable 5의 강점 비결은 단순히 지능이 아닙니다. 바로 행동 방식입니다.
오래 생각하기. 먼저 성공 조건 정의하기. 의심하기. 검증하기. 메모하기. 그리고 마지막으로, 달성한 것과 달성하지 못한 것을 정직하게 보고하기.
이러한 행동 방식의 상당 부분은 CLAUDE.md와 환경 설정에 주입할 수 있습니다.
CLAUDE.md는 Claude Code가 지속적으로 참조하는 구성 메모로, "이 프로젝트에서 어떻게 행동해야 하는지"를 알려줍니다. 매 채팅마다 붙여넣는 프롬프트가 아닙니다. 환경 자체에 배치되는 지침입니다.
매번 프롬프트를 붙여넣는 사람들의 기술도 강력합니다. 승리 조건을 만들게 하고, 초안을 비교하게 하고, 작업을 분해하고, 마무리하게 하는 것입니다. 이 패턴은 매우 효과적입니다.
하지만 매번 붙여넣어야 하는 것은 잊어버리기 쉽습니다. 길수록 더 귀찮아집니다. 세션이 바뀌면 사라집니다.
그래서 이번에는 그것을 영구적으로 만듭니다.
해외에서 유행하는 말을 빌리자면:
프롬프트는 일시적이다. 구조는 영원하다.
이 글에서는 Sonnet 5를 Fable 5에 더 가깝게 만들어 줄 CLAUDE.md 설정을 복사해서 바로 사용할 수 있는 형식으로 제공합니다.
게다가 이 설정들은 제가 임의로 만든 것이 아닙니다.
Claude Code의 헤드리스 모드, 즉 터미널에서 claude -p를 통해 질문하여 Sonnet 5와 Fable 5 자체를 인터뷰했습니다.
주니어인 Sonnet 5에게 자신의 약점을 물었습니다.
시니어인 Fable 5에게 주니어를 어떻게 훈련시킬지 물었습니다.
이 이중 인터뷰는 매우 흥미로운 답변을 이끌어냈습니다.
Fable 5의 정체는 "지속적인 행동 방식"
Fable 5를 사용해보면 확실히 똑똑합니다.
하지만 출력을 자세히 살펴보면 강점이 단순히 지식의 양에 있지 않습니다. 작업에 접근하는 방식 자체가 다릅니다.
바로 구축을 시작하지 않습니다. 먼저 성공 조건을 정의합니다.
자신의 아이디어를 바로 신뢰하지 않습니다. 먼저 실패할 수 있는 지점을 찾습니다.
"작동했다"고만 말하지 않습니다. 검증에 사용한 것을 보여줍니다.
지식의 공백을 아는 척으로 채우지 않습니다.
그리고 긴 작업에서도 초기 제약 조건을 끝까지 유지하려고 노력합니다.
이것은 인간의 작업에 대입해보면 이해하기 쉽습니다.
Fable 5는 유능한 시니어처럼 보입니다. 모호한 요청을 받아도 바로 달려가기 전에 돌아와서 "성공은 어떤 모습인가요?"라고 묻습니다. 계획이 실패하면 계획을 버리고 다시 시작합니다.
Sonnet 5는 유능한 주니어입니다. 빠릅니다. 순종적입니다. 지시에 충실합니다. 하지만 구조가 없으면 너무 매끄럽게 대답할 수 있습니다.
그렇다면 주니어에게 시니어의 작업 습관을 주면 됩니다.
그것을 넣을 곳이 바로 CLAUDE.md입니다.
Sonnet 5 "자체"를 인터뷰하여 확인한 명확한 약점
먼저 Sonnet 5 자체에게 물었습니다.
"Fable 5 수준의 결과를 얻으려면 CLAUDE.md에 무엇을 써야 할까요?"
돌아온 자기 분석은 꽤 솔직했습니다.
Sonnet 5는 자신에 대해 이렇게 말했습니다.
"저는 유창하게 대답하는 경향이 있으며, 불확실성이 종종 제 글쓰기 스타일에 숨겨집니다."
이것은 중요합니다.
AI의 답변은 글이 좋을 때 위험할 수 있습니다. 명확하게 쓰여 있으면 인간은 그것을 믿는 경향이 있습니다. 하지만 실제로는 "아마도", "확인되지 않음", "이 부분은 의심스러움"이 포함되어 있을 수 있습니다.
따라서 포함해야 할 첫 번째 설정은 다음과 같습니다.
**불확실한 부분에 대해 명시적으로 신뢰 수준을 표시하게 하십시오.
모호한 부사 뒤에 숨지 못하게 하십시오.
신뢰도가 낮으면 진행하기 전에 확인하게 하십시오.**
이것이 효과적인 이유는 간단합니다. 더 이상 불안을 글쓰기 스타일 안에 숨길 수 없기 때문입니다.
다음으로, Sonnet 5는 "일단 구현하고 나중에 조정하는" 경향이 있다고 인정했습니다. 이를 막으려면 먼저 성공 조건을 작성하게 하십시오.
코드나 텍스트를 작성하기 전에 전제, 검증 가능한 성공 조건, 실패 모드를 출력하게 하십시오. "작동함"이나 "느낌 좋음"이 아니라 테스트, 출력, 화면 또는 특정 텍스트 조건으로 판단할 수 있는 형태로 말입니다.
여기서 중요한 것은 성공 조건을 "기분"이 아닌 "판단"으로 만드는 것입니다.
"좋은 글을 써라"는 약합니다.
"7월 7일 마감일을 시작 부분에 언급하라. 가격 차이를 포함하라. CLAUDE.md용 복사 설정을 6개 이상 배치하라. Fable이 채울 수 없는 격차를 숨기지 마라."
이 정도로 작성하면 마지막에 비교할 수 있습니다.
Sonnet 5는 이렇게 결론지었습니다.
"Fable 5는 스스로 깊이 생각할 수 있습니다. 저는 구조가 주어지면 빠르고 정확하게 움직입니다. CLAUDE.md로 그 차이를 연결하는 것이 핵심입니다."
이 글의 핵심이 바로 그것입니다.
Fable 5를 인터뷰한 결과
다음으로 같은 주제에 대해 Fable 5 자체에게 물었습니다.
첫 번째 응답이 훌륭했습니다.
"모델의 자기 보고는 신뢰할 수 있는 데이터가 아닙니다."
정확합니다. 모델에게 물었다고 해서 그것이 벤치마크가 되는 것은 아닙니다. 내부에서의 자기 평가는 편향되어 있습니다.
따라서 이 글에서는 "그들이 말한 것"을 절대 진리로 취급하지 않겠습니다. 사용 패턴을 만드는 힌트로 취급하겠습니다.
그렇지만 Fable 5가 정의한 차이는 날카로웠습니다.
그 차이는 "구조가 없을 때, 또는 주어진 구조가 잘못되었을 때 무슨 일이 일어나는지"라고 말했습니다.
사양이 명확하고, 테스트가 존재하며, 절차가 설정되어 있으면 차이는 작습니다.
차이는 사양 자체가 잘못되었을 때 나타납니다. 계획이 실패했을 때. 긴 작업의 끝까지 초기 제약 조건을 유지해야 할 때. 요청되지 않은 개선 사항을 추가하지 않으려는 자제력이 필요할 때.
그리고 Fable 5는 자신의 약점도 인정했습니다.
높은 단위 비용. 단순한 작업에도 지나치게 생각함. 대량 처리 속도 경쟁에서 밀림.
즉, "모든 것에 Fable"은 경제적으로 올바른 운영이 아닙니다.
그렇다면 Fable 5가 후배 Sonnet을 위해 작성한 `CLAUDE.md`는 무엇일까요?
Sonnet 측과 중복된 점을 정리하면, 지켜야 할 7가지 팁이 있습니다.
Sonnet 5를 Fable로 만드는 `CLAUDE.md`를 위한 7가지 팁
첫 번째는 성공 조건입니다. 두 모델 모두 독립적으로 이 점을 언급했습니다.
1[완료를 기계적으로 판단하라]2시작하기 전에 "완료"를 한 줄로 정의하라.3예: 이 테스트가 통과한다. 이 명령어가 exit 0을 반환한다. 이 제목이 본문에 있다.4작성할 수 없으면, 진행하기 전에 무엇을 결정해야 하는지 물어봐라.
두 번째는 다중 해석입니다. 이것도 두 모델이 동의했습니다.
1[여러 해석 중에서 혼자 선택하지 마라]2지시에 두 가지 이상의 해석이 있다면, 조용히 하나를 선택하지 마라.3후보 해석을 나열하고 추천과 함께 확인하라.4단, 해석에 관계없이 출력이 동일하다면 진행해도 좋다.
세 번째는 범위입니다.
1[우발적 개선 금지]2요청되지 않은 변경을 구현하지 마라.3"하는 김에 고쳤다" 또는 "더 나은 디자인을 만들었다"는 금지다.4인접한 개선 영역을 발견하면 구현하는 대신 제안으로 나열하라.
네 번째는 검증 보고입니다.
1['작동했다' 대신 '검증됨'을 보고하라]2완료 보고서에는 실행된 검증 명령어, 반환 값, 테스트 결과, 스크린샷 확인과 같은 증거를 포함해야 한다.3실행되지 않은 것에 대해 "작동할 것이다"라고 쓰지 마라.4건너뛴 검증에 대해서는 그 이유를 명확히 밝혀라.
다섯 번째는 동일한 실패를 지속하는 방법입니다. 지속성은 중요하지만, 잘못된 방향으로 지속하면 시간을 낭비합니다.
1[동일 오류 최대 2회 재시도]2동일한 오류에 대한 수정이 두 번 실패하면 세 번째 변형을 시도하지 마라.3현재 상태, 시도한 것, 남은 가설을 간략히 보고한 후 방향을 바꿔라.
여섯 번째는 반대자의 역할입니다.
1[완료 전에 처음 읽는 검토 수행하라]2완료 보고 전에 변경 사항을 처음 읽는 것처럼 검토하라.3깨질 수 있는 인접 기능 하나를 식별하라.4회의적인 시니어가 반대할 내용을 쓰고, 그 반대에 답하라.
일곱 번째는 신뢰도와 정직한 진행 상황입니다. 이는 Sonnet 5의 자기 분석을 반영합니다.
1[신뢰도와 진행 상황을 3가지로 보고하라]2불확실한 부분에 신뢰 수준(높음, 중간, 낮음)을 첨부하라.3신뢰도가 중간 또는 낮으면 진행 전에 확인해야 하는지 물어봐라.4긴 작업에서는 각 마일스톤에서 다음 세 가지만 보고하라:5완료된 것. 다음에 할 것. 우려되는 것.6"문제없이 진행 중"으로만 구성된 보고는 금지다.
이 7가지 팁은 능력을 추가하는 설정이 아닙니다.
격차가 나타나는 실패 모드를 사전에 차단하는 설정입니다.
사양 구멍에 빠지지 마라. 모호함을 혼자 결정하지 마라. 범위를 부풀리지 마라. 검증 없이 완료를 주장하지 마라. 망가진 계획을 계속하지 마라.
요컨대, Fable 5가 자연스럽게 수행하는 행동을 Sonnet 5 환경에 외부적으로 부착하는 것입니다.
비교에서 확인된 점
흥미로웠던 점은 Sonnet 5와 Fable 5가 별도로 질문을 받았음에도 답변이 상당히 일치했다는 것입니다.
첫째, 여러 해석을 혼자 선택하지 마라.
둘 다 이렇게 말했습니다. 모호한 지시가 주어지면 AI는 그럴듯한 해석을 선택하고 진행하는 경향이 있습니다. 인간의 관점에서는 "그걸 확인해주길 바랐는데"라고 생각하게 됩니다.
다음으로, 검증을 외부화하라.
"작동했다"고 말하게 하는 대신, 무엇을 실행했는지, 무엇이 통과했는지, 무엇을 보았는지 출력하게 하십시오. 공식 모범 사례에서도 Claude가 자신의 작업을 검증할 방법을 제공하는 것이 가장 중요하다고 간주됩니다.
테스트, 빌드 또는 스크린샷 비교와 같이 통과 또는 실패로 결과가 나오는 검사를 제공하십시오. 이것이 루프를 닫습니다.
또한, 검증하는 눈을 분리하는 것이 중요합니다.
창작자가 스스로 평가하면 관대해집니다. 새 컨텍스트에서 검증 하위 에이전트가 계획과 diff를 비교하게 하십시오. 인간 세계에서 저자와 별도의 검토자가 있는 것과 같습니다.
그리고 마지막으로, 메울 수 없는 격차도 일치했습니다.
장기 컨텍스트 유지.
수십 번의 도구 호출과 몇 시간이 소요되는 작업에서 처음에 결정된 제약 조건을 끝까지 유지하는 능력입니다. 이것은 CLAUDE.md만으로 완전히 채울 수 없습니다.
이것을 숨기면 이 글은 거짓말이 됩니다.
환경 측면의 마무리 작업
CLAUDE.md를 작성하는 것으로 끝나지 않습니다.
Sonnet 5에는 사고 깊이를 지정하는 effort 설정이 있습니다. 공식 대응표에서 Sonnet 5의 "medium"은 Sonnet 4.6의 "high"와 동등하고, Sonnet 5의 "high"는 Sonnet 4.6의 "max"와 동등합니다.
얕은 추론이 보이면 프롬프트를 조정하는 대신 effort를 높이십시오. 이것이 공식 권장 사항입니다.
Claude Code가 항상 깊이 생각하게 하려면 settings.json에 다음을 추가하십시오:
"effortLevel": "high"
이것은 Sonnet 5를 처음부터 "지속적인" 쪽으로 밀어붙입니다.
하지만 CLAUDE.md는 단순히 길기만 해서는 안 됩니다.
이상적으로는 60줄 미만이어야 합니다. 최대 200~300줄입니다. 각 줄에 대해 "이것을 삭제하면 Claude가 실수할까?"라고 물어보십시오. 대답이 '아니오'라면 삭제하십시오.
코드에서 추론할 수 있는 것은 쓰지 마십시오. 표준 관행은 쓰지 마십시오. 린터가 처리할 수 있는 것은 린터에 맡기십시오.
작성해야 할 것은 예측할 수 없는 명령어, 고유한 관행, 테스트 실행 방법, 함정, 아키텍처 결정입니다.
중요한 지침은 처음에 배치하십시오. "권장" 대신 "반드시" 또는 "금지"와 같은 강력한 단어를 사용하십시오.
CLAUDE.md는 AI에 대한 요청 편지가 아닙니다. 팀의 업무 규칙입니다.
여전히 Fable 5를 사용해야 하는 상황
여기까지 읽었다면 "그럼 Fable 5는 필요 없는 거야?"라고 생각할 수 있습니다.
아닙니다.
Fable 5는 필요합니다. 하지만 사용처를 좁혀야 합니다.
메울 수 있는 격차는 정답을 기계적으로 판단할 수 있는 작업에 있습니다.
테스트로 판단할 수 있는 구현 수정. 대량 분류, 추출 및 요약. 어차피 사람이 검토할 작은 변경. 좋은 CLAUDE.md를 갖춘 Sonnet 5는 이러한 작업에서 충분히 경쟁할 수 있습니다.
메울 수 없는 격차는 주로 세 가지입니다.
1. 검사기를 작성할 수 없는 작업.
이 디자인이 괜찮은가? 이 마이그레이션 계획에 허점은 없는가? 도대체 무엇을 구축해야 하는가? 승인 기준 자체를 작성하는 것이 작업의 핵심이라면 먼저 검증 루프를 실행할 수 없습니다.
2. 규칙 적용의 판단.
"간단하게 유지하라"고 써도 모델이 무엇이 간단한지 결정합니다. "허가 없이 추상화하지 마라"고 써도 추상화가 시작되는 지점은 상황에 따라 달라집니다.
3. 장기 컨텍스트 유지.
이것은 원천 성능의 차이입니다. 프롬프트가 개선할 수 있지만 완전히 사라지지는 않습니다.
Fable 5 자체가 제공한 판단 기준이 가장 실용적이었습니다.
승인 테스트를 먼저 작성할 수 있으면 Sonnet을 사용하십시오. 승인 테스트 자체를 작성하기 어렵다면 Fable을 사용하십시오. 확실하지 않으면 Sonnet으로 시작하고, 두 번 연속 재작업이 발생하는 작업에만 Fable로 전환하십시오.
이 정도면 괜찮다고 생각합니다.
처음부터 모든 것을 Fable에 던질 필요는 없습니다. 반대로 모든 것을 Sonnet이 처리할 수 있다고 말하는 것도 경솔합니다.
더 저렴한 Sonnet으로 시작하십시오. 구조로 실패를 줄이십시오. 두 번의 좌절 후에 Fable로 전환하십시오.
이것이 7월 8일 이후 사용처를 차별화하는 현실적인 방법입니다.
오늘 해야 할 일
먼저, 이 글의 7가지 팁을 프로젝트의 CLAUDE.md에 붙여넣으십시오.
다음으로, settings.json에서 effortLevel을 high로 설정하십시오.
그런 다음, 다음 작업에서는 반드시 "성공 조건", "다중 해석", "검증 보고서"를 출력하게 하십시오.
긴 작업의 경우 구현 역할과 검증 역할을 분리하십시오. 창작자가 스스로 평가하게 하지 말고, 다른 컨텍스트의 Claude에게 보여주십시오.
그리고 재작업이 두 번 계속되는 작업에만 Fable 5로 전환하십시오.
Fable 5의 무료 기간이 끝나더라도 끝나는 것은 무료 시식 기간뿐입니다.
정말 유지해야 할 것은 Fable 5의 행동 방식입니다.
Sonnet 5를 Fable 5로 만드십시오.
첫 번째 단계는 매번 긴 마법 프롬프트를 붙여넣는 것이 아닙니다.
작업 템플릿을 CLAUDE.md에 배치하는 것입니다.
하지만 여기까지 읽었다면 이런 생각이 들었을 것입니다.
"설정은 알겠어. 하지만 이 업그레이드된 AI로 무엇을 만들고 어떻게 수익을 내야 할지 모르겠어."
그 반대입니다. 더 저렴해지고 똑똑해진 AI는 고객 유치와 콘텐츠를 대량 생산하는 데 먼저 사용되어야 합니다. Fable 수준의 지속성을 Sonnet에 주입할 수 있다면 일일 포스팅, 기사, 퍼널, 제품 아이디어, 개선 루프를 저렴한 비용으로 실행할 수 있습니다.
구체적인 내용은 제 고정 게시물에 요약되어 있습니다. "AI를 저렴하고 똑똑하게 사용하여 고객 유치 및 수익화에 연결"하는 것을 진지하게 고려하는 분들은 여기로 가십시오 ↓
