--- title: "KORE, Parquet보다 더 작고 빠르다는 새 컬럼형 바이너리 포맷 공개" published: 2026-05-30T20:54:22.000Z canonical: https://jeff.news/article/3424 --- # KORE, Parquet보다 더 작고 빠르다는 새 컬럼형 바이너리 포맷 공개 KORE는 분석 워크로드를 겨냥한 오픈소스 바이너리 파일 포맷으로, Parquet 대비 더 높은 압축률과 빠른 쿼리 성능을 주장한다. 다만 현재 공개된 내용에는 일부 구현이 스텁 처리됐다는 언급도 있어, 벤치마크 숫자는 흥미롭지만 실제 도입 전 검증이 필수다. - KORE는 분석 워크로드용 바이너리 파일 포맷을 표방하는 새 오픈소스 프로젝트임 - 버전은 v0.1.0이고, “빅데이터용으로 가장 빠르고 가장 압축이 잘 되는 컬럼형 포맷”이라는 꽤 센 주장을 내세움 - 타깃은 일반 파일 저장이 아니라 Spark 같은 분석 시스템에서 큰 테이블을 빠르게 읽고 거르는 쪽임 - README에서 가장 눈에 띄는 숫자는 압축률 38% vs Parquet 63%임 - KORE 쪽 설명 기준으로는 같은 데이터를 저장할 때 KORE가 Parquet보다 훨씬 작게 저장된다는 의미임 - 압축률이 낮을수록 원본 대비 크기가 작다는 뜻이라, 스토리지 비용과 스캔 I/O 양에 바로 영향을 줌 - 성능 주장도 꽤 공격적임. 컬럼 프루닝(column pruning)과 프레디킷 푸시다운(predicate pushdown)으로 131배 쿼리 속도 향상을 말함 - 컬럼 프루닝은 필요한 열만 읽는 최적화임 - 프레디킷 푸시다운은 필터 조건을 파일 읽기 단계로 내려보내서 필요 없는 데이터를 빨리 버리는 방식임 - 둘 다 Parquet 같은 컬럼형 포맷이 이미 강하게 활용하는 최적화라, KORE가 정말 차이를 내려면 파일 구조나 메타데이터 설계에서 뭔가 더 세게 먹히는 지점이 있어야 함 > [!IMPORTANT] > 131배 속도 향상과 38% 압축률은 공유하기 좋은 숫자지만, 아직 README 기준 주장에 가깝다. 실제 데이터셋, 쿼리 패턴, Spark 실행계획에서 재현되는지 확인하기 전에는 도입 판단으로 바로 쓰면 위험함. - 무손실 검증도 언급됨 - 40만 개 이상의 셀을 테스트했고 데이터 손실이 없었다고 설명함 - 파일 포맷에서 “빠르다”보다 먼저 필요한 게 “읽고 쓴 값이 정확히 돌아오냐”라서, 이 항목 자체는 방향이 맞음 - Spark 통합을 제공한다는 점은 실사용 관점에서 꽤 중요함 - PySpark로 읽기와 쓰기를 지원한다고 되어 있고, 자세한 문서는 python/README.md를 보라고 안내함 - 빅데이터 포맷은 단독 라이브러리보다 Spark, 데이터레이크, 쿼리 엔진에 붙는 순간부터 진짜 평가가 시작됨 - 다만 현재 공개 상태는 조심해서 봐야 함 - README에는 Cargo 메타데이터, 라이선스, CI, cargo test, cargo clippy 같은 배포 체크리스트가 남아 있음 - 특히 “일부 긴 구현은 초기 export에서 스텁 처리됐다”는 문장이 있음 - 런타임 기능이 필요한 경우 unimplemented!() 스텁을 실제 구현으로 바꾸라는 안내도 있어서, 아직 완성된 포맷 생태계라기보다는 초기 공개본에 가까워 보임 > [!WARNING] > README에 스텁 구현 언급이 있는 프로젝트는 벤치마크 숫자보다 먼저 코드 경로를 확인해야 함. 읽기, 쓰기, 필터링, 타입 처리 중 어느 부분이 실제 구현인지부터 봐야 삽질을 줄일 수 있음. - 그래서 이 프로젝트를 보는 현실적인 포인트는 “Parquet 대체재 등장!”보다 “컬럼형 포맷 실험 하나가 꽤 야심찬 숫자를 들고 나왔다”에 가까움 - Parquet은 포맷 자체보다 생태계가 강한 기술임 - KORE가 의미 있으려면 압축률과 쿼리 속도뿐 아니라 타입 호환성, 스키마 진화, 병렬 읽기, 장애 케이스, 여러 엔진 지원까지 넘어야 함 - 그래도 데이터 엔지니어라면 테스트 데이터 하나 던져보고 숫자가 어디까지 나오는지 확인해볼 만한 떡밥은 충분함 --- ## 기술 맥락 - KORE가 노리는 지점은 “더 작은 파일, 더 적은 스캔, 더 빠른 분석”이에요. 분석 시스템에서는 CPU 연산보다 디스크와 네트워크에서 데이터를 얼마나 덜 읽느냐가 병목이 되는 경우가 많거든요. - Parquet과 비교하는 이유도 명확해요. Parquet은 이미 컬럼형 저장, 압축, 컬럼 프루닝, 프레디킷 푸시다운을 제공하는 강한 기준점이라서, 새 포맷이 이 시장에 들어오려면 “우리도 지원함”이 아니라 “특정 조건에서 확실히 더 낫다”를 보여줘야 해요. - PySpark 통합은 도입 장벽을 낮추려는 선택이에요. 데이터 팀 입장에서는 Rust 라이브러리만 있는 포맷보다, 기존 Spark 파이프라인에서 바로 읽고 쓸 수 있는 포맷이 훨씬 테스트하기 쉽거든요. - 다만 초기 공개본에 스텁 구현이 있다는 건 꽤 큰 제약이에요. 파일 포맷은 벤치마크보다 엣지 케이스가 무서운데, 타입 변환, 누락값, 스키마 변경, 큰 파일 분할 읽기 같은 부분이 실제 구현인지 확인해야 해요. - 결국 지금 단계의 KORE는 운영 도입 후보라기보다 검증할 만한 실험체에 가까워요. 성능 숫자가 재현되고 Spark 통합이 안정적이면 재미있어지지만, Parquet의 생태계 무게를 넘으려면 시간이 더 필요해요. ## 핵심 포인트 - KORE는 빅데이터 분석용 컬럼형 바이너리 포맷을 표방하며 0.1.0 버전으로 공개됨 - 압축률 38%를 주장하며 Parquet의 63%보다 작다고 설명함 - 컬럼 프루닝과 프레디킷 푸시다운을 통해 131배 쿼리 속도 향상을 주장함 - PySpark 읽기와 쓰기 통합을 제공한다고 하며 40만 개 이상 셀에 대해 무손실 검증을 했다고 밝힘 - README에는 일부 긴 구현이 초기 공개본에서 스텁 처리됐다는 주의점이 있음 ## 인사이트 숫자만 보면 혹할 만한데, ‘일부 구현이 스텁’이라는 문장이 꽤 크다. Parquet을 대체하겠다는 포맷은 항상 많았지만, 진짜 승부는 벤치마크보다 생태계, 호환성, 실패 케이스, 장기 유지보수에서 난다.