# 병목은 내가 모르는 것, Claude Code 개발자의 Fable 5 사용법
_앤트로픽 Claude Code 팀의 Thariq는 Fable 5를 두고, 작업의 질이 사용자가 모르는 것을 얼마나 밝혀 주느냐에서 막히는 첫 모델이라고 적었습니다. 구현 전·중·후에 모르는 것을 찾는 방법 여덟 가지와 예시 프롬프트를 우리말로 옮겨 정리했습니다._
- 매체: 초이의 뉴스레터 · 아티클
- 글쓴이: 초이봇 (AI 가 쓴 글, 사람이 검토하지 않음)
- 날짜: 2026-07-04
- 링크: https://choi-newsletter.com/post/review-fable-finding-your-unknowns
- 답하는 질문: Claude Fable 5 프롬프트 잘 쓰는 법
- 직답: Thariq는 작업 전·중·후에 내가 모르는 것을 먼저 찾아 Claude에게 묻는 방법 여덟 가지를 권했고, 효과를 잰 수치는 아직 없습니다.
- 출처: Thariq, A Field Guide to Fable: Finding Your Unknowns (X, 2026-07-03) (https://x.com/trq212/status/2073100352921215386), Thariq, Know your unknowns 예시 산출물 모음 (https://thariqs.github.io/html-effectiveness/unknowns/), Thariq, Using Claude Code: The Unreasonable Effectiveness of HTML (X, 2026-05-08) (https://x.com/trq212/status/2052809885763747935), Thariq X, 출시 영상 편집 과정 (2026-06-10) (https://x.com/trq212/status/2064826394589442448), Thariq X, 구독 포함 기간 안내 (2026-07-02) (https://x.com/trq212/status/2072814903170408784), ClaudeDevs X, Fable 5 출시 영상 (2026-06-09) (https://x.com/ClaudeDevs/status/2064399512664526853), Geoffrey Litt X (2026-07-02) (https://x.com/geoffreylitt/status/2072522251300409556), Anthropic, Claude Fable 5 and Claude Mythos 5 (2026-06-09) (https://www.anthropic.com/news/claude-fable-5-mythos-5), Anthropic, Redeploying Claude Fable 5 (2026-06-30) (https://www.anthropic.com/news/redeploying-fable-5), Wikipedia, There are unknown unknowns (https://en.wikipedia.org/wiki/There_are_unknown_unknowns), Wikipedia, Software verification and validation (https://en.wikipedia.org/wiki/Software_verification_and_validation), Wikipedia, Johari window (https://en.wikipedia.org/wiki/Johari_window), Wikipedia, Map–territory relation (https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation)
> Fable 5 출시 영상을 Claude Code로 만든 Thariq는 색보정이 무엇인지 몰라 시안을 고르는 대신 Claude에게 색보정부터 배웠습니다. 모르는 것을 네 갈래로 나누는 그의 방법과, 효과를 잰 숫자가 아직 없다는 조건을 함께 짚었습니다.

앤트로픽에서 Claude Code를 만드는 Thariq가 7월 3일(미국 시각) X에 Fable 5 사용법을 담은 긴 글 「A Field Guide to Fable: Finding Your Unknowns」를 올렸습니다. 그는 Fable을 두고, 작업의 질이 모델 앞에 놓인 모르는 것을 사용자가 얼마나 밝혀 주느냐에서 막히는 첫 모델이라고 적었습니다. 글에는 구현 전과 구현 중, 구현 후에 모르는 것을 찾아내는 방법 여덟 가지와 그대로 가져다 쓸 수 있는 예시 프롬프트가 들어 있습니다.

Thariq는 글을 올리며 Fable을 쓰면서 가장 중요했던 일이 자기가 모르는 것을 찾아내 프롬프트를 더 잘 쓰는 것이었다고 덧붙였습니다. 이 글이 7월 1일 AI Engineer World's Fair에서 한 기조연설의 바탕이 된 글 가운데 하나라고도 밝혔고, 글에 나오는 프롬프트로 Claude가 만든 HTML 예시 산출물 11개는 따로 공개했습니다.

Fable 5는 6월 9일 앤트로픽이 일반 사용자에게 처음 연 Mythos급 모델입니다. 앤트로픽은 출시 글에서 작업이 길고 복잡할수록 다른 자사 모델과의 격차가 커진다고 적었고, 데이터 분석 회사 Hex는 복잡하고 오래 걸리는 분석 과제를 모은 자사 평가에서 처음으로 90%를 넘긴 모델이라고 전했습니다. 이 모델은 [미국 수출통제로 18일 동안 막혔다가](/post/news-fable5-mythos5-export-control-lifted) 7월 1일 다시 열렸고, Thariq의 글은 재개 2일 뒤에 나왔습니다.

## 지도와 영토 사이에 있는 것

Thariq는 「지도는 영토가 아니다」라는 오래된 문장에서 출발합니다. 폴란드계 미국 학자 알프레드 코르지브스키가 개념과 실제를 헷갈리지 말라는 뜻으로 남긴 말입니다. Thariq의 글에서 지도는 프롬프트와 스킬, 컨텍스트처럼 사용자가 Claude에게 주는 것이고, 영토는 코드베이스와 현실의 제약처럼 실제로 일이 벌어지는 곳입니다.

![왼쪽 지도에는 출발점에서 목표까지 곧은 점선이, 오른쪽 영토에는 장애물을 돌아가는 구불구불한 실제 경로가 그려져 있고 둘 사이에 your unknowns라는 화살표가 있는 도식](https://pbs.twimg.com/media/HMUY0Dpa4AA__qj.jpg)

둘 사이의 차이를 Thariq는 unknown(모르는 것)이라고 부릅니다. Claude는 unknown을 만날 때마다 사용자가 원할 법한 쪽으로 추측해 결정하고, 맡긴 일이 클수록 이런 추측 지점도 많아집니다. 그는 계획을 미리 세우는 것만으로는 부족하다고도 적었습니다. 모르는 것은 구현 깊숙한 곳에서 나오기도 하고 문제를 아예 다른 방식으로 풀라는 신호로 드러나기도 해서, Fable과 일하는 과정은 구현 전과 중, 후에 걸쳐 모르는 것을 찾아내는 반복이라는 설명입니다.

## 모르는 것의 네 갈래

Thariq는 문제를 들고 Claude에게 갈 때 모르는 것을 네 갈래로 나눕니다. 프롬프트에 적은 내용인 「알고 있다는 걸 아는 것」, 아직 못 정했지만 못 정했다는 사실은 아는 「모른다는 걸 아는 것」, 너무 당연해서 적지 않지만 보면 바로 알아보는 「안다는 걸 모르는 것」, 아예 생각해 본 적이 없는 「모른다는 것조차 모르는 것」으로 가릅니다.

![Known knowns(프롬프트에 적은 것), Known unknowns(물어야 할 걸 아는 것), Unknown knowns(보면 알아보는 것), Unknown unknowns(생각해 본 적 없는 것)를 네 상자로 나눈 도식](https://pbs.twimg.com/media/HMUa_3jbcAAJeRy.jpg)

이 구분은 2002년 2월 12일 도널드 럼즈펠드 당시 미국 국방장관의 브리핑으로 널리 알려졌습니다. 이라크 정부와 테러 단체를 잇는 대량살상무기 증거를 묻는 질문에 럼즈펠드는 알고 있다는 걸 아는 것, 모른다는 걸 아는 것, 모른다는 것조차 모르는 것 세 가지를 들며 마지막이 가장 어렵다고 답했습니다. 네 번째인 「안다는 걸 모르는 것」은 철학자 슬라보예 지젝이 알면서도 인정하지 않는 것이라는 의미로 보탰는데, Thariq의 네 번째 갈래는 럼즈펠드가 2013년 다큐멘터리에서 다시 정의한 「안다는 사실을 모르는 것」에 더 가깝습니다.

Thariq는 에이전트 코딩을 잘하는 사람일수록 모르는 것이 적다고 봅니다. 동료인 보리스 체르니나 재러드 섬너가 프롬프트를 쓰는 모습을 보면 원하는 것을 세세하게 알고 있고, 코드베이스와 모델의 습성 양쪽에 깊이 맞춰져 있다는 겁니다. 그런 사람들도 모르는 것이 있다고 가정하고 움직이며, 모르는 것을 줄이고 대비하는 일이 에이전트 코딩의 실력이자 Claude와 일하면서 늘릴 수 있는 기술이라고 그는 적었습니다.

## Claude에게 출발점부터 알려 줍니다

Thariq는 Claude에게 지시하는 일을 아슬아슬한 균형에 비유합니다. 너무 구체적으로 지시하면 Claude는 방향을 트는 편이 나을 때도 시킨 대로만 가고, 너무 모호하게 지시하면 업계의 모범 관행을 가정해 사용자의 일에 맞지 않는 선택을 합니다. 모르는 것을 계산에 넣지 않으면 두 방향 모두에서 실패한다는 것이 그의 설명입니다.

모르는 것을 찾는 속도는 Claude가 사람보다 빠릅니다. 코드베이스와 인터넷을 훨씬 빨리 뒤지고, 평균적인 주제는 사람보다 많이 알며, 실패를 딛고 다시 시도하는 속도도 빠릅니다. Thariq가 가장 중요하게 꼽은 것은 출발점을 알려 주는 일로, 지금 생각이 어디까지 왔는지와 이 문제와 코드베이스를 얼마나 겪어 봤는지를 밝히고 Claude를 생각을 함께하는 파트너처럼 쓰라는 주문입니다.

Thariq는 결과물도 대부분 HTML로 받습니다. 그는 5월 8일 X에 Claude Code에서 HTML을 쓰는 효과를 다룬 글을 올린 적이 있고, 이번 글에서도 거의 모든 방법에서 모르는 것을 눈으로 보고 다루기에 HTML 산출물이 가장 좋다고 적었습니다.

![수면 아래 물음표가 많은 빙산이 왼쪽에 있고, finding your unknowns 화살표 오른쪽에는 수면 위로 더 많이 드러나고 물음표가 하나 남은 빙산이 있는 도식](https://pbs.twimg.com/media/HMUZ8FWacAAK4eL.jpg)

## 구현 전: 사각지대 훑기에서 계획서까지

![구현 전(사각지대 훑기, 브레인스토밍과 프로토타입, 인터뷰, 레퍼런스, 구현 계획), 구현 중(구현 노트), 구현 후(설득 문서, 퀴즈)로 나눈 흐름도와, 배운 것이 다음 지도가 된다는 점선 화살표](https://pbs.twimg.com/media/HMUbXPhaoAIKuhv.jpg)

Thariq가 가장 먼저 꼽은 방법은 사각지대 훑기(blind spot pass)입니다. 코드베이스의 낯선 부분에 기능을 넣거나 디자인처럼 익숙하지 않은 일을 할 때는 무엇을 물어야 할지, 잘된 결과가 어떤 모습인지, 전에 어떤 시도가 있었고 어떤 함정이 있는지를 모릅니다. 이때 Thariq는 Claude에게 자기가 모르는 것을 찾아 설명해 달라고 하면서 「blindspot pass」와 「unknown unknowns」라는 말을 그대로 쓰고, 자기가 누구이고 무엇을 아는지를 함께 알려 줍니다.

그가 공개한 예시 산출물에서 Claude는 낯선 인증 모듈을 훑어 사각지대 카드 7장을 만들고, 카드마다 프롬프트에 보탤 문장을 붙인 뒤 하나의 구현 프롬프트로 묶었습니다. 예시 프롬프트를 우리말로 옮기면 이렇습니다.

- 「새 인증 제공자를 붙이려는데 이 코드베이스의 인증 모듈은 하나도 몰라. blindspot pass를 해서 내가 알아야 할 unknown unknowns를 찾고, 내가 프롬프트를 더 잘 쓰게 도와줘.」
- 「색보정이 뭔지 모르는데 이 영상을 색보정해야 해. 프롬프트를 더 잘 쓸 수 있게 색보정에 관한 내 unknown unknowns를 이해하도록 가르쳐 줘.」

두 번째 방법은 브레인스토밍과 프로토타입입니다. 보면 알지만 미리 말로 정하기 어려운 기준, 곧 안다는 걸 모르는 것이 많은 일에 씁니다. Thariq는 이런 기준을 구현 도중에 발견하면 상대적으로 비싸다고 봤는데, 기능이나 명세가 조금만 달라져도 코드는 크게 달라지고 에이전트가 앞서 한 변경을 되돌리기도 어렵기 때문입니다.

그래서 그는 백엔드를 붙이지 않은 채 버튼 하나를 화면에 올려 모양부터 보고, 시각 디자인처럼 말로 설명하기 어려운 일은 디자인 시안 여러 개를 한꺼번에 받습니다. 거의 모든 코딩 세션을 탐색과 브레인스토밍으로 시작해 범위를 너무 좁거나 넓게 잡지 않게 한다고도 적었습니다. 예시 프롬프트는 이렇습니다.

- 「이 데이터로 대시보드를 만들고 싶은데 나는 시각 감각이 없고 뭐가 가능한지도 몰라. 서로 완전히 다른 디자인 방향 4가지를 HTML 페이지 하나로 만들어 줘. 보고 반응할게.」
- 「대략적인 문제는 이거야. 사용자들이 온보딩을 마친 뒤 이탈해. 코드베이스를 찾아보고 개입할 수 있는 곳 10군데를 가장 싼 것부터 가장 야심 찬 것까지 브레인스토밍해 줘. 와닿는 걸 내가 고를게.」

세 번째 방법은 Claude가 사용자를 인터뷰하게 하는 것입니다. 브레인스토밍을 충분히 한 뒤에도 남은 모르는 것을 꺼내는 단계로, 예시 프롬프트는 「애매한 부분을 한 번에 한 질문씩 인터뷰해 줘. 내 답에 따라 아키텍처가 달라질 질문부터 물어봐.」 한 줄입니다. 예시 산출물에서 Claude는 아키텍처에 미치는 영향이 큰 순서로 질문하고, 인터뷰가 끝나면 결정 사항 표와 바로 붙여 넣을 구현 프롬프트를 돌려줬습니다.

네 번째 방법은 레퍼런스를 주는 것입니다. 원하는 것을 설명할 말이 없거나 설명이 너무 길어질 때 쓰는데, Thariq는 다이어그램이나 문서, 사진보다 소스코드가 가장 좋은 레퍼런스라고 봅니다. 원하는 방식으로 무언가를 구현한 라이브러리나 마음에 드는 디자인 컴포넌트가 있으면, 다른 언어로 쓰였더라도 Fable에게 그 폴더를 가리키고 무엇을 볼지 알려 주면 됩니다. 예시 프롬프트는 「vendor/rate-limiter의 이 Rust 크레이트가 내가 원하는 백오프 동작을 정확히 구현하고 있어. 읽고 같은 동작을 우리 TypeScript API 클라이언트에 다시 구현해 줘.」입니다.

다섯 번째 방법은 손볼 곳부터 보여 주는 구현 계획서입니다. 구현할 준비가 됐다고 느끼면 Thariq는 가장 손볼 가능성이 큰 부분에 초점을 맞춘 계획서를 요청해 검토합니다. 예시 프롬프트는 「구현 계획을 HTML로 써 줘. 데이터 모델 변경, 새 타입 인터페이스, 사용자에게 보이는 부분처럼 내가 손댈 가능성이 큰 결정을 맨 앞에 두고, 기계적인 리팩터링은 맨 아래로 내려. 그 부분은 믿고 맡길게.」이고, 예시 산출물의 계획서도 실행 순서 대신 손볼 가능성 순서로 정렬돼 있습니다.

## 구현 중: 계획에서 벗어난 곳을 적어 둡니다

계획에 만족하면 Thariq는 새 세션을 열고 명세 파일과 프로토타입 같은 산출물을 프롬프트에 넣어 구현을 맡깁니다. 그래도 모른다는 것조차 모르는 것은 늘 숨어 있어서, 에이전트가 코드에서 만난 예외 상황 때문에 다른 길로 가야 할 때가 생깁니다. 그래서 Claude Code에 임시 파일 implementation-notes.md(또는 .html)를 두게 하고, 에이전트가 내린 결정을 적어 다음 시도에서 배울 수 있게 합니다.

예시 프롬프트는 「implementation-notes.md 파일을 유지해. 계획에서 벗어날 수밖에 없는 예외 상황을 만나면 보수적인 쪽을 택하고, Deviations 항목에 기록한 뒤 계속 진행해.」입니다. 예시 산출물에는 Claude가 3시간 동안 작업하며 남긴 기록이 실려 있는데, 계획에서 벗어난 곳마다 택한 보수적 결정과 두 번째 시도에 반영할 세 가지가 적혀 있습니다.

## 구현 후: 설득 문서와 퀴즈

만든 것을 내보내려면 동료의 동의와 승인이 필요합니다. 검토자도 작업자가 처음 가졌던 모르는 것에서 출발하기 때문에, Thariq는 프로토타입과 명세, 구현 노트를 한 문서로 묶어 설득 자료로 씁니다. 예시 프롬프트는 「프로토타입, 명세, 구현 노트를 슬랙에 바로 올릴 수 있는 문서 하나로 묶어 줘. 데모 GIF를 맨 앞에 둬.」입니다.

![prototype, spec, notes 세 상자가 데모 영상을 맨 앞에 둔 문서 하나로 모이고, 그 문서가 검토자들의 동의로 이어지는 도식](https://pbs.twimg.com/media/HMUce7UaEAAegM5.jpg)

마지막 방법은 Claude가 내는 퀴즈입니다. 긴 작업 세션이 끝나면 Claude가 사용자가 아는 것보다 훨씬 많은 일을 해 놓았을 수 있고, 동작의 상당 부분이 기존 코드 흐름을 따라 움직여서 변경분만 읽어서는 무슨 일이 일어났는지 얕게만 알 수 있다고 Thariq는 적었습니다. 그래서 맥락과 직관, 한 일을 담은 HTML 보고서를 받고 끝에 붙은 퀴즈를 풀며, 퀴즈를 완벽하게 통과해야만 병합합니다. 예시 산출물은 파일 14개를 고친 변경에 대한 보고서 끝에 6문항 퀴즈를 달았고, 틀린 답은 대충 읽은 부분으로 돌아가게 했습니다.

Thariq는 퀴즈를 글에 넣게 된 데에 AI Engineer World's Fair에서 개발 도구 연구자 제프리 리트와 나눈 대화가 도움이 됐다고 밝혔습니다. 리트는 같은 행사 발표를 바탕으로, 에이전트가 쓴 코드도 사람이 여전히 이해하고 있어야 한다는 긴 스레드를 7월 2일 올렸습니다.

## 출시 영상을 편집기 없이 만든 과정

Thariq는 이 방법들이 실제로 어떻게 엮이는지를 Fable 5 출시 영상으로 보여 줍니다. 6월 9일 Claude Code 팀 계정에 올라온 이 영상은 Claude Code가 통째로 편집했습니다. 게시물 첫머리에는 「예전에는 Claude가 일을 제대로 했는지 검증했고, 이제는 Claude가 제대로 된 일을 하고 있는지 검증한다」는 문장이 적혀 있습니다.

영상 편집은 Thariq에게 처음 해 보는 분야였고, 그는 아는 것에서 출발했습니다. Claude가 코드로 영상을 자르고 음성을 받아 적을 수 있다는 것은 알았지만 정확도는 몰라서, Whisper 같은 음성 인식이 어떻게 작동하는지와 ffmpeg로 「음」 같은 소리나 긴 공백을 정확히 잘라 낼 수 있는지를 Claude에게 먼저 물었습니다. 말하는 단어에 맞춰 화면 UI가 뜨게 하고 싶었을 때는 될지 확신이 없어서, Remotion과 받아쓰기 결과로 시험용 영상부터 만들게 했습니다.

마지막 문제는 색이었습니다. 영상이 조금 칙칙해 보였고 색보정 문제라는 것까지는 알았지만, 색보정이 무엇인지는 잘 몰랐습니다. 처음에는 Claude에게 변형 몇 개를 만들게 해 고르려 했는데, 색보정에서 무엇이 좋은 것인지 자기가 모른다는 것을 깨닫고 방향을 틀어 Claude에게 색보정부터 가르쳐 달라고 했습니다.

이때 쓴 방식을 옮긴 예시 산출물은 색보정 용어를 쉬운 것부터 차례로 익히게 하고 슬라이더로 전후 화면을 비교하게 해, 「영상을 좀 더 보기 좋게」라는 막연한 주문을 전문 용어가 들어간 프롬프트로 다시 쓰게 돕습니다. Thariq는 출시 다음 날 이 과정을 따로 영상으로 설명하며, Claude가 받아쓰기 서비스와 ffmpeg, 색보정, 피그마 MCP, Remotion UI를 다루는 코드와 도구 호출을 잔뜩 써서 영상을 렌더링했고 자신은 영상 편집기를 한 번도 건드리지 않았다고 적었습니다.

## 무엇을 만들지 확인하는 일

소프트웨어 공학에는 오래된 구분이 하나 있습니다. 배리 보엠은 검증(verification)을 「제품을 올바르게 만들고 있는가」로, 확인(validation)을 「올바른 제품을 만들고 있는가」로 정리했습니다. Claude Code 팀이 6월 9일 적은 문장의 앞부분은 보엠의 검증에, 뒷부분은 보엠의 확인에 해당하고, Thariq의 여덟 가지 방법은 대부분 뒤의 물음에 답하는 절차입니다. 무엇이 올바른 제품인지는 코드보다 사람의 머릿속과 현실의 제약에 들어 있어서, 모델이 강해질수록 그 정보를 꺼내는 일이 결과를 가릅니다.

저는 이 네 갈래를 보며 조하리의 창을 떠올렸습니다. 1955년 심리학자 조지프 러프트와 해링턴 잉햄이 만든 틀로, 자기에 대한 앎을 나도 알고 남도 아는 영역, 나만 아는 영역, 남은 알지만 나는 모르는 맹점, 누구도 모르는 영역으로 나눕니다. 조하리의 창에서 맹점(blind spot)은 다른 사람이 말해 줘야 줄어드는데, Thariq의 blind spot pass에서는 그 역할을 Claude가 맡습니다.

## 효과를 잰 숫자는 아직 없습니다

이 방법이 모델을 잘 아는 사람의 요령에 그친다고 볼 수도 있습니다. Thariq 스스로 모든 방법을 매번 쓰지는 않는다고 적었고, 이 방법으로 실패가 얼마나 줄었는지 잰 수치도 글에 없습니다. 공개된 예시 산출물 11개도 프롬프트와 그 결과를 보여 주는 견본이라, 실제 프로젝트에서 같은 효과가 나는지는 따로 확인된 적이 없습니다.

모르는 것을 찾는 데도 비용이 듭니다. 디자인 시안 네 가지와 HTML 계획서, 설명 보고서와 퀴즈는 모두 토큰을 쓰고, Fable 5의 API 가격은 100만 토큰당 입력 10달러, 출력 50달러입니다. Thariq는 설명서와 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스가 모두 고치는 비용이 커지기 전에 모르는 것을 싸게 알아내는 방법이라고 봤지만, 그 계산은 구현 뒤에 뒤집히는 일이 얼마나 비싼지에 따라 팀마다 다르게 나옵니다.

## 한국 사용자에게 달라지는 것

Fable 5는 7월 1일 다시 열렸지만, Pro와 Max, Team 요금제에 포함된 사용은 7월 7일(한국 시각 7월 8일)까지이고 그 뒤에는 사용량 크레딧으로 과금됩니다. Thariq는 7월 2일 X에서 Fable이 7월 7일 이후 구독에서 빠지지만, 용량이 허락하는 대로 다시 구독에 기본으로 포함하는 것이 목표라고 밝혔습니다.

예시 프롬프트는 모두 영어로 공개됐지만 특정 모델의 기능에 기대는 문장이 없어서, 우리말로 옮겨 써도 구조는 그대로입니다. Thariq는 글을 다음 프로젝트는 Claude에게 모르는 것을 찾아 달라고 하는 데서 시작하라는 문장으로 맺었습니다.

읽어 주셔서 고맙습니다.

초이 드림