Claude Code에 코딩을 맡길 때, 결과물의 품질은 결국 사용자가 자신이 ‘모르는 것(unknowns)’ 을 얼마나 잘 파악하고 전달하느냐에 달려 있습니다.

‘지도는 영토가 아니다’라는 말처럼, 우리가 프롬프트와 지시로 그리는 지도 와 실제 코드베이스라는 영토 사이에는 늘 간극이 있습니다. 좋은 결과란 이 간극을 좁히는 일이고, 간극의 정체는 내가 미처 말하지 못한 ‘모르는 것’입니다. 이 글은 Thariq(@trq212) 의 “A Field Guide to Fable: Finding Your Unknowns"를 정리한 것입니다.

네 가지 ‘모르는 것’

내가 무엇을 모르는지부터 분류하면 소통의 사각지대가 드러납니다. 크게 네 갈래로 나눌 수 있습니다.

  • 아는 것을 아는 것(known knowns) — 프롬프트에 명시적으로 적어 넣는 내용입니다.
  • 모르는 것을 아는 것(known unknowns) — 아직 파악하지 못했지만, 스스로 모른다는 사실만큼은 인지하고 있는 부분입니다.
  • 아는 것을 모르는 것(unknown knowns) — 너무 당연해서 굳이 말하지 않지만, 막상 결과를 보면 “이건 아닌데” 하고 알아채는 암묵적 기준입니다.
  • 모르는 것도 모르는 것(unknown unknowns) — 존재조차 몰라 아예 고려하지 못한 영역입니다.

결과물을 무너뜨리는 주범은 세 번째와 네 번째입니다. 말하지 못한 취향과 떠올리지도 못한 변수가 지도에서 통째로 빠지기 때문입니다. 아래 기법들은 이 사각지대를 구현 전·중·후 단계별로 좁혀 갑니다.

구현 전: 사각지대를 미리 줄이기

착수하기 전에 ‘모르는 것’을 최대한 지도 위로 끌어올리는 단계입니다.

  • 블라인드 스팟 패스(Blind Spot Pass) — Claude에게 나의 배경지식과 상황을 먼저 알려주고, 낯선 영역에서 내가 놓치고 있는 ‘모르는 것도 모르는 것’을 짚어 달라고 요청합니다.
  • 브레인스토밍·프로토타입 — 말로 설명하기 어려운 취향이나 기준은 여러 시안(예: HTML 목업)으로 만들어 보고 거기에 반응하며 찾아갑니다. 반응이 곧 기준을 드러냅니다.
  • 인터뷰 — Claude가 한 번에 하나씩 질문하게 해서, 모호하게 남아 있던 부분을 스스로 말로 정리하도록 유도합니다.
  • 레퍼런스 제공 — 설명하기 힘든 요구사항은 유사한 소스코드나 참고 모듈을 직접 보여 주는 편이 가장 정확합니다.
  • 구현 계획서 요청 — 바뀔 가능성이 큰 부분(데이터 모델, 타입, UX 흐름 등)을 먼저 검토할 수 있도록 계획부터 받아 봅니다.

구현 중: 벗어난 결정을 기록하기

구현이 시작되면 계획은 어긋나기 마련입니다. 이때 implementation-notes.md 같은 파일에 계획에서 벗어난 결정과 예외 상황을 그때그때 기록하게 하면, 나중에 무엇이 왜 달라졌는지 되짚는 학습 자료가 됩니다.

구현 후: 이해도를 검증하기

  • 피치·설명 문서 — 프로토타입과 스펙, 구현 노트를 하나의 문서로 묶으면 이해관계자의 승인을 훨씬 빠르게 받을 수 있습니다.
  • 퀴즈 — 변경사항을 두고 Claude가 나에게 퀴즈를 내게 합니다. 그 퀴즈를 통과해야 머지하는 규칙을 두면, 내가 정말 이해했는지 스스로 점검하게 됩니다.

사례: Fable 런칭 영상 만들기

저자는 영상 편집 경험이 전혀 없었지만, ‘모르는 것’을 하나씩 좁혀 가며 Fable 런칭 영상을 완성했습니다.

  • 자막을 붙이기 위해 Claude에게 Whisper 기반 전사(transcription) 원리부터 설명받았습니다.
  • Remotion 으로 프로토타입을 만들어 자막 타이밍을 눈으로 검증했습니다.
  • 색보정(color grading)은 개념 자체를 몰랐기에, 용어와 원리부터 Claude에게 배우며 접근했습니다.

낯선 분야일수록 ‘모르는 것도 모르는 것’이 많습니다. 저자는 그 영역을 Claude와의 대화로 하나씩 ‘아는 것’으로 바꿔 나갔습니다.

너무 구체적이지도, 너무 모호하지도 않게

결국 핵심은 균형입니다. 지시가 지나치게 구체적이면 더 나은 대안을 막고, 지나치게 모호하면 엉뚱한 영토로 향합니다. 작업이 길고 비쌀수록, 착수 전에 자신의 ‘모르는 것’을 파악하고 계획을 세우는 일이 비용을 줄이는 가장 확실한 전략입니다.

지도를 더 크고 화려하게 그리는 데 매달리지 마세요. 내 지도에서 무엇이 비어 있는지를 먼저 찾는 것, 그것이 영토에 한 걸음 더 가까워지는 길입니다.

핵심 정리

  • Claude Code 결과물의 품질은 사용자가 자신의 ‘모르는 것(unknowns)‘을 얼마나 잘 파악하고 전달하는지에 달려 있습니다.
  • ‘모르는 것’은 네 가지로 나뉘며, 특히 말하지 않은 암묵적 기준(아는 것을 모르는 것)과 고려조차 못 한 영역(모르는 것도 모르는 것)이 결과를 좌우합니다.
  • 블라인드 스팟 패스·프로토타입·레퍼런스·구현 계획서로 착수 전에 사각지대를 줄이고, 구현 노트와 퀴즈로 이해도를 검증하면 긴 작업의 비용을 크게 줄일 수 있습니다.