저렴한 LLM으로 바꿔도 될까: 업무별 모델 배정과 검증 기준

모델을 고르기 전에 업무를 분류합니다

라우팅은 들어온 요청을 분류해 알맞은 모델이나 처리 흐름으로 보내는 방식입니다. 단순한 문의가 많다면 건당 비용을 줄일 수 있습니다. 평소와 다른 문의가 값싼 경로에 섞일 때 중요한 예외를 놓치거나 두 모델을 연이어 호출할 수도 있으므로, 비용과 품질은 배정 정책이 적용된 전체 과정에서 확인해야 합니다. Anthropic의 에이전트 설계 자료는 충분히 구별되는 유형과 정확하게 분류할 수 있는 조건에서 라우팅을 제안합니다.

상담 문장을 몇 가지 고정된 분류 중 하나에 넣는 작업, 정책 문서나 계약에서 필드를 추출하는 작업, 보상 여부를 판단하는 작업은 결과가 틀릴 때의 영향이 다릅니다. 정형 분류는 대상 팀이 틀린 접수를 바로 옮길 수 있을지도 모릅니다. 문서 추출은 근거 위치, 식별 번호와 단위가 맞아야 후속 처리에서 오류를 피할 수 있습니다. 보상 판단은 지급 권한, 업무 소유자의 승인과 외부 실행 결과까지 연결해야 합니다.

업무 카드에는 행동 위험, 허용한 데이터와 근거, 지연 한도, 사람이 볼 수 있는 시간, 실패 때 해야 할 일을 적습니다. 분류가 쉬워도 규정상 특정 계정 밖으로 입력을 보낼 수 없는 업무가 있습니다. 반대로 형식이 복잡해도 샌드박스에서 결과를 검사한 뒤 사람에게 초안만 보여 주는 일에는 제한된 모델을 시도할 수도 있습니다. 모델 간 비교에 들어가기 전에 클라우드 워크로드 분류 기준에서 사용하는 필수 조건과 선호, 미확인 구분을 업무별 데이터 처리에도 적용할 수도 있습니다.

라우터가 알아낼 신호는 실제 정책에 맞춥니다. 사용자의 역할, 입력 채널, 인증된 주문 참조, 읽어 온 문서의 등급처럼 서버가 확인한 증거가 있으면 모델에게 그 사실을 추측하게 할 필요가 없습니다. 출처를 확인할 수 없는 요청, 여러 의도가 섞인 요청, 자동 실행의 위험을 판정할 수 없는 요청에는 추가 확인이나 사람 이관을 배정합니다. 데이터와 도구 권한을 제한한 뒤 모델을 고르면, 저가 모델이나 상위 모델의 답변이 서버의 인가를 대신하는 일을 줄일 수 있습니다.

같은 평가 자료로 후보와 배정 정책을 비교합니다

모델 A를 낮은 호출 단가 후보, B를 더 높은 호출 단가 후보라고 가정하겠습니다. 가상 평가에서는 기준 모델과 후보 모델에 동일한 요청의 전제, 근거와 도구 계약을 제공합니다. 모델별로 꼭 필요한 템플릿이 다르면 변경된 부분을 기록하고 같은 업무 정답과 운영 환경에서 평가합니다. 모델 단독 점수뿐 아니라 실제 라우터를 포함한 구성도 실행해 최종 결과를 봅니다.

고정된 카테고리 값은 정답표와 코드 비교가 가능하고 복수 조건이 맞는지는 항목별 평가로 볼 수 있습니다. 예외 상담은 사용자에게 보이는 답변과 사람 이관·처리 결과를 나눠 확인합니다. Google Cloud 평가 지표 문서^[1]는 참조와 비교하는 계산 기반 지표 및 업무별 평가 로직의 예를 제공합니다. Anthropic의 에이전트 평가 방법^[2]은 모델이 말한 결과와 실제 환경 상태에 각각 증거가 필요하다고 설명합니다.

업무별 평가셋은 배정이 쉬운 정상 입력만으로 만들지 않습니다. 여러 종류의 문서, 정확한 데이터가 빠진 사례, 긴급 예외가 문장 뒤에 붙은 입력, 다른 조직에 속한 자료에 대한 요청을 포함할 수도 있습니다. 실제 비율을 대표하는 표본과 안전 경계를 집중 확인하는 표본을 분리해 기록합니다. 같은 입력을 여러 번 돌릴 때는 입력 케이스 수와 실제 실행 수를 각각 남겨 반복을 적은 유형과 구별합니다.

모델이 보낸 확신값은 현장에서 보정합니다

예를 들어 분류기가 확신 0.9라고 반환해도, 우리 문의에서 그 범위의 요청 100건이 실제로 90건 맞는지는 시험해야 합니다. 응답에 적은 수치와 모델 내부의 토큰 확률도 같은 값이 아닙니다. Tian 등의 2023년 연구는 특정 모델과 단답형 질의응답 벤치마크에서 수치를 얻는 방식에 따라 보정 결과가 다름을 보고합니다. 이 연구의 실험 결과를 이번 업무의 정확도로 사용하지 않습니다. Tian 외의 확신도 보정 연구^[3]

조직에서 확신값을 배정 신호로 쓰려면 특정 모델·버전과 업무 유형에서 값의 구간별로 실제 결과를 봅니다. 예를 들어 0.9 이상 구간의 표본 수, 그중 정답 수, 고위험 오분류, 검토 대상이 몇 건인지 기록합니다. 표본이 드문 구간은 다른 근거와 함께 판단합니다. 모델이나 프롬프트가 바뀌면 구간별 실제 성능을 다시 확인합니다. 권한, 근거와 금전 한도는 확신값에 관계없이 실행 권한이 있는 서비스에서 확인합니다.

라우터가 잘못 보낸 요청을 따로 계산합니다

라우터의 장애는 모델 품질 뒤에 숨을 수 있습니다. 예컨대 긴급한 보상 요청 100건 중 10건이 일반 문의의 낮은 단가 경로에 들어갔다면 위험한 업무의 오경로율은 10/100, 즉 10%입니다. 전체 1,000건에서 이 10건을 나눠 1%라고만 쓰면 차단해야 할 유형의 취약점이 보이지 않습니다. 단가가 높은 경로로 보낸 정상 문의도 따로 집계해 불필요한 호출과 지연을 계산합니다.

혼동 행렬에는 업무 전문가가 승인한 실제 분류와 라우터가 선택한 경로, 그리고 오류 탐지 이후 재배정 결과를 함께 적습니다. 잘못 보낸 건을 후단 검사에서 회수했는지, 고객이 응답을 보기 전에 막았는지, 사람이 고친 뒤 완료했는지를 확인합니다. 모델이 제공한 분류와 시스템이 차단 규칙을 적용한 결과가 다를 수 있으므로 로그로 둘을 구분합니다.

월간 호출비가 낮아져도 두 번 읽습니다

아래는 동일한 가상 업무 집합 1,000건을 비교한 계산입니다. 정형 문의 700건, 문서 추출 200건, 예외 상담 100건입니다. A 호출은 40원, B 호출은 120원, 라우터 평가는 업무당 5원, 사람 검토는 1건 300원으로 가정합니다. 모든 착수 비용은 1회 실행 흐름에서 청구됐고 확인 기간 안에 규칙과 업무 상태를 충족한 건만 성공 분모에 넣습니다. 공통 인프라 비용과 별도의 정기 유지비는 양쪽이 같아 이 예의 분자에 넣지 않았습니다. 실제 제품 단가나 효과를 설명하는 수치가 아닙니다.

라우팅의 최초 900건 중 예외 상담 10건이 A로 들어갔고 그 자리에 일반 문의 10건이 B로 들어갔다고 가정합니다. 이 예에서 120번의 B 승격에는 후단에서 발견한 예외 10건이 포함되어 있습니다. 차단 지점 전에 예외를 찾았는지와 그 이후 외부 실행을 허용했는지를 확인합니다. 만약 10건 중 일부가 필수 정책을 거쳐야 하는데도 자동 처리됐다면 비용 비교와 관계없이 해당 라우팅 정책은 승인 조건을 충족하지 않습니다. 성공 업무 수 960건이 운영에서 기본 품질 기준을 만족하는지도 업무군별로 봅니다.

이 예에서는 비용 범위 합계가 46,600원 감소하지만 검증된 성공 건수도 10건 줄어듭니다. B 호출로 보낸 120건이 520건으로 늘면 다른 항목이 같다는 가정에서 승격비가 48,000원 더 들고 총비용은 151,400원이 됩니다. 같은 성공 건수라면 성공 업무당 비용도 올라갑니다. 승격과 검토 비율을 평일 한 가지 값으로 고정하면 입력 구성이나 재시도 급증으로 손익이 뒤집힐 때를 놓칩니다. FinOps Foundation의 Unit Economics^[4]는 기술 비용과 결과 단위를 연결하고 정의·가정·포함 비용을 기록하도록 권고합니다. 비용을 귀속하는 방법은 클라우드 비용을 업무 단위로 계산하는 법으로 이어집니다.

실무에서는 건당 호출 수의 분포, 입력과 출력 규모, 저장과 검색의 계정별 비용, 지연으로 인해 작업자가 확인하는 시간, 사람 이관까지 업무 ID로 연결합니다. 업무 규모와 지연 한도를 고려해 한 요청에 추가 모델 호출을 허용할 시한과 횟수를 정합니다. 두 모델을 모두 거쳤고 사람도 검토한 건은 각 비용을 한 번씩 합산합니다. 성공 분모에는 별도 업무 ID 한 건만 넣습니다. 실제 처리 방식이 달라지면 비용과 성공 기준을 함께 설명합니다.

운영 변경과 장애에서 배정 정책을 다시 판정합니다

모델 A의 응답 실패가 늘면 모든 요청을 B로 즉시 보내는 정책은 B의 사용량 제한이나 검토 인력의 허용량을 넘길 수 있습니다. B가 같은 공급자에 있다면 동일 장애의 영향을 받을 가능성도 있습니다. 자동 승격을 허용할 업무, 대기할 수 있는 최대 시한, 사람이 초안을 준비해야 하는 경로, 안전하게 중단해야 할 행동을 상태별로 정합니다. 다른 모델로 옮길 때 데이터 등급과 리전, 승인·도구 제한을 똑같이 확인합니다. 오래된 외부 실행 요청을 모델 변경만으로 다시 시도하지 않습니다.

릴리스에는 모델·프롬프트 버전, 라우터 규칙과 임계값, 평가 자료 버전을 함께 남깁니다. 최초에는 실제 부작용 없이 요청의 배정만 기록하는 시험으로 기존 경로와 비교할 수도 있습니다. 그 뒤 낮은 위험의 일부 업무에서 실제 처리 정책을 적용하고 업무군별 지연·정확성·상위 모델 승격·사람 이관·비용을 확인합니다. 자주 들어오는 정상 업무는 계속 대표하는지, 늘어난 예외나 새로운 형식은 옛 라우팅을 벗어나는지를 운영 중 확인합니다. Google Cloud의 운영 가이드^[5]에서 제안하는 입력 변화 관측과 지속 평가를 배정 단계에도 적용할 수도 있습니다.

후보가 통과한 업무에서도 승인된 경계를 정합니다. 예외 분류 실패, 사용 허용 범위 위반, 신규 업무 유형의 대량 유입은 비용 목표와 독립적으로 중단할 수도 있습니다. 라우터 설정을 복귀시킬 때 몇 건이 이미 다른 모델로 갔고 해당 업무가 외부에서 무엇을 실행했는지 확인합니다. 다음 모델 변경에서는 전체 평균과 함께 업무군별 경계, 오경로율, 회수된 예외와 검증된 성공 업무당 비용을 보고합니다.