모두가 "어떤 AI 모델이 최고인가"를 논쟁하고 있습니다. 그동안 가장 똑똑한 개발자들은 조용히 선택을 멈췄습니다.

이 워크플로우(workflow)를 보세요: Fable 5 🤝 Composer 2.5 Fast

스크린샷 하나. 다섯 개의 서브에이전트(subagents)가 병렬로 실행됩니다:

→ 과도하게 큰 다목적 파일 찾기
→ 죽은 코드(dead code) 및 미사용 코드 추적
→ TODO 및 스텁(stub) 기능 스캔
→ 중복 및 불일치 감지
→ 테스트 및 데이터 레이어(data layer) 매핑

실제로 일어나고 있는 일과 그것이 중요한 이유는 다음과 같습니다:

Fable 5는 두뇌입니다. Composer 2.5 Fast는 손입니다.

Fable 5는 1M 컨텍스트 윈도우(context window)를 가진 최상단에 위치하여 전체 계획 — 아키텍처(architecture), 의도, "이유" — 를 보유합니다. 그런 다음, 각각 하나의 좁은 작업을 맡아 몇 초 만에 실행하는 빠르고 저렴한 서브에이전트(subagents) 군단에게 단순 반복 작업(grunt work)을 위임합니다.

이것은 아무도 충분히 이야기하지 않는 패턴입니다: 당신의 가장 똑똑한 모델이 모든 것을 할 필요는 없습니다.

죽은 코드를 찾기 위해 프런티어 모델(frontier model)을 사용하는 것은 시니어 아키텍트(senior architect)를 고용해 바닥을 쓸게 하는 것과 같습니다. 비싸고, 느리고, 낭비적입니다. 승리하는 설정은 다음과 같습니다:

🧠 하나의 비싸고 깊은 추론(deep-reasoning) 모델 → 계획, 설계 결정, 결과 검토

⚡ 다수의 저렴하고 빠른 모델 → 스캔, 검색, 요약, 기계적 리팩터링(refactors)

결과는 무엇일까요? 당신이 커피를 마시는 동안 죽은 코드, 중복, 테스트 커버리지, 데이터 레이어 매핑 등 전체 코드베이스 감사(audit)가 병렬로 실행됩니다. 일주일 동안 매달려야 했던 기술 부채(tech-debt) 고고학 작업이 이제는 백그라운드 작업이 되었습니다.

모델 전쟁은 결코 진짜 이야기가 아니었습니다.

오케스트레이션(Orchestration)이 진짜입니다.

2026년에 승리하는 개발자들은 최고의 모델을 가진 사람들이 아닙니다. 그들은 모델들이 함께 작동하게 만드는 방법, 즉 깊은 사고를 하는 모델이 빠른 실행가(executors)의 군단을 지휘하게 만드는 방법을 알아낸 사람들입니다.

단일 모델 워크플로우(Single-model workflows)는 새로운 싱글 스레드(single-threaded) 코드와 같습니다.