나의 미지수 찾기
핵심 요약
Anthropic의 Thariq Shihipar가 Claude Fable 5와 함께 일하며 얻은 교훈: 결과물의 품질은 나의 미지수(unknowns)를 얼마나 잘 밝혀내느냐에 달려 있습니다.
- 지도는 영토가 아니다: 프롬프트(지도)와 실제 작업 환경(영토) 사이의 간극이 곧 ‘미지수’이고, Claude는 미지수를 만날 때마다 추측으로 결정을 내립니다.
- 미지수를 4분면으로 나누기: 아는 앎, 아는 모름, 모르는 앎, 모르는 모름. 각각을 다루는 기법(블라인드스팟 패스, 브레인스토밍·프로토타입, 인터뷰, 레퍼런스)이 다릅니다.
- 구현 전·중·후 전 과정이 반복: 미리 계획하는 것만으로는 부족하고, 구현 노트·피치 문서·퀴즈로 계속 미지수를 드러내야 합니다.
- 왜 중요한가: 설명, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 모두 “고치기 비싸지기 전에” 몰랐던 것을 싸게 알아내는 방법입니다.
• • •
Claude Fable 5와 함께 일하다 보면 오래된 교훈 하나를 계속 다시 배우게 됩니다. 지도는 영토가 아니다1라는 것이죠.
지도, 즉 해야 할 일에 대한 표현은 제 프롬프트와 스킬과 컨텍스트입니다. 제가 Claude에게 건네주는 것들이죠. 영토는 실제로 일이 일어나야 하는 곳입니다. 코드베이스, 현실 세계, 그리고 그 실제 제약 조건들입니다.
지도와 영토 사이의 차이, 저는 이것을 미지수(unknowns)라고 부릅니다. Claude가 미지수를 만나면, 제가 무엇을 원하는지 최대한 추측해서 결정을 내려야 합니다. 수행하는 작업이 많아질수록, Claude가 마주칠 수 있는 미지수도 많아집니다.
Fable은 제가 써본 모델 중 처음으로, 미지수를 명확히 밝혀내는 나의 능력이 결과물 품질의 병목이 되는 모델입니다.
중요한 점은, 미리 계획하는 것만으로는 항상 충분하지 않다는 것입니다. 구현 깊숙한 곳에서 미지수를 발견할 수도 있고, 미지수가 문제를 아예 다른 방식으로 풀어야 한다는 사실을 알려줄 수도 있습니다.
저는 Fable과 함께 일하는 것이 구현 전, 구현 중, 구현 후에 걸쳐 나의 미지수를 발견해 나가는 반복적인 과정이라는 것을 깨달았습니다.
미지수를 찾기 위한 예시 아티팩트를 여기에 만들어 두었습니다. 다만 이것들을 언제 써야 하는지 직관을 기르려면, 꼭 이 글로 돌아와 주세요.
나의 미지수 알기
당신의 미지수는 무엇일까요? 저는 어떤 문제를 들고 Claude를 찾아갈 때, 그것을 네 가지로 나누어 생각하는 편입니다.2
- 아는 앎 (Known Knowns): 본질적으로 제 프롬프트에 들어 있는 내용입니다. 내가 원하는 것을 에이전트에게 무엇이라고 말하는가?
- 아는 모름 (Known Unknowns): 아직 파악하지 못했지만, 파악하지 못했다는 사실은 알고 있는 것은 무엇인가?
- 모르는 앎 (Unknown Knowns): 너무 당연해서 절대 글로 적지 않겠지만, 눈으로 보면 바로 알아볼 수 있는 것은 무엇인가?
- 모르는 모름 (Unknown Unknowns): 아예 고려조차 하지 못한 것은 무엇인가? 내가 존재조차 모르는 지식은 무엇인가? 어떤 것이 얼마나 좋아질 수 있는지 알고는 있는가?
최고의 에이전틱 코더들은 미지수가 상대적으로 적습니다. Boris3나 Jarred4 같은 사람이 프롬프트하는 것을 지켜보면, 자신이 원하는 것을 세부까지 알고 있다는 게 뚜렷하게 보입니다. 그들은 코드베이스와 모델의 행동 양쪽 모두와 깊이 동기화되어 있습니다.
하지만 그들 역시 미지수가 있다는 것을 전제하고 움직입니다. 여러모로, 미지수를 줄이고 미지수에 대비하는 것이야말로 에이전틱 코딩의 핵심 기술입니다. 다행히도 이것은 Claude와 함께 일하면서 향상시킬 수 있는 기술입니다.
Claude가 당신을 도울 수 있게 도우세요
Claude에게 지시하는 것은 섬세한 균형의 문제입니다. 너무 구체적으로 지시하면, 방향 전환이 더 적절한 상황에서도 Claude는 당신의 지시를 그대로 따릅니다. 너무 모호하게 지시하면, Claude는 업계 모범 사례에 기반해 선택과 가정을 하는 경우가 많은데, 그것이 당신의 작업에는 맞지 않을 수 있습니다.
미지수를 고려하지 않으면 양쪽 모두에서 실패합니다. 길이 언제 장애물로 가득할지 알 수 없고, 길이 훤히 뚫려 있는데도 Claude가 방향을 틀어주길 바라는 순간이 언제 올지도 알 수 없는 것이죠.
Claude는 당신이 미지수를 더 빨리 발견하도록 도와줄 수 있습니다. Claude는 코드베이스와 인터넷을 엄청나게 빠르게 검색할 수 있고, 웬만한 주제에 대해서는 당신보다 훨씬 많이 알고 있습니다. 실패했을 때 배우고 다시 시도하는 속도도 더 빠릅니다.
이 과정에서 가장 중요한 것은 당신의 출발점에 대한 컨텍스트를 Claude에게 주는 것입니다. 예를 들어, 지금 사고 과정의 어디쯤에 있는지 말해주고, 그 문제와 코드베이스에 대한 자신의 경험 수준을 솔직히 밝히고, 사고 파트너처럼 함께 일하게 하세요.
이전에 Claude와 HTML을 활용하는 법에 대해 쓴 적이 있는데, 아래 소개하는 거의 모든 경우에서 이런 내용을 시각화하고 표현하는 데는 HTML 아티팩트가 가장 좋은 방법입니다.
이 글에서는 이런 미지수들을 드러내기 위해 제가 사용하는 몇 가지 패턴을 소개합니다. 매번 모든 기법을 쓰는 것은 아니지만, 갖고 있으면 유용한 기법 모음입니다.
• • •
구현 전 (Pre-implementation)
블라인드스팟 패스 (Blind Spot Pass)
작업을 시작할 때 할 수 있는 가장 유용한 일 중 하나는 자신의 사각지대를 파악하는 것입니다. 예를 들어 코드베이스의 낯선 부분에 기능을 추가하거나, 디자인 반복 작업처럼 익숙하지 않은 일을 Claude와 함께 한다면, 모르는 모름이 아주 많을 가능성이 큽니다.
무엇을 물어봐야 하는지, 좋은 결과물이 어떤 모습인지, 과거에 어떤 작업이 있었는지, 어떤 함정을 피해야 하는지 모를 수 있습니다.
이럴 때는 Claude에게 나의 모르는 모름을 찾아서 설명해 달라고 부탁하면 됩니다. 저는 “blindspot pass(블라인드스팟 패스)“와 “unknown unknowns(모르는 모름)“라는 표현을 문자 그대로 쓰는 것을 좋아합니다. 당신이 누구이고 무엇을 알고 있는지에 대한 컨텍스트를 주는 것이 대개 중요합니다.
예시 프롬프트:
- “새 인증 프로바이더를 추가하려는데, 이 코드베이스의 인증 모듈에 대해 아는 게 하나도 없어. 블라인드스팟 패스를 해서 관련된 나의 모르는 모름을 파악하게 해주고, 내가 너에게 프롬프트를 더 잘할 수 있게 도와줘."
- "색 보정(color grading)5이 뭔지 모르는데 이 영상의 색 보정을 해야 해. 색 보정에 대한 나의 모르는 모름을 이해할 수 있게 가르쳐줘. 그래야 프롬프트를 더 잘할 수 있을 것 같아.”
브레인스토밍과 프로토타입
모르는 앎이 많은 영역에서 일할 때, 즉 눈으로 봐야만 정의할 수 있는 기준을 다루는 작업일 때, 저는 Claude에게 함께 브레인스토밍하고 프로토타입을 만들자고 합니다.
모르는 앎을 프로토타이핑 초기 단계에 짚어내고 말로 정리해 두는 것은 대단히 가치가 있습니다. 구현 도중에 발견하면 (상대적으로) 비용이 커지기 때문입니다. 기능이나 스펙의 작은 변화가 코드 구현을 극적으로 다르게 만들 수 있고, 에이전트가 이전 변경 사항을 되돌리는 것도 더 어려워질 수 있습니다.
예를 들어, 백엔드 라우트를 연결하거나 프론트엔드에 추가 상태를 유지하는 일 없이, 프레임에 버튼을 하나 추가하면 어떻게 보이는지만 확인하고 싶을 수 있습니다.
비주얼 디자인은 제게는 말로 설명하기 어렵지만, 보면 원하는 게 뭔지 아는 영역입니다. 이런 경우 저는 하나의 아티팩트에 대해 여러 가지 디자인 접근을 요청합니다.
또 저는 거의 모든 코딩 세션을 탐색이나 브레인스토밍 단계로 시작합니다. 이렇게 하면 의도를 갖고 프로젝트의 범위를 정의하며 시작할 수 있습니다. Claude는 제가 놓쳤을 법한 가치 큰 접근법을 자주 찾아내고, 때로는 나무에 매몰되어 숲을 놓치기도 합니다. 브레인스토밍은 범위를 너무 좁게도, 너무 넓게도 잡지 않도록 막아줍니다.
예시 프롬프트:
- “이 데이터를 보여줄 대시보드가 필요한데, 나는 시각적 감각이 없고 뭐가 가능한지도 몰라. 서로 완전히 다른 4가지 디자인 방향을 담은 HTML 페이지를 만들어줘. 보고 반응할게."
- "아무것도 연결하기 전에, 가짜 데이터로 새 에디터 툴바를 목업한 HTML 파일 하나를 만들어줘. 실제 앱을 건드리기 전에 레이아웃에 먼저 반응하고 싶어."
- "대략적인 문제는 이거야: 사용자들이 온보딩 후에 이탈해. 코드베이스를 검색해서 우리가 개입할 수 있는 지점 10곳을, 가장 저렴한 것부터 가장 야심찬 것 순서로 브레인스토밍해줘. 어떤 게 와닿는지 내가 말해줄게.”
인터뷰
브레인스토밍을 충분히 하고 나서도, 여전히 미지수가 남아 있을 가능성이 큽니다.
이럴 때 저는 Claude에게 미지수나 모호한 부분에 대해 저를 인터뷰해 달라고 합니다. Claude에게 인터뷰를 부탁할 때는, 질문의 방향을 잡을 수 있도록 문제에 대한 컨텍스트를 함께 주세요. 예시는 다음과 같습니다.
예시 프롬프트:
- “모호한 부분에 대해 한 번에 하나씩 질문하면서 나를 인터뷰해줘. 내 답에 따라 아키텍처가 바뀔 수 있는 질문을 우선해줘.”
레퍼런스
때로는 원하는 것을 자세히 설명할 수 없을 때가 있습니다. 표현할 언어가 없을 수도 있고, 너무 복잡해서 설명에 한참 걸릴 수도 있습니다.
이런 경우 최선의 답은 레퍼런스입니다. 다이어그램, 문서, 그림도 넣을 수 있지만, 단연 최고의 레퍼런스는 소스 코드입니다.
어떤 것을 특정한 방식으로 구현한 라이브러리가 있거나 정말 마음에 드는 디자인 컴포넌트가 있다면, 그냥 Fable에게 그 폴더를 가리키고 무엇을 봐야 하는지 알려주세요. 다른 프로그래밍 언어로 되어 있어도 상관없습니다.
Claude Design6도 이런 방식으로 작동합니다. 파일을 직접 건네줄 필요가 없습니다(물론 그렇게 해도 됩니다). 마음에 드는 웹사이트의 어떤 모듈을 가리키면, Claude는 스크린샷만 보는 게 아니라 그 밑에 깔린 코드를 읽습니다. 이렇게 하면 마크업, 구조, 그리고 그 컴포넌트가 실제로 어떻게 만들어졌는지에 대해 훨씬 풍부한 디테일을 얻을 수 있습니다.
예시 프롬프트:
- “vendor/rate-limiter에 있는 이 Rust 크레이트가 내가 원하는 백오프 동작을 정확히 구현하고 있어. 이걸 읽고 우리 TypeScript API 클라이언트에 같은 시맨틱을 다시 구현해줘.”
구현 계획
구현할 준비가 됐다고 생각되면, 저는 Claude에게 제가 검토할 구현 계획을 만들어 달라고 하는 편입니다. 이때 데이터 모델, 타입 인터페이스, UX 플로우처럼 바뀔 가능성이 가장 높은 부분을 검토하는 데 초점을 맞추게 합니다. 이렇게 하면 제가 실제로 수정해야 할지도 모르는 것들을 Claude가 미리 짚어줄 수 있습니다.
예시 프롬프트:
- “구현 계획을 HTML로 작성하되, 내가 손볼 가능성이 가장 높은 결정들부터 앞세워줘: 데이터 모델 변경, 새 타입 인터페이스, 그리고 사용자에게 보이는 모든 것. 기계적인 리팩토링은 맨 아래에 묻어둬. 그 부분은 너를 믿을게.”
구현 중 (During implementation)
구현 노트
계획에 만족하고 나면, 새 세션을 열고 아티팩트들을 프롬프트에 넘깁니다. 예를 들어 스펙 파일과 프로토타입을 전달하고 에이전트에게 구현을 부탁하는 식입니다.
하지만 아무리 계획을 세워도, 모르는 모름은 언제나 어딘가에 숨어 있기 마련입니다. 에이전트가 작업 중에 코드에서 발견한 엣지 케이스 때문에 다른 방향을 택해야 할 수도 있습니다.
저는 Claude Code에게 임시 ‘implementation-notes.md’(또는 .html) 파일을 유지하면서 자신이 내리는 결정들을 기록해 두게 합니다. 다음 시도에서 배울 수 있도록 말이죠.
예시 프롬프트:
- “
implementation-notes.md파일을 유지해줘. 계획에서 벗어날 수밖에 없는 엣지 케이스를 만나면, 보수적인 선택지를 고르고, ‘Deviations’ 항목 아래에 기록하고, 계속 진행해.”
구현 후 (Post implementation)
피치와 설명 문서
무언가를 출시하는 데 가장 중요한 부분 중 하나는 동의와 승인을 얻는 것입니다. 최종 문서에 피치와 설명 아티팩트를 함께 만들어 두면 다음과 같은 도움이 됩니다.
- 리뷰어가 당신과 같은 미지수에서 출발할 때, 이해가 빨라집니다.
- 전문가들은 자신이라면 예상했을 미지수와 흔한 실패 지점이 있기 마련인데, 당신이 그것들을 이미 고려했다는 걸 보여주면 승인이 빨라집니다.
예시 프롬프트:
- “프로토타입, 스펙, 구현 노트를 하나의 문서로 묶어줘. Slack에 올려서 팀 동의를 받을 수 있게. 데모 GIF를 맨 앞에 배치해줘.”
퀴즈
긴 작업 세션이 끝나면, Claude는 제가 인지한 것보다 훨씬 많은 일을 해냈을 수 있습니다. 동작의 상당 부분이 기존 코드 경로에 의존하기 때문에, 코드 diff를 읽는 것만으로는 무슨 일이 일어났는지 겉핥기로밖에 이해할 수 없습니다.
Claude에게 먼저 충분한 컨텍스트를 설명하게 한 다음 변경 사항에 대해 저를 퀴즈로 시험해 달라고 하면, 무슨 일이 일어나는지 이해하는 데 도움이 됩니다. 저는 퀴즈를 만점으로 통과한 후에만 머지합니다.
예시 프롬프트:
- “이 변경에서 일어난 모든 일을 내가 이해하고 있는지 확인하고 싶어. 컨텍스트, 직관, 무엇이 이루어졌는지 등을 담아 내가 읽고 이해할 수 있는 HTML 리포트를 만들어주고, 맨 아래에 내가 반드시 통과해야 하는 변경 사항 퀴즈를 넣어줘.”
• • •
이 모든 것이 어떻게 어우러지는가: Fable 출시하기
Fable 출시 영상은 전부 Claude Code로 편집되었습니다. 제게는 완전히 새로운 도메인이었고, 저는 결코 전문가가 아닙니다.
그래서 제가 아는 것에서 출발했습니다. Claude가 코드로 영상을 편집하고 전사(transcribe)할 수 있다는 건 알았지만, 충분히 정확한지는 확신이 없었습니다. 그래서 Claude에게 Whisper7 같은 전사 기술이 어떻게 작동하는지, 그리고 ffmpeg으로 “음…” 같은 군말이나 긴 침묵을 정확하게 잘라낼 수 있을지 설명해 달라고 했습니다.
제가 말하는 단어에 맞춰 타이밍이 동기화되는 UI를 Claude가 만들어주길 원했지만, 가능할지 확신이 없었습니다. 그래서 Claude에게 Remotion8과 전사 결과를 사용해 프로토타입 영상을 만들어 실제로 되는지 확인해 보게 했습니다.
마지막으로, 영상 자체가 조금 물 빠진 느낌이었는데, 그것이 색 보정의 결과라는 건 알았지만 색 보정이 정확히 뭔지는 몰랐습니다. 처음에는 Claude에게 몇 가지 변형을 만들게 해서 그중에서 고르려 했지만, 색 보정에 관해서는 제가 “좋은 것”이 어떤 모습인지 모른다는 걸 깨달았습니다. 그래서 대신, Claude에게 색 보정을 가르쳐 달라고 해서 저의 미지수를 발견했습니다.
이에 대한 더 자세한 설명은 여기서 영상으로 볼 수 있습니다.
• • •
지도와 영토를 일치시키기
모델이 좋아질수록, 올바른 접근법으로 이룰 수 있는 것도 많아집니다. 장기 호흡의 작업이 잘못된 결과로 돌아온다면, 미지수를 정의하는 데 더 많은 시간을 쓰거나, Claude가 미지수를 만나도 임기응변으로 헤쳐나갈 수 있는 구현 계획을 만들어야 한다는 신호일 가능성이 큽니다.
모든 설명 문서, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 고치기 비싸지기 전에, 몰랐던 것을 싸게 알아내는 방법입니다.
그러니 다음 프로젝트는 Claude에게 나의 미지수를 찾도록 도와달라고 부탁하는 것으로 시작해 보세요.
역자 주
- 지도는 영토가 아니다(The map is not the territory): 폴란드 출신 학자 알프레드 코지브스키(Alfred Korzybski)가 1931년에 남긴 유명한 경구로, 어떤 것에 대한 표현(지도)은 결코 그 대상 자체(영토)가 될 수 없다는 뜻입니다. 영어권에서는 “모델과 현실을 혼동하지 말라”는 의미의 관용구로 널리 쓰입니다. ↩
- 4분면 분류의 유래: “아는 앎/아는 모름/모르는 모름” 구분은 2002년 미국 국방장관 도널드 럼즈펠드(Donald Rumsfeld)의 기자회견 발언(“known knowns, known unknowns, unknown unknowns”)으로 유명해졌습니다. 여기에 네 번째 칸인 “모르는 앎(unknown knowns)”, 즉 알고 있으면서도 안다는 사실을 인지하지 못하는 것을 더해 4분면으로 확장한 것입니다. ↩
- Boris Cherny: Anthropic의 엔지니어로, 에이전틱 코딩 도구 Claude Code를 처음 만든 인물입니다. ↩
- Jarred Sumner: 고성능 JavaScript 런타임·번들러 Bun의 창시자이자 Oven 창업자입니다. ↩
- 색 보정(color grading): 영상 후반 작업에서 색감·명암·톤을 다듬어 화면의 분위기와 일관성을 만드는 공정입니다. 영화·광고 업계에서는 전문 컬러리스트가 따로 있을 만큼 독립된 전문 영역입니다. ↩
- Claude Design: Anthropic의 디자인 특화 기능으로, 참고하고 싶은 웹사이트나 컴포넌트를 가리키면 스크린샷이 아니라 그 밑의 실제 코드(마크업·스타일)를 읽고 디자인을 재현·응용합니다. ↩
- Whisper: OpenAI가 2022년 공개한 오픈소스 음성 인식(전사) 모델로, 영상·음성에서 텍스트와 단어별 타임스탬프를 뽑아내는 데 널리 쓰입니다. ↩
- Remotion: React 코드로 영상을 만들 수 있게 해주는 프레임워크입니다. 프로그래머가 코드로 애니메이션·자막·장면 전환을 제어할 수 있어, 에이전트가 영상을 “코딩”하는 워크플로우에 자주 쓰입니다. ↩
저자 소개: Thariq Shihipar (@trq212)는 Anthropic에서 Claude 관련 제품을 만들고 있으며, Claude와 HTML 아티팩트를 활용한 워크플로우에 대한 글을 씁니다.
참고: 이 글은 Thariq Shihipar가 X(트위터)에 게시한 아티클을 번역한 것입니다. 원문의 일부 문장(“Giving it context on who you are and what you know is usually important for”)은 중간에 끊긴 채 게시되어 있어, 문맥에 맞게 자연스럽게 옮겼습니다.
원문: Finding Your Unknowns - Thariq Shihipar, X (2026-07-04)
생성: Claude (Anthropic)