JSON vs YAML vs XML: 어떤 포맷을 써야 할까요?

같은 데이터를 세 포맷으로

이름, 활성 여부, 역할 두 개를 가진 사용자는 각 포맷에서 다음과 같습니다.

JSON과 YAML은 대부분의 프로그래밍 언어에서 객체, 리스트, 스칼라 값에 그대로 대응됩니다. XML은 요소의 트리를 표현하며, 객체로의 대응은 관례일 뿐입니다. 이 예에서 활성 여부는 속성일 수도 자식 요소일 수도 있고, XML 자체에는 그 값이 텍스트 true가 아니라 불리언이라는 정보가 없습니다.

나란히 비교하기

JSON: 엄격하고 예측 가능

JSON의 문법은 한 페이지에 들어갈 만큼 작아서 모든 언어의 파서가 같은 결과를 냅니다. 하지만 그 엄격함 때문에 가장 흔한 오류도 생깁니다.

• 키와 문자열에는 큰따옴표가 필요하며, 작은따옴표는 유효하지 않습니다.
• 객체나 배열의 마지막 항목 뒤에 쉼표를 붙이면 안 됩니다.
• 주석이 없어서 JSON으로 쓴 설정은 스스로를 설명할 수 없습니다. JSONC나 JSON5 같은 변형은 주석을 추가하지만 표준 JSON은 아닙니다.
• RFC 8259는 시스템 간에 주고받는 JSON에 UTF-8을 요구합니다.

문법상 숫자 크기에는 제한이 없지만, RFC 8259는 대부분의 소프트웨어가 IEEE 754 배정밀도 부동소수점을 쓴다고 언급합니다. JavaScript에서는 9007199254740992(2^53)보다 큰 정수가 정밀도를 잃으므로, 큰 ID는 문자열로 보내는 편이 안전합니다.

YAML: 읽기 쉽지만 함정이 있음

YAML은 사람이 읽고 편집하기 좋게 설계되었고, YAML 1.2는 JSON의 상위 집합에 가까워 대부분의 JSON 파일은 YAML로도 유효합니다. 하지만 유연함에는 대가가 따릅니다.

• 들여쓰기가 곧 구조입니다. 공백 하나만 잘못 들어가도 중첩이 바뀌며, 들여쓰기에 탭은 쓸 수 없습니다.
• 따옴표 없는 값은 타입을 추측합니다. 여전히 많은 파서가 쓰는 YAML 1.1 규칙에서는 no, off, yes가 불리언이 되어, 국가 코드 NO가 false로 바뀝니다. YAML 1.2의 core 스키마는 true와 false만 불리언으로 취급하지만, 사용하는 파서가 어떤 버전을 구현하는지 확인하세요.
• 1.10 같은 값은 숫자 1.1이 되고 012는 8진수가 될 수 있습니다. 버전 번호나 우편번호처럼 숫자처럼 보이기만 하는 문자열은 따옴표로 감싸세요.

XML: 장황하지만 문서용으로 설계됨

단순한 데이터에는 XML이 JSON보다 무겁지만, 다른 두 포맷이 못하는 일을 해냅니다. <p>Hello <b>world</b></p>처럼 텍스트 안에 마크업이 섞인 혼합 콘텐츠, 출처가 다른 어휘를 한 파일에 공존시키는 네임스페이스, XSD를 통한 성숙한 검증이 그렇습니다. DOCX, XLSX, SVG, RSS 같은 포맷도 내부는 XML입니다.

XML을 JSON으로 변환하면 본질적으로 정보가 손실됩니다. 속성, 요소 순서, 반복 요소, 혼합 콘텐츠에는 하나로 정해진 JSON 표현이 없으므로, 변환기는 속성에 @ 접두사를 붙이거나 반복 요소를 배열로 강제하는 등의 관례를 택합니다.