Ollama 0.32: 로컬 모델 런처가 승인형 에이전트 셸로 바뀔 때 운영자가 확인할 것

왜 지금 Ollama 0.32를 봐야 하나

2026년 7월 14일 공개된 Ollama 0.32.0은 단순히 새 모델을 몇 개 더 올린 릴리스가 아니다. 이 버전부터 ollama 루트 명령 자체가 "Chat, Code, & Work"를 위한 대화형 에이전트 진입점으로 바뀌었다. 이어서 7월 17일 공개된 0.32.1은 작업 디렉터리 전달, 인증 오류 메시지, deprecated 모델 선택 같은 실제 운영 마찰점을 빠르게 보완했다.

이 변화가 중요한 이유는 Ollama의 역할이 달라졌기 때문이다.

• 예전에는 ollama run이나 REST API를 통해 모델을 띄우는 로컬 추론 런타임으로 보는 편이 자연스러웠다.
• 0.32부터는 모델 선택, 추천 모델 카탈로그, 도구 실행, 승인 프롬프트, 웹 검색/웹 fetch, 외부 앱 연동(ollama launch)까지 한 CLI 안에서 묶는다.
• 즉, 모델 서빙 프로세스만 관리하던 도구가 에이전트 실행의 제어면(control plane) 일부가 되기 시작한 것이다.

운영자 관점에서 핵심 질문도 달라진다. 이제는 "로컬 모델이 잘 뜨는가"만 보면 부족하다. 어떤 모델이 기본으로 추천되는가, 도구는 언제 열리는가, 승인 범위는 어디까지인가, 현재 작업 디렉터리와 인증 상태가 모델 판단에 어떻게 들어가는가까지 같이 봐야 한다.

한눈에 보는 변화

전체 경로: 0.32가 추가한 제어면

이 그림에서 중요한 점은 단순하다. 0.32의 Ollama는 더 이상 "모델을 띄우는 바이너리"만이 아니다. 추천 모델 결정, 인증 확인, 승인 상태 누적, 작업 디렉터리 전달, 외부 앱 연동 설정이 모두 ollama 진입 경로 안으로 들어왔다.

1. ollama 루트 명령이 에이전트 런처가 됐다

태그된 README.md는 시작 예시를 그냥 ollama로 바꿔 놓았고, 그 다음에 ollama launch claude, ollama launch openclaw 같은 연동 경로를 바로 소개한다. cmd/tui/tui.go를 보면 루트 메뉴의 첫 항목이 아예 "Chat, Code, & Work"이고, 설명도 "Chat with models, code, search the web, and delegate real work"다.

이건 UX 문구 변화가 아니라 기본 사용 모델 변화다.

• 루트 진입점은 agent TUI다.
• 자주 쓰는 연동만 root menu에 짧게 올리고(claude, opencode, hermes, openclaw), 나머지는 ollama launch <integration>로 빼 둔다.
• ollama run과 REST API는 여전히 남아 있지만, 기본 진입점의 철학이 "prompt 1개 실행"에서 "작업 수행"으로 이동했다.

운영 측면에서 이것이 뜻하는 바는 명확하다.

1. 사용자 기대치가 바뀐다. 로컬 모델 runner를 설치해 준다고 생각했던 환경이, 실제로는 shell/file/web 도구까지 연결된 에이전트 셸로 보일 수 있다.
2. 감사 포인트가 늘어난다. 예전에는 API 포트, 모델 파일, 메모리 사용량이 주 관심사였다면 이제는 승인 로그, 도구 사용 경로, 연동 앱 설정 변경까지 같이 봐야 한다.
3. 공유 환경 기본값을 재검토해야 한다. 개인 노트북에서는 편한 기본값이지만, 팀 공용 jump host나 교육용 lab에서는 루트 명령을 그대로 열어 두는 것이 적절한지 다시 판단해야 한다.

2. 도구는 capability가 맞아야 열리고, 세션은 무한 반복을 허용하지 않는다

cmd/agent_tui.go의 agentToolsRegistry()는 아무 모델에나 도구를 붙이지 않는다. 먼저 Show API로 모델 capability를 읽고, model.CapabilityTools가 있을 때만 registry를 만든다. 즉, 모델이 tool calling을 지원한다고 선언하지 않으면 bash/read/edit/web 도구가 아예 비활성이다.

도구가 열려도 세션은 무한 루프를 허용하지 않는다. agent/session.go에는 다음 guardrail이 들어 있다.

• 기본 최대 tool round: 100
• 기본 tool output 상한: 60,000 runes
• 컨텍스트가 작을 때는 6,000 또는 3,200 runes까지 더 줄어드는 후처리 경로
• 한 번의 모델 응답이 tool call을 연쇄적으로 밀어 넣더라도, 일정 횟수 이후에는 "send another message to continue"로 끊어 냄

이 설계가 중요한 이유는 에이전트 failure mode가 일반 chat failure mode와 다르기 때문이다.

• 잘못된 plan은 같은 도구를 반복 호출하며 context를 불린다.
• tool output이 길어질수록 정작 모델이 읽어야 할 핵심 상태가 묻힌다.
• shell/web/file을 한 프로세스에서 섞어 쓰면 "조금만 더 실행해 보자"가 끝없이 이어질 수 있다.

0.32의 Ollama는 이 문제를 모델 품질로만 돌리지 않고, runtime 차원에서 루프 횟수와 출력 크기를 먼저 자른다.

3. 실제 guardrail은 승인 범위와 작업 디렉터리 처리에서 나온다

shell 승인 범위는 "bash 전체"가 아니라 정확한 command 문자열이다

agent/approval.go의 toolApprovalScope()는 shell 도구(bash, Windows에서는 powershell)에 대해 scope를 <tool>\x00<command> 형태로 만든다. 즉 "항상 이 shell 도구 허용"이 아니라 정확히 그 명령 문자열을 기준으로 승인 상태를 기억한다.

이 차이는 꽤 크다.

• ls -la를 허용했다고 해서 ls -la /etc가 자동 허용되는 식이 아니다.
• 공백, 인자, quoting이 바뀌면 다시 프롬프트를 띄운다.
• --auto-approve-tools나 --yolo를 쓰지 않는 한, shell은 기본적으로 세밀한 재승인을 요구한다.

이건 agent shell에서 중요한 안전장치다. 다만 같은 파일의 주석이 분명히 말하듯, 이것은 보안 sandbox가 아니라 승인 편의의 단위화다.

bash 도구는 timeout과 blocklist가 있지만, 보안 경계는 아니다

agent/tools/bash.go는 shell 실행에 다음 제약을 둔다.

• 기본 timeout 3분
• stdout/stderr 각각 최대 60KB
• 너무 넓은 rm -rf 계열이나 credential path 읽기 같은 일부 패턴을 best-effort로 차단

하지만 source code 주석은 이 blocklist를 defense-in-depth라고 명시한다. 즉, 새로운 파괴 명령이나 우회 명령을 완전히 막는 설계가 아니다. 위험 판단의 실제 핵심은 승인 프롬프트다.

file 도구는 설명보다 구현이 더 미묘하다

agent/tools/file.go는 설명 문자열에서 read/edit를 현재 작업 디렉터리 기준 도구처럼 소개한다. 실제 구현은 조금 더 복잡하다.

• edit는 상대 경로만 허용하고 .. 탈출과 symlink escape를 막는다.
• read는 상대 경로 탈출은 막지만, 구현상 allowAbsolute=true로 열리기 때문에 절대 경로의 regular file read는 허용한다.
• read/edit 모두 기본 200KB 제한이 있다.

이건 운영자에게 중요한 포인트다. 겉보기 설명만 읽으면 "file 도구는 cwd sandbox 안에 있다"고 생각하기 쉽다. 하지만 태그된 0.32.0 source는 write 경로는 강하게 묶고, read 경로는 상대적으로 더 넓게 열어 둔 형태다. 개인 노트북에서는 합리적일 수 있지만, 공유 환경 보안 가정과는 다를 수 있다.

4. 추천 모델과 런처는 정적 목록이 아니라 서버 응답 우선 구조다

Ollama 0.32의 런처를 그냥 "모델 picker" 정도로 보면 놓치는 부분이 있다. cmd/launch/launch.go의 recommendations()는 먼저 ModelRecommendationsExperimental()을 호출하고, 실패하거나 비어 있으면 recommendedModels fallback으로 내려온다. 주석도 "Fail open: recommendation issues should not block launch flows"라고 박아 둔다.

이 구조는 두 가지를 뜻한다.

1. 실제 추천 모델 집합은 서버 상태에 따라 바뀔 수 있다.
2. 태그된 소스만 보고 기본 picker 화면을 완전히 재현할 수 없을 수 있다.

이 차이는 release note와 source를 같이 보면 더 분명하다.

• 0.32.0 release screenshot은 glm-5.2:cloud를 예시로 보여 준다.
• 그런데 태그된 cmd/launch/models.go의 fallback 추천 목록에는 glm-5.1:cloud가 들어 있다.

즉, picker의 "권장 모델"은 릴리스 노트 스크린샷, 태그된 fallback list, 서버가 당일 내려주는 추천이 서로 조금씩 다를 수 있는 표면이다. 재현성과 운영 가이드를 쓰는 사람은 이를 고정값처럼 다루면 안 된다.

여기에 deprecated 모델 처리도 붙는다. cmd/launch/deprecated_models.go와 launch.go를 보면 오래된 agent 부적합 모델(codellama, qwen2.5-coder, llama3.x, mistral, 특정 deepseek-r1 태그 등)을 고르면, launcher가 "Launch anyway" / "Pick another model" 프롬프트를 띄운다. 즉 0.32는 단순 추천을 넘어 agent에 맞는 모델 카탈로그를 강하게 유도한다.

5. ollama launch는 외부 앱 설정까지 건드리는 런처가 됐다

0.32의 또 다른 변화는 ollama launch가 단순 wrapper가 아니라 외부 애플리케이션 설정을 조정하는 구성 도구에 가까워졌다는 점이다.

대표적인 예가 chatgpt integration이다. cmd/launch/codex_app.go를 보면 ollama launch chatgpt는 다음을 수행한다.

• ChatGPT용 관리 profile 이름을 잡는다.
• Ollama base URL을 가리키는 config를 쓴다.
• 모델 catalog JSON을 따로 만든다.
• 원래 설정으로 되돌릴 수 있도록 ollama launch chatgpt --restore 경로를 제공한다.

즉, 이제 Ollama는 단순히 "다른 앱이 localhost:11434를 치게 한다" 수준이 아니라, 어떤 앱이 어떤 profile로 어떤 모델 목록을 보게 할지까지 관리한다. desktop integration을 배포하는 팀이라면 이건 편의 기능이면서 동시에 변경관리 대상이다.

• 개인 장비에서는 온보딩을 쉽게 만든다.
• 반면 팀 장비에서는 profile overwrite, restore 절차, 앱 버전 호환성을 따로 점검해야 한다.

6. 0.32.1은 0.32.0의 의도를 유지한 채 운영 마찰을 줄인 패치다

0.32.1 릴리스 노트와 v0.32.0...v0.32.1 compare를 보면, 핵심은 새 철학을 뒤집는 것이 아니라 0.32.0에서 바로 드러난 agent 운영 문제를 봉합하는 것이다.

가장 중요한 수정은 세 가지다.

1. 현재 작업 디렉터리가 system prompt에도 들어간다.

- 0.32.0은 WorkingDir를 tool context로 넘기긴 했지만, 0.32.1에서는 agentWorkingDir()를 통해 이를 system prompt 문면에도 넣는다. - 결과적으로 모델이 프로젝트 문맥을 더 일찍 알 수 있다.

1. web 도구 인증 오류가 행동 가능한 메시지로 단순화된다.

- agent/tools/web.go가 ErrWebAuthRequired = "Not authenticated. Run \ollama signin\ and try again."로 바뀌며, 사용자가 다음 행동을 바로 알 수 있다.

1. deprecated 모델을 --model로 넘겼을 때 picker 복귀 동작이 보정된다.

- 릴리스 노트 기준으로, "Pick another model"을 눌렀을 때 model picker가 다시 열리도록 수정됐다.

이 패치가 주는 운영 메시지는 명확하다. 0.32.0을 기능 소개판으로 읽고, 실제 배포는 최소 0.32.1 이상을 기준으로 보라는 것이다.

트레이드오프와 한계

1. guardrail은 있지만 완전한 격리는 아니다

• shell blocklist는 일부 위험 패턴만 막는다.
• 승인 범위는 세밀하지만, 악의적 입력 전체를 막는 sandbox는 아니다.
• web 도구는 cloud auth에 기대고, local shell 도구와 같은 세션에서 공존한다.

즉 0.32를 개인용 agent shell로 보는 것과 다중 사용자 환경에서 허용 가능한 실행면으로 보는 것은 전혀 다른 판단이다.

2. 설명 문자열과 구현 세부가 완전히 일치하지는 않는다

• file 도구 설명은 cwd 중심처럼 읽히지만, read 구현은 절대 경로 regular file read를 허용한다.
• release note screenshot의 추천 모델과 태그된 fallback 목록도 다르다.

이런 차이는 출시 초반의 agent product에서 흔한 현상이다. 문제는 차이가 있다는 사실보다, 운영자가 문구만 보고 경계를 과신할 때 생긴다.

3. 추천 모델 카탈로그가 서버 응답 우선이라 재현성이 흔들릴 수 있다

문서화나 교육 자료를 만들 때 "Ollama가 기본으로 이 모델을 고른다"고 단정하면 금방 낡는다. 0.32 구조에서는 서버 측 recommendation API가 우선이고, 태그된 정적 목록은 fallback일 뿐이다.

운영자가 바로 확인할 체크리스트

1. 최소 버전을 0.32.1 이상으로 잡을지 결정한다. 0.32.0의 개념 증명만 보고 끝내지 말고, cwd/auth UX 보정이 들어간 패치를 기준점으로 삼는 편이 낫다.
2. 공유 환경에서 루트 ollama 허용 범위를 정한다. 필요하면 ollama run/REST API만 쓰고 agent TUI 진입을 문서나 wrapper로 제한한다.
3. tool capability가 없는 모델에서 UX가 어떻게 보이는지 직접 확인한다. 모든 추천 모델이 항상 tool-capable인 것은 아니다.
4. --auto-approve-tools 또는 --yolo 사용 금지/허용 기준을 정한다. 개인 장비와 팀 장비 기준이 같으면 안 된다.
5. file read/edit 경계를 실제로 테스트한다. 특히 절대 경로 read 허용 여부를 자신들의 보안 가정과 대조해야 한다.
6. cloud 모델과 web 도구를 허용한다면 ollama signin 경로를 온보딩 문서에 넣는다. 0.32부터는 auth가 agent 작업 흐름에 직접 영향을 준다.
7. 추천 모델 drift를 감안해 재현성 문구를 보수적으로 쓴다. release screenshot, 태그된 fallback list, 실시간 recommendation API는 서로 다를 수 있다.
8. 외부 앱 연동은 변경관리 대상으로 본다. ollama launch chatgpt 같은 경로는 설정 쓰기와 restore 절차까지 같이 검토해야 한다.

결론

Ollama 0.32의 본질은 "로컬에서도 agent를 쉽게 돌릴 수 있다"가 아니다. 더 정확히 말하면, 로컬 모델 런처와 agent 실행 제어면이 하나의 CLI로 수렴하기 시작했다는 데 있다.

이 변화는 분명 강력하다. ollama 하나로 모델 선택, tool execution, web search, desktop integration, cloud model auth까지 묶을 수 있기 때문이다. 그러나 바로 그 이유로 운영자는 이전보다 더 많은 것을 확인해야 한다.

• 기본 진입점이 무엇으로 바뀌었는가
• 추천 모델은 어디에서 결정되는가
• tool safety는 어떤 층위에서 보장되는가
• 작업 디렉터리와 인증 상태가 실제로 모델 판단에 들어가는가
• 외부 앱 설정 변경을 누가 책임지는가

0.32는 "로컬 LLM 실행기"가 "작업 수행용 agent shell"로 이동하는 분기점에 가깝다. 그래서 이번 릴리스는 성능 숫자보다 신뢰 경계와 운영 경계가 어디로 옮겨갔는지를 보는 편이 훨씬 중요하다.

References

• Ollama v0.32.0 release notes (published 2026-07-14): https://github.com/ollama/ollama/releases/tag/v0.32.0
• Ollama v0.32.1 release notes (published 2026-07-17): https://github.com/ollama/ollama/releases/tag/v0.32.1
• Ollama v0.32.0 README (ollama, ollama launch, integration overview): https://github.com/ollama/ollama/blob/v0.32.0/README.md
• cmd/tui/tui.go (root menu and Chat, Code, & Work entry): https://github.com/ollama/ollama/blob/v0.32.0/cmd/tui/tui.go
• cmd/agent_tui.go (model selection, tool registry, system prompt wiring): https://github.com/ollama/ollama/blob/v0.32.0/cmd/agent_tui.go
• agent/session.go (tool-round limits and output truncation): https://github.com/ollama/ollama/blob/v0.32.0/agent/session.go
• agent/approval.go (approval scope accumulation and exact shell-command scoping): https://github.com/ollama/ollama/blob/v0.32.0/agent/approval.go
• agent/tools/bash.go (timeout, output cap, best-effort dangerous-command blocking): https://github.com/ollama/ollama/blob/v0.32.0/agent/tools/bash.go
• agent/tools/file.go (read/edit path handling and size limits): https://github.com/ollama/ollama/blob/v0.32.0/agent/tools/file.go
• agent/tools/web.go (web search/fetch auth and timeouts): https://github.com/ollama/ollama/blob/v0.32.0/agent/tools/web.go
• cmd/launch/models.go, cmd/launch/launch.go, cmd/launch/deprecated_models.go (server-driven recommendations, fallback catalog, deprecated-model prompts):

- https://github.com/ollama/ollama/blob/v0.32.0/cmd/launch/models.go - https://github.com/ollama/ollama/blob/v0.32.0/cmd/launch/launch.go - https://github.com/ollama/ollama/blob/v0.32.0/cmd/launch/deprecated_models.go

• Diff for 0.32.0 → 0.32.1 (working-directory and auth-behavior follow-up): https://github.com/ollama/ollama/compare/v0.32.0...v0.32.1