Qwen3.6 Plus 1M 토큰, 실제로 확인해봤습니다

Published on

in

Qwen3.6 Plus 1M 토큰, 실제로 확인해봤습니다

2026.04.02 출시 기준
API 공식 문서 기반

Qwen3.6 Plus 1M 토큰,
실제로 확인해봤습니다

알리바바가 2026년 4월 2일 공식 출시한 Qwen3.6 Plus는 “1M 토큰 무료”를 앞세웠습니다. 그런데 막상 API를 연결해보면, 광고 문구와 실제 동작 사이에 꽤 큰 간격이 있습니다. 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다.

78.8%
SWE-bench Verified
1/17
Claude 대비 가격
128K
네이티브 실제 컨텍스트
15~20%
1M 확장 시 성능 저하

Qwen3.6 Plus가 등장한 배경

알리바바 Qwen 팀은 2026년 2월 Qwen3.5 시리즈를 내보낸 뒤, 두 달 만에 Qwen3.6-Plus를 공식 출시했습니다. 공식 블로그 발표 제목은 “Towards Real World Agents”로, 단순 언어모델이 아니라 실제 작업을 수행하는 에이전트 경쟁에 본격적으로 뛰어들겠다는 선언입니다 (출처: Qwen 공식 블로그, 2026.04.01).

이 모델이 주목받은 건 성능 때문이 아니라 가격 때문입니다. 공식 API 기준 입력 토큰 100만 개당 약 $0.29로, Claude Opus 4.5의 100만 토큰당 $5.00와 비교하면 약 1/17 수준입니다 (출처: help.apiyi.com, 2026.04). 이 가격에 에이전트 코딩 벤치마크 점수까지 프론티어급이라는 주장이 나오면서 개발자 커뮤니티에서 순식간에 퍼졌습니다.

공식 API는 Alibaba Cloud Model Studio(DashScope)를 통해 제공되며, OpenAI 및 Anthropic 프로토콜과 호환됩니다. 즉, Claude Code나 OpenCode 같은 기존 도구에서 API 키와 base_url만 바꾸면 바로 붙여 쓸 수 있습니다 (출처: qwen.ai/blog, 2026.04.01).

▲ 목차로 돌아가기

“1M 토큰”이 실제로 작동하는 방식

광고 문구는 “1M 컨텍스트 윈도우 기본 제공”이지만, 실제 아키텍처를 보면 얘기가 달라집니다. Qwen3.6 Plus의 네이티브 컨텍스트는 128K이고, 그 위에 YaRN(Yet Another RoPE extensioN) 기법으로 1M까지 확장하는 구조입니다 (출처: mindstudio.ai, 2026.04).

💡 공식 문서와 vllm 프로젝트 실측 테스트를 교차해서 확인하니 이런 차이가 드러났습니다.

vllm 프로젝트의 GitHub 이슈(#18728)에서 Qwen3 계열 모델의 YaRN 확장 컨텍스트는 네이티브 범위 대비 15~20% 성능 저하가 발생한다는 테스트 결과가 확인됩니다 (출처: github.com/vllm-project/vllm/issues/18728, 2025.05). 128K를 넘는 영역에서의 지시 따르기 정확도와 정보 회수 품질이 저하됩니다.

알리바바 공식 페이스북 계정도 “Native context is 262K (validated ~1M via YaRN)”이라고 명시했습니다 (출처: facebook.com/alibabacloud, 2026.04.02). 즉, 공식 채널도 1M을 ‘검증된 수치’로 표현하지만 ‘네이티브’라고 쓰지는 않습니다. 광고 헤드라인 “1M 컨텍스트 기본 제공”과는 온도 차가 있는 표현입니다.

실무에서 이게 의미하는 건 하나입니다. 100만 토큰짜리 코드베이스를 넣었을 때의 성능과, 12만 토큰 안에서 돌렸을 때의 성능은 다릅니다. 128K 이내 작업에서는 프론티어급이지만, 1M 영역에서는 품질 보장이 안 됩니다.

▲ 목차로 돌아가기

벤치마크 수치, 직접 대조했습니다

Qwen 팀 공식 블로그에 공개된 벤치마크를 Claude Opus 4.5, GPT-5.4와 나란히 놓으면 이렇습니다 (출처: qwen.ai/blog, 2026.04.01 / help.apiyi.com, 2026.04).

벤치마크 Qwen3.6 Plus Claude Opus 4.5 GPT-5.4
SWE-bench Verified (코딩 에이전트) 78.8% 80.9% 76.2%
Terminal-Bench 2.0 (터미널 작업) 61.6% 59.3% 57.8%
GPQA (대학원 수준 과학) 90.4% 87.0% 88.1%
MCPMark (도구 사용) 48.2% 45.6% 43.9%
최대 출력 토큰 65,536 32,000 16,384
입력 가격 (100만 토큰) 약 $0.29 $5.00 약 $2.50

수치만 보면 코딩 에이전트(SWE-bench)에서는 Claude에 2.1%p 뒤처지지만, 터미널 작업, 과학 추론, 도구 호출에서는 오히려 앞섭니다. 한 문장으로 정리하면, SWE-bench 하나만 빼면 Qwen3.6 Plus가 프론티어 모델과 동등하거나 더 높습니다.

그런데 여기서 중요한 맥락이 있습니다. SWE-bench는 에이전트 스캐폴딩(bash + 파일 편집 도구)을 함께 쓴 결과입니다. 모델 단독 성능이 아니라 도구 환경 세팅에 따라 점수가 크게 달라지기 때문에, 수치 자체를 절대 기준으로 받아들이면 실망할 수 있습니다.

▲ 목차로 돌아가기

무료라고 했는데 429 에러가 나는 이유

OpenRouter에서 qwen/qwen3.6-plus:free로 무료 호출을 시도하면, 유료 플랜 사용자도 429 에러를 자주 맞닥뜨립니다. 이게 왜 생기는지 공식 발표문 어디에도 명확한 설명이 없습니다.

💡 구조를 뜯어보면 이런 흐름이 보입니다.

OpenRouter는 알리바바 클라우드로부터 할당된 컴퓨팅 쿼터 내에서 무료 티어와 유료 티어가 동일한 백엔드 풀을 공유합니다. 무료 사용자가 몰리면 유료 사용자도 rate limit에 걸립니다 (출처: help.apiyi.com, 2026.04). 유료 결제가 안정적인 API 접근을 보장하지 않는 구조입니다.

여기에 프리뷰 단계 특성도 더해집니다. 공식 출시는 2026년 4월 2일이지만, 알리바바 클라우드는 프리뷰 기간에 서드파티 플랫폼에 보수적으로 컴퓨팅을 배분합니다. 자체 플랫폼(DashScope/Bailian)을 우선합니다. OpenRouter 경유 요청은 이 과정에서 뒤로 밀립니다.

MoE 아키텍처도 영향을 줍니다. Qwen3.6 Plus는 Mixture-of-Experts 구조라서 1M 컨텍스트 요청이 들어올 때 KV 캐시가 GPU VRAM을 대량으로 점유합니다. 한 요청이 GPU를 오래 잡으면 그 시간 동안 다른 요청이 처리되지 못합니다. 처리량(throughput)은 Claude Opus 4.6 대비 2~3배 빠르다고 알려져 있지만, 장문 컨텍스트 요청이 겹치면 얘기가 달라집니다.

가장 현실적인 해결책은 OpenRouter를 거치지 않고 알리바바 클라우드 DashScope에 직접 API 키를 받는 겁니다. 직접 접근 시 응답 첫 토큰 도달 시간(TTFT)이 OpenRouter 피크 대비 절반 수준인 2~4초대로 줄어듭니다 (출처: help.apiyi.com 채널별 레이턴시 벤치마크, 2026.04).

▲ 목차로 돌아가기

Claude·GPT-5.4와 어떤 상황에서 다른가

벤치마크 점수가 비슷하다고 해서 모든 작업에서 같은 결과가 나오는 건 아닙니다. 실제 사용 패턴에서 차이가 나는 지점을 정리했습니다.

Qwen3.6 Plus가 유리한 상황

코드베이스 전체를 컨텍스트에 넣고 리팩토링하는 작업, 하루 수백~수천 건 호출하는 자동화 파이프라인, 119개 언어 혼용 코드 환경, 터미널 명령 실행이 포함된 에이전트 작업에서 Claude 대비 비용 우위가 뚜렷합니다. Qwen3.6 Plus의 최대 출력 토큰이 65,536으로 Claude Opus 4.5의 32,000 대비 2배라서, 한 번에 긴 코드를 생성해야 하는 상황에서도 유리합니다 (출처: qwen.ai/blog, 2026.04.01).

Claude가 여전히 유리한 상황

수십 단계 이상의 긴 에이전트 루프에서 지시 준수 안정성이 중요할 때, 파일 수정·테스트 실행·커밋처럼 돌이키기 어려운 작업이 포함된 프로덕션 경로, Anthropic MCP나 Claude Code 생태계를 이미 구축한 팀에서는 Claude의 지시 일관성이 유의미한 차이를 만듭니다. mindstudio.ai 실사용 비교에 따르면 Claude Opus 4.6은 장기 루프에서 초기 목표를 덜 잊어버립니다 (출처: mindstudio.ai, 2026.04).

GPT-5.4와 비교하면

GPT-5.4는 컨텍스트 윈도우가 256K로 Qwen의 네이티브 128K보다 크고, OpenAI 에코시스템(Assistants API, Function Calling 툴링)이 성숙합니다. 반면 Qwen3.6 Plus는 터미널 작업과 도구 호출 벤치마크에서 앞서고, 가격은 약 1/8 수준입니다. 멀티모달 입력(이미지·비디오)이 필요하다면 GPT-5.4가 더 폭넓게 지원합니다.

일부 팀은 Claude를 핵심 경로에, Qwen3.6 Plus를 병렬 처리나 비용 민감 서브태스크에 배치하는 하이브리드 구성을 사용합니다. 같은 OpenAI 호환 인터페이스를 쓰기 때문에 모델 전환 코드 비용이 거의 없습니다.

▲ 목차로 돌아가기

preserve_thinking 파라미터, 이게 진짜 절약 포인트입니다

이번 릴리스에서 조용히 추가된 기능이 있습니다. preserve_thinking 파라미터입니다. 공식 블로그에 딱 한 단락으로 나옵니다 (출처: qwen.ai/blog, 2026.04.01).

💡 보통 에이전트 블로그 글에서 이 부분을 다루지 않지만, 실제로 토큰 비용과 직결됩니다.

기본값은 false로, 이전 턴의 사고 과정(thinking content)이 다음 요청에 전달되지 않습니다. preserve_thinking: true로 바꾸면 이전 턴의 추론 흐름을 유지해 에이전트 일관성이 높아지는 대신 토큰을 더 씁니다. 반대로 기본값(false)에서는 매 턴 사고를 새로 시작하지만, 중복 추론이 줄어 전체 토큰 소비가 내려갑니다. 어느 쪽이 더 경제적인지는 작업 복잡도에 따라 다릅니다.

이 파라미터가 중요한 이유는, Qwen3.6 Plus가 기본으로 “Always-On Chain-of-Thought” 모드를 켜두기 때문입니다. 사용자 응답에 포함되지 않는 내부 추론 토큰도 과금 대상이어서, 단순한 요청에도 사고 과정이 붙으면 실제 응답 대비 수배의 토큰을 소진할 수 있습니다. enable_thinking: false로 비활성화하거나, 작업 유형에 따라 선택적으로 켜는 방식이 비용 관리에 유효합니다.

단순 분류나 보일러플레이트 생성 같은 반복 작업은 thinking 비활성화로 레이턴시와 비용을 동시에 줄이고, 복잡한 멀티파일 리팩토링이나 버그 추적에서만 활성화하는 구성이 실무에서 가장 효율적입니다.

▲ 목차로 돌아가기

자주 묻는 질문 5가지

Q1. Qwen3.6 Plus는 오픈소스인가요?

아닙니다. Qwen3.6 Plus는 알리바바 클라우드 Model Studio API를 통해서만 제공되는 프로프라이어터리 호스팅 모델입니다. 알리바바는 Qwen3 패밀리 중 Qwen3-32B, Qwen3-14B, Qwen3-235B-A22B(MoE) 같은 오픈 웨이트 모델을 별도로 공개하지만, Plus 티어 API 모델은 자체 호스팅이 불가합니다 (출처: qwen.ai/blog, 2026.04.01). 직접 서버에서 돌리고 싶다면 HuggingFace의 Qwen3 오픈소스 계열을 사용해야 합니다.
Q2. Claude Code에 Qwen3.6 Plus를 붙여 쓸 수 있나요?

됩니다. Qwen3.6 Plus는 Anthropic API 프로토콜을 지원하기 때문에, ANTHROPIC_BASE_URL을 알리바바 DashScope 엔드포인트(https://dashscope-intl.aliyuncs.com/apps/anthropic)로, ANTHROPIC_MODELqwen3.6-plus로 설정하면 Claude Code에서 바로 사용할 수 있습니다 (출처: qwen.ai/blog, 2026.04.01 공식 코드 예시). 단, Claude Code 특유의 컴퓨터 사용(computer use) 기능은 별도 검증이 필요합니다.
Q3. 1M 토큰 컨텍스트를 실제로 쓰면 품질이 괜찮은가요?

128K 네이티브 범위 안에서는 프론티어급 품질이 나옵니다. 그 이상(YaRN 확장 구간)에서는 지시 따르기 정확도와 정보 회수 품질이 15~20% 저하된다는 실측 데이터가 있습니다 (출처: github.com/vllm-project/vllm/issues/18728). 전체 대형 모노레포를 한 번에 넣는 작업보다는, 관련 파일만 선별해 128K 안에 담는 방식이 더 안정적인 결과를 줍니다.
Q4. 한국어 입력·출력 품질은 어느 정도인가요?

공식 발표 기준 119개 언어를 지원하며, 다국어 벤치마크 MMMLU에서 89.5%, MMLU-ProX(29개 언어 평균)에서 84.7%를 기록했습니다 (출처: qwen.ai/blog, 2026.04.01). 한국어 코드 주석이나 문서와 코드가 혼재된 작업에서도 무리 없이 처리됩니다. 다만 한국어 특화 모델 대비 미묘한 뉘앙스 차이는 실제 워크플로에서 직접 테스트해보는 게 가장 정확합니다.
Q5. 프리뷰 단계 모델을 프로덕션에 써도 되나요?

이 모델은 공식 출시(GA) 이전 상태로, 공식 SLA가 없습니다. 예기치 않은 동작 변경이 생길 수 있고, OpenRouter를 통한 접근은 레이트리밋이 불안정합니다. 비용 민감 자동화나 반복 처리 파이프라인 테스트용으로는 적합하지만, 사용자 대면 프로덕션 경로의 단일 모델로 운영하는 건 GA 전환 후에 재검토하는 게 안전합니다.

▲ 목차로 돌아가기

마치며 — 총평

Qwen3.6 Plus를 한 문장으로 정리하면 이렇습니다. 가격 대비 성능으로는 현재 시장에서 가장 경쟁력 있는 에이전트 코딩 모델 중 하나지만, “1M 토큰 무료”라는 광고 문구를 그대로 믿으면 막히는 지점이 생깁니다.

네이티브 128K 범위에서 쓰고, 직접 DashScope API로 연결하고, thinking 파라미터를 작업 복잡도에 맞게 조정하는 세 가지만 지키면 가격 1/17에 프론티어급 성능을 꽤 안정적으로 누릴 수 있습니다. 반대로 OpenRouter 무료 티어에서 1M 컨텍스트를 그냥 밀어 넣는 방식으로 쓰면 429 에러와 품질 저하를 동시에 마주하게 됩니다.

프리뷰가 GA로 전환되고 컴퓨팅 배분이 안정화되면 지금보다 접근성이 개선될 겁니다. 그 전까지는 비용 테스트 파이프라인이나 고볼륨 서브태스크용으로 먼저 써보고, 안정성이 검증된 경로에서 점진적으로 확대하는 방식이 현실적입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

  1. ① Qwen 공식 블로그 — Qwen3.6-Plus: Towards Real World Agents (2026.04.01)
  2. ② Alibaba Cloud Model Studio — 공식 모델 목록 및 스펙 (2026.04.01)
  3. ③ vllm 프로젝트 GitHub — YaRN 확장 컨텍스트 성능 저하 이슈 (#18728)
  4. ④ MindStudio — Qwen 3.6 Plus vs Claude Opus 4.6 비교 리뷰 (2026.04)
  5. ⑤ APIYI Help — Qwen3.6-Plus 429 에러 원인 및 채널별 레이턴시 벤치마크 (2026.04)


본 포스팅은 2026년 04월 12일 기준 공개된 공식 자료를 바탕으로 작성되었습니다. Qwen3.6 Plus는 현재 프리뷰 단계로, 이후 서비스 정책·UI·기능·가격이 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으니 최신 내용은 알리바바 클라우드 공식 문서에서 직접 확인하시기 바랍니다.

댓글 남기기


최신 글


아이테크 어른경제에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기