핵심 답변: Ollama 0.32.1은 로컬 에이전트의 ‘도구 호출 신뢰성’과 ‘장기 실행 메모리’를 함께 점검해야 하는 업데이트다
2026년 7월 16일 Ollama가 공개한 v0.32.1은 Gemma 4의 도구 호출과 다중 턴 추론을 개선하고, MLX에서 반복 요청 중 커질 수 있던 모델 캐시 누수를 수정했다. 단순히 답변 품질이 조금 좋아졌다는 소식이 아니다. Mac에서 로컬 모델을 개발 도구나 사내 자동화 에이전트로 돌리는 팀이라면, 같은 작업을 오래 반복할 때의 메모리 상한과 도구 응답이 다음 단계로 정확히 이어지는지를 다시 측정해야 한다는 운영 변화다. Ollama 공식 v0.32.1 릴리스 노트가 이 두 변경을 명시한다.
오늘의 결론은 명확하다. Gemma 4를 쓰는 팀은 모델 교체 벤치마크보다 먼저 도구 호출 성공률·재시도 횟수·작업당 RSS 메모리를 전후 비교해야 한다. 반대로 로컬 API를 단발성 채팅에만 쓰고 MLX도 사용하지 않는다면 긴급 배포 사유는 약하다. 그러나 에이전트가 웹 검색·파일 접근·코드 변경처럼 권한이 있는 도구를 호출한다면, 개선된 연속성은 권한 경계가 잘못 연결될 위험도 키울 수 있으므로 승인과 감사 로그를 함께 검증해야 한다.
무슨 일이 있었나
Ollama는 7월 16일 v0.32.1을 배포했다. 공식 변경 기록의 확인 가능한 항목은 ① Gemma 4 도구 호출 및 멀티턴 추론, 특히 tool-response continuation의 신뢰성 개선, ② 반복 요청에서 메모리를 증가시킬 수 있던 MLX 모델 캐시 누수 수정과 캐시 스냅샷 성능 개선, ③ MLX 텍스트 모델 로딩이 OLLAMA_LOAD_TIMEOUT을 따르도록 변경, ④ 인증이 필요한 에이전트 웹 search/fetch에서 ollama signin 안내 추가, ⑤ 대화형 에이전트에 현재 작업 디렉터리 컨텍스트 전달이다. 발표 주체와 날짜, 원문은 공식 GitHub Release에서 교차 확인할 수 있다.
직전 v0.32.0은 기본 ollama 실행 경험을 대화형 에이전트로 확장했다. 따라서 이번 패치는 새 에이전트 경험에 누적된 실사용 문제를 겨냥한 성격이 강하다. 여기서 ‘Gemma 4가 모든 작업에서 더 정확해졌다’거나 ‘메모리 사용량이 특정 비율로 줄었다’는 수치는 릴리스에 없다. 그런 결론은 사실이 아니라 각 팀의 하드웨어·컨텍스트 길이·동시성에 달린 해석이며, 반드시 자체 측정으로 분리해야 한다.
왜 중요한가
사실: 릴리스는 tool-response continuation과 반복 요청의 MLX 캐시 누수를 직접 언급한다. 해석: 에이전트의 실패는 모델이 도구를 고르지 못하는 문제만이 아니라, 도구 결과가 다음 추론 턴에 누락·왜곡되거나 워커가 메모리 압박으로 불안정해지는 문제로도 나타난다. 도구 호출이 한 번 성공했다는 UI 표시는 충분하지 않다. 호출 ID, 인자, 결과 요약, 후속 행동이 같은 trace에 이어져야 운영 가능한 성공이다. 불확실성: Gemma 4의 개선 범위, MLX 외 백엔드의 변화, 실서비스의 지연시간 효과는 공식 노트만으로 정량화할 수 없다.
특히 Nuxt 프론트엔드를 운영하는 개발자에게 로컬 AI는 콘텐츠 초안, PR 요약, 로그 분류, 내부 검색처럼 서버 측 작업으로 연결되기 쉽다. 이때 모델이 현재 디렉터리를 안다는 사실은 편의 기능이지 권한 모델이 아니다. 작업 디렉터리의 파일 목록·환경변수·비밀 파일에 접근 가능한지 여부는 실행 래퍼와 도구 서버가 결정한다. 모델 품질 개선을 이유로 셸·파일·배포 토큰을 한 번에 열어 주는 설계는 피해야 한다.
1. Gemma 4 도구 호출: ‘선택’이 아니라 ‘완결된 트랜잭션’을 평가한다
변경 내용: v0.32.1은 Gemma 4의 tool calling과 multi-turn reasoning, 특히 도구 응답 뒤의 연속성을 개선했다. 실제 영향: 검색→문서 읽기→요약, 이슈 조회→코드 수정 제안처럼 결과를 다음 턴에서 참조하는 흐름에서 불필요한 재호출과 중단이 줄 수 있다. 그러나 모델이 도구 이름을 맞혔다고 성공으로 세면 안 된다. 잘못된 인자, 오래된 결과 재사용, 결과를 무시한 최종 답변도 실패다.
적용/회피 조건: JSON schema가 있는 읽기 전용 도구부터 적용하고, 쓰기 도구는 사람 승인 또는 idempotency key를 둔다. 도구 결과가 크면 원문 전체 대신 서버가 만든 제한된 구조체를 반환한다. 운영 데이터에 직접 쓰는 CRM·배포·결제 도구는 모델의 자연어 판단만으로 실행하지 않는다. 검증 방법: 고정된 30~50개 시나리오를 만들고 tool_selected, schema-valid 인자율, 결과를 사용한 후속 답변율, 동일 호출 재시도 수, 승인 거절 수를 버전별로 수집한다. 실패 transcript도 보관하되 개인 데이터와 토큰은 마스킹한다.
2. MLX 캐시 수정: 장기 실행 워커의 메모리 곡선을 다시 그린다
변경 내용: 공식 노트는 반복 요청에서 메모리를 키울 수 있던 MLX 모델 캐시 누수 수정과 캐시 스냅샷 성능 개선을 밝힌다. 실제 영향: Mac의 로컬 에이전트가 짧은 요청에서는 정상인데 밤새 처리 후 느려지거나 재시작되는 유형이라면, 이 패치가 직접 관련될 수 있다. 다만 누수 수정은 전체 메모리 비용 제거를 뜻하지 않는다. KV cache, 동시 요청, 큰 이미지 입력, 애플리케이션 큐 적체는 별도 원인이다.
적용/회피 조건: MLX 백엔드와 반복 호출 워커를 실제로 사용하면서 메모리 증가가 관찰된 경우 우선순위가 높다. 이미 프로세스를 요청마다 종료하거나 GPU 서버만 쓰는 경우 효과는 제한적일 수 있다. 검증 방법: 동일 프롬프트·동일 컨텍스트로 500회 이상 호출해 PID RSS와 p95 지연시간을 10회 단위로 기록한다. 업그레이드 전후의 기울기와 재시작 횟수를 비교하고, 메모리가 단조 증가하거나 p95가 기준선보다 20% 이상 악화하면 롤백한다. macOS에서는 Activity Monitor만 보지 말고 서비스 프로세스 기준의 샘플을 남긴다.
3. 로딩 시간 제한과 큐: 장애를 타임아웃으로 숨기지 않는다
변경 내용: MLX 텍스트 모델 로딩이 OLLAMA_LOAD_TIMEOUT을 존중하게 됐다. 실제 영향: 모델 cold start가 긴 환경에서 애플리케이션의 HTTP timeout과 런타임 로딩 timeout을 의도적으로 맞출 수 있다. 반대로 값을 무작정 늘리면 사용자는 무한 대기처럼 느끼고, 큐는 쌓인다.
적용/회피 조건: Nuxt 서버 API가 Ollama를 호출한다면 runtimeConfig에 실제 비밀을 넣지 말고 서버 환경변수로 endpoint만 주입하며, 요청별 abort timeout은 사용자 화면 예산 안에 둔다. 백그라운드 작업은 더 긴 별도 큐로 분리한다. 검증 방법: 모델이 메모리에서 제거된 상태와 warm 상태를 구분해 성공률, cold/warm p50·p95, 499/504 비율, 큐 체류 시간을 대시보드에 표시한다. timeout 발생 후에도 모델 로딩이 계속돼 자원을 점유하는지 로그로 확인한다.
4. 웹 search/fetch와 현재 디렉터리: 컨텍스트 전달은 최소 권한으로 감싼다
변경 내용: 인증이 필요한 웹 도구에서 로그인 안내가 추가됐고, 대화형 에이전트는 현재 작업 디렉터리 정보를 받는다. 실제 영향: 사용자는 ‘왜 검색이 안 되는지’를 더 빨리 진단할 수 있지만, 인증 완료를 자동 실행 권한 획득으로 오해할 수 있다. 현재 디렉터리도 모델의 경로 추론을 돕지만 프로젝트 밖 접근을 막지는 않는다.
적용/회피 조건: 검색과 fetch는 허용 도메인 목록, 응답 크기 제한, 다운로드 차단 규칙을 둔다. 파일 도구는 프로젝트 루트를 실경로로 검증하고 .env, SSH 키, 배포 설정은 기본 거부한다. 쓰기·명령 실행은 명시적 승인 단계와 diff를 요구한다. 검증 방법: 상위 디렉터리 이동, 심볼릭 링크, 비밀 파일명, 리다이렉트 URL, 대용량 응답을 넣은 adversarial test를 만든다. 허용되지 않은 경로·도메인 접근이 0건인지, 모든 실행에 사용자·도구·인자 해시·결과 코드가 남는지 확인한다.
개발자 실행 계획
- 버전 고정: 배포 manifest 또는 Brew/패키지 관리 설정에서 현재 Ollama 버전과 모델 태그를 기록하고, v0.32.1을 스테이징에만 먼저 설치한다.
- 도구 계약 테스트:
tests/agent/tool-contract.json에 읽기·실패·재시도·승인 시나리오를 추가하고 schema-valid 비율과 후속 결과 참조를 CI 기준으로 만든다. - 메모리 soak test: MLX 워커에 500회 반복 작업을 실행해 RSS, p95, 재시작 횟수를 CSV/관측 시스템에 남긴다.
- Nuxt API 분리:
server/api/ai/*의 사용자 요청 timeout과server/tasks/*의 장기 작업 timeout·큐를 분리한다. - 권한 축소: 도구 서버의 허용 루트·도메인·명령 allowlist를 코드 리뷰하고 비밀 파일 denylist와 심볼릭 링크 검사를 넣는다.
- 관측성: request ID에서 모델 호출, tool call, 승인, 최종 응답까지 잇되 프롬프트·비밀 값은 저장하지 않는다.
- 점진 배포: 내부 사용자 또는 읽기 전용 작업 10%에 먼저 적용하고 tool error rate, 작업 완료 시간, RSS 기울기를 전 버전과 비교한다.
리스크와 한계
이 릴리스는 Gemma 4 도구 호출 개선의 벤치마크, 지원되는 모든 플랫폼의 메모리 수치, 보안 모델의 변경을 발표하지 않았다. 따라서 ‘더 안전하다’ 또는 ‘메모리가 해결됐다’는 선언은 근거가 없다. tool-response continuation이 더 잘 된다는 것은 의도하지 않은 쓰기 단계까지 더 매끄럽게 이어질 가능성도 뜻한다. 승인 없는 배포·삭제·외부 전송 도구는 계속 금지해야 한다.
롤백 조건은 명시적으로 정한다. 계약 테스트의 핵심 성공률이 이전보다 2%p 이상 하락, p95 지연시간이 20% 이상 증가, RSS가 기준선 대비 지속 상승, 권한 거부가 우회되거나 감사 이벤트가 누락되면 이전 버전과 이전 모델 태그로 되돌린다. 롤백 전에 실행한 쓰기 작업은 별도 감사 목록으로 검토한다. 모델과 런타임을 동시에 바꾸면 원인 분리가 불가능하므로 한 번에 하나만 바꾼다.
FAQ
Ollama 0.32.1은 Gemma 4를 쓰지 않아도 설치해야 하나요?
MLX에서 반복 요청을 처리하고 메모리 증가를 겪었다면 검토 가치가 높다. Gemma 4 개선은 직접 적용되지 않을 수 있으므로, 사용 백엔드·모델·에이전트 기능을 먼저 확인한 뒤 스테이징 soak test 결과로 결정하는 것이 맞다.
도구 호출 성공률은 어떤 지표로 측정하나요?
도구 선택 성공만 보지 말고 schema-valid 인자, 실행 HTTP/프로세스 결과, 응답을 사용한 다음 단계의 정확성, 재시도 수, 사람 승인 결과를 한 작업 ID로 묶어 측정한다. 특히 쓰기 도구는 ‘실행됨’이 아니라 의도한 변경만 한 번 적용됐는지를 확인해야 한다.
현재 작업 디렉터리를 에이전트에 주면 프로젝트 파일이 안전한가요?
아니다. 디렉터리 정보는 컨텍스트일 뿐 샌드박스가 아니다. 파일 접근 도구가 실제 경로를 제한하고, 비밀 파일을 거부하며, 심볼릭 링크와 상위 경로 이동을 검사해야 안전 경계가 된다.
출처 및 추가 읽기
더 깊게 읽기: 실전 가이드
이 리포트는 최근 흐름을 빠르게 파악하기 위한 요약입니다. 실제 프로젝트에 적용할 때는 아래의 기준 글과 함께 확인하면 더 안전합니다.