# Fable 필드 가이드: 나의 미지(Unknowns) 찾기

> Clean Markdown view of GeekNews topic #31107. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31107](https://news.hada.io/topic?id=31107)
- GeekNews Markdown: [https://news.hada.io/topic/31107.md](https://news.hada.io/topic/31107.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-04T10:03:02+09:00
- Updated: 2026-07-04T10:03:02+09:00
- Original source: [x.com/trq212](https://x.com/trq212/status/2073100352921215386)
- Points: 4
- Comments: 0

## Topic Body

- Claude Fable 5 작업의 핵심은 사용자가 주는 **지도(map, 프롬프트·스킬·컨텍스트)** 와 작업이 실제 일어나는 **영토(territory, 코드베이스·현실·제약)** 의 간극, 즉 **미지(unknowns)** 를 찾아 좁히는 것  
- Fable은 작업 품질이 **미지를 명확히 하는 사용자 능력**에 의해 좌우되는 첫 모델로, 작업량이 많을수록 마주치는 미지도 증가  
- 미지는 **Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns** 4가지로 구분되며, 미지를 줄이고 대비하는 것이 에이전틱 코딩의 핵심 역량  
- 구현 **이전·도중·이후**에 걸쳐 blindspot pass, 브레인스토밍, 인터뷰, 레퍼런스, 구현 계획, 구현 노트, 퀴즈 등 반복적 기법으로 미지를 발견  
- 설명·브레인스토밍·인터뷰·프로토타입·레퍼런스는 문제가 **비싸지기 전에 저렴하게 미지를 발견**하는 수단으로, 다음 프로젝트를 Claude에게 미지 찾기를 요청하며 시작하는 것이 중요  
  
---  
  
### 지도와 영토, 그리고 미지(Unknowns)  
  
- 지도는 수행할 작업의 표현으로 **프롬프트·스킬·컨텍스트** 즉 Claude에게 주는 것이며, 영토는 작업이 실제로 일어나는 **코드베이스·현실·실제 제약**  
- 지도와 영토의 차이가 곧 **미지(unknowns)** 이며, Claude는 미지에 부딪히면 사용자가 원하는 바에 대한 최선의 추측으로 결정을 내려야 함  
- Fable은 작업 품질이 **미지를 명확히 하는 능력에 병목**이 걸리는 첫 모델  
- 사전 계획만으로는 불충분하며, 미지는 구현 깊숙한 곳에서 발견되거나 문제를 아예 **다른 방식으로 풀어야 함**을 알려주기도 함  
- Fable 작업은 구현 전·중·후에 걸쳐 미지를 발견하는 반복 과정  
- [미지의 것을 찾는 데 도움이 되는 몇가지 예시 자료](https://thariqs.github.io/html-effectiveness/unknowns/) 나중에 참고 할 것  
  
### 미지 알기 (Knowing your unknowns)  
  
- 문제를 4가지로 분해  
  - **Known Knowns**: 프롬프트에 담긴 것, 에이전트에게 원한다고 말하는 것  
  - **Known Unknowns**: 아직 파악하지 못했으나 못했다는 사실은 인지하는 것  
  - **Unknown Knowns**: 너무 당연해 적어두지 않지만 보면 알아보는 것  
  - **Unknown Unknowns**: 전혀 고려하지 않은 것, 인지하지 못한 지식, 얼마나 좋아질 수 있는지 모르는 것  
- 뛰어난 에이전틱 코더는 미지가 상대적으로 적으며, 코드베이스와 모델 동작에 **깊이 동기화(in-sync)** 되어 원하는 바를 상세히 앎  
- 미지를 줄이고 대비하는 것은 **Claude와 작업하며 향상 가능한 기술**  
  
### Claude가 당신을 돕게 하기 (Help Claude help you)  
  
- 지시는 균형이 중요하며, 너무 구체적이면 방향 전환이 나을 때도 지시를 따르고, 너무 모호하면 과제에 맞지 않는 **업계 통념(best practices)** 에 기반한 선택을 함  
- 미지를 고려하지 않으면 양쪽 모두에서 실패하며, 경로가 막힐 때와 뚫릴 때를 모른 채 Claude가 방향을 틀길 원하게 됨  
- Claude는 코드베이스·인터넷을 빠르게 검색하고 평균적 주제에 대해 더 많이 알며 **실패로부터 빠르게 반복**하므로 미지 발견을 가속  
- 가장 중요한 것은 **출발점에 대한 컨텍스트 제공**으로, 사고 과정의 위치·문제와 코드베이스에 대한 경험을 밝히고 사고 파트너처럼 협업  
- 이전에 [Claude에서 HTML을 사용하는 것](https://x.com/trq212/status/2052809885763747935)에 대해 글을 쓴 적이 있는데, 대부분의 경우 **HTML 아티팩트**가 시각화·표현에 최적  
  
### 사전 구현 (Pre-implementation)  
- ## Blind Spot Pass  
  - 새 영역의 기능 작성이나 디자인 반복 같은 낯선 작업에서는 **unknown unknowns**가 많으며, 어떤 질문을 해야 할지·무엇이 좋은 것인지·과거 작업·피해야 할 함정을 모를 수 있음  
  - Claude에게 unknown unknowns를 찾아 설명해달라고 요청하며, "blindspot pass", "unknown unknowns"라는 표현을 그대로 사용하고 자신이 누구이며 무엇을 아는지 컨텍스트 제공이 중요  
  - 예시 프롬프트  
    - "새 auth provider 추가 작업 중인데 이 코드베이스의 auth 모듈을 전혀 모름. blindspot pass로 관련 unknown unknowns를 파악하고 더 잘 프롬프트하도록 도와달라"  
    - "color grading이 뭔지 모르지만 이 영상을 grade해야 함. 더 잘 프롬프트하도록 color grading의 unknown unknowns를 이해하게 가르쳐달라"  
- ## 브레인스토밍과 프로토타입 (Brainstorms and prototypes)  
  - **unknown knowns**가 많은 영역, 즉 보면 알지만 미리 정의하기 어려운 기준이 많은 경우 Claude와 브레인스토밍·프로토타입 진행  
  - unknown knowns를 구현 도중이 아닌 **프로토타이핑 초기에 식별·언어화**하는 것이 가치 있으며, 스펙의 작은 변화가 코드 구현을 크게 바꾸고 이전 변경을 되돌리기 어려울 수 있기 때문  
    - 예: 백엔드 라우트나 프론트엔드 상태 없이 프레임에 버튼을 추가한 모습만 확인하고 싶을 때  
  - 시각 디자인은 명확히 표현하기 어렵지만 보면 원하는 것을 아는 영역으로, 여러 디자인 접근을 요청  
  - 거의 모든 코딩 세션을 **탐색·브레인스토밍 단계로 시작**해 의도를 갖고 범위를 정의하며, 이는 범위가 너무 좁거나 넓어지는 것을 방지  
  - 예시 프롬프트  
    - "이 데이터용 대시보드를 원하지만 시각적 감각이 없고 뭐가 가능한지 모름. 완전히 다른 4가지 디자인 방향의 HTML 페이지를 만들어 반응할 수 있게 해달라"  
    - "연결 작업 전에 가짜 데이터로 새 에디터 툴바를 목업한 단일 HTML 파일을 만들어달라. 실제 앱을 건드리기 전 레이아웃에 반응하고 싶음"  
    - "대략적 문제는 온보딩 후 사용자 이탈. 코드베이스를 검색해 가장 저렴한 것부터 가장 야심찬 것까지 개입 가능한 10곳을 브레인스토밍해달라"  
- ## 인터뷰 (Interviews)  
  - 충분한 브레인스토밍 후에도 남은 미지가 있으면 Claude에게 미지·모호함에 대해 **인터뷰**를 요청하며, 질문을 유도하도록 문제 컨텍스트 제공  
  - 예시 프롬프트  
    - "모호한 부분을 한 번에 하나씩 질문하고, 내 답이 아키텍처를 바꿀 질문을 우선하라"  
- ## 레퍼런스 (References)  
  - 원하는 바를 상세히 묘사할 수 없을 때 최선의 답은 레퍼런스이며, 다이어그램·문서·그림도 되지만 **소스 코드가 절대적으로 최고의 레퍼런스**  
  - 특정 방식으로 구현된 라이브러리나 마음에 드는 디자인 컴포넌트가 있으면 다른 언어라도 폴더를 가리키고 찾을 것을 지시  
  - Claude Design도 동일한 방식으로, 좋아하는 웹사이트의 모듈을 가리키면 스크린샷이 아닌 **기반 코드를 읽어** 마크업·구조·실제 구현 방식에 대한 풍부한 정보 제공  
  - 예시 프롬프트  
    - "vendor/rate-limiter의 이 Rust crate가 원하는 backoff 동작을 정확히 구현함. 읽고 같은 의미를 우리 TypeScript API 클라이언트에 재구현하라"  
- ## 구현 계획 (Implementation Plans)  
  - 구현 준비가 되면 **변경 가능성이 가장 높은 부분**(데이터 모델, 타입 인터페이스, UX 흐름)에 초점을 둔 구현 계획을 검토용으로 요청해, 수정이 필요한 지점을 표면화  
  - 예시 프롬프트  
    - "HTML로 구현 계획을 작성하되 내가 가장 손댈 결정(데이터 모델 변경, 새 타입 인터페이스, 사용자 대면 요소)을 앞세우고, 기계적 리팩터링은 맨 아래로 내려라"  
  
### 구현 도중 (During implementation)  
- ## 구현 노트 (Implementation notes)  
  - 계획에 만족하면 새 세션을 만들어 스펙 파일·프로토타입 등 아티팩트를 프롬프트에 전달해 에이전트에게 구현 요청  
  - 아무리 계획해도 **unknown unknowns는 항상 잠복**하며, 에이전트가 작업 중 발견한 엣지 케이스로 다른 방식을 취해야 할 수 있음  
  - Claude Code에게 임시 **implementation-notes.md(또는 .html)** 파일에 내린 결정을 기록하게 해 다음 시도에서 학습  
  - 예시 프롬프트  
    - "implementation-notes.md 파일을 유지하라. 계획에서 벗어나게 하는 엣지 케이스를 만나면 보수적 선택을 하고 'Deviations'에 기록한 뒤 계속 진행하라"  
  
### 사후 구현 (Post implementation)  
- ## 피치와 설명자료 (Pitches and explainers)  
  - 무언가를 출시하는 데 가장 중요한 부분 중 하나는 **동의와 승인 확보**로, 최종 문서에 피치·설명 아티팩트를 만들면 도움  
    - 리뷰어가 당신과 같은 미지에서 출발할 때 **이해를 가속**  
    - 전문가가 미지와 흔한 실패 지점을 고려했는지 확인하려 할 때 **승인을 가속**  
  - 예시 프롬프트  
    - "프로토타입·스펙·구현 노트를 Slack에 올려 동의를 얻을 단일 문서로 묶어라. 데모 GIF를 앞세워라"  
- ## 퀴즈 (Quizzes)  
  - 긴 작업 세션 후 Claude가 예상보다 많이 해냈을 수 있으며, 코드 diff만으로는 기존 코드 경로에 의존하는 동작을 가볍게만 이해하게 됨  
  - 컨텍스트를 준 뒤 Claude에게 변경 사항에 대해 **퀴즈를 내달라고 요청**해 이해를 확인하고, 퀴즈를 완벽히 통과한 후에만 머지  
  - 예시 프롬프트  
    - "이 변경에서 일어난 모든 것을 이해하고 싶음. 컨텍스트·직관·수행 내용 등을 담은 HTML 리포트와 반드시 통과해야 할 퀴즈를 하단에 달아달라"  
  
### Fable 출시 사례로 본 통합 (How this comes together)  
  
- **[Fable 런치 영상](https://www.google.com/url?q=https://x.com/ClaudeDevs/status/2064399512664526853&sa=D&source=editors&ust=1783101769363678&usg=AOvVaw1MyZd5YMjjShztWHzo8N9u)은 전적으로 Claude Code로 편집**되었으며, 새로운 영역이자 전문 분야가 아니었음  
- 아는 것에서 시작해, Claude가 코드로 영상 편집·전사가 가능함은 알았으나 정확도를 확신하지 못해 **Whisper 방식의 전사 원리**와 ffmpeg로 ums·긴 침묵을 정확히 잘라낼 수 있는지 설명을 요청  
- 말하는 단어와 타이밍이 맞는 UI를 원했지만 가능할지 확신이 없어, **Remotion과 전사**로 프로토타입 영상을 만들어 검증  
- 영상이 다소 muted해 보인 것은 color grading 때문임을 알았으나 그것이 무엇인지 몰라, 변형을 골라내는 대신 **color grading을 가르쳐달라 요청**해 미지를 발견  
  
### 지도와 영토 맞추기 (Matching the Map and Territory)  
  
- 모델이 좋아질수록 올바른 접근으로 더 많은 것을 달성 가능하며, 장기 과제가 잘못 돌아오면 대개 **미지 정의**나 Claude가 즉흥 대응할 수 있는 구현 계획에 더 시간을 써야 함  
- 모든 설명·브레인스토밍·인터뷰·프로토타입·레퍼런스는 문제가 **비싸지기 전에 저렴하게 미지를 발견**하는 수단  
- 다음 프로젝트는 Claude에게 미지 찾기를 요청하며 시작하는 것이 핵심

## Comments



_No public comments on this page._