Claude Fable 실전 가이드: 나의 unknowns 발견하는 AI 협업법

Claude Fable 5 실전 가이드: 나의 unknowns를 발견하는 8가지 AI 협업 패턴 (2026)

결론부터 말씀드릴게요. Claude Fable 5로 좋은 결과를 얻는 열쇠는 "얼마나 프롬프트를 화려하게 쓰느냐"가 아니라 "내가 뭘 모르는지를 얼마나 잘 짚어내느냐"에 있습니다.

Anthropic의 Thariq Shihipar(member of technical staff)가 2026년 7월 6일 공식 블로그에 올린 실전 가이드의 핵심 주장이 바로 이거예요. 그는 Claude Fable 5를 "작업 품질이 모델 능력이 아니라, 내가 나의 unknowns(모르는 것)를 얼마나 잘 짚어주느냐에 병목되는 첫 모델"이라고 정의합니다. 다시 말해 이제 AI가 발목을 잡는 게 아니라, 내가 무엇을 원하는지 스스로 모르는 상태가 발목을 잡는다는 거죠.

이 글에서는 그 가이드가 제시한 unknowns라는 개념과, 그것을 발견하는 8가지 실전 프롬프트 패턴을 하나씩 쉽게 풀어드릴게요. 개발자뿐 아니라 문서·디자인·영상 작업을 하는 비개발자와 1인 기업가에게도 그대로 적용되는 이야기입니다.

지도와 영토, 그리고 그 사이의 unknowns

먼저 이 가이드가 쓰는 비유부터 짚고 갈게요. 여행을 준비할 때 우리는 지도를 봅니다. 하지만 실제로 걷는 건 진짜 땅, 즉 영토죠.

• 지도(Map): 내가 Claude에게 주는 것입니다. 프롬프트, 스킬, 컨텍스트 같은 것들이에요. "해야 할 일을 내가 표현한 것"이라고 보시면 됩니다.
• 영토(Territory): 실제로 일이 벌어지는 곳입니다. 코드베이스, 실제 세계, 진짜 제약 조건이죠.
• unknowns: 지도와 영토의 차이입니다. Claude가 이 빈틈(unknown)을 만나면, "이 사람이 뭘 원하는지"에 대한 나름의 최선의 추측으로 결정을 내려야 합니다.

작업이 커질수록 이 빈틈도 많아집니다. 저자는 이렇게 말합니다. "그냥 미리 계획하는 것만으로는 충분하지 않다. unknown은 구현 깊숙한 곳에서 발견될 수도 있고, 때로는 unknown이 오히려 '문제를 아예 다른 방식으로 풀어야 한다'는 걸 알려줄 수도 있다."

그래서 unknowns를 다루는 일은 한 번 계획하고 끝나는 게 아니라, 작업 전·중·후에 걸쳐 반복해서 발견하는 과정입니다.

4가지 unknowns: 내가 모르는 것에도 종류가 있어요

저자는 문제를 받으면 그것을 4가지로 나눕니다. 도널드 럼스펠드의 유명한 매트릭스를 응용한 분류예요. 표로 정리하면 이렇습니다.

저자는 재미있는 관찰을 하나 덧붙입니다. "최고의 agentic coder는 unknown이 상대적으로 적다. Boris나 Jarred가 프롬프트하는 걸 보면, 그들이 원하는 걸 디테일하게 안다는 게 명백하다. 코드베이스와 모델 행동에 깊이 sync(동기화)되어 있다."

여기서 핵심 메시지가 나옵니다. "unknown을 줄이고 대비하는 것이 곧 agentic coding의 스킬이다. 다행히 이건 Claude와 일하면서 향상시킬 수 있는 스킬이다." 실력이 부족한 게 문제가 아니라, 모르는 것을 미리 알아차리는 훈련이 안 된 게 문제라는 거죠.

Claude를 thought partner로 대하기

그러면 unknown은 어떻게 줄일까요? 저자는 지시의 균형이 미묘하다고 말합니다.

• 너무 구체적으로 지시하면, 방향을 바꾸는 게(pivot) 나은 상황에서도 Claude가 내 지시를 그대로 따릅니다.
• 너무 모호하게 지시하면, 내 작업에 안 맞을 수도 있는 "업계 best practice"로 알아서 추측하고 가정해버립니다.

Claude의 강점은 명확합니다. 코드베이스와 인터넷을 아주 빠르게 검색하고, 평균적인 주제에 대해서는 나보다 많이 알고, 실패에서 빠르게 배웁니다.

그래서 가장 중요한 건 Claude에게 시작점 컨텍스트를 주는 일입니다. 내 생각이 지금 어디까지 진행됐는지, 이 문제와 코드베이스에 대한 내 경험 수준이 어느 정도인지 밝히고, Claude를 단순한 실행 도구가 아니라 생각을 함께 굴리는 파트너(thought partner)로 대하는 거죠.

구현 전에 쓰는 5가지 패턴

이제 실전 패턴입니다. 저자는 총 8가지 패턴을 구현 전·중·후로 나눠 제시하는데요, 먼저 구현 전에 쓰는 5가지부터 볼게요. 이 단계의 목표는 "나중에 고치면 비싼 실수를, 지금 값싸게 미리 알아내기"입니다.

1. Blind Spot Pass (사각지대 훑기) — 코드베이스의 낯선 영역을 다루거나, 디자인 반복처럼 익숙하지 않은 일을 할 때 씁니다. 이럴 때는 unknown unknowns가 많거든요. "blind spot pass", "unknown unknowns"라는 문구를 그대로 프롬프트에 써도 됩니다. 내가 누구고 뭘 아는지 컨텍스트를 주는 게 중요해요.

"새 auth provider를 추가하는데 이 코드베이스의 auth 모듈은 하나도 모른다. blind spot pass를 해서 관련 unknown unknowns를 찾도록 도와주고, 내가 너에게 프롬프트를 더 잘 쓰게 도와줘."

2. Brainstorms and Prototypes (브레인스토밍·프로토타입) — "보면 알겠는데 미리 정의는 못 하는" 기준이 많을 때, 즉 unknown knowns가 많은 영역에서 씁니다. 구현 중에 이런 걸 발견하면 되돌리기가 비싸니까요. 저자는 거의 모든 코딩 세션을 탐색과 브레인스토밍으로 시작한다고 합니다. Claude가 놓쳤을 좋은 접근을 찾아주고, 범위를 너무 좁거나 넓게 잡는 것도 막아주거든요.

"이 데이터로 대시보드를 원하는데 시각 감각이 전혀 없고 뭐가 가능한지 모른다. 완전히 다른 4가지 디자인 방향을 HTML 한 페이지로 만들어줘. 반응을 보고 고를게."

3. Interviews (인터뷰) — 충분히 브레인스토밍했는데도 빈틈이 남아 있을 때, Claude에게 나를 인터뷰하게 합니다. 문제에 대한 컨텍스트를 줘서 좋은 질문을 유도하는 거죠.

"모호한 부분에 대해 한 번에 한 질문씩 나를 인터뷰해줘. 내 답이 아키텍처를 바꿀 질문을 우선해."

4. References (레퍼런스) — 원하는 걸 말로 디테일하게 설명하기 어려울 때(적절한 언어가 없거나 너무 복잡할 때) 씁니다. 다이어그램, 문서, 사진도 되지만 저자가 꼽는 최고의 레퍼런스는 소스코드입니다. 마음에 드는 라이브러리나 디자인 컴포넌트가 있으면 그 폴더를 가리키고 뭘 찾을지 말하면 돼요. 다른 언어여도 상관없습니다. 스크린샷보다 마크업과 구조가 훨씬 풍부한 정보를 담고 있거든요.

"vendor/rate-limiter의 이 Rust crate가 내가 원하는 backoff 동작을 정확히 구현한다. 읽고 우리 TypeScript API client에 같은 semantics로 재구현해줘."

5. Implementation Plans (구현 계획) — 이제 구현 준비가 됐다 싶을 때, Claude에게 검토용 구현 계획을 만들게 합니다. 이때 가장 바뀔 가능성이 높은 부분(데이터 모델, 타입 인터페이스, UX 흐름)에 초점을 두면, 실제로 손봐야 할 것이 앞으로 튀어나옵니다.

"구현 계획을 HTML로 써줘. 단, 내가 가장 만질 것 같은 결정(데이터 모델 변경, 새 타입 인터페이스, 사용자 대면 요소)을 앞에 두고, 기계적 리팩토링은 맨 아래에 묻어줘. 그 부분은 너를 믿어."

구현 중과 구현 후에 쓰는 3가지 패턴

계획을 잘 세워도 예상 못 한 함정은 늘 도사립니다. 그래서 구현 중과 후에도 unknown을 계속 붙잡아야 해요.

6. Implementation Notes (구현 노트, 구현 중) — 계획이 만족스러우면 새 세션을 열고 스펙 파일이나 프로토타입 같은 아티팩트를 프롬프트로 넘깁니다. 신선한 컨텍스트 창에 계획 단계에서 모은 정보를 다 담는 거죠. 하지만 아무리 계획해도 unknown unknowns는 남아 있습니다. 에이전트가 작업 중 발견한 예외 상황(edge case) 때문에 다른 방향을 잡아야 할 수도 있고요. 그래서 Claude Code에게 임시 implementation-notes.md 파일을 유지하면서 내리는 결정을 기록하게 하면, 다음 시도에서 그걸 학습에 쓸 수 있습니다.

"implementation-notes.md 파일을 유지해. plan에서 벗어나게 만드는 edge case를 만나면 보수적 옵션을 선택하고 'Deviations' 아래에 로그한 뒤 계속 진행해."

7. Pitches and Explainers (피치·설명 자료, 구현 후) — 무언가를 세상에 내놓을 때 가장 중요한 일 중 하나가 동의(buy-in)와 승인을 받는 겁니다. 잘 만든 설명 자료는 두 가지를 빠르게 해줍니다. 리뷰어가 나와 같은 지점에서 출발할 때 이해가 빨라지고, 전문가가 "이 사람이 우리가 걱정했을 함정을 고려했나"를 확인하고 싶을 때 승인이 빨라집니다.

"프로토타입, 스펙, implementation notes를 Slack에 드롭해서 buy-in 받을 단일 문서로 패키징해줘. 데모 GIF를 맨 앞에 놓고."

8. Quizzes (퀴즈, 구현 후) — 긴 세션이 끝나면 Claude가 생각보다 훨씬 많은 일을 해냈을 수 있습니다. 코드 diff만 읽으면 얕게만 이해하게 되죠. 동작의 상당수가 기존 코드 경로에 얽혀 있으니까요. 그래서 충분한 컨텍스트를 준 뒤 Claude에게 변경사항에 대해 나를 퀴즈하게 합니다. 그리고 **그 퀴즈를 완벽히 통과한 뒤에만 머지(merge)**합니다.

"이 변경에서 일어난 모든 걸 확실히 이해하고 싶다. 컨텍스트·직관·뭘 했는지 등과 함께 변경사항에 대한 HTML 리포트를 주고, 맨 아래에 내가 반드시 통과해야 하는 퀴즈를 붙여줘."

Fable 런칭 영상: 저자가 직접 겪은 사례

이 패턴들이 실제로 어떻게 작동하는지, 저자 본인의 경험담이 잘 보여줍니다. Fable 런칭 영상은 Claude Code로 처음부터 끝까지 편집됐는데요, 영상 편집은 저자에게 새로운 도메인이었고 그는 전문가가 아니었습니다.

그는 아는 것에서 시작했습니다. Claude가 코드로 영상을 편집하고 전사(transcription)할 수 있다는 건 알았지만, 정확도가 충분한지는 몰랐죠. 그래서 Whisper 같은 전사가 어떻게 동작하는지, ffmpeg로 "음..." 같은 군말이나 긴 정적을 정확히 잘라낼 수 있는지 Claude에게 설명해달라고 했습니다.

또 자기가 말하는 단어와 타이밍이 맞는 UI를 원했지만 그게 가능한지 몰랐어요. 그래서 Remotion과 전사를 결합한 프로토타입 영상을 만들어 검증하게 했습니다.

가장 인상적인 대목은 색 보정(color grading)이었습니다. 영상이 다소 칙칙(muted)해 보였는데, 그게 color grading 문제라는 건 알았지만 정작 color grading이 뭔지는 잘 몰랐어요. 처음엔 변형 몇 개를 만들게 했지만, "뭐가 좋은 건지" 스스로 판단하지 못한다는 걸 깨달았습니다. 그래서 방향을 바꿔 Claude에게 color grading을 가르쳐달라고 했고, 그 과정에서 자신의 unknown을 발견했습니다. 이게 바로 unknown knowns를 unknown unknowns로 착각하지 않고 제대로 짚어낸 사례예요.

한국 1인 기업가와 비개발자를 위한 적용법

이 가이드는 얼핏 개발자용처럼 보이지만, 사실은 "AI와 협업할 때 내가 뭘 모르는지 먼저 짚는 법"을 다룹니다. 그래서 코드를 짜지 않는 분에게도 그대로 통합니다.

문서를 정리하든, 디자인 시안을 잡든, 영상을 편집하든 unknown은 똑같이 존재합니다. "제안서를 써줘"라고 던지기 전에 "이 제안서에서 내가 놓치고 있는 게 뭘까? blind spot pass를 해줘"라고 먼저 물어보는 것, 시안을 하나만 받지 말고 "완전히 다른 4가지 방향을 보여줘"라고 브레인스토밍부터 시작하는 것, 결과물을 받은 뒤 "이 변경에서 내가 이해해야 할 걸 퀴즈로 내줘"라고 확인하는 것. 개발이 아니어도 패턴은 똑같습니다.

QJC가 이야기하는 AX(AI 전환)의 맥락에서도 마찬가지예요. 클로드 코드, 코덱스, 헤르메스로 회사 운영체제를 만들 때 "무엇을 자동화할까"보다 "내가 이 업무에서 뭘 모르는지"를 먼저 에이전트에게 물어보는 것이 진짜 레버리지가 됩니다. 저자의 마무리 문장이 이 모든 걸 압축합니다. "다음 프로젝트는 Claude에게 나의 unknowns를 찾도록 도와달라고 하며 시작하라."

모든 설명 자료, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 나중에 고치기 비싸지기 전에 몰랐던 걸 값싸게 알아내는 방법입니다. 지도와 영토를 맞추는 일, 그게 Claude Fable 시대의 핵심 실력이에요.

마무리

정리하면, Claude Fable 5 시대의 실력은 프롬프트를 얼마나 화려하게 쓰느냐가 아니라 내가 뭘 모르는지를 얼마나 빨리 알아차리느냐에 달렸습니다. 오늘 소개한 4가지 unknowns와 8가지 패턴은 순서대로 외울 목록이 아니라, 상황에 맞게 꺼내 쓰는 도구 상자예요. 낯선 영역이면 blind spot pass로 사각지대부터 묻고, 기준이 애매하면 브레인스토밍과 인터뷰로 좁히고, 끝나면 퀴즈로 확인하는 흐름을 다음 작업에 한 번만 적용해 보세요. 다음 프로젝트는 이 한 문장으로 시작하면 됩니다. "내 unknowns부터 찾아줘."

자주 묻는 질문 (FAQ)

Q. Claude Fable 5가 이전 모델과 뭐가 다른가요?

가이드는 Claude Fable 5를 "작업 품질이 모델 능력이 아니라, 내가 나의 unknowns를 얼마나 잘 짚어주느냐에 병목되는 첫 모델"이라고 설명합니다. 예전에는 모델의 성능 자체가 한계였다면, 이제는 내가 무엇을 원하는지 스스로 얼마나 명확히 아느냐가 결과를 좌우한다는 뜻이에요. 그래서 프롬프트 실력보다 "내가 뭘 모르는지 발견하는 능력"이 더 중요해집니다.

Q. 비개발자도 이 패턴을 쓸 수 있나요?

네, 그대로 쓸 수 있습니다. 이 가이드의 본질은 코딩 기법이 아니라 "AI와 협업할 때 내가 모르는 것을 먼저 짚는 법"이거든요. 문서·디자인·영상처럼 코드가 아닌 작업에도 unknown은 똑같이 존재합니다. 브레인스토밍으로 시작하고, Claude에게 나를 인터뷰하게 하고, 결과물을 퀴즈로 확인하는 흐름은 업무 종류를 가리지 않고 적용됩니다.

Q. 8가지 패턴을 다 외워서 순서대로 써야 하나요?

그럴 필요는 없습니다. 8가지는 구현 전·중·후에 unknown을 발견하는 도구 상자예요. 낯선 영역이면 blind spot pass, 기준이 애매하면 브레인스토밍과 인터뷰, 말로 설명이 어려우면 레퍼런스처럼 상황에 맞는 걸 골라 쓰면 됩니다. 핵심은 "지금 내가 모르는 게 어떤 종류인지" 알아차리고 거기에 맞는 패턴을 꺼내는 감각을 기르는 것입니다.

참고자료

• A field guide to Claude Fable 5: Finding your unknowns (Thariq Shihipar, Anthropic, 2026-07-06)
• Anthropic 공식 블로그 (Claude Code 실전 가이드·제품 소식 모음)

관련 글

• 특이점 빌더스 — 클로드 코드 실무 부트캠프
• 퀀텀점프클럽 더 알아보기