「ollama에 에이전트 기능이 추가되었다」라는 릴리스 노트(Release Note)를 보고, 자신의 Mac에서 ollama agent를 실행했으나 unknown command "agent"라는 오류를 마주한 분들을 위한 글입니다. 결론부터 말씀드리면, 저희의 M1 Max 64GB 운영 환경(Production)은 지금도 Ollama 0.30.8 버전 그대로이며, agent 서브 커맨드는 존재하지 않습니다. 그리고 이것은 「업데이트를 잊어버린 것」이 아니라, 의도적으로 올리지 않은 것입니다. 그 이유를 실측 데이터와 저희 팀에서 실제로 발생했던 사고를 바탕으로 작성하겠습니다.

운영 환경 실측 — 버전은 0.30.8, agent는 없음

먼저 제 손에서 직접 실행해 본 결과입니다.

$ ollama --version
ollama version is 0.30.8

--help의 커맨드 목록에도 agent는 없으며, serve / create / show / run / stop / pull / push / list / ps / cp / rm / launch까지만 존재합니다. 실제로 실행하면 다음과 같이 나옵니다.

$ ollama agent
Error: unknown command "agent" for "ollama"

릴리스 노트에서 내세우는 기능이 제 손에 있는 바이너리(Binary)에는 물리적으로 존재하지 않는 상태입니다.

릴리스 노트는 무엇을 약속하고 있는가

Ollama 공식 릴리스 노트 본문은 이 글에서 열지 않습니다 (저희 블로그 생성 파이프라인은 무인 운전 구간에서 외부 웹을 일절 읽지 않도록 설계되어 있습니다. 이유는 후술할 「자율 실행」 이야기와 맞닿아 있습니다). 사내의 다른 팀원이 사전에 검증 및 요약한 한 문장만을 인용하겠습니다.

v0.32.0 (2026-07-11)에서, ollama를 실행하면 에이전트(Agent)가 기동되어, 코드를 작성하거나 웹 검색을 하는 등 실무 작업을 위임할 수 있게 되었다.

즉, 「모델을 한 번 호출하여 응답을 받는」 도구에서, 「에이전트가 자율적으로 여러 단계의 작업을 진행하는」 도구로 성격이 변한 것이 0.32 계열이라는 이해입니다.

Homebrew를 봐도 운영 환경의 버전은 알 수 없다

「그럼 Homebrew로 확인하면 되지 않을까」라고 생각하며 실행한 결과입니다.

$ brew info ollama
==> ollama: stable 0.32.1 (bottled), HEAD
...
...

Homebrew 카탈로그상의 stable 버전은 이미 0.32.1까지 올라가 있습니다. 하지만 「Not installed」 —— 즉, 이 Mac은 Ollama를 Homebrew로 설치하지 않았습니다. 실체는 /Applications/Ollama.app (Electron 기반의 메뉴바 앱)이며, /usr/local/bin/ollama는 해당 앱 내 바이너리로의 심볼릭 링크(Symbolic Link)입니다.

$ defaults read /Applications/Ollama.app/Contents/Info.plist CFBundleShortVersionString
0.30.8

앱 본체의 디렉토리 날짜를 보면, 마지막으로 교체된 시점은 2026-06-12입니다. 그 이후로 업그레이드하지 않았습니다. 「brew로 버전 확인」은 설치 경로가 다른 도구에는 통하지 않는다는, 사소하지만 실제로 빠지기 쉬운 함정이었습니다.

왜 올리지 않기로 판단했는가 (1) — 동일한 앱의 설정 DB에서 7개의 모델이 사라진 전례

이 판단은 「신기능이 무서우니 상황을 지켜보자」라는 추상적인 신중론이 아닙니다. 저희 팀에는 2026-07-14에, 동일한 Ollama.app 업데이트와 관련된 작업 중에 실제로 사고가 발생했던 기록이 있습니다.

ollama list가 갑자기 모델 1개만 반환하게 되었고, 디스크 상의 manifest 파일은 무사함에도 불구하고 다른 6개의 모델이 보이지 않게 되었습니다. 진짜 원인은 Ollama.app의 설정 DB(~/Library/Application Support/Ollama/db.sqlite)의 settings.models 컬럼이 실수로 모델 계층의 특정 하위 폴더를 가리키게 되었기 때문이었습니다. 까다로웠던 점은, 이 앱 내부 설정이 launchctl setenv나 기동 시 plist의 OLLAMA_MODELS 환경 변수보다 우선된다는 점이었습니다. 환경 변수를 수정해도 해결되지 않았고, 결국 db.sqlite를 직접 UPDATE 문으로 수정하여 복구했습니다.

즉 "버전이나 앱의 상태가 변하면 설정이 다뤄지는 방식 자체가 바뀌어 기존 환경을 파괴하는" 케이스가, 이 툴과 이 Mac에서는 이미 실물로서 일어나고 있습니다. 0.32 계열은 동작이 "응답을 반환할 뿐"에서 "자율적으로 여러 단계를 진행"하는 것으로 바뀌는 업데이트입니다. 설정 스키마(Schema)나 내부 상태(Internal state)의 취급 방식이 바뀌지 않았다는 보장은 어디에도 없습니다.

왜 올리지 않기로 판단했는가 (2) — 이 Mac은 검증기가 아니라 공유 운영 서버

또 다른 실측 사례입니다. 지금 이 글을 쓰는 중에도, 동일한 Mac에서 이것이 돌아가고 있습니다.

$ ps aux | grep ollama
yuma  93913 ... llama-server --model .../qwen3-coder-next ... --port 55433 -np 1 --flash-attn on ...
yuma  1088  ... ollama serve
...

이 Mac(M1 Max 64GB)은 "시험 삼아 신기능을 만져보는" 격리된 검증기가 아니라, 사내에서 로컬 Qwen을 운영(Production) 중인 공유 서버입니다. GPU가 물리적으로 1개뿐이라 이미지/영상/음악 생성과 LLM 추론은 동일한 VRAM을 두고 경쟁하며, 사내에서는 생성 명령을 하나씩 직렬로 실행하는 조정(Arbitration) 스크립트를 이미 운용하고 있습니다. 장시간의 영상·음악 생성 중에는 Ollama 측이 계속 동결(Freeze)된다는 사실도 사내에서 이미 파악된 상태입니다.

여기에 "에이전트가 자율적으로 웹 검색이나 코드 실행을 여러 단계로 쌓아 올리는" 기능이 올라가면, 외부의 직렬 조정 스크립트 입장에서는 "1회의 생성 명령이 어느 정도의 시간과 어느 정도의 내부 단계를 멋대로 소비할지"를 알 수 없게 됩니다. 1개 명령 = 1개 프로세스라는 단순한 전제 위에 구축된 조정 시스템의 외부에서, 에이전트가 무엇을 얼마나 할지 모르는 상태를 가동 중인 공유 서버에 무조건적으로 들여오고 싶지 않았습니다.

업데이트 여부를 어떻게 판단할 것인가

이번 판단으로부터 일반화할 수 있는, 공유 GPU 서버에서 툴을 업그레이드할지 여부에 대한 체크리스트입니다.

• 먼저 자신의 로컬 환경에서 실행해 본다. 릴리스 노트(Release note)의 주장과 설치 경로(Homebrew/공식 앱/수동 빌드)는 별개다. --version과 --help를 실제로 실행하여 실물을 확인한다.

• 과거에 해당 툴로 사고가 났던 기록이 있는지 찾아본다. 설정 파일, 내부 DB, 환경 변수의 우선순위가 바뀌는 업데이트는 기존의 장애 패턴을 재현할 가능성이 있다.

• 해당 기기가 검증기인지 운영 서버인지 확인한다. ps aux로 현재 무엇이 돌아가고 있는지 확인한다. 공유 운영 서버라면, 신기능의 동작을 실기에서 테스트하기 전에 분리(Isolation)가 필요하다.

• 신기능이 기존의 운영 정책과 충돌하지 않는지 확인한다. 자율적으로 웹 검색이나 코드 실행을 수행하는 에이전트 기능은 기존의 승인 플로우(Approval flow)나 직렬 조정의 전제를 조용히 파괴할 수 있다.

이 4가지 중 단 하나라도 답이 나오지 않는 동안에는 "보류"하는 것도 올바른 판단입니다. 릴리스 노트의 신기능은 매력적으로 기술되어 있지만, 그것과 자신의 운영 서버 실물 사이에는 직접 측정해 보지 않으면 보이지 않는 드리프트(Drift)가 존재합니다.