작은 모델 먼저 붙여봤더니, 큰 모델이 꼭 답은 아니었다

처음엔 큰 모델부터 써야 한다고 생각했다

한동안은 나도 그랬다. 새 기능 붙일 때마다 가장 성능 좋은 모델부터 넣어보고, 속도가 느리면 그제서야 줄이는 식이었다. 근데 몇 번 반복해보니 이상하더라. 사용자가 매번 깊은 추론을 원하는 것도 아니고, 간단한 분류나 초안 생성, 제목 추천 같은 작업은 작은 모델이 훨씬 편했다. 써봤는데 비용보다 더 체감된 건 반응 속도였다. 기다림이 줄어드니까 기능 자체를 더 자주 쓰게 됐다.

2026년엔 이 차이가 더 또렷하다. OpenAI 쪽도 작은 모델 라인업이 정리됐고, Anthropic이나 Google도 가벼운 모델을 꽤 공격적으로 밀고 있다. 그래서 이제는 “성능 최고”보다 “이 작업에 과한가”를 먼저 보게 된다. 이게 별거 아닌 것 같아도 운영 단계에 들어가면 차이가 꽤 크다.

작은 모델이 잘 먹히는 구간은 생각보다 넓다

내가 주로 먼저 붙여보는 건 세 가지다. 첫째는 반복 업무다. 문장 톤 정리, 태그 생성, 짧은 요약, 문의 분류 같은 건 큰 모델을 쓰면 오히려 사치인 경우가 많았다. 둘째는 실시간성이 중요한 화면이다. 입력창 옆 추천, 자동 제목, 빠른 리라이트처럼 사용자가 바로 체감하는 부분은 1초 안팎 차이도 크게 느껴진다. 셋째는 실패해도 복구가 쉬운 작업이다. 초안이 조금 아쉬우면 다시 돌리면 되니까 부담이 덜하다.

반대로 애매한 요구사항을 길게 해석해야 하거나, 여러 문서를 엮어 판단해야 하거나, 도구 호출까지 이어지는 작업은 아직 큰 모델이 유리했다. 결국 핵심은 “작은 모델도 된다”가 아니라, 작은 모델이 맡을 수 있는 영역을 분리하는 설계다. 이걸 안 하면 매번 비싼 모델만 호출하게 된다.

운영에서 더 크게 보이는 건 비용보다 안정감이다

실제로 붙여보면 비용 절감도 좋지만, 더 마음 편한 건 트래픽이 몰릴 때다. 작은 모델은 응답 시간이 예측 가능한 편이고, 요청량이 늘어도 시스템 전체가 덜 흔들린다. 해봤더니 사용자 만족도는 최고 성능보다 일관성에 더 민감한 경우가 많았다. 늘 0.8초쯤 나오는 답변이, 가끔 8초 걸리는 정답보다 나을 때가 있다.

물론 한계도 있다. 미묘한 문맥 해석, 긴 지시 유지, 예외 상황 판단은 아직 차이가 난다. 그래서 나는 처음부터 하나로 통일하지 않고, 작은 모델을 기본값으로 두고 특정 조건에서만 상위 모델로 올리는 쪽을 더 선호한다. 이 방식이 생각보다 실무적이다. 괜히 폼만 잡지 않아도 된다.

이제는 모델 크기보다 라우팅이 더 중요해졌다

요즘은 어떤 모델이 최고인지보다 어떤 요청을 어디로 보내는지가 더 중요해 보인다. 작은 모델이 맡을 일, 큰 모델이 맡을 일을 구분하고, 실패했을 때 승격시키는 흐름만 잡아도 체감이 확 달라진다. 솔직히 예전엔 성능표부터 봤는데, 지금은 라우터 설계부터 본다. 그게 덜 멋져 보여도 서비스는 훨씬 튼튼해진다.

---

📎 참고 자료

• OpenAI API Models
• Anthropic Claude models overview
• Google Gemini API models