🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5의 핵심은 “무엇이 가능한가”를 다시 묻게 만드는 성능보다, 장기 위임·검증·모델 배치 방식까지 바꾸는 새로운 작업 운영 방식에 있다.

📌 핵심 요점

1. Fable 5는 단순 질의응답보다 큰 과업을 오래 맡기고, 중간 장애를 스스로 우회하며, 사용자가 나중에 검토할 결과물을 남기는 장기 실행 파트너에 가깝게 설명된다.
2. 모델이 강해질수록 프롬프트를 짧게 던지는 방식보다, 목표·맥락·제약·검증 기준을 충분히 전달하고 작업을 설계하는 능력이 중요해진다.
3. 모든 작업에 Fable 5를 쓰는 것이 아니라, 빠른 질문에는 가벼운 모델을 쓰고 복잡한 장기 작업에는 더 깊게 생각하는 모델을 쓰는 식의 모델 선택과 effort 조절이 필요하다.
4. 생산성 향상은 코드 작성 자체보다 의도와 실행 사이의 간극을 줄이는 데서 크게 나타나며, 비개발자도 자기 업무 맥락에 맞는 도구를 직접 만들 가능성이 커진다.
5. 모델이 만든 결과가 실제로 좋은지, 프로덕션에 넣어도 되는지, 어떤 트레이드오프를 감수했는지는 여전히 사람이 이해하고 검증해야 하는 책임으로 남는다.

🧩 배경과 문제 정의

• Fable 5는 출시 직후의 과장된 첫인상보다, 몇 주간 실제 업무와 개인 프로젝트에 밀도 있게 적용해본 뒤 효용과 한계가 더 선명해지는 모델이다.
• 강력한 모델은 단순한 질문 응답을 넘어 작업 분해, 장기 위임, 병렬 실행, 검증 루프, 비용 관리까지 사용 방식을 함께 바꾸며 업무 습관 자체를 재설계하게 만든다.
• 비기술 직군은 “어디에 써야 하는가”를 찾는 데 어려움을 겪고, 에이전트를 조율하는 고급 사용자는 새롭게 익혀야 할 운영 기술과 책임 범위가 빠르게 늘어난다.
• 모든 작업에 최상위 모델을 쓰는 방식은 비용과 속도 면에서 비효율적이므로, 작업 유형·사용 표면·노력 수준에 따라 모델을 나누고 적절한 검증 구조를 붙이는 일이 중요해진다.
• 핵심 쟁점은 소프트웨어 엔지니어링이 사라지는지가 아니라, 인간이 어떤 맥락을 보유하고 어떤 결정을 책임지며, 모델이 만든 결과를 어떻게 검증·배포·운영할 것인지로 이동한다.

🕒 시간순 섹션별 상세정리

1. 출시 직후 반응보다 장기 사용 경험이 중요해진다

• Fable 5는 공개 하루 전 녹화 시점에서도 이미 강력한 모델로 전제되며, 핵심은 첫날의 인상이 아니라 실제 생활과 업무 흐름에 어떻게 맞물리는지에 있다 [00:12]
• 강력한 모델일수록 어디에 유용하고, 무엇을 바꾸며, 무엇은 바꾸지 못하는지 구분해야 하며, 과도한 기대보다 일상 속 적합성을 판단하는 관점이 필요하다 [00:25]

2. 프롬프트와 작업 분해 방식이 낡아진다

• 내부의 비기술·지식노동 사용자들은 새 모델의 활용처를 막막해하지만, 에이전트를 조율하는 사용자는 새로 익혀야 할 역량이 크게 늘었다고 느낀다 [01:29]
• Labs로 옮겨 다시 빌더 모드에 들어간 시점에 새 모델을 접하면서, 기존 프롬프트 작성법과 작업 분해 방식만으로는 충분하지 않다는 감각이 생긴다 [02:02]

3. 장기 위임과 자율 복구가 생산성의 중심이 된다

• 비행 중에도 올바른 맥락과 지시를 넣어두면 와이파이가 끊겨도 작업이 이어질 것이라는 신뢰가 생기며, 원격·비동기 작업의 부담이 줄어든다 [03:10]
• 복잡한 작업을 밤에 맡겨두면 새벽에 상당 부분이 완료되고, 원격 서비스 장애가 생겨도 임시 백엔드를 스캐폴딩하고 문서화하며 다음 복구 조건까지 추적한다 [03:31]

4. 사전 설계와 팀 정렬이 더 중요해진다

• Fable은 느리고 비싸기 때문에 짧은 일상 작업보다 큰 과업을 오래 맡길 때 강점이 두드러지며, 실제 업무에서는 어떤 모델을 어디에 배치할지가 중요해진다 [04:48]
• 사전 아키텍처 논의가 늘어나고, Instagram을 작은 서버에서 대규모 인프라로 확장했던 경험은 단계별 추상화와 복잡도 수준을 판단하는 기준이 된다 [05:10]

5. 여러 세션과 노력 수준 조절이 새 작업 방식이 된다

• 설계가 잡힌 뒤에는 낮과 밤에 여러 작업 덩어리를 병렬로 맡기며, 이전보다 훨씬 많은 동시 세션을 운영하는 방식이 자연스러워진다 [06:58]
• 하나의 긴 Claude Code 세션에서 백그라운드 서브에이전트를 fork해 메인 스레드의 반응성을 유지하는 방식과, 여러 탭에서 장기 작업을 병렬 처리하는 방식이 함께 쓰인다 [07:13]

6. 빠른 질문과 개인 프로젝트에서는 모델 선택과 표면이 갈린다

• 이동 중 NBA 결승 같은 가벼운 질문을 Fable에 던지면 지나치게 깊게 생각하는 느낌이 들고, 빠른 질문에는 Sonnet 같은 더 가벼운 모델이 적합해진다 [08:49]
• 장기적으로는 사용자가 모델 선택을 계속 의식하지 않도록, 용도별 버킷이나 iOS 앱 같은 표면별 sticky model selection이 제품 과제로 떠오른다 [09:25]

7. 앱 내부에서 앱을 수정하는 에이전트 네이티브 구조

• 앱 안의 채팅 인터페이스를 통해 Claude가 URL 기반 작업이나 기능 추가를 처리하고, 사용자는 메뉴를 직접 탐색하지 않아도 되는 방향이 핵심이 된다 [12:27]
• 에이전트 네이티브 아키텍처의 첫 단계는 제품 안의 모든 기능을 에이전트와 tool call로 접근 가능하게 만드는 것이며, 다음 단계는 에이전트가 앱 자체를 이동 중에도 수정하는 것이다 [12:40]

8. Manage Agent와 live preview가 만든 닫힌 제작 루프

• long press로 채팅 인터페이스를 열면 Manage Agent가 편집 요청을 맡고, 사용자는 결과를 미리 보며 변경 사항을 확인할 수 있다 [13:16]
• Vercel live preview와 diff view가 결합되면서, 한 번의 요청으로 기능을 만들고 이후 실제 사용 중에도 계속 보완하는 흐름이 가능해진다 [13:29]

9. Instagram 시절과 비교한 제작 비용과 반복 속도의 변화

• 과거에도 비슷한 앱을 만들 수는 있었지만, 지금은 빌드 비용이 크게 낮아졌고 Instagram 초기와 비교해 아이디어를 실행물로 바꾸는 시간이 훨씬 짧아졌다 [14:54]
• Instagram v1은 기능이 더 많았더라도 복잡도는 비슷한 수준이었고, 초기 제품을 내기까지 약 4~5일의 밤샘 작업과 기존 iOS 개발 경험이 필요했다 [15:31]

10. 비개발자에게 열린 제작 능력과 intent-execution 간극 축소

• 과거에는 비전문 개발자가 아이디어를 제품으로 만들려면 컨설턴시를 찾거나 자금을 모아야 했고, 전달 과정에서 원래 의도가 손실되기 쉬웠다 [16:58]
• 모델이 더 자율적이고 접근 가능해질수록 의도와 실행 사이의 간극은 줄어들고, 개발자가 아닌 사람도 실제 도구를 만들 가능성이 커진다 [17:18]

11. 소프트웨어 엔지니어링의 변화와 남아 있는 인간의 역할

• 소프트웨어 엔지니어링이 사라진 것은 아니지만, 어려운 문제 설계·텍스트 에디터 작업·프레임워크 세부 이해·배포 후 버그 수정에 집중하던 과거 형태와는 크게 달라졌다 [18:52]
• 엔지니어링과 제품 관리의 경계가 흐려지면서, 순수 개발자 역할보다 소프트웨어 생산 과정 전체를 다루는 활동의 중요성이 커진다 [19:41]

12. Anthropic 내부의 책임 구조와 비동기 에이전트 관리

• Anthropic 내부에서도 제품의 의도, 진행 상황, 향후 통합될 다른 제품 맥락은 여전히 사람이 보유해야 할 핵심 컨텍스트로 남는다 [21:47]
• 각 사람은 특정 제품 영역의 DRI로 책임을 맡으며, 모두가 막연히 개선하는 방식보다 정해진 과제와 영역을 깊게 고민하는 구조가 유지된다 [22:29]

13. 사고 대응과 프로토타입의 역할 변화

• 네트워크 링크 단절처럼 일반 장애 모드에 없는 문제가 실제 서비스에 영향을 줄 수 있으며, 엔지니어에게는 침착하게 데이터를 모으고 즉시 완화한 뒤 장기 수정으로 이어가는 경험이 여전히 중요하다 [24:01]
• 엔지니어링 프로토타입은 단순히 코드 작성 능력으로 논쟁을 이기는 수단이 아니라, PM도 직접 거친 구현을 만들어 제품 방향의 가능성과 한계를 드러내는 대화의 재료가 된다 [24:42]

14. 프로덕션 AI의 회귀 위험과 관측 가능성

• AI 기능은 테스트에서 정상처럼 보여도 프롬프트·모델·파라미터 변경 뒤 며칠 만에 예상 밖 응답과 지원 티켓으로 이어질 수 있고, 언제 왜 문제가 생겼는지 추적하기 어렵다 [25:35]
• Braintrust는 프로덕션 실행 경로, 평가 기준, 실험 비교를 하나의 워크플로로 연결해 변경이 품질을 개선했는지 악화했는지 측정하는 관측 가능성 도구로 드러난다 [25:54]

15. Fable 5 비용과 실제 경제성

• Fable 5는 비용이 높은 모델이기 때문에 개인 사용자는 실행 전 비용을 의식하게 되고, 이 구조는 누가 어떤 용도로 쓸 수 있는지를 제한할 수 있다 [26:50]
• 회사 업무에서는 단순 도입 장려를 넘어 사용량 경쟁이 생겼고, 이제는 누가 효과적으로 쓰는지와 낭비 없이 충분히 쓰게 하는 프로세스가 더 중요해진다 [27:43]

16. 모델의 차별점은 시스템 맥락과 판단력

• Fable 5의 발전은 사전학습과 강화학습 작업의 연장선에 있지만, 개별 작업 조각보다 전체 시스템을 파악하는 감각이 더 두드러진다 [30:06]
• 모델은 프로덕션에서는 다른 처리가 필요하다는 점, 기능 플래그가 켜지지 않으면 동작하지 않는 점, 한쪽 변경이 다른 계약을 바꾸는 점을 장기 세션 안에서 계속 추적한다 [30:30]

17. 채팅 인터페이스의 한계와 새로운 사용 방식

• 메시지를 보내고 답을 받는 기본 구조가 완전히 틀린 것은 아니지만, Fable 5급 모델에는 노트북 중심 사용, 복잡도 전달, 팀 협업이라는 세 가지 축에서 인터페이스 변화가 필요하다 [32:33]
• 작업이 원격 개발 박스에서 계속 돌아가고 사람은 모바일에서 지시만 이어갈 수 있으면, 일이 일어나는 장소와 사람이 대화하는 장소가 분리된다 [32:55]

18. 멀티플레이어 협업과 조직 내 이해 병목

• 한 사람과 여러 Claude가 하나의 큰 작업 단위를 함께 처리하는 구조는 이미 가능하지만, 사고 대응이나 여러 영역이 맞물린 프로젝트에서는 더 넓은 팀 협업 추상화가 필요하다 [34:27]
• 독립적으로 많은 작업을 진행하는 Claude가 누군가의 지시로 시작된 뒤에도 팀의 다른 작업 흐름을 계속 따라갈 수 있어야 하며, 채팅 공유만으로는 그 요구를 충분히 채우기 어렵다 [35:03]

19. 검증 루프와 사람이 져야 하는 책임

• 빠른 개발 루프의 핵심은 아이디어를 가장 좁은 범위에서 반복 검증하는 구조였고, 과거에는 Xcode의 별도 빌드 타깃이나 합성 데이터로 특정 화면만 빠르게 돌리는 방식이 효과적이었다 [36:10]
• Fable이 만든 PR마다 iOS 화면, UI 변경, 에러 상태를 사진이나 영상으로 붙이면 사람이 전체 결과를 빠르게 훑고 예상하지 못한 사용자 경로까지 발견할 수 있다 [36:56]

20. 실제 사용자 흐름과 회귀 테스트의 결합

• 검증은 정적 주입 데이터보다 실제 사용자 흐름을 실행하는 방식으로 옮겨가며, iOS 앱이 스테이징의 실제 계정·데이터로 로그인해 동작하는 환경이 중요해진다 [38:47]
• 8단계 온보딩을 매번 반복하면 테스트 효율이 낮아지므로, 특정 화면의 두 번째 단계만 바로 확인할 수 있는 권한·비밀값·우회 경로가 필요하다 [39:07]

21. 시각·영상 검증과 대체 백엔드의 확장

• 시각 검증은 화면 상태 확인에 효과적이고, 영상 캡처는 스크린샷이 놓치기 쉬운 애니메이션 지연이나 순간적인 끊김까지 드러낸다 [40:00]
• Claude가 자신이 만든 결과 영상을 보고 FFMPEG로 구간을 훑으면, 정적 이미지로는 찾기 어려운 애니메이션 버벅임도 직접 확인해 수정할 수 있다 [40:09]

22. 버그 처리 루프와 운영 판단

• Slack 피드백 채널의 버그는 MCP를 통해 원래 스레드까지 연결할 수 있고, Claude Code 세션은 PR 링크와 수정 상태를 사용자에게 되돌려 피드백 루프를 이어간다 [41:57]
• 수정 PR이 생성된 뒤에도 아직 프로덕션에 반영되지 않았다는 상태를 명확히 남기고, 배포 후 재테스트 요청까지 이어가는 것이 폐쇄 루프의 핵심이다 [42:23]

23. 모델 성능 상승이 여는 창작과 도메인 확장

• 새 모델은 누구나 앱을 만들 수 있는 하한선을 높이는 동시에, 엔지니어나 창업자가 이전에는 어려웠던 복잡한 작업까지 밀어붙일 수 있는 상한선도 높인다 [43:49]
• 브라우저 기반 3D 게임형 무한 도서관 사례처럼, 개인의 아이디어는 게임·시각화·검색 가능한 인터랙티브 경험으로 곧바로 구현될 수 있다 [44:04]

24. 개인 맞춤 소프트웨어와 동적 워크플로

• 모델은 개인에게만 중요한 특수 문제를 해결하는 소프트웨어를 조합할 수 있고, 내부 시스템은 MCP화·권한 구조·배포 구조를 갖출수록 이런 맞춤형 도구를 더 강하게 뒷받침한다 [45:38]
• 늘 갖고 싶었지만 만들기 어려웠던 도구를 직접 구성할 수 있으며, 플랫폼 서비스와 모델의 설정 지원이 결합되면 비전문가도 배포 가능한 시스템에 접근할 수 있다 [45:52]

25. 장기 workflow가 복잡한 Python 프로젝트를 TypeScript/Bun으로 옮긴다

• 내부 Python 프로젝트는 특정 배포 이유로 TypeScript가 필요했고, 이는 과거 Instagram/Facebook 환경의 Hack·PHP 엔진 포팅처럼 예전에는 현실적으로 어렵게 보였던 작업이었다 [48:00]
• 복잡한 코드베이스에 dynamic workflow를 설정해 주말 동안 실행했고, workflow는 전체 동작 이해, 사양에 가까운 구조화, 모듈별 번역, 점진 테스트, 적대적 테스트, 누락 검사를 순서대로 수행했다 [48:23]

26. workflow 설계는 chat에서 시작해 코드 표현과 단계별 실행 UI로 계속된다

• workflow 설계는 Claude Code에 복잡한 작업을 제시하고 실행 계획을 받아보는 데서 시작됐으며, 원하는 검증 수준에 맞춰 누락 기능 확인을 위한 3~4단계 추가 검증이 더해졌다 [50:05]
• workflow는 코드로 표현되어 실행 전 수행 내용을 확인할 수 있었고, 전체 포팅 이후의 후속 질문과 작은 수정도 기존 workflow 위에 쌓는 mini workflow로 처리됐다 [50:23]

🧾 결론

• Fable 5는 “더 똑똑한 챗봇”이라기보다, 긴 시간 축에서 작업을 맡기고 여러 세션을 병렬 운영하며 결과를 검증하는 새로운 업무 시스템의 중심으로 제시된다.
• 중요한 변화는 모델 성능 자체뿐 아니라, 사용자가 일을 쪼개고 설명하고 검토하는 방식이 바뀐다는 점이다. 즉 생산성의 병목은 입력 프롬프트에서 작업 설계와 결과 검증으로 이동한다.
• 비용과 속도가 있는 만큼 Fable 5는 짧고 가벼운 질문보다 복잡한 구현, 장기 워크플로, 높은 맥락 이해가 필요한 작업에 더 적합하다는 메시지가 반복된다.
• 검증이 필요한 내용: 영상에서 언급된 Fable의 벤치마크 수치, 비용 대비 효율, 내부 사례의 일반화 가능성은 발화 기준 요약이며, 실제 성능·가격·도입 효과는 별도 확인이 필요하다.

📈 투자·시사 포인트

• AI 모델 경쟁은 단순 성능 비교를 넘어, 장기 작업 위임, 실행 추적, PR·화면·영상 기반 검증, 팀 협업 인터페이스를 포함한 운영 레이어 경쟁으로 확장될 가능성이 크다.
• 고성능 모델은 비용이 높기 때문에 기업 도입에서는 “많이 쓰게 하는 것”보다 “어떤 작업에 어떤 모델을 배치해야 가장 경제적인가”가 핵심 관리 지표가 될 수 있다.
• 에이전트 네이티브 앱, live preview, diff view, 실제 사용자 흐름 기반 테스트처럼 모델이 만든 결과를 즉시 확인하고 수정하는 폐쇄 루프 도구의 가치가 커질 수 있다.
• 비개발자의 도구 제작 능력이 올라가면 내부 업무 자동화, 개인 맞춤 소프트웨어, 도메인 특화 시뮬레이션·시각화 시장이 넓어질 수 있다.
• 다만 프로덕션 AI는 프롬프트·모델·파라미터 변경에 따른 회귀 위험이 크므로, 관측 가능성, 평가 데이터셋, CI 연동, 실제 흐름 테스트를 제공하는 인프라의 중요성도 함께 커진다.

⚠️ 불확실하거나 확인이 필요한 부분

• 입력 요약만으로는 “Fable 5”가 실제 공개 제품명인지, 영상 내에서 사용된 별칭·가칭인지 외부적으로 확인되지 않습니다.
• Anthropic 내부 사례, DRI 구조, Claude Code 대시보드, internal MCP 활용 사례는 화자의 경험담으로 제시되지만, 조직 전체의 공식 운영 방식으로 일반화하려면 추가 확인이 필요하다.
• Braintrust 관련 내용은 제품 소개 또는 스폰서성 구간일 가능성이 있어, 평가·관측 가능성 도구로서의 성능 주장과 고객사 언급은 별도 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Fable 5급 고성능 모델을 “빠른 질문용”, “장기 위임용”, “설계·검증용”으로 나눠 적용할 내부 작업 분류표를 만든다.
• 장기 에이전트 작업을 맡기기 전에 목적, 제약, 검증 기준, 예상 산출물, 중단·복구 조건을 포함한 사전 브리프 템플릿을 정리한다.
• 모델이 만든 PR이나 산출물을 검토할 때 스크린샷, 영상, diff, 테스트 결과, 미해결 리스크를 함께 확인하는 검증 체크리스트를 만든다.
• 팀 단위로 여러 에이전트 세션을 운영할 때 누가 어떤 작업의 DRI인지, 어떤 작업이 대기·진행·검토 상태인지 추적하는 대시보드 필요성을 검토한다.

❓ 열린 질문

• Fable 5처럼 느리고 비싼 모델은 어떤 기준으로 사용할 때 비용 대비 생산성이 충분하다고 판단할 수 있을까?
• 에이전트가 장시간 작업을 완주하는 환경에서, 사람은 어느 수준까지 세부 구현을 이해해야 PR 병합이나 배포 책임을 질 수 있을까?
• 비개발자가 직접 도구를 만들 수 있는 시대에, 엔지니어와 PM의 역할 경계는 어떻게 재정의되어야 할까?