로컬 LLM 도구 선택 가이드: Ollama, LM Studio, vLLM까지 언제 쓰나

로컬 LLM을 돌리려는 순간 가장 먼저 막히는 건 설치 명령이 아니라 도구 선택입니다. Ollama로 충분한 일에 vLLM을 붙이면 복잡도만 늘고, LM Studio로 모델을 고르면 쉬운 일을 llama.cpp부터 만지면 시간을 씁니다. 이 글은 노트북, 맥, GPU 서버에서 어떤 도구를 골라야 하는지 실전 기준으로 정리합니다.

요즘은 Qwen, Kimi, GLM 계열처럼 직접 내려받아 테스트할 만한 오픈 모델이 많아졌습니다. 그래서 모든 대화와 파일을 hosted API로 보낼 필요가 없는 상황도 늘었습니다. 다만 "로컬에서 돈다"는 말 하나로 끝나지 않습니다. 채팅용인지, 개발 API용인지, 운영 서빙용인지, Apple Silicon 최적화가 필요한지에 따라 출발점이 달라집니다.

 

 

로컬 LLM 모델 파일이 노트북 채팅, 코드 기반 로컬 API, GPU 서버, 맥 워크스테이션으로 나뉘는 작업 환경 이미지

 

먼저 결론: 처음이면 Ollama 또는 LM Studio부터 고르세요

개발자라면 보통 Ollama가 빠릅니다. 모델 다운로드, 실행, 로컬 서버 구성을 한 번에 처리하고, OpenAI 호환 API로 기존 코드의 base_url만 바꿔 붙일 수 있습니다.

터미널보다 GUI에서 모델을 보고 싶다면 LM Studio가 낫습니다. 모델 검색, 다운로드, 양자화 선택, 로컬 서버 실행까지 화면에서 확인할 수 있어 "이 모델이 내 컴퓨터에서 돌까?"라는 불안을 줄여줍니다.

한눈에 나누면 이렇습니다.

 

상황	먼저 볼 도구	피해야 할 착각
코딩하면서 빠르게 로컬 API를 붙이고 싶다	Ollama	운영 서빙까지 그대로 해결된다고 생각하기
모델을 GUI에서 고르고 비교하고 싶다	LM Studio	UI가 편하다고 배포 도구로 쓰기
가장 얇은 런타임, 특이한 하드웨어, 직접 제어가 필요하다	llama.cpp	처음부터 모든 옵션을 직접 만지기
여러 사용자 요청을 GPU 서버에서 처리해야 한다	vLLM	개인 실험에 먼저 붙이기
RAG, 멀티턴처럼 반복되는 긴 프롬프트가 많다	SGLang	단순 채팅 성능만 보고 선택하기
M 시리즈 맥에서 최대한 효율적으로 돌리고 싶다	MLX-LM	맥이면 무조건 큰 모델이 빠를 거라 믿기

 

이미 Ollama 기반 로컬 모델 구축 흐름을 따라가고 있다면 Ollama와 OpenClaw로 로컬 LLM 구축하는 방법을 함께 보면 좋습니다. 이 글은 설치 절차보다 "무엇을 선택해야 하는가"에 초점을 둡니다.

 

 

 

로컬 LLM에서 먼저 봐야 할 것은 모델명이 아니라 실행 형태입니다

처음에는 대부분 모델 이름부터 봅니다. Qwen 몇 B, Gemma 몇 B, GLM 몇 B 같은 식입니다. 하지만 실제로 오래 걸리는 문제는 모델명이 아니라 실행 형태입니다.

내가 필요한 것이 채팅 화면이면 GUI가 중요합니다. 코드에서 호출해야 한다면 API 호환성이 중요합니다. 여러 사람이 동시에 쓰는 서비스라면 처리량, 배치, 모니터링, GPU 메모리 관리가 먼저입니다. 같은 모델이라도 이 기준이 달라지면 선택 도구가 달라집니다.

역할별로 보면 도구는 다섯 갈래로 나뉩니다.

• 바닥 런타임: llama.cpp
• 개발자 편의 래퍼: Ollama
• GUI 실험 도구: LM Studio
• 운영 서빙 엔진: vLLM, SGLang
• Apple Silicon 특화 실행: MLX-LM

 

이렇게 보면 도구가 서로 완전히 경쟁하는 관계가 아니라는 점이 보입니다. Ollama와 LM Studio는 많은 부분에서 llama.cpp 생태계와 맞물려 편의성을 얹습니다. vLLM과 SGLang은 "더 좋은 채팅 앱"이 아니라 서버에서 많은 요청을 처리하기 위한 층에 가깝습니다.

 

 

로컬 LLM 모델 파일에서 런타임, 개발 API, GUI, GPU 서빙, Apple Silicon 실행 경로가 역할별로 나뉘는 구조도

 

 

llama.cpp: 가장 얇게, 가장 깊게 들어가는 바닥 도구

llama.cpp는 C/C++ 기반 LLM 추론 런타임입니다. CPU, GPU, Apple Silicon, 여러 백엔드에서 모델을 돌리는 바닥 기술에 가깝습니다. 직접 빌드하고 옵션을 조절할 수 있어 가볍고 유연하지만, 그만큼 사용자가 알아야 할 것도 많습니다.

여기서 자주 나오는 형식이 GGUF입니다. GGUF는 단순히 "모델 파일 확장자"가 아닙니다. 모델 텐서와 메타데이터를 함께 담고, 여러 양자화 타입을 지원하는 로컬 추론용 파일 형식입니다. Hugging Face에서 Q4_K_M, Q5_K_M, Q8_0 같은 이름이 붙은 파일을 봤다면 대부분 이 맥락입니다.

실전에서 중요한 점은 "4bit라서 무조건 좋다"가 아니라는 것입니다. 4bit는 모델을 작게 만들어 메모리 부담을 줄이지만, 품질과 속도는 모델 구조, 컨텍스트 길이, GPU offload 정도에 따라 달라집니다. 노트북에서 30B 모델을 억지로 올리는 것보다 7B나 14B 모델의 좋은 양자화 버전을 빠르게 쓰는 편이 나을 때가 많습니다.

llama.cpp를 고를 때는 이런 경우입니다.

• GUI나 서버 편의 기능보다 가벼운 실행 파일이 필요하다.
• CPU 위주, 오래된 장비, edge device처럼 제약이 큰 환경이다.
• 모델 로딩, GPU offload, 컨텍스트, 양자화 옵션을 직접 만져야 한다.
• 다른 도구가 감춰둔 실행 옵션을 정확히 확인하고 싶다.

 

처음부터 llama.cpp로 모든 것을 해결하려고 하면 설치보다 모델 선택에서 더 피곤해질 수 있습니다. 하지만 로컬 LLM을 오래 만질수록 결국 한 번은 내려가 보게 되는 층입니다.

 

 

 

Ollama: 개발자가 가장 빨리 로컬 API를 붙이는 길

Ollama의 장점은 "모델을 실행했다"에서 끝나지 않는다는 점입니다. 모델을 내려받고, 로컬 서버를 띄우고, 채팅 또는 API 호출로 바로 이어지게 해줍니다. 개발자가 빠르게 프로토타입을 만들 때 이 차이가 큽니다.

예를 들어 기존 OpenAI 클라이언트를 쓰던 코드가 있다면 로컬 서버 주소만 바꾸는 식으로 시작할 수 있습니다.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1/",
    api_key="ollama",
)

 

이 구조는 RAG, 내부 문서 요약, 간단한 에이전트 실험을 빠르게 붙일 때 편합니다. 로컬 모델에 MCP나 외부 작업 도구를 붙이는 흐름이 궁금하다면 Ollama, MCP, Zapier로 로컬 LLM 에이전트 구축하기와도 이어집니다.

다만 Ollama는 편의성을 위해 많은 선택을 감춥니다. 이것이 장점이면서 한계입니다. 모델별 세부 로딩 옵션, 벤치마크 조건, GPU 메모리 사용량을 세밀하게 통제해야 하는 단계라면 llama.cpp나 운영 서빙 엔진 쪽을 따로 봐야 합니다.

Ollama를 고르면 맞는 경우는 명확합니다.

• 코드에서 로컬 LLM을 빠르게 호출하고 싶다.
• OpenAI 호환 클라이언트를 그대로 활용하고 싶다.
• 모델 설치와 실행 과정을 오래 붙잡고 싶지 않다.
• 개인 개발, 내부 데모, 작은 자동화부터 시작한다.

 

반대로 "여러 팀원이 동시에 쓰는 사내 챗봇"을 바로 운영하려는 목적이라면 Ollama만 보고 끝내면 부족합니다. 그때부터는 동시성, 큐, 로그, 장애 대응, GPU 사용률을 봐야 합니다.

 

 

 

LM Studio: 모델을 고르고 비교하는 단계에서 시간을 아껴줍니다

LM Studio는 로컬 LLM을 GUI로 다루고 싶은 사람에게 맞습니다. 모델을 검색하고, 양자화 버전을 고르고, 다운로드한 뒤 바로 채팅할 수 있습니다. 터미널 명령보다 "내 하드웨어에서 이 모델이 현실적인가"를 눈으로 보고 판단하기 쉽습니다.

초보자가 자주 겪는 실패는 모델을 무작정 내려받은 뒤 실행이 안 되는 것입니다. 모델은 받았는데 메모리가 부족하거나, 속도가 너무 느리거나, GPU offload 설정을 몰라서 CPU로만 버티는 일이 생깁니다. LM Studio는 이런 판단을 GUI에서 하게 해주기 때문에 첫 모델 비교 단계에서 덜 피곤합니다.

또 LM Studio도 OpenAI 호환 엔드포인트를 제공합니다. 그래서 GUI로 모델을 고른 뒤 로컬 서버로 띄워 코드에서 호출하는 흐름도 가능합니다. 다만 이 장점을 운영 배포와 혼동하면 안 됩니다. LM Studio는 모델 탐색과 개인 실험에 강한 도구이지, 많은 사용자의 요청을 안정적으로 받는 서버 엔진으로 먼저 떠올릴 도구는 아닙니다.

LM Studio를 고르면 맞는 경우입니다.

• 터미널보다 데스크톱 앱에서 시작하고 싶다.
• 여러 모델과 양자화 버전을 빠르게 비교하고 싶다.
• 가족, 동료, 비개발자에게 로컬 LLM을 보여줘야 한다.
• "이 모델이 내 장비에서 돌아가는지"부터 확인하고 싶다.

 

 

 

vLLM과 SGLang: 로컬 실험이 아니라 운영 서빙의 문제입니다

vLLM과 SGLang은 개인 노트북에서 "한 번 채팅해보기"보다 운영 서빙에 가깝습니다. 여러 사용자의 요청을 GPU 서버에서 동시에 처리하거나, 내부 챗봇, 코딩 보조 도구, 대량 배치 작업을 운영해야 할 때 보는 층입니다.

vLLM은 높은 처리량을 목표로 하는 LLM inference/serving 라이브러리입니다. 여기서 자주 나오는 말이 PagedAttention과 continuous batching입니다. 쉽게 말해 GPU 메모리를 더 효율적으로 쓰고, 한 배치가 모두 끝날 때까지 기다리지 않고 새 요청을 끼워 넣어 처리량을 높이는 방향입니다.

이 차이는 혼자 채팅할 때는 잘 보이지 않습니다. 하지만 동시에 여러 사용자가 긴 답변을 요청하면 바로 드러납니다. GPU는 비싼 자원이고, 요청마다 길이도 다릅니다. 짧은 요청이 긴 요청 뒤에서 기다리면 체감 지연이 커집니다. 운영 서빙에서는 평균 속도보다 요청 길이 편차, 동시성, GPU 메모리 파편화, 배치 전략이 더 큰 문제가 됩니다.

SGLang은 저지연, 고처리량 추론을 위한 프레임워크이며 RadixAttention, prefix caching, multi-GPU parallelism을 전면에 둡니다. 특히 RAG나 멀티턴 대화처럼 많은 요청이 긴 시스템 프롬프트나 문서 prefix를 공유할 때 의미가 있습니다. 같은 앞부분을 계속 계산하지 않도록 캐시하는 구조가 중요해지기 때문입니다.

둘 중 무엇을 먼저 보느냐는 질문은 "내 워크로드가 무엇을 반복하는가"로 바꾸는 편이 낫습니다.

• 일반적인 OpenAI 호환 서버, 배치 처리, 높은 처리량이 우선이면 vLLM부터 본다.
• 긴 prefix를 공유하는 RAG, 멀티턴, 에이전트형 요청이 많으면 SGLang도 함께 비교한다.
• 단일 사용자 실험이면 둘 다 나중에 봐도 된다.

 

여기서 많이 하는 실수는 운영 엔진을 "성능 좋은 로컬 앱"처럼 이해하는 것입니다. vLLM과 SGLang을 붙이면 Docker, CUDA/ROCm, 모델 병렬화, GPU 메모리, 로그, 모니터링, 배포 자동화가 함께 따라옵니다. 로컬 LLM을 처음 만지는 사람에게는 모델보다 운영 환경이 먼저 터질 수 있습니다.

 

 

 

MLX-LM: M 시리즈 맥이라면 별도 선택지가 생깁니다

M 시리즈 맥을 쓴다면 MLX-LM을 따로 볼 만합니다. MLX-LM은 Apple의 MLX 기반으로 Apple Silicon에서 LLM을 실행하고 변환, 양자화, fine-tuning 흐름까지 다룰 수 있는 패키지입니다.

이 선택지가 의미 있는 이유는 단순히 "맥용이라서"가 아닙니다. MLX 문서가 설명하듯 Apple Silicon은 CPU와 GPU가 같은 unified memory pool에 접근합니다. 일반 PC에서는 GPU VRAM이 병목이 되기 쉽지만, M 시리즈 맥에서는 시스템 메모리 구조를 다르게 활용할 수 있습니다.

그래서 메모리가 큰 Mac Studio나 MacBook Pro에서는 PC의 작은 VRAM으로는 답답했던 모델을 다뤄볼 여지가 생깁니다. 물론 이것도 마법은 아닙니다. 메모리에 올라간다고 항상 빠른 것은 아니고, 모델 크기와 컨텍스트 길이가 커질수록 속도는 여전히 현실적인 한계에 부딪힙니다.

MLX-LM은 이런 경우에 맞습니다.

• Apple Silicon Mac에서 주로 작업한다.
• 맥의 unified memory 장점을 활용하고 싶다.
• Python API나 CLI로 모델 실행, 변환, 양자화를 다뤄보고 싶다.
• macOS 환경에서 로컬 LLM 실험을 오래 할 계획이다.

 

Windows나 Linux GPU 서버를 운영할 계획이라면 MLX-LM은 중심 선택지가 아닙니다. 반대로 맥 한 대에서 개인 연구, 문서 요약, 코드 보조, 작은 모델 실험을 할 거라면 Ollama, LM Studio와 함께 비교할 만합니다.

 

 

 

로컬이라고 무조건 안전한 것은 아닙니다

로컬 LLM의 큰 장점은 프롬프트와 파일을 외부 모델 API로 보내지 않도록 구성할 수 있다는 점입니다. 민감한 문서, 내부 코드, 개인 기록을 다룰 때 이 장점은 큽니다.

하지만 로컬 추론과 로컬 네트워크 공개는 다른 문제입니다.

모델이 내 컴퓨터에서 돈다는 것과 회사 네트워크에서 누구나 호출할 수 있다는 것은 완전히 다른 상태입니다.

 

다음 항목은 꼭 확인해야 합니다.

• 로컬 서버가 localhost에만 묶여 있는가, 네트워크에 열려 있는가
• 에이전트나 플러그인이 외부 API를 호출하지 않는가
• 로그, 히스토리, 캐시가 어디에 저장되는가
• 다운로드한 모델의 라이선스가 내가 하려는 사용을 허용하는가
• 사내 배포라면 인증, 권한, 감사 로그가 있는가

 

특히 Ollama나 LM Studio의 로컬 서버를 다른 장비에서 접근 가능하게 열 때는 방화벽과 인증을 반드시 봐야 합니다.

 

 

 

실제로 비교할 때는 같은 프롬프트로 좁혀가세요

처음부터 "가장 좋은 도구"를 찾으려 하지 말고, 같은 모델과 같은 프롬프트로 좁혀가는 편이 빠릅니다.

1. LM Studio로 모델 후보를 고른다. 내 장비에서 실행 가능한 크기와 양자화 버전을 먼저 확인합니다.
2. Ollama로 코드 호출을 붙인다. 기존 OpenAI 클라이언트 코드가 있다면 로컬 서버로 바꿔 실제 흐름을 확인합니다.
3. 답변 품질과 속도를 같이 본다. 체감 속도, 첫 토큰 지연, 초당 토큰 수, 메모리 사용량, 컨텍스트 길이를 기록합니다.
4. 옵션이 부족하면 llama.cpp로 내려간다. GPU offload, batch, context, quantization을 직접 조정합니다.
5. 동시 사용자가 생기면 vLLM/SGLang으로 넘어간다. 그전까지는 운영 엔진보다 모델과 프롬프트를 먼저 다듬는 편이 낫습니다.
6. M 시리즈 맥이면 MLX-LM을 별도 비교한다. 같은 모델이라도 실행 백엔드에 따라 체감이 달라질 수 있습니다.

 

이 순서의 장점은 실패 비용이 작다는 것입니다. 작은 모델 하나를 같은 프롬프트로 돌려보고, 속도와 답변 품질, 메모리 사용량을 확인하면 다음 도구를 고르는 기준이 훨씬 선명해집니다.

로컬 LLM은 도구 이름보다 "내 병목이 무엇인가"를 먼저 봐야 합니다. 병목이 설치라면 Ollama나 LM Studio가 풀어줍니다. 병목이 메모리와 옵션이라면 llama.cpp가 보입니다. 병목이 동시성과 처리량이라면 vLLM과 SGLang의 영역입니다. 병목이 맥의 하드웨어 활용이라면 MLX-LM을 따로 볼 이유가 생깁니다.

 

 

 

FAQ

 

Ollama와 LM Studio 중 하나만 먼저 고른다면 무엇이 좋나요?

개발자라면 Ollama부터 시작하는 편이 빠릅니다. 코드에서 바로 호출하기 쉽기 때문입니다. 터미널이 부담스럽고 모델을 눈으로 비교하고 싶다면 LM Studio가 더 편합니다.

 

로컬 LLM을 쓰면 개인정보가 완전히 안전한가요?

외부 모델 API로 프롬프트를 보내지 않도록 구성할 수 있다는 장점은 있습니다. 다만 로컬 서버 공개 범위, 플러그인/에이전트의 외부 호출, 로그 저장 위치, 모델 라이선스는 따로 확인해야 합니다.

 

 

 

마무리: 설치보다 먼저 용도를 정하세요

로컬 LLM 도구 선택은 어렵게 보이지만 기준은 단순합니다. 혼자 쓰고 비교하려면 LM Studio, 코드에 붙이려면 Ollama, 더 깊은 제어가 필요하면 llama.cpp, 운영 트래픽을 받으려면 vLLM이나 SGLang, M 시리즈 맥을 제대로 활용하려면 MLX-LM입니다.

처음부터 운영 엔진으로 뛰어들 필요는 없습니다. 먼저 작은 모델 하나를 같은 프롬프트로 돌려보고, 속도와 답변 품질, 메모리 사용량을 확인하세요. 그 결과가 다음 도구를 고르는 가장 확실한 기준이 됩니다.