Anthropic 개발자 Thariq Shihipar가 Fable 5를 두고 제안한 프롬프트 팁은 흔한 생산성 조언과 결이 다르다. 요지는 “더 자세히 써라”가 아니다. 모델이 강해질수록 결과를 제한하는 쪽은 모델 자체보다 사용자가 미처 인식하지 못한 blind spot일 수 있다는 주장이다.
그는 사용자의 지식을 네 가지로 나눈다. 프롬프트에 이미 적은 Known Knowns, 아직 답하지 못했다는 걸 알고 있는 Known Unknowns, 너무 당연해서 굳이 쓰지 않는 Unknown Knowns, 그리고 아예 고려하지 못한 Unknown Unknowns다. Fable 5 같은 모델을 쓸 때 특히 문제가 되는 건 마지막 범주다. 사용자가 문제의 지형을 덜 파악한 상태에서 구현을 맡기면, 모델은 그 빈틈까지 포함해 그럴듯한 결과를 만들어낸다.
Shihipar의 처방은 구현 전 탐색을 독립된 단계로 두는 것이다. 예를 들어 낯선 코드베이스에서 새 인증 제공자를 추가한다면, 곧바로 코딩을 시키지 않고 Claude에게 blindspot pass를 요청한다. 내가 인증 모듈에 대해 모르는 것, 설계상 놓치기 쉬운 부분, 더 나은 프롬프트를 위해 먼저 답해야 할 질문을 뽑게 하는 방식이다. 디자인처럼 암묵지가 많은 영역에서는 여러 HTML 프로토타입을 먼저 만들게 하고, 사용자가 반응하면서 자기 기준을 발견하게 한다.
여기에는 중요한 균형이 있다. 지시가 너무 자세하면 Fable 5는 잘못된 접근까지 충실히 따라갈 수 있다. 반대로 너무 모호하면 업계 기본값에 가까운 무난한 결정을 내리기 쉽다. 좋은 프롬프트는 길고 촘촘한 명령문이라기보다, 사용자의 출발점과 불확실성을 모델이 함께 파악하도록 만드는 인터뷰에 가깝다.
구현 중에도 blind spot은 계속 나온다. Shihipar는 Claude Code가 temporary implementation-notes.md를 유지하며 어떤 결정을 했는지, 예상 밖 edge case에서 왜 보수적 선택을 했는지 기록하게 한다. 작업 후에는 변경 내용을 설명하는 HTML 리포트와 퀴즈를 만들고, 사용자가 그 퀴즈를 통과하기 전에는 merge하지 않는 방식도 소개한다. AI가 만든 결과를 이해하지 못한 채 받아들이는 흐름을 끊기 위한 장치다.
이 접근의 의미는 플러그인이나 도구 목록보다 실행 흐름에 있다. 더 강한 모델을 쓰는 것만으로는 장기 작업의 실패를 막기 어렵다. 먼저 모르는 것을 드러내고, 아키텍처를 바꿀 질문을 앞당기고, 구현 중 판단을 기록하고, 마지막에 사람이 이해했는지 확인하는 루프가 필요하다. Fable 5의 메시지는 그래서 꽤 현실적이다. 모델에게 맡기기 전에, 내가 무엇을 모르는지부터 모델과 함께 찾아야 한다.