에이전트 코딩에 로컬 LLM 활용하기

(blog.alexewerlof.com)

21P by GN⁺ 19시간전 | ★ favorite | 댓글 7개

클라우드 플래그십 모델의 가격 급등 속에서, 비용 부담 없이 코딩 작업을 이어갈 수 있는 로컬 모델 활용법 정리
로컬 모델은 SOTA 모델 성능에 미치지 못하지만 가격 대비 성능과 결정론적 하니스(deterministic harness) 보강으로 품질을 최대 6배까지 끌어올릴 수 있음
코딩용으로는 Gemma 4가 일반 작업과 코드 생성 사이 균형이 좋으며, Tools Use·Vision·Reasoning 지원으로 VS Code 연동에 적합
LM Studio로 모델 서버를 띄우고 VS Code Copilot·Pi의 커스텀 엔드포인트에 연결하는 전체 설정 절차 제공
하드웨어가 부족하면 OpenRouter 무료 모델을 대안으로 사용 가능하며, 로컬 모델은 오프라인·프라이버시 측면에서 여전히 우위

가격 인상 배경

GitHub Copilot이 크레딧 모델에서 사용량 기반 과금으로 전환했고, 기존 무료 모델도 더 이상 무료가 아님
GitHub는 토큰 리셀러이기 때문에 가격 인상 체감이 더 큼. 플래그십 모델은 성능 향상 속도가 가격 인상 속도를 따라오지 못한 채 출시됨
- Google Flash 3.5는 Flash 2.5 대비 3배 비쌈
- GPT 5.5는 GPT 5 대비 3배 비쌈
- Claude는 이미 너무 비쌌던 탓에 오히려 가격을 하향 조정

로컬 모델의 현실과 강점

로컬 모델은 Claude·GPT·Gemini 같은 SOTA 모델 성능에는 못 미치지만, 몇 가지 뉘앙스(nuance) 존재
- 가격/성능 비율: 클라우드 모델은 성능 향상 대비 비용이 기하급수적으로 증가
- 결정론적 하니스: 더 나은 툴링·지침으로 약한 모델 품질을 최대 6배까지 개선 가능
- 벤치마크의 함정: 모델을 단일 수치로 환산하기 어렵고, 각 AI 랩은 자사에 유리한 벤치마크에 집중하므로 본인 워크로드로 직접 평가 필요
- 지정학적 효과: 미국 랩이 무료로 공개하는 것은 최고 수준이 아님. gpt-oss-20b는 너무 오래됐고 Anthropic은 오픈 웨이트 미공개. Gemma 4가 유일하게 진지한 모델이며, Qwen·Kimi·GLM 등 중국 랩의 유능한 모델 공개에 주목
"brain rot" 현상 관점에서, 약한 모델은 사용자가 더 개입해야 하므로 두뇌 건강에 이로움
- 자전거를 타는 것처럼 느리지만 건강에는 좋음. 지식 노동에서 "느린 것이 빠른 것(slow is fast)"
- 목표는 사고를 기계에 떠넘기는 자동화 극대화가 아님. 단기 속도를 위해 미래의 자기 가치(relevance) 를 희생하지 말 것
- 약한 모델을 다루는 기법은 큰 모델에도 적용됨. 약한 모델 다루기는 하드 모드 플레이와 같아, 익히면 큰 도구를 더 효과적으로 활용 가능

모델 선택 — Gemma 4

코딩용으로는 중국 모델이 Huggingface 리더보드 상위를 차지하며, Qwen·DeepSeek·Kimi·Llama·Gemma 등 존재
Gemma 4는 여러 버전으로 구성
- E2B: "E"는 edge를 의미. 2B 파라미터로 대부분 하드웨어에서 구동되나 환각이나 작업 미완료 위험이 높음
- E4B: E2B의 두 배 크기. 다운로드·설정이 저렴해 시작용으로 권장
- 12B: 디코더 없이 이미지를 네이티브로 이해해 프론트엔드·시각 코딩에서 더 빠름. 오디오도 네이티브 지원하나 코딩 워크로드에는 비중요
- 26B A4B: 26B 파라미터 중 4B만 활성화되는 MoE(mixture of experts) 아키텍처. E4B보다 똑똑하면서 8~12GB VRAM 그래픽카드에 적합 (저자 선호 모델)
- 31B: Google 최대 오픈 웨이트 모델. MoE가 아니라 많은 VRAM 필요. AMD APU에서 속도가 1~2 TPS로 사용 불가 수준
- QAT 변형(예: E4B QAT)은 메모리를 덜 쓰면서 거의 동일한 품질 유지. Unsloth가 추가 최적화 작업 진행

로컬 모델 구동에 필요한 구성 요소

로컬 모델 실행에는 하니스·모델·런타임·모델 매니저가 필요
- 하니스(Harness): VS Code Copilot, Copilot CLI, Pi 등. 모델(확률적 요소) 주위를 감싸는 결정론적 구성 요소(전통적 코드)
- 모델: 심층 신경망 가중치 파일. 양자화(quantization)(Q8, Q4 등)는 이미지 해상도와 유사한 개념, 포맷은 GGUF·MLX 등으로 구분
런타임 (추론 엔진)
- Llama.cpp: 가장 인기 있는 오픈소스 런타임으로 GGUF·MLX 로드 가능. Meta의 Llama 모델과는 무관하며 LM Studio가 내부적으로 사용
- MLX: Apple 런타임. M1·M2 등 Mac에서 사용
- ONNX Runtime: transformers.js 기반으로 WebGPU를 통한 브라우저 구동, iOS·Android 모바일도 지원
- vLLM: UC Berkeley 발 오픈소스로 주로 고성능 서버용, 설정 난이도 높음
모델 매니저
- Ollama: 터미널 CLI로 시작해 경량 GUI 추가. Llama.cpp를 감싼 Go 래퍼. 오픈소스
- LM Studio: 무료지만 오픈소스 아님. SDK(Python/TypeScript)와 REST API 제공, 로컬 모델 고유 기능(동적 로딩 등) 제어 가능
- Jan: 무료이면서 오픈소스인 LM Studio 유사 대안, 기능은 덜 풍부
- OpenAI 호환 API 지원이 핵심 기능으로, 다수 AI 애플리케이션이 이 사실상 표준과 동작

LM Studio 서버 설정

"Developer" 버튼에서 토글로 서버 시작. 다른 머신이나 컨테이너에서 구동 시 Serve on Local Network, 웹 앱 접근 시 Enable CORS 설정
LM Studio는 요청 시점에 모델을 적재하는 JIT(Just In Time) 로딩 사용. TTL 설정으로 메모리 유지 시간 제어 가능
- 콜드 스타트(Cold start): 모델 미적재 시 첫 요청에 약 10~30초 추가 소요, AWS Lambda 콜드 스타트와 유사. TTFT(Time To First Token) 지표에 영향
- 짧은 컨텍스트 윈도우: 기본 설정 시 컨텍스트 윈도우가 4k에 불과할 수 있어 수동 증대 필요. VS Code Copilot 모델 대부분은 200~400k 보유
컨텍스트 길이 및 메모리 설정
- 컨텍스트 길이별 VRAM 요구량: 262144(최대) = 25.74GB, 4096(기본) = 18.16GB, 150000(저자 선호) = 22.45GB
- 코딩용으로는 시스템 프롬프트가 20~40k 토큰을 차지하므로 최소 100k 토큰 적재 필요
- 컨텍스트가 너무 크면 토큰 생성 속도가 저하됨. 하니스가 컨텍스트를 자동 압축하는 지점이 최적
- 모든 모델 레이어를 GPU에서 구동하는 것이 이상적이며 "GPU Offload" 슬라이더 최대화 권장. CPU 레이어 구동은 Apple Silicon(UMA) 외에는 CPU-GPU 간 데이터 복사 필요
KV 캐시 양자화 트릭
- K Cache Quantization Type을 Q8_0, V Cache Quantization Type을 Q4_0으로 설정
- 키를 값보다 높은 해상도로 유지하는 방식. 이 설정으로 GPU 메모리 요구량을 기본 28.75GB에서 22.45GB로 감소
- 설정 저장이 필수. 미저장 시 다음 모델 적재에서 기본값으로 복귀
- VS Code Copilot은 커스텀 컨텍스트 윈도우 요청 개념이 없어 LM Studio가 REST API 호출 시 설정을 기억해야 함
TPS가 10 미만이면 코딩 용도로 견디기 어려움. 모델 대기에 더 많은 시간 소모

Copilot 커스텀 엔드포인트 연결

최신 VS Code(작성 시점 1.122.1) 필요. 모델 선택기 → 톱니바퀴 → "Add Models" → "Custom Endpoint" 경로로 추가
- 이름 지정(예: "Local LM Studio"), API Key 입력(미설정 시 엔터), 추론 API 형태 선택
- 3종 API 중 Chat Completions만 원활히 동작
JSON 설정에서 url, maxInputTokens, maxOutputTokens 등 수동 지정
- thinking 옵션을 올바르게 설정(Gemma 4 지원)
- supportsReasoningEffort 배열은 모델별로 다르며, 26B 버전이 E4B보다 세밀한 제어 지원
- 4B는 maxInputTokens 64000/maxOutputTokens 16000, 26B MoE는 100000/50000 설정
첫 프롬프트는 Copilot이 거대한 시스템 프롬프트와 툴 정의를 전송해 최초 상호작용에 2~5분 지연 발생. 모델 적재 30초, 프롬프트 입력 처리 약 5분
- 세션당 한 번만 발생하며 LM Studio가 프롬프트 캐싱 적용. Pi는 시스템 프롬프트가 작아 이 문제 없음
빠른 테스트 및 환경
- AGENTS.md나 SKILL 없이 원샷 프롬프트로 스네이크 게임을 생성해 Gemma 4 26B A4B 성능 시연
- 사용 환경: Lenovo Thinkpad L16 Gen 2, AMD Ryzen 7 PRO 250 APU, 64GB DDR5(5,600MT/s), Aurora Linux. 32GB로도 충분하다고 판단

Pi 설정

로컬 LM Studio 서버 연결이 간단하며, contextWindow 설정이 LM Studio 구성 방식과 더 잘 맞음
baseUrl을 http://host.containers.internal:1234/v1로, api를 openai-completions로 지정
- 4B는 contextWindow 64000/maxTokens 16000, 26B MoE는 150000/50000으로 설정하고 thinkingLevelMap 매핑 지정

로컬 모델의 장단점 정리

장점: 오프라인 동작, 높은 프라이버시, 하드웨어·워크플로우·모델·설정에 따른 빠른 응답 속도
단점
- 오픈 웨이트 모델은 플래그십 독점 모델만큼 똑똑하지 않으나, 적절한 가드레일(lint·테스트·AGENTS.md)을 갖춘 하니스로 코딩 정확도 크게 향상 가능
- 동일 머신에서 LLM 구동 시 하드웨어 부하로 인한 속도 저하 발생
- 콜드 스타트, 최초 프롬프트 입력 처리(캐시 미스), 높은 초기 하드웨어 투자 비용
LM Studio에 익숙해지면 GUI 없이 Llama.cpp 직접 사용 가능. 대부분의 하니스가 커스텀 엔드포인트를 지원해 로컬 LLM과 연동 가능

OpenRouter 무료 모델 대안

OpenRouter는 단일 엔드포인트·계정으로 수백 개 모델을 노출하는 통합 API·라우팅 서비스
Copilot·Zed·Pi 모두 OpenRouter를 네이티브 지원하며 API 토큰만 발급해 연결
- 비용 폭주 방지를 위해 $1/월 상한의 커스텀 가드레일 생성 후 무료 모델만 허용 목록에 추가
- 신규 API 키 생성 시 max credit을 0으로 설정 권장
단점: 프롬프트·데이터가 학습에 쓰일 수 있음(ZDR 설정 존재), 인터넷 연결 필요, OpenRouter가 무료 모델 제공을 중단할 가능성
장점: 로컬 다운로드·설정 불필요, 사용 중 컴퓨터 속도 저하 없음
2026-06-09 업데이트
- Deepseek V4 Pro를 채택. Claude Opus 4.8에 거의 준하는 성능에 5배 컨텍스트 윈도우, 약 17~86배 저렴한 가격
- Pi와 OpenRouter의 가격이 약 3배 차이 났는데, OpenRouter가 더 비싼 엔드포인트(GMICloud)로 요청을 보낸 것이 원인
- Deepseek 계정을 직접 개설해 복잡한 작업에 활용. 단순 작업·동작 이해·프라이버시 중시 상황에서는 로컬 모델이 여전히 우선 선택지

emptybynature 8시간전 [-]

일단 제 m5 max 128gb 맥북에서 로컬 llm 활용하려고 부단히 애를 써봐도 결론은 그냥 deepseek 쓰는게 훨씬 비용과 시간면에서 낫다는 결론에 도달했습니다. 그리고 로컬 모델들도 참 다양하게 써봐도 결국 deepseek v4 flash 가 제일 낫더군요. 하지만 그 마저도 클라우드 모델에 비할바는 못됩니다. 현재 llm 패러다임을 바꿀정도의 대단한 뭔가가 나오지 않는한 그리고 중국 업체들이 고맙게도 지금처럼 낮은 가격을 유지 해 주는 한 사실 로컬 llm은 장난감 용도가 최대입니다. deepseek과 mimo가 정말 너무 저렴해서 로컬 llm이 비집고 들어갈 틈이 없어요

답변달기

ly0738 11시간전 [-]

local llm은 특정 목적이 있는게 아니면 지금은 비용적으로 비효율적인 것 같아요.
프론티어 모델들은 검열이 걸려있어서 제가 요청하는 작업들을 거부하는 경우가 있더라구요.
deepseek는 느슨하긴 했습니다.

답변달기

click 18시간전 [-]

결국 로컬 모델 쓰다가 deepseek v4 pro로 갔다는 결론이 되었네요
작업할 때마다 매번 모델 바꿔가면서 쓰는것도 쉽지 않아서 단순 작업에는 로컬을 쓴다는 방침도 힘들더라고요

하지만 너무 부족한 능력..

smallcode라는 소형 로컬 모델 특화 하네스도 있던데, 사용해보신 분 계신가요?
컨텍스트 길이도 최대한 작게 가져가거나, tool call 형식 오류도 적당히 잡아주는게 인상적이더라고요.