▲

로컬 LLM 생태계에는 Ollama가 필요하지 않다

 (sleepingrobots.com)
6P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 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
    • 진정한 개방성과 성능은 이미 커뮤니티 중심 도구들이 제공 중임

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 대부분의 로컬 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은 단일 실행 파일로 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에서 확인 가능함
    • 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에서 설치 가능함
      Vulkan, ROCm, CUDA 버전 모두 지원됨
    • 반면 openSUSE에서는 zypper로 llamacpp를 찾을 수 있음
      배포판마다 버전과 지원이 달라서, 결국 수많은 리눅스 배포판이 존재하는 이유가 여기에 있음
    • 나는 CachyOS에서 yay -S llama.cpp로 설치했는데, Ollama보다 훨씬 빠르고 좋았음

  • “llama.cpp”라는 이름이 이제는 친근하지 않게 들림
    예전엔 Meta의 Llama 모델을 의미했지만, 지금은 더 강력한 오픈소스 모델들이 많음

    • 하지만 “Ollama”도 같은 문제를 안고 있음
      지금은 “Local LLaMA”라는 이름이 로컬 모델 실행의 일반 명칭처럼 쓰이고 있음
    • 위키백과의 일반화된 상표 목록을 보면 이런 현상이 흔함

  • Ollama는 워크플로 전체를 통제하려는 냄새가 나서 처음부터 피했음
    결과적으로 잘한 선택이었다고 생각함

  • Ollama의 해시 블롭 스토리지 구조가 가장 큰 함정임
    몇 달 동안 모델을 받아왔다면, 다른 툴로 옮길 때 전부 다시 다운로드해야 함
    대부분의 사용자는 이미 깊이 투자한 뒤에야 이 사실을 깨닫고 이탈 비용을 크게 느끼게 됨

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.