서론: “친구라면 Ollama를 쓰게 두지 마라”

최근 Hacker News에 “Friends Don’t Let Friends Use Ollama”라는 글이 올라와 로컬 LLM 생태계에서 큰 반향을 일으켰다. 작성자 Zetaphor는 Ollama가 llama.cpp 위에 얹은 래퍼이면서 기반 프로젝트에 대한 귀속을 축소하고, 성능을 낭비하며, VC 기반 클라우드 전환으로 락인을 추진한다고 비판했다.

Ollama는 ollama run llama3 한 줄로 로컬 LLM을 시작할 수 있게 만든 공로가 있다. 하지만 2026년 현재 대안 도구들도 UX를 크게 개선했고, Ollama만의 장벽은 빠르게 사라지고 있다. 이 글은 Ollama의 실제 문제점을 검증하고, 시나리오별로 최적의 대안을 제안한다.

TL;DR
– Ollama는 llama.cpp 대비 10~30% 느림 (특정 조건에서 최대 1.8배)
– 2025년 중반 llama.cpp 포크에서 이탈했다는 보고 — 호환성 이슈 다수 제기
– 클라우드 전환 시 프롬프트 라우팅 투명성에 대한 커뮤니티 우려
– 대안: llama.cpp(최고 성능), vLLM(다중 사용자), LM Studio(GUI), llamafile(포터블)

Ollama의 5가지 문제

1. 귀속(Attribution) 논란

Ollama는 llama.cpp를 엔진으로 사용하면서 README에서 llama.cpp 언급을 1년 이상 누락했다. MIT 라이선스 고지 의무 불이행을 지적하는 GitHub 이슈(#3185)는 400일 이상 방치됐다. 오픈소스 생태계에서 이는 단순 실수가 아니라 신뢰 문제다.

2. 성능 오버헤드

동일 하드웨어에서 llama.cpp를 직접 실행하면 Ollama보다 빠르다는 보고가 다수 존재한다. 다만 수치는 벤치마크 조건에 따라 편차가 크다.

일반적인 사용에서는 10~30% 오버헤드가 현실적 범위이며, 특정 최적화 조건에서 최대 1.8배까지 벌어질 수 있다. 캐주얼 채팅에서는 체감되지 않으나, 배치 처리나 대형 모델에서는 유의미한 차이다.

3. 포크 퇴행 (2025년 중반, 원문 주장)

원문 저자 Zetaphor에 따르면, Ollama는 llama.cpp를 버리고 ggml 기반 자체 백엔드로 전환했다. 이 주장은 Ollama 공식 입장으로 확인되지 않았으나, HN 토론에서 복수의 사용자가 유사한 경험을 보고했다.

• 이미 수정된 버그가 재발했다는 보고
• 구조화 출력(structured output) 및 비전 모델 지원 호환성 이슈
• 최신 텐서 타입과의 비호환 사례
• llama.cpp 커뮤니티의 최적화 업스트림 반영 지연

4. 모델 네이밍 기만

Ollama 모델 라이브러리에서 “DeepSeek-R1″을 풀하면 실제로는 8B 증류 변형이 다운로드된다. 671B 원본과 혼동을 유발하는 네이밍이다. 초보자일수록 이 차이를 알 수 없다.

5. 벤더 락인과 보안

• 모델 파일이 해시 파일명으로 저장돼 다른 도구와 호환 불가
• 독점 모델 레지스트리 — HuggingFace GGUF와 직접 호환되지 않음
• 2025년 말 클라우드 전환 시 프롬프트 라우팅 투명성에 대한 커뮤니티 우려 제기
• 원문은 토큰 탈취 관련 보안 취약점을 언급했으나, 공식 CVE 데이터베이스에서 해당 번호의 존재 여부는 독자가 직접 확인할 것을 권장한다

대안 비교: 2026년 로컬 LLM 도구 7선

llama.cpp: 성능이 곧 정의

llama-server를 직접 실행하면 OpenAI 호환 API가 바로 뜬다.

# HuggingFace에서 직접 다운로드 + 서버 실행
llama-server -hf Qwen/Qwen3.5-35B-GGUF --port 8080

별도 모델 레지스트리 없이 HuggingFace 직접 연동, CUDA/Metal/Vulkan 자동 감지, 최신 텐서 타입 즉시 지원. Ollama가 래핑으로 가려놓은 것을 직접 건드리면 오히려 단순하다.

vLLM: 서버가 진짜 필요할 때

가족이나 소규모 팀이 같은 모델을 동시에 쓴다면 vLLM의 PagedAttention이 빛난다. RTX 5090에서 동시 접속 시 Ollama 대비 처리량 35배 차이를 보인다. 다만 개인 단독 사용이면 과잉이다.

하드웨어별 현실적 선택

Vitalik Buterin의 기준: 50 tok/s 미만은 비실용적. 대화형으로 쓰려면 최소 이 속도가 필요하다.

프라이버시: 로컬 LLM의 진짜 가치

Vitalik Buterin은 2026년 4월 글에서 이렇게 경고했다. “우리는 E2E 암호화가 주류가 되는 시점에, 전체 생활을 클라우드 AI에 먹이는 것을 정상화하며 열 걸음 후퇴하고 있다.”

로컬 LLM의 프라이버시 이점은 구체적이다.

• 데이터 주권: 프롬프트, RAG 문서, 추론 로그 전부 자체 디스크에 잔류
• 침해 위험 감소: 온프레미스 호스팅 조직의 데이터 침해 사고 75% 감소 (DeepSeek 사례 연구)
• 규제 준수: GDPR, HIPAA — 국경 간 데이터 전송 이슈 원천 차단

Ollama의 클라우드 전환은 이 가치를 훼손한다. 로컬 LLM을 쓰는 이유가 프라이버시라면, 실제로 로컬에 남는 도구를 선택해야 한다.

시나리오별 최종 권장

Ollama가 아직 괜찮은 경우

공정하게 말하면, Ollama가 여전히 합리적인 선택인 시나리오가 있다.

• 처음 로컬 LLM을 접하는 비개발자: ollama pull + ollama run의 UX는 아직 최고 수준이다
• 캐주얼 채팅: 성능 30% 차이가 체감되지 않는 가벼운 사용
• 빠른 모델 비교: 여러 모델을 한 줄씩 내려받아 즉시 전환

하지만 프로덕션, 프라이버시, 성능 중 하나라도 중요하다면 대안을 검토해야 할 시점이다.

참고 링크

• Friends Don’t Let Friends Use Ollama (sleepingrobots.com)
• Vitalik Buterin — My self-sovereign LLM setup (2026-04)
• llama.cpp vs Ollama vs vLLM 벤치마크
• Best Open Source LLM in 2026 (BenchLM)
• Local LLM Hardware Requirements 2026 (SitePoint)

다음 글 추천: 오픈소스가 위기인가? Cal.com의 클로즈드 전환과 “Open Source Isn’t Dead” 논쟁을 양면에서 해부한다.

관련 글

• Karpathy의 LLM Wiki 패턴 — RAG를 대체할 새로운 지식 관리 방법
• 2026 오픈소스 위기론: Cal.com 클로즈드 전환과 Strix 반박 해부
• GPT-5.4 사이버보안: High 등급 근거와 GPT-5.4-Cyber (2026)