Qwen3.6-Max-Preview: 에이전틱 코딩과 세계 지식이 강화된 차세대 모델

• Qwen3.6-Plus의 후속으로, 전작 대비 에이전트형 코딩과 더 강한 세계 지식 및 지시 이행 성능 향상
• 6개 주요 코딩 벤치마크에서 최고 점수를 기록하며 코딩 에이전트 성능의 대폭 향상 확인
• preserve_thinking 기능을 지원해 에이전틱 작업 시 이전 턴의 사고 과정을 메시지에 보존하는 방식을 사용
• 세계 지식 벤치마크에서는 SuperGPQA +2.3, QwenChineseBench +5.3 등으로 개선됐고, 지시 이행에서는 ToolcallFormatIFBench +2.8 기록
• Qwen Studio에서 대화형 테스트가 가능하며, Alibaba Cloud Model Studio API를 통해 qwen3.6-max-preview로 호출 예정

---

주요 개선 사항

• Qwen3.6-Plus 대비 에이전틱 코딩 역량이 크게 향상: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
• 세계 지식(world knowledge) 강화: SuperGPQA +2.3, QwenChineseBench +5.3
• 명령어 수행(instruction following) 개선: ToolcallFormatIFBench +2.8
• 6개 주요 코딩 벤치마크에서 최고 점수 달성: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

모델 특징 및 접근 방식

• Alibaba Cloud Model Studio를 통해 제공되는 호스팅 독점 모델
• 실제 에이전트(real-world agent) 및 지식 신뢰성(knowledge reliability) 성능 향상
• Qwen Studio에서 대화형으로 즉시 테스트 가능
• API 모델명은 qwen3.6-max-preview이며, Alibaba Cloud Model Studio API에서 곧 사용 가능

API 사용 및 기능

• OpenAI 호환 chat completions 및 responses API, Anthropic 호환 인터페이스 등 업계 표준 프로토콜 지원
• preserve_thinking 기능을 통해 이전 턴의 추론 과정(reasoning content) 을 보존 가능하며, 에이전틱 작업에 권장
• enable_thinking: True 설정 시 추론 내용과 응답을 스트리밍 방식으로 분리 수신 가능
• API 지역별 Base URL 제공: 베이징, 싱가포르, 미국(버지니아)

개발 상태

• 현재 프리뷰 릴리스 단계로 반복 개선 지속 중이며, 이후 버전에서 추가 개선 예정

[GN⁺]

Hacker News 의견들

• 사람들이 SOTA 비교에만 집착하는 게 좀 웃기게 느껴짐. 나는 glm 5.1이 Opus가 못 하던 일을 해낸 경우를 봤고, 코드도 더 잘 짜는 장면을 경험했음. qwen max는 아직 안 써봤지만 로컬 122b 모델이 문서를 더 잘 읽고 더 정확하게 처리하는 모습도 봤음. 결국 벤치마크는 일부일 뿐이고, 실제로는 모델마다 강점이 다르니 망치와 렌치를 단순 우열로 비교하듯 말하면 안 된다고 생각함

  • 나는 개인 프로젝트에서 Ollama Cloud의 pi.dev로 GLM-5.1을 쓰고 있는데 꽤 만족 중임. 회사에서는 pi.dev와 Claude Sonnet, Opus 4.6을 함께 씀. Claude Code도 좋지만 최근 업데이트 이후 너무 자주 compact를 해야 해서 불편했음. pi.dev를 쓸 때는 MCP tool calling이 없어도 API 연동이 잘 돼서 아쉽지 않았음. 오히려 웹사이트 제작은 GLM-5.1이 Claude Opus보다 더 잘한다고 느꼈고, 지금 만들고 있는 풀스택 개발 플랫폼에서도 아주 잘 해주고 있음
  • GLM 5.1은 중국 모델이 정말 따라잡았다고 처음 느끼게 해준 모델이었음. 그래서 Claude Max 구독도 취소했고, 솔직히 전혀 아쉽지 않았음. 사람마다 의견이 갈리는 걸 보면 이제는 절대적인 SOTA 우열보다 도메인과 사용 패턴 차이가 더 중요한 단계에 온 것 같음
  • 내가 Claude와 ChatGPT를 계속 쓰는 거의 유일한 이유는 tool calling 때문임. skills 같은 유용한 기능도 있고 말임. qwen이나 deepseek도 써봤지만 문서 출력조차 잘 안 되는 경우가 있었음. 다들 이런 도구로 문서나 Excel 처리는 어떻게 하는지 궁금하고, 가능하면 나도 갈아타고 싶음
  • 몇 달 전에는 Qwen3-Coder가 Claude Opus나 Google Gemini보다 훨씬 더 나은 Rust 코드를 만들어줬음. 특히 Rust의 x86-64 벡터 확장까지 활용하는 코드를 뽑아줘서 인상적이었음. 나는 Zed editor나 trae CLI 같은 harness에서 호출해 썼는데, 정말 많이 놀랐음
  • 모델들은 벤치마크 점수가 대체로 비슷하고 차이도 작아서, 이런 상황이면 다른 기준으로 고르는 게 합리적이라고 봄. 내 경우에는 JetBrains 플러그인만 괜찮게 나오면 어느 벤더든 바로 옮길 의향이 있음

• 회사에서 몇 달째 Claude Code를 꾸준히 쓰고 있고, 얼마 전에는 작은 개인 웹사이트 프로젝트에도 잘 활용했음. 지난 주말에는 처음으로 self-hosting도 시도해봤음. 비슷하게 CC나 Codex를 충분히 써본 뒤 어느 정도 만족할 만한 자가 호스팅 구성을 찾은 사람이 있는지 궁금함. 나는 32GB DDR5, AMD 7800X3D, RTX 4090, Windows와 WSL 환경에서 ollama, docker desktop model runner, pi-coding-agent, opencode와 Gemma 4, Qwen, GLM-5.1 조합을 이것저것 시험했음. 기본 RAM 사용량이 이미 높아서 Gemma4-31B 같은 좋은 모델은 못 돌렸음. Windows 단독 환경에서는 파일 경로 처리가 자주 꼬였고, WSL에서 pi나 opencode를 돌리고 모델은 docker desktop으로 구동하는 방식은 어느 정도 성공했음. 다만 실제 체감 성능은 CC 대비 너무 느렸고, 도구 완성도도 CC harness 쪽이 훨씬 좋게 느껴졌음. 세팅에 시간을 너무 많이 써서 실제 사용은 길게 못 했지만, 그래도 재미있는 실험이었음

  • MoE 모델을 써보고 추론을 CPU로 오프로딩해보면 좋겠음. Gemma 4 26b-a4b나 qwen3.6 35b-a3b 같은 모델이 예시임. 32GB RAM은 다른 앱까지 켜면 좀 빠듯하긴 하지만, 시스템 RAM만 충분하면 꽤 잘 돌아감. GPU에 일부 레이어를 올리는 방법도 있지만 MoE 모델과 llama.cpp 조합에서는 문제가 있었음. 대신 KV cache를 GPU에 두면 속도가 꽤 잘 나오고 컨텍스트 윈도도 적당히 유지 가능했음. 나는 로컬에서 아주 인상적인 결과를 봤음. 또 WSL2에서 llama.cpp를 직접 클론하고, Claude Code 같은 frontier 모델에게 설치와 튜닝을 맡기는 걸 강하게 추천함. llama.cpp 위에 올라간 앱들은 옵션과 플래그를 다 노출하지 않아서, 플래그 하나만 잘못 줘도 컨텍스트 캐시가 안 되는 식으로 성능이 크게 망가질 수 있음. 소스에서 직접 빌드하면 문제 생길 때 실제 코드를 바로 확인할 수 있음. 그 머신이면 Gemma 4에서 최소 20~40tok/s 정도는 나와서 충분히 실사용 가능할 것 같고, qwen3.6은 활성 파라미터가 3b라 더 빠를 수도 있음
  • 지금 겪는 문제는 아마 VRAM 부족 때문에 모델 전체를 한 번에 못 올리는 데서 오는 현상 같음. llmfit도 한 번 써볼 만함

• 이 분야는 먼저 공짜를 풀어서 이름을 알리고, 나중에 전부 proprietary로 바꾸는 식으로 흘러가는 것처럼 보여서 걱정됨. 그래도 open weights는 계속 나와줬으면 함. 아무도 open weights를 내놓지 않는 날이 오면 정말 씁쓸할 것 같음. 그런 세상이 오면 보통 사람은 자기 compute를 직접 소유하기 더 어려워질 것 같음

  • 그건 좀 과한 일반화라고 봄. 미국 모델들은 처음부터 닫혀 있던 경우가 많았고, 반대로 미국 밖 모델들, 특히 중국 모델들은 초반부터 더 개방적이었음. 오히려 중국 쪽은 처음엔 proprietary였다가 나중에 공개로 전환한 경우도 있었고, 큰 Qwen 모델들 중에도 그런 사례가 있었음
  • 나는 이게 국가 전략 차원의 움직임처럼 보임. 계속 경쟁력 있는 무료 모델을 공개해서 서구 기업들이 proprietary 모델로 쌓아두려는 moat를 약화시키려는 흐름 같음. 중국에 유리한 서사가 유지되는 한, 완전히 proprietary로 돌아설 가능성은 낮다고 봄
  • 칩 제조사 입장에서도 우리가 로컬 모델을 돌릴 수 있는 환경이 유지되는 게 이익일 것 같음
  • 맞음. 중국 연구소들에겐 오픈소스가 일종의 상업 전략이라고 봄. 모델과 추론 서비스를 알릴 다른 효과적인 마케팅 수단이 부족하니까 그런 선택을 하는 면이 있음. 관련 글도 참고할 만함
  • 원래부터 비슷한 구조였다고 느낌. 결국 이것도 SaaS에 가깝고, 차이라면 요즘 frontier lab의 최하위 구독제가 사실상 무료 체험처럼 보인다는 정도임

• 오늘 Kimi K2.6도 같이 나와서 둘을 비교하는 게 꽤 자연스럽다고 봄. 가격만 봐도 Qwen은 입력 1.3달러, 출력 7.8달러인데 Kimi는 입력 0.95달러, 출력 4달러라 Qwen이 더 비싸 보임. 발표 글에서 겹치는 벤치마크도 두 개뿐인데, SWE-Bench Pro와 Terminal-Bench 2.0 모두 Kimi가 Qwen보다 약간 더 높았음. 물론 모델마다 강점이 다르고 벤치마크가 전부는 아니지만, 숫자 기준으로만 보면 Kimi 쪽이 더 매력적으로 느껴짐

  • 중국 모델들 가격이 올라가면서 매력이 좀 떨어졌다고 느낌. 그리고 Gemma-4가 나온 뒤에는 파레토 프런티어에 남는 모델도 많지 않다고 봄. 내 체감도 비슷하고, arena 리더보드 통계도 참고할 만함

• 이 발표의 아이러니는 이름 자체에 있다고 느낌. Max-Preview는 proprietary이고 cloud-only임. 내가 보기엔 진짜 중요한 Qwen은 사람들이 자기 하드웨어에서 돌리는 open weights 시리즈임. 나는 dual A4000으로 32B와 72B를 로컬에서 돌리고 있음. hosted Max와의 격차가 아직 있긴 하지만, 릴리스가 나올 때마다 그 차이가 줄어드는 게 보임. 그래서 진짜 흥미로운 질문은 Max가 Opus와 어떻게 비교되느냐보다, open-weight tier가 언제쯤 대부분의 워크로드에서 cloud tier를 무의미하게 만들 것이냐는 점임

• 다들 SOTA만 쫓아다니는 동안, 나는 MiniMax M2.5로 병렬 세션 여러 개 돌리면서 월 10달러로 코딩 작업을 다 처리하고 있고 제한에도 거의 안 걸리고 있음

  • 진지한 업무라면 월 10달러와 100달러 차이는 대부분의 전문 개발자에게 고민할 가치가 크지 않다고 봄. 학생이나 저소득 국가 사용자 같은 예외는 있겠지만, 고연봉 개발자가 도구 비용을 지나치게 아끼는 걸 보면 늘 의아함. 지금의 SOTA 모델조차도 일회성 작업 이상에서는 완전히 신뢰하기 어렵다고 느끼는데, 거기서 더 낮은 성능 모델을 감시해가며 월 10~100달러를 아끼는 건 전혀 매력적이지 않음. self-hosted 모델은 가벼운 버려도 되는 작업엔 재미있게 실험하고 있지만, 실제 중요한 업무에선 내 시간을 낭비하고 싶지 않음
  • 그 월 10달러는 어디에 내는지 궁금함. OpenRouter인지 물어보고 싶음
  • 그걸 실제로 어떻게 쓰는지 궁금함. opencode를 쓰는지, 아니면 다른 프런트엔드를 쓰는지 알고 싶음

• 나는 Qwen의 context caching 문서도 보고 Opus, Codex, Qwen을 함께 테스트해봤는데, Qwen이 많은 코딩 작업에서 강한 건 맞다고 느낌. 다만 내가 가장 신경 쓰는 건 장시간 세션에서의 동작임. Qwen은 큰 컨텍스트 윈도를 내세우지만 실제 장문맥 효율은 context caching 방식에 크게 좌우되는 것 같음. 공식 문서상 implicit, explicit caching을 모두 제공하지만 TTL이 몇 분 수준으로 짧고, prefix 기반 매칭과 최소 토큰 조건 같은 제약이 있음. 이런 제약 때문에 코딩 에이전트처럼 문맥이 계속 커지는 워크플로에서는 캐시 재사용이 기대만큼 잘 안 될 수 있음. 그래서 토큰당 가격은 낮아 보여도 긴 세션에서는 cache hit rate가 떨어지고 재계산이 늘어나서 체감 비용이 더 높게 느껴질 수 있음. 그래도 보안 관련 작업에서는 개인적으로 Qwen이 Opus보다 더 잘한 경우도 있었음. 내 경험상 Qwen은 개별 메서드나 함수 단위처럼 짧은 작업에서는 Opus보다 훨씬 잘하는 편이지만, 전체적인 코딩 경험으로 보면 Claude처럼 자율적인 end-to-end 코딩 어시스턴트라기보다 함수 단위 생성기에 더 가깝게 느껴졌음

  • 그래도 긴 세션을 짧게 끊고 새로 시작하는 게 best practice인 건 맞다고 봄. Anthropic의 Claude Code Best Practices에서도 "더 좋은 프롬프트를 가진 깨끗한 새 세션이, 수정이 누적된 긴 세션보다 거의 항상 더 낫다"고 안내하고 있음
  • 내가 마지막으로 확인했을 때 기준으로는, context caching은 비용과 지연 시간을 줄여줄 뿐이고 실제로 어떤 토큰이 출력되는지는 바꾸지 않았음

• Qwen 쪽이 Opus 4.5와 비교하는 걸 보면, 그걸 선의로 받아들이기 조금 어렵게 느껴짐. Opus 4.7이 아주 최신이라 빠진 건 이해해도, Opus 4.6은 나온 지 꽤 됐기 때문임

  • 내 기준에서 Opus 4.5는 다양한 문제에서 모델이 충분히 괜찮다고 느껴진 첫 지점이었음. 그전에는 개발 작업에 AI를 쓰면 꼭 환각 때문에 시간이 더 날아가서 생산적인 선택이 아니었음. 그런데 만약 발전이 Opus 4.5에서 멈췄더라도, 우리는 이미 엄청 많은 실전 작업을 빠르게 처리할 수 있었을 거라고 봄. 이제 소프트웨어 개발이 다시 모두 손코딩 중심으로 돌아가진 않을 것 같음. 그래서 Opus 4.5와 비슷하거나 약간 나은 수준을 10분의 1 가격에 제공한다면 많은 사람에게 충분히 매력적일 수 있음. 물론 서구권 개발자 입장에선 Opus 4.7에 월 100달러 이상을 내는 것도 가치가 큼. 낮은 등급 모델이 낭비시키는 시간이 훨씬 비싸기 때문임. 당분간은 덜 시간을 낭비시키고, 더 적은 프롬프트 수정으로 더 좋은 결과를 내는 모델에 프리미엄을 계속 지불할 생각임. 동시에 변화 속도는 정말 놀랍고, 요즘은 오픈 모델도 2년 전 frontier 모델과 경쟁 가능한 수준까지 왔다고 느낌. Qwen 3.6 MoE 35B A3B나 큰 Gemma 4 모델은 성능 좋은 Macbook, Strix Halo, 최근 24GB나 32GB GPU 정도의 평범한 장비에서도 돌릴 수 있고, pre-AI 시절 개발자 노트북보다 훨씬 비싸지도 않음. 코드도 쓰고, 글도 꽤 잘 쓰고, 도구도 쓰고, 문맥 길이도 실전에 충분함. 아직 Opus 4.5만큼은 아니지만 꽤 인상적임. 나도 보안과 코드 리뷰에는 이미 여러 모델을 섞어 쓰고 있고, 대부분의 소프트웨어 개발에선 여전히 Claude Code와 Opus가 가장 좋다고 느끼지만, Qwen도 기꺼이 써볼 생각임. 작은 모델들도 체급 대비 아주 잘해서 큰 모델도 기대하고 있음
  • 돈이 전혀 문제가 아니라면 결국 Codex 5.4나 Opus 4.7 같은 최고 성능만 보면 된다고 생각함. 하지만 많은 사람에게는 비용 대비 품질이 아주 큰 변수임. Claude 구독자들 중에도 비용과 사용량 압박 때문에 Opus 4.7을 항상 못 쓰고 Sonnet이나 예전 Opus를 쓰는 경우가 많음. 그래서 가치 대비 품질 곡선을 보면 이런 비교도 충분히 의미 있다고 봄
  • 최근 몇 달간 Opus 4.6 성능이 너무 들쭉날쭉해서, 굳이 토큰을 낭비하고 싶지 않았음
  • Sonnet 4.6이 나왔을 때 나는 기본 모델을 Opus에서 Sonnet으로 바꿨음. 체감상 Sonnet 4.6이 Opus 4.5급과 비슷했기 때문임. 4.6과 4.7이 더 낫긴 하지만 대부분의 작업에서 도약 폭이 크지 않아서, 이제는 비용 절감이 충분히 합리적인 선택이 됐음. 더 싼 모델들이 그 수준에 도달하면 더 큰 일이고, GLM 5.1도 꽤 가까워 보여서 많이 쓰고 있음. 그런 관점에선 Opus 4.5와 비교하는 것도 타당하다고 봄
  • 비교는 가장 비슷한 대상끼리 하는 게 맞다고 생각함. 그리고 벤치마크를 제공업체가 직접 내놓으면 당연히 자기 모델이 잘하는 프레임워크만 고르고 불리한 건 뺄 가능성이 큼. 그래서 결국 믿을 만한 건 독립 벤치마크라고 봄

• 최근 중국 제공업체들을 보면 패턴이 보인다고 느낌. 첫째는 모델을 closed source로 유지하는 쪽으로 가는 점이고, 둘째는 가격을 꽤 크게 올린다는 점임. 경우에 따라선 100퍼센트 가까이 오르기도 함

  • 그게 마치 중국 기업만의 특징인 것처럼 말하는 건 좀 이상하게 들림. 다른 나라 기업들도 전혀 다르지 않다고 느낌
  • Qwen max는 원래부터 cloud only였고, 1T가 넘는 모델이라 비용이 비쌀 수밖에 없다고 봄
  • 가격을 크게 올린다는 점이 미국 업체와 뭐가 다른지 되묻고 싶음
  • 그 말이 GLM 5.1, DeepSeek V3.2, 방금 나온 Kimi K2.6 같은 모델들에도 해당하는지 묻고 싶음. 막상 그런 사례들엔 잘 안 맞아 보였음
  • 그 수법은 미국 회사들도 정말 좋아하지 않느냐는 반응이 먼저 나옴

• 재미있는 점은, 로컬 실행 가능한 Qwen 모델군 전체는 알고 있으면서도 클라우드 모델 쪽은 전혀 모를 수 있다는 점임. 나는 3.5 계열들과 3.6 하나 정도만 알고 있었고, Plus라는 이름은 이번에야 처음 들었음

  • 내가 기억하기로 Plus 시리즈는 Qwen chat가 공개됐을 때부터 있었음. 적어도 작년 초에 Plus 모델을 직접 써본 기억은 있음