XML 포맷

XML(확장 가능한 마크업 언어)은 25년 이상 존재해왔지만, 여전히 현대 소프트웨어의 인프라에 깊이 통합되어 있습니다: Office 문서와 Android 레이아웃부터 SOAP API, RSS 피드, 설정 파일, 디지털 보존 워크플로우까지. 더 이상 인기 있는 것은 아닙니다—그 왕관은 JSON에게 넘어갔습니다—하지만 XML은 엄격한 구조, 풍부한 메타데이터, 장기적인 상호 운용성이 중요한 곳에서 여전히 중요합니다. 이 글의 목표는 XML을 철저히 설명하는 것입니다: 그 기원, 작동 방식, 처리 및 검증 방법, 새로운 형식과의 비교, 그리고 2025년 및 그 이후에 안전하고 효과적으로 사용하는 방법.

1. XML이 실제로 무엇인가

XML은 중첩된 요소와 속성을 사용하여 구조화된 데이터와 문서를 표현하기 위한 간소화된 마크업 언어입니다. World Wide Web Consortium의 확장 가능한 마크업 언어 (XML) 1.0 권고 에 의해 정의되며, 이는 올바른 형식의 XML 문서에 대한 구문을 지정하고 프로세서가 이를 어떻게 처리해야 하는지 설명합니다.

XML 사양은 XML을 SGML(표준 일반화 마크업 언어)의 제한된 하위 집합으로 설명하며, 명시적 마크업으로 구조화된 텍스트를 표현하는 SGML의 핵심 기능을 유지하면서 구현을 더 간단하게 설계되었습니다.

일부 주요 속성이 XML을 특징짓습니다:

• 텍스트 기반 및 Unicode 인식. XML 문서는 일반 텍스트이며 Unicode/ISO 10646 문자 집합에 의존하여 이식 가능하고 언어 독립적으로 만듭니다.
• 자기 설명적. 태그 이름과 속성은 의미를 전달합니다. 구조를 기본적으로 이해하기 위해 별도의 스키마가 필요하지 않습니다(스키마가 훨씬 더 강력하게 만들지만).
• 계층적. XML의 트리 구조는 중첩된 데이터, 문서 및 구성 계층에 직접 매핑됩니다.
• 확장 가능. 자신만의 태그와 어휘를 발명할 수 있습니다; XML 자체는 허용된 요소 집합을 고정하지 않습니다.

2. 간단한 역사: SGML에서 XML로, 그리고 현대 웹으로

XML의 뿌리는 1980년대 ISO 표준인 SGML에 있으며, 출판 및 기술 문서에서 광범위하게 사용되었습니다. 1990년대 중반까지 웹의 HTML(자체가 SGML 기반이었음)은 어디에나 있었지만 너무 제한적이고 프레젠테이션과 밀접하게 결합되어 있었습니다.

1996–1997년경, Jon Bosak, Tim Bray, C. M. Sperberg-McQueen, James Clark 등을 포함한 작업 그룹이 쉽고 안정적으로 구문 분석할 수 있는 더 간단하고 웹 친화적인 SGML 하위 집합을 설계하기 시작했습니다. 첫 번째 XML 1.0 권고는 1998년에 발표되었으며, XML은 SOAP, WSDL, SVG, XSLT 및 수많은 업계별 어휘를 포함하여 많은 초기 웹 표준 및 프로토콜의 기반이 되었습니다.

나중에 XML 1.1은 문자 처리 및 제어 문자에 대한 일부 엣지 케이스를 개선했지만, XML 1.0은 실제로 여전히 지배적인 변형입니다.

3. 핵심 XML 구문: 올바른 형식의 문서

XML 1.0 사양은 올바른 형식의 문서에 대한 정확한 구문을 정의합니다. 최소한 올바른 형식의 XML 문서는:

• 정확히 하나의 루트 요소를 가집니다.
• 일치하는 시작 및 종료 태그를 사용합니다.
• 요소를 적절하게 중첩합니다(겹치는 태그 없음).
• 속성 값에 따옴표를 사용합니다.
• 합법적인 문자 및 인코딩을 사용합니다.

작지만 유효한 문서는 다음과 같을 수 있습니다:

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>George</to>
  <from>Adam</from>
  <message>Hello XML!</message>
</note>

XML 선언은 선택 사항이지만 버전과 문자 인코딩을 명시하는 일반적인 방법입니다. 문서 요소 <note> 는 단일 루트입니다. 텍스트 노드, 요소, 속성, 주석, 처리 지시문 및 엔티티 참조가 함께 사양에 설명된 트리 구조를 형성합니다.

XML은 또한 올바른 형식과 유효한 문서를 구분합니다:

• 올바른 형식의 문서는 구문 규칙을 따릅니다.
• 유효한 문서는 추가로 구조와 내용을 제한하는 DTD 또는 스키마를 준수합니다.

4. 네임스페이스: 어휘를 안전하게 혼합

XML 어휘가 증가함에 따라 이름 충돌이 문제가 되었습니다: 하나의 어휘는 책 제목에 <title> 를 사용할 수 있습니다; 다른 어휘는 직함에 사용합니다. 충돌을 피하기 위해 XML은 네임스페이스를 도입했습니다. 이는 W3C 권고 XML의 네임스페이스 에 정의되어 있습니다.

예를 들어:

<book xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>XML in Depth</dc:title>
</book>

여기서 dc:title 은 dc 접두사를 더블린 코어 네임스페이스 URI에 바인딩하여 다른 <title> 요소와 안전하게 구별됩니다. 네임스페이스는 현대 XML 생태계에서 중요합니다: XSD, XSLT, SOAP, RSS 및 Office Open XML이 모두 이를 크게 의존합니다.

5. 검증: DTD, XML Schema 등

5.1 DTD

원본 XML 사양에는 문서의 허용된 구조—허용된 요소, 속성, 엔티티 등—를 정의하는 표준 방법으로 문서 유형 정의 (DTD) 가 포함되어 있었습니다. DTD는 컴팩트하고 XML 프롤로그에 잘 통합되어 있지만 제한이 있습니다: 비XML 구문을 사용하고, 약한 타이핑을 가지며, 네임스페이스에서 어려움을 겪습니다.

5.2 XML Schema (XSD)

DTD 제한을 해결하기 위해 W3C는 XML Schema Definition (XSD)를 표준화했습니다. 현재 버전 1.1이며 XML Schema Definition Language (XSD) 1.1 Part 1: Structures 에 있습니다. XSD 자체는 XML로 작성되며, 네임스페이스를 지원하고, 풍부한 타이핑(문자열, 숫자, 날짜, 목록, 유니온), 발생 제약 조건 및 복잡한 내용 모델을 제공합니다.

RELAX NG 및 Schematron과 같은 다른 스키마 언어가 존재하지만, XSD는 많은 엔터프라이즈 및 표준 중심 환경에서 사실상의 표준으로 남아 있습니다.

5.3 검증이 중요한 이유

검증은 XML을 구조화된 텍스트에서 시스템 간 계약으로 변환합니다. 예를 들어:

• 금융 메시징 사양은 결제 지시에 대한 엄격한 스키마를 정의합니다.
• Office Open XML 및 RSS와 같은 표준은 스키마로 문서 형식을 공식화합니다.
• 빌드 및 구성 도구는 pom.xml 또는 web.config 와 같은 파일을 검증하여 오류를 조기에 발견합니다.

6. XML 처리: DOM, SAX 및 스트리밍

XML 자체는 단순히 텍스트입니다. 유용한 작업을 수행하려면 소프트웨어가 이를 어떤 모델로 구문 분석해야 합니다. 두 가지 고전적인 처리 모델은 DOM 및 SAX입니다.

6.1 DOM: 메모리 내 트리

W3C의 DOM Level 3 Core 사양 은 요소, 속성, 텍스트, 주석 등의 노드를 가진 전체 문서 트리를 나타내는 언어 중립적 객체 모델을 정의합니다. DOM은 랜덤 액세스에 친화적이고 추론하기 쉬우며 라이브러리에서 광범위하게 지원되지만, 전체 문서를 메모리에 보관해야 합니다.

6.2 SAX: 이벤트 기반 스트리밍

Simple API for XML (SAX) 는 XML을 스트림으로 구문 분석하고 "요소 시작" 또는 "요소 종료"와 같은 이벤트에 대한 콜백을 발생시키는 이벤트 기반 API입니다. SAX 프로젝트 사이트 및 Oracle SAX 자습서 에 설명되어 있습니다.

SAX는 전체 트리를 저장하지 않고 단일 패스로 문서를 처리하므로 메모리 효율이 극도로 높으며 로그, 메시지 처리 또는 배치 변환과 같은 대규모 스트림에 이상적입니다. StAX와 같은 풀 기반 스트리밍 API는 유사한 원칙을 따릅니다.

7. XPath, XSLT 및 XQuery: XML 쿼리 및 변환

7.1 XPath

XPath 는 /bookstore/book[1]/title과 같은 경로와 유사한 표현식을 사용하여 XML 문서의 부분을 주소 지정하는 컴팩트한 쿼리 언어입니다. XPath 3.1 에 정의된 최신 버전은 맵과 배열을 통해 JSON 데이터도 처리하도록 모델을 확장하며, 대량의 표준 함수로 지원됩니다.

XPath는 많은 도구에 내장되어 있습니다: XSLT, XQuery, XML Schema 어설션 및 인기 있는 프로그래밍 언어의 API.

7.2 XSLT

XSL Transformations (XSLT) 는 XML을 다른 형식—XML, HTML, 텍스트 또는 최신 프로세서에서는 JSON—으로 변환하기 위한 선언적 언어입니다. W3C의 XSLT 3.0 권고 는 패턴 일치 및 선택을 위해 XPath에 의존하는 템플릿 기반 시스템을 정의합니다.

스타일시트 자체는 XSLT 네임스페이스를 사용하는 XML 문서입니다. XSLT 3.0은 거대한 문서에 대한 스트리밍 기능과 JSON 및 맵과의 향상된 통합을 추가합니다.

7.3 XQuery

XQuery 는 XML 저장소를 위한 전체 쿼리 언어로 XQuery 3.1 에 정의되어 있습니다. 네이티브 XML 데이터베이스 또는 문서 저장소에 저장되는 경우가 많은 XML 데이터 컬렉션을 쿼리 및 변환하도록 설계되었으며, FLWOR 표현식(for, let, where, order by, return)을 사용하여 강력한 결과 집합을 생성합니다.

XPath, XSLT 및 XQuery는 함께 특히 출판, 디지털 인문학, 전자 정부 및 데이터 통합 컨텍스트에서 대규모로 XML 작업을 위한 풍부한 도구 키트를 형성합니다.

8. 오늘날 XML의 실제 사용

JSON이 웹 API를 지배하고 있지만, XML은 여전히 많은 시스템 및 표준에 깊이 통합되어 있습니다.

8.1 문서 형식 및 표준

• Office Open XML (OOXML). 현대 Microsoft Office 문서(.docx, .xlsx, .pptx)는 ECMA-376 Office Open XML 및 관련 ISO 표준에 의해 정의된 XML 파일의 ZIP 패키지입니다.
• 디지털 보존. 의회 도서관과 같은 기관은 XML(특히 XML 1.0)을 구조화된 디지털 콘텐츠를 표현하기 위한 안정적이고 보존 친화적인 형식으로 취급합니다.
• 학술 및 기술 마크업. TEI, DocBook 및 기타 도메인별 어휘는 XML 기반이며 의미론적 마크업 및 장기 아카이빙을 가능하게 합니다.

8.2 메시징 및 웹 서비스

• SOAP. W3C의 SOAP 1.2 사양은 HTTP와 같은 프로토콜을 통해 구조화된 메시지를 교환하기 위한 XML 기반 봉투를 정의합니다.
• RSS 및 신디케이션. RSS 2.0 사양 은 피드 신디케이션을 위한 XML 형식을 정의하며, 여전히 블로그, 뉴스 및 제품 피드에 광범위하게 사용됩니다.

8.3 구성 및 빌드 시스템

• Maven POM. Apache Maven의 프로젝트 객체 모델(pom.xml)은 프로젝트 메타데이터, 종속성, 플러그인 및 빌드 구성을 설명하는 XML 파일로 POM 참조 및 POM 소개 에 문서화되어 있습니다.
• Spring Framework XML 구성. 전통적인 Spring 앱은 종종 applicationContext.xml 또는 beans.xml 파일에서 빈과 배선을 정의하며, 이 접근 방식은 Spring 참조 문서 및 Java Guides 와 같은 자습서에 설명되어 있습니다.
• .NET 구성. ASP.NET 및 WCF는 XML 형식의 web.config 및 app.config 파일에 의존하여 엔드포인트, 바인딩 및 동작을 구성하며, Microsoft의 web.config 문서 및 WCF 구성 가이드 에 설명되어 있습니다.

더 일반적으로, 검증 및 도구가 중요한 경우, 특히 XSD 지원 스키마를 사용할 때 XML은 일반적인 구성 형식으로 남아 있습니다.

8.4 모바일 및 UI 레이아웃

Android에서 UI 레이아웃은 일반적으로 res/layout 아래의 XML 파일에서 선언됩니다. Google의 문서는 Android의 XML 어휘를 사용하여 레이아웃을 작성하고 HTML과 매우 유사하게 뷰를 중첩하며, 각 레이아웃 파일에 단일 루트 요소가 포함되어 있음을 설명합니다.

9. XML vs JSON vs YAML

2025년까지 JSON은 웹 API의 인기 경쟁에서 명확히 승리했습니다: 최근 비교 기사는 JSON이 웹 API 응답의 약 87%, XML이 9%, YAML이 4%로 추정합니다.

9.1 XML의 강점

JSON 및 YAML과 비교하여 XML은 다음이 필요할 때 빛을 발합니다:

• 풍부한 스키마 및 강력한 검증. XSD를 사용하면 복잡한 유형, 제약 조건 및 관계를 지정할 수 있으며, 성숙한 도구 및 검증기 생태계를 가지고 있습니다.
• 혼합 콘텐츠 및 문서. XML은 마크업과 텍스트가 교차하는 텍스트 중심 문서를 위해 구축되었습니다; JSON 및 YAML은 순수하게 구조화된 데이터에 더 적합합니다.
• 깊은 메타데이터 및 확장성. 네임스페이스와 스키마를 사용하면 선택적 요소와 속성을 추가할 수 있는 버전 허용 문서가 가능하며, 이전 소비자를 깨뜨리지 않습니다.

9.2 JSON 및 YAML의 강점

JSON은 읽고 쓰기가 더 간단하고, JavaScript 객체에 자연스럽게 매핑되며, 전송 시 더 작습니다. 자습서는 JSON이 종료 태그를 생략하고, 더 간결하며, 전용 XML 파서 없이 브라우저에서 기본적으로 구문 분석할 수 있음을 자주 지적합니다.

YAML은 구성에 대한 인간 가독성을 강조하며 Kubernetes 및 Ansible과 같은 DevOps 도구에서 인기가 있지만, 복잡성과 들여쓰기 민감도로 인해 오류가 발생할 수 있습니다.

9.3 올바른 형식 선택

현대적인 지침은 다음과 같은 경향이 있습니다:

• 대부분의 웹 API 및 클라이언트-서버 통신에는 JSON을 사용합니다.
• 클라우드/DevOps 환경에서 개발자 중심 구성에는 YAML을 사용합니다.
• 스키마 기반 문서, 혼합 콘텐츠, 기존 XML 생태계(SOAP, OOXML, WCF, Android 레이아웃) 또는 표준화 및 도구가 성숙한 장기 아카이빙이 필요한 경우 XML을 사용합니다.

10. 보안: XXE 및 기타 XML 함정

XML의 유연성은 특히 외부 엔티티 및 DTD 주변에서 날카로운 가장자리를 동반합니다. OWASP의 XML External Entity (XXE) 방지 치트 시트 는 XXE 취약점이 공격자가 로컬 파일을 읽고, 서버 측 요청 위조를 수행하거나, 엔티티 확장을 악용하여 서비스 거부를 유발할 수 있는 방법을 문서화합니다.

일반적인 공격 벡터에는 다음이 포함됩니다:

• 로컬 또는 원격 리소스를 참조하는 외부 엔티티.
• 거대한 페이로드로 확장되는 DTD의 매개변수 엔티티.
• 신뢰할 수 없는 네트워크를 통한 DTD 검색.

완화 지침은 일반적으로 다음을 권장합니다:

• 가능한 한 파서에서 DTD 및 외부 엔티티를 비활성화합니다.
• OWASP 권장 사항을 따르는 강화된 파서 설정 또는 안전한 라이브러리를 사용합니다.
• 위험한 기능을 활성화하지 않고 스키마에 대해 검증합니다.

기타 보안 고려 사항에는 과도하게 큰 문서(리소스 고갈), 사용자 입력에서 쿼리를 구축하는 시스템의 XPath/XQuery 주입, 권한 상승 또는 코드 실행으로 이어지는 잘못 구성된 XML 기반 구성 파일이 포함됩니다.

11. XML의 디자인 및 모범 사례

신중하게 사용하면 XML은 데이터와 문서를 모델링하는 깨끗하고 견고한 방법으로 남아 있습니다. 일부 실용적인 지침:

• 명확한 트리를 모델링합니다. 관계형 스키마를 직접 반영하는 대신 안정적인 개념 트리(예: <invoice> → <lineItems> → <lineItem>)를 중심으로 XML을 설계합니다.
• 요소와 속성을 의도적으로 선택합니다. 주요 콘텐츠 및 구조에는 요소를 사용합니다; 메타데이터 및 플래그에는 속성을 사용합니다.
• 처음부터 네임스페이스를 사용합니다. 작은 어휘의 경우에도 네임스페이스를 할당하면(예: xmlns="https://example.com/ns/invoice") 나중에 고통스러운 마이그레이션을 피할 수 있습니다.
• 스키마로 형식을 지원합니다. XSD(또는 다른 스키마 언어)를 제공하고 이를 공개 계약의 일부로 취급합니다. CI 및 통합 지점에서 스키마 검증을 사용합니다.
• 인간이 검사할 수 있도록 유지합니다. 예쁜 인쇄 및 주석은 디버깅, 구성 및 장기 유지 관리에 도움이 됩니다.
• 데이터와 프레젠테이션을 분리합니다. XML을 구조와 의미에 사용하고 XSLT 또는 기타 도구로 HTML, PDF 또는 기타 형식으로 변환합니다.
• 적절한 처리 모델을 선택합니다. 소규모 및 중규모 문서와 복잡한 쿼리의 경우 DOM + XPath/XSLT가 이상적일 수 있습니다; 매우 큰 스트림 또는 제한된 환경의 경우 SAX, StAX 또는 이벤트 기반 처리를 사용합니다.
• 파서를 강화합니다. 신뢰할 수 없는 입력을 구문 분석할 때 OWASP XXE 방지 지침 및 언어의 보안 모범 사례를 따릅니다.

12. XML의 미래 역할

일상적인 웹 개발에서 XML은 대부분 JSON 및 YAML에 중심 무대를 양보했습니다. 하지만 많은 도메인—엔터프라이즈 통합, 문서 표준, 구성 관리, 디지털 보존 및 레거시 시스템—에서 모든 것을 새로운 형식으로 다시 작성하는 것은 실행 불가능하거나 바람직하지 않습니다.

W3C 및 Ecma와 같은 표준 기관은 여전히 XML 1.x, XML Schema, XPath, XSLT, XQuery, SOAP 및 OOXML과 같은 XML 기반 사양을 유지하고 있으며, 의회 도서관과 같은 기관은 XML을 아카이브 작업마로 계속 취급합니다.

개발자에게 이것은 Office 파일, Android 레이아웃, 많은 Java 엔터프라이즈 스택, .NET 구성, 오래된 SOAP/WSDL 서비스 또는 표준 기반 데이터 교환을 다룰 때마다 XML과 상호 작용할 가능성이 높다는 것을 의미합니다. XML의 구문, 네임스페이스, 스키마 및 처리 모델을 이해하는 것은 특히 통합, 인프라 또는 장기 시스템에서 작업하는 경우 여전히 귀중한 기술입니다.

XML은 더 이상 현대 웹 API의 스타가 아닐 수 있지만, 여전히 엄청난 양의 소프트웨어를 위한 견고하고 잘 지정되며 강력하게 도구화된 기반입니다. 강력한 스키마, 풍부한 문서 또는 기존 XML 기반 표준의 광대한 풍경을 탐색해야 할 때마다 깊이 배우는 것이 보상됩니다.