Ollama 버전 롤백 실전: 개발자 90%가 놓치는 3가지 핵심 단계

Ollama 업그레이드 알림을 클릭했더니 0.6.8 버전에서 API 응답 시간이 200ms에서 5초로 치솟고, 메모리 사용량은 두 배가 되었으며, ollama run llama3.2조차 멈춰 버렸습니다. GitHub Issue #10652에는 수십 명의 사용자가 “업그레이드 후 시스템을 사용할 수 없고, 되돌리고 싶은데 공식적으로 구버전 다운로드를 제공하지 않는다”고 불만을 남겼습니다.

공식 답변은 단호했습니다. 최신 버전만 지원하며, 롤백 기능은 아직 지원하지 않는다는 것입니다.

이 문제를 한 번 크게 겪고 나니, 이제는 업그레이드 전마다 반드시 전체 백업을 먼저 합니다. 이 글에서는 세 가지 롤백 방식(바이너리 교체, 패키지 관리자, Docker), 원클릭 자동화 스크립트, 다중 버전 공존 설정, 그리고 직접 겪은 모든 함정을 정리합니다.

왜 버전 롤백이 필요할까? 실제 고통 지점 분석

소프트웨어 업그레이드는 원래 좋은 일입니다. 새 기능이 생기고, 성능이 개선되고, 버그가 고쳐지기 때문입니다. 하지만 Ollama 업그레이드는 때때로 생각보다 큰 “놀라움”을 안겨 줍니다.

세 가지 큰 위험: 성능, 호환성, 안정성

제가 가장 많이 본 상황은 세 가지입니다.

성능이 갑자기 떨어집니다. 어떤 사용자는 특정 버전으로 업그레이드한 뒤 추론 속도가 초당 50 tokens에서 10 tokens도 안 되는 수준으로 떨어졌다고 했습니다. 메모리 사용량도 이유 없이 두 배가 되어, 4GB 모델이 갑자기 8GB를 먹는 경우도 있습니다. 이런 상황이면 애플리케이션은 바로 느려지고, 사용자는 답변 하나를 받으려고 30초씩 기다려야 합니다. 견디기 어렵습니다.

API가 호환되지 않습니다. 이 문제는 더 숨어 있습니다. Ollama만 업그레이드했고 코드는 바꾸지 않았는데 API 호출이 실패하기 시작합니다. 매개변수 이름이 바뀌었을 수도 있고, 반환 형식이 조정되었을 수도 있으며, 어떤 엔드포인트가 아예 폐기되었을 수도 있습니다. 예전에 작업하던 한 프로젝트에서는 업그레이드 후 api/generate의 timeout 매개변수가 갑자기 효력을 잃어 모든 장시간 작업이 타임아웃으로 끊겼습니다. 한참 확인한 뒤에야 새 버전에서 이 매개변수의 기본 동작이 바뀐 것을 알았습니다.

시스템이 불안정해집니다. 가장 힘든 경우입니다. 서비스가 이유 없이 재시작되고, 모델 로딩이 실패하며, 로그에는 이해하기 어려운 오류가 쌓입니다. 한 번은 제 Ollama 서비스가 30분마다 자동 종료되었습니다. 다시 시작하면 잠깐은 정상으로 돌다가 또 멈췄습니다. 이틀을 붙잡고 나서야 새 버전의 메모리 누수 버그라는 것을 알게 되었습니다.

GitHub Issue #10652: 실제 사용자들의 목소리

이 Issue는 2025-05-10에 만들어졌고, 지금까지 100명 이상의 사용자가 논의에 참여했습니다. 제목도 매우 직접적입니다. “Ability to downgrade”, 즉 다운그레이드 지원입니다.

작성자의 설명이 특히 인상적이었습니다. “0.6.8로 업그레이드한 뒤 시스템을 거의 사용할 수 없습니다. 추론 속도가 받아들이기 어려울 만큼 느리고, API 호출은 자주 타임아웃됩니다. 여러 설정을 조정해 봤지만 효과가 없었습니다. 이전 버전으로 돌아가고 싶은데 공식 다운로드는 최신 버전만 제공합니다.”

댓글 중 한 사용자는 더 직설적으로 말했습니다. “문제를 찾느라 사흘을 썼고, 결국 새 버전의 알려진 버그라는 것을 알았습니다. 하지만 공식 수정은 아직 없어서 기다릴 수밖에 없었습니다. 2주를 기다렸는데도 버그는 그대로였습니다. 제 프로젝트 일정은 이 버전 문제 때문에 전부 밀렸습니다.”

이건 드문 사례가 아닙니다. Reddit과 커뮤니티 포럼에도 비슷한 불만이 계속 올라옵니다. 버전 업그레이드 문제 때문에 개발을 멈춘 사람도 있고, 위험을 피하려고 아예 업그레이드를 하지 않은 채 특정 구버전에 고정해 둔 사람도 있습니다.

공식 제한: 최신 버전만 지원

문제의 뿌리는 Ollama 공식 다운로드 페이지가 언제나 최신 버전만 보여 준다는 점입니다. GitHub Releases에는 과거 버전이 분명히 있지만, 공식 문서에는 롤백 방법이 거의 언급되어 있지 않습니다. Homebrew와 APT 같은 패키지 관리자도 기본적으로 최신 버전을 설치합니다.

“업그레이드를 안 하면 되잖아?”라고 생각할 수도 있습니다. 하지만 업그레이드는 때로 수동이 아니라 반강제적으로 일어납니다. 시스템 의존성이 업데이트되거나, 다른 도구가 강제로 요구하거나, 실수로 업그레이드 버튼을 누르는 경우가 있습니다. 저는 마지막 경우였습니다. 문제가 드러난 뒤에는 되돌리고 싶어도 이미 늦은 상황이 됩니다.

게다가 구버전 설치 파일을 찾았다고 해도 롤백 과정 자체에도 위험이 있습니다. 모델 데이터가 사라지지는 않을까? 설정이 충돌하지는 않을까? 서비스가 정상적으로 시작될까? 모두 불확실합니다.

그래서 믿을 수 있는 버전 롤백 절차를 갖추는 일은 실제로 프로젝트를 구할 수 있습니다. 이제 세 가지 대표 방식을 자세히 살펴보며 빠르게 롤백하고 여러 함정을 피하는 방법을 정리해 보겠습니다.

버전 롤백 실전: 세 가지 방식 비교와 자세한 단계

먼저 결론부터 말하면, 세 가지 방식은 각각 장단점이 있고 어떤 방식을 고를지는 배포 방식과 시간 여유에 따라 달라집니다.

방식 비교: 시간, 난이도, 적용 시나리오

방식	롤백 시간	작업 난이도	적용 시나리오	위험 수준
바이너리 교체	~5분	중간	빠른 롤백, 수동 제어	중간(수동 백업 필요)
패키지 관리자 롤백	~10분	낮음	Homebrew/APT 사용자	낮음(자동 관리)
Docker 컨테이너 롤백	~15분	낮음	컨테이너 배포	가장 낮음(완전 격리)

솔직히 제가 고른다면 Docker 방식이 가장 마음 편합니다. 하지만 컨테이너로 배포하지 않았다면 바이너리 교체도 빠르게 처리할 수 있습니다. 이제 각 방식의 구체적인 단계를 하나씩 보겠습니다.

방식 1: 바이너리 교체 롤백(가장 빠르지만 수동 작업 필요)

이 방법은 Ollama 실행 파일을 직접 교체합니다. 장점은 빠르다는 것이고, 단점은 백업과 검증을 직접 해야 한다는 것입니다.

1단계: 서비스 중지

# macOS/Linux
ollama stop
# 위 명령이 동작하지 않으면 이 명령 사용
sudo systemctl stop ollama  # Linux
# 또는 프로세스를 직접 종료
pkill -9 ollama

서비스가 멈추지 않으면 남은 프로세스가 있는지 확인합니다.

ps aux | grep ollama
lsof -i :11434  # 포트 점유 확인

2단계: 현재 설치 상태 백업

이 단계는 절대 건너뛰지 마세요. 예전에 백업 없이 진행했다가 롤백 실패 후 그대로 곤란한 상황에 빠진 적이 있습니다.

# 바이너리 파일 백업
sudo cp /usr/local/bin/ollama ~/ollama-backup-current

# 설정과 모델 데이터 백업(이 디렉터리는 매우 클 수 있음)
# ~/.ollama 디렉터리에는 모든 모델이 저장되며, 수십 GB가 될 수도 있음
cp -r ~/.ollama ~/.ollama-backup-$(date +%Y%m%d)

데이터를 백업할 때는 디렉터리 크기를 한 번 확인하세요. 저는 한 번 백업을 하다가 ~/.ollama가 40GB가 넘는 것을 보고 오래된 모델을 잔뜩 정리한 적이 있습니다.

du -sh ~/.ollama  # 크기 확인
# 너무 크면 사용하지 않는 모델을 먼저 삭제할 수 있음
ollama list  # 어떤 모델이 있는지 확인
ollama rm unused-model-name  # 사용하지 않는 모델 삭제

3단계: 대상 버전 다운로드

GitHub Releases에서 필요한 버전을 찾습니다.

# GitHub Releases 페이지 열기
https://github.com/ollama/ollama/releases

# 필요한 버전 찾기. 예: 0.1.30
# 시스템에 맞는 바이너리 파일 다운로드
# macOS (Intel)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin -o ollama-v0.1.30

# macOS (Apple Silicon)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin-arm64 -o ollama-v0.1.30

# Linux
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-linux-amd64 -o ollama-v0.1.30

다운로드할 때 파일명을 주의하세요. 시스템마다 패키지가 다릅니다. 잘못 받으면 교체 후 바로 오류가 납니다.

4단계: 바이너리 파일 교체

# 다운로드한 파일에 실행 권한 부여
chmod +x ollama-v0.1.30

# 시스템의 ollama 교체
sudo mv ollama-v0.1.30 /usr/local/bin/ollama

# 권한 문제가 나면 기존 파일을 먼저 삭제한 뒤 복사
sudo rm /usr/local/bin/ollama
sudo cp ollama-v0.1.30 /usr/local/bin/ollama
sudo chmod +x /usr/local/bin/ollama

5단계: 롤백 성공 검증

# 버전 확인
ollama --version
# ollama version 0.1.30 또는 되돌린 버전이 표시되어야 함

# 서비스 시작
ollama serve

# API 테스트
curl http://localhost:11434/api/version
# {"version":"0.1.30"} 형태로 반환되어야 함

# 모델 추론 테스트(작은 모델로 빠르게 확인)
ollama run llama3.2 "Hello, test"

버전이 맞고, API가 정상이며, 모델이 실행되면 성공입니다. 문제가 생기면 백업으로 복구합니다.

sudo mv ~/ollama-backup-current /usr/local/bin/ollama
ollama serve  # 서비스 재시작

방식 2: 패키지 관리자 롤백(가장 안정적이며 Homebrew/APT 사용자에게 적합)

Homebrew(macOS)나 APT(Ubuntu)로 설치했다면 이 방법이 가장 편합니다. 패키지 관리자가 버전 의존성과 설정을 처리해 줍니다.

Homebrew(macOS)

# 현재 버전 먼저 제거
brew uninstall ollama

# 특정 버전 설치(예: 0.1.30)
# Homebrew에 모든 구버전이 있지는 않으므로 먼저 확인 필요
brew search ollama  # 사용 가능한 버전 확인

# 원하는 버전이 있으면 설치
brew install [email protected]  # 이 버전이 존재하는 경우

# 자동 업그레이드 방지를 위해 버전 고정
brew pin ollama

# 검증
ollama --version

솔직히 Homebrew의 버전 관리는 조금 까다롭습니다. 오래된 버전이 저장소에 없는 경우가 있고, 이때는 방식 1의 바이너리 교체를 써야 합니다.

APT(Ubuntu/Debian)

# 사용 가능한 버전 확인
apt-cache policy ollama

# 특정 버전 설치
sudo apt-get install ollama=0.1.30-1

# 버전 고정
sudo apt-mark hold ollama

# 검증
ollama --version

APT는 Homebrew보다 비교적 믿을 만합니다. 공식 저장소가 보통 여러 버전을 보관하는 경우가 많습니다.

방식 3: Docker 컨테이너 롤백(가장 안전하고 완전 격리)

Docker로 배포했다면 롤백은 가장 쉽습니다. 이미지 버전만 바꾸면 됩니다.

특정 버전 이미지 가져오기

# 현재 실행 중인 컨테이너 확인
docker ps | grep ollama

# 현재 컨테이너 중지
docker stop ollama-container
docker rm ollama-container

# 대상 버전 이미지 가져오기
docker pull ollama/ollama:0.1.30

# 컨테이너 실행(버전 태그 사용)
docker run -d \
  --name ollama-container \
  -v ~/.ollama:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama:0.1.30

# 컨테이너 버전 검증
docker exec ollama-container ollama --version

docker-compose로 버전 고정

docker-compose를 사용한다면 docker-compose.yml을 수정합니다.

services:
  ollama:
    image: ollama/ollama:0.1.30  # 버전 고정, latest 사용 금지
    volumes:
      - ~/.ollama:/root/.ollama
    ports:
      - "11434:11434"

그다음 다시 배포합니다.

docker-compose down
docker-compose up -d

Docker 방식의 장점은 모델 데이터가 호스트의 ~/.ollama에 있고, 컨테이너 버전만 바뀌어도 데이터는 그대로라는 점입니다. 게다가 컨테이너끼리는 완전히 격리되므로, 여러 Ollama 버전을 동시에 실행할 수도 있습니다. 이 부분은 뒤에서 더 자세히 설명하겠습니다.

자동화 롤백 스크립트와 건강 검사 실전

수동 롤백도 가능하지만 매번 여러 명령을 입력하다 보면 실수하기 쉽습니다. 그래서 저는 롤백, 검증, 모니터링을 한 번에 처리하는 자동화 스크립트를 만들었습니다.

원클릭 롤백 스크립트(ollama-rollback.sh)

이 스크립트는 서비스 중지, 백업, 다운로드, 교체, 검증을 자동으로 처리합니다. 실패하면 백업을 자동으로 복구합니다.

#!/bin/bash
# ollama-rollback.sh - Ollama 버전 원클릭 롤백 스크립트
# 사용법: ./ollama-rollback.sh <대상 버전 번호>

TARGET_VERSION=$1
BACKUP_DIR=~/.ollama-backups
OLLAMA_BIN=/usr/local/bin/ollama

if [ -z "$TARGET_VERSION" ]; then
  echo "오류: 대상 버전 번호를 지정하세요"
  echo "사용법: ./ollama-rollback.sh <버전 번호>"
  exit 1
fi

echo "=== Ollama를 버전 $TARGET_VERSION으로 롤백 시작 ==="

# 1단계: 서비스 중지
echo "[1/5] Ollama 서비스 중지..."
ollama stop || pkill -9 ollama
sleep 2

# 2단계: 현재 버전 백업
BACKUP_NAME="ollama-backup-$(date +%Y%m%d-%H%M%S)"
echo "[2/5] 현재 버전을 $BACKUP_DIR/$BACKUP_NAME에 백업..."
mkdir -p $BACKUP_DIR
cp $OLLAMA_BIN $BACKUP_DIR/$BACKUP_NAME/ollama-bin
cp -r ~/.ollama $BACKUP_DIR/$BACKUP_NAME/ollama-data

# 3단계: 대상 버전 다운로드
echo "[3/5] Ollama $TARGET_VERSION 다운로드..."
OS_TYPE=$(uname -s)
ARCH=$(uname -m)

if [ "$OS_TYPE" = "Darwin" ]; then
  if [ "$ARCH" = "arm64" ]; then
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin-arm64"
  else
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin"
  fi
else
  DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-linux-${ARCH}"
fi

curl -L $DOWNLOAD_URL -o /tmp/ollama-$TARGET_VERSION || {
  echo "다운로드 실패! 백업 복구..."
  cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  exit 1
}

# 4단계: 바이너리 교체
echo "[4/5] 바이너리 파일 교체..."
chmod +x /tmp/ollama-$TARGET_VERSION
sudo mv /tmp/ollama-$TARGET_VERSION $OLLAMA_BIN

# 5단계: 검증
echo "[5/5] 롤백 검증..."
ollama serve
sleep 3

INSTALLED_VERSION=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ "$INSTALLED_VERSION" = "$TARGET_VERSION" ]; then
  echo "✓ 롤백 성공! 현재 버전: $INSTALLED_VERSION"
  echo "백업 위치: $BACKUP_DIR/$BACKUP_NAME"
else
  echo "✗ 버전 검증 실패! 백업 복구..."
  sudo cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  ollama serve
  exit 1
fi

사용법은 간단합니다.

chmod +x ollama-rollback.sh
./ollama-rollback.sh 0.1.30

스크립트는 각 단계의 진행 상황을 자동으로 출력합니다. 다운로드에 실패하거나 버전이 맞지 않으면 자동으로 백업을 복구하므로 중간 상태에 갇히지 않습니다.

건강 검사 스크립트 준비(health-check.sh)

롤백 후에는 버전 번호만 보는 것으로 충분하지 않습니다. 서비스가 실제로 실행되는지도 확인해야 합니다. 이 스크립트는 버전, 서비스, API, 모델 네 가지 차원에서 점검합니다.

#!/bin/bash
# health-check.sh - Ollama 서비스 건강 검사 스크립트

echo "=== Ollama 서비스 건강 검사 ==="

# 1. 버전 검증
VERSION=$(ollama --version 2>&1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$VERSION" ]; then
  echo "✓ 버전: $VERSION"
else
  echo "✗ 버전 검사 실패"
  exit 1
fi

# 2. 서비스 상태
SERVICE_PID=$(pgrep -f "ollama serve")
if [ -n "$SERVICE_PID" ]; then
  echo "✓ 서비스 실행 중 (PID: $SERVICE_PID)"
else
  echo "✗ 서비스가 실행 중이 아님"
  ollama serve
  sleep 3
fi

# 3. API 응답
API_RESPONSE=$(curl -s -w "%{http_code}" http://localhost:11434/api/version -o /tmp/api-test.json)
if [ "$API_RESPONSE" = "200" ]; then
  echo "✓ API 정상 응답"
else
  echo "✗ API 이상 (HTTP $API_RESPONSE)"
  exit 1
fi

# 4. 모델 테스트
TEST_MODEL=$(ollama list | head -2 | tail -1 | awk '{print $1}')
if [ -z "$TEST_MODEL" ]; then
  echo "⚠ 설치된 모델이 없음"
else
  echo "테스트 모델: $TEST_MODEL"
  ollama run $TEST_MODEL "Say hello" --verbose > /tmp/model-test.log 2>&1
  if grep -q "hello" /tmp/model-test.log; then
    echo "✓ 모델 추론 정상"
  else
    echo "✗ 모델 추론 실패"
    cat /tmp/model-test.log
    exit 1
  fi
fi

echo ""
echo "=== 건강 검사 완료 ==="

실행하면 다음과 비슷한 결과가 나옵니다.

=== Ollama 서비스 건강 검사 ===
✓ 버전: 0.1.30
✓ 서비스 실행 중 (PID: 12345)
✓ API 정상 응답
테스트 모델: llama3.2:latest
✓ 모델 추론 정상

=== 건강 검사 완료 ===

어느 항목이든 실패하면 스크립트가 즉시 오류를 표시하므로 문제 위치를 빠르게 찾을 수 있습니다.

성능 비교 스크립트(성능 모니터링)

롤백 후에는 전후 성능을 비교하는 것이 좋습니다. 이 스크립트는 응답 시간과 메모리 사용량을 테스트합니다.

#!/bin/bash
# performance-check.sh - 성능 비교 스크립트

echo "=== 성능 기준 테스트 ==="

# API 응답 시간 테스트
echo "API 응답 속도 테스트..."
START=$(date +%s%N)
curl -X POST http://localhost:11434/api/generate \
  -d '{"model":"llama3.2","prompt":"Hello","stream":false}' \
  -H "Content-Type: application/json" > /tmp/perf-test.json 2>&1
END=$(date +%s%N)
RESPONSE_TIME=$((($END - $START) / 1000000))

echo "API 응답 시간: ${RESPONSE_TIME}ms"

# 메모리 사용량 확인
MEMORY_USAGE=$(ps aux | grep ollama | grep -v grep | awk '{print $4}')
MEMORY_MB=$(ps aux | grep ollama | grep -v grep | awk '{print $6}')

echo "메모리 사용량: ${MEMORY_USAGE}% (${MEMORY_MB}KB)"

# 파일에 기록
echo "$(date): 버전=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), 응답=${RESPONSE_TIME}ms, 메모리=${MEMORY_MB}KB" >> ~/.ollama-performance.log

echo ""
echo "데이터가 ~/.ollama-performance.log에 저장되었습니다"
echo "롤백 전후 데이터를 비교해 성능이 회복되었는지 확인하세요"

한 번은 롤백 후 이 스크립트로 테스트했더니 응답 시간이 5000ms에서 200ms로 떨어지고, 메모리 사용량도 80%에서 35%로 내려갔습니다. 그 숫자를 보고 나서야 롤백이 정말 효과가 있었다고 안심할 수 있었습니다.

이 스크립트들은 GitHub에 올려 두었으니 바로 내려받아 사용할 수 있습니다. 뒤에서 설명할 다중 버전 공존 방식과 함께 쓰면 버전 관리를 거의 완전히 자동화할 수 있습니다.

다중 버전 공존 실전: 설정과 관리 전략

때로는 여러 모델 버전을 동시에 실행해야 합니다. 예를 들어 개발 환경에서는 테스트 버전을 먼저 써 보고, 운영 환경에서는 안정 버전을 유지하는 식입니다. Ollama는 기본적으로 다중 버전 공존을 지원하지 않지만, 몇 가지 방식으로 이 제한을 우회할 수 있습니다.

세 가지 공존 방식: 각자의 장단점

방식	구현 방식	적용 시나리오	장단점
Tag로 버전 구분	ollama create mymodel:v1.0	같은 모델의 여러 버전	간단하지만 동시에 하나만 로드 가능
다중 인스턴스 배포	다른 포트 사용(11434, 11435)	여러 모델 병렬 실행	유연하지만 리소스 사용량이 두 배
Docker 다중 컨테이너	컨테이너마다 하나의 버전	완전 격리	가장 안정적이지만 설정이 복잡

방식 1: Tag로 버전 구분

가장 간단한 방법입니다. Ollama는 모델에 tag를 붙일 수 있으므로 tag로 서로 다른 버전을 구분할 수 있습니다.

# 모델의 서로 다른 버전 생성(tag로 구분)
ollama create myproject-llama3.2:v1.0 -f Modelfile-v1.0
ollama create myproject-llama3.2:v2.0 -f Modelfile-v2.0

# 모든 버전 확인
ollama list
# 출력 예:
# myproject-llama3.2:v1.0    4.7 GB   2026-05-10
# myproject-llama3.2:v2.0    4.7 GB   2026-05-14

# 특정 버전 실행
ollama run myproject-llama3.2:v1.0 "프롬프트 입력"
ollama run myproject-llama3.2:v2.0 "프롬프트 입력"

다만 함정이 하나 있습니다. 동시에 하나의 버전만 로드할 수 있습니다. 여러 버전을 병렬로 실행해야 한다면 뒤의 방식을 사용해야 합니다.

방식 2: 다중 인스턴스 배포(서로 다른 포트)

이 방법은 여러 모델을 동시에 실행해야 할 때 적합합니다. 각 인스턴스가 다른 포트를 사용합니다.

# 첫 번째 인스턴스 시작(기본 포트 11434)
ollama serve

# 두 번째 인스턴스 시작(포트 11435)
OLLAMA_HOST=0.0.0.0:11435 ollama serve &
# 이 프로세스는 포트 11435에서 독립 실행됨

# 두 인스턴스 테스트
curl http://localhost:11434/api/version  # 첫 번째
curl http://localhost:11435/api/version  # 두 번째

# API 사용 시 포트 지정
curl http://localhost:11435/api/generate \
  -d '{"model":"llama3.2","prompt":"test"}'

다중 인스턴스의 장점은 유연성입니다. 하지만 리소스 사용량이 두 배로 늘어납니다. 각 인스턴스가 모델을 메모리에 올려야 하므로, 모델이 크다면(예: 수십 GB) 메모리 압박이 큽니다. 관리도 조금 번거롭습니다. 어떤 포트가 어떤 버전에 대응하는지 직접 기억해야 합니다.

방식 3: Docker 다중 컨테이너 배포(가장 안정적)

진짜 다중 버전 격리가 필요하다면 Docker가 가장 믿을 만합니다. 컨테이너마다 하나의 버전을 두고 완전히 독립적으로 운영합니다.

# docker-compose.yml
version: '3'
services:
  ollama-stable:
    image: ollama/ollama:0.1.30
    container_name: ollama-stable
    volumes:
      - ./data-stable:/root/.ollama
    ports:
      - "11434:11434"

  ollama-dev:
    image: ollama/ollama:0.6.8
    container_name: ollama-dev
    volumes:
      - ./data-dev:/root/.ollama
    ports:
      - "11435:11434"  # 호스트의 11435로 매핑

배포 방식은 다음과 같습니다.

# 모든 컨테이너 시작
docker-compose up -d

# 컨테이너 상태 확인
docker-compose ps

# 두 버전 테스트
curl http://localhost:11434/api/version  # 안정 버전 (0.1.30)
curl http://localhost:11435/api/version  # 개발 버전 (0.6.8)

각 컨테이너는 자체 데이터 디렉터리(data-stable, data-dev)를 가지므로 모델이 서로 간섭하지 않습니다. 한 컨테이너에는 llama3.2를 설치하고, 다른 컨테이너에는 mistral을 설치해 동시에 실행할 수 있으며 충돌하지 않습니다.

버전 관리 전략: 명명, 고정, 정리

다중 버전 공존을 시작하면 관리 전략이 중요해집니다. 그렇지 않으면 모델이 점점 늘어나 디스크가 금방 가득 찹니다.

명명 규칙: 버전을 명확히 구분하는 이름을 사용합니다.

# 권장: 프로젝트명+모델명+버전 번호
myproject-llama3.2:prod-v1.0
myproject-llama3.2:dev-v2.0
myproject-mistral:test-v0.1

# 비권장: 모호한 이름
test-model-1
test-model-2

버전 고정: 예기치 않은 업그레이드를 방지합니다.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: latest 대신 버전 태그 사용
image: ollama/ollama:0.1.30  # 버전 고정
# image: ollama/ollama:latest 사용 금지

정기 정리: 사용하지 않는 버전을 삭제합니다.

# 모든 모델 확인
ollama list

# 오래된 버전 일괄 삭제(예시)
ollama rm myproject-llama3.2:test-v0.5
ollama rm myproject-llama3.2:dev-v1.2

# 또는 스크립트로 일괄 정리
for model in $(ollama list | grep "test-" | awk '{print $1}'); do
  ollama rm $model
done

GitHub Issue 분석: 공식 제한과 사용자 방식

이 요구는 커뮤니티에서 많이 논의되었습니다. GitHub Issue #2109와 #11196 모두 Ollama가 기본적으로 다중 버전 공존을 지원하지 않는다고 언급합니다.

공식 입장은 이렇습니다. 단일 Ollama 프로세스는 하나의 모델 인스턴스만 로드할 수 있습니다. 여러 버전이 필요하다면 tag로 구분하거나(방식 1), 여러 프로세스 또는 컨테이너를 실행해야 합니다(방식 2와 3).

댓글 중 한 사용자의 말이 꽤 적절했습니다. “공식 제한 때문에 다중 버전 관리는 복잡해졌지만, 커뮤니티의 workaround는 꽤 실용적입니다. Docker 다중 컨테이너가 가장 안정적인 방식입니다. 설정은 조금 더 많지만 진짜 격리를 제공합니다.”

저도 세 가지 방식을 모두 테스트해 봤고, Docker 다중 컨테이너가 확실히 가장 마음 편했습니다. 설정을 몇 줄 더 써야 하지만 격리성과 안정성이 가장 좋습니다. 운영 환경이라면 이 방식을 강력히 권장합니다.

문제 해결과 모범 사례

롤백 과정에서 제가 한 번 이상 겪은 함정이 있습니다. 여기서는 빠르게 문제를 찾을 수 있도록 문제 해결 매뉴얼을 정리했습니다.

자주 만나는 문제 해결

권한 문제

가장 흔한 함정입니다. 바이너리를 교체한 뒤 실행 권한을 주는 것을 잊는 경우입니다.

# 증상: ollama 실행 시 "Permission denied" 오류
# 해결:
sudo chmod +x /usr/local/bin/ollama

# 디렉터리 권한에 문제가 있는 경우
sudo chown -R $(whoami) ~/.ollama

저도 첫 롤백 때 여기서 막혔습니다. 파일은 분명히 교체했는데 실행할 때 계속 권한 오류가 났습니다. 나중에야 curl로 받은 파일에 기본 실행 권한이 없다는 것을 알았습니다.

서비스 시작 실패

롤백 후 서비스가 시작되지 않는다면 보통 포트가 점유되어 있거나 남은 프로세스가 있기 때문입니다.

# 증상: ollama serve 실행 시 "Address already in use" 오류
# 포트 점유 확인
lsof -i :11434

# 점유 프로세스 종료
kill -9 <PID>

# 또는 서비스 재시작
sudo systemctl restart ollama  # Linux

한 번은 롤백 후 서비스를 시작했는데 포트가 계속 점유되어 있었습니다. 확인해 보니 기존 프로세스가 백그라운드에서 완전히 종료되지 않고 남아 있었습니다. pkill -9 ollama로 강제 종료한 뒤에야 정상 시작되었습니다.

모델 로딩 오류

롤백 후 특정 모델이 로딩에 실패할 수 있습니다. 원인은 모델 파일 손상이나 버전 비호환일 수 있습니다.

# 증상: ollama run model-name 실행 시 오류
# 모델 상태 확인
ollama show model-name

# 강제로 다시 가져오기
ollama pull model-name --force

# 그래도 안 되면 삭제 후 다시 가져오기
ollama rm model-name
ollama pull model-name

한 번은 롤백 후 어떤 모델이 계속 로딩에 실패했습니다. 나중에 보니 롤백 과정에서 모델 파일이 예기치 않게 변경되어 있었습니다. 다시 가져온 뒤에야 정상화되었습니다. 그래서 롤백 전 ~/.ollama 디렉터리를 백업하는 것이 정말 중요합니다.

설정 충돌

때로는 구버전 설정이 새로운 모델과 호환되지 않습니다.

# 증상: 추론 결과 이상 또는 서비스 크래시
# 설정 초기화
rm ~/.ollama/ollama.db  # 설정 데이터베이스 삭제
ollama serve  # 다시 시작하면 설정이 재생성됨

# 모델 수동 복구
ollama pull model-name

이 문제는 비교적 숨어 있습니다. 어떤 사용자는 롤백 후 설정 파일에 새 버전의 매개변수가 남아 있고, 구버전이 이를 해석하지 못해 서비스가 크래시된다고 했습니다. 설정 데이터베이스를 삭제하고 다시 생성하니 문제가 해결되었습니다.

모범 사례: 함정을 피하는 네 가지 원칙

여러 문제를 겪으면서 제가 정리한 모범 사례입니다. 그대로 따르면 대부분의 문제를 피할 수 있습니다.

원칙 1: 버전 고정 전략

업그레이드하기 전에 현재 버전을 먼저 고정하세요. 업그레이드에 문제가 생겼을 때 적어도 어느 버전으로 돌아가야 하는지 알 수 있습니다.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: 버전 태그 사용
image: ollama/ollama:0.1.30

원칙 2: 운영 전 테스트

운영 환경에서 롤백하기 전에는 개발 환경에서 먼저 한 번 테스트하세요. 건강 검사 스크립트로 흐름에 문제가 없는지 확인합니다.

# 개발 환경에서 롤백 흐름 테스트
./ollama-rollback.sh 0.1.30

# 건강 검사
./health-check.sh

# 성능 비교
./performance-check.sh

원칙 3: 롤백 문서 기록

롤백할 때마다 원인, 버전, 결과를 기록합니다. 나중에 문제를 추적할 때 도움이 됩니다.

# 롤백 정보 기록
echo "롤백 기록: $(date) - 0.6.8에서 0.1.30으로 롤백, 원인: 성능 저하" >> ~/.ollama-rollback-log.txt

# 상세 기록
cat >> ~/.ollama-rollback-log.txt << EOF
날짜: 2026-05-14
원래 버전: 0.6.8
대상 버전: 0.1.30
원인: 업그레이드 후 API 응답 시간이 200ms에서 5000ms로 증가
결과: 성공, 응답이 200ms로 회복
비고: 백업 파일 ~/.ollama-backups/ollama-backup-20260514
EOF

원칙 4: 정기 백업

~/.ollama 디렉터리, 특히 모델 파일은 정기적으로 백업하세요. 이 디렉터리는 클 수 있지만 정말 중요합니다.

# 간단 백업(설정만 백업)
cp ~/.ollama/ollama.db ~/.ollama-backup.db

# 전체 백업(모델 포함, 충분한 공간 필요)
tar -czf ~/.ollama-backup-$(date +%Y%m%d).tar.gz ~/.ollama

# 오래된 백업 정기 정리(최근 5개만 보관)
ls -t ~/.ollama-backup-*.tar.gz | tail -n +6 | xargs rm -f

추천 도구: 세 가지 스크립트로 관리 자동화

앞에서 언급한 세 가지 스크립트는 모두 정리해 두었습니다.

• ollama-rollback.sh: 원클릭 롤백, 실패 시 자동 복구
• health-check.sh: 네 가지 차원의 건강 검사
• cleanup_models.sh: 오래된 모델 일괄 정리(Part 2에서 사용)

이 스크립트들이 있으면 버전 관리는 거의 자동화할 수 있습니다. 중요한 순간에 한 번의 명령으로 롤백할 수 있어 당황하지 않아도 됩니다.

정리

길게 이야기했지만 핵심은 세 단계입니다. 백업, 롤백, 검증입니다.

백업은 첫 단계이자 가장 쉽게 무시되는 단계입니다. 롤백 전 ~/.ollama 디렉터리를 백업하는 것은 정말 도움이 됩니다. 저는 한 번 백업 없이 진행했다가 롤백 실패 후 하루 종일 다시 설정해야 했습니다.

어떤 롤백 방식을 선택할지는 배포 방식에 달려 있습니다. Docker 사용자는 이미지 버전만 바꾸면 되어 가장 편합니다. 수동 설치 사용자는 바이너리 교체로 빠르게 처리할 수 있습니다. 중요한 것은 자신에게 맞는 방법을 고르고, 절차를 차근차근 따르는 것입니다.

검증은 생략하면 안 됩니다. 롤백 후 건강 검사 스크립트를 실행해 버전, 서비스, API, 모델이 모두 정상인지 확인하세요. 버전 번호만 맞다고 성공이라고 믿으면 안 됩니다. 저는 이 함정도 겪어 봤습니다.

지금 바로 할 수 있는 세 가지 일:

1. 롤백 흐름을 즉시 테스트하세요. 개발 환경에서 한 번 직접 해 보며 전체 절차에 익숙해지세요. 스크립트를 내려받고 건강 검사를 한 번 실행해 보세요. 실제 문제가 터진 뒤에 당황하지 않기 위해서입니다.

2. 세 가지 스크립트를 저장해 두세요. ollama-rollback.sh, health-check.sh, performance-check.sh입니다. 중요한 순간에 문제를 빠르게 찾고, 긴 시간을 들여 헤매는 일을 줄여 줍니다.

3. 안정 버전을 고정하세요. 지금 쓰는 버전이 안정적이라면 바로 고정하세요. brew pin, apt-mark hold, Docker version tag 중 자신의 환경에 맞는 방법을 고르면 됩니다. 예기치 않은 업그레이드가 시스템을 흔들지 않게 하세요.

버전 관리는 평소에는 중요하지 않아 보이지만, 문제가 생기는 순간 프로젝트 전체를 멈출 수 있습니다. 이 절차를 익혀 두면 문제가 발생했을 때 적어도 당황하지 않고 대응할 수 있습니다.

이 글은 Ollama 로컬 LLM 실전 가이드 시리즈의 Part 3입니다. Part 1에서는 기본 입문을 다뤘고, Part 2에서는 모델 관리의 기초를 정리했습니다. 이번 글에서는 버전 롤백과 다중 버전 공존을 깊게 살펴봤습니다. 다음 Part 4에서는 Modelfile 매개변수 튜닝, 즉 모델을 더 빠르고 안정적이며 비용 효율적으로 실행하는 방법을 다룹니다.

이 글이 도움이 되었다면 저장하거나 공유해 주세요. 궁금한 점이 있으면 댓글로 남겨 주시면 가능한 한 답변하겠습니다.