Iceberg

Iceberg를 선택해야 하는 신호

원문이 제시하는 Iceberg 선택 기준은 다음과 같다. 여러 쿼리 엔진을 동시에 운영하는 경우(예: Trino와 Spark를 함께 쓰거나, Flink로 적재하고 Athena로 조회하는 구조), 아키텍처 팀 차원에서 벤더 독립성이 필수 요건인 경우, 데이터가 성장하며 파티셔닝 전략이 바뀔 것으로 예상되어 파티션 진화가 필요한 경우, AWS 네이티브 서비스(Athena, Glue, EMR)를 주로 쓰며 Iceberg 지원이 강한 경우, REST 카탈로그·Nessie·Polaris 등 폭넓은 카탈로그 생태계를 원하는 경우다.

이 기준들의 공통점은 결국 '하나의 엔진/벤더에 묶이고 싶지 않다'는 축과 '데이터/파티셔닝 요구사항이 앞으로 계속 바뀔 것이다'는 축으로 요약된다.

Delta Lake가 더 맞을 수도 있는 신호 (보조 맥락)

반대로 이미 Databricks를 주력 플랫폼으로 쓰고 있거나 채택할 계획이라면, Spark 중심 팀으로 가장 매끄러운 통합을 원한다면, 기존 Delta 테이블이 있고 마이그레이션할 뚜렷한 이유가 없다면, OPTIMIZE·VACUUM 같은 빌트인 최적화 명령을 선호한다면 Delta Lake가 더 맞을 수 있다고 원문은 설명한다. 이 내용은 Delta Lake 자체가 스코프 밖이므로 세부 사항을 암기할 필요는 없고, 'Iceberg가 항상 정답은 아니며 이미 특정 플랫폼에 깊이 투자한 조직에서는 그 플랫폼의 네이티브 포맷이 합리적일 수 있다'는 판단 축만 기억하면 충분하다.

포맷보다 운영 규율 — 저자의 핵심 주장

원문 결론부의 핵심 메시지는 '포맷 자체가 병목이 아니라, 그 포맷을 제대로 유지보수하는 운영 규율이 병목'이라는 것이다. 저자는 컴팩션을 한 번도 실행하지 않아 성능이 나빠진 Iceberg 배포와, VACUUM(오래된 미참조 파일 정리)을 한 번도 스케줄링하지 않아 스토리지 비용이 눈덩이처럼 불어난 Delta Lake 배포를 모두 목격했다고 말한다.

이 학습 프로그램 관점에서 이 주장을 Iceberg에 대입하면, 모듈 5에서 다룬 컴팩션(rewrite_data_files)과 스냅샷 만료(expire_snapshots)를 정기적으로 스케줄링하지 않으면, 아무리 아키텍처가 훌륭해도 성능이 서서히 저하되거나 스토리지 비용이 조용히 늘어난다는 실전 함의로 이어진다. 즉 Iceberg를 도입할 때는 '어떤 포맷을 쓸까'만큼이나 '누가, 얼마나 자주 컴팩션과 만료를 실행할 것인가'를 설계 단계에서 함께 정해야 한다.

판단을 미루지 않기 — '10TB 미만이면 아무거나' 기준 검토

원문은 '총 데이터가 10TB 미만이면 차이는 학술적인 수준이니 아무거나 골라서 진행하라', '2년 미만 수명 프로젝트라면 그 사이 UniForm 같은 호환 레이어가 논쟁 자체를 무의미하게 만들 수도 있다'는 경험칙을 제시한다.

이 기준은 실무적으로 유용한 조언이지만 공식적으로 검증된 임계값이 아니라 저자 개인의 관찰에 근거한 경험칙임을 분명히 해야 한다. 특히 모듈 2에서 다뤘듯 쿼리 플래닝 성능 차이는 '데이터 총량'보다 '파일 개수'에 더 크게 좌우된다. 즉 데이터가 5TB뿐이더라도 매우 작은 파일 수백만 개로 쪼개져 있다면(예: IoT 이벤트를 초 단위로 적재), 원문의 '10TB 미만이면 무관하다'는 조언이 적용되지 않을 수 있다. 총 데이터 크기라는 단일 지표보다, 파일 개수·커밋 빈도·쿼리 패턴(포인트 룩업이 많은가, 풀스캔이 많은가)을 함께 살펴 판단하는 것이 더 정확하다.

원문이 반복해서 강조하는 실전 교훈은 '포맷 선택에 몇 개월을 쓰지 말고 파이프라인을 만들어라'는 것이며, 이는 두 포맷의 핵심 기능(ACID, 타임트래블, 기본 스키마 진화)이 실질적으로 동등하다는 사실에 근거한 합리적 조언이다.