XML, JSON, CBOR의 진화를 따라가며 각 형식의 기원과 동기, 핵심 설계 원칙과 트레이드오프, 채택 흐름을 살핀다. 특히 CBOR가 제약된 환경에서 제공하는 이점과 결정적 특성(결정적 인코딩)을 포함해 현재 위치와 향후 전망을 개관한다.
← 또는 → 키를 눌러 장 사이를 이동합니다
S 또는 / 키를 눌러 책에서 검색합니다
? 키를 눌러 이 도움말을 표시합니다
Esc 키를 눌러 이 도움말을 숨깁니다
소개
Part I: CBOR
Part II: dCBOR
Part III: Gordian Envelope
부록
현대 컴퓨팅에서 데이터 교환은 웹 브라우징부터 마이크로서비스와 IoT 기기까지 모든 것의 토대다. 서로 다른 시스템이 구조화된 정보를 표현하고, 공유하며, 해석할 수 있는 능력이 우리의 디지털 세계를 움직인다. 그러나 모든 요구를 만족하는 완벽한 단일 형식은 등장하지 않았다. 대신, 각 시대의 특정 과제와 기술적 요구를 해결하려는 데이터 교환 형식의 진화가 있었다.
이 글은 세 가지 중추적인 데이터 형식을 따라가며 그 기원과 동기, 핵심 설계 원칙과 내재된 트레이드오프, 그리고 변화하는 디지털 환경 속에서의 채택 경로를 살핀다. 견고한 문서 구조에 초점을 맞춘 XML에서 출발해, 웹 중심의 단순성과 성능을 강조한 JSON을 거쳐, 제약된 기기를 위한 이진 효율성에 도달한 CBOR까지 이어지는 여정을 통해, 단순한 기술 명세를 넘어 데이터 교환 형식 혁신을 이끈 바탕의 압력을 이해할 수 있다.
현대 데이터 교환 형식의 출발점은 웹이 아니라 수십 년 전 전자 출판의 과제였다. SGML은 이후 XML이 인터넷 시대에 맞춰 다듬고 적응시킬 복잡한 토대를 제공했다.
1960~70년대, IBM의 Charles Goldfarb, Ed Mosher, Ray Lorie는 독점 조판 시스템의 한계를 극복하기 위해 GML(Generalized Markup Language)을 만들었다. 그들의 접근법은 표현보다 콘텐츠 구조를 우선시했다. GML은 이후 SGML(Standard Generalized Markup Language)로 발전했고, 1986년에 ISO 8879로 표준화되었다.
SGML의 혁신은 메타언어 접근법이었다. 이는 맞춤형 마크업 언어를 만들기 위한 규칙을 제공했다. 개발자는 다양한 문서 유형에 대해 특정 어휘(태그 집합)와 문법(DTD, Document Type Definition)을 정의할 수 있었고, 처리 기술과 무관하게 장기간 기계가 읽을 수 있는 문서를 만들 수 있었다.
SGML은 복잡한 문서를 관리하는 분야, 즉 정부, 군(예: CALS DTD), 항공우주, 법률 출판, 중공업에서 입지를 다졌다. 그러나 150쪽이 넘는 규격과 수많은 특례는 파서 구현을 어렵게 만들어 광범위한 보급에 제약이 되었다.
웹의 등장은 마크업 언어에 결정적이었다. Tim Berners-Lee는 텍스트 기반이면서 유연하고 비독점적인 특성 때문에 SGML을 HTML의 토대로 선택했다. Dan Connolly는 1992년 첫 HTML DTD를 만들었다. HTML은 대중화되었지만, 브라우저별 확장이 난립하면서 구조보다 표현 위주로 흘렀다. SGML은 웹 전반에 쓰기엔 여전히 너무 복잡했기에, SGML의 구조적 역량을 더 쉽게 인터넷으로 가져올 수 있는 형식에 대한 수요가 생겼다.
1990년대 중반, 웹은 HTML의 표현 중심을 넘어선 더 구조적인 데이터 교환이 필요했다. 1996년 W3C는 Sun Microsystems의 Jon Bosak이 의장으로 있는 XML 워킹 그룹을 구성해, 확장성과 구조를 유지하면서도 인터넷에 적합한 단순화된 SGML 부분집합을 만들도록 했다.
W3C XML 워킹 그룹은 명확한 설계 목표를 갖고 XML을 개발했으며, 이는 XML 1 사양(W3C 권고안, 1998년 2월)으로 공식화되었다:
SGML 호환성은 전략적으로 중요했다. XML을 유효한 SGML 부분집합으로 정의함으로써, 1998년 표준 공개 시 기존 SGML 파서와 도구가 즉시 XML 문서를 처리할 수 있었다. 이는 이미 SGML을 쓰던 조직의 도입 장벽을 낮추고 곧바로 활용 가능한 소프트웨어 생태계를 제공했다. 이러한 제약은 설계 선택지를 제한해 워킹 그룹이 빠르게 개발을 마치는 데에도 도움을 주었고, 이는 새로운 표준을 성공적으로 출범시키는 효과적인 전략임을 보여주었다.
XML의 구조는 태그로 표시되는 중첩 요소를 사용한다. 요소는 시작 태그(<customer>), 종료 태그(</customer>), 그리고 그 사이의 콘텐츠(텍스트 또는 다른 중첩 요소)로 구성된다. 시작 태그에는 메타데이터를 위한 속성을 넣을 수 있다(<address type="billing">). 빈 요소는 <br/> 또는 <br></br>와 같은 문법을 사용한다. 이러한 계층 구조는 데이터 구성을 명시적이고 사람이 읽기 쉽게 만든다.
XML 사용이 확산되면서, 서로 다른 어휘를 결합할 때 이름 충돌이 발생했다. 이를 해결하기 위해 1999년 1월 "Namespaces in XML" 권고안이 요소를 고유한 IRI(보통 URI)로 수식하는 방법을 제시했다. 이는 xmlns 속성을 사용하며, 주로 접두사와 함께 쓴다(xmlns:addr="http://www.example.com/addresses"). 이렇게 하면 고유하게 식별되는 요소(<addr:street>)가 생성된다. 기본 네임스페이스(xmlns="URI")를 선언해 접두사가 없는 요소에 적용할 수 있지만, 속성에는 적용되지 않는다. URI는 고유성을 보장하지만 실제 온라인 리소스를 가리킬 필요는 없다.
XML 문서는 스키마 언어로 검증한다. 초기에는 SGML의 DTD를 사용해 허용되는 요소, 속성, 중첩 규칙을 정의했다. DTD의 한계(비-XML 문법, 빈약한 타입 지원)를 극복하기 위해 W3C는 2001년에 XML 스키마 정의(XSD)를 표준화했다. XSD는 강력한 구조 정의, 풍부한 데이터 타이핑, 그리고 기수성 및 유일성 규칙을 제공하며, 스키마 자체도 XML로 작성된다.
XML의 구조는 다양한 지원 기술을 낳았다. 노드 선택을 위한 XPath, 문서 변환을 위한 XSL 변환(XSLT), 메모리 내 표현을 위한 DOM(Document Object Model)이나 이벤트 기반 스트리밍을 위한 SAX(Simple API for XML) 같은 API들이 그것이다.
XML은 확장성과 검증을 갖춘 복잡한 데이터 구조를 효과적으로 모델링했지만, 그 강력함은 곧 복잡성으로 이어졌다. 견고한 XSD 스키마를 만드는 일은 어려웠고, 일부는 RELAX NG나 Schematron 같은 더 단순한 대안을 선호했다. 네임스페이스는 이름 충돌을 해결했지만 문서 작성과 파서 개발을 모두 복잡하게 만들었다. XML의 유연성은 동일 데이터를 여러 방식으로 유효하게 표현할 수 있게 했고, 이는 엄격한 규약이 없으면 상호운용성을 저해할 수 있었다. 이러한 내재적 복잡성과 장황함은 특히 사용 편의성과 성능이 검증과 표현력을 앞서는 영역에서 더 단순한 형식에 대한 수요를 촉발했다. 풍부함과 단순성 사이의 긴장은 이후 데이터 형식의 진화에 큰 영향을 미쳤다.
1998년 표준화 이후, XML은 2000년대 초반 컴퓨팅 전반에서 빠르게 지배적 위치를 차지하며 구조화된 데이터 교환을 위한 표준적이고 플랫폼 독립적인 접근을 제공했다.
XML은 SOAP(Simple Object Access Protocol)를 통해 웹 서비스의 기반을 이뤘다. SOAP는 HTTP 상에서 작동하는 XML 기반 메시징 프레임워크다. WSDL(Web Services Description Language)과 UDDI(Universal Description, Discovery and Integration) 같은 지원 기술이 엔터프라이즈 통합을 위한 "WS-*" 스택을 완성했다.
구성 파일에서도 XML이 널리 채택되었다. 구조와 가독성 덕분이다. 대표적으로 Java의 Log4j, Microsoft .NET 구성(web.config, app.config), Apache Ant 빌드 스크립트, 다양한 시스템 파라미터 등이 있다.
문서 형식과 퍼블리싱 영역에서도 XML은 본래의 약속을 이행했다. XHTML, RSS와 Atom 피드, KML 지리정보, DocBook 같은 특수 형식들을 구동했다. 콘텐츠와 표현을 분리하는 특성은 멀티채널 퍼블리싱과 콘텐츠 관리에 유용했다.
범용 데이터 교환 형식으로서 XML은 벤더 종속을 피하면서 시스템 간 통신을 촉진했고 장기 보존에도 도움이 되었다.
이러한 광범위한 채택은 XML 파서, 편집기, 검증 도구, 변환 엔진(XSLT), 데이터 바인딩 유틸리티, 전용 컨퍼런스까지 포괄하는 풍부한 생태계를 형성해 강력한 기술 커뮤니티를 만들었다.
성공에도 불구하고 XML은 자체 부분적 쇠퇴의 씨앗을 품고 있었다. "XML 마크업에서 간결성은 최소한으로 중요하다"는 핵심 설계 원칙은 간결성보다 명확성을 우선시해 모든 요소에 대해 시작 태그와 종료 태그를 명시하도록 했다.
이는 가독성을 높였지만, 구조적으로 장황함을 낳았다. 단순한 데이터 구조를 표현하는 데도 XML은 더 많은 문자를 필요로 했다. 예를 들어 JSON의 {"name": "Alice"}와 XML의 <name>Alice</name>를 비교하면, 특히 많은 작은 요소로 이루어진 대규모 데이터셋에서 상당한 오버헤드가 발생한다.
웹이 진화하면서 이러한 장황함은 문제가 되었다. 2000년대 중반 AJAX의 부상은 동적 인터페이스를 위해 브라우저와 서버 사이에서 빈번하고 작은 데이터 교환을 강조했다. 이 맥락에서 대역폭 사용과 파싱 시간을 최소화하는 것이 중요해졌다. XML의 큰 페이로드와 복잡한 파싱 요구는 성능 병목을 만들었다.
XML 커뮤니티는 이러한 효율성 문제를 인식하고 W3C Efficient XML Interchange(EXI) 워킹 그룹과 같은 이니셔티브를 통해 표준화된 바이너리 XML 형식을 개발했다. EXI는 큰 압축 효과를 제공했지만, 태그 중심의 XML 토대 위에 효율을 사후적으로 덧입히는 일의 복잡함을 부각시켰다.
간결성을 우선하지 않은 결정은 XML을 SGML과 구분 짓는 요소였지만, 예상치 못한 결과를 낳았다. 속도와 효율이 우선되는 동적 웹 애플리케이션 시대로 전환되면서 XML의 장황한 구조는 약점이 되었다. 이는 웹 브라우저와 JavaScript 환경에서의 간결성과 파싱 용이성, 곧 XML이 최소한으로 여겼던 요소를 최적화하는 형식의 기회를 만들었다.
웹 개발에서 XML의 장황함과 복잡성이 문제가 되면서, 특히 AJAX의 부상과 함께, 더 단순한 대안이 JavaScript에서 직접 등장했다.
JSON(JavaScript Object Notation)은 JavaScript 작업으로 알려진 미국 프로그래머 Douglas Crockford에게서 비롯되었다. 2001년 State Software에서 Crockford와 동료들은 Flash나 자바 애플릿 같은 플러그인 없이 Java 서버와 JavaScript 브라우저 간 데이터를 교환할 수 있는 경량 형식을 필요로 했다.
Crockford는 JavaScript의 객체 리터럴 문법(예: { key: value })이 그 목적에 부합함을 깨달았다. 서버에서 브라우저로 데이터를 JavaScript 스니펫에 포함시켜 보낼 수 있었고, 초기에는 eval() 함수로 파싱했다. 그는 이를 발명이라기보다 "발견"이라고 표현하며, 1996년 Netscape에서도 유사한 기법이 있었다고 회고한다.
초기 구현은 <script> 태그가 JavaScript 함수를 호출하고, 그 인자로 객체 리터럴 형태의 데이터를 전달하는 HTML 문서를 보내는 방식이었다. 한 가지 정제된 규칙은 모든 키에 쌍따옴표를 강제해 JavaScript 예약어와의 충돌을 피하는 것이었다.
JSpeech Markup Language와의 명명 충돌을 겪은 후, 이들은 "JavaScript Object Notation" 또는 JSON으로 이름을 정했다. 2002년 Crockford는 json.org 도메인을 확보해 문법과 레퍼런스 파서를 공개했다. 다양한 언어용 파서가 빠르게 제출되며 JSON의 광범위한 잠재력이 드러났다.
JSON은 XML보다 단순하고 가벼운 데이터 교환 형식에 대한 요구를 충족했다. Crockford는 "상호운용을 위해 합의해야 할 것이 적을수록, 우리는 더 잘 상호운용할 가능성이 높다"는 신념으로 극단적 미니멀리즘을 지향했다. 그는 명함 한 장에 담을 수 있을 만큼 단순한 표준을 원했다.
JSON이 단지 XML을 재발명한 것 아니냐는 도전에 대해, Crockford는 "바퀴를 재발명하는 좋은 점은 이번에는 둥글게 만들 수 있다는 것이다"라고 유명한 말로 응수했다.
JSON은 완벽한 시기에 등장했다. AJAX 기법은 서버와 브라우저 사이의 작은 데이터 전송을 최적화할 필요를 만들었다. "AJAX"가 "Asynchronous JavaScript and XML"을 의미했지만, 많은 경우 JSON이 더 적합했다. 그 문법은 JavaScript의 객체와 배열에 직접 대응되어 클라이언트 측 파싱을 매우 간단하게 만들었다. 경량 특성은 대역폭 사용을 줄이고 웹 애플리케이션 반응성을 개선했다.
JavaScript에서 출발했지만 JSON의 성공은 브라우저에 국한되지 않았다. 그 단순성 덕분에 거의 모든 프로그래밍 언어에서 구현이 매우 쉬웠다. 객체(맵/딕셔너리), 배열(리스트), 문자열, 숫자, 불리언, null 같은 핵심 구조는 대부분의 현대 언어에 기본적이다. 이러한 언어 간 구현 용이성이 빠른 채택을 이끌며, JSON을 JavaScript 특화 해법에서 업계 전반의 웹 API와 구성 파일을 위한 사실상의 표준으로 변모시켰다. 단순함은 언어 독립성과 광범위한 채택을 촉진하는 강력한 촉매가 되었다.
JSON의 문법은 의도적으로 최소화되어 JavaScript에서 가져온 몇 가지 구조 요소만으로 구성된다.
{} 안에 순서가 없는 키-값 쌍. 키는 반드시 큰따옴표 문자열이어야 하며, 콜론 : 뒤에 값이 오고, 쌍은 콤마로 구분된다. 예: { "name": "Alice", "age": 30 }.[] 안의 순서 있는 값 시퀀스. 값은 콤마로 구분된다. 예: [ "apple", "banana", "cherry" ].값으로 올 수 있는 것은 다음뿐이다:
true 또는 false(소문자)null(소문자)이 텍스트 기반 구조는 사람이 읽을 수 있고 일반적인 프로그래밍 데이터 구조에 직접 매핑되어 개발자 친화적이다.
JSON은 의도적으로 주석, 네임스페이스, 속성 같은 XML의 기능을 생략한다. Crockford는 주석이 종종 XML 같은 형식에서 파싱 지시나 메타데이터에 오용되어 상호운용성을 해칠 수 있다고 보아 주석을 제외했다. 권장 방식은 "_comment" 같은 관례적인 키에 일반 데이터로 설명을 넣는 것이다.
ECMAScript 5(2009)에는 JSON.parse()와 JSON.stringify()가 기본으로 도입되어 eval()보다 안전한 파싱 방법을 제공했다. stringify는 출력 제어를 위한 선택적 replacer 함수를 지원하고, 객체는 toJSON()을 구현해 직렬화를 커스터마이즈할 수 있다.
JSON과 XML은 근본적으로 다른 설계 철학을 반영한다.
이 비교는 전환점을 보여준다. XML은 복잡한 문서를 위한 구조, 확장성, 검증에 방점을 찍었고, JSON은 웹 API를 위한 단순성, 사용성, 성능을 강조했다.
JSON은 웹 기술과의 정합성 덕분에 "웹 2.0"과 AJAX 시대에 폭넓게 채택되었다. 특히 RESTful 웹 API에서 빠르게 지배적이 되었고, 조사에 따르면 85% 이상의 API가 기본 형식으로 JSON을 사용한다.
그 효용은 구성 파일과 데이터 저장으로도 확장되었고, MongoDB 같은 NoSQL 데이터베이스(BSON 사용)와 브라우저의 localStorage에서도 활용되었다.
JSON의 채택은 json.org에 나타나듯 개발자 선호와 언어 전반에 걸친 파서 제작의 용이성으로 유기적으로 성장했다. 이후 ECMA-404와 IETF RFC 8259로 공식 표준화가 뒤따랐다.
JSON 성공의 핵심 요인 중 하나는 놀라운 안정성이다. Crockford가 강조했듯 JSON은 "완성되었다" — 버전 번호가 없고, 핵심 명세는 시작 이래 변하지 않았다. 이는 잦은 업데이트가 필요한 기술들과 대조되며, 단편화와 호환성 문제를 CBOR가 나중에 명확히 경계한 것과 같은 효과를 미리 거뒀다. 단순하고 신뢰할 수 있는 토대를 제공함으로써, JSON은 코어의 지속적 변경 없이도 풍부한 생태계가 그 위에 번성하도록 했다. 인프라 기술에서 안정성은 결정적 기능임을 입증했다.
JSON은 웹 API에서 XML에 비해 꼭 필요했던 단순성과 성능 향상을 제공했지만, 텍스트 기반 특성은 특정 환경에서는 한계를 드러냈다. 특히 사물인터넷(IoT)의 부상으로 가속된 효율성에 대한 끊임없는 요구는, JSON의 데이터 모델을 유지하면서도 이진 인코딩의 압축성과 속도를 결합한 형식, CBOR로 이어졌다.
JSON 같은 텍스트 기반 형식은 이진 표현에 비해 태생적 비효율을 가진다.
이러한 한계는 IoT의 전형적 특성인 제약 환경에서 치명적이다.
이런 시나리오에서 메시지 크기를 줄이면 대역폭과 에너지를 절약하고, 처리 오버헤드를 줄이면 배터리 수명이 늘어난다. CBOR는 바로 이런 제약 환경을 위해, JSON의 유연한 데이터 모델을 유지하면서도 컴팩트하고 효율적으로 처리 가능한 이진 형태로 설계되었다.
CBOR는 IETF에서 제약 환경을 목표로 Carsten Bormann과 Paul Hoffman 등을 중심으로 개발되었다.
CBOR는 JSON 데이터 모델을 의도적으로 계승해, 숫자, 문자열, 배열, 맵, 불리언, null과 같은 동등한 타입을 지원하면서, JSON의 핵심 한계를 보완하는 네이티브 바이너리 바이트 문자열(byte string)을 추가했다.
CBOR는 처음 RFC 7049(2013)로 표준화되었고, RFC 8949(2020)에서 인터넷 표준 94(STD 94)로 갱신되었다. 중요한 점은 RFC 8949가 이전 버전과의 전송(와이어) 포맷 호환성을 완전히 유지한다는 것이다.
표준은 명확한 설계 목표를 제시한다.
CBOR는 JSON과 XML에서 얻은 교훈을 효과적으로 종합한다. 친숙한 JSON 데이터 모델을 계승하면서, 이진 인코딩과 크기 효율로 제약 환경에 최적화했다. 확장성 측면에서는 IANA에 등록되는 의미적 태그(semantic tag)를 제공해, 하위 호환을 깨뜨리지 않고 새로운 데이터 타입을 통합할 수 있게 한다. 이는 JSON의 단순함과 XML의 확장 접근을 결합한 것이다.
CBOR는 복잡한 데이터 구조를 컴팩트하게 표현하는 능력이 중요한 효율을 만들어내는 사물인터넷(IoT) 및 제약 환경에서 주로 자리 잡았다.
CBOR를 활용하는 핵심 IETF 프로토콜은 다음과 같다.
CoAP(Constrained Application Protocol): 제약 네트워크를 위한 경량 HTTP 대안으로 CBOR 페이로드를 사용한다. IEC 61850(스마트 그리드) 같은 프로토콜과의 매핑이 존재하며, HTTP/XML이나 WS-SOAP 대비 성능 이점을 보여준다.
COSE(CBOR Object Signing and Encryption): CBOR을 사용해 암호 연산을 정의한다. JOSE 개념을 계승하되 이진 효율을 갖췄다. IoT 보안의 핵심이며 FIDO WebAuthn 패스키 인증에서 사용된다.
ACE(Authentication and Authorization for Constrained Environments): CBOR와 COSE를 사용하는 IoT 리소스 접근용 보안 프레임워크.
디바이스 관리: CORECONF 등은 NETCONF/YANG 개념을 CBOR를 통해 제약 기기에 적용한다.
인증서 표현: C509는 전통적인 DER/ASN.1 인코딩보다 더 작은 X.509 인증서를 제공한다.
IETF 표준을 넘어, CBOR-LD나 CBL과 같은 형식은 IoT 응용을 위해 시맨틱 웹 데이터를 압축한다.
C, C++, Go, Rust, Python, Java, Swift 등 다양한 언어 전반의 광범위한 구현 지원은 이질적 시스템 간 CBOR 통합을 촉진한다.
CBOR 채택은 제약 시스템과 보안 프로토콜에서 성장하고 있지만, 전반적인 웹 API 영역에서는 여전히 JSON보다 덜 지배적이며, 역사적으로 XML만큼 성숙하진 않다. 바이너리 특성은 효율을 위해 사람 가독성을 희생하므로, 직접 검사와 수동 편집이 중요한 곳에는 덜 적합하다.
CBOR의 진화는 JSON의 유연한 데이터 모델을 유지하면서 이진 효율을 극대화하는 데 초점을 맞춘다. 성장은 이러한 최적화가 특히 중요한 환경, 즉 IoT, M2M 통신, 보안 프로토콜에서 중심적으로 이뤄지고 있다.
수십억 대의 IoT 기기가 추가로 배치됨에 따라 효율적인 통신에 대한 수요는 증가할 것이며, 이는 CBOR의 입지를 강화할 것이다. COSE 등 보안 메커니즘으로의 통합, 특히 비밀번호 없는 인증(WebAuthn/패스키)과 함께 채택이 확대된다. CBOR의 의미적 태그는 하위 호환을 유지하면서 확장성을 제공한다.
Part II에서는 CBOR의 또 다른 중요한 장점, 즉 결정적 인코딩을 살펴본다. 이 속성은 서명, 해시, 안전한 메시징, 분산 합의 프로토콜 등 암호 응용에서 필수적인 일관된 직렬화를 보장한다.
이러한 강점에도 불구하고, 사람 가독성과 JavaScript 통합이 핵심 장점인 웹 API와 일반적 데이터 교환 영역에서 CBOR가 JSON을 대체할 가능성은 낮다.
XML-JSON-CBOR의 진화는 기술이 기능 풍부한 해법에서 특정 사용 사례에 특화된 형식으로 이동하는 패턴을 보여준다. SGML은 포괄적 기능을 제공했지만 복잡했고, XML은 이를 웹 문서에 맞게 단순화했다. JSON은 웹 API를 위해 더 간소화했고, CBOR는 제약 환경에서의 이진 효율을 위해 최적화했다.
미래는 단일 지배 형식이 아니라 공존일 가능성이 높으며, 선택은 응용 요구에 의해 좌우될 것이다. CBOR 같은 특화 형식은 사람 가독성을 크기와 처리 속도로 교환하는 등 의도적 트레이드오프를 통해 자신들의 틈새에서 탁월한 성능을 달성한다.
비교 개요: XML, JSON, CBOR
| 기능 | XML | JSON | CBOR |
|---|---|---|---|
| 발안자/기관 | W3C (Jon Bosak 등) | Douglas Crockford; 이후 ECMA, IETF | IETF (Carsten Bormann, Paul Hoffman) |
| 주요 목표 | 구조화 문서, 웹 데이터 교환 | 단순·경량 웹 API, 데이터 교환 | 이진 효율, 컴팩트함, 제약 환경(IoT) |
| 형식 유형 | 마크업 언어(텍스트) | 데이터 형식(텍스트) | 데이터 형식(바이너리) |
| 기본 모델 | SGML 부분집합 | JavaScript 객체 리터럴 부분집합 | JSON 데이터 모델 확장 |
| 구조 | 태그 기반 트리(요소, 속성) | 키-값 쌍(객체)과 순서 있는 값(배열) | 키-값 쌍(맵)과 순서 있는 값(배열) |
| 스키마/검증 | DTD, XSD(내장, 강력) | JSON Schema(별도 명세, 선택) | CDDL(별도 명세, 선택) |
| 사람 가독성 | 높음(장황) | 높음(간결) | 낮음(바이너리) |
| 크기/효율 | 장황, 파싱 효율 낮음 | 경량, 파싱 효율 높음 | 매우 컴팩트, 파싱 효율 매우 높음 |
| 확장성 | 네임스페이스, 스키마 | 관례 기반(예: JSON-LD), JSON Schema | 의미적 태그(IANA 등록부) |
| 네이티브 바이너리 지원 | 없음(예: Base64 인코딩 필요) | 없음(예: Base64 인코딩 필요) | 있음(바이트 문자열 타입) |
| 주요 사용 사례 | 문서(HTML, DocBook), SOAP, 구성 파일 | REST API, 구성 파일, NoSQL 데이터 | IoT 프로토콜(CoAP), 보안(COSE), 제약 기기 |
W3C Recommendation: Extensible Markup Language (XML) 1.0 (Fifth Edition)
IETF RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
IETF RFC 8949: Concise Binary Object Representation (CBOR)
Walsh, N. "A Technical Introduction to XML"
"The Rise and Rise of JSON" – Two-Bit History
CBOR.io (Official CBOR Website)
AWS: "JSON vs XML – Difference Between Data Representations"
DuCharme, B. "A brief, opinionated history of XML"