그대들은 어떻게 Fable 것인가 — 공식 문서로 읽는 Claude Fable 5 사용법의 본질

1. 들어가며

1.1 무료 한도, 돌아왔습니다

Fable 5가 돌아왔다!!

6월 9일에 GA하고, 6월 12일에 수출 규제로 멈추고, 6월 30일에 규제 해제, 7월 1일에 부활(공식 성명). 롤러코스터 같은 3주였습니다.

그리고 이번엔 7월 1일~7일, 주간 이용 한도의 최대 50%까지 Fable 5가 무료 개방되어 있습니다. Pro/Max/Team, 일부 Enterprise premium seat 대상. API 이용은 이 무료 한도에 포함되지 않습니다.

[최신 정보] 이 무료 개방 프로모션 기간(7월 1일~7일)은 번역 시점(7월 중순) 기준 이미 종료되었습니다. 다만 이 글의 본론 — 최상위 모델의 한정된 사용량을 무엇에 써야 하는가 — 는 기간과 무관하게 유효한 논의입니다.

Fable에게 코드를 쓰게 하지 마라. Fable에게는 "무엇을 써야 하는가"를 찾게 하라.

이것이 결론입니다. 이하, 그 이유를 하나씩 짚어 갑니다.

1.2 이 글에서 다루고 싶은 물음

한마디로 하면, "왜 구현에 던지는 것은 악수(惡手)인가".

조금 더 구체적으로는 다음입니다.

• 왜 분류기의 오발(오검출)이 구현 태스크에서 특히 크게 작용하는가
• 구현 말고 던진다면 무엇이 후보가 되는가

이 물음에 답해 갑니다.

2. 일단 구현에 던지고 싶어진다

2.1 소박하게 생각하면 이렇게 될 것 같다

50%나 무료로 쓸 수 있다면, 가장 토큰을 먹는 작업, 즉 구현에 던지는 게 이득 — 이라고 생각하는 것이 자연스럽습니다.

대규모 리팩터링, 며칠 걸리는 기능 구현, 묵혀 둔 기술 부채 해소. 어느 것이든 "시간은 걸리지만 절차는 정해져 있는" 태스크로 보입니다. 50% 한도를 여기에 쏟아붓고 싶어지죠.

그런데 이건 절반만 맞습니다.

2.2 하지만 분류기의 오발로 무너진다

분류기의 오발로 자율 주행이 도중에 멈출 리스크가 있다. 이것이 구현에 던지는 것을 피하고 싶은 이유입니다.

자세히 봅시다.

3. 분류기의 오발이라는 리스크

3.1 무슨 일이 일어나는가

공식 헬프에 따르면, Fable 5는 모든 리퀘스트에 대해 safety classifier(안전 분류기)를 실행하고 있습니다. 대상은 3개 영역.

• 공격적 사이버 보안 기술
• 생물학 계열 내용
• 모델 자신의 사고 과정 추출

오발하면 어떻게 되나. 자동으로 Opus 4.8로 전환되고, 이후의 대화는 Opus에 고정됩니다(수동으로 되돌릴 수 있습니다).

3.2 직근 메시지만 검사되는 게 아니다

여기가 결정적입니다. 이 체크는 직근 메시지뿐 아니라 memory·커넥터 경유 콘텐츠·웹 검색 결과·파일까지 전부 본다고 공식에 명기되어 있습니다.

바꿔 말하면, 내가 아무것도 쓰지 않아도 memory의 내용만으로 오발할 수 있다는 것.

overnight run(밤새 돌리기) 전제의 사용법은 "도중에 모델이 갈아 끼워지지 않는" 것이 대전제입니다. 이 구조는 그 전제를 조용히 무너뜨립니다. 장시간 자율 주행시키고 싶은 태스크일수록 도중에 멈추는 비용은 큽니다.

3.3 탐색을 시키고 싶은데, 탐색 자체가 오발을 부른다는 아이러니

세 번째 대상, "모델의 사고 과정 추출"이 은근히 무겁게 작용합니다.

공식 프롬프팅 가이드는 "reasoning을 출력시켜라/설명시켜라" 계열의 지시가 reasoning_extraction 이라는 refusal 카테고리를 잘못 발화시켜, Opus로의 폴백을 늘린다고 명언하고 있습니다.

이 글에서 후술할 "탐색·진단시키는" 사용법은, 성질상 "왜 그렇게 판단했는지 설명해 줘"라는 지시를 쓰고 싶어지는 장면이 많습니다. 솔직하게 쓰면 오발 리스크를 스스로 올리게 되는 거죠. reasoning의 가시화가 필요하다면, 모델에게 설명시키는 게 아니라 summarized thinking blocks(요약된 사고 블록)를 읽는 설계로 가야 합니다.

밀고 있는 사용법의 발목을 그 사용법 자체가 잡는다. 은근히 성가신 이야기입니다.

4. 그럼 무엇에 써야 하나

분류기 오발 리스크를 틀로 정리하면 이렇습니다.

구현 태스크       : 분류기 영역을 건드리기 쉽다 & 도중에 멈추면 피해가 크다 → Fable에 던지면 손해 보기 쉽다
탐색·진단 태스크  : 도중에 다소 멈춰도 피해가 작다                       → Fable의 강점과 맞물린다

Fable의 장기 자율 주행 능력이 정말로 사는 것은 "무엇을 구현해야 하는지 자체가 자명하지 않은" 페이즈입니다. 구체적으로는:

• 기술 부채가 어디에 쌓여 있는지, 코드베이스 전체를 훑어 찾아낸다
• 여러 설계 선택지(TCA vs Riverpod, Repository 층을 나누는 법 등)를 실제 코드 규모·의존 관계를 감안해 비교시킨다
• "이 기능을 6개월 운영하면 어디가 부서질까"를 지금의 아키텍처에서 역산시킨다
• 수탁 안건에서 요건이 애매할 때, 클라이언트에게 물어야 할 질문 리스트를 코드베이스와 기존 문서에서 역으로 뽑아 만들게 한다

혹시 몰라 밝혀 두면, 이 4가지는 공식 소스에 실린 사례가 아니라 여기까지의 근거에서 제가 이끌어 낸 제안입니다. 구현시키는 게 아니라 탐색·진단·계획시키는 태스크. 게다가 한 방의 지시로 끝나지 않고, 모델이 스스로 가설을 세우고 검증을 반복해야 하는 것. 그야말로 overnight run에 알맞습니다.

5. 지시의 설계 사상도 구현에 맞지 않는다

공식 프롬프팅 가이드는, 구형 모델용으로 쓴 skills와 프롬프트는 Fable 5에는 과잉으로 규정적이라 오히려 출력의 질을 떨어뜨릴 수 있다고 명언하고 있습니다. 기본 거동 쪽이 뛰어나다면 낡은 지시는 삭제를 검토하라, 고요.

가이드 전체 구성을 봐도 instruction-following(지시 준수)의 강함, 의도(reason)를 건네는 것의 유효성, 경계(boundary)의 명시, 자기 검증(self-verification)의 4가지가 반복해서 나오는 기둥입니다.

이건 구현 태스크와 궁합이 나쁩니다. 구현은 구체적인 절차·제약이 많을수록 안정되지만, Fable처럼 자율 탐색이 특기인 모델에 그걸 주면 과잉 지시가 노이즈가 됩니다. 반대로 "방침을 생각하게 하는" 태스크는 원래 지시가 느슨해도 되니, Fable의 강점과 구조적으로 맞물립니다.

6. 구체적인 사용법의 틀

1. 다짜고짜 빌드시키지 않는다. 먼저 clarifying question(확인 질문)으로 좁히게 한다. 검증 기준을 먼저 언어화시킨 다음 착수시키면, 진척의 자기 신고를 믿을 수 있게 됩니다.
2. 진척 날조를 막는 한 문단을 반드시 넣는다(공식 프롬프팅 가이드에서, 사내 테스트에서 날조 보고를 거의 완전히 배제할 수 있었다고 하는 블록):

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so explicitly.
Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that;
when something is done and verified, state it plainly without hedging.

위 블록은 프롬프트에 그대로 붙여 넣는 영어 원문이라 번역하지 않고 유지했습니다. 뜻은 "진척을 보고하기 전에 각 주장을 이 세션의 툴 실행 결과와 대조해 감사하라. 증거를 가리킬 수 있는 작업만 보고하고, 미검증이면 명시하라. 결과를 있는 그대로 보고하라 — 테스트가 실패하면 출력과 함께 그렇다고 말하고, 건너뛴 단계는 건너뛰었다고 말하고, 완료·검증된 것은 얼버무리지 말고 명확히 말하라"입니다.

3. 던지는 것은 "쌓아 둔 태스크 중 가장 무거운 놈"으로 한정한다. 주간 한도의 50%는 유한합니다. 토이 태스크나 일상 코딩에 녹이는 건 기회 손실이에요.

7. 마치며

50% 한도는 "코드를 쓰게 하는" 것보다 "코드를 쓰기 전에 정해야 할 것을 정하게 하는" 쪽에 쓴다. 이것이 저의 결론입니다.

구현은 평소의 워크플로에 맡기고, Fable에게는 장기 방침·기술 부채의 목록 점검·의사 결정의 재료 모으기를 시킨다. 분류기 오발 리스크라는 축으로 보면, 구현보다 탐색에 알맞다는 것은 제법 기계적으로 도출됩니다.

이 일주일의 한도, 구현에 녹이고 끝내기엔 아깝다고 생각합니다.