Mistral Large인가 Mistral Medium인가? 한 달간 두 모델을 모두 사용해 본 결과

자, 어떤 일이 있었는지 말씀드리겠습니다. Mistral Large인가 Mistral Medium인가? 한 달간 두 모델을 모두 사용해 본 결과입니다.

지난 3월, 저는 저를 거의 탈진하게 만든 부업을 하나 맡게 되었습니다. 베를린의 한 스타트업 창업자가 두 가지 역할을 동시에 수행하는 고객 지원 챗봇(customer support chatbot)이 필요했습니다. 티켓을 분류(triaging)하고, 상담원을 위한 답변 초안을 생성(generating draft responses)하는 역할이었죠. 문제는 무엇이었을까요? 그는 OpenAI에 매달 800유로를 지출하고 있었고, 고객 지원 품질을 떨어뜨리지 않으면서 그 비용을 절반으로 줄여달라고 저에게 요청했습니다.

그 프로젝트로 인해 저는 실제 유료 클라이언트 작업에 Mistral Large와 Mistral Medium을 비교하는 깊은 연구(rabbit hole)에 빠지게 되었습니다. 저는 4주 동안 약 18시간에 걸쳐 실제 운영 트래픽(production traffic)에 두 모델을 모두 적용해 보았습니다. 중요한 수치들을 포함하여 제가 배운 모든 것을 공유하겠습니다.

이 비교가 왜 중요한가

1인 개발자로서의 현실은 이렇습니다. 모든 API 호출 비용은 제 마진에서 직접 빠져나갑니다. 클라이언트를 위해 작업할 때, 저는 단순히 그들의 비용을 최적화하는 것뿐만 아니라, 저의 작업 완료 시간(time-to-delivery)과 평판까지 최적화해야 합니다. 모델 선택을 잘못하면 클라이언트의 예산을 낭비하게 되거나, 저를 해고하게 만들 쓰레기 같은 답변을 내놓게 됩니다.

Mistral 제품군이 제 눈길을 끈 이유는 Mistral의 가격 구조가 묘하게 적절한 지점(sweet spot)에 있기 때문입니다. DeepSeek 옵션만큼 저렴하지도 않으면서, 최상위 GPT 모델들만큼 비싸지도 않습니다. 품질과 비용 사이에서 균형을 잡으려는 프리랜서에게 이것은 밤잠을 설치게 만드는 결정 사항입니다.

그래서 저는 결심했습니다. 한 달 동안 동일한 프롬프트(prompts)와 동일한 평가 기준(evaluation rubric)을 사용하여 두 모델을 나란히 실행해 보기로 말이죠. 지름길은 없었으며, 유리한 사례만 골라내지도 않았습니다.

가격에 대한 현실 점검

결과를 보여드리기 전에, 제가 다루었던 실제 수치들을 살펴보겠습니다. Global API를 통해 이 클라이언트의 프로젝트를 위해 고려했던 모델들의 현황은 다음과 같습니다:

모델 (Model)	입력 ($/M)	출력 ($/M)	컨텍스트 (Context)
DeepSeek V4 Flash	0.27	1.10	128K
...

GPT-4o 행이 보이시나요? 그것이 제가 오기 전 제 클라이언트가 지불하던 비용입니다. 출력 토큰 100만 개당 10.00달러라는 비용은, 바쁜 고객 지원 봇(support bot)의 경우 순식간에 엄청난 청구서를 만들어낼 수 있습니다. 이전 개발자는 클라이언트에게 "최고의" 모델이 필요하다고 설득해 왔고, 솔직히 말해서 일부 워크로드(workloads)의 경우 GPT-4o가 그 프리미엄을 받을 자격이 있습니다. 하지만 고객 지원 티켓을 분류(triaging)하는 작업에는 그렇지 않습니다.

나의 첫 번째 실수 (그리고 그것이 내게 가르쳐준 것)

솔직히 말씀드리면, 저의 첫 번째 본능은 그냥 가장 저렴한 모델로 교체하고 상황을 종료하는 것이었습니다. 그것은 실수였습니다. 저는 클라이언트의 과거 티켓 일주일 분량을 $0.27/$1.10 가격의 DeepSeek V4 Flash로 돌려보았고, 결과는... 적절했습니다.

internal_compare 워크로드(지원 티켓 분류(triage)의 본질인—새 티켓을 과거 패턴과 비교하여 적절하게 라우팅하는 작업)의 경우, Mistral Medium은 "CFO를 울리지 않을 가격대에 충분히 좋은 품질"이라는 절묘한 지점을 찾아냈습니다.

그다음 Mistral Large를 시도해 보았습니다 (그리고 모든 것에 의구심을 가졌습니다)

강박적인 개발자로서, 저는 다음 단계로 Mistral Large를 테스트해야만 했습니다. Medium이 좋았다면, Large는 분명 더 나을 것이라 생각했으니까요, 그렇지 않나요? 그리고 품질 향상을 고려하면 호출당 비용 차이도 그렇게 극적이지 않았습니다.

저는 일주일 내내 동일한 워크로드에 Large를 실행했습니다. 제가 발견한 결과는 다음과 같습니다:

뉘앙스, 공감, 그리고 세심한 문구 작성이 필요한 복잡한 고객 불만 사항의 경우, Large가 눈에 띄게 더 나았습니다. 이는 "기꺼이 도와드리겠습니다"라고 말하는 것과, 제 클라이언트의 브랜드 가이드라인이 요구하는 톤을 실제로 맞추는 것 사이의 차이와 같습니다.

하지만 유료 업무(billable work)에 있어서 중요한 점은 이것입니다. 들어오는 티켓의 70%는 일상적인 것이었습니다. 비밀번호 재설정, 주문 상태 확인, FAQ 스타일의 질문들 말이죠. 이런 작업에 Large는 과했습니다. 저는 더 저렴한 등급의 모델이 충분히 잘 처리할 수 있는 작업을 위해 프리미엄 가격을 지불하고 있었습니다.

이 지점에서 40-65%의 비용 절감 주장이 저에게 납득되기 시작했습니다. 이는 하나의 모델을 선택해 모든 곳에 사용하는 문제가 아닙니다. 바로 라우팅(routing)의 문제입니다.

클라이언트의 비용을 월 500유로 절감해 준 라우팅 아키텍처

제가 최종적으로 결정한 설정은 다음과 같습니다. 이것은 제가 베를린 스타트업을 위해 실제로 배포한 코드입니다:

import openai
import os
from typing import Literal
...

패턴은 이렇습니다: 분류(classification)에는 가장 저렴한 모델(입력 비용 $0.27인 DeepSeek V4 Flash)을 사용하고, 그 다음 복잡도에 따라 실제 응답 생성(response generation)을 Mistral Medium 또는 Large로 라우팅하는 것입니다.

제 클라이언트의 경우, 라우팅(routing) 비율은 대략 65/35로 나뉘었습니다. 티켓의 약 65%는 Medium 티어에 해당했고, 35%는 Large가 필요했습니다. 계산 결과는 매우 훌륭했습니다. 모든 작업에 GPT-4o를 사용하여 월 800달러를 지출하는 대신, 동일한 볼륨에 대해 응답 품질은 같거나 더 나으면서도 월 비용을 약 300달러 수준으로 낮출 수 있었습니다.

나에게 실제로 중요했던 벤치마크 (Benchmarks)

Global API의 문서에 따르면 Mistral Large는 평균 84.6%의 벤치마크 점수를 기록했다고 하는데, 솔직히 저의 실제 테스트 결과도 그와 일치했습니다. 하지만 마케팅용 벤치마크가 항상 전체 이야기를 다 보여주는 것은 아닙니다.

클라이언트의 데이터를 통해 제가 실제로 측정한 지표는 다음과 같습니다:

• 응답 일관성 (Response coherence): 인간 평가 척도 기준, Large는 91%, Medium은 84%를 기록
• 필요한 편집 시간 (Edit time required): Large는 응답의 평균 8%에 편집이 필요했고, Medium은 평균 22%가 필요했음
• 지연 시간 (Latency): Large는 평균 1.4초, Medium은 평균 1.1초 — 둘 다 허용 가능한 범위 내에 있음
• 처리량 (Throughput): 두 모델 모두 하루 200~300건의 티켓 볼륨을 무리 없이 처리함

지연 시간의 차이는 저를 놀라게 했습니다. Large가 더 느릴 것이라고 예상했지만, 아주 미세하게 뒤처질 뿐이었습니다. 두 모델 모두 초당 약 320 토큰(tokens/sec)의 처리량을 보여주었기에, 트래픽 급증 시에도 병목 현상(bottleneck)을 걱정할 필요가 없었습니다.

실제로 각 모델을 언제 사용해야 하는가

한 달간의 테스트를 거친 후, 이 두 모델 사이에서 선택할 때 제가 사용하는 사고 모델(mental model)은 다음과 같습니다:

Mistral Large를 선택해야 할 때:

• 출력이 인간의 검토 없이 최종 사용자에게 직접 전달될 때
• 미묘한 어조(nuanced tone)나 브랜드 보이스(brand voice)가 중요할 때
• 작업이 복잡한 추론(reasoning)이나 다단계 논리(multi-step logic)를 포함할 때
• 비용보다 품질이 우선시되는 창의적인 콘텐츠를 생성할 때
• 오류 허용치가 낮을 때 (의료, 법률, 금융 문맥)

Mistral Medium을 유지해야 할 때:

• 출력을 다듬을 수 있는 인간이 개입(human in the loop)할 때
• 작업이 충분히 구조화되어 있어 창의성보다 일관성이 더 중요할 때
• 처리량이 많아 호출당 비용(per-call cost)이 누적될 때
• 사용 사례가 내부 비교 또는 분류(classification)와 유사할 때
• 80%의 작업을 잘 처리하는 훌륭한 범용 모델(generalist)이 필요할 때

아무도 말하지 않는 청구 가능 시간(Billable Hours)의 수학

일반적인 API 비교 기사에서는 알려주지 않는 사실이 하나 있습니다. 모델 선택은 고객의 API 비용뿐만 아니라, 개발자인 '당신의 시간'에도 영향을 미친다는 점입니다.

저는 이 비교 프로젝트에 대략 18시간을 소비했습니다. 약 4시간은 초기 통합(integration) 설정을 하는 데 사용했고, 8시간은 두 모델을 나란히 실행하며 결과를 분석하는 데, 그리고 6시간은 라우팅 아키텍처(routing architecture)를 구축하고 배포하는 데 사용했습니다.

제 프리랜서 요율을 기준으로 계산하면, 이는 연구에 투입된 실제 비용입니다. 하지만 모든 과정을 문서화했기 때문에, 다음에 고객이 LLM 비용 최적화를 요청할 때 이 작업 내용을 참조하여 프로젝트 시간을 단축할 수 있습니다. 부업(side-hustle) 학습이 가져다주는 복리 효과입니다.

이 글을 읽고 있는 프리랜서라면, 제 조언은 간단합니다. 모든 모델 비교를 당신의 미래 시간당 요율(hourly rate)에 대한 투자로 취급하십시오. 정밀하게 계산하는(精打细算) 사고방식은 단순히 고객의 돈을 아끼는 것뿐만 아니라, 당신을 더 가치 있게 만드는 의사결정 포트폴리오를 구축하는 과정입니다.

첫날 알았더라면 좋았을 것들

돌이켜보면, 청구 가능 시간(billable hours)을 낭비하게 만든 몇 가지 실수가 있었습니다.

첫째, 처음부터 적절한 평가(evaluation) 체계를 구축했어야 했습니다. 제대로 된 채점 루브릭(scoring rubric)을 만들기 전까지 첫 일주일 동안은 응답 품질을 눈대중으로만 확인했습니다. 저처럼 하지 마세요. 모델 테스트를 시작하기 전에 평가 파이프라인(evaluation pipeline)을 먼저 구축하십시오.

둘째, 캐싱(caching)의 가치를 과소평가했습니다. Global API 문서에서 언급된 40%의 히트율(hit rate)은 달성 가능하지만, 이를 위한 아키텍처를 설계했을 때만 가능합니다. 결국 3주 차에 일반적인 쿼리를 위한 간단한 Redis 캐시를 추가했고, 그것만으로도 비용을 약 15% 더 절감할 수 있었습니다.

셋째, 스트리밍 응답(streaming responses)은 사용자 경험(UX) 측면에서 게임 체인저였습니다. 지연 시간(latency)은 비슷했음에도 불구하고, 스트리밍은 챗봇이 고객의 사용자들에게 훨씬 더 즉각적으로 반응한다는 느낌을 주었습니다. 작은 차이지만 사용자 만족도에는 중요한 요소였습니다.

이를 구현하려는 분들을 위한 간단한 스트리밍 예시입니다:

import openai
import os

...

프리랜서를 위한 결론

만약 시간당 비용을 청구하는 방식이라면, 모델 선택은 프로젝트의 수익성을 결정짓거나 망가뜨릴 수 있는 결정 중 하나입니다. 잘못된 모델을 선택하면 품질이 낮은 출력값(outputs)에 대한 비용을 떠안거나, AI가 만든 결과물을 정리하는 데 수 시간을 허비하게 됩니다.

Mistral Large와 Mistral Medium 중 무엇을 선택해야 하는지에 대한 보편적인 정답은 없습니다. 이는 귀하의 구체적인 작업 부하(workload), 품질 요구 사항, 그리고 사용량에 따라 달라집니다. 하지만 제가 설명해 드린 접근 방식, 즉 복잡도에 기반한 라우팅(route based on complexity) 방식이 대부분의 프리랜서 프로젝트에 가장 적절한 기본 설정일 것입니다.

베를린에 있는 제 클라이언트의 경우, 이 설정으로 현재 3개월째 운영 중입니다. 고객 지원 팀의 만족도는 높아졌고, 비용은 예측 가능해졌으며, 저는 창업자로부터 재계약을 따냈습니다. 이것이 바로 모든 프리랜서가 쫓는 세 가지 요소(trifecta)의 완벽한 조화입니다.

전체적인 통합(integration)을 결정하기 전에 이 모델들을 직접 테스트해 보고 싶다면, Global API를 통해 단 하나의 API 키로 184개의 서로 다른 모델에 접근할 수 있습니다. 설정에는 약 10분 정도가 소요되었으며, 무료 크레딧을 받아 실험을 시작할 수도 있습니다. 직접 살펴보고 싶다면 global-apis.com을 확인해 보세요. 저도 처음에는 통합 API(unified APIs)에 대해 회의적이었지만, 통합 과정에서 절약되는 시간만으로도 제 프리랜서 워크플로우(workflow)를 전환할 가치가 충분했습니다.