나의 미지수 찾기

게시일: 2026년 7월 6일 | 원문 작성일: 2026년 7월 4일 | 저자: Thariq Shihipar (@trq212) | 원문 보기

• • •

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(모르는 모름)“라는 표현을 그대로 즐겨 씁니다. 자신이 누구이고 무엇을 아는지 컨텍스트로 알려 주는 것도 대개 중요합니다.

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

모르는 앎이 많은 영역에서 일할 때, 즉 눈으로 봐야만 정의할 수 있는 기준을 다루는 작업일 때, 저는 Claude에게 함께 브레인스토밍하고 프로토타입을 만들자고 합니다.

모르는 앎은 프로토타이핑 초기에 짚어 내어 말로 정리해 두면 얻는 것이 아주 많습니다. 구현 도중에 발견하면 (상대적으로) 비용이 커질 수 있기 때문입니다. 기능이나 스펙을 조금만 바꿔도 코드 구현이 판이하게 달라질 수 있고, 에이전트가 이전 변경 사항을 되돌리는 것도 더 어려워질 수 있습니다.

예를 들어, 백엔드 라우트를 연결하거나 프론트엔드에서 상태를 추가로 관리할 필요 없이, 프레임에 버튼을 하나 추가하면 어떻게 보이는지만 확인하고 싶을 수 있습니다.

비주얼 디자인은 제게는 말로 설명하기 어렵지만, 보면 원하는 게 뭔지 아는 영역입니다. 이런 경우 저는 아티팩트 하나를 두고 디자인 방향을 여러 가지 요청합니다.

또 저는 거의 모든 코딩 세션을 탐색이나 브레인스토밍 단계로 시작합니다. 이렇게 하면 프로젝트 범위를 정하겠다는 분명한 의도를 품고 출발할 수 있습니다. Claude는 제가 놓쳤을 법한, 가치가 큰 접근법을 자주 찾아내고, 때로는 나무에 매몰되어 숲을 놓치기도 합니다. 브레인스토밍을 거치면 범위를 너무 좁게도, 너무 넓게도 잡지 않게 됩니다.

인터뷰

브레인스토밍을 충분히 하고 나서도 미지수는 아마 남아 있을 겁니다.

이럴 때 저는 Claude에게 미지수나 모호한 부분을 두고 저를 인터뷰해 달라고 합니다. Claude에게 인터뷰를 부탁할 때는, 질문의 방향을 잡을 수 있도록 지금 풀려는 문제의 컨텍스트를 함께 주세요. 예시는 다음과 같습니다.

레퍼런스

원하는 것을 자세히 설명할 수 없을 때가 있습니다. 표현할 말을 모를 수도 있고, 너무 복잡해서 설명에 한참 걸릴 수도 있습니다.

이런 경우 최선의 답은 레퍼런스입니다. 다이어그램, 문서, 그림도 넣을 수 있지만, 단연 최고의 레퍼런스는 소스 코드입니다.

어떤 것을 특정한 방식으로 구현한 라이브러리가 있거나 정말 마음에 드는 디자인 컴포넌트가 있다면, 그냥 Fable에게 그 폴더를 짚어 주고 무엇을 찾아봐야 하는지 말해 주세요. 다른 프로그래밍 언어로 되어 있어도 상관없습니다.

Claude Design6도 이런 방식으로 작동합니다. 파일을 직접 건네줄 필요가 없습니다(물론 그렇게 해도 됩니다). 마음에 드는 웹사이트의 어떤 모듈을 가리키면, Claude Design은 스크린샷만 보는 게 아니라 그 밑에 깔린 코드를 읽습니다. 덕분에 마크업과 구조는 물론, 그 컴포넌트가 실제로 어떻게 만들어졌는지까지 훨씬 자세히 파악할 수 있습니다.

구현 계획

구현할 준비가 됐다고 생각되면, 저는 Claude에게 제가 검토할 구현 계획을 만들어 달라고 하는 편입니다. 이때 데이터 모델, 타입 인터페이스, UX 플로우처럼 바뀔 가능성이 가장 높은 부분을 검토하는 데 초점을 맞추게 합니다. 이렇게 하면 제가 실제로 수정해야 할지도 모르는 것들을 Claude가 미리 짚어줄 수 있습니다.

구현 중 (During implementation)

구현 노트

계획에 만족하고 나면, 새 세션을 열고 아티팩트들을 프롬프트에 넘깁니다. 예를 들어 스펙 파일과 프로토타입을 전달하고 에이전트에게 구현을 부탁하는 식입니다.

하지만 아무리 계획을 세워도, 모르는 모름은 언제나 어딘가에 숨어 있기 마련입니다. 에이전트가 작업 중에 코드에서 발견한 엣지 케이스 때문에 다른 방향을 택해야 할 수도 있습니다.

저는 Claude Code에게 임시 ‘implementation-notes.md’(또는 .html) 파일을 하나 만들게 하고, 작업하면서 내리는 결정을 거기에 계속 적어 두게 합니다. 그래야 다음 시도 때 우리가 그 기록을 보고 배울 수 있습니다.

구현 후 (Post implementation)

피치와 설명 문서

원문 보기

무언가를 출시할 때 손에 꼽을 만큼 중요한 일이 동의와 승인을 얻는 것입니다. 최종 문서에 피치와 설명 아티팩트를 함께 만들어 두면 다음과 같은 도움이 됩니다.

• 리뷰어가 작업자와 같은 미지수에서 출발할 때, 이해가 빨라집니다.
• 전문가들이 자신이라면 예상했을 미지수와 흔한 실패 지점을 작업자가 고려했는지 확인하고 싶어 할 때, 승인이 빨라집니다.

퀴즈

긴 작업 세션이 끝나면, Claude는 제가 인지한 것보다 훨씬 많은 일을 해냈을 수 있습니다. 동작의 상당 부분이 기존 코드 경로에 의존하기 때문에, 코드 diff를 읽는 것만으로는 무슨 일이 일어났는지 겉핥기로밖에 이해할 수 없습니다.

Claude에게 먼저 컨텍스트를 넉넉히 알려 달라고 한 뒤 변경 사항에 관한 퀴즈를 내 달라고 하면, 무슨 일이 일어나는지 제가 이해하기 쉬워집니다. 저는 퀴즈를 만점으로 통과한 후에만 머지합니다.

• • •

이 모든 것이 어떻게 어우러지는가: Fable 출시하기

Fable 출시 영상은 처음부터 끝까지 Claude Code가 편집했습니다. 제게는 처음 다뤄 보는 분야였고, 전문가와는 한참 거리가 멉니다.

그래서 제가 아는 것에서 출발했습니다. Claude가 코드로 영상을 편집하고 전사(transcribe)할 수 있다는 건 알았지만, 충분히 정확한지는 확신이 없었습니다. 그다음 Claude에게 Whisper7 같은 전사 기술이 어떻게 작동하는지, 그리고 ffmpeg으로 “음…” 같은 군말이나 긴 침묵을 정확하게 잘라낼 수 있을지 설명해 달라고 했습니다.

제가 말하는 단어와 타이밍을 맞춰 움직이는 UI를 Claude가 만들어주길 원했지만, 그게 가능할지는 확신이 없었습니다. 실제로 되는지 보려고 Claude에게 Remotion8과 전사 결과로 프로토타입 영상을 만들게 했습니다.

마지막으로, 영상 자체가 조금 물 빠진 느낌이었습니다. 색 보정 때문이라는 건 알았지만, 정작 색 보정이 뭔지는 잘 몰랐습니다. 처음에는 Claude에게 몇 가지 변형을 만들게 해서 그중에서 고르려 했지만, 색 보정에 관해서는 제가 “좋은 것”이 어떤 모습인지 모른다는 걸 깨달았습니다. 그래서 고르는 대신, 제 미지수를 찾으려고 Claude에게 색 보정을 가르쳐 달라고 했습니다.

이 과정을 더 자세히 설명한 영상은 여기서 볼 수 있습니다.

• • •

지도와 영토를 일치시키기

모델이 좋아질수록, 올바른 접근법으로 이룰 수 있는 것도 많아집니다. 호흡이 긴 작업을 맡겼는데 결과가 빗나갔다면, 아마 미지수를 정의하는 데 시간을 더 쓰거나, Claude가 미지수를 만나도 임기응변으로 헤쳐 나갈 여지를 주는 구현 계획을 세워야 할 것입니다.

설명 문서, 브레인스토밍, 인터뷰, 프로토타입, 레퍼런스는 하나같이 고치는 비용이 커지기 전에, 몰랐던 것을 싸게 알아내는 방법입니다.

그러니 다음 프로젝트는 Claude에게 미지수를 찾도록 도와 달라고 부탁하는 것으로 시작해 보세요.