본문으로 건너뛰기
피드

Cap'n Proto: Protobuf 만든 사람이 다시 만든 '인코딩 없는' 직렬화 포맷

backend 약 3분
vote
0
댓글
북마크

Protocol Buffers v2의 핵심 개발자 Kenton Varda가 만든 데이터 직렬화 포맷 겸 RPC 시스템. 인코딩과 메모리 표현이 동일해서 직렬화/역직렬화 비용이 0이며, mmap, 랜덤 액세스, 프로세스 간 공유 메모리 등 다양한 이점을 제공함. Cloudflare Workers에서 실전 사용 중.

  • 1

    인코딩 포맷 = 메모리 내 표현이라 직렬화/역직렬화 비용 제로

  • 2

    플랫폼 독립적이면서 현대 CPU에 최적화된 설계 (고정 폭, 리틀엔디언, 오프셋 기반 포인터)

  • 3

    packing 압축으로 protobuf과 비슷하거나 더 작은 메시지 크기 달성

  • 4

    mmap, 랜덤 액세스, 언어 간/프로세스 간 통신 등 다양한 활용 가능

  • 5

    Time-traveling RPC: promise pipelining으로 응답이 요청보다 먼저 도착하는 구조

  • Protocol Buffers v2의 핵심 개발자였던 Kenton Varda가 만든 데이터 직렬화 포맷 + RPC 시스템. Protobuf의 수년간 경험과 사용자 피드백을 바탕으로 설계한 "개선판"임
  • 벤치마크에서 Protocol Buffers 대비 무한 배 빠름. 물론 불공정한 비교인데, 인코딩/디코딩 과정 자체가 없기 때문

핵심 아이디어: 인코딩 포맷과 메모리 내 표현이 동일함. 구조체를 만들면 그 바이트를 그대로 디스크에 쓰면 됨

  • 플랫폼 독립적이지만 현대 CPU에 최적화된 설계: 고정 폭, 고정 오프셋, 정렬, 리틀엔디언
  • 포인터는 절대 주소가 아닌 오프셋 기반이라 메시지가 위치 독립적
  • 하위 호환성: 새 필드는 항상 구조체 끝에 추가되고, 읽는 쪽은 바운드 체크만 하면 됨
  • 고정 폭 정수나 패딩이 낭비처럼 보이지만, 어차피 0이라서 "packing"이라는 전용 압축을 걸면 protobuf와 비슷한(오히려 더 작은) 크기 달성 가능

보안: 버퍼 포인터를 구조체로 캐스팅하는 짓은 안 함. 접근자 메서드가 포인터를 검증한 후 따라감. Sandstorm.io와 Cloudflare Workers에서 실전 투입 중이고, 퍼징 + 보안 전문가 리뷰를 거침

기타 장점들:

  • 점진적 읽기: 메시지를 다 받기 전에 처리 시작 가능
  • 랜덤 액세스: 전체 파싱 없이 특정 필드만 읽기
  • mmap 지원: 대용량 파일을 메모리 매핑해서 접근한 부분만 OS가 읽음
  • 언어 간 / 프로세스 간 통신: 같은 메모리 표현을 공유하니까 Java↔C++ 같은 조합에서 별도 변환 없이 동작
  • 아레나 할당: Protobuf의 메모리 할당 병목 회피
  • 생성 코드가 극도로 작음: 대부분 인라인 접근자 메서드 수준
  • Time-traveling RPC: 요청이 서버에 도착하기 전에 응답이 클라이언트에 돌아오는 마법 같은 구조 (promise pipelining)

Protobuf을 왜 그렇게 까냐고? 본인이 만든 거라서 까기 편해서라고 함. 구글과는 무관한 프로젝트임

Protobuf의 창시자가 '인코딩 단계 자체를 없애버리면 어떨까'라는 근본적 질문에서 출발한 설계. 제로카피 직렬화의 대표 사례.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.