Fable 5.2 just dropped. I am speechless...

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5.2에 감탄한 발표자가 제시하는 핵심 활용법은, 간결한 대화로 기획과 작업 명세를 완성한 뒤 더 저렴한 모델에 실행을 맡기는 것이다.

📌 핵심 요점

1. 발표자는 사전 사용 경험을 바탕으로 Fable 5.2의 지능·속도·가격·토큰 효율이 개선됐다고 평가한다. 다만 영상에서 정량 비교 결과를 제시하지는 않는다.
2. 가장 강조하는 장점은 인지 부담 감소다. 복잡한 내용을 짧게 설명하고 선택형 질문으로 다음 결정을 안내해, 사용자가 읽고 판단하는 데 드는 수고를 줄인다는 설명이다.
3. 시연 프로젝트는 하나의 관리자 에이전트가 여러 작업자를 운영하는 개인용 에이전트 하네스다. 모델은 작업자 수보다 사용자의 주의력이 병목이라며, 모든 에이전트를 보여주는 화면보다 짧은 의사결정 대기열을 핵심 기능으로 제안한다.
4. Fable 5.2로 아이디어를 구체화하고 계획을 세운 뒤, Notion에 마일스톤·상태·완료 조건·인수 기준 등을 갖춘 작업 보드를 만든다. 발표자는 이 단계에 높은 지능을 집중할 것을 권한다.
5. 실행 단계에서는 Opus의 medium 설정으로 전환한다. Sonnet도 대안으로 언급하지만, 영상은 구현 착수까지 보여주며 완성된 앱의 품질이나 실제 절감액은 확인하지 않는다.

🧩 배경과 문제 정의

발표자는 Fable 5.2를 사전 사용한 경험을 소개하며, 성능 향상에 대한 감탄을 실제 개발 흐름으로 설명하려 한다. 기존 고성능 모델의 길고 복잡한 답변이 읽기 부담을 만들었다는 문제의식에서 출발해, 간결한 응답과 선택형 질문이 사용자의 인지 부담을 줄인다고 주장한다.

시연 과제는 하나의 관리자 에이전트에게 프로젝트를 전달하면 여러 작업자를 운영해 주는 개인용 에이전트 하네스다. 이 과정에서 ‘많은 에이전트를 어떻게 관리할 것인가’라는 초기 요구는 ‘사용자가 꼭 내려야 하는 결정을 어떻게 줄일 것인가’라는 설계 문제로 구체화된다. 영상은 이 아이디어를 기획하고 작업 보드로 정리한 뒤 실행 모델에 넘기는 과정까지 다룬다.

🕒 시간순 섹션별 상세정리

1. 신모델에 대한 호평과 인지 부담 감소

• 발표자는 Fable 5.2를 매우 높게 평가하며, 성능 설명과 함께 사용량을 아끼는 활용 흐름을 보여주겠다고 예고한다. [00:37]
• 기존 고성능 모델보다 응답이 간결하고 복잡한 내용을 쉽게 설명한다고 평가한다. 이어 속도·가격·토큰 효율도 개선됐다고 주장하지만 수치 비교는 제시하지 않는다. [02:44]
• 핵심 효과로 인지 부담 감소를 꼽는다. 짧은 답변과 선택형 질문 덕분에 같은 일을 더 적은 정신적 노력으로 처리할 수 있다는 설명이다. [03:55]

2. Claude Code에서 에이전트 하네스 기획 시작

• Claude Code 데스크톱 앱에서 시연하며 effort를 high로 설정한다. medium이 권장된다고 언급하면서도 자신의 선택은 더 높은 설정이라고 보여준다. [04:38]
• 작업을 브레인스토밍·계획·실행으로 나누고, Fable 5.2를 앞의 두 단계에 적극 활용하라고 권한다. 처음에는 정교한 명세 대신 대략적인 아이디어를 입력한다. [05:19]
• 하나의 관리자 에이전트가 프로젝트별 작업자를 띄우고, 사용자는 여러 대화 스레드를 직접 관리하지 않아도 되는 하네스를 구상한다. 에이전트·하위 작업 모니터링과 구독 지원도 요구에 포함한다. [05:54]

3. 의도 파악과 선택형 질문으로 요구사항 다듬기

• 발표자는 모델이 요청을 문자 그대로 수행하는 데서 나아가 사용자의 근본적인 의도를 파악하고 더 나은 접근을 제안한다고 평가한다. [07:20]
• 모델은 로컬 앱과 작업자 실행 방식을 제안하고 도구 환경을 확인한다. 발표자는 선택형 질문이 사용자의 다음 결정을 안내해 기획과 조사 부담을 줄인다고 보여준다. [08:45]
• 모델은 병목이 에이전트 수보다 사용자의 주의력이라고 지적한다. 작업자가 늘수록 검토할 결과도 늘어나므로, 핵심 기능으로 짧은 의사결정 대기열을 제안한다. [09:07]

4. 제품 범위 확정과 외부 작업 보드 생성 요청

• 선택형 질문을 통해 첫 대상은 업무 프로젝트, 접점은 웹 앱과 휴대전화, 작업 저장소는 자체 데이터베이스로 좁힌다. [09:32]
• 초기 사용자는 본인으로 정하고, 모델은 요구사항 확정·명세 작성·테스트 준비·구현·개선으로 이어지는 계획을 제시한다. [10:17]
• 발표자는 상세 작업을 새 Notion 보드에 만들어 달라고 요청한다. 연결된 Notion 커넥터를 사용하며, Linear도 작업 추적 도구의 대안으로 언급한다. [11:00]

5. 상세 명세를 만든 뒤 저렴한 실행 모델로 전환

• 발표자는 고성능 모델이 계획과 작업 분해를 충분히 수행하면, Opus나 Sonnet 같은 더 저렴한 모델에 구현을 맡길 수 있다고 보여준다. [11:30]
• Notion에 생성된 작업 보드를 보여주며 마일스톤·상태·완료 조건·인수 기준·작업 크기 등을 확인한다. 발표자는 수백 개의 작업이 만들어졌다고 드러낸다. [11:58]
• 실행 모델을 Opus로 바꾸고 effort를 medium으로 설정한 뒤 작업 시작을 지시한다. Fable로 기획하고 외부 보드에 저장한 다음 저렴한 모델로 실행하는 흐름을 다시 정리한다. [12:50]

6. 후속 구현과 공개 가능성을 남기며 마무리

• 앱의 나머지 구현은 다음 제작 영상에서 이어가겠다고 예고한다. 이번 영상에서는 완성된 앱의 동작 결과를 보여주지 않는다. [12:56]
• 시청자 반응이 충분하면 프로젝트를 오픈소스로 공개할 수 있다고 말하며 의견을 요청한다. [13:04]
• Vibe Coding Academy의 관련 강의와 질의응답 기회를 홍보하고 영상을 마친다. [13:22]

🧾 결론

• 이 영상의 중심은 신모델에 대한 호평과 함께 제시하는 ‘기획에 고성능 모델, 실행에 저렴한 모델’이라는 역할 분담이다.
• 모델의 가치는 답변의 정교함뿐 아니라 사용자가 읽고 선택하고 검토하는 부담을 얼마나 줄이는지로도 평가할 수 있다는 관점이다.
• 상세한 작업 명세와 완료 기준은 모델을 바꿔도 업무 맥락을 이어가기 위한 연결 장치로 제시된다.
• 시연에서 확인되는 결과는 아이디어 구체화, 작업 보드 생성, 실행 모델 전환이며 최종 제품의 완성은 후속 영상으로 남는다.

📈 투자·시사 포인트

• AI 도입 비용을 검토할 때 모델 사용료와 함께 사용자의 독해·판단·검토 시간을 살펴볼 필요가 있다는 시사점을 준다. 영상은 이를 수치로 측정하지 않는다.
• 기획과 실행에 서로 다른 모델을 배치하는 방식은 비용 관리 전략의 후보가 된다. 경제성은 계획 작성 비용과 실행 중 재작업까지 포함해 확인해야 한다.
• 다중 에이전트 제품에서는 작업자 수 확대만큼 사용자의 결정 대기열을 줄이는 설계가 중요할 수 있다. 이는 시연 중 모델이 제안한 제품 방향이다.
• Notion 같은 외부 작업 보드는 계획을 저장하고 실행 모델에 넘기는 수단으로 등장한다. 영상만으로 특정 기업의 실적이나 투자 매력을 판단할 근거는 없다.

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

• ‘역대 최고의 모델’, 속도 향상, 가격 인하, 토큰 효율 개선은 발표자의 주장이다. 비교 조건, 가격표, 사용량 기록, 벤치마크 수치는 제공되지 않는다.
• Fable 5.2 등 제품명과 일부 모델 표기는 제공된 자막을 따른다. 공식 명칭·버전·출시 여부는 이 자료만으로 확정할 수 없다.
• 좋은 계획을 저렴한 모델에 넘겨도 같거나 더 나은 결과를 얻는다는 주장은 최종 구현물 비교로 검증되지 않는다. 영상은 Opus가 작업을 시작하는 단계에서 시연을 마친다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 구현하고 싶은 프로젝트의 목적과 원하는 사용 경험을 먼저 적고, 모델이 제안하는 범위와 선택지를 검토한다.
• 에이전트 수를 늘리기 전에 사용자가 직접 내려야 할 결정과 검토해야 할 산출물이 무엇인지 정리한다.
• 기획 단계에서 작업별 완료 조건·인수 기준·마일스톤을 명시하고, Notion이나 Linear 등 추적 가능한 보드에 저장한다.
• 명세가 정리된 작업을 더 저렴한 모델에 넘겨 보고, 결과 품질과 재작업 여부를 확인한다.

❓ 열린 질문

• 선택형 질문으로 줄어드는 판단 부담은 어느 정도이며, 모델이 제시하지 않은 중요한 선택지는 어떻게 발견할 수 있을까?
• 고성능 모델의 상세 계획이 실행 모델의 재질문과 재작업을 얼마나 줄여줄까?
• 수백 개의 작업으로 세분화한 보드가 실제 프로젝트에서 관리 부담을 줄일까, 새로운 검토 부담을 만들까?