이 기사에 대하여

Anthropic의 Thariq Shihipar 씨가 작성한 A field guide to Claude Fable 5: Finding your unknowns (2026년 7월 6일)를 읽으며, **"AI 에이전트에게 일을 맡길 때의 품질은 모델의 성능이 아니라 자신의 unknowns(알지 못하는 것)의 양으로 결정된다"**라는 사고방식과 그 구체적인 실천 방법을 일본어로 정리합니다.

원문은 5분 정도면 읽을 수 있는 짧은 에세이지만, 쓰여 있는 내용은 "내일부터 바로 사용할 수 있는 프롬프트 모음"으로서 상당히 실용적입니다. 이 기사에서는 원문의 주장을 쉽게 풀어서 설명하면서, 실제 워크플로우에 적용할 수 있는 형태로 정리했습니다.

1. 지도와 현지 (Map and Territory)

원문은 우선 다음과 같은 비유로 시작합니다.

지도 (Map) = 당신이 Claude에게 전달하는 것. 프롬프트, Skill, 컨텍스트.

현지 (Territory) = 실제로 작업이 이루어지는 장소. 코드베이스, 현실 세계, 진정한 제약 사항.

그리고, **이 지도와 현지의 차이야말로 "unknowns"**라고 정의합니다.

이 부분이 기사의 핵심입니다. Claude가 unknowns에 부딪혔을 때, Claude는 "아마 이것을 원할 것이다"라는 추측으로 의사결정을 할 수밖에 없다. 그리고,

맡기는 작업량이 많아질수록, Claude가 부딪히는 unknowns도 늘어난다.

즉 "AI에게 큰 일을 맡긴다" = "AI에게 추측하게 만드는 횟수를 늘린다"는 뜻입니다.

왜 지금 이 이야기가 중요한가

저자는 이렇게 쓰고 있습니다.

Claude Fable는,

업무의 품질이 "자신이 unknowns를 명확히 할 수 있는 능력"에 의해 병목 현상(bottleneck)이 되는 첫 번째 모델이라고 느끼고 있다.

바꾸어 말하면, 이러한 시대적 변화가 일어나고 있다는 주장입니다.

그리고 중요한 주의점으로,

단순히 사전에 계획하는 것만으로는 불충분하다. unknowns는 구현의 깊은 곳에서 발견될 수도 있고, 애초에 "다른 방식으로 풀어야 했다"라고 깨닫게 해 주기도 한다.

그래서 저자는 unknowns의 발견을 구현의 "전·중·후"에서 반복하는 반복 프로세스로 취급하고 있습니다.

2. unknowns의 4가지 분류

저자는 문제를 가져올 때 항상 4가지로 분해한다고 합니다. 유명한 람즈펠드 매트릭스 (Rumsfeld Matrix)의 응용이군요.

위의 3단계는 노력하면 밝혀낼 수 있지만, 가장 아래 단계는 끌어올 곳 자체가 없기 때문에 밝혀낼 수 없습니다. 이것이 Unknown Unknowns입니다.

가장 까다로운 것은 Unknown Knowns

개인적으로 이 4가지 분류 중 가장 와닿는 것은 Unknown Knowns입니다.

"말하면 당연하지만, 스스로는 절대로 언어화하지 않는" 것. 이 부분이 채워져 있지 않으면, AI의 출력은 기술적으로는 맞는데, 왠지 모르게 납득이 가지 않는 결과가 됩니다. 디자인 리뷰에서 "왠지 느낌이 다르다"라고밖에 말할 수 없을 때의 정체가 바로 이것입니다.

숙련된 사람은 unknowns가 적다, 하지만 "있다"는 것을 전제로 한다

저자는 Claude Code를 만든 Boris Cherny 씨나 Bun의 Jarred Sumner 씨의 프롬프트를 보면,

그들이 무엇을 원하는지 상세히 파악하고 있음이 분명하다. 코드베이스와 모델의 동작 양쪽 모두에 깊이 동기화되어 있다.

라고 말하며 다음과 같이 이어갑니다.

하지만 그들 역시 unknowns (미지의 영역)의 존재를 전제로 하고 있다. 여러 의미에서, unknowns를 줄이고 unknowns에 대비하는 것이 에이전틱 코딩 (Agentic Coding)의 "기술"이다. 하지만 다행스럽게도, 이는

Claude와 협업함으로써 향상될 수 있는 기술이다.

"지시를 잘 못 하는 것은 재능의 문제"가 아니라, 연습을 통해 성장하는 기술로 다루어지고 있다는 점이 포인트입니다. 이후의 장은 이를 위한 구체적인 방법론이 됩니다.

3. 구현 전 (Pre-implementation)

여기서부터 실전 파트입니다. 원문에서는 4가지 방법론을 제시하고 있습니다.

3-1. 브레인스토밍 & 프로토타입

겨냥하는 unknowns: Unknown Knowns (알고는 있지만 언어화하지 못하는 것)

저자는 "보고 나서야 기준을 정의할 수 있는" 영역에서는, Claude와 함께 브레인스토밍 (Brainstorming)과 프로토타이핑 (Prototyping)을 진행한다고 합니다.

왜 이를 앞당겨서 하는가. 그 이유가 명확하게 적혀 있습니다.

프로토타이핑 단계에서 unknown knowns를 특정하고 언어화하는 것은 매우 가치가 높다. 구현 중에 발견되면 (상대적으로) 비용이 많이 들기 때문이다. 기능이나 사양의 작은 변경이 코드상에서는 극적으로 다른 구현을 초래할 수 있으며, 에이전트가 이전의 변경 사항을 되돌리는 것은 더 어렵기 때문입니다.

예를 들어 "프레임에 버튼을 추가했을 때의 모습만 확인하고 싶을 뿐"이라면, 백엔드 (Backend) 라우트를 연결하거나 프론트엔드 (Frontend) 상태 관리를 늘릴 필요는 없다는 이야기입니다.

나아가 저자는 거의 모든 코딩 세션을 탐색 및 브레인스토밍 단계부터 시작한다고 적고 있습니다. 그 효과는 다음과 같습니다:

• 의도를 가지고 프로젝트의 스코프 (Scope)를 정의할 수 있음
• Claude가 스스로는 놓치고 있었던 고가치 접근 방식을 잘 찾아내 줌
• 반대로 "나무만 보고 숲은 보지 못하는" 상황이 생길 수도 있음
• 결과적으로
  스코프를 너무 좁게 또는 너무 넓게 설정하는 것을 방지할 수 있음

프롬프트 예시 (원문 기준)

이 데이터의 대시보드가 필요한데, 나에게는 비주얼 감각이 없어서
무엇이 가능한지도 모르겠어. 완전히 방향성이 다른 디자인 안을 4개 넣은
HTML 페이지를 만들어줘. 그것에 반응하는 방식으로 결정하고 싶어.

아무것도 연결하기 전에, 새로운 편집 화면을 모킹 (Mock)한 단일 HTML 파일을 만들어줘.

3-2. 레퍼런스 (참조)

겨냥하는 unknowns: 설명 비용이 너무 높은 Known Unknowns

상세히 설명할 수 없거나, 설명하는 데 시간이 너무 오래 걸리는 경우입니다.

도표나 문서, 이미지도 포함할 수 있지만, **최고의 레퍼런스는 "소스 코드"**입니다.

저자는 이렇게 적고 있습니다.

특정 동작을 특정한 방식으로 구현하고 있는 라이브러리나, 마음에 드는 디자인 컴포넌트 (Design Component)가 있다면,

그 폴더를 Fable에 가리켜 주며 무엇을 보면 되는지 알려주기만 하면 된다. 설령 다른 언어로 작성되어 있어도 상관없다. 스크린샷 등과 비교했을 때, 마크업 (Markup)이나 구조에 대해 훨씬 더 풍부한 디테일을 Claude에게 제공할 수 있다.

프롬프트 예시 (원문 기준)

vendor/rate-limiter에 있는 Rust crate가 내가 정확히 원하는 백오프 (Backoff) 동작을
구현하고 있어. 그것을 읽고, 동일한 시맨틱스 (Semantics)를 우리의 TypeScript
API 클라이언트에서 재구현해줘.

3-3. 인터뷰

겨냥하는 unknowns: Known Unknowns의 도출

브레인스토밍을 충분히 했음에도 여전히 unknowns는 남아 있습니다. 그래서 저자는 Claude에게 자신을 인터뷰하게 합니다.

Claude에게 인터뷰를 요청할 때는, 질문을 유도할 수 있도록 문제의 컨텍스트 (Context)를 제공하도록 합니다.

프롬프트 예시 (원문 기준)

모호한 점에 대해, 한 번에 하나씩 나에게 인터뷰해줘.
내 답변에 따라 아키텍처 (Architecture)가 바뀔 법한 질문을 우선시해줘.

3-4. 구현 계획 (Implementation Plans)

구현할 수 있다고 판단되는 단계에서, 리뷰용 구현 계획을 작성하게 합니다. 여기에도 요령이 있습니다.

계획은,

가장 변경될 가능성이 높은 부분에 집중하게 합니다. 데이터 모델 (Data Model), 타입 인터페이스 (Type Interface), UX 플로우 (UX Flow) 등입니다. 이렇게 함으로써 Claude는 "자신이 실제로 변경해야 할 수도 있는 것"을 드러내 줍니다.

프롬프트 예시 (원문 기사 발췌)

구현 계획을 HTML로 작성해 줘. 단, 내가 수정할 가능성이 가장 높은 결정 사항들을
맨 앞에 배치해 줘: 데이터 모델의 변경, 새로운 타입 인터페이스,
사용자에게 보이는 모든 부분.
...

4. 구현 중 (During implementation)

4-1. 세션을 전환하여 결과물을 전달하기

계획이 만족스러우면, 저자는 새로운 세션을 만들고 결과물 (Artifacts)을 프롬프트로 전달합니다.

이를 통해 Claude에게는

새로운 컨텍스트 윈도우 (Context Window)가 주어지지만, 계획 단계에서 수집한 정보는 모두 손에 쥐고 있는 상태가 됩니다.

예를 들어 spec 파일과 프로토타입을 전달하여 구현하게 합니다. 계획 단계에서의 시행착오로 인한 노이즈를 가져오지 않고, 결론만을 계승하는 발상입니다.

4-2. implementation-notes.md 작성시키기

아무리 계획을 세워도 unknown unknowns는 반드시 잠재되어 있습니다. 에이전트는 작업 중에 코드 내에서 발견한 엣지 케이스 (Edge Case) 때문에 다른 방침을 취해야 할 필요성을 느낄 수 있습니다.

그래서 저자는 Claude Code에 임시 implementation-notes.md (또는 .html)를 갖게 하여, 내린 결정을 기록하게 합니다. "다음 시도에서 배울 수 있도록" 하는 것이 목적입니다.

프롬프트 예시 (원문 기사 발췌)

implementation-notes.md를 유지해 줘.
계획에서 벗어날 수밖에 없는 엣지 케이스를 만나면, 보수적인 선택지를 택하고
'Deviations' (이탈) 섹션에 기록한 뒤 그대로 진행해 줘.

5. 구현 후 (Post implementation)

5-1. 퀴즈 (자신이 테스트받기)

긴 세션이 끝난 후, Claude는 자신이 생각했던 것보다 훨씬 더 많은 것을 달성했을지도 모릅니다.

코드의 차이점 (Diff)만 읽어서는 얕은 이해밖에 얻을 수 없습니다.

많은 동작이 기존의 코드 경로 (Code Path)에 의존하고 있기 때문입니다.

그래서 저자는 Claude에게 충분한 컨텍스트를 제공한 뒤, 변경 사항에 대해 자신을 퀴즈 내게 합니다.

나는 퀴즈를 완벽하게 맞힌 후에야 비로소 머지 (Merge)한다.

프롬프트 예시 (원문 기사 발췌)

이 변경으로 인해 일어난 일을 전부 이해하고 있는지 확인하고 싶어.
변경 사항에 대한 HTML 리포트를 만들어 줘. 컨텍스트, 직관적인 이해,
무엇을 했는지 등을 포함해서 내가 읽고 이해할 수 있는 형태로.
...

5-2. 피치 (Pitch)와 설명 자료

무언가를 출시하는 데 있어 가장 중요한 부분 중 하나는

찬성과 승인을 얻는 것입니다.

피치나 설명을 담은 아티팩트 (Artifact)를 최종 문서에 포함해 두면 다음과 같은 효과가 있다고 기술되어 있습니다.

리뷰어가 당신과 동일한 unknowns 상태에서 시작할 때, 이해를 가속화한다
전문가가 "자신이라면 예상했을 unknowns나 전형적인 실패 지점"을 당신이 이미 고려했음을 확인하고 싶을 때, 승인을 가속화한다

프롬프트 예시 (원문 기사 발췌)

프로토타입, spec, implementation notes를 하나의 문서로 정리해 줘.
Slack에 올려서 찬성을 얻을 수 있는 형태로 만들어 줘. 데모 GIF를 맨 앞에 배치하고.

6. 지도와 현장을 일치시키기 (결론)

원문 기사의 마무리는 다음과 같습니다.

모델이 좋아질수록,

올바른 접근 방식을 취했을 때 달성할 수 있는 것은 늘어납니다. 장기적인 태스크가 잘못된 결과로 돌아왔을 때는, 아마도 unknowns의 정의에 더 많은 시간을 들여야 하거나, 당신과 Claude가 unknowns에 적응하며 나아갈 수 있는 구현 계획을 만들어야 할 것입니다.

그리고 이 기사에서 가장 좋아하는 문장은 이것입니다.

모든 설명 자료, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 "수정 비용이 커지기 전에, 몰랐던 것을 알기 위한" 저렴한 수단입니다. 그러니 다음 프로젝트는 Claude에게 unknowns를 찾는 데 도움을 요청하는 것부터 시작해 봅시다.

실천 체크리스트

원문 기사의 수법을 그대로 사용할 수 있는 체크리스트로 정리했습니다.

구현 전

• 브레인스토밍 (Brainstorming): 바로 구현하게 하지 말고, "전혀 다른 접근 방식 N개를 제시해 줘"라고 요청하며 시작하기
• 프로토타입 (Prototype): 외관 및 UX는 배선(Wiring) 전에 단일 HTML로 모킹(Mocking)하여 반응을 보고 결정하기
• 레퍼런스 (Reference): 참고하고 싶은 구현이 있다면 스크린샷이 아니라 **소스 코드의 경로 (Source code path)**를 전달하기 (언어가 달라도 OK)
• 인터뷰 (Interview): "한 번에 하나씩, 아키텍처가 변할 수 있는 질문을 우선해 줘"라고 요청하기
• 구현 계획 (Implementation plan): 변경 가능성이 높은 결정 사항(데이터 모델, 타입, UI)은 서두에, 기계적인 작업은 말미에 배치하기

구현 중

• 계획이 확정되면 **새 세션 (New session)**을 만들어 spec과 프로토타입을 전달하며 시작하기
• implementation-notes.md에 **편차 (Deviations)**를 기록하게 하기
• 고민되는 지점이 있을 때를 대비해 판단 기준을 미리 제공하기 (예: 보수적인 방향을 선택해라)

구현 후

• **퀴즈를 통과한 후에 머지 (Merge)**하기
• 프로토타입 + spec + notes를 **하나의 피치 자료 (Pitch document)**로 통합하기

회고

• implementation-notes.md의 Deviations를 읽고, **다음에 제거할 수 있는 미지의 영역 (Unknowns)**을 CLAUDE.md나 Skill에 반영하기

마치며: 소감

이 필드 가이드를 읽으며 가장 와닿았던 점은, "AI에게 지시를 못 한다"라는 문제를 "자신의 요구사항이 모호하다"라는 문제로 재해석하고 있다는 점입니다.

"프롬프트의 요령"에 관한 이야기는 세상에 넘쳐나지만, 이 기사의 주장은 반대 방향을 향하고 있습니다. 모델이 충분히 똑똑해진 이상, 개선해야 할 것은 모델에게 전달하는 기술적 기교가 아니라, 전달할 내용이 자신 안에서 확립되지 않았다는 사실이라는 것입니다.

그리고 4가지 분류 중 Unknown Knowns와 Unknown Unknowns는 정의상 혼자만의 힘으로는 찾아낼 수 없습니다. 그렇기에 Claude에게 "찾는 것을 도와달라"고 요청하는 것입니다. 이 기사에서 제시하는 수법(브레인스토밍, 여러 안 제시, 인터뷰, 퀴즈)이 모두 "AI가 질문을 던지게 하거나 / 선택지를 내놓게 하는" 형태를 띠고 있는 이유도 바로 그 때문입니다.

구현을 요청하기 전에, **"이제부터 만들 것에 대해 내가 결정하지 않은 것들을 질문해 줘"**라는 한 줄을 추가하는 것만으로도 경험은 달라질 것이라고 생각합니다.

참고

• 원문 기사: A field guide to Claude Fable 5: Finding your unknowns — Thariq Shihipar (Anthropic), 2026년 7월 6일
• 관련 기사: Building verification loops in Claude Code with skills — 2026년 7월 21일
• Claude Code 문서

※ 본 기사 중의 프롬프트 예시는 원문 기사에 게재된 영어 프롬프트를 필자가 번역한 것입니다. 뉘앙스를 확인하고 싶으신 분은 원문을 참조해 주시기 바랍니다.

Discussion