Claude Fable 실전 가이드: 미지의 요소를 먼저 파악하라

Claude Code로 작업할 때면, 나는 종종 지도와 실제 지형의 차이를 떠올린다.

지도는 해야 할 작업을 표현한 것으로, 내가 Claude에게 전달하는 프롬프트와 맥락, 그리고 나의 역량이 여기에 해당한다. 반면 실제 지형은 작업이 실제로 이루어지는 곳, 즉 코드베이스와 현실 세계, 그리고 그것이 가진 실제 제약들이다.

지도와 실제 지형 사이의 간극, 나는 이것을 미지의 요소라고 부른다. Claude가 미지의 요소에 부딪히면, 내가 원하는 것을 최대한 추정해 결정을 내려야 한다. 작업량이 많아질수록, Claude가 마주치는 미지의 요소도 늘어난다.

Claude Fable은 내가 처음으로, 작업 품질이 내 능력—즉 미지의 요소를 얼마나 잘 파악하고 명확히 하느냐—에 의해 결정된다고 느낀 모델이다.

중요한 것은, 미리 계획을 세우는 것만으로는 충분하지 않다는 점이다. 구현 깊숙이 들어가서야 미지의 요소가 드러나기도 하고, 파고들다 보면 애초에 문제를 완전히 다른 방식으로 풀어야 한다는 사실을 깨닫게 되기도 한다.

Fable과의 작업은 구현 전·중·후 각 단계에서 미지의 요소를 반복적으로 발견해나가는 과정이라는 것을 나는 몸소 경험했다.

미지의 요소를 파악하라

미지의 요소란 무엇인가? 나는 Claude에게 문제를 가져갈 때, 그것을 네 가지 방식으로 분류한다.

• 알려진 기지(Known Knowns): 본질적으로 내 프롬프트에 담긴 내용이다. 내가 에이전트에게 원한다고 말하는 것이 무엇인가?
• 알려진 미지(Known Unknowns): 아직 해결하지 못했지만, 해결하지 못했다는 사실 자체는 인식하고 있는 것이다.
• 숨겨진 기지(Unknown Knowns): 너무나 당연해서 굳이 적어두지 않지만, 막상 보면 바로 알아차릴 수 있는 것이다.
• 숨겨진 미지(Unknown Unknowns): 아예 고려조차 하지 못한 것이다. 내가 모른다는 사실조차 모르는 지식은 무엇인가? 어떤 것이 얼마나 좋아질 수 있는지 알고 있는가?

에이전트 코딩을 잘하는 사람들은 미지의 요소가 상대적으로 적다. Boris나 Jarred가 프롬프트를 작성하는 모습을 보면, 그들이 자신이 원하는 것을 얼마나 구체적으로 알고 있는지 한눈에 느껴진다. 코드베이스와 모델의 동작 방식 모두에 깊이 동기화되어 있는 것이다.

하지만 그들도 미지의 요소는 존재한다고 가정한다. 어떤 의미에서, 미지의 요소를 줄이고 그에 대비하는 것 자체가 에이전트 코딩의 핵심 역량이다. 다행히도, 이는 Claude와 함께 작업하면서 충분히 키울 수 있는 역량이다.

Claude가 당신을 도울 수 있도록

Claude에게 지시하는 것은 섬세한 균형이 필요한 일이다. 너무 구체적이면 방향 전환이 필요한 순간에도 Claude는 지시를 그대로 따른다. 반대로 너무 모호하면, Claude는 업계의 일반적인 관행을 기준으로 선택하고 가정을 세우는데, 이것이 당신의 작업에 맞지 않을 수 있다.

미지의 요소를 고려하지 않으면 양쪽 모두 실패한다. 경로에 장애물이 가득할 때를 예측하지 못하고, 경로가 훤히 열려 있는데도 Claude에게 굳이 방향을 틀라고 지시하게 된다.

Claude는 미지의 요소를 더 빠르게 발견하는 데 도움을 줄 수 있다. 코드베이스와 인터넷을 매우 빠르게 탐색하고, 대부분의 주제에 대해 당신보다 훨씬 많은 것을 알고 있으며, 실패에서 더 빠르게 반복해 나갈 수도 있다.

이 과정에서 가장 중요한 것은 출발점에 대한 맥락을 Claude에게 충분히 전달하는 것이다. 예를 들어, 현재 생각이 어느 단계까지 진행되었는지 알려주고, 해당 문제와 코드베이스에 대한 자신의 경험 수준을 솔직하게 밝히고, 사고 파트너처럼 함께 논의할 수 있게 하라.

이 글에서는 미지의 요소를 발견하기 위해 내가 활용하는 패턴들을 소개한다.

구현 전:

• 맹점 점검
• 브레인스토밍 및 프로토타입
• 인터뷰
• 레퍼런스
• 구현 계획

구현 중:

• 구현 노트

구현 후:

• 피치 및 설명 문서
• 퀴즈

구현 전

맹점 점검

작업을 시작할 때 가장 유용한 것 중 하나는 자신의 맹점을 파악하는 것이다. 예를 들어, 코드베이스의 낯선 영역에서 기능을 구현하거나, 디자인 반복 작업처럼 익숙하지 않은 영역에서 Claude의 도움을 받을 때는 숨겨진 미지가 많을 수밖에 없다.

어떤 질문을 해야 할지, 좋은 결과물이 어떤 모습인지, 이전에 어떤 작업이 이루어졌는지, 어떤 함정을 피해야 하는지조차 모를 수 있다.

이런 상황에서는 Claude에게 숨겨진 미지를 찾아서 설명해달라고 요청할 수 있다. 나는 "맹점 점검(blind spot pass)"과 "숨겨진 미지(unknown unknowns)"라는 표현을 직접적으로 사용한다. 자신이 누구이고 무엇을 알고 있는지 맥락을 전달하는 것이 중요한데, 이를 통해 Claude가 어떻게 협업을 시작하면 좋을지 파악할 수 있다.

프롬프트 예시:

• "새 인증 프로바이더를 추가하는 작업을 하고 있는데, 이 코드베이스의 인증 모듈에 대해 아는 게 없어. 맹점 점검을 해줘서 관련된 숨겨진 미지를 파악하고 더 잘 프롬프트할 수 있게 도와줘."

• "컬러 그레이딩이 뭔지 모르는데 이 영상을 그레이딩 해야 해. 컬러 그레이딩에 대한 나의 숨겨진 미지를 이해할 수 있도록 가르쳐줘서, 더 잘 프롬프트할 수 있게 해줘."

브레인스토밍 및 프로토타입

직접 봐야 기준을 정할 수 있는 숨겨진 기지가 많은 영역에서 작업할 때는, Claude와 함께 브레인스토밍하고 프로토타이핑하는 방식을 즐겨 사용한다.

숨겨진 기지는 프로토타이핑 초기에 찾아내고 언어로 명확히 해두는 것이 매우 중요하다. 구현 단계에서 발견하면 비용이 훨씬 더 커지기 때문이다. 기능이나 스펙의 작은 변경이 코드 구현 방식을 크게 바꿀 수 있고, 에이전트가 이전 변경 사항을 되돌리기도 더 어려워진다.

예를 들어, 백엔드 라우트를 연결하거나 프론트엔드 상태를 추가로 관리하지 않고도, 프레임에 버튼 하나를 추가했을 때 어떻게 보이는지 먼저 확인하고 싶을 수 있다.

또 다른 예로 비주얼 디자인이 있는데, 나는 이것을 말로 표현하기 어렵지만 직접 보면 내가 원하는 것을 바로 안다. 이런 경우에는 결과물에 대해 여러 가지 디자인 방향을 제시해달라고 요청한다.

코딩 세션을 시작할 때도 거의 항상 탐색이나 브레인스토밍 단계부터 시작한다. 이를 통해 프로젝트 범위를 의도적으로 정의하는 데서 출발할 수 있다. Claude는 내가 놓쳤을 고가치 접근법을 종종 찾아내지만, 때로는 큰 그림을 놓치기도 한다. 브레인스토밍은 범위를 너무 좁게 혹은 너무 넓게 설정하는 것을 막아준다.

프롬프트 예시:

• "이 데이터를 위한 대시보드가 필요한데 시각적 감각도 없고 뭐가 가능한지도 몰라. 완전히 다른 디자인 방향 4가지를 담은 HTML 페이지를 만들어줘서, 내가 반응할 수 있게 해줘."

• "아무것도 연결하기 전에, 가짜 데이터로 새 에디터 툴바를 흉내 낸 단일 HTML 파일을 만들어줘. 실제 앱에 손대기 전에 레이아웃에 대해 먼저 피드백할게."

• "대략적인 문제는 이래: 사용자들이 온보딩 후에 이탈해. 코드베이스를 살펴보고, 가장 간단한 것부터 가장 야심찬 것 순서로 개입할 수 있는 지점 10가지를 브레인스토밍해줘. 어떤 게 와닿는지 내가 알려줄게."

인터뷰

브레인스토밍을 충분히 했어도, 미지의 요소는 여전히 남아 있기 마련이다.

이럴 때는 Claude에게 미지의 요소나 모호한 부분에 대해 나를 인터뷰해달라고 요청한다. 인터뷰를 요청할 때는 질문의 방향을 잡을 수 있도록 문제에 대한 맥락을 충분히 전달하는 것이 좋다.

‍프롬프트 예시:

• "모호한 부분에 대해 질문 하나씩 차례로 인터뷰해줘. 내 답변이 아키텍처에 영향을 미칠 수 있는 질문을 우선적으로 물어봐."

레퍼런스

원하는 것을 구체적으로 표현하지 못할 때가 있다. 그럴 언어가 없거나, 너무 복잡해서 설명하는 데만 한참이 걸리는 경우다.

이런 경우에는 레퍼런스를 활용하는 것이 최선이다. 다이어그램, 문서, 이미지를 첨부할 수도 있지만, 단연 가장 좋은 레퍼런스는 소스 코드다.

특정 방식으로 구현된 라이브러리나 마음에 드는 디자인 컴포넌트가 있다면, 다른 언어로 작성된 것이라도 해당 폴더를 Fable에게 바로 가리키며 무엇을 찾아야 할지 알려주면 된다. 스크린샷과 비교해 마크업 구조까지 훨씬 풍부한 정보를 Claude에게 전달할 수 있다.

프롬프트 예시:

• "vendor/rate-limiter에 있는 이 Rust 크레이트가 내가 원하는 백오프 동작을 정확히 구현하고 있어. 읽어보고 같은 동작 방식을 우리 TypeScript API 클라이언트에 재구현해줘."

구현 계획

구현할 준비가 됐다고 판단되면, Claude에게 검토용 구현 계획을 작성해달라고 요청하는 편이다. 계획은 데이터 모델, 타입 인터페이스, UX 흐름처럼 변경 가능성이 가장 높은 부분에 초점을 맞춘다. 이를 통해 Claude가 실제로 수정이 필요할 수 있는 사항들을 미리 드러낼 수 있다.

프롬프트 예시:

• "HTML로 구현 계획을 작성해줘. 단, 내가 가장 많이 조정할 것 같은 항목—데이터 모델 변경, 새 타입 인터페이스, 사용자에게 보이는 모든 것—을 앞에 배치해줘. 기계적인 리팩터링은 맨 아래에 묻어둬도 돼, 그 부분은 믿어."

구현 중

구현 노트

계획이 만족스러우면 새 세션을 열고 결과물을 프롬프트에 전달한다. Claude에게 새로운 컨텍스트 창을 주되, 계획 단계에서 정리한 모든 정보는 함께 넘긴다. 예를 들어, 스펙 파일과 프로토타입을 함께 전달하며 에이전트에게 구현을 요청하는 식이다.

하지만 현실에서는 아무리 철저히 계획해도 숨겨진 미지는 항상 도사리고 있다. 에이전트가 작업 중에 코드에서 예외 케이스를 발견해 방향을 바꿔야 하는 상황이 생기기도 한다.

나는 Claude Code에게 임시 'implementation-notes.md'(또는 .html) 파일을 유지하면서, 내린 결정들을 기록해달라고 요청한다. 다음 시도에서 배울 수 있도록 하기 위해서다.

프롬프트 예시:

• "implementation-notes.md 파일을 유지해줘. 계획에서 벗어날 수밖에 없는 예외 케이스가 생기면, 보수적인 선택을 하고 '이탈 사항'에 기록한 다음 계속 진행해줘."

구현 후

피치 및 설명 문서

무언가를 출시할 때 가장 중요한 것 중 하나는 동의와 승인을 얻는 것이다. 최종 문서에 피치와 설명 자료를 함께 구성해두면 다음과 같은 효과가 있다.

• 검토자가 처음에 나와 동일한 미지의 요소에서 출발할 때, 이해를 빠르게 가속화
• 전문가가 예상했을 미지의 요소와 주요 실패 지점을 충분히 고려했다는 것을 보여줌으로써, 승인 절차를 빠르게 진행

프롬프트 예시:

• "프로토타입, 스펙, 구현 노트를 하나의 문서로 묶어줘. Slack에 바로 올려서 동의를 얻을 수 있게. 데모 GIF로 시작해."

퀴즈

긴 작업 세션이 끝나고 나면, Claude가 내가 생각한 것보다 훨씬 많은 일을 해냈을 수 있다. 코드 diff를 읽어봐도 표면적인 이해에 그치는 경우가 많다. 실제 동작의 상당 부분은 기존 코드 경로에 달려 있기 때문이다.

변경 사항에 대한 충분한 맥락을 먼저 전달받은 뒤, Claude에게 퀴즈를 내달라고 요청하면 무슨 일이 일어났는지 제대로 이해하는 데 도움이 된다. 퀴즈를 완벽히 통과한 후에야 병합한다.

프롬프트 예시:

• "이번 변경 사항을 완전히 이해하고 싶어. 맥락, 직관, 무엇이 어떻게 바뀌었는지 등을 담은 HTML 리포트를 만들어줘서 읽고 이해할 수 있게 해줘. 그리고 마지막에 반드시 통과해야 하는 퀴즈도 추가해줘."

모든 것이 하나로: Fable 출시

Fable 출시 영상은 Claude Code를 사용해 처음부터 끝까지 편집됐다. 내게는 완전히 새로운 영역이었고, 결코 전문가라고 할 수 없었다.

그래서 내가 아는 것에서부터 시작했다. Claude가 코드를 활용해 영상을 편집하고 전사(transcribe)할 수 있다는 것은 알았지만, 충분히 정확할지는 확신이 없었다. 그래서 Whisper 같은 전사 기술이 어떻게 작동하는지, ffmpeg을 사용해 "음"이나 긴 침묵 같은 부분을 정확하게 잘라낼 수 있는지 Claude에게 설명해달라고 요청했다.

내가 말하는 단어에 맞춰 타이밍이 맞는 UI를 Claude가 만들어주길 원했는데, 가능한지 확신이 없었다. 그래서 Remotion과 전사본을 활용해 프로토타입 영상을 먼저 만들어달라고 해서 실현 가능한지 확인했다.

마지막으로, 영상 자체가 다소 칙칙해 보였는데 컬러 그레이딩 때문이라는 것은 알았지만, 컬러 그레이딩이 정확히 무엇인지는 몰랐다. 처음에는 Claude에게 몇 가지 변형 버전을 만들어달라고 해서 골라보려 했다. 그런데 컬러 그레이딩에서 '좋다'는 것이 어떤 모습인지 내가 전혀 모른다는 것을 깨달았다. 그래서 방향을 바꿔, Claude에게 컬러 그레이딩을 가르쳐달라고 해서 나의 미지의 요소를 먼저 파악하는 방식을 택했다.

지도와 지형을 맞추다

모델 성능이 향상될수록, 올바른 접근 방식으로 얻을 수 있는 것도 더 많아진다. 장기 작업이 잘못된 결과를 냈다면, 미지의 요소를 정의하거나 당신과 Claude가 함께 유연하게 대응할 수 있는 구현 계획을 수립하는 데 더 많은 시간을 투자해야 한다는 신호일 가능성이 높다.

설명 문서, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스 하나하나는 모두, 나중에 수정 비용이 커지기 전에 미처 몰랐던 것을 값싸게 발견하는 방법이다.

다음 프로젝트는 Claude에게 미지의 요소를 찾는 것부터 도움을 구하며 시작해보자.

이 글은 Anthropic의 테크니컬 스태프 Thariq Shihipar가 작성했습니다.