Sentry 자체 호스팅 대안 및 리소스 비교

자체 호스팅 오류 추적 도구가 이벤트를 하나도 저장하기 전에 발생하는 비용

자체 호스팅 오류 추적 도구의 선택을 결정짓는 단 하나의 수치는 바로 최소 RAM 요구량입니다. Sentry의 자체 호스팅 공식 문서에서는 애플리케이션이 단 하나의 이벤트도 전송하기 전에 4개의 CPU 코어, 16 GB의 RAM과 16 GB의 스왑, 그리고 20 GB의 여유 디스크 공간을 요구합니다. 반면 GlitchTip은 512 MB를 요구합니다. 여기에 나열된 모든 옵션은 동일한 Sentry SDK로부터 이벤트를 수신하므로, 이는 코드 계측 방식을 결정하는 문제가 아닙니다. 이는 여러분이 비용을 지불하고 유지할 서버의 규모를 결정하는 문제입니다.

공개된 리소스 수치 비교

각 프로젝트가 2026년 8월 기준으로 직접 공개한 수치입니다. 측정 기준이 서로 다르므로 비교하기 전에 각 행의 주석을 확인하십시오.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Sentry의 16 GB는 문서화된 최소 사양이며, 동일한 페이지에서 32 GB를 권장합니다. GlitchTip의 0.5 GB는 권장 사양이며, 프로젝트 측은 작동을 위한 최소 사양으로 256 MB를, 신중하게 설정할 경우 128 MB와 스왑(swap) 사용을 명시하고 있습니다. Bugsink의 4 GB는 위 두 경우와 다릅니다. 이는 벤더가 자체 처리량 벤치마크를 수행할 때 사용한 장비의 사양입니다. 공개된 수치는 시작점일 뿐이며, 사용자의 이벤트 처리량을 보장하는 수치가 아닙니다.

Sentry self-hosted: 전체 제품과 전체 비용

공식 스택은 getsentry/self-hosted이며, Sentry가 운영 환경에서 사용하는 것과 동일한 구성 요소를 실행하는 Docker Compose 프로젝트입니다. 자체 문서에서는 이를 "기능이 완벽하게 갖춰져 있으며 소규모 배포 및 개념 증명(PoC)을 위해 패키징됨"이라고 설명합니다. 이 문장이 솔직한 요약입니다. 모든 기능을 얻게 되지만, 그 기능을 작동하게 만드는 모든 움직이는 부품도 함께 떠안아야 합니다.

master 대신 태그가 지정된 릴리스에서 설치하십시오:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

그런 다음 시작하십시오:

docker compose up --wait

Sentry는 기본적으로 http://127.0.0.1:9000에서 수신 대기합니다. Docker Engine 19.03.6 이상과 Docker Compose 2.32.2 이상이 필요하며, 이전 버전의 Compose를 사용하면 Sentry의 문제라기보다 파일 구문 문제로 인해 실패합니다.

실제로 무엇을 시작했는지 확인하십시오:

docker compose ps
free -h

docker compose ps은 스택의 모든 서비스를 나열하며, 그 목록은 깁니다: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator 및 여러 worker와 cron 프로세스가 포함됩니다. 이 숫자가 곧 유지보수 부담이므로 한 번 세어 보십시오. 각 항목은 충돌하거나, 디스크를 가득 채우거나, 마이그레이션에 실패할 수 있는 프로세스입니다.

서비스가 Restarting 상태에 머물러 있다면, 다른 무엇보다 먼저 메모리를 확인하십시오:

dmesg -T | grep -i 'out of memory'

Out of memory: Killed process 3412 (java)과 같은 줄은 서버의 RAM이 부족하여 커널의 OOM killer(out of memory killer)가 컨테이너를 종료했음을 의미합니다. 따라서 해당 서비스는 정상 상태가 되지 못하고 스택은 시작을 완료하지 못합니다. 이는 문서화된 최소 사양 미만에서 전체 스택을 실행할 때 발생하는 일반적인 결과입니다. 문서는 디스크 속도도 경고합니다. iowait가 10%를 넘으면 시스템이 수집 파이프라인을 따라가지 못한다는 뜻입니다. top의 wa 열에서 확인하거나, sysstat이 설치되어 있다면 iostat -x 5에서 확인하십시오.

업그레이드는 사람들이 과소평가하는 부분입니다

Sentry self-hosted는 매월 15일에 주요 릴리스가 나오는 CalVer(날짜 기반 버전 체계)를 따릅니다. 이전 버전에서 최신 버전으로 바로 건너뛸 수는 없습니다. 프로젝트는 하드 스톱(hard stop) 버전을 정의하며, 데이터베이스 마이그레이션을 적용하려면 각 버전을 순서대로 체크아웃해야 합니다. 2026년 8월 기준으로 발표된 하드 스톱 버전은 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 및 26.7.0입니다. 또한 문서는 23.7.0, 25.9.0, 25.12.0 및 26.3.0에서 26.4.0 범위와 같이 마이그레이션 문제로 인해 건너뛰어야 할 릴리스를 나열합니다.

업그레이드는 체크아웃 후 설치 프로그램을 다시 실행하는 과정입니다:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

시작하기 전에 서버 스냅샷을 생성하십시오. 대규모 ClickHouse 데이터셋에 대한 마이그레이션은 몇 시간 동안 실행될 수 있으며, 중간에 실패하면 데이터베이스가 두 스키마 사이의 상태로 남기 때문입니다. 대부분의 self-hosted Sentry 업그레이드 실패 원인은 단순합니다. 서버를 1년 동안 한 버전에만 방치하여 여러 하드 스톱을 한 번에 건너뛰게 되었고, 건너뛴 마이그레이션 중 중요한 것이 포함되어 있었기 때문입니다.

커밋하기 전에 알아야 할 한 가지가 더 있습니다. Sentry self-hosted는 Sentry가 직접 도입한 FSL(Functional Source License)을 따릅니다. 이는 OSI 승인 오픈 소스가 아닌 페어 소스(fair source)입니다. 즉, 직접 실행할 수는 있지만 경쟁 서비스로 판매할 수는 없습니다. 각 릴리스는 출시 2년 후 Apache 2.0으로 전환됩니다.

GlitchTip: 512 MB 환경 구성

GlitchTip은 MIT 라이선스를 따르며 Sentry의 오픈 소스 SDK로부터 이벤트를 수신합니다. 따라서 계측된 애플리케이션은 DSN(데이터 소스 이름, SDK가 이벤트를 전송하는 URL) 값 하나만 변경하면 즉시 전환할 수 있습니다. PostgreSQL 14 이상 버전이 필요합니다. Valkey 또는 Redis 7 이상 버전은 선택 사항이지만, 대규모 인스턴스 운영 시 성능을 향상시킵니다.

설치는 Docker와 하나의 compose 파일을 사용합니다.

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

시작하기 전에 environment 섹션을 수정하십시오. 반드시 설정해야 할 값은 secret, domain, mail 경로입니다.

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

샘플 파일은 이미 DATABASE_URL를 자체 postgres 서비스에 연결하고 있으므로, 외부에서 운영 중인 데이터베이스를 사용하지 않는다면 해당 줄은 그대로 두십시오. GLITCHTIP_DOMAIN에는 스킴(scheme)이 포함되어야 합니다. 앞에 https://이 없으면 알림 이메일의 링크가 잘못 생성되어 응답하지 않는 URL로 연결됩니다.

서비스를 시작하고 첫 부팅 과정을 확인하십시오.

docker compose up -d
docker compose logs -f web

2026년 8월 기준 샘플의 이미지 태그는 postgres:18, valkey/valkey:9, glitchtip/glitchtip:6입니다. 이 버전을 고정하여 사용하십시오. latest로 설정된 compose 파일은 다음 docker compose pull 시점에 데이터베이스 엔진을 업그레이드합니다. 실행 중인 인스턴스에서 Postgres 메이저 버전이 갑자기 변경되면 정상 작동하던 오류 추적기가 실행되지 않을 수 있습니다.

메모리 사용량을 256 MB에서 512 MB 범위로 유지하려면 샘플 파일의 주석에 따라 Valkey를 끄고 선택적인 로그 및 가동 시간(uptime) 기능을 비활성화하십시오. Valkey 없이 실행하면 GlitchTip은 캐시와 큐 작업을 위해 데이터베이스를 대신 사용하게 되며, 속도는 다소 느려지지만 기능은 정상적으로 작동합니다. All in one 모드로 설정하면 웹 프로세스 내부에서 워커가 실행되므로, 두 개의 컨테이너 대신 하나의 애플리케이션 컨테이너만 관리하면 됩니다.

앞단에 프록시를 배치하십시오. GlitchTip 문서에서는 요청을 버퍼링하고 청크 단위의 Transfer-Encoding를 처리할 수 있는 프록시나 로드 밸런서를 권장하며, 예시로 nginx를 제시합니다. 버퍼링을 사용하지 않으면 느린 클라이언트가 업로드되는 동안 애플리케이션 워커를 계속 점유하게 됩니다. 이로 인해 몇몇 느린 전송자가 모든 워커를 차지하여 정상적인 클라이언트의 요청이 타임아웃될 수 있습니다.

업그레이드는 간단합니다.

docker compose pull
docker compose stop
docker compose up -d

데이터베이스 마이그레이션은 시작 시 자동으로 실행됩니다. 하지만 자동 마이그레이션 역시 데이터 변경을 수반하므로, 반드시 사전에 덤프를 생성해 두십시오.

Bugsink: 컨테이너 하나와 반드시 읽어야 할 라이선스

Bugsink는 세 가지 도구 중 가장 가볍습니다. Sentry SDK 프로토콜을 지원하며, 메시지 큐나 데이터베이스 외의 외부 서비스 없이 실행됩니다. 기본값은 SQLite이며, 규모가 커지면 MySQL이나 PostgreSQL을 사용할 수 있습니다.

도입을 결정하기 전 인터페이스를 확인하기 위한 일회성 인스턴스 실행 방법입니다.

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

http://localhost:8000/를 열고 CREATE_SUPERUSER에서 전달한 주소와 비밀번호로 로그인합니다. 이 컨테이너는 중지되면 모든 데이터를 삭제합니다. 실제 운영 환경을 위해서는 프로젝트의 compose 샘플을 사용하십시오. 이 샘플은 bugsink/bugsink:2과 postgres:17-alpine을 연결하며 DATABASE_URL, BASE_URL, BEHIND_HTTPS_PROXY을 설정합니다. 비밀 키는 다음과 같이 올바르게 생성하십시오.

openssl rand -base64 50

BASE_URL은 스킴을 포함하여 사용자와 SDK가 실제로 접근하는 URL과 일치해야 합니다. https://errors.example.com으로 접속하는 서버에서 이를 http://localhost:8000로 두면, 알림 이메일의 모든 링크가 접속 불가능한 호스트를 가리키게 됩니다. Nginx나 Caddy가 앞단에서 TLS(전송 계층 보안)를 종료하는 경우 BEHIND_HTTPS_PROXY를 true로 설정하십시오. 그렇지 않으면 Bugsink가 https:// 프록시 뒤에서 http:// URL을 생성하게 되어 브라우저가 혼합 콘텐츠(mixed content)를 차단합니다.

제조사는 2 vCPU 및 4 GB RAM을 갖춘 VPS에서 50 KB 크기의 이벤트를 초당 18개, 즉 하루 150만 개까지 처리할 수 있다고 밝히고 있습니다. 이는 보장된 성능 수치가 아니라 도구의 대략적인 처리 능력을 나타내는 지표로 이해해야 합니다. 다만, 일반적인 소규모 애플리케이션이 생성하는 로그량보다는 훨씬 높은 처리 한계를 가지고 있음을 의미합니다.

이제 라이선스에 관한 내용입니다. 스택에 도입하기 전에 반드시 읽어보아야 합니다. Bugsink는 PolyForm Shield License 1.0.0을 따릅니다. 이는 오픈 소스가 아닌 소스 공개(source available) 라이선스입니다. 소프트웨어를 실행하고 수정할 수는 있으나, Bugsink와 경쟁하는 제품을 만드는 데 사용할 수는 없습니다. 사내용 오류 추적 도구로 사용하는 경우에는 이러한 제한 사항이 문제가 되지 않습니다. 만약 귀사가 개발자 도구를 판매하는 기업이라면, 도입 전 반드시 라이선스 전문을 검토하십시오.

에러 추적과 LLM 관측 가능성은 여전히 별개의 도구입니다

에러 추적과 대규모 언어 모델(LLM) 관측 가능성을 모두 제공한다고 주장하는 제품을 찾을 수는 있지만, 두 영역의 데이터 형태가 다르기 때문에 통합은 계속해서 이루어지지 않고 있습니다. 에러 추적기는 스택 트레이스가 포함된 예외를 수신하여 지문을 계산하고, 수천 건의 발생 사례를 하나의 이슈와 카운터로 통합합니다. 반면 LLM 추적 도구는 프롬프트, 응답, 토큰 수, 지연 시간이 포함된 스팬(span)을 수신하며, 동일한 입력값을 가진 두 번의 호출이라도 각각 별개의 이벤트로 읽어야 하므로 모든 데이터를 보존해야 합니다.

따라서 두 도구를 모두 운영하십시오. 예외 사항은 에러 추적기로 보내고, 모델 호출은 이를 위해 설계된 곳으로 보내야 합니다. 에이전트 추적을 위한 자체 호스팅 Langfuse는 해당 영역을 다루며, 자체 호스팅 AI 관측 가능성은 같은 작업을 다른 관점에서 접근합니다. 애플리케이션은 이미 두 가지 유형의 장애를 모두 발생시키고 있습니다. 확신에 찬 헛소리를 반환하는 모델 호출은 예외를 발생시키지 않으므로, 에러 추적기에서는 이를 확인할 수 없습니다.

디스크 용량 증가는 나중에 발견되는 장애입니다

모든 에러 추적기는 쓰기 작업이 빈번하며 입력 데이터가 제한되지 않는 데이터베이스입니다. 애플리케이션이 기록할 데이터의 양을 결정하므로, 자주 호출되는 코드 경로에 버그가 하나만 생겨도 하룻밤 사이에 백만 개의 이벤트가 생성될 수 있습니다.

GlitchTip은 계획 수립에 참고할 만한 수치를 공개합니다. 매달 백만 개의 이벤트를 처리하는 인스턴스는 30 GB의 디스크 공간이 필요할 수 있습니다. 이는 해당 속도로 한 달간 수집된 데이터를 저장하는 용량이며, 보관 기간 설정에 따라 한 번에 저장할 데이터의 개월 수가 결정됩니다.

Bugsink는 반대 방향에서 접근합니다. 고정된 할당량 대신 이벤트 개수와 경과 시간에 따른 보관 알고리즘을 적용하며, 제한 값을 직접 노출합니다. 전체 설치 환경에 대해서는 MAX_RETENTION_EVENT_COUNT, 프로젝트별로는 MAX_RETENTION_PER_PROJECT_EVENT_COUNT, 절대적인 차단 값으로는 MAX_EVENT_AGE_DAYS을 사용합니다. 설치 전체에 대한 이벤트 예산을 설정하는 것이 디스크 크기를 결정하는 정직한 방법입니다. 그 예산 자체가 곧 디스크 용량이기 때문입니다.

서버의 실제 수치를 모니터링하십시오.

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v은 볼륨별 크기를 출력하므로 어떤 서비스가 용량을 차지하고 있는지 확인할 수 있습니다. 트래픽 변화가 없는데도 매주 수 기가바이트씩 볼륨이 증가한다면, 보관 정책이 설정되지 않아 데이터가 삭제되지 않고 파티션이 찰 때까지 계속 쌓이고 있을 가능성이 큽니다.

메모리 문제도 형태만 다를 뿐 동일합니다. 제한이 없는 스택은 커널이 허용하는 모든 자원을 점유합니다. 시스템 메모리가 고갈되면 OOM killer는 가장 큰 프로세스를 종료하는데, 이때 원인이 된 추적기가 아니라 웹 서버가 종료될 수 있습니다. 모든 서비스에 상한선을 두십시오. Docker Compose의 메모리 제한 문서에서 구문과 컨테이너가 제한에 도달했을 때의 동작을 확인할 수 있습니다. 자체 제한으로 종료된 컨테이너는 장애를 격리합니다. 커널에 의해 종료된 컨테이너는 주변 서비스까지 함께 무너뜨립니다.

어떤 스택이 어떤 VPS에 적합한가

• 1 GB 또는 여유가 있는 2 GB: Valkey를 끈 all-in-one 모드의 GlitchTip, 또는 SQLite 기반의 Bugsink가 적합합니다. 두 옵션 모두 소수의 애플리케이션을 운영하기에 충분합니다.
• 4 GB: PostgreSQL 기반의 Bugsink, 또는 Valkey를 켜고 별도의 worker 서비스를 사용하는 GlitchTip이 적합합니다. 이 사양부터는 설정을 최적화할 필요 없이 바로 운영할 수 있습니다.
• 8 GB: 공식 Sentry 스택을 돌리기에는 여전히 부족합니다. 이 사양이라면 선택한 경량 옵션의 데이터 보존 기간을 늘리거나 디스크 용량을 확보하는 데 투자하십시오.
• 최소 16 GB, 권장 32 GB: 공식 Sentry self-hosted 스택을 위한 사양입니다. 경량 프로젝트에서 구현되지 않은 특정 Sentry 기능이 반드시 필요할 때만 선택하십시오. 호환되는 프로젝트들이 일반적인 기능은 대부분 지원하므로, 먼저 각 프로젝트의 문서를 확인하여 필요한 기능이 있는지 대조해 보시기 바랍니다.

어떤 것을 운영하든, 에러 추적기는 자신의 장애를 스스로 보고할 수 없습니다. 다른 장비에서 상태를 확인하십시오. 다른 장비에서 모니터링하는 Uptime Kuma를 사용하면 추적기가 다운되었을 때 즉시 알 수 있습니다. 이는 애플리케이션에서 에러가 발생하기 시작하는데 아무도 기록하지 못하는 상황을 방지하는 데 필수적입니다.

호스팅 플랜이 더 저렴한 선택이 되는 경우

데이터 보존 규정상 자체 호스팅이 필수적이거나, 이벤트 발생량이 많아 이벤트당 과금 방식이 부담스러운 경우에는 에러 트래커를 직접 운영하는 것이 경제적입니다. 그 외의 상황이라면 비용을 정직하게 계산해 보아야 합니다. Sentry가 권장하는 최소 사양은 4코어 CPU와 16 GB RAM, 고속 디스크를 갖춘 서버이며, 이 정도 사양의 VPS는 결코 저렴하지 않습니다. 여기에 운영 비용을 더해야 합니다. 매년 몇 차례씩 진행되는 마이그레이션 과정에서 모든 중단 지점을 순서대로 해결하고, 작업 전마다 스냅샷을 생성하는 수고가 따르기 때문입니다.

GlitchTip과 Bugsink는 이러한 비용 계산을 완전히 바꿉니다. 512 MB에서 4 GB RAM 정도의 저렴한 서버로도 충분히 운영 가능하며, 업그레이드 또한 docker compose pull로 간단하기 때문입니다. 이 질문을 하는 대부분의 사용자가 결국 공식 스택 대신 호환 프로젝트를 선택하는 이유가 바로 여기에 있습니다. 이들은 에러 트래킹 기능을 원할 뿐, 분산 데이터 파이프라인을 관리하며 시간을 쏟고 싶어 하지 않기 때문입니다.

서버에 무엇을 올릴지 아직 고민 중이라면, 직접 호스팅할 가치가 있는 서비스 목록을 통해 에러 트래킹과 동일한 RAM 자원을 두고 경쟁하는 다른 서비스들을 확인해 보시기 바랍니다.

FAQ

2 GB VPS에서 Sentry를 직접 호스팅할 수 있습니까?

아니요. Sentry의 직접 호스팅 문서에 따르면 최소 4개의 CPU 코어, 16 GB의 RAM과 16 GB의 스왑, 그리고 20 GB의 여유 디스크 공간이 필요합니다. 이 스택은 Postgres, ClickHouse, Kafka, Redis 및 여러 워커 프로세스를 동시에 실행하므로, 사양이 낮은 서버에서는 설치가 완료되기 전에 커널이 컨테이너를 강제 종료합니다. dmesg -T | grep -i 'out of memory' 명령을 실행하면 강제 종료된 프로세스 이름이 포함된 줄이 출력되므로 이를 통해 확인할 수 있습니다. 2 GB VPS를 사용 중이라면 512 MB를 요구하는 GlitchTip이나, SQLite 기반의 단일 컨테이너로 실행되는 Bugsink를 사용하십시오.

Sentry에서 GlitchTip이나 Bugsink로 전환하려면 애플리케이션 코드를 수정해야 합니까?

아니요. 두 서비스 모두 Sentry의 오픈 소스 SDK에서 보내는 이벤트를 수용하므로, 이미 설치된 SDK를 그대로 유지하면서 DSN 값 하나만 변경하면 됩니다. DSN은 SDK가 이벤트를 전송하는 URL입니다. 만약 코드에 하드코딩되어 있다면 환경 변수로 옮기고, 새로운 호스트 주소를 가리키도록 설정한 뒤 테스트 예외를 발생시켜 이벤트가 도착하는지 확인하십시오. 아무것도 나타나지 않는다면 DSN의 프로젝트 식별자가 새 서버에 존재하는 프로젝트와 일치하는지, 그리고 방화벽이 해당 호스트와 포트로의 통신을 허용하는지 확인하십시오.

직접 호스팅하는 오류 추적 서비스에는 어느 정도의 디스크 공간이 필요합니까?

이는 도구 자체보다는 이벤트 발생량과 보존 기간에 따라 달라집니다. GlitchTip은 월 100만 건의 이벤트를 처리하는 인스턴스에 대해 30 GB의 디스크 공간을 권장합니다. Bugsink는 MAX_RETENTION_EVENT_COUNT 및 MAX_EVENT_AGE_DAYS를 통해 예산(디스크 사용량)을 직접 설정할 수 있으므로, 사용자가 상한선을 정하면 그에 따라 필요한 디스크 용량이 결정됩니다. 보존 정책은 첫날에 설정하십시오. 보존 정책이 없는 추적기는 df -h의 결과가 100%가 될 때까지 계속 커지며, 이 시점에 도달하면 데이터 수집이 중단되어 가장 확인이 필요한 오류 로그를 잃게 됩니다.

직접 호스팅하는 Sentry의 업그레이드가 계속 실패하는 이유는 무엇입니까?

업그레이드 과정에서 반드시 거쳐야 하는 중간 단계를 건너뛰었기 때문입니다. Sentry 직접 호스팅은 데이터베이스 마이그레이션을 위해 반드시 통과해야 하는 특정 버전을 정의하고 있습니다. 2026년 8월 기준으로 해당 버전은 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 및 26.7.0입니다. 오래된 릴리스에서 최신 버전으로 바로 건너뛰면 마이그레이션이 누락되어 스키마와 코드 간의 불일치가 발생하고 업그레이드가 중단됩니다. 각 중간 버전을 순서대로 확인하며 단계마다 ./install.sh을 실행하십시오. 작업을 시작하기 전에 서버 스냅샷을 생성하고, 23.7.0, 25.9.0, 25.12.0과 같이 업그레이드 시 피해야 할 릴리스 목록을 문서에서 확인하십시오.