Qwen3.6-27B 완전 분석 — 27B 모델이 397B MoE 능가

RTX 4090 한 장으로 프론티어급 코딩 에이전트를 돌릴 수 있는 시대가 왔습니다. 2026년 4월 22일 Alibaba Qwen Team이 공개한 Qwen3.6-27B는 27B dense 모델인데, 이전 플래그십이었던 397B MoE 모델 Qwen3.5-397B-A17B를 코딩 벤치마크 전 항목에서 앞질렀습니다. 라이센스는 Apache 2.0이라 상업적 사용에도 제약이 없습니다.

---

핵심 요약

출시는 2026년 4월 22일 Alibaba Qwen Team이 진행했으며, 라이센스는 Apache 2.0으로 상업 사용이 가능합니다. 파라미터는 27B dense로 이전 플래그십 Qwen3.5-397B 대비 약 14분의 1 크기입니다. VRAM은 Q4_K_M 양자화 기준 약 16.8GB로 RTX 4090 한 장으로 구동할 수 있습니다. 벤치마크 결과는 SWE-bench Verified 77.2%로 Claude Opus 4.6의 80.8%와 3.6점밖에 차이 나지 않고, Terminal-Bench 2.0은 59.3%로 Claude 4.5 Opus와 동점이며, SkillsBench는 48.2%로 397B MoE의 30.0% 대비 60% 가까이 향상됐습니다. 다만 CUDA 13.2에서 버그가 보고되고 있어 CUDA 13.1이나 12.x 사용이 권장됩니다.

---

왜 이게 충격인가

27B짜리 dense 모델이 397B MoE 모델을 코딩 벤치마크에서 전부 이긴 사례라는 점에서 의미가 큽니다. 이전 오픈소스 플래그십이었던 Qwen3.5-397B-A17B는 총 파라미터가 397B, 활성 파라미터가 17B인 MoE 구조였고 모델 파일 크기가 807GB에 달해서 서빙에 멀티 GPU가 필수였습니다. 반면 이번에 나온 Qwen3.6-27B는 27B 전부가 dense로 활성화되는 구조인데도 모델 파일 크기가 BF16 기준 55.6GB, Q4_K_M 양자화 기준 약 16.8GB로 줄어서 RTX 4090 한 장으로 서빙이 가능합니다.

벤치마크를 직접 비교하면 차이가 더 명확합니다. SWE-bench에서 Qwen3.6-27B는 77.2%, Qwen3.5-397B는 76.2%로 27B가 1.0%포인트 앞섰습니다. Terminal-Bench에서는 59.3% 대 52.5%로 6.8%포인트 차이가 났고, SkillsBench에서는 48.2% 대 30.0%로 18.2%포인트나 차이가 벌어졌습니다. AIME 2026에서는 94.1%를 기록했습니다. 파라미터 수가 14분의 1로 줄었는데 성능이 오히려 전 영역에서 높아진 건 아키텍처 혁신의 결과로 볼 수 있습니다.

---

실전 1 — 로컬 설치 (llama.cpp / GGUF)

가장 빠르게 써보고 싶다면 GGUF 양자화 버전을 받는 게 좋습니다. Unsloth의 Dynamic Q4 버전이 권장되는데, 품질과 용량의 균형이 잘 맞춰져 있기 때문입니다. 아래 명령으로 다운로드하고 llama.cpp 서버를 띄울 수 있습니다.

# GGUF 다운로드 (Unsloth Dynamic Q4 — 권장)
huggingface-cli download unsloth/Qwen3.6-27B-GGUF \
    Qwen3.6-27B-UD-Q4_K_XL.gguf

# llama.cpp 서버 실행
./llama-server \
    -m Qwen3.6-27B-UD-Q4_K_XL.gguf \
    -c 262144 \
    -ngl 99 \
    --host 0.0.0.0 \
    --port 8080

서버가 뜨면 OpenAI 호환 API로 바로 호출할 수 있습니다. 양자화 레벨에 따라 필요한 VRAM이 크게 달라지는데, Q4_K_M은 약 16.8GB로 RTX 4080에서는 빠듯하고 RTX 4090에서는 여유가 있습니다. Q5_K_M은 약 19.5GB로 RTX 4090이 권장되고, Q6_K는 약 22.5GB로 RTX 4090에서 가능합니다. Q8_0은 약 28.6GB가 필요해서 A6000 48GB급이 권장되고, BF16 풀 버전은 약 55.6GB로 고성능 서버용입니다. 한 가지 주의할 점은 KV 캐시가 별도로 VRAM을 소모한다는 겁니다. 기본 컨텍스트에서는 1~3GB가 추가되지만, 1M 토큰 풀 컨텍스트를 쓰면 20~40GB가 추가로 필요해서 VRAM 계산할 때 반드시 감안해야 합니다.

---

실전 2 — vLLM 서빙

프로덕션 환경에서 서빙한다면 vLLM을 추천합니다. 먼저 0.19.0 이상 버전을 설치해야 합니다.

# vLLM 설치 (0.19.0 이상 필수)
pip install "vllm>=0.19.0" --torch-backend=auto

# 텍스트 전용 서버 (VRAM 절약)
vllm serve Qwen/Qwen3.6-27B \
    --port 8000 \
    --tensor-parallel-size 2 \
    --max-model-len 262144 \
    --reasoning-parser qwen3 \
    --language-model-only

# 멀티모달 포함 (이미지/비디오)
vllm serve Qwen/Qwen3.6-27B \
    --port 8000 \
    --tensor-parallel-size 2 \
    --max-model-len 262144 \
    --reasoning-parser qwen3 \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_coder

설정에서 신경 써야 할 부분이 몇 가지 있습니다. --reasoning-parser qwen3는 Thinking 모드를 제대로 파싱하기 위해 필수이고, --tool-call-parser qwen3_coder는 에이전트가 툴을 호출하는 작업에 꼭 필요합니다. 텍스트만 쓸 거라면 --language-model-only 옵션으로 비전 인코더를 제외해서 메모리를 아낄 수 있습니다. OOM이 발생하면 --max-model-len을 128K로 줄이는 게 1차 대응책이지만, Thinking 성능에 영향을 주기 때문에 최소 128K 컨텍스트는 유지하는 걸 권장합니다.

---

실전 3 — SGLang 서빙 (MTP 옵션 포함)

추론 속도를 추가로 끌어올리고 싶다면 SGLang을 고려해볼 만합니다. 0.5.10 이상 버전이 필요합니다.

# SGLang 설치 (0.5.10 이상 필수)
pip install "sglang[all]>=0.5.10"

# 기본 서버
python -m sglang.launch_server \
    --model-path Qwen/Qwen3.6-27B \
    --port 8000 \
    --tp-size 2 \
    --mem-fraction-static 0.8 \
    --context-length 262144 \
    --reasoning-parser qwen3

# MTP (Multi-Token Prediction) 옵션 — 속도 추가 향상
python -m sglang.launch_server \
    --model-path Qwen/Qwen3.6-27B \
    --port 8000 \
    --tp-size 2 \
    --mem-fraction-static 0.8 \
    --context-length 262144 \
    --reasoning-parser qwen3 \
    --speculative-algo NEXTN \
    --speculative-num-steps 3 \
    --speculative-eagle-topk 1 \
    --speculative-num-draft-tokens 4

MTP 옵션을 켜면 추측 디코딩 방식으로 추론 속도를 추가로 높일 수 있습니다. SGLang과 vLLM 중 어느 걸 선택할지는 용도에 따라 다릅니다. SGLang은 MTP로 속도를 더 끌어올릴 수 있어서 에이전트 서빙처럼 응답 속도가 중요한 경우에 유리하고, vLLM은 레퍼런스 구현이고 문서가 더 풍부해서 처음 세팅하는 경우에는 vLLM이 편합니다. 둘 다 OpenAI 호환 API 엔드포인트를 제공하기 때문에 클라이언트 코드는 동일하게 쓸 수 있습니다.

---

실전 4 — Cursor / Aider 연동

로컬 서버를 띄워두면 Cursor나 Aider 같은 코딩 툴에 바로 연결할 수 있습니다. Cursor는 settings.json에 아래처럼 추가하면 됩니다.

// Cursor settings.json — 로컬 Qwen3.6-27B 연동
{
  "models": [
    {
      "title": "Qwen3.6-27B (local)",
      "provider": "openai",
      "model": "Qwen/Qwen3.6-27B",
      "apiBase": "http://localhost:8000/v1"
    }
  ]
}

Aider는 명령줄 인자로 바로 지정할 수 있습니다.

# Aider 연동
aider \
    --model openai/Qwen/Qwen3.6-27B \
    --openai-api-base http://localhost:8000/v1 \
    --openai-api-key EMPTY

Python에서 직접 호출하고 싶다면 OpenAI SDK를 그대로 쓰면 됩니다.

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1"
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B",
    messages=[
        {
            "role": "user",
            "content": "FastAPI로 JWT 인증 시스템 만들어줘"
        }
    ],
    max_tokens=4000,
    temperature=1.0,
    top_p=0.95
)

print(response.choices[0].message.content)

OpenAI 호환 엔드포인트라서 기존에 쓰던 코드를 거의 그대로 가져다 쓸 수 있다는 점이 큰 장점입니다. api_key는 로컬 서버에서 검증을 하지 않기 때문에 아무 값이나 넣어도 됩니다. Thinking 모드를 활성화할 때는 temperature=1.0을 쓰는 게 공식 권고 사항입니다.

---

Thinking Preservation — 새로운 기능

Qwen3.6에서 처음 도입된 기능입니다. 기존 방식에서는 대화가 이어지더라도 매 요청마다 이전 추론 과정이 사라지는 문제가 있었습니다. 예를 들어 "이 코드 분석해줘" 다음에 "이제 수정해줘"라고 요청하면, 수정 요청 시점에는 이전 분석에서 사용된 추론 컨텍스트가 남아있지 않았습니다.

Thinking Preservation은 이전 메시지에서의 chain-of-thought를 모델이 기억하도록 만들어서 이 문제를 해결합니다. 반복 개발이나 코드 리팩토링처럼 같은 코드베이스를 여러 번 수정하는 작업에서 일관성이 눈에 띄게 향상됩니다. 효과가 가장 크게 나타나는 영역은 세 가지입니다. 반복 개발에서는 이전 분석 결과를 다음 요청에 그대로 활용할 수 있고, 코드 리팩토링에서는 히스토리 기반으로 일관된 수정이 가능하며, 에이전트 루프에서는 이전 스텝의 추론 맥락이 유지되면서 오류가 줄어듭니다.

---

클로즈드 소스 대비 포지션

성능만 따지면 클로즈드 모델이 아직 앞서 있습니다. SWE-bench에서는 Claude Opus 4.7이 84.3%로 가장 높고 Qwen3.6-27B가 77.2%, GPT-5.5가 58.6%로 뒤를 잇습니다. Terminal-Bench에서는 순서가 바뀌어서 GPT-5.5가 82.7%로 1위, Claude Opus 4.7이 69.4%, Qwen3.6-27B가 59.3%로 가장 낮습니다.

하지만 비용과 프라이버시 측면에서는 완전히 다른 그림이 나옵니다. Qwen3.6-27B는 로컬에서 돌리면 API 비용이 0원이지만, Claude Opus 4.7은 1M 토큰당 입력 5달러·출력 25달러, GPT-5.5는 입력 5달러·출력 30달러가 듭니다. 로컬 서빙이기 때문에 데이터가 외부로 전송되지 않는다는 것도 큰 차이점입니다. 정리하면 SWE-bench는 Claude Opus 4.7, Qwen3.6-27B, GPT-5.5 순이고 Terminal-Bench는 GPT-5.5, Claude Opus 4.7, Qwen3.6-27B 순이지만, 비용은 Qwen3.6-27B가 압도적으로 낮고 보안 측면에서도 로컬 서빙의 장점이 명확합니다.

---

마무리

Qwen3.6-27B를 써야 할 상황과 아직 클로즈드 모델이 나은 상황은 명확히 구분됩니다. API 비용 없이 프론티어급 코딩 에이전트를 돌리고 싶거나, RTX 4090 한 장을 보유한 개인 개발자거나, 금융·의료·사내 코드베이스처럼 데이터 외부 전송이 불가능한 보안 환경이거나, Claude나 GPT API 비용이 부담스러운 스타트업이라면 Qwen3.6-27B가 현실적인 대안이 됩니다. 오픈소스 기반으로 자체 코딩 에이전트를 구축하려는 경우에도 적합합니다.

반대로 SWE-bench 최고 성능이 꼭 필요하다면 Claude Opus 4.7의 84.3%가 여전히 앞서 있고, 터미널 에이전트 최강 성능이 필요하다면 GPT-5.5의 82.7%를 따라가지 못합니다. 또한 이 글 작성 시점에는 Ollama 지원이 아직 안 되기 때문에 Ollama로 빠르게 테스트하고 싶다면 기다려야 합니다. CUDA 13.2 환경에서는 버그가 있다고 보고됐으니 13.1이나 12.x로 맞춰서 세팅하는 게 안전합니다.

---

관련 글

• Qwen3.6-27B로 로컬 코딩 에이전트 만들기 — Aider, Continue.dev, Cursor, Qwen Code 완전 연동 가이드
• Qwen3.6-27B vs 35B-A3B — Dense vs MoE
• GPT-5.5 비싸다 — GPT-5.4 대비 2배