AI 에이전트가 장애를 조사하고, 문서를 찾고, 코드를 수정하고, 도구를 호출하는 환경에서는 “어느 모델이 100만 토큰당 더 싼가”만으로 API를 고르기 어렵습니다. 한 번의 판단 오류가 추가 도구 호출, 더 긴 컨텍스트, 재실행, 사람의 검토로 이어지기 때문입니다.
모델 라우팅 API는 요청 난이도에 따라 경량 모델과 상위 모델을 나눠 쓰려는 선택입니다. 직접 모델을 고르는 방식보다 운영 부담을 줄일 수 있지만, 라우터가 싼 모델을 자주 선택했다는 사실만으로 경제성이 증명되지는 않습니다. CTO와 개발 리더가 확인해야 할 질문은 더 구체적입니다.
우리의 실제 에이전트 업무에서, 라우팅 API는 직접 모델 선택보다 성공한 작업 1건을 더 낮은 비용과 허용 가능한 시간 안에 처리하는가.
이 질문에 답하려면 가격표가 아니라 작업 단위의 비교 기준을 먼저 세워야 합니다.
라우팅 API와 직접 선택은 무엇을 바꾸는가
직접 모델 선택에서는 개발팀이 업무별로 모델을 지정합니다. 예를 들어 단순 분류나 형식 변환에는 경량 모델을 쓰고, 복잡한 분석이나 코드 수정에는 상위 모델을 붙이는 방식입니다. 모델 선택 규칙, 장애 시 대체 경로, 프롬프트 호환성은 팀이 관리합니다.
라우팅 API는 이 선택 일부를 제공업체나 라우터에 맡깁니다. 요청마다 적합한 모델을 고르거나, 비용 우선·균형·성능 우선 같은 전략 안에서 후보 모델을 선택하도록 구성할 수 있습니다. Liner의 GPT·Claude·Gemini 계열 라우터는 응답의 model 필드에 실제 처리 모델명을 표시하고, 선택된 모델의 가격으로 청구하는 구조를 안내합니다. 전략별 후보 모델 범위도 정할 수 있습니다.
반면 Liner의 liner-mark 계열처럼 자체 버전 모델명으로 호출하고 고정된 요금 체계를 제시하는 방식도 있습니다. 이 경우 호출한 버전은 식별할 수 있어도, 각 요청을 어떤 외부 또는 내부 모델이 처리했는지와 같은 수준의 정보는 별도 확인 대상이 됩니다.
둘의 차이는 기술 취향 문제가 아닙니다. 첫 번째 방식은 요청별 모델 선택을 감사하고 조정하기 쉽지만 가격 변동과 모델별 비용을 함께 관리해야 합니다. 두 번째 방식은 비용 예측과 호출 인터페이스를 단순화할 수 있지만, 품질 편차와 장애 원인을 모델 단위로 분해하기 어려울 수 있습니다.
토큰 비용은 시작점일 뿐, 운영 비용은 작업이 끝날 때 확정된다
에이전트는 답변 한 번으로 끝나지 않습니다. 도구를 실행한 뒤 결과를 다시 모델에 넣고, 다음 행동을 정하고, 실패하면 다른 가설을 세웁니다. 대화와 도구 결과가 누적될수록 입력 토큰도 커집니다.
따라서 비교 단위는 다음처럼 잡는 편이 낫습니다.
작업 1건당 운영 비용
= API 사용료 + 재시도 사용료 + 실패 후 사람 개입 비용 + 지연으로 인한 업무 비용
이 식의 각 항목을 금액으로 완벽하게 환산하기 어려울 수 있습니다. 그래도 네 항목을 따로 기록하면, “라우터가 토큰은 적게 썼지만 사람이 더 자주 개입했다”거나 “첫 응답은 느렸지만 재실행이 줄어 전체 완료 시간은 짧아졌다”는 차이를 볼 수 있습니다.
공개된 쿠버네티스 장애 대응 측정에서는 특정 라우팅 조건이 상위 직접 선택 모델과 비슷한 운영 점수를 보이면서 비용은 더 낮게 나타났습니다. 다만 이 결과에는 고정된 에이전트 버전, 정해진 장애 시나리오, 특정 라우터 버전, 반복 실행 조건이 포함됩니다. 다른 업무의 절감률로 옮겨 적을 수는 없습니다.
특히 그 측정에서 비용 차이는 단가만으로 설명되지 않았습니다. 라우팅 조건은 입력·출력 토큰 사용량도 더 적었습니다. 에이전트가 명령을 묶어 실행하고 대화 왕복을 줄이는 방식이 토큰량에 영향을 줄 수 있기 때문입니다. 팀의 도구 정의, 시스템 프롬프트, 명령 실행기, 캐시 정책이 달라지면 비용 구조도 달라집니다.
성공률과 재시도를 함께 봐야 지연시간을 잘못 읽지 않는다
라우터 평가에서 자주 빠지는 지표가 재시도입니다. 첫 토큰이 빨리 도착하고 응답 시간이 짧아도, 결과가 틀려 다시 실행하거나 사람이 되돌려야 하면 사용자가 체감하는 완료 시간은 길어집니다.
긴 컨텍스트 환경에서는 이 문제가 더 커질 수 있습니다. 최근 연구는 긴 입력에서 정확도 변동이 재시도를 늘리고, 단일 요청의 지연시간으로는 보이지 않는 누적 지연을 만든다고 설명합니다. 이 관점에서는 정확도와 속도를 별개로 평가하면 안 됩니다. 올바른 답을 처음 얻기까지 걸린 시간을 봐야 합니다.
에이전트 업무에서는 다음 세 시간을 분리해 기록하는 것이 좋습니다.
| 측정 항목 | 확인할 질문 |
|---|---|
| 첫 응답 시간 | 라우팅 판단과 모델 호출이 사용자 대기를 얼마나 늘리는가 |
| 작업 완료 시간 | 도구 호출, 추가 추론, 최종 보고까지 얼마나 걸리는가 |
| 정상 완료까지 시간 | 실패·재시도·사람 개입을 포함하면 언제 업무가 끝나는가 |
장애 대응처럼 시간이 중요한 업무라면 세 번째 지표의 비중이 큽니다. 반대로 야간 배치 요약처럼 즉시성이 낮고 대량 처리가 중요한 업무라면, 일정 수준의 품질을 만족하는 범위에서 작업당 API 비용을 더 크게 볼 수 있습니다.
모델 식별 가능성은 감사와 장애 대응의 조건이다
라우터가 어떤 모델을 선택했는지 알 수 있는지는 조달 문서의 부가 항목이 아닙니다. 품질 저하, 형식 오류, 도구 호출 실패, 특정 언어 처리 문제를 추적할 때 필요한 운영 정보입니다.
요청별 실제 모델명이 응답에 남는 라우터라면, 팀은 다음을 분석할 수 있습니다.
- 특정 모델 선택 뒤에 실패율이나 재시도율이 높아지는지
- 특정 업무 유형에서 비용 우선 전략이 품질을 과도하게 낮추는지
- 모델별 지연시간과 도구 호출 성공률이 다른지
- 사고 조사 때 어떤 모델과 라우팅 전략이 영향을 받았는지
반대로 실제 처리 모델을 확인할 수 없는 구조라면, 모델명 대신 확보할 수 있는 관측 정보를 계약과 기술 검증에서 확인해야 합니다. 예를 들어 라우터 버전 고정 가능 여부, 버전 변경 공지 방식, 요청별 비용 데이터, 입력·출력·캐시 토큰 사용량, 오류 코드, 요청 ID, 장애 시 대체 처리 방침이 여기에 해당합니다.
라우팅과 캐스케이딩 연구에서도 비용과 품질의 개선 폭은 요청 품질을 얼마나 잘 추정하느냐에 크게 좌우된다고 봅니다. 즉, 라우터의 핵심은 “어떤 모델이 많으냐”보다 “어떤 작업에 더 좋은 모델이 필요한지 얼마나 안정적으로 가려내느냐”에 있습니다. 이 판단을 외부에 맡길수록, 팀은 결과 품질을 더 엄격하게 검증해야 합니다.
벤더 선정 전에는 같은 업무를 세 조건으로 시험하라
라우팅 API를 검토할 때는 라우터 조건 하나와 최고급 모델 하나만 비교하면 판단이 기울기 쉽습니다. 최소한 아래 세 조건을 같은 에이전트, 같은 도구 권한, 같은 성공 기준으로 비교하는 편이 좋습니다.
-
현재 직접 선택 방식
현재 운영 중인 모델과 프롬프트를 기준선으로 둡니다. -
라우터의 비용 우선 또는 기본 전략
비용 절감이 목적이라면 가장 먼저 확인할 조건입니다. 다만 품질 하락이 어떤 업무에서 나타나는지 분리해야 합니다. -
라우터의 균형 또는 성능 우선 전략
비용 우선 전략에서 실패한 업무가 전략 변경으로 회복되는지 봅니다. 회복되지 않는다면 라우팅 전략 문제가 아니라 도구 설계나 모델 호환성 문제일 수 있습니다.
시험 업무는 평균적인 요청만 모으면 안 됩니다. 짧고 반복적인 업무, 도구 호출이 여러 번 필요한 업무, 긴 문맥을 읽어야 하는 업무, 잘못된 조치가 큰 영향을 주는 업무를 함께 넣어야 합니다. 업무별 성공 조건도 미리 정해야 합니다. 예를 들어 문서 요약은 필수 항목 누락 여부로, 코드 변경은 테스트 통과와 변경 범위로, 운영 업무는 해결 여부와 위험 조치 여부로 판정할 수 있습니다.
각 실행에서는 API 비용, 토큰 사용량, 선택 모델 또는 라우터 버전, 첫 응답 시간, 완료 시간, 재시도 횟수, 사람 개입 여부를 함께 남기십시오. 성공률만 평균 내지 말고, 실패한 작업이 어떤 유형에 몰렸는지도 봐야 합니다.
라우팅 API가 적합한 팀은 “가장 싼 모델”을 찾는 팀이 아니라, 업무별 성공 기준을 정하고 실패 기록을 다시 라우팅 정책 검증에 쓸 수 있는 팀입니다. 먼저 대표 업무의 성공 판정표와 허용 가능한 재시도 범위부터 정한 뒤, 그 조건에서 라우터가 직접 모델 선택보다 낮은 작업 완료 비용을 보이는지 시험하는 순서가 안전합니다.
