Nate HerkMORNING DIGEST · 2026-09-05 · Nate Herk🎬 영상
Fable 5.1과 Fable 5에 같은 앱을 맡겼더니 품질은 비슷한데 비용은 2.4배 갈렸다
Nate Herk가 동일 프롬프트로 두 모델에 인시던트 대응 워크플로 앱을 위임 개발시켜 비용·품질·속도를 직접 비교했다.
01핵심 개요
- Fable 5.1은 1,200달러·36시간, Fable 5는 500달러·훨씬 짧은 시간으로 동일한 "OpsFlow" 앱을 완성.
- Codex 블라인드 심사 결과 가중 점수는 5.1이 9.1점, 5가 8.4점으로 근소 우세.
- Fable 5.1은 Opus 57%+Sonnet 40%, Fable 5는 Sonnet 80% 중심으로 워커를 배분해 비용 격차 발생.
- 두 앱은 워크플로 JSON 임포트 스키마조차 서로 호환되지 않을 만큼 설계가 갈렸다.
- 저자 결론: "700달러를 더 낼 가치가 있는 차이는 아니다" — 이번 과제 한정으로 Fable 5 승리 판정.
02핵심 주장 / 논점 구조
- 실험 설계: 동일한 빅골 프롬프트("you are Fable 5.1/5, work inside this folder"만 차이)를 두 에이전트에 각각 부여.
- 에이전트에게 요구한 역할은 직접 구현이 아니라 오케스트레이션 — 전략·계획·위임·시퀀싱·품질기준·최종 승인만 담당하고, 엔지니어링·디버깅·테스트·비주얼 디자인은 워커에게 위임하도록 명시.
- 워커 배정 원칙: 아키텍처/제품·디자인 방향/난제·독립 리뷰는 Opus, 구현/리서치/테스트/디버깅/반복은 Sonnet 우선 사용.
- "그럴듯한 구현"에서 멈추지 말고 "완전히 작동하고 발표 가능한 수준"이라는 객관적 증거가 나올 때까지 오케스트레이션을 지속하라는 완결성 기준을 부여.
- 저자의 핵심 반문: 같은 예산(약 519달러)으로 두 모델을 맞췄다면 Fable 5.1이 이 정도 품질을 냈을지 의문 — 비용 정규화 없이 품질만 비교하는 것은 불공정하다는 문제의식.
03빌드 대상: OpsFlow란 무엇인가
- OpsFlow는 n8n 같은 워크플로 자동화 플랫폼이 아니라, "프로덕션이 터졌을 때 무엇을 할지"를 시각적으로 그리고 리허설하는 로컬 우선 도구.
- 트리거·조건·액션·승인·해결(resolution) 노드를 캔버스에 드래그해 인시던트 대응 플로우차트를 구성.
- Run 버튼으로 시뮬레이션을 실행하면 각 노드가 실시간으로 처리되는 과정과 건너뛴 분기, 실행된 분기, 최종 해결 방식(예: "롤백으로 완화됨")을 시각적으로 확인 가능.
- 승인 대기 노드에서 실제로 승인/거부를 선택하면 이후 분기가 달라지는 상호작용까지 구현됨.
04UI/UX 비교
| 항목 | Fable 5.1 | Fable 5 |
|---|
| 카드 디자인 | 둥근 모서리·색상 크롭 카드로 "AI가 만든 티"가 남 | 상대적으로 더 깔끔하고 튀지 않음 |
| 확대/축소 시 텍스트 | 일정한 크기 유지 | 확대할수록 텍스트가 커져 저렴해 보임 |
| 트리거 연결 제약 | 여러 개 연결 가능 | 트리거 1개당 연결 1개만 허용(초과 시 "connection refused" 에러) |
| 노드 확장/줌 | 결과 패널 확장 시 아쉬움 있음 | 결과 패널을 끌어서 확장 가능, 라이트모드 지원 |
| 거부(reject) 처리 | 정지 처리 | 초기 버전에서 거부해도 true 경로로 계속 진행하는 버그 발견, payload를 "minor degradation"으로 바꾸자 false 분기로 정상 작동 |
| 워크플로 JSON 스키마 | 서로 호환 불가 | 서로 호환 불가 |
05비용·리소스 구조 비교
| 항목 | Fable 5.1 | Fable 5 |
|---|
| 총 비용 | 약 1,200달러 | 약 500달러 |
| 소요 시간 | 약 36시간(하루 반) | 훨씬 짧음(약 반나절) |
| 모델 배분 | Opus 57% / Sonnet 40% / 자체 3% | Sonnet 80% 중심 |
| 컨텍스트 윈도우 사용률 | 약 40%(404,000 토큰) | 약 26%(260,000 토큰) |
| Codex 블라인드 평가 가중 점수 | 9.1 | 8.4 |
06전략적 의미
- 오케스트레이터형 에이전트에게 "위임 원칙"만 주면, 어떤 모델을 오케스트레이터로 쓰느냐에 따라 하위 워커 배분 전략이 크게 달라진다 — Fable 5.1은 고비용 Opus에 더 의존, Fable 5는 저비용 Sonnet에 더 의존.
- 품질 차이(9.1 vs 8.4, 0.7점)에 비해 비용 차이(2.4배, 700달러)가 지나치게 크다는 점은 "모델 성능"과 "비용 대비 효율"이 별개 지표임을 보여줌.
- 저자는 일상적 지식 노동에서는 Fable 5.1이 의도 파악에 더 뛰어나다고 밝혀, "이번 과제 한정 결론"과 "전반적 모델 선호"를 분리해서 봐야 한다고 강조.
- 동일 프롬프트라도 위임형 워크플로에서는 결과물의 스키마·UX 디테일까지 크게 갈릴 수 있어, 재현성·예측가능성 측면에서 오케스트레이션 방식의 한계를 시사.
07활용 시나리오
- 인시던트 대응 플레이북을 시각적으로 설계하고 사전에 리허설하려는 SRE/DevOps 팀에게 OpsFlow류 도구가 유용.
- AI 코딩 에이전트에게 대규모 앱을 통째로 맡기기 전에, 동일 프롬프트·다른 모델로 저비용 파일럿을 돌려 비용 대비 품질을 먼저 검증하는 전략.
- 오케스트레이터-워커 구조를 설계할 때 Opus/Sonnet 비중을 명시적으로 지정해 비용을 통제하는 프롬프트 설계 참고 사례.
08현황 및 전망
- Fable 5.1과 Fable 5는 같은 제품군 내에서도 비용·속도·워커 배분 전략이 뚜렷이 다른 별개의 모델로 자리매김하고 있음을 보여주는 사례.
- 저자는 별도 영상에서 Fable 5.1로 프리미엄 애니메이션이 들어간 웹사이트(Amation Society 사이트, 개인 사이트 등)를 디자인한 경험을 소개하며, 웹디자인 작업에는 5.1을 계속 활용 중이라고 언급.
- 장시간·고비용 오케스트레이션 실험이 늘어나면서, "완결성 게이트(정의된 완료 기준)"를 명시하는 프롬프트 설계가 에이전트 품질 검증의 표준으로 자리잡는 흐름.
09용어 사전
- OpsFlow: 인시던트 대응 워크플로를 시각적으로 설계·시뮬레이션하는 로컬 우선 자동화 스튜디오(영상 속 데모 앱명).
- 오케스트레이터 프롬프트: 에이전트에게 직접 구현 대신 전략·위임·품질기준·최종 승인만 맡기는 상위 역할 지시.
- Opus/Sonnet 워커: 각각 고난도 아키텍처·디자인·리뷰용, 구현·테스트·디버깅용으로 구분해 배정하는 하위 실행 모델.
- 컨텍스트 윈도우 사용률: 에이전트 세션이 전체 허용 토큰 중 실제 사용한 비율(5.1은 40%, 5는 26%).
- 완결성 게이트: "그럴듯한 구현"이 아니라 "객관적 증거로 검증된 완전 작동"을 완료 기준으로 못 박는 프롬프트 조항.