Ollama로 뭘 할 수 있고 뭘 못 하는가
회사에서 개발하던 한 프로젝트의 기능 중, OpenAI API를 호출해 결과를 받아 오는 작업이 서버장애로 먹통이 된 적이 있다. 이를 계기로 OpenAI 쪽 장애가 나면 사내 서버에 띄워둔 Ollama로 자동 전환되도록 fallback을 걸어 두려는 시도를 한 적이 있다. OpenAI 호환 엔드포인트 덕에 base_url만 바꾸면 코드가 그대로 동작하니, ‘API 모양이 같으면 결과도 어느 정도 비슷하지 않을까’ 정도의 막연한 기대로 짜둔 구성이었다. 하지만 테스트를 해보니 문제가 많았다. 답변 품질이 눈에 띄게 떨어졌고 응답 속도도 사용자가 체감할 만큼 느려져, ‘fallback이 있긴 하지만 fallback 상태로는 정상 운영이 어렵다’는 결론에 도달했다.
이 경험을 계기로, Ollama가 잘 하는 일과 못 하는 일을 한 번 정리해 두는 편이 낫겠다는 생각이 들었다. 같은 OpenAI 호환 인터페이스를 노출한다고 해서 같은 자리에 그대로 끼워 넣을 수 있는 도구는 아니고, 잘 되는 영역과 굳이 Ollama를 고를 이유가 없는 영역이 모델 크기, 동시성, 사용 목적에 따라 꽤 분명하게 갈린다. 이 글에서는 2025년 12월 시점을 기준으로 Ollama가 어디까지 쓸 만하고 어디부터는 다른 선택지로 넘어가야 하는지를 정리한다.
Ollama가 자리한 위치
Ollama는 llama.cpp 추론 엔진 위에 패키지 매니저, 모델 레지스트리, HTTP 서버, GUI를 덧씌운 형태다. 사용자가 보는 UX는 Docker와 비슷하다. ollama pull, ollama run, ollama list 같은 서브커맨드로 모델을 가져오고 실행하며, Modelfile로 시스템 프롬프트와 파라미터를 박아 커스텀 모델을 만들 수도 있다. 백그라운드에서는 11434 포트의 HTTP 서버가 떠 있고, 자체 /api/chat 엔드포인트와 함께 /v1/chat/completions OpenAI 호환 엔드포인트를 같이 노출한다. 클라이언트 라이브러리를 새로 만들 필요 없이, OpenAI 파이썬 SDK의 base_url만 바꿔 끼우면 그대로 동작한다는 점이 도입 비용을 크게 떨어뜨렸다.
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
model="qwen3:8b",
messages=[{"role": "user", "content": "한 문장으로 자기 소개"}],
)
2025년 7월 macOS와 Windows용 데스크톱 앱이 정식으로 추가되면서, 터미널을 거치지 않고도 모델을 골라 채팅 창을 띄울 수 있게 되었다. 같은 해 하반기에는 ‘Turbo’라는 이름의 클라우드 백엔드가 도입되어, 로컬에서 돌리기 버거운 대형 모델(예: gpt-oss-120B)은 Ollama 계정과 연결된 클라우드 GPU 위에서 실행하고 결과만 받아오는 옵션도 생겼다. 즉 Ollama는 로컬 전용이라는 초기 정체성을 어느 정도 벗어나, 같은 인터페이스 안에서 로컬과 원격을 섞어 쓸 수 있는 도구로 확장되는 중이다.
Ollama로 잘 되는 일
가장 잘 되는 일은 단일 사용자 데스크톱 추론이다. 노트북이나 워크스테이션 한 대에서 모델 한두 개를 띄워 놓고 본인이 직접 묻고 답을 받는 시나리오에서, Ollama는 설치, 모델 관리, 종료까지를 가장 적은 마찰로 처리한다. M-시리즈 맥북은 통합 메모리 덕에 7~14B 모델을 무리 없이 굴리고, 24GB VRAM의 RTX 4090 같은 데스크톱 GPU라면 30B급 모델까지 4비트 양자화로 올릴 수 있다.
두 번째는 프라이버시 또는 오프라인 제약이 강한 작업이다. 사내 코드, 환자 기록, 미공개 문서처럼 외부 API에 보내기 곤란한 입력이 있는 작업이라면, 로컬 추론 자체가 요구사항이 된다. 이 경우 Ollama의 OpenAI 호환 API는 기존에 OpenAI/Anthropic API로 짠 코드를 거의 그대로 재사용하게 해 준다. RAG 인덱싱 단계에서 쓰는 임베딩도 nomic-embed-text 또는 mxbai-embed-large를 같은 서버에서 같이 띄워두면 한 프로세스로 검색과 답변을 모두 처리할 수 있다.
세 번째는 프로토타이핑이다. 새로운 아이디어를 검증할 때, 매번 토큰 비용을 신경 쓰며 호출하는 것보다는 로컬에서 8B급 모델로 워크플로의 골격을 먼저 잡고, 품질이 부족한 부분만 클라우드 API로 옮기는 진행이 효율이 좋다. 도구 호출 지원이 있는 모델(Llama 3.1 이후 계열, Qwen 3, gpt-oss 등)이라면 에이전트 루프의 형태도 그대로 검증해 볼 수 있다.
네 번째는 멀티모달의 가벼운 활용이다. Llama 3.2-Vision, Qwen2-VL, LLaVA 같은 비전 모델이 Ollama 카탈로그에 들어와 있어서, 스크린샷을 입력으로 넣어 화면 요약을 받거나 OCR 보조용으로 쓰는 작업은 데스크톱에서 충분히 돌아간다. 영상이 아닌 정지 이미지 단위라면 응답 지연도 받아들일 만한 수준이다.
마지막은 커스텀 모델의 배포 단순화다. 파인튜닝이나 LoRA로 만든 어댑터를 GGUF로 변환한 뒤 Modelfile로 묶어 두면, 팀 동료에게 모델 카드 한 줄과 ollama pull 명령으로 배포가 끝난다. 시스템 프롬프트, temperature, top_p 같은 운영 파라미터도 같이 박을 수 있어서 ‘같은 모델인데 사람마다 결과가 다르다’는 종류의 혼선을 줄여 준다.
FROM qwen3:8b
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
SYSTEM """
너는 사내 코드베이스 컨벤션을 따르는 코드 리뷰어다.
모든 응답은 한국어로, 변경 제안은 diff 형태로 작성한다.
"""
Ollama로 안 되거나 어려운 일
먼저 품질의 절대치다. 2025년 12월 기준 데스크톱에서 굴릴 수 있는 30B급 이하 모델의 종합적인 추론 능력은 Claude Sonnet 4.5, GPT-5, Gemini 3 Pro 같은 프런티어 모델과 격차가 여전히 크다. gpt-oss-120B나 DeepSeek-R1-Distill-70B처럼 좀 더 큰 모델이 일부 벤치마크에서 클라우드 모델과 비슷한 점수를 내는 사례도 나왔지만, 이들은 단일 GPU 한 장으로는 실행이 어려워 데스크톱에서의 ‘Ollama 경험’과는 다른 이야기가 된다. 코드 작성, 도구 호출, 긴 추론 체인이 결합된 에이전트형 작업에서 격차는 더 두드러진다.
두 번째는 긴 컨텍스트다. 카드 상의 컨텍스트 길이가 128K로 적혀 있어도, 실제로 그만큼 띄우려면 KV 캐시가 VRAM을 빠르게 잡아먹는다. 7B 모델의 32K 컨텍스트를 4비트 양자화로 올리는 것까지는 24GB VRAM에서 무리가 없지만, 같은 모델로 128K를 켜는 순간 모델 가중치보다 KV 캐시가 더 큰 자리를 차지하게 된다. 길이가 늘어날수록 prefill 시간도 비례해서 늘어나고, 결과적으로 첫 토큰까지의 지연이 클라우드 API 대비 크게 벌어진다. 32K 이상 컨텍스트가 일상이 되는 워크로드라면 Ollama는 최선의 도구가 아니다.
세 번째는 동시성이다. Ollama의 서버는 기본적으로 한 모델당 한 번에 하나의 요청을 처리하도록 설계되어 있다. 큐가 있긴 하지만 vLLM이나 SGLang이 제공하는 continuous batching, paged attention, speculative decoding 같은 처리량 최적화가 들어가 있지 않다. 동시 사용자 수십 명에게 같은 모델을 서빙해야 하는 사내 챗봇 같은 환경이라면 처리량이 빠르게 한계에 부딪힌다. 이 자리는 Ollama 대신 vLLM 또는 SGLang의 영역이다.
네 번째는 멀티 GPU 활용이다. Ollama도 여러 GPU에 모델을 분산 적재할 수는 있지만, 텐서 병렬화의 효율이나 NVLink 최적화 같은 면에서는 vLLM 쪽이 한참 앞서 있다. A100 또는 H100 여러 장을 묶어서 70B 이상 모델을 풀 정밀도로 서빙하려는 시나리오에서 Ollama는 적합한 도구가 아니다.
다섯 번째는 학습이다. Ollama는 추론 전용 런타임이고, 파인튜닝이나 RLHF, GRPO 같은 학습 절차는 다루지 않는다. LoRA 어댑터를 import해서 추론에 합치는 것까지는 가능하지만, 학습 자체는 Axolotl, Unsloth, HuggingFace trl 같은 별도 스택에서 진행한 뒤 결과물을 GGUF로 변환해 가져오는 흐름이 된다.
여섯 번째는 가장 큰 모델이다. Llama 4 Maverick의 400B 파라미터 클래스, DeepSeek-V3 계열의 600B+ MoE 모델 같은 것은 가정용 하드웨어에서 4비트 양자화로 적재하더라도 수백 GB의 VRAM 또는 통합 메모리가 필요하다. 이 영역은 Ollama Turbo 같은 클라우드 백엔드를 통해서 다루는 것이 사실상 유일한 선택이고, 그 시점에서 ‘Ollama로 로컬 추론’이라는 본래의 매력은 거의 사라진다. 다른 클라우드 추론 서비스 대비 가격 경쟁력이 있느냐의 문제로 넘어간다.
마지막으로, 신모델 지원의 시간차다. 새로운 오픈 모델이 공개되면 보통 며칠에서 길게는 몇 주에 걸쳐 GGUF 변환과 템플릿 정합 작업이 진행된다. 그 사이에는 Hugging Face Transformers나 vLLM 쪽이 먼저 동작하는 경우가 많다. 출시 직후 며칠 안에 모델을 검증해야 하는 입장이라면 Ollama만 보고 기다리는 것은 답이 아니다.
모델 선택 기준
2025년 12월 시점에서 Ollama 카탈로그 안의 선택지는 작년보다 훨씬 두꺼워졌다. 일반적인 한국어, 영어 대화와 가벼운 코드 작업에는 Qwen3-8B 또는 Llama 3.3-8B가 무난하다. 추론을 명시적으로 요구하는 문제에는 DeepSeek-R1 distill 계열 또는 Qwen3-30B-A3B의 thinking 모드가 효과를 본다. 코드 보조 용도라면 Qwen2.5-Coder-7B/14B가 여전히 가성비가 좋다.
하드웨어 한도가 좀 더 여유 있는 워크스테이션에서는 gpt-oss-20B가 합리적인 후보다. OpenAI가 2025년 8월에 공개한 가중치로, 도구 호출과 함수 시그니처 준수가 비교적 안정적이라는 평가가 많다. 더 무거운 gpt-oss-120B는 단일 24GB GPU로는 빡빡하고, 통합 메모리가 큰 맥 스튜디오 또는 다중 GPU 환경에서야 데스크톱 추론으로 의미가 있다.
비전 입력이 필요하다면 Llama 3.2-Vision-11B 또는 Qwen2-VL-7B 정도가 출발점으로 무난하다. 임베딩은 한국어를 섞는 검색이라면 mxbai-embed-large가 nomic-embed-text보다 결과가 안정적이라는 후기가 많은 편이다.
선택의 기준은 결국 하드웨어와 작업의 결합이다. VRAM 용량이 모델 크기를 결정하고, 작업의 성격(대화/코드/추론/비전)이 모델 계열을 결정하며, 동시성과 컨텍스트 요구가 ‘Ollama로 끝낼 수 있는가, 아니면 vLLM 또는 클라우드 API로 가야 하는가’를 결정한다.
정리
Ollama가 잘 어울리는 자리는 명확하다. 한 사람이 자기 머신에서 7~30B급 모델을 가지고 프라이빗하게 작업하거나, 팀 안에서 가벼운 사내 도구를 빠르게 시제품 형태로 띄우거나, 새로운 오픈 모델을 손쉽게 비교 평가하고 싶을 때다. 이 자리에서 Ollama는 압도적으로 편하다.
반대로 Ollama로 무리하게 끌고 가지 않는 편이 좋은 자리도 있다. 프런티어 품질의 답변이 필요한 사용자 대면 서비스, 32K 이상의 긴 컨텍스트를 일상적으로 다루는 워크로드, 동시 사용자 처리량이 중요한 서빙, 그리고 본격적인 학습 파이프라인이다. 이쪽은 클라우드 API와 vLLM/SGLang이 더 적합한 도구다.
요약하자면 ‘Ollama로 다 된다’와 ‘Ollama로는 진지한 일을 못 한다’는 양극단의 인식 모두 현실과 어긋나 있다. Ollama는 로컬 단일 사용자 추론이라는 한정된 자리에서 가장 좋은 도구이고, 그 경계 바깥에서는 망설이지 말고 다른 도구로 넘어가는 것이 비용과 결과 모두에서 합리적이다.