Field Guide to Fable — Thariq Shihipar, Anthropic
📺 원본 영상: Field Guide to Fable — Thariq Shihipar, Anthropic
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-07
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
이 강연에서 Anthropic의 Thariq Shihipar는 Fable을 단순히 더 강한 모델이 아니라, 사용자가 모델과 일하는 방식을 다시 조정해야 하는 새로운 종류의 시스템으로 소개한다. 그의 핵심 주장은 모델의 능력이 선형적으로 좋아지는 것이 아니라, 도구·프롬프트·환경과 결합될 때 갑자기 새로운 가능성이 열리는 방식으로 나타난다는 점이다.
따라서 Fable을 잘 쓰기 위해서는 “더 좋은 프롬프트”만 필요한 것이 아니다. 사용자는 모델을 묶어두는 제약을 줄이고, 자신이 모르는 것을 더 잘 드러내며, 에이전틱 코딩이 가져오는 감정적 전환을 받아들이고, 기존의 합리적 타협을 의심할 수 있어야 한다. 이 강연은 그 네 가지 태도를 중심으로 Fable 시대의 개발자가 어떻게 일해야 하는지 설명한다.
02:24 - 강연자가 Fable field guide의 네 가지 구성인 Claude 풀어주기, unknown 찾기, 상실감 다루기, 덜 합리적으로 일하기를 소개하는 구간
Fable은 왜 “지도 밖의 세계”처럼 느껴지는가
Shihipar는 Fable을 설명하면서 RPG에서 튜토리얼이 끝나고 오픈월드가 열리는 순간에 비유한다. 이전까지 사용자는 모델에게 비교적 제한된 작업을 맡겼고, 모델이 잘할 수 있는 범위도 어느 정도 예측 가능했다. 그러나 Fable은 더 넓은 영역을 스스로 탐색하고, 도구를 사용하며, 사용자가 미처 명시하지 않은 문제까지 마주할 수 있기 때문에 가능성과 혼란을 동시에 만든다.
그가 말하는 “field guide”는 바로 이 지점에서 필요해진다. 새로운 모델을 단순히 벤치마크 점수로 이해하면 실제 작업에서 어떤 변화가 생기는지 놓치기 쉽다. Shihipar에 따르면 Fable의 중요한 특징은 사용자가 모델을 어떻게 감싸고, 어떤 도구를 주고, 어떤 방식으로 맥락을 제공하느냐에 따라 능력이 크게 달라진다는 데 있다. 다시 말해 모델 자체의 지능뿐 아니라 모델을 둘러싼 하네스와 작업 환경이 실제 성능의 일부가 된다.
Claude를 풀어준다는 것: 모델은 설계되기보다 길러진다
강연의 첫 번째 축은 “unhobbling Claude”, 즉 Claude를 묶고 있던 제약을 풀어주는 것이다. Shihipar는 Anthropic 내부에서 모델을 “designed”라기보다 “grown”한 것으로 자주 표현한다고 말한다. 이는 모델이 특정 목표 점수에 맞춰 기계적으로 조립되는 것이 아니라, 데이터와 피드백, 컴퓨팅 자원을 통해 길러지고, 실제 사용 과정에서 그 성질을 발견하게 된다는 의미에 가깝다.
그가 든 포켓몬 예시는 이 관점을 잘 보여준다. 일반적인 채팅 모델에게 이름이 “aw”로 끝나는 포켓몬을 묻는다면, 모델은 전체 포켓몬 목록을 알고 있음에도 제대로 답하지 못할 수 있다. 반면 Claude Code처럼 코드 실행 도구를 가진 모델은 포켓몬 목록을 가져오고, 스크립트를 작성해 조건에 맞는 이름을 필터링할 수 있다. Shihipar는 이 차이를 capability overhang, 즉 이미 잠재해 있던 능력이 적절한 도구와 작업 방식이 주어졌을 때 뒤늦게 드러나는 현상으로 설명한다.
이 사례에서 중요한 점은 모델이 갑자기 포켓몬 지식을 더 많이 외우게 된 것이 아니라는 것이다. 같은 지식이라도 도구를 통해 탐색하고 검증할 수 있게 되면, 모델의 실제 문제 해결 능력은 전혀 다른 수준으로 나타난다. Shihipar가 말하는 “Claude를 풀어준다”는 것은 결국 모델이 스스로 컨텍스트를 만들고, 환경과 상호작용하며, 단순 생성기를 넘어 작업 수행자로 움직이게 하는 설계를 뜻한다.
거대한 컨텍스트보다 중요한 것은 팔을 달아주는 일이다
Shihipar는 코딩 모델의 발전을 설명하면서, 초기에는 많은 사람들이 더 큰 컨텍스트 윈도우가 문제를 해결할 것이라고 생각했다고 말한다. 예컨대 전체 코드베이스를 한 번에 붙여넣을 수 있다면 모델이 더 나은 코드를 작성할 것이라는 기대가 있었다. 그러나 실제로 Claude Code가 보여준 중요한 통찰은 모델에게 Bash 도구와 파일 검색 능력처럼 환경을 직접 탐색할 수 있는 “팔”을 주는 것이었다.
이 변화는 단순한 편의 기능 이상의 의미를 갖는다. 모델이 수동적으로 주어진 문맥만 읽는 존재라면 사용자는 항상 무엇을 넣어야 하는지 결정해야 한다. 반면 모델이 파일을 검색하고, 빌드하고, 실행하고, 오류를 확인할 수 있다면 필요한 문맥을 스스로 구성할 수 있다. 이때 컨텍스트는 사용자가 던져주는 고정된 입력이 아니라, 모델과 환경 사이에서 동적으로 만들어지는 작업 산물이 된다.
Fable의 의미도 이 연장선에 있다. 더 강한 모델은 더 많은 지시를 필요로 하는 것이 아니라, 때로는 더 적은 제약과 더 넓은 작업 공간을 필요로 한다. Shihipar는 최근 Claude Code의 system prompt를 80% 제거했다고 언급하는데, 이는 최신 모델들이 이전처럼 촘촘한 예시와 금지 규칙에 의존하지 않아도 된다는 판단을 반영한다. 오히려 너무 많은 예시는 모델의 상상력과 탐색 능력을 제한할 수 있기 때문에, 이제는 제약보다 맥락을 주는 방식이 더 중요해지고 있다.
06:00 - Claude Code의 system prompt를 크게 줄인 사례와 모델 세대별 프롬프트 전략 변화를 설명하는 구간
질문하는 모델: 사용자를 인터뷰하는 Claude
Shihipar가 강조한 또 하나의 변화는 Claude가 사용자에게 질문하는 능력이다. 그는 Claude Code에 “ask user question” 도구를 도입했던 경험을 소개하며, Opus 4 시기에는 모델이 이 도구를 겨우 호출하는 수준이었다고 설명한다. 하지만 Opus 4.5 무렵에는 명세를 이해하기 위해 사용자에게 수십 개의 질문을 던지는 인터뷰가 가능해졌고, Opus 4.8과 Fable에 이르러서는 질문이 포함된 HTML 리포트까지 구성할 수 있게 되었다고 말한다.
이 변화는 인간과 모델의 역할 분담을 바꾼다. 과거의 프롬프트는 사용자가 모든 요구사항을 미리 정리해 모델에게 넘기는 방식에 가까웠다. 그러나 모델이 질문할 수 있다면, 요구사항 정의 자체가 대화형 프로세스가 된다. 사용자는 처음부터 완벽한 명세를 작성할 필요가 없고, 모델은 모호한 지점을 드러내며 작업의 방향을 함께 구체화한다.
특히 Fable처럼 더 넓은 영역을 탐색하는 모델에서는 이 능력이 중요하다. 모델이 멀리 갈 수 있을수록, 잘못된 전제나 비어 있는 결정 지점도 더 큰 영향을 미친다. 따라서 질문은 단순한 확인 절차가 아니라, 모델이 작업을 안전하게 확장하기 위한 핵심 메커니즘이 된다.
07:38 - Opus 4.8과 Fable에서 질문을 포함한 HTML 리포트까지 만들 수 있게 된 상호작용 방식을 설명하는 구간
나의 지도를 의심하기: unknown을 찾는 방법
강연의 두 번째 축은 “finding your unknowns”다. Shihipar는 작업을 시작할 때 머릿속에 있는 계획, 프롬프트, 명세를 “지도”라고 부르고, 실제 코드베이스와 현실의 제약을 “영토”라고 부른다. 문제는 지도와 영토가 언제나 일치하지 않는다는 점이다. 모델이 실제 코드베이스를 탐색하다가 사용자가 명시하지 않은 조건이나 충돌을 발견하는 순간, 그것이 바로 unknown이 된다.
그는 이 unknown을 네 가지 범주로 나누어 설명한다. 사용자가 이미 알고 있고 프롬프트에 적는 것은 known knowns이며, 아직 답은 모르지만 모른다는 사실은 아는 것은 known unknowns다. 반대로 사용자가 너무 당연하게 여겨 적지 않았지만 실제로는 중요한 전제가 unknown knowns가 되고, 아예 고려하지 못한 것은 unknown unknowns가 된다. Fable은 넓은 작업 범위를 스스로 탐색하기 때문에, 사용자가 자신의 unknown을 제대로 찾지 못하면 예상보다 많은 결정 지점에서 흔들릴 수 있다.
10:13 - known knowns, known unknowns, unknown knowns, unknown unknowns로 문제 공간을 나누는 matrix를 설명하는 구간
Shihipar가 제안하는 첫 번째 방법은 blind spot pass다. 예를 들어 새로운 인증 provider를 도입해야 하는데 해당 코드베이스를 잘 모른다면, Claude에게 관련 모듈을 훑고 unknown unknowns를 찾아달라고 요청할 수 있다. 이때 모델은 인증 모듈, Git diff, Slack 맥락처럼 사용자가 지정한 자료를 살펴보며 반복적으로 문제가 되는 지점이나 숨겨진 제약을 찾아낼 수 있다. 그는 이 방식이 코딩뿐 아니라 영상 편집의 color grading 같은 새로운 분야를 배울 때도 강력하다고 말한다.
프로토타입과 레퍼런스는 말로 못 하는 취향을 드러낸다
Shihipar는 unknown knowns를 찾기 위해 brainstorm과 prototype을 적극적으로 사용한다고 설명한다. 특히 디자인처럼 “보면 알지만 말로 설명하기 어려운” 영역에서는 처음부터 정확한 요구사항을 쓰기 어렵다. 이때 Fable에게 서로 크게 다른 네 가지 디자인 방향의 HTML 페이지를 만들게 하면, 사용자는 결과물을 보고 무엇을 좋아하고 싫어하는지 반응할 수 있다.
11:52 - brainstorm과 prototype을 통해 사용자의 암묵적 취향과 unknown knowns를 발견하는 방법을 설명하는 구간
이 방식은 프롬프트 작성의 부담을 줄이는 동시에, 사용자의 암묵지를 작업 가능한 형태로 바꾼다. 사용자는 “내 취향은 이런 것이다”라고 추상적으로 설명하는 대신, 모델이 만든 후보를 비교하면서 선택하고 수정할 수 있다. 그 과정에서 모델은 사용자의 선호를 더 구체적으로 학습하고, 다음 작업에서 더 나은 방향을 잡는다.
레퍼런스의 중요성도 같은 맥락에 있다. Shihipar는 Claude에게 지도를 주는 가장 좋은 방법 중 하나가 “다른 지도”를 주는 것이라고 말한다. 직접 긴 명세를 쓰는 대신, 다른 시스템이나 언어로 작성된 코드, HTML mockup, 기존 구현체를 넘겨주고 그것이 원하는 결과를 대표한다고 설명할 수 있다. Fable은 이러한 참조를 읽고 구조와 의도를 추출해 새로운 작업의 출발점으로 삼는 데 강하다는 것이 그의 평가다.
implementation notes와 퀴즈: 인간이 loop 안에 남는 법
Fable이 더 많은 결정을 할수록, 사용자가 작업 흐름에서 빠져나갈 위험도 커진다. Shihipar는 이를 막기 위해 implementation notes를 남기게 하라고 조언한다. 모델이 작업 중 unknown을 만났다면 어디서 어떤 판단을 했는지 기록하게 하고, 사용자는 그 기록을 통해 원래 계획과 실제 구현이 어디서 달라졌는지 확인할 수 있다.
이 접근은 단순한 로그 이상의 역할을 한다. 에이전트가 스스로 파일을 수정하고 결정을 내리는 환경에서는 최종 diff만 봐서는 왜 그런 코드가 되었는지 이해하기 어렵다. implementation notes는 모델의 경로를 사용자에게 다시 설명해 주는 장치이며, 사용자가 코드 리뷰나 PR 작성 단계에서 작업을 자기 언어로 설명할 수 있게 만든다.
Shihipar는 더 나아가 Fable에게 작업 내용을 퀴즈로 물어보게 한다고 말한다. 이는 사용자가 실제로 구현 내용을 이해했는지 확인하는 방식이다. 에이전틱 코딩의 목표는 인간을 완전히 배제하는 것이 아니라, 더 큰 작업을 맡기면서도 중요한 판단과 책임은 인간이 유지하는 데 있다. 그가 반복해서 말하는 “stay in the loop”는 Fable을 잘 쓰기 위한 기술적 원칙이면서 동시에 협업 원칙이다.
에이전틱 코딩이 주는 상실감
강연의 세 번째 축은 “dealing with the grief”다. Shihipar는 Fable 같은 모델을 처음 사용했을 때 큰 이득과 함께 상실감을 느꼈다고 말한다. LLM 이전의 코딩은 그에게 낯선 나라처럼 느껴진다고 표현할 만큼, 이미 과거의 방식이 되어버렸다. 이전 스타트업에서 그는 약 30명 규모의 팀을 운영하며 빠른 앱, 새 기능 프로토타입, 리팩터링 사이에서 끊임없이 트레이드오프를 해야 했다.
하지만 몇 주 전 그 코드베이스로 돌아갔을 때, 과거에는 몇 주 걸렸을 작업이 몇 시간 만에 가능해졌다고 한다. 이 경험은 웃기면서도 슬픈 감각을 만든다. 그는 손으로 코드를 쓰고, 머릿속에서 코드베이스를 회전시키며 이해하는 감각을 사랑했다고 말한다. 동시에 밤늦게 디버깅하고, 몇 주 동안 실패하고, 대부분의 프로젝트가 실패하는 현실도 기억한다고 덧붙인다.
이 대목에서 강연은 단순한 생산성 도구 소개를 넘어선다. AI 코딩 도구는 개발자의 시간을 줄여주는 동시에, 개발자가 자신의 정체성으로 여겼던 일부 감각을 바꿔버린다. Shihipar는 그럼에도 돌아갈 수 없다고 말한다. 프로그래밍은 본래 매우 어렵고 실패가 많은 일이었으며, Fable과 같은 도구는 그 고통을 줄이면서 더 큰 가능성을 열기 때문이다.
합리적이지 않게 생각하기: good, fast, cheap에서 pick three로
마지막 축은 “being unreasonable”다. Shihipar는 Anthropic에서 좋아하는 문화 중 하나로 “tradeoff는 실제가 아닐 수 있다”는 태도를 언급한다. 이는 모든 제약이 사라진다는 뜻이 아니라, 우리가 너무 빨리 타협을 받아들이는 습관을 경계하자는 의미에 가깝다. 과거에는 분기별 우선순위를 정하면서 하나를 선택하고 다른 것을 포기하는 것이 합리적인 관리 방식처럼 보였다.
하지만 Claude와 Fable의 수학은 그 계산을 바꾼다. 좋은 것, 빠른 것, 싼 것 중 둘만 고르는 것이 아니라 이제는 셋을 모두 시도해볼 수 있는 상황이 늘어난다. Shihipar는 현실이 실제로 어디에서 한계를 드러내는지 보기 전까지는, 머릿속에서 먼저 트레이드오프를 확정하지 말라고 제안한다. 모델이 작업 비용을 급격히 낮춘다면, 사용자는 더 큰 야망을 품어야 한다는 것이다.
그는 자신이 이 발표 자료를 전날 밤 약 네 시간 만에 Fable과 함께 만들었다고 말한다. 이 사례는 단지 슬라이드를 빨리 만들었다는 자랑이 아니라, AI Engineer 커뮤니티가 AI의 실제 효용을 증명해야 하는 위치에 있다는 메시지로 이어진다. AI가 유행어가 아니라 생산성과 시간 절약을 동시에 만들어낸다는 것을 보여주려면, 개발자들은 이전보다 더 빠르게, 더 좋은 작업을 해내야 한다.
17:49 - Fable로 발표 자료를 약 네 시간 만에 만들었다는 사례를 통해 생산성과 야망의 변화를 설명하는 구간
building은 쉬워졌지만 value는 여전히 어렵다
Shihipar는 강연 말미에서 중요한 균형점을 제시한다. AI 덕분에 building은 쉬워졌지만, value를 만드는 일은 여전히 어렵다는 것이다. AI 엔지니어들은 종종 어떤 모델을 쓰고, 어떤 setup을 만들고, 어떤 워크플로를 구성할지에 많은 관심을 쏟는다. 그러나 그 모든 과정의 목적은 결국 가치 있는 것을 만들어내는 데 있다.
이 말은 Fable 시대에도 제품 감각과 문제 선택이 사라지지 않는다는 뜻이다. 오히려 구현 비용이 낮아질수록 무엇을 만들 것인지, 누구에게 의미 있는지, 어떤 시도가 실제 변화를 만드는지 판단하는 능력이 더 중요해진다. 많은 시도를 할 수 있게 된 만큼, 가치 있는 시도를 찾아내는 탐색의 밀도도 높아져야 한다.
따라서 Shihipar의 결론은 단순하다. 더 많이 탐험하고, 아이디어를 실제로 만들고, 덜 합리적으로 굴라는 것이다. 여기서 “덜 합리적”이라는 말은 무모해지라는 뜻이 아니라, 과거의 비용 구조에서 형성된 자기검열을 내려놓으라는 요청에 가깝다. Fable은 더 큰 작업을 더 빠르게 시도할 수 있게 만들지만, 그 가능성을 현실로 바꾸는 일은 여전히 사용자의 몫이다.
마무리 / 핵심 정리
이 강연의 핵심은 Fable이 더 강한 모델이라는 사실보다, 더 강한 모델을 둘러싼 작업 방식이 함께 바뀌어야 한다는 데 있다. Shihipar는 모델에게 도구와 환경을 제공해 capability overhang을 끌어내고, blind spot pass와 인터뷰를 통해 unknown을 찾아내며, implementation notes와 퀴즈로 인간이 loop 안에 남아야 한다고 설명한다.
동시에 그는 에이전틱 코딩이 개발자에게 주는 감정적 변화도 회피하지 않는다. 코딩의 어려움과 실패를 사랑했던 사람에게, 몇 주짜리 작업이 몇 시간짜리 작업으로 바뀌는 경험은 해방이자 상실이다. 그러나 그의 결론은 과거로 돌아가는 것이 아니라 통과해 나가는 것이다. Fable을 잘 쓰는 개발자는 단지 더 빨리 코드를 쓰는 사람이 아니라, 더 큰 가능성을 현실로 만들기 위해 자신의 지도와 타협을 계속 의심하는 사람이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Field Guide to Fable — Thariq Shihipar, Anthropic |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-07 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.