미스트랄 스몰 4 reasoning_effort 다이얼, 직장인 일감 5개로 굴려본 후기
지난주에 200줄짜리 VBA 객체 누수를 'none'으론 못 잡았는데, 'high'로 올리니 3턴 만에 찾아주더라고요. 같은 모델인데 말이죠. 미스트랄 스몰 4(Mistral Small 4) 다이얼 실전 후기입니다.
미스트랄 스몰 4 reasoning_effort 다이얼이 대체 뭔가요
한 모델에 추론을 켜고 끄는 토글이 달렸다고 보시면 됩니다. 공식 문서 기준 reasoning_effort 는 현재 none 과 high 두 값만 받는 2단 다이얼이에요. 모델 ID는 mistral-small-2603, 119B 파라미터 MoE 구조에 토큰당 활성은 6B 정도라고 해요. 256K 토큰까지 받아주는데요. 256K가 어느 정도냐면, A4 용지로 따지면 500장쯤 통째로 밀어넣을 수 있는 양입니다.
핵심은 챗 컴플리션 API 요청에 reasoning_effort 파라미터 하나만 끼우면 같은 가중치 위에서 두 인격이 토글된다는 점입니다. none이면 사고 과정 없이 바로 답하는 미스트랄 스몰 3.2급, high로 올리면 단계별 사고 청크를 본문 앞에 줄줄이 뽑아주는 마지스트랄(Magistral)급으로 굴러가지요.
가격은 입력 100만 토큰에 $0.15, 출력은 $0.60. 프롬프트 캐싱을 태우면 반복되는 입력 비용은 더 떨어지는데, 정확한 캐시 할인율은 공급자별 정책을 확인하시는 게 안전합니다. 다만 high 모드의 사고 청크는 전부 출력 토큰으로 카운트된다는 점, 이거 모르고 남용하면 청구서가 훌쩍 튀어버릴 수 있으니 주의하셔야 되는데요.
메일·요약·OCR 자동화는 'none' 모드가 정답
속도가 중요하고 추론이 오히려 방해되는 자리에는 무조건 none입니다. 한 주 굴려본 일감 중 세 가지가 여기에 들어갔어요.
- 회의록 5줄 요약 — 사고 청크 없이 바로 떨어집니다. 한국어 존댓말도 깔끔해요.
- 고객 클레임 메일 톤 수정 — 짧은 답장 다듬는 일이라 굳이 단계별 추론이 필요 없습니다.
- 보고용 이미지 표 추출(OCR) — 이게 의외였는데, high로 돌리면 모델이 셀 구조를 제멋대로 해석해서 오히려 틀리더라고요. 멀티모달 인식만 깔끔하게 빌려쓰는 게 정답이었습니다.
세 가지 다 high 대비 출력 토큰이 1/4 수준으로 떨어지는 게 체감됩니다. 점심값 한 끼 차이를 우습게 보면 안 되는 게, 5인 팀 한 달이면 몇 만원 단위로 벌어지는 일이거든요.
분류·번역도 'high'가 한 수 위 — 다단계 다이얼은 향후 지켜볼 자리
한 가지 짚어둘 점은, 출시 시점에는 low 나 medium 같은 중간 단계가 공개돼 있지 않다는 거예요. 지금은 none 과 high 두 값만 토글되는 구조라, 라우팅 설계도 이 이분법 위에서 짜는 게 안전합니다. 추후 미스트랄이 중간 단계를 추가해줄지는 지켜볼 자리지요.
다만 none 과 high 사이에는 분명한 골이 있더라고요. 회의록 단순 요약은 none이 충분한데, 같은 회의록을 "결정 사항 / 액션 아이템 / 미해결 이슈" 셋으로 분류해달라고 시키면 얘기가 달라집니다. none에선 누락이 눈에 띄게 잡혔는데, high로 올리니 거의 다 짚어주더라고요. 영한 번역에서도 능동·수동태 전환이나 어미 처리가 한층 자연스러워집니다.
다만 사고 청크가 영어로 새어나오는 일이 종종 있어서, 시스템 프롬프트에 "think in Korean"을 박아두는 게 안전합니다. 비용은 사고 청크가 그대로 출력 토큰으로 잡혀 none 대비 꽤 올라가지만, 분류 정확도와 추론 로그를 같이 얻을 수 있다는 점에서 분류·번역 자리는 high가 합리적이라고 봅니다.
계약서 분석·VBA 디버깅에서 살아나는 'high' 모드
high로 올려야 본전 뽑는 자리는 두 군데입니다.
1. 계약서 리스크 분석
NDA의 비밀유지 기간, 손해배상 한도, 준거법 조항 같은 걸 단계별로 짚어달라고 시켜봤습니다. none에선 "OO조가 불리해 보입니다" 정도로 두루뭉술하던 게, high에선 "이 조항이 다른 조항과 충돌하므로 ~한 경우 분쟁 소지가 있다"는 식으로 근거를 잡아주더라고요. 미스트랄이 GPQA·MMLU-Pro 같은 추론 벤치에서 동급 오픈모델(GPT-OSS 120B 등)과 경쟁력 있는 점수를 냈다고 내세우는 강점이 체감되는 자리가 바로 여기였어요.
2. 엑셀 VBA 코드 디버깅
도입에 적은 그 사례입니다. 200줄짜리 매크로에 객체가 어디서 누수되는지 none으론 끝까지 못 짚었는데, high로 올리니 "Set obj = Nothing 호출이 빠진 분기"를 3턴 안에 잡아줬어요. 에이전트형 코딩 능력과 단계별 추론이 같이 도는 자리에선 확실히 다른 모델로 보입니다.
다만 주의할 점이 있어요. 민감 문서를 high로 분석하면 사고 청크에 사내 표현이 영어로 그대로 기록될 여지가 있습니다. 후처리로 thinking chunk를 잘라내는 절차를 안 깔면 컴플라이언스에서 걸리니, 사내망 배포라면 처음부터 chunk 제거 파이프라인을 같이 설계하시는 게 좋겠습니다.
한 주 굴려본 결산과 한국 직장인 활용 팁
5인 팀 기준으로 한 주 굴려보니 4,200원 정도 나왔어요. 같은 작업을 GPT-4o로 돌렸을 때보다 훨씬 저렴했고, 반복 컨텍스트에 프롬프트 캐싱까지 태우면 차이는 더 벌어집니다. 비용 절감의 진짜 핵심은 다이얼 조절보다 캐시 활용이라고 보시면 되겠습니다.
다만 한국어 품질은 아직 변수입니다. 공식 한국어 벤치마크가 따로 공개되지 않은 상황이라, 큐원(Qwen) 계열과의 한국어 비교는 일단 변수로 두고 직접 테스트해보시는 게 안전합니다. high 모드 사고 청크가 영어로 흘러나오는 것도 같은 결의 한계입니다.
사내망 배포를 검토하신다면 Apache 2.0 라이선스는 분명 매력적입니다. 다만 활성 파라미터가 6B여도 119B 전체 가중치를 메모리에 올려야 해서 VRAM은 80GB 이상이 필요하다는 점, 인프라 견적부터 먼저 잡으셔야 합니다.
개인적으로는 다이얼을 4단이니 5단이니 잘게 쪼개길 기다리기보다, 지금 주어진 none / high 두 값만으로 업무 카테고리별 라우팅을 박아두는 쪽이 훨씬 깔끔하다고 봅니다. 메일·OCR·요약은 none, 분류·번역과 계약서·코드는 high로 박아두면 한 달 청구서가 다르게 찍힙니다.
지난주 그 VBA 객체 누수 한 줄이 다이얼 한 칸 올렸다고 잡혔다는 게, 사실 저한테는 그게 이 모델의 전부였던 한 주였어요.