클라이언트 프로젝트에 Ollama를 쓰면 안 되는 이유 (sleepingrobots.com)

한줄 요약

로컬 LLM 프로젝트에서 Ollama 선택은 성능, 투명성, 장기 유지보수 세 가지를 동시에 희생하는 결정이다.

본문

로컬 LLM을 프로젝트에 도입할 때 가장 먼저 거론되는 도구가 Ollama다. 설치 한 줄, 모델 실행 한 줄. 데모 속도가 빠르니 클라이언트 앞에서 보여주기 좋다. 그런데 에이전시 입장에서 이 편리함은 종종 납품 이후에 청구서로 돌아온다.

이 글은 Ollama를 쓰지 말라는 감정적 주장이 아니다. 외주 개발과 시스템 납품 경험을 바탕으로, 어떤 구조적 문제가 실제 프로젝트에서 문제로 번지는지를 정리한 것이다.

실제 추론 성능이 기대치보다 낮게 나오는 이유는?

Ollama는 내부적으로 독립적인 추론 엔진을 갖추고 있지 않다. 오픈소스 C++ 추론 라이브러리를 기반으로 동작하던 구조에서, 일정 시점 이후 자체 백엔드로 전환을 시도했다. 문제는 그 과정에서 기존에 해결됐던 버그들이 재현되고, 일부 신규 모델에 대한 지원이 뒤처지는 현상이 나타났다는 점이다.

커뮤니티 벤치마크 기준으로 동일 하드웨어, 동일 모델에서 Ollama의 처리 속도가 기반 라이브러리 대비 30~70% 낮게 측정되는 사례가 여럿 보고됐다. 에이전시 관점에서 이 수치는 단순한 성능 수치가 아니다. 클라이언트가 "왜 AI 응답이 이렇게 느려요?"라고 물을 때, 인프라 선택이 원인이라고 설명해야 하는 상황이 된다.

납품 이후 클라이언트가 자체 운영하는 시스템에서 성능 병목이 발생하면, 원인 추적에 들어가는 공수는 처음 도구를 잘 고를 때보다 훨씬 크다.

모델 이름과 실제 모델이 다르다면, 클라이언트에게 어떻게 설명할 것인가?

Ollama 레지스트리에는 모델 이름 표기 방식이 업스트림 배포처와 다른 경우가 있다. 대표적으로 소형 파인튜닝 모델이 원본 대형 모델과 같은 이름으로 등록되어 제공되는 사례가 있었다. 사용자 입장에서는 유명 모델을 실행한다고 생각했지만, 실제로는 전혀 다른 성능 수준의 모델이 돌아가는 상황이다.

에이전시 프로젝트에서 이런 혼동은 심각한 결과를 낳는다. QA 단계에서 특정 응답 품질을 기준으로 테스트를 통과시켰는데, 클라이언트 환경에서 "같은 모델"을 설치했더니 결과가 전혀 다르게 나오는 경우다. 납품 후 클레임으로 이어질 수 있고, 신뢰 문제가 된다.

모델 선택에 있어 에이전시는 항상 "이 도구가 모델을 있는 그대로 실행하는가"를 검증해야 한다. Hugging Face에서 직접 GGUF를 받아 실행하는 방식이나 모델 출처를 명확히 추적할 수 있는 도구를 쓰는 것이 훨씬 안전하다.

로컬 AI라고 계약했는데, 데이터가 외부로 나가면?

Ollama는 원래 로컬 추론, 즉 데이터가 외부 서버로 나가지 않는다는 전제로 많은 프로젝트에서 채택됐다. 그런데 GUI 앱 출시와 클라우드 모델 제공이 더해지면서 상황이 복잡해졌다. 일부 모델을 선택하면 실제로는 외부 제공사 서버로 요청이 전달되는 구조임에도, 인터페이스상에서 이를 명확히 구분하지 않는다는 지적이 커뮤니티에서 꾸준히 나오고 있다.

에이전시 입장에서 이것은 계약 리스크다. "온프레미스 AI 시스템"으로 납품했는데 특정 조건에서 데이터가 외부로 나간다면, 개인정보 처리 방침, 보안 감사, 경우에 따라서는 법적 책임 문제로 번진다. 금융, 의료, 법률 도메인 클라이언트라면 더 말할 것도 없다.

GUI 앱의 경우 초기에 소스를 공개하지 않고 배포했다가 뒤늦게 코드를 공개 저장소에 합친 이력도 있다. 오픈소스 프로젝트라는 전제로 시스템을 설계했다면, 이런 정책 변화는 유지보수 기준 자체를 흔든다.

대안은 있는가? 에이전시가 고려해야 할 현실적인 선택지

Ollama 자리에 들어올 수 있는 도구는 분명히 있다. 직접 추론 라이브러리를 서버 형태로 실행하는 방식은 성능 오버헤드 없이 동일한 API 형태로 쓸 수 있다. Hugging Face에서 모델을 직접 받아 실행하므로 모델 이름 혼동도 없다. 채팅 템플릿은 모델 파일 자체에 내장된 것을 그대로 읽어 쓰기 때문에, 별도 설정 파일을 만들어 관리할 필요가 없다.

로컬 AI 도입 프로젝트에서 에이전시가 가져야 할 기준은 세 가지다.

첫째, 성능이 검증 가능한가. 동일 환경에서 벤치마크를 직접 돌려보고 클라이언트에게 수치를 제시할 수 있어야 한다.

둘째, 모델 출처가 투명한가. 어떤 파일이 어디서 왔는지, 무엇이 실행되는지 추적 가능해야 한다.

셋째, 데이터 흐름이 명확한가. 온프레미스 계약이라면 네트워크 수준에서 외부 연결이 없음을 확인할 수 있어야 한다.

도구의 인기는 기술적 우수성과 다르다. 많이 쓰인다는 것이 납품 기준이 될 수 없고, 쉽다는 것이 안전하다는 뜻도 아니다. 에이전시의 역할은 클라이언트가 모르는 것을 대신 검토해서, 나중에 문제가 되지 않을 선택을 지금 하는 것이다.