바이너리 로깅 입문 — 6개 포맷 비교와 선택 기준
소프트웨어들을 많이 개발하면서 이벤트 로그를 바이너리 포맷으로 수집하는 방식에 관심을 갖게 됐습니다. AI 학습 데이터로 활용하기에 바이너리가 여러모로 유리한 점이 많았고, 실제로 프로젝트에도 적용해보고 있습니다. 실증 데이터와 적용 사례는 앞으로 이 카테고리에서 계속 공유할 예정인데, 오늘은 그 첫 번째 글로 바이너리 로깅 포맷 6종의 특성과 비교를 정리해보겠습니다.
6종
비교한 바이너리 포맷
35~67%
JSON 대비 크기 (포맷별)
2008~
가장 오래된 포맷 등장 시기
3가지
스키마 분류 기준
1왜 바이너리 로깅에 관심을 갖게 됐는가
JSON 로그는 훌륭합니다. 사람이 읽을 수 있고, 어디서든 열어볼 수 있고, 대부분의 프로젝트에서 잘 동작합니다. 저도 여전히 DB 감사 로그는 JSON으로 운영하고 있고, 바꿀 이유가 없습니다.
바이너리에 눈을 돌리게 된 건 AI 학습 데이터를 고민하면서였습니다. 여러 프로젝트를 개발하다 보면 이벤트 로그가 자연스럽게 쌓이는데, 이걸 나중에 학습 파이프라인에 태우려면 결국 변환 과정을 거쳐야 합니다. 처음부터 AI가 바로 읽을 수 있는 포맷으로 수집해두면 어떨까? 라는 생각이 출발점이었습니다.
그래서 바이너리 로깅 포맷들을 찾아보기 시작했고, 생각보다 선택지가 다양해서 정리가 필요했습니다. 이 글은 그 정리의 결과입니다.
바이너리 로깅의 일반적인 장점
크기 절감
대부분의 바이너리 포맷은 JSON 대비 35~67% 크기입니다. 키 이름 반복이 없거나, 스키마 기반 압축이 적용되기 때문입니다.
직렬화/역직렬화 속도
JSON 파싱 대비 2~10배 빠른 포맷들이 많습니다. 대량 데이터를 읽어야 하는 분석/학습 파이프라인에서 이 차이가 의미 있습니다.
Python 생태계와의 호환
Avro, MessagePack, Protobuf 등은 Python에서 바로 읽어서 Pandas나 PyTorch로 변환할 수 있습니다.
26개 포맷 한눈에 보기
MessagePack, Protobuf, CBOR, FlatBuffers, Avro, Cap'n Proto — 6개 포맷을 비교했습니다. 각각의 설계 철학이 달라서 적합한 상황이 다릅니다.
한 줄 요약
속도 및 크기 비교
| 포맷 | 직렬화 (쓰기) | 역직렬화 (읽기) | 크기 (JSON 대비) |
|---|---|---|---|
| JSON | ~300 MB/s | ~250 MB/s | 100% |
| MessagePack | ~800 MB/s | ~900 MB/s | 65% |
| Protobuf | ~1,000 MB/s | ~1,200 MB/s | 35% |
| CBOR | ~700 MB/s | ~800 MB/s | 67% |
| FlatBuffers | ~600 MB/s | ~3,000 MB/s (제로카피) | 40% |
| Avro | ~900 MB/s | ~1,000 MB/s | 38% |
| Cap'n Proto | ~2,000 MB/s | ~5,000 MB/s (제로카피) | 42% |
규모별 적합성
| 포맷 | 소규모 (일 수만) | 중규모 (일 수백만) | 대규모 (일 수억+) |
|---|---|---|---|
| MessagePack | ★★★ 최적 | ★★ 충분 | ★ 비효율 |
| Protobuf | ★★ 과할 수 있음 | ★★★ 최적 | ★★★ 최적 |
| CBOR | ★★★ 좋음 | ★★ 충분 | ★ 비슷 |
| FlatBuffers | ★ 과함 | ★★ 특수용도 | ★★★ 읽기 집약적 |
| Avro | ★ 과함 | ★★★ 최적 | ★★★ Hadoop이면 최고 |
| Cap'n Proto | ★ 과함 | ★★ 특수용도 | ★★★ 극한 성능 |
4스키마 있음 vs 없음 — 가장 큰 갈림길
6개 포맷을 비교하다 보면 결국 이 질문으로 수렴합니다. 이벤트 구조를 미리 정의할 것인가, 자유롭게 갈 것인가.
| 분류 | 포맷 | 특징 |
|---|---|---|
| 스키마 없음 | MessagePack, CBOR | 이벤트 구조가 자주 바뀌어도 코드 수정 불필요. 대신 잘못된 데이터가 들어와도 알 수 없음 |
| 스키마 필수 | Protobuf, FlatBuffers, Cap'n Proto | 데이터 무결성 보장, 크기 최소화. 구조 바꿀 때마다 스키마 수정 + 배포 필요 |
| 중간 | Avro | 스키마 권장이지만 파일에 같이 저장됨. 스키마 진화(하위 호환) 내장 지원 |
탐색 단계(이벤트 구조가 계속 바뀌는 초기)라면 스키마 없는 쪽이 편합니다. 안정 단계(필드가 고정된 후 장기 수집)라면 스키마 기반이 크기와 무결성 면에서 유리합니다.
5AI 학습 데이터로서의 적합성
AI 학습 데이터로 쓸 때 가장 중요한 건 나중에 읽어서 가공하기 쉬운가입니다. Python 생태계와의 호환성, Pandas 변환 편의, 스키마 진화 지원 여부가 핵심입니다.
| 포맷 | Python 지원 | Pandas 변환 | 스키마 진화 | 비정형 데이터 | AI 적합도 |
|---|---|---|---|---|---|
| MessagePack | ★★★ | 바로 가능 | 자유자재 | 완벽 | ★★★ |
| Protobuf | ★★★ | 변환 필요 | 버전관리 가능 | 어려움 | ★★ |
| CBOR | ★★ | 바로 가능 | 자유자재 | 완벽 | ★★ |
| Avro | ★★★ | 바로 가능 | 내장 지원 | 스키마 필요 | ★★★ |
| FlatBuffers | ★★ | 번거로움 | 어려움 | 어려움 | ★ |
| Cap'n Proto | ★ | 번거로움 | 가능 | 어려움 | ★ |
MessagePack은 비정형 데이터에 강합니다. 이벤트마다 필드가 다르고 구조가 수시로 바뀌는 탐색적 수집에 좋습니다. Avro는 스키마 진화를 내장 지원합니다. 6개월 전 데이터와 오늘 데이터의 스키마가 달라도 알아서 호환 처리를 해줍니다. 장기간 대량 수집하는 AI 학습 데이터셋에 적합합니다.
6상황별 선택 가이드
- 소규모 + 비정형 + 빨리 시작하고 싶음→ MessagePack
- 중규모 이상 + 이벤트 구조 안정적 + 팀→ Protobuf
- 빅데이터 생태계 (Kafka/Spark/Hadoop)→ Avro
- 게임/실시간 + 읽기 속도가 극단적으로 중요→ FlatBuffers
- IoT 디바이스 + 국제 표준 필요→ CBOR
- 극한 성능 + C++ 중심 시스템→ Cap'n Proto
소규모에서 Protobuf나 Avro를 쓰면 스키마 관리 비용이 절감 효과보다 클 수 있습니다. 반대로 대규모에서 MessagePack을 쓰면 키 이름 반복으로 인한 저장 공간 낭비가 무시할 수 없는 수준이 됩니다. 규모와 상황에 맞는 선택이 중요합니다.
7앞으로 다룰 내용
이 글은 바이너리 로깅 포맷의 소개와 비교였습니다. 이 카테고리에서 앞으로 다룰 예정인 내용은 다음과 같습니다.
실제 프로덕션에 바이너리 로깅을 적용한 구현기 (비동기 큐, 파일 분리 전략)
수집된 바이너리 로그를 AI 학습 파이프라인에 태우는 과정
JSON 로그 vs 바이너리 로그 실측 크기/속도 비교 (실증 데이터 기반)
DB 감사 로그와 파일 기반 이벤트 로그의 역할 분리 설계
실증 데이터가 쌓이는 대로 하나씩 공유하겠습니다.
본 글의 성능 수치(MB/s)는 일반적인 벤치마크 참고값이며 하드웨어 및 데이터 특성에 따라 다릅니다. 실제 도입 전 대상 시스템에서 직접 측정하시기 바랍니다.
댓글
(4)로그인 하면 댓글을 작성할 수 있습니다.
큐 최대 1,000건 초과 시 드롭하는 설계가 실용적입니다. 로깅 실패가 앱을 망가뜨리면 안 되니까요. 날짜+PID별 파일 분리도 멀티프로세스 환경에서 꼭 필요한 부분입니다.
6개 포맷 비교표가 실용적입니다. 저는 Protobuf를 써왔는데, 소규모 시스템에서는 Avro의 자체 설명적 파일 구조가 더 관리하기 편할 것 같네요.
Avro를 AI 학습 데이터용으로 쓰는 건 정석이죠. Python fastavro로 바로 읽을 수 있고 스키마 진화도 내장이라 장기 데이터 수집에 이만한 게 없습니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.