서브에이전트 모델 티어링: 위임까지 최상위 모델일 필요는 없습니다

메인 에이전트를 가장 비싸고 강한 모델로 올려둔 어느 날이었습니다. 로그 몇 줄을 요약하는 사소한 서브에이전트 하나를 띄웠는데, 그 작은 작업까지 최상위 모델이 처리하고 있다는 것을 뒤늦게 알아차렸습니다. 파일 목록을 추출하는 단순한 맵 작업도 마찬가지였습니다.

곰곰이 생각해보니, 여러 서브에이전트가 함께 도는 멀티에이전트 하네스에서는 메인을 센 모델로 켜는 순간 거기서 갈라져 나가는 모든 위임이 아무 의심 없이 그 모델을 물려받고 있었습니다. 강한 모델이 알아서 잘 해주니 처음엔 문제라는 생각조차 들지 않았습니다. 다만 이 상속이 정말 당연한 것인지, 한 번쯤 멈춰 서서 따져볼 필요가 있다는 생각이 들었습니다.

메인이 최상위 모델이면, 서브에이전트 위임도 최상위를 상속합니다

문제를 처음 실감한 것은 청구서를 들여다보고 나서였습니다. 로그 요약이나 파일 목록 추출처럼 기계적인 일에까지 최상위 모델을 쓰는 것이 얼마나 큰 낭비인지, 숫자로 보고서야 체감했습니다. 이런 작업은 오류가 나더라도 다음 단계가 금방 잡아주는 종류인데도 말입니다.

그렇다면 반대로, 모든 서브에이전트를 값싼 모델로 내려버리면 되지 않을까. 잠깐 그런 생각도 했습니다. 하지만 그것은 더 위험한 선택이었습니다. 코드 리뷰나 보안 감사, 데이터베이스 결정처럼 판단의 정확도가 결과를 좌우하는 작업까지 싼 모델로 내리면, 눈에 잘 띄지 않는 곳에서 품질이 조용히 무너지기 때문입니다.

결국 깨달은 것은 이것이었습니다. "무지성 상속"도 "무지성 다운그레이드"도 답이 아니라는 것. 양극단이 다 틀렸습니다. 작업 하나하나에 대해, 그 일이 요구하는 최저 충분 티어를 골라야 했습니다. 너무 세지도 너무 약하지도 않은, 딱 그 작업을 감당할 만큼의 티어 말입니다.

두 개의 레버 — 정적 기본값과 동적 보정

서브에이전트의 모델 티어를 조절하는 레버는 두 가지였습니다. 저는 Claude Code로 구현했지만, 서브에이전트를 굴리는 환경이라면 대개 이와 비슷한 두 개의 손잡이를 갖고 있을 것입니다.

첫 번째는 정적 기본값입니다. 에이전트 정의 파일의 frontmatter에 model: 필드를 박아두면, 그 에이전트를 부를 때마다 그 값이 적용됩니다. 유효값은 haiku / sonnet / opus / fable / inherit 또는 풀 모델 ID입니다. 중요한 것은, 이 필드를 생략하면 inherit, 즉 메인 세션 모델을 그대로 상속하는 것이 기본 동작이라는 점입니다. 앞에서 겪은 함정이 바로 이 기본 동작 때문이었습니다. 추론 강도를 조절하는 effort 필드(low~max)도 함께 지정할 수 있습니다.

---
name: web-researcher
model: sonnet   # 하류에 교차 검증이 있으니 sonnet 으로 충분
effort: low
---

두 번째는 동적 보정입니다. 에이전트를 호출하는 그 순간에 model 파라미터를 넘기면, 이번 한 번의 호출에 한해 기본값을 덮어씁니다. 평소엔 opus로 충분한 구현 에이전트라도 이번 작업이 유독 미묘한 디버깅을 요구한다면, 그 순간만 더 센 모델로 올리는 식입니다. 반대로 단순한 boilerplate 작업이라면 그 순간만 내릴 수도 있습니다.

이 둘 사이에는 명확한 우선순위가 있습니다. 위에 있는 것이 아래를 이깁니다.

우선순위	레버	비고
1 (가장 강함)	CLAUDE_CODE_SUBAGENT_MODEL 환경변수	전역 강제. 잘 쓰지 않음 — 위임 모델이 이상하면 이 잔존부터 의심
2	호출 시 model 파라미터	이번 호출만 덮어쓰는 동적 보정
3	에이전트 frontmatter model:	에이전트별 정적 기본값
4 (최종 fallback)	메인 세션 모델	아무것도 지정하지 않으면 이것을 상속

설계 원칙은 분명했습니다. 정적 기본값이 단일 진실 공급원이고, 동적 보정은 어디까지나 예외적인 보정용이라는 것. 티어 표를 여기저기 복제해두면 언젠가 서로 어긋나기 마련이라, 에이전트별 기본값은 frontmatter 한 곳에만 두기로 했습니다. 만약 위임 모델이 이상하게 동작한다면, 가장 먼저 의심해야 할 것은 맨 위의 환경변수가 어딘가에 잔존해 전역으로 강제하고 있지는 않은지입니다.

티어 판정은 난이도가 아니라 "틀렸을 때 누가 잡아주는가"로

레버를 알았으니, 이제 어떤 작업에 어떤 티어를 줄지 정해야 했습니다. 애석하게도 여기서 오래 헤맸습니다. 처음엔 "이 작업이 얼마나 어려운가"를 기준으로 삼았는데, 자꾸 어긋났습니다. 어려워 보이는 작업이 사실은 싼 모델로 충분한 경우가 있었고, 쉬워 보이는 작업이 최상위를 요구하는 경우도 있었습니다.

곰곰이 생각한 끝에, 판정 질문을 딱 하나로 좁혔습니다.

"이 단계 출력의 오류가 하류 검증(테스트 실행·코드 리뷰·머지 게이트·사용자 확인) 없이 최종 결과에 조용히 들어가는가?" Yes라면 상위 티어로. No라면 하위 티어로 내려도 안전합니다.

이 질문으로 다시 보니, 티어를 가르는 기준은 작업의 난이도가 아니었습니다. "틀렸을 때 누가 잡아주는가"였습니다. 뒤에 검증이 촘촘히 서 있는 작업이라면 좀 틀려도 괜찮으니 싼 모델로 내려도 되고, 뒤에 아무도 없는 작업이라면 반드시 세게 가야 했습니다. 이 관점으로 정리한 티어 앵커는 다음과 같습니다.

티어	작업 성격	예시
haiku (최저)	기계적 추출·포맷·단순 상태 확인. 오류가 재시도·검증으로 싸게 잡힘	대량 fan-out 맵 단계, 로그 요약
sonnet	표준 전문작업 — 수집 리서치, 테스트 작성·실행, 데이터 분석, 리포트 생성	웹 리서처, 유닛 테스트 작성, 런타임 준비
opus	설계·기획 문서·복잡한 구현 (단, 하류에 코드 리뷰 루프 같은 검증이 있을 때)	백엔드 구현, IA·PRD 설계, 전달 문서
inherit (세션 모델·최상위)	리뷰·검증 게이트·아키텍처·보안·DB 판단·미묘한 디버깅. 오류가 하류 검증 없이 최종 결과를 오염	코드 리뷰어, 머지 게이트, DBA, 데이터 검증기

리뷰어를 싸게 돌리면 안 되는 이유

이 프레임으로 보면 몇 가지 반직관적인 결론이 따라 나옵니다. 사실 이 글에서 가장 하고 싶은 이야기입니다.

먼저, 리뷰어와 머지 게이트, 데이터베이스 판단은 다운그레이드해서는 안 됩니다. 이들이 false-pass, 즉 틀린 것을 통과시키는 실수를 하면, 그 뒤에는 그것을 걸러줄 단계가 없습니다. 이들 자신이 품질 체인의 마지막 문지기이기 때문입니다. 앞 단계의 오류는 리뷰어가 잡아주지만, 리뷰어의 오류는 아무도 잡아주지 못합니다. 그래서 문지기 자리에서 아낀 비용은, 아낀 것이 아니라 나중에 조용히 청구되는 부채에 가깝습니다.

두 번째로, "구현이니까 opus"처럼 반사적으로 티어를 정하는 습관을 경계해야 합니다. 구현 에이전트를 opus로 두는 것이 정당한 이유는 "구현이 어려워서"가 아닙니다. 그 뒤에 코드 리뷰 루프라는 검증이 있어서, 오류가 거기서 걸러지기 때문입니다.

만약 검증이 없는 구현이라면, 오히려 최상위로 올려야 맞습니다. 그래서 티어를 정하기 전에 "이 뒤에 하류 검증이 있는가"를 먼저 확인하는 습관이 생겼습니다. 순서가 중요합니다. 난이도부터 보면 자꾸 틀리게 됩니다.

세 번째로, 기계적인 fan-out에 최상위 모델을 쓰는 것은 그저 낭비입니다. 100개의 항목을 훑고 지나가는 맵 단계는 haiku로 충분하고, 각각의 오류는 다음 검증 단계가 싼 값에 잡아줍니다.

이 세 가지를 관통하는 감각은 결국 하나였습니다. 티어는 작업의 무게가 아니라, 그 작업이 틀렸을 때 새어나갈 구멍의 크기로 정해야 한다는 것. 무겁고 어려운 일이라도 뒤에서 받쳐주는 손이 있으면 가볍게 가도 되고, 사소해 보이는 판정이라도 그것이 마지막 관문이면 무겁게 가야 했습니다.

제 티어 배정을, 여섯 검증 에이전트에게 반박당하게 했습니다

여기서 한 가지 솔직한 고백을 해야겠습니다. 이 티어 배정을 저 혼자 눈대중으로 확정하지 않았습니다. 부끄럽지만, 제 판단을 그대로 믿기가 어려웠습니다.

그래서 제가 짠 배정표를, 여섯 개의 검증 에이전트에게 동시에 넘겨 하나하나 반박당하게 했습니다. 검증자들에게 준 역할은 "맞는지 봐 달라"가 아니라 "틀렸다고 쳐보고 트집을 잡아 달라"였습니다. 특히 각 에이전트가 대상의 한 줄 요약이 아니라 정의 파일 본문 전체를 읽고, 그 에이전트가 실제로 하는 일이 제가 제안한 티어보다 무거운 판단인지 아닌지를 따지도록 했습니다. 그렇게 나온 반대 의견만 제가 다시 들여다보고 받아들일지 정했습니다.

실제로 제 초안이 교정된 사례가 있었습니다. 저는 test-data-verifier라는 에이전트를 sonnet으로 내리자고 제안했습니다. E2E와 통합 테스트가 끝난 뒤 데이터베이스의 데이터 정합을 감사하는 에이전트인데, 하는 일이 절차적으로 보였기 때문입니다. 그런데 검증 에이전트가 이렇게 반박했습니다.

"이건 절차적인 데이터 덤프가 아니라 검증 게이트 그 자체다. 합격·불합격 판정이 최종 산출물이고, 그 false-pass를 잡아줄 하류가 없다."

맞는 말이었습니다. 결국 최상위 티어로 되돌렸습니다. 이 일화가 준 교훈은 조금 아이러니했습니다. 티어 배정이라는 판단 자체가 "틀리면 조용히 새는" 종류의 판단이었던 것입니다. 그래서 저는 이 판단에도 똑같은 프레임워크를 재귀적으로 적용할 수밖에 없었습니다. 검증을 붙이는 것. 결국 제 판단을 지켜준 것도, 제가 그토록 강조하던 하류 검증이었습니다.

이 원칙에 따라 글로벌과 프로젝트를 합쳐 서른다섯 개의 서브에이전트 정의에 기본값을 지정했습니다. 리서치·테스트·데이터 분석·비평 계열 스물다섯 개는 sonnet으로, 구현·설계·전달 문서 계열 열 개는 opus로 두었습니다. 하나같이 하류에 검증이 있는 작업들입니다. 반대로 코드 리뷰어·보안 감사·머지 게이트·DBA·데이터 검증기처럼 문지기 역할을 하는 에이전트들은 최상위 티어를 그대로 유지했습니다.

그리고 이 판정 규칙 자체를 매 세션 자동으로 불러오는 규칙 문서에 박아두어, 앞으로의 모든 위임이 두 단계를 거치도록 했습니다. 먼저 어떤 에이전트를 부를지 고르고, 그다음 그 에이전트에 어떤 티어를 줄지 정하는 두 단계입니다.

결국 남은 한 줄

돌이켜 생각해보면, 이 모든 고민의 출발점은 "강한 모델은 언제나 더 낫다"는 막연한 믿음이었습니다. 아주 틀린 믿음은 아니었습니다. 다만 강한 모델이 정말로 제값을 하는 자리는 따로 있었습니다. 틀렸을 때 아무도 잡아주지 못하는 자리 말입니다. 그 자리를 알아보는 눈이, 결국 이 긴 정리의 핵심이었습니다.

비싼 모델은 틀리면 조용히 새는 자리에, 싼 모델은 틀려도 곧 잡히는 자리에. 이 한 줄이, 서른다섯 개의 위임을 정리하며 제가 얻은 전부라는 생각이 들었습니다.