Starburst Enterprise 버전 정책 — LTS vs STS, 버전 넘버링과 업그레이드 전략
Starburst Enterprise Platform(SEP)의 버전 체계를 실무 관점에서 정리합니다. -e와 패치 번호가 Trino와 어떻게 매핑되는지, LTS와 STS가 운영에서 실제로 무엇을 보장하는지, 현재 지원 중인 버전 목록과 업그레이드 계획 수립 방법까지 다룹니다.
Starburst Enterprise Platform(SEP)을 운영 환경에서 사용한다면, 가장 큰 영향을 주는 운영 결정은 결국 어떤 버전을, 얼마나 오래 쓸 것인가입니다. SEP의 버전 정책은 의도적으로 두 개의 릴리스 트랙 — LTS와 STS — 위에서 설계되어 있고, 이 둘은 오픈소스 Trino의 릴리스 주기와 직접 연결됩니다. 어느 쪽을 선택하고, 언제, 어떻게 옮길지를 아느냐 모르느냐가 곧 "조용히 돌아가는 플랫폼"과 "분기마다 불 끄는 플랫폼"의 차이입니다.
1. SEP 버전 정책이 왜 별도로 존재하는가
Starburst Enterprise는 Trino(오픈소스 MPP SQL 엔진, 이전 이름 PrestoSQL)의 상용 배포판입니다. Trino 자체는 약 2주에 한 번씩 새 마이너 버전을 릴리스합니다. 커뮤니티 입장에서는 훌륭한 속도지만, 대부분의 엔터프라이즈 플랫폼에서는 그대로 따라갈 수 없습니다.
SEP는 Trino 릴리스 스트림 위에 두 가지 장치를 얹어 이 문제를 해결합니다.
- 예측 가능한 릴리스 주기: 일부 Trino 릴리스만 SEP 릴리스가 되고, 그중 일부만 LTS가 됩니다.
- LTS의 패치 라이프사이클: 1년간 보안 패치와 중대한 결함 수정이 LTS 라인으로 백포트됩니다. 덕분에 Trino의 2주 사이클을 쫓아가지 않아도 보안성을 유지할 수 있습니다.
이 글의 모든 내용은 결국 이 두 가지에서 파생됩니다.
2. 버전 넘버링
SEP의 버전 번호는 세 가지 형태만 알면, 어떤 버전이 어떤 종류인지 따로 찾아볼 필요가 없습니다.
Trino 릴리스 → 338
SEP (STS) 릴리스 → 338-e ← Trino 번호 + "-e"
SEP (LTS) 릴리스 → 338-e.0 ← STS 형식 + 패치 번호
338-e.1 ← LTS 패치 1
338-e.2 ← LTS 패치 2
...
| 형식 | 의미 | 예시 |
|---|---|---|
N | 오픈소스 Trino 릴리스 | 479 |
N-e | Trino N 기반 SEP STS 릴리스 | 480-e |
N-e.x | SEP LTS 릴리스, 패치 레벨 x | 479-e.3 |
실무에서 곧바로 따라오는 결과는 세 가지입니다.
- 앞의 정수는 언제나 상위 Trino 버전입니다.
479-e와 Trino 479는 동일한 엔진 기능을 포함합니다. - 패치 접미사(
.x)가 있으면 LTS, 없으면 STS입니다. - 패치 번호는 동일한 LTS 라인 안에서만 증가합니다.
479-e.1→479-e.2는 패치 업그레이드지만,479-e.x→480-e는 완전히 다른 릴리스로 이동하는 것입니다.
3. LTS vs STS
LTS — Long-Term Support
- 최초 릴리스 시점부터 12개월 동안 지원됩니다.
- 분기당 최대 1개의 LTS만 나오므로, 연간 선택지가 작고 예측 가능합니다.
- 12개월 지원 기간 동안 패치 릴리스(
.x접미사)가 제공됩니다. - 백포트 대상:
- 중대한 보안 수정(주로 CVE)
- 운영에 영향을 주고 워크어라운드가 없는 중대한 결함 수정 중 선별된 것
- 새 기능은 절대로 백포트되지 않습니다. 새 기능을 쓰려면 더 새 릴리스로 이동해야 합니다.
LTS는 운영 환경의 기본값입니다. 한 라인 위에서 머무르며 패치를 받고, 1년에 한 번 통제된 업그레이드를 계획하는 모델입니다.
STS — Short-Term Support
- 다음 STS 릴리스가 나올 때까지만 지원됩니다.
- 같은 버전의 Trino 오픈소스 릴리스 직후에 공개됩니다.
- 패치가 없습니다. 수정 사항은 다음 STS 릴리스에 포함되며, 현재 릴리스에 패치 형태로 제공되지 않습니다.
STS는 LTS에 아직 들어오지 않은 기능이 필요한 경우, 또는 의도적으로 업스트림 Trino에 더 가깝게 운영하고 싶을 때 선택합니다. 대신 "1년 동안 같은 자리에 머무는" 모드는 존재하지 않으며, 지속적인 업그레이드 사이클을 받아들여야 합니다.
비교표
| 항목 | LTS | STS |
|---|---|---|
| 지원 기간 | 릴리스로부터 12개월 | 다음 STS 릴리스가 나올 때까지 |
| 패치 릴리스 | 제공 (-e.0, -e.1, -e.2, …) | 제공되지 않음 |
| 릴리스 주기 | 분기당 1개 이하 | Trino를 따라감 (빈번) |
| 보안 수정 | 패치로 백포트 | 다음 STS 릴리스에서만 반영 |
| 중대한 버그 수정 | 선별적으로 백포트 | 다음 STS 릴리스에서만 반영 |
| 새 기능 | 백포트되지 않음 | STS가 바뀔 때마다 도입됨 |
| 일반적인 운영 적합도 | 기본값 | 기능 주도 또는 업스트림 근접 운영 |
4. 현재 지원 중인 LTS 버전
아래는 12개월 지원 기간 안에 있는 LTS 라인과, 참고를 위한 최근 라인들입니다. STS는 어느 시점이든 최신 한 개만 지원되며, 작성 시점 기준 최신 STS는 480-e (2026년 4월)입니다.
| LTS 라인 | 릴리스 시점 | 지원 종료일 | 상태 |
|---|---|---|---|
479-e.x | 2026년 2월 | 2027년 2월 28일 | 지원 중 |
477-e.x | 2025년 11월 | 2026년 11월 30일 | 지원 중 |
476-e.x | 2025년 8월 | 2026년 8월 31일 | 지원 중 |
474-e.x | 2025년 5월 | 2026년 5월 31일 | 지원 중 |
468-e.x | 2025년 2월 | 2026년 2월 28일 | 지원 중 |
462-e.x | 2024년 11월 | 2025년 11월 30일 | 지원 종료 |
453-e.x | 2024년 8월 | 2025년 8월 31일 | 지원 종료 |
443-e.x | 2024년 5월 | 2025년 5월 31일 | 지원 종료 |
435-e.x | 2024년 2월 | 2025년 2월 28일 | 지원 종료 |
429-e.x | 2023년 11월 | 2024년 11월 30일 | 지원 종료 |
423-e.x | 2023년 8월 | 2024년 8월 31일 | 지원 종료 |
413-e.x | 2023년 5월 | 2024년 5월 31일 | 지원 종료 |
407-e.x | 2023년 2월 | 2024년 2월 29일 | 지원 종료 |
402-e.x | 2022년 11월 | 2023년 11월 30일 | 지원 종료 |
이 표에서 읽어둘 점은 두 가지입니다.
- 릴리스 주기는 분기 단위 — 2월, 5월, 8월, 11월입니다.
- 각 LTS 라인이 12개월 살아 있기 때문에, 어느 시점이든 약 4개의 LTS 라인이 겹쳐서 지원됩니다. 이 겹침이 곧 업그레이드 활주로(runway)입니다.
표의 내용은 정책과 최근 이력을 반영했지만, 지원 집합은 분기마다 갱신됩니다. 실제 운영 전에는 반드시 공식 버전 페이지에서 최신 목록을 확인하세요.
5. 업그레이드 전략 — 현장에서 권하는 방법
공식 가이드는 짧고 분명합니다.
"가능하다면 LTS 릴리스로 업그레이드할 것을 권장합니다. 그래야 전체 지원 기간 동안 보안 패치와 수정 사항을 받을 수 있습니다."
실제로 우리가 고객과 함께 쓰는 플레이북은 다음과 같습니다.
5.1 기본 경로: 1년에 한 번, LTS → 다음 LTS
- 남은 지원 기간이 최소 9~12개월인 LTS 라인을 타깃으로 정합니다.
- 현재 버전과 타깃 사이의 모든 LTS 라인에 대한 SEP breaking changes 문서를 읽습니다. Breaking change는 누적됩니다. 중간 라인을 건너뛰더라도 그 라인에서 도입된 변경 사항은 모두 처리해야 합니다.
- 비운영 환경에서 업그레이드를 미리 수행하고, 스모크 테스트가 아니라 실제 워크로드를 돌려 보세요. 커넥터, 보안 통합, UDF를 모두 검증합니다.
- 새 LTS로 전환한 뒤에는, 남은 기간 동안 패치 라인(
-e.0→-e.1→-e.2…)을 따라가며 머무릅니다.
5.2 기능이 LTS에 도달하기 전에 필요할 때
LTS에는 아직 없지만 STS에는 들어와 있는 Trino 기능이 필요한 경우:
- 현재 STS로 이동해서 기능을 확보합니다.
- 그 기능이 들어간 LTS 라인이 등장할 때까지 STS 릴리스가 나올 때마다 업그레이드합니다.
- LTS가 나오고 검증이 끝나는 즉시 LTS 트랙으로 복귀합니다.
문서가 명시적으로 설명하는 경로입니다. "새 기능이 있는 STS 버전으로 변경하고, LTS 버전이 나올 때까지 매 STS 릴리스마다 업그레이드할 수 있다."
5.3 EOL을 넘기지 않는다
LTS 라인이 EOL 날짜를 지나면, 그 라인에는 더 이상 보안 패치가 제공되지 않습니다. 그 시점부터 Trino, JDK, 커넥터에서 새로 공개되는 CVE는 여러분 플랫폼에서 미수정 상태가 됩니다. EOL 날짜는 플랫폼 로드맵의 "느슨한 목표"가 아니라 하드 데드라인으로 다루는 것이 맞습니다.
5.4 다운그레이드는?
정책은 다운그레이드에 대해 의도적으로 언급하지 않습니다. 그것이 곧 정답입니다. 다운그레이드를 전제로 계획을 세우지 마세요. 메타데이터, 쿼리 이력, 디스크 상태는 그것을 생성한 엔진 버전에 종속되어 있습니다. 지원되는 복구 경로는 같은 라인 안에서 특정 패치 레벨로 롤포워드하는 것뿐이며, 그것이 곧 -e.x 패치가 존재하는 이유입니다.
6. 무엇이 백포트되는가 (그리고 무엇은 안 되는가)
정책에서 가장 자주 오해되는 부분이라 명시적으로 정리합니다.
| 변경 종류 | LTS 패치로 백포트되는가? |
|---|---|
| 중대한 보안 수정 (Trino/커넥터의 CVE 등) | 백포트 |
| 워크어라운드가 없는 중대한 운영 결함 | 선별적으로 백포트 |
| 그 외 일반적인 버그 수정 | 미백포트 — 새 릴리스에서 제공 |
| 성능 개선 | 미백포트 — 새 릴리스에서 제공 |
| 새 커넥터 / 함수 / SQL 기능 | 미백포트 — 새 릴리스에서 제공 |
| 라이브러리 / 의존성 업그레이드 (보안 외) | 미백포트 — 새 릴리스에서 제공 |
이를 한 줄로 요약하면: LTS 패치는 릴리스를 더 안전하게 만들 뿐, 더 새 것으로 만들지 않습니다. 새 동작이 필요하면 패치 레벨이 아니라 라인 자체를 올려야 합니다.
7. 자주 받는 질문
마이그레이션 중에 두 SEP 버전을 병행 운영해도 되나요? 네. 흔한 패턴은 타깃 LTS로 새 클러스터를 띄우고 일부 워크로드를 옮긴 뒤, 검증이 끝나면 기존 클러스터를 폐기하는 것입니다. Iceberg/Hive/Glue의 카탈로그 메타데이터는 클러스터 간 공유되므로 블루/그린 업그레이드가 실제로 작동합니다.
SEP 버전 번호는 동일 Trino 번호와 기능 동일성을 보장하나요? 엔진 버전이 같으므로 업스트림 Trino 기능 측면에서는 그렇습니다. SEP는 보안, 커넥터, 웹 UI 등 자체 추가 기능을 함께 제공하며, 이는 릴리스 노트에 별도로 문서화됩니다.
오늘 443-e.x를 쓰고 있다면 479-e.x로 바로 점프할 수 있나요?
기술적으로는 중간 LTS 라인을 건너뛸 수 있지만, 그 라인들의 breaking changes까지 건너뛸 수는 없습니다. 현재 버전과 타깃 사이의 모든 라인에 대한 breaking changes 문서를 읽는 것이 필수이며, 대부분의 업그레이드 고통은 여기에 숨어 있습니다.
Starburst Galaxy는 어떻게 되나요? Galaxy는 완전 관리형 SaaS이며 버전 관리와 업그레이드를 Starburst가 직접 수행합니다. 이 글의 LTS/STS 모델은 자체 운영하는 SEP에만 적용됩니다.
8. 요약
- SEP 버전은 Trino 번호 +
-e(STS) 또는 Trino 번호 +-e.x(LTS)입니다. 번호를 보면 무엇을 쓰고 있는지 알 수 있습니다. - LTS = 12개월 패치 제공, 분기당 최대 1개, 보안과 중대 결함은 백포트. 운영 환경의 기본값입니다.
- STS = 최신 한 개만, 패치 없음. 다음 LTS 이전에 기능이 필요할 때 쓰며, 대신 지속적인 업그레이드 사이클을 받아들여야 합니다.
- 1년에 한 번 LTS-to-LTS 업그레이드를 계획하고, breaking changes를 라인 단위로 처리하며, EOL 날짜는 협상 불가능한 데드라인으로 다룹니다.
- 새 기능은 절대 패치로 나오지 않습니다. 필요하면 라인을 옮기는 수밖에 없습니다 — 지름길은 없습니다.
버전 정책은 관료적인 절차가 아니라, Trino 기반 플랫폼을 1년 단위로 안정적으로 유지하기 위한 계약입니다. 그렇게 사용하면 됩니다.
— Data Dynamics 팀