JSON을 대체하는 데이터 포맷: LinkedIn, Uber, Slack, Auth0 사례 비교 분석

JSON을 대체할 형식: LinkedIn, Uber, Slack, Auth0 사례 분석

JSON은 오랫동안 데이터 직렬화의 표준처럼 사용되어 왔지만, 대규모 데이터 처리와 성능 최적화가 중요한 환경에서는 몇 가지 한계가 드러났습니다. 이 글에서는 JSON의 한계를 극복하고자 실제 대규모 서비스 기업들이 도입한 대체 형식들을 살펴봅니다.

 

1. LinkedIn: Protocol Buffers 통합

LinkedIn은 성능 최적화를 위해 Google의 Protocol Buffers (Protobuf) 를 채택했습니다.

• 특징: Protobuf는 이진(binary) 형식으로 데이터를 직렬화하여, JSON 대비 크기를 줄이고 파싱 속도를 크게 향상시킵니다.
• LinkedIn 사례: LinkedIn은 REST API 백엔드와 프론트엔드 간 통신에서 Protobuf를 도입해 응답 크기를 줄이고, 모바일 앱 성능을 개선했습니다.
• 장점: 빠른 직렬화/역직렬화, 작은 데이터 크기, 명확한 스키마 정의
• 단점: 사람이 읽기 어려운 포맷, 스키마 변경 관리 필요

 

2. Uber: H3 Geo-Index

Uber는 지리 공간 데이터 최적화를 위해 H3 (Hexagonal Hierarchical Spatial Index) 를 개발했습니다.

• 특징: H3는 전 세계 지표면을 16단계로 정밀하게 분할하는 육각형 기반 인덱싱 시스템입니다.
• Uber 사례: 이동 수요 예측, 차량 배치 최적화, 지도 렌더링 등 다양한 위치 기반 서비스에 활용하고 있습니다.
• 장점: 지리 정보 데이터의 압축 및 정밀 표현, 공간 연산 최적화
• 단점: 범용 직렬화 포맷은 아니며, 위치 데이터에 특화

 

3. Slack: 메시지 포맷 최적화

Slack는 내부 메시징 프로토콜을 JSON에서 커스텀 바이너리 포맷으로 변경했습니다.

• 특징: Slack은 수백만 개의 실시간 메시지를 처리하기 위해 네트워크 대역폭 절감과 속도 향상에 초점을 맞춘 포맷을 개발했습니다.
• Slack 사례: WebSocket 통신에서 JSON 대신 더 작은 크기의 최적화된 바이너리 메시지를 전송하여 레이턴시를 줄였습니다.
• 장점: 실시간 처리 성능 향상, 네트워크 트래픽 감소
• 단점: 개발 복잡성 증가, 디버깅 난이도 상승

메시지 포맷 최적화에 따른 데이터 크기 비교

포맷 종류	평균 메시지 크기 (Bytes)
JSON	1200 Bytes
커스텀 바이너리 포맷	450 Bytes

Slack의 최적화된 바이너리 포맷은 평균적으로 JSON 대비 약 62.5% 이상의 데이터 크기를 절감할 수 있습니다.

graph TD
A[JSON: 1200 Bytes] --> B[커스텀 바이너리 포맷: 450 Bytes]

 

4. Auth0: Protocol Buffers 적용

Auth0도 인증 및 보안 토큰 처리 최적화를 위해 Protocol Buffers를 도입했습니다.

• 특징: 빠르고 경량화된 포맷이 인증 시스템에서 중요한 성능과 보안 요건을 만족시킵니다.
• Auth0 사례: 인증 요청과 응답에 대해 Protobuf를 사용해 처리 속도와 일관성을 개선했습니다.
• 장점: 데이터 무결성 강화, 빠른 처리
• 단점: JSON 기반 API와의 호환성 문제 가능성

 

5. 같은 JSON 데이터에 대한 포맷별 크기 비교 예시

포맷 종류크기 (Bytes)

JSON	약 100 Bytes
Protocol Buffers	약 40 Bytes
H3 Geo-Index*	(적용 불가)
BSON (Binary JSON)	약 80 Bytes

barChart
    title 포맷별 데이터 크기 비교
    "JSON" : 100
    "Protocol Buffers" : 40
    "BSON" : 80

※ H3는 일반 데이터 직렬화에 사용되지 않고, 위치 데이터에 특화된 인덱싱입니다.

 

6. 개인적 추천 및 도입은 BSON (Binary JSON)

BSON은 Binary JSON의 약자로, JSON과 유사한 구조를 가지면서도 이진 데이터로 인코딩하여 더 빠른 파싱과 효율적인 저장을 지원합니다.

• 특징: JSON의 가독성과 구조를 유지하면서, 바이너리 형식으로 속도 및 크기 최적화를 달성
• 장점: 빠른 읽기/쓰기, ObjectId 같은 특수 타입 지원
• 단점: 순수 JSON 대비 약간의 오버헤드 존재

BSON 활용 방법 심화 (Java 예제)

Gradle 의존성 추가

dependencies {
    implementation 'org.mongodb:bson:4.11.0'
}

Java 코드 예시

import org.bson.BsonBinaryReader;
import org.bson.BsonBinaryWriter;
import org.bson.BsonDocument;
import org.bson.Document;
import org.bson.codecs.BsonDocumentCodec;
import org.bson.io.BasicOutputBuffer;

import java.nio.ByteBuffer;

public class BsonExample {
    public static void main(String[] args) {
        Document document = new Document()
                .append("name", "Alice")
                .append("age", 30)
                .append("email", "alice@example.com");

        BasicOutputBuffer buffer = new BasicOutputBuffer();
        BsonBinaryWriter writer = new BsonBinaryWriter(buffer);
        new BsonDocumentCodec().encode(writer, document.toBsonDocument(Document.class, null), null);

        byte[] bsonBytes = buffer.toByteArray();
        System.out.println("Serialized BSON size: " + bsonBytes.length + " bytes");

        BsonBinaryReader reader = new BsonBinaryReader(ByteBuffer.wrap(bsonBytes));
        BsonDocument decodedDoc = new BsonDocumentCodec().decode(reader, null);
        System.out.println("Deserialized BSON Document: " + decodedDoc.toJson());
    }
}

 

---

비교 분석

기업	사용 기술	주된 목적	장점	단점
LinkedIn	Protocol Buffers	API 성능 최적화	작은 크기, 빠른 파싱	스키마 관리 필요
Uber	H3 Geo-Index	위치 데이터 최적화	공간 연산 최적화	범용성 부족
Slack	커스텀 바이너리 포맷	실시간 메시징 최적화	대역폭 절감	디버깅 복잡성
Auth0	Protocol Buffers	인증 데이터 최적화	빠른 처리, 데이터 무결성	호환성 문제 가능
개인 도입	BSON	경량 저장 및 전송	빠른 읽기/쓰기, 유연성	약간의 오버헤드

 

결론

JSON은 여전히 널리 사용되지만, 대규모 트래픽, 빠른 응답성, 특수 데이터 구조가 필요한 경우에는 대체 형식을 고려할 가치가 있습니다. 특히, Protocol Buffers와 같은 이진 직렬화 포맷은 다양한 기업이 선택하는 대안으로 부상하고 있습니다. BSON은 구조를 유지하면서도 더 나은 성능을 제공할 수 있는 훌륭한 대안이며, Kafka와 같은 스트리밍 환경에서도 유용하게 활용할 수 있습니다. 반면, Uber의 H3처럼 특정 도메인 문제를 해결하기 위한 포맷도 존재한다는 점에서, 상황에 맞는 선택이 중요합니다.