[펌] XML의 새로운 도약을 위한 돌파구, X쿼리

X쿼리 1.0은 W3C에서 2003년 11월에 최종 Working Draft로 발표한 XML 문서의 검색과 생성을 위한 서버 사이드 솔루션이다. X쿼리는 SQL과 유사한 표준 구문을 이용하여 XML 문서를 다룰 수 있도록 설계되어 있으며 객체지향 프로그램 언어 형식을 갖추고 있다. 이번 시간을 통해 XML의 새로운 도약을 위한 돌파구가 될 X쿼리에 대한 정의와 관련된 개괄적인 내용과 간단한 예제, 그리고 X쿼리의 미래에 대해 이야기할 것이다.

쿼리는 아직 생소하다. 그럼에도 불구하고 필자는 이 생면부지의 단어를 처음 접할 때부터 익숙한 느낌을 지울 수 없었다. 아마도 쿼리라는 단어가 주는 직업상의 친근감 때문이었던 것 같다. 다음 정의는 필자가 읽은 X쿼리에 관한 서적과 각종 문서에 표현된 정의들이다.

◆ X쿼리는 XML용 데이터 검색 언어이다.
◆ X쿼리는 XML 객체에 대하여 검색을 수행할 수 있는 새로운 언어이다.
◆ X쿼리는 간결하지만 유용한 XML용 검색 언어이다.
◆ X쿼리는 간결하고 이해하기 쉽게 설계된 XML용 검색 언어이다.
◆ X쿼리는 관계형 DB의 SQL과 같은 XML용 검색어이다.
◆ X쿼리는 XML의 SQL이다.

이 정의를 다시 종합 정리하면 X쿼리는 ‘XML을 위한 쿼리 랭귀지’라는 뜻이다. 하지만 이것만으로 X쿼리에 대해 정의를 단정하기엔 아쉬움이 남는다. 필자가 살펴본 X쿼리에 관한 많은 문서들은 이처럼 단정적인 정의를 내리기보다는 많은 설명을 곁들여 X쿼리를 서술하고 있었다. 공부를 더 진행하고 나서야 X쿼리의 정의가 그리 간단치 않음을 알게 되었고 나름대로 X쿼리라는 이름이 다소 협소한 의미로 붙여진 것이 아닌가 하는 불만이 생길 정도였다.

XML을 위한 쿼리?
X쿼리 1.0은 W3C(World Wide Web Consortium, http://www.w3.org)에서 2003년 11월에 Working Draft로 제안한 XML Query Language의 약식 표현이며 해당 Working Group 프로젝트의 공식 용어이다. 필자가 처음부터 X쿼리라는 이름을 갖고 시비 거는 이유는 간단하다. 직업적인 감각으로 인해 X쿼리라는 이름에서 느껴지는 친근하며 직관적인 느낌 때문에 오히려 그 용도와 실체를 파악하는 데 방해가 되고 있기 때문이다. X쿼리는 단순한 XML을 위한 검색 언어가 아니다.
X쿼리는 다양한 데이터 소스 검색을 통해 원하는 XML 문서를 가장 효율적으로 생성할 수 있는 강력한 ‘문서생성자(Document Creator)’이다. X쿼리는 XML 문서를 포함하여 그 외의 다양한 데이터 소스(예를 들어 RDBMS에 저장된 테이블 데이터 등)로부터 새로운 XML 문서를 직관적이고 이해하기 쉬운 방식으로 새롭게 생성시킬 수 있는 방법을 제시하고 있다. 바로 이 점이 X쿼리가 최근 XML 기술의 새로운 패러다임으로 조명받는 가장 중요한 이유이다.
우리가 XML에 있어 X쿼리의 출현에 관심을 갖는 또 다른 이유는 RDBMS에 있어 SQL의 출현과 비교해 볼 수 있다. 최초 RDBMS의 개념은 놀라운 것이었지만 시장의 반응은 그리 신속하지 못했다. 그러나 국제표준화 기구인 ISO에서 SQL을 제정 발표함에 따라 RDBMS는 시장에서 현재까지 가장 확고한 데이터 저장 기술로 인정받을 수 있었다. 이처럼 XML에 있어 X쿼리 표준화가 갖는 의미는 매우 크다고 할 수 있다.

XML 기술의 정체 현상
X쿼리를 이야기하는 데 XML을 빼놓을 수는 없다. 그러나 XML에 대한 기술적인 부분은 방대할 뿐 아니라 독자들은 이미 알고 있다고 판단하여 생략하고 넘어가겠다. XML은 그 태생적인 편리함과 자연스러움으로 인하여 IT 관련 산업 분야뿐만 아니라 출판, 문화 등 많은 산업 분야에서 활용되기에 이르렀고, 점차 복잡 다양한 XML 문서가 등장하고 있으며 저장된 자료의 크기 역시 기하급수적으로 늘어나고 있는 추세이다.
그러나 XML 문서는 사용상의 자연스러움과 편리함의 이면에 있는 자동화의 어려움은 아직 극복하지 못한 그림자이다. 복잡하고 다양한 구조의 XML 문서는 대량의 프로그램 코드를 양산시키고 있고, 대용량 문서는 처리속도를 악화시켜 이를 개선하기 위해 복잡한 프로젝트 과정을 거쳐 수없는 단위 시스템들을 만들어내고 있다. 다시 말해 현재 XML의 상황은 만들기는 쉽지만 다루기는 쉽지 않은 기술적인 한계로 인한 정체 현상으로 분석되기도 한다.
이러한 문제 극복을 위한 노력은 XML이 표준으로 발표된 직후부터 계속됐다. W3C에서는 XML이 발표된 뒤 여러 Working Group을 통해 XSLT나 XPath, XQL 등과 같은 다양한 XML 전용 검색 방안을 연구했고 2003년 11월에 이러한 관련 연구를 통합하여 XML 전용 검색 언어인 X쿼리 1.0을 발표하기에 이른 것이다. X쿼리 1.0은 현재까지 Working Draft 버전이며 실질적이고 실무적인 테스트를 거친 후 올해 말이나 내년 쯤 권고 버전으로 확정될 전망이다.

XML 문서 처리를 위한 방법들
XML 파서
현재 XML 문서를 응용 프로그램 내에서 처리하기 위한 가장 일반적이며 표준화된 방식은 XML 파서를 이용하는 것이다. XML 파서는 일반적으로 텍스트 형태의 XML 문서를 트리 형식의 구조로 객체화시키고 element와 attribute, value 등으로 의미를 부여하여 응용 프로그램 내부에서 처리할 수 있는 자료 구조로 변경시켜준다. XML 파서는 XML 문서를 처리하는 응용 프로그램에서 현재 가장 많이 활용되는 수단이지만 이에 대한 경험이 없는 개발자라면 사용이 그리 쉽지 않다. 또한 유경험자라 하더라도 XML 문서 구조가 복잡하거나 2개 이상의 XML 문서를 복합적으로 다루게 된다면 그 작업은 많은 노력과 심오한 상상력을 요구하게 된다. 또한 XML 파서는 뒤에서 확인하겠지만 필연적으로 많은 코드를 양산할 수밖에 없고 유지관리에 취약한 문제점을 갖고 있다.

XSLT
또 다른 방식은 역시 W3C에서 제안한 XSL(eXtensible Stylesheet Language)와 XSLT(XSL Transformations, http://www.w3.org/TR/xslt)를 들 수 있다. 최초의 XSL이 제안된 때에는 XML 문서를 HTTP를 이용하여 웹에서 활용할 수 있도록 하기 위한 방안이었다. 뒤에 XSLT로 변경되어 제안됐는데 단순한 웹 스타일 시트의 기능을 넘어 XML 문서를 다른 형태의 문서로 전환(transformation)시키자는 기능 확장의 의도였다. XSLT는 XPath문을 기초로 조건문과 반복문 등 일부 프로그램 기능을 제공하고 있어 현재 X쿼리와 가장 많이 비교되고 있지만 기본적으로 웹 브라우저를 기반으로 만들어진 기술로 HTML이나 스타일 시트 내에서 작성해야 하는 제약 때문에 XML 파서에 비하여 실제 비즈니스 업무에 있어 활용도는 미미하다.

XML-DB
다른 관점에서 일부 벤더에서 제시하는 XML 문서의 저장과 검색 방식과 비교할 수는 있을 것이다. 현재 오라클을 필두로 일부 XML-DB 벤더들이 제안하고 있는 기술이 그것인데, 그들의 기술과 X쿼리간에 정밀한 기술적 설계의 완성도 차이는 차치하더라도 이러한 기술들은 국제적으로 전혀 표준화되지 않았다는 허점이 있다. 또한 이들이 제안하는 특정 기술은 그들의 제품을 구입해서 사용하지 않는 경우에는 그림의 떡처럼 보기만 좋을 뿐이며 더 이상 일반적으로 확산되지 못하는 이유도 여기 있는 것이다.
이 같은 문제들로 인해 XML 기술이 많은 장점과 성공 요인을 갖고 있음에도 불구하고 아직 여러 분야에서 기술적인 주도권을 확보하지 못하거나 본격적으로 도입되지 못했다고 할 수 있다. 그러나 여러분은 잠시 후 예를 통해 X쿼리가 어떻게 이들 기술을 대체하며 새로운 기회를 제공할 수 있는지를 확인하게 될 것이다.

새로운 XML 서버 사이드 솔루션, X쿼리
앞에서 언급한대로 X쿼리는 XSLT과 자주 비교된다. 이유는 X쿼리는 기능적으로 XSLT와 유사할 뿐 아니라 W3C의 또 다른 XML 관련 검색 표준안인 XPath 2.0(XML Path Language, http://www.w3. org/TR/xpath20)이 XSLT와 X쿼리 모두에서 핵심적인 검색 수단으로서의 역할을 하기 때문이다. 그러나 단순히 기능적인 측면에서 X쿼리와 XSLT를 비교하는 것은 운송수단으로서 버스와 오토바이의 성능을 비교하는 것처럼 의미가 없다. 혹자는 그 차이를 X쿼리가 갖고 있는 풍부한 빌트인 함수와 객체지향 프로그래밍 지원 등을 가지고 X쿼리의 우월성을 말하기도 하지만 필자가 생각하는 둘 사이의 가장 확연한 차이는 실행 방법에 있어서 X쿼리는 XML을 위한 새로운 개념의 서버 사이드 솔루션이라는 데 있다.
서버 사이드 솔루션은 때때로 생각보다 강력한 힘을 발휘한다. 초기 자바는 애플릿 형태의 브라우저 기반 기술로 웹을 구현하려던 시도였지만 브라우저 벤더와의 갈등과 네트워크 속도 문제 등으로 많은 시행착오를 겪었다. 그러나 자바의 서버 사이드 솔루션인 JSP(Java Server Page)의 등장으로 웹 시스템에서 자바 기술의 발전 속도와 방향이 확연히 달라진 것은 부인할 수 없는 사실이다. 현재 W3C의 X쿼리 Working Group 내에서의 활동이 IBM이나 오라클 등 서버 사이드 솔루션 업체에 비하여 MS가 비교적 소극적인 이유도 X쿼리의 실행 방식과도 관련이 깊다고 볼 수 있다.
필자의 주장대로 X쿼리가 서버 사이드 솔루션이기 때문에 스포트라이트를 받을 것이라는 단순한 주장은 일부 오해를 낳을 수 있다. 현재 XML과 관련된 서버 사이드 솔루션으로 XML 파서가 굳건히 자리를 잡고 있기 때문이다. 다른 말로는 현재까지 표준화된 XML 관련 서버 사이드 기술로는 거의 유일하다고 하는 것이 옳은 표현일 것이다. 이와 관련해서 앞에서 언급한 최근의 몇 가지 제품과 기술적인 시도가 있지만 특정 제품에 종속적이며 표준화되지 않은 점 때문에 보편적인 기술로 보기에는 문제가 있다. 반면 X쿼리는 프로그램 언어와 독립적이며 저장장치와도 무관한 구조를 제안하고 있다. 또한 특정 HW나 OS에 종속되지 않는, 말 그대로 표준안 자체이다.

XML 파서와 X쿼리의 비교
다음의 XML 문서는 W3C(http://www.w3.org/TR/xquery-use-cases)에서 X쿼리의 활용 예제를 위해 샘플로 제시한 것이다. 간단하게 문서에 대한 설명과 용어 정의를 하고 넘어가도록 하자.

<리스트 1>에는 총 4권의 책과 관련된 정보가 저장되어 있다. 최상위 엘리먼트는 엘리먼트이며 최상위 엘리먼트는 자식 엘리먼트로 엘리먼트 4개를 갖고 있다. 엘리먼트는 year 속성을 갖고 있으며

이러한 결과를 만들기 위해서는 다양한 방식으로 프로그램을 할 수 있을 것이다. XML 파서를 사용하는 경우도 있을 것이고, XML 파서 없이 시쳇말로 ‘날코딩’으로 프로그램을 할 수도 있겠지만 여기서는 XML 관련 솔루션을 이용한다는 전제로 XML 파서를 이용하도록 하겠다. XML 파서는 여러 형태의 제품이 있다. 처리 속도와 메모리에 대한 문제로 인해 실제 프로그램에서는 대부분 SAX(Streaming API for XML Processing) 형태의 파서를 주로 사용하고 있지만 DOM(Document Object Model) 파서 형태에 비하여 코드가 복잡하고 길어지므로 여기서는 DOM 파서를 기준으로 예를 들었다(문서량을 줄이기 위해 main문만 표현하였음. 이달의 디스켓에서 전체 코드 다운로드 가능).

<리스트 2>와 <리스트 3>의 차이가 느껴지는가? 다시 이 결과물을 알파벳순으로 정렬하는 경우를 생각해보자. XML 파서 형식의 프로그램 내에서 정렬을 구현하는 일은 일단 결과를 출력하기 전에 다시 한 번 내부 자료구조를 만들고 퀵소트 알고리즘을 구해서 자료구조에 맞게 변경해야 한다. 처음 작업한 것에 비해서도 그리 간단한 작업이 아니다. 그러나 X쿼리는 SQL의 order by 절과 유사한 명령으로 이 문제를 간단히 해결할 수 있다.

for $a in document("bib.xml")//title
order by $a
return $a

가운데 문장에 order by 절을 삽입하는 것만으로 간단히 해결됐다. 좀 복잡한 쿼리를 생각해보자. Addison-Wesley 출판사에서 발간된 모든 책 제목을 순서대로 추출해보자.


{
for $b in document("bib.xml")//book
where $b/publisher = "Addison-Wesley"
order by $b/title
return $b/title
}


이번에는 SQL과 동일한 where 절을 이용해서 간단히 해결됐다. 좀 더 복잡한 예를 들자면 끝도 없겠지만 더 이상 두 가지 기술을 비교하는 것은 의미 없는 일이다.

XML의 새로운 향기 FLWOR
<리스트 3>의 중괄호 안에 있는 구문이 X쿼리의 핵심인 FLWOR 구문이다. 발음은 꽃(Flower)의 영어 발음과 동일하다. 발음대로 향기가 느껴지는가? 여러분들은 앞의 몇 예제를 통해 이미 X쿼리의 핵심 구문 5개중 4개에 대하여 거의 내용 파악을 끝냈다. X쿼리 문법이 이렇게 쉽기만 할 리는 만무하겠지만 일반적인 경우라면 이정도로 충분하다.

for $a in document("bib.xml")//title
return $a

<리스트 3>에서 보았던 FLWOR 구문의 의미를 살펴보면 다음과 같다.

51710; bib.xml 문서를 읽고 → document('bib.xml')
51711; 문서에서 위치에 관계없이 < title > 엘리먼트를 모두 찾아 → //title
51713; 찾은 값을 반복 변수 a에 Assign하고 → for $a in
51714; 결과로 변수 a의 값을 반환하라 → return $a

Let 절은 For 절과 유사하므로 이에 대한 예제와 설명은 생략하도록 하겠다. Let 절은 For 절과 비슷하긴 하지만 실상 내부 처리 방식은 확연히 다르므로 신중하게 접근할 필요가 있다. 향후 다시 지면이 허락된다면 X쿼리 문법에 대하여 좀 더 자세하게 다루고 싶은 욕심이 있으므로 그때로 미루도록 하자.
FLWOR 구문은 X쿼리의 기본 구문이다. 이 FLWOR 문장 때문에 X쿼리를 XML의 SQL이라고 정의하기도 한다. 사용자는 FLWOR 구문을 이용해서 XML 문서에 대해 단순하면서도 강력하고 유연한 검색을 실행할 수 있게 된다. 그러나 서두에 했던 필자의 X쿼리 이름에 대한 불만을 잊지 말라. 재차 이야기하지만 X쿼리의 가장 큰 활용은 XML 문서의 검색뿐 아니라 기존의 XML 문서 또는 RDBMS와 같은 다른 종류의 데이터 소스로부터 새로운 XML 문서를 쉽게 생성할 수 있다는 데 있다. X쿼리를 활용하면 생성될 새로운 XML 문서에 대해 별다른 상상력이 필요 없다. 생성하고자 하는 문서양식(schema)을 직관적으로 확인하며 매우 간단히 만들어낼 수 있게 되기 때문이다.

XPath 2.0
X쿼리 1.0이 등장하기까지 역사에 대해 잠깐 언급하고 넘어가도록 하자. X쿼리는 기본적으로 XSLT에서 사용되고 있는 XML 검색 기술인 XPath를 기반으로 만들어졌다. 여기에 SQL의 구문을 일부 활용하고 변수 바인딩 기법과 객체지향 언어 구조 등을 혼합하여 탄생된 것이다. 이중 XPath는 XML과 관련된 가장 간단하고도 중요한 검색 방법이므로 잠깐 알아보도록 하자.

for $a in document("bib.xml")//title
for $a in document("bib.xml")/bib/book/title

이 두 FLWOR 문장 중 흐릿하게 표시된 부분이 XPath 표현식이다. XPath는 XML 문서를 엘리먼트의 위치 기반으로 검색하도록 표현식을 제공한다. 첫번째 예는 bib.XML 문서에서 엘리먼트 위치에 관계없이 모든 title 엘리먼트를 검색하는 것이며, 두 번째 예는 최상위 엘리먼트인 bib로부터 자식 노드에서 book 엘리먼트를 찾은 다음 자식 노드에서 title 엘리먼트를 찾는다는 의미이다. 스키마 구조가 동일한 경우 결과 집합이 같을 수도 있지만 경우에 따라서는 전혀 다른 결과 집합이 나올 수도 있다.

1. for $a in document("bib.xml")/bib/book[@year > 1991]/title

이 XPath 표현식은 결과 집합에 대한 사전 Filter 역할을 한다. 의미는 bib/book 엘리먼트의 속성인 “year”의 값이 1991보다 큰 값만을 선택하여 title을 가져오라는 의미이다. 다음의 FLOWR 표현과 비교해보자.

2. for $a in document("bib.xml")/bib/book/title
where @year > 1991

두 표현식은 같은 결과 값을 리턴하게 된다. 그러나 우리는 1번과 2번 문장의 실행 방식의 차이에 주목해야 한다. 1번 구문은 “bib.xml”에서 “title” 엘리먼트를 가져오기 전에 1991년 이후 결과 값만을 찾아서 값을 리턴하게 되며 2번 구문에서는 모든 “title” 엘리먼트를 찾은 뒤에 차례로 1991년 값과 비교하게 된다는 의미이다. 두 번째 방법의 경우 X쿼리 파서를 설계하는 입장에서 보면 반드시 XPath의 모든 결과 집합을 메모리에 적재한 뒤에만 후속 처리가 가능할 수밖에 없다는 부담을 갖게 된다. 이와 같이 적절한 XPath 구문의 활용은 시스템 운영을 가볍게 만들고 실행속도를 단축시키는 중요한 이슈가 될 수 있다.

X쿼리의 미래
X쿼리가 일반화된다면 XML은 만들기는 쉬워도 다루기는 어려운 천덕꾸러기 신세는 면하게 될 것 같다. 이제 더 이상 XML 기술은 전문가의 영역이나 시스템화의 대상이 아닌 것이다. 컴퓨터가 윈도우의 등장으로 어린아이 장난감이 된 것과 비교하면 지나친 비약이겠지만 불과 몇년전 RDBMS와 SQL이 없던 시절 VSAM, ISAM, Network-DB, H-DB에 자료를 저장하고 검색하기 위해 필자나 우리 선배들이 했던 노고에 비한다면 이 역시 작지 않을 것이다.
우리는 지금까지 XML로 작성된 파일을 문서(Document)라고 부르는 이유에 대해서 아무런 관심을 갖지 않았다. XML이 데이터나 자료가 아니고 문서인 이유는 XML 언어로 작성된 자료는 그 자체만으로도 누구나 내용을 파악할 수 있기 때문이다. 어쩌면 X쿼리가 활성화된다면 더 이상 워드나 아래아 한글로 문서작업을 하지 않게 될 지도 모른다. 아니면 이런 오피스 문서와 XML 문서를 상호 교환할 수 있는 기반 기술이 등장해야만 할 것이다. 이렇게만 된다면 전산 매체를 이용해 저장된 어떠한 정보도 그냥 버려지지 않도록 하겠다는 XML의 꿈이 X쿼리로 마침내 이루어지지 않을까 하는 상상을 해본다.