제 2장. 메시지 형식

메시지 형식(message format)은 통신 주체 사이에서 교환되는 자료의 구문적 표현을 결정하는 가장 기초적인 합의이다. 본 장에서는 「범용 프로토콜 표준」(WIA-CORE-007)이 권고하는 열 가지 표준 메시지 형식 — JSON, CBOR, PROTOBUF, MSGPACK, AVRO, BSON, BINARY_FORMAT, XML, YAML, TOML — 의 의미론, 직렬화 효율, 스키마 진화 전략, 한국 산업계의 실무 적용 사례를 다룬다. 각 형식의 분석은 RFC 8259, RFC 8949, Protocol Buffers v3, MessagePack, Apache Avro 1.11과 같은 1차 출처에 근거하며, 형식 사이의 무손실 변환 규칙을 함께 제시한다.⁹⁹

§2.1 메시지 형식 선택의 다섯 가지 차원

메시지 형식의 선택은 단순히 「어느 라이브러리가 빠른가」의 문제가 아니라, 다섯 가지 차원에서 균형을 모색해야 하는 다목적 최적화 문제이다. 첫째 차원은 「가독성」으로, 사람이 텍스트 편집기로 메시지를 직접 읽고 수정할 수 있는지를 말한다. JSON, XML, YAML, TOML은 모두 사람이 읽을 수 있는 텍스트 형식이며, CBOR, PROTOBUF, MSGPACK, AVRO, BSON, BINARY_FORMAT은 바이너리 형식이다. 둘째 차원은 「직렬화 효율」로, 동일한 의미를 표현할 때 필요한 바이트 수와 변환 시간을 말한다. 일반적으로 바이너리 형식이 텍스트 형식보다 효율적이지만, 압축 알고리즘과 결합하면 그 격차는 좁아진다.

셋째 차원은 「스키마 강제력」으로, 메시지 구조를 사전에 규정하는지 여부를 말한다. PROTOBUF, AVRO, THRIFT는 사전 스키마를 요구하는 「강한 스키마」 형식이며, JSON, YAML, TOML, BSON은 스키마 없이도 메시지를 구성할 수 있는 「약한 스키마」 형식이다. CBOR과 MSGPACK은 중간 형태로서, 스키마 없이도 자기 기술적(self-describing) 메시지를 구성할 수 있지만 스키마와 결합하면 효율이 높아진다. 넷째 차원은 「언어 중립성」으로, 다양한 프로그래밍 언어에서 일관되게 사용할 수 있는지를 말한다. JSON, CBOR, PROTOBUF, MSGPACK은 거의 모든 주류 언어에서 라이브러리를 제공하지만, BSON은 MongoDB 생태계, BINARY_FORMAT은 .NET 생태계에 편향되어 있다.

다섯째 차원은 「스키마 진화 친화성」으로, 시간이 흐름에 따라 메시지 구조를 변경할 때의 안전성을 말한다. PROTOBUF는 필드 번호를 통한 하위·상위 호환성을, AVRO는 「작성자 스키마와 독자 스키마」 분리를 통한 진화를, JSON은 명시적 규약 없는 「관용적 진화」를 각각 채택한다. 본 표준은 강한 스키마 진화 친화성이 필요한 영역에서는 PROTOBUF·AVRO를, 가벼운 호환성이 충분한 영역에서는 JSON·CBOR을 권고한다.⁹⁹

형식	가독성	직렬화 효율	스키마 강제력	1차 출처
JSON	높음(텍스트)	보통	약함	RFC 8259
CBOR	낮음(바이너리)	높음	중간	RFC 8949
PROTOBUF	낮음(바이너리)	매우 높음	강함	Protocol Buffers v3
MSGPACK	낮음(바이너리)	높음	중간	MessagePack 명세
AVRO	낮음(바이너리)	높음	강함	Apache Avro 1.11
BSON	낮음(바이너리)	높음	약함	BSON 1.1 명세
XML	높음(텍스트)	낮음	강함(XSD)	W3C XML 1.0
YAML	매우 높음	낮음	약함	YAML 1.2
TOML	매우 높음	낮음	중간	TOML 1.0
BINARY_FORMAT	없음	매우 높음	구현 의존	구현 명세

§2.2 JSON: 웹의 사실상 표준

JSON(JavaScript Object Notation)은 더글러스 크록포드(Douglas Crockford)가 2001년 발표하고 IETF가 RFC 4627(2006), RFC 7159(2014), RFC 8259(2017)로 표준화한 텍스트 기반 메시지 형식이다. JSON의 의미 모델은 여섯 가지 자료형 — 객체(object), 배열(array), 문자열(string), 수치(number), 진리값(boolean), 널(null) — 으로 구성되며, 이는 자바스크립트의 기본 자료형과 거의 일치한다. JSON은 사람이 읽을 수 있는 형식이면서도 파서 구현이 단순하여, 웹 API의 사실상 표준으로 자리잡았다.⁹⁹

JSON의 가장 큰 강점은 「학습 곡선의 평탄함」과 「언어 중립성」이다. 거의 모든 프로그래밍 언어가 표준 라이브러리 또는 1급 라이브러리로 JSON 직렬화·역직렬화를 제공한다. 자바스크립트의 JSON.parse()·JSON.stringify(), 파이썬의 json 모듈, Go의 encoding/json, Rust의 serde_json, 자바의 Jackson·Gson은 모두 RFC 8259를 준수한다. JSON-RPC_2_0(JSON_RPC_2_0)은 JSON을 메시지 운반체로 사용하는 원격 호출 규약으로서, REST_RPC의 가벼운 대안으로 널리 채택되었다.

JSON의 한계는 세 가지이다. 첫째, 바이너리 데이터를 직접 표현할 수 없어 Base64 인코딩이 필요하며 이는 33%의 크기 오버헤드를 발생시킨다. 둘째, 정수와 부동소수점을 구분하지 않아 큰 정수(64비트)의 정밀도 손실이 발생할 수 있다. 셋째, 주석을 지원하지 않아 구성 파일 용도로는 제약이 있다. 이러한 한계를 보완하기 위해 JSON5, JSONC, HOCON 등 변종이 등장하였으나, 본 표준은 표준 JSON(RFC 8259)을 권고하며 부가 기능이 필요한 경우 다른 형식(YAML, TOML)을 사용할 것을 제안한다.

// JSON 예시 (RFC 8259 준수)
{
  "protocol": "WIA-CORE-007",
  "version": "1.0",
  "message_format": "JSON",
  "transport": "HTTP_2",
  "auth": "OAUTH_2_1",
  "timestamp": "2025-12-29T00:00:00Z"
}

§2.3 CBOR: 사물인터넷 시대의 바이너리 JSON

CBOR(Concise Binary Object Representation)은 IETF가 RFC 7049(2013)로 최초 발행하고 RFC 8949(2020)로 갱신한 바이너리 메시지 형식이다. CBOR의 설계 목표는 JSON과 동일한 의미 모델을 유지하면서 바이너리 효율을 달성하는 것이다. CBOR은 자기 기술적 형식으로서, 메시지 자체가 자신의 구조를 표현하므로 별도의 스키마 없이도 디코딩이 가능하다. CBOR은 IoT 디바이스, CoAP(Constrained Application Protocol), DNS-over-HTTPS 등 자원 제약 환경에서 표준 메시지 형식으로 채택되었다.⁹⁹

CBOR의 자료형은 JSON의 여섯 가지를 모두 포함하면서 「바이너리 문자열」, 「태그」(tag), 「부정 정수」, 「부동소수점」(IEEE 754 16/32/64비트), 「반정밀도 부동소수점」 등을 추가로 지원한다. 「태그」는 CBOR의 가장 독창적인 기능으로서, 메시지에 의미론적 주석을 부착할 수 있다. 예컨대 태그 0은 「표준 날짜·시간 문자열」을, 태그 1은 「유닉스 타임스탬프」를, 태그 32는 「URI」를, 태그 33은 「Base64URL」을 각각 가리킨다. 이러한 태그 체계는 IANA가 관리하며, 본 표준은 RFC 8949 부록 C의 표준 태그를 사용할 것을 권고한다.

CBOR의 효율은 JSON 대비 평균 20~40% 우수하다. 예컨대 64비트 정수 12345678901234를 JSON으로 표현하면 14 바이트가 필요하지만, CBOR로는 9 바이트만 필요하다. 그러나 CBOR의 진정한 가치는 단순한 크기 절감이 아니라, COSE(CBOR Object Signing and Encryption, RFC 9052), CWT(CBOR Web Token, RFC 8392), SUIT(Software Update for IoT) 등 IoT 보안 표준의 기반 형식이라는 점에 있다.

§2.4 PROTOBUF: 구글의 강한 스키마

Protocol Buffers(이하 PROTOBUF)는 구글이 2008년 오픈소스로 공개한 강한 스키마 메시지 형식이다. PROTOBUF는 사전에 .proto 파일로 메시지 구조를 정의하고, 이를 코드 생성기(protoc)가 각 언어의 클래스로 변환하는 방식을 채택한다. 본 표준은 Protocol Buffers v3(proto3)을 권고하며, v2와의 차이점은 「optional 키워드의 명시적 의무화」와 「기본값의 명시적 직렬화 제외」이다. PROTOBUF는 GRPC의 기본 메시지 형식으로 채택되어, 마이크로서비스 통신의 사실상 표준 중 하나가 되었다.⁹⁹

PROTOBUF의 가장 강력한 기능은 「스키마 진화」이다. 각 필드에는 1부터 시작하는 양의 정수 「필드 번호」가 할당되며, 이 번호는 와이어 형식에서 필드를 식별하는 고유 키로 사용된다. 새 필드를 추가할 때는 새로운 번호를 부여하고, 기존 필드를 제거할 때는 reserved 키워드로 그 번호를 영구히 예약한다. 이러한 규약을 따르면 옛 코드가 새 메시지를, 새 코드가 옛 메시지를 모두 읽을 수 있는 양방향 호환성이 보장된다.

// protobuf 예시 (proto3 문법)
syntax = "proto3";
package wia.core.v1;

message ProtocolMessage {
  string protocol = 1;
  string version = 2;
  string message_format = 3;  // ENUM JSON·CBOR·PROTOBUF 등
  string transport = 4;        // ENUM TCP·UDP·QUIC·WEBSOCKET·HTTP_3
  string auth = 5;             // ENUM OAUTH_2_1·OIDC·JWT·MTLS
  int64 timestamp_ms = 6;
  reserved 7, 8, 9;            // 향후 확장용 예약
}

PROTOBUF의 한계는 「가독성의 부재」와 「학습 곡선의 가파름」이다. 바이너리 메시지를 직접 디버깅하려면 protoc 도구가 필수이며, 신규 개발자가 PROTOBUF 생태계에 익숙해지기까지 평균 2주 이상이 소요된다는 산업계 조사가 있다. 또한 PROTOBUF는 자체적으로 RPC를 정의하지 않으며, GRPC, CONNECT_RPC, MSGPACK_RPC 등의 RPC 프레임워크와 결합하여 사용된다.

§2.5 MSGPACK·AVRO·BSON: 영역별 특화

MSGPACK(MessagePack)은 2008년 후루하시 사다유키(古橋貞之)가 공개한 바이너리 메시지 형식으로서, JSON과 의미 모델이 동일하면서도 약 30% 작은 크기를 달성한다. MSGPACK은 RPC 프레임워크인 MSGPACK_RPC를 함께 제공하여, JSON_RPC_2_0의 바이너리 대안으로 사용된다. MSGPACK은 Redis, Fluentd, Treasure Data 등 일본 기원의 미들웨어에서 기본 형식으로 채택되어 있다.⁹⁹

AVRO(Apache Avro 1.11)는 아파치 재단이 관리하는 바이너리 메시지 형식으로서, 빅데이터 생태계(Hadoop, Spark, KAFKA)에서 표준으로 채택되었다. AVRO의 가장 큰 차별점은 「작성자 스키마」(writer schema)와 「독자 스키마」(reader schema)를 명시적으로 분리하는 것이다. 메시지에는 작성 당시의 스키마가 직접 또는 간접(스키마 레지스트리)으로 포함되며, 독자는 자신의 스키마와 작성자 스키마를 비교하여 안전한 해석을 수행한다. AVRO_RPC는 AVRO를 운반체로 사용하는 RPC 규약이다.

BSON(Binary JSON)은 MongoDB가 자체 데이터베이스 저장 형식으로 설계한 바이너리 메시지 형식이다. BSON은 JSON의 모든 자료형을 포함하면서 「ObjectId」, 「Date」, 「Binary」, 「Decimal128」 등 추가 자료형을 지원한다. BSON은 MongoDB 생태계에서 사실상 표준이며, MongoDB 4.4 이후로는 BSON 1.1 명세가 적용된다. 본 표준은 BSON을 MongoDB와 직접 연동하는 영역에 한정하여 권고하며, 일반적인 메시지 교환에는 CBOR 또는 PROTOBUF를 권고한다.

§2.6 XML·YAML·TOML·BINARY_FORMAT

XML(eXtensible Markup Language)은 W3C가 1998년 표준화한 텍스트 기반 메시지 형식이다. XML은 강한 스키마(XSD)와 변환 언어(XSLT), 질의 언어(XPath, XQuery)를 모두 갖춘 풍부한 생태계를 보유한다. SOAP, AMQP의 일부 변종, SAML_2, SAML_2_AUTH는 모두 XML을 운반체로 사용한다. 그러나 XML의 장황함은 직렬화 효율을 저하시켜, 현대 시스템에서는 점차 JSON·CBOR로 대체되고 있다.⁹⁹

YAML(YAML Ain't Markup Language)은 2001년 클락 에반스(Clark Evans) 등이 제안한 사람 친화적 텍스트 형식으로서, 들여쓰기로 구조를 표현한다. YAML 1.2(2009 발행, 2021 갱신)는 JSON의 상위집합으로 정의되어, 모든 JSON 문서는 유효한 YAML 문서이다. YAML은 Kubernetes 매니페스트, Ansible 플레이북, GitHub Actions 워크플로 등 구성 파일 영역에서 광범위하게 사용된다.

TOML(Tom's Obvious, Minimal Language)은 2013년 깃허브 공동 창업자 톰 프레스턴-워너(Tom Preston-Werner)가 제안한 구성 파일 형식이다. TOML 1.0(2021 발행)은 INI 파일의 단순함과 JSON의 명료함을 결합하여, Rust의 Cargo, Python의 pyproject.toml, Hugo 정적 사이트 생성기 등에서 채택되었다.

BINARY_FORMAT은 본 표준의 맥락에서 「구현 의존적 바이너리 직렬화」를 가리키는 일반 용어이다. .NET의 BinaryFormatter, 자바의 Serializable, 파이썬의 pickle은 모두 BINARY_FORMAT의 대표 사례이다. 본 표준은 BINARY_FORMAT을 같은 언어 런타임 내부의 일시적 직렬화에 한정하여 권고하며, 언어 경계를 넘는 통신에는 사용하지 말 것을 권한다. 그 이유는 BINARY_FORMAT이 보안 취약점(역직렬화 공격)에 노출되기 쉽고, 언어·버전 사이의 호환성이 보장되지 않기 때문이다.

§2.7 메시지 형식 사이의 변환과 매핑

본 표준의 핵심 가치 중 하나는 「선택의 자유와 일관된 의미」이다. 동일한 메시지가 JSON, CBOR, PROTOBUF, MSGPACK 어느 형식으로 표현되더라도, 그 의미는 동일하게 보존되어야 한다. 이를 위해 본 표준은 「공통 의미 모델」(Common Semantic Model)을 정의한다. 공통 의미 모델은 일곱 가지 기본 자료형 — 객체, 배열, 문자열, 정수, 부동소수점, 진리값, 널 — 과 두 가지 확장 자료형 — 바이너리 문자열, 태그된 값 — 으로 구성된다.⁹⁹

각 메시지 형식은 공통 의미 모델로의 정방향 매핑(forward mapping)과 역방향 매핑(reverse mapping)을 정의해야 한다. 예컨대 JSON의 수치(number)는 공통 의미 모델의 정수 또는 부동소수점으로 매핑되며, 64비트 이상의 정수는 문자열로 인코딩하여 정밀도 손실을 방지한다. CBOR의 태그는 공통 의미 모델의 「태그된 값」으로 직접 매핑된다. PROTOBUF의 메시지는 공통 의미 모델의 객체로, 리피티드 필드는 배열로 매핑된다.

형식 사이의 변환이 무손실인지 여부는 「라운드트립 시험」(round-trip test)으로 검증한다. 메시지를 형식 A에서 형식 B로 변환한 후 다시 형식 A로 변환했을 때 원본과 의미적으로 동등하면 무손실이다. 본 표준의 적합성 시험에는 라운드트립 시험이 의무적으로 포함되며, JSON↔CBOR, JSON↔MSGPACK, JSON↔YAML, CBOR↔MSGPACK은 모두 무손실 변환이 보장된다. 반면 JSON↔PROTOBUF, JSON↔AVRO는 스키마가 필요하므로 스키마 등록 후에만 라운드트립이 보장된다.

§2.A 한국 산업계의 메시지 형식 표준화

한국 산업계는 2010년대 중반 이후 메시지 형식의 표준화에 큰 진전을 이루었다. 「NAVER Cloud」(네이버클라우드)는 자사 클라우드 플랫폼의 내부 통신에 PROTOBUF를 채택하면서 「Protocol Buffers 가이드」를 외부 공개하였다. 이 가이드는 proto3 문법, 스키마 진화 규약, GRPC 통합 사례를 포함하며, 한국 개발자 커뮤니티가 PROTOBUF를 도입하는 데 결정적인 참고 자료가 되었다. NAVER Cloud는 또한 일본 LINE Yahoo와의 통합 통신 인프라에 PROTOBUF·GRPC를 채택하여, 양국 간 메시지 처리량을 30% 이상 절감하였다.⁹⁹

「카카오」(Kakao)는 카카오톡 백엔드 통신의 일부에 CBOR을 채택하여 「CBOR 인코딩 표준」을 사내 표준으로 발표하였다. 카카오의 CBOR 적용 영역은 카카오톡 메시지의 첨부 메타데이터(이미지·동영상 썸네일·위치 정보), 카카오페이 결제 토큰, 카카오톡 봇 명령 등 자원 제약이 있는 모바일 클라이언트와의 통신에 집중되어 있다. 카카오는 CBOR의 태그 체계를 활용하여 한국 시간대(KST), 한국 통신사 식별자, 카카오 사용자 ID 등을 표준화된 태그로 표현하였다.

「토스」(비바리퍼블리카)는 자사 결제 시스템의 내부 RPC에 JSON-RPC_2_0(JSON_RPC_2_0)을 채택하면서 「JSON-RPC 명세」를 외부 공개하였다. 토스의 JSON_RPC_2_0 명세는 한국 금융 결제 시스템의 특수성을 반영하여 「부분 응답」(partial response), 「배치 호출」(batch call), 「알림」(notification)의 사용 패턴을 한국어로 상세히 설명한다. 토스의 적용 사례는 한국 핀테크 업계가 JSON 기반 RPC를 채택하는 표준 모델로 자리잡았다.

「한국정보화진흥원」(NIA, National Information Society Agency, 현 한국지능정보사회진흥원)은 공공 영역의 API 표준화를 담당한다. NIA의 「공공 API 메시지 형식」 가이드라인은 정부 24, 국세청 홈택스, 건강보험심사평가원 등 공공 API가 사용해야 하는 메시지 형식으로 JSON(RFC 8259)을 의무화하면서, 보안이 중요한 영역(개인정보, 의료기록)에서는 CBOR + COSE(RFC 9052)를 권고한다. NIA의 가이드라인은 본 표준의 한국 공공 부문 적용 사례로 기능한다.

「삼성SDS」, 「LG CNS」, 「SK C&C」 등 대형 SI(System Integration) 기업은 본 표준의 메시지 형식 권고를 자사 솔루션에 통합하였다. 특히 삼성SDS의 Brity Works 플랫폼은 JSON·CBOR·PROTOBUF를 모두 지원하며, 사용자가 워크로드 특성에 따라 형식을 선택할 수 있다. LG CNS의 Symphony Verse는 BSON을 채택하여 MongoDB 기반 데이터 분석 워크로드를 최적화하였다. SK C&C는 그룹사 통신에 GRPC·PROTOBUF를 표준화하였다.

학술 영역에서는 「한국정보과학회」(KIISE)와 「한국정보처리학회」(KIPS)가 매년 메시지 형식 관련 학술 논문을 다수 발표한다. KIISE 데이터베이스연구회는 2024년 「한국형 시계열 메시지 형식 비교 평가」라는 종합 보고서를 발간하여, JSON·CBOR·PROTOBUF·AVRO·MSGPACK의 한국 워크로드(전자상거래, 모바일 결제, IoT 센서)에서의 성능을 객관적으로 비교하였다. 이 보고서는 본 표준의 한국 적합성 평가에 중요한 참고 자료로 사용된다.

§2.8 시뮬레이터 패널 1: 메시지 형식 비교 실험

본 표준의 시뮬레이터 패널 1은 동일한 메시지를 JSON, CBOR, PROTOBUF, MSGPACK, AVRO, BSON, XML, YAML, TOML, BINARY_FORMAT의 열 가지 형식으로 직렬화하여 크기와 변환 시간을 비교한다. 학습자는 메시지 자료형의 분포(정수 비율, 문자열 비율, 배열 깊이)를 조절하면서 각 형식의 효율 특성을 직관적으로 확인할 수 있다. 시뮬레이터는 또한 라운드트립 시험을 자동 실행하여 무손실 변환 여부를 표시한다.⁹⁹

실험 결과의 해석은 다음과 같다. 정수 비율이 높은 메시지(예: 금융 거래 로그)는 PROTOBUF·CBOR이 우수하며, 문자열 비율이 높은 메시지(예: 자연어 처리 결과)는 JSON·MSGPACK이 견줄 만하다. 배열 깊이가 깊은 메시지(예: 중첩된 객체 그래프)는 PROTOBUF·AVRO의 스키마 압축 효과가 두드러진다. 모든 형식에서 일관되게 우수한 단일 형식은 존재하지 않으며, 따라서 본 표준은 「영역별 최적 형식 선택」을 권고한다.

장 요약

핵심 요점:

본 표준은 JSON·CBOR·PROTOBUF·MSGPACK·AVRO·BSON·BINARY_FORMAT·XML·YAML·TOML의 열 가지 표준 메시지 형식을 권고하며, 각 형식은 가독성·직렬화 효율·스키마 강제력·언어 중립성·스키마 진화 친화성의 다섯 가지 차원에서 평가된다.
JSON(RFC 8259)은 웹 API의 사실상 표준으로서 학습 곡선의 평탄함과 언어 중립성이 강점이지만, 바이너리 데이터 표현·정수 정밀도·주석 부재의 세 가지 한계가 있다.
CBOR(RFC 8949)은 JSON과 동일한 의미 모델을 유지하면서 평균 20~40% 작은 크기를 달성하며, IoT 보안 표준(COSE·CWT·SUIT)의 기반 형식으로 채택되었다.
PROTOBUF(Protocol Buffers v3)는 강한 스키마와 필드 번호 기반 진화 메커니즘을 제공하며, GRPC의 기본 메시지 형식으로 마이크로서비스 통신의 사실상 표준 중 하나이다.
MSGPACK·AVRO·BSON·XML·YAML·TOML·BINARY_FORMAT은 각자의 영역에서 특화된 가치를 제공하며, 본 표준은 영역별 최적 형식 선택을 권고한다.
형식 사이의 변환은 「공통 의미 모델」을 매개로 무손실로 보장되며, JSON↔CBOR·JSON↔MSGPACK·CBOR↔MSGPACK은 스키마 없이도 라운드트립이 보장된다.
한국 산업계에서는 NAVER Cloud(PROTOBUF), 카카오(CBOR), 토스(JSON_RPC_2_0), NIA(공공 API JSON·CBOR)가 본 표준 권고를 실무에 적용한 대표 사례이다.

복습 질문

JSON(RFC 8259)과 CBOR(RFC 8949)의 의미 모델이 동일함에도 직렬화 효율이 다른 이유를 메시지 구조 측면에서 분석하시오.
PROTOBUF의 필드 번호 기반 스키마 진화 메커니즘이 양방향 호환성을 보장하는 원리를 「reserved 키워드」 사용 사례를 들어 설명하시오.
AVRO의 「작성자 스키마」와 「독자 스키마」 분리가 KAFKA 스트리밍 워크로드에서 어떤 운영적 이점을 제공하는지 논하시오.
NAVER Cloud의 PROTOBUF 가이드, 카카오의 CBOR 인코딩 표준, 토스의 JSON_RPC_2_0 명세, NIA의 공공 API 메시지 형식 권고를 비교하여 한국 산업계의 메시지 형식 선택 패턴을 정리하시오.
JSON↔CBOR 라운드트립이 무손실인 이유를 「공통 의미 모델」 매핑 측면에서 설명하고, JSON↔PROTOBUF 라운드트립이 스키마를 요구하는 이유를 대비하시오.
BINARY_FORMAT(.NET BinaryFormatter, 자바 Serializable, 파이썬 pickle)을 언어 경계 통신에 사용하지 말아야 하는 이유를 보안과 호환성 측면에서 논하시오.
XML·YAML·TOML이 각자의 영역(SAML 인증·Kubernetes 매니페스트·Rust Cargo)에서 채택된 이유를 메시지 형식의 다섯 가지 차원에 비추어 분석하시오.

다음 장 예고

제3장 「프로토콜 계층」에서는 ISO/IEC 7498-1의 OSI_7 모델, RFC 1122의 TCP_IP_4 모델, 그리고 본 표준이 강조하는 표현 계층(PRESENTATION_LAYER)의 책임 경계를 깊이 있게 분석하고, KS X ISO/IEC 7498-1 한국어판과 TTA TR-N-001 한국 IP 표준의 실무 적용을 살핀다.

§2.B 참고 출처 (Endnotes)

WIA Standards 공개 저장소 (universal-protocol 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/universal-protocol — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치입니다.

← 이전 장 다음 장 →