# Qwen3.6-Max-Preview: 에이전틱 코딩과 세계 지식이 강화된 차세대 모델 > Clean Markdown view of GeekNews topic #28738. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28738](https://news.hada.io/topic?id=28738) - GeekNews Markdown: [https://news.hada.io/topic/28738.md](https://news.hada.io/topic/28738.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-21T10:05:53+09:00 - Updated: 2026-04-21T10:05:53+09:00 - Original source: [qwen.ai](https://qwen.ai/blog?id=qwen3.6-max-preview) - Points: 1 - Comments: 1 ## Topic Body - 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 제공: 베이징, 싱가포르, 미국(버지니아) ### 개발 상태 - 현재 **프리뷰 릴리스** 단계로 반복 개선 지속 중이며, 이후 버전에서 추가 개선 예정 ## Comments ### Comment 55946 - Author: neo - Created: 2026-04-21T10:05:54+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47834565) - 사람들이 **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](https://github.com/AlexsJones/llmfit)도 한 번 써볼 만함 - 이 분야는 먼저 공짜를 풀어서 이름을 알리고, 나중에 전부 **proprietary**로 바꾸는 식으로 흘러가는 것처럼 보여서 걱정됨. 그래도 open weights는 계속 나와줬으면 함. 아무도 open weights를 내놓지 않는 날이 오면 정말 씁쓸할 것 같음. 그런 세상이 오면 보통 사람은 자기 **compute**를 직접 소유하기 더 어려워질 것 같음 - 그건 좀 과한 일반화라고 봄. 미국 모델들은 처음부터 닫혀 있던 경우가 많았고, 반대로 미국 밖 모델들, 특히 **중국 모델**들은 초반부터 더 개방적이었음. 오히려 중국 쪽은 처음엔 proprietary였다가 나중에 공개로 전환한 경우도 있었고, 큰 Qwen 모델들 중에도 그런 사례가 있었음 - 나는 이게 국가 전략 차원의 움직임처럼 보임. 계속 경쟁력 있는 무료 모델을 공개해서 서구 기업들이 proprietary 모델로 쌓아두려는 **moat**를 약화시키려는 흐름 같음. 중국에 유리한 서사가 유지되는 한, 완전히 proprietary로 돌아설 가능성은 낮다고 봄 - **칩 제조사** 입장에서도 우리가 로컬 모델을 돌릴 수 있는 환경이 유지되는 게 이익일 것 같음 - 맞음. 중국 연구소들에겐 오픈소스가 일종의 **상업 전략**이라고 봄. 모델과 추론 서비스를 알릴 다른 효과적인 마케팅 수단이 부족하니까 그런 선택을 하는 면이 있음. [관련 글](https://try.works/writing-1#why-chinese-ai-labs-went-open-an...)도 참고할 만함 - 원래부터 비슷한 구조였다고 느낌. 결국 이것도 **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 리더보드](https://arena.ai/leaderboard/text/overall?viewBy=plot) 통계도 참고할 만함 - 이 발표의 아이러니는 이름 자체에 있다고 느낌. **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 문서](https://www.alibabacloud.com/help/en/model-studio/context-ca...)도 보고 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](https://code.claude.com/docs/en/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 모델을 직접 써본 기억은 있음