입력

출력

JSON에서 MessagePack으로란?

대역폭이 빠듯한 WebSocket으로 보내야 할 JSON 설정이 있다면 — MessagePack이 같은 페이로드를 JSON으로 보낼 때보다 30~60% 줄여줍니다. 게다가 JSON을 다루기 편하게 만드는 "그냥 객체" 같은 스키마리스 느낌을 포기하지 않고도 가능합니다. 이 페이지는 왼쪽에 붙여넣은 JSON을 오른쪽에서 msgpack 바이트 스트림으로 인코딩하며, 기본은 base64이고 한 번 클릭으로 hex로 전환할 수 있습니다.

인코딩은 공식 @msgpack/msgpack 라이브러리를 사용해 전부 브라우저에서 실행되므로, JSON은 탭 밖으로 나가지 않습니다. 내부적으로는 JSON RFC가 명세하는 JSON.parse로 입력을 파싱하고, 결과 객체를 msgpackEncode에 넘긴 뒤, 반환된 Uint8Array를 전송 친화적인 문자열 — base64(RFC 4648 기준) 또는 소문자 hex로 변환합니다.

JSON, HTTP 헤더, DB 필드에 바이트를 임베드할 때는 base64를 쓰세요. msgpack 와이어 사양이나 서버 로그와 샘플을 바이트 단위로 비교할 때는 hex를 쓰세요. 같은 바이트의 다른 표현일 뿐입니다.

JSON에서 MessagePack 인코더 사용법

세 단계입니다. 입력하는 동안 변환이 자동으로 실행됩니다 — 누를 버튼이 없습니다.

JSON 붙여넣기 또는 샘플 불러오기

왼쪽 에디터에 JSON을 넣으세요. 샘플 JSON을 누르면 문자열, 정수, 부동소수점, 중첩 배열 등 의미 있는 케이스를 다루는 작은 주문 페이로드가 들어옵니다. 인코더는 입력을 표준 MessagePack 타입 시스템으로 처리합니다: 정수는 가장 작은 fixint/int8/int16/int32/int64 형식을 사용하고, 부동소수점은 float64가 되며, 문자열은 길이에 따라 fixstr/str8/16/32, 배열은 fixarray/array16/32, 맵은 fixmap/map16/32를 사용합니다. 입력 예시:

{
  "orderId": "ORD-7421",
  "items": [{ "sku": "SKU-101", "qty": 2 }],
  "total": 89.50
}

이런 90바이트짜리 JSON은 보통 ~55바이트의 msgpack으로 인코딩됩니다 — gzip 한 겹 얹기도 전에 약 1/3 더 작아진다는 뜻입니다.

Hex와 Base64 전환

출력 형식의 기본값은 base64입니다 — 보통 설정에 붙여넣거나 통신으로 보낼 때 쓰는 형식이기 때문입니다. 서버 측 인코더와 diff를 뜨거나 타입 바이트를 눈으로 확인하고 싶다면(예: fixmap of 2를 의미하는 0x82) Hex 출력을 눌러 소문자 hex로 전환하세요. 원하는 만큼 전환해도 — 내부 바이트는 동일합니다.

복사해서 보내기

복사를 눌러 출력을 클립보드에 담으세요. Redis SET, WebSocket 텍스트 프레임, Content-Type: application/x-msgpack이 붙은 HTTP 본문, Postgres의 bytea 컬럼(base64를 먼저 디코딩) 등에 그대로 넣을 수 있습니다. 반대 방향이 필요하면 MessagePack에서 JSON으로 페이지에 붙여넣으세요.

실제로 쓰게 되는 상황

WebSocket 프레임 줄이기

초당 업데이트가 잦은 실시간 앱에서는 크기 차이가 체감됩니다. JSON으로 220바이트짜리 위치 업데이트나 호가창 틱이 msgpack에서는 ~140바이트로 떨어집니다 — 초당 수천 프레임이라면 누적 차이가 큽니다. 샘플 메시지를 여기서 변환해 테스트 하니스에 바이트를 붙여넣고, 수신 측이 동일하게 디코딩하는지 확인해 보세요.

캐시 값 압축

Redis 같은 캐시는 저장하는 모든 바이트와 읽는 모든 바이트에 비용을 매깁니다. 캐시 객체를 JSON 문자열 대신 msgpack으로 인코딩하면 매 히트마다 저장 공간과 네트워크를 줄일 수 있습니다. 시리얼라이저에 인코딩 방식을 확정하기 전에, 이 페이지에서 특정 객체가 바이트로 어떻게 보일지 미리 점검하세요.

타입이 있는 숫자 보내기

JSON에는 숫자 타입이 하나뿐이라 42와 42.0을 똑같이 다룹니다. MessagePack은 와이어상에서 정수와 부동소수점을 구분합니다 — 수신 측이 Go, Rust, C# 같은 강타입 언어이고 문자열을 거치는 왕복을 피하고 싶을 때 유용합니다. JSON 숫자를 붙여넣고 hex 출력에서 타입 바이트를 확인하면 float이 아니라 int로 인코딩되었는지 검증할 수 있습니다.

디코더 디버깅

"msgpack이어야 하는" 서비스인데 컨슈머가 바이트를 못 읽고 막힌다고요? 같은 JSON을 여기서 인코딩하고, 서비스의 출력과 우리 출력을 hex 모드로 바이트 단위로 비교해 보세요. 어긋나는 지점에서 어느 필드 또는 타입이 잘못되었는지 정확히 알 수 있습니다. 레퍼런스 인코더는 공개 사양을 정확히 따릅니다.

자주 묻는 질문

JSON이 제 브라우저 밖으로 나가나요?

아니요. JSON은 브라우저에 내장된 JSON.parse로 파싱되고, 클라이언트 사이드 JavaScript의 @msgpack/msgpack 라이브러리로 인코딩되어 오른쪽 패널에 base64 또는 hex로 렌더링됩니다 — 서버 호출도, 입력에 대한 텔레메트리도, 어떤 로그도 남기지 않습니다. DevTools를 열어보면 입력하는 동안 네트워크 탭이 조용한 것을 직접 확인할 수 있습니다. 사내 기밀 설정이나 고객 데이터에도 안전합니다.

왜 출력이 예상보다 큰가요?

보통 두 가지 이유입니다. 첫째, base64는 바이트 수를 약 33% 부풀립니다 — base64-msgpack을 JSON 텍스트와 직접 비교하면 실제 와이어 크기를 비교하는 게 아닙니다. hex(이쪽은 2배로 부풀림)로 전환하거나, 더 좋게는 바이트 길이를 보세요: DevTools에서 atob(output).length를 실행하면 진짜 크기가 나옵니다. 둘째, msgpack이 JSON을 이기는 건 데이터에 숫자, 불리언, 반복되는 짧은 문자열이 많을 때입니다. 90%가 길고 고유한 문자열인 데이터 덩어리는 어느 형식이든 거의 같은 크기가 됩니다.

정수, 부동소수점, 큰 수는 어떻게 처리되나요?

JavaScript의 JSON.parse는 모든 숫자를 64비트 부동소수점으로 만들기 때문에, 데이터가 인코더에 도달할 즈음에는 이미 int 대 float 구분이 사라져 있습니다. 라이브러리는 이를 합리적으로 처리합니다: 값이 정수이고 safe-int 범위 안이면 int로 인코딩(가장 작은 변형 — fixint, int8, int16, int32, int64 중 선택)하고, 그 외에는 float64로 인코딩합니다. Snowflake ID처럼 정확한 64비트 정수가 필요하다면, JSON에서는 문자열로 전달한 뒤 수신 측에서 변환하세요.

이걸로 바이너리 블롭(파일 바이트 같은 것)을 인코딩할 수 있나요?

JSON을 거쳐서는 직접 안 됩니다 — JSON에는 bin 타입이 없으므로 Uint8Array는 이 UI를 base64 문자열로 왕복하고 msgpack의 str로 다시 인코딩됩니다. bin이 되지 않습니다. 실제 msgpack의 bin이나 ext 타입(msgpack에만 있는 두 가지 큰 기능)이 필요하다면, 코드에서 객체를 만들고 Uint8Array를 그대로 넣어 encode를 직접 호출해야 합니다. JSON 패널은 데이터가 이미 JSON 모양인 90% 케이스를 위한 것입니다.

hex와 base64 출력의 차이는 무엇인가요?

같은 바이트를 텍스트로 쓰는 두 가지 방식입니다. Hex는 바이트당 두 글자(따라서 0x82는 문자열 "82") — 사양의 타입 바이트를 눈으로 읽기에 좋습니다. Base64는 RFC 4648에 따라 3바이트당 4글자 — 더 조밀하고, JSON, JWT, HTTP 헤더에 바이너리를 임베드하는 표준 방식입니다. 출력을 붙여넣는 곳에 맞는 쪽을 선택하세요.

msgpack이 JSON보다 정말 빠른가요, 아니면 그냥 작은 건가요?

작다는 게 보통 더 큰 승부처입니다. 인코딩/디코딩 속도에서, 요즘 JSON.parse는 충분히 최적화되어 있어서 JS에서는 msgpack이 비슷하거나 10~20% 정도만 앞섭니다. 시리얼라이즈의 이점은 하류에서 드러납니다: 페이로드가 작으면 네트워크 시간이 줄고, JSON 파싱이 msgpack 파싱보다 비싼 언어(Python, 너 말이야)에서는 수신 측 부담도 줄어듭니다. 빠른 가이드: 병목이 대역폭이나 저장소면 msgpack을, 가독성과 도구 생태계라면 JSON을 유지하세요.

다른 MessagePack 도구

인코딩은 한 방향입니다. 다음은 왕복의 나머지를 다룹니다: