JSON→XML 변환의 근본적 한계 — 배열·null·타입이 사라지는 지점
JSON과 XML은 둘 다 데이터를 트리 구조로 표현하니 서로 자유롭게 오갈 수 있을 것 같지만, 실제로 변환해보면 곳곳에서 "이걸 어떻게 표현하지?" 하는 애매한 지점이 나옵니다. 배열, null, 숫자·불리언 타입, 속성(attribute) 개념 — 이 넷은 JSON에는 명확히 있지만 XML에는 표준 문법이 없어서, 모든 JSON→XML 변환기는 나름의 관례를 발명해야 합니다. 이 가이드는 그 관례가 정확히 무엇이고, 왜 XML→JSON으로 되돌릴 때 정보가 완전히 복원되지 않는지 짚습니다.
1. 배열: XML에는 아예 없는 개념
JSON은 ["a","b","c"]처럼 배열이 언어 차원의 타입입니다. 반면 XML에는 배열이라는 개념 자체가 없습니다. XML이 가진 건 "같은 이름의 태그가 부모 밑에 여러 번 나타날 수 있다"는 사실뿐입니다. 그래서 모든 JSON→XML 변환기는 배열을 부모 키와 같은 이름의 태그를 반복하는 방식으로 흉내 냅니다. 예를 들어 {"hobbies":["독서","코딩"]}은 <hobbies>독서</hobbies><hobbies>코딩</hobbies>로 변환됩니다. 문제는 이렇게 만들어진 XML만 봐서는 "hobbies가 원래 배열이었다"는 사실을 확신할 수 없다는 점입니다. 같은 이름의 태그가 우연히 두 번 나온 것인지, 원래 배열이었는지는 XML 자체에 표시되지 않고, 역변환하는 쪽이 "같은 태그가 여러 개면 배열로 간주한다"는 추론에 의존해야 합니다. 배열 요소가 딱 1개뿐이었다면 이 추론은 아예 실패해서, 원래 배열이었는지 단일 값이었는지조차 구분할 수 없게 됩니다.
2. null: self-closing 빈 태그라는 관례
JSON의 null은 "값이 명시적으로 없음"을 뜻하는 별도 타입입니다. XML에는 이에 대응하는 표준 타입이 없어, 대개 두 가지 관례 중 하나를 씁니다. 하나는 <email/>처럼 닫는 슬래시로 끝나는 self-closing 빈 태그를 쓰는 방식이고, 다른 하나는 XML Schema의 xsi:nil="true" 속성을 붙이는 좀 더 정교한 방식입니다. 대부분의 간단한 브라우저용 변환기는 전자를 씁니다. 그런데 이 방식의 함정은, 같은 <email/>이 "null이었다"는 뜻인지 "빈 문자열("")이었다"는 뜻인지 XML만 봐서는 구분이 안 된다는 것입니다. JSON에서는 null과 ""이 명백히 다른 값인데, XML로 갔다가 돌아오면 둘 다 같은 빈 태그로 뭉개져 있어 원래 뭐였는지 알 길이 없습니다.
{"email": null}과 {"email": ""} 둘 다 <email/>로 변환됩니다. XML만 보고는 원래 JSON에서 null이었는지 빈 문자열이었는지 절대 알 수 없습니다.
3. 숫자·불리언: 전부 텍스트로 뭉개진다
JSON은 30(숫자), true(불리언), "30"(문자열)을 명확히 구분하는 타입 시스템을 갖고 있습니다. XML에는 이런 타입 시스템이 없습니다 — 태그 사이에 들어가는 건 전부 텍스트일 뿐입니다. 그래서 {"age":30}도, {"age":"30"}도 똑같이 <age>30</age>로 변환됩니다. XML을 다시 JSON으로 되돌리는 쪽은 "30"이라는 텍스트를 보고 이게 숫자였는지 문자열이었는지 추측해야 하고, 이 추측은 원본 데이터의 의도와 다를 수 있습니다(예: 우편번호 "04523"이 숫자로 오인되면 앞자리 0이 사라지는 식의 오류로 이어질 수 있습니다).
4. 속성(attribute) 개념의 부재
XML은 <person id="1">처럼 태그에 속성을 붙일 수 있는 반면, JSON에는 애초에 "속성"이라는 개념이 없습니다. 그래서 JSON→XML 변환기는 이 여지를 아예 쓰지 않고, JSON의 모든 키를 예외 없이 자식 요소(child element)로만 만드는 단순한 방식을 택하는 경우가 대부분입니다 — id도, 이름도, 나이도 전부 같은 층위의 자식 태그가 됩니다. 이는 구현을 단순하게 만들지만, XML 고유의 속성 표현력(예: 같은 데이터를 요소로 쓸지 속성으로 쓸지 구분해 문서를 더 간결하게 만드는 관행)은 전혀 활용되지 않는다는 뜻이기도 합니다.
5. 이런 한계가 실무에 미치는 영향
- 레거시 SOAP/XML API 연동: JSON 데이터를 변환해 보낼 때, 상대 시스템이 배열/null/타입을 특정 스키마(XSD)로 기대한다면 단순 변환기의 출력이 그 스키마와 안 맞을 수 있습니다.
- 왕복 변환(round-trip)에 대한 기대치: JSON→XML→JSON을 거치면 원본과 100% 동일한 결과가 나올 거라고 기대하면 안 됩니다. 배열 요소 1개, null vs 빈 문자열, 숫자 vs 숫자형 문자열은 정보가 소실되는 대표적 지점입니다.
- 태그 이름 규칙: JSON 키가 숫자로 시작하거나 공백을 포함하면 XML 태그 이름 규칙(문자로 시작, 공백 금지 등)에 어긋나 유효하지 않은 XML이 만들어질 수 있으므로, 변환 전에 키 이름을 점검하는 편이 안전합니다.
자주 묻는 질문
Q. JSON 배열이 XML에서 어떻게 표현되나요?
A. XML에는 배열 문법이 없어, 배열의 각 요소를 부모 키와 동일한 이름의 태그로 반복해서 나열합니다. 예: hobbies:["독서","코딩"] → <hobbies>독서</hobbies><hobbies>코딩</hobbies>.
Q. null 값은 어떻게 표현되나요?
A. 닫는 슬래시로 끝나는 self-closing 빈 태그(예: <email/>)로 표현되는 것이 일반적인 관례입니다. 다만 빈 문자열과 구분되지 않는다는 한계가 있습니다.
Q. XML을 다시 JSON으로 정확히 되돌릴 수 있나요?
A. 완벽하게는 안 됩니다. 배열 요소가 1개뿐이었는지, 값이 null이었는지 빈 문자열이었는지, 숫자였는지 숫자 형태의 문자열이었는지는 XML만 보고 확정할 수 없어 추론에 의존하게 됩니다.
Q. 숫자와 불리언 타입은 XML에서 유지되나요?
A. 아니요. XML은 태그 안 내용을 전부 텍스트로 다루므로 30과 "30"이 똑같은 텍스트로 출력됩니다. 되돌릴 때 타입을 복원하려면 별도의 타입 추론 로직이 필요합니다.
Q. 변환된 XML이 유효하지 않다고 나오면?
A. XML 태그 이름은 숫자로 시작하거나 공백·특수문자를 포함할 수 없습니다. JSON 키가 이 규칙을 어기면(예: "1st-item") 검증 없이 그대로 태그명으로 쓰여 유효하지 않은 XML이 만들어질 수 있으니, 변환 전 키 이름을 확인하세요.