F3 - 미래를 위한 오픈소스 데이터 파일 형식, Parquet 이후의 차세대 컬럼 포맷

2026년 6월, Parquet(파케이)과 ORC가 등장한 지 10년이 넘었다. 두 형식은 하드웨어와 워크로드가 지금과는 전혀 달랐던 시대를 위해 만들어졌고, 그 위에 Spark·DataFusion·DuckDB 같은 분석 엔진이 올라왔다. 하지만 새로 등장하는 형식들이 만들어내는 차별점이 점점 미묘해지는 지금, 학계에서 근본적인 답을 내놓으려 한다. F3(Future-proof File Format)가 바로 그것이다. CMU·CMU 출신 공동 연구진이 VLDB와 ACM SIGMOD에서 잇따라 발표했고, 2025년 9월 Proc. ACM Manag. Data에 정식 게재됐다.

F3란 무엇인가 — Parquet 이후의 데이터 파일 형식

F3는 자기기술형(self-describing) 컬럼 저장 포맷이다. 겉보기에는 Parquet·ORC와 같은 범주에 속하지만, 출발선이 다르다. Parquet이 "한 파일 = 한 테이블"의 단순함 위에 분석 엔진과의 호환성 시너지를 만든 반면, F3는 파일 안에 데이터·메타데이터·디코더까지 통째로 담는다. 그래서 파일을 받은 쪽에 네이티브 디코더가 없더라도 Wasm 폴백 디코더로 즉시 읽을 수 있다. MIT 라이선스 연구 프로토타입이며, 현재 프로덕션 사용은 금지되어 있다.

핵심 아이디어: Wasm 디코더를 파일에 내장하다

F3가 다른 형식과 가장 크게 갈라지는 지점이 바로 이 부분이다. 파일 한 개에 Wasm(WebAssembly) 바이너리를 끼워 넣고, 읽는 쪽에 그 디코더가 없으면 즉시 폴백한다. 저장 공간은 킬로바이트 단위로 매우 작다. 새로운 인코딩 방식이 등장하면, 그 디코더를 Wasm으로 빌드해서 파일에 끼우기만 하면 호환성이 따라온다.

// 의사코드: F3 파일 읽기 흐름 (사용자 코드)
// 1. 네이티브 디코더가 있으면 우선 사용
if let Some(native) = env::find_native_decoder(&f3.header) {
    return native.decode(&f3.payload);
}
// 2. 없으면 파일에 내장된 Wasm 디코더로 폴백
let wasm_bytes = f3.embedded_decoder.as_ref();
let module = wasmtime::Module::new(&wasm_bytes)?;
module.decode(&f3.payload)

파일 형식 정의는 FlatBuffer 기반이다. Wasm 디코더가 무엇을 디코딩해야 할지 파일 메타데이터가 모두 알려주므로, 디코더 로직을 외부 SDK에 의존하지 않아도 된다.

빌드와 디렉터리 구조 한눈에

F3 저장소는 fff-core, fff-encoding, fff-format, fff-ude-wasm 같은 서브크레이트로 쪼개져 있다. fff-ude*의 UDE는 User-Defined-Encoding의 약자로, 사용자가 정의한 인코딩을 위한 Wasm 디코딩 구현이 들어 있다.

# Intel + Debian 12에서만 테스트됨
git submodule update --init --recursive
./scripts/setup_debian.sh
cargo build -p fff-poc     # PoC 패키지 빌드
cargo test -p fff-poc      # 단위 테스트 실행

벤치마크는 fff-bench/examples/ 아래에 마이크로·E2E 실험 코드가 함께 묶여 있고, 논문 결과를 재현하는 절차는 doc/paper_reproduction.md에 정리되어 있다.

Parquet·ORC vs F3 — 무엇이 다른가

| 항목 | Parquet | ORC | F3 |

|------|---------|-----|-----|

| 출시 | 2013년 | 2013년 | 2025년(논문) |

| 디코더 | 외부 SDK 필요 | 외부 SDK 필요 | Wasm 내장 폴백 |

| 새 인코딩 추가 | 표준 합의 후 | 표준 합의 후 | Wasm 모듈만 끼우면 끝 |

| 파일당 테이블 | 1개 | 1개 | 1개(개선 목표 아님) |

| 분석 엔진 호환 | Spark·DataFusion·DuckDB | Hive·Spark | PoC 단계 |

| 라이선스 | Apache 2.0 | Apache 2.0 | MIT |

핵심 차이는 "디코더를 누가 들고 있느냐"다. Parquet은 호환성을 분석 엔진이 책임지고, F3는 파일이 책임진다. HN 토론에서도 "언어별 SDK에 의존하지 않고 Wasm 폴백을 가진다는 점은 꽤 기발하다"는 반응이 나왔다.

보안과 디코더라는 양면 — HN의 우려

F3의 가장 큰 혁신이자 가장 큰 약점이 바로 보안이다. "공격자가 일부러 손상된 파일을 만들 필요도 없이, 데이터 파일 자체에 공격 코드를 넣으면 되는 건가?"라는 HN 의견이 시사적이다. PDF가 내장 자바스크립트로 고생한 역사가 있고, F3는 디코더라는 더 민감한 위치에 Wasm을 박는 셈이다. 동시에 "디코더가 무엇으로 작성됐는지 검증 가능한가?", "모든 형식에 유일한 정답 디코딩 단계가 있는 건 아니다"라는 실용적 의문도 제기됐다. 단순한 압축·스키마 수준을 넘어 코드를 들고 다닐 때, 신뢰 경계가 어디서 끊기는지는 아직 해결되지 않은 숙제다.

F3를 둘러싼 형제 프로젝트들: Vortex·Lance

F3는 혼자 등장한 게 아니다. VLDB 2024 논문 pvldb/vol17/p148-zeng.pdf가 Parquet의 단점을 정리했고, 그 다음 해에 F3·Vortex·Lance가 같은 문제의식을 공유하며 나왔다.

• Vortex: Parquet의 블랙박스 인코더를 투명한 인코딩으로 바꿔 확장성과 성능에 집중한다. 대량 스캔과 임의 접근을 동시에 잡는 게 목표. LangChain의 smithDB가 Vortex 기반으로 다시 만들어져 큰 속도 향상을 봤다고 한다.
• Lance: 흥미로운 아이디어가 여러 개 들어 있고, ML 워크로드 친화적 방향으로 발전 중.
• F3: 호환성과 미래보증에 무게중심. 디코더 내장으로 "어디서든 읽힌다"를 보장.

세 프로젝트가 각자 다른 트레이드오프를 택하고 있다는 점이 흥미롭다.

결론: 누가 지금 F3를 만져봐야 하는가

F3는 아직 프로덕션 사용이 금지된 연구 프로토타입이다. Intel + Debian 12에서만 빌드가 검증됐고, ACM SIGMOD·VLDB 학회 커뮤니티 외엔 사용자 기반이 거의 없다. 바로 실무에 쓸 수 있는 도구는 아니다. 그렇다면 누가 만져봐야 할까? 컬럼 저장 포맷의 진화 방향을 학회 논문 수준에서 따라가고 싶은 개발자, Parquet이 더 이상 답이 아닐 때를 대비해 차세대 후보를 미리 평가해 보고 싶은 데이터 플랫폼 엔지니어, 그리고 Wasm 기반 디코더 호환성이라는 아이디어가 실제 워크로드에서 어디까지 먹히는지 직접 실험해 보고 싶은 사람에게 F3는 의미 있는 학습 자료다. 2026년 6월 기준으로, F3는 Parquet을 대체할 수 없다. 하지만 Parquet이 2013년에 그랬듯, 지금 시작된 프로토타입이 10년 뒤 분석 엔진의 표준이 될 가능성을 완전히 배제할 수는 없다.