LLM WikiAccess-protected knowledge portal
← 스터디 홈
28편 · 약 16분

Trino 483: PIVOT·JSON 접근자·Lakehouse S3 인증 정리 — 운영자가 먼저 볼 변화

왜 지금 Trino 483을 봐야 하나

2026년 7월 17일 공개된 Trino 483은 2026년 7월 20일 기준으로 나온 지 3일밖에 지나지 않은 릴리스다. 표면만 보면 PIVOT, JSON simplified accessor, OVERLAPS 같은 SQL 기능이 늘어난 버전처럼 보인다. 그런데 운영 관점에서 더 중요한 변화는 다른 층에 걸려 있다.

  1. 분석가와 애플리케이션이 쓰는 SQL 표면이 넓어졌다. PIVOT과 JSON 접근자가 들어오면서, 예전에는 CASE/FILTER/json_extract로 우회하던 쿼리를 엔진 기본 문법으로 표현할 수 있게 됐다.
  2. 보안·운영 표면이 바뀌었다. OAuth2 SSO 계정 선택을 특정 도메인으로 제한하는 domain-hint가 추가됐고, 새 Web UI가 /ui의 기본이 됐다.
  3. Lakehouse 커넥터의 S3 인증 방식이 정리됐다. Delta Lake, Hive, Hudi, Iceberg, Lakehouse 커넥터가 s3.auth-type 중심으로 수렴하면서, 예전 키를 그대로 들고 올라가면 startup failure나 인증 오작동이 날 수 있다.
  4. 플러그인 작성자에게는 SPI 경계가 깨진다. block null 표현이 boolean 배열에서 bit-packed validity bitmap으로 바뀌어, BlockBuilder를 우회해 직접 block을 만들던 코드는 수정이 필요하다.

즉, 483은 “SQL 문법이 편해졌다” 정도로 넘기면 아깝다. 분석 쿼리, SSO, Web UI, object storage 인증, custom plugin 호환성이 한 릴리스에서 동시에 바뀌는 버전이다.


한눈에 보는 483의 핵심

영역483에서 달라진 것운영자가 먼저 볼 것
SQL 표면PIVOT, JSON simplified accessor, OVERLAPS, geospatial 함수 확대기존 BI/리포트 SQL을 더 단순화할 수 있는지, JSON 컬럼 조회 경로를 표준화할 수 있는지
보안/접근http-server.authentication.oauth2.domain-hint 추가사내 계정만 선택되도록 SSO 경로를 좁힐 수 있는지
Web UI새 UI가 /ui 기본, 예전 UI는 /ui/legacy로 이동프록시, 런북, 스크린샷, 운영자 교육 자료가 새 경로를 전제하는지
Lakehouse 커넥터s3.auth-type 중심 인증 정리, 일부 예전 키 제거IAM role / web identity / public bucket 접근 설정을 다시 검증해야 하는지
쓰기 경로 정확성Parquet writer 메모리 사용량 감소, Delta deletion vector sidecar 오류 수정대용량 Parquet 쓰기와 Delta DELETE/OPTIMIZE 계열 canary를 다시 돌려야 하는지
SPInull 표현을 validity bitmap으로 변경custom connector/UDF/plugin이 block을 직접 조립하는지
Trino 483: SQL 표면, 운영 표면, Lakehouse 인증, SPI가 동시에 바뀌는 릴리스 ① 클라이언트 / SQL 계층 BI · dbt · ad-hoc 분석 · ETL SELECT PIVOT, JSON simplified accessor, OVERLAPS, geospatial 함수 추가 ② Coordinator 보안 / 운영 표면 OAuth2 SSO: domain-hint로 계정 선택 범위 축소 Web UI: 새 UI가 /ui 기본, 예전 UI는 /ui/legacy 영향: 프록시 라우팅, 문서, 온콜 런북, 관리자 교육 자료 ③ Connector / Object storage 계층 Delta Lake · Hive · Hudi · Iceberg · Lakehouse s3.auth-type 통일, IAM_ROLE/WEB_IDENTITY 경계 명확화 영향: startup validation, role assumption, public bucket read, write correctness ④ 엔진 내부 / SPI 계층 block null 표현: boolean null[] → bit-packed validity bitmap 직접 block을 조립하는 plugin은 수정 필요 / BlockBuilder 경로는 상대적으로 안전 Parquet writer dictionary 메모리 accounting 개선, Delta deletion vector sidecar 직렬화와 실패 cleanup 보정 즉, 483은 SQL 문법 릴리스이면서 동시에 auth·UI·storage·plugin upgrade runbook 릴리스다.
Trino 483에서 변화가 걸리는 네 개의 층

1. PIVOT과 JSON 접근자는 단순 문법 추가가 아니다

PIVOT은 보고서형 SQL의 우회 경로를 줄인다

483은 Trino에 first-class PIVOT 구문을 추가했다. 이제 row 값을 column으로 돌리기 위해 SUM(...) FILTER (WHERE ...)를 길게 나열할 필요가 줄어든다.

SELECT *
FROM sales PIVOT (
    sum(amount) AS total
    FOR month IN (1 AS jan, 2 AS feb, 3 AS mar)
    GROUP BY region
);

이 변화가 실무적으로 의미 있는 이유는 다음과 같다.

  • 보고서형 SQL이 짧아진다.
  • 같은 회전을 애플리케이션 코드나 BI tool의 후처리로 밀어내지 않아도 된다.
  • GROUPING SETS, CUBE, ROLLUP 같은 집계 문법과 같은 수준에서 회전 결과를 다룰 수 있다.

다만 PR 설명이 강조하듯이, GROUP BY를 생략하면 GROUP BY ()와 같다. 즉 보존하려는 차원 컬럼이 있다면 반드시 GROUP BY region처럼 명시해야 한다. 이 점을 놓치면 “PIVOT이 됐는데 결과가 한 줄뿐”인 쿼리를 만나게 된다.

JSON simplified accessor는 json_extract 난독화를 줄인다

483의 또 다른 큰 변화는 SQL:2023 계열 JSON simplified accessor다. json 타입 컬럼에서 dotted/subscripted 체인을 바로 쓸 수 있게 됐다.

SELECT
  j.customer.name,
  j.items[0].price.decimal(18,2),
  j.items[*]
FROM orders;

이전에는 아래처럼 json_extract, json_extract_scalar, 캐스팅을 섞어 써야 했던 패턴이 많았다.

SELECT
  json_extract_scalar(j, '$.customer.name'),
  CAST(json_extract_scalar(j, '$.items[0].price') AS decimal(18,2))
FROM orders;

운영자 입장에서 중요한 점은, 이 기능이 단순 편의성만이 아니라 SQL 표준 경로를 쓰게 만든다는 점이다.

  • 애플리케이션/분석가마다 JSON path 문자열을 제각각 복붙하던 습관을 줄인다.
  • review 시 “이 경로가 어떤 값을 읽는지”를 더 빨리 파악할 수 있다.
  • JSON 컬럼 조회가 row-field 접근처럼 보이기 때문에 쿼리 가독성이 크게 올라간다.

다만 PR 설명에는 아직 내부적으로 JSONJSON_2016 타입 경계 때문에 우회 캐스팅 경로가 남아 있다는 언급이 있다. 즉 표면은 단순해졌지만 엔진 내부 경로가 완전히 정리된 것은 아니다. 그래서 대량 JSON 조회 워크로드에서는 새 문법이 들어왔다고 해서 곧바로 비용 구조가 크게 달라진다고 가정하면 안 된다.


2. OAuth2 domain-hint와 새 Web UI 기본값 전환은 런북 변경 사항이다

domain-hint는 SSO 실수를 줄이기 위한 운영용 기능이다

OAuth2 문서에 따르면 483부터 아래 속성을 사용할 수 있다.

http-server.authentication.type=oauth2
http-server.authentication.oauth2.domain-hint=example.com

공식 문서는 이 값을 설정하면 authorization URL에 domain_hintprompt=select_account가 함께 실리고, 일부 IdP(예: Azure AD)가 계정 선택기를 특정 도메인으로 제한하는 데 사용한다고 설명한다.

이건 화려한 기능은 아니지만, 실제 운영에서는 꽤 쓸모가 있다.

  • 개인 계정과 회사 계정이 같은 브라우저에 같이 로그인돼 있을 때 잘못된 계정 선택을 줄인다.
  • 테스트/운영 환경을 나눌 때 접근 경계를 사용자 경험 수준에서도 좁힐 수 있다.
  • 온콜이나 임시 운영자가 "왜 자꾸 다른 계정이 보이냐"고 묻는 상황을 줄여 준다.

즉, 483의 보안 변화는 인증 프로토콜을 새로 바꿨다기보다 운영 실수의 빈도를 줄이는 작은 제어점을 추가한 쪽에 가깝다.

/ui가 새 기본이고, 예전 UI는 이제 임시 복귀 수단이다

릴리스 노트는 483의 Web UI 변화에 breaking change 마크를 달았다.

  • 새 Web UI가 이제 /ui 기본이다.
  • 예전 UI는 /ui/legacy로 이동했다.
  • 예전 UI는 기본 비활성화이며, 필요하면 web-ui.legacy.enabled=true로 다시 열 수 있다.
web-ui.legacy.enabled=true

이 변화의 실무적 의미는 의외로 크다.

  • 프록시 규칙이나 사내 포털이 /ui/preview를 전제하고 있으면 깨진다.
  • 운영 문서, 스크린샷, 교육 자료, 장애 대응 절차가 모두 새 UI 기준으로 다시 맞춰져야 한다.
  • 브라우저 자동화나 스모크 테스트가 오래된 DOM 구조를 기대하면 실패할 수 있다.

Trino 쪽 이슈 설명을 보면 이 UI 교체는 단순 스킨 변경이 아니라, 오래된 React/jQuery/bootstrap 3 기반 UI를 현대 스택으로 바꾸고 완전 대체하려는 장기 작업의 결과다. 따라서 이번 버전에서 예전 UI를 임시로 다시 켤 수는 있어도, 장기 전략은 새 UI로 옮겨가는 쪽이라고 보는 것이 맞다.


3. Lakehouse 커넥터의 S3 인증 방식이 s3.auth-type 중심으로 정리됐다

483에서 운영자에게 가장 직접적으로 위험한 부분은 Lakehouse 커넥터의 object storage 인증 정리다. Delta Lake, Hive, Hudi, Iceberg, Lakehouse 커넥터 릴리스 노트가 거의 같은 breaking change를 반복한다.

  • s3.auth-type 속성이 중심이 된다.
  • s3.iam-role을 쓸 때는 s3.auth-type=IAM_ROLE이 필요하다.
  • s3.use-web-identity-token-credentials-provider는 제거됐고 s3.auth-type=WEB_IDENTITY를 써야 한다.
  • public bucket 읽기는 s3.auth-type=ANONYMOUS로 명시한다.

공식 S3 파일 시스템 문서도 s3.auth-type을 아래 네 모드 중 하나로 설명한다.

  • ANONYMOUS
  • DEFAULT
  • IAM_ROLE
  • WEB_IDENTITY

예를 들면 이제 이런 식으로 적는 편이 맞다.

connector.name=iceberg
s3.auth-type=IAM_ROLE
s3.iam-role=arn:aws:iam::123456789012:role/trino-lakehouse

또는 Kubernetes / IRSA / Workload Identity 계열이면 다음처럼 가야 한다.

connector.name=hive
s3.auth-type=WEB_IDENTITY

왜 이게 중요한가

이 변화는 단순 rename처럼 보여도, 실제로는 인증 의도를 명시하게 만드는 강제다.

예전에는 “role도 넣고, web identity provider도 켜고, 나머지 기본 credential chain도 남겨 놓는” 식의 모호한 구성이 팀 문서에 섞여 있기 쉬웠다. 483은 이 경계를 더 엄격하게 드러낸다.

  • public bucket read를 하면서도 실수로 credential chain을 태우는 구성을 줄일 수 있다.
  • role assumption인지, web identity인지, 그냥 default chain인지 문서상으로도 분명해진다.
  • 반대로, 예전 속성을 그대로 들고 오면 startup validation 단계에서 바로 걸릴 수 있다.

인증 정리만이 아니라 write correctness도 함께 봐야 한다

483의 Lakehouse 관련 변화는 인증만이 아니다.

  • Parquet writer 메모리 사용량 감소: PR #30372는 dictionary-heavy write에서 실제 메모리 사용량과 accounting이 맞지 않던 문제를 줄이고, per-column writer 구조를 재작성해 과소 계상과 과도한 오버헤드를 줄인다.
  • Delta deletion vector 직렬화 수정: PR #30355는 sidecar payload 크기 계산이 틀려 다른 Delta reader가 deletion vector를 거부할 수 있던 문제를 고친다.
  • Delta failed write cleanup 수정: PR #30342는 실패한 write 뒤에 orphaned deletion vector sidecar가 남는 문제를 고친다.
  • Iceberg encrypted Parquet read 지원: release 483은 Iceberg encrypted Parquet file read 지원을 추가했다.
  • Iceberg materialized view 메타데이터 테이블 조회 지원: $files, $snapshots, $partitions 계열 메타데이터를 MV 저장 테이블 쪽에서도 볼 수 있게 했다.

즉, 483의 Lakehouse 메시지는 “인증 속성을 정리했다”에서 끝나지 않는다. 오브젝트 스토리지 접근 방식과 write/read correctness를 함께 다듬은 릴리스에 가깝다.


4. custom plugin이 있다면 SPI null 표현 변경을 그냥 넘기면 안 된다

릴리스 노트의 SPI 항목은 한 줄이지만, 내용은 꽤 세다.

block null representation이 boolean null arrays에서 bit-packed validity bitmaps로 바뀌었다.

PR #30185 설명은 더 구체적이다.

  • set bit는 value가 존재함을 뜻한다.
  • 이 표현은 Java vector API가 쓰는 validity 개념과 맞춘 것이다.
  • block encoding은 compacted validity words를 운반한다.
  • ORC/Parquet 경로도 이 표현을 직접 생산/소비하도록 업데이트됐다.
  • BlockBuilder API를 거치지 않고 직접 block을 만들던 코드는 깨질 수 있다.

운영자보다는 plugin/connector 개발자에게 더 가까운 얘기지만, Trino를 깊게 커스터마이즈한 팀이라면 매우 실전적인 체크포인트다.

왜 이 변화가 위험한가

Trino upgrade에서 가장 골치 아픈 종류의 오류는 “서버는 뜨는데 특정 custom type/connector/UDF 경로에서만 잘못된 결과가 나는” 경우다. 이런 문제는 보통 문법 변경보다 SPI 경계 변경에서 더 많이 나온다.

특히 아래 같은 패턴이 있다면 483 업그레이드 전 컴파일/리뷰가 필요하다.

  • custom plugin이 ByteArrayBlock, VariableWidthBlock 같은 구현 세부에 직접 기대는 경우
  • block builder가 아니라 raw null array/offset array를 직접 조합하는 코드가 있는 경우
  • ORC/Parquet reader/writer 확장 코드를 사내 포크로 들고 있는 경우

PR 설명은 메모리를 1/8 수준으로 줄이는 장점도 시사하지만, release note 자체도 말하듯이 호환성 경계가 더 중요하다. 483은 plugin 작성 규칙을 “BlockBuilder API 중심”으로 더 강하게 밀어붙이는 릴리스다.


5. 483은 누구에게 특히 먼저 의미가 있는가

1) Trino를 BI/리포트 SQL 게이트웨이로 쓰는 팀

PIVOT과 JSON 접근자는 SQL 템플릿을 단순화하고 review 비용을 줄일 수 있다. 특히 BI 툴이 복잡한 FILTER aggregate를 남발하던 팀이라면 체감이 크다.

2) SSO 계정 혼선과 운영 문서 부채가 있는 팀

여러 계정이 한 브라우저에 공존하는 환경, 사내 포털/프록시를 두고 Web UI를 노출하는 환경이라면 483은 인증과 UI 동선을 정리할 기회다.

3) Iceberg/Hive/Delta/Hudi를 object storage 위에서 운영하는 팀

s3.auth-type 정리는 결국 object storage 접근 의도를 명확히 하라는 메시지다. 동시에 Parquet writer 메모리 accounting과 Delta deletion vector correctness가 손봐졌기 때문에, write-heavy 워크로드 팀에게 의미가 있다.

4) Trino plugin을 직접 들고 있는 팀

이 경우 483은 단순 업그레이드가 아니라 SPI 호환성 점검 이벤트다.


바로 실행할 업그레이드 체크리스트

점검 항목확인 방법기대 신호문제 시 대응
PIVOT / JSON accessor대표 보고서 쿼리를 새 문법으로 스테이징 실행결과 shape는 같고 SQL 길이는 짧아짐우선 기존 쿼리 유지, 새 문법은 신규 쿼리부터 점진 도입
OAuth2 계정 선택사내 계정/개인 계정이 같이 로그인된 브라우저에서 SSO 테스트account picker가 의도한 도메인으로 좁혀짐domain-hint 제거 또는 IdP 동작 차이 문서화
Web UI 경로/ui, /ui/legacy, 프록시 라우팅, 내부 링크 확인새 UI가 기본 경로에서 정상 동작임시로 web-ui.legacy.enabled=true, 문서와 스모크 테스트 수정
S3 인증 설정catalog properties에서 s3.auth-type, s3.iam-role, 예전 web identity 키 inventory의도한 auth mode가 명시적으로 보임제거된 키 삭제, IAM_ROLE / WEB_IDENTITY 중 하나로 정리
Parquet/Delta 쓰기대용량 Parquet write, Delta DELETE/MERGE canaryworker 메모리 초과 감소, DV sidecar 오류 없음482 대비 메모리/오브젝트 listing 비교, 문제 쿼리 격리
custom plugin483으로 rebuild + block 직접 생성 코드 grepBlockBuilder 중심 코드는 대부분 안전raw block constructor 경로 수정 후 재빌드

추천하는 최소 검증 순서는 다음이다.

  1. SQL 카나리: PIVOT, JSON accessor, 기존 보고서 쿼리 결과 비교
  2. 접근 카나리: SSO login, /ui 경로, reverse proxy 및 온콜 런북 점검
  3. 스토리지 카나리: Iceberg/Hive/Delta catalog를 483 설정으로 띄워 startup validation 확인
  4. 쓰기 카나리: dictionary-heavy Parquet write, Delta deletion vector 발생 경로, Iceberg encrypted Parquet read
  5. 확장 카나리: custom plugin/UDF/connector compile + smoke test

정리

Trino 483은 SQL 기능이 눈에 띄는 릴리스지만, 운영자가 챙겨야 할 핵심은 그보다 아래층에 있다.

  • 분석 표면에서는 PIVOT과 JSON accessor가 들어와 SQL을 더 표준적인 형태로 바꾼다.
  • 운영 표면에서는 OAuth2 domain-hint와 새 Web UI 기본값이 계정 선택과 운영 동선을 바꾼다.
  • 스토리지 표면에서는 Lakehouse 커넥터의 S3 인증 방식이 s3.auth-type로 정리되고, write correctness 수정이 함께 들어왔다.
  • 확장 표면에서는 SPI null 표현 변경으로 custom plugin의 호환성 점검이 필요하다.

그래서 483 업그레이드는 "새 SQL 문법을 언제 쓰지?"보다 "우리 SSO/UI/object storage/plugin 경계가 483의 새 기본값을 견디는가?"를 먼저 묻는 편이 맞다.

References

  • Trino Release 483 notes (published 2026-07-17): https://trino.io/docs/current/release/release-483.html
  • Trino PIVOT documentation: https://trino.io/docs/current/sql/pivot.html
  • Trino JSON functions documentation (JSON simplified accessor): https://trino.io/docs/current/functions/json.html#json-simplified-accessor
  • Trino OAuth2 security documentation (http-server.authentication.oauth2.domain-hint): https://trino.io/docs/current/security/oauth2.html
  • Trino S3 file system documentation (s3.auth-type): https://trino.io/docs/current/object-storage/file-system-s3.html
  • Trino issue #29404, Add support for PIVOT: https://github.com/trinodb/trino/issues/29404
  • Trino issue #29565, Add SQL/JSON simplified accessor: https://github.com/trinodb/trino/issues/29565
  • Trino issue #22697, Modernize the Trino web UI: https://github.com/trinodb/trino/issues/22697
  • Trino issue #30185, Use bit-packed validity bitmaps for block nulls: https://github.com/trinodb/trino/issues/30185
  • Trino issue #30372, Reduce memory footprint of Parquet writer dictionary encoding: https://github.com/trinodb/trino/issues/30372
  • Trino issue #30355, Fix Delta Lake deletion vector serialization: https://github.com/trinodb/trino/issues/30355
  • Trino issue #30342, Clean up Delta Lake deletion vector sidecars after failed writes: https://github.com/trinodb/trino/issues/30342