JSON to XML 변환기 — 데이터 형식을 바꿔야 할 때

개발 일을 하다 보면 XML만 받는 시스템을 만나는 날이 옵니다. 은행의 SOAP API일 수도 있고, 2003년에 만들어져서 지금도 그대로 돌아가는 정부 데이터 피드일 수도 있습니다. 혹은 SAP ERP 시스템에 데이터를 밀어 넣어야 하는 경우일 수도 있죠. 그리고 보통 당신 쪽 데이터는 현대적인 REST API에서 가져온 JSON 형식입니다.

JSON to XML 변환기는 이런 상황을 빠르게 해결해줍니다. JSON을 붙여넣으면 XML이 나옵니다. 하지만 변환 과정에서 실제로 무슨 일이 일어나는지, 어디서 문제가 생기는지를 이해하면 디버깅 시간을 크게 줄일 수 있습니다.

JSON과 XML이 공존하는 이유

XML은 1998년에 등장했습니다. 2000년대 내내 엔터프라이즈 소프트웨어의 표준 언어였습니다. SOAP 웹 서비스, 설정 파일, Office 문서 형식(OOXML), 데이터 교환 프로토콜 — 다 XML이었습니다.

JSON은 2001년에 Douglas Crockford가 명세화했습니다. JavaScript에 자연스럽게 맞고, XML보다 훨씬 가볍고, 사람이 읽기도 쉬웠습니다. REST API가 대세가 되고 JavaScript가 웹을 장악하면서 JSON이 API 응답의 기본값이 됐습니다.

그런데 XML 기반 시스템들이 사라진 건 아닙니다. 메인프레임은 여전히 돌아갑니다. SAP와 Oracle ERP는 XML을 씁니다. 은행, 보험, 의료, 정부의 SOAP 서비스들은 멀쩡히 운영 중입니다. SVG, RSS, XHTML은 XML 기반입니다.

결과적으로 세상이 나뉩니다. 새로운 API는 JSON을 쓰고, 레거시 시스템은 XML을 씁니다. 둘 사이를 연결하려면 변환이 필요합니다.

변환이 필요한 실제 상황들

SOAP API 연동: 가장 흔한 경우입니다. SOAP는 XML 형식의 요청 본문을 요구합니다. REST API에서 JSON으로 받은 데이터를 SOAP 엔드포인트로 보내려면 XML로 변환해야 합니다. 금융, 의료(HL7), 정부 시스템에서 자주 등장합니다.

ERP/CRM 시스템: SAP, Oracle, 구형 Salesforce 연동에서 XML 형식의 데이터를 요구하는 경우가 많습니다. 현대 소스에서 데이터를 가져와 이 시스템에 밀어 넣을 때 변환이 필요합니다.

Maven, Ant 빌드 설정: Java 빌드 도구는 XML(pom.xml, build.xml)을 사용합니다. JSON 데이터에서 이 파일들을 프로그래밍 방식으로 생성할 때 변환이 필요합니다.

RSS, Atom 피드: JSON API나 데이터베이스에서 RSS/Atom 피드를 생성할 때 XML 출력이 필요합니다.

정부 및 규제 기관 데이터 제출: 세무 당국, 통계 기관, 금융 규제 기관은 XML 형식 데이터 제출을 요구하는 경우가 많습니다. XBRL(재무 보고) 같은 형식도 XML 기반입니다.

변환 원리: 실제로 어떻게 작동하는가

기본 개념은 단순합니다. JSON의 키-값 쌍이 XML 요소로 매핑되고, 객체는 부모-자식 요소가 됩니다.

단순 객체

{
  "name": "홍길동",
  "email": "hong@example.com",
  "age": 30
}

XML로 변환하면:

<root>
  <name>홍길동</name>
  <email>hong@example.com</email>
  <age>30</age>
</root>

JSON 키가 XML 요소명이 됩니다. 값은 텍스트 내용이 됩니다. XML은 루트 요소가 하나여야 하기 때문에 <root> 래퍼가 추가됩니다.

중첩 객체

{
  "user": {
    "name": "김철수",
    "address": {
      "city": "서울",
      "district": "강남구"
    }
  }
}

XML로:

<root>
  <user>
    <name>김철수</name>
    <address>
      <city>서울</city>
      <district>강남구</district>
    </address>
  </user>
</root>

중첩 구조는 자연스럽게 부모-자식 요소로 변환됩니다.

데이터 타입

JSON에는 문자열, 숫자, 불리언, null, 배열, 객체가 있습니다. XML은 전부 텍스트입니다. 따라서:

• "active": true → <active>true</active> (불리언이 텍스트 "true"가 됨)
• "count": 42 → <count>42</count> (숫자가 텍스트 "42"가 됨)
• "price": 3.14 → <price>3.14</price>

XML을 소비하는 시스템은 이 텍스트를 적절한 타입으로 파싱해야 합니다.

배열 변환 — 까다로운 부분

배열이 JSON to XML 변환에서 가장 복잡한 부분입니다. XML에는 배열의 직접적인 동등 개념이 없기 때문입니다. 같은 이름의 요소가 반복되는 방식이 가장 유사하지만, 어떻게 매핑할지 표준이 없습니다.

가장 흔한 방식은 제네릭 래퍼를 사용하는 것입니다:

{
  "colors": ["red", "green", "blue"]
}

→

<root>
  <colors>
    <item>red</item>
    <item>green</item>
    <item>blue</item>
  </colors>
</root>

또는 부모 키 이름을 각 요소에 사용하는 방식:

<root>
  <colors>red</colors>
  <colors>green</colors>
  <colors>blue</colors>
</root>

어떤 방식이 "맞다"고 할 수 없습니다. 수신 시스템이 기대하는 구조에 달려 있습니다. 특정 SOAP API나 XML 스키마에 맞춰 변환한다면, 해당 스키마가 요구하는 구조를 확인하고 출력을 그에 맞게 후처리해야 할 수 있습니다.

주요 주의사항과 엣지 케이스

유효하지 않은 XML 태그명

XML 요소명은 규칙이 있습니다. 문자나 밑줄로 시작해야 하고, 공백을 포함할 수 없으며, "xml"로 시작할 수 없습니다. JSON 키에는 이런 제한이 없습니다.

문제가 생기는 JSON 키 예시:

• 숫자 시작: "1stItem" → 유효하지 않은 XML 태그. 해결책: _1stItem 같은 접두사 추가.
• 공백 포함: "first name" → <first name>은 불가. 공백을 밑줄이나 하이픈으로 대체.
• 특수문자 포함: "price$" → 특수문자 제거 또는 대체.

좋은 변환기는 이를 자동으로 처리하거나 경고를 줍니다. 직접 변환 코드를 작성한다면 키를 요소명으로 사용하기 전에 반드시 검증하고 정제해야 합니다.

JSON null 값

JSON의 null은 XML에 직접 대응하는 개념이 없습니다. 일반적인 처리 방법:

• 해당 요소를 아예 생략
• 빈 요소로 표현: <fieldName/>
• XSD 인식 시스템에서는 xsi:nil="true" 속성 사용

어떤 방식을 쓸지는 수신 시스템의 기대에 달려 있습니다.

루트 요소 문제

JSON 객체는 최상위에 여러 키를 가질 수 있습니다. XML은 루트 요소가 하나여야 합니다. 따라서:

{
  "firstName": "길동",
  "lastName": "홍"
}

XML로 변환하면 래퍼 루트가 필요합니다:

<root>
  <firstName>길동</firstName>
  <lastName>홍</lastName>
</root>

대부분의 변환기는 <root> 래퍼를 자동으로 추가합니다. 타겟 XML 스키마가 특정 루트 요소명을 요구한다면(<Customer>, <Request> 등), 변환 후 이름을 바꿔야 합니다.

XML 속성 vs 자식 요소

XML에는 JSON에 없는 개념이 있습니다. 바로 요소의 속성입니다. <user id="42" active="true">길동</user> 같은 형태로 요소에 메타데이터를 담을 수 있습니다.

JSON에는 이 구분이 없습니다. 모든 것이 키-값 쌍입니다. 그래서 JSON to XML 변환에서는 보통 모든 것이 자식 요소가 됩니다. 하지만 수신 XML 스키마가 특정 필드를 속성으로 요구한다면, @id 같은 특수 표기법을 지원하는 변환기나 수동 후처리가 필요합니다.

JSON vs XML — 언제 어떤 것을 쓸까

JSON이 더 적합한 경우:

• REST API 개발
• 개발자가 직접 읽고 쓸 설정 파일
• 웹 서비스와 브라우저 간 데이터 전송
• JavaScript/TypeScript 환경
• 파일 크기와 파싱 속도가 중요할 때

XML이 더 적합한 경우:

• 수신 시스템이 XML을 요구할 때 (SOAP, 엔터프라이즈 API)
• 혼합 콘텐츠가 필요한 문서 구조
• 개별 필드에 메타데이터를 속성으로 붙여야 할 때
• 여러 스키마를 조합하는 네임스페이스가 필요할 때
• SVG, RSS, XHTML 등 XML 기반 표준을 다룰 때
• 장기 보관에서 자기 기술적(self-describing) 형식이 필요할 때

대부분의 신규 개발에서는 JSON이 단순함으로 이깁니다. 하지만 레거시 XML 세계는 방대하고 사라지지 않을 것입니다. 그래서 변환 도구가 필요합니다.

실전 활용

JSON to XML 변환기는 단순 객체, 중첩 구조, 배열, 기본 데이터 타입의 일반적인 케이스를 처리합니다. JSON을 붙여넣으면 포매팅된 XML을 복사하거나 다운로드할 수 있습니다.

프로덕션 통합에서는 변환된 XML을 타겟 스키마(XSD)로 반드시 검증하세요. 변환기는 구조를 처리해주지만, 특정 시스템이 요구하는 요소명, 속성 요건, 네임스페이스 선언은 추가 조정이 필요할 수 있습니다.

탐색적 용도 — 페이로드 확인, 데이터 구조 파악, 테스트용 XML 빠르게 생성 — 에는 설치 없이 브라우저에서 몇 초 안에 해결됩니다.