Fable을 제대로 쓰는 법: 끝까지 맡기고 검증하기

URL: https://www.youtube.com/watch?v=-XWSJM-Ue-o
날짜: 2026-09-22
채널: t3dotgg
원문 제목: I was using Fable wrong, this is how I fixed it

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Fable 5.1을 더 잘 쓰는 핵심은 모델을 일일이 감시하고 컨텍스트를 관리하는 데 있지 않고, 명확한 완료 상태와 검증 방법을 알려 준 뒤 모델이 끝까지 일하도록 맡기는 데 있다.==

• Fable은 Astra보다 출력 품질의 변동이 작아 장시간 작업과 비동기 작업을 맡기기 쉽다.
• 공식 프롬프트 가이드의 세부 조정법보다 중요한 것은 높은 추론 수준, 사용자-facing 업데이트, 작업 범위와 완료 조건, 검증 수단을 명확히 주는 일이다.
• PR 생성·리뷰 대응·테스트·영상 증거·머지까지 모델이 수행할 수 있으므로, 사람이 모델이 할 수 있는 확인 작업을 반복할 이유가 줄어든다.
• 다만 위험한 변경에서는 스테이징, shadow mode, synthetic traffic, differential test처럼 모델이 실제로 판단할 근거를 제공해야 한다.
• Claude Code의 오래된 사용 습관인 dumb zone 공포, 과도한 컨텍스트 감시, 수동 승인과 과잉 설정은 현재 모델의 능력을 과소평가하게 만들 수 있다.

t3dotgg는 몇 달 전 OpenAI 모델을 좋아한다는 이유로 OpenAI에게 돈을 받는다는 말을 들었지만, 이번에는 Sam Altman에게 Anthropic fanboy라는 말을 들었다고 농담한다. 이유는 일상 업무에서 Astra보다 Fable을 훨씬 선호하기 때문이다. 과거 비교 영상에서 그는 Astra의 최고점은 Fable보다 높지만 최저점도 훨씬 낮고, Fable은 실수가 있어도 훨씬 덜 noisy하다고 설명했다. 이 영상은 두 모델의 재비교가 아니라, 한 달가량 Fable을 혹사하며 얻은 사용법을 Anthropic의 Claude Fable 5.1 프롬프트 가이드와 연결해 정리한 실전 보고서다.

---

1. Fable을 선호하게 된 배경과 이 영상의 범위

Fable의 장점은 단순히 한 번의 답변 품질이 아니라 긴 작업을 계속 맡길 수 있는 일관성에 있다.

1.1. OpenAI 팬에서 Anthropic 팬보이로 불리게 된 이유

1. 모델 선호가 바뀐 것이 아니라 작업 방식에 맞는 모델을 찾았다

   1. 몇 달 전 사람들은 그가 OpenAI가 출시하는 모델을 좋아한다는 이유만으로 OpenAI에게 돈을 받는다고 비난했다.
   2. 그런데 Sam Altman은 그가 Anthropic fanboy라고 불렀다. 일상 업무에서 Astra보다 Fable을 선호한다는 이유였다.
   3. 두 상황 모두 특정 회사의 후원을 받은 것이 아니라, 실제로 써 본 모델의 작업 결과에 대한 개인적 평가에서 나온 말이다.

2. Fable의 낮은 변동성이 장시간 작업을 가능하게 한다

   1. 과거 비교 영상에서 그가 즉흥적으로 그린 그래프는 두 모델의 출력 품질이 일정하지 않다는 감각을 보여 줬다.
   2. Astra는 특정 순간 Fable보다 훨씬 높은 품질을 낼 수 있지만, 다른 순간에는 훨씬 더 나쁜 결과를 낸다.
   3. Fable도 실수한다. 그러나 출력이 훨씬 덜 noisy하기 때문에 결과를 신뢰하기가 쉽다.
   4. 신뢰도가 높으면 모델에게 한 번에 더 오래 일하게 할 수 있고, “끝나면 영상으로 돌아와서 결과를 보여 줘”라고 시킬 수도 있다.
   5. Fable의 작은 품질 하락은 오히려 더 아프게 느껴지므로, 그 하락을 줄이는 프롬프트와 도구가 큰 가치가 된다.

1.2. 작성자의 사용량과 영상의 목표

1. 짧은 기간에 모델을 극단적으로 사용했다

   1. 작성자는 유료로 쓰는 모델 중 이렇게 짧은 시간에 이 정도로 많이 사용한 모델은 거의 없었다고 말한다.
   2. Fable로 엄청난 양의 코드를 출시했고, 다섯 개 계정의 사용량을 사실상 바닥까지 태웠다고 농담한다.
   3. Anthropic의 Prompting Claude Fable 5.1 문서를 더 일찍 읽었더라면 계정을 그렇게 많이 소모하지 않았을 것이라고 말한다.
   4. 공식 문서에는 단순한 프롬프트 문법을 넘어 모델의 행동을 바꾸는 유용한 통찰이 많다.

2. 이 영상이 제공하려는 실전 범위

   1. Agent MD를 고치는 법부터 모델이 계속 일하고 더 나은 결과를 내도록 필요한 도구를 주는 법까지 다룬다.
   2. Fable의 출력물을 Codex로 검증하거나 개선하게 만드는 모델 간 협업도 다룬다.
   3. 단순히 Fable과 Astra 중 어느 쪽이 더 좋다는 결론을 반복하지 않고, 더 넓은 작업 위임 철학을 설명한다.

---

2. 스폰서 구간 1: 에이전트 시대의 버그 관찰과 Sentry

에이전트가 코드를 더 많이 만들수록 사용자가 겪는 버그와 비용을 추적할 수 있는 관찰성(observability)이 중요해진다.

2.1. 에이전트 개발에서 버그가 더 찾기 어려워진 이유

1. 코드 생산량이 늘면 버그의 양과 성격도 바뀐다

   1. 기업은 에이전트 덕분에 과거 어느 때보다 많은 코드를 출시하고 있을 가능성이 크다.
   2. 더 많은 코드를 출시한다는 것은 더 많은 버그도 출시한다는 뜻이다.
   3. 특히 에이전트를 사용해 코드를 만드는 경우뿐 아니라, 사용자에게 에이전트 기능을 제공하는 제품을 만들 때 버그가 더 교묘해질 수 있다.

2. Sentry의 역할

   1. 에이전트 이전부터 개발해 온 사람이라면 Sentry를 애플리케이션의 실제 환경에서 버그를 찾는 대표적인 플랫폼으로 알고 있을 것이라고 설명한다.
   2. 작성자는 오랜 기간 작업한 거의 모든 코드베이스에 Sentry를 설치해 왔다.
   3. Sentry MCP를 사용하면 에이전트도 사람이 보던 애플리케이션 오류 데이터를 직접 활용할 수 있다.

2.2. T3 Code 데모에서 확인한 디버깅 정보

1. 요청 전체와 요청 내부의 비용을 분해한다

   1. 작성자는 T3 Code로 데모를 구성해 trace를 수집했다.
   2. 전체 요청 비용뿐 아니라 요청 안의 각 chunk가 얼마를 소비했는지도 분해해서 보여 준다.
   3. 예시에서 최상위 요청은 약 40센트가 들었고, 중요한 것은 총액보다 그 돈이 어느 단계에서 사용됐는지를 확인할 수 있다는 점이다.

2. Timeline view와 Chat view를 함께 제공한다

   1. Timeline view는 어떤 일이 언제 발생했고 비용이 어디에 들어갔는지 파악하기 좋다.
   2. 작성자는 timeline식 표현이 자신의 사고 방식과는 잘 맞지 않고 실제 작업에는 chat view가 더 익숙하다고 말한다.
   3. Chat view에서는 에이전트나 사용자가 문제를 만들기까지의 대화 transcript를 볼 수 있다.
   4. 화면을 옆으로 밀면 사용 token 수, 발생한 error 수, 실행 비용 같은 정보도 확인할 수 있다.
   5. timestamp를 따라가며 사용자가 실제로 본 순서대로 무엇이 성공했고 무엇이 실패했는지, 각 단계의 비용이 얼마였는지 볼 수 있다.

3. MCP와 전체 파이프라인을 함께 디버깅한다

   1. 커스텀 도구나 에이전트가 사용하는 MCP를 만들 때는 모델이 MCP에 보낸 입력만 확인해서는 부족하다.
   2. MCP를 실제로 서비스하는 코드와 에이전트 요청 전체의 pipeline까지 살펴야 한다.
   3. 이 데모의 안내 주소는 swyd.link/sentry다.

---

3. 공식 프롬프트 가이드: effort level을 어떻게 사용할 것인가

Fable 5.1에서 5로 바뀐 점은 큰 기능 하나가 아니라, 작업 수행 방식에 영향을 주는 미세한 행동 변화의 묶음이다.

3.1. 구독 사용량과 API 가격을 먼저 이해해야 한다

1. 구독 없이 API 정가로 쓰는 상황은 비현실적일 수 있다

   1. 공식 가이드는 모든 effort level을 고려하라고 하지만, 작성자는 구독자에게 한도의 50%만 제공되는 현실을 잊은 조언처럼 느껴져 약간 cringe하다고 말한다.
   2. 자신의 계정처럼 구독으로 보조되는 경우가 아니라면 Fable은 돈값을 하기 어렵다고 평가한다.
   3. API 정가로 이 모델들을 사용하는 것은 너무 비싸 보이며, 그래서 많은 기업이 직원에게 이런 모델을 자유롭게 쓰게 하지 않는 것 같다고 말한다.

2. Fable과 Astra의 비용 패턴이 다르다

   1. 중앙값에 가까운 일반 작업에서는 Fable이 확실히 더 비싸다.
   2. 반대로 극단적인 작업에서는 Astra가 loop에 빠져 필요 이상으로 usage를 태우는 일이 있다.
   3. Fable은 적절한 순간에 멈출 가능성이 조금 더 높다.
   4. 작성자는 비용 비교가 구독 사용량을 전제로 한 이야기임을 거듭 강조한다.

3. 구독 한도의 분배

   1. 구독자의 전체 주간 한도 중 절반은 Fable에 예약된다.
   2. 나머지 절반은 다른 모델에 쓸 수 있지만, 사실상 Opus 5에 할당된다.
   3. 작성자는 Opus 5가 좋은 모델은 아니라고 평가하며, 당시에는 5.1 또는 5.2로 불릴 새 버전이 곧 나와 덜 spiky해지기를 기대했다.
   4. 실제로는 한 주가 끝날 때 Fable 사용량은 0이 되는데 다른 50%는 상당 부분 남는 경우가 많았다고 말한다.

3.2. high를 기본으로 하고 작업에 따라 조절한다

1. 작성자의 기본값은 high다

   1. 공식 가이드는 high에서 시작한 뒤 자신의 eval로 다른 effort level을 시험하라고 권한다.
   2. Claude Code에서 이 정도의 엄밀한 평가를 하는 사람은 많지 않으므로, 익숙한 작업을 각 level로 시켜 감각을 얻는 정도가 현실적이다.
   3. 다만 각 level을 모두 시험하면 token과 시간이 많이 들기 때문에, 작성자는 개인적으로 gut feeling을 권한다.
   4. Fable의 low와 medium은 high보다 실패할 가능성이 높다고 느꼈으므로 기본적으로 high를 사용한다.
   5. 아주 깊고 철저한 작업에서만 가끔 x-high를 사용하고, max는 한도를 태우려는 것이 아니면 거의 사용하지 않는다.

2. 낮은 effort level은 실패 후 재실행 비용을 만들 수 있다

   1. low로 시켰다가 실패하고 medium 또는 high로 다시 하면 최종적으로 더 많은 token을 쓸 수 있다.
   2. 그러므로 작성자는 처음부터 실행하고 결과를 가져오는 것을 선호한다.
   3. low와 medium은 모델이 일찍 멈추게 하거나, rabbit hole에 빠질 것 같은 작업의 깊이를 일부 제한하고 싶을 때 사용하면 된다.
   4. 단순한 작업에 high를 설정해도 모델이 필요하지 않은 reasoning token을 무작정 낭비하지는 않는다.

3. 모델마다 작업 크기에 맞춰 사용량을 조절하는 정도가 다르다

   1. Fable은 Astra만큼 task size에 따라 effort를 세밀하게 조절하지는 않지만, high를 계속 켜 두어도 충분히 효율적이다.
   2. 작성자는 benchmark인 Skatebench에서 Astra가 max와 low 사이의 token 사용량을 거의 늘리지 못하는 사례를 봤다.
   3. Astra의 차이는 최악의 경우 약 50 token, 예를 들어 130 token에서 180 token 정도에 그쳤다.
   4. 반면 같은 작업에서 Gemini 1.5 Pro는 1,000개가 넘는 reasoning token을 사용했다.
   5. Astra는 주어진 window를 작업 크기에 맞춰 사용하는 능력이 더 좋지만, Fable은 high를 기본으로 두기에 충분하다는 결론이다.
   6. 작성자는 시연 중 max로 바꿨다가 high로 되돌리는 것을 잊지 않으려고 직접 언급한다.

3.3. 실전 선택 규칙

1. high를 기본으로 둔다

   1. 대부분의 코드 작업은 high로 시작한다.
   2. 매우 깊은 분석에만 x-high를 추가한다.
   3. max는 일반 업무의 기본값이 아니다.

2. low와 medium을 쓸 상황을 제한한다

   1. 모델이 너무 깊게 파고드는 것을 막고 싶을 때 사용한다.
   2. 단순한 작업을 빨리 끝내고 싶거나 의도적으로 조기 종료시키고 싶을 때 사용한다.
   3. 그 외에는 낮은 level에서 실패한 뒤 재작업하는 위험을 감수하기보다 high에서 한 번에 처리하게 하는 편이 낫다.

---

4. 사용자-facing progress update를 요구하는 법

Fable 5.1은 모델의 내부 진행을 사용자에게 매번 설명하던 Fable 5보다 조용해졌다. 이 행동은 프롬프트로 다시 켤 수 있다.

4.1. 5.1에서 업데이트가 줄어든 이유

1. 이전 모델은 tool call마다 지나치게 설명했다

   1. Opus와 Fable 5는 새 tool call이나 새 batch를 시작할 때마다 “이것을 찾았으니 이제 저것을 하겠다”는 식의 이유와 진행 상황을 자주 말했다.
   2. 그 결과는 솔직히 말하면 noisy했다.
   3. Anthropic은 Fable 5.1에서 장시간 tool call turn 동안 이런 user-facing update를 훨씬 적게 쓰도록 바꿨다.

2. 사용자에 따라 조용한 모델이 더 좋을 수 있다

   1. 작성자는 Fable이 아무 업데이트도 없이 150회의 tool call을 실행해도 괜찮다고 말한다.
   2. 그는 T3 Code에서 prompt를 시작하고 repository를 command-shift-O로 지정한 뒤, 다른 thread를 보러 간다.
   3. 작업이 끝났을 때 결과만 확인하는 자신의 방식에는 중간 진행 보고가 필요하지 않다.
   4. 반대로 작업 중 trace를 보고 싶은 사람에게는 업데이트를 요구하는 것이 간단한 해결책이다.

4.2. 사용할 수 있는 진행 보고 프롬프트

1. 시스템 프롬프트 또는 skill에 짧은 지침을 추가한다

   1. “시작하기 전에 무엇을 하려는지 한 줄로 말하라.”
   2. “작업하는 동안 사용자가 따라올 수 있도록 짧은 업데이트를 제공하라.”
   3. “마지막에는 독립적으로 읽어도 전체 상황이 보이는 짧은 요약을 작성하라.”
   4. 마지막 요약에는 무엇을 발견했고, 무엇을 했고, 다음에 무엇이 남았는지를 포함한다.

2. UI가 tool output을 숨기는 앱은 모델에게 상황을 알려야 한다

   1. 애플리케이션이나 제품이 tool output을 접어 버리거나 사용자에게 보여 주지 않는다면 모델은 그 UI가 대신 보여 줄 것이라고 가정한다.
   2. 따라서 tool output이 사용자에게 직접 보이지 않는다는 사실을 시스템 프롬프트에 알려야 한다.
   3. 작성자는 T3 Code가 tool call output을 거의 보여 주지 않는 방향이라 이 지침을 제품에 넣을 수도 있다고 말한다.

4.3. 대화 기록 편집과 reasoning trace

1. history를 중간에서 편집하면 reasoning trace가 유지되지 않는다
   1. 네 개의 메시지가 있는 thread에서 첫 번째나 두 번째 메시지를 편집하면 해당 thread의 reasoning을 계속 유지할 수 없게 된다.
   2. 과거 대화가 바뀌면 reasoning이 그 대화를 전제로 만들어진 것이므로, 모델이 가진 trace를 그대로 이어 가기 어렵다.
   3. Anthropic은 이를 distillation attack을 막기 위한 조치라고 설명한다.
   4. 작성자는 다소 silly해 보여도 앞으로 이런 보호 조치가 더 나타날 것이라고 예상한다.

---

5. 문체와 포맷을 프롬프트로 바로잡기

Fable 5.1의 출력 문체는 이전 Claude 계열의 전형적인 slop에서 개선됐지만, 사용자가 싫어하는 문체를 명시하면 더 좋아진다.

5.1. mannered prose를 제거한다

1. Fable 5.1의 문체 개선

   1. 공식 가이드는 예전 Claude 모델보다 stock phrase와 설명되지 않은 jargon이 줄었다고 평가한다.
   2. 대신 어떤 경우에는 Fable 5보다 산문이 더 dense해졌다.
   3. 문장이 길어지고 paragraph break가 줄어들 수 있다.

2. mannered prose의 정의

   1. mannered prose는 직접적인 문장 대신 은유와 장식을 사용해 글쓴이의 솜씨를 드러내는 문체다.
   2. “바꿔 볼 가치가 있는 parameter”를 “돌려 볼 만한 dial”이라고 쓰는 것이 한 예다.
   3. “이 지점은 여전히 중요하다”를 “이 지점은 제 몫을 해낸다(this point earns its keep)”로 바꾸는 것도 같은 문제다.
   4. 문구가 아이디어를 전달하기보다 글쓴이를 과시하기 위해 존재하면 독자는 그 의도를 알아차린다.
   5. 이런 문체는 글쓴이가 공연하는 동안 독자에게 더 많은 해석 노동을 시키기 때문에 irritate한다.

3. 가장 간단한 해결책

   1. 긴 정의와 어색한 예시를 system prompt에 모두 넣을 필요는 없다.
   2. “Please remove all mannered prose”라고 직접 요구하는 것만으로도 충분할 수 있다.
   3. 작성자는 이 조언에 강하게 동의하며, 이런 문체를 Claude slop의 한 형태로 본다.

5.2. 과도한 bullet과 bold를 금지하는 설정을 재검토한다

1. anti-formatting 지침이 오히려 오래된 문제를 고정할 수 있다

   1. 이전 모델이 채팅에서 bullet과 bold를 과도하게 사용했기 때문에 많은 prompt에는 “bullet과 bold를 쓰지 말라”는 규칙이 들어갔다.
   2. 어떤 모델이 원래 50%의 확률로 이를 사용한다면 규칙이 사용률을 10%까지 낮출 수 있다.
   3. 하지만 최신 모델이 원래 10%만 사용한다면 동일한 규칙이 사용률을 1%까지 낮추지 못하고 어정쩡한 행동을 남길 수 있다.
   4. 따라서 과거 문제를 해결하려고 넣었던 behavioral instruction이 현재 모델에 필요한지 다시 측정해야 한다.

2. Claude MD와 Agent MD를 정리한다

   1. Claude MD에 formatting 관련 behavioral instruction이 많다면 우선 삭제하고 지침 없이 어떻게 동작하는지 확인한다.
   2. 작성자는 자신의 Agent MD나 Claude MD에 formatting 관련 지침을 전혀 두지 않았으며 오히려 사용하기 편해졌다고 말한다.
   3. 최신 Claude Code는 Claude MD가 없을 때 Agent MD를 대신 사용한다.
   4. 예전에 저렴하고 덜 똑똑한 모델이나 Open Coder Codex 같은 도구에 맞춰 작성한 Agent MD가 있다면, Fable과 Claude Code가 이제 그 내용까지 읽을 수 있다.
   5. 팀이 공유 Agent MD를 바꾸지 못하게 한다면 Claude.local.md 같은 로컬 파일에서 그 지침을 무시하라고 지정할 수 있다.

5.3. 인용 표시도 예시로 가르친다

1. 출처 문장을 인용부호 없이 복제하는 문제

   1. 모델은 source text의 passage를 인용 표시 없이 그대로 재현하는 나쁜 습관을 보일 수 있다.
   2. Fable 기반 제품을 만드는 경우가 아니라면 큰 문제는 아닐 수 있지만, 발생하면 바로 교정할 수 있다.

2. 해결 방법

   1. 원하는 인용 표시 방식의 예시를 prompt에 제공한다.
   2. 모델이 그 예시를 따라 source text의 인용 구간을 더 명확하게 표시하게 한다.

---

6. 작업 전체를 끝내게 하는 prompt와 babysit skill

Fable 5.1은 목표가 명확하면 방법론을 자세히 설명하지 않아도 매우 긴 작업을 수행한다. 문제는 복잡한 비동기 작업에서 모델이 실제 완료 전에 다음 계획만 말하고 멈출 수 있다는 점이다.

6.1. Finish the whole task

1. 끝까지 하라는 nudge를 넣는다

   1. 모델이 “다음에는 이 일을 하겠다”라고 말하고 turn을 끝내면 “좋다, 지금 가서 해라”라고 다시 시켜야 한다.
   2. Fable은 Astra보다 이런 조기 종료가 훨씬 적지만, 복잡한 비동기 작업에는 “작업이 끝날 때까지 turn을 종료하지 말라”는 지침이 유용하다.
   3. skill 하나나 짧은 프롬프트 변경만으로 모델을 계속 움직이게 할 수 있다.

2. 긴 작업에서 목표의 선명도가 방법론보다 중요하다

   1. 무엇을 어떻게 할지 모두 설계해 주기보다, 무엇이 완료된 상태인지 명확하게 쓰는 편이 Fable 5.1의 능력을 더 잘 활용한다.
   2. 모델이 스스로 필요한 조사, 수정, 테스트, 보고 순서를 선택하게 한다.

6.2. pull request를 맡기는 babysit PR skill

1. skill의 목적

   1. 사용자가 PR을 watch 또는 babysit하라고 하면 모델이 계속 업데이트와 새 comment를 확인한다.
   2. 사용자가 thread를 다시 확인할 때쯤에는 PR이 병합 가능한 상태가 되도록 하는 것이 목표다.

2. 검토 comment와 CI를 다루는 규칙

   1. 모든 repository에는 여러 AI review bot이 있고, 항상 옳지는 않지만 유용한 신호를 준다는 전제로 시작한다.
   2. harness가 PR monitor 도구를 제공하면 그 도구를 사용해 새 comment에 대응한다.
   3. monitor 도구가 없으면 새 comment와 check를 polling한다.
   4. 가장 최근 push보다 새로 생긴 comment와 check만 처리한다.
   5. bot이 지적한 모든 내용을 source code와 대조해 검증한 뒤 실제 finding만 수정한다.
   6. 실제 finding과 CI failure를 고친다.
   7. repository 구분, main의 변경, rebase 등 해당 저장소의 규칙을 계속 감시한다.
   8. 겹치는 PR 때문에 현재 PR이 쓸모없어지면 monitoring을 멈추고 사용자에게 보고한다.
   9. PR 종료 권한이 명시적으로 주어지지 않았다면 사용자의 확인 없이 닫지 않는다.
   10. review bot의 feedback을 실제로 고칠 가치가 있다고 판단하면 글로 답하고 comment를 resolve한다.

3. PR comment 작성 규칙과 scope creep 방지

   1. Theo를 대신해 comment를 쓸 때마다 작성자의 leaving PR comment skill을 사용한다.
   2. 그 skill은 comment 형식을 정하고, 상단에 AI agent가 작성했다는 짧은 disclaimer를 넣는다.
   3. 일부 모델, 특히 Soul은 babysit 중 scope creep하는 경향이 있었다.
   4. 그래서 “scope creep하지 말라. 새 기능을 추가하지 말라. 실제 문제만 해결하라. filler comment를 남기지 말라”는 규칙을 추가했다.
   5. 이 두 가지 callout을 끝에 넣자 필요하지 않은 comment를 쓰는 문제가 크게 줄었다.

6.3. T3 Code의 screenshot/rendering 문제를 맡긴 사례

1. 문제를 조사하는 prompt

   1. T3 Code에서 모델이 screenshot을 찍고 image를 render하는 과정에 문제가 생겼다.
   2. 작성자는 깊게 직접 조사하는 대신 Fable에게 screenshot과 thread ID를 주고 원인 분석과 PR 작성을 모두 맡겼다.
   3. 핵심 요구는 “특정 T3 Code thread에서 무엇이 잘못됐는지 전부 파악하고, T3 Code 측에서 고칠 수 있는 만큼 고쳐 PR을 하나만 만들어라”였다.
   4. preview environment에서 preview image에 접근하지 못했고, 저장에도 문제가 있는 듯했으며, thread history의 tool call과 실패 기록을 thread ID로 찾아 root cause를 파악하라고 했다.
   5. 여러 개의 임시 수정 대신 문제를 명확하고 단순하게 해결하는 단일 PR을 요구했다.

2. 다른 기여자의 PR과 비교하는 방식

   1. PR을 올리자마자 다른 사람이 닫힌 자신의 PR이 더 낫다고 주장했다.
   2. 작성자는 Fable에게 상대 PR을 확인해 더 낫다면 다시 열어 완성하거나 commit을 가져와 새 PR을 만들라고 했다.
   3. 현재 PR이 더 낫다면 modernize해 완료 상태로 준비하라고 했다.
   4. 어떤 선택이 맞는지 사용자가 미리 정하지 않고, 두 PR의 데이터와 실제 결과를 보고 모델이 결정하게 했다.

3. 모델의 판단을 신뢰할 수 있게 된 결과

   1. Fable은 다른 기여자의 PR이 더 좋은 base라고 verdict를 내렸지만, 상대 PR의 save-to-disk 기능과 현재 PR의 두 가지 thread-breaking bug 수정도 비교했다.
   2. 상대 PR에서 두 가지를 가져오고 발견한 bug를 고쳤다.
   3. main 위에서 PR을 최신 상태로 modernize하고 review comment를 계속 처리했다.
   4. 작성자가 돌아왔을 때 새 finding이 없었고 merge 가능해 보여 직접 merge button을 눌러 thread를 끝냈다.
   5. 작성자는 예전처럼 모델이 제시한 선택지 중 하나를 고르는 데 시간을 덜 쓰고, 모델이 좋은 결정을 내릴 수 있도록 필요한 정보와 선택권을 주는 데 더 시간을 쓴다고 말한다.

---

7. 위험한 YOLO 작업: Lakebed 엔진 변경을 Fable이 검증한 사례

이 사례는 일상적인 대규모 production codebase에 그대로 적용하라는 권고가 아니다. 좋은 staging, QA, test 시스템이 있을 때 실험할 수 있는 위험한 workflow의 예시다.

7.1. Lakebed와 Rusty V8 변경

1. 프로젝트의 성격

   1. Lakebed는 작성자가 slop app을 위한 더 나은 slop cloud를 만들려는 실험 프로젝트다.
   2. 그는 자체 runtime을 만들었지만, 실제로는 Astra와 함께 Rusty V8을 fork하고 몇 가지 무모한 수정을 한 것이다.
   3. runtime은 놀랍게도 약 26,000줄이며, 전체 cloud 코드의 절반 정도다.
   4. JavaScript slop project에 Rust가 많지 않다는 점을 농담처럼 덧붙인다.

2. 위험한 PR

   1. 사용자 코드가 표준 Node isolates가 아니라 자체 engine에서 실행되도록 바꾸는 일은 무서운 변경이다.
   2. Astra가 만든 작업을 무조건 merge하지 않고, PR 주장과 screenshot을 Fable에게 주며 “성능에는 도움이 되지만 크고 위험한 변경이다. merge해도 되는지 솔직하게 말해 달라”고 했다.
   3. Fable은 merge하지 말라고 답했다.

7.2. Fable이 지적한 위험

1. 변경 자체의 구조적 위험

   1. migration을 되돌리기 어려운 one-way door다.
   2. 하나의 PR에 세 가지 기능이 동시에 들어가 있다.
   3. 아직 human approval이 없다.
   4. 기본값이 native로 전환됐기 때문에, 실행 방식에 따라 source runtime이 일종의 kill switch가 될 수 있다.
   5. 작성자가 혼자 작업하는 codebase라는 사실은 human approval 부재를 없애 주지 않는다.

2. 성과 주장과 실패 정보의 부족

   1. headline 숫자만으로 live queries가 애플리케이션의 중요한 비중을 차지한다는 것을 입증할 수 없다.
   2. 설명되지 않은 failure도 있었다.
   3. 따라서 단순히 벤치마크 숫자가 좋아졌다는 이유로 production에 넣어서는 안 된다.

7.3. staging에서 무엇을 검증할 수 있는가

1. Fable의 현실적인 답변

   1. 작성자는 기존 deployment가 아직 공식 출시 전이라 크게 걱정되지 않는다고 설명하며, staging에서 위험을 줄이는 방법을 물었다.
   2. Fable은 staging에서 crash, latency, resource problem은 어느 정도 디버깅할 수 있다고 했다.
   3. 그러나 잘못된 query result는 자신 있게 디버깅할 수 없다고 했다.
   4. 이 silent bug가 가장 무서운 종류이므로, 답변 상단에 굵게 표시할 만큼 핵심 위험으로 다뤘다.

2. 당시 staging이 가진 신호

   1. Railway logs와 metrics가 있었다.
   2. engine crash 정보와 health Z endpoint가 있었다.
   3. Axiom event도 활성화돼 있으면 사용할 수 있었다.
   4. 반대로 maintained view가 잘못됐다는 신호는 없었다.
   5. 재현 경로도 없었고 traffic도 없었다.
   6. 따라서 당시 staging은 사실상 매우 한산한 빈 환경이었다.

3. staging을 충분히 만들 조건

   1. shadow mode가 필요하다.
   2. refresh failure가 발생했을 때 구조화된 이유를 남겨야 한다.
   3. staging에 synthetic traffic을 흘려야 한다.
   4. health Z에 runtime counter를 추가해야 한다.
   5. 그래야 crash와 latency만이 아니라 실제 query 결과의 동작도 비교할 수 있다.

7.4. 모델에게 테스트 환경을 확장하게 한 과정

1. 새 branch에서 confidence boost를 만들게 했다

   1. 작성자는 Fable에게 기존 overhaul branch 위에 새 branch를 만들어 자신이 요구한 신뢰성 강화 장치를 전부 구현하라고 했다.
   2. 아직 장기 branch의 merge 여부가 확정되지 않았고 프로젝트가 중요 production 서비스가 아니므로, 작성자가 원하지 않을 수도 있는 합리적인 실험 변경을 허용했다.
   3. Fable이 제안한 변경은 대체로 합리적으로 들렸기 때문에 이 권한을 줬다.

2. 약 60분 동안 자동으로 확장했다

   1. 약 60분 뒤 새 branch가 만들어졌고, 모델은 추가한 내용을 설명했다.
   2. 작성자는 PR을 열라고 명시하지 않았기 때문에 Fable이 branch만 만든 것을 처음에는 아쉽게 여겼다.
   3. 곧바로 PR을 열라고 말하자 PR이 생성됐다.
   4. 작성자가 “이 정도면 테스트를 시작해도 되는가? 그렇다면 8200으로 merge한 뒤 전체에도 merge하라”고 하자, Fable은 작업을 계속했다.

3. 중간 개입은 네트워크 문제 때문이었다

   1. Fable은 한 시간 34분 동안 계속 일했다.
   2. 작성자가 돌아온 이유는 네트워크 성능과 작업 중인 컴퓨터가 나빠졌기 때문이었다.
   3. 이때 Fable이 medium reasoning을 사용 중이었는데도 한 시간 반을 계속 일할 수 있었다.
   4. 작성자는 모델에게 현재 방식이 IP 주소를 망가뜨리고 사실상 DDoS를 하고 있다고 말하며, 다른 container에서 실행할 방법을 찾되 자신의 IP를 더 이상 괴롭히지 말라고 했다.
   5. 모든 변경은 merge된 뒤 시스템은 정상화됐다.

7.5. shadow mode, 성능 측정, 실제 위험의 재평가

1. 노트북을 사용한 접근의 문제

   1. Fable은 laptop에서 직접 실행한 현재 접근이 왜 잘못됐는지 설명했다.
   2. shadow mode는 무료가 아니므로 동일 작업을 병렬로 수행하는 만큼 느려진다는 점도 명시했다.
   3. 작성자는 shadow mode를 가장 쉽게 끄고 현재 production build보다 실제 성능이 얼마나 좋아졌는지 측정하자고 했다.
   4. 확인 결과 shadow mode는 이미 꺼져 있어 추가로 바꿀 것은 없었다.

2. 42분간의 성능 조사

   1. Fable은 여러 호출을 실행하며 성능 개선을 찾았다.
   2. 작성자는 이 과정이 42분간 진행됐다고 기록한다.
   3. 모델이 직접 benchmark와 비교를 수행했기 때문에 작성자는 단순한 주장보다 실제 숫자와 원인을 얻었다.

3. 처음 의심한 위험과 실제 위험의 차이

   1. 작성자가 마지막에 “처음에는 회의적이었는데 최종적으로 이 변경은 merge할 가치가 있었는가?”라고 물었다.
   2. Fable은 회의 자체는 올바른 방향이었지만 대상이 잘못됐다고 답했다.
   3. 작성자는 silent wrong query result를 가장 걱정했다.
   4. 실제로 incremental path는 삭제, range change, journal gap, budget miss 등 조금이라도 의심이 생기면 receive를 거부할 만큼 편집증적으로 안전했다.
   5. differential test는 160단계 동안 1,400회의 receive를 강제로 수행했지만 잘못된 결과를 한 번도 내지 않았다.
   6. Fable은 diff의 크기를 위험의 기준으로 봤지만, 실제 위험은 운영 방식과 네트워크·리소스 문제였다.
   7. 이 분석 덕분에 작성자는 코드를 직접 작성했을 때보다 코드와 위험, 수정 방법을 더 잘 이해하게 됐다고 말한다.

4. 후속 PR까지 맡겼다

   1. Fable이 추가로 바꾸고 싶은 부분을 언급하자 작성자는 engine pre-warm인 file 212를 PR로 만들라고 했다.
   2. 이어서 PR을 babysit하고 comment를 처리하며 모든 것이 green이고 변경에 만족하면 merge하라고 했다.
   3. 그 뒤 작성자는 thread를 다시 보지 않아도 됐다.

7.6. 위험한 실험에 대한 경고

1. 모든 codebase에 적용할 수는 없다

   1. 이 방법은 중요한 대형 codebase에서 일상적으로 따라 하라는 조언이 아니다.
   2. staging, QA, test 시스템이 충분할 때에만 이런 YOLO workflow를 실험해야 한다.
   3. 모델이 아직 이 일을 항상 안전하게 할 수준이 아닐 수도 있지만, 이미 놀랄 만큼 잘하는 수준에 가까워졌다고 평가한다.

2. 미래의 개발 방식

   1. 모델이 더 reliable해지면 수백 명의 동료와 수백만 명의 사용자가 있는 거대한 제품에서도 팀이 이런 식으로 일하게 될 것이라고 예상한다.
   2. 그 미래가 생각보다 가까이 와 있다고 말한다.

---

8. 서로 다른 모델을 검증자와 구현자로 조합하기

Fable과 Astra의 강점을 따로 활용하면 한 모델의 결과를 다른 모델이 검증하는 반복 루프를 만들 수 있다.

8.1. Claude와 Codex의 역할 차이

1. macOS computer use는 Codex가 더 낫다

   1. 작성자는 Claude가 Codex보다 computer use를 잘하지 못한다고 느낀다.
   2. 특히 macOS에서는 그 차이가 더 크게 나타난다.
   3. 따라서 컴퓨터에 저렴한 Codex sub-agent라도 설정해 두면 Fable이 Codex를 호출해 화면 조작과 결과 검증을 맡길 수 있다.

2. Fable과 Astra의 역할 분담

   1. Fable과 Astra 모두 변경 제안과 코드 review를 매우 철저하고 사려 깊게 수행한다.
   2. 그중 Astra가 review에는 조금 더 낫다고 느낀다.
   3. 반대로 실제 코드를 작성하는 능력은 Fable이 훨씬 낫다고 평가한다.
   4. 그래서 Fable에게 Astra에게 변경을 review하거나 테스트해 달라고 요청하게 한다.

3. 검증 실패 시 모델이 다시 고치게 한다

   1. “Astra에게 이 변경을 검증해 달라”고 말하면 Fable이 Astra를 호출한다.
   2. 검증이 실패하거나 Astra가 나쁜 점을 지적하면 Fable은 코드에 반영한다.
   3. 그 뒤 다시 테스트하고, 만족스러운 결과가 나올 때까지 사용자에게 돌아오지 않는다.

8.2. 에이전트 능력에 대한 정신 모델을 리셋한다

1. 과거의 모델 기준으로 현재 모델을 제한하지 않는다

   1. Fable 5와 일관성·신뢰성이 높아진 5.1 이전에 에이전트 능력에 대한 mental model을 만들었다면 그 모델을 다시 설정해야 한다.
   2. 현재 모델이 작업을 얼마나 잘 유지하고 끝까지 수행하는지 직접 확인하면 놀랄 수 있다.

2. 사람이 해야 할 일은 선택이 아니라 판단 조건을 제공하는 것이다

   1. 모델이 스스로 검증할 수 있는 작업이라면 사람이 매 단계 결과를 읽고 다음 지시를 내릴 필요가 없다.
   2. 모델이 무엇을 확인해야 하는지, 어떤 위험은 멈춰야 하는지, 어느 상태를 완료로 볼지를 주는 것이 더 중요하다.

---

9. 모든 prompt에 명확한 end state를 넣는다

Fable을 제대로 활용하는 핵심은 “무엇을 하라”에서 끝내지 않고 “어디까지 도달하면 끝인가”를 쓰는 것이다.

9.1. 완료 조건의 여러 형태

1. 업무별로 다른 종료점을 명시한다

   1. PR을 모든 check가 green이 될 때까지 babysit하라고 할 수 있다.
   2. 모든 것이 green이고 모델이 변경에 만족하면 merge하라고 할 수 있다.
   3. PR만 열고 사용자에게 PR이 생성됐다고 알려 달라고 할 수도 있다.
   4. 질문을 한 뒤 조건이 충족되면 merge와 test까지 진행하라고 할 수도 있다.

2. 조건부 경로를 함께 제공한다

   1. 모델이 변경에 만족하지 않으면 어떤 문제가 남았는지 사용자와 다시 논의할 수 있다.
   2. 모델이 만족하면 한 시간 반 동안 사용자 개입 없이 계속 작업할 수 있다.
   3. 사용자는 T3 Code의 marker가 다시 확인할 시점을 알릴 때까지 해당 작업을 머릿속에서 내려놓을 수 있다.
   4. 목표는 thread로 되돌아가는 횟수를 작업이 끝날 때까지 최소화하는 것이다.

9.2. 넓은 prompt가 더 높은 위임 효과를 만든다

1. 모델이 할 수 있는 확인을 사람이 반복하지 않는다

   1. 작성자는 많은 사용자의 prompt가 숫자를 받는 함수에 숫자인지 확인하는 코드를 또 넣는 것처럼 보인다고 비유한다.
   2. 모델은 입력이 무엇인지, 무엇이 동작하고 무엇이 동작하지 않는지 스스로 검사할 수 있다.
   3. 모델이 확인할 수 있는 부분까지 사람이 별도로 확인하면 Fable의 장점을 사용하지 못한다.

2. TypeScript 비유

   1. TypeScript의 가치는 코드에 type safety를 추가하는 데만 있지 않다.
   2. TypeScript가 한 종류의 bug를 제거하면, 원래 그 bug를 찾던 뇌의 공간을 더 중요한 문제에 쓸 수 있다.
   3. 컴퓨터가 애플리케이션 전체의 type safety를 검증할 수 있는데 사람이 같은 검사를 반복하면 뇌를 효율적으로 쓰는 것이 아니다.
   4. 마찬가지로 모델이 root cause를 찾고, 수정하고, 수정 결과를 검증하고, 결과 영상까지 찍고, PR을 올리고, review comment에 대응한 뒤 완료를 알릴 수 있다면 사람이 그 각 단계를 직접 반복할 이유가 줄어든다.

3. 그래도 중복 검증이 필요한 경우

   1. 작성자는 코드가 틀렸다는 말이 아니다.
   2. 외부에 노출된 함수나 API가 올바른 방식으로 호출되는지는 TypeScript만으로 보장되지 않을 수 있다.
   3. 같은 검사를 두 번 하거나 네 번 확인해야 하는 상황도 있다.
   4. 그러나 그런 상황이 사람들이 생각하는 만큼 흔하지는 않으며, 모델과 함께 일하면서도 불필요한 중복 검증을 하는 사람은 뇌의 일부를 낭비하게 된다.

---

10. 스폰서 구간 2: General Translation과 에이전트 기반 localization

앱을 영어 하나로만 제공하면 잠재 사용자의 상당 부분을 잃을 수 있으므로, 에이전트가 작성하는 코드에 localization을 내장하는 접근을 소개한다.

10.1. 다국어 지원의 세 가지 상태

1. 영어 하나만 사용하는 앱

   1. 세계 인구의 85% 이상은 영어를 모른다는 통계를 제시한다.
   2. 앱이 영어만 지원한다면 상당한 잠재 사용자를 놓칠 수 있다.

2. 직접 만든 번역 stack

   1. 어떤 팀은 localization을 자체 구축한다.
   2. 그러면 한 장소에서 쓴 단어가 다른 장소에서는 다르게 번역되는 문제가 생긴다.
   3. 여러 앱·웹사이트·플랫폼 사이에서 용어가 불일치하고, 번역 stack을 계속 유지보수해야 한다.

3. General Translation을 사용하는 팀

   1. Cursor, Ramp, Partyful, ClickHouse 등이 이 서비스의 사용자로 소개된다.
   2. 블로그와 docs부터 mobile app과 web app까지 중요한 모든 surface의 localization을 관리할 수 있다고 설명한다.

10.2. source code와 glossary 중심의 동작

1. 에이전트가 작성하는 코드에 직접 통합한다

   1. General Translation은 source-code level에서 동작한다.
   2. 에이전트가 이미 작성하는 코드와 직접 통합해 어떤 문자열이 필요한지 정의하고 localization 전에 export하기 쉽게 한다.
   3. 플랫폼을 한 번 설정하면 에이전트가 translatable code를 자동으로 작성한다.
   4. PR을 올리면 CI가 실행되어 localization 작업이 이어진다.

2. 용어집으로 일관성을 유지한다

   1. 여러 화면과 제품 surface에서 동일하게 써야 하는 용어를 glossary에 정의할 수 있다.
   2. 번역이 화면마다 달라지는 문제를 줄일 수 있다.
   3. 안내 주소는 soitof.link/gt다.

---

11. compaction, 범위 통제, safeguard를 다루는 방법

공식 가이드에는 작업 결과가 긴 대화에서 사라지지 않게 하는 법과, 모델이 요청 밖의 변경을 하지 않게 하는 법이 포함돼 있다.

11.1. compaction summary에 보존할 내용을 지정한다

1. 무엇을 잊지 말아야 하는지 알려 준다

   1. 모델이 compaction 후 특정 사실을 잊거나 작업 맥락을 놓친다면 Agent MD에 보존 규칙을 추가한다.
   2. Fable을 사용하는 애플리케이션을 직접 만들고 있다면 system prompt에서 지정한다.
   3. Fable이 자기 thread의 compaction을 수행하므로, 무엇을 유지해야 하는지 말해 주면 실제로 그 정보를 기억하도록 compaction할 수 있다.

2. compaction을 과하게 걱정할 필요는 없다

   1. 작성자는 일반적으로 사람들이 compaction을 과도하게 고민한다고 말한다.
   2. 문제가 실제로 나타났을 때 보존 항목을 구체적으로 지정하는 방식이 적절하다.

11.2. 요청하지 않은 파일 변경과 test code를 막는다

1. open-ended request의 부작용

   1. 모델은 요청하지 않은 주변 파일을 고치거나, 근처의 bug를 함께 수정하거나, task에 없던 behavior를 확장할 수 있다.
   2. 작성자는 자신의 prompt가 이런 행동을 막고 있는지 모르지만, Fable이 예상보다 reserved해서 이 문제를 많이 겪지는 않았다고 말한다.

2. 복사해서 쓸 수 있는 범위 통제 문구

   1. “요청하지 않은 추가와 commit된 test code는 task 성공률을 측정 가능하게 낮추지 않으면서 크게 줄어든다”는 원칙을 제시한다.
   2. 실제 지침은 다음과 같다.
      • 작업하거나 테스트하는 중 pre-existing bug, 성능 문제, task에 언급되지 않은 behavior를 발견해도 이번 변경에서 고치거나 최적화하거나 확장하지 않는다.
      • 요청한 behavior가 그것 없이는 동작하지 않을 때만 예외로 한다.
      • 그 외의 발견은 summary에서 follow-up으로 보고한다.
   3. 이 문장을 그대로 붙여 넣으면 scope 밖의 변경을 크게 줄일 수 있다고 설명한다.

11.3. low effort의 search와 safeguard false positive

1. low effort가 search를 생략할 수 있다

   1. low effort를 많이 권하지는 않지만, low에서 search가 필요한데 실행하지 않는 문제가 있으면 prompt에 search를 사용하라고 직접 쓴다.

2. 안전장치가 오해하지 않게 질문을 표현한다

   1. safeguard는 사용자가 프로그램을 공격하거나 해킹하려 한다고 오해할 수 있다.
   2. “이 프로그램이 error 없이 compile되는가?”라고 묻기보다 “이 프로그램에 bug가 있는가?”라고 묻는 편이 false positive를 줄일 수 있다.
   3. 잘 알려지지 않은 programming language를 사용할 때는 그 언어의 작동 방식과 문서 링크를 context에 넣는다.
   4. 정보가 없으면 모델이 binary를 해킹해 내부를 알아내려는 식으로 탐색하다가 safeguard를 건드릴 수 있다.
   5. base64가 context나 output에 들어가면 내용을 숨기거나 난독화하려는 것으로 오해받을 가능성이 커진다.
   6. 가능한 경우 base64를 대화 context에서 제거하면 false positive를 줄일 수 있다.
   7. 작성자는 수천 번의 prompt 중 Fable 5.1에서 false positive가 대략 다섯 번뿐이었다고 말해 큰 문제는 아니지만, 문제가 있는 사람에게는 유용한 세부 사항이라고 덧붙인다.

---

12. sub-agent를 실행하는 동안 lead agent도 계속 일하게 한다

Fable 기반 애플리케이션을 만드는 경우에 가까운 지침이지만, 여러 에이전트를 운용하는 개발자에게도 의미가 있다.

12.1. 병렬 실행의 이점

1. lead agent가 기다리기만 하지 않는다

   1. Fable 5.1과 Astra 모두 sub-agent에게 일을 위임하면서 top-level agent의 작업을 계속할 수 있다.
   2. sub-agent 결과를 기다리는 동안 아무것도 하지 않고 멈추는 대신, 관련 코드를 수정하거나 다음 작업을 준비할 수 있다.
   3. sub-agent에 추가 메시지를 보내고, 받은 finding을 테스트하며, 다음 단계가 무엇인지 판단할 수도 있다.

2. 사용자에게 더 짧은 대기 시간과 더 넓은 실행 범위를 제공한다

   1. lead agent와 sub-agent가 동시에 움직이면 한 번의 thread에서 처리할 수 있는 일이 늘어난다.
   2. 이 방식은 단순한 병렬화뿐 아니라, 결과를 기다리면서 검증 루프를 계속 유지하는 구조다.

12.2. vision 작업은 crop과 zoom을 제공한다

1. 큰 이미지를 통째로 보여 주는 것보다 도구가 낫다
   1. vision 작업은 crop과 zoom 도구가 있을 때 성능이 더 좋아진다.
   2. 모델은 local Python script로 이미지를 직접 crop하거나 확대할 수 있다.
   3. 일반 Claude Code 사용에서는 덜 중요할 수 있지만, Fable을 핵심으로 제품을 만드는 경우에는 도구 설계에 반영할 만하다.

---

13. 가장 큰 조언: 오래된 Claude Code 사용 습관을 버린다

사람들이 Fable의 능력을 놓치는 가장 큰 이유는 현재 모델이 아니라 과거 Claude Code의 제약을 기준으로 작업하기 때문이다.

13.1. dumb zone 공포에 도전한다

1. 오래된 mental model

   1. 많은 개발자는 thread가 얼마나 많은 context를 쓰는지 계속 감시하지 않으면 dumb zone에 들어간다고 걱정한다.
   2. dumb zone에 들어가면 하루 동안 한 일이 무너지고, token을 낭비하고, 결과가 망가져 해고될 수 있다는 식으로 생각한다.
   3. 작성자는 이를 개발자 사이에 퍼진 과도한 공포라고 부른다.

2. Anthropic이 나쁜 기본값을 출시했을 것인가

   1. Anthropic은 flagship model을 최대한 잘 작동시키기 위해 막대한 인력, 도구, 검증 작업을 투입했다.
   2. 그런 회사가 모델이 가장 잘 작동해야 하는 기본값에 엉뚱한 context cutoff를 넣었을 것인지 생각해 보라고 한다.
   3. context window의 수치는 본질적으로 임의의 경계이며, API가 허용하면 1,000억 token도 보낼 수 있다.
   4. Anthropic이 100만 token을 선택한 것은 그 지점부터 성능 저하가 충분히 나타날 수 있다고 판단했기 때문이다.
   5. 따라서 100만 token에 도달하는 순간 모델이 갑자기 멍청해지는 dumb zone은 크게 중요하지 않다.

3. T3 Code에서 context monitor를 없앤 이유

   1. 현대 모델은 compaction과 긴 실행을 관리하는 능력이 좋아졌다.
   2. T3 Code UI에는 현재 사용 중인 context 양을 보여 주는 monitor가 없다.
   3. 모델이 이 문제를 스스로 관리하도록 training loop가 개선됐기 때문이다.
   4. 작성자는 T3 Code에서 context monitoring을 제거한 Maria에게 “그럴 배짱이 있다”고 농담하며 감사한다.
   5. 채팅에서 Maria가 자신을 칭찬하고 있었다는 말까지 덧붙여 분위기를 가볍게 만든다.

13.2. 1 million context와 cache를 이해하는 방식

1. context 관리 비용

   1. 100만 token context는 read 비용이 높으면 비싸질 수 있다.
   2. 전체 context를 매번 새로 쓰는 것이 아니라 기존 위에 append write를 쌓고, compaction을 자주 하면 context를 다시 쓰는 비용이 늘어난다.
   3. compaction 시작점을 낮추면 비용이 커질 수 있다.

2. cache 가격 인하와 실제 영향

   1. Anthropic이 cache read 비용을 75% 낮췄기 때문에 context window 크기는 예전만큼 중요한 문제가 아니라고 주장한다.
   2. 예외는 cache가 만료된 경우다.
   3. T3 계열 도구는 cache 상태를 보여 주며, “less context로 resume”하는 선택지를 제공한다.
   4. 예를 들어 이전 527,000 token이 아직 cached되지 않았다면 빠르게 compaction하는 것이 나을 수 있다.
   5. 핵심은 사용자가 모든 context를 직접 추적하기보다, 모델과 도구가 제공하는 상태 신호를 보고 필요한 때만 개입하는 것이다.

13.3. 모르는 내부 동작은 모델에게 추측시키지 않는다

1. 모델에게 compaction을 물어도 정확하지 않을 수 있다

   1. 작성자는 시청자가 헷갈리면 평소처럼 모델에게 물어보라고 권할 수 없다고 말한다.
   2. 모델에게 Codex에서 compaction이 어떻게 작동하는지 물으면 자신 있게 틀린 답을 만들기 쉽다.
   3. 실제로 그런 답을 받은 사람들이 댓글과 reply에 많이 나타났다고 한다.

2. 가장 안전한 대응

   1. 내부 동작이 혼란스럽거나 걱정될 때는 default를 바꾸지 않는다.
   2. 작성자가 자신의 Claude Code 설정에서 바꾼 것은 기본 fullscreen과 proxy layer를 통한 routing뿐이다.
   3. memory는 껐다. 일부 사람에게는 유용할 수 있지만 자신에게는 유용하지 않다고 판단했기 때문이다.
   4. 그 외에는 Claude Code의 기본값을 그대로 사용한다.

13.4. T3 Code가 노출하는 설정의 의미

1. compaction threshold를 직접 구현한 것이 아니다

   1. T3 Code에 compaction threshold 조절 기능이 있다고 생각하는 질문이 나왔지만, 작성자는 T3 Code가 별도의 threshold 기능을 제공하지 않는다고 말한다.
   2. 사용자가 자신의 config에서 바꾼 값이 T3 Code에서도 동작하는 것은 T3 Code가 컴퓨터의 Claude Code 설정을 그대로 사용하기 때문이다.

2. 200K와 1M context 선택

   1. T3 Code는 200K context와 1M context 사이를 선택하는 옵션을 노출한다.
   2. 이유는 Claude Code도 그 옵션을 제공하기 때문이다.
   3. T3 Code가 특별히 “이렇게 해야 한다”고 판단한 설정이 아니라, 기존 도구의 옵션을 사용자에게 노출한 것이다.

---

14. 기본값을 믿고, 오래된 안전장치와 맞춤 설정을 재평가한다

도구가 좋아졌다면 과거의 결함을 보완하려 만든 설정이 현재는 오히려 방해가 될 수 있다.

14.1. 과도한 설정을 줄인다

1. 최근 1년 이상 존재하지 않은 문제를 해결하지 않는다

   1. 많은 사용자가 이미 사라진 문제를 해결하기 위해 복잡한 context 관리와 자동화 설정을 계속 유지한다.
   2. 모델은 context를 스스로 관리하는 능력이 좋아졌고, 컴퓨터의 여러 도구도 충분히 잘 사용한다.
   3. 사용자가 모델 대신 context를 관리하거나 모든 도구를 일일이 설정할 필요가 줄었다.

2. 권한과 자동 승인 모드

   1. 작성자는 accept edits나 supervised 같은 모드를 사용하지 말라고 강하게 말한다.
   2. T3 Code에 anti-gravity 지원을 추가한 뒤, Gemini 모델을 충분히 신뢰할 수 없고 auto mode가 없다는 이유로 accept edits를 추가해 달라는 요구를 많이 받았다.
   3. 그는 anti-gravity 지원을 없애 버릴 뻔했다고 농담한다.
   4. supervised와 auto accept edits는 최신이라 해도 2024년의 도구에 가깝다고 평가한다.
   5. 조심스럽게 사용할 때는 auto를, 더 큰 권한이 필요할 때는 full을 사용하라는 단순한 원칙을 제시한다.

14.2. 새 컴퓨터처럼 다시 시작한다

1. mental model과 설정을 함께 리셋한다

   1. 도구가 좋아졌으므로 과거의 결함을 피해 가려고 만든 customization은 대체로 낡았을 수 있다.
   2. 모델이 할 수 있는 일에 대한 사용자의 mental model도 낡았을 수 있다.
   3. 새 컴퓨터를 받은 것처럼 생각하고, Claude Code를 처음부터 최소한으로 설치한다.
   4. 불필요한 설정, 오래된 Agent MD 규칙, 수동 감시 절차를 처음부터 모두 추가하지 않는다.

2. 문제를 만났을 때만 작은 해결책을 추가한다

   1. 최소 설정으로 실제 능력을 확인한다.
   2. 특정한 작은 문제가 재현될 때만 그 문제를 해결하는 작은 지침이나 도구를 하나씩 추가한다.
   3. 이 방식이 기존의 복잡한 설정을 그대로 유지하는 것보다 현재 모델의 능력을 공정하게 평가하게 한다.

---

15. 영상의 최종 메시지

Fable 5.1은 단순히 Fable 5보다 조금 나아진 모델이 아니라, 개발자가 에이전트와 협업하는 방식을 다시 설계하게 만드는 모델이다.

15.1. 도구의 품질보다 사용자의 위임 방식이 중요하다

1. 모델에게 더 넓은 책임을 준다

   1. 모델이 조사하고, 수정하고, 테스트하고, 결과를 기록하고, PR을 만들고, 리뷰에 대응하고, merge할 수 있다면 작업 단위를 넓혀야 한다.
   2. 사람은 각 단계를 매번 클릭하는 대신 완료 조건과 안전 경계를 정의한다.
   3. 모델이 실패하거나 자신 없다고 말해야 하는 경로도 prompt에 포함한다.

2. 검증 가능한 근거를 제공한다

   1. 위험한 작업에서는 staging, logs, metrics, synthetic traffic, shadow mode, differential test를 준비한다.
   2. 모델에게 “안전해 보이니 해라”가 아니라 “어떤 신호가 있으면 안전하다고 판단할 것인가”를 준다.
   3. 다른 모델이나 Codex를 reviewer로 연결해 결과를 다시 확인한다.

15.2. Fable 5.1에 대한 개인적 결론

1. 일상 개발에 미친 영향

   1. 작성자는 Fable 5.1이 동작과 성능의 incremental improvement로 시작했지만, 일상 업무에서는 그 이상이 됐다고 말한다.
   2. 모델이 긴 작업을 유지하고, 판단을 내리고, 결과를 검증하고, 마지막 상태까지 갈 수 있게 되면서 개발자의 역할이 달라졌다.
   3. 작성자는 Fable을 매우 좋아하며 시청자도 좋아할 것이라고 말한다.

2. 마무리

   1. Fable을 좋아하지 않는다면 왜 그런지 댓글로 알려 달라고 한다.
   2. 마지막 인사는 “peace nerds”라는 가벼운 표현으로 끝난다.

---

주요 발언 모음

“Fable still makes its mistakes, but it was less noisy by far.”
“Fable도 실수하지만, 훨씬 덜 noisy하다.”

“Finish the whole task.”
“작업 전체를 끝내라.”

“Every prompt should have a pretty clear place where it stops when it’s done.”
“모든 prompt에는 일이 끝났을 때 멈출 명확한 지점이 있어야 한다.”

“If the model can do the work of verifying the type safety across your app, then you are not using your brain well if you’re letting your brain do that same work.”
“모델이 앱 전체의 type safety를 검증할 수 있는데 사람이 그 일을 반복한다면 뇌를 제대로 쓰는 것이 아니다.”

“My skepticism was in the right place, but aimed at the wrong thing.”
“내 회의는 방향은 맞았지만, 겨냥한 대상이 틀렸다.”

“If you’re not really doing that, you’re not really taking advantage of the benefits these models give you.”
“모델이 할 수 있는 검사를 직접 반복한다면 이런 모델이 주는 이점을 제대로 활용하는 것이 아니다.”

“The tools are good now. Reset it.”
“도구는 이제 충분히 좋아졌다. mental model을 리셋하라.”

“Pretend you’re on a brand new machine, delete everything, install Claude Code from scratch, set it up with as little as possible.”
“새 컴퓨터를 받은 것처럼 생각하고, 전부 지운 뒤 Claude Code를 최소한으로 처음부터 설정하라.”

---

핵심 데이터 & 수치

• 구독 한도 50%: 작성자는 구독자에게 Fable용 주간 사용량의 절반이 예약되고 나머지는 사실상 Opus 5에 쓰인다고 설명한다.
• five accounts: 짧은 기간 동안 Fable로 코드를 많이 작성해 다섯 개 계정의 사용량을 모두 소진할 정도로 사용했다.
• 약 40센트: Sentry의 T3 Code demo에서 최상위 agent request 하나의 비용으로 제시된 값이다.
• 150회 tool call: 작성자는 Fable이 사용자 업데이트 없이 150회의 tool call을 수행해도 자신은 괜찮다고 말한다.
• 26,000줄: Lakebed의 자체 runtime은 Rusty V8 fork 기반으로 약 26,000줄이며 cloud 코드의 절반 정도다.
• 60분: Fable이 Lakebed의 confidence-boost branch를 구성하는 데 걸린 시간이다.
• 1시간 34분: 작성자가 medium reasoning에서 Fable을 약 1시간 30분 이상 계속 일하게 한 실행 사례다.
• 42분: shadow mode가 꺼진 상태에서 Fable이 성능 개선을 확인하기 위해 추가 호출과 측정을 수행한 시간이다.
• 1,400회 / 160단계: differential test가 160 steps 동안 1,400회의 receive를 수행했지만 wrong answer를 내지 않은 결과다.
• 85% 이상: 영어를 모국어로 사용하지 않는 세계 인구가 85% 이상이라는 General Translation sponsor 구간의 통계다.
• 75%: cache read 비용이 75% 낮아져 1M context window의 비용 부담이 예전보다 덜 중요해졌다는 설명이다.
• 527,000 token: cache가 아직 유효하지 않다면 빠른 compaction을 고려할 수 있는 이전 context의 예시다.
• 약 5회: 수천 개 prompt 중 Fable 5.1에서 경험한 safeguard false positive의 대략적인 횟수다.
• 200K / 1M: T3 Code가 Claude Code에서 노출하는 context window 선택지다.
• 130→180 token: Skatebench에서 Astra가 low와 max 사이에 보인 최악의 추가 사용량 예시다.
• 1,000+ reasoning token: 같은 benchmark에서 Gemini 1.5 Pro가 사용한 reasoning token의 예시다.
• 한 시간 반: 명확한 완료 조건을 주면 모델을 사용자 개입 없이 계속 일하게 할 수 있다는 대표적인 시간 범위다.

---

결론 및 시사점

1. Fable의 핵심 강점은 최고점보다 낮은 noise와 높은 지속성이다. 단일 답변의 화려함보다 긴 작업을 안정적으로 끝내는 능력이 실제 개발 생산성에 더 중요하다.
2. 대부분의 작업은 high를 기본값으로 둔다. low와 medium은 조기 종료나 rabbit hole 방지가 명확할 때만 사용하고, 깊은 작업에 x-high를 추가한다.
3. 모델이 조용히 일하게 할지 진행 상황을 보여 줄지는 prompt로 정한다. 기본 행동을 제품 UI가 어떻게 처리하는지까지 모델에게 알려 줘야 한다.
4. mannered prose와 오래된 formatting 규칙은 직접 제거한다. 현재 모델이 이미 해결한 문제를 과거의 anti-slop 지침으로 다시 만들지 않는다.
5. Claude MD와 Agent MD를 반드시 재검토한다. Claude MD가 없으면 최신 Claude Code가 Agent MD를 사용하므로 과거 모델용 지침이 Fable에 갑자기 영향을 줄 수 있다.
6. prompt에는 “끝까지 하라”와 정확한 end state를 함께 쓴다. PR 생성, 모든 check green, merge, 사용자 보고 중 원하는 종료점을 분명히 지정한다.
7. 모델이 할 수 있는 검증은 모델에게 맡긴다. 사람이 매 단계 확인하는 대신 테스트·리뷰·영상·PR·merge까지 이어지는 넓은 작업 단위를 준다.
8. 위험한 변경은 모델의 자신감이 아니라 관측 가능한 신호로 판단한다. staging과 synthetic traffic, shadow mode, structured failure reason, differential test가 그 근거를 제공한다.
9. 다른 모델을 reviewer로 연결하면 역할 분담이 좋아진다. Fable은 코드 작성, Astra는 review, Codex는 macOS computer use와 화면 검증에 활용할 수 있다.
10. compaction과 dumb zone을 과도하게 관리하지 않는다. cache 만료나 실제 재현된 문제처럼 확인 가능한 신호가 있을 때만 개입한다.
11. 요청하지 않은 변경은 명시적으로 범위를 제한한다. pre-existing bug와 주변 성능 문제는 이번 변경에 필요하지 않다면 follow-up으로 보고하게 한다.
12. safeguard false positive는 질문의 표현과 context로 줄인다. 언어 문서와 의도를 제공하고 base64처럼 난독화로 오해받을 수 있는 데이터를 피한다.
13. 오래된 auto-approval 습관을 버리고 기본값을 다시 시험한다. 새 컴퓨터에서 Claude Code를 최소 설정으로 설치한 뒤 실제 문제가 생길 때만 맞춤화를 추가한다.
14. 현재 모델의 능력에 맞춰 mental model을 리셋한다. 과거 에이전트가 못 하던 일을 아직도 사람이 대신하고 있지 않은지 계속 의심해야 한다.
15. 개발자의 역할은 모든 동작을 직접 수행하는 것이 아니라 선택 조건과 안전 경계를 설계하는 쪽으로 이동한다.

---

핵심 요약 (20줄)

1. Fable은 Astra보다 출력 변동성이 작아 긴 코드 작업을 끝까지 맡기기 쉽다.
2. Fable의 낮은 noise는 한 번의 최고 품질보다 장시간 작업의 신뢰성과 지속성을 높인다.
3. 구독자가 아니라 API 정가를 내고 Fable을 사용하는 방식은 비용 대비 효율이 낮을 수 있다.
4. 대부분의 작업에서 Fable의 reasoning effort는 high를 기본값으로 두는 편이 안정적이다.
5. low와 medium은 조기 종료나 rabbit hole 방지가 필요할 때만 제한적으로 사용해야 한다.
6. 사용자에게 진행 상황을 보여 주고 싶다면 시작·중간·종료 업데이트를 prompt로 직접 요구하면 된다.
7. Fable 5.1은 tool call 진행 보고를 줄였지만 150회 이상 조용히 작업하는 방식도 지원한다.
8. mannered prose는 직접적인 설명 대신 은유와 장식으로 글쓴이를 과시하는 문체다.
9. “모든 mannered prose를 제거하라”는 짧은 지침만으로 Claude식 산문을 줄일 수 있다.
10. 오래된 Claude MD와 Agent MD의 formatting 규칙은 최신 모델의 자연스러운 출력을 방해할 수 있다.
11. 복잡한 비동기 작업에는 작업이 끝날 때까지 turn을 종료하지 말라는 nudge가 필요하다.
12. babysit PR skill은 새 comment와 CI를 검증하고 실제 문제만 고친 뒤 green 상태까지 유지한다.
13. 모델이 PR의 대안과 근거를 비교하게 하면 사람이 선택지를 직접 고르는 시간이 줄어든다.
14. Lakebed 실험은 Fable이 risky migration의 silent bug와 운영 위험을 구분할 수 있음을 보여 준다.
15. differential test는 160단계 1,400회 receive에서 잘못된 결과를 한 번도 만들지 않았다.
16. Fable은 코드 작성에, Astra는 review에, Codex는 macOS computer use와 검증에 활용할 수 있다.
17. 모든 prompt에는 PR 생성·merge·보고처럼 모델이 멈출 명확한 end state가 있어야 한다.
18. 모델이 type safety와 테스트를 확인할 수 있는데 사람이 같은 검사를 반복하면 집중력을 낭비하게 된다.
19. 1M context의 dumb zone을 두려워하기보다 cache 만료 같은 실제 신호가 있을 때만 개입해야 한다.
20. Claude Code를 최소 설정으로 새로 시작하면 낡은 customization보다 현재 모델의 능력을 정확히 확인할 수 있다.