Qwen3-Coder 로컬 실행: RTX 3090 한 장으로 SWE-bench 70% AI 코딩 에이전트 세팅하기

클라우드 AI 비용 청구서가 두 달 연속 두 배씩 오르는 걸 보면서 진지하게 대안을 찾기 시작했습니다. 솔직히 "오픈소스가 얼마나 하겠어"라는 편견보다, 이전에 몇 가지 오픈소스 코딩 모델을 써봤다가 실망했던 경험이 더 컸습니다. 특히 레거시 코드베이스에서 파일 여러 개를 넘나드는 리팩터링을 시키면 맥락을 금방 잃고 앞서 정의한 함수를 또 만들어내거나, 손대지 않아야 할 부분까지 건드리는 일이 반복됐거든요. 그러다 발견한 게 Qwen3-Coder였습니다.

직접 세팅해보고 나서 생각이 바뀌었습니다. 이 글에서는 Qwen3-Coder의 아키텍처 특징, 양자화 선택 기준, Ollama/llama.cpp/vLLM을 활용한 로컬 세팅까지 직접 시행착오를 겪으며 정리한 내용을 다룹니다. SWE-bench Verified 69.6%라는 수치가 마케팅이 아니었고, 256K 컨텍스트가 실제 작업 방식을 어떻게 바꾸는지도 구체적인 경험으로 풀어볼게요.

준비물은 생각보다 단순합니다. RTX 3090/4090급 GPU 하나면 30B 모델을 충분히 돌릴 수 있고, M1/M2 Mac에서도 GGUF 양자화 버전으로 쓸 만한 성능이 나옵니다. 자신의 GPU VRAM이 얼마인지 모르신다면 터미널에서 nvidia-smi (NVIDIA) 또는 system_profiler SPDisplaysDataType (Mac)을 실행해보시면 바로 확인할 수 있습니다.

핵심 개념

이 섹션에서는 Qwen3-Coder가 왜 다른지를 아키텍처 관점에서 간략히 살펴봅니다. 개념 설명이 당장 필요 없다면 실전 적용 섹션으로 바로 넘어가셔도 됩니다.

Qwen3-Coder는 왜 "코딩 특화"인가

Alibaba의 Qwen 팀이 만든 Qwen3-Coder는 코드 생성·디버깅·리팩터링·에이전틱 소프트웨어 개발에 특화된 오픈웨이트 LLM입니다. 단순히 코드 데이터를 많이 학습시킨 게 아니라, 아키텍처 자체를 에이전틱 개발 시나리오에 맞게 설계했다는 점이 차별화 포인트입니다.

현재 공식적으로 제공되는 모델 변형은 두 가지입니다.

모델	총 파라미터	활성 파라미터	컨텍스트 윈도우
Qwen3-Coder-480B-A35B-Instruct	480B	35B	256K (최대 1M)
Qwen3-Coder-30B-A3B-Flash	30B	3B	256K

"480B인데 실제 활성 파라미터는 35B"라는 부분이 처음엔 이해가 안 됐는데, 이게 MoE 아키텍처의 핵심입니다.

MoE(Mixture-of-Experts): 전체 파라미터를 여러 "전문가" 서브네트워크로 나누고, 각 토큰 처리 시 관련 전문가만 선택적으로 활성화하는 구조입니다. 덕분에 480B라는 규모임에도 실제 추론에서는 35B 수준의 계산 비용만 발생합니다.

256K 컨텍스트가 실제로 의미하는 것

저도 처음엔 "그냥 긴 컨텍스트겠지"라고 생각했는데, 실무에서 써보면 차이가 납니다. 레거시 코드베이스에서 리팩터링할 때, 관련 파일 10~20개를 컨텍스트에 통째로 넣고 "이 패턴을 전체적으로 바꿔줘"라고 요청하는 게 가능해집니다. 기존 모델들처럼 파일을 잘라서 넣고 결과를 이어 붙이는 수작업이 줄어드는 거죠.

기술적으로는 하이브리드 어텐션과 Yarn 기법을 결합해서 네이티브 256K를 구현합니다. 하이브리드 어텐션은 전체 시퀀스를 균일하게 처리하는 대신 지역과 전역 어텐션을 레이어별로 섞어서 긴 시퀀스 처리 비용을 줄입니다. Yarn은 학습 때 보지 못한 더 긴 컨텍스트로 위치 인코딩을 확장하는 기법인데, 이 두 기법 덕분에 기존 어텐션 구조보다 훨씬 긴 컨텍스트를 현실적인 메모리 안에서 처리할 수 있습니다.

단, 한 가지 중요한 함정이 있습니다. "256K 지원"과 "실제로 256K를 GPU에서 돌릴 수 있느냐"는 전혀 다른 문제입니다.

KV 캐시: 어텐션 레이어에서 이전 토큰 정보를 저장하는 메모리 공간입니다. 컨텍스트가 길어질수록 이 캐시가 선형으로 증가하기 때문에, 24GB VRAM GPU에서 Q5_K_M 기준으로 32K 토큰 정도가 실용적인 상한선입니다. 저도 128K 이상 컨텍스트를 써보려다 OOM을 두 번 겪고 나서야 이 한계를 받아들였습니다.

에이전틱 설계: 단순 자동완성과 다른 점

Qwen3-Coder의 가장 큰 차별점은 에이전틱 코딩 능력입니다. 20,000개 병렬 환경에서 강화학습(Agent RL)을 통해 실제 소프트웨어 개발 워크플로우를 시뮬레이션했는데, 쉽게 말하면 "테스트 실패 → 원인 파악 → 수정 → 재테스트" 루프를 반복하는 방식을 학습했다는 겁니다.

480B-Instruct 모델 기준으로 SWE-bench Verified 69.6%(500턴 기준)를 달성했습니다. 단순히 코드 스니펫을 잘 만드는 게 아니라, 실제 GitHub 이슈를 해결하는 시나리오에서의 수치라서 체감 차이가 있습니다.

실전 적용

환경별로 가장 빠르게 시작하는 방법을 다룹니다. Ollama(간단하게 시작), llama.cpp(소비자 GPU/Mac), vLLM(팀 서버) 순으로 구성했으니, 자신의 환경에 맞는 섹션만 읽어보셔도 됩니다.

예시 1: Ollama로 빠르게 시작하기

가장 빠르게 시작할 수 있는 방법입니다. 저도 처음 테스트할 때 이걸로 시작했는데, 미리 알아두면 좋을 함정이 하나 있습니다.

⚠️ 먼저 알아야 할 것: Ollama의 기본 컨텍스트 크기는 4096 토큰입니다. Qwen3-Coder가 256K를 지원해도 이 기본값으로 실행하면 4K 토큰에서 잘립니다. 모델은 멀쩡히 돌아가는데 성능이 눈에 띄게 낮게 나오는 이유가 대부분 여기서 비롯됩니다. --context-size 옵션을 반드시 지정해주세요.

bash

# 모델 태그가 다를 수 있으니, 먼저 검색해보는 편이 안전합니다
ollama search qwen3-coder
 
# 다운로드 및 실행 — 컨텍스트 윈도우 확장 필수
ollama pull qwen3-coder
ollama run qwen3-coder --context-size 32768

모델 크기에 따라 다운로드에 꽤 시간이 걸립니다. 30B Q4_K_M 기준으로 약 20GB 가량이라, 네트워크 상황에 따라 30분에서 몇 시간까지 걸릴 수 있습니다. 설정 자체는 5분이지만 다운로드 시간은 미리 감안해두시는 편이 좋습니다.

GUI가 편하신 분은 LM Studio를 활용하는 방법도 있습니다. lmstudio.ai에서 앱을 설치하고 검색창에 qwen3-coder를 입력하면 Q4_K_M 양자화 버전을 바로 받을 수 있습니다. 서버 모드에서 OpenAI 호환 API(http://localhost:1234/v1)를 자동으로 제공해서, 코딩을 잘 모르는 팀원에게 배포할 때 이 방식이 훨씬 편했습니다.

예시 2: llama.cpp + GGUF (소비자 GPU / Mac)

GPU 메모리가 넉넉하지 않거나 Mac에서 사용하는 경우, GGUF 양자화 버전이 현실적인 선택입니다. Unsloth는 메모리 효율적인 양자화와 파인튜닝으로 알려진 서드파티 오픈소스 팀인데, 이 팀이 최적화된 GGUF 버전을 Hugging Face에 공개해두어서 바로 받아서 쓸 수 있습니다.

llama.cpp 자체가 없다면 먼저 설치가 필요합니다.

bash

# Mac의 경우
brew install llama.cpp
 
# Linux/직접 빌드의 경우
# https://github.com/ggerganov/llama.cpp#build 참고

설치 후에는 아래와 같이 모델을 받아서 서버를 띄울 수 있습니다.

bash

# Unsloth GGUF 다운로드
huggingface-cli download unsloth/Qwen3-Coder-30B-A3B-GGUF \
  --include "Qwen3-Coder-30B-A3B-Q5_K_M.gguf" \
  --local-dir ./models
 
# llama-server 실행
llama-server \
  -m ./models/Qwen3-Coder-30B-A3B-Q5_K_M.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 99 \
  --port 8080

--n-gpu-layers 99는 가능한 많은 레이어를 GPU에 올리겠다는 의미입니다. VRAM이 부족하면 이 숫자를 줄여서 일부만 GPU에, 나머지는 CPU로 처리하는 혼합 추론도 됩니다. 속도는 느려지지만 M1/M2 Mac의 통합 메모리 환경에서도 잘 작동합니다.

양자화 레벨 선택 기준은 이렇게 정리할 수 있습니다.

양자화	VRAM (30B 기준)	품질	추천 상황
Q4_K_M	16GB	양호	RTX 3090, 일반 작업
Q5_K_M	20GB	우수	RTX 4090, 코드 생성 집중
Q8_0	32GB+	거의 풀 정밀도	A6000, 정확도 우선

참고로 Q4_K_M, Q5_K_M의 K_M은 K-means 양자화 방식을 의미합니다. 단순 비트 절삭이 아니라 클러스터링 기반으로 가중치를 압축하기 때문에 같은 비트 수에서 품질이 더 좋습니다. 다른 GGUF 모델을 고를 때도 이 기준을 그대로 적용할 수 있습니다.

예시 3: vLLM으로 팀 공용 API 서버 구축

여러 명이 함께 쓰거나, 에이전틱 도구 호출(tool calling)이 필요한 워크플로우라면 vLLM이 좋은 선택입니다. 팀에서 이 방식으로 전환하면서 가장 좋았던 건, 기존 OpenAI 기반 코드를 건드리지 않고 엔드포인트만 바꿔서 바로 쓸 수 있었다는 점이었습니다.

--tool-call-parser qwen3_coder 옵션은 vLLM 0.6.x 이상에서 지원됩니다. 버전이 낮다면 먼저 업그레이드해주세요.

bash

pip install "vllm>=0.6.0"
 
# 단일 GPU 환경 (RTX 4090 등, 30B 모델 기준)
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-Coder-30B-A3B-Instruct \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --port 8000
 
# 멀티 GPU 환경 (A100 8장 등, 480B 모델 서빙이 필요한 경우)
# python -m vllm.entrypoints.openai.api_server \
#   --model Qwen/Qwen3-Coder-480B-A35B-Instruct \
#   --tensor-parallel-size 8 \
#   --max-model-len 131072 \
#   ...

서버가 뜨면 기존 OpenAI SDK 코드의 base_url만 바꿔서 바로 사용할 수 있습니다.

python

from openai import OpenAI
 
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"  # 로컬 서버는 아무 값이나 가능합니다
)
 
response = client.chat.completions.create(
    model="Qwen/Qwen3-Coder-30B-A3B-Instruct",
    messages=[{"role": "user", "content": "Python으로 이진 탐색 구현해줘"}]
)
print(response.choices[0].message.content)

IDE 연동

추론 서버가 준비됐다면 평소 쓰는 에디터와 연결하는 단계입니다. "나는 추론 서버는 정했고 에디터 연결만 하면 돼"라는 상황이라면 여기만 보시면 됩니다.

Continue 익스텐션 연결

Continue는 VS Code와 JetBrains 양쪽을 지원하는 오픈소스 AI 코딩 보조 도구입니다. 설치 후 .continue/config.json에 아래 설정을 추가해주시면 됩니다.

json

{
  "models": [{
    "title": "Qwen3-Coder (Local)",
    "provider": "ollama",
    "model": "qwen3-coder",
    "contextLength": 32768
  }]
}

백엔드로 Ollama 대신 vLLM을 쓴다면 "provider": "openai"로 바꾸고 "apiBase": "http://localhost:8000/v1"을 추가하면 됩니다.

CLINE + vLLM (에이전틱 워크플로우)

파일 수정, 터미널 실행, 브라우저 열기 같은 에이전틱 워크플로우를 IDE 안에서 써보고 싶다면 CLINE 익스텐션과 vLLM 조합이 가장 안정적이었습니다. CLINE 설정에서 "OpenAI Compatible"을 선택하고 vLLM 서버 주소를 입력하면 됩니다. 같은 모델인데 에이전트가 오동작한다면, 대부분 구버전 Ollama의 tool calling 지원 불안정 문제이므로 vLLM으로 전환해보시면 많이 개선됩니다.

장단점 분석

실제로 몇 주 써보면서 느낀 점을 정리해봤습니다. 제가 가장 불편했던 건 KV 캐시 메모리 문제였는데, 표 아래에 좀 더 자세히 적어뒀습니다.

장점

항목	내용
비용	Qwen API는 Claude Opus 4.x 대비 입력 토큰 기준 약 17배 저렴, 로컬 실행 시 초기 비용 이후 무과금
성능	480B 모델 기준 SWE-bench Verified 69.6%, 에이전틱 멀티스텝 추론에서 경쟁력 있는 수치
컨텍스트	256K 네이티브 컨텍스트로 대형 코드베이스 통째로 처리 가능
유연성	완전 오픈웨이트, 파인튜닝·상업적 활용 가능, 주요 추론 프레임워크 전부 지원
언어 지원	Python, JavaScript, Java, C++, Go, Rust 등 광범위한 커버리지
데이터 보안	민감한 코드가 외부 API 서버로 나가지 않음

단점 및 주의사항

항목	내용	대응 방안
최상위 모델 대비 성능	Claude Opus 4.x(SWE-bench 80%+)나 GPT-4.1에는 아직 격차	일상 코딩 작업에는 충분, 고난도 작업만 클라우드 병행
하드웨어 요구사항	30B Q4_K_M 기준 최소 16GB VRAM 필요	양자화 레벨 조정 또는 CPU 혼합 추론 활용
Ollama 도구 호출	구버전 Ollama에서 Qwen tool calling 지원 불안정	에이전틱 워크플로우에는 LM Studio 또는 vLLM 권장
KV 캐시 메모리	컨텍스트 길이에 비례해 메모리 급증	24GB GPU에서 Q5_K_M 기준 32K 토큰이 현실적 상한

단점 표에 KV 캐시를 올렸는데, 저한테는 이게 가장 고통스러운 부분이었습니다. 24GB GPU에서 Q5_K_M 모델을 쓰면서 128K 이상 컨텍스트를 사용하려다 OOM을 두 번 겪었는데, 그때마다 진행 중이던 추론이 통째로 날아갔습니다. 이후 32K 토큰을 상한으로 삼고 정말 긴 컨텍스트가 필요한 작업만 클라우드 API로 분리했더니 훨씬 안정적으로 쓸 수 있었습니다.

실무에서 가장 흔한 실수

Ollama 기본 컨텍스트로 그냥 쓰기: 4096 토큰 제한에서 돌아가는 Qwen3-Coder는 제 성능을 낼 수 없습니다. 모델은 멀쩡히 실행되는데 왜 성능이 안 나오지 싶다면, 컨텍스트 크기를 먼저 확인해보시면 좋습니다. 대부분 여기서 해결됩니다.
480B 모델을 무조건 선택하기: 30B-A3B Flash 모델도 일반 코딩 작업에서 충분히 좋은 성능을 보입니다. 하드웨어 환경 확인 없이 풀 모델을 받으려다 디스크 공간이나 VRAM에서 막히는 경우가 많습니다. 480B Q4 양자화만 해도 200GB 이상 디스크 공간이 필요합니다.
에이전틱 워크플로우에서 Ollama 도구 호출 사용: CLINE이나 Qwen Code CLI처럼 도구 호출 기반 에이전틱 워크플로우를 쓴다면, 구버전 Ollama보다 LM Studio나 vLLM의 안정성이 훨씬 좋습니다. 같은 모델인데 에이전트가 오동작한다면 이 부분부터 확인해보시면 대부분 해결됩니다.

마치며

팀에서 3주 써본 결과, PR 리뷰 코멘트 초안 작성, 단위 테스트 생성, 보일러플레이트 코드 작성에서는 클라우드 API와 체감 차이가 없었습니다. Claude Opus 4.x 대비 아직 격차가 있는 건 사실이고, 복잡한 아키텍처 설계 문제에서는 여전히 한계가 느껴집니다. 하지만 클라우드 API 의존도를 줄이면서 민감한 코드를 로컬에서 처리할 수 있다는 점은 팀 입장에서 분명한 가치가 있었습니다.

지금 바로 시작해볼 수 있는 3단계입니다.

Ollama로 체험해보기: ollama pull qwen3-coder 후 ollama run qwen3-coder --context-size 32768로 실행해볼 수 있습니다. 설정 자체는 5분이지만 30B 모델 다운로드에 네트워크 속도에 따라 30분에서 수 시간이 걸릴 수 있습니다. 16GB 이상 VRAM이 있다면 Q4_K_M 버전이 기본으로 선택됩니다.
IDE에 연결해서 실제 코딩 작업에 써보기: Continue 익스텐션 설치 후 위의 .continue/config.json 설정을 추가하면 VS Code나 JetBrains 안에서 인라인 AI 지원을 받을 수 있습니다.
팀 공용 서버가 필요하다면 vLLM으로 전환: GPU 서버 한 대에 vLLM API 서버를 올리면, 팀 전체가 기존 OpenAI SDK 코드 그대로 엔드포인트만 바꿔서 로컬 모델을 쓸 수 있습니다.

참고 자료

#Qwen3-Coder#LLM로컬실행#MoE#vLLM#llama.cpp#GGUF양자화#Ollama#에이전틱AI#SWE-bench#KV캐시

Qwen3-Coder 로컬 실행: RTX 3090 한 장으로 SWE-bench 70% AI 코딩 에이전트 세팅하기

핵심 개념

Qwen3-Coder는 왜 "코딩 특화"인가

현재 공식적으로 제공되는 모델 변형은 두 가지입니다.

모델	총 파라미터	활성 파라미터	컨텍스트 윈도우
Qwen3-Coder-480B-A35B-Instruct	480B	35B	256K (최대 1M)
Qwen3-Coder-30B-A3B-Flash	30B	3B	256K

"480B인데 실제 활성 파라미터는 35B"라는 부분이 처음엔 이해가 안 됐는데, 이게 MoE 아키텍처의 핵심입니다.

MoE(Mixture-of-Experts): 전체 파라미터를 여러 "전문가" 서브네트워크로 나누고, 각 토큰 처리 시 관련 전문가만 선택적으로 활성화하는 구조입니다. 덕분에 480B라는 규모임에도 실제 추론에서는 35B 수준의 계산 비용만 발생합니다.

256K 컨텍스트가 실제로 의미하는 것

단, 한 가지 중요한 함정이 있습니다. "256K 지원"과 "실제로 256K를 GPU에서 돌릴 수 있느냐"는 전혀 다른 문제입니다.

KV 캐시: 어텐션 레이어에서 이전 토큰 정보를 저장하는 메모리 공간입니다. 컨텍스트가 길어질수록 이 캐시가 선형으로 증가하기 때문에, 24GB VRAM GPU에서 Q5_K_M 기준으로 32K 토큰 정도가 실용적인 상한선입니다. 저도 128K 이상 컨텍스트를 써보려다 OOM을 두 번 겪고 나서야 이 한계를 받아들였습니다.

에이전틱 설계: 단순 자동완성과 다른 점

실전 적용

예시 1: Ollama로 빠르게 시작하기

가장 빠르게 시작할 수 있는 방법입니다. 저도 처음 테스트할 때 이걸로 시작했는데, 미리 알아두면 좋을 함정이 하나 있습니다.

⚠️ 먼저 알아야 할 것: Ollama의 기본 컨텍스트 크기는 4096 토큰입니다. Qwen3-Coder가 256K를 지원해도 이 기본값으로 실행하면 4K 토큰에서 잘립니다. 모델은 멀쩡히 돌아가는데 성능이 눈에 띄게 낮게 나오는 이유가 대부분 여기서 비롯됩니다. --context-size 옵션을 반드시 지정해주세요.

bash

# 모델 태그가 다를 수 있으니, 먼저 검색해보는 편이 안전합니다
ollama search qwen3-coder
 
# 다운로드 및 실행 — 컨텍스트 윈도우 확장 필수
ollama pull qwen3-coder
ollama run qwen3-coder --context-size 32768

예시 2: llama.cpp + GGUF (소비자 GPU / Mac)

llama.cpp 자체가 없다면 먼저 설치가 필요합니다.

bash

# Mac의 경우
brew install llama.cpp
 
# Linux/직접 빌드의 경우
# https://github.com/ggerganov/llama.cpp#build 참고

설치 후에는 아래와 같이 모델을 받아서 서버를 띄울 수 있습니다.

bash

# Unsloth GGUF 다운로드
huggingface-cli download unsloth/Qwen3-Coder-30B-A3B-GGUF \
  --include "Qwen3-Coder-30B-A3B-Q5_K_M.gguf" \
  --local-dir ./models
 
# llama-server 실행
llama-server \
  -m ./models/Qwen3-Coder-30B-A3B-Q5_K_M.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 99 \
  --port 8080

양자화 레벨 선택 기준은 이렇게 정리할 수 있습니다.

양자화	VRAM (30B 기준)	품질	추천 상황
Q4_K_M	16GB	양호	RTX 3090, 일반 작업
Q5_K_M	20GB	우수	RTX 4090, 코드 생성 집중
Q8_0	32GB+	거의 풀 정밀도	A6000, 정확도 우선

예시 3: vLLM으로 팀 공용 API 서버 구축

--tool-call-parser qwen3_coder 옵션은 vLLM 0.6.x 이상에서 지원됩니다. 버전이 낮다면 먼저 업그레이드해주세요.

bash

pip install "vllm>=0.6.0"
 
# 단일 GPU 환경 (RTX 4090 등, 30B 모델 기준)
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-Coder-30B-A3B-Instruct \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --port 8000
 
# 멀티 GPU 환경 (A100 8장 등, 480B 모델 서빙이 필요한 경우)
# python -m vllm.entrypoints.openai.api_server \
#   --model Qwen/Qwen3-Coder-480B-A35B-Instruct \
#   --tensor-parallel-size 8 \
#   --max-model-len 131072 \
#   ...

서버가 뜨면 기존 OpenAI SDK 코드의 base_url만 바꿔서 바로 사용할 수 있습니다.

python

from openai import OpenAI
 
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"  # 로컬 서버는 아무 값이나 가능합니다
)
 
response = client.chat.completions.create(
    model="Qwen/Qwen3-Coder-30B-A3B-Instruct",
    messages=[{"role": "user", "content": "Python으로 이진 탐색 구현해줘"}]
)
print(response.choices[0].message.content)

IDE 연동

Continue 익스텐션 연결

Continue는 VS Code와 JetBrains 양쪽을 지원하는 오픈소스 AI 코딩 보조 도구입니다. 설치 후 .continue/config.json에 아래 설정을 추가해주시면 됩니다.

json

{
  "models": [{
    "title": "Qwen3-Coder (Local)",
    "provider": "ollama",
    "model": "qwen3-coder",
    "contextLength": 32768
  }]
}

백엔드로 Ollama 대신 vLLM을 쓴다면 "provider": "openai"로 바꾸고 "apiBase": "http://localhost:8000/v1"을 추가하면 됩니다.

CLINE + vLLM (에이전틱 워크플로우)

장단점 분석

실제로 몇 주 써보면서 느낀 점을 정리해봤습니다. 제가 가장 불편했던 건 KV 캐시 메모리 문제였는데, 표 아래에 좀 더 자세히 적어뒀습니다.

장점

항목	내용
비용	Qwen API는 Claude Opus 4.x 대비 입력 토큰 기준 약 17배 저렴, 로컬 실행 시 초기 비용 이후 무과금
성능	480B 모델 기준 SWE-bench Verified 69.6%, 에이전틱 멀티스텝 추론에서 경쟁력 있는 수치
컨텍스트	256K 네이티브 컨텍스트로 대형 코드베이스 통째로 처리 가능
유연성	완전 오픈웨이트, 파인튜닝·상업적 활용 가능, 주요 추론 프레임워크 전부 지원
언어 지원	Python, JavaScript, Java, C++, Go, Rust 등 광범위한 커버리지
데이터 보안	민감한 코드가 외부 API 서버로 나가지 않음

단점 및 주의사항

항목	내용	대응 방안
최상위 모델 대비 성능	Claude Opus 4.x(SWE-bench 80%+)나 GPT-4.1에는 아직 격차	일상 코딩 작업에는 충분, 고난도 작업만 클라우드 병행
하드웨어 요구사항	30B Q4_K_M 기준 최소 16GB VRAM 필요	양자화 레벨 조정 또는 CPU 혼합 추론 활용
Ollama 도구 호출	구버전 Ollama에서 Qwen tool calling 지원 불안정	에이전틱 워크플로우에는 LM Studio 또는 vLLM 권장
KV 캐시 메모리	컨텍스트 길이에 비례해 메모리 급증	24GB GPU에서 Q5_K_M 기준 32K 토큰이 현실적 상한

실무에서 가장 흔한 실수

Ollama 기본 컨텍스트로 그냥 쓰기: 4096 토큰 제한에서 돌아가는 Qwen3-Coder는 제 성능을 낼 수 없습니다. 모델은 멀쩡히 실행되는데 왜 성능이 안 나오지 싶다면, 컨텍스트 크기를 먼저 확인해보시면 좋습니다. 대부분 여기서 해결됩니다.
480B 모델을 무조건 선택하기: 30B-A3B Flash 모델도 일반 코딩 작업에서 충분히 좋은 성능을 보입니다. 하드웨어 환경 확인 없이 풀 모델을 받으려다 디스크 공간이나 VRAM에서 막히는 경우가 많습니다. 480B Q4 양자화만 해도 200GB 이상 디스크 공간이 필요합니다.
에이전틱 워크플로우에서 Ollama 도구 호출 사용: CLINE이나 Qwen Code CLI처럼 도구 호출 기반 에이전틱 워크플로우를 쓴다면, 구버전 Ollama보다 LM Studio나 vLLM의 안정성이 훨씬 좋습니다. 같은 모델인데 에이전트가 오동작한다면 이 부분부터 확인해보시면 대부분 해결됩니다.

마치며

지금 바로 시작해볼 수 있는 3단계입니다.

Ollama로 체험해보기: ollama pull qwen3-coder 후 ollama run qwen3-coder --context-size 32768로 실행해볼 수 있습니다. 설정 자체는 5분이지만 30B 모델 다운로드에 네트워크 속도에 따라 30분에서 수 시간이 걸릴 수 있습니다. 16GB 이상 VRAM이 있다면 Q4_K_M 버전이 기본으로 선택됩니다.
IDE에 연결해서 실제 코딩 작업에 써보기: Continue 익스텐션 설치 후 위의 .continue/config.json 설정을 추가하면 VS Code나 JetBrains 안에서 인라인 AI 지원을 받을 수 있습니다.
팀 공용 서버가 필요하다면 vLLM으로 전환: GPU 서버 한 대에 vLLM API 서버를 올리면, 팀 전체가 기존 OpenAI SDK 코드 그대로 엔드포인트만 바꿔서 로컬 모델을 쓸 수 있습니다.

참고 자료

#Qwen3-Coder#LLM로컬실행#MoE#vLLM#llama.cpp#GGUF양자화#Ollama#에이전틱AI#SWE-bench#KV캐시

핵심 개념

Qwen3-Coder는 왜 "코딩 특화"인가

256K 컨텍스트가 실제로 의미하는 것

에이전틱 설계: 단순 자동완성과 다른 점

실전 적용

예시 1: Ollama로 빠르게 시작하기

예시 2: llama.cpp + GGUF (소비자 GPU / Mac)

예시 3: vLLM으로 팀 공용 API 서버 구축

IDE 연동

Continue 익스텐션 연결

CLINE + vLLM (에이전틱 워크플로우)

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

Qwen3-Coder는 왜 "코딩 특화"인가

256K 컨텍스트가 실제로 의미하는 것

에이전틱 설계: 단순 자동완성과 다른 점

실전 적용

예시 1: Ollama로 빠르게 시작하기

예시 2: llama.cpp + GGUF (소비자 GPU / Mac)

예시 3: vLLM으로 팀 공용 API 서버 구축

IDE 연동

Continue 익스텐션 연결

CLINE + vLLM (에이전틱 워크플로우)

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

오픈웨이트 vs 클로즈드 AI 2026: 벤치마크 격차가 좁혀진 지금, 선택의 기준이 바뀌었다

에이전틱 AI 설계 7대 패턴

사내 REST API를 LLM이 직접 호출하게 만드는 법: TypeScript MCP 서버 구현과 Gateway 패턴

AI 에이전트 LLM 비용이 폭증하는 구조와 60~80% 절감 전략

LLM 에이전트 출력 검증: 할루시네이션이 JSON 스키마를 통과하는 이유와 3레이어 방어 설계

AI 에이전트 상태 관리 아키텍처 — LangGraph 체크포인팅으로 프로덕션 신뢰성 확보하기