F3: 차세대 오픈 소스 데이터 파일 형식

F3는 Apache Parquet 및 ORC와 같은 기존 형식의 경직성을 해결하기 위해 설계된 차세대 오픈 소스 컬럼형 데이터 파일 형식의 연구 프로토타입입니다. 주요 혁신은 임베디드 WebAssembly (Wasm) 디코더를 사용하는 것으로, 이를 통해 네이티브 디코더를 사용할 수 없거나 새로운 인코딩 방식이 도입될 때도 파일이 자기 기술적(self-describing)이며 읽기 가능한 상태를 유지할 수 있도록 합니다.

임베디드 Wasm 디코더를 통한 형식 경직성 해결

F3는 데이터를 디코딩하는 데 필요한 로직을 파일 자체에 직접 임베디드함으로써 장기적인 상호 운용성과 확장성을 보장합니다. 전통적인 형식은 특정 인코딩 방식을 구현하기 위해 외부 SDK나 라이브러리에 의존하는 반면, F3는 폴백(fallback) 디코더 역할을 하는 Wasm 바이너리를 포함합니다.

이 접근 방식은 다음과 같은 몇 가지 기술적 이점을 제공합니다:

• 전방 호환성: 개발자는 파일 형식 사양의 글로벌 업데이트나 새로운 SDK의 광범위한 채택을 기다리지 않고도 새로운 인코딩 방식을 구현할 수 있습니다.
• 플랫폼 독립성: Wasm은 이식 가능한 바이너리 명령 형식이기 때문에, 임베디드 디코더는 Wasm 런타임이 있는 모든 플랫폼에서 실행될 수 있습니다.
• 최소한의 오버헤드: 프로젝트 문서에 따르면 이러한 디코더를 임베디드하는 데는 불과 몇 킬로바이트의 추가 저장 공간만 필요합니다.

기존 컬럼형 형식과의 비교

F3는 Parquet와 같은 "차세대" 형식을 계승하는 위치에 있습니다. 이 프로젝트는 현재의 하드웨어 및 워크로드 환경으로 진화한 이후, 이전 형식들에 내재된 레이아웃의 단점을 보완하는 것을 목표로 합니다.

새로운 인코딩 방식을 추가하기 위한 범용 API를 제공함으로써, F3는 데이터 처리 또는 컴퓨팅 패러다임이 변화할 때마다 완전히 새로운 파일 형식을 만들 필요가 없도록 하려는 의도입니다. 형식의 구조는 직렬화된 데이터에 효율적으로 접근할 수 있는 방법을 제공하는 FlatBuffers를 사용하여 정의됩니다.

기술적 구현 및 연구 상태

F3는 현재 SIGMOD 2026 논문과 관련된 연구 프로토타입입니다. 프로덕션용으로 의도된 것은 아닙니다. 현재 구현은 Rust로 작성되었으며 다음과 같은 몇 가지 핵심 구성 요소를 포함합니다:

• fff-poc: 주요 개념 증명(proof-of-concept) 코드.
• fff-ude-wasm: Wasm을 통한 사용자 정의 인코딩(User-Defined-Encoding, UDE) 구현.
• fff-bench: 저장 레이아웃의 효능을 검증하는 데 사용되는 벤치마크 및 실험 세트.

커뮤니티 비판 및 기술적 트레이드오프

임베디드 디코더라는 개념은 일부에 의해 SDK 의존성 문제를 해결하는 "천재적인" 솔루션으로 간주되지만, 다른 기술 관찰자들은 보안 및 장기적 생존 가능성에 대해 상당한 우려를 제살기합니다:

보안 및 공격 표면

비판론자들은 데이터 형식에 능동적 실행 레이어(VM)를 도입하는 것이 공격 표면을 크게 증가시킨다고 주장합니다. 구체적으로 다음과 같은 우려가 있습니다:

• 원격 코드 실행 (RCE): 파일 내부에서 Wasm 바이너리를 실행할 수 있는 능력은 악의적인 목적으로 악용될 수 있습니다.
• 자원 소모 (Resource Exhaustion): 악의적으로 제작된 Wasm 디코더는 자원 소모를 통해 서비스 거부 공격(DoS)을 유발할 수 있습니다.

장기적 아카이브 우려

콜드 스토리지 및 장기 아카이브(예: 10년 이상)의 경우, 일부는 바이너리 디코더보다 "단순하고 문서화가 잘 된 바이트 사양"이 더 바람직하다고 주장합니다. Wasm 인터프리터에 의존하는 것은 먼 미래에 Wasm 런타임의 지속적인 가용성 및 성능에에 대한 의존성을 유생합니다.

기능적 제한

일부 관찰자들은 디코더가 비트스트림을 변환하는 문제만 해결할 뿐, 디코딩된 데이터가 어떻게 사용되는지에 대한 상 higher-level 문제를 해결하지 못한다고 지적합니다. F3가 효율적인 mmap이나 임베디드 Wasm 블롭(blob)의 실행을 요구하지 않고도 부분 탐색(partial seeking)을 것을 지원하는지에 대한 우려가 제기되었습니다.

"각 파일에 디코더를 임베디드하는 것은 최소한의 저장 공간(킬로바이트 단위)을 필요로 하며, 네이티브 디코더를 사용할 수 없는 경우 모든 플랫폼에서 호환성을 보장합니다."

"WASM 바이너리 안에 디코딩 로직을 넣는 것은 콜드 스토리지에 무엇이 되어야 할 능동적 실행 레이어를 도입하는 것입니다." extthought}```json}{