--- title: "Qwen 3.6 27B, 로컬 개발용 LLM의 꽤 현실적인 ‘스윗스팟’" published: 2026-06-29T17:05:16.000Z canonical: https://jeff.news/article/4407 --- # Qwen 3.6 27B, 로컬 개발용 LLM의 꽤 현실적인 ‘스윗스팟’ Qwen 3.6 27B가 로컬에서 돌리는 범용 대규모 언어 모델(LLM)로 꽤 쓸 만한 수준까지 왔다는 사용기다. llama.cpp로 Q8 양자화 모델을 띄우고 OpenCode에 붙여 코딩 에이전트처럼 쓰는 과정, 성능 수치, 35B A3B 모델과의 비교까지 다룬다. - 로컬 대규모 언어 모델(LLM)이 드디어 ‘써볼 만한 장난감’을 넘어 ‘개발에 붙일 수 있는 도구’ 쪽으로 온 느낌이라는 사용기임 - 글쓴이는 예전 로컬 모델들에 실망했지만, Qwen 3.6 27B는 처음으로 범용 지능 모델처럼 느껴졌다고 말함 - Qwen 3.6에는 혼합 전문가 모델(MoE)인 35B A3B와 고밀도(dense) 모델인 27B가 있는데, 글쓴이는 더 느리지만 더 강한 27B를 추천함 - 첫인상 테스트부터 꽤 인상적이었다고 함 - Simon Willison이 쓰는 ‘자전거 탄 펭귄’ 테스트 대신, 글쓴이는 제약이 있는 글쓰기와 짧은 창작 과제를 던짐 - 양자역학과 춤을 엮은 8행 시 같은 과제에서 사고 과정과 운율이 꽤 말이 됐다고 평가함 - 1년 전만 해도 이런 류의 결과는 비싼 GPT-4.5급 모델에서나 기대하던 거였다는 비교가 붙음 - 코딩 테스트에서도 27B 쪽이 더 마음에 들었다는 게 포인트임 - OpenCode에 pnpm 기반 육각형 지뢰찾기를 만들라고 했더니, 단일 프롬프트로 제대로 된 Node 패키지를 만들어냈다고 함 - 반면 Qwen 3.6 35B A3B는 더 빠르긴 했지만, 패키지로 만들라는 지시를 무시하고 단일 index.html로 처리함 - 여기서 글쓴이의 결론은 꽤 명확함: 빠른 모델보다 지시를 잘 따르고 결과 품질이 좋은 모델이 코딩에는 더 낫다는 것 > [!IMPORTANT] > 35B A3B가 3배 빠르더라도, 글쓴이는 27B를 고름. 코드가 3분의 1만 생성되더라도 더 나은 코드가 나오면 그쪽이 실무에선 이득이라는 판단임. ## 로컬에서 돌리는 방법 - 실행은 llama.cpp 기준으로 꽤 단순하게 정리됨 - Hugging Face에서 unsloth의 Qwen3.6-27B-MTP-GGUF Q8_0 양자화 모델을 가져옴 - Q8은 8비트 양자화라 BF16 기본 모델보다 공간을 절반 가까이 줄이면서 품질 손실은 크지 않은 편이라고 설명함 - 더 낮은 비트로 내려가면 모델은 더 작고 빠를 수 있지만 품질 손실 가능성이 커짐 - 서버 실행 옵션은 로컬 LLM을 개발 도구에 붙이기 위한 구성임 - `llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 --spec-type draft-mtp -ngl 999 -fa on -c 65536 --port 8080` 형태로 실행함 - `-ngl 999`는 레이어를 GPU에 올리는 옵션이고, `-fa on`은 플래시 어텐션을 켜는 설정임 - 컨텍스트는 65,536토큰으로 잡았지만, Qwen 3.6 27B의 네이티브 컨텍스트는 256k라 조정 여지가 있음 - 이렇게 띄운 서버는 채팅뿐 아니라 코딩 에이전트에도 바로 붙일 수 있음 - 브라우저에서 `127.0.0.1:8080`으로 들어가면 직접 채팅 가능함 - OpenCode 설정에 OpenAI 호환 provider로 `http://127.0.0.1:8080/v1`을 넣으면 로컬 모델을 기본 모델처럼 쓸 수 있음 - 글에서는 OpenCode 외에도 Pi, Hermes 같은 에이전트 선택지는 취향과 목적에 따라 갈린다고 봄 ## 성능과 현실성 - Macbook Max M5 128GB에서 약 30토큰/초가 나왔다는 게 핵심 수치임 - 프론티어 모델 API 체감 속도 범위 안에 들어오는 수준이라, 로컬 모델치고는 답답하지 않다는 평가임 - Apple Silicon에 특화된 mlx-lm보다 llama.cpp가 더 빨랐고, GPU 사용률도 95%까지 올라가 자원을 잘 쓰는 것으로 보였다고 함 - Qwen 3.6의 두 변형 모두 Apple Silicon 공유 메모리 48GB 안에서 돌아가는 범위라고 설명함 - 소비자용 Nvidia RTX 카드에서도 가능하지만 양자화를 더 세게 해야 함 - Hacker News 댓글 사례로 RTX 5090에서 Q6_K 양자화와 Q4_0 KV를 쓰고, 123k 컨텍스트에서 약 50토큰/초를 꾸준히 얻었다는 이야기가 나옴 - 이때 VRAM은 32GB 중 약 28GB를 사용했다고 함 - 즉 ‘아무 노트북이나 가능’은 아니지만, 고급 소비자 장비나 개발자 워크스테이션에선 꽤 현실적인 선까지 내려옴 - 벤치마크와 커뮤니티 반응도 Qwen 3.6 27B 쪽에 힘을 실어준다고 함 - Artificial Analysis 기준으로 프론티어 모델과 비교했고, 로컬 코딩 모델로 많이 쓰이는 Gemma 4 31B보다 Qwen 3.6 27B가 더 좋은 평가를 받는다고 정리함 - DeepSeek V4 Flash의 양자화 버전인 DwarfStar4와 비교하면, 글쓴이 체감으로는 Qwen 3.6 27B가 비슷하거나 살짝 더 낫다고 봄 - 다만 긴 컨텍스트 프로젝트에서는 DeepSeek 계열이 우위일 수 있다는 단서도 붙임 ## 왜 이게 중요한가 - 로컬 모델은 단순히 비용 절감만의 문제가 아님 - 클라우드 프론티어 모델은 가격 보조가 크게 들어간 상태라, 월 100달러로 수천 달러어치 토큰을 쓰는 지금 구조가 오래갈지 알 수 없음 - 특정 모델이 내려가거나 정책이 바뀌면 개발 워크플로가 흔들릴 수 있는데, 로컬 모델은 그런 리스크가 적음 - 기업 입장에서는 내부 코드, 고객 데이터, 민감한 문서를 외부 API로 보내지 않고도 AI 도구를 붙일 수 있음 - 글쓴이는 오픈 웨이트 모델의 다음 단계도 꽤 크게 봄 - Qwen 3.6은 징검다리였고, GLM 5.2 같은 프론티어급 오픈 웨이트 모델도 로컬 실행 가능성이 열렸다고 봄 - 물론 GLM 5.2는 맥북이나 단일 RTX 5090으로 돌릴 급은 아니지만, 회사 예산으로는 감당 가능한 영역이라고 설명함 - 장기적으로는 모델이 모든 지식을 가중치에 넣는 방식에서 벗어나고, 도구 호출(tool calling)로 지식을 분리하면 스마트폰급 로컬 모델도 더 똑똑해질 수 있다고 전망함 --- ## 기술 맥락 - 이 글의 선택은 ‘가장 빠른 로컬 모델’이 아니라 ‘코딩 작업에서 실패가 덜한 로컬 모델’을 고르는 쪽이에요. 35B A3B가 3배 빠르더라도 지시를 무시하면 개발자는 결과를 다시 고쳐야 하거든요. - llama.cpp를 고른 이유도 단순 실행 편의성 때문만은 아니에요. OpenAI 호환 API 서버로 띄우면 OpenCode 같은 기존 개발 도구에 그대로 붙일 수 있어서, 모델 교체가 워크플로 전체 변경으로 번지지 않아요. - Q8 양자화는 메모리와 품질 사이의 타협점이에요. BF16 그대로 돌리면 장비 요구사항이 커지고, 2비트나 4비트까지 내리면 품질 손실이 커질 수 있어서 글쓴이는 27B Q8을 실사용 기준점으로 잡은 거예요. - 컨텍스트를 64k로 잡은 것도 개발 작업에선 꽤 중요해요. 작은 예제 생성은 짧은 컨텍스트로도 되지만, 실제 코드베이스를 읽고 수정하려면 긴 파일과 대화 이력을 같이 들고 가야 하거든요. ## 핵심 포인트 - Qwen 3.6 27B는 35B A3B보다 느리지만 지시를 더 잘 따르고 결과 품질이 좋다는 평가를 받음 - llama.cpp와 Q8 양자화 모델을 쓰면 64k 컨텍스트로 로컬 서버를 띄워 OpenCode 같은 도구에 붙일 수 있음 - Macbook Max M5 128GB 기준 약 30토큰/초, RTX 5090에서는 더 강한 양자화로 123k 컨텍스트에서 50토큰/초 사례가 나옴 - 로컬 모델은 민감한 데이터, 오프라인 작업, 기업 내부 코드 작업에서 API 모델 의존도를 줄이는 선택지가 됨 ## 인사이트 로컬 LLM 이야기가 예전엔 ‘재밌는 장난감’에 가까웠다면, 이 글은 이제 개발 워크플로에 실제로 붙일 수 있는 단계까지 왔다는 신호에 가깝다. 특히 한국 개발자 입장에선 회사 코드와 민감 데이터를 외부 API로 보내기 애매한 상황에서 꽤 현실적인 대안이 생기는 중이다.