모델이 좋아질수록 결과물의 병목은 AI가 아니라 사람 쪽으로 옮겨 갑니다. Anthropic에서 Claude Code를 만드는 엔지니어가 AI Engineer World's Fair 무대에서 Claude Fable을 다루는 현장 지침을 풀었습니다. 핵심은 프롬프트를 늘리는 게 아니라, 내가 뭘 모르는지부터 싸게 찾아내는 것입니다.
무대에 오르자마자 청중과 셀카부터 찍습니다. Claude Code 팀의 발표 전 전통이라고 하네요. 발표자는 Thariq Shihipar, Anthropic에서 Claude Code를 만드는 테크니컬 스태프입니다. Claude가 거꾸로 사용자에게 객관식 선택지를 띄우고 질문하는 기능을 만든 사람이고, Anthropic에 오기 전에는 30명 규모의 YC 스타트업을 운영했습니다. 이 19분짜리 키노트는 그가 연재하려던 글 몇 편을 한 번에 몰아 발표한 것으로, 새 모델 Claude Fable을 어떻게 다뤄야 하는지에 대한 현장 지침입니다.
포켓몬 문제가 드러낸 능력 과잉
Anthropic 안에서 자주 하는 말이 있습니다. 모델은 설계되는 게 아니라 길러진다는 것이죠. 데이터와 피드백과 연산을 주면서 유기적으로 키우기 때문에, 만든 사람조차 모델이 무엇을 할 수 있는지 다 알지 못한 채로 세상에 내놓게 됩니다. 그래서 모델을 가두는 건 모델 자신이 아니라 우리가 씌운 하네스와 프롬프트라고 Thariq는 말합니다.
몇 주 전 화제가 된 트윗이 예시로 나옵니다. 이름이 aw로 끝나는 포켓몬을 왜 LLM은 못 찾을까요. 포켓몬은 천 마리가 넘고 정답은 Croconaw와 Drednaw 두 마리뿐인데, 일반 채팅 모델에 물으면 틀립니다. 모델이 포켓몬 이름을 다 알고 있는데도 그렇죠. 그런데 Claude Code에 물으면 맞힙니다. 포켓몬 전부를 받아 온 뒤 aw로 끝나는 것만 거르는 스크립트를 짜 버리거든요. 이걸 능력 과잉(capability overhang)이라 부릅니다. 능력은 이미 모델 안에 있는데 꺼내는 법을 몰라서 못 쓰는 상태입니다.
시스템 프롬프트 80%를 지운 이유
같은 원리를 Anthropic은 자기 제품에도 적용했습니다. 최근 Claude Code의 시스템 프롬프트 80%를 지웠습니다. 설계 방식이 세 번 뒤집힌 셈이죠. 처음(Sonnet 3.5 new 무렵)에는 짧은 프롬프트에 도구 몇 개, 예시는 잔뜩. 모델이 똑똑해지자 긴 프롬프트에 예시도 도구도 많이. 그런데 지금 세대는 다시 짧은 프롬프트를 원합니다. 예시가 오히려 모델의 상상력을 예시 수준으로 묶어 버리기 때문입니다. 그래서 방향을 바꿨습니다 — 제약 대신 맥락을 준다. "이건 하지 마"를 최대한 걷어내는 겁니다.
Thariq가 만든 질문 도구 하나에도 세대 차이가 그대로 보입니다. Opus 4는 그 도구를 제대로 호출하지도 못해 계속 손을 봐야 했고, Opus 4.5부터는 "스펙에 대해 질문 40개만 해 줘"라고 하면 인터뷰가 됐습니다. 지금 Opus 4.8과 Fable은 질문을 통째로 심은 HTML 보고서를 만들어 옵니다. 같은 도구인데 모델이 바뀔 때마다 일하는 방식 자체가 달라진 거죠. 그는 이런 발전을 물리학보다 생물학에 가깝다고 표현합니다. 규칙을 다 알지 못한 채 경험으로 감을 쌓아 간다는 뜻입니다.
지도는 영토가 아니다
Claude를 풀어 줬으면 다음은 나를 풀어 줄 차례입니다. 여기서 발표의 핵심 프레임이 나옵니다. 지도는 내가 AI에게 주는 것 전부입니다. 프롬프트, 스펙, 계획. 영토는 일이 실제로 벌어지는 곳이죠. 진짜 코드베이스, 진짜 제약 조건. 아무리 정성껏 그려도 지도가 영토와 같아질 수는 없습니다.
Claude가 지도에 없는 지형을 만나는 순간, Thariq는 그걸 언노운(unknown)이라 부릅니다. 그 지점에서 Claude는 멈춰 묻는 대신 내가 뭘 원할지 추측해 결정합니다. 내가 지정한 적 없는 결정 지점이 생기는 거죠. Fable은 그가 "내 언노운을 정말로 찾아내야겠다"고 처음 느낀 모델이라고 합니다. 모델이 돌아다니는 영토가 그만큼 넓어져서, 추측 지점도 그만큼 늘어나거든요.
그는 이걸 네 칸 매트릭스로 정리합니다. 내가 아는 것(보통 프롬프트에 쓰는 내용), 모른다는 걸 아는 것, 너무 당연해서 적지 않았지만 보면 아는 것, 그리고 아예 고려조차 안 해 본 것. 마지막 칸이 제일 비쌉니다. 프로젝트가 끝나갈 무렵 발견되면 갈아엎어야 하는 것들이 거기서 나오니까요.
언노운을 싸게 찾는 여섯 가지
다행히 언노운을 찾는 데도 Fable을 쓸 수 있습니다. 발표에서 그가 실제로 쓰는 기법 여섯 개가 프롬프트 문장까지 그대로 공개됐습니다. 시작 전에 네 개, 작업 중에 하나, 끝난 뒤에 하나입니다.
- 사각지대 점검낯선 영역은 일부터 시키지 말고 내가 모르는지도 모르는 것부터 묻는다
- 브레인스토밍·프로토타입말로 못 하는 건 완전히 다른 방향 네 가지를 만들게 해 눈으로 고른다
- 인터뷰거꾸로 AI가 나를 묻게 한다. 설계가 바뀌는 질문부터 하라고 지정한다
- 레퍼런스원하는 동작의 코드를 던진다. 언어가 달라도 된다
- 구현 노트계획에서 벗어난 지점을 기록하게 한다. 나중에 왜 그랬는지 볼 수 있다
- 퀴즈끝나면 보고서와 퀴즈를 요구해 내가 이해했는지 확인한다
사각지대 점검은 이런 문장입니다. "이 코드베이스의 인증 모듈을 하나도 모릅니다. 사각지대 점검을 해서 내가 모르는지도 모르는 것들을 알려주고, 프롬프트를 더 잘 쓰게 도와주세요." 코딩에만 쓰는 게 아니라 영상 편집의 색보정을 배울 때도 같은 방식을 썼다고 합니다. 레퍼런스도 재밌습니다. Claude에게 지도를 주는 가장 좋은 방법은 이미 그려진 다른 지도를 주는 것이라, 스펙을 글로 쓰는 대신 "이 폴더의 Rust 라이브러리가 내가 원하는 동작 그대로입니다. 읽고 같은 의미로 TypeScript에 다시 구현하세요"라고 던집니다.
마지막 퀴즈는 취지가 좀 다릅니다. PR을 올리거나 머지하기 전에 이 변경을 내가 설명할 수 있는지 확인하는 장치죠. Fable을 쓸 때 가장 중요한 건 루프 안에 계속 남아 있는 것이라고 그는 강조합니다.
애도, 그리고 비합리적으로 굴기
발표 후반부에서 방향이 꺾입니다. Fable을 처음 썼을 때 그는 큰 이득감과 함께 상실감을 느꼈다고 합니다. 몇 주 전 옛 스타트업 코드베이스를 다시 열었더니, 몇 주 걸리던 일이 몇 시간 만에 끝났습니다. 30명이던 그 시절엔 코드가 너무 어려워서 앱을 빠르게 만들거나 새 기능을 프로토타이핑하거나 둘 중 하나만 골라야 했는데 말이죠. "웃지 않을 수가 없지만, 울지 않을 수도 없다"는 게 그의 표현입니다. 손으로 코드를 쓰고 코드베이스를 머릿속에서 돌려 보던 감각을 그는 정말 좋아했다고 하네요. 그러면서도 밤새 디버깅하고 몇 주씩 안 되는 걸 붙들던 실패의 기억을 함께 꺼내며, 그래도 돌아갈 수는 없다고 인정합니다. 얻은 것뿐 아니라 잃은 것까지 말하는 발표는 흔치 않습니다.
그래서 나온 결론이 마지막 파트, '비합리적으로 굴기'입니다. Anthropic에서 배운 것 중 그가 가장 좋아하는 믿음이 트레이드오프는 실재하지 않는다는 것이라고 합니다. 예전 회사에서는 우선순위 목록을 쓰고 이번 분기엔 이것만, 하는 식으로 합리적으로 굴었죠. 그런데 전부 다 해 버리면 어떨까요. 트레이드오프를 현실이 직접 보여 주게 만들면요. 좋고 빠르고 싸게 중에 둘만 고르라던 명제도 이제는 셋 다 고르는 것이라고 그는 말합니다.
증거는 발표 자체입니다. 이 19분짜리 키노트 덱을 전날 밤 Fable과 함께 약 4시간 만에 만들었다고 합니다. 다만 하나는 분명히 합니다. 만드는 건 쉬워졌지만 가치를 만드는 건 여전히 어렵다는 것. 도구 세팅에 빠져 있지 말고 그 빨라진 손으로 인생에서 가장 좋은 작업을 하라는 게 그의 마무리입니다. 병목이 나라는 말은 기분 나쁘라고 한 말이 아닙니다. 결정권이 나에게 넘어왔다는 뜻이죠. 모델이 좋아질수록 값이 오르는 건 도구가 아니라 자기가 뭘 원하는지 아는 사람입니다. 🧭
