AI 코딩 에이전트를 쓰다 보면 프롬프트도 정확히 썼고 계획도 그럴듯한데 결과물이 묘하게 어긋나는 경험, 다들 한 번쯤 있을 겁니다. 앤트로픽 개발자 타리크 시히파르는 최신 모델 Fable 5에서는 그 원인이 점점 모델이 아니라 사용자 자신에게 있다고 말합니다.

시히파르는 Fable 5가 출력 품질이 모델의 한계가 아니라 사용자가 자신의 “모르는 것”을 얼마나 명확히 하는지에 달린 첫 모델이라고 설명합니다. 그는 이를 네 가지 범주로 나누고, 그중 가장 위험한 “모르는지도 몰랐던 것”을 미리 찾아내는 자신만의 기법들을 공유했습니다.

출처: Know your unknowns — examples – Thariq Shihipar

네 가지 모름의 종류

시히파르는 모름을 네 가지로 나눕니다. 프롬프트에 이미 적어놓은 “아는 것(known known)”, 아직 답을 못 찾았다는 걸 스스로 아는 “아는 모름(known unknown)”, 너무 당연해서 굳이 적지는 않지만 보면 바로 알아채는 “모르는 앎(unknown known)”, 그리고 아예 생각조차 못 해본 “모르는 모름(unknown unknown)”입니다. 그는 이 마지막 범주가 가장 위험하다고 말합니다.

프롬프트를 너무 구체적으로 쓰면 Fable 5가 상황이 바뀌어도 그 지시만 고집스럽게 따르고, 너무 두루뭉술하게 쓰면 업계 기본값으로 대충 판단해버립니다. “자신의 모름을 제대로 관리하지 않으면 양쪽 다 실패한다”는 게 그의 표현입니다.

구현 전에 사각지대부터 찾는다

시히파르는 실제 구현에 들어가기 전 단계에서 몇 가지 기법을 씁니다. 그가 “블라인드스팟 패스”라고 부르는 과정에서는 Claude에게 자신이 모르고 있는 것 자체를 찾아달라고 요청합니다. 코드베이스에서 낯선 영역을 다룰 때 특히 효과적이라고 합니다. 그가 예로 든 프롬프트는 이런 식입니다. “새 인증 제공자를 추가하는 작업을 하고 있는데 이 코드베이스의 인증 모듈에 대해서는 아는 게 없어. 내가 모르고 있는 것들을 파악해서 더 나은 프롬프트를 만들 수 있게 블라인드스팟 패스를 해줄래?”

디자인처럼 “보면 안다”는 식의 “모르는 앎”이 많은 영역에는 브레인스토밍과 프로토타입을 추천합니다. 곧바로 구현에 들어가는 대신, 서로 확연히 다른 여러 디자인 방향을 HTML 아티팩트로 만들게 해서 반응해보는 식입니다. 그는 거의 모든 코딩 세션을 프로젝트 범위를 의식적으로 정의하는 탐색·브레인스토밍 단계로 시작한다고 말합니다.

이 밖에도 Claude가 모호한 부분을 하나씩 질문하는 구조화 인터뷰(답이 아키텍처를 크게 바꿀 질문부터 우선 처리), 그리고 스크린샷이 아니라 원본 코드 같은 레퍼런스를 활용하는 방법도 소개합니다.

구현 중과 이후, 기록하고 이해하기

구현 중에도 모름은 계속 튀어나옵니다. 시히파르는 Claude Code에게 임시로 “implementation-notes.md” 파일을 만들어 내린 결정들을 기록하게 하고, 예상 밖의 상황이 나오면 보수적인 선택을 한 뒤 그 편차를 로그로 남기고 계속 진행하게 합니다.

구현이 끝난 뒤에는 두 가지를 씁니다. 하나는 프로토타입과 스펙, 구현 노트를 한데 묶은 요약 문서인 “피치 앤 익스플레이너”이고, 다른 하나는 변경 내용을 담은 리포트 뒤에 퀴즈를 붙여, 오류 없이 통과해야만 머지한다는 “퀴즈” 기법입니다.

영상 편집을 전혀 몰랐던 개발자의 실험

시히파르는 이 기법들이 어떻게 맞물리는지 Fable 출시 영상 사례로 보여줍니다. 그는 이 영상 전체를 Claude Code로 편집했는데, 영상 편집은 그에게 완전히 낯선 분야였습니다.

그는 자신이 아는 것부터 시작했습니다. Claude가 코드로 영상을 편집하고 자막을 딸 수 있다는 것이었죠. 정확도가 충분할지 확신이 서지 않아서, 위스퍼(Whisper)로 음성을 텍스트로 바꾸는 방식과 ffmpeg로 필러 단어나 정적 구간을 정밀하게 잘라낼 수 있는지를 다른 사람에게 설명 듣기도 했습니다. UI 요소가 시간에 맞춰 서서히 나타나는 효과를 위해서는 리모션(Remotion)으로 프로토타입을 만들었습니다.

결과물의 색감이 밋밋해 보였을 때, 처음엔 Claude에게 여러 색보정 버전을 만들게 했습니다. 하지만 그는 곧 자신이 “좋은 색보정”이 어떤 모습인지조차 모른다는 걸 깨달았습니다. 여러 버전 중 하나를 무작정 고르는 대신, Claude에게 색보정 자체를 배우면서 자신의 모름을 드러내는 쪽을 택했습니다.

시히파르는 모델이 강력해질수록 올바른 접근으로 이뤄낼 수 있는 것도 더 많아진다고 말합니다. 그의 표현을 빌리면, 설명이든 브레인스토밍이든 인터뷰든 프로토타입이든 레퍼런스든, 이런 값싼 확인 작업 하나하나가 문제가 커지기 전에 미리 알아채는 방법이라는 것입니다.

참고자료: Anthropic developer shares prompting tips for Fable 5 that focus on finding your own blind spots first – THE DECODER