AI 에이전트는 왜 항상 가장 강한 모델을 써서는 안 되는가

좋은 에이전트는 모든 질문에 최고 모델로 답하지 않는다. 평범한 작업은 빠르게 처리하고, 되돌리기 비싼 결정에서만 더 강한 판단을 호출한다.

TL;DR

모든 턴에 최고 모델을 쓰면 비용과 지연이 기본값으로 커진다.
작업 모델이 어려운 순간에 advisor 모델을 호출하는 escalation 레이어가 현실적인 절충안이다.
핵심은 “언제 부를까”와 “상담 결과를 어떻게 증명할까”를 실행 계약으로 만드는 데 있다.
모델 선택은 질문의 길이보다 실패했을 때의 되돌리기 비용을 기준으로 설계해야 한다.

왜 지금 중요한가

AI 에이전트의 모델 선택은 품질 문제가 아니라 운영비와 책임의 문제로 바뀌고 있다. 간단한 요약과 분류까지 가장 비싼 모델에 맡기면 사용량이 불필요하게 늘어난다. 반대로 저렴한 모델만 고정하면 API 계약, 권한, 금액, 데이터 삭제처럼 한 번 틀리면 되돌리기 어려운 결정을 놓칠 수 있다.

제품은 두 극단 중 하나를 고를 필요가 없다. 일상 작업은 작업 모델이 맡고, 특정 조건에서만 더 강한 모델에게 판단을 요청하면 된다. 이 구조는 비용을 낮추는 동시에 중요한 순간의 검토를 남긴다.

핵심 흐름

‘강한 모델 기본값’은 안전과 비용을 혼동한다

최고 모델을 매번 호출하면 판단 품질을 일정하게 유지하기는 쉽다. 하지만 모든 작업이 같은 수준의 판단을 요구하지는 않는다. 초안 작성과 결제 취소 정책의 변경은 비용도 위험도도 다르다.

모델 라우팅의 단위는 질문의 길이가 아니라 결정의 위험도여야 한다.

되돌리기 쉬운 초안: 작업 모델
외부 시스템을 바꾸는 실행: 검증 레인
고객·돈·권한·데이터 보존에 영향: advisor 또는 인간 승인

Advisor는 작업 중간에 두 번째 판단을 끼워 넣는다

Claude의 Managed Agents cookbook은 작업 모델의 roster에 더 강한 모델을 advisor로 등록하고, 작업 모델이 필요할 때 advisor 도구를 호출하는 패턴을 보여준다. Advisor는 새 작업을 처음부터 수행하는 대신 지금까지의 대화 맥락을 읽고 guidance를 돌려준다.

이 구조가 중요한 이유는 escalation이 별도 사후 심사가 아니라 현재 작업의 중간 단계가 되기 때문이다. 작업 모델은 상담을 반영한 뒤 계속 진행할 수 있다.

좋은 escalation은 호출 조건을 먼저 쓴다

“어려우면 advisor를 불러라”는 운영 규칙으로 부족하다. 어려움은 측정하기 어렵기 때문이다. 대신 되돌리기 비용과 실패 영향을 기준으로 조건을 적는다.

결정	기본 레인	escalation 조건
문장 초안	작업 모델	보통 없음
API pagination·오류 계약	작업 모델	외부 클라이언트가 이미 의존하거나 변경 비용이 큰 경우
idempotency·권한 경계	검증 레인	advisor 검토
실제 금액·데이터 삭제	실행 중지	별도 승인과 독립 검증

이 표의 목적은 최고 모델을 자주 부르는 것이 아니다. 어떤 판단을 싸게 처리해도 되는지, 어떤 판단부터 추가 검토가 필요한지 합의하는 데 있다.

실제 사례 / 신호

원문 cookbook은 advisor를 별도 roster 항목으로 두고, 상담을 짧은 플랫폼 스레드로 실행하며, 이벤트 스트림과 thread 사용량에서 상담 시점과 비용을 확인하는 흐름을 설명한다. Advisor는 “더 똑똑한 답변”만이 아니라 비용과 판단 경계를 관찰할 수 있는 실행 표면이다.

함께 논의된 Graph Engineering 자료와 연결하면 구조가 선명해진다. 하나의 loop 안에서 advisor를 호출하는 것은 내부 escalation이고, 여러 loop를 병렬 실행·검증·인계하는 것은 외부 orchestration이다. 두 경우 모두 핵심은 노드 수가 아니라 상태와 중단 조건이다.

실전 활용 팁: 모델 라우팅 receipt 만들기

작은 AI 유틸을 만들 때 매 요청마다 아래 정보를 기록한다.

요청의 위험 레인과 기본 작업 모델
advisor 호출 여부와 호출 이유
advisor가 검토한 결정 요약
사용량·지연·추정 비용
최종 결과와 사용자가 확인해야 할 남은 불확실성

이 receipt가 있으면 “모델을 바꿨더니 좋아졌다”는 인상 대신 어떤 종류의 결정에서 추가 지능이 효과를 냈는지 비교할 수 있다. 사용자는 답변뿐 아니라 왜 그 경로가 선택됐는지도 확인할 수 있다.

바로 해볼 실험

세 가지 설정으로 동일한 API 설계 과업 20개를 실행한다.

A: 강한 모델 단독
B: 중간 모델 단독
C: 중간 모델 + 되돌리기 비싼 결정만 advisor 호출

정답률만 비교하지 않는다. 상담 횟수, 비용, 지연, 계약 누락, 재작업 횟수를 함께 기록한다. C가 A와 비슷한 품질을 더 낮은 비용으로 내면 escalation 정책의 가치를 설명할 수 있다.

처음부터 완벽한 라우터를 만들 필요는 없다. 위험한 결정 두세 가지를 고정하고, 호출 이유와 결과를 남기는 것부터 시작하면 된다.

리스크 / 반론

Advisor가 항상 더 나은 판단을 보장하지는 않는다. 두 모델이 같은 잘못된 전제를 공유할 수 있다. 또한 대화 전체를 advisor에 전달하면 민감한 맥락이 추가 모델로 이동한다. 데이터 경계와 redaction 정책을 함께 설계해야 한다.

호출 조건이 너무 넓으면 비용 절감 효과가 사라지고, 너무 좁으면 위험한 결정이 빠져나간다. cookbook의 구현 예시는 특정 플랫폼과 베타 API에 의존하므로 그대로 범용 표준으로 해석해서도 안 된다.

결론

AI 에이전트의 경쟁력은 가장 강한 모델을 항상 켜두는 데 있지 않다. 평범한 작업은 빠르게 끝내고, 되돌리기 비싼 결정에서만 더 강한 판단을 호출하며, 그 선택과 비용을 증거로 남기는 데 있다.

다음 에이전트를 설계할 때는 모델 이름부터 고르지 말고 먼저 물어야 한다.

이 작업에서 정말 강한 판단이 필요한 순간은 언제이며, 그 호출이 남긴 증거를 사용자가 확인할 수 있는가?