Mistral이 MoE 대세를 거스르고 128B Dense 모델을 낸 이유
Mistral Medium 3.5의 128B Dense 아키텍처 선택 배경과 Le Chat의 비동기 클라우드 코딩 에이전트 Vibe, Work 모드 병렬 도구 호출 실무 가이드
2026-08-14 · 최초 발행 2026-05-04
2026년 4월 29일 Mistral AI가 128B 파라미터 덴스(Dense) 모델인 Mistral Medium 3.5를 MIT 라이선스 오픈 웨이트로 공개하고, Le Chat 플랫폼에 에이전틱 Work 모드와 클라우드 기반 비동기 코딩 세션 기능을 추가했다. SWE-Bench Verified에서 77.6% 점수를 기록하며 Devstral 2, Qwen3.5 397B A17B를 앞선 이 모델은 256K 컨텍스트 윈도우와 함께 명령 이행·추론·코딩을 단일 가중치 세트로 처리한다.
MoE가 대세인 시대에 Dense를 고른 이유
AI 업계의 주류 트렌드가 MoE(Mixture of Experts)로 기울어진 상황에서 Mistral이 128B 완전 덴스(Dense) 모델을 선택한 것은 의도적인 역행이다.
MoE(Mixture of Experts) 아키텍처는 총 파라미터 수는 방대하지만, 각 토큰 처리 시 라우터가 일부 전문가(expert) 서브네트워크만 활성화한다. DeepSeek V4-Pro의 경우 1.6조 파라미터 중 490억만 활성화된다. 추론 시 활성 파라미터가 적어 처리 속도가 빠르고 비용이 낮지만, 전문가 간 로드 밸런싱, 라우팅 오버헤드, 전문가 붕괴(expert collapse) 등의 복잡한 문제를 수반한다.
Dense 아키텍처는 모든 토큰에서 모든 파라미터가 활성화된다. 128B 파라미터가 매 토큰마다 완전히 연산에 참여하므로, 주어진 파라미터 수에서 이론적으로 최대한의 표현력을 발휘한다. 대신 추론 비용이 활성 파라미터 수에 비례하므로 MoE 대비 높다.
Mistral이 Dense를 선택한 이유는 일관성과 예측 가능성이다. Dense 모델은 어떤 입력에서도 동일한 용량의 파라미터가 처리에 참여하므로, 특정 도메인에서 전문가 부재로 인한 품질 저하 없이 균일한 성능을 제공한다. 코딩·추론·명령 이행이라는 서로 다른 태스크를 단일 모델로 처리할 때 이 일관성이 특히 중요하다.
양자화(Quantization) 전략도 128B Dense 모델 실용화의 핵심이다. FP16 기준 128B 모델은 약 256GB VRAM을 요구하지만, INT8 양자화 시 128GB, INT4 시 64GB로 줄어든다. GPTQ, AWQ, GGUF 등의 양자화 포맷이 품질 손실을 최소화하면서 소비자 하드웨어에서의 실행을 가능하게 한다. Mistral Medium 3.5가 MIT 라이선스 오픈 웨이트로 공개된 만큼, 커뮤니티가 다양한 양자화 버전을 제공하는 것도 채택 확대에 기여한다.
클라우드로 세션을 텔레포트하는 코딩 에이전트, Vibe
Mistral이 Le Chat에 추가한 Vibe 기능은 클라우드 기반 비동기 코딩 에이전트다. 기존 AI 코딩 도구가 로컬 IDE 플러그인 형태로 동기적으로 동작하는 것과 달리, Vibe는 클라우드 격리 샌드박스에서 독립적으로 실행된다.
핵심 아키텍처는 세 원칙으로 구성된다. 비동기 실행(Async Execution)에서는 사용자가 작업을 요청하면 Vibe 에이전트는 클라우드 샌드박스에서 독립적으로 실행되며, 사용자는 연결을 끊어도 된다. 에이전트가 작업을 완료하면 슬랙 메시지나 이메일로 결과를 알려, 사용자는 매 단계를 지켜볼 필요 없이 결과만 검토하면 된다. 상태 지속성(State Persistence)은 로컬 터미널 세션을 클라우드로 "텔레포트"할 수 있게 한다. 로컬에서 시작한 작업의 컨텍스트(파일 상태, 환경변수, 작업 히스토리)가 클라우드로 마이그레이션되므로 세션 히스토리나 태스크 상태를 잃지 않는다. 투명한 승인(Transparent Approval)에서는 모든 도구 호출과 추론 단계가 사용자에게 공개되며, 민감한 작업(코드 푸시, 파일 삭제 등)은 명시적 승인이 필요하다. 에이전트가 자율적으로 GitHub PR을 열고 사용자에게 검토 링크를 전송하는 방식으로 워크플로우가 완성된다.
비동기 코딩 에이전트의 작업 큐 설계에서 중요한 것은 멱등성(idempotency)이다. 네트워크 장애나 샌드박스 재시작으로 인해 작업이 재시도될 때, 동일한 작업이 두 번 실행되지 않도록 작업 ID 기반의 중복 실행 방지 로직이 필요하다. 각 코딩 세션은 고유 UUID를 가지며, 완료·실패·재시도 상태가 영속 저장소에 기록된다.
Work 모드는 도구를 순서대로 부르지 않는다
Work 모드는 Vibe 코딩 에이전트와는 별개로, 이메일·캘린더·문서·Jira·Slack을 아우르는 업무 자동화 에이전트다. Mistral Medium 3.5를 기반으로 도구를 병렬로 호출하며 멀티스텝 작업을 완수한다.
Work 모드의 기술적 특징은 도구 병렬 호출(Parallel Tool Calling)이다. 예컨대 "이번 주 미팅 요약하고 Jira 티켓 업데이트해줘"라는 요청에 대해 에이전트는 캘린더 조회와 Jira API 호출을 순차적이 아닌 병렬로 실행하여 전체 응답 시간을 단축한다. 각 도구 호출의 결과가 다음 도구 호출의 입력이 되는 의존 관계가 있을 때만 순차 실행으로 전환된다.
같은 소식 속의 의료 AI: 응급실 트리아지에서 의사를 앞선 o1
포스트에서 언급된 또 다른 주목할 성과는 OpenAI o1이 응급실 환자 트리아지(triage) 정확도 67%로 트리아지 의사를 능가했다는 연구다. 이는 의료 도메인에서 LLM 적용의 새로운 기준점을 제시한다.
의료 도메인 LLM 적용 시 신뢰성 평가 방법론은 일반 벤치마크와 다르다. 의료적 오류는 회복 불가능한 결과를 낳을 수 있으므로, 정확도 외에 오류 유형 분석이 핵심이다.
트리아지에서 치명적 오류는 높은 위험 환자를 낮은 위험으로 잘못 분류하는 것이다. 이 오류는 과잉 트리아지(낮은 위험을 높음으로 분류)보다 훨씬 심각하다. 따라서 의료 LLM 평가에서는 전체 정확도보다 민감도(sensitivity)와 치명적 오류율을 우선시한다. o1이 트리아지 의사를 능가했다는 67% 정확도는 이 맥락에서 해석되어야 하며, 실제 임상 배포를 위해서는 더 엄격한 안전성 검증이 요구된다.
Mistral Medium 3.5의 128B Dense 아키텍처 선택은 MoE의 복잡성을 피하고 균일한 성능 일관성을 택한 실용주의적 결정이다. Le Chat의 Vibe 비동기 코딩 에이전트는 AI 코딩 도구가 로컬 동기 보조에서 클라우드 자율 에이전트로 진화하는 방향을 구체적으로 구현했다. 작업 큐·상태 지속성·투명한 승인·PR 자동화로 구성된 Vibe 아키텍처는 개발자가 결과를 검토하는 시간만 투자하도록 설계됐다.
Sources
- Mistral AI Launches Remote Agents in Vibe and Mistral Medium 3.5 | MarkTechPost
- Mistral Medium 3.5 Folds Chat, Reasoning, and Code Into One 128B AI Model | WinBuzzer
- Remote agents in Vibe. Powered by Mistral Medium 3.5 | Mistral AI
- Mistral Launches Medium 3.5 and Cloud-Based Remote Agents for Async Coding | Open Data Science
- Mistral Medium 3.5: The Model Powering Async AI Coding Agents | Medium
- Mistral AI unveils Medium 3.5 model and Work Mode for Le Chat | Testing Catalog
- Mistral Medium 3.5 launches with dense 128B model and remote coding agents | AlternativeTo