Parquet 10년 지배 후, WASM이 그것을 흔들 수 있을까?
당신은 8년 동안 쌓아온 Parquet 테이블을 하나 가지고 있습니다. 데이터 크기는 그리 크지도 작지도 않은 300GB 정도. 어느 날 새로운 요구사항이 들어옵니다: 이 테이블에 대해 포인트 쿼리를 수행하라 — 전체 스캔 말고, 기본 키로 몇십 행만 골라내는 것. 시도해보니 Parquet가 못 하는 건 아닌데, 매번 row group의 column chunk에서 대상 페이지를 뒤져야 하고, 페이지 단위는 쉽게 수십만 행에 달해 I/O 오버헤드가 요구사항과 전혀 맞지 않습니다.
당신은 생각합니다: 컬럼형 저장 포맷이 10년 넘게 발전했는데, 어떻게 제대로 된 랜덤 액세스 하나 못 하는 거지?
이것이 바로 CMU 데이터베이스 그룹이 SIGMOD에서 F3(Future File Format)를 발표한 출발점입니다. 그리고 바로 이 출발점이 포맷 전쟁에서 가장 민감한 줄을 건드렸습니다.
새 포맷, 오래된 문제
F3가 해결하려는 문제를 한마디로: 기존 컬럼형 저장 포맷(Parquet, ORC)은 Hadoop 시대에 탄생했으며, 그 저장 레이아웃과 진화 메커니즘이 현재의 하드웨어와 워크로드에 맞지 않는다. Parquet의 row group 단위는 거칠고, 메타데이터 계층은 평면적이며, 컬럼 인코딩은 스펙에 고정되어 있습니다 — 새로운 인코딩이 도입되려면 모든 reader 구현이 업데이트되기를 기다려야 합니다. F3 논문이 인용한 한 데이터 세트는 꽤 시사적입니다: 현재 가장 널리 사용되는 Parquet 버전은 여전히 2013년의 v1입니다.
Parquet 자신조차 Parquet 자신을 대체하지 못했습니다.
F3의 해법은 양방향입니다. 레이아웃 측면에서는 더 정교한 계층 구조를 도입했습니다: IOUnit(I/O 기본 단위) → EncUnit(인코딩 기본 단위, 기본값 64K 행) → 선택적 서브 EncUnit 벡터. 이 계층 구조는 reader가 읽을 때 더 세밀한 프로젝션을 수행할 수 있게 합니다 — 특정 컬럼에서 몇천 행만 가져오고 싶다면? EncUnit 인덱스를 순회하며 관련 없는 블록을 건너뛰면 됩니다.
확장성 측면에서 F3의 핵심 아이디어는 디코더를 WASM 바이너리 형태로 파일 자체에 임베딩하는 것입니다. 각 EncUnit은 WASM ID를 표시하여 파일 끝에 저장된 디코더를 가리킬 수 있습니다. reader가 로컬에서 이 인코딩을 인식하지 못하면 WASM 모듈을 직접 로드하여 디코딩합니다 — reader 버전을 업그레이드할 필요도, 커뮤니티 합의를 기다릴 필요도 없습니다. 논문에 따르면 WASM 디코더 크기는 KB 수준으로, “무시할 수 있는 저장 비용(negligible storage cost)“이라고 합니다.
이것이 F3의 두 장의 패입니다: 더 정밀한 랜덤 액세스, 그리고 WASM으로 호환성 교착 상태를 우회하는 것.
데이터 이면에 있는 것
F3의 벤치마크는 Parquet, ORC, Vortex, Lance, Nimble을 비교했습니다. 논문의 실험에서 몇 가지 트렌드를 볼 수 있습니다:
- 랜덤 액세스: F3의 포인트 쿼리 지연 시간은 Parquet보다 현저히 낮으며, 특히 적은 수의 컬럼과 적은 수의 행만 필요한 시나리오에서 두드러집니다. 이것은 마법이 아닙니다 — EncUnit 계층이 본질적으로 더 작은 I/O 단위를 지원하기 때문입니다.
- 압축률과 압축 해제 속도: 대체로 Parquet와 같은 수준입니다. F3는 기본적으로 64K 행마다 EncUnit에 Cascade 인코딩(Vortex의 기본 인코딩과 유사)을 Zstd/LZ4 압축과 함께 사용합니다. 이기지도, 지지도 않았습니다.
- WASM 디코딩 오버헤드: WASM 디코더를 사용하면 네이티브 디코딩보다 한 단계 느리지만, 논문은 이 격차가 수용 가능한 범위 내에 있다고 주장합니다. 여기서는 엔지니어링적 판단이 필요합니다: WASM 디코더의 존재 의미는 ‘파일을 읽을 수 있음을 보장’하는 것입니다. 이것은 폴백이지, 가속기가 아닙니다.
종합하면 F3는 벤치마크에서 “어떤 차원에서는 개선되었고, 전체적으로 Parquet에 뒤지지 않는다”는 포즈를 취하고 있습니다. SIGMOD 논문으로서 이 결과는 합격입니다. 포맷 대체 전쟁으로서 이 결과는 아직 부족합니다.
호환성: 진정한 해자
HN 토론에서 가장 높은 표를 받은 댓글은 vouwfietsman의 글입니다. 그는 매우 잔혹하지만 반박하기 어려운 말을 했습니다:
Parquet is unfortunately very good just by virtue of being first, and so widely supported.
Parquet의 생태계 지위가 얼마나 견고한가요? 몇 가지 사실을 나열하면 명확해집니다: Spark, DuckDB, Pandas, Polars, Snowflake, BigQuery, Redshift Spectrum, AWS Athena, Trino, Presto, ClickHouse(외부 테이블)…… 이름을 댈 수 있는 거의 모든 데이터 도구가 Parquet를 네이티브로 지원합니다. 그 명세는 개방되어 있지만, 20여 개 주요 구현체의 반복적인 조율을 거치며 사실상의 표준을 형성했습니다. 당신이 생성한 Parquet 파일은 어떤 도구로도 읽을 수 있습니다 — 이것은 커뮤니티의 10년치 버그 수정과 상호운용성 적응이 쌓아올린 것입니다.
여기서 역설이 발생합니다: F3는 WASM으로 “새 인코딩을 구형 reader가 인식하지 못하는” 호환성 문제를 해결하려 하지만, 실제로 새 포맷을 가로막는 것은 생태계 접속 비용입니다.
한 회사가 F3로 전환하려면 무엇이 필요할까요?
- 모든 다운스트림 쿼리 엔진에 F3 reader 추가(WASM 폴백은 EncUnit만 디코딩할 수 있을 뿐, 완전한 reader 구현을 대체할 수 없습니다 — 파일 헤더 파싱, 메타데이터 탐색, 술어 푸시다운, 프로젝션 가지치기, 이 모두가 네이티브 코드를 필요로 합니다).
- 모든 데이터 파이프라인(ETL/ELT)이 F3 writer 지원.
- 모든 데이터 거버넌스 도구(카탈로그, 스키마 레지스트리, 계보 추적)가 F3 메타데이터 파싱 가능.
- 데이터 공유 외부 협력사가 F3를 읽을 수 있어야 함.
이것은 WASM 디코더 하나로 해결될 일이 아닙니다. Parquet의 해자는 10년간 축적된 생태계 망입니다.
WASM 솔루션의 텐션
F3의 WASM 설계는 HN에서 치열한 서브 디스커션을 촉발했으며, 쟁점은 세 가지 층위에 집중되었습니다.
첫 번째 층위는 보안성. 파일 내 임베디드 실행 코드. WASM 샌드박스가 아무리 성숙해도, 엔지니어의 보안 신경을 건드리는 것은 당연합니다. 누군가는 PDF의 JavaScript를 유추했습니다 — 표준이 이 기능을 설계했지만, 이성적인 뷰어라면 기본적으로 비활성화합니다. F3 지지자들은 WASM 디코더는 pure function이며 I/O 능력이 없고, 샌드박스가 명령어 수와 메모리 상한을 제한할 수 있다고 반박합니다. 그러나 데이터 엔지니어링 워크플로는 종종 신뢰할 수 없는 출처의 데이터 파일을 포함하며, 임의의 WASM 실행을 허용하는 것은 많은 보안 팀이 받아들이지 않을 선택지입니다.
두 번째 층위는 성능 포지셔닝. vouwfietsman이 예리하게 지적했습니다: 컬럼형 저장 포맷의 핵심 가치는 순차 스캔으로 분석 성능을 얻는 대신 랜덤 액세스를 희생하는 것입니다. F3는 랜덤 액세스 개선을 주요 셀링 포인트로 내세우지만, 랜덤 액세스 자체는 컬럼형 저장의 설계 목표가 아닙니다. 랜덤 액세스를 최적화하면서 전체 테이블 스캔이 느려진다면(단지 WASM 디코딩 경로라도), 핵심 강점을 보조 능력과 맞바꾸는 셈입니다.
세 번째 층위는 기술 선택의 자기 정합성. F3의 메타데이터 계층은 Google의 FlatBuffers를 사용하여 스키마와 파일 레이아웃 정보를 직렬화합니다. WASM 디코더는 호스트 언어와 WASM 메모리 사이에서 데이터를 주고받아야 하며, FlatBuffers 파싱 자체도 일정한 오버헤드를 필요로 합니다. 어떤 댓글 작성자는 WASM 런타임 + FlatBuffers 직렬화/역직렬화의 조합이 읽기 경로에 두 겹의 추상화 오버헤드를 추가하며, 이것이야말로 컬럼형 저장이 최대한 간소화하고자 하는 부분이라고 지적했습니다.
이러한 의문들은 F3의 설계가 틀렸다는 뜻은 아닙니다. 그러나 이들은 하나의 핵심 명제를 가리킵니다: F3가 해결하려는 것은 포맷 진화의 부차적 모순이지, 주요 모순이 아니다. 주요 모순은 “모두가 교체할 의향을 가지게 하는 방법”이지, “새 인코딩을 어떻게 적용할지”가 아닙니다.
역사의 메아리
HN 댓글에는 xkcd #927(“Standards”)를 붙인 사람도 있고, OpenDoc의 운명 — 기술적으로 더 우수했지만 결국 네트워크 효과에 패배한 파일 포맷 — 을 언급하는 사람도 있었습니다. 그렇게 비관적일 필요는 없다고 보는 사람도 있습니다: F3가 특정 세분 시장에서 Parquet가 제공할 수 없는 가치(자주 랜덤 액세스가 필요한 온라인 특성 저장소, 혹은 커스텀 인코딩이 필요한 수직적 도메인 등)를 제공한다면, 전체 시장을 이길 필요 없이 자신의 생태적 지위에서 자리 잡으면 된다는 것입니다.
필자는 이 두 판단이 상호 배타적이지 않다고 보는 쪽에 가깝습니다. 포맷 대체의 역사는 실제로 일방적으로 ‘호환성 우선’론을 지지하지만, 역사상 ‘디코더를 파일에 임베딩하는’ 설계는 없었습니다. WASM의 등장은 크로스 플랫폼 실행 코드의 비용 구조를 바꾸었습니다 — 10년 전에는 파일 안에 샌드박스 실행 환경을 심는 것은 상상할 수 없었지만, 오늘날에는 단지 wasmtime::Module::new() 한 줄입니다.
F3가 Parquet를 대체하지는 못할지 모르지만, F3가 제안한 WASM 디코더 패러다임은 Parquet나 다른 포맷에 흡수될 가능성이 있습니다. 최고의 결말은 대체가 아니라, 오염 — 예전 포맷이 당신의 좋은 설계를 배워가게 하고, 당신은 다음 무인지대를 향해 달려가는 것.
현재 트렌드로 보면
F3는 현재도 연구 프로토타입입니다 — README는 첫 문장에서 “프로덕션 환경에서 사용해서는 안 됨”을 선언하고, GitHub 커밋은 4회에 불과하며, 벤치마크 재현 스크립트도 완전하지 않습니다. ‘엔지니어링 팀이 진지하게 대체 솔루션으로 평가할 수 있는’ 상태까지는 아직 긴 엔지니어링화 거리가 남아 있습니다.
업계 트렌드로 보면, Parquet의 지위는 단기간에 거의 흔들리지 않을 것입니다. Iceberg, Delta Lake, Hudi 같은 개방형 테이블 포맷의 부상이 Parquet를 레이크하우스 아키텍처의 하층부에 더욱 고정시키고 있습니다 — 테이블 포맷 전쟁은 위쪽 계층으로 이동 중이며, 파일 포맷은 오히려 더 깊이 ‘록인’되었습니다. 한쪽에서 Iceberg로 전환하면서 동시에 하층 파일 포맷을 바꾸는 것은 이중의 마이그레이션 비용이기 때문에 가능성이 낮습니다.
그러나 F3가 제기한 질문은 가치 있습니다. Parquet의 진화 병목은 실재합니다 — 10년 동안 움직이지 않은 v1이 여전히 세계를 지배하고 있다는 것은 정상적인 상태가 아닙니다. WASM 디코더라는 아이디어는, 설령 결과적으로 F3를 성공시키지 못하더라도, 다른 포맷의 어느 버전 스펙을 성사시킬 가능성이 있습니다.
다시 말해: 이것은 Parquet의 장례식이 아닐지 모르나, 차세대 컬럼형 저장 포맷의 첫 번째 태동일 수는 있습니다.
참고: F3 SIGMOD 논문 · GitHub 저장소 · HN 토론