파이썬 데이터 직렬화 포맷 완전 가이드, JSON부터 Parquet까지 선택 기준 정리

📄 텍스트 기반 직렬화 포맷 JSON YAML TOML INI

텍스트 기반 직렬화 포맷은 말 그대로 사람이 읽고 쓸 수 있는 형태로 데이터를 표현하는 방식입니다.
파이썬에서 특히 많이 쓰이는 것이 JSON, YAML, TOML, 그리고 INI 같은 설정 파일 스타일의 포맷입니다.
이 네 가지는 공통적으로 “버전 관리에 넣고 diff를 보고 싶다”, “사람이 직접 열어서 수정해야 한다”, “인프라 설정값을 코드처럼 다루고 싶다” 같은 요구에 잘 맞습니다.
그리고 무엇보다 중요한 점은 텍스트 포맷은 디버깅이 빠르고 신뢰 관계를 만들기 쉽다는 겁니다.
눈으로 확인이 되니까요.

🧩 JSON 기본값처럼 쓰이는 표준 포맷

JSON은 가장 널리 쓰이는 데이터 직렬화 포맷 중 하나입니다.
웹 API 응답, 설정, 로그 데이터까지 안 쓰이는 데를 찾는 게 더 어려울 정도죠.
문법은 { } 객체, [ ] 배열 같은 구조로 이뤄져 있고 숫자, 문자열, 불리언, null 같은 기본 타입만 지원합니다.
파이썬에서는 json 모듈로 바로 직렬화/역직렬화가 가능하다는 점이 가장 큰 장점입니다.
간단한 예로 파이썬 dict를 JSON 문자열로 덤프해서 네트워크로 보내고, 다시 로드해서 dict로 복구하는 흐름은 사실상 업계 표준처럼 자리 잡았습니다.

JSON의 장점은 세 가지로 많이 정리됩니다.
첫째, 언어에 독립적이라 파이썬뿐 아니라 자바스크립트, 고, 자바 등 어디서든 쓸 수 있습니다.
둘째, 구조가 명확해서 자동 처리에 유리합니다.
셋째, 대부분의 시스템과 라이브러리가 JSON을 기본으로 지원하므로 별다른 합의 과정 없이 “JSON으로 주고받자”라고 말하면 협업이 바로 시작됩니다.
반면 단점은 주석(// 이런 식의 주석이나 # 주석 등)을 공식적으로 허용하지 않는다는 점, 그리고 큰 데이터를 다룰 때는 용량과 파싱 속도에서 한계가 나타난다는 점이 있습니다.

📒 YAML 사람 손으로 편집하기 편한 설정 파일 스타일

YAML은 인프라 쪽에서 특히 사랑받는 포맷입니다.
쿠버네티스 설정 파일, CI/CD 파이프라인 설정처럼 “사람이 직접 열어 수정하는 구성 정보”에 정말 자주 쓰입니다.
들여쓰기를 통해 계층을 표현하기 때문에, 보기에 부담이 적고 주석도 넣을 수 있습니다.
이런 특징 덕분에 팀 단위 운영/배포 설정 같은 영역에서는 사실상 표준으로 취급되는 경우가 많습니다.

다만 YAML은 단점도 분명합니다.
들여쓰기 공백이나 하이픈(-) 위치 하나 잘못 써도 전체 구조가 바뀌거나 파싱이 깨질 수 있습니다.
또 너무 복잡한 YAML은 오히려 읽기가 어려워지며, 타입 추론(예: 001이 문자열인지 정수인지) 때문에 의도하지 않은 결과가 나오는 경우도 있습니다.
파이썬에서는 pyyaml 같은 라이브러리로 쉽게 다룰 수 있지만, 운영 자동화 스크립트에서 잘못된 YAML로 인프라 전체 설정을 덮어쓰는 사고가 날 수 있다는 점은 항상 조심해야 합니다.

⚙️ TOML 파이썬 생태계에서 급부상한 설정 포맷

TOML은 “사람이 읽기 편하고 파서가 실수 없이 읽을 수 있는” 균형을 목표로 한 포맷입니다.
섹션은 [section] 형태로 선언하고 key = “value” 형태로 값을 넣는 스타일이라 비교적 직관적입니다.
파이썬 개발자라면 pyproject.toml 파일을 통해 자연스럽게 접하게 됩니다.
요즘은 패키지 설정, 의존성 선언 등을 TOML로 통합하는 흐름이 강해지고 있어서 파이썬 프로젝트 메타데이터 표준처럼 자리 잡아가는 중입니다.

TOML의 강점은 명확한 타입 표현과 일관된 문법입니다.
날짜/시간 같은 것도 명시적으로 표현할 수 있고, 숫자나 불리언도 헷갈리지 않게 고정된 규칙을 가집니다.
또 INI처럼 단순하면서도 YAML처럼 들여쓰기 민감하지 않다는 점이 실무에서 꽤 편합니다.
반면, 복잡한 중첩 구조나 대규모 계층형 데이터를 담기에는 다소 한계가 있기 때문에 API 응답 본문처럼 쓰기보다는 “프로젝트 설정”이라는 역할에 더 어울립니다.

📝 INI 여전히 살아 있는 클래식 설정 파일

INI는 아주 오래된 형식이지만, 의외로 여전히 시스템 설정 파일이나 단순한 애플리케이션 설정에서 많이 쓰입니다.
구조는 [section] 아래에 key=value 쌍이 이어지는 간단한 형태입니다.
파이썬 표준 라이브러리의 configparser를 사용하면 INI 스타일 설정 파일을 바로 읽고 쓸 수 있기 때문에, 별도 의존성을 추가하고 싶지 않은 작은 프로젝트에서는 여전히 유효한 선택입니다.

단점도 분명합니다.
자료형 정보가 사실상 문자열에 가깝기 때문에 숫자, 불리언, 리스트 같은 걸 다룰 때 일관성을 유지하기가 어렵습니다.
또 계층 구조를 표현하는 게 제한적이라 복잡해지기 시작하면 금방 유지보수가 힘들어집니다.
그래서 INI는 “환경 변수보다 조금 더 구조화된 정도면 충분하다”라는 상황, 예를 들면 간단한 설정값 몇 개를 외부 파일에서 관리하고 싶은 소규모 유틸리티나 내부용 스크립트에 적합합니다.

🔍 어떤 상황에 어떤 텍스트 포맷을 쓰면 좋을까

💬 정리하면, JSON은 시스템 간 교환용, YAML은 운영 설정용, TOML은 파이썬 프로젝트 설정용, INI는 단순 로컬 설정용이라고 생각하면 선택이 한결 가벼워집니다.

🚀 바이너리 직렬화 MessagePack CBOR Protocol Buffers Avro Thrift FlatBuffers

텍스트 포맷이 사람이 보기 좋은 구조라면, 바이너리 포맷은 기계가 빠르게 읽고 쓰기 좋은 구조입니다.
이들은 기본적으로 “네트워크 전송 속도”, “용량 절감”, “명확한 타입 보존” 같은 효율성에 초점을 맞춥니다.
파이썬에서는 주로 분산 처리, IoT, 마이크로서비스 간 데이터 통신, 또는 대규모 로그 전송 시스템에서 이런 포맷들을 활용합니다.
여기서 중요한 건 “어떤 포맷이 제일 빠른가?”보다 “우리 시스템의 데이터 구조와 업데이트 패턴에 맞는가?”입니다.

⚡ MessagePack JSON보다 가볍고 빠른 대안

MessagePack은 “binary JSON”이라고 불릴 만큼 구조가 단순하면서도 효율적입니다.
JSON 구조를 그대로 유지하면서 불필요한 구분자나 문자열 표현을 제거해 훨씬 작은 크기로 데이터를 표현합니다.
파이썬에서는 msgpack 패키지를 사용하면 dict, list 같은 객체를 바로 직렬화할 수 있습니다.
특히 IoT나 모바일 환경처럼 네트워크 대역폭이 제한된 시스템에서 자주 선택됩니다.

단점은 텍스트 포맷과 달리 사람이 직접 보기 어렵다는 점입니다.
그래도 단순한 구조와 다양한 언어 지원 덕분에, JSON의 대체재로 실무에서 가장 많이 쓰이는 바이너리 포맷 중 하나입니다.

🔁 CBOR IoT 표준으로 채택된 JSON의 진화형

CBOR(Concise Binary Object Representation)는 MessagePack과 비슷하지만 좀 더 표준화된 형태를 추구합니다.
RFC 8949로 정의되어 있으며, IoT 프로토콜(CoAP 등)에서 공식적으로 사용됩니다.
CBOR은 단순히 JSON의 이진 버전이 아니라, 날짜, 부동소수점, 태그된 값 등 더 다양한 데이터 타입을 표현할 수 있습니다.
파이썬에서는 cbor2 패키지를 사용해 직렬화/역직렬화를 쉽게 할 수 있습니다.

CBOR은 특히 센서 데이터 전송이나 소형 디바이스 간 통신에서 빛을 발합니다.
JSON보다 훨씬 작고 빠르며, 스키마 없이도 타입이 명확하기 때문에 저전력 환경에서도 안정적으로 동작합니다.

📡 Protocol Buffers 구글이 만든 고성능 직렬화 표준

Protocol Buffers(줄여서 Protobuf)는 구글이 만든 데이터 직렬화 포맷입니다.
정해진 스키마(.proto 파일)에 따라 데이터를 정의하고, 컴파일하여 각 언어별 클래스나 구조체로 변환한 후 이진 형태로 직렬화합니다.
이 구조 덕분에 데이터의 타입 안정성과 버전 호환성을 매우 엄격하게 보장합니다.
gRPC 같은 최신 분산 시스템 통신 규약이 모두 Protobuf를 기본으로 사용합니다.

파이썬에서도 공식 protobuf 패키지를 통해 사용할 수 있습니다.
성능이 매우 뛰어나고, 스키마 기반이라 대규모 시스템에서도 데이터 구조가 혼란스러워질 일이 거의 없습니다.
다만 초기 학습 비용이 약간 높고, 스키마를 수정하려면 컴파일 과정을 거쳐야 한다는 점이 단점입니다.

📦 Avro 빅데이터 시스템에서 사랑받는 포맷

Avro는 아파치 하둡 생태계에서 만들어진 직렬화 포맷으로, 빅데이터 파이프라인에서 주로 사용됩니다.
JSON 기반의 스키마를 따르지만 데이터는 이진 형태로 저장됩니다.
덕분에 용량을 최소화하면서도 스키마 진화(Schema Evolution) 기능을 지원해, 새로운 필드를 추가해도 기존 데이터와 호환이 유지됩니다.

Spark, Kafka, Flink 등과 잘 통합되며, 파이썬에서는 fastavro 라이브러리를 사용합니다.
데이터 엔지니어링 환경에서 Parquet과 함께 가장 많이 쓰이는 포맷 중 하나입니다.

🧱 Thrift와 FlatBuffers 고성능 시스템 간 통신을 위한 선택지

Thrift는 Meta(옛 Facebook)가 개발한 범용 직렬화 프레임워크로, Protobuf와 유사한 스키마 기반 구조를 갖습니다.
다양한 전송 프로토콜과 서비스 정의를 함께 지원해 하나의 인터페이스 정의 파일로 여러 언어의 서버·클라이언트를 생성할 수 있습니다.
FlatBuffers는 구글이 게임·그래픽스 엔진 등에서 메모리 효율을 극대화하려고 만든 포맷으로, 역직렬화 과정 없이 직접 데이터 구조에 접근할 수 있어 초저지연 환경에 적합합니다.

즉, Thrift는 대규모 서비스 간 통신, FlatBuffers는 실시간 성능이 중요한 시스템(예: 게임, AR/VR, 로보틱스)에 강점이 있습니다.
둘 다 일반적인 데이터 교환보다는 시스템 설계 단계에서 구조적 효율을 극대화하려는 경우에 선택됩니다.

🧭 포맷별 요약 비교

📊 컬럼 지향 저장 Parquet Feather ORC

데이터 분석이나 머신러닝 파이프라인에서는 단순한 직렬화보다 훨씬 중요한 것이 있습니다.
바로 읽기 성능과 압축 효율입니다.
이때 주로 사용하는 것이 바로 컬럼 지향(Columnar) 저장 포맷입니다.
행(row) 단위로 데이터를 저장하는 CSV나 JSON과 달리, 컬럼 단위로 데이터를 묶어 저장하기 때문에 특정 컬럼만 읽을 때 속도가 비약적으로 빨라집니다.
파이썬에서는 pandas, pyarrow, fastparquet 등이 이런 포맷을 지원합니다.

📁 Parquet 데이터 분석의 표준

Parquet은 아파치 소프트웨어 재단에서 만든 컬럼 지향 저장 포맷으로, 현재 빅데이터 업계 표준으로 자리 잡았습니다.
스키마 정보와 데이터가 함께 저장되며, 효율적인 압축과 인코딩 덕분에 수십 GB~TB 단위 데이터에서도 빠르게 특정 열만 읽을 수 있습니다.
Spark, Hive, Dask, Pandas 모두 Parquet을 기본 지원하며, 클라우드 스토리지(AWS S3, GCP, Azure 등)와의 호환성도 뛰어납니다.

파이썬에서는 pyarrow를 통해 쉽게 사용할 수 있습니다.
데이터프레임을 to_parquet()으로 저장하고, read_parquet()으로 다시 불러올 수 있죠.
CSV보다 최대 10배 이상 빠르며, 스키마를 유지하기 때문에 재현성과 일관성 면에서도 안정적입니다.

🪶 Feather 빠른 입출력용 경량 포맷

Feather는 Parquet보다 단순한 구조를 가진 경량 포맷입니다.
pandas와 R 간 데이터 교환을 쉽게 하기 위해 개발되었으며, I/O 속도에 초점을 맞춘 설계가 특징입니다.
스키마 복잡도가 낮고 압축을 최소화해, 데이터프레임을 빠르게 저장하고 즉시 다시 읽어오는 데 매우 적합합니다.

특히 데이터 분석 실험을 반복하며 중간 결과를 캐시해야 하는 상황에서 유용합니다.
단, 장기 저장보다는 임시 저장·테스트 데이터 교환용에 더 어울립니다.

🧮 ORC 대규모 테이블 압축 효율 최고 수준

ORC(Optimized Row Columnar)는 아파치 하이브(Hive)에서 파생된 포맷으로, 대용량 테이블의 압축 효율과 쿼리 성능이 매우 우수합니다.
각 컬럼을 별도의 스트라이프로 저장하고, 인덱스와 요약 통계 정보를 함께 보관하기 때문에 쿼리 최적화에 큰 도움이 됩니다.

ORC는 주로 하둡, Hive, Presto, Trino 같은 분산 SQL 엔진에서 많이 사용됩니다.
파이썬에서도 pyarrow로 읽고 쓸 수 있지만, Parquet만큼 광범위하게 쓰이지는 않습니다.
대신 대규모 집계나 저장 효율을 극대화해야 하는 환경에서는 여전히 좋은 선택입니다.

📈 컬럼 지향 포맷 비교표

💬 요약하자면, Parquet은 데이터 분석의 표준, Feather는 빠른 임시 저장용, ORC는 분산 환경의 고압축 저장용으로 구분하면 됩니다.

🔬 과학 데이터 HDF5

HDF5(Hierarchical Data Format version 5)는 과학, 공학, AI 연구 분야에서 널리 사용되는 고성능 데이터 저장 포맷입니다.
한마디로 “파일 안에 계층형 데이터베이스를 통째로 넣는 방식”이라고 보면 됩니다.
수백만 개의 데이터 포인트, 3D 시뮬레이션 결과, 이미지 배열, 딥러닝 학습용 텐서 등을 하나의 파일에 구조화해 저장할 수 있습니다.
파이썬에서는 h5py와 pandas.HDFStore로 쉽게 다룰 수 있습니다.

🧬 HDF5의 구조와 장점

HDF5 파일은 내부적으로 그룹(Group)과 데이터셋(Dataset)으로 구성됩니다.
그룹은 폴더, 데이터셋은 파일처럼 동작하며, 계층 구조를 자유롭게 설계할 수 있습니다.
각 데이터셋은 메타데이터, 속성(attribute)을 가질 수 있어, 데이터 자체뿐 아니라 설명, 단위, 출처 같은 정보까지 함께 저장됩니다.
이런 구조 덕분에 HDF5는 대규모 과학 실험 결과나 인공위성 이미지, 수치 시뮬레이션 데이터를 저장하기에 최적입니다.

또한 내부적으로 청크(chunk) 단위 압축을 지원해, 특정 부분만 빠르게 읽거나 쓸 수 있습니다.
이는 수백 GB 크기의 데이터 파일을 다룰 때도 효율적인 접근이 가능하다는 뜻입니다.

🧠 머신러닝·과학 연구에서의 활용

HDF5는 TensorFlow, PyTorch, Keras 등 주요 딥러닝 프레임워크의 기본 저장 포맷으로 자리 잡았습니다.
예를 들어 Keras 모델을 저장하면 `.h5` 확장자로 저장되는 이유도 여기에 있습니다.
이미지 데이터셋을 여러 그룹으로 나누어 저장하거나, 실험 결과를 반복 측정값과 함께 기록할 때 유용합니다.

또한 병렬 접근 기능(MPI 지원) 덕분에 슈퍼컴퓨팅 환경에서도 널리 사용됩니다.
NASA, CERN, 기상청, 국내 연구소 등에서도 시뮬레이션 결과나 센서 측정 데이터를 HDF5로 관리하는 경우가 많습니다.

📘 HDF5 주요 특징 정리

• 📂데이터 그룹화와 계층 구조 지원 (폴더 구조처럼 관리 가능)
• ⚙️압축 및 청크 기반 부분 접근 (필요한 부분만 빠르게 읽기)
• 🧩다차원 배열(Numpy 호환)과 메타데이터 저장 가능
• 🚀병렬 입출력 지원 (MPI 병렬 처리 환경에서 효율적)
• 💡과학·공학·AI 분야의 사실상 표준 포맷

💬 HDF5는 한 파일 안에 모든 실험 데이터를 체계적으로 담을 수 있어, 과학 연구와 AI 개발의 ‘데이터 컨테이너’로 불립니다.

📂 스프레드시트 교환 Excel ODS

데이터 직렬화 포맷의 마지막 축은 바로 스프레드시트 기반 포맷입니다.
즉, 우리가 일상적으로 다루는 엑셀(.xlsx)과 오픈오피스(.ods) 형식이죠.
이들은 “데이터를 사람이 직접 다루는 환경”에서 강점을 갖습니다.
비개발자도 쉽게 열고 편집할 수 있고, 시각적으로 테이블 구조를 확인할 수 있다는 점 덕분에 여전히 강력한 생명력을 유지하고 있습니다.

📊 Excel 포맷 (.xlsx)

Excel 파일은 사실상 전 세계에서 가장 널리 쓰이는 데이터 교환 포맷입니다.
기본 확장자인 .xlsx는 내부적으로 XML 압축 구조로 되어 있으며, 시트 단위의 표 형식을 갖습니다.
파이썬에서는 pandas의 read_excel()과 to_excel(), 혹은 openpyxl 패키지를 통해 자유롭게 다룰 수 있습니다.
비즈니스 리포트, 재무 데이터, 일정표, 결과 보고서처럼 사람이 직접 보는 것이 중요한 데이터에 이상적입니다.

하지만 엑셀은 대규모 데이터 처리에는 부적합합니다.
수십만 행을 넘기면 속도가 급격히 느려지고, 자동 서식이나 수식 때문에 파일 크기가 빠르게 커집니다.
따라서 분석용 데이터 저장보다는 “최종 결과 공유” 목적에 어울립니다.

🗂️ ODS 포맷 (OpenDocument Spreadsheet)

ODS는 LibreOffice나 OpenOffice에서 사용하는 오픈 표준 스프레드시트 포맷입니다.
ISO/IEC 26300 표준을 따르며, 엑셀과 호환되면서도 완전한 공개 포맷이라는 점이 강점입니다.
기관이나 정부, 공공 데이터 포털 등에서 ‘폐쇄 포맷(XLSX)’ 대신 ODS를 권장하는 이유도 여기에 있습니다.

파이썬에서는 pandas의 read_excel() 함수가 ODS를 기본 지원하지 않지만, odfpy나 pyexcel-ods로 쉽게 읽고 쓸 수 있습니다.
ODS는 단순 보고서나 오픈데이터 공개용으로 탁월합니다.
특히 기관 간 데이터 교환 시 ‘라이선스 제약 없는 형식’을 원한다면 ODS가 좋은 대안입니다.

📋 Excel vs ODS 비교

💬 Excel은 여전히 가장 접근성이 높고, ODS는 가장 개방적인 포맷입니다.
데이터 교환의 목적이 명확하다면 두 포맷 모두 훌륭한 선택이 될 수 있습니다.

❓ 자주 묻는 질문 파이썬 데이터 직렬화 선택 가이드 FAQ