• 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 작업은 구현 전·중·후에 걸쳐 미지를 발견하는 반복 과정
• 미지의 것을 찾는 데 도움이 되는 몇가지 예시 자료 나중에 참고 할 것

미지 알기 (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을 사용하는 것에 대해 글을 쓴 적이 있는데, 대부분의 경우
  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 런치 영상은 전적으로 Claude Code로 편집되었으며, 새로운 영역이자 전문 분야가 아니었음

• 아는 것에서 시작해, Claude가 코드로 영상 편집·전사가 가능함은 알았으나 정확도를 확신하지 못해
  Whisper 방식의 전사 원리와 ffmpeg로 ums·긴 침묵을 정확히 잘라낼 수 있는지 설명을 요청
• 말하는 단어와 타이밍이 맞는 UI를 원했지만 가능할지 확신이 없어,
  Remotion과 전사로 프로토타입 영상을 만들어 검증
• 영상이 다소 muted해 보인 것은 color grading 때문임을 알았으나 그것이 무엇인지 몰라, 변형을 골라내는 대신
  color grading을 가르쳐달라 요청해 미지를 발견

지도와 영토 맞추기 (Matching the Map and Territory)

• 모델이 좋아질수록 올바른 접근으로 더 많은 것을 달성 가능하며, 장기 과제가 잘못 돌아오면 대개
  미지 정의나 Claude가 즉흥 대응할 수 있는 구현 계획에 더 시간을 써야 함
• 모든 설명·브레인스토밍·인터뷰·프로토타입·레퍼런스는 문제가
  비싸지기 전에 저렴하게 미지를 발견하는 수단
• 다음 프로젝트는 Claude에게 미지 찾기를 요청하며 시작하는 것이 핵심

댓글과 토론