서브에이전트, 핀 걸어도 최상위 모델로 샌다

클로드 코드(Claude Code)로 서브에이전트를 운용하던 한 개발자가 토큰 비용이 체감보다 크게 불어난 원인을 추적해 공개했다. 범인은 에이전트 정의 파일에 한 줄 적어둔 모델 지정이었다. 특정 릴리스에서 이 지정이 조용히 무시되면서, 값싼 모델로 돌아야 할 잡무 에이전트들이 세션의 최상위 모델로 실행되고 있었다. 오류도 경고도 없었고 결과물도 멀쩡했다. 달라진 것은 몇 주 뒤 청구서에 찍힌 숫자뿐이었다.

무슨 일인가

이 개발자는 세션 본체는 상위 모델로 두고, 로그 조회·포맷 정리·검사 같은 기계적인 일은 서브에이전트에게 맡기는 구성을 쓴다. 서브에이전트를 쓰는 진짜 이유는 모델이 작아서가 아니라 별도의 문맥 공간에서 돌기 때문이다. 지저분하고 양 많은 작업을 대신 처리한 뒤 요약된 몇 줄만 돌려주므로, 본 세션이 쓰레기 데이터로 오염되지 않는다. 많이 가져와 걸러서 조금 돌려주는 일에는 똑똑한 모델이 아니라 지시를 잘 따르는 모델이면 충분하다.

문제는 그 지정이 얹히는 자리였다. 클로드 코드는 서브에이전트가 쓸 모델을 네 단계로 결정한다. 환경변수가 가장 세고, 그다음이 호출할 때 직접 넘긴 값, 세 번째가 에이전트 정의 파일에 적은 값, 마지막이 세션 모델이다. 문서에 나와 있고 한 번만 적어두면 되기에 대부분이 쓰는 세 번째 층이 하필 아래에서 두 번째다. 이 층이 몇몇 릴리스에서 무력화되자 지정이 통째로 미끄러져 네 번째인 세션 모델로 떨어졌다.

핵심 짚어보기

가장 위험한 대목은 실패가 실패처럼 보이지 않는다는 점이다. 프로그램이 죽으면 최소한 죽었다고 알려주지만 이 문제는 아무 신호도 남기지 않는다. 하루에 수백 번 부르는 가장 싼 에이전트가 가장 비싼 모델로 돌아가는데, 화면상으로는 전과 똑같이 잘 작동한다. 게다가 정성껏 모델을 지정해둔 에이전트일수록 자주 부르고 덜 들여다보는 종류라 발견이 늦을 수밖에 없다.

같은 문제를 겪은 이용자들이 공유하는 우회법은 하나로 모인다. 호출할 때마다 모델을 명시적으로 넘기는 것이다. 이는 두 번째 층이고, 이 층은 깨진 전례가 없다. 다만 사람이든 오케스트레이터든 매번 잊지 않고 챙긴다는 전제가 현실적이지 않다. 그래서 저자가 택한 방식은 기억이 아니라 강제다. 도구 호출 직전에 개입하는 훅을 두고, 정의 파일에 모델이 지정돼 있는데 호출에 모델이 실려 있지 않으면 그 호출 자체를 막은 뒤 어떻게 다시 보내야 하는지 알려주게 했다. 스크립트는 열 줄 안팎이며 호출 정보를 파싱해 작업 위임 계열 도구만 걸러낸 뒤 종료 코드로 차단한다.

1인기업 실전 적용 포인트

• 클라우드 로그 조회, 이슈와 변경분 확인, 에러 추적, 정적 분석 리포트, 테스트 결과 읽기처럼 입력은 방대하고 답은 짧은 작업은 전부 저렴한 모델로 내려라. 이 다섯 갈래만 정리해도 월 토큰 지출의 체감이 달라진다.
• 지정을 걸었으니 됐다고 넘기지 말고, 이번 주 안에 실제 사용 기록에서 서브에이전트별 실행 모델을 한 번 대조하라. 지정과 실행이 어긋난 항목이 곧 새는 돈이다.
• 우회 대신 차단 장치를 만들어라. 호출 직전 검사 훅 하나면 사람이 규칙을 잊어도 시스템이 대신 기억한다. 규칙을 문서에 적는 것과 코드로 막는 것은 전혀 다른 일이다.
• 도구를 업데이트한 주에는 비용 지표를 따로 확인하라. 조용한 비용 증가는 아무도 신고하지 않으므로 알아채는 사람만 손해를 피한다.

전망과 주의점

설정 우선순위 동작은 릴리스마다 바뀔 수 있어 지금 쓰는 버전에서 직접 확인해야 한다. 훅을 잘못 배선하면 정상 호출까지 막혀 작업이 멈추니, 처음에는 차단 대신 기록만 남기는 방식으로 며칠 돌려본 뒤 조이는 편이 안전하다. 더 넓게 보면 이 사건은 에이전트 시대의 비용 관리가 어떤 모습일지 보여준다. 앞으로 자동화의 손익은 성능보다, 설정이 의도대로 유지되는지를 감시하는 능력에서 갈린다.

출처: Thomas Witt Blog (https://thomas-witt.com/blog/blog-subagent-model-pin/)