Qwen3.6-Max-Preview 출시: AI 에이전트 개발자가 알아야 할 것들 (id.news.hada.io)

한줄 요약

Qwen3.6-Max-Preview, 에이전트 코딩 특화 모델로 프리뷰 출시 — 전작 대비 SkillsBench +9.9 향상.

Alibaba의 Qwen 팀이 Qwen3.6-Plus의 후속 모델인 Qwen3.6-Max-Preview를 공개했다. 에이전트 스타일 코딩, 세계 지식, 명령어 추종 능력을 전반적으로 끌어올린 호스팅 전용 독점 모델이며, 현재는 프리뷰 단계로 Alibaba Cloud Model Studio와 Qwen Studio에서 제한적으로 접근할 수 있다.

무엇이 달라지나?

전작인 Qwen3.6-Plus 대비 수치로 확인된 주요 개선 항목은 다음과 같다.

에이전트 코딩 벤치마크

• SkillsBench: +9.9
• SciCode: +6.3
• NL2Repo: +5.0
• Terminal-Bench 2.0: +3.8

세계 지식

• SuperGPQA: +2.3
• QwenChineseBench: +5.3

명령어 추종

• ToolcallFormatIFBench: +2.8

공식 발표에 따르면 SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode 등 6개 주요 코딩 벤치마크에서 최고 점수를 기록했다고 밝히고 있다. 다만 이는 자체 발표 기준이므로 독립 검증 데이터와의 비교는 별도로 확인이 필요하다.

API 모델명은 qwen3.6-max-preview이며, 이번 릴리스에서 주목할 만한 기능은 preserve_thinking이다. 이전 대화 턴의 추론 내용(thinking content)을 다음 요청에 그대로 유지하는 방식으로, 에이전트 스타일 태스크에서 맥락 손실을 줄이는 데 효과적으로 설계됐다.

인프라 측면에서는 OpenAI Chat Completions API, OpenAI Responses API, Anthropic API 형식을 모두 지원한다. 기존 Claude나 GPT 기반 파이프라인을 운영 중인 팀이라면 별도의 SDK 교체 없이 엔드포인트와 키만 바꿔서 테스트해볼 수 있는 구조다.

실무에서 어떤 의미인가?

이 모델의 포지셔닝을 읽는 데 있어 벤치마크 숫자보다 더 중요한 맥락이 있다.

첫째, 에이전트 태스크에 최적화된 방향성이다. 단순 질답이나 단발성 코드 생성이 아니라, 멀티턴 추론과 도구 호출이 반복되는 워크플로우를 타깃으로 삼고 있다. preserve_thinking 기능이 이를 뒷받침하는 핵심 설계다. 긴 에이전트 루프에서 모델이 이전 추론 과정을 "기억"한다는 것은 실제로 의사결정의 일관성에 직결된다.

둘째, 오픈 소스 진영과의 격차 문제다. 커뮤니티 반응을 보면 이미 로컬에서 Qwen 32B, 72B를 운영하는 개발자들이 적지 않다. 이들이 공통적으로 지적하는 것은 "호스팅 Max 모델과의 격차가 릴리스마다 줄어들고 있다"는 점이다. 결국 Max-Preview의 진짜 경쟁자는 타사 클라우드 모델이 아니라 자사 오픈 웨이트 시리즈일 수 있다.

셋째, 컨텍스트 캐싱 전략을 실무 도입 전에 검토해야 한다. 긴 세션을 다루는 에이전트 시스템에서 컨텍스트 캐싱의 TTL 정책과 implicit/explicit 캐싱 방식은 비용과 응답 속도에 직접 영향을 준다. 공식 문서에서 이를 명시하고 있으므로 사전에 파악해두는 것이 좋다.

커뮤니티에서는 같은 시점에 출시된 Kimi K2.6과의 비교도 활발하다. 가격 경쟁력과 벤치마크 수치 모두 Kimi K2.6이 우위를 보인다는 의견이 있으며, 실제 사용 목적과 도메인에 따라 선택이 달라질 수 있다는 게 중론이다.

도입 전 체크포인트

• 프리뷰 단계다. 공식적으로 지속적인 개선이 예정돼 있고, 커뮤니티 피드백을 반영 중이라고 밝혔다. 프로덕션 크리티컬 워크플로우에는 안정화 이후 적용을 검토하라.
• 호스팅 전용 모델이다. 로컬 실행이나 온프레미스 배포는 불가능하다. 데이터 거버넌스나 망분리 요건이 있는 환경이라면 오픈 웨이트 계열(Qwen3.6-35B-A3B 등)을 대안으로 살펴봐야 한다.
• API 키 및 리전 설정을 확인하라. DASHSCOPE_API_KEY가 필수이며, 베이징·싱가포르·US Virginia 리전 엔드포인트가 제공된다. 레이턴시와 데이터 레지던시 요건에 맞는 리전을 선택해야 한다.
• preserve_thinking 활성화 여부를 설계 단계에서 결정하라. 에이전트 루프 길이와 컨텍스트 비용 간의 트레이드오프가 발생한다. 단발성 요청에는 오히려 불필요한 오버헤드가 될 수 있다.
• 벤치마크는 출발점이지 결론이 아니다. HN 커뮤니티에서도 지적됐듯, SOTA 순위보다 자신이 다루는 도메인과 사용 패턴에서의 실제 성능이 더 중요하다. 소규모 A/B 테스트를 먼저 진행하는 것이 합리적이다.