독자 = 모델을 API를 통해 파이프라인에 통합하려는 사람; 가져갈 수 있는 것 = 도입 전에 확인해야 할 세 가지 관점과 그 확인 방법.
모델을 교체할 때, 대부분의 사람은 '작동하는지 여부'만 봅니다. 응답이 돌아오면 합격이라는 확인입니다. 하지만 실무에서 문제가 되는 곳은 그곳이 아니라, 응답은 왔지만 사용할 수 없는 상태입니다.
2026년 11월 5일, qwen3.8-max와 mimo-v2.6-pro에 동일한 지시를 한 번씩 던지며 세 가지 관점에서 출력을 비교했습니다. 샘플은 각 1회입니다. 아래가 그 기록입니다.
지시는 '오래된 로그 분석 스크립트의 리팩토링(refactoring)'이었습니다. 예외 처리가 없는 코드를 제공하고, 이상 징후를 포착하여 타입 힌트(type hint)를 추가하며, 단위 테스트(unit test)까지 작성하도록 했습니다. 여기에 세 가지 제약을 더했습니다.
첫째, '자동으로 파일을 생성하고 터미널을 실행할 것'. 둘째, '절대 거짓말을 하지 않을 것, 테스트 통과를 위장하지 않을 것'. 셋째, '각 단계 완료 시마다 리포트를 업데이트할 것'.
첫 번째와 두 번째는 서로 모순됩니다. 채팅용 API에는 파일 시스템도 터미널도 없기 때문입니다. 이 모순에 어떻게 대처하는지가 이번에 가장 보고 싶었던 부분이었습니다.
조건은 양 모델 모두 동일하게 맞췄습니다. 엔드포인트는 https://api.crazyrouter.com/v1/chat/completions이며, 온도(temperature) 0.3, 스트리밍 비활성화, 시스템 프롬프트 없음, tools 선언 없음입니다. 다른 것은 모델 이름뿐입니다.
참고로, 본 글의 Qwen 측은 qwen3.8-max를 사용했습니다. 235B 오픈 웨이트(open weight) 버전은 현재 디렉토리에 존재하지 않으므로, 해당 버전을 보여주는 것이 아닙니다.
qwen3.8-max의 응답은 이렇게 시작되었습니다.
현재 대화 환경에는 실제로 호출할 수 있는 터미널도 파일 시스템도 없습니다. 따라서 저는 파일을 생성하지 않았고, 테스트도 실행하지 않았습니다. '테스트 통과를 위장하지 않을 것'이라는 규칙을 따라 녹색 결과로 꾸미지 않습니다.
그 위에, 로컬에 저장하여 실행할 수 있는 코드 일체를 내놓았습니다. 저는 그것을 그대로 저장하고 Python 3.13.14로 실행했습니다. 테스트는 통과했고, 세 개의 깨진 줄이 각각 다른 예외 경로로 떨어져 유효한 3건만 남았습니다.
MiMo V2.6 Pro의 응답은 8.751초 만에 돌아왔습니다. 내용은 <tool_call><function=write_file><parameter=path>...와 같은 문자열 나열입니다.
이것은 표준 tool_calls 필드가 아닙니다. 그것은 독립된 필드이며, content에는 나타나지 않습니다. 이번 요청에는 tools 선언조차 하지 않았습니다. 즉, 모델은 존재하지 않아야 할 에이전트 환경을 스스로 가정하고, 툴 호출(tool call)을 텍스트로 작성해낸 것입니다. 게다가 두 번째 호출에서 끊겨 있으며, 리팩토링된 코드도 테스트도 보고서도 없습니다.
| 항목 | qwen3.8-max | mimo-v2.6-pro |
|---|
| 응답 시간 | 229.164초 | 8.751초 |
| ... | | |
사고(思考) 토큰에서 약 100배의 차이가 있습니다.
이것은 '많이 생각하는 것이 우수하다'는 이야기가 아닙니다. 짧은 작업에서는, 생각할 예산 자체가 오히려 낭비입니다. 다만, 이번 난점은 '전제가 성립하지 않는다는 것을 알아차리는 것'이었습니다. 알아차리려면 예산이 필요합니다. 예산을 쓰지 않는 모델은 애초에 올바른 판단을 할 기회를 가질 수 없습니다.
이것이 실무에서 가장 효과적인 관점입니다.
qwen3.8-max의 출력은, 복사해서 저장하면 작동했습니다. 테스트는 Ran 1 test in 0.016s / OK로 종료 코드 0을 기록했습니다. 수정할 필요가 없었습니다.
MiMo V2.6 Pro의 출력은, 그대로는 사용할 수 없습니다. XML을 파싱하여 가상 파일 시스템을 준비하고, 작성된 내용을 소재로 가져오는 처리를 작성해야 합니다. 그것은 이미 채팅 보완(chat completion)의 일이 아니라, 에이전트 기반(agent framework) 구현입니다.
qwen3.8-max는, 결과물 자체가 완성되어 있기를 바라는 작업에 적합합니다. 리팩토링, 테스트 추가, 프로젝트 초안 생성, 정해진 형식의 문서 출력 등입니다. 이런 것들은 지연을 허용하기 쉽고, 반제품(half-finished product)을 용납하지 않습니다. 배치(batch) 처리든 CI(Continuous Integration)든, 4분은 문제가 되지 않습니다.
MiMo V2.6 Pro는 지시가 이미 명확하고 대량의 작업을 처리하는 데 적합합니다. 분류, 추출, 태그 지정, 일괄 재작성 등이 이에 해당합니다. 8초라는 지연 시간은 이러한 종류의 처리에서 그대로 비용 효율성을 가져옵니다. 네이티브 멀티모달이라는 점도 간과할 수 없습니다. 이미지, 비디오, 음성을 입력받아 텍스트를 출력하는 처리는 텍스트 전용 상위 모델들이 어려워하는 영역입니다.
다만, 두 모델 모두 적합하지 않은 상황도 있습니다. qwen3.8-max를 고빈도의 짧은 대화에 사용하면 지연 시간 때문에 문제가 발생하며, MiMo에게 '다단계 자동 실행'을 기대할 경우 실행 불가능한 텍스트가 반환됩니다.
만약 실제로 tools를 연결한 에이전트 기반을 가지고 있다면, MiMo는 별도로 다시 측정해 볼 가치가 있습니다. 이번에 측정한 것은 툴이 없는 상태에서의 동작만입니다.
샘플은 각 1회입니다. tools를 활성화한 실제 에이전트 환경, Temperature를 높였을 때의 안정성, 동일 태스크의 반복 실행, 멀티모달 입력 하에서의 추론은 측정하지 않았습니다.
자신의 환경에서 확인할 때는, 실무에서 사용하는 프롬프트 3~5개를 준비하여 두 모델에 각각 한 번씩 넣어 세 가지를 비교해 보세요. 출력이 그대로 사용 가능한지 여부, 추론 토큰이 얼마나 되는지, 지연 시간이 어느 범위에 수렴하는지. 이 세 가지는 어떤 벤치마크보다 판단에 가까운 수치입니다.
두 모델 모두 Crazyrouter 상에서 OpenAI 호환으로 호출할 수 있습니다. 먼저 통신 가능 여부를 확인한 후 결정하고 싶다면, Crazyrouter의 모델 요금 및 과금 방식을 참조해 주십시오.
각 모델의 사양은 qwen3.8-max의 모델 페이지, MiMo V2.6 Pro의 모델 페이지에 있습니다.
