회사 데이터를 최대한 활용하기 위해서는 그 흐름에서의 변화(사용자, 애플리케이션 및 시스템간)를 좇아가야 한다. XML이 일상화돼 가는 IT환경을 관리하는 사람이라면 누구든지 XSLT와 XPath를 제대로 이해하는 게 필수다.

어떤 기업의 IT 환경이든 그 근본은 사용자, 애플리케이션 및 외장 시스템들 사이를 이동하는 데이터다. 환경이 바뀜에 따라, 사용자 니즈와 애플리케이션 수요로 인해 우리는 이러한 데이터 흐름의 본성을 조정해야만 한다.
W3C(World Wide Web Cosortium)의 ESL(Extensi ble Stylesheet Language) 권고안은 이러한 데이터 흐름을 우리의 필요와 우리 사용자의 필요에 맞게 적응시킬 수 있도록 메커니즘을 제공하는 두 가지 유용한 기술을 설명하고 있다. 우선 XSLT(XSL Transformations)는 XML 문서를 변형하는 언어를 제공하며, XPath는 XML 문서에 있는 특정 엘러먼트(element)를 식별할 수 있는 툴을 제공한다. XSLT와 XPath에 이들을 이행하는 프로그래밍 언어를 결합시키면 중소기업들이 첨단 기술을 배치할 수 있는 입수 가능한 길이 열린다.
XSLT/XPath 콤보는 거의 모든 IT조직에 흔히 있는 특수한 필요, 즉 사용자와 애플리케이션이 최대한 활용할 수 있도록 데이터의 구조화를 항시 보장함으로써 그 가치를 극대화시켜야 한다는 필요에 대해 뛰어난 솔루션을 제공한다. XSLT 1.0과 XPath 1.0은 1999년 11월에 발표된 것이며, W3C는 현재 두 표준을 모두 대대적으로 개정하는 작업을 진행 중이다. 사실 이 기사를 작성하고 있는 지금, XSLT 2.0과 XPath 2.0은 모두 권고 후보(Candidate Recom mendation) 단계에 있다.

기본적인 것들
스타일시트(stylesheet)는 XSLT의 기본적인 컴포넌트다. 이것은 XML 문서로부터 목적지 문서로의 매핑을 규정하는데, 이는 XML, HTML, 혹은 다른 텍스트 포맷으로 가능하다. 이러한 매핑을 종종 ‘변형(transformation)’이라고도 부른다.
‘스타일시트’란 말은 약간 잘못된 이름인데, 그 이유는 이것이 ‘스타일’에 관련된 게 아니기 때문이다. 그보다 스타일시트는 소스 문서의 데이터를 목적지 문서의 스트럭처로 전환하는 방법에 대해 XSLT 프로세스에 지시를 하는 명령어 세트를 제공한다.
스타일시트 안에 있는 XML 태그는 소스 문서의 원하는 부분에서 목적지 문서를 구축하는 번역을 규정한다. XSLT에는 ‘if’나 ‘choose’와 같은 익숙한 프로그래밍 구문이 포함돼 있는데, 이것은 개발자로 하여금 출력 문서에 어떤 것이 보일지에 대한 조건을 둘 수 있게 해준다. XSLT에는 또한 설명된 유형이 소스 문서에서 발견될 때 트리거링되는 강력한 템플릿 프로세싱 메커니즘이 포함돼 있다.
XPath는 XSLT에 대한 중요한 지원 역할을 한다. XSLT는 자신의 프로세싱 태그 안에서 XPath의 표현법을 이용해 소스 문서의 엘러먼트를 식별한다. XPath는 하드 드라이브에 있는 특정 파일로 인도를 하는 길과 같지만, 파일을 로케이팅하는 대신 소스 문서 안에 있는 특정 엘러먼트를 식별하는 데 사용된다.

실질적 조언
XSLT와 XPath가 IT환경에서 사용될 수 있는 몇 가지 방법이 있다. 가장 일상적이고 쉬운 XSLT의 용례는 XML 문서를 다른 것으로 매핑하는 것이다. 새로운 애플리케이션으로 데이터를 임포팅하고 싶어질 수 있지만, 기존의 XML 구조화 메시지는 적용할 수 없다.
기존 메시지의 스트럭처를 바꾸기보다는 XSLT 프로세스와 연계된 스타일시트가 새 스트럭처 구조를 이용해 메시지를 만드는 데 사용된다. XSLT는 또한 외부 클라이언트가 당신에게 XML 데이터를 제공할 때도 유용하다. 이 경우 스타일시트는 클라이언트 데이터의 엘러먼트를 당신의 애플리케이션이 인식하는 표준 형태로 매핑하기 위해 만들어질 수 있다.
XSLT에는 또한 프리젠테이션 레이어에서 역할을 할 수 있는데, 그 이유는 스타일시트가 XML 문서에 포함된 데이터로부터 HTML을 구성하는 데 사용될 수 있기 때문이다. 이런 상황에서는 XSLT를 이용해 시스템 안에 있는 XML에 저장된 어떤 데이터로부터든 역동적으로 HTML을 만들 수 있다. 사용자 그룹에 따라 자신들에게 가장 유용한 형태로 데이터를 디스플레이하는 서로 다른 스타일시트를 가질 수 있다. 데이터 모양을 조정하는 일은 스타일시트만 변경하면 간단히 해결된다.
XML이 조직에서 널리 사용되고 있지 않을 경우에도 역시 자바나 펄 같이 기존 데이터 스트럭처를 XML로 매핑해주는 툴을 이용해 자체 어댑터를 구축함으로써 이러한 기술을 활용할 수 있다. XSLT 2.0은 또한 새로운 명령어인 애널라이즈-스트링(analyze-string)을 이용해 비 XML 데이터를 내비게이팅할 수 있는 기능을 제공한다.
회사에서 새 소프트웨어를 이행하고, 업데이트 과정에서 사용자 데이터를 새 스트럭처로 마이그레이팅할 필요가 있을 때는 XSLT가 이러한 마이그레이션을 자동화해주는 메커니즘을 제공할 수 있다. 이 경우 데이터가 XML로 저장돼 있다는 것을 전제로 한다. 업데이트 애플리케이션을 이용하면 사용자 데이터를 새 버전으로 업데이트하도록 고안된 스타일시트뿐만 아니라 어떠한 XML 구성 파일이든 적용을 시킬 수 있다.
앞서 언급한 바와 같이 XPath는 XSLT와 독립적으로 사용된다. XPath는 주어진 조건 세트에 부합되는 특정 요소를 위해 XML 문서를 검색하는 데 사용될 수 있으며, 이러한 기능은 XML 데이터에서 흔히 나타나는 복잡한 계층적 스트럭처를 다를 때 매우 중요하다.

제대로 사용하고 있는가
스타일시트에서 특정 프로세싱 명령어를 두어야 할지를 결정할 때 고려해야 할 중요한 질문이 있다. 예를 들어 코드 안에서 템플릿 메커니즘을 완전히 사용하는 대신 ‘if’나 ‘when’과 같은 흐름 제어 문구를 많이 사용하고 있는가? 스타일시트 내에서 작업을 완료하기 위해 XSLT의 익스텐션에 의존하는가? 만약 이런 질문에 대한 대답이 예스라면 너무 많은 프로세싱을 수행하기 위해 스타일시트를 강행하고 있다는 얘기가 된다.
많은 프로그래머들이 순차적인 방식으로 문서를 처리하는 스타일시트를 만드는 덫에 빠진다. 개발자들은 XSLT의 템플릿 메커니즘에 숙달되는 게 아니라 이런 식으로 사용하는 데 습관이 된 스스로를 발견하게 될 것이다. XSLT를 사용하는 가장 강력한 방식은 이것을 패턴 매칭(pattern-matching) 언어로 사용하는 것이다. 여기서는 템플릿이 소스 문서에서 발견되는 패턴을 기반으로 적용된다. 이런 식으로 프로그래밍을 하는 방법은 시간을 들여 배울 만한 가치가 있는데, 그 이유는 이것이 XSLT로 하여금 훨씬 다양한 문제를 해결할 수 있게 해주기 때문이다.
궁극적으로 XSLT 프로세스를 주도하는 스타일시트는 코드며, 이것은 자바나 C# 코드 기반을 다룰 때와 같은 방식으로 취급돼야 한다. 스타일시트를 데이터 변형 프로세스를 주도하는 배치된 구성 파일보다도 약간이라도 더 쉽게 취급을 한다면, 잘못 디자인되고 테스트되지 않은 코드에 의해 문제를 겪게 될 것이다.
이와 함께 XSLT 스타일시트 디버깅은 다른 종류의 코드에서보다 더 복잡하다는 사실 또한 염두에 둬야 한다. 완전 사양의 IDE(Integrated Development Environment)에서 제공하는 와치(watch)나 브레이크포인트(breakpoint)의 도움이 없이 디버깅을 해야 하기 때문이다.
JUnit나 NUnit 테스트 프레임워크를 사용하는 환경에서 유용하게 사용될 수 있는 한 가지 툴은 XMLUnit 익스텐션이다. XMLUnit는 구축 프로세스의 일부로 XML 출력물을 자동식에서 예상되는 것과 비교할 수 있게 해준다. 또한 입력 및 출력 XML 문서에 각각 잘 정의된 DTD (Document Type Definition)나 XML 스키마가 있을 경우 테스팅은 훨씬 더 수월해진다.
XSLT는 개방형 웹 표준을 기반으로 하기 때문에, 하나의 플랫폼이나 프로그래밍 언어만을 사용해야 하는 제한이 없다. 개발된 어떠한 스타일시트든 다양한 플랫폼으로 이식이 가능하다. C++, 자바, 펄 및 닷넷 등과 같은 수많은 언어용의 XSLT 프로세서가 나와 있다.

소중한 도구
앞서 언급한 것처럼 이 두 가지 기술에는 개발팀 스태프가 발견할 수 있는 것 이상의 용례가 있다. 새로운 기술을 이행하는 데 사용되는 많은 애플리케이션들이 XML 구조화 데이터를 처리하기 위해 XSLT에 의존하고 있다. 회사에서 이런 애플리케이션을 구입할 때는 XSLT도 또한 함께 얻게 될 것이다.
SOA(Service Oriented Architecture)의 일부로, 회사에서는 회사 환경에 애플리케이션을 통합하기 위해 ESB (Enterprise Service Bus)를 배치하고 싶을 것이다. 보통 XSLT를 ESB 이행의 일부로 생각하는데, XSLT 프로세스는 기존의 애플리케이션이 웹 서비스나 기타 수단을 통해 통신할 수 있게 해준다. XSLT는 또한 기존 애플리케이션에 대한 하나의 어댑터로 기능함으로써 SOA에서 장려하는 표준이 수용될 수 있게 해준다.
XSLT에 많이 의존하는 또 한 가지 기술로 SAML(Se curity Assertion Markup Language)이 있다. SAML은 XML 기반 스트럭처를 통해 조직에서 특정 엔티티의 보안 특성에 대해 다른 조직과 통신을 할 수 있게 해준다. 이러한 정보를 공유함으로써 조직들은 다른 조직과의 신용 관계(trust relationship)를 넓혀 갈 수 있다.
XSLT가 마법의 총탄은 아니다. 모든 문제를 완벽히 해결해 주지는 못하지만, 그런 기술은 어디에도 없다. 기업 내 데이터 구조화의 주 방안으로 XML이 부상하면서, 기업 환경으로 가져오는 많은 기술 및 애플리케이션들이 XSLT와 XPath를 사용하고 있을 것이다. XSLT와 XPath를 조화롭게 사용하는 방식을 제대로 알고 있다면 이들은 분명 소중한 도구로 당신의 IT도구함에 자리잡을 것이다.

XSLT와 XPath의 미래
현재의 XSLT 2.0에는 보다 강력한 에러 처리 기능이 있는데, 이는 보다 다양한 에러 상황에서 에러 설명 메시지를 제공하기 때문에, 스타일시트에서 문제를 디버깅하는 데 필요한 시간을 단축하게 된다. XSLT 2.0은 또한 시퀀스를 포함해 보다 다양한 데이터 유형을 다루며, 사용법을 제대로 지키지 못해서 발생되는 예외 상황을 처리해 준다.
XSLT 2.0에서는 스타일시트에 지정된 변형이 다중 출력 트리를 만들 수 있기 때문에 사용자가 하나의 소스 문서를 파싱해서 결과물로 다중 문서를 만들 수 있다. 이것은 하나의 데이터 소스로 다중 웹 페이지를 만드는 데 사용될 수 있다.
한편 바른 표현법 엔진을 이용해 문자열이 검토되도록 해주는 강력한 애널라이즈 스트링 명령어도 추가됐다. 이것은 스타일시트가 입력 문서의 비 XML 스트럭처 섹션을 기반으로 검토를 하고 의사결정을 할 수 있게 해준다. 이러한 명령어는 표준 정식 표현법을 이용해 입력 문자열 안에서 특정 패턴을 찾으며, 다른 많은 문서 유형에까지 XSLT가 사용될 수 있게 한다.
다른 많은 사소한 변경들이 XSLT의 유용성을 향상시켜 줄 것이다. 예를 들어 2.0에는 데이터와 시간의 포매팅을 다루는 명령어가 포함돼, 이러한 공통된 데이터 유형을 훨씬 더 쉽게 사용할 수 있게 된다.
후방 호환성을 돕기 위해 스타일시트는 자신이 사용하는 XSLT 권고안의 버전을 XSLT에게 알릴 수 있다. 만약 이 값이 1.0으로 지정돼 있으면, 프로세서가 후방 호환성 모드로 작동할 수 있다. XSLT 코드 기반에 상당한 시간과 노력을 기울였다면, 이러한 능력 덕분에 스케줄에 따라 새로운 권고안으로의 변형을 이행할 수 있을 것이다. 하지만 이러한 후방 호환성 옵션을 이행하느냐 아니냐의 선택은 XSLT 2.0 소프트웨어 사업자들에게 달려 있다는 사실을 명심해야 한다.
XSLT 2.0과 나란히 작동하도록 고안된 XPa th2.0에는 또한 다양한 데이터 유형 지원 등과 같은 수많은 새로운 사양들이 있다. 아마 새로운 데이터 유형으로 가장 중요한 것은 시퀀스 유형일 것이다. 시퀀스와 그 관련 기능들을 사용함으로써 XPath 2.0은 예전에는 불가능했던 방식으로 주문받은 데이터 목록을 처리할 수 있다.
XSLT 2.0과 상당히 유사하게 XPath 2.0은 버전 1.0으로 구축된 표현법이 유효하도록 보장해 주는 후방 호환성 모드를 제공한다.
XSLT 2.0과 XPath 2.0을 시험해 보고 싶다면 saxon.sourceforge.net에서 오픈소스 프로세서를 구할 수 있다. 이 프로세서는 W3C의 XSLT 2.0 사양 에디터인 마이클 케이 박사가 만든 것이다.