XML

XML 문서의 기본 구성 단위는 요소와 속성이다. 요소는 문서의 구조와 내용을 정의하고, 속성은 요소에 대한 추가 정보를 제공한다.

요소는 시작 태그와 종료 태그, 그리고 그 사이의 내용으로 구성된다. 시작 태그는 <요소이름> 형태이고, 종료 태그는 </요소이름> 형태이다. 태그 사이의 내용은 텍스트 데이터나 다른 요소가 될 수 있다. 내용이 없는 요소는 <빈요소/>와 같이 단일 태그로 표현할 수 있다[1]. 모든 XML 문서는 반드시 하나의 루트 요소를 가져야 하며, 다른 모든 요소는 이 루트 요소 내에 중첩되어야 한다.

속성은 시작 태그 내에서 이름="값"의 형태로 사용된다. 속성 값은 반드시 작은따옴표나 큰따옴표로 묶어야 한다. 하나의 요소는 여러 개의 속성을 가질 수 있지만, 동일한 이름의 속성을 두 번 이상 정의할 수는 없다. 속성은 주로 요소의 메타데이터나 요소의 특성을 설명하는 데 사용된다. 예를 들어, <책 ISBN="12345">에서 ISBN은 속성 이름이고 "12345"는 속성 값이다.

요소와 속성의 사용은 어느 정도 선택의 여지가 있다. 같은 정보를 요소의 내용으로 표현할 수도 있고, 속성으로 표현할 수도 있다. 일반적으로 데이터 자체는 요소로, 데이터에 대한 설명이나 메타데이터는 속성으로 정의하는 것이 관례이다.

DTD(Document Type Definition)는 XML 문서의 구조와 내용을 정의하는 가장 오래된 방법이다. DTD는 문서에 허용되는 요소, 속성, 그리고 그들 간의 계층 관계를 선언한다. DTD는 SGML에서 유래했으며, 비교적 간단한 문법을 가지고 있어 빠르게 문서 구조를 정의할 수 있다는 장점이 있다. 그러나 DTD는 자체적인 문법을 사용하며, 데이터 타입을 세밀하게 정의하는 데 한계가 있고, 네임스페이스를 지원하지 않는다는 단점이 있다.

이러한 DTD의 한계를 극복하기 위해 등장한 것이 XML 스키마(XML Schema, XSD)이다. XML 스키마는 XML 문서의 구조를 정의하는 데 사용되는 W3C 권고 표준으로, DTD보다 훨씬 풍부하고 강력한 기능을 제공한다. 가장 큰 차이점은 XML 스키마 자체가 XML 문법으로 작성된다는 점이다. 이로 인해 기존의 XML 도구들을 스키마 처리에도 활용할 수 있다.

XML 스키마는 DTD에 비해 다음과 같은 주요 이점을 제공한다.

• 풍부한 데이터 타입 지원: 문자열, 숫자, 날짜, 시간 등 다양한 기본 데이터 타입과 사용자 정의 복합 타입을 지원한다.

• 네임스페이스 지원: 명시적으로 네임스페이스를 사용하여 요소와 속성을 구분할 수 있다.

• 세밀한 제약 조건 정의: 요소의 발생 횟수(최소, 최대), 값의 범위, 문자열 패턴(정규 표현식) 등을 정확히 정의할 수 있다.

다음은 DTD와 XML 스키마의 주요 차이점을 비교한 표이다.

실무에서는 데이터 구조의 정확성과 유효성 검사가 중요한 복잡한 시스템, 특히 웹 서비스나 금융 데이터 교환과 같은 분야에서 XML 스키마가 널리 사용된다. 반면, 구조가 단순한 문서나 레거시 시스템에서는 여전히 DTD가 사용되기도 한다.

네임스페이스는 서로 다른 XML 어휘나 스키마에서 정의된 요소와 속성의 이름이 충돌하는 것을 방지하기 위한 메커니즘이다. 예를 들어, "title"이라는 요소가 한 문서 안에서 책의 제목과 직위를 동시에 나타내야 할 경우, 네임스페이스를 사용하여 각각을 구분할 수 있다. 이를 위해 URI(Uniform Resource Identifier)를 식별자로 사용하며, 주로 URL 형식이 채택된다. 네임스페이스 선언은 문서의 루트 요소나 특정 요소 내에서 xmlns 접두사를 사용하여 이루어진다.

네임스페이스는 접두사와 실제 네임스페이스 URI를 연결하여 사용한다. 기본 네임스페이스는 접두사 없이 선언할 수 있으며, 해당 범위 내의 모든 요소에 적용된다. 특정 접두사를 가진 네임스페이스는 요소나 속성 이름 앞에 콜론(:)과 함께 붙여 사용한다. 이를 통해 동일한 로컬 이름을 가진 요소라도 서로 다른 네임스페이스에 속하면 완전히 다른 것으로 인식된다.

네임스페이스는 XML 스키마, XSLT, XPath 등 다른 XML 관련 기술과 함께 사용될 때 그 중요성이 더욱 부각된다. 특히 복잡한 문서에서 여러 벤더나 표준 기관에서 정의한 XML 어휘를 혼합하여 사용할 때 필수적이다. 네임스페이스의 올바른 사용은 문서의 명확성과 상호 운용성을 보장하는 핵심 요소이다.

XPath는 XML 문서 내의 특정 부분을 찾고 선택하기 위한 쿼리 언어이다. XPath는 트리 구조로 표현된 XML 문서에서 노드를 탐색하기 위한 경로 표현식을 사용한다. 이 표현식은 계층 구조를 따라 특정 요소, 속성, 텍스트 노드 등을 정확히 가리킬 수 있다. XPath는 단독으로 사용되기도 하지만, 주로 XSLT 변환이나 XQuery에서 데이터를 선택하는 핵심 도구로 활용된다.

XQuery는 XML 데이터를 쿼리하기 위한 강력한 함수형 프로그래밍 언어이다. 관계형 데이터베이스에 SQL이 있다면, XML 데이터베이스나 XML 문서 모음에는 XQuery가 해당한다. XQuery는 XPath 표현식을 기반으로 구축되어 복잡한 데이터 추출, 변환 및 반환을 수행할 수 있다. FLWOR(For, Let, Where, Order by, Return) 표현식은 XQuery의 핵심 구문으로, 데이터를 반복 처리하고 필터링하며 정렬된 결과를 생성하는 데 사용된다.

두 기술의 주요 차이점과 관계는 다음 표와 같다.

XPath와 XQuery는 XML 데이터베이스, 웹 서비스, 문서 처리 시스템 등에서 복잡한 XML 데이터를 효율적으로 조작하는 데 필수적이다. 특히 대규모 XML 문서 저장소에서 정보를 검색하고 보고서를 생성할 때 XQuery의 능력이 빛을 발한다.

XSLT(Extensible Stylesheet Language Transformations)는 XML 문서를 다른 형식의 문서로 변환하기 위한 W3C 표준 언어이다. 주로 XML 데이터를 HTML이나 XHTML, 다른 XML 구조, 일반 텍스트 등으로 변환하는 데 사용된다. XSLT는 XPath를 사용하여 원본 XML 문서의 특정 부분을 선택하고, 템플릿 기반 규칙을 적용하여 출력 문서를 생성한다.

XSLT 변환의 핵심은 소스 문서의 노드와 일치하는 템플릿 규칙을 정의하는 것이다. 처리기는 소스 트리의 노드를 순회하며, 해당 노드와 일치하는 가장 구체적인 템플릿을 찾아 그 내용을 실행한다. 템플릿 내에서는 새로운 요소를 생성하거나, 값을 삽입하고, 조건부 처리나 반복 처리를 위한 제어 구조를 사용할 수 있다. 일반적인 변환 과정은 다음과 같다.

1. XML 소스 문서와 XSLT 스타일시트 문서를 입력으로 받는다.

2. XSLT 프로세서가 소스 문서를 파싱하여 트리 모델을 생성한다.

3. 프로세서는 스타일시트의 규칙에 따라 소스 트리를 처리하고 결과 트리를 생성한다.

4. 결과 트리는 최종적으로 HTML, XML, 텍스트 등의 형식으로 직렬화되어 출력된다.

XSLT는 데이터 표현과 내용을 분리하는 데 유용하며, 특히 동일한 XML 데이터를 웹 페이지(HTML), PDF, 다른 XML 포맷 등 여러 형태로 게시해야 할 때 널리 활용된다. 예를 들어, 카탈로그 데이터를 담은 XML 파일 하나를 가지고 웹용 HTML 페이지와 모바일용 경량 HTML, 그리고 인쇄용 PDF 생성을 위한 중간 형식을 모두 하나의 XSLT 스타일시트나 각각의 스타일시트를 통해 생성할 수 있다. XSLT 1.0은 1999년, 보다 강력한 기능을 제공하는 XSLT 2.0은 2007년에 표준으로 제정되었다.

XML 파서는 XML 문서를 읽고 그 구조와 내용을 해석하여 응용 프로그램이 사용할 수 있는 형태로 제공하는 소프트웨어 구성 요소 또는 라이브러리이다. 파서는 문서가 XML 문법을 올바르게 따르는지 검증하는 역할을 수행하며, 일반적으로 트리 구조나 이벤트 스트림 형태로 데이터를 애플리케이션에 전달한다.

주요 파서 유형은 다음과 같다.

파서는 또한 문서의 유효성을 검사하는지에 따라 구분된다. 비검증 파서는 문서가 형식 올바름인지만 확인하는 반면, 검증 파서는 문서가 참조하는 DTD나 XML 스키마에 정의된 규칙을 준수하는지, 즉 유효함을 추가로 검사한다. 검증 파서는 데이터의 정확성이 중요한 금융 거래나 의료 정보 교환과 같은 분야에서 필수적으로 사용된다.

대부분의 현대 프로그래밍 언어는 자체 XML 파서 라이브러리를 제공한다. 예를 들어, 자바에는 JAXP, 파이썬에는 xml.etree.ElementTree, C#에는 System.Xml 네임스페이스가 있다. 이러한 파서들은 애플리케이션이 구성 파일을 읽거나, 웹 서비스 메시지를 처리하거나, 다양한 시스템 간에 구조화된 데이터를 교환하는 데 핵심적인 역할을 한다.

XML은 웹 서비스 구현의 핵심 데이터 형식으로 널리 사용된다. 웹 서비스는 네트워크를 통해 서로 다른 시스템 간에 데이터 교환과 기능 호출을 가능하게 하는 기술이다. XML 기반 웹 서비스는 주로 SOAP 프로토콜을 사용하며, REST 아키텍처 스타일에서도 데이터 표현 형식으로 자주 활용된다.

SOAP는 XML을 메시지 포맷으로 사용하는 프로토콜이다. SOAP 메시지는 필수적인 Envelope 요소와 선택적인 Header, 필수적인 Body 요소로 구성된다. 이 메시지는 일반적으로 HTTP, SMTP 같은 전송 프로토콜 위에서 동작하며, WSDL이라는 XML 기반 언어로 서비스 인터페이스를 기술한다. SOAP는 보안, 트랜잭션, 신뢰성 메시징 등 엔터프라이즈 수준의 표준을 지원하는 것이 특징이다.

반면, REST는 프로토콜이 아닌 아키텍처 스타일이다. RESTful 서비스는 HTTP 메서드(GET, POST, PUT, DELETE)를 자원 조작에 매핑하고, XML은 여러 가능한 표현 형식(Media Type) 중 하나로 사용된다. 클라이언트와 서버는 HTTP 헤더를 통해 주고받는 데이터의 형식을 협상한다. REST는 SOAP에 비해 간결하고 웹의 기본 원칙을 따르며, JSON 형식과의 결합도 흔히 볼 수 있다.

두 방식 모두 XML을 통해 구조화된 데이터를 교환한다는 공통점이 있으나, 접근 방식과 복잡성에서 차이를 보인다. SOAP는 높은 수준의 표준화와 확장성을, REST는 단순함과 유연성을 각각의 장점으로 삼는다.

XML은 구조화된 데이터를 표현하는 데 적합하여, 다양한 소프트웨어와 시스템에서 설정 파일 형식으로 널리 사용된다. 인간이 읽을 수 있는 형식이면서도 계층적 구조를 명확하게 정의할 수 있어, 복잡한 설정 정보를 체계적으로 관리하는 데 유용하다.

주요 응용 사례로는 자바 기반 애플리케이션의 Spring Framework 설정 파일, Apache Maven의 pom.xml, Apache Tomcat의 server.xml, 그리고 안드로이드 앱의 레이아웃 및 매니페스트 파일 등이 있다. 이러한 파일들은 애플리케이션의 동작 방식, 컴포넌트 간의 관계, 데이터베이스 연결 정보, 빌드 옵션 등을 정의한다.

XML 설정 파일의 사용은 JSON이나 YAML과 같은 대안 형식의 등장으로 일부 영역에서 감소했으나, 여전히 많은 엔터프라이즈 시스템과 레거시 환경에서 표준으로 자리 잡고 있다. 그 장점은 표준화된 파서와 검증 도구(XML 스키마, DTD)가 풍부하며, 주석을 지원하여 설정의 의도를 명시할 수 있다는 점이다. 반면, 상대적으로 장황한 문법은 파일 크기를 증가시키고 가독성을 떨어뜨릴 수 있다는 단점도 존재한다.

XML은 플랫폼 독립성과 인간 가독성을 갖춘 구조화된 데이터 형식으로, 이질적인 시스템 간에 정보를 교환하는 데 널리 사용되는 사실상의 표준이다. 특히 웹 서비스, 엔터프라이즈 애플리케이션 통합, 그리고 전자 데이터 교환 분야에서 핵심적인 역할을 한다.

데이터 교환에서 XML의 주요 장점은 데이터와 그 구조를 함께 기술할 수 있는 자기 기술적 특성에 있다. 태그를 통해 데이터의 의미를 명시할 수 있어, 송신자와 수신자가 동일한 XML 스키마나 DTD를 참조하기만 하면 데이터의 정확한 해석이 가능하다. 이는 서로 다른 프로그래밍 언어나 운영체제를 사용하는 시스템 간 통신에서 큰 장점으로 작용한다. 예를 들어, 자바 애플리케이션이 생성한 XML 데이터를 .NET 기반 시스템이 별도의 변환 과정 없이도 읽고 처리할 수 있다.

주요 응용 사례로는 금융 거래 메시지(FIX 프로토콜), 의료 정보 표준(HL7), 신문 기사 마크업(NewsML), 그리고 오피스 문서 형식(OOXML, ODF) 등이 있다. 또한 RSS나 Atom과 같은 웹 피드 형식도 XML을 기반으로 하여, 블로그나 뉴스 헤드라인을 표준화된 방식으로 배포하는 데 사용된다.

이러한 광범위한 채택은 XML이 단순한 데이터 포맷을 넘어, 데이터의 의미와 관계를 정의하는 메타데이터 언어로서의 역할을 수행하기 때문이다. 구조화된 문서와 데이터의 교환을 동시에 지원함으로써, 비즈니스 프로세스 연계와 시스템 상호운용성을 실현하는 데 기여한다.

XXE 공격(XML External Entity Attack)은 XML 파서의 외부 개체 참조 기능을 악용하는 보안 취약점이다. 이 공격은 공격자가 악성 XML 데이터를 처리하는 애플리케이션에 주입하여 서버의 민감한 파일을 읽거나, 내부 네트워크를 스캔하거나, 서비스 거부 공격을 수행하는 것을 가능하게 한다.

공격의 핵심은 DTD(Document Type Definition) 내에 정의된 외부 개체(External Entity)를 이용하는 것이다. 공격자는 다음과 같은 악성 DTD를 XML 문서에 삽입할 수 있다.

```xml

<!DOCTYPE foo [

<!ENTITY xxe SYSTEM "file:///etc/passwd">

]>

<foo>&xxe;</foo>

```

이 경우, XML 파서가 &xxe; 엔티티를 처리할 때, 시스템 파일(file:///etc/passwd)의 내용을 읽어 문서에 삽입하게 된다. 이 외에도 http://나 ftp:// 같은 프로토콜을 이용해 내부 시스템에 대한 요청을 보내는 등 다양한 형태의 공격이 가능하다.

XXE 공격의 영향은 매우 다양하다. 주요 위험은 다음과 같다.

이러한 공격을 방지하기 위한 가장 효과적인 방법은 XML 파서에서 DTD와 외부 개체 처리를 완전히 비활성화하는 것이다. 대부분의 현대 XML 파서 라이브러리는 이를 위한 설정 옵션을 제공한다. 또한, 입력 데이터의 신뢰성을 검증하고, 필요한 최소한의 기능만을 사용하도록 애플리케이션을 설계하는 것이 중요하다.

XML 문서를 처리할 때는 XXE 공격을 비롯한 다양한 보안 위협으로부터 시스템을 보호하기 위한 모범 사례를 준수해야 한다. 가장 기본적인 조치는 신뢰할 수 없는 출처의 XML 데이터를 처리하지 않는 것이며, 불가피한 경우 입력 데이터의 유효성을 엄격하게 검증해야 한다. 또한 XML 파서의 보안 설정을 강화하는 것이 중요하다. 외부 엔티티 참조와 DTD 처리를 명시적으로 비활성화하여 XXE 공격을 차단해야 한다. 많은 현대 파서는 기본적으로 이러한 기능을 꺼두지만, 설정을 다시 확인하는 것이 안전하다.

XML 데이터의 크기와 복잡성을 제한하는 것도 공격 표면을 줄이는 효과적인 방법이다. 매우 깊은 요소 중첩이나 과도하게 큰 속성 값은 파서의 자원을 고갈시켜 서비스 거부 공격으로 이어질 수 있다. 스키마 유효성 검사를 수행할 때는 로컬 파일 시스템이나 내부 네트워크 리소스를 참조하지 않는지 확인해야 한다. 가능하다면 DTD 대신 XML 스키마(XSD)를 사용하는 것이 보안상 더 안전하다.

마지막으로, XML 처리 라이브러리는 정기적으로 최신 보안 패치가 적용된 버전으로 업데이트해야 한다. 로깅을 통해 의심스러운 XML 처리 시도를 모니터링하고, 필요 이상의 상세한 오류 메시지를 외부에 노출하지 않도록 해야 한다. 이러한 조치들은 XML의 강력한 기능을 유지하면서도 관련 보안 취약점으로 인한 위험을 현저히 낮춘다.