XML에서 JSON으로 변환하기: 개발자 실용 가이드

개발자 커뮤니티에서 몇 년마다 XML이 죽었다고 선언하는 글이 나옵니다. 그러다가 첫 엔터프라이즈 통합 계약을 맡거나, RSS 피드를 불러오거나, Android 레이아웃 파일을 들여다보거나, 소설만한 SOAP API 응답을 받아들면 — 거기 있습니다. XML. 여전히 건재하게.

이 글은 XML이 좋은지 나쁜지에 대한 것이 아닙니다. XML 데이터가 있고 JSON이 필요한 실제적인 문제를 다룹니다. 현대 API에 공급하거나, JavaScript로 파싱하거나, 그냥 읽을 수 있게 만들기 위해서든 말이죠.

2026년에도 XML을 여전히 보게 되는 이유

XML은 1990년대 말과 2000년대의 지배적인 데이터 교환 포맷이었습니다. JSON이 2010년대에 웹 API에서 XML을 대부분 대체했지만, XML은 사라지지 않았습니다 — 이미 자리잡은 곳에서 계속 쓰이고 있을 뿐입니다.

여전히 XML을 자주 만나는 곳들:

RSS와 Atom 피드. 모든 주요 뉴스 사이트, 팟캐스트 플랫폼, 블로그는 여전히 XML로 RSS 피드를 발행합니다. 콘텐츠 집계기나 뉴스 리더, 팟캐스트 앱을 만든다면 XML을 다루게 됩니다.

SOAP 웹 서비스. 많은 기업과 정부 시스템이 XML 기반인 SOAP API를 사용합니다. 뱅킹 통합, 보험 시스템, 헬스케어 API, 물류 운송사 — B2B 소프트웨어에서 SOAP은 매우 광범위합니다.

Maven과 Gradle (Java/Kotlin 빌드 도구). pom.xml 파일들. JVM 프로젝트를 건드린다면 XML을 만납니다. Android의 AndroidManifest.xml과 레이아웃 파일도 XML입니다.

Microsoft Office 포맷. DOCX, XLSX, PPTX는 XML을 담은 ZIP 아카이브입니다. 프로그래밍 방식으로 문서를 생성하거나 파싱하면 내부적으로 XML을 다루게 됩니다.

SVG. 확장 가능한 벡터 그래픽은 XML입니다. 프로그래밍 방식으로 벡터 이미지를 다루면 XML 영역입니다.

Salesforce. Salesforce의 SOQL과 Bulk API v1은 모두 XML을 출력합니다. Salesforce 통합 작업에는 종종 XML 파싱이 포함됩니다.

패턴이 명확합니다: 현대 웹 개발은 JSON 쪽으로 기울어져 있지만, 엔터프라이즈 통합, 데이터 피드, 오래된 생태계에 가까이 가면 XML이 나타납니다.

XML을 다루는 게 고통스러운 이유

JSON에 익숙하다면 XML은 매우 짜증스럽게 느껴집니다. 이유가 있습니다.

장황함. 비교해보세요:

{"user": {"id": 1, "name": "철수", "active": true}}

대비:

&lt;user>
  &lt;id>1&lt;/id>
  &lt;name>철수&lt;/name>
  &lt;active>true&lt;/active>
&lt;/user>

동일한 데이터를 담고 있습니다. XML이 더 길고, 한눈에 읽기 어렵고, 직접 작성하면 오류가 나기 쉽습니다.

속성 대 요소의 모호함. XML에서는 데이터를 속성(<user id="1">)이나 자식 요소(<id>1</id>) 둘 다로 표현할 수 있습니다. 둘 다 유효하고, 다른 XML 스키마는 다른 선택을 합니다. 이 불일관성 때문에 스키마를 읽지 않고는 구조를 예측할 수 없습니다.

네임스페이스. XML 네임스페이스는 서로 다른 어휘의 요소 이름이 충돌 없이 공존하도록 허용합니다:

&lt;feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:media="http://search.yahoo.com/mrss/">
  &lt;media:thumbnail url="https://example.com/img.jpg"/>
&lt;/feed>

복잡한 문서에서는 강력하고 필요한 기능입니다. 단순한 값을 추출하려고 할 때는 두통거리입니다.

혼합 콘텐츠. XML은 자식 요소와 텍스트를 섞어 지원합니다:

&lt;p>이것은 &lt;em>중요한&lt;/em> 텍스트입니다.&lt;/p>

이건 JSON으로 깔끔하게 매핑되지 않습니다. JSON 객체는 키-값 쌍이고, "태그된 영역이 포함된 문자열"을 쉽게 표현할 수 없습니다.

이 모든 것이 JavaScript나 Python에서 XML을 다룰 때 문자열 파싱이 아닌 제대로 된 XML 라이브러리가 필요한 이유입니다. 그리고 구조가 허용하는 경우에 JSON으로 변환하면 데이터를 훨씬 다루기 쉬운 이유입니다.

XML to JSON 도구 사용법

XML to JSON 변환기는 브라우저에서 직접 변환을 처리합니다 — 서버에 데이터를 전송하지 않고, 설치도 필요 없습니다.

기본 사용법:

왼쪽 패널에 XML 붙여 넣기
변환 클릭 (또는 자동으로 변환됨)
오른쪽에 JSON 출력 표시
JSON을 복사해서 필요한 곳에 사용

다음과 같은 간단한 XML 문서의 경우:

&lt;?xml version="1.0" encoding="UTF-8"?>
&lt;person>
  &lt;name>철수&lt;/name>
  &lt;age>30&lt;/age>
  &lt;email>cs@example.com&lt;/email>
&lt;/person>

깔끔한 JSON을 얻습니다:

{
  "person": {
    "name": "철수",
    "age": "30",
    "email": "cs@example.com"
  }
}

age가 JSON 출력에서 문자열("30", 30이 아님)이라는 점을 주목하세요. XML에는 숫자 타입이 없어서 모든 것이 텍스트입니다. 일부 변환기는 타입을 추론하려 하지만(숫자처럼 보이는 문자열을 숫자로 변환), 전화번호나 ID처럼 숫자처럼 생겼지만 숫자로 처리하면 안 되는 값들에서 문제가 생길 수 있습니다.

속성 접두사 규칙

XML 요소에 속성이 있을 때, JSON 출력에서 @ 접두사를 붙여 나타납니다:

&lt;book id="123" lang="ko">
  &lt;title>Clean Code&lt;/title>
  &lt;author>로버트 마틴&lt;/author>
&lt;/book>

다음으로 변환됩니다:

{
  "book": {
    "@id": "123",
    "@lang": "ko",
    "title": "Clean Code",
    "author": "로버트 마틴"
  }
}

@ 접두사는 널리 사용되는 규칙입니다(원래 Badgerfish 규칙에서 나온 것으로 여러 인기 XML-JSON 변환 라이브러리에서 사용). JSON 구조에서 속성과 자식 요소를 구분합니다. 코드에서 이 JSON을 사용할 때는 data.book["@id"]로 속성 값에 접근합니다.

반복 요소는 배열이 됩니다

가장 중요하고 (잠재적으로 놀라운) 변환 동작 중 하나: 동일한 태그가 같은 레벨에 여러 번 나타나면 JSON 배열이 됩니다.

&lt;library>
  &lt;book>
    &lt;title>Clean Code&lt;/title>
  &lt;/book>
  &lt;book>
    &lt;title>실용주의 프로그래머&lt;/title>
  &lt;/book>
  &lt;book>
    &lt;title>리팩터링&lt;/title>
  &lt;/book>
&lt;/library>

다음으로 변환됩니다:

{
  "library": {
    "book": [
      {"title": "Clean Code"},
      {"title": "실용주의 프로그래머"},
      {"title": "리팩터링"}
    ]
  }
}

이것은 올바르고 유용한 동작입니다. 하지만 한 가지 불일관성이 생깁니다: 도서관에 책이 한 권만 있다면, book은 배열이 아닌 객체가 됩니다. JSON 구조가 항상 일관적이라고 가정하는 많은 코드가 이 부분에서 실패합니다.

변환된 JSON을 소비하는 코드를 작성할 때는 필드가 객체일 수도 있고 배열일 수도 있는 경우를 항상 처리하세요. JavaScript에서는 인덱스 접근 전에 Array.isArray(data.library.book) 확인. TypeScript에서는 스키마를 신중하게 타입 정의.

변환이 완벽하지 않은 경우

일부 XML 기능은 JSON으로 깔끔하게 변환되지 않습니다.

네임스페이스. 네임스페이스 선언(xmlns="...")은 변환기에 따라 보존되거나 그렇지 않을 수 있습니다. 요소 이름의 네임스페이스 접두사(media:thumbnail)는 일반적으로 키 이름에 접두사가 포함된 형태로 변환됩니다("media:thumbnail"). 동작은 하지만, 하위 코드에서 그 키를 찾을 줄 알아야 합니다.

CDATA 섹션. <![CDATA[...]]> 섹션에는 마크업으로 파싱되지 않아야 하는 원시 텍스트가 포함됩니다. 대부분의 변환기는 CDATA 블록에서 텍스트 콘텐츠를 추출하는데, 이것이 올바른 동작입니다. 하지만 CDATA 콘텐츠에 의도적인 마크업이나 특수 문자가 있다면 출력을 신중하게 확인하세요.

처리 지시문. <?xml-stylesheet type="text/xsl" href="style.xsl"?> 같은 선언은 변환기에 의해 일반적으로 제거됩니다. 필요하다면 별도로 처리해야 합니다.

XML 주석.  노드는 일반적으로 제거됩니다. XML에서 의미 있는 데이터를 주석으로 전달하는 경우(나쁜 관행이지만 존재합니다), 변환 시 해당 데이터를 잃게 됩니다.

단순한 데이터 교환 — API, 설정, 데이터 피드 — 의 경우에는 이런 엣지 케이스가 거의 중요하지 않습니다. 문서 중심 XML(콘텐츠 관리, 기술 문서)의 경우에는 인식하고 있어야 합니다.

실제 사용 사례

SOAP API 응답 소비하기

SOAP 응답:

&lt;soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  &lt;soap:Body>
    &lt;GetUserResponse>
      &lt;User id="42">
        &lt;Name>철수&lt;/Name>
        &lt;Email>cs@example.com&lt;/Email>
      &lt;/User>
    &lt;/GetUserResponse>
  &lt;/soap:Body>
&lt;/soap:Envelope>

이것을 변환하면 완전한 SOAP 라이브러리 없이 JavaScript에서 작업할 수 있는 JSON 구조를 얻습니다. 네임스페이스 접두사(soap:)는 키 이름의 일부로 나타납니다. 빠른 데이터 추출에는 이것으로 충분한 경우가 많습니다.

RSS 피드 파싱하기

RSS 피드는 예측 가능한 구조를 가진 XML 문서입니다. JSON으로 변환하면 현대 JavaScript에서 훨씬 다루기 쉬워집니다:

&lt;rss version="2.0">
  &lt;channel>
    &lt;title>예시 블로그&lt;/title>
    &lt;item>
      &lt;title>첫 번째 포스트&lt;/title>
      &lt;link>https://example.com/post1&lt;/link>
      &lt;pubDate>Mon, 01 Apr 2026 00:00:00 GMT&lt;/pubDate>
    &lt;/item>
    &lt;item>
      &lt;title>두 번째 포스트&lt;/title>
      &lt;link>https://example.com/post2&lt;/link>
      &lt;pubDate>Tue, 02 Apr 2026 00:00:00 GMT&lt;/pubDate>
    &lt;/item>
  &lt;/channel>
&lt;/rss>

변환 후에는 data.rss.channel.item이 직접 순회할 수 있는 포스트 배열인 일반 JavaScript 객체를 갖게 됩니다.

Android 리소스 파일 읽기

Android strings.xml 리소스 파일은 XML입니다:

&lt;resources>
  &lt;string name="app_name">내 앱&lt;/string>
  &lt;string name="welcome_message">다시 오신 것을 환영합니다!&lt;/string>
  &lt;string name="error_generic">문제가 발생했습니다.&lt;/string>
&lt;/resources>

JSON으로 변환하면 완전한 Android SDK 없이 빌드 스크립트나 툴링에서 이 파일들을 처리하기 쉬워집니다.

프로그래밍 방식 변환을 위해

코드에서 반복적으로 XML을 JSON으로 변환해야 한다면 브라우저 도구가 정답이 아닙니다. 옵션들:

JavaScript/Node.js: fast-xml-parser가 가장 널리 사용되는 라이브러리로, 빠르고 설정 가능합니다. xml2js는 더 오래됐지만 여전히 인기 있습니다. 둘 다 속성, 배열, 네임스페이스를 설정 가능한 동작으로 처리합니다.

const { XMLParser } = require('fast-xml-parser');
const parser = new XMLParser({ ignoreAttributes: false, attributeNamePrefix: '@' });
const result = parser.parse(xmlString);

Python: xmltodict는 XML을 Python 딕셔너리로 변환합니다(JSON으로 깔끔하게 매핑). lxml은 복잡한 XML 처리에 더 강력합니다.

import xmltodict, json
result = xmltodict.parse(xml_string)
json_output = json.dumps(result, indent=2, ensure_ascii=False)

일회성 변환이나 디버깅에는 XML to JSON 도구가 이 코드를 작성하는 것보다 빠릅니다. 프로덕션 파이프라인에는 언어에 맞는 라이브러리를 선택해서 한 번 설정하세요.

XML은 사라지지 않습니다 — XML 기반 시스템의 설치 기반은 방대하고, 기업들은 작동하는 인프라를 일정에 맞춰 재작성하지 않습니다. 실용적인 기술은 XML이 나타날 때 매번 씨름하는 것이 아니라 효율적으로 다루는 방법을 아는 것입니다.

구조화된 데이터 작업에 유용한 관련 도구들:

XML 포매터 — XML 포맷, 검증, 예쁘게 출력
JSON 포매터 — 변환 후 JSON 출력 정리
JSON Diff — 두 JSON 구조를 비교해서 변경 사항 파악