Fable 실전 가이드: 미지의 영역을 찾아내는 법

Claude Fable 5 와 함께 작업하면서 계속해서 배우는 오래된 교훈이 있습니다: 지도는 영토가 아니라는 것입니다.

해야 할 작업을 표현한 지도는 제 프롬프트, 스킬, 컨텍스트이며, 이는 제가 Claude 에게 주는 것입니다. 영토는 작업이 실제로 이루어져야 하는 곳, 즉 코드베이스, 현실 세계, 그리고 그 실제 제약 조건입니다.

지도와 영토의 차이점을 저는 미지의 것이라고 부릅니다. Claude 가 미지의 것과 마주치면, 제가 원하는 바에 대한 최선의 추측을 바탕으로 결정을 내려야 합니다. 더 많은 작업이 이루어질수록 Claude 가 마주칠 수 있는 미지의 것도 더 많아집니다.

Fable 은 작업의 질이 제가 그 미지의 것들을 명확히 하는 능력에 의해 병목 현상이 발생하는 첫 번째 모델입니다.

중요한 점은, 단순히 사전에 계획을 세우는 것만으로는 충분하지 않다는 것입니다. 구현 과정 깊숙이 미지의 것을 발견할 수도 있고, 미지의 것이 문제를 완전히 다른 방식으로 해결해야 한다는 사실을 알려줄 수도 있습니다.

Fable 과 협업하는 것은 구현 전, 구현 중, 구현 후에 걸쳐 제 미지의 것들을 발견하는 반복적인 과정임을 깨달았습니다.

여기에서 미지의 것을 찾기 위한 예시 아티팩트를 만들었지만, 언제 사용해야 할지에 대한 직관을 기르기 위해 꼭 돌아와서 읽어보시기 바랍니다.

자신의 미지의 것 알기

당신의 미지의 것은 무엇인가요? 제가 Claude 에게 문제를 제시할 때는 보통 4 가지 방식으로 분석합니다:

• 알고 있는 것을 알고 있음: 이것은 본질적으로 제 프롬프트에 있는 내용입니다. 에이전트에게 내가 원하는 바를 무엇이라고 말했는가?
• 알고 있는 미지의 것: 아직 파악하지 못했지만, 파악하지 못했다는 사실을 인지하고 있는 것은 무엇인가?
• 모르고 있던 알고 있음: 너무 자명해서 절대 기록하지 않았지만, 보자마자 알아볼 수 있는 것은 무엇인가?
• 모르고 있는 미지의 것: 전혀 고려하지 않은 것은 무엇인가? 어떤 지식을 내가 알지 못하고 있는가? 어떤 것이 얼마나 좋을 수 있는지 내가 알고 있는가?

최고의 에이전틱 코더들은 미지의 것이 상대적으로 적습니다. Boris나 Jarred 같은 사람이 프롬프트를 입력하는 모습을 보면, 그들이 자신이 원하는 바를 상세히 알고 있다는 것이 명확히 드러납니다. 그들은 코드베이스와 모델 동작 모두에 깊이 동기화되어 있습니다.

하지만 그들 역시 미지의 것을 가정합니다. 여러모로, 미지의 것을 줄이고 이에 대비하는 것이 에이전틱 코딩의 스킬입니다. 하지만 운 좋게도, 이는 Claude 와 함께 작업함으로써 향상시킬 수 있는 스킬입니다.

Claude 가 당신을 돕도록 도우세요

Claude 에게 지시하는 것은 섬세한 균형을 필요로 합니다. 너무 구체적이면, 방향 전환이 더 적절할 때조차 Claude 가 당신의 지시를 따를 것입니다. 너무 모호하면, Claude 는 종종 당신의 작업에 적합하지 않을 수 있는 업계 모범 사례를 바탕으로 선택과 가정을 합니다.

미지의 것을 고려하지 않으면 두 가지 방식 모두 실패합니다. 언제 경로에 장애물이 가득할지, 언제 경로가 깨끗할지 알 수 없지만, 여전히 Claude 가 방향을 바꾸길 원합니다.

Claude 는 당신이 미지의 것을 더 빨리 발견하도록 도울 수 있습니다. 코드베이스와 인터넷을 매우 빠르게 검색할 수 있고, 평균적인 주제에 대해 당신보다 훨씬 많이 알고 있습니다. 또한 실패로부터 더 빠르게 반복할 수 있습니다.

이 과정에서 가장 중요한 부분은 Claude 에게 당신의 시작점에 대한 맥락을 제공하는 것입니다. 예를 들어, 사고 과정의 어디쯤에 있는지 알려주고; 문제와 코드베이스에 대한 경험을 공개하며; 사고 파트너처럼 함께 작업하도록 하는 것입니다.

저는 이전에 HTML 과 Claude 를 함께 사용하는 방법에 대해 글을 쓴 적이 있는데, 거의 모든 경우에서 HTML 아티팩트가 이를 시각화하고 표현하는 최고의 방법입니다.

이 글에서는 이러한 미지의 것을 발견하기 위해 제가 사용하는 몇 가지 패턴을 자세히 설명합니다. 매번 모든 기술을 사용하는 것은 아니지만, 가지고 있으면 유용한 기술 모음집입니다.

구현 전

블라인드 스팟 패스

작업을 시작할 때 가장 유용한 것 중 하나는 자신의 맹점을 이해하는 것입니다. 예를 들어, 코드베이스의 새로운 부분에서 기능을 작성하거나 디자인 반복과 같은 익숙하지 않은 작업을 위해 Claude 를 사용한다면, 모르는 미지의 것이 많을 가능성이 높습니다.

무슨 질문을 해야 할지, 좋은 결과가 무엇인지, 어떤 선례 작업이 있었는지, 어떤 함정을 피해야 할지 모를 수 있습니다.

이를 위해 Claude 에게 당신의 모르는 미지의 것을 찾아서 설명해 달라고 요청할 수 있습니다. 저는 문자 그대로 "블라인드 스팟 패스"와 "모르는 미지의 것"이라는 단어를 사용하는 것을 좋아합니다. 당신이 누구이고 무엇을 알고 있는지에 대한 컨텍스트를 제공하는 것이 일반적으로 중요합니다.

예시 프롬프트:

• "새로운 인증 제공자를 추가하는 작업을 하고 있는데 이 코드베이스의 인증 모듈에 대해 아무것도 몰라. 블라인드 스팟 패스를 해서 내가 놓치고 있는 관련 모르는 미지의 것들을 파악하고 더 나은 프롬프트를 작성할 수 있도록 도와줘."
• "컬러 그레이딩이 무엇인지 모르지만 이 비디오를 그레이딩해야 해. 컬러 그레이딩에 대한 내 모르는 미지의 것들을 이해할 수 있도록 가르쳐줘, 그래야 더 나은 프롬프트를 작성할 수 있을 것 같아."

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

볼 때만 정의할 수 있는 기준(모르고 있던 알고 있음)이 많은 영역에서 작업할 때는 Claude 에게 저와 함께 브레인스토밍하고 프로토타입을 만들어 달라고 요청하는 것을 좋아합니다.

프로토타입 단계에서 모르고 있던 알고 있음을 조기에 식별하고 언어화하는 것은 매우 가치가 있습니다. 구현 중에 이를 발견하면 (상대적으로) 비용이 많이 들 수 있기 때문입니다. 기능이나 사양의 작은 변화가 코드에서 완전히 다른 구현을 초래할 수 있으며, 에이전트가 이전 변경 사항을 되돌리기가 더 어려울 수 있습니다.

예를 들어, 백엔드 라우트를 연결하거나 프론트엔드에서 추가 상태를 유지하지 않고 프레임에 추가된 버튼이 어떻게 보일지 보고 싶을 수 있습니다.

시각적 디자인은 제가 표현하기 어려워하는 부분이지만, 보면 원하는 것을 압니다. 이런 경우, 저는 아티팩트에 대한 여러 디자인 접근 방식을 요청합니다.

또한 거의 모든 코딩 세션을 탐색 또는 브레인스토밍 단계로 시작합니다. 이는 프로젝트의 범위를 정의하려는 의도로 시작하는 데 도움이 됩니다. Claude 는 종종 제가 놓쳤을 높은 가치의 접근 방식을 찾아내기도 하고, 때로는 나무만 보고 숲을 놓치기도 합니다. 브레인스토밍은 제가 너무 좁거나 너무 넓은 범위를 설정하는 것을 방지해 줍니다.

예시 프롬프트:

• "이 데이터에 대한 대시보드를 원하는데 시각적 감각이 없고 무엇이 가능한지 몰라. 4 가지 완전히 다른 디자인 방향으로 HTML 페이지를 만들어서 내가 반응할 수 있게 해줘."
• "실제 연결을 하기 전에, 가짜 데이터로 새 에디터 도구 모음을 모킹한 단일 HTML 파일을 만들어줘. 실제 앱을 건드리기 전에 레이아웃에 반응하고 싶어."
• "내 대략적인 문제는 이거야: 사용자들이 온보딩 후에 이탈해. 코드베이스를 검색하고 우리가 개입할 수 있는 10 곳을 가장 저렴한 것부터 가장 야심찬 것까지 브레인스토밍해줘. 어떤 것이 공감 가는지 알려줄게."

인터뷰

충분한 브레인스토밍을 한 후에도 여전히 미지의 것이 남아 있을 가능성이 높습니다.

이런 경우 Claude 에게 미지의 것이나 모호한 점에 대해 저를 인터뷰해 달라고 요청합니다. Claude 가 인터뷰를 하도록 요청할 때는 문제에 대한 컨텍스트를 제공하여 질문을 유도하도록 해보세요. 몇 가지 예시입니다.

예시 프롬프트:

• "모호한 것들에 대해 한 번에 하나씩 질문하며 인터뷰해줘. 내 대답이 아키텍처를 바꿀 수 있는 질문에 우선순위를 둬."

참조

때로는 원하는 것을 자세히 설명할 수 없을 때가 있습니다. 예를 들어, 언어가 부족하거나 너무 복잡해서 시간이 꽤 오래 걸릴 수 있습니다.

이런 경우 가장 좋은 해결책은 참조입니다. 다이어그램, 문서 또는 사진을 포함할 수 있지만, 가장 좋은 참조는 소스 코드입니다.

특정 방식으로 무언가를 구현하는 라이브러리나 정말 마음에 드는 디자인 구성 요소가 있다면, 다른 언어로 작성되었더라도 Fable 을 해당 폴더로 지정하고 무엇을 찾아야 하는지 알려주기만 하면 됩니다.

이것이 Claude Design 이 작동하는 방식이기도 합니다. 파일을 건네줄 필요는 없지만(물론 그렇게 할 수도 있습니다). 마음에 드는 웹사이트의 모듈을 지정하면, 스크린샷뿐만 아니라 기본 코드를 읽습니다. 이는 마크업, 구조, 그리고 구성 요소가 실제로 어떻게 구축되었는지에 대해 훨씬 더 풍부한 세부 정보를 제공합니다.

예시 프롬프트:

• "vendor/rate-limiter 에 있는 이 Rust 크레이트가 내가 원하는 정확한 백오프 동작을 구현하고 있어. 그것을 읽고 동일한 의미를 우리 TypeScript API 클라이언트에 다시 구현해줘."

구현 계획

구현할 준비가 되었다고 생각되면, 변경될 가능성이 가장 높은 부분(예: 데이터 모델, 타입 인터페이스 또는 UX 흐름 검토)에 초점을 맞춘 구현 계획을 작성해 달라고 Claude 에게 요청하는 경향이 있습니다. 이를 통해 Claude 가 실제로 수정해야 할 사항을 표면화할 수 있습니다.

예시 프롬프트:

• "구현 계획을 HTML 로 작성해줘. 하지만 내가 가장 수정할 가능성이 높은 결정들, 즉 데이터 모델 변경, 새로운 타입 인터페이스, 사용자 대면 부분을 먼저 제시해줘. 기계적인 리팩토링은 아래쪽에 두어도 돼, 그 부분은 네게 믿음을 줘."

구현 중

구현 노트

계획에 만족하면 새 세션을 만들고 모든 아티팩트를 프롬프트에 전달합니다. 예를 들어, 사양 파일과 프로토타입을 전달하고 에이전트에게 구현을 요청할 수 있습니다.

하지만 아무리 많은 계획을 세워도 항상 숨어 있는 모르는 미지의 것이 있다는 것이 진실입니다. 에이전트는 작업 중에 코드에서 발견한 엣지 케이스로 인해 다른 방식을 취해야 할 필요성을 발견할 수 있습니다.

저는 Claude Code 에게 임시 [implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359369&usg=AOvVaw1Iqvg51JpzkrkRtHHIjyOL) (또는 .html) 파일을 유지하도록 요청하여, 내린 결정을 추적하고 다음 시도에서 배울 수 있도록 합니다.

예시 프롬프트:

• "[implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359896&usg=AOvVaw1wFqbnqbAuO_GYnGk8_1bh) 파일을 유지해. 계획에서 벗어나야 하는 엣지 케이스를 만나면, 보수적인 옵션을 선택하고 '이탈' 아래에 기록한 다음 계속 진행해."

구현 후

피치 및 설명자

무언가를 출시하는 데 있어 가장 중요한 부분 중 하나는 지지와 승인을 얻는 것입니다. 최종 문서에 피치 및 설명자 아티팩트를 구축하면 다음 사항에 도움이 됩니다:

• 검토자가 당신과 동일한 미지의 것을 가지고 시작할 때 이해를 가속화합니다.
• 전문가들이 당신이 미지의 것과 그들이 예상했을 일반적인 실패 지점을 고려했는지 확인하려 할 때 승인을 가속화합니다.

예시 프롬프트:

• "프로토타입, 사양, 구현 노트를 Slack 에 올릴 수 있는 단일 문서로 패키징해서 지지를 얻어. 데모 GIF 로 시작해줘."

퀴즈

긴 작업 세션 후에 Claude 는 제가 깨달은 것보다 훨씬 더 많은 것을 성취했을 수 있습니다. 코드 차이점을 읽는 것은 무슨 일이 일어났는지에 대한 피상적인 이해만을 제공할 수 있습니다. 많은 동작이 기존 코드 경로에 의존하기 때문입니다.

Claude 에게 많은 컨텍스트를 제공한 후 변경 사항에 대해 퀴즈를 내도록 요청하면 무슨 일이 일어났는지 이해하는 데 도움이 됩니다. 저는 퀴즈를 완벽하게 통과한 후에만 병합합니다.

예시 프롬프트:

• "이 변경 사항에서 일어난 모든 것을 확실히 이해하고 싶어. 변경 사항에 대한 HTML 보고서를 작성해줘. 컨텍스트, 직관, 수행된 작업 등을 포함하여 내가 읽고 이해할 수 있게 하고, 맨 아래에는 반드시 통과해야 하는 변경 사항에 대한 퀴즈를 포함해줘."

이 모든 것이 어떻게 하나가 되는가: Fable 출시

Fable 출시 비디오는 Claude Code 에 의해 완전히 편집되었습니다. 이것은 저에게 새로운 영역이었고 저는 결코 전문가가 아닙니다.

그래서 제가 아는 것부터 시작했습니다. Claude 가 코드를 사용하여 비디오를 편집하고 트랜스크립션할 수 있다는 것을 알았지만, 그것이 충분히 정확한지 확신할 수 없었습니다. 그런 다음 Claude 에게 Whisper 와 같은 트랜스크립션이 어떻게 작동하는지, 그리고 ffmpeg 를 사용하여 '음'이나 긴 멈춤과 같은 것을 정확하게 잘라낼 수 있을지 설명해 달라고 요청했습니다.

Claude 가 제가 말하는 단어와 시간이 맞춰진 UI 를 만들기를 원했지만, 그것이 가능할지 확신이 없었기 때문에 Claude 에게 Remotion 과 트랜스크립션을 사용하여 프로토타입 비디오를 만들어서 작동하는지 확인해 달라고 요청했습니다.

마지막으로, 비디오 자체가 다소 칙칙해 보였는데, 이는 컬러 그레이딩의 결과라는 것을 알았지만 컬러 그레이딩이 실제로 무엇인지 잘 알지 못했습니다. 첫 번째 시도는 Claude 에게 몇 가지 변형을 만들어 선택하게 하는 것이었지만, 컬러 그레이딩에 있어 "좋은" 것이 무엇인지 모른다는 것을 깨달았습니다. 그래서 대신 Claude 에게 컬러 그레이딩에 대해 가르쳐 달라고 요청하여 제 미지의 것을 발견했습니다.

이에 대한 더 자세한 설명은 [여기](https://x.com/trq212/status/2064826394589442448/video/1)에서 볼 수 있습니다.

지도와 영토 일치시키기

모델이 좋아질수록 올바른 접근 방식으로 더 많은 것을 성취할 수 있습니다. 장기적인 작업이 잘못되어 돌아왔을 때, 아마도 미지의 것을 정의하거나 Claude 가 이를 통해 즉흥적으로 대처할 수 있도록 하는 구현 계획을 만드는 데 더 많은 시간을 할애해야 할 필요가 있습니다.

모든 설명자, 브레인스토밍, 인터뷰, 프로토타입 및 참조는 수정 비용이 비싸지기 전에 당신이 몰랐던 것을 발견하는 저렴한 방법입니다.

그러니 다음 프로젝트를 Claude 에게 당신의 미지의 것을 찾는 데 도움을 달라고 요청하면서 시작하세요.