에이전트에게 일을 맡기기 전, 우리는 대부분 너무 빨리 프롬프트를 작성한다. 원하는 결과를 머릿속으로 그려놓고 곧장 지시를 내리지만, 정작 에이전트가 헤매는 건 명령이 부족해서가 아니라 우리 자신이 모른다는 사실조차 몰랐던 것들 때문이다. Claude Fable 팀이 공개한 필드 가이드(GeekNews)는 이 문제를 정면으로 다룬다. 핵심 개념은 '지도(Map)와 영토(Territory)의 간극', 즉 미지(Unknowns)다.
지도는 우리가 에이전트에게 주는 것—프롬프트, 스킬, 컨텍스트—이고, 영토는 코드베이스와 현실의 제약이다. 이 둘 사이의 간극이 곧 미지다. Fable 가이드는 미지를 네 가지로 분류한다. Known Knowns(프롬프트에 이미 담긴 것), Known Unknowns(모른다는 걸 아는 것), Unknown Knowns(너무 당연해 적지 않은 것), 그리고 Unknown Unknowns(인지조차 못 한 것). 에이전틱 코딩에서 가장 위험한 건 마지막이다. 이걸 사전에 끄집어내지 않으면 에이전트는 우리가 원하는 바에 대해 '최선의 추측'으로 결정을 내리고, 우리는 한참 뒤에 그 결과를 마주한다.
그렇다면 미지를 어떻게 찾는가. Fable 가이드가 제안하는 첫 번째 도구는 Blind Spot Pass다. 새 영역에 진입할 때 Claude에게 "나는 이 코드베이스의 auth 모듈을 전혀 모른다. unknown unknowns를 찾아 설명해달라"고 요청하는 것이다. 이 한 번의 요청이 이후 구현 전체의 방향을 바꿀 수 있다. 두 번째는 프로토타입과 브레인스토밍이다. 시각 디자인처럼 '보면 알지만 말로 표현하기 어려운' 영역에서는 완전히 다른 방향의 HTML 목업 네 개를 요청하는 방식으로, 구현 이전에 unknown knowns를 언어화한다. 스펙의 작은 변화가 코드 구현을 크게 바꾸는 만큼, 이 단계를 건너뛰면 비용이 기하급수적으로 오른다.
여기에 인터뷰와 레퍼런스 기법이 더해진다. 브레인스토밍 후에도 모호함이 남으면 Claude에게 "아키텍처를 바꿀 질문을 한 번에 하나씩 물어달라"고 요청한다. 원하는 바를 묘사하기 어렵다면 다이어그램이나 문서보다 소스 코드가 최고의 레퍼런스다. 다른 언어로 작성된 라이브러리라도 폴더를 가리키면 Claude는 마크업, 구조, 실제 구현 방식까지 읽어낸다. 이 모든 과정은 구현이 시작되기 전에 미지를 발굴하는 전략이며, Fable은 이를 "문제가 비싸지기 전에 저렴하게 미지를 발견하는 수단"이라고 표현한다.
실제 Fable 런치 영상 제작 사례가 이 워크플로우를 잘 보여준다. 팀은 Claude Code로 영상을 편집하면서, Whisper 전사의 정확도와 ffmpeg의 침묵 컷팅 가능 여부를 먼저 설명해달라고 요청했다. 영상이 다소 밋밋해 보였을 때 'color grading'이라는 단어를 몰랐지만, 변형 결과물을 고르는 대신 color grading 자체를 가르쳐달라고 요청해 미지를 먼저 제거했다. 알고 나서야 원하는 변환을 정확히 지시할 수 있었다.
이 '미지 발견 → 프로토타입 → 구현' 흐름은 dev.to에 연재 중인 인디 개발자 Leo Zhang의 'MVP 2주 출시' 전략과 맞닿는다. 그는 3개월을 쏟은 프로젝트가 아무도 쓰지 않는 걸 경험한 뒤 규칙을 세웠다. 2주 안에 쓸 수 있는 무언가를 출시하지 못하면, 너무 많이 만들고 있는 것이다. OpenNomos Json은 타임스탬프 변환기와 JSON 파서 단 두 개의 도구로 시작했고, 사람들은 즉시 쓰기 시작했다. '출시'의 정의도 명확하다. URL을 입력하면 동작하고, 단 하나의 문제를 해결하며, 실제로 완료됐는지 측정할 수 있는 것.
두 관점을 합치면 실용적인 워크플로우가 완성된다. 1단계: Blind Spot Pass로 unknown unknowns를 꺼낸다. 프로젝트를 시작할 때 첫 프롬프트는 구현 지시가 아니라 미지 탐색 요청이어야 한다. 2단계: HTML 목업이나 가짜 데이터 프로토타입으로 unknown knowns를 언어화한다. 백엔드 연결 없이 레이아웃에 먼저 반응하는 것만으로 스펙을 크게 좁힐 수 있다. 3단계: 구현 노트를 유지하며 에이전트가 계획에서 벗어날 때 기록하게 한다. implementation-notes.md에 이탈 이유를 남기면 다음 세션의 컨텍스트가 된다. 4단계: 퀴즈로 코드 이해를 검증한 뒤 머지한다. 긴 에이전트 세션 후 diff만으로는 변경 맥락을 파악하기 어렵다.
이 흐름에서 '2주'는 단순한 데드라인이 아니다. 미지를 가장 저렴하게 발견할 수 있는 타임박스다. 6개월을 조용히 만들다가 런칭했을 때의 침묵보다, 2주 후 "JSON 오류 메시지가 헷갈린다"는 피드백 한 줄이 훨씬 가치 있다. 모델이 좋아질수록 올바른 접근으로 더 많은 걸 달성할 수 있다고 Fable 가이드는 말한다. 하지만 역설적으로, 모델이 강력해질수록 미지를 제대로 정의하지 않았을 때의 비용도 커진다. 에이전트는 우리의 미지를 자신의 최선으로 채울 뿐이다.
결국 에이전틱 코딩의 병목은 모델 성능이 아니다. 미지를 명확히 하는 개발자의 능력이다. 다음 프로젝트를 시작할 때 가장 먼저 할 일은 구현 계획 작성이 아니라, Claude에게 이렇게 묻는 것이다. "내가 모른다는 걸 모르는 게 뭔지 알려달라." 그 한 줄이 이후 2주를 전혀 다른 궤도에 올려놓는다.