HydraFusion 라우팅 설계법: single·cascade·critique를 사내 코딩 에이전트에 적용하는 기준

HydraFusion을 단순히 GitHub Copilot의 새 모델로 보면 놓치는 게 많다. 실무에서 더 중요한 건 라우팅 설계다. 사내 코딩 에이전트나 자동 PR 봇을 운영한다면 single, cascade, critique 패턴을 직접 구현하거나 최소한 정책으로 흉내 낼 수 있다. 목표는 모든 요청에 비싼 모델을 쓰지 않으면서도 위험한 변경은 독립 검토를 거치게 만드는 것이다.

먼저 작업을 분류한다

라우팅의 출발점은 모델이 아니라 작업 유형이다. 개발 요청을 난도와 위험도로 분류하지 않으면 어떤 모델을 써도 비용과 실패율을 통제하기 어렵다.

가장 단순한 분류는 세 가지다. Low-risk 작업은 문서 수정, 타입 에러, 작은 UI copy, 테스트 이름 변경처럼 영향 범위가 좁다. Medium-risk 작업은 API 마이그레이션, dependency 업데이트, 작은 리팩터링처럼 테스트로 검증 가능하지만 여러 파일이 바뀔 수 있다. High-risk 작업은 인증·결제·권한·암호화·DB migration·보안 패치처럼 실패 비용이 크다.

이 분류를 issue label, PR template, 명령어 옵션으로 받으면 런타임이 결정을 내리기 쉬워진다. 사람이 ‘중요해 보여요’라고 쓰는 대신 risk:high, requires-review:true, allow-write:false 같은 구조화 신호를 주는 편이 낫다.

single 패턴은 작고 검증 쉬운 작업에 쓴다

Single은 한 모델이 분석, 수정, 설명을 모두 처리하는 방식이다. 비용과 latency가 낮고 사용자 경험이 좋다. 하지만 실패하면 사람이 뒤늦게 잡아야 한다.

따라서 single에는 자동 gate를 꼭 붙여야 한다. 예를 들어 TypeScript 프로젝트라면 npm run typecheck, npm test -- --runInBand, eslint 중 최소 하나를 돌린다. 변경 파일 수가 3개를 넘거나, auth/payment/database 경로가 포함되면 single 결과를 바로 적용하지 않고 cascade 또는 critique로 올린다.

Single의 좋은 기준은 ‘실패해도 revert가 쉽고, 성공 여부가 기계적으로 보이는 작업’이다. README 문구 수정, 경고 제거, 작은 컴포넌트 prop 수정은 적합하다. 반면 권한 조건문 한 줄 수정은 작아 보여도 single로 처리하면 위험하다.

cascade 패턴은 비용 절감용이 아니라 실패 격리용이다

Cascade는 저렴하거나 빠른 모델이 먼저 시도하고, gate를 통과하지 못하면 강한 모델로 escalate한다. 여기서 흔한 실수는 cascade를 비용 절감용으로만 보는 것이다. 실제 효과는 실패를 초기에 격리하는 데 있다.

예를 들어 dependency upgrade 작업을 생각해보자. 빠른 모델이 package 변경과 import 수정까지 처리한다. 이후 테스트가 깨지면 강한 모델이 실패 로그와 diff를 보고 원인을 찾는다. 이렇게 하면 강한 모델이 처음부터 전체 코드를 읽지 않아도 된다.

Cascade gate는 명확해야 한다. 테스트 통과, 빌드 성공, snapshot diff 없음, migration dry-run 성공, bundle size 변화 허용 범위 같은 조건이 좋다. ‘답변이 그럴듯함’은 gate가 아니다. gate가 흐리면 escalation이 너무 잦아지고, 결국 비싼 multi-call만 남는다.

critique 패턴은 독립성과 읽기 전용 권한이 핵심이다

Critique는 초안 모델과 리뷰 모델을 분리한다. 특히 보안·권한·금전·데이터 변경에는 강력하다. 초안 모델은 코드를 수정하고, 리뷰 모델은 diff와 요구사항, 테스트 결과만 읽는다. 리뷰 모델에게 shell이나 edit 권한을 주지 않는 것이 중요하다.

읽기 전용 critique에는 장점이 있다. 첫째, 리뷰 모델이 새 side effect를 만들지 않는다. 둘째, 초안 모델과 다른 계열의 모델을 쓰면 blind spot이 줄어든다. 셋째, 사람 리뷰어에게 넘길 때 ‘무엇을 봐야 하는지’가 더 선명해진다.

Critique 결과는 pass/fail만으로 충분하지 않다. 위험 항목, 재현 절차, 수정 제안, 사람이 확인해야 할 질문을 구조화해야 한다. 예를 들어 blocking, non_blocking, needs_human_decision 세 그룹으로 나누면 자동화와 사람 판단의 경계가 분명해진다.

비용 로그는 leg 단위로 남긴다

Multi-model 라우팅은 비용이 숨어들기 쉽다. 최종 응답 하나만 보면 싸 보이지만, 내부에서 draft, critique, revise, retry, fallback을 여러 번 돌렸을 수 있다. 그래서 비용 로그는 workflow leg 단위로 남겨야 한다.

최소 필드는 task id, route, model, role, input tokens, output tokens, cache hit, latency, exit status, gate result다. 여기에 변경 파일 수, 테스트 결과, 사람이 리뷰한 시간까지 붙이면 라우팅 정책을 개선할 수 있다.

예를 들어 high-risk 작업에서 critique 비용이 늘어도 production incident가 줄면 합리적이다. 반대로 low-risk 작업에서 cascade가 자주 escalation된다면 첫 모델 선택이나 gate 기준이 잘못됐을 가능성이 높다.

사내 적용 순서

처음부터 복잡한 orchestrator를 만들 필요는 없다. 기존 자동화에 routing table부터 붙이면 된다.

1단계는 작업 label과 위험 경로를 정의한다. 2단계는 single 작업에 테스트 gate를 강제한다. 3단계는 실패 로그를 강한 모델에게 넘기는 cascade를 만든다. 4단계는 high-risk diff에 읽기 전용 critique를 붙인다. 5단계는 leg 단위 비용과 성공률을 대시보드로 본다.

이 순서가 좋은 이유는 각 단계가 독립적으로 가치를 내기 때문이다. label만 붙여도 사람이 검토 우선순위를 잡기 쉬워지고, 테스트 gate만 붙여도 실패 PR이 줄어든다. critique는 그 다음이다.

실행 체크리스트

• 작업 label을 low, medium, high risk로 나눈다.
• auth, payment, database, infra, security 경로는 기본 high-risk로 둔다.
• single route에는 최소 1개 이상의 자동 gate를 붙인다.
• cascade escalation 조건은 테스트 실패, 빌드 실패, diff 범위 초과처럼 기계적으로 정의한다.
• critique 모델은 읽기 전용 권한만 가진다.
• 비용·latency·gate 결과를 workflow leg 단위로 저장한다.
• 한 달 뒤 route별 성공률과 재작업 시간을 보고 정책을 조정한다.