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도 그런 모델이고, 저는 이 모델에 애정도 많이 가고 설렘도 커요.

제가 보기에 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에도 아직 배울 것이 많습니다. 하지만 있는 힘껏 노력하고, 루프 안에 머물며, Fable의 족쇄를 풀어낸다면 우리는 거기에 도달할 수 있고, 반대편으로 나와 훨씬 더 많은 것을 손에 쥘 수 있다고 생각합니다.

• • •

4. 비합리적으로 굴기

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

이건 제가 우리 문화에서 정말 소중히 여기는 부분이고, 앞으로 저는 훨씬 덜 합리적으로 굴려고 합니다. Claude와 Fable이 있으면 셈법이 달라지고, 그러면 트레이드오프를 생각하는 방식도 크게 달라진다고 봐요. 우리가 머릿속에서 은연중에 감수하는 트레이드오프가 한두 가지가 아니잖아요. 좋게, 빠르게, 싸게. 원래는 이 중 둘만 골라야 했는데, 이제는 셋 다 고르면 됩니다.

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

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

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

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