모델 쇼다운 라운드 7: 실제 코딩 작업에서의 5개 로컬 모델 vs 1개 클라우드 모델 비교

5개의 로컬 모델. 1개의 프론티어 클라우드 모델. 동일한 코딩 작업. 가이드 없음.

단 두 개만이 코드를 완성했습니다. 그중 하나는 클라우드 모델이었습니다.

이 시리즈의 목표 중 하나는 로컬 모델의 생존 가능성과 성숙도를 지속적으로 테스트하는 것입니다. 저는 이미 기본적인 에이전트 작업 (basic agentic tasks)에 대해 이를 수행한 바 있습니다. 오늘은 코딩 작업을 다시 다루어 보겠습니다.

우리는 무엇을 배웠을까요?

로컬 모델은 아직 준비되지 않았습니다 — 적어도 저와 같은 홈랩(homelab) 환경에서는 말이죠. 아마도 수백 기가바이트의 통합 메모리(예를 들어, 구형 Mac Studio 사용자분들)를 보유하고 있다면 완전히 양자화되지 않은 (unquantized) 모델을 실행할 수 있을 것입니다. 하지만 가장 강력한 소비자용 discrete GPU를 사용하더라도, 로컬 모델은 코딩을 할 수 없습니다.

자세히 살펴보겠습니다.

설정 (The Setup)

이번은 Model Showdown 시리즈의 라운드 7입니다. 이전 라운드에서는 Opus, Sonnet, GPT-5.5, Qwen cloud와 같은 클라우드 모델들을 서로 비교했습니다. 이번에는 다른 질문에 답하고 싶었습니다: 소비자용 하드웨어에서 실행되는 로컬 모델이 실제로 실제 에이전트 코딩 작업 (agentic coding task)을 완료할 수 있는가?

홈랩 사양:

CPU: AMD Ryzen 9 9950X3D, 64GB RAM
GPU: NVIDIA RTX 5090, 32GB VRAM
추론 (Inference): llama.cpp b9660, 8080 포트에서 단일 모델 서빙
에이전트 플랫폼 (Agent platform): Coder Agents v2.34.0
OS: Ubuntu 24.04, NVIDIA Driver 590.48.01, CUDA 13.1

모든 로컬 모델은 하드웨어가 허용하는 한 가장 공격적으로 구성되었습니다 — flash attention, 양자화된 KV 캐시 (quantized KV cache, q8_0), 그리고 VRAM이 허용하는 최대 컨텍스트 창 (context windows)을 적용했습니다.

참가자 (The Contestants)

모델	유형	양자화 (Quant)	VRAM	컨텍스트 (Context)	최대 출력 (Max Output)
Qwen 3.6 35B-A3B	로컬 MoE	UD-Q4_K_XL (21GB)	~21GB	131,072	81,920
...

Sonnet 4는 대조군 (control variable)입니다. 저는 그것이 무엇을 할 수 있는지 이미 알고 있습니다. 질문은 로컬 모델들이 얼마나 근접할 수 있느냐 하는 것입니다.

작업: 관리자 태그 매니저 (Admin Tag Manager)

이전 라운드에서는 "이미지 관리" 기능을 사용했으나, 이는 저장소(repo)의 기존 코드와 충돌했습니다. 라운드 7을 위해 저는 클린룸(clean-room) 작업을 설계했습니다: 블로그 관리자 패널을 위한 태그 매니저(tag manager) 구축입니다.

블로그에는 이미 태그가 있습니다. 포스트는 MDX 프론트매터(frontmatter)의 tags[] 배열을 사용하며, 공개된 /tags 페이지가 있고, src/lib/posts.ts에는 getAllTags() 함수가 있습니다. 하지만 이를 관리할 관리자 UI는 없습니다.

각 모델에는 동일한 프롬프트가 제공되었습니다:

목표: /admin 섹션에 태그 매니저(Tag Manager)를 추가하십시오.

요구사항:

src/lib/tags.ts 생성 — 포스트 수와 함께 태그 목록 표시, 고립된 태그(orphans) 감지, 이름 변경 및 병합 지원

src/app/api/admin/tags/route.ts 생성 — GET, PATCH, DELETE 엔드포인트(endpoints)

src/app/admin/tags/page.tsx 생성 — 인라인 이름 변경, 삭제, 정렬 기능이 포함된 테이블

AdminNav에 "Tags" 추가

새로고침을 포함한 클라이언트 사이드 뮤테이션(Client-side mutations) 적용 (전체 페이지 새로고침 금지)

npm run build 시 오류가 전혀 없어야 함

Playwright MCP를 통해 스크린샷 촬영

논리적 단위(chunks)로 커밋하고 브랜치에 푸시(push)

PR(Pull Request)을 생성하지 말 것

열 가지의 요구사항. 실제 코드베이스. 실제 빌드 시스템. 실제 Git 워크플로우.

방법론 (The Methodology)

각 모델은 동일한 main 커밋에서 포크(fork)된 각자의 독립적인 브랜치(run-10부터 run-15까지)를 할당받았습니다. 로컬 모델들은 llm-switch.sh를 통해 한 번에 하나씩 로드되었으며, localhost:8080의 llama-server를 통해 서비스되었습니다. Sonnet 4는 Coder의 내장된 Anthropic 프로바이더(provider)를 통해 실행되었습니다.

모델과 실행(run)의 할당은 무작위로 이루어졌으며 실행 전에 봉인되었습니다. 저는 6개의 실행이 모두 완료(또는 실패)될 때까지 어떤 모델이 어떤 실행인지 알 수 없었습니다.

인간의 개입에 관한 참고 사항: 저는 각 세션을 실시간으로 모니터링하며, 정체된 모델에게 가끔씩 독려(

가장 뛰어난 성능을 보인 로컬 모델입니다. 이 모델은 저장소(repo)를 복제하고, 코드베이스를 탐색하며, 요구된 4개의 파일(410줄의 코드)을 모두 생성했습니다. 세 번의 빌드 시도 과정에서 TypeScript 오류를 수정했으며, 작동하는 커밋(commit)을 푸시(push)했습니다.

하지만 깔끔하지는 않았습니다. 작업 디렉토리(working directory) 문제를 해결하는 데에만 약 8번의 도구 호출(tool calls)을 낭비했습니다(각 execute 호출 시 /home/coder로 초기화되기 때문에, 저장소로 cd 하는 것을 계속 잊어버렸습니다). 커밋을 마친 후에는 자신의 API 라우트(API route) 파일이 존재하는지 여부에 대해 혼란을 겪으며 30번의 도구 호출을 추가로 소모했습니다. 이미 커밋된 것을 삭제하고 다시 생성하려고 시도한 것입니다.

스크린샷도 없었고, 논리적인 커밋 청킹(commit chunking)도 없었습니다(모든 것이 하나의 커밋에 담겼습니다). 하지만 작동하는 코드를 배포(ship)했다는 점에서, 이 모델은 로컬 모델들 사이에서 독보적인 위치를 차지합니다.

Qwen 3.6 35B-A3B (Run 13): 비극적 영웅

이 사례는 정말 안타깝습니다. Qwen 3.6은 실제로 구현을 완료했습니다. 코드베이스를 철저히 탐색하고, 4개의 파일을 모두 작성했으며, 타입 오류(type error)를 수정하고, npm run build가 깔끔하게 통과되도록 만들었습니다.

그러고 나서 이 모델은 커밋하기 전에 Playwright 스크린샷이 필요하다고 결정했습니다.

이후 77개의 메시지 — 전체 세션의 50% 이상 — 를 Playwright를 설치하려 애쓰고, 누락된 Chromium 의존성(dependencies)과 싸우며, 브라우저 실행 실패를 디버깅하고, 스크린샷 스크립트를 네 번이나 다시 쓰고, 인증되지 않은 페이지 로드를 차단하는 인증 미들웨어(auth middleware)와 씨름하는 데 사용했습니다. 결국 스크린샷은 찍지 못했습니다. 커밋도 하지 못했습니다. 푸시도 하지 못했습니다.

코드는 바로 그곳에 있었습니다. 빌드도 통과했습니다. 실행 준비가 끝난 상태였습니다. 하지만 모델은

Gemma는 저장소(repo)를 클론하고, 기존 코드를 읽은 뒤, 세 개의 새로운 파일과 네비게이션 업데이트를 모두 작성했습니다. 합리적인 시작이었습니다. 그 후 npm run build를 실행했으나, gray-matter의 stringify() 함수에서 타입 오류(type error)가 발생했습니다.

해결 방법은 간단했습니다: matter.stringify(content, data) — 첫 번째 인자는 content 문자열, 두 번째 인자는 data 객체여야 합니다. Gemma는 인자(arguments)의 순서를 거꾸로 알고 있었습니다. Gemma는 해당 호출을 6가지 변형으로 시도했고, tags.ts를 6번 다시 작성했으며, 7번의 빌드를 실행했습니다. 하지만 단 한 번도 올바른 인자 순서를 시도하지 않았습니다. gray-matter의 타입 정의(type definitions)를 읽지도 않았고, 문서(docs)를 확인하지도 않았습니다.

5번째 빌드 실패 이후, 모델은 **퇴행적 텍스트 생성 루프 (degenerate text generation loop)**에 빠졌습니다. "src/lib/tags.ts가 올바른지 확인하겠습니다"라는 문장을 26번 연속으로 출력했습니다. 루프를 끊기 위해 "stop" 명령을 보내야만 했습니다.

Hermes 4 14B (Run 12): 죽지 않는 임포트 경로

Hermes는 프로젝트 구조를 먼저 탐색하지 않고 곧바로 코드 작성으로 넘어갔습니다. 두 개의 파일을 생성하고 npm run build를 실행했습니다. 발생한 에러는 다음과 같습니다:

Module not found: Can't resolve '../../../lib/tags'

src/app/api/admin/tags/route.ts에 있는 라우트 파일에는 ../../../../lib/tags (4단계 상위) 또는 @/lib/tags (Next.js 경로 별칭 (path alias))가 필요합니다. Hermes는 3단계만 사용했습니다. 하나가 모자랐습니다.

모델은 이를 진단하지 못했습니다. 대신, 잘못된 임포트 경로를 그대로 둔 채 두 파일을 다시 작성하고 재빌드하기를 13번 반복했습니다. 메시지 34번 이후의 출력물은 매 반복마다 거의 토씨 하나 틀리지 않고 동일했습니다. 같은 코드, 같은 에러, 같은 "수정". 제가 "stop"을 보냈을 때도, 모델은 신호를 인지하기 전까지 5번의 도구 호출(tool calls)을 더 수행했습니다.

Devstral 24B (Run 10): 시작조차 못한 모델

Devstral은 단 한 번의 도구 호출(tool call)도 실행하지 못했습니다. 존재하지도 않는 Python 프로젝트에 대한 가짜 대화 전체를 환각(hallucinate)해냈고, 그 후 execute, read_file, write_file과 같이 도구 호출처럼 보이는 것들을 내뱉었지만, 이를 어시스턴트 메시지 내에 **일반 텍스트 (plain text)**로 렌더링했습니다. 플랫폼이 이를 구조화된 도구 호출로 파싱할 수 없었기 때문에, 아무런 일도 일어나지 않았습니다.

이것은 근본적인 호환성 실패입니다. 모델이 Coder의 도구 호출 (tool-calling) 프로토콜과 전혀 인터페이스를 형성할 수 없었습니다. 9개의 메시지, 14K 토큰, 하지만 실행된 동작은 0건이었습니다.

토큰 효율성 격차 (The Token Efficiency Gap)

저를 멈춰 세운 숫자는 바로 이것입니다:

모델	총 토큰 수	결과
Sonnet 4	19,237	완료 (4개 커밋, 스크린샷)
...

Sonnet은 작업을 완료하는 데 19K 토큰을 사용했습니다. 실제로 시도했던 로컬 모델들은 100만~400만 토큰을 소모했으며 대부분 실패했습니다. 동일한 작업에 대해 100~200배의 토큰 효율성 격차가 발생한 것입니다.

로컬 모델들은 단순히 느린 것이 아닙니다. 이들은 진행 단위당 근본적으로 더 많은 일을 하고 있습니다. 이미 읽은 파일을 다시 읽고, 방금 작성한 코드를 다시 쓰고, 동일한 오류로 다시 빌드하며, 동일한 추론 과정을 반복합니다. 이것은 속도의 문제가 아니라 사고 (thinking)의 문제입니다.

공통적인 실패 패턴

충분히 오래 실행된 모든 로컬 모델은 동일한 병리적 현상을 보였습니다:

1. 퇴행적 루프 (Degenerate loops). Gemma는 동일한 텍스트를 26번 반복했습니다. Hermes는 잘못된 임포트 (import)를 포함한 채 13번이나 다시 빌드했습니다. Qwen 3.6은 동일한 방식으로 스크린샷 스크립트를 4번이나 다시 작성했습니다. 로컬 모델이 일단 루프에 빠지면, 인간의 개입 없이는 빠져나올 수 없습니다.

2. 작업 디렉토리 건망증 (Working directory amnesia). Coder의 execute 도구는 호출 간에 cd 상태를 유지하지 않습니다. Sonnet은 이를 즉시 학습하여 모든 명령 앞에 접두사를 붙였습니다. 여러 로컬 모델은 이 사실을 재발견하느라 세션당 5~10번의 도구 호출을 낭비했습니다.

3. 우선순위 설정 능력 부족 (Inability to prioritize). Qwen 3.6은 빌드에 성공했음에도 불구하고, 커밋을 하는 대신 Playwright 관련 부수적인 작업 (yak-shave)에 매달리는 것을 선택했습니다. 어떤 로컬 모델도 작동하는 것을 배포하고 반복 개선하는 판단력을 보여주지 못했습니다.

4. 자기 진단 능력 부재 (No self-diagnosis). 빌드가 실패하면 오류를 읽고, 가설을 세우고, 다른 방법을 시도하는 수정 과정이 필요합니다. Hermes와 Gemma는 모두 동일한 수정 방법을 반복해서 시도했습니다. 두 모델 모두 문서를 읽거나, 타입 정의 (type definitions)를 확인하거나, 프로젝트 설정을 검토하기 위해 한 걸음 물러나는 모습을 전혀 보이지 않았습니다.

내가 실제로 배운 것

로컬 모델은 그럴듯한 코드를 작성할 수 있습니다. 5개의 로컬 모델 중 4개가 문법적으로 타당한 TypeScript를 생성했습니다. 코드는 올바르게 보였습니다. 아키텍처도 합리적이었습니다. 하지만 디버깅, 빌드, 커밋, 배포(shipping)와 같은 '라스트 마일(last mile)' 단계에서 이들은 무너집니다.

에이전트 격차(agentic gap)는 코딩 격차보다 더 큽니다. 이 모델들은 코드를 생성할 수 있습니다. 하지만 이들이 하지 못하는 것은 에이전트로서 작동하는 것(operate as agents) — 즉, 도구 호출(tool calls) 전반에 걸쳐 상태를 관리하고, 오류를 진단하며, 작업의 우선순위를 정하고, 언제 멈춰서 배포해야 할지를 아는 능력입니다. 이는 코드 생성과는 다른 역량이며, 현재 로컬 모델들이 가장 취약한 부분입니다.

토큰 효율성(Token efficiency)이 진정한 벤치마크입니다. 단순한 파라미터 수와 컨텍스트 윈도우(context window)는 에이전트로서의 성공을 예측하지 못합니다. Qwen 3.6은 가장 큰 컨텍스트(131K)를 가졌고 가장 많은 토큰(3.89M)을 소모했지만, 여전히 배포에 성공하지 못했습니다. 반면 Sonnet은 100배 적은 토큰을 사용하고도 모든 작업을 완료했습니다. 병목 현상은 컨텍스트가 아니라, 토큰당 추론 품질(reasoning quality per token)에 있습니다.

도구 호출(Tool-calling) 호환성이 보장되지 않습니다. Devstral은 에이전트형 코딩 모델로 마케팅되지만, 도구 호출 프로토콜과 인터페이스조차 연결하지 못했습니다. 에이전트 용도로 로컬 모델을 평가하고 있다면, 도구 호출 능력을 먼저 테스트하십시오.

Qwen3-Coder는 주목해야 할 로컬 모델입니다. 이번 테스트에서 실제로 코드를 배포한 유일한 로컬 모델입니다. 지저분하고, 단일 커밋이며, 스크린샷도 없었지만 — 브랜치에 작동하는 코드가 푸시되었습니다. 단일 소비자용 GPU에서 실행되는 30B MoE 모델이라는 점을 고려하면 이는 주목할 만한 성과입니다.