Trino vs Starburst Enterprise (SEP) 비교

"Trino는 무료인데, 왜 Starburst Enterprise를 돈 주고 써야 하나요?" 레이크하우스의 쿼리 엔진으로 Trino를 표준화하기 시작한 팀에서 가장 자주 듣는 질문입니다. 솔직히 답하면, 어려운 것은 Trino 그 자체가 아닙니다. 어려운 것은 보안 모델, 엔터프라이즈 커넥터의 긴 꼬리, 자주 쓰는 테이블에 대한 성능 작업, 그리고 엔진을 둘러싼 운영 도구입니다. Starburst Enterprise Platform(SEP)은 거의 전적으로 이 네 가지 문제에 대한 답입니다.

이 글은 SEP 공식 개요와 Starburst 커넥터 기능 매트릭스를 기반으로 Trino와 SEP를 카테고리별로 비교합니다. 의도적으로 영업 자료처럼 쓰지 않았습니다. 우리 플랫폼이 실제로 어느 쪽이 필요한지 판단할 수 있도록 만드는 것이 목표입니다.

---

1. SEP의 정의

"Starburst Enterprise Platform(SEP)은 Trino의 상용 배포판이며, Trino의 비용 기반 옵티마이저는 물론 추가적인 보안 기능, 더 많은 커넥터, 추가 배포 플랫폼 지원 등을 포함한다."

다시 말해:

• 엔진은 동일합니다. SEP N-e는 업스트림 Trino N과 동일한 엔진을 탑재합니다. SQL 시맨틱, 비용 기반 옵티마이저, 워커/코디네이터 아키텍처, 커넥터 SPI가 모두 같습니다.
• 표면적이 확장됩니다. SEP는 그 위에 엔터프라이즈 보안, 추가 커넥터, 성능 도구(특히 Warp Speed), 관리 UI, 지원되는 배포 경로, 24/7 지원 계약을 얹습니다.

Trino를 엔진으로, SEP를 그 엔진을 둘러싼 플랫폼으로 본다면 멘탈 모델이 정확합니다.

---

2. 상위 레벨 기능 비교

---

3. 보안과 인가

엔터프라이즈가 Trino에서 SEP로 옮겨가는 가장 명확한 이유 중 하나는 보안입니다.

업스트림 Trino도 단단한 기본기를 제공합니다. 인증은 LDAP, OAuth2, JWT, Kerberos가 있고, 파일 기반 액세스 컨트롤 플러그인도 있습니다. 작은 팀이나 단일 테넌트에는 충분합니다. 하지만 규제 요건이 걸린 멀티 테넌트 레이크하우스에는 부족합니다.

SEP가 추가적으로 제공하는 것은 다음과 같습니다.

• Built-in Access Control(BIAC) — SEP 자체에서 관리되는 네이티브 인가 모델. 카탈로그 / 스키마 / 테이블 / 컬럼 / 로우 단위로 역할 기반 권한을 관리합니다.
• Apache Ranger 통합 — 글로벌, 카탈로그, 컬럼, 로우 레벨 필터. 이미 Hive/HDFS에 사용 중인 Ranger 정책을 그대로 공유할 수 있습니다.
• Okta 인증을 LDAP / OAuth2 / Kerberos와 동급으로 통합.
• Kerberos credential passthrough(캐싱 포함) — 워커가 장수명 서비스 계정을 들지 않고도 사용자 자격 증명으로 Kerberized HDFS/Hive에 접근합니다.
• Password credential passthrough — 패스워드 기반 백엔드에도 같은 패턴을 적용.
• 사용자 임퍼소네이션 일반화 — Trino에서는 주로 Hive 커넥터에 한정되어 있던 임퍼소네이션을 SEP는 더 넓은 범위로 확장합니다.
• Query audit — 누가, 언제, 어떤 카탈로그에 대해, 어떤 쿼리를 실행했는지 영속 기록.

실무적 효과는 단순합니다. 정책이 한 곳(BIAC 또는 Ranger)에 모이고, 그 정책이 아래에 나오는 모든 엔터프라이즈 커넥터를 포함해 SEP가 노출하는 모든 커넥터에 균일하게 적용됩니다.

---

4. 커넥터

업스트림 Trino도 건강한 커넥터 세트를 갖고 있지만, 일반적인 엔터프라이즈의 데이터는 Oracle, Teradata, Db2, SAP HANA, Snowflake, Synapse, Greenplum, Netezza, Salesforce, Cosmos DB 같은 곳에 살아 있습니다. 이런 커넥터들이 SEP 라이선스 비용의 상당 부분을 차지하는 이유입니다.

Starburst 전용 커넥터 (업스트림 Trino에 없음)

Starburst가 직접 개발/유지하며 SEP에만 포함됩니다.

• Starburst Alteryx 커넥터
• Starburst Cosmos DB 커넥터 (Azure)
• Starburst IBM Db2 커넥터
• Starburst DynamoDB 커넥터 (AWS)
• Starburst Generic JDBC 커넥터
• Great Lakes 커넥터 (데이터 레이크 테이블 포맷 통합 처리)
• Starburst Greenplum 커넥터
• Starburst Kudu 커넥터
• Starburst MaxCompute 커넥터 (Alibaba)
• Starburst Neo4j 커넥터
• Starburst Netezza 커넥터 (IBM)
• Starburst Salesforce 커넥터
• Starburst SAP HANA 커넥터
• Starburst Snowflake 커넥터
• Starburst Splunk 커넥터
• Starburst Stargate 커넥터 (Trino/SEP ↔ Trino/SEP 페더레이션)
• Starburst Synapse 커넥터 (Azure)
• Starburst Teradata 커넥터들

업스트림 커넥터의 개선판

Trino에도 존재하지만 SEP는 더 강한 푸시다운, Warp Speed 통합, 추가 인증 옵션 등을 포함한 빌드를 제공합니다.

BigQuery, Cassandra, ClickHouse, Delta Lake, Elasticsearch, Hive(Warp Speed 지원), Hudi, Iceberg(Warp Speed 지원), Kafka, MySQL, MongoDB, Oracle, PostgreSQL, Redshift, SingleStore, SQL Server, Vertica.

업스트림 Trino와 동일

Black Hole, Druid, DuckDB, Exasol, Faker, Google Sheets, Ignite, JMX, Lakehouse, Loki, MariaDB, Memory, OpenSearch, Pinot, Prometheus, Redis, System, Thrift, TPC-DS, TPC-H.

이 목록을 읽는 한 가지 방법: "S3 + Postgres 위의 Trino"만으로 모든 요건이 커버된다면 업스트림 Trino로 충분합니다. 아키텍처 다이어그램에 Salesforce, SAP HANA, Snowflake, Teradata, Db2 같은 소스가 등장하는 순간, 저울은 빠르게 SEP 쪽으로 기웁니다.

---

5. 성능 — Warp Speed

Warp Speed는 SEP가 Trino 위에 얹는 가장 큰 성능 차별점이며, 대부분의 레이크하우스에서 실제 워크로드를 짊어지는 Hive와 Iceberg 커넥터에 적용됩니다.

개념적으로 Warp Speed는 워커마다 동작하는 스마트한 캐싱·인덱싱 레이어로, Trino 워커와 오브젝트 스토리지 사이에 자리합니다. 실제 쿼리 패턴으로부터 학습해서:

• 자주 사용되는 컬럼과 범위를 각 워커의 로컬 SSD에 캐싱해서, 이후 쿼리가 오브젝트 스토리지를 왕복하지 않도록 합니다.
• 실제로 읽힌 데이터에 대해 경량 인덱스(range, lookup, bitmap, geo)를 구축해서, 푸시다운된 술어가 파일이나 row group을 통째로 스킵할 수 있게 합니다. 원래라면 열어보고 버려야 했을 데이터가 아예 읽히지 않습니다.
• 백그라운드에서 자신을 갱신하면서 기반 테이블 변경에 따라갑니다.

결과적으로는 전통적인 파일시스템 캐싱보다 데이터베이스의 "쿼리하는 곳이 곧 핫 데이터"에 가까운 효과를 냅니다. SQL 입장에서는 투명합니다. 같은 Iceberg 테이블을 쿼리하고, 엔진이 단지 더 적은 I/O를 합니다.

성능에 인접한 다른 기능들:

• Materialized View가 SEP 카탈로그의 관리 대상으로 제공됩니다(업스트림 Trino도 MV 메커니즘은 있지만, SEP는 refresh, 저장, 액세스 컨트롤까지 묶어서 다룹니다).
• Dynamic filtering과 비용 기반 옵티마이저는 Trino와 동일하지만, 디폴트 튜닝이 좀 더 잘 맞춰져 있습니다.

워크로드가 동일한 Iceberg/Hive 테이블에 대한 반복 스캔으로 지배된다면, SEP에서 가장 빠르게 비용을 회수할 가능성이 높은 기능이 Warp Speed입니다.

---

6. 페더레이션 — Stargate

Stargate 커넥터는 한 Trino/SEP 클러스터가 다른 Trino/SEP 클러스터를 마치 하나의 소스처럼 쿼리할 수 있게 해 줍니다. 호기심으로 들리지만, 멀티 리전이나 멀티 테넌트 Trino 토폴로지를 만들어 본 사람이라면, 데이터를 복제하지도, 서로 다른 보안 자세를 가진 클러스터들을 합치지도 않고 클러스터 사이로 쿼리를 라우팅할 깔끔한 방법이 필요했음을 알고 있습니다.

자주 쓰이는 패턴:

• 글로벌 클러스터가 리전별 SEP 클러스터들을 페더레이트. 데이터는 각 소스 시스템에 가깝게 둡니다.
• 중앙 클러스터가 별도 보안이 적용된 테넌트 클러스터들 위에 큐레이션된 뷰를 노출합니다.
• 마이그레이션 브릿지 — 새 클러스터에서 레거시 클러스터로 Stargate를 걸어 두고, 데이터와 소비자가 옮겨가는 동안 양쪽에서 동일하게 보이도록 합니다.

Stargate는 SEP 전용입니다. 업스트림 Trino에서는 이런 조합을 매번 자체적으로 재구현해야 합니다.

---

7. 관리와 운영

이 카테고리는 Trino를 규모 있게 운영해 보기 전까지는 가치를 과소평가하기 쉽습니다.

• Starburst Enterprise 웹 UI와 쿼리 편집기 — 기본 Trino 코디네이터 UI를 넘어, 쿼리 작성, 이력, 운영자 친화적인 클러스터 뷰를 제공합니다.
• Starburst Insights — 쿼리 패턴, 자원 사용량, 슬로우 쿼리 분석을 위한 클러스터 메트릭 대시보드. "내 Trino 클러스터가 지금 실제로 뭘 하고 있는가, 어제 새벽 3시에는 뭘 했는가" 질문에 답합니다.
• High availability — 코디네이터와 그 주변 백엔드 서비스에 대한 고가용성.
• Autoscaling with graceful scaledown — 진행 중인 쿼리를 죽이지 않고 워커를 drain할 수 있습니다.
• Backend service — 쿼리 이력, 설정, Insights 데이터를 보관하는 SEP의 보조 서비스.
• Telemetry — CloudWatch, Google Stackdriver와의 로그·대시보드 통합.
• Data products — 카탈로그 위에 오너, 문서, 액세스 정책이 부여된 큐레이션된 데이터셋을 게시하는 구조화된 방법.
• Apache Atlas 통합 — 리니지와 메타데이터 카탈로깅.

업스트림 Trino는 JMX 메트릭, 로그, 기본 웹 UI를 제공합니다. 그 위에 있는 모든 것은 플랫폼 팀이 직접 만들어야 할 항목입니다. 쿼리 이력 저장소, 진행 중 쿼리를 존중하는 오토스케일러, 메트릭 파이프라인, 카탈로그 UX, 리니지 통합. 엔지니어링 시간을 정직하게 비용으로 환산해 보면, 보통 "직접 만들기"가 우세하지 않습니다.

---

8. 배포와 패키징

Trino는 JAR + Docker 이미지로 배포되며, 그 위는 운영자의 몫입니다. SEP는 지원되는 설치 경로를 문서와 함께 제공합니다.

• 기본 제공 Kubernetes 설정(Helm 차트, 매니페스트).
• Red Hat OpenShift 지원.
• Starburst Admin — 온프레미스나 VM 기반 설치를 위한 Ansible 기반 배포 도구.
• AWS Marketplace, Azure Marketplace, Google Cloud Marketplace 등록과 Marketplace 빌링 경로.
• CloudWatch(AWS), Stackdriver(GCP)와의 기본 제공 로그/대시보드 통합.

Kubernetes를 이미 잘 운영하는 조직이라면 업스트림 Trino Helm 차트로도 충분히 운영 가능합니다. SEP의 가치는 주로 감사·구매팀에 보여줄 수 있는 지원되는 표준 배포가 필요한 조직에 있습니다.

---

9. 지원과 릴리스 모델

Trino는 커뮤니티 프로젝트입니다. SEP는 지원 계약이 붙은 제품입니다.

• 24/7 지원과 30분 SLA.
• 엔터프라이즈 고객을 위한 전담 TAM(Technical Account Manager).
• 공식 릴리스 모델 — LTS(분기 단위, 12개월 패치)와 STS(Trino를 따라가며 최신 한 개만 지원). 상세한 내용은 함께 발행한 글 Starburst Enterprise 버전 정책 — LTS vs STS, 버전 넘버링과 업그레이드 전략을 참고하세요.

많은 의사결정에서 이 카테고리 하나 — 새벽 3시에 전화할 곳이 있다는 사실, 그리고 1년 단위로 계획 가능한 릴리스 라인 — 가 결정을 가르는 경우가 많습니다.

---

10. SEP vs Starburst Galaxy

자주 혼동되는 지점입니다. Starburst는 두 가지 제품을 판매합니다.

• Starburst Enterprise(SEP) — 이 글이 다루는 제품. 사용자가 자체 인프라(Kubernetes, OpenShift, EC2, 온프레미스)에 설치하고 운영합니다. 버저닝은 LTS/STS이며, 업그레이드는 운영자의 책임입니다.
• Starburst Galaxy — 완전 관리형 SaaS. Starburst가 클러스터를 운영하고, 사용자는 엔드포인트를 가리키기만 합니다. LTS/STS가 표면에 노출되지 않으며, Starburst가 지속적으로 업데이트합니다.

엔진 패밀리는 같지만, 운영 소유권의 경계가 다른 두 제품입니다.

Trino를 서비스처럼 쓰고 클러스터를 직접 운영하고 싶지 않다면 Galaxy가 답입니다. 데이터 중력, 네트워크 격리, 규제 거주 요건, 기존 K8s 투자, 또는 심층적인 커스터마이즈 요구가 있다면 SEP가 답입니다.

---

11. 어떻게 선택할 것인가

실용적인 판단 트리:

1. 데이터가 거의 전적으로 오브젝트 스토리지 + Postgres 계열 DB에 있고, 강한 플랫폼 팀이 있는가? 업스트림 Trino로 충분할 가능성이 큽니다. 보안, 관측성, HA 작업에 들어가는 시간을 예산에 잡으세요.

2. 아키텍처에 Snowflake, Oracle, Teradata, Db2, SAP HANA, Salesforce, Synapse, Greenplum, Netezza가 있는가? SEP의 엔터프라이즈 커넥터가 결정적입니다. 이걸 Trino 위에 다시 만드는 일은 작은 프로젝트가 아닙니다.

3. 워크로드의 대부분이 Iceberg / Hive 테이블에 대한 반복 스캔인가? 두 제품을 통틀어 ROI가 가장 높은 단일 기능은 Warp Speed일 가능성이 높습니다.

4. 모든 카탈로그에 대해 Ranger 기반 또는 BIAC 기반의 fine-grained 인가와 감사가 필요한가? SEP가 현실적인 유일한 경로입니다.

5. 지원되는 배포와 24/7 SLA, 1년 단위로 계획 가능한 릴리스 라인이 필요한가? SEP.

6. 운영 부담을 0에 가깝게 줄이고 싶은가? SEP가 아니라 Starburst Galaxy입니다.

---

12. 요약

• Trino는 엔진, SEP는 플랫폼. 같은 SQL 시맨틱, 같은 CBO, 같은 커넥터 SPI. SEP는 그 주변에 보안, 커넥터, 성능, 운영 레이어를 두른 것입니다.
• 결정 요인은 대개 보안과 커넥터. BIAC, Ranger, query audit, credential passthrough, 그리고 Starburst 전용 커넥터들(Snowflake, Oracle, Teradata, Db2, SAP HANA, Salesforce, Synapse, …)이 대부분의 엔터프라이즈에서 SEP를 정당화합니다.
• 성능 차별화는 Warp Speed. Iceberg / Hive 워크로드에서 엔진만으로는 만들 수 없는 캐싱과 경량 인덱싱을 제공합니다.
• 운영 차별화는 Insights와 관리 UI. 내부 도구로 만들었을 양의 적지 않은 부분을 대체합니다.
• SEP와 Galaxy는 다른 제품. 같은 엔진 패밀리, 다른 운영 소유권 경계. 운영 경계를 어디에 두고 싶은지로 선택하세요.

조직 입장에서 빠진 조각의 한계 비용이 낮다면 Trino를 쓰세요. 그 빠진 조각이 곧 운영 진입을 막는 요소라면 SEP를 쓰세요.

— Data Dynamics 팀