로컬 코딩 모델은 어디까지 왔나: Qwen3.6 27B와 llama.cpp, OpenCode 조합

AI 코딩 도구라고 하면 보통 Claude Code, Codex, Cursor, Gemini CLI 같은 클라우드 기반 도구를 먼저 떠올립니다. 성능이 좋고, 설치가 쉽고, 최신 모델을 바로 쓸 수 있기 때문입니다. 최근에는 로컬에서 돌리는 코딩 모델도 선택지로 쓰이기 시작했습니다.

Qwen3.6 27B + llama.cpp + OpenCode 조합은 아직 최상위 클라우드 에이전트를 대체하지 못합니다. 대신 코드 설명, 작은 수정, 로그 해석, 테스트 초안 작성처럼 자주 반복되는 개발 작업은 로컬에서 처리할 수 있습니다.

기준 작성 시점 2026-06-30에 확인한 Qwen3.6-27B Hugging Face 모델 카드, Unsloth Qwen3.6 문서, Quesma 실사용기 기준입니다.

이 글에서 다루는 질문은 세 가지입니다.

왜 Qwen3.6 27B가 로컬 코딩 모델의 sweet spot으로 언급되는가?
llama.cpp와 GGUF, MTP는 로컬 실행의 어떤 문제를 줄이는가?
OpenCode 같은 코딩 에이전트에 붙였을 때 어떤 작업까지 맡길 수 있는가?

왜 Qwen3.6 27B인가

Qwen3.6-27B 모델 카드 ↗는 이 모델을 27B 파라미터의 post-trained 모델로 설명합니다. Qwen은 이 모델의 강점으로 agentic coding, frontend workflow, repository-level reasoning을 듭니다.

27B는 모델 크기 면에서 중간에 있습니다. 7B급 모델은 가볍지만 복잡한 코딩 작업에서는 한계가 빨리 드러납니다. 반대로 70B급 이상 모델은 품질은 좋아도 개인 장비에서 굴리기 부담스럽습니다. 27B급은 그 사이에 있습니다.

Unsloth의 Qwen3.6 문서 ↗는 Qwen3.6-27B의 4-bit 실행 요구량을 18GB, 8-bit 실행 요구량을 30GB로 제시합니다. 모든 노트북에서 가벼운 수준은 아닙니다. 고사양 Apple Silicon이나 VRAM이 충분한 데스크톱이라면 시도할 수 있는 범위입니다.

주의 로컬에서 실행할 수 있어도 모든 환경에서 쾌적하지는 않습니다. 컨텍스트 길이, 양자화 비트수, KV cache 설정, GPU 메모리 여유에 따라 속도와 안정성이 크게 달라집니다.

로컬 실행의 세 계층

로컬 코딩 모델은 모델 하나만으로 완성되지 않습니다. 실제로는 모델, 런타임, 코딩 에이전트가 함께 맞물려야 합니다.

flowchart TD
    A[Qwen3.6 27B<br/>모델 가중치] --> B[GGUF / MTP<br/>양자화와 추론 최적화]
    B --> C[llama.cpp<br/>로컬 OpenAI-compatible 서버]
    C --> D[OpenCode<br/>코드베이스 작업 루프]
    D --> E[설명 / 수정 / 테스트 초안 / 리뷰]

llama.cpp README ↗는 프로젝트의 목표를 “minimal setup”과 다양한 하드웨어에서의 LLM inference로 설명합니다. Apple Silicon은 Metal과 Accelerate로 지원합니다. NVIDIA GPU는 CUDA, AMD GPU는 HIP를 쓰고, 그 밖에 Vulkan과 SYCL 백엔드도 지원합니다.

모델 파일은 GGUF 형식으로 받습니다. Qwen의 llama.cpp 실행 문서 ↗에 따르면 GGUF는 모델 가중치, 하이퍼파라미터, 기본 generation configuration, tokenizer 등을 한 파일에 담는 포맷입니다. 로컬 런타임은 이 파일 하나로 모델을 불러옵니다.

마지막으로 MTP가 있습니다. Unsloth Qwen3.6 MTP GGUF 페이지 ↗는 MTP가 약 1.5~2배 빠른 추론을 가능하게 한다고 설명합니다. Unsloth 문서에 따르면 Qwen3.6 MTP GGUF는 llama.cpp에서 실행할 수 있고, --spec-type draft-mtp와 --spec-draft-n-max 같은 옵션을 사용합니다.

llama.cpp로 OpenAI 호환 서버 띄우기

Quesma의 실사용기는 llama-server로 Qwen3.6 27B MTP GGUF를 띄우고, OpenCode가 http://127.0.0.1:8080/v1을 바라보게 합니다. 이 구성에서 로컬 모델은 채팅 CLI로 쓰이지 않고 OpenAI-compatible API 서버로 동작합니다.

예시는 이런 형태입니다.

llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q8_0 \
  --spec-type draft-mtp -ngl 999 -fa on -c 65536 --port 8080

--port 8080으로 포트를 고정해 두면 OpenCode 같은 도구가 같은 endpoint를 계속 바라볼 수 있습니다.

OpenCode 쪽은 provider 설정으로 로컬 서버를 붙입니다. OpenCode provider 문서 ↗에 따르면 OpenCode는 AI SDK와 Models.dev로 여러 provider를 지원합니다. custom endpoint나 local model도 provider 설정으로 붙일 수 있습니다.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama": {
      "name": "llama.cpp (local)",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1",
        "apiKey": "local"
      },
      "models": {
        "qwen3.6-27b": {
          "name": "Qwen3.6-27B Q8 +MTP"
        }
      }
    }
  },
  "model": "llama/qwen3.6-27b"
}

이 설정을 마치면 로컬 모델이 OpenCode의 작업 루프 안에서 코드베이스를 대상으로 질문에 답하고, 코드를 수정하고, 변경을 검토합니다.

무엇을 맡기기 좋은가

Qwen3.6 27B를 로컬 코딩 모델로 쓸 때는 “Claude Code나 Codex를 이기는가?”보다 “어떤 작업은 클라우드 최상위 모델까지 부르지 않아도 되는가?”를 따집니다.

로컬 모델에 잘 맞는 작업은 대체로 작고 반복적입니다.

작업	로컬 모델에 맡기기 좋은 이유
코드 설명	파일 일부나 함수 단위 맥락이면 충분한 경우가 많습니다.
작은 리팩터링	이름 정리, 조건문 단순화, 타입 힌트 보강처럼 범위가 좁습니다.
테스트 초안	완성도보다 빠른 초안과 edge case 목록이 먼저 필요합니다.
로그 해석	민감한 로그를 외부 API에 보내기 어려운 경우가 있습니다.
문서화	README, 주석, 변경 요약처럼 반복 생성 작업이 많습니다.

반대로 큰 설계 변경, 여러 패키지에 걸친 리팩터링, 보안·결제·데이터 손실 위험이 있는 수정에는 여전히 상위 클라우드 모델과 사람의 리뷰가 필요합니다. 코딩 에이전트의 성능에는 코드 생성 능력과 함께 작업 분해, 파일 탐색 순서, 실패 복구, 테스트 해석이 포함되기 때문입니다.

Tip 로컬 모델은 항상 켜둘 수 있는 1차 필터로 둡니다. 작은 작업은 로컬에서 처리하고, 큰 판단이 필요할 때만 클라우드 모델로 넘깁니다.

기존 로컬 LLM 글과의 차이

이 블로그에서는 이미 Ollama + EXAONE 3.5 설치 가이드에서 Mac에서 로컬 LLM을 설치하고 API로 활용하는 흐름을 다뤘습니다. 그 글은 로컬 LLM을 시작하는 방법을 다뤘고, 이번 글은 로컬 LLM을 코딩 에이전트의 실행 계층에 넣는 방법을 다룹니다.

token-router 로컬 LLM 라우터에서는 작은 로컬 모델이 큰 문서에서 필요한 원문 조각을 찾아 클라우드 모델로 넘겼습니다. 이번 글에서는 로컬 모델이 라우터 역할에 그치지 않고, OpenCode 같은 도구 안에서 코드 작업 일부를 직접 수행합니다.

터미널 기반 에이전트라는 점에서는 Hermes Agent와 ChatGPT OAuth 연동과도 이어집니다. Hermes 글은 클라우드 모델을 로컬 CLI에 붙였고, Qwen3.6 조합은 모델 자체까지 로컬에 둡니다.

한계는 세팅 비용이다

로컬 모델을 쓰면 API 비용 부담이 줄고, 민감한 코드나 로그를 외부로 덜 보내도 됩니다. 네트워크나 provider rate limit의 영향을 덜 받고, 모델 파일과 런타임을 직접 통제할 수 있습니다.

대신 운영자가 챙겨야 할 일이 늘어납니다.

어떤 GGUF quant를 받을지 고르기
컨텍스트 길이와 메모리 사용량 조정하기
llama-server 옵션을 하드웨어에 맞게 조정하기
OpenCode provider 설정을 맞추기
느린 응답, OOM, 깨진 출력이 나올 때 원인 좁히기

Qwen3.6은 긴 컨텍스트와 thinking 계열 기능을 지원하지만, 이 기능을 모두 켜면 메모리 요구량도 올라갑니다. Qwen 모델 카드 ↗는 기본 context length를 262,144 tokens로 설명합니다. 로컬 개발 환경에서 OOM이나 느린 응답이 나온다면 컨텍스트 길이를 작업 단위에 맞춰 먼저 줄입니다.

로컬 코딩 모델의 현재 위치

Qwen3.6 27B + llama.cpp + OpenCode 조합은 최고급 클라우드 에이전트를 완전히 대체하지 못합니다. 그래도 데모나 취미 실험 수준은 넘었습니다. 27B 모델이 반복 작업을 처리할 수 있고, llama.cpp가 로컬 실행 경로를 제공하며, OpenCode가 그 모델을 실제 코드 작업 루프에 연결합니다.

로컬 모델은 매번 클라우드 API를 호출하지 않는 코딩 도우미로 쓸 수 있습니다. 회사 코드나 개인 프로젝트를 밖으로 보내지 않는 분석기, 부담 없이 반복해서 물어볼 수 있는 보조 엔진으로도 쓸 수 있습니다.

참고 자료

Qwen/Qwen3.6-27B Hugging Face 모델 카드 ↗ — 모델 개요, 파라미터, 컨텍스트 길이, 벤치마크
Unsloth Qwen3.6 실행 문서 ↗ — 로컬 실행 요구량, GGUF, MTP 설명
unsloth/Qwen3.6-27B-MTP-GGUF ↗ — llama.cpp MTP 실행 예시
Qwen llama.cpp 문서 ↗ — GGUF와 llama.cpp 실행 경로
Quesma: Qwen 3.6 27B is the sweet spot for local development ↗ — OpenCode 연동 실사용기