아티클
무지성 Fan-out은 그만: Claude Haiku 5.5 기반 4단계 오케스트레이션 아키텍처 실전
Claude Haiku 5.5는 빠르고 저렴하지만, 모든 작업을 무작정 병렬로 던지면 오판, 심사 편향, Supply Chain 리스크만 증폭됩니다. Fable 판단, Opus 조율, Sonnet 및 Haiku 구현, CI 검증, Opus 인수 검사로 이어지는 계층형 아키텍처와 어떤 작업에 Fan-out을 적용해야 하는지 정리했습니다.
· 8분 분량
Claude Haiku 5.5가 2026년 10월 7일에 출시되었습니다. prompt가 100,000 tokens 이내일 때 가격은 Sonnet 5.5의 20분의 1 수준이며, 지연 시간 역시 현세대 Claude 모델 중 가장 빠릅니다.
저렴하고 빠르다 보니 모든 코딩 작업을 잘게 쪼개 여러 Haiku에 병렬로 던져서 끝내고 싶어지기 쉽습니다.
프로토타입 단계에서는 이런 방식도 그럭저럭 돌아갈지 모릅니다. 하지만 실제 프로덕션 엔지니어링 환경에 도입하면 곧바로 세 가지 문제에 부딪히게 됩니다.
- 소형 모델은 모호성을 다루기에 적합하지 않습니다. Haiku 5.5의 공식 포지셔닝은 분류, 추출, 라우팅, subagent처럼 대규모·저지연 작업입니다. 요구사항에 비즈니스 모호성이 남아 있거나 시스템 전반의 컨텍스트가 필요한 상황에서는, 겉보기엔 그럴싸하지만 실제로는 엉뚱하게 짚은 결과물을 내놓기 일쑤입니다.
- 모델에게 답을 고르게 하면 심사 편향이 발생합니다. 수십 개의 산출물을 대형 모델에 넣고 검토하게 하면, 로직과 실행이 정말로 올바른 버전보다는 '겉보기에 구조가 예쁜' 버전을 고르기 쉽습니다.
- 권한 위험은 Worker 수에 비례해 커집니다. 병렬 subagent가 패키지를 자동으로 설치하거나 설정을 수정하도록 허용하면, Worker를 N개 띄우는 순간 악성 패키지가 유입될 수 있는 진입로도 N개로 늘어납니다.
그래서 저는 계층형 오케스트레이션(Hierarchical Orchestration) 방식을 택했습니다. 각 계층이 각자 가장 잘하는 일만 맡고, Haiku의 병렬 처리 능력은 정말로 필요한 곳에만 사용하는 구조입니다.
결론부터 말하자면 다음과 같습니다. Fable이 문제를 명확히 정의하고, Opus가 분배와 인수를 맡고, Sonnet이 핵심 구현을 담당하며, Haiku는 기계적인 작업과 자동 검증이 가능한 탐색형 작업만 수행합니다. 후보 안은 먼저 CI를 거친 뒤 모델에게 전달합니다.
4단계 아키텍처: 판단, 조율, 검증, 인수#
요구사항 입력
│
▼
【판단 계층】Fable: 아키텍처 결정, 작업 분할, 인수 기준
│
▼
【조율 계층】Opus Main Session: 분배만 수행, 재분할 금지
├─► 경로 A: 복잡하지만 경계가 명확함 ──► Sonnet 구현
├─► 경로 B: 기계적인 작업 ──► 단일 Haiku
├─► 경로 C: 탐색형·다양한 해법 ──► 여러 Haiku, 각자 독립된 Git Worktree
│
▼
【검증 계층】Build, Type Check, Test, Benchmark (경로 C는 상위 2–3개만 유지)
│
▼
【인수 계층】Opus가 인수 기준에 따라 취합 및 검수
실패 시 에스컬레이션: Haiku 수정 2회 실패 ➔ Sonnet ➔ Opus로 반환
각 모델을 어느 계층에 배치할지는 공식 포지셔닝과 가격을 기준으로 정했습니다. 아래는 2026년 10월 8일 Anthropic 공식 문서에 명시된 수치이며, 가격 단위는 100만 tokens당 달러($)입니다.
| 모델 |
공식 포지셔닝 |
지연 시간 |
Input / Output 가격 |
| Claude Fable 5.1 |
고난도 추론 및 장시간 agentic 작업 |
비교적 느림 |
$10 / $50 |
| Claude Opus 5.5 |
장시간 agentic coding 및 지식 작업 |
보통 |
$4 / $20 |
| Claude Sonnet 5.5 |
속도와 성능의 최적 밸런스 |
빠름 |
$2 / $10 |
| Claude Haiku 5.5 |
대규모·저지연 분류, 추출, 라우팅 및 subagent 작업 |
가장 빠름 |
$0.10 / $0.50부터 |
Haiku 5.5의 가격은 두 구간으로 나뉩니다. prompt가 100,000 tokens를 초과하면 $0.50 / $2.50로 바뀝니다.
판단 계층: Fable이 아키텍처 결정과 인수 기준을 전담#
모든 요구사항에 Fable이 필요한 것은 아닙니다. 가장 비싸고 가장 느린 계층이므로 요구사항이 모호하거나, 크로스 시스템 연동이 얽혀 있거나, 핵심 아키텍처 결정을 내려야 할 때만 투입합니다.
Fable이 산출해야 하는 결과물은 세 가지입니다.
- 솔루션 설계
- 작업 분할
- 각 하위 작업을 테스트로 검증할 수 있는 인수 기준(Acceptance Criteria)
추론과 분할은 반드시 동일한 계층에서 완결되어야 합니다. 시스템의 맹점을 끝까지 파악할 수 있는 계층이어야만 경계가 깔끔한 하위 작업을 나눌 수 있기 때문입니다. 아키텍처는 A에게 맡기고 분할은 B에게 맡기면 대개 인터페이스 정의가 모호해집니다.
보안 작업은 예외입니다. 현세대 Claude 모델들에는 안전 분류기가 적용되어 있어, 요청이 차단되면 stop_reason: "refusal"을 반환하며 정당한 보안 작업조차 오탐으로 차단될 수 있습니다. Fable 5.1의 분류기는 보안 관련 내용을 광범위하게 다루고 있어 공식적으로도 보안 도메인용으로 설계된 것이 아니라고 안내되어 있습니다. 반면 Opus 5.5는 소스 코드 내 취약점 탐색을 허용합니다. 따라서 보안 취약점 패치 같은 요구사항의 프론트엔드 분석은 곧바로 Opus에 맡깁니다.
조율 계층: Opus는 분배만, 재분할은 하지 않는다#
Opus는 Main Session으로서 라우팅과 작업 할당을 책임집니다. 이 계층에서는 아키텍처를 뒤엎지 않으며, 2차 분할도 진행하지 않습니다.
- 경로 A, 복잡하지만 경계가 명확한 작업: 로직은 복잡하지만 인터페이스 경계가 이미 명확히 정의된 작업은 Sonnet에 넘깁니다. 실질적인 구현의 주력입니다.
- 경로 B, 단순한 기계적 작업: 보일러플레이트(Boilerplate) 코드, 변수명 변경, 단순 단위 테스트 추가, 문서 보강 등은 단일 Haiku에 맡겨 처리합니다.
- 경로 C, 탐색형 및 최적화 작업: 성능 튜닝, 복잡한 SQL이나 Regex의 다양한 작성 방식, Flaky Test 트러블슈팅 등에서만 비로소 Fan-out을 실행합니다. 여러 Haiku를 투입해 각자 독립된 Git Worktree에서 서로 다른 해결책을 시도하게 합니다.
어느 경로를 거치든 결과물은 반드시 검증 계층으로 들어가야 합니다.
검증 계층: 기계가 먼저, 모델은 나중에#
병렬로 생성된 코드를 전부 Opus나 Sonnet에 넘겨 prompt로 리뷰하게 만드는 방식을 흔히 볼 수 있습니다.
문제는 모델이 코드를 읽을 때 서식이 깔끔하고 타입 선언이 온전한 답변에 쉽게 매료된다는 점입니다. 하지만 그렇다고 해서 엣지 케이스 테스트까지 통과했다는 뜻은 아닙니다. 따라서 후보 안은 반드시 기계적인 검증 관문부터 통과해야 합니다.
- Build 및 Type Check: 컴파일이 정상적으로 되고 타입이 올바른지
- Unit / Integration Tests: 단위 테스트 및 통합 테스트 통과 여부
- Benchmark / Profiling: 성능 및 메모리 측정
자동화 테스트를 통과하지 못한 코드는 즉시 탈락시킵니다. 경로 C의 후보 안 중에서도 Opus는 검사를 통과하고 지표가 가장 우수한 상위 2–3개만 확인하므로, context window와 token도 아낄 수 있습니다.
인수 계층: Opus의 수렴, 실패 시 상위로 에스컬레이션#
마지막으로 Opus가 판단 계층에서 정의한 인수 기준에 따라 결과를 취합하고 검수합니다. Worker 작업이 막히면 순서대로 에스컬레이션 경로(Escalation Path)를 밟습니다.
- Haiku가 실패하고 자동 수정을 2회 시도해도 통과하지 못하면 재시도를 중단합니다.
- Sonnet이 이어받아 수정을 진행합니다.
- Sonnet마저 인수를 통과하지 못한다면, 대개 작업 분할이나 사전 전제에 모순이 있다는 뜻입니다. 작업을 Opus로 반환하고, Opus가 Fable로 돌려보내 다시 쪼갤지 판단합니다.
프로덕션 도입 전 지켜야 할 세 가지 원칙#
맹목적인 Fan-out은 피할 것#
단순한 작업에는 여러 Worker가 필요 없고, 모호성이 높은 작업은 소형 모델이 풀어내지 못합니다. '해법 공간(Solution Space)이 넓고' 동시에 '자동화 테스트로 빠르게 검증할 수 있는' 탐색형 작업이어야만 여러 Haiku를 병렬로 돌릴 가치가 있습니다.
환경을 격리하고, Lockfile은 잠글 것#
Git Worktree가 격리하는 것은 코드 변경 사항일 뿐이며, 병렬 Worker끼리 파일을 덮어쓰지 않게 해줄 뿐입니다. 네트워크 접근이나 프로그램의 리소스 접근 범위까지 제한하지는 못합니다. Supply Chain Attack을 방어하려면 sandbox가 추가로 필요하며, Worker가 검증되지 않은 패키지를 임의로 설치하거나 Lockfile을 수정하지 못하도록 막아야 합니다. 설치 권한을 무분별하게 열어두는 것은 Agent가 출처 불명의 패키지와 스크립트를 코드베이스에 끌고 들어오도록 방치하는 것과 같습니다.
모델의 평가 문구가 아닌 측정 데이터로 인수할 것#
테스트 결과, 커버리지, 메모리 사용량, 지연 시간만이 재현 가능하고 비교할 수 있는 근거입니다. 모델이 텍스트로 남긴 코멘트는 참고용일 뿐, 코드 품질을 최종 인수하는 잣대로 삼아서는 안 됩니다.
저렴한 모델은 올바른 자리에 써야 한다#
Haiku 5.5 덕분에 병렬 처리가 저렴해졌지만, 병렬 처리 그 자체가 결과의 정합성을 보장해 주지는 않습니다. 판단, 분배, 검증, 인수를 먼저 명확히 분리해야만 저렴함과 빠름이 비로소 진짜 강점이 됩니다.
이러한 계층 구조는 제가 AI Agent는 그 자체로 하나의 애자일 팀이다에서 설명했던 Graph와 본질적으로 같습니다. 누가 먼저 시작하고, 작업이 끝나면 누구에게 넘기며, 문제가 생기면 누구에게 전달할 것인가의 문제입니다.