판단: 업그레이드할 수 있지만, 이미지만 바꾸고 끝내면 안 됩니다. 먼저 데이터베이스를 백업하고 변경 사항을 확인하세요. 여러 인스턴스나 Worker를 운영한다면 공식 안내에 따라 모두 동기화해 업데이트한 뒤 기능을 검증해야 합니다.
이 글은 단일 인스턴스를 관리하며 백업과 업데이트 순서를 확인하려는 개발자를 위한 안내입니다.
여러 인스턴스나 Worker를 운영한다면 버전 동기화와 작업 일정을 먼저 정리하세요.
도구나 하위 에이전트를 사용하는 팀은 새 버전의 기본 동작이 업무 절차에 미치는 영향도 살펴봐야 합니다.
마지막 업데이트: 2026년 11월 7일. Open WebUI 공식 릴리스 기록과 업데이트 안내를 기준으로 확인했습니다. (릴리스 기록, 공식 업데이트 안내)
업그레이드 전: 이미지 교체와 변경 영향 확인
Open WebUI v0.13.0은 2026년 11월 3일 공개됐으며, 공식 안내에 따르면 데이터베이스 이전이 포함됩니다. 따라서 기존 이미지 태그를 새 버전으로 바꾸는 것만으로 완료 처리하지 마세요. 먼저 현재 버전, 배포 방식, 인스턴스 수, Worker 구성을 확인한 다음 공식 릴리스 기록과 버전별 변경 안내를 대조해야 합니다.
Open WebUI 0.13.0 업그레이드에서 먼저 확인할 항목은 무엇인가요?
현재 실행 중인 이미지 태그와 서비스 구성을 기록하고, 데이터베이스와 설정이 어디에 저장되는지 확인하세요. Docker Compose를 쓴다면 docker compose config로 적용될 설정을 확인할 수 있습니다. 이 명령은 설정 확인용이지 백업이나 업그레이드 명령은 아닙니다. 사용법은 Docker Compose 설정 확인 문서를 참고하세요. 출력에 비밀 값이 들어갈 수 있으므로 공유하거나 저장할 때 민감 정보를 가려야 합니다.
버전 안내에는 컨트롤 버튼 위치, 도구 호출 라운드 제한, 하위 에이전트 제한의 기본 동작 변경이 포함됩니다. 팀에서 실제로 쓰는 기능에 해당하는 항목을 사전 확인 목록에 넣으세요. 이전 버전의 동작이 새 버전에서도 그대로 유지된다고 가정하지 않는 편이 안전합니다.
실행 준비: 백업본과 되돌림 기준
업그레이드 전에 무엇을 백업해야 하나요?
설치마다 데이터 경로가 같다고 가정하지 마세요. 배포 설정을 확인해 실제 데이터베이스, 영속 볼륨이나 데이터 디렉터리, 환경 설정 파일을 식별한 뒤 해당 항목을 보호해야 합니다. 공식 데이터베이스 이전 문제 해결 안내를 참고하되, 안내된 경로를 자신의 배포에 그대로 대입하지 말고 현재 설정과 비교하세요.
백업 파일이 존재하는지만 확인하지 말고, 내용을 읽을 수 있는지와 복구에 필요한 설정을 함께 보관했는지도 살펴보세요. 업데이트 전에 다음 사항을 기록하면 변경 전후 비교와 복구 판단에 도움이 됩니다.
- 현재 이미지 태그와 배포 방식
- 주요 환경 변수와 설정 파일의 위치
- 실행 중인 서비스와 인스턴스 구성
- 백업한 데이터베이스와 영속 데이터의 위치
- 문제가 생겼을 때 복원할 백업, 이미지 태그, 설정
데이터베이스 이전이 시작된 뒤에는 이미지 태그만 이전 것으로 되돌려도 안전한 복구가 보장되지 않습니다. 중단이 필요하면 변경 범위를 더 넓히지 말고, 백업과 이전 이미지 및 설정을 함께 복원하는 절차를 따르세요. 별도의 스냅샷이나 백업 서비스를 전제로 삼지 말고 직접 준비한 복구 계획을 확인해야 합니다.
업데이트 진행: 단일 인스턴스와 여러 인스턴스
여러 인스턴스는 따로 업데이트해도 되나요?
공식 업데이트 안내는 여러 인스턴스와 Worker를 사용하는 배포에서 모든 인스턴스를 동기화해 업데이트하도록 요구합니다. 새 버전과 기존 버전이 동시에 요청을 처리하지 않도록 작업 순서를 조정하세요. 자신의 배포 형태에 맞는 세부 조건은 공식 확장 안내와 업데이트 지침에서 확인해야 합니다.
업데이트 여부와 순서는 아래 항목을 확인해 결정하세요.
- [ ] 단일 인스턴스이고 백업을 읽을 수 있으며 복구 절차도 확인했습니다. 해당 배포 방식에 맞는 공식 절차로 업데이트하고 검증 단계로 진행합니다.
- [ ] 여러 인스턴스나 Worker를 운영합니다. 모든 인스턴스를 같은 업데이트 작업에 포함하고 버전이 일치하는지 확인한 뒤 서비스를 다시 엽니다.
- [ ] 백업을 읽을 수 없거나 복구 방법이 불명확합니다. 업데이트를 미루고 백업과 복구 절차부터 점검합니다.
- [ ] 팀에서 도구 호출이나 하위 에이전트를 쓰지만 변경 동작을 확인하지 못했습니다. 운영 전환을 보류하고 실제 업무 흐름으로 시험합니다.
배포 방식에 따라 업데이트 절차가 다르므로 확인되지 않은 공통 명령을 그대로 실행하지 마세요. Docker 방식인지 Python 방식인지 먼저 확인하고, 그에 해당하는 공식 안내를 따르세요. Docker Compose를 쓴다면 적용 설정과 기존 서비스 상태를 확인한 후 공식 절차에 따라 업데이트합니다.
docker compose ps
docker compose logs <서비스명>
위 명령은 상태와 로그를 확인하는 예시입니다. 서비스 이름이나 배포 도구가 다르면 그대로 사용할 수 없습니다. 업데이트 중에는 로그에서 데이터베이스 이전 결과와 시작 오류를 확인하세요. 이상이 보이면 추가 인스턴스까지 변경을 확대하지 말고 멈춰야 합니다.
완료 판정: 화면 표시와 핵심 작업 검증
Open WebUI 0.13.0 업그레이드 후 도구 호출은 어떻게 달라지나요?
공식 버전 안내에는 도구 호출의 라운드 제한과 하위 에이전트 제한의 기본 동작 변경이 포함됩니다. 해당 기능을 쓰는 팀은 실제 설정으로 시험하고, 기존 업무 안내나 운영 문서를 수정해야 하는지 판단하세요. 이는 해당 버전의 변경 사항이며 모든 버전에서 고정된 동작이라는 뜻은 아닙니다. (공식 버전 안내)
화면이 열리는 것만으로 업그레이드가 끝난 것은 아닙니다. 실제 계정과 업무 흐름으로 다음 항목을 확인하고 업데이트 전 기록과 비교하세요.
- 모든 인스턴스가 의도한 버전으로 실행되는지
- 데이터베이스 이전이 완료됐고 시작 로그에 오류가 없는지
- 계정 로그인이 되고 이전 대화와 설정을 확인할 수 있는지
- 팀에서 쓰는 지식베이스와 모델 연결이 작동하는지
- 도구 호출이나 하위 에이전트를 쓴다면 실제 작업이 완료되는지
사용하지 않는 기능까지 무조건 시험할 필요는 없습니다. 다만 팀이 쓰는 기능을 확인하지 않은 채 운영 전환을 승인해서는 안 됩니다. 이전 데이터나 설정이 보이지 않으면 새 작업을 이어가기보다 로그와 백업 상태부터 확인하세요.
운영 환경 판단: 앱 서비스와 모델 추론 분리
업데이트 후 서버를 바꿀지는 실제 사용량과 관측 결과를 기준으로 판단하세요. Open WebUI 앱 서비스의 CPU, 메모리, 저장 공간 요구와 모델 추론 서비스의 요구는 구분해야 합니다. 모델을 같은 서버에서 실행하는지 외부 API로 연결하는지에 따라서도 부하가 달라집니다.
- 자원 여유가 확인되고 서비스가 안정적이면 현재 구성을 유지하면서 사용량을 관찰합니다.
- 로그와 모니터링에서 메모리나 저장 공간 부족이 확인되면 데이터베이스와 영속 데이터의 증가량을 함께 살펴본 뒤 조정이나 이전을 검토합니다.
- 추론 작업이 앱 서비스와 자원을 다투면 두 역할을 분리할 필요가 있는지 검토합니다. 앱 서버만으로 대형 모델 추론 성능을 보장할 수는 없습니다.
- 성능 기준이 없다면 근거 없는 최소 사양이나 처리량을 정하지 말고 업데이트 전후의 실제 측정치를 먼저 확보합니다.
자체 호스팅 서버의 메모리와 저장 공간을 검토할 때는 서버 메모리와 디스크 선택 기준을 참고할 수 있습니다. 직접 서버에 접속해 운영한다면 SSH 접속 안내에서 접속 방식을 확인하세요. 이 자료는 특정 자원 요구량이나 성능을 보장하는 근거가 아니라 현재 구성과 선택지를 살펴보기 위한 참고 자료입니다.
업그레이드 검증 후에도 공유 가상 서버에서 CPU 경합이나 자원 변동이 반복된다면 독립형 서버를 검토할 수 있습니다. 반대로 잠깐 시험하는 작업이나 부하가 매우 가벼운 서비스라면 물리 서버 임대가 적합하지 않을 수 있습니다. 장기간 운영하며 전용 자원이 필요하다면 OSFP Cloud의 현재 서버 구성과 제공 범위를 실제 제품 정보와 대조하세요. GPU 추론을 전제로 하지 말고, 앱 서버와 모델 실행 환경을 나눠 요구 사항을 판단하는 편이 정확합니다.
업그레이드 환경을 안정적으로 운영할 전용 서버를 준비하세요
OSFP Cloud는 일본 도쿄에 있는 물리 서버 한 대를 통째로 제공해 다른 계정과 자원을 나누지 않습니다.
$462 / 월부터