현재 기존 유료 구독자라면, 주간 사용량 제한의 최대 50%까지 페이블 5를 이용할 수 있는데요. 원래는 7월 7일에 이 구독제 이용도 끝날 예정이었지만, 앤트로픽이 기간을 5일 더 연장했습니다. 변경된 만료일은 7월 12일. 오늘이 7월 10일이니, 이제 딱 이틀 남았습니다.

저도 어떻게든 알차게 써보려고 사내에서 이것저것 돌려보는 중인데요. 마침 앤트로픽 클로드 코드(Claude Code) 팀의 타리크 시히파(Thariq Shihipar)가 AI Engineer World Fair에서 발표한 "Field Guide to Fable" 키노트에 좋은 내용이 있어 공유합니다. 개발에 직접 참여한 엔지니어의 활용법이라, 남은 이틀 동안 실무에서 바로 써먹을 수 있도록 핵심 가이드 형태로 정리해봤습니다.

모델이 아니라 우리가 발목을 잡고 있다

타리크의 발표는 네 부분(unhobbling Claude · finding your unknowns · dealing with the grief · being unreasonable)인데 첫 부분 제목이 좀 셉니다. unhobbling, 우리말로 하면 ‘발목에 채운 족쇄를 푼다’는 뜻인데요. 그가 말하는 요지는 이렇습니다. 모델은 설계된(designed) 게 아니라 길러진(grown) 것이고, 그걸 가두는 건 결국 우리라는 거죠. 우리가 씌운 하네스와 프롬프트가 클로드를 이해한 만큼만 성능을 열어준다는 얘기예요.

예시가 재밌습니다. 포켓몬 이야기인데요. "이름이 aw로 끝나는 포켓몬은?"이라고 물으면 일반적인 챗 모델은 못 맞힙니다. 천 마리 중에 Croconaw랑 Drednaw 딱 둘인데 말이죠. 그런데 클로드 코드한테 시키면 맞힙니다. 포켓몬 목록을 전부 긁어와서 aw로 끝나는 걸 거르는 스크립트를 짜버리거든요. 능력이 없던 게 아니라 도구를 쥐여주니 드러난 겁니다. 타리크는 이걸 “capability overhang, 아직 안 꺼내 쓴 능력”이라고 부릅니다.

그래서 프롬프트를 짜는 방식도 바뀝니다. 최근에 클로드 코드 시스템 프롬프트의 80%를 걷어냈다는데, 페이블급 새 모델은 오히려 짧은 프롬프트를 원한다는 겁니다. 예시를 잔뜩 주면 그 예시가 오히려 상상력을 가둡니다. 모델이 우리가 준 예시보다 더 창의적이거든요. 그래서 "이건 하지 마" 식 제약(constraint) 대신 맥락(context)을 주는 쪽으로 갔다고 합니다. 저도 이 얘기 듣고 사내 프롬프트에서 "하지 마" 목록부터 지워봤는데, 확실히 결과가 나아졌습니다.

지도는 영토가 아니다: 결과물의 병목은 나의 'unknowns'

두 번째 파트가 실전에서 가장 쓸모 있었는데요. 타리크는 "지도는 영토가 아니다(map is not the territory)"라는 말을 꺼냅니다. 내가 프롬프트나 스펙에 적은 건 지도일 뿐이고 실제 영토, 그러니까 코드베이스와 요구사항과 현실은 훨씬 넓다는 거죠. 페이블은 자율성이 커서 이 넓은 영토를 혼자 돌아다닙니다. 그러다 내 지도에 없는 지점을 자꾸 만나죠. 그가 "페이블을 쓰면서 처음으로 내 unknown을 진짜 찾아내야겠다고 느꼈다"고 말한 이유입니다.

이 unknown을 네 칸으로 나눠볼게요. 내가 알고 있고 프롬프트에 적는 것(known knowns), 아직 못 풀었다고 아는 것(known unknowns), 너무 당연해서 안 적지만 보면 아는 것(unknown knowns), 아예 고려조차 못 한 것(unknown unknowns). 사고를 치는 건 주로 오른쪽 아래 두 칸이고요. 아래 기법들은 전부 이 안 보이는 칸을 비싸지기 전에 미리 끄집어내려는 장치입니다.

구현 전: 비싸지기 전에 모르는 것을 찾아라

페이블은 토큰을 빨리 태웁니다. 한참 달린 뒤에 "아, 그건 내가 원한 게 아닌데" 하면 그 비용이 다 날아가죠. 그래서 코드를 짜기 전에 모르는 걸 먼저 터는 게 이득입니다. 발표와 공식 블로그에 나온 다섯 가지를 복붙용 한국어 프롬프트로 옮겨봤습니다.

블라인드 스팟 패스

내가 뭘 모르는지조차 모를 때 씁니다(unknown unknowns).

이 코드베이스에 새 인증(auth) 프로바이더를 붙이려는데, 나는 여기 auth 모듈을 하나도 몰라.
blind spot pass 해줘. 내가 놓치고 있는 unknown unknowns를 찾아서 내가 프롬프트를 더 잘 쓰도록 도와줘.

타리크는 이걸 코드뿐 아니라 새 분야를 배울 때도 쓴다고 합니다. 익숙한 코드베이스에 낯선 모듈을 붙일 때 특히 요긴하고요.

브레인스토밍·프로토타이핑

내 안에 있지만 말로 못 꺼내는 취향(unknown knowns)을 끌어내는 용도예요. 시각적인 결정이 특히 그렇죠.

나는 시각적인 취향이 딱히 없어. 완전히 다른 방향의 디자인 4개를 한 HTML 페이지에 만들어줘.
내가 보고 반응할 수 있게.

말로 스펙을 쓰는 것보다 눈앞에 4개 놓고 "이건 별로, 저건 좋아"하는 게 훨씬 빠릅니다.

역인터뷰

이번엔 클로드가 나를 인터뷰하게 합니다.

애매한 부분에 대해 한 번에 하나씩 나를 인터뷰해줘.
내 대답으로 아키텍처를 바꿀 만한 질문을 우선적으로 해줘.

"아키텍처를 바꿀 질문 우선"이 핵심이죠. 사소한 질문 백 개보다 판을 뒤집을 질문 세 개가 더 낫습니다.

레퍼런스

클로드에 지도를 주는 가장 좋은 방법은 다른 지도를 주는 거라고 합니다. 스펙을 장황하게 쓰는 대신, 참조 코드나 목업을 던지는 거죠. 언어가 달라도 됩니다.

vendor/rate-limiter에 있는 이 Rust 크레이트가 내가 원하는 backoff 동작을 정확히 구현하고 있어.
읽고 나서 같은 동작을 우리 TypeScript API 클라이언트에 그대로 다시 구현해줘.

만약 React 컴포넌트를 만들 거면 HTML 목업 하나가 스펙 열 줄보다 낫습니다.

거꾸로 배우기

앞의 블라인드 스팟 패스를 응용해, 아예 새 분야를 클로드에게 배우는 방식입니다. 타리크는 최근 영상 편집의 컬러 그레이딩을 이렇게 익혔다고 합니다.

나는 컬러 그레이딩을 하나도 몰라. 이걸 처음 배우는 사람 기준으로,
내가 뭘 모르는지부터 짚어주고 핵심 개념을 순서대로 가르쳐줘.

내가 잘 모르는 영역일수록 그냥 "가르쳐줘"보다 "내가 뭘 모르는지 짚어줘"가 잘 먹힙니다.

구현 중: 클로드가 내린 결정을 기록하게 하라

이제 실행 단계입니다. 페이블이 오래 달리다 보면 내 지도에 없던 갈림길에서 혼자 결정을 내립니다. 문제는 나중에 결과만 보면 "왜 이렇게 했지?"를 알 수가 없다는 거죠. 그러니 결정을 남기게 시킵니다.

작업하다가 내 지시에 없는 판단을 내려야 하면 일단 보수적인 쪽을 택하고 계속 진행해.
대신 어떤 지점에서 뭘 왜 그렇게 결정했는지 implementation-notes.md에 로그로 남겨줘.

공식 문서도 비슷한 얘기를 합니다. 페이블은 이전 실행에서 배운 걸 markdown에 적어두고, 다시 참조할 때 특히 잘 굴러간다고요. 한 파일에 교훈 하나씩, 맨 위에 한 줄 요약, 그리고 왜 중요했는지까지 적으라고 권합니다. 진행 상황을 보고할 때도 "이번 세션 도구 실행 결과에 각 주장을 대조해서, 검증 안 된 건 검증 안 됐다고 명시해."라고 시키면 없는 성공을 지어내는 일이 줄어듭니다.

구현 후: 퀴즈를 통과하기 전엔 머지하지 않는다

마지막은 검증입니다. 페이블이 다 만들었다고 그대로 PR 올리면 안 됩니다. 정작 내가 그 변경을 설명하지 못 하면 리뷰에서 막히거든요. 그래서 타리크는 끝나고 나서 클로드에게 퀴즈를 내게 시킵니다.

이번 변경사항을 내가 맥락·직관·무엇을 왜 했는지까지 이해할 수 있게 HTML 리포트로 정리해줘.
맨 아래엔 이 변경에 대한 퀴즈를 붙여줘. 내가 반드시 풀어서 통과해야 하는 걸로.

앞서 나온 컬러 그레이딩이 이 전 과정을 잘 보여줍니다. 문외한인 분야를 블라인드 스팟 패스로 배우고(발견 전), 작업 중엔 결정을 로그로 남기고(구현 중), 끝나선 퀴즈로 자기 이해를 확인한 뒤 머지합니다(구현 후). 만드는 속도는 빨라졌지만, 그 결과를 내가 책임지고 설명할 수 있느냐는 여전히 사람의 몫이라는 거죠.

커뮤니티에서도 검증된 활용 패턴

발표 말고 커뮤니티에서도 비슷한 내용이 반복됩니다. 가장 자주 보이는 게 싼 모델로 계획하고 페이블로 실행하는 구성인데요. Wavect의 케빈 리들(Kevin Riedl)은 작업을 Explore·Plan·Execute 세 단계로 쪼갭니다. 탐색은 저렴한 모델로, 설계 판단은 페이블로, 실제 구현은 오퍼스나 소넷으로 나누는 거죠. 페이블을 오케스트레이터로 두고, 나머지를 서브 에이전트로 부리는 구성입니다. 문법 고치기 같은 타이핑 노동이 아니라, 아키텍처·마이그레이션·디버깅·리뷰 같은 판단에는 페이블을 아끼라는 조언입니다.

또 페이블이 정리해둔 걸 자산으로 남겨두는 것도, 남은 이틀을 생각하면 아까운 장사가 아닙니다. 7월 12일에 페이블이 닫혀도, 그 안에서 페이블이 만든 스킬 파일이나, 메모리 노트는 그 뒤에도 남아 있죠. 지금 페이블로 팀 관례나 반복 작업을 마크다운으로 정리해 두면, 나중에 더 싼 모델로 돌려도 그 자산은 계속 쓸 수 있습니다. 저는 개인적으로 이게 제일 이득이라고 봅니다.

무엇보다 페이블은 크고 어려운 일감에 몰아 쓰는 게 맞습니다. 공식 문서도 대놓고 페이블은 사람이 몇 시간, 며칠, 몇 주 걸릴 end-to-end 작업에 붙일 때 진가를 발휘하고, 쉬운 일로 테스트하면 능력을 저평가하게 된다고 말합니다. 프로그래머 사이먼 윌리슨(Simon Willison)은 페이블을 두고 "relentlessly proactive(집요하게 알아서 움직인다)"라고 표현했는데요. 시키지도 않은 Playwright·CORS 서버·pyobjc까지 스스로 조합해 버그를 잡았다고 합니다(그 세션 비용이 $12.11).

국내 사례도 비슷합니다. 한국의 워프센스는 개인용 로컬 앱 만들기, 코드베이스 전체에서 버그 찾기, 브라우저 게임 만들기, 주식 투자 기법 검증하기, 문서 기반 전문가 조언 받기 등을 페이블 5의 활용법으로 꼽았습니다. 또 주식 투자 기법 검증에서는 "이런 기법으로 투자하는데, 이를 증명하거나 박살내 주세요."처럼 확증 편향을 깨는 프롬프트를 추천했습니다.

하지만 페이블 5의 한계점도 있습니다. 바로 공격적인 사이버보안 기법이나 생물학·생명과학 관련 쿼리(실험 방법, 분자 메커니즘 등)를 감지하면 안전 분류기가 작동해 Opus로 넘긴다는 건데요. 실제로 생물다양성에 대한 프로젝트를 하던 한 개발자는 "생물학이랑 관련됐다고 전부 오퍼스로 보내서 페이블이 쓸모없어졌다"고 말했습니다. 만약 이런 태스크를 다룬다면, 굳이 무리해서 페이블을 고집할 필요가 없겠죠.

마치며: 남은 이틀, 달려봅시다

시계를 다시 볼게요. 만료는 7월 12일 밤 11시 59분 59초(태평양시), 한국 시간으로는 7월 13일 오후 4시쯤입니다. 딱 이틀 남짓 남았습니다. 오늘의 팁을 정리하면 다음과 같습니다.

코드를 짜기 전에 블라인드 스팟 패스·인터뷰·레퍼런스로 내 unknown부터 먼저 털어내세요.
실행 중엔 결정을 implementation-notes.md에 남기게 하고, 끝나면 퀴즈로 내 이해를 확인한 다음 머지하세요.
이 아까운 며칠은 자잘한 일 대신 대규모 리팩터·전체 버그 스캔·긴 문서 분석 같은 큰 일감에 몰아 쓰세요.

물론 7월 12일 이후에도 페이블 5가 완전히 사라지는 건 아닙니다. usage credit으로는 계속 쓸 수 있어요. 다만 입력 100만 토큰당 $10, 출력 100만 토큰당 $50으로 Opus 4.8의 딱 두 배라 실사용엔 부담이 큽니다. 서브스크립션으로 돌아올지는 앤트로픽이 "용량이 되면"이라고만 말했고요. 그러니 지금이 마음 편히 달려볼 때입니다.

타리크의 마지막 말을 빌리자면, “탐험하세요. 실제로 만드세요. 그리고 조금 덜 합리적으로 굴어보세요.” 남은 이틀, 달려봅시다.

<출처>

[AI Engineer] Field Guide to Fable — Thariq Shihipar, Anthropic
[Thariq, X] A Field Guide to Fable: Finding Your Unknowns