# 로컬 LLM 생태계에는 Ollama가 필요하지 않다 > Clean Markdown view of GeekNews topic #28622. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28622](https://news.hada.io/topic?id=28622) - GeekNews Markdown: [https://news.hada.io/topic/28622.md](https://news.hada.io/topic/28622.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-17T09:39:13+09:00 - Updated: 2026-04-17T09:39:13+09:00 - Original source: [sleepingrobots.com](https://sleepingrobots.com/dreams/stop-using-ollama/) - Points: 7 - Comments: 1 ## Topic Body - **Ollama**는 로컬 LLM 실행을 단순화한 초기 도구였으나, 이후 **출처 은폐와 클라우드 중심 전환**으로 신뢰를 잃음 - 핵심 엔진인 **llama.cpp의 공로를 축소**하고, 자체 ggml 백엔드로 전환하면서 **성능 저하와 버그 재도입**이 발생 - **모델 명칭 오도**, **비공개 GUI 앱 배포**, **비효율적 Modelfile 구조** 등으로 커뮤니티의 비판이 이어짐 - **모델 레지스트리 병목**, **보안 취약점**, **벤더 락인 구조**가 로컬 우선 철학과 충돌 - **llama.cpp, LM Studio, Jan** 등 오픈소스 대안들이 이미 **더 높은 성능과 투명성**을 제공하며 로컬 LLM 생태계의 중심으로 자리함 --- ### Ollama의 문제점과 로컬 LLM 생태계의 대안 - ## Ollama의 기원과 초기 역할 - **Ollama**는 로컬 LLM 실행을 간소화한 첫 **llama.cpp 래퍼**로 주목받음 - 사용자가 C++을 직접 빌드하거나 서버 설정을 하지 않아도 모델을 실행 가능 - 이후 **출처를 숨기고**, **사용자를 오도하며**, **로컬 중심 철학에서 벗어나** 벤처 자본 기반의 클라우드 중심 구조로 이동 - 창업자는 Jeffrey Morgan과 Michael Chiang으로, 이전에 Docker GUI인 **Kitematic**을 개발해 Docker Inc.에 인수된 경력 보유 - Y Combinator(W21) 출신으로 2023년 공개 출시, “**Docker for LLMs**”를 표방 - ## llama.cpp에 대한 부적절한 크레딧 - Ollama의 추론 기능은 전적으로 **Georgi Gerganov의 llama.cpp**에 의존 - 1년 넘게 README, 웹사이트, 마케팅 자료 어디에도 llama.cpp 언급이 없었으며 **MIT 라이선스 고지조차 누락** - 커뮤니티의 라이선스 준수 요청 이슈(#3185)는 **400일 이상 응답 없음** - 이후 공동 창업자가 README 하단에 “llama.cpp project founded by Georgi Gerganov” 한 줄만 추가 - Ollama 측은 “우리가 많은 패치를 수행하고 있으며 점차 자체 엔진으로 전환할 것”이라며 **의도적으로 크레딧을 축소** ### 자체 백엔드 전환과 성능 저하 - ## ggml 기반 커스텀 백엔드 도입 - 2025년 중반, Ollama는 llama.cpp 대신 **ggml 기반 자체 구현체**로 전환 - 안정성을 이유로 내세웠으나, 결과적으로 **기존에 해결된 버그를 재도입** - 구조화 출력 오류, 비전 모델 실패, GGML assertion 충돌 등 다수 문제 발생 - **GPT-OSS 20B** 등 최신 모델이 작동하지 않거나 텐서 타입 미지원 문제 발생 - Gerganov는 Ollama가 **ggml을 잘못 포크했다**고 직접 지적 - ## 성능 비교 결과 - 커뮤니티 벤치마크에서 **llama.cpp가 Ollama보다 1.8배 빠름** (161 vs 89 tokens/s) - CPU에서도 30~50% 성능 차이 존재 - Qwen-3 Coder 32B 테스트에서는 **llama.cpp가 70% 높은 처리량** - 원인은 Ollama의 **데몬 구조, 비효율적 GPU 오프로딩, 구식 백엔드** ### 모델 명칭 오도 - ## DeepSeek-R1 사례 - Ollama는 **DeepSeek-R1-Distill-Qwen-32B** 등 축소 모델을 단순히 **“DeepSeek-R1”** 로 표기 - 실제 671B 파라미터 모델이 아님에도 동일 이름 사용 - 사용자들이 “DeepSeek-R1을 로컬에서 실행했다”고 오해하며 **DeepSeek의 평판에 손상** - 관련 GitHub 이슈(#8557, #8698)는 모두 중복 처리 후 미해결 상태 - 현재도 `ollama run deepseek-r1`은 축소 모델을 실행 ### 폐쇄형 앱 출시 - ## GUI 앱의 비공개 배포 - 2025년 7월, macOS·Windows용 **Ollama GUI 앱** 공개 - **비공개 저장소**에서 개발되어 라이선스 없이 배포, 소스 코드 비공개 - 오픈소스 이미지를 유지하던 프로젝트로서는 **급격한 폐쇄 전환** - 커뮤니티는 AGPL-3.0 의존성 가능성과 **라이선스 위반 우려** 제기 - 웹사이트는 GitHub 링크 옆에 다운로드 버튼을 배치해 **오픈소스인 듯한 인상 제공** - 수개월간 침묵 후 2025년 11월에야 메인 저장소로 병합 - XDA는 “**오픈소스를 표방하는 프로젝트는 공개 여부를 명확히 해야 한다**”고 비판 ### Modelfile의 비효율성 - ## GGUF 포맷과의 중복 - **GGUF 포맷**은 모델 실행에 필요한 모든 정보를 단일 파일에 포함 - Ollama는 여기에 **Modelfile**이라는 별도 설정 파일을 추가, Dockerfile과 유사한 구조 - 이미 GGUF에 포함된 정보를 중복 정의하며 **불필요한 복잡성** 초래 - Ollama는 **하드코딩된 템플릿 목록**만 자동 인식, 새로운 템플릿은 무시됨 - 결과적으로 모델의 **지시문 형식이 깨지고**, 사용자가 수동 변환해야 함 - ## 비효율적 파라미터 수정 - 파라미터 변경 시 `ollama show --modelfile`로 추출 후 수정, `ollama create`로 재생성 필요 - 이 과정에서 **30~60GB 모델 전체 복사** 발생 - 커뮤니티는 이를 “**비효율적이고 불필요한 복제**”라 비판 - llama.cpp는 단순히 **명령줄 인자**로 파라미터 조정 가능 - ## 템플릿 호환성 문제 - Ollama는 **Go 템플릿 문법**을 사용, 모델 제작자가 사용하는 **Jinja 템플릿**과 불일치 - LM Studio와 llama.cpp는 Jinja를 직접 지원하지만, Ollama는 변환 필요 - 변환 오류로 인한 **대화 형식 깨짐** 문제 다수 보고 ### 모델 레지스트리의 병목 - ## 모델 등록 지연 - 새로운 모델이 Hugging Face에 올라와도 Ollama는 **직접 패키징 후 등록**해야 사용 가능 - 지원하는 양자화 형식도 **Q4_K_M, Q8_0 등 제한적** - 결과적으로 **모델 출시 후 Ollama에서 사용까지 지연** 발생 - 커뮤니티에서는 “**새 모델 테스트는 llama.cpp나 vLLM을 사용하라**”는 PSA 게시물 확산 - ## 양자화 제약 - Ollama는 **Q5, Q6, IQ 계열** 미지원 - 사용자가 요청해도 “다른 도구를 사용하라”는 답변 - `ollama run hf.co/{repo}:{quant}` 명령으로 Hugging Face 직접 호출 가능해졌지만, 여전히 **내부 해시 저장소에 복사되고 공유 불가**, 템플릿 문제도 지속 ### 클라우드 전환과 보안 문제 - ## 클라우드 모델 도입 - 2025년 말, Ollama는 **클라우드 호스팅 모델**을 추가 - 로컬 중심 도구였음에도 일부 모델이 **외부 서버로 프롬프트를 전송** - MiniMax 등 **서드파티 모델** 사용 시 데이터가 외부로 전달될 수 있음 - Ollama는 “로그 저장 안 함”이라 명시했으나 **제3자 정책은 불명확** - Alibaba Cloud 기반 모델의 경우 **데이터 보존 보장 없음** - ## 보안 취약점 - **CVE-2025-51471**: 악성 레지스트리 서버가 인증 토큰을 탈취할 수 있는 취약점 - 수정 PR은 존재했으나 **수개월간 미반영** - 로컬 프라이버시를 핵심 가치로 내세운 도구로서는 **심각한 구조적 문제** ### 벤처 자본 중심의 구조 - ## 반복되는 패턴 - 오픈소스 프로젝트를 **래핑해 사용자 기반 확보 → 투자 유치 → 수익화 전환** - Ollama의 단계별 행보 - 오픈소스로 시작, llama.cpp 기반 구축 - 출처 축소, 독립적 제품처럼 포장 - **모델 레지스트리와 포맷으로 락인 유도** - **폐쇄형 GUI 출시** - **클라우드 서비스 도입**으로 수익화 - ## 벤더 락인 구조 - Ollama는 모델을 **해시된 파일명**으로 저장해 다른 도구와 호환 어려움 - GGUF를 가져올 수는 있지만 **내보내기는 불편하게 설계** - 사용자는 Ollama 생태계에 **묶이게 되는 구조** ### 대안 도구 - ## llama.cpp - **OpenAI 호환 API 서버(‘llama-server’)**, 웹 UI, 세밀한 파라미터 제어, 높은 처리량 제공 - 2026년 2월, **ggml.ai가 Hugging Face에 합류**하여 지속 가능성 확보 - MIT 라이선스 기반, 450명 이상 기여자 참여 - ## 기타 대안 - **llama-swap**: 다중 모델 로딩·핫스왑 지원 - **LiteLLM**: 여러 백엔드 간 OpenAI 호환 프록시 제공 - **LM Studio**: GUI 기반, llama.cpp 사용, GGUF 완전 호환 - **Jan**, **Msty**: 로컬 우선 설계의 오픈소스 데스크톱 앱 - **koboldcpp**, **Red Hat ramalama**: 컨테이너 기반 모델 실행, **명확한 출처 표기** ### 결론: 로컬 LLM 생태계의 방향 - **Georgi Gerganov의 llama.cpp**는 로컬 AI 혁신의 기반 - 커뮤니티 협업으로 소비자 하드웨어에서도 강력한 모델 실행 가능 - Ollama는 이 기반 위에서 성장했으나 **출처 은폐, 품질 저하, 폐쇄화, 클라우드 전환**으로 신뢰 상실 - 로컬 LLM 생태계가 필요한 것은 **Ollama가 아니라 llama.cpp** - 진정한 개방성과 성능은 이미 커뮤니티 중심 도구들이 제공 중임 ## Comments ### Comment 55652 - Author: neo - Created: 2026-04-17T09:39:14+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47788385) - 대부분의 로컬 LLM 사용자는 **Ollama** 덕분에 UX 문제가 해결되었다고 생각함 한 줄 명령으로 모델을 실행할 수 있고, ROCm 드라이버도 자동으로 처리됨 반면 **llama.cpp**는 이름부터가 C++ 라이브러리처럼 들려서 일반 사용자가 접근하기 어려움 나는 단지 직접 프로그램을 빌드하고 싶지 않고, 그냥 재미있게 써보고 싶을 뿐임 - 이제 **llama.cpp**는 기본적으로 GUI를 포함함. 예전에는 없었지만 지금은 시대가 달라졌음 - “LM Studio, Jan, Msty, koboldcpp…” 등 대안이 많지만, 실제로 **Ollama를 대체할 만한 후속 주자**가 무엇인지 궁금함 Mac Mini를 쓰지만 CLI 도구도 괜찮음. Ollama의 강점은 손쉬운 설치와 모델 다운로드였기에, 대체 도구도 그 정도의 편의성을 기대함 - **kobold.cpp**나 **LM Studio**는 어떤가 제안함. LM Studio는 오픈소스는 아니지만 llama.cpp에 정당한 크레딧을 줌 모델 지원이 깨진 상태로 통합되거나 잘못된 GGUF를 업로드하지 않도록 **품질 관리**가 중요하다고 생각함 - 동의함. 이건 **Docker**와 비슷한 상황임 물론 runc를 직접 쓸 수도 있지만 대부분은 `docker run`을 선택함 UX는 기술 채택의 핵심 요소이며, 인터페이스를 잘 만들지 못한 프로젝트라면 래퍼를 만드는 게 나쁠 이유가 없음 - Ollama가 UX 문제를 해결했다고 해서 **라이선스 위반**이 면책되는 것은 아님 - 같은 주장을 반복하기 지쳐서, 내가 아는 **타임라인과 출처**를 한 번에 정리했음 - 이 글을 써줘서 고맙다고 함. 나도 llama.cpp에 조금 참여했는데, Ollama 창업자들의 행동은 정말 실망스러웠음 대안으로는 **llama-file**을 추천함. [Mozilla AI의 llamafile](https://github.com/mozilla-ai/llamafile?tab=readme-ov-file)은 단일 실행 파일로 OS에 상관없이 동작하며, 완전한 오픈소스임 **Justine Tunney**가 만든 CosmopolitanC 기반으로, llama.cpp를 정식으로 사용함 - FOSS 정신을 중요하게 생각하는 사람으로서 매우 **교육적인 글**이었다고 함 - 몰랐던 사실이 많았다고 함 - 요약과 타임라인이 훌륭하다고 평가함 - Ollama는 **사용 편의성 면에서 1000배 낫다**고 생각함 llama.cpp는 훌륭하지만 일반 사용자 친화적이지 않음 나는 Ollama로 시작했지만 최신 수정사항을 위해 llama.cpp로 옮겼음 그래도 모델 관리에는 여전히 Ollama를 씀. 너무 편해서 직접 **스크립트를 만들어 캐시 디렉터리**를 관리함 - 블로그 글에서 대안들이 직관적이라고 했지만 실제로는 그렇지 않음 단순 채팅 앱이라면 몰라도, **OpenAI 호환 API와 모델 관리**가 필요한 경우 접근성이 급격히 떨어짐 - Ollama의 기본 **context size**가 너무 작아서 모델이 멍청하다는 불만이 많았음 지속적으로 바꾸려면 새 모델 파일을 만들어야 했고, 그게 더 복잡했음 Docker식 접근이 오히려 일반 사용자에게는 불편하고, 고급 사용자는 llama.cpp가 더 낫다고 생각함 - 참고로 이제 **llama.cpp에 router 모드**가 추가되어 모델을 실시간으로 교체할 수 있음 - 최근 버전은 훨씬 강력해졌음. [llama.cpp tools/serv](https://github.com/ggml-org/llama.cpp/tree/master/tools/serv)에서 확인 가능함 - LM Studio를 3년 전부터 써왔는데, 그때도 이미 Ollama보다 훨씬 나았음 - MIT 라이선스에 대한 두 가지 시각을 정리함 1. “한 줄 크레딧만 주면 뭐든 가능” 2. “법적으로는 자유롭지만, **공동체에 대한 도덕적 책임**이 따른다” llama.cpp의 창시자 **Georgi Gerganov**는 오직 크레딧 누락에만 불만을 표했음. 즉, 그는 첫 번째 해석에 가깝게 행동함 - 두 번째 해석은 말이 안 된다고 생각함. **GPL 의무**를 원하면 GPL을 쓰면 됨 MIT는 법적 문서이지 도덕 지침이 아님 개인적으로는 사용자 대상 소프트웨어에는 GPL을 쓰는 게 좋다고 봄 MIT를 쓰고 나서 기업이 코드를 가져간다고 불평하는 건 모순임 기업에는 **도덕이 없고**, 사람에게만 있다고 생각함 - Georgi가 원했다면 언제든 GPL로 바꿀 수 있었음. 하지만 그렇게 하지 않았음 결국 두 프로젝트 모두 계속 발전했고, 사용자에게 더 많은 선택지가 생겼음 - 예전에는 **기본 모델 폴더를 바꿀 수 없어서** 불편했음 모델을 등록하려면 Dockerfile 비슷한 절차를 거쳐야 했고, 모델이 해시 스토리지로 복사되어 위치를 바꿀 수 없었음 그래서 **LM Studio**로 옮겼음. 완전한 오픈소스는 아니지만, 모델 폴더를 노출하고 **Hugging Face**와 통합되어 있었음 - 이제는 가능함. 서버 설정 파일의 환경 변수 `OLLAMA_MODELS`로 경로를 지정할 수 있음 - 나도 이 문제로 고생했음. SSD 업그레이드 전후로 LM Studio와 비교하려 했는데, 모델 위치를 찾고 정리하는 과정이 너무 **복잡하고 불필요하게 고통스러웠음** - Ollama가 모델 파일을 **해시 블롭 스토리지**에 복사하는 구조 때문에 다른 도구와 공유가 불가능함 아마 **중복 제거**를 위한 설계겠지만, 결과적으로 다른 툴을 시험하기 어렵게 만듦 모델 파일이 워낙 크기 때문에 저장 공간과 다운로드가 큰 부담이 됨 - Arch Linux에서 `pacman -Ss ollama`는 16개 결과가 나오지만, `llama.cpp`나 `lmstudio`는 0개임 언젠가 바뀌길 바람 - **llama.cpp는 업데이트가 너무 빠르기 때문에** 안정 패키지로는 어렵고, 대신 [AUR](https://aur.archlinux.org/packages?O=0&K=llama.cpp)에서 설치 가능함 Vulkan, ROCm, CUDA 버전 모두 지원됨 - 반면 openSUSE에서는 `zypper`로 llamacpp를 찾을 수 있음 배포판마다 버전과 지원이 달라서, 결국 **수많은 리눅스 배포판이 존재하는 이유**가 여기에 있음 - 나는 CachyOS에서 `yay -S llama.cpp`로 설치했는데, **Ollama보다 훨씬 빠르고 좋았음** - “llama.cpp”라는 이름이 이제는 **친근하지 않게 들림** 예전엔 Meta의 Llama 모델을 의미했지만, 지금은 더 강력한 오픈소스 모델들이 많음 - 하지만 “Ollama”도 같은 문제를 안고 있음 지금은 “Local LLaMA”라는 이름이 **로컬 모델 실행의 일반 명칭**처럼 쓰이고 있음 - [위키백과의 일반화된 상표 목록](https://en.wikipedia.org/wiki/List_of_generic_and_genericized_trademarks)을 보면 이런 현상이 흔함 - Ollama는 **워크플로 전체를 통제하려는 냄새**가 나서 처음부터 피했음 결과적으로 **잘한 선택**이었다고 생각함 - Ollama의 **해시 블롭 스토리지 구조**가 가장 큰 함정임 몇 달 동안 모델을 받아왔다면, 다른 툴로 옮길 때 전부 다시 다운로드해야 함 대부분의 사용자는 이미 깊이 투자한 뒤에야 이 사실을 깨닫고 **이탈 비용**을 크게 느끼게 됨