XML(eXtensible Markup Language)은 많은 현대 개발자에게 익숙하면서도 종종 오해받는 기술이다. 그 본질을 이해하려면, 데이터를 단순히 화면에 보여주는(display) 데 초점을 맞춘 HTML과의 근본적인 차이점부터 알아야 한다. XML의 설계 목적은 데이터를 저장하고 전달하며, 데이터 자체의 구조와 의미를 기술하는 데 있다.1 이는 서로 다른 시스템, 특히 인터넷으로 연결된 이기종 시스템 간에 데이터를 원활하게 교환하기 위한 목적에서 출발했다.4
XML은 1998년 W3C(World Wide Web Consortium)에 의해 표준으로 제정되었으며, 그 뿌리는 SGML(Standard Generalized Markup Language)에 두고 있다. XML은 SGML의 복잡성을 대폭 줄인 실용적인 부분집합으로 설계되었다.4 가장 핵심적인 특징 중 하나는 특정 목적을 가진 마크업 언어를 만드는 데 사용되는 메타 언어(meta-language)라는 점이다.1 이름에 포함된 ‘확장 가능(eXtensible)’이라는 단어가 바로 이 특성을 의미한다. 개발자는 미리 정해진 태그만 사용하는 것이 아니라, 데이터의 의미에 맞게 새로운 태그를 직접 정의할 수 있다. 이러한 확장성 덕분에 수학을 위한 MathML, 화학을 위한 CML, 지리 정보를 위한 GML 등 수많은 산업 표준 파생 언어가 탄생할 수 있었다.1
2000년대 초반, XML은 플랫폼에 독립적인 텍스트 기반 형식이라는 장점 덕분에 이기종 시스템 간 데이터 교환의 사실상 표준으로 군림했다.1 유니코드를 완벽하게 지원하여 어떤 운영체제나 프로그래밍 언어 환경에서도 데이터의 손실 없이 정보를 주고받을 수 있었고, 이는 데이터 무결성을 보장하는 핵심 가치로 여겨졌다.5 그러나 기술의 흐름은 변했다. 최근 웹 API와 모바일 애플리케이션 개발에서는 더 가볍고 파싱 속도가 빠른 JSON(JavaScript Object Notation)이 주도권을 잡으면서, XML은 구식 기술로 치부되기도 한다.1
이러한 상황은 XML의 현재 위치를 정의하는 근본적인 긴장감을 만들어낸다. XML은 한편으로는 정부, 금융, 복잡한 문서 표준 등 광범위한 디지털 인프라를 지탱하는 기반 기술이지만, 다른 한편으로는 JSON이 지배하는 현대 웹 개발의 맥락에서는 ‘레거시’ 또는 ‘구식’ 형식으로 간주된다. 따라서 2025년 현재 XML을 이해한다는 것은 사라져가는 언어를 배우는 것이 아니다. 데이터의 무결성, 구조적 복잡성, 그리고 공식적인 유효성 검사가 무엇보다 중요한 특정 문제 영역에서, XML이 왜 여전히 가장 강력하고 올바른 선택인지를 이해하고 그 전문성을 습득하는 것을 의미한다. 이 안내서는 바로 그 지점을 파고들어, XML의 핵심 문법부터 현대적 활용 사례와 미래 전망까지 심층적으로 분석할 것이다.
XML을 제대로 활용하기 위해서는 그 구조와 엄격한 문법 규칙을 정확히 이해하는 것이 선행되어야 한다. HTML과 유사해 보이지만, XML의 규칙은 훨씬 더 엄격하며, 이 규칙을 지키지 않으면 문서는 처리되지 않는다.
모든 XML 문서는 논리적으로 계층적인 트리 구조를 가진다. 이 구조의 최상단에는 단 하나의 루트 요소(Root Element)가 존재해야 하며, 모든 다른 요소들은 이 루트 요소 안에 중첩되는 형태로 구성된다.2
문서의 가장 첫 줄에는 XML 프롤로그(Prolog)를 선언할 수 있다. 이는 필수는 아니지만, 문서의 속성을 명확히 하기 위해 강력히 권장된다.10
XML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
xml은 반드시 소문자로 작성해야 한다.10version: 사용된 XML의 버전을 명시한다. 현재 대부분 1.0을 사용한다.10encoding: 문서의 문자 인코딩 방식을 지정한다. 전 세계의 거의 모든 문자를 표현할 수 있는 UTF-8이 기본값이자 가장 널리 사용된다.4standalone: 문서가 외부 문서 정의(DTD 등)에 의존하는지 여부를 파서에게 알리는 속성이다. yes는 외부 의존성이 없음을, no는 외부 문서를 참조해야 함을 의미한다. 기본값은 no이다.12XML 문서는 세 가지 핵심 구성 요소로 이루어진다.
요소(Element): XML의 기본 빌딩 블록으로, 시작 태그, 내용(콘텐츠), 종료 태그로 구성된다. 예를 들어, <book>XML Guide</book> 전체가 하나의 요소다.14
태그(Tag): 요소를 정의하기 위해 꺾쇠괄호(<>)로 감싼 이름이다. 모든 시작 태그(<book>)는 반드시 그에 대응하는 종료 태그(</book>)를 가져야 한다.12 만약 요소 내에 아무런 내용이 없다면,
<br></br> 대신 <br/>와 같이 하나의 태그로 축약하여 표현할 수 있다. 이를 빈 요소(empty element)라고 한다.12
속성(Attribute): 요소에 대한 추가적인 정보를 제공하는 역할을 한다. 속성은 항상 시작 태그 안에 이름="값"의 형태로 정의되며, 속성값은 반드시 큰따옴표(") 또는 작은따옴표(')로 감싸야 한다.12 하나의 요소는 여러 개의 속성을 가질 수 있지만, 같은 이름의 속성을 두 번 이상 사용할 수는 없다.14
XML
<book category="Programming" published="2024">
<title>XML Guide</title>
</book>
위 예제에서 book은 category와 published라는 두 개의 속성을 가진 요소이며, title이라는 자식 요소를 포함하고 있다.
XML은 데이터를 표현하고 처리하는 과정에서 혼란을 막기 위해 매우 엄격한 문법 체계를 가지고 있다.
-- 문자열을 포함할 수 없으며, 주석을 중첩시키는 것도 허용되지 않는다.4<!]>로 끝나며, CDATA 키워드는 반드시 대문자로 써야 한다.14<, >, &)을 텍스트 내용으로 사용하려면, 미리 정의된 엔티티로 변환해야 한다. 예를 들어, <는 <, >는 >, &는 &로 표현해야 한다.12이 외에도 반드시 지켜야 할 핵심 규칙들이 있다. 이 규칙들은 XML을 HTML이나 JSON과 구별하는 중요한 특징이다.
<Book>과 <book>은 완전히 다른 요소로 인식된다.12<b><i>text</i></b>는 올바르지만, <b><i>text</b></i>는 잘못된 중첩으로 오류를 발생시킨다.10_)로 시작해야 한다. 이름 중간에 공백을 포함할 수 없으며, xml이라는 문자열(대소문자 무관)로 시작할 수 없다.14| 규칙 (Rule) | 설명 (Description) | 올바른 예시 (Correct Example) | 잘못된 예시 (Incorrect Example) |
|---|---|---|---|
| 루트 요소 | 문서는 단 하나의 최상위 요소를 가져야 함 | <root><child/></root> |
<root/><another_root/> |
| 태그 닫기 | 모든 시작 태그는 종료 태그를 갖거나, 빈 태그 형식이어야 함 | <p>text</p>, <br/> |
<p>text, <br> |
| 대소문자 구분 | 태그와 속성 이름은 대소문자를 구분함 | <book>...</book> |
<book>...</Book> |
| 중첩 순서 | 나중에 열린 태그가 먼저 닫혀야 함 | <b><i>text</i></b> |
<b><i>text</b></i> |
| 속성 값 따옴표 | 모든 속성값은 따옴표로 감싸야 함 | <a href="url"> |
<a href=url> |
| 공백 처리 | 텍스트 내의 공백과 줄 바꿈을 그대로 인식함 | <p>Hello World</p> |
(HTML과 달리 공백이 유지됨) |
| 이름 규칙 | 문자나 _로 시작, 공백 포함 불가, ‘xml’ 시작 불가 |
<_my-tag>, <item1> |
<1item>, <my tag>, <xml-tag> |
XML 문서의 품질을 논할 때 ‘정형(Well-formed)’과 ‘유효(Valid)’라는 두 가지 중요한 개념이 등장한다. 이 둘의 차이를 이해하는 것은 XML의 설계 철학을 파악하는 데 있어 핵심적이다.
‘정형(Well-formed)’ XML이란 1장에서 설명한 모든 구문 규칙(syntax rules)을 완벽하게 준수한 문서를 의미한다.15 이는 XML 문서가 되기 위한 최소한의 자격 요건이다.
이러한 기본 문법을 하나라도 어기면 그 문서는 ‘정형’이 아니며, 기술적으로 더 이상 XML 문서로 취급되지 않는다. XML 파서(parser)는 정형이 아닌 문서를 만나면 즉시 처리를 중단하고 오류를 보고한다.16 따라서 정형성은 모든 XML 처리 과정의 가장 기본적인 전제 조건이다.
‘유효(Valid)’한 XML 문서는 정형이라는 기본 조건을 만족하는 동시에, 한 단계 더 나아가 미리 정의된 스키마(Schema)의 규칙까지 준수하는 문서를 말한다.15 스키마는 특정 XML 문서가 가져야 할 구조적인 ‘설계도’ 또는 ‘문법서’와 같다. 스키마는 다음과 같은 규칙들을 정의한다 18:
title 요소는 반드시 하나만 있어야 하고, author 요소는 하나 이상 올 수 있다)price 속성은 숫자여야 한다)논리적으로 모든 유효한 문서는 반드시 정형이다. 하지만 모든 정형 문서가 유효한 것은 아니다. 유효성은 스키마라는 추가적인 계약을 만족해야만 얻을 수 있는 더 높은 수준의 품질 보증이다.16
이러한 정형성과 유효성의 구분은 단순한 기술적 구분이 아니라, XML의 핵심 설계 철학을 보여준다. 이는 데이터 품질을 보장하기 위한 2단계 시스템으로 작동한다. 1단계인 정형성은 최소한의 문법적 예측 가능성을 보장하여, 어떤 범용 XML 도구라도 문서를 일단 파싱할 수 있게 해준다. 2단계인 유효성은 특정 애플리케이션이나 시스템 간에 합의된 ‘계약’(스키마)에 따라 데이터의 의미적, 구조적 정확성을 보장한다. 이처럼 내장된 강력한 유효성 검사 기능이야말로, 외부 라이브러리에 의존해야 하는 JSON과 같은 형식에 비해 XML이 갖는 가장 큰 전략적 우위다.20
XML 문서의 유효성을 검사하기 위한 스키마를 정의하는 언어로는 대표적으로 DTD와 XML 스키마(XSD)가 있다.
DTD (Document Type Definition): XML 초창기부터 사용된 전통적인 스키마 정의 방식이다.18 XML 문서 상단에
<!DOCTYPE...> 선언을 통해 DTD를 명시하고, 이를 기준으로 유효성을 검사한다.13 하지만 DTD는 몇 가지 치명적인 단점을 가지고 있다. 첫째, DTD 자체의 문법이 XML이 아니어서 별도의 파싱 로직이 필요할 수 있다. 둘째, 데이터 타입을 정수, 날짜 등으로 세밀하게 정의하는 기능이 매우 빈약하다. 셋째, 태그 이름의 충돌을 방지하는 네임스페이스(Namespace)를 지원하지 않는다.15
XML 스키마 (XSD - XML Schema Definition): DTD의 한계를 극복하기 위해 W3C에서 새로 제정한 강력하고 현대적인 스키마 언어다.15 XSD는 다음과 같은 압도적인 장점을 가진다.
오늘날 대부분의 엔터프라이즈 환경에서는 DTD보다 월등한 기능과 유연성을 제공하는 XSD가 유효성 검증의 표준으로 사용되고 있으며, Xerces와 같은 주요 XML 파서들은 XSD 기반의 유효성 검사를 완벽하게 지원한다.15
XML은 단순히 데이터를 담는 그릇이 아니다. 그 데이터를 효과적으로 탐색하고, 변환하며, 질의하기 위한 강력한 기술 생태계를 함께 가지고 있다. XPath, XSLT, XQuery는 이 생태계의 삼총사라 할 수 있다.
XPath는 XML 문서 내의 특정 요소, 속성, 텍스트 노드 등 원하는 부분에 접근하고 선택하기 위한 경로 언어(Path Language)다.23 마치 파일 시스템에서 디렉터리 경로를 사용해 파일에 접근하듯, XPath는
/와 // 같은 경로 표현식을 사용해 XML의 계층 구조를 자유롭게 탐색한다.25 XPath는 그 자체로도 유용하지만, 주로 XSLT와 XQuery의 핵심 엔진으로 작동하며, 이들 언어가 XML 데이터에 접근하는 기반을 제공한다.22
주요 경로 표현식은 다음과 같다.
/로 경로를 구분한다. 예: /bookstore/book/title은 루트 요소인 bookstore 아래의 book 요소 아래의 title 요소를 선택한다.27//로 시작하며, 현재 위치에 상관없이 문서 내에서 특정 조건을 만족하는 모든 노드를 검색한다. 훨씬 유연하고 강력하다. 예: //title은 문서 어디에 있든 모든 title 요소를 선택한다.27@ 기호를 사용하여 특정 속성이나 속성값을 가진 요소를 선택한다. 예: //book[@category='COOKING']은 category 속성값이 ‘COOKING’인 모든 book 요소를 찾는다.29contains(), starts-with(), text() 등 다양한 내장 함수를 통해 더욱 정교한 조건의 노드를 선택할 수 있다. 예: //title[contains(text(), 'Java')]는 텍스트 내용에 ‘Java’를 포함하는 모든 title 요소를 선택한다.28ancestor(조상), descendant(자손), following-sibling(다음 형제), parent(부모) 등 현재 노드를 기준으로 다양한 관계에 있는 노드를 정밀하게 선택할 수 있는 고급 기능이다.27XSLT는 XML 문서를 전혀 다른 형태의 문서, 예를 들어 HTML, 다른 구조의 XML, 또는 일반 텍스트 파일로 변환(Transform)하기 위해 설계된 언어다.31 XSLT는 절차적 프로그래밍 언어와 달리, 선언적(declarative)이고 템플릿 기반(template-based)으로 동작한다.
XSLT의 처리 모델은 다음과 같은 핵심 요소로 구성된다.
<xsl:stylesheet>: 모든 XSLT 문서의 루트 요소.<xsl:template match="pattern">: 변환 규칙의 핵심. match 속성에는 XPath 표현식이 들어가며, 소스 XML에서 해당 패턴과 일치하는 노드를 발견했을 때 이 템플릿 안의 내용을 적용하여 결과를 생성한다.33<xsl:apply-templates>: 현재 처리 중인 노드의 자식 노드들로 이동하여, 그 자식 노드에 맞는 템플릿을 다시 찾아 재귀적으로 변환 과정을 계속하도록 지시한다. 이를 ‘Push’ 방식 처리라고 한다.31<xsl:value-of select="expression">: XPath 표현식으로 선택된 노드의 텍스트 값을 결과물에 출력한다.31<xsl:for-each select="expression">: 선택된 노드 집합을 순회하며 반복적으로 특정 작업을 수행한다. 이는 ‘Pull’ 방식 처리에 해당한다.33예를 들어, XML로 된 데이터 목록을 HTML 테이블로 변환하는 작업에 XSLT는 최적의 도구다.
XQuery는 이름에서 알 수 있듯 XML 데이터를 위한 질의 언어(Query Language)다.26 관계형 데이터베이스에 질의하기 위해 SQL을 사용하듯, XQuery는 방대한 XML 문서나 XML 데이터베이스에서 원하는 데이터를 효율적으로 추출하고 조작하기 위해 사용된다.35
XQuery의 심장은 FLWOR 표현식이다. 이는 SQL의 SELECT-FROM-WHERE 구문과 매우 유사한 구조를 가진다.22
For: 변수를 특정 노드 시퀀스(집합)에 바인딩하며 순회한다.Let: 변수에 특정 값을 할당한다.Where: 결과를 필터링할 조건을 지정한다.Order by: 결과를 특정 기준으로 정렬한다.Return: 위 과정을 거쳐 최종적으로 생성할 결과 XML의 형태를 정의하고 반환한다.XQuery는 단일 문서를 넘어 여러 XML 문서의 컬렉션을 대상으로 복잡한 조인, 필터링, 집계, 정렬 연산을 수행하는 데 매우 강력한 성능을 발휘한다.26
XML 문서를 프로그래밍 언어 내에서 처리(파싱)할 때는 크게 두 가지 API 모델, DOM과 SAX를 사용한다. 둘의 차이는 컴퓨터 과학의 근본적인 개념인 공간-시간 트레이드오프(space-time tradeoff)를 명확하게 보여준다.
OutOfMemoryError를 유발할 수 있다. 한 성능 테스트에 따르면, DOM은 SAX에 비해 약 5배에서 10배에 달하는 메모리를 사용한다.37이처럼 DOM은 메모리 공간(space)을 희생하여 처리 시간(time)과 개발 편의성을 얻는 전략이고, SAX는 처리 시간(더 복잡한 프로그래밍)과 유연성을 희생하여 메모리 공간을 아끼는 전략이다. 따라서 어떤 파서를 선택할지는 단순히 어떤 것이 더 좋고 나쁨의 문제가 아니라, 처리할 데이터의 크기와 애플리케이션의 요구사항을 분석하여 내리는 전략적인 아키텍처 결정에 해당한다.
| 구분 (Category) | DOM 파서 (DOM Parser) | SAX 파서 (SAX Parser) |
|---|---|---|
| 처리 방식 | 문서 전체를 메모리에 트리 구조로 로드 (Tree-based) | 문서를 순차적으로 읽으며 이벤트 발생 (Event-based, Streaming) |
| 메모리 사용량 | 매우 높음 (문서 크기의 약 10배) 37 | 매우 낮음 (문서 크기와 무관하게 일정) 39 |
| 처리 속도 | 작은 파일에서는 빠르나, 로딩 시간이 김 | 대용량 파일에서 월등히 빠름 |
| 데이터 접근 | 무작위 접근 가능 (Random Access) | 순방향 접근만 가능 (Forward-only) |
| 데이터 수정 | 용이함 (노드 추가, 삭제, 변경이 자유로움) | 매우 복잡하고 어려움 |
| 주요 장점 | 데이터 구조 변경 및 탐색이 편리함 | 메모리 효율성이 극도로 높음 |
| 주요 단점 | 대용량 파일 처리 시 메모리 부족 문제 발생 | 데이터 구조를 파악하고 상태를 직접 관리해야 함 |
| 추천 사용 사례 | 크기가 작고 구조 변경이 잦은 설정 파일 처리 | 대용량 로그 파일, 데이터 피드, 실시간 스트림 처리 |
현대 웹 개발, 특히 API 통신에서 XML은 강력한 경쟁자인 JSON과 자주 비교된다. 두 기술은 데이터 교환이라는 공통된 목적을 가졌지만, 철학과 구조, 장단점에서 뚜렷한 차이를 보인다. 어떤 상황에서 어떤 기술을 선택해야 하는지 판단하려면 이 차이점을 명확히 이해해야 한다.
키:값 쌍으로 이루어진 객체와 값들의 리스트인 배열을 기반으로 한다. 문법이 매우 간결하여 사람이 읽고 쓰기 편하며, 동일한 데이터를 표현하더라도 파일 크기가 훨씬 작아 네트워크 전송 효율이 높다.20주석 및 메타데이터: XML은 `` 구문을 통해 주석을 공식적으로 지원하며, 속성(attribute)을 이용해 데이터 자체와 분리된 메타데이터를 표현하기에 매우 용이하다. 반면, JSON은 표준 명세에 주석 기능이 없으며, 모든 정보는 키:값 쌍으로 표현되어야 한다.19
JSON.parse())를 통해 매우 빠르고 간단하게 파싱된다.20 반면 XML은 구조의 복잡성으로 인해 전용 파서가 필요하며, 일반적으로 파싱 과정이 JSON보다 더 많은 연산을 요구하여 상대적으로 느리다.20어떤 데이터 형식이 더 안전한지에 대한 논의는 종종 오해를 불러일으킨다. XML과 JSON 중 어느 하나가 본질적으로 더 안전하거나 위험한 것은 아니다. 각각의 보안 위협은 데이터 형식 자체가 아닌, 그 형식을 처리하는 파서의 특정 기능이나 잘못된 구현 방식에서 비롯된다.
XML 보안 위협: XXE (XML External Entity) Injection
XML의 가장 심각하고 잘 알려진 보안 취약점은 XXE 공격이다. 이는 XML 파서가 DTD(문서 유형 정의)나 외부 엔티티(external entity) 참조를 처리하도록 설정되어 있을 때 발생한다. 공격자는 악의적으로 조작된 XML을 전송하여 파서가 서버의 로컬 파일을 읽게 하거나, 내부 네트워크의 다른 시스템을 스캔하거나, 서비스 거부(DoS) 공격을 유발할 수 있다.44 따라서 XML 파서를 사용할 때는
DTD 처리와 외부 엔티티 로드를 명시적으로 비활성화하는 것이 가장 중요한 보안 수칙이다.43
JSON 보안 위협: Injection 및 Insecure Parsing
JSON은 구조가 단순하여 XXE와 같은 복잡한 기능에서 비롯된 취약점은 없다. 그러나 처리 방식에서 문제가 발생할 수 있다.
eval() 함수를 사용하는 경우가 있었다. 이는 치명적인 실수로, JSON 문자열에 악의적인 JavaScript 코드가 포함되어 있다면 그대로 실행되어 XSS(Cross-Site Scripting) 공격으로 이어질 수 있다. 항상 각 언어에서 제공하는 안전한 내장 파서(예: JavaScript의 JSON.parse())를 사용해야 한다.45결론적으로, 보안은 데이터 형식을 선택하는 문제가 아니라, 개발자가 각 형식의 특성을 이해하고 안전한 구현 관행을 따르는지에 달려있다. XML의 위험성은 강력한 레거시 기능에 있고, JSON의 위험성은 JavaScript와의 긴밀한 관계와 부주의한 처리 방식에 있다.
| 기준 (Criteria) | XML (eXtensible Markup Language) | JSON (JavaScript Object Notation) |
|---|---|---|
| 형식 (Format) | 태그 기반의 트리 구조 | 키-값 쌍(key-value pair) 기반의 맵과 배열 구조 |
| 구문 (Syntax) | 시작/종료 태그로 인해 장황함(verbose) | 간결하고 최소한의 문법 구조 |
| 가독성 (Readability) | 구조가 명확하지만 태그 때문에 복잡해 보일 수 있음 | 매우 높음, 사람이 읽고 쓰기 쉬움 |
| 파싱 (Parsing) | 전용 XML 파서 필요, 상대적으로 느림 | 대부분 언어에 내장된 함수로 파싱, 매우 빠름 |
| 스키마/유효성 검사 | DTD, XSD를 통해 강력하고 내장된 유효성 검사 지원 | 스키마가 내장되어 있지 않음 (JSON Schema 등 외부 도구 필요) |
| 데이터 타입 | XSD를 통해 매우 풍부하고 사용자 정의된 타입 지원 | 숫자, 문자열, 불리언, 배열, 객체 등 제한된 기본 타입 지원 |
| 네임스페이스 | 지원함 (태그 이름 충돌 방지) | 지원하지 않음 |
| 주석 (Comments) | 공식적으로 지원함 (``) | 공식적으로 지원하지 않음 |
| 보안 취약점 | XXE(XML External Entity) Injection | Insecure Parsing(eval), JSON Injection, CSRF(JSONP 사용 시) |
| 주요 사용 사례 | 복잡한 문서, 설정 파일, 데이터 무결성이 중요한 B2B/정부 데이터 교환 | 웹 API, 모바일 앱, 경량 데이터 교환, 실시간 통신 |
JSON이 웹의 새로운 표준으로 떠오른 지금, XML은 과연 과거의 유물이 되어가고 있는가? 답은 ‘아니오’다. XML은 범용 데이터 교환의 왕좌를 내주었을지 몰라도, 특정 전문 분야에서는 그 누구도 대체할 수 없는 독보적인 위치를 차지하며 여전히 활발하게 사용되고 진화하고 있다.
XML은 우리 주변의 수많은 핵심 기술과 시스템의 근간을 이루고 있다.
pom.xml, Spring 프레임워크의 설정 파일, 그리고 수백만 개발자가 사용하는 안드로이드 애플리케이션의 AndroidManifest.xml과 UI 레이아웃 파일은 모두 XML을 표준으로 사용한다.46XML의 미래는 소멸이 아닌 전문화(Specialization)의 길을 걷고 있다. 범용 데이터 교환이라는 역할은 JSON에 넘겨주었지만, 특정 고부가가치 문제 영역에서는 오히려 그 입지를 더욱 공고히 하고 있다.
이러한 전망을 뒷받침하는 가장 강력한 증거는 주요 기관들의 지속적인 투자다. 단순히 기존 레거시 시스템을 유지하는 수준을 넘어, 2025년 이후에 적용될 새로운 XML 스키마가 지금도 활발하게 개발되고 있다는 사실은 XML의 장기적인 생명력을 증명한다. 예를 들어, 미국 재무부는 2025년 5월 이후 적용될 새로운 국채 매입 XML 형식을 발표했고 54, 국세청은 2025년 세금 보고를 위한 신규 XML 스키마를 제공하고 있으며 55, 교육부는 2025-26 학자금 지원을 위한 COD Common Record XML 스키마 버전 5.0c를 발표했다.57 이는 법규 준수와 데이터 무결성이 핵심인 영역에서 XML이 여전히 신뢰받는 표준 기술임을 명백히 보여준다.
따라서 XML의 미래는 다음과 같이 요약할 수 있다.
결론적으로, “XML vs. JSON”은 더 이상 어느 한쪽을 선택해야 하는 제로섬 게임이 아니다. 현대 개발자에게 필요한 역량은 두 기술의 철학과 장단점을 모두 깊이 이해하고, 당면한 문제의 성격에 따라 가장 적합한 도구를 선택하는 능력이다.
XML은 죽지 않았다. 단지 더 중요하고 복잡한 문제들을 해결하기 위해, 화려한 무대 위에서 조용한 무대 뒤로 자리를 옮겼을 뿐이다.
| How To Use XPath in Selenium: Complete Guide With Examples | LambdaTest, accessed July 27, 2025, https://www.lambdatest.com/blog/complete-guide-for-using-xpath-in-selenium-with-examples/ |
| JSON Vs. XML for Web APIs: The Format Showdown | Zuplo Blog, accessed July 27, 2025, https://zuplo.com/blog/2025/04/30/json-vs-xml-for-web-apis |
| XML vs. JSON: A Security Perspective | by David Petty, accessed July 27, 2025, https://blog.securityevaluators.com/xml-vs-json-security-risks-22e5320cf529 |
| Vector drawables overview | Views - Android Developers, accessed July 27, 2025, https://developer.android.com/develop/ui/views/graphics/vector-drawable-resources |
| Tax year 2025 valid XML schemas and business rules for Form 2290 Modernized e-File (MeF) | Internal Revenue Service, accessed July 27, 2025, https://www.irs.gov/tax-professionals/tax-year-2025-valid-xml-schemas-and-business-rules-for-form-2290-modernized-e-file-mef |
| XML Extract | Grants.gov, accessed July 27, 2025, https://www.grants.gov/xml-extract |
| COD Common Record XML Schema Version 5.0c Now Available | Knowledge Center, accessed July 27, 2025, https://fsapartners.ed.gov/knowledge-center/library/electronic-announcements/2024-10-25/cod-common-record-xml-schema-version-50c-now-available |