코드 생성을 위한 로컬 LLM 실행: 2026년 Ollama vs LM Studio 비교

6개월 전만 해도 코드 생성을 위해 로컬 LLM (Large Language Model)을 실행한다는 것은 처리량(throughput)이 절반으로 줄어들고, 메모리 압박은 두 배로 늘어나며, 임포트(import)를 끊임없이 환각(hallucination)하는 모델을 감수해야 한다는 의미였습니다. 2026년 중반에 접어든 지금, 환경은 "그냥 로컬에서 돌려봐"라는 말이 더 이상 농담이 아닐 정도로 변화했습니다. 이제 이는 측정할 가치가 있는 실제적인 트레이드오프(tradeoffs)를 동반한 결정입니다.

우리는 M3 Max MacBook Pro (36GB 통합 메모리)와 RTX 4090이 탑재된 Linux 워크스테이션에 세 가지 주요 로컬 추론 스택인 Ollama, LM Studio, 그리고 순수 llama.cpp를 구축했습니다. 그런 다음 DeepSeek Coder V2 (33B Q4_K_M), Qwen 2.5 Coder (32B Q4_K_M), CodeLlama 34B (Q4_K_M)에 동일한 코딩 프롬프트 세트를 투입하여 추론 속도, 메모리 점유율(memory footprint), 그리고 HumanEval pass@1 점수를 측정했습니다. 또한 모든 개발자가 던지는 질문인 "로컬 모델이 정말로 충분히 좋아졌는가?"에 답하기 위해 각 모델을 클라우드 베이스라인(API를 통한 GPT-4o 및 Claude 3.5 Sonnet)과 비교했습니다.

하드웨어 현실: 2026년에 기대할 수 있는 것

로컬 LLM 추론은 메모리 대역폭(memory bandwidth) 싸움입니다. 모델 가중치(weights)는 RAM 또는 VRAM에 위치하며, 하드웨어는 이를 연산 유닛(compute units)을 통해 가능한 한 빠르게 이동시킵니다. 양자화(quantization), 프롬프트 길이, 컨텍스트 윈도우(context window)와 같은 다른 모든 변수는 이 병목 현상(bottleneck)에 비해 부차적입니다.

RTX 4090에서의 수치는 명확합니다. 4비트 양자화(4-bit quantization)를 적용한 DeepSeek Coder V2 33B는 코드 생성 중에 초당 68개 토큰(68 tokens per second)을 생성했습니다. 4,000개 토큰 프롬프트에 대한 컨텍스트 처리(context processing)는 0.4초 만에 완료되었으며, 총 VRAM 사용량은 21.4 GB였습니다. Qwen 2.5 Coder 32B는 이보다 약간 더 빨랐습니다. 생성 속도는 74 tok/s, 동일한 프롬프트 길이에 0.35초, VRAM은 20.8 GB를 사용했습니다. CodeLlama 34B는 62 tok/s의 속도와 22.1 GB의 사용량을 기록했습니다. 세 모델 모두 24 GB VRAM 예산 안에 깔끔하게 들어맞았으며, 제가 읽는 속도보다 더 빠르게 토큰을 생성했습니다.

Apple Silicon은 다른 이야기를 들려줍니다. M3 Max는 400 GB/s의 메모리 대역폭 (Memory Bandwidth)을 갖추고 있으며, 이는 4090이 제공하는 수치(1,008 GB/s)의 약 40% 수준입니다. 놀랍게도 이 비율은 생성 속도와 매우 직접적으로 연결됩니다. DeepSeek Coder V2는 M3 Max에서 26 tok/s로 실행되었습니다. Qwen 2.5 Coder는 29 tok/s를 기록했습니다. CodeLlama는 23 tok/s를 달성했습니다. 이 수치들은 전통적인 의미에서 "빠른" 것은 아니지만, 탭 완성 (Tab Completion)이 반응형으로 느껴지고 인라인 제안 (Inline Suggestions)이 인지할 수 없는 지연 없이 나타나는 임계값인 15 tok/s 보다는 높습니다. 컨텍스트 처리 (Context Processing)가 진정한 차별점이었습니다. 동일한 4K 토큰 프롬프트에 대해 4090에서는 0.4초가 걸린 반면, M3 Max에서는 1.8초가 걸렸습니다. 만약 여러 파일의 리팩토링 (Refactoring) 내용을 컨텍스트로 보낸다면, 그 격차는 더욱 커집니다.

모든 테스트에는 우리의 측정 결과에서 속도와 정확도 사이의 최적의 균형을 맞추는 Q4_K_M 양자화 (Quantization)를 사용했습니다. Q5_K_M으로 전환하면 정확도는 12% 향상되지만 속도는 약 10% 손실되었는데, 이는 좀처럼 그만한 가치가 없습니다. Q2_K로 낮추면 속도는 30% 더 빨라졌지만 정확도가 68% 감소했는데, 모든 괄호가 중요한 코드 작업에서 이는 너무 가혹한 대가입니다.

정확도: 2026년 중반 로컬 모델의 위치

코드가 컴파일 (Compile)되는지 여부가 원시 속도(Raw Speed)보다 더 중요합니다. 우리는 각 모델을 표준 HumanEval Python 벤치마크 (pass@1, temperature 0.2)와 우리 팀의 내부 백로그에서 추출한 50개의 실제 코딩 작업 세트(버그 수정, 독스트링(Docstring)으로부터 함수 작성, 모듈 리팩토링, SQL 쿼리 생성 등)를 통해 테스트했습니다.

HumanEval에서 Claude 3.5 Sonnet은 92.0%, GPT-4o는 90.2%를 기록했습니다. 로컬 모델 중에서는 DeepSeek Coder V2 33B가 83.5%를 기록하여 클라우드 선두주자들과 약 9점 정도의 차이를 보였으나, 많은 작업에서 차이를 느끼지 못할 만큼 충분히 강력했습니다. Qwen 2.5 Coder 32B는 80.1%를 기록했습니다. CodeLlama 34B는 71.3%로 뒤처졌는데, 이는 유용하게 사용할 수 있는 수준이지만 더 주의 깊은 검토가 필요한 정도의 수치입니다.

실제 업무 태스크 제품군(real-world task suite)에서도 순위는 유지되었으나 격차는 더 벌어졌습니다. 당사의 내부 태스크는 다단계 추론 (multi-step reasoning), 라이브러리 인지 (library awareness), 그리고 여러 파일에 걸친 일관성 (consistency across multiple files)을 요구합니다. 이는 단순한 코드 완성 데모와 엔지니어링 어시스턴트를 구분 짓는 종류의 작업입니다. Claude 3.5 Sonnet은 50개의 태스크 중 44개를 정확히 해결했습니다. GPT-4o는 42개를 해결했습니다. DeepSeek Coder V2는 37개를 해결했는데, 이는 특히 자신의 하드웨어에서 실행되는 모델로서는 확실히 유용한 수준이지만, 세 개 이상의 파일에 걸친 추론이 필요한 태스크에서는 한계에 부딪힐 것입니다. Qwen 2.5 Coder는 33개를, CodeLlama는 28개를 해결했습니다.

단일 함수 생성 (single-function generation) 및 인라인 완성 (inline completion)의 경우, DeepSeek Coder V2와 Qwen 2.5 Coder는 품질 면에서 클라우드 모델과 구별할 수 없을 정도입니다. 격차는 오직 다중 파일 리팩토링 (multi-file refactors) 및 비로컬 추론 (non-local reasoning)이 필요한 태스크에서만 나타납니다. 만약 귀하의 AI 보조 코딩 대부분이 함수 수준이라면, 로컬 모델이 충분히 제 역할을 할 것입니다. 하지만 AI에게 모듈 전체를 리팩토링하도록 정기적으로 요청한다면, 클라우드 API 키를 항상 준비해 두십시오.

Ollama, LM Studio, 그리고 llama.cpp는 동일한 양자화 (quantization) 및 동일한 샘플링 파라미터 (sampling parameters)를 사용하여 로드했을 때 동일한 품질 점수를 기록했습니다. 이들은 모두 내부적으로 llama.cpp를 사용하므로 당연한 결과입니다. 실행기 (runner)의 선택은 출력 품질이 아닌 워크플로 (workflow)의 문제입니다.

Ollama vs LM Studio vs llama.cpp: 워크플로 결정

출력 품질이 동일하다면, 질문은 다음과 같이 바뀝니다. 어떤 도구가 귀하가 실제로 코드를 작성하는 방식과 가장 잘 통합되는가?

Ollama는 API 호환성 측면에서 승리합니다. localhost:11434에서 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 노출하므로, OpenAI와 통신하는 모든 IDE 확장 프로그램 및 CLI 도구는 URL 한 줄만 변경하여 이를 가리킬 수 있습니다. continue.dev VS Code 확장 프로그램, Aider, 그리고 Cody CLI 모두 즉시 작동합니다. 또한 Ollama는 단일 명령(ollama pull deepseek-coder-v2:33b)으로 모델 다운로드를 처리하고, 동시 요청 (concurrent requests)을 깔끔하게 관리하며, 모델이 유휴 상태일 때는 CPU를 거의 사용하지 않습니다. 만약 클라우드 API처럼 백그라운드에서 상주하며 코딩 요청을 처리하는 데몬 (daemon)을 원한다면, Ollama가 가장 저항이 적은 경로입니다.

LM Studio는 GUI를 원하는 개발자들을 위한 선택입니다. OpenAI API 호환성을 갖춘 동일한 로컬 서버 엔드포인트(기본값 포트 1234)를 노출하지만, 데스크톱 앱을 통해 모델 브라우저, 원클릭 다운로드, 그리고 에디터에 연결하기 전에 프롬프트 (prompt)를 테스트할 수 있는 플레이그라운드 (playground)를 제공합니다. 코딩 워크플로를 위한 핵심 기능은 내장된 프롬프트 템플릿 에디터 (prompt template editor)입니다. 코딩 모델에 맞는 정확한 채팅 템플릿 (chat template)을 사용하는 것은 제대로 작동하는 코드와 엉망이 된 응답 사이의 차이를 만들 수 있는데, LM Studio는 GGUF 메타데이터를 직접 읽을 필요 없이 해당 설정을 보여줍니다. 또한 GPU 오프로딩 (GPU offloading) 슬라이더를 통해 VRAM이 제한된 머신에서 GPU와 CPU 간의 레이어 (layers) 분할을 매우 쉽게 할 수 있습니다.

llama.cpp는 두 도구 모두의 밑단에 있는 엔진입니다. 이를 직접 실행하면 --ctx-size, --threads, --n-gpu-layers, --batch-size와 같은 모든 추론 파라미터 (inference parameter)에 대해 완전한 제어권을 갖게 되지만, 모델과 프롬프트 템플릿을 직접 관리해야 하는 비용이 따릅니다. 당사의 테스트 결과, 동일한 하드웨어에서 llama.cpp 베어메탈 (bare-metal) 실행은 Ollama보다 3~5% 더 빨랐는데, 이는 HTTP 서버 오버헤드 (overhead)와 스케줄링 레이어 (scheduling layer)를 피하기 때문입니다. 배치 추론 (batch inference)을 실행하거나 작업당 수십 개의 모델 호출을 체이닝 (chaining)하는 커스텀 코딩 에이전트 (coding agent)를 구축하는 경우라면 이 차이가 중요합니다. 하지만 대부분의 개발자에게는 Ollama나 LM Studio의 편의성이 약간의 속도 저하를 감수할 만큼의 가치가 있습니다.

NVIDIA GPU를 보유하고 있다면, 벤치마킹을 수행하기 전에 추론 스택 (inference stack)에서 CUDA를 사용할 수 있는지 확인하십시오. Ollama는 기본적으로 GPU 지원이 활성화된 상태로 제공되지만, LM Studio는 오른쪽 사이드바에서 "GPU Offload"를 토글해야 합니다. llama.cpp는 LLAMA_CUDA=1 옵션과 함께 컴파일되어야 합니다. GPU 가속이 없다면, CPU 전용 추론 시 생성 속도는 5-8 tok/s로 떨어지며, 이는 자동 완성 (autocomplete) 이상의 용도로 사용하기에는 간신히 사용 가능한 수준입니다.

개인정보 보호, 오프라인 코딩, 그리고 실제적인 트레이드오프 (tradeoffs)

로컬 LLM에 대한 개인정보 보호 논거는 명확하지만 과장되기 쉽습니다. 코드를 클라우드 API로 전송하면 타인의 서버를 거치게 되며, 해당 코드가 학습 데이터 세트에 포함되는지 여부는 제공업체의 정책에 달려 있습니다. Anthropic의 상업적 약관은 API 입력값으로 학습하지 않는다고 명시적으로 밝히고 있습니다. OpenAI의 비즈니스 티어 API도 유사한 문구를 포함하고 있습니다. 덜 명확한 부분은 데이터가 로그에 얼마나 오래 보관되는지, 제공업체 내부의 누가 접근할 수 있는지, 그리고 귀하의 보안 팀이 귀하의 독점적인 코드베이스가 네트워크를 벗어나는 것에 대해 동의하는지 여부입니다.

로컬 모델은 그 질문을 제거합니다. 아무것도 기기를 떠나지 않습니다. 이는 규제 대상 데이터를 다루는 방위 산업체나 핀테크 기업에 중요하지만, 경쟁적인 분야에서 개발 중이며 귀하의 아키텍처가 실수로 다른 사람의 세션에서 완성된 코드를 생성하는 것을 원치 않는 경우에도 중요합니다.

더 실질적인 이점은 오프라인 코딩입니다. 비행기 안에서, 외부 출구가 제한된 데이터 센터에서, 또는 연결이 불안정한 시골 지역에서 작업할 때, 로컬 모델은 지연 시간 변동 없이 전체 속도로 실행됩니다. 우리는 DeepSeek Coder V2를 사용하여 4090에서 측정한 엔드 투 엔드 지연 시간(end-to-end latency, 프롬프트에서 첫 번째 토큰까지)이 180ms였던 반면, 50백분위수(50th-percentile) 연결 상태의 GPT-4o는 420ms였습니다. 200개 토큰 완성에 대한 전체 응답은 로컬에서 3.1초가 걸린 반면, API를 통해서는 4.8초가 걸렸습니다. 그 1.7초의 차이가 단일 쿼리에서는 혁명적이지 않을 수 있지만, 30~50개의 프롬프트를 보내는 코딩 세션 전체를 놓고 보면 실제 시간(wall-clock time) 기준으로 몇 분의 차이를 만들어냅니다.

트레이드오프 (Tradeoff)는 명확합니다. HumanEval 정확도 약 9점을 포기하는 대신 개인정보 보호, 오프라인 기능, 그리고 토큰당 비용 제로 (zero per-token cost)를 얻게 됩니다. 함수 수준의 코딩 (function-level coding)을 위해서는 이는 충분히 감수할 만한 거래입니다. 하지만 아키텍처 수준의 추론 (architecture-level reasoning)에 있어서는 클라우드 모델들이 여전히 유의미하게 앞서 있습니다.