Qwen-3.6-27B와 클라우드 모델의 로컬 코딩 성능 실제 비교
Actual comparison between locally ran Qwen-3.6-27B and proprietary models
핵심 요약
로컬 환경에서 Qwen-3.6-27B와 클라우드 모델의 코딩 성능을 비교하여 로컬 모델의 실용성과 한계를 분석함.
- 로컬 모델 성능 — Qwen-3.6-27B를 활용해 복잡한 코딩 과제에서 클라우드 모델과 성능을 비교함.
- 하드웨어 최적화 — 3090 등 로컬 GPU 환경에서 양자화 모델을 통해 에이전트 루프를 실용적으로 구동함.
- 평가 방법론 — 단순히 해결 여부가 아닌 실패의 깔끔함과 수정 필요량을 기준으로 모델의 능력을 평가함.
- 실제 활용성 — 로컬 모델이 클라우드 모델을 대체할 수 있는 가능성과 하드웨어 투자 가치를 논의함.
여러분 안녕하세요!
최근 Qwen-3.6-27B와 하위 티어 클라우드 모델들을 어려운 작업에서 비교해 본 경험을 러시아어로 작성했었는데, 결과가 흥미롭고 놀라워서 번역본을 공유하고 싶었습니다. LLM이 작성한 코드에 대한 평가라서 규칙 3을 위반할 수도 있겠지만, 어쨌든 제 방법론은 수작업으로 진행했고 결과도 의미가 있다고 생각합니다. 영어 실력이 부족해서 번역이 매끄럽지 않은 점 양해 부탁드립니다.
__
예전에 3090과 알리익스프레스에서 산 Xeon으로 서버를 돌리며 로컬 모델을 사용하던 시절이 있었습니다. LLM과의 모든 상호작용이 웹 UI를 통해서만 이루어지고, 에이전트가 막 등장하기 시작했으며, 코드를 제대로 작성하려면 채팅창에서 파일로 복사해서 붙여넣기를 반복해야 했던 그 멋진 시절 말이죠. 당시 저는 Mixtral 8x7B를 로컬에서 RAM에 일부 오프로드하여 돌렸고, 매우 만족했습니다. 생성 속도는 초당 약 8토큰 정도였는데, 즉각적인 모델과의 가벼운 대화에는 충분했고, Mixtral은 대학의 기업가 정신 및 혁신 과정 과제를 위한 에세이도 성공적으로 작성해 주었습니다. 코드 생성, 아니 정확히는 Ansible 설정 파일 작성에도 사용해 보려 했지만, 뻔하게도 팀장님께 멍청한 실수들 때문에 엄청나게 깨졌죠. 즐거운 시절이었습니다.
이제 Qwen-3.6-27B와 Qwen-3.6-35B-A3B가 출시되었습니다. 코딩과 에이전트 작업에 특화되어 로컬 추론을 목표로 하는 두 개의 작은 모델이죠. 이 모델들을 FP8(네이티브 학습 정밀도)로 완전히 돌리려면 약 36/40GB의 VRAM이 필요합니다. 하지만 우리는 자존심을 내세우기보다는 타협을 즐기는 사람들이니, 로컬 하드웨어에 맞추기 위해 q4_k_m이나 q3_k_s GGUF를 사용하면 됩니다.
저는 로컬 모델이 '바이브 코딩(vibe coding)'에 얼마나 능숙한지 궁금해졌습니다. 당연히 Opus나 Sonnet을 대체할 수는 없겠지만, 만족스러운 타겟으로 프론티어 연구소의 서브 프론티어 모델인 GPT-Codex-Spark를 선택했습니다. 이 모델은 262k 컨텍스트 윈도우를 가지고 있으며, 완전한 Codex나 GPT-5.2/5.4/5.5만큼 똑똑하지는 않지만 도구 호출, 코드 작성 등을 완벽하게 수행할 수 있습니다. 로컬 모델의 근사치로서 아주 잘 작동하며, 차이점이라면 매우 빠르고 월 100달러가 든다는 점, 반면 로컬 모델은 매우 느리고 무료(또는 게이밍 PC가 소비하는 전기료만큼의 비용)라는 점입니다. Anthropic의 성능을 확인하기 위해 Claude Haiku 4.5도 함께 테스트했습니다.
로컬 추론 하드웨어로는 Ryzen 7 7800X3D, 64GB DDR5-6400, RTX 5080(16GB VRAM) 시스템을 사용했습니다. 작업을 현실적으로 어렵게 만들기 위해, 비교적 상세한 설계 문서*를 바탕으로 자동 연구 루프를 구현하는 복잡한 업무 프로젝트를 선택했습니다. 그리고 Qwen-3.6-27B-q4_k_m, OpenRouter를 통한 Qwen-3.6-27B, OpenRouter를 통한 Gemma-4-31B, Pi Agent의 Claude Haiku 4.5, Codex의 Codex-Spark를 사용하여 AGENTS.md에 따라 구현하도록 프롬프트를 주었습니다. OpenRouter 모델들은 첫째로 API를 통해 이 모델들을 사용하는 비용을 추정하고, 둘째로 로컬 하드웨어의 제한된 양자화 추론이 아닌 전체 정밀도에서의 상위 성능 한계를 추정하기 위해 포함했습니다.
중요한 점은, 이 모델들이 해결하기엔 너무 어려운 작업을 의도적으로 선택했다는 것입니다. 저는 그중 하나라도 깔끔하게 해결할 것이라고 기대하지 않았습니다. 원칙적으로 이는 로컬 모델 평가의 흔한 문제입니다. 사람들은 너무 단순한 작업을 프롬프트로 주고는 “내 로컬 Qwen이 Claude Opus 성능을 따라잡았다!” 같은 헤드라인을 뽑아내죠. 두 모델 다 HTML로 Snake 게임을 만들었으니 말입니다. 제 경우 목표는 “작업을 해결하는 것”이 아니라 “해결을 시도하는 동안 최대한 덜 망치는 것”이었습니다. 따라서 모델의 적용 가능성을 해결 여부가 아닌, 실패의 깔끔함과 사양을 맞추기 위해 필요한 수정 횟수로 평가할 것입니다. 구현 결과는 Claude Opus 4.7(xhigh)을 사용하는 Claude Code로 평가했습니다. 이 모델은 설계 문서를 작성하고 깔끔한 솔루션을 직접 구현할 수 있었으므로(GPT-5.5의 검토에 따르면), 좋은 심사위원이라고 믿기로 했습니다.
결과:
-
Gemma-4-31B는 완전히 실패했습니다. 뼈대 솔루션은 작성했지만, 모듈 절반을 모킹(mock)하고 구현에서 여러 실수를 저질렀습니다. 테스트도 없고, , , 도 없으며, 문서는 기본적으로 “NumPy만 설치하면 괜찮을 거야”라고 말합니다. 비용: $0.112, 803k 컨텍스트 토큰 소비, 21k 토큰 생성.
