Fable 5에게 타이핑을 시키지 마라: 미첼 하시모토의 59% 비용 절감 분업 워크플로우

 

Fable 5의 성능은 상당하다...!

그러나 복잡한 개발 작업을 처음부터 끝까지 맡기는 방식은 치명적인 단점이 존재한다.

바로 막대한 비용과 느린 속도다.

 

모든 과정을 최고 사양 모델로 구동하면 단 한 번의 작업 흐름에 50달러가 넘는 비용이 청구되기도 한다.

이 문제를 해결하기 위해 터미널 애플리케이션 Ghostty의 제작자이자 HashiCorp의 창업자인 미첼 하시모토(Mitchell Hashimoto)가 AI 활용법을 공개했다. 핵심은 간단하다.

 

가장 똑똑한 거인의 어깨에 올라타되,

역할표를 영리하게 짜서 좋은 과실만 체리피킹하는 것이다.

 

이 글에서는 계획, 코딩, 심판을 분리하여 품질을 유지하면서도 비용을 59% 이상 절감한 AI 워크플로우를 분석한다.

 

---

1. 하시모토의 3단계 AI 분업 아키텍처

하시모토가 정립한 작업 흐름은 모델의 체급과 특성에 따라 역할을 명확히 나누는 3단계 구조를 가진다.

[1단계: 계획] Fable 5 (설계자) -> 구체적인 수정 계획 수립
       ↓ (복사 & 붙여넣기)
[2단계: 구현] GPT 5.5 (코더) -> 신속하고 저렴한 코드 작성
       ↓ (복사 & 붙여넣기)
[3단계: 검증] Fable 5 (심판) -> 최종 코드 품질 및 예외 처리 검사

---

1단계: 계획과 설계 (Planner/Architect)

• 담당 모델: Fable 5 (xhigh)
• 역할: 프로젝트의 전체적인 아키텍처를 분석하고 설계도를 그린다. 단순히 "코드를 고쳐라"가 아니라, 어떤 파일의 몇 번째 줄을 어떻게 수정해야 하는지까지 극도로 구체적인 계획을 수립하도록 명령한다.

2단계: 코딩과 구현 (Coder)

• 담당 모델: GPT 5.5 (xhigh, 구독 요금제)
• 역할: Fable 5가 작성한 구체적인 설계도를 전달받아 실제 소스 코드를 타이핑한다. 이미 명확한 가이드라인이 주어졌기 때문에, 구현 속도가 빠르고 비용이 저렴한 모델이 이 역할을 맡는다.

3단계: 심판과 검사 (Judge/Reviewer)

• 담당 모델: Fable 5 (xhigh)
• 역할: GPT 5.5가 생산한 결과물을 다시 넘겨받아 최종 검수를 진행한다. 구현 과정에서 누락된 로직이나 잠재적 결함이 없는지 까다롭게 따진다.

---

2. 감이 아닌 데이터로 증명된 모델별 가성비

이러한 모델 배치는 단순한 직관에서 나온 것이 아니다.

 

하시모토는 동일한 기능 구현 작업을 세 가지 최신 모델(Fable 5, GPT 5.5, GLM-5.1)에 각각 독립적으로 시키는 사전 실험을 거쳤다. 결과물의 품질은 세 모델 모두 합격점이었으나, 속도와 API 비용에서 거대한 격차가 발생했다.

모델명	수행 시간	소요 비용	특징
GLM-5.1	몇 분 내외	1달러 미만	뛰어난 가성비와 빠른 속도
GPT 5.5	몇 분 내외	약 1.5달러	신속한 구현력과 안정적인 코드 생산
Fable 5	40분	9달러	극도로 정밀하지만 느리고 무거움

Fable 5는 일상적인 코딩 작업을 맡기기에는 지나치게 느리고 비싸다.

그러나 복잡한 컨텍스트를 분석하고 논리적 오류를 잡아내는 능력은 압도적이다.

 

따라서 Fable 5는 정밀한 판단이 필요한 '계획'과 '심판' 단계에만 아껴 쓰고, 실제 타이핑은 가성비와 속도가 우수한 GPT 5.5에게 맡기는 전략이 탄생했다. 이 조합을 사용할 경우 전체 비용은 단 몇 달러 수준으로 떨어진다.

---

3. 실험으로 검증된 59%의 비용 절감 효과

이러한 분업 구조의 효율성은 타 개발 팀의 데이터로도 증명되었다.

 

Kilo 팀이 진행한 교차 검증 실험에 따르면, Fable 5와 GPT-5.5에게 동일한 서비스 개발 계획을 세우게 한 뒤 점수를 매겼을 때 Fable 5가 9.1점, GPT-5.5가 8.3점을 기록했다. 기획과 설계 단계에서는 확실한 체급 차이가 존재한다.

Claude Fable 5 vs GPT-5.5: better planning, similar execution

그러나 이긴 계획서(Fable 5가 작성한 문서)를 바탕으로 두 모델에게 구현을 시켰을 때는 반전이 일어났다. 두 모델 모두 15개의 인수 테스트를 완벽하게 통과했다.

구체적인 이정표와 설계도가 문서 형태로 명확히 고정되고 나면, 실제 코드를 구현하는 단계에서는 모델 간의 최종 결과물 격차가 사라진다.

이 방식을 적용해 계획은 Fable, 구현은 GPT로 나누어 실행한 결과, 모든 과정을 Fable로만 돌릴 때(16.66달러)보다 비용이 59% 저렴한 6.3달러까지 절감되었다.

---

4. 실무 적용을 위한 프롬프트와 단서들

심판 에이전트의 단순한 프롬프트

하시모토가 활용한 심판 에이전트의 시스템 프롬프트는 거창하지 않다. 한 문단이면 충분하다.

"이 브랜치의 변경사항을 보고 품질을 평가하라. 처리되지 않은 엣지케이스 및 명백히 나쁜 성능 결정을 찾아라."

---

데이터 이동과 최종 최종 지표

모델 간에 계획서와 코드를 어떻게 넘기냐는 질문에 하시모토는 단순하게 "Copy and Paste"라고 답했다.

정교한 서브에이전트 시스템을 구축하는 것보다 단순한 복사 작업이 실험 단계에서는 더 빠르기 때문이다.

 

또한, 이 자동화 흐름의 최종 성공 여부를 측정하는 지표는 결국 인간의 눈이다.

하시모토는 "코드를 직접 읽는다(I read the code)"라고 단언한다.

 

최종 판단의 종착지에는 여전히 사람이 앉아 검증해야 한다.

---

인터페이스 설계의 주의점

개발자 테오(Theo)는 이 워크플로우를 적용할 때 주의할 점을 덧붙였다.

 

API와 인터페이스 정의만큼은 반드시 Fable이 직접 수행하도록 통제해야 한다는 것이다.

GPT 5.5는 모든 코드를 파이썬 스타일로 짜려는 고유 버릇이 있기 때문에 구조적 뼈대는 상위 모델이 쥐고 있어야 안전하다고 한다.

---

5. 하루 만에 표준 기능으로 흡수된 워크플로우

하시모토의 이 개인적인 복사 붙여넣기 실험은 공개된 지 채 하루도 지나지 않아 오픈소스 에이전트 개발 환경인 Orca의 내장 오케스트레이션 기능으로 흡수되었다. 이제 개발자들은 프롬프트 세 줄로 이 강력한 삼각 분업 체제를 구동한다.

Fable xhigh as a planner/architect
GPT 5.5 xhigh as coder
Fable xhigh as judge/reviewer

개인의 영리한 워크플로우가 단 24시간 만에 자동화 파이프라인으로 자리 잡은 것이다.

GitHub - stablyai/orca: Orca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscrip

---

마치며: 성과를 가르는 것은 모델이 아니라 '역할표'다

하시모토가 더 비싸고 좋은 모델을 새로 구입한 것이 아니다.

이미 시장에 존재하는 모델들을 그대로 두고 오직 '배치'만 바꿨다.

누구에게 설계를 시키고, 누구에게 타이핑을 시키고, 누구에게 검사를 맡길지 배분했을 뿐이다.

 

모델은 이미 차고 넘칠 정도로 똑똑하다.

최상위 모델의 핵심 가치는 기계적인 타이핑 능력이 아니라 정밀한 분석과 판단력에 있다.

 

프롬프트를 고도화하는 기술을 넘어,

적재적소에 모델을 배치하는 '역할 설계 능력'이야말로 비용을 아끼고 생산성을 극대화하는 현대 개발자의 새로운 무기다.

X의 Mitchell Hashimoto님(@mitchellh)

---

Fable 5 범용 프롬프트 템플릿

1. 기본 골격 (모든 모드 공통)

## 역할
[Fable5가 이번에 맡을 역할: 기획자 / 구현자 / 검증자 중 하나를 명시]

## 목표
[한 문장으로 최종 산출물이 뭔지 — "제안만" vs "구현까지" 를 반드시 구분]

## 범위
[건드려도 되는 파일/폴더/시스템을 구체적으로 나열. "전체 봐줘" 금지 — 
 Fable5는 범위를 넓게 줄수록 이득을 보는 모델이라 애매하게 좁히면 오히려 손해]

## 이미 아는 사실 / 가설
[선행 조사·과거 결정·알려진 이슈를 먼저 주입. 처음부터 재발견하게 하지 말 것]

## 제약
[건드리면 안 되는 것, 하위호환성, 의존성 추가 금지 등]

## 산출물 형식
[표/체크리스트/코드 diff 등 원하는 최종 형태를 미리 지정]

---

2. 모드별 변형

A. 기획자(Planner) 모드 — 구현은 다른 모델에게 넘길 계획일 때

Fable5에게: 이 작업을 구현하기 전에 계획/스펙만 작성해줘. 
- 왜/무엇을/어떻게를 구분해서 정리
- 엣지케이스와 리스크를 먼저 찾아줘
- 이 계획은 다른(더 저렴한) 모델이 구현할 거니까, 
  그 모델이 오해 없이 따라갈 수 있는 수준까지 구체적으로 적어줘

→ Hashimoto 워크플로우의 1단계와 동일한 역할. Fable5는 여기서 비용 대비 효율이 가장 좋음(9.1점 vs 다른 모델 8.3점 — 기획 품질 격차가 실제로 존재).

---

B. 검증자(Judge) 모드 — 다른 모델이 짠 코드/문서를 채점할 때

Fable5에게: 아래는 [모델명]이 만든 결과물이야. 
- 원래 요구사항/인수 조건과 대조해서 빠짐없이 체크해줘
- 통과/실패만 말하지 말고, 실패라면 구체적으로 어느 줄이 왜 틀렸는지
- 통과했다면 "왜 통과로 판단했는지" 근거를 남겨줘 (나중에 재검토 가능하게)

→ 3단계 중 마지막 단계. 저렴한 모델의 결과물이 실제로 기준을 만족하는지 재확인하는 용도.

---

C. 단독 실행(Full Execution) 모드 — Fable5 혼자 처음부터 끝까지 시킬 때

Fable5에게: 이 작업을 계획부터 구현, 테스트까지 전부 진행해줘.
- 진행하다가 방향을 바꿔야 하면 이유와 함께 알려주고 계속 진행해
- 중간 산출물(계획, 변경 파일 목록)을 단계마다 남겨줘

→ 이건 A+B를 다른 모델 없이 Fable5 혼자 다 하는 경우라 가장 비쌈. 작업이 진짜로 길고 복잡해서 "격차가 벌어지는" 영역(멀티파일 리팩토링, 장시간 자율작업)일 때만 쓰는 게 맞고, 단순 구현이면 B안처럼 검증만 Fable5에게 맡기고 구현은 다른 모델에 넘기는 게 비용상 유리