커버는 본 비교의 주제를 보여주는 이미지입니다. 제품 화면의 스크린샷이 아닙니다.
두 모델을 같은 입구(entry)와 같은 파라미터로 19문항에 걸쳐 돌려 비교했습니다.
결론부터 말씀드리자면, 코드 수정/구현/도구 연동의 9문항은 두 모델 모두 만점을 받았습니다. 하지만 이 작은 테스트만으로는 일반적인 코딩 능력이 동등하다고 말하기는 어렵습니다.
차이점 중 하나는 출력 형태였습니다. MiniMax M3는 사고 과정(thinking process)과 최종 답변을 같은 content 필드에 반환하는 경우가 있어, 엄격한 형식을 요구하는 문제에서는 답변 내용뿐만 아니라 출력 전체가 판정에 영향을 미쳤습니다.
이 글은 그 현상을 측정하는 방법과 실무에서 어떻게 다룰지를 정리한 것입니다.
| 항목 | 값 |
|---|
| 입구 | api.crazyrouter.com/v1 |
| ... | |
| 19문항은 7개 카테고리로 나누었으며, 가중치는 실무에서 마주칠 빈도 높은 순서로 설정했습니다. | |
| 카테고리 | 문항 수 | 가중치 | 판정 방법 |
|---|---|
| 코드 수정 | 3 | 20% | 테스트 실행, 종료 코드 0 |
| ... |
구현 관련 문제는 실제로 작동하는 작은 프로젝트입니다. 버그가 있는 소스 파일과 테스트 파일을 두고, 모델 스스로가 파일을 읽고 쓰고, 테스트가 통과할 때까지 수정하게 합니다. 판정은 테스트 파일의 실행 결과 그 자체이며, 문장의 모양새는 평가하지 않습니다.
19문항을 하나씩 자동 판정했습니다 (2026년 10월 20일 실측).
| 카테고리 | 가중치 | MiniMax M3 | DeepSeek V4-Pro |
|---|---|
| 코드 수정 | 20% | 3/3 | 3/3 |
| ... |
'지시 추종(Instruction Following)'에서 0 대 3이 눈에 띕니다. 출력 형태가 판정에 영향을 준 측면은 있지만, 이것만으로는 능력 차이가 있는지 결론 내릴 수 없습니다.
M3의 응답을 하나씩 분해하여 사고 과정이 본문에 섞여있는지 확인했습니다.
19문항 전체에서 최소한 한 번은 사고 과정이 본문에 혼입되어 있었습니다. V4-Pro는 0문항입니다.
우연적인 것이 아니라, 고유의 동작 방식입니다.
영향이 가장 큰 것은 형식 지정이 있는 문제였습니다. 다음 3문항은 원시 출력(raw output) 판정에서 모두 불합격했습니다.
- 정확한 JSON을 하나만 출력하는 문제
- 세 단어를 파이프(|)로 구분하여 출력하는 문제
- 상수 값만 답변하는 문제
저장 기록을 확인해보니, 처음 2문항은 요구된 내용이 포함되어 있었지만, 그 앞에 사고 텍스트가 섞여 있었습니다. 3문항은 사고 블록이 닫혀있지 않아, 답을 확실하게 추출할 수 없습니다. 따라서 '사고를 제외하면 3문항 모두 통과'라고 말할 수 없습니다.
판정의 첫 단계는 문자열 비교가 아니라, 응답을 '본문(本文)'과 '사고(思考)'로 나누는 것입니다. 여기서 가장 놓치기 쉬운 것이 닫히지 않은 사고 블록입니다. 시작 태그와 종료 태그 사이만 추출하는 구현으로는, 종료 태그가 없는 응답을 본문으로 생각하고 사고 과정으로 취급해 버립니다. 올바른 처리는, 시작 태그는 있으나 종료 태그가 없을 경우, 시작 태그부터 끝까지 전부를 사고로 간주하고 그 바로 앞 부분만을 본문으로 하는 것입니다.
응답을 볼 때 확인해야 할 점은 4가지입니다.
| 확인 항목 | 바람직한 상태 | 문제가 있는 상태 |
|---|---|
| 사고 전용 필드 유무 | 있음 | 없음 (본문에 섞임) |
| 본문 내 사고 태그 | 출력되지 않음 | <think> 등이 나옴 |
| 사고의 폐쇄성 | 시작과 종료가 일치함 | 시작만 되고 끝남 |
| 사고 제거 후 본문량 | 실질적인 내용이 있음 | 거의 0 (미답변) |
이는 연결 전 확인 항목입니다. 사고가 본문에 섞여 있는 경우, 실제 응답에서 제거 규칙을 검증해야 합니다. 특히, 시작 태그만 있고 끝난지 않은 미폐쇄 블록을 일반 본문으로 취급하지 않는 것이 중요합니다.
V4-Pro가 만능인 것도 아닙니다. 장문 카테고리에서 1문항을 놓쳤습니다.
400줄의 운영 로그에서 288번째 줄에 있는 키를 찾는 문제입니다. M3는 찾아내어 올바른 값을 반환했습니다. V4-Pro는 6턴 전체를 파일 읽기에 사용하며, 누적 42766 입력 토큰을 소모했지만 본문을 한 줄도 반환하지 않았습니다.
오답이 아니라, 멈추지 못했던 것입니다.
이 실패는 벤치마크 표에 나타나지 않습니다. 잘못된 답조차 반환하지 않았기 때문입니다. 하지만 실제로는 청구와 대기 시간으로 남습니다. 4만 토큰 이상을 지불하고 빈 문자열을 받게 되는 것입니다.
각 문항의 전체 턴을 포함한 총 시간입니다. 단일 요청의 레이턴시가 아닙니다.
| 지표 | MiniMax M3 | DeepSeek V4-Pro |
|---|
| 1문제당 평균 시간 | 29.1초 | 11.7초 |
| ... | | |
| 이 실행에서, M3의 평균 턴 수는 4.1회였고, V4-Pro는 2.9회였습니다. 평균 소요 시간의 차이에는 턴 수 이외의 요인이 포함됩니다. 대화형 제품에서는 이번 11.7초와 29.1초의 차이가 대기 시간에 영향을 미칩니다. | | |
이번 총액은 M3가 0.061달러, V4-Pro가 0.074달러로, M3가 약 17.6% 더 낮았습니다. 단가만으로는 총액을 예측할 수 없으며, 다른 태스크에서는 비율이 달라질 가능성이 있습니다.
여기서 제 실수를 하나 정정하겠습니다. 사전에 작은 버그 수정 문제를 1문제만 시도했을 때, V4-Pro는 1600 이상의 사고 토큰(thinking token)을 소비하여 단가 환산으로 10.6배가 되었습니다. 이를 근거로 삼으려 했지만, 19문제 규모에서는 성립하지 않습니다. 1문제에서 10배의 차이가 나더라도, 19문제에서는 같은 수준이 됩니다.
| 어떤 사람/용도인가 | 먼저 시도해 볼 후보 | 이 실측 결과로 알 수 있는 것 |
|---|
| API 개발자. 답변을 JSON 파싱이나 자동 처리에 전달할 경우 | DeepSeek V4-Pro | 이번에는 고정 형식의 3문제를 통과했습니다. 자신의 API 계약으로도 검증해 보세요 |
| ... | | |
| 마지막 항목을 보충합니다. 이번 검증은 OpenAI 호환 엔드포인트를 통해 이루어졌습니다. M3의 네이티브 프로토콜에서 사고 과정(thinking)이 독립된 필드가 될지는 미검증입니다. 비폐쇄적인 사고 블록(unclosed thinking block)은 답변 부분을 안전하게 분리할 수 없으므로, 검증이 완료될 때까지는 태그를 기계적으로 제거하지 말고, 그 응답을 이용 불가능으로 취급해 주십시오. | | |
두 모델 모두 같은 플랫폼에서 동일한 키를 공유하고 있으므로, 전환은 모델 이름 변경만 하면 됩니다. 시도 비용이 낮으므로, 실제 트래픽에서 4가지 항목을 확인하는 것이 빠르다고 생각합니다.
- 코드 수정/구현/툴 연동의 9문제는 양쪽 모두 통과했습니다. 다만 일반적인 능력 차이를 보여주는 결과는 아닙니다.
- 차이는 출력 형태입니다. M3는 사고 과정이 본문에 혼입되어 19문제 전체에서 발생했습니다.
- 서식 지정의 3문제는 원시 출력(raw output)으로 불합격했습니다. 내용을 확인할 수 있었던 것은 2문제였고, 나머지 1문제는 답변을 확실하게 추출할 수 없었습니다.
- V4-Pro는 빠르지만, 장문에서 멈추지 못하고 본문을 반환하지 않는 실패가 있습니다.
- 선정 시에는 정답률뿐만 아니라 사고 과정이 본문에 섞이지 않는지를 확인해야 합니다.
API에 그대로 연결할 사람이나 응답 속도를 중시하는 사람은 V4-Pro부터 시도하는 것이 적절합니다. 배치 비용을 절감하고 싶은 사람은 M3를 자신의 태스크로 작게 검증해 보세요. 장문(long text)을 다루는 사람에게는 이번 결과만으로는 추천할 수 있는 승자가 없습니다. 최종 판단에서는 정답률뿐만 아니라 '그대로 사용 가능한 출력'의 비율, 완료까지 걸리는 시간, 완료 결과당 비용을 비교해야 합니다.
본 기사의 데이터는 2026년 10월 20일 시점의 실측입니다. 각 문제당 단 1회 실행으로 경향을 파악하기에는 충분하지만, 소수점 둘째 자리 논의를 하기는 부족합니다.
