2026년의 XML: 현대 개발에서 아직 관련이 있을까?

솔직히 말하면 — 2026년에 "XML"을 보면 처음 드는 생각은 "레거시 코드"입니다. 하지만 그건 사실 불공평합니다. XML은 지구상에서 가장 중요한 시스템 중 일부를 조용히 가동하고 있으며, 곧 사라질 일은 없습니다. 그 이유를 보여드리겠습니다.

XML이 아직 주도하는 곳

은행 및 금융: 유럽에서 은행 송금을 할 때마다 ISO 20022 메시지를 통할 가능성이 높습니다 — 이것이 바로 XML입니다. 재무 보고는 XBRL(이것도 XML)을 사용합니다. 매일 수조 달러가 XML 파이프를 통해 흐르고 있습니다.

의료: HL7 FHIR은 JSON과 XML을 모두 사용하지만, 대부분의 병원 시스템이 돌아가는 기존 HL7 v2/v3 메시지는요? 순수 XML입니다. 환자 기록, 검사 결과, 처방전 — 모두 XML입니다.

여러분의 Office 문서: 모든 .docx, .xlsx, .pptx 파일은 실제로 XML 파일로 가득 찬 ZIP 아카이브입니다. 한번 열어보세요 — 매혹적입니다 (그리고 좀 무섭기도 합니다).

안드로이드 개발: 안드로이드의 모든 레이아웃 파일은 XML입니다. activity_main.xml은 아마 모든 안드로이드 개발자가 처음 만드는 파일일 겁니다.

빌드 도구: Maven의 pom.xml, .NET의 .csproj 파일, Spring Framework 설정 — XML은 엔터프라이즈 도구 체인에 깊이 내장되어 있습니다.

XML이 할 수 있고 JSON이 할 수 없는 것

네임스페이스: 이름 충돌 없이 서로 다른 어휘의 요소를 하나의 문서에 결합하는 것을 상상해보세요. XML 네임스페이스가 이를 가능하게 합니다. HTML에 포함된 SVG나 SOAP 헤더와 커스텀 페이로드를 혼합하는 형식에 필수적입니다.

혼합 콘텐츠: 일부 단어가 굵은 글씨이고 다른 단어가 기울임 글씨인 단락을 JSON으로 표현해보세요. 기껏해야 어색합니다. XML은 데이터만이 아니라 문서를 위해 설계되었기 때문에 이를 자연스럽게 처리합니다.

XSLT 변환: 하나의 XSLT 스타일시트를 작성하면 XML을 HTML, PDF, 다른 XML 형식 또는 일반 텍스트로 변환할 수 있습니다. JSON 세계에는 진정한 대안이 없는 선언적 변환 언어입니다.

스키마 검증: XML Schema (XSD)는 많은 영역에서 JSON Schema보다 표현력이 뛰어납니다. 요소 순서, 복잡한 타입 계층, JSON Schema가 어려워하는 필드 간 제약을 강제할 수 있습니다.

실제 사례

송장을 생성해야 하는 전자상거래 시스템을 구축한다고 가정합시다. XML + XSLT를 사용하면 송장 데이터를 XML에 저장하고, 다른 XSLT 스타일시트를 적용하여 브라우저용 HTML 버전, 인쇄용 PDF 버전, 공급자 시스템용 EDI 버전을 동일한 소스 데이터에서 생성할 수 있습니다. JSON으로 이걸 해보세요.

XML 네임스페이스 실전

네임스페이스는 실제로 필요할 때까지 혼란스러워 보이는 XML 기능 중 하나입니다. 실용적인 예를 봅시다 — XHTML 문서 안에 포함된 SVG 아이콘입니다:

네임스페이스가 없다면 파서는 이 HTML 어휘에 속하는지 SVG 어휘에 속하는지 알 수 없을 것입니다. 네임스페이스를 사용하면 하나의 문서에서 어휘를 자유롭게 혼합할 수 있으며, 이는 JSON에는 단순히 메커니즘이 없는 것입니다.

개발자가 XML에서 흔히 저지르는 실수

프로덕션 시스템에서 XML을 다루며 수년간 일한 후, 가장 자주 보는 함정들입니다:

1. 인코딩 선언을 무시하기. XML 파일에 비ASCII 문자가 포함되어 있는데 인코딩 선언을 잊으면, 파서는 UTF-8이나 기본값을 가정합니다. 항상 명시적으로 선언하세요:

2. 요소가 더 적합한데 속성을 사용하기. 속성은 복잡한 구조를 담을 수 없고, 반복할 수 없으며, 쉽게 발전시킬 수 없습니다. 값이 나중에 복잡해질 수 있다면, 대신 자식 요소를 사용하세요.

3. 스키마에 대해 검증하지 않기. 검증되지 않은 XML을 주고받는 것은 조용한 실패의 레시피입니다. XSD가 있다면 사용하세요. 잘못된 데이터가 시스템을 통해 연쇄적으로 퍼지게 하는 대신 파싱 시점에 데이터 문제를 잡아냅니다.

4. 문자열 연결로 XML 만들기. 절대 하지 마세요 — 발생을 기다리는 인젝션 취약점입니다. 항상 적절한 XML 라이브러리나 DOM 빌더를 사용하세요.

XML 처리 성능 팁

XML 파서는 크게 두 가지 종류가 있으며, 올바른 것을 선택하는 것이 성능에 매우 중요합니다:

• DOM 파서는 전체 문서를 트리로 메모리에 로드합니다. 임의 접근이 필요한 소규모에서 중규모 문서에 좋습니다. 대용량 파일에는 좋지 않습니다 — 100MB XML 파일은 DOM 트리로 1GB 이상의 RAM을 소비할 수 있습니다.
• SAX/StAX 파서는 문서를 스트림으로 처리하며, 한 번에 하나의 요소만 처리합니다. 메모리를 거의 사용하지 않으며 대용량 파일에 훨씬 빠릅니다. 단점은 문서 내에서 이동할 수 없다는 것입니다.

경험칙은 이렇습니다: XML이 10MB 미만이면 DOM이 괜찮습니다. 10MB 이상이면 스트리밍을 진지하게 고려하세요. 100MB 이상이면 서버가 메모리 부족으로 멈추는 걸 보는 것을 즐기지 않는 한 스트리밍은 필수입니다.

XML vs JSON: 빠른 참조

XML의 간략한 역사

XML은 1998년 2월 W3C 권고안으로 발표되었습니다. 1980년대부터 존재했지만 악명 높게 복잡했던 SGML(Standard Generalized Markup Language)의 단순화된 하위 집합으로 설계되었습니다. 목표는 사람이 읽을 수 있고 기계가 파싱할 수 있으며, 모호함을 피할 만큼 엄격하고, 어떤 도메인에도 충분히 유연한 형식을 만드는 것이었습니다. 2000년대 첫 10년간 XML은 *바로 그* 데이터 교환 형식이었습니다. SOAP 웹 서비스, RSS 피드, Atom 피드, XHTML — 모든 것이 XML이었습니다. 그런 다음 JSON이 등장하여 웹 API 영역을 차지했지만, XML은 고유한 기능(네임스페이스, 스키마, 변환)이 실제로 중요한 모든 도메인을 유지했습니다.

현대의 XML 개발자

오늘날 대부분의 개발자는 하이브리드 환경에서 일합니다. 웹 API와 실시간 통신에는 JSON을, 문서 처리, 엔터프라이즈 통합, 규정 준수에는 XML을 사용합니다. 두 형식을 모두 알고 — 언제 어떤 것을 사용할지 아는 것은 — 정말 가치 있는 기술입니다.

XML 보안: XXE 및 기타 함정

보안 엔지니어의 잠을 빼앗는 XML 관련 한 가지가 있다면, 바로 XXE — XML External Entity 공격입니다. 솔직히 여러분도 걱정해야 합니다. XXE는 충분한 이유로 OWASP Top 10 목록에 올라 있으며, 2026년에도 여전히 개발자들을 당황하게 합니다.

XXE의 작동 방식은 이렇습니다: XML을 사용하면 문서 타입 선언(DTD)에서 "엔티티" — 본질적으로 변수 — 를 정의할 수 있습니다. *외부* 엔티티는 서버의 URL이나 파일 경로를 참조할 수 있습니다. 파서가 외부 엔티티를 해석하도록 설정되어 있다면 (많은 파서가 기본적으로 그렇습니다), 공격자는 서버에서 임의 파일을 읽는 XML을 만들 수 있습니다:

파서가 이를 처리하면 &xxe;를 /etc/passwd의 내용으로 대체합니다. 그렇게 간단하게 공격자가 시스템의 민감한 파일을 읽습니다. 더 고급 공격에서는 서버에서 아웃바운드 HTTP 요청(Server-Side Request Forgery)을 하거나, 사용 가능한 모든 메모리를 소비하는 재귀적 엔티티 확장인 악명 높은 "billion laughs" 공격으로 서비스 거부를 유발할 수도 있습니다.

해결책은 간단합니다: 외부 엔티티 처리를 비활성화하세요. 두 가지 인기 언어에서의 방법은 다음과 같습니다:

XXE 외에도 XML 인젝션에 주의하세요 — 사용자 입력이 적절한 이스케이프 없이 XML에 삽입되는 것입니다. SQL 인젝션의 XML 버전입니다. 문자열 연결 대신 항상 적절한 XML 빌더 라이브러리를 사용하세요 (흔한 실수 섹션에서 이미 언급했지만, *그만큼* 중요하기 때문에 반복할 가치가 있습니다).

황금률: 신뢰할 수 없는 XML을 기본 파서 설정으로 파싱하지 마세요. 항상 명시적으로 외부 엔티티 해석, DTD 처리, XInclude 처리를 비활성화하세요. 외부 세계의 XML을 SQL 쿼리의 사용자 입력과 같은 의심을 가지고 다루세요.

XPath: 프로처럼 XML 쿼리하기

XML을 정기적으로 다루면서 XPath를 사용하지 않는다면, 어렵게 하고 있는 겁니다. XPath는 XML 문서를 탐색하기 위해 특별히 설계된 쿼리 언어로, 익숙해지면 놀라울 정도로 강력합니다.

XPath를 CSS 셀렉터의 XML 버전이라고 생각하세요. 중첩된 루프로 DOM을 수동으로 순회하는 대신, 원하는 노드를 정확히 선택하는 간결한 표현식을 작성합니다. 몇 가지 실용적인 예를 봅시다:

JavaScript와 Python에서 XPath를 사용하는 방법은 다음과 같습니다 — 대부분의 개발자가 사용하는 두 가지 언어입니다:

한 가지 주목할 점: JSON에는 내장 쿼리 언어가 없습니다. 가장 가까운 대안은 jq로, 훌륭하지만 형식의 표준화된 부분이 아닌 외부 도구입니다. XPath는 XML 생태계에 내장되어 있습니다 — 브라우저가 기본 지원하고, 거의 모든 프로그래밍 언어에서 사용 가능하며, W3C가 표준화했습니다. XML의 진정한 경쟁 우위 중 하나입니다.

XPath는 또한 XSLT(변환할 노드를 선택)와 XQuery(XML 데이터베이스용 완전한 쿼리 언어)의 기반이기도 합니다. XPath를 배우면 XML 기술의 전체 가족을 해제한 것입니다.

산업별 표준에서의 XML

앞서 은행과 의료에 대해 언급했지만, 산업별 표준에서 XML의 영향력은 그보다 훨씬 깊습니다. XML이 단순히 사용되는 것이 아니라 *필수*인 도메인을 둘러봅시다:

법률: 법률 산업은 법원 접수와 사건 관리를 위해 XML에 크게 의존합니다. OASIS가 개발한 LegalXML은 전자 법원 접수, 법적 인용, 사건 메타데이터를 표준화합니다. 미국에서는 많은 주 법원 시스템이 XML 기반 전자 접수 형식을 의무화하고 있습니다. 법률 기술을 구축하고 있다면, XML 위에 구축하고 있는 겁니다.

출판: 이건 많은 사람을 놀라게 합니다 — 여러분이 읽은 모든 EPUB 전자책은 XML 위에 구축되어 있습니다. EPUB 파일은 XHTML 콘텐츠 파일(XML), OPF 패키지 디스크립터(XML), 네비게이션 문서(XML)를 포함하는 ZIP 아카이브입니다. 또 다른 XML 형식인 DocBook은 1990년대부터 기술 문서의 표준이었습니다. O'Reilly Media는 유명하게도 수년간 DocBook을 사용하여 단일 XML 소스에서 여러 출력 형식으로 책을 제작했습니다.

과학과 수학: MathML은 XML로 수학적 표기법을 표현하기 위한 W3C 표준입니다. 모든 최신 브라우저에서 지원되며 웹에서의 과학 출판에 필수적입니다. 그 다음으로 분자 구조를 위한 Chemical Markup Language(CML), 천체 데이터를 위한 Astronomical Markup Language, 그리고 수십 가지 다른 과학 XML 어휘가 있습니다. 정밀도와 모호하지 않은 데이터 표현이 중요할 때 — 그리고 과학에서는 항상 중요합니다 — XML이 해답입니다.

정부 및 조달: Universal Business Language (UBL)는 전 세계 정부가 조달, 청구, 공급망 관리에 사용하는 OASIS 표준입니다. 유럽 연합의 전자 청구 지침은 기업 대 정부 청구에 UBL 기반 XML을 본질적으로 의무화합니다. 유럽 정부에 판매한다면, XML 청구서를 보내고 있는 겁니다.

항공: Aeronautical Information Exchange Model(AIXM)은 항공 데이터를 위한 XML 스키마를 정의합니다 — 공항, 공역, 항행 보조 시설, 절차. 모든 비행 관리 시스템, 모든 항공 교통 관제 업데이트, 모든 NOTAM(Notice to Airmen)이 AIXM 데이터에 접촉합니다. 이것은 "그냥 JSON으로 바꾸자"라는 대화가 이루어지지 않는 도메인입니다. 형식 마이그레이션의 안전 영향이 엄청날 것이기 때문입니다.

이 모든 산업에 공통되는 것은 무엇일까요? 강력한 검증, 어휘를 결합하기 위한 네임스페이스, 그리고 역호환성을 깨지 않고 수십 년에 걸쳐 발전할 수 있는 형식이 필요했기 때문에 XML을 선택했습니다. 이러한 요구 사항은 변하지 않았습니다.

SOAP vs REST: XML API가 아직 존재하는 이유

지난 10년 내에 경력을 시작했다면, 모든 API가 JSON을 사용하는 REST라고 생각할 수 있습니다. 하지만 대형 은행, 보험 회사, 통신사, 정부 기관에 들어가면 중요한 비즈니스 로직을 처리하는 SOAP 웹 서비스를 발견할 것입니다. 그리고 그럴 만한 이유가 있습니다.

SOAP(Simple Object Access Protocol)은 REST+JSON이 기본적으로 제공하지 않는 몇 가지 기능을 가진 XML 기반 메시징 프로토콜입니다:

WSDL을 통한 강력한 계약: WSDL(Web Services Description Language) 파일은 SOAP 서비스에 대한 *모든 것*을 설명합니다 — 작업, 입출력 메시지 구조, 데이터 타입, 엔드포인트. Java, C#, Python 또는 거의 모든 엔터프라이즈 언어로 WSDL에서 클라이언트 코드를 자동 생성할 수 있습니다. REST API에는 OpenAPI/Swagger가 있지만, 채택은 자발적입니다. SOAP에서는 계약이 곧 서비스입니다.

내장 오류 처리: SOAP에는 오류 코드, 오류 문자열, 상세 요소가 있는 표준화된 fault 요소가 있습니다. 모든 SOAP 클라이언트는 오류를 파싱하는 방법을 정확히 알고 있습니다. REST API는요? 각 API가 자체 오류 형식을 만듭니다.

WS-Security: SOAP에는 전송 수준(TLS)뿐만 아니라 메시지 수준 암호화 및 서명을 지원하는 포괄적인 보안 표준이 있습니다. 이는 SOAP 메시지가 중간 서버를 거치면서도 종단간 암호화된 상태를 유지할 수 있다는 것을 의미합니다. 메시지가 여러 시스템을 통해 라우팅되는 금융 서비스에서 이는 매우 중요합니다.

트랜잭션과 신뢰성: WS-AtomicTransaction과 WS-ReliableMessaging은 분산 트랜잭션 지원과 보장된 전달을 제공합니다. 이는 REST가 애플리케이션 개발자에게 전적으로 맡기는 어려운 문제들입니다.

그렇지만 SOAP에는 실제 단점이 있습니다: 메시지가 장황하고, 학습 곡선이 가파르며, 디버깅이 고통스럽고, XML 오버헤드로 인해 단순한 CRUD 작업에서는 JSON보다 느립니다. 새로운 웹 API와 마이크로서비스에는 REST+JSON이 거의 항상 올바른 선택입니다. 하지만 복잡한 엔터프라이즈 통합 — 특히 규제 산업에서는 — SOAP의 내장 계약 적용과 보안 기능이 진정으로 가치 있습니다.

XML에서 JSON으로 마이그레이션: 실용 가이드

경력의 어느 시점에 누군가가 XML 기반 시스템을 JSON으로 마이그레이션해달라고 할 것입니다. "물론이죠, 쉽습니다"라고 말하기 전에, 모두를 놀라게 하는 함정들을 보여드리겠습니다.

속성 손실: XML 요소는 속성과 자식 요소 모두를 가질 수 있습니다. JSON 객체는 프로퍼티만 있습니다. Dune을 변환할 때 id는 어디로 가나요? format은? 텍스트 콘텐츠는? 일반적인 관례에서는 속성에 @ 접두사를, 텍스트 콘텐츠에 #text를 사용하지만, 보편적인 표준은 없습니다 — 그리고 무엇을 선택하든 상대 시스템이 여러분의 관례를 이해해야 합니다.

타입 강제 변환: XML은 본질적으로 텍스트 기반입니다. XML의 문자열 "42"는 정수, 부동소수점, 문자열 또는 우편번호일 수 있습니다. JSON에는 구별된 타입이 있습니다. 마이그레이션 중에는 명시적인 타입 매핑 규칙이 필요하며, 그렇지 않으면 숫자가 필요한 곳에 문자열이 (또는 더 나쁘게는 문자열이 필요한 곳에 숫자가 — 우편번호의 앞쪽 0이 사라집니다).

배열 모호성: 이것은 특히 까다롭습니다. XML에서 요소에 자식이 하나 있으면 단일 요소입니다. 같은 이름의 자식이 여러 개 있으면 자연스럽게 컬렉션입니다. 하지만 JSON은 무언가가 배열인지 단일 값인지 미리 알아야 합니다. 생각해보세요: Widget — item은 문자열인가요 아니면 단일 요소 배열인가요? 다른 주문에 세 개의 항목이 있으면 구조가 바뀝니다. JSON 소비자는 두 경우 모두를 처리해야 합니다.

성공적인 마이그레이션을 위한 단계:

• 1단계: 모든 XML 스키마의 인벤토리를 작성하고 어떤 기능을 사용하고 있는지 정확히 문서화하세요 (네임스페이스, 속성, 혼합 콘텐츠, CDATA 섹션, 처리 지시문).
• 2단계: JSON 스키마를 먼저 설계하고, 속성, 혼합 콘텐츠, 배열을 어떻게 처리할지 명시적으로 결정하세요. 모든 결정을 문서화하세요.
• 3단계: 변환 레이어를 구축하세요 (빅뱅 재작성이 아닌). 두 형식을 병렬로 실행하고 출력을 비교하세요.
• 4단계: 소비자를 하나씩 마이그레이션하고, 모두가 전환할 때까지 XML 엔드포인트를 유지하세요.
• 5단계: XML을 폐기하기 전에 최소 하나의 완전한 비즈니스 사이클 (도메인에 따라 월, 분기 또는 연) 동안 병렬 시스템을 운영하세요.

마이그레이션하지 말아야 할 때: XML이 네임스페이스 혼합, XSLT 변환 또는 XPath 기반 비즈니스 규칙을 많이 사용하는 경우, 마이그레이션 비용이 이점을 초과할 수 있습니다. 또한 XML이 규제 표준(HL7, ISO 20022, UBL)에 의해 의무화된 경우, 어차피 XML을 유지해야 합니다 — JSON을 추가하면 지원할 두 번째 형식만 추가됩니다.

모든 개발자가 알아야 할 XML 도구

적절한 도구가 있으면 XML 작업이 고통스러울 필요가 없습니다. 제가 의존하는 도구들입니다:

xmllint: libxml2와 함께 제공되며 아마 이미 시스템에 있을 겁니다. 스키마에 대해 XML을 검증하고, XML을 포맷(프리티 프린트)하며, XPath 표현식을 평가합니다 — 모두 명령줄에서. XML 세계의 curl입니다: 단순하고, 빠르고, 어디에나 있습니다.

Saxon: XSLT 및 XQuery 처리의 골드 스탠다드로, Michael Kay(XSLT 2.0 및 3.0 사양을 문자 그대로 편집한 사람)가 개발했습니다. 진지한 XSLT 변환을 한다면 Saxon이 필요합니다. 오픈소스 Home Edition은 XSLT 3.0과 XPath 3.1을 처리합니다.

XMLSpy (Altova): 기업에서 인기 있는 상용 XML IDE입니다. 비주얼 스키마 편집기, XSLT 디버거, 데이터베이스 통합이 있습니다. 비싸지만 강력합니다 — 손으로 편집하기 비현실적인 거대한 XSD 스키마를 다룰 때 특히 유용합니다.

oXygen XML Editor: XML 집중 작업을 위한 제 개인적인 즐겨찾기입니다. 단계별 실행으로 XSLT 디버깅, XPath 평가, 자동 완성이 있는 스키마 인식 편집을 지원하고, DITA와 DocBook에 대한 훌륭한 지원이 있습니다. 정기적으로 XSLT를 작성한다면, oXygen은 일주일 안에 본전을 뽑습니다.

xmlstarlet: 터미널에서 직접 XML을 쿼리, 편집, 검증, 변환할 수 있는 명령줄 XML 툴킷입니다. XML용 sed와 awk라고 생각하세요. XML 설정 파일에서 값을 추출하거나 즉석에서 XML을 수정해야 하는 셸 스크립트와 CI/CD 파이프라인에 완벽합니다.

XML 확장 프로그램이 있는 Visual Studio Code: 이미 VS Code를 사용하고 있다면, Red Hat의 "XML" 확장 프로그램이 스키마 검증, 자동 완성, 포맷을 제공합니다. "XSLT/XPath" 확장 프로그램과 결합하면 가끔의 XML 작업에 놀라울 정도로 유능한 무료 설정입니다.

직접 해보세요

두 세계를 연결해야 하나요? 저희 XML to JSON 변환기가 데이터 구조와 타입을 유지하면서 변환을 처리합니다. XML을 디버깅하고 있다면, XML Formatter가 아무리 지저분한 XML도 읽기 쉽게 만들어줍니다. 그리고 프로덕션에 XML을 배포하기 전에 XML Validator로 구조적 문제를 일찍 잡으세요.