Fable 필드 가이드

게시일: 2026년 7월 7일 | 원문 작성일: 2026년 7월 7일 | 저자: Thariq Shihipar (Anthropic) | 출처: AI Engineer 강연 | 원문 보기

• • •

들어가며: 지도가 열린다

본론으로 들어가기 전에, 말씀드린 대로 Fable이 돌아왔습니다. 오늘 늦게 출시할 예정이고, 정확한 일정은 곧 공유하겠습니다. 저와 Cat Wu, Simon Willison이 12시 30분에 파이어사이드 챗을 진행하는데, 그때 몇 가지 새 소식을 전할 수 있을지도 모르겠어요. 어쨌든 Fable은 제가 정말, 정말 기대하는 모델입니다. Sonnet 3.5 New, Opus 4, Opus 4.5처럼 두고두고 기억에 남는 부류의 Anthropic 모델, 제가 유독 애정과 설렘을 갖는 그런 모델이에요.

Fable을 가장 잘 설명하는 표현은 지도가 열린다는 말입니다. RPG를 하다 보면 튜토리얼 구간을 지나 마침내 오픈월드가 시작되는 순간이 오잖아요. 할 수 있는 것도, 탐험할 곳도 너무나 많죠. 하지만 바로 그만큼 조금 막막하고 혼란스럽기도 합니다. 할 수 있는 게 너무 많으니까요. 그래서 이 강연에서 하고 싶은 건, 여러분에게 Fable 필드 가이드를 드리는 것입니다. 이 새로운 부류의 모델과 어떻게 일해야 할까요?

네 갈래로 나눠 이야기하려고 합니다. 사실 이걸 여러 편의 글과 블로그 포스트로 나눠 쓰고 있었는데, Fable 출시가 발표되자 “그래, 강연에서 한꺼번에 다 풀자, 스피드런처럼” 싶었어요. 그래서 네 부분입니다. Claude의 족쇄 풀기, 나의 미지수 찾기, 상실을 마주하기, 그리고 비합리적으로 굴기.

• • •

1. Claude의 족쇄 풀기

우리가 정말 자주 하는 말이 있습니다. 모델은 설계되는 게 아니라 길러진다는 것이죠. 어느 날 아침에 일어나 “SWE-bench에서 99%를 찍어야 해”라고 정하는 식이 아닙니다. 모델은 우리가 정성껏 길러내는 무언가예요. 데이터와 피드백과 연산을 주지만, 결국엔 조금은 유기적이어서, 우리도 모델을 쓰면서 함께 알아가고 배워갑니다. 그렇다는 건 곧, 모델을 가두는 게 바로 우리라는 뜻이기도 합니다. 우리가 씌우는 하네스, 우리가 프롬프트하는 방식은 결국 우리가 Claude를 이해한 만큼의 함수인 셈이죠.

제가 말하는 족쇄 풀기 (unhobbling)란, Claude를 더 잘 이해해서 그 잠재력을 풀어주자는 뜻입니다. Fable을 더 깊이 이해해야 해요. 제 요점 중 하나는 우리가 아직 아주 초기 단계에 있다는 것, 그리고 Fable 안에는 앞으로 풀어낼 이해가 훨씬 더 많이 남아 있다는 것입니다.

능력 과잉: 뾰족하게 똑똑해지는 모델

모델이 어떻게 더 똑똑해지는지, 조금 직관에 어긋나는 예를 하나 들어보겠습니다. 몇 주 전에 바이럴하게 퍼진 트윗을 봤는데, “왜 LLM은 이름이 ‘aw’로 끝나는 포켓몬을 못 맞히지?”라는 내용이었어요. 포켓몬이 천 마리쯤 되는데, 그중 이름이 ‘aw’로 끝나는 건 엘리게이(Croconaw)와 갈가부기(Drednaw) 딱 둘입니다. 그런데 일반 챗 모델에게 물어보면 답을 못 해요. 좀 이상하죠. 포켓몬 이름은 분명히 다 알고 있으니까요. 그런데 Claude Code에게 물어보면 맞힙니다. 뭘 하냐면, 모든 포켓몬을 가져와서 ‘aw’로 끝나는 걸 걸러내는 스크립트를 짜거든요.

이게 바로 제가 말하는 Claude의 족쇄 풀기입니다. 우리는 이걸 능력 과잉 (capability overhang)이라고 부릅니다. Claude는 뾰족한 방식으로 똑똑해집니다. 모든 포켓몬을 외워서 추론으로 답을 내는 게 아니라, 코드 실행 도구를 쥐여주면 ‘aw’로 끝나는 두 마리를 찾아내는 거죠. 이게 Fable의 도전 과제이기도 합니다. 이 능력 과잉이 어디까지인지, 이제 무엇이 가능해졌는지 알아내는 것 말이에요. 저는 이걸 여러분과 함께 탐험해 나가는 게 정말 기대됩니다.

모델은 이렇게 발전해 왔다

조금 더 분명히 하기 위해, 지금까지 모델이 어떻게 발전해 왔는지 몇 가지 예를 들어보겠습니다. 대표적인 예가 챗입니다. 챗 모델에는 맥락을 직접 넣어줘야 했죠. 이를테면 코드베이스를 통째로 붙여넣는 식으로요. 순진하게 생각하면, 코딩 문제는 맥락 창을 무한정 키워서 푸는 거라고 여길 수 있습니다. 1억 토큰짜리 맥락 창에 코드베이스 전체를 붙여넣으면 되지 않겠냐고요. 그런데 알고 보니 그게 아니라, 모델에게 팔다리를 달아주면, 즉 bash 도구를 주고 환경과 상호작용할 방법을 주면, 모델이 스스로 맥락을 만들고 검색합니다. 그게 바로 Claude Code로 이어진 통찰이에요. 역시나 뾰족하죠. 모델을 대하고 다루는 방식에서의 새로운 혁신입니다.

그리고 최근에는 Claude Tag를 선보였습니다. Claude Tag를 가능하게 한 건, Claude가 능동적으로 그리고 멀티플레이어로 일하는 능력입니다. Claude Code는 여러분이 프롬프트를 넣어야 일을 시작하잖아요. 그런데 Claude가 스스로 깨어나 일을 하는 이 능력이야말로, 새로운 에이전트의 물결을 열어젖히고 있다고 봅니다.

여기서 더 있습니다. 예를 들어 최근에 우리는 Claude Code의 시스템 프롬프트에서 80%를 덜어냈습니다. 이건 모델이, 그리고 모델에게 필요한 것이, 시간에 따라 어떻게 달라지는지 보여주는 한 예입니다. 원래 Sonnet 3.5 New 시절의 모범 사례는 작은 시스템 프롬프트, 적은 도구, 많은 예시였어요. 그러다 모델이 똑똑해지면서 정보와 지시를 더 많이 줘도 잘 따르기 시작했고, 그래서 큰 시스템 프롬프트, 많은 예시, 많은 도구가 됐죠. 그런데 가장 최근에 발견한 건, 이 새로운 부류의 모델은 오히려 더 작은 시스템 프롬프트를 원한다는 겁니다. 예시가 오히려 모델을 옭아매요. 우리가 주는 예시보다 모델이 더 상상력이 풍부하거든요. 그래서 우리는 제약이 아니라 맥락을 주려고 합니다. “이건 하지 마”라는 식의 지시를 정말 피하려고 애써요. 이전 모델에는 그게 꼭 필요했지만요. 시스템 프롬프트가 이렇게 달라지고 있고, 앞으로도 계속 달라질 겁니다.

제가 정말 좋아하는 또 다른 기능은 사용자에게 질문하기(ask-user-question) 도구입니다. 제가 Claude Code에 처음 왔을 때 작업한 기능인데, Claude가 계획을 세우거나 뭔가 묻고 싶을 때 객관식 선택지를 띄워줄 수 있어요. Opus 4에서는 이 도구를 겨우겨우 호출하는 수준이라, 제대로 작동하게 하려고 도구를 정말 많이 손봐야 했습니다. 그러다 Opus 4.5쯤 되니 “스펙에 대해 나한테 40개쯤 질문해 봐”라고 하면 저를 인터뷰하기 시작하더군요. 질문하는 능력이 확 뛴 거죠. 그리고 가장 최근 Opus 4.8과 Fable에서는, 질문을 통째로 담은 HTML 리포트를 만들어낼 수 있습니다. Claude와 상호작용하는 완전히 새로운 방식이에요. 이렇게 Claude가 여러분에게서 정보를 얻어내는 방식도 계속 변해 왔습니다.

말이 나온 김에, 마크다운과 HTML 얘기도 자주 하는데요. 처음에 마크다운은 모델을 위한 좋은 출력 형식이었습니다. 약간의 풍부한 정보를 담을 수 있었죠. 그러다 플랜 모드가 나오면서 여러분을 위한 것이 되기 시작했어요. Claude가 무엇을 하려는지 여러분이 이해할 수 있게요. 그리고 이제는 Claude가 깊이 있는 HTML 리포트를 만들어 줍니다. 역시나 모델이 뾰족한 방식으로 똑똑해지는 한 예입니다.

물리학이 아니라 생물학

제가 강조하고 싶은 건, 이건 물리학보다 생물학에 가깝다는 점입니다. 여전히 매우 경험적이고 유기적이에요. 우리는 모든 규칙을 알지 못하지만, 그래도 그 뒤에는 일종의 과학이 있습니다. 길러내야 할 직관 같은 것도 있고요. 그러니 Fable도 그렇게 대해 주시길 정말 권합니다. 우리가 Anthropic에서 쓴 논문 중 제가 가장 아끼는 것이 거대 언어 모델의 생물학 (the biology of a large language model)에 관한 글입니다. 우리 연구 논문은 다양한 기술 수준의 독자가 읽을 수 있도록 쓰여 있는데, 이 논문은 그중에서도 제가 특히 좋아하는 것이니, 조금 더 배우고 싶으신 분은 꼭 한번 읽어보시길 권합니다. 자, 여기까지가 Claude의 족쇄 풀기였습니다.

• • •

2. 나의 미지수 찾기

그런데 Fable과 일하다 보면, 여러분 자신의 족쇄도 풀어야 한다는 걸 알게 됩니다. 제가 자주 생각하는 게 있는데, 지도는 영토가 아니다라는 말입니다. 제가 코딩 문제를 다룰 때, 머릿속에 있는 계획과 프롬프트와 스펙은 지도예요. 하지만 영토는 실제 코드베이스, 실제 세계, 그리고 Claude가 헤쳐 나가야 할 진짜 제약들이죠. Claude가 영토에서 지도에 없는 무언가를 마주칠 때, 저는 그걸 미지수라고 부릅니다. Claude는 그걸 어떻게 처리할지 스스로 판단해야 해요. 제가 미리 정해두지 않은 결정 지점인 거죠. Fable은 제가 “정말 내 미지수를 밝혀내야겠구나” 하고 절감한 첫 모델입니다. 그러지 않으면, 워낙 넓은 영역을 누비다 보니 미지수를 잔뜩 마주치게 되거든요.

미지수 매트릭스

그럼 미지수는 어떻게 찾을까요? Fable을 쓰다 보면, 지도와 영토를 맞춰보며 미지수를 찾아내는 제 능력이 오히려 병목이 됩니다. 저는 이걸 매트릭스로 생각하길 좋아합니다. 어떤 문제든 이렇게 나눌 수 있어요.

다행히 Claude, 즉 Fable을 활용하면 내 미지수를 찾아낼 수 있습니다. 제가 Fable로 그걸 어떻게 하는지 몇 가지 예를 보여드릴게요.

미지수를 찾는 실전 방법들

첫째, 제가 사각지대 점검(blind spot pass)이라고 부르는 걸 즐겨 합니다. 이런 식으로 말하죠. “이 코드베이스에 내가 전혀 모르는 새 OAuth 공급자를 붙이려고 하는데, 관련된 ‘모르는 모름’을 찾아내고 프롬프트를 더 잘 짤 수 있게 사각지대 점검을 해줄래?” 그러면 Claude가 OAuth 모듈을 훑으면서 “아, 여기 자주 걸리는 골치 아픈 막다른 길이 있네” 같은 걸 짚어줍니다. 제 git diff나 Slack을 뒤지기도 하고요. 맥락이 어디 있는지 알려주면, 온갖 함정을 미리 배울 수 있어요. 이건 아주 넓게 응용할 수 있습니다. 새로운 분야를 배우는 데에도 쓸 수 있어요. 저는 최근에 영상 편집을 하면서 컬러 그레이딩을 배우는 데 이걸 써봤습니다. 정말 강력하고, Fable은 이걸 기막히게 잘하거든요. 여러 면에서 모델은 거의 모든 것에 대해 저보다 더 많이 알고 있어요. 저는 그걸 끄집어내기만 하면 됩니다.

둘째, 브레인스토밍과 프로토타입입니다. 이건 ‘모르는 앎’을 찾는 데 도움이 돼요. 특히 디자인처럼 “보면 안다”는 영역에서요. 예를 들어 대시보드를 만들어 달라고 하면서 이렇게 말합니다. “나는 시각적 안목이 전혀 없으니, 완전히 다른 방향의 디자인 네 가지를 HTML 페이지로 만들어 줘. 내가 반응해 볼 수 있게.” 취향에 맞게 조정하면 되는데, 핵심은 말로 설명할 수 없는 것들이 뭔지 감을 잡고, 모델과 함께 그걸 알아내는 겁니다.

셋째, 인터뷰입니다. 어느 정도 “이걸 하고 싶다”는 그림이 생겼어도, 미처 고려하지 못했거나 명시하지 못한 미지수가 여전히 많이 남아 있죠. 그래서 저는 Claude에게 저를 인터뷰해 달라고 합니다. 질문마다 저와 제 작업, 지금 어느 단계인지에 대한 맥락을 조금씩 더 주면서요. “아키텍처를 바꿀 만한 질문을 우선해 줘” 같은 주문은 정말 큰 도움이 됩니다.

넷째, 레퍼런스입니다. Claude에게 지도를 주는 가장 좋은 방법 중 하나는, 또 다른 지도를 주는 것입니다. 스펙을 일일이 써 내려가는 대신 “여기 내가 원하는 걸 대표하는 코드가 있어. 다른 시스템이나 언어라도 좋으니, 이걸 읽고 이해한 다음 그걸 바탕으로 작업을 시작해”라고 말할 수 있어요. 이것도 방식이 아주 다양합니다. React 컴포넌트를 만든다면, 제 지도가 되는 HTML 목업을 레퍼런스로 넘길 수 있죠. 정말, 정말 강력하고 Fable은 이걸 기막히게 해냅니다.

다섯째, 구현 노트입니다. Fable을 돌리다가 미지수에 부딪히면, 그걸 기록해 달라고 하세요. 그러면 어디서 이탈이 일어났는지 볼 수 있고, 왜 그랬는지도 짚어낼 수 있습니다. 보통 무슨 일이 있었는지에 대한 맥락을 함께 남겨주거든요.

마지막으로, 저는 Fable에게 무슨 일이 있었는지 나한테 퀴즈를 내달라고 하길 좋아합니다. 내가 지금 뭘 하고 있는지 제대로 이해했는지, 나중에 PR을 만들거나 머지할 때 이 작업을 제대로 설명할 수 있는지 확인하려는 거예요. 이건 여러분이 Fable과 함께 루프 안에 머무는 아주 좋은 방법입니다. 그리고 저는 이게 Fable 작업에서 가장 중요한 부분 중 하나라고 생각해요. 루프 안에 머물면서, 내가 원하는 걸 제대로 얻고 있는지 확인하는 것 말입니다. 여기까지가 Fable과 일할 때의 제 팁 몇 가지였습니다.

• • •

3. 상실을 마주하기

Mythos급 모델, 즉 Fable을 처음 써봤을 때, 저는 크게 얻었다는 벅찬 느낌과 동시에 상실감도 느꼈습니다. 그 얘기를 조금 하고 싶어요.

LLM 이전의 코딩을 떠올리면, 마치 낯선 외국 같은 느낌입니다. 저는 예전에 30명 규모의 YC 스타트업을 운영했는데, 코드가 워낙 어렵다 보니 늘 트레이드오프에 내몰렸어요.

앱을 빠르게 만들 것인가, 아니면 새 기능을 프로토타이핑해 볼 것인가. 이건 한 달, 저건 두 달. 그래서 하나를 골라야 했죠. 정말, 정말 힘들었습니다.

그런데 몇 주 전에 그 코드베이스로 돌아가서, 예전에 하고 싶었던 것들을 다시 떠올려봤어요. 그런데 그냥 훨씬 쉬운 거예요. 몇 주가 걸렸을 일이 몇 시간이면 됐습니다. 그러다 보면 어느 순간, 어떻게 웃지 않을 수 있으며, 또 어떻게 울지 않을 수 있겠어요. 저는 손으로 코드를 짜고 프로그래밍하는 걸 정말, 정말 사랑했거든요. 코드베이스를 머릿속에 그리고 이리저리 회전시켜 보는 그 감각을 사랑했어요.

하지만 저는 밤을 새워가며 디버깅하던 것도, 몇 주 동안 아무것도 안 돌아가는 걸 붙잡고 있던 것도 기억합니다. 그저 실패 속에서 허우적대던 기억이요. 제가 해온 프로젝트 대부분이 실패했고, 스타트업 대부분은 파산합니다. 전반적으로 프로그래밍과 코딩은 지독히 어려워요. 그 짜릿한 순간들을 아무리 즐겼다 해도, 저는 되돌아갈 수 없습니다.

여기서 제 성찰은, 빠져나가는 유일한 길은 통과하는 것이라는 겁니다. 코딩에도, Fable에도 아직 배울 것이 많습니다. 하지만 정말 열심히 노력하고, 루프 안에 머물며, 족쇄를 풀어낸다면 우리는 거기에 도달할 수 있고, 반대편으로 나와 훨씬 더 많은 것을 손에 쥘 수 있다고 생각합니다.

• • •

4. 비합리적으로 굴기

마지막으로 이야기하고 싶은 건 그 “훨씬 더 많은 것”에 관한 부분입니다. 저는 이걸 비합리적으로 굴기라고 부릅니다. Anthropic에서 제가 가장 좋아하는 점 하나는, 우리가 트레이드오프는 실재하지 않는다고 믿는다는 거예요. 예전 회사에서 저는 아주 합리적으로 구는 데 익숙했습니다. 우선순위 목록을 쭉 적어놓고 “음, 이건 저것과 저울질해야겠지”라고 했죠. 말이 되니까요. “그래, 이번 분기엔 이걸 우선순위로 하자.” 그런데, 그냥 전부 다 해버리면 어떨까요? 현실이 트레이드오프를 억지로 드러내게 만들면요?

이건 제가 우리 문화에서 정말 소중히 여기는 부분이고, 앞으로의 제 다짐은 훨씬 덜 합리적으로 굴겠다는 것입니다. Claude와 Fable의 셈법은 트레이드오프에 대한 생각을 완전히 바꿔놓아요. 우리가 머릿속에서 은연중에 감수하는 트레이드오프가 정말 많잖아요. 좋게, 빠르게, 싸게. 원래는 이 중 둘만 골라야 했는데, 이제는 셋 다 고르면 됩니다.

더 야심 찬 작업을 해내는 가장 좋은 방법은, 우리 스스로를 다시 프레이밍해서 더 야심 차게 만드는 것이라고 생각합니다. 에이전트가 정말 작동한다는 걸 증명하는 유일한 길은, 인생 최고의 작업을 그 어느 때보다 빠르게 해내는 것이니까요. 예를 들어 저는 이 발표 자료를 어젯밤에 Fable로 약 4시간 만에 만들었습니다. 제가 정말 마음에 드는 덱이고 만드는 과정도 즐거웠는데, 게다가 정말 빨리 끝냈어요.

여기 AI Engineer에 오신 여러분이라면, 세상이 어느 정도는 여러분을 바라보며 AI가 정말 작동한다는 걸 증명해 주길 기대하고 있습니다. 한때의 유행 같은 게 아니라, 우리를 더 생산적으로 만들고 시간도 아껴줄 수 있다는 걸요. 그리고 그게 올해 제 다짐이기도 합니다. 더 생산적이되 일은 덜 하고, 정말 아끼는 사람들과 더 많은 시간을 보내는 것.

짚고 넘어갈 만한 게 하나 더 있습니다. 만드는 건 쉬워졌지만, 가치를 만들어내는 건 여전히 어렵다는 것. AI 엔지니어로서 우리가 종종 부딪히는 지점이에요. 우리는 만드는 과정과 우리의 셋업에 너무 많이 몰두하곤 합니다. 하지만 요점은 가치를 만들어내는 것입니다. 가치 있는 걸 찾아내려면 수많은 시도가 필요하지만, 진짜 목표는 바로 그것이에요. 그리고 그게, 세상이 우리에게 증명해 주길 바라는 것이기도 합니다. AI가 정말로 세상을 바꿔놓을 수 있다는 걸요.

이제 마무리하며 이 말을 남기고 싶습니다. 탐험하러 나가고, 직접 만들어 보고, 덜 합리적으로 구세요. 감사합니다.