프로덕션 LLM 트래픽의 대부분은 어렵지 않다. 분류, 추출, 짧은 재작성, 라우팅처럼 작고 빠른 모델이 정확하고 저렴하게 처리하는 종류의 작업이다. 그런데도 흔한 패턴은 모든 호출을 사용 가능한 가장 큰 모델에 연결하는 것이다. "그냥 되니까"라는 이유로 말이다. 그러고는 왜 청구서와 지연 시간이 둘 다 높은지 의아해한다. Amazon Bedrock에서는 Claude Haiku 4.5와 Claude Opus 4.5를 둘 다 쓸 수 있으며, 엔지니어링에서 이기는 방법은 둘 중 하나를 고르는 것이 아니라 작업 유형별로 라우팅해서 저렴한 모델이 다수를 처리하고 비싼 모델은 기본값이 아니라 에스컬레이션 경로가 되게 하는 것이다.

재구성은 이렇다. 모델 선택은 작업 단위의 결정이지 프로젝트 전체의 결정이 아니다. 모든 요청을 가장 어려운 요청에 맞춰 사이징하는 것은 모든 워크로드를 가장 큰 인스턴스 타입에서 돌리는 것과 같은 실수다. 적정 사이징이란 모델을 특정 호출의 난이도에 맞추는 것이며, 상당수의 호출에서 정답은 작은 모델이다.

큰 모델이 잘못된 기본값인 이유

프론티어 모델을 기본값으로 삼는 것은 안전해 보이지만 두 차원에서 비싸다. Opus급 모델은 토큰당 Haiku급 모델보다 몇 배 더 비싸므로, 90퍼센트가 기계적인 워크로드가 작은 모델이 완벽하게 해낼 작업에 프론티어 가격을 치르는 셈이다. 더 유능한 모델은 대개 응답하는 데 시간이 더 걸리므로 속도가 느리기도 하며, 그 결과 사용자가 속도를 가장 눈여겨보는 고볼륨의 단순한 호출에서 지연을 부풀리게 된다.

숨겨진 비용은 단순한 작업에 큰 모델을 쓴다고 더 나은 결과가 나오는 경우가 드물다는 점이다. 이메일에서 날짜를 추출하거나 티켓을 여섯 개 버킷 중 하나로 분류하는 일은 더 큰 역량을 던진다고 나아지지 않는다. 더 작은 모델이 맞게 처리했을 답을 더 비싸게, 더 오래 기다려서 얻는 셈이다.

작업 유형별로 라우팅하라

효과가 있는 설계는 요청을 난이도별로 분류하고 그에 맞는 모델로 보내는 것이다. 사용자별도 기능별도 아닌 작업 유형별이다.

  • 기계적인 작업은 Haiku로. 분류, 추출, 형식 변환, 짧은 요약, 도구 인자 구성, 라우팅 결정. 볼륨은 높고 모호함은 낮으며, 작은 모델이 품질 손실 없이 더 저렴하고 더 빠르다.
  • 판단이 필요한 작업은 Opus로. 다단계 추론, 모호한 지시, 긴 컨텍스트 종합, 그리고 틀린 답의 대가가 큰 모든 경우. 볼륨은 낮지만, 그 역량이 실제로 결과를 바꾸므로 프리미엄을 낼 가치가 있다.
  • 라우터 자체는 저렴하게. 입력 길이와 작업 유형에 대한 휴리스틱, 또는 작은 모델 호출 한 번이 등급을 결정한다. 모든 것을 최상위 모델로 기본값 설정하지 않아서 절약하는 것에 비하면 라우팅 비용은 반올림 오차 수준이다.

에스컬레이션 경로로서의 큰 모델

가장 신뢰할 수 있는 패턴은 프론티어 모델을 정문이 아니라 에스컬레이션으로 만드는 것이다. 먼저 작은 모델을 시도하라. 성공하면, 그리고 기계적인 다수에서는 성공할 것인데, 비용과 지연 모두 극히 일부로 끝난다. 검사를 통과하지 못하면, 즉 신뢰도가 낮거나, 스키마가 유효하지 않은 출력이거나, 명시적으로 "확신이 없다"는 경우 그 요청 한 건만 더 큰 모델로 에스컬레이션한다.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

이것은 경제성을 뒤집는다. 드문 어려운 경우를 커버하기 위해 모든 요청에 Opus 가격을 치르는 대신, 흔한 경우에는 Haiku 가격을 치르고 저렴한 시도가 눈에 띄게 부족했을 때만 Opus에 손을 뻗는다. 대가는 필요로 하는 소수의 요청에 대한 호출 한 번 추가이며, 이는 필요 없는 다수에서 얻는 큰 절감에 비하면 작은 값이다.

비율을 가정하지 말고 측정하라

팀이 틀리는 지점은 작업 구성을 측정하지 않고 추측하는 것이다. 라우팅하기 전에 실제 트래픽을 표본으로 뽑아 그중 얼마나 진짜로 기계적이고 얼마나 진짜로 어려운지 레이블링하라. 그 숫자는 거의 항상 팀이 예상한 것보다 더 기계적이며, 바로 그래서 큰 모델을 기본값으로 삼는 것이 그토록 낭비인 것이다. 이것은 또한 에스컬레이션 트리거를 어디에 설정할지도 알려준다. 작은 모델이 트래픽의 92퍼센트를 깔끔하게 처리한다면 에스컬레이션 비율은 8퍼센트 근처여야 하며, 그보다 훨씬 높은 비율은 검사가 너무 엄격하거나 라우팅이 잘못 보정되었다는 뜻이다.

결론

Haiku와 Opus 모두 몇 달째 Bedrock에 올라와 있으며, 요점은 둘 중 하나를 고르는 것이 아니라 각각을 맞는 곳에 쓰는 것이다. 작업 유형별로 라우팅하라. 기계적인 다수는 작고 빠른 모델로 보내고, 프론티어 모델은 판단이 무거운 소수를 위해 아껴 두되, 이상적으로는 기본값이 아니라 실패한 검사로 트리거되는 에스컬레이션 경로로 만들어라. 비율을 튜닝하기 전에 실제 작업 구성을 측정하라. 모델 적정 사이징은 인스턴스 적정 사이징과 같은 규율이며, 가장 빠르고 가장 저렴한 시스템은 작은 모델이 정확히 해낼 작업에 프론티어 가격을 지불하는 것을 멈춘 시스템이다.

이어서 읽으면 좋은 글

여러 모델에 걸친 라우팅과 용량의 플랫폼 측면은 ercan.cloud의 클라우드 현장 노트에서 다루고, 허브는 ercanermis.com에 있다.