벤치마크 점수만 보면 결론은 단순합니다. 큰 모델이 이깁니다.
그런데 실제로 서비스를 굴리는 팀들의 선택은 점점 다른 방향입니다. 가장 좋은 모델이 아니라 가장 맞는 모델을 고르고, 그 결과가 작은 모델인 경우가 늘고 있습니다.
이유를 벤치마크는 보여주지 않습니다.
벤치마크가 측정하지 않는 세 가지
첫째, 응답 시간. 정답률이 3% 높아도 응답이 4초 늦으면 사용자는 떠납니다. 대화형 인터페이스에서 체감 품질은 정확도보다 지연에 더 민감합니다.
둘째, 단가 × 호출량. 한 번 호출의 비용 차이는 작아 보입니다. 하루 5만 건이면 이야기가 달라집니다. 앞서 여러 조사에서 프로덕션 비용이 초기 예상의 3~5배로 간다고 지적된 배경에 이 항목이 있습니다.
셋째, 안정성. 큰 모델은 더 창의적이고, 그래서 더 다양하게 답합니다. 분류나 추출처럼 같은 입력에 같은 출력이 나와야 하는 작업에서는 이게 단점입니다.
세 번째가 실무에서 특히 과소평가됩니다.
작은 모델로 충분한 작업
경계는 대체로 이렇게 갈립니다.
작은 모델로 충분한 쪽
- 분류 — 문의 유형, 감정, 우선순위
- 추출 — 문서에서 날짜·금액·이름 뽑기
- 형식 변환 — 자유 텍스트를 구조화된 데이터로
- 짧은 요약 — 회의록, 로그
- 라우팅 판정 — 이 요청을 어디로 보낼지
큰 모델이 필요한 쪽
- 여러 단계의 추론이 걸린 문제
- 긴 문서 전체를 종합하는 작업
- 코드 설계와 리팩터링
- 애매한 상황에서의 판단
- 창작
**공통점은 "정답이 좁게 정해져 있는가"**입니다. 좁으면 작은 모델로 충분하고, 넓으면 큰 모델이 필요합니다.
라우팅이 실질적인 답이다
하나를 고르는 문제로 접근할 필요가 없습니다. 실제로 자리 잡는 형태는 작업별로 나누는 것입니다.
들어온 요청을 먼저 작은 모델이 분류하고, 단순한 건 그대로 처리하고, 복잡한 것만 큰 모델로 넘깁니다. 앞서 도구 스택에서 다룬 "바깥 흐름과 안쪽 판단의 분리"가 여기서도 그대로 적용됩니다.
효과는 큽니다. 전체 요청의 상당수가 단순 분류·조회인 서비스라면, 비용의 대부분을 차지하던 호출이 작은 모델로 내려갑니다.
주의할 점은 라우팅 판정 자체의 비용과 실패입니다. 판정이 틀려 어려운 요청이 작은 모델로 가면 품질이 떨어집니다. 그래서 라우팅에는 보수적인 기준을 두고, 애매하면 큰 쪽으로 보내는 편이 안전합니다.
판단 기준
모델을 고를 때 던질 질문 다섯 개입니다.
- 이 작업의 정답 범위가 좁은가 — 좁으면 작은 모델
- 같은 입력에 같은 출력이 나와야 하는가 — 그렇다면 작은 모델 + 낮은 온도
- 응답 시간이 사용자 경험에 직접 닿는가 — 그렇다면 작은 모델
- 하루 호출량이 몇 건인가 — 많을수록 작은 모델의 이점이 커집니다
- 틀렸을 때 비용이 큰가 — 크면 큰 모델, 또는 사람 확인
5번이 나머지를 뒤집을 수 있습니다. 계약서 검토처럼 한 번의 오류가 비싼 작업이라면, 호출량이 많아도 큰 모델을 씁니다.
측정하지 않으면 고를 수 없다
가장 중요한 건 이겁니다. 자기 데이터로 비교하지 않으면 결정할 수 없습니다.
벤치마크는 일반적인 과제에서의 성능입니다. 우리 업무의 문서, 우리 고객의 질문, 우리 조직의 용어에서 어떤지는 다릅니다.
방법은 단순합니다. 실제 업무에서 나온 입력 30~50건을 골라 평가 세트를 만들고, 후보 모델들에 같은 걸 넣고, 사람이 채점합니다. 반나절이면 됩니다.
이 세트를 한 번 만들어두면 새 모델이 나올 때마다 30분이면 판단할 수 있습니다. 모델 교체 결정이 감이 아니라 데이터가 됩니다.
정리
- 벤치마크는 응답 시간, 단가×호출량, 출력 안정성을 측정하지 않습니다.
- 정답 범위가 좁은 작업 — 분류·추출·변환·짧은 요약 — 은 작은 모델로 충분합니다.
- 하나를 고르지 말고 라우팅하세요. 애매하면 큰 쪽으로 보내는 보수적 기준이 안전합니다.
- 틀렸을 때 비용이 크면 다른 조건을 뒤집고 큰 모델을 쓰세요.
- 자기 업무 입력 30~50건으로 평가 세트를 만드세요. 이후 모든 모델 결정이 빨라집니다.
