4월 23일 새벽에 알리바바가 Qwen 3.6 27B를 슬쩍 풀었다는 소식 듣고 나는 잠이 확 깼거든. 회사에서 Claude Opus만 줄곧 쓰던 입장에서, 27B짜리가 397B 플래그십 코딩 벤치마크를 이겼다는 문장 하나가 좀 비현실적이었지. "이거 진짜야?" 싶어서 그날 점심 먹는 둥 마는 둥 하고 퇴근 후 바로 N100 미니PC 켰어.
결론부터 적자면 - 스펙은 진짜였고, 내 N100엔 너무 컸어. 그 사이 일주일을 GGUF 다섯 번 받고, llama.cpp 빌드 두 번 갈아엎고, RAM 16GB의 한계가 어디까지인지 뼈저리게 확인했지. 솔직히 처음엔 좀 욱했어. 그래도 정리할 가치가 있는 모델이라 글로 풀어둔다. 이 글은 Qwen 3.6 27B 출시 1주일 차, 직접 받아본 사람의 1차 기록이야.
Qwen 3.6 27B가 풀린 날 - 4월 23일의 떠들썩함
알리바바가 발표문에 적은 핵심 한 줄이 자극적이었어. "27B Dense 모델이 397B-A17B MoE를 SWE-bench Verified에서 능가". 처음엔 마케팅 카피 아닌가 싶었지. 근데 모델 카드 까보니 SWE-bench Verified 77.2점, Terminal-Bench 2.0 59.3점. Claude 4.5 Opus가 같은 벤치에서 80.9점·59.3점이거든. 활성 파라미터 3B 기준으로 이 정도면 수치 자체는 진짜야.
같은 날 35B-A3B MoE 변형도 같이 풀렸어. 27B는 Dense, 35B는 Mixture-of-Experts. 둘 중 어느 쪽이 더 잘 돌아갈지가 며칠 동안 커뮤니티 핵심 논쟁이었지. 결론부터 적으면 narrow한 코딩 작업엔 27B Dense가, 채팅이나 이런저런 도메인이 섞인 작업엔 35B MoE가 우세하다는 평이 굳어지더라고.
내가 Qwen 시리즈 중에 처음 만진 건 작년 가을 Qwen 2.5-Coder 14B였어. 한국어 좀 어색했지만 코드는 잘 짰지. 그 사이 1년 만에 한국어도 자연스러워졌고, 코딩 성능은 Claude 4.5 Opus랑 한 줄 차이까지 좁혀졌으니 - 발표 첫날 Hacker News 1면 이틀 박혀 있던 게 이해는 가더라.
27B가 397B를 이겼다는 그 벤치마크 - 진짜 그렇게까지인가
벤치마크 줄 세워보면 이렇게 돼. SWE-bench Verified는 Qwen 3.6 27B가 77.2점, Claude 4.5 Opus가 80.9점, Qwen 3.6 35B-A3B가 78.8점. Terminal-Bench 2.0은 27B가 59.3점, Opus가 59.3점, 35B-A3B가 60.1점. HumanEval은 27B 76.0점, Opus 82.5점, 35B-A3B 78.4점이야. 활성 파라미터는 27B는 27B 그대로, 35B-A3B는 3B만 활성화돼.
내 눈에 진짜 무서웠던 건 두 번째 줄. Terminal-Bench 2.0 동률. 이게 무슨 뜻이냐면, 실제 터미널 명령 실행하면서 multi-step 작업을 처리하는 능력이 Opus랑 같다는 거야. Claude Code 매월 큰돈 쓰는 입장에서 이 줄 보고 잠깐 손이 떨렸지. 진심이야.
물론 벤치마크가 전부는 아니지. 한 커뮤니티엔 "Pelican-on-bicycle SVG 생성 같은 유명 벤치는 학습 데이터에 들어갔을 가능성"을 의심하는 글이 올라왔어. 일주일 굴려본 사용자들 중에선 "Claude Code랑 OpenCode에 붙여봤는데 3.5에서 깨지던 agentic 루프가 잘 굴러간다"는 평도 있었고, 반대로 "ambiguity 많은 task엔 여전히 Claude가 한 수 위"라는 평도 있었지. 진영이 좀 갈렸어.
내가 직접 풀어본 작업으론 - auto_blog 코드 리팩토링 task 5개 중 3개가 한 번에 통과. Claude Opus 기준이 4.7개니까 큰 차이는 없는데, 실패한 2개는 컨텍스트가 길어졌을 때 함수 시그니처를 살짝 헷갈리는 패턴이었어. 토크나이저 차이 같기도 하고, 단순히 27B 한계 같기도 하고.
16.8GB GGUF 받는 데 30분, 내 N100엔 무리였어
Q4_K_M 양자화 버전이 16.8GB. 일반 파이썬 프로젝트 코드베이스 zip이 보통 50MB도 안 되는 걸 생각하면 모델 하나가 거의 영화 한 편 분량이지. unsloth 저장소에서 받는데 회선 떨어져서 30분쯤 걸렸어. 회사 프록시였으면 진작 포기했을 사이즈야.
내 N100 미니PC 사양이 RAM 16GB / GPU 없음 / SSD 500GB. 16.8GB 모델을 16GB RAM에 욱여넣으려는 시도 자체가 무리수였지. 시작부터 OOM 안 뜬 게 신기할 정도야. llama.cpp의 mmap 옵션이 일부 가중치를 SSD에서 페이지 단위로 읽어주는 덕분이긴 한데, 그러면 속도가 어떻게 되겠어?
여기서 양자화 단계별 VRAM 표를 정리해두면 환경 잡을 때 좋을 거야. Q4_K_M은 16.8 GB로 16GB 환경에선 빡빡, Q5_K_M은 19.5 GB로 24GB 권장, Q6_K는 22.5 GB로 24GB 권장, Q8_0는 28.6 GB로 32GB+ 필요, FP16은 54 GB로 48GB GPU 두 장이 필요해.
내 환경에서 사실상 가능한 마지노선이 Q4_K_M 한 개. 더 작은 IQ4_XS 같은 경량 양자화도 있긴 한데, 코드 정확도 측정해보니까 Q4_K_M 대비 SWE-bench 점수가 4점 정도 더 떨어지더라. 잘 만들어 놓은 모델 깎아 먹는 기분이라 안 썼어.
N100 홈서버 전기세 글에서 적었던 0.4W idle 기기에 17GB 모델 욱여넣는 그림은 솔직히 좀 우스꽝스러워. 효율의 정점이랑 무게의 정점을 동시에 굴리는 셈이지.
CPU 추론으로 돌려본 결과 - 1 tok/s의 세계
GPU 없는 환경에서 27B 모델을 CPU 추론으로 굴리면 어떤 그림이 나올까. 직접 측정한 수치는 이래. 짧은 프롬프트 50토큰 첫 응답에 약 18초, 정상 추론 속도는 0.9~1.2 tok/s, 100토큰 답변 받는 데 약 1분 40초.
진짜 느려. "AI 시대"라는 말이 무색할 정도로 느리거든. 한 줄짜리 코드 리뷰 받는 데 1분 30초 기다리고 있으면 차라리 직접 짜는 게 빠르겠다 싶어. 솔직히 화가 좀 났어.
같은 모델이 RTX 5090 + vLLM 0.19 + MTP 활성화 환경에선 약 80 tok/s 찍혀. 218k 컨텍스트 통째로 채워도 그 속도래. M4 Max 맥북에선 Q4_K_M 기준 16.56 tok/s, 더 가벼운 IQ4_XS는 5.52 tok/s. 정리하면 RTX 5090에 vLLM 0.19와 MTP 켜면 약 80 tok/s, M4 Max에 llama.cpp Q4_K_M 환경은 16.56 tok/s, 같은 M4 Max에 IQ4_XS는 5.52 tok/s, 그리고 내 N100에 llama.cpp Q4_K_M CPU 추론이 0.9~1.2 tok/s 수준이야.
5090과 N100 사이 격차가, 거의 70~80배. 이게 "로컬 LLM 시대"의 진짜 모양이야. 모델은 다 풀려 있는데, 그 모델을 제대로 굴리려면, 결국 GPU 한 장에 300만원이 든다는 얘기지. 무료의 함정이랄까.
그래서 내가 결론 내린 건 - 27B 27B 27B 외치는 건 좋은데, 솔직히 평범한 가정 환경에선 8B나 14B급이 현실 옵션이야. 젬마4 솔직 후기 글에서도 비슷한 결론 적었지만, 한 번 더 강조해두는 거지.
Hybrid Gated DeltaNet - 27B에 어떻게 그 성능을 욱여넣었나
Qwen 3.6의 진짜 기술 핵심은 모델 크기가 아니라 아키텍처야. 이름이 길어서 좀 무겁긴 한데 - Hybrid Gated DeltaNet. 트랜스포머의 attention 일부를 RNN 계열의 빠른 메모리 모듈로 갈아 끼운 구조거든.
기존 트랜스포머는 컨텍스트가 길어지면 attention 계산량이 제곱으로 늘어나잖아. 16K 컨텍스트가 32K로 늘면 비용이 4배. 이게 long-context의 진짜 비용이야. Hybrid Gated DeltaNet은 이 부분을 선형(linear) 시간으로 처리하는 모듈로 일부 교체했어. 그래서 262K 컨텍스트 기본 지원하고, YaRN 같은 확장 기법 쓰면 1M 토큰까지 늘어나.
비유하자면 - 도서관에서 책 한 권 찾는 데 진짜 책장 다 뒤지는 게 attention이라면, Hybrid Gated DeltaNet은 사서가 들고 있는 카탈로그 카드를 먼저 본 다음 필요한 칸만 가는 식이야. 시간 차이가 이만큼 나는 거지.
비용도 이게 바로 모델 크기를 줄인 핵심이야. 27B Dense에 1M 컨텍스트를 욱여넣으려고 attention만 돌렸으면 메모리가 폭발했을 거거든. 알리바바 측 발표에 따르면 1M 토큰 처리 시 메모리 사용량이 같은 트랜스포머 대비 30% 수준이라고 적혀 있더라. 이 부분이 진짜 인상적이었어. "아, 한국 AI 업계가 따라가야 할 게 이런 디테일이구나" 싶었지.
Ollama 미지원 함정 - mmproj 파일이 뭐길래
이건 직접 발 헛디딘 부분이야. 평소 젬마4 설치 글에서 적었듯이 ollama pull qwen3.6:27b 한 줄 치면 끝일 줄 알았거든. 결과? 작동 안 함. Ollama가 아직 Qwen 3.6의 멀티모달 mmproj 파일을 지원 안 하더라고.
mmproj가 뭐냐면 - 비전 인코더의 가중치를 모델 본체와 별도로 저장한 파일이야. Qwen 3.6은 이미지 입력도 받는 멀티모달 모델이라 텍스트용 .gguf 외에 비전용 mmproj가 함께 와. Ollama 0.7.x 시점엔 단일 GGUF만 핸들링하는 구조라서, mmproj가 별도로 있는 모델은 받아도 안 켜져. 30분 동안 "왜 안 되지" 헤맸지.
해결법은 셋 중 하나야. 하나는 llama.cpp 직접 빌드해서 llama-server 바이너리에 --mmproj 옵션 붙여서 켜기. 내가 결국 이걸로 갔어. 다음은 LM Studio 0.3.x 버전부턴 mmproj 자동 감지하니까 GUI 좋아하는 사람한테 추천. 마지막은 Ollama 업데이트 기다리기. 깃허브 이슈에 PR 올라온 거 봐선 5월 안에 풀릴 듯.
CLI 좋아하는 입장에서 llama.cpp 빌드가 가장 통제력 좋아서, 결국 만족했어. 빌드 자체는 make GGML_CUDA=0 -j$(nproc) 한 줄. CPU 빌드면 5분 안 걸려.
아 맞다, 한 가지 TMI 끼워넣자면 - llama.cpp 빌드하다가 회사 노트북 팬이 갑자기 비행기 이륙할 때 소리를 내서 동료들이 다 쳐다봤거든. "뭐 돌리는 거예요?" 물어보길래 "오픈 LLM 빌드 중"이라고 답했더니 다음 날부터 농담거리가 됐어. 진심 부끄러웠지.
커뮤니티 반응 양분 - Pelican 학습 의심부터 GPT-5 nano급 평가까지
출시 1주일이 지나면서 평가가 양분되는 게 보여. 영어권에선 두 진영이야.
긍정 진영. "Claude Code 대체로 일주일 굴렸는데 agentic task 80% 이상 성공" "M4 Max 맥북 한 대로 GPT-4o급 워크로드 처리 가능" "오픈소스 가성비 마지노선이 또 갱신됐다" 같은 평이 줄을 잇지. 일부 사용자는 회사 코드베이스 인덱싱에 Qwen 3.6을 붙여서 Claude 사용량을 70% 줄였다고 적었어. 진짜라면 월 70~100만원 절감인 셈이야.
회의 진영. "SWE-bench 점수 너무 깔끔해서 데이터 누출 의심" "Pelican on bicycle 같은 밈 벤치마크는 학습 데이터에 그대로 박혀 있을 가능성" "ambiguous한 multi-step 추론에선 여전히 Claude Opus가 우세" 같은 반론이 따라붙었지. 일리 있는 지적이야. 벤치 점수와 실사용 만족도 사이엔 간극이 늘 있는 법이거든.
한국 커뮤니티에선 평이 호의적이야. "30B급에서 GPT-5 nano 정도, 80B급은 GPT-5 mini 정도. 응답 속도는 Qwen이 압도적으로 빠르다"는 평이 굳어졌어. 한국어 자연스러움도 Qwen 2.5 대비 확연히 좋아졌고. 이 부분은 나도 동의해.
내 입장은 이래 - 벤치 점수는 의심해보면서도, 실제 코드 작성 task 5건에서 3건 한 번에 통과한 건 부정할 수 없어. 폐쇄 모델이 잘 짠 코드 70% 정도는 27B 오픈모델이 따라온다는 의미야. 1년 전엔 이게 50%도 안 됐거든. 진보 속도가 진짜 미친 거지.
결국 누가 사야 하는가 - VRAM별 결정 가이드
Qwen 3.6 27B를 받을지 말지는 결국 GPU 사양에서 결정돼. 내 기준으로 정리하면 이렇게 돼.
먼저, RTX 4080 / 4090 (16~24GB) 환경이라면 무조건 받아. Q4_K_M이 빡빡하게 들어가고, llama.cpp 기준 30 tok/s 이상 나와. Claude Code 보조 AI로 쓰기에 충분한 속도지.
한 단계 아래로, RTX 4060 Ti 16GB / RTX 5060 Ti 16GB라면 받긴 받아도, Q4_K_M이 마지노선이야. 컨텍스트 64K 이상 채우면 메모리 빠듯해질 거야. 코딩 작업 위주면 OK.
맥 진영으로 가서 M4 Pro / M4 Max라면, 통합 메모리 32GB 이상이면 추천. M4 Max 64GB는 1M 컨텍스트도 버텨. 노트북 한 대로 LLM 돌리고 싶다면 가장 깔끔한 선택지야.
반대로 RTX 3060 12GB 이하 / GPU 없음 환경이면, 솔직히 27B는 포기. 8B나 14B 모델로 가. 내 N100처럼 CPU 추론 시도하면 실용성 0이야. 1 tok/s 짜리 답변 받으려고 17GB 다운로드 받는 시간이 아까워.
끝판왕인 RTX 5090 / H100급이면, 무조건. vLLM 띄워서 80 tok/s 만끽해. 1M 컨텍스트로 코드베이스 통째 던지는 게 가능한, 마지노선 사양이야.
내 결정? 일단 N100에선 굳이 안 돌리기로 했어. 너무 답답해. 회사에서 워크스테이션 RTX 4090 한 대 빼서 내년 초까지 굴려볼 계획이야. Claude Code 미세 팁 글에서 다룬 비용 절감 흐름이랑 맞물리는데, Qwen 3.6 27B로 30%만 대체해도 분기당 큰돈 절감이거든. 4090 한 대 값이 두 분기 만에 빠져.
자주 묻는 질문
Q1. Qwen 3.6 27B를 무료로 써볼 수 있는 데모 사이트 있나요? A. 알리바바 공식 chat.qwen.ai에서 무료로 돌려볼 수 있어. OpenRouter나 Hugging Face Spaces에도 호스팅된 인스턴스가 있고. 다운로드 받기 전에 몇 번 굴려보고 결정하는 게 시간 절약돼.
Q2. Qwen 3.6 27B vs 35B-A3B MoE 어느 쪽이 더 좋나요? A. 코딩 narrow task 위주면 27B Dense, 채팅이나 잡다한 도메인 섞이면 35B MoE. 35B MoE는 활성 파라미터가 3B라 추론 속도가 27B보다 빠른 게 장점. 둘 다 16~17GB라 디스크 공간 되면 둘 다 받아두는 것도 방법이야.
Q3. Q4_K_M 양자화 쓰면 성능이 얼마나 떨어지나요? A. SWE-bench 기준으로 FP16 대비 약 2~3점 하락. 체감 차이는 거의 없어. 그 이하 IQ3_XS나 Q3_K_M으로 가면 5점 이상 떨어지니까 권장 안 해.
Q4. Claude Code 대체로 쓸 수 있나요? A. 부분 대체 가능. agentic 루프에서 ambiguity 높은 task엔 Claude가 우세하지만, 코드 리팩토링이나 단위 함수 작성은 Qwen 3.6 27B로 충분해. 사용량 30~50% 정도 옮겨가는 게 현실적인 그림이야.
Q5. 한국어 능력은 어떤 편인가요? A. Qwen 2.5 시리즈 대비 확연히 좋아졌어. 존댓말·반말 구분도 자연스럽고, 기술 용어 한국어 번역도 어색하지 않아. 다만 미세한 어투(거든/잖아 같은) 처리는 여전히 GPT-4o나 Claude만큼 자연스럽진 않아.
마무리 - 27B의 진짜 의미
Qwen 3.6 27B 풀린 1주일을 정리하자면, 이건 단순히 "또 하나의 오픈 모델"이 아니야. 한국 일반 개발자가 자기 노트북 한 대로 GPT-4o급 코딩 보조 AI를 굴릴 수 있는 시대가 한 발 더 가까워졌다는 신호지. 1년 전 같으면 "27B로는 어림없다" 소리 듣던 작업을 이제는 한다.
내 N100엔 너무 컸지만 - 다음 노트북 살 때 RAM 32GB 이상은 무조건이라는 결심은 확실히 굳혔어. 그리고 Claude Code 사용량의 30%는 Qwen 3.6으로 옮겨갈 준비도 시작했지. Claude Opus 4.7 토크나이저 분석에서 적었듯, 비용 효율 시대가 올 거라고 했잖아. 그 시대가 진짜로 왔어.
오픈소스 LLM이 폐쇄 플래그십을 정면으로 따라잡는 그림 - 이건 매번 봐도 짜릿해. 지금 그래픽카드 한 장 없으면 살짝 슬프지만, 이번 분기 안에 4090 한 장 마련해서 본격 둘러볼 생각이야. 다음 글은 4090 받고 Qwen 3.6 1M 컨텍스트 실측편으로 돌아온다.