파이썬 데이터 직렬화, Apache Arrow와 Feather로 빠르게 처리하는 법

파이썬 데이터 직렬화, Apache Arrow와 Feather로 빠르게 처리하는 법

🚀 파이썬에서 pyarrow.Table과 Feather로 메모리 복사 없이 공유하고 분석 속도 높이는 비법

파이썬으로 데이터 다루다 보면 슬슬 이런 고민을 하게 됩니다.
데이터프레임은 판다스에 있고, 일부 처리는 폴라스(Polars)나 DuckDB, GPU 쪽 처리는 PyTorch나 cuDF로 넘기고 싶은데, 옮길 때마다 복사되고 변환되면서 속도가 확 떨어지는 느낌.
파일로 저장해도 CSV처럼 느리고, 파이썬 객체 피클링은 언어 간 공유가 잘 안 되고, 대용량 처리에는 뭔가 답답하죠.
이 글은 그런 병목을 하나씩 줄여 주는 핵심 포맷인 Apache Arrow와 Feather를 정리해 둔 내용입니다.
Arrow는 열 지향(columnar) in-memory 포맷으로, 서로 다른 분석 도구와 언어 사이에서 데이터를 복사 없이 주고받도록 설계된 표준입니다.
pyarrow.Table은 이 Arrow 메모리 레이아웃을 파이썬에서 그대로 다룰 수 있게 해주는 테이블 객체이고, 덕분에 판다스, 폴라스, DuckDB 같은 엔진과 데이터를 빠르게 교환하거나 GPU 분석 라이브러리 쪽으로 넘길 때도 유리합니다.
또한 Arrow는 IPC(Inter-Process Communication) 포맷을 통해 테이블을 파일로 저장하고 다시 읽어올 수 있는데, 이게 우리가 흔히 ‘Feather’라고 부르는 .feather / .arrow 형태의 바이너리 파일입니다.
Feather v2는 사실상 Arrow IPC 파일 포맷과 동일하다고 공식적으로 안내되고 있고, CPU 메모리에만 한정되지 않고 다양한 언어(R, Python 등) 간 데이터프레임을 아주 빠르게 교환하도록 만들어졌습니다.
게다가 Arrow 쪽은 DLPack을 통한 제로카피(또는 거의 제로에 가까운) 전달 경로도 지원하는데, 이 덕분에 텐서/배열 기반 라이브러리(PyTorch, CuPy 등)와의 상호운용성까지 같이 열립니다.
즉 “붙여넣는 순간 복사”가 아니라 “같은 버퍼를 같이 본다”에 더 가까운 방향으로 가고 있는 거죠.

여기서는 파이썬 데이터 직렬화 포맷 묶음 중에서도 Arrow / Feather 조합을 중심으로 살펴봅니다.
구체적으로는 pyarrow.Table이라는 구조가 무엇인지, 왜 “열지향 in-memory 포맷”이 중요한지, Arrow IPC / Feather 파일이 무슨 차이를 가지는지, 그리고 DLPack을 활용한 제로카피 공유가 어떤 식으로 실제 워크플로우에서 시간을 아껴주는지까지 단계별로 정리합니다.
빅데이터, ETL 파이프라인, 머신러닝/딥러닝 전처리 어느 쪽에 있어도 체감 차이가 큰 부분이라서, 특히 판다스 2.x 이후 Arrow 기반 타입을 적극적으로 쓰는 흐름이 궁금했다면 꽤 도움이 될 겁니다.

일반적인 데이터 처리 루틴을 떠올려 보면 “읽기 → 가공 → 전달 → 저장” 흐름이 반복됩니다.
이 과정에서 매번 직렬화/역직렬화(serialize/deserialize)를 거치게 되는데, 이게 바로 성능을 갉아먹는 주범입니다.
Arrow는 이 직렬화 비용 자체를 낮추는 방향으로 만들어졌습니다.
하나는 공유 가능한 열 지향 메모리 레이아웃(pyarrow.Table)이고, 다른 하나는 가볍고 빠른 IPC/Feather 바이너리 파일입니다.
즉 RAM 안에서 빠르게 돌릴 수도 있고, 디스크에 썼다가 다른 언어/프로세스가 바로 읽어갈 수도 있는 구조죠.

📌 Arrow와 Feather 기본 개념

먼저 이 두 가지 이름부터 정리하는 게 편합니다.
Apache Arrow는 데이터를 “열 단위(columnar)”로 메모리에 담는 표준 포맷이자 생태계입니다.
여기서 중요한 건 이 포맷이 파이썬, R, 자바, 러스트 등 서로 다른 언어와 엔진 사이에서 그대로 공유 가능하도록 설계됐다는 점입니다.
즉 테이블 형태의 데이터를 한쪽에서 계산하고 다른 쪽으로 넘길 때, 굳이 CSV처럼 문자열로 변환했다가 다시 파싱할 필요가 없습니다.
Arrow 메모리 레이아웃 자체를 곧바로 읽는 식이라서 직렬화·역직렬화 부담이 훨씬 줄어듭니다.

Arrow의 철학을 조금 더 현실적으로 표현하면 이런 느낌에 가깝습니다.
“데이터 사이언스 / 분석 / 머신러닝 워크플로우에서 서로 다른 라이브러리끼리 데이터를 주고받을 때 복사(copy)를 최소화하자.”
특히 CPU, GPU 모두에서 효율적으로 다룰 수 있게 최적화된 메모리 배치 덕분에, 고성능 분석 작업에 잘 맞습니다.
Arrow는 현대 CPU와 GPU 캐시 친화적인 연속 메모리 버퍼 형태로 컬럼을 보관하고, 랜덤 액세스와 벡터화 계산에 유리한 구조를 가집니다.

그렇다면 Feather는 뭘까요.
Feather는 Arrow 데이터를 디스크에 저장하기 위한 가볍고 빠른 바이너리 파일 포맷입니다.
확장자는 주로 .feather 또는 .arrow로 쓰고, 파이썬이나 R에서 데이터프레임(테이블)을 저장했다가 다시 불러올 때 아주 빠르게 쓸 수 있도록 만들어졌습니다.
원래 Feather v1은 일종의 초기 실험 버전이었는데, 현재 기본이 된 Feather v2부터는 사실상 Arrow IPC “파일” 포맷과 동일하다고 공식 문서에서 못 박고 있습니다.
쉽게 말하면, Feather v2 = Arrow IPC file format입니다.

여기서 IPC라는 표현이 등장합니다.
IPC(Inter-Process Communication) 포맷은 Arrow 테이블을 직렬화해서 다른 프로세스나 다른 런타임으로 넘기기 위한 바이너리 표현입니다.
Arrow는 크게 두 가지 IPC 형태를 제공합니다.
하나는 스트리밍(streaming) 포맷으로, 길이를 알 수 없는 연속 배치를 순차적으로 전송할 때 적합합니다.
다른 하나는 파일(file / random access) 포맷으로, 고정된 배치를 디스크에 저장하고 임의 접근(random access)이 가능하도록 만든 형식입니다.
Feather v2는 바로 이 “파일 포맷”과 1:1로 호환되는 형태라서, 분석 툴 사이에 데이터를 공유할 때 표준 입출력처럼 쓰입니다.

정리해보면 흐름이 이렇게 연결됩니다.
pyarrow.Table 같은 Arrow 기반 객체는 메모리 상에서 열지향 형태로 데이터를 들고 있고, 이것을 프로세스 간/언어 간으로 주고받고 싶다면 Arrow IPC로 직렬화합니다.
그리고 그 Arrow IPC 파일 형태를 그대로 디스크에 기록해 두는 사용성 좋은 API 이름이 Feather입니다.
즉 “RAM 안의 Arrow ⟷ 디스크 위의 Feather” 구도가 잡히는 셈입니다.

이게 왜 중요한가.
데이터 작업에서 병목은 보통 알고리즘보다 I/O와 복사에서 터집니다.
CSV처럼 문자열 위주 포맷은 용량도 크고, 읽을 때마다 타입 추론을 다시 해야 하고, 판다스나 다른 엔진으로 넘기려면 또 파싱을 합니다.
반면 Arrow/Feather 계열은 이미 타입 정보까지 포함된 상태의 바이너리 컬럼 버퍼이기 때문에, “그대로 가져다 쓴다”는 관점이 강합니다.
그래서 대용량 ETL 파이프라인, Spark ↔ Python, Python ↔ R 사이처럼 서로 다른 분석 스택을 이어 붙일 때 속도 이득이 크게 체감됩니다.
Arrow는 실제로 분산/고성능 분석 시스템 간 데이터 이동 비용을 줄이는 표준 인터페이스로 채택되고 있고, 복사 없는(또는 거의 복사 없는) 전달이라는 목표 때문에 ‘제로카피 지향’이라는 표현도 자주 따라붙습니다.

📌 pyarrow.Table과 열지향 in-memory 구조

이제 파이썬에서 실제로 Arrow 데이터를 다룰 때 핵심이 되는 구조인 pyarrow.Table을 살펴볼 차례입니다.
pyarrow.Table은 간단히 말해 Arrow의 열 지향 메모리 레이아웃을 그대로 표현한 테이블 객체입니다.
각 컬럼은 연속적인 메모리 버퍼에 저장되어 있고, Arrow 타입 시스템을 기반으로 각 열의 데이터 타입(int64, float32, string 등)을 엄격하게 정의합니다.
이 덕분에 CPU 캐시 효율이 좋고, 벡터화 연산(한 번에 여러 데이터를 처리하는 계산)에 매우 유리합니다.

pyarrow.Table은 판다스 DataFrame과 모양은 비슷하지만, 구조는 완전히 다릅니다.
판다스는 각 컬럼이 서로 다른 객체로 흩어져 있고, 메모리도 파편화되어 있기 때문에 대규모 연산 시 오버헤드가 많습니다.
반면 pyarrow.Table은 각 컬럼이 Arrow Array로 구성되어 있으며, 동일한 데이터 타입의 값들이 하나의 연속된 버퍼에 저장됩니다.
즉, 판다스보다 훨씬 메모리 접근 패턴이 단순하고, CPU가 예측하기 쉬운 구조를 가지고 있죠.
이 차이가 바로 “열지향 in-memory 포맷”의 핵심입니다.

예를 들어 pyarrow.Table을 생성하는 방법은 매우 직관적입니다.

import pyarrow as pa

data = {
    "name": ["Alice", "Bob", "Charlie"],
    "age": [25, 30, 35],
    "score": [88.5, 92.3, 79.8]
}

table = pa.table(data)
print(table)

위 코드를 실행하면 판다스처럼 보이지만, 내부적으로는 각 컬럼이 Arrow Array 객체로 구성된 열지향 구조를 가지고 있습니다.
즉, 동일한 자료형이 하나의 버퍼에 모여 있으며, 이 버퍼를 다른 라이브러리나 프로세스와 공유할 수 있는 형태로 유지합니다.
또한 pyarrow.Table은 판다스 DataFrame과 완전한 호환을 제공하여 to_pandas()나 from_pandas() 메서드로 손쉽게 변환 가능합니다.

이 구조의 장점은 단순히 “빠르다”에 그치지 않습니다.
pyarrow.Table은 메모리 매핑(memory mapping)을 활용해 파일에 저장된 Arrow 데이터를 직접 읽을 수도 있습니다.
즉, 전부 로드하지 않고도 특정 컬럼만 선택적으로 읽을 수 있어, 대용량 데이터셋에서 효율적입니다.
이 덕분에 Arrow는 분석 엔진(DuckDB, Polars, Spark)과 연결할 때 ‘공용 메모리 버퍼’를 중심으로 한 고속 데이터 인터페이스로 활용됩니다.

정리하면 pyarrow.Table은 단순한 테이블 객체가 아니라, 언어나 라이브러리 경계를 넘나드는 ‘공통 언어’ 역할을 합니다.
이게 바로 Arrow 생태계의 진짜 강점입니다.
데이터 과학, 클라우드 분석, GPU 연산까지, 데이터가 머무는 장소가 달라도 같은 포맷으로 연결할 수 있으니까요.

📌 IPC와 Feather 파일 포맷으로 주고받기

데이터를 메모리 안에서만 다루는 것도 중요하지만, 결국은 저장과 재활용이 필요합니다.
이때 사용하는 게 바로 Arrow IPC와 Feather 파일 포맷입니다.
두 포맷 모두 Arrow 테이블 구조를 직렬화해 저장하고 다시 불러올 수 있도록 설계된 이진(Binary) 형식입니다.
핵심은, 판다스의 pickle처럼 파이썬에 종속되지 않고, 다른 언어나 프로세스에서도 바로 읽을 수 있다는 점이죠.

먼저 IPC (Inter-Process Communication) 포맷부터 살펴봅시다.
이 포맷은 Arrow 데이터를 스트림(stream) 형태로 직렬화하여 다른 프로세스나 프로그램으로 전달할 수 있도록 만든 형식입니다.
즉, 메모리 상의 pyarrow.Table을 빠르게 바이너리 시퀀스로 변환해, 네트워크 전송이나 다른 언어 런타임과의 데이터 교환에 활용됩니다.
이 포맷은 완전히 언어 독립적이며, C++, Java, R, Rust, Go 등에서도 동일한 규격으로 읽을 수 있습니다.

반면 Feather는 Arrow IPC 포맷을 기반으로 한 ‘파일 저장용 버전’이라고 보면 됩니다.
즉, IPC 파일 포맷을 그대로 디스크에 기록하고 다시 읽을 수 있게 만들어진 편의 포맷이죠.
그래서 Feather v2는 실제로 Arrow IPC file format과 완전히 동일하며, 단지 Python과 R 사용자가 더 쉽게 접근할 수 있도록 한 API 래퍼라고 생각하면 됩니다.

파이썬에서는 아래처럼 간단하게 Feather 파일로 저장하고 다시 읽을 수 있습니다.

import pyarrow.feather as feather
import pyarrow as pa

# 예시 테이블 생성
table = pa.table({
    "city": ["Seoul", "Tokyo", "New York"],
    "population": [9.7, 14.0, 8.4]
})

# Feather 파일로 저장
feather.write_feather(table, "cities.feather")

# 다시 읽기
reloaded = feather.read_table("cities.feather")
print(reloaded)

CSV나 JSON으로 저장할 때보다 훨씬 빠르고, 타입 정보가 유지됩니다.
뿐만 아니라 Feather 파일은 압축(Compression) 옵션도 지원합니다.
예를 들어 feather.write_feather(table, “file.feather”, compression=’zstd’)처럼 지정하면, Zstandard 알고리즘으로 압축 저장이 가능합니다.

여기서 주목할 점은 Feather 파일이 Arrow Table 구조를 그대로 담고 있다는 것입니다.
즉, 다시 읽어도 데이터 손실이나 타입 변환이 일어나지 않습니다.
또한 다른 언어에서 읽을 때도 동일한 구조를 유지하기 때문에, 언어 간 분석 워크플로우를 손쉽게 구축할 수 있습니다.
예를 들어 R에서 저장한 Feather 파일을 파이썬에서 pyarrow로 바로 읽거나, 그 반대로도 완벽히 호환됩니다.

💬 Feather는 Arrow IPC 파일 포맷의 사용자 친화적 래퍼입니다.
따라서 “Feather = Arrow IPC file format”이라고 봐도 무방합니다.

즉, Arrow IPC와 Feather는 단순한 저장 포맷이 아니라, 데이터를 안전하고 빠르게 주고받는 표준 통로입니다.
특히 대용량 ETL이나 다중 언어 협업 환경에서는, 이 두 포맷을 활용해 메모리 복사를 최소화하고 속도를 크게 개선할 수 있습니다.

📌 제로카피 공유와 DLPack 연동

Apache Arrow의 가장 강력한 특징 중 하나는 바로 제로카피(Zero-Copy) 데이터 공유입니다.
일반적으로 데이터를 다른 프로세스나 라이브러리로 전달할 때는 복사(copy)가 발생합니다.
하지만 Arrow는 메모리 구조 자체가 표준화되어 있어, 별도의 변환 없이 같은 버퍼를 다른 쪽에서 바로 참조할 수 있습니다.
이게 가능한 이유는 Arrow가 데이터를 열 단위 연속 버퍼로 저장하고, 각 버퍼의 메타데이터(스키마, 오프셋, 타입)를 함께 보관하기 때문입니다.

이 철학은 GPU 연산이나 텐서 기반 프레임워크와도 자연스럽게 이어집니다.
특히 DLPack이라는 표준 인터페이스를 통해 Arrow 객체를 PyTorch, TensorFlow, CuPy 등의 라이브러리와 제로카피 방식으로 주고받을 수 있습니다.
즉, 데이터를 중간에 다시 직렬화하거나 디코딩하지 않고, 같은 메모리 버퍼를 양쪽에서 그대로 보는 셈이죠.
GPU 메모리나 대규모 연산을 다루는 환경에서는 이 구조가 엄청난 속도 향상을 가져옵니다.

예를 들어 pyarrow에서 DLPack을 활용해 데이터를 공유하는 과정은 다음처럼 진행됩니다.

import pyarrow as pa
import torch

# Arrow Array 생성
arr = pa.array([1, 2, 3, 4, 5])

# Arrow → DLPack 변환
dl_tensor = pa.cuda.as_dlpack(arr)

# DLPack → PyTorch Tensor로 변환
tensor = torch.utils.dlpack.from_dlpack(dl_tensor)
print(tensor)

위 코드에서 주목할 부분은 데이터 복사가 일어나지 않는다는 것입니다.
Arrow의 메모리 버퍼를 DLPack 규격으로 감싸 전달하면, PyTorch가 동일한 버퍼를 바로 참조합니다.
이 덕분에 데이터가 큰 경우에도 복사로 인한 메모리 낭비나 속도 저하가 없습니다.

또한 이 방식은 고성능 데이터 엔진에서도 적극 활용됩니다.
예를 들어 DuckDB는 Arrow 테이블을 직접 입력받아 분석할 수 있고, Polars 역시 pyarrow.Table을 내부 포맷으로 바로 인식합니다.
즉, 데이터를 “읽고 변환”하는 단계를 건너뛸 수 있는 거죠.
DLPack, Arrow, cuDF, Torch Tensor가 이런 식으로 연결되면, CPU와 GPU 간 대용량 데이터 이동이 매우 효율적으로 이뤄집니다.

결국 Arrow의 제로카피 구조와 DLPack 연동은 “데이터를 한 번만 만들고, 여러 엔진이 함께 쓴다”는 철학의 구체적 구현이라 할 수 있습니다.
이 개념은 점점 더 많은 분석 프레임워크의 핵심으로 자리잡고 있으며, 향후 데이터 파이프라인 표준의 중심이 될 것으로 평가됩니다.

📌 언제 Arrow와 Feather를 쓰면 좋은가

Arrow와 Feather는 데이터 포맷의 대세로 자리잡아가고 있지만, 모든 상황에서 꼭 써야 하는 것은 아닙니다.
그 대신 이 두 포맷이 가진 강점을 이해하면, 어떤 경우에 가장 효율적인지 명확히 구분할 수 있습니다.
즉, “데이터가 자주 복사되고, 여러 언어와 툴 사이를 오간다면 Arrow/Feather를 쓰라”는 것이 핵심 원칙입니다.

먼저 Feather를 고려해야 하는 대표적인 경우는 다음과 같습니다.

• 📁대용량 데이터프레임 캐싱이 필요할 때 (CSV보다 수십 배 빠른 입출력)
• 🔄R, Python, Julia 등 서로 다른 언어 간 데이터 공유가 필요한 경우
• ⚙️DuckDB, Polars, PyTorch 같은 Arrow 지원 엔진과의 연동 시
• 💾타입 정보와 null 값 처리까지 정확히 보존해야 할 때

반대로 단순한 텍스트 기반 데이터 교환이나, 데이터 크기가 작고 직관적인 구조가 필요한 경우엔 CSV나 JSON이 여전히 유효합니다.
Arrow/Feather는 “빠른 입출력”과 “형식 일관성”을 위해 설계된 포맷이라, 텍스트 가독성보다는 효율성에 초점이 맞춰져 있습니다.
특히 분석 파이프라인 전체를 구성하는 단계에서는, CSV → Arrow → Feather → GPU 텐서의 형태로 점점 더 빠르고 효율적인 형태로 발전하는 것이 이상적입니다.

실무에서는 Feather 파일을 중간 캐시 계층으로 활용하는 경우가 많습니다.
예를 들어, 대용량 로그 데이터를 처음엔 CSV로 받아 전처리한 후, pyarrow.Table 형태로 정제해 Feather로 저장해 두는 것이죠.
그 이후엔 Feather 파일을 빠르게 로드해 판다스나 Polars로 분석할 수 있습니다.
이렇게 하면 파일 입출력 속도는 수배 이상 빨라지고, 타입 일관성도 유지됩니다.

한편, Arrow IPC 포맷은 단순 파일 저장용을 넘어, 프로세스 간 메시지 전달에도 사용됩니다.
파이썬 프로세스끼리 데이터를 공유하거나, R·Julia 등 외부 인터페이스와 데이터를 교환할 때, Arrow 스트림을 직접 주고받는 형태로 설계할 수 있습니다.
이런 구조는 복잡한 직렬화 과정을 생략하면서도, 타입 안정성과 성능을 모두 확보할 수 있게 합니다.

💬 정리하자면, Arrow와 Feather는 “데이터를 잃지 않고 빠르게 주고받는 표준 포맷”입니다.
대용량, 다언어, GPU 환경일수록 이 두 포맷의 이점이 극대화됩니다.

따라서 단순 파일 저장 목적이라면 Feather를, 시스템 간 고속 데이터 교환이 필요하다면 Arrow IPC를, GPU나 ML 파이프라인 연결이 목적이라면 DLPack과 함께 Arrow 메모리 버퍼를 사용하는 것이 이상적입니다.
즉, 한 줄로 정리하자면 다음과 같습니다.

❓ 자주 묻는 질문 (FAQ)

📌 데이터 포맷 혁신의 중심, Arrow와 Feather가 만든 속도의 차이

Arrow와 Feather는 단순한 데이터 저장 포맷이 아닙니다.
데이터 과학과 분석 환경 전체에서 ‘데이터를 어떻게 주고받을 것인가’에 대한 표준을 새롭게 정의하고 있습니다.
pyarrow.Table을 중심으로 한 열지향 in-memory 포맷은 CPU와 GPU, 그리고 여러 언어 간 데이터 교환의 경계를 허물고 있습니다.

Feather 파일은 빠른 캐시용, Arrow IPC는 프로세스 간 교환용, 그리고 DLPack 연동은 제로카피 GPU 데이터 공유용으로 각각의 강점을 발휘합니다.
이 세 가지 요소가 결합되면, 기존의 “읽기-복사-변환” 구조에서 “참조-연결-계산” 구조로 전환이 일어납니다.
결국 데이터가 머무는 경로가 짧아지고, 파이프라인의 속도가 비약적으로 향상됩니다.

이런 구조적 혁신 덕분에 최근의 데이터 분석 도구(DuckDB, Polars, Pandas 2.x)는 이미 Arrow 기반 인터페이스를 채택하고 있습니다.
즉, Arrow를 이해하는 것은 단순한 기술 습득이 아니라, 앞으로의 데이터 생태계를 이해하는 길이라고 할 수 있습니다.
대규모 데이터, 멀티언어 환경, GPU 가속이 결합된 시대일수록 Arrow 포맷의 존재감은 더욱 커질 것입니다.

🏷️ 관련 태그 : ApacheArrow, pyarrow, Feather파일, DLPack, 데이터직렬화, 열지향포맷, 판다스2, Polars, DuckDB, 고성능데이터분석