본문으로 건너뛰기
피드

RX – JSON을 대체하는 랜덤 액세스 데이터 포맷

backend 약 5분

대용량 JSON을 전체 파싱 없이 원하는 값만 직접 읽을 수 있는 새 텍스트 포맷 RX가 공개됨. 92MB 배포 매니페스트 기준 조회 속도가 JSON 대비 23,000배 빠르고, 파일 크기도 5.1MB로 대폭 줄어드는 성능을 보여줌.

  • 1

    92MB JSON → 5.1MB RX, 라우트 조회 69ms → 0.003ms (실제 프로덕션 데이터 벤치마크)

  • 2

    인코딩된 버퍼를 파싱 없이 직접 읽음 — 배열 O(1), 오브젝트 키 O(log n) 접근

  • 3

    반환값이 읽기 전용 Proxy라 기존 JS 코드(map/filter/JSON.stringify 등)에서 거의 그대로 동작

  • 4

    텍스트 인코딩이라 copy-paste 가능, 바이너리 툴 불필요

  • 5

    빌드/배포 아티팩트처럼 한 번 쓰고 드문드문 읽는 대용량 JSON에 최적화된 포맷

  • JSON의 고질적인 문제인 "전체 파싱" 없이 원하는 값만 바로 읽을 수 있는 새 포맷 RX가 공개됨
  • creationix가 만든 오픈소스 프로젝트로, "no-SQL SQLite"처럼 비정형 데이터에 데이터베이스 수준의 랜덤 액세스를 제공하는 게 컨셉임

성능 벤치마크 (92MB 배포 매니페스트, 라우트 키 35,000개 기준)

JSON RX
파일 크기 92 MB 5.1 MB
라우트 1개 조회 69 ms (전체 파싱) 0.003 ms (~16번 인덱스 이동)
힙 할당 횟수 2,598,384 ~10
  • 조회 속도 차이가 무려 23,000배 수준임. 단순 벤치마크가 아니라 실제 프로덕션 데이터 기준이라 더 설득력 있음

어떻게 동작하나

  • 인코딩 시 중복 값을 자동으로 제거(포인터 방식으로 재사용), 오브젝트 스키마 공유, 문자열 prefix 압축, 정렬 인덱스 추가가 자동으로 이뤄짐
  • 인코딩된 버퍼를 그대로 쿼리 — 별도 파싱 단계 없이 버퍼를 직접 읽음
  • 배열 접근은 O(1), 오브젝트 키 조회는 O(log n)
  • 반환값은 읽기 전용 Proxy 형태라 기존 JS 코드에서 거의 그대로 쓸 수 있음
    • Object.keys(), for...of, .map(), .filter(), 구조분해, JSON.stringify() 모두 지원

사용 예시

import { stringify } from "@creationix/rx";
const rx = stringify({ users: ["alice", "bob"], version: 3 });

import { parse } from "@creationix/rx";
const data = parse(rx) as any;
data.users[0] // "alice" — 파싱 없이 버퍼 직접 읽기
data.version  // 3
JSON.stringify(data) // 그대로 동작
  • 문자열 기반은 stringify/parse, 바이너리(Uint8Array) 기반은 encode/open 사용
  • CLI 툴도 제공되고, rx.run에서 브라우저로 바로 인스펙트 가능함

잘 맞는 케이스 vs 맞지 않는 케이스

이럴 때 쓰기 좋음

  • 빌드/배포 아티팩트, 라우트 테이블처럼 한 번 쓰고 드문드문 읽는 대용량 JSON
  • 브라우저, 엣지 런타임, 워커 프로세스에 임베드하는 데이터셋
  • 전체 문서 파싱이 병목인 워크플로우

이럴 때는 적합하지 않음

  • JSON 파싱이 이미 빠를 만큼 작은 문서
  • 사람이 직접 편집하는 설정 파일
  • 자주 쓰거나 변경이 많은 데이터 (그냥 DB 써야 함)
  • gzip/zstd 압축 전송 크기를 최소화해야 하는 경우
  • 테이블 구조면 SQLite, 고정 스키마면 Protobuf가 더 적합

포맷 구조

  • 텍스트 인코딩이라 바이너리처럼 툴을 타지 않고, copy-paste나 문자열 삽입이 가능함
  • 값은 오른쪽에서 왼쪽으로 읽는 구조: [body][tag][b64 varint]
  • 태그 종류: + 정수, * 소수, , 문자열, ' ref/리터럴, : 오브젝트, ; 배열, ^ 포인터, . 체인, # 인덱스

정리

  • JSON이 너무 크고 느리지만, SQLite나 Protobuf처럼 구조를 강제하고 싶지는 않은 그 사이 어딘가를 정확히 겨냥한 포맷임
  • 대규모 빌드/배포 파이프라인에서 매니페스트나 라우트 테이블을 다루는 팀이라면 한번쯤 검토해볼 만함
  • MIT 라이선스, npm 패키지 @creationix/rx로 바로 설치 가능

JSON이 너무 크고 느리지만 SQLite나 Protobuf처럼 스키마를 강제하기 싫은 틈새를 정확히 겨냥한 포맷. 대규모 배포 파이프라인이나 엣지 런타임에서 라우트 테이블 같은 읽기 전용 대용량 데이터를 다루는 팀에게 실용적인 선택지가 될 수 있음. 다만 쓰기가 잦거나 소규모 데이터엔 오히려 오버엔지니어링.

댓글

댓글

댓글을 불러오는 중...

backend

Cloudflare가 잡아낸 QUIC CUBIC 버그, ‘idle’ 한 줄 오판이 다운로드를 죽였다

Cloudflare의 QUIC 구현체 quiche에서 CUBIC 혼잡 제어가 최소 윈도우에 갇혀 회복하지 못하는 버그가 발견됐다. Linux 커널의 idle 최적화를 QUIC에 옮기는 과정에서 TCP와 QUIC의 이벤트 타이밍 차이를 놓쳤고, 결국 ACK 시점을 기준으로 idle 시간을 재도록 고쳐 100% 테스트 통과를 회복했다.

backend

삼성전자가 반도체 개발 조직에 오라클 자바를 공식 채택한 이유

삼성전자 DS 부문이 글로벌 반도체 개발 환경에 오라클 자바 SE 유니버설 서브스크립션을 공식 채택했다. 서로 다른 자바 배포판과 버전이 섞이면서 생길 수 있는 보안, 컴플라이언스, 라이선스 리스크를 줄이고 개발 환경을 표준화하려는 결정이다.

backend

네이버클라우드, 트래픽 따라 알아서 줄고 느는 서버리스 데이터베이스 출시

네이버클라우드가 사용량에 따라 CPU, 메모리, 스토리지를 자동 조절하는 완전관리형 서버리스 데이터베이스 서비스를 내놨다. 기존 가상머신 기반 관리형 데이터베이스처럼 피크 트래픽에 맞춰 서버를 과하게 잡아두는 방식에서 벗어나, 사용량 기반 과금과 오토스케일링으로 비용 낭비를 줄이겠다는 방향이다.

backend

네이버클라우드, 사용량 따라 늘고 줄어드는 서버리스 데이터베이스 출시

네이버클라우드가 완전관리형 서버리스 데이터베이스 서비스인 Cloud DB Serverless를 출시했다. VM 기반 관리형 데이터베이스의 고정 비용과 과잉 프로비저닝 문제를 줄이고, 트래픽에 따라 CPU·메모리·스토리지를 자동 조절하는 구조를 내세운다.

backend

네이버클라우드, 사용량 따라 자동 확장되는 서버리스 데이터베이스 출시

네이버클라우드가 사용량에 따라 컴퓨팅 자원을 자동 조절하는 서버리스 기반 클라우드 데이터베이스를 출시했음. 기존 가상머신 기반 관리형 데이터베이스의 고정 비용과 운영 부담을 줄이고, 국내 데이터 규제 요구까지 맞추겠다는 전략임.