MQTT 페이로드 설계: JSON vs Protobuf vs CBOR

소개

사물인터넷 환경에서 MQTT는 가볍고 널리 쓰이는 프로토콜이다. 하지만 페이로드 포맷 선택은 성능과 유지보수에 큰 영향을 준다. 이 글은 MQTT 페이로드를 JSON, Protobuf, CBOR 세 가지 관점에서 비교한다. 처음 접하는 개발자도 이해할 수 있도록 장단점과 설계 포인트, 실제 예제를 함께 제시한다.

페이로드 설계가 중요한 이유

페이로드는 네트워크 트래픽과 디바이스 자원 사용을 좌우한다. 전송 크기, 직렬화/역직렬화 비용, 스키마 진화 방식, 디버깅 편의성 등이 선택 기준이다. 또한 상호운용성 요구와 보안 규칙도 고려해야 한다.

포맷별 개요

JSON

JSON은 읽기 쉽고 도구 지원이 풍부하다. 디버깅과 사람이 이해하기 쉬운 형식이 장점이다. 표준 라이브러리로 바로 사용할 수 있어 초기 개발이 빠르다.

단점은 텍스트 기반이라 바이트 효율이 낮고 파싱 비용이 상대적으로 높다는 점이다. 스키마가 명확하지 않으면 필드 변경에서 런타임 오류가 발생할 수 있다.

{
  "deviceId": "sensor-01",
  "ts": 1627890123,
  "temp": 23.7,
  "status": "ok"
}

Protobuf

Protobuf는 구글이 만든 이진 직렬화 포맷이다. 크기가 작고 파싱 속도가 빠르다. 스키마(.proto)를 통해 타입 안전성과 명확한 버전 관리를 제공한다.

단점은 초기 설정과 빌드 파이프라인이 필요하고, 디버깅이 불편하다는 점이다. 또한 스키마 변경 시 호환성을 신경 써야 한다.

syntax = "proto3";

message Telemetry {
  string deviceId = 1;
  uint64 ts = 2;
  double temp = 3;
  string status = 4;
}

// 사용 예 (의사 코드)
// payload = Telemetry.encode({ deviceId: "sensor-01", ts: 1627890123, temp: 23.7, status: "ok" })

CBOR

CBOR(Concise Binary Object Representation)은 JSON과 유사한 구조를 이진으로 표현한다. 가독성을 어느 정도 유지하면서도 바이트 효율이 좋다. 확장성도 유연하다.

단점은 일부 환경에서 라이브러리 지원이 부족할 수 있고, 스키마를 별도로 정의하지 않으면 타입 혼동이 발생할 수 있다.

// CBOR 예제 (표현형)
// { "deviceId": "sensor-01", "ts": 1627890123, "temp": 23.7, "status": "ok" }
// CBOR 바이트 시퀀스: 0xa4 68 64 65 76 69 63 65 49 ... (예시)

비교 관점별 상세 분석

전송 크기 및 성능

• JSON: 텍스트 기반이라 크기가 크다. 압축으로 개선 가능하지만 CPU 부담 증가.
• Protobuf: 매우 효율적이다. 필드 번호 방식으로 반복되는 구조에 우수.
• CBOR: 대부분의 경우 JSON보다 작고, 구조가 단순하면 Protobuf와 비슷한 성능을 보임.

스키마와 확장성

• JSON: 스키마가 명시적이지 않다. JSON Schema 같은 별도 규칙을 사용하면 해결 가능.
• Protobuf: 스키마 기반으로 필드 추가/제거 시 호환성 지침이 명확하다.
• CBOR: 스키마 없이 유연하나, 데이터 해석 규칙을 문서화해야 안정적이다.

도구와 개발 편의성

• JSON: 모든 언어에서 기본 지원. 디버깅과 로깅이 용이하다.
• Protobuf: 코드 생성 도구가 있어 타입 안정성이 높다. 빌드 파이프라인 필요.
• CBOR: 라이브러리 의존성이 있지만 사용법은 단순하다. 디버거 지원은 제한적일 수 있다.

디바이스 제약(메모리/CPU)

제한된 MCU 환경에서는 이진 포맷(Protobuf, CBOR)이 유리하다. 단, Protobuf의 런타임과 코드 크기를 고려해야 한다. CBOR는 경량 라이브러리로 효율적일 수 있다.

설계 패턴과 권장사항

• 초기 프로토타입 또는 로그 중심 서비스: JSON 권장. 빠른 개발과 가시성이 장점.
• 대규모 디바이스 네트워크에서 대역폭 절감이 필요할 때: Protobuf 권장.
• 유연성과 중간 수준의 이진 효율을 원할 때: CBOR 고려.
• 스키마 관리: 중앙 레지스트리(.proto 저장소, JSON Schema, CBOR 표준 문서)를 둔다.
• 버전 전략: 필드 번호 재사용 금지, 선택 필드는 optional 처리, 기본값 명시.

간단한 결정 흐름

• 디버깅과 빠른 개발이 우선이면 JSON.
• 대역폭과 성능이 우선이면 Protobuf.
• 가벼운 이진 포맷에 유연성도 원하면 CBOR.

결론

정답은 사용 환경에 달려 있다. 작은 파일 전송과 낮은 지연이 필요하다면 Protobuf를 우선 고려한다. 개발 속도와 가시성이 중요하면 JSON이 합리적이다. 중간 수준의 절충을 원하면 CBOR가 좋은 대안이다. 마지막으로 mqtt json vs protobuf, mqtt payload cbor 사용, iot payload 포맷 비교 관점에서 요구사항을 명확히 정리한 뒤 선택하는 과정이 중요하다.