XML Schema(XSD)의 타입 시스템과 참조 무결성 제약

DTD가 요소·속성의 존재와 순서만 규정하고 타입은 문자열 수준에서 멈췄다면, XSD는 그 자리에 정형 타입 시스템과 네임스페이스, 참조 무결성 제약까지 들여왔다. 스키마 문법 자체도 XML로 표현되기 때문에 기계 가독성과 도구 호환성이 높고, B2B·엔터프라이즈 통합에서 데이터 교환 계약을 엄격하게 정의하는 표준으로 자리 잡았다.

버전과 스키마 세트

XSD 1.0은 산업 표준으로 널리 배포돼 대부분의 라이브러리·툴이 기본 지원한다. XSD 1.1은 xs:assert 같은 고급 제약을 추가했지만 지원 도구와 런타임의 가용성은 벤더별로 다르므로 도입 전 최신 정보를 확인해야 한다. 여러 스키마 파일은 include/import로 결합해 스키마 세트를 구성하고, XML 네임스페이스를 기반으로 모듈화와 이름 충돌 방지를 꾀한다.

타입 시스템과 파셋 제약

내장 단순 타입(string, decimal, dateTime 등)에 더해 사용자 정의 파생 타입을 만들 수 있다. 파셋(facet)으로는 길이, 패턴, 범위 등을 정밀하게 제약하는데, 예를 들어 xs:pattern으로 정규식 기반 형식 검증을 걸 수 있다.

복합 타입과 컨텐트 모델

xs:sequence, xs:choice, xs:all로 요소의 순서와 조합을 정의하고, minOccurs/maxOccurs로 반복 허용 범위를 제어한다. 혼합 콘텐츠(mixed) 모델도 지원한다.

네임스페이스와 스키마 상호참조

xs:import로 다른 네임스페이스의 타입·요소를 재사용하고, xs:include로 동일 네임스페이스를 여러 파일로 나눠 구성할 수 있다. elementFormDefault/attributeFormDefault로 네임스페이스 한정 전략을 통제한다.

식별자와 참조 무결성

xs:ID/xs:IDREF, xs:unique/xs:key/xs:keyref로 문서 내 유일성과 참조 무결성을 보장한다. 컬렉션 문서에서 키 기반 중복 방지와 관계 일관성을 확보하는 데 쓰인다.

타입 파생과 교체성

확장(extension)·제한(restriction)으로 상속형 타입 파생이 가능해 재사용성과 진화 가능성이 강화된다. substitutionGroup, abstract 요소를 쓰면 다형적 컨텐트 모델도 구현할 수 있다.

활용 사례

계약 주도 통합(Contract-first)에서는 B2B 메시지, SOAP/WSDL, UBL·XBRL 같은 산업 표준에서 데이터 계약을 정의한다. 스키마를 단일 진실 공급원(Single Source of Truth)으로 채택하면 클라이언트·서버 간 동기화가 쉬워진다.

내부 시스템 간 데이터 교환에서는 배치·스트리밍 파이프라인의 입력 검증 게이트로 XSD를 쓰고, 데이터 레이크 적재 전 스키마 검증으로 품질을 관리한다.

문서 중심 워크플로우에서는 전자문서 양식, 설정 파일, 규정 문서의 형식 일관성을 강제하고, 전자서명·암호화 이전 단계에서 스키마 기반 구조 검증을 거친다.

검증 프로세스 다이어그램

⤢✕

DTD vs XML Schema vs RELAX NG

항목	DTD	XML Schema (XSD)	RELAX NG
데이터 유형 지원	제한적(문자열 중심)	풍부한 내장/사용자 정의 타입, 파셋 제약	외부 데이터타입(XML Datatypes) 연계로 유연
네임스페이스	미지원	완전 지원	완전 지원
제약 표현력	구조 위주, 무결성 한계	키/키참조, 타입 파생, 제약 풍부	구조 표현력 강함, 패턴 기반 유연
확장성/재사용	낮음	높음(import/include, 파생, 그룹)	높음(컴팩트 문법, 조합 용이)
문법 복잡도	단순	복잡(정형적)	직관적(Compact)/표현력 높음(XML)
검증 성능(상대)	빠름	보통	보통~빠름(구현체 의존)
도구/호환성	제한적	매우 넓음(산업 표준)	중간(도구 다양성 제한)
스트리밍 검증	제한	구현체 지원	구현체 지원

코드 예시

전제조건은 Python 3.11+, lxml 5.x, 파일 인코딩 UTF-8이다.

스키마(person.xsd, XSD 1.0)는 나이 범위를 파셋으로 제약하고 xs:ID로 식별자를 강제한다.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">
  <xs:simpleType name="AgeType">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="150"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="PersonType">
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="age" type="AgeType"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID" use="required"/>
  </xs:complexType>

  <xs:element name="person" type="PersonType"/>
</xs:schema>

이 스키마를 만족하는 문서(person.xml)다.

<?xml version="1.0" encoding="UTF-8"?>
<person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        id="p1">
  <name>Alice</name>
  <age>34</age>
</person>

검증 스크립트(validate.py)는 lxml의 XMLSchema.assertValid로 예외 기반 검증을 수행한다.

# Python 3.11+, lxml 5.x
from lxml import etree

schema_doc = etree.parse("person.xsd")
schema = etree.XMLSchema(schema_doc)

doc = etree.parse("person.xml")
schema.assertValid(doc)  # 유효하지 않으면 etree.DocumentInvalid 예외 발생
print("valid")

실행은 pip install lxml 후 python validate.py면 된다.

한 가지 주의할 점은 XSD 1.1의 xs:assert 등이 lxml/libxml2에서는 미지원이라는 것이다. Saxon, Xerces-J(준수 수준 제한) 같은 별도 검증기가 필요하며, 이 부분은 최신 정보를 확인해야 한다.

계약을 앞세우면 달라지는 숫자들

계약 주도 설계와 CI 검증 게이트를 결합하면 효과가 누적된다. 스키마 미적용 대비 초기 통합 단계를 기준으로 인터페이스 형식 오류 사전 차단율이 30~~50%p 개선된다는 관찰이 있는데, 이는 조직 성숙도에 따라 달라진다. 자동 검증 게이트를 도입하면 수동 리뷰·리젝트 비용이 20~~40% 절감되고, 스키마 기반 계약을 동결하고 변경을 관리하면 회귀 결함 재발률이 15~25% 감소한다는 사례도 있다.

정성적으로는 계약 명세가 단일화되면서 커뮤니케이션 비용이 줄고 온보딩이 쉬워지며, 도구 기반 생성·검증 자동화로 릴리스 안정성이 높아진다. 장기 유지보수 관점에서도 스키마 재사용과 버전 호환성 확보가 핵심 이점이다.

실무 도입 시에는 계약 주도 설계, CI 검증 게이트, 확장 우선·하위 호환 원칙의 버전 관리 전략을 함께 적용하는 게 좋다. XSD 1.1 기능이 꼭 필요한지, 그리고 쓰려는 검증기가 그 기능을 지원하는지는 사전에 반드시 확인해야 한다.