효율적인 XML 교환을 위한 EXI

명분을 넘어 실용으로…

김도형 dynaxis@alticast.com 양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다. 2008년 6월 10일

이번 글에서는 지난 “To XML or Not to XML”이라는 글에서 소개한 XML 바이너리 인코딩 규격인 EXI의 의의와 동작 원리를 살펴보고 어떤 경우에 적용하면 좋을지에 대해 살펴보겠습니다.

최근 세상 돌아가는 소식…

2008년 5월 6일부터 9일까지 열린 올해 자바원에서는 자바FX를 부각하면서 흥미로운 발표가 많았다. 이전 “RIA 플랫폼 전쟁을 바라보며…”라는 글에서는 RIA(Rich Internet Application) 플랫폼으로서 자바FX의 약점을 지적했었는데 약점을 보완할 구체적인 계획이 제시되었다. 물론 여전히 확신은 주지 못하지만 말이다. 구체적으로는 이제 막 개발을 시작한 듯하지만 디자이너가 쉽게 사용할 수 있는 저작 도구 개발에 대한 발표가 있었고, A/V 처리의 약점을 보완하기 위해 기존 JMF(Java Media Framework) 대신 자바 미디어 컴포넌트를 개발하고 있다는 언급도 있었다. 여기에 어느 플랫폼에서나 지원되는 A/V 코덱을 위해 플래시 비디오로 유명한 On2와 제휴를 했다는 발표도 있었다. HTML 지원도 강화해 기존 JEditorPane의 제한된 HTML 지원 대신 JWebPane 이라는 웹킷(WebKit) 기반 컴포넌트도 추가한다고 한다.

한편 어도비에서는 플래시 플레이어 10 베타가 나왔고, 오픈스크린 프로젝트를 공개했다. 특히 플레이어나 변환기를 만들 수 없게 한 SWF 규격 라이선스의 제약을 오픈스크린 프로젝트를 통해 없애고 임베디드 시스템용 플래시 플레이어에 대한 로열티를 받지 않겠다고 했다. 로열티 문제는 독점 기술이라는 한계를 가진 데다 임베디드 시스템 쪽 지원이 시원치 않았던 플래시가 PC 이외의 장치로 퍼져 나가는 것을 막는 가장 큰 장애물이었던 바 상당한 영향을 미치지 않을까 한다. 다만 버전 9 이후의 플래시 플레이어는 AVM2(ActionScript Virtual Machine 2) 같은 이미 소스가 공개된 컴포넌트의 구조로 볼 때 보수적 가베지 컬렉션(conservative garbage collection)을 하는 등 저사양 임베디드 시스템에 적용하기에는 적절치 못한 부분이 많아 추후 비 PC 환경에서 플래시의 확산은 좀 더 두고 봐야 할 것으로 보인다.

살짝 덜 뜨거운 주제?

바쁘게 돌아가는 세상이다. 사실 이 글을 제목과 다른 잡다한 동향을 소개하면서 시작하는 이유는 이처럼 다뤄볼 만한 주제가 넘치고 넘치는 가운데 비교적 덜 뜨거운 주제를 다뤄볼까 해서다. 위에 언급한 뜨거운 주제는 조금 시간을 두고 보다가 기회가 닿으면 글로 풀어보도록 하겠다.
본론으로 들어가서, 이전 “To XML or Not to XML”이라는 제목의 글에서 XML(엄밀히 XML이 표현하는 정보)은 무조건 텍스트 형식으로 표현해야 한다고 믿는 XML 순수론자의 맹목적인 주장에 대해 회의적인 의견을 제시한 바 있다. XML이 텍스트라서 좋은 점도 있지만 그렇다고 W3C 내에서 바이너리 규격을 만드는 것조차 반대해서야 되겠는가? 그 글에서 앞으로 주목해야 할 바이너리 인코딩 규격으로 W3C의 EXI(Efficient XML Interchange) 규격에 대해 간단히 짚고 넘어간 바가 있다. 글을 쓸 당시는 제대로 된 초안은커녕 규격의 기본이 될 Efficient XML의 세부 규격조차 공개되지 않았던 상황이었는데 어느덧 시간이 흘러 많은 진전이 있고 초안이 공개되었다.

이번 글에서는 이 EXI 규격의 의의와 동작 원리를 살펴보고 어떤 경우에 적용하면 좋을지에 대해 살펴보고자 한다.

위로

The Binary XML Strikes Back?

텍스트 형태의 XML을 중심으로 형성된 사용자 공동체에는 XML의 바이너리 인코딩을 그저 W3C와 XML의 명성에 편승하려는 불온한 세력의 획책으로 보는 시각이 여전히 있다. 2007년 7월 EXI 1.0의 초안이 나왔을 때의 반응을 보면 바이너리 인코딩이 그렇게 나쁜 것인가 하는 생각이 절로 든다. 현재로서는 EXI를 제정하는 측이 수세인 것 같기는 하지만 EXI에 대한 XML 순수론자의 반응을 보면 영화 스타워즈 에피소드 5, “제국의 역습(The Empire Strikes Back)” 이 생각난다 . 과연 바이너리 인코딩은 평화롭던 XML 은하를 위협하는 “사악한 제국” 일까? 최종 판단은 시간이 지나 실제 EXI 가 어떻게 쓰이고 XML 공동체에 어떤 영향을 끼치는지를 봐야 내릴 수 있을 것이다. 하지만 개인적으로는 “사악한 제국” 이라기보다는 “새로운 희망(A New Hope)” 이 아닐까 한다.

바이너리 형식에 문제가 많아 텍스트로 온 거 아닌가요?

정보를 표현하는 데 있어 애당초 사람이 읽을 수 있는 형태인 편이 좋은 분야가 많다. 원래 XML이 목표로 했던 전자 출판이나 인터넷 상의 정보 교환은 표현하고자 하는 정보 자체가 텍스트라는 면에서 XML과 잘 맞는다. 이런 응용은 굳이 바이너리 인코딩을 할 필요도 없고 해도 크기가 그다지 줄지도 않는다. 저장 공간이나 전송 시 크기가 문제가 된다면 GZIP으로 압축만 해도 충분하다. 또 이런 응용에서는 메시지를 처리하면서 서버 성능을 극한까지 밀어 붙일 필요도 없다.

하지만 SOAP(Simple Object Access Protocol)처럼 기존 CORBA나 RPC(Remote Procedure Call) 같이 통상 바이너리 형태의 프로토콜을 정의해서 사용하던 분야에 XML을 적용하게 된 것은 경우가 다르다. 지난 글에서도 언급했지만 CORBA나 RPC의 상호 운영성 문제는 표현 수단 자체의 문제라기보다는 규격이 커지면서 세부적인 부분을 충분히 상술하지 못해서 생기는 모호함 때문이라고 봐야 한다. 실질적인 문제는 프로토콜 자체를 단순화하고 현실화함으로써 해결했고, 이런 환경에서 XML을 적용하게 된 것은 사실상 다음과 같은 이유에서라고 볼 수 있다.

• 웹 기반으로 재편된 서비스 환경에 따라 HTTP 친화적인 메시지 형식이 필요했다.

• 경직된 국제 표준화 기구나 특정 회사, 상업적 목적의 컨소시엄에 의해 개발된 메시지 형식이 널리 받아들여지지 못했던 것에 비해, 공개적이고 자생적으로 발전해 온 웹의 특성으로 인해 XML은 공통의 데이터 표현 방식으로 널리 받아들여질 수 있었다. 또 이미 다른 목적으로 많이 수용되고 있었다.

이런 배경 하에 XML을 새롭게 메시징에 적용해 얻는 실질적인 이점은 다음 정도가 아닐까 한다.

• XML은 메시징 이외에 온라인/오프라인을 망라한 전자 출판, 다양한 데이터 파일 형식 등에 사용되어 와서 XSLT, XML 스키마 등 메시지 처리와 정보 모델링, 검증에 도움이 되는 풍부한 표준 및 개념이 정립되어 있었다. 또, 파서 등의 도구와 자료가 풍부하고, XML을 이해하고 사용하는 큰 공동체가 형성되어 있다.

• XML이 텍스트라는 점은 최소한 정보를 모델링하고 프로토콜을 설계하고 디버깅하는 측면에서는 바이너리 형식에 비해 아주 편리하다. 일단 시스템이 완성되면 사람이 거의 끼어들 필요 없이 잘 동작하지만 이런 과정은 모두 사람이 해야 하기 때문이다.

하지만 문제는 이러한 장점에도 불구하고 바이너리 인코딩을 다시 쳐다보는 이유는 XML이 텍스트라는 것 때문이 아니라 일부 응용 분야에서 텍스트 형식을 사용하는 데 한계가 있기 때문이다.

• 단시간에 어마어마한 규모의 메시지를 처리: 웹은 특정 회사나 조직을 넘어 지구적인 메시지 교환을 초래했다. 또 이전에 비해 컴퓨터 인프라가 잘 갖춰지면서 네트워크를 통한 메시지 교환을 더욱 더 가속화했다. 최근 각종 서비스를 위해 대규모 서버군이 사용되고 그 서버군을 유지하는 전력과 비용이 어마어마한 현 상황에서 서비스 과정 각 요소를 최적화해 비용을 절감하려는 노력이 크다. 따라서 외부와 인터페이스하는 메시지의 인코딩과 디코딩에 드는 자원부터 최소화할 필요가 있다.

• 대역폭이나 컴퓨팅 자원이 부족한 경우: 일반적인 인터넷과 달리 상대적으로 저속이거나 패킷 단위로 과금되는 무선망, 단방향으로 신뢰성 있는 데이터 전달을 위해 동일 데이터를 반복 전송하는 방송망 등의 경우는 전달되는 데이터 크기가 작아야 한다. 또, 휴대폰이나 디지털 TV 등의 임베디드 장치의 경우 텍스트 형태의 XML을 처리하기에 메모리나 CPU가 한계가 있는 경우가 많다.

여기서 한 가지 언급하고 싶은 것은 대부분의 XML 순수론자는 XML 인코딩과 디코딩에 소요되는 자원이나 시간이 서비스 전체를 봤을 때는 그다지 중요하지 않다고 말하기도 한다는 점이다. 물론 그런 경우도 있다. 하지만 단순히 서버에 도착하는 요청 하나를 처리하기 위한 작업을 일렬로 늘어 놓고 전체 대비 XML 디코딩/인코딩 시간의 비율이 얼마 되지 않으니 XML은 성능에 별 영향을 끼치지 않는다고 이야기하는 것은 현실적이지 않다.

예를 들어 흔히 서버를 여러 층(multi-tier)으로 구성한다. 여기에 XML을 디코딩하는 서버군을 별도 층으로 분리했다고 하자. 그러면 뒤에 위치한 층이 어떻든 디코딩에 들어가는 자원이 줄면 디코딩을 담당하는 서버 수를 대폭 줄일 수 있다. 비슷한 예로 실제 처리해야 할 작업에 비하면 미비한 웹 서버 성능을 높이기 위해 왜 그렇게 노력을 하겠는가? 또한, 설사 한 기계에서 XML 디코딩과 나머지 작업을 한꺼번에 하더라도 작업 단계 사이의 버퍼 사용이나, I/O, CPU 사용 중첩 등 다양한 요인에 의해 XML 디코딩에 들어가는 부하를 줄여 많은 효과를 볼 수도 있다.

결론적으로 원래 텍스트 형식이 적합하던 쪽에서는 SGML을 거쳐 더 단순하고 널리 쓸 수 있도록 XML을 만들었고 바이너리 형식을 쓰던 쪽에서도 단순히 바이너리 형식이 문제라서 XML을 쓰게 된 것은 아니라는 것이다. 다만 XML에 맞는 바이너리 인코딩을 만들면 앞서 언급한 텍스트 형태의 XML을 사용하는 장점은 그대로 두면서 특정 상황에서 텍스트 형태가 가지는 단점을 극복할 수 있다. 즉 작은 크기와 효율적인 처리라는 두 마리 토끼를 한꺼번에 잡을 수 있는 것이다.

위로

그럼 왜 W3C표 인코딩을 새로 만들죠?

사실 XML의 바이너리 인코딩을 정의한 규격은 EXI를 제외하고도 이미 여럿이다. 잘 알려진 것으로 WML에 적용된 WBXML 이 있고 이미 바이너리 인코딩을 여럿 정의하고 있는 ASN.1을 XML과 접목한 ITU-T/ISO 표준인 Fast Infoset이 있다. 또 MPEG 규격의 일부로 제정된 BiM도 있다. 이런 상황에서 왜 W3C표 바이너리 인코딩을 새로 만들까? 바로 다음과 같은 이유 때문이다.

로열티 없는 규격
W3C는 권고안을 구현하는 데 있어서 로열티가 없어야 한다는 점을 명확히 하고 있다. 물론 누군가 돈을 들이고 노력해 얻은 지적재산권을 공짜로 쓰는 것이 정당하다는 것은 아니다. 하지만 W3C 특허 정책에 언급한 대로 W3C 권고안처럼 기반이 되는 기술이 널리 사용되기 위해서는 로열티 부담이 낮을 필요가 있다. 자칫하면 배보다 배꼽이 더 클 수도 있기 때문이다. XML 파싱 부분은 보통 전체 응용의 극히 일부분이다. 이를 위해 수십 센트에서 수 달러의 로열티를 기꺼이 내리라 생각하기는 어렵다.

기존에 나와 있는 기술 중 충분한 효율을 보여주는 MPEG BiM 같은 규격은 특허와 그에 따른 로열티 때문에 상대적으로 널리 받아들여지지 못한 대표적인 예다. 최근 많은 MPEG 및 방송 관련 규격에서 데이터를 기술하기 위해 XML을 사용하고 있다. 재미있는 것은 많은 경우 MPEG BiM을 인코딩 방법의 하나로 선택한다는 점이다. 이렇게 보면 널리 받아들여진 것 같지만 대부분의 규격에서 GZIP으로 압축한 XML 또한 기본 인코딩 방법으로 허용하는 터라 실제 구현에서는 로열티 부담이 있는 BiM을 아예 구현하지 않는 경우가 대부분이다.

물론 아직 완성되지 않은 EXI에 대해서는 추후 특허 문제가 발생하지 않는지 아직 더 지켜볼 필요가 있다. 다만 W3C 멤버는 특허를 가지고 있다는 사실을 감추고 추후 로열티를 요구할 수 없게 되어 있고, 지금까지 알려진 관련 특허를 가지고 있는 AgileDelta나 BiM 규격에 대한 특허를 가지고 있는 것으로 알려진 Expway 같은 회사가 모두 EXI에 들어와 있는 상황이니 그나마 나은 편이기는 하다.

여담이지만 W3C 내에서 특허 문제가 별로 없을 것 같지만 실제 문제가 되는 경우도 있다. 일례로 XML 문서의 내용을 갱신하기 위한 DOM 레벨 3 이벤트를 원격으로 전달하기 위한 W3C 표준 규격인 REX(Remote Events for XML)의 경우 W3C 멤버인 프랑스 텔레콤의 특허 주장으로 규격 제정 중 특허 검토에 들어가 있다. 참고로 이 멤버는 MPEG 규격과 관련해서 해당 특허를 출원했다. 사실 상식적으로는 원격으로 명령을 보내서 XML 문서를 변경하는 게 무슨 특허인가 하는 생각이 들지만 실제 문제가 되는 것이 현실이다.

XML에 맞춘 범용 인코딩의 필요성
다른 바이너리 인코딩도 모두 XML을 위한 인코딩이라 이야기하는 마당에 “XML에 맞춘 인코딩”을 만든다는 것이 다소 이상하게 들릴지 모르겠지만 기존에 나와 있는 규격은 XML 견지에서 봤을 때는 문제점을 가지고 있다. 몇 가지를 정리해 보면 다음과 같다.

• 제한된 시나리오에서만 적용 가능: 실제 XML은 스키마가 없이 사용되기도 하고 한 문서 내에서도 부분적으로만 스키마를 쓰는 경우도 있다. 하지만 WBXML은 특정 XML 응용(WML, SYNCML 등) 내의 엘리먼트나 속성에 대한 코드를 미리 정해놓아야만 사용할 수 있다. 또 BiM은 스키마가 있어야만 사용할 수 있다.
• XML에 최적화되지 않은 인코딩: WBXML은 텍스트 형태의 XML을 바이너리 형태로 기본적인 1:1 대응을 시키는 구조라 그저 긴 문자열을 미리 정한 짧은 코드로 대체하는 것뿐이다. 스키마를 활용하거나 XML의 구조적인 특성을 고려한 최적화를 하지 않는다. 또, Fast Infoset은 기존에 있던 ASN.1을 활용한 규격이라서 비교적 효율이 괜찮기는 하지만 XML만을 위한 규격은 아니므로 XML의 특성을 고려한 최적화가 부족하다. 특히 스키마가 없는 경우는 미리 정해진 ASN.1 스키마를 활용하므로 효율은 더 떨어진다.

물론 EXI 1.0이 순수하게 기술적인 관점에서 궁극의 솔루션이 된다는 것은 아니다. 현재 EXI 1.0에서 고려하고 있지 않은 특성을 다른 규격에서는 지원하는 경우도 많다. 예를 들어 BiM에서는 스키마가 필수지만 새로운 스키마를 인코딩해 상대편에 보내는 방법도 정의하고 있고, 명시적으로 XML 문서를 조각 내서 각기 전송하고 받는 쪽에서 조합하는 방법을 정의하고 있기도 하다. 하지만 범용성과 XML에 최적화하는 점, 널리 수용될 수 있도록 로열티 문제를 해결하는 등의 측면에서 EXI는 주목할 만하다.

EXI 진척 상황

EXI에 대해 본격적인 작업은 2006년 3월 기여 요청(Call for Contributions)을 하면서 시작되었다. 그 결과 Fast Infoset, Efficient XML(AgileDelta, Inc.), Xebu(헬싱키 대학), XSBC(Web3D), FXDI(후지쓰 소프트웨어), esXML(High Performance Technologies, Inc.) 등이 제안을 했고, 이전 XBC(XML Binary Characterization) 그룹에서 만들어낸 평가 항목과 방법에 기반을 두고 Efficient XML을 EXI 1.0의 기반 규격으로 삼기로 결정했다.

그 후 EXI 1.0의 최초 초안이 2007년 7월 공개되었다. . EXI 1.0 초안은 현재 2007년 12월, 2008년 3월 두 차례 개정되었고, 2007년 12월에는 EXI 입문서(Primer)와 EXI 모범 사례(Best Practice) 초안이 나왔다. 사실 단순히 나중에 EXI 프로세서(인코더/디코더)를 사용할 사람이라면 EXI 모범 사례 정도만 읽으면 충분할 것이다.

현재 EXI 1.0의 기본이 된 Efficient XML의 성능에 대해서는 관련 EXI 문서에 나와 있다. 사실 자신이 사용할 XML 문서에 직접 EXI를 적용해 보는 것만큼 피부에 더 빨리 와 닿는 방법은 없겠지만, 평가 결과를 보면 다양한 특성의 XML 문서에 대해 어떤 효과가 있는지는 감을 잡을 수 있을 것이다. 참고로 Efficient XML은 많은 경우 XML을 GZIP으로 압축한 것보다도 작다. 하지만 차이가 크지 않은 경우라도 잊어서는 안 되는 점은 GZIP의 경우 압축을 풀고 다시 텍스트를 파싱해야 하는 등 부하가 비교할 수 없을 만큼 크다는 점이다.

위로

대체 어떻게 작아지고 처리가 빨라지나요?

EXI가 XML을 어떻게 인코딩하는지를 이해하려면 EXI 입문서를 보면 많은 도움이 된다. 어차피 대부분의 독자가 EXI 프로세서를 직접 만들 것은 아니니 여기서는 입문서에 나오는 내용보다 더 간단히 원리만 짚고 넘어가자.

사실 EXI뿐 아니라, BiM 같은 다른 바이너리 인코딩과, XML 스키마와 비슷한 목적으로 프로토콜 설계에 사용되어 온 ASN.1을 바이너리 인코딩할 때도 다들 비슷한 원리를 활용한다. 우선 어떤 기본 원리가 있는지부터 살펴 보자.

• 엘리먼트/속성 이름, 값 등에서 반복되는 문자열을 짧은 코드로 표현 - WBXML 같은 아주 기본적인 바이너리 인코딩에서는 이 방법만 사용한다.
• 코드를 할당하는 데 있어서 빈번히 나타날 것으로 추정되거나 실제 빈번히 나타나는 쪽에 더 짧은 코드를 할당
• 스키마가 인코딩하는 쪽과 디코딩하는 쪽 모두에 알려져 있다고 가정하고 스키마가 표현하는 구조적인 특성을 이용해 스키마에 표현되어 있는 내용은 문서에서 제외 - 예를 들어 특정 엘리먼트 내에 A 엘리먼트가 나오고 그 다음에는 B, C 엘리먼트 중 하나가 나와야 한다는 것을 알면 인코딩한 문서에는 A 엘리먼트 자체가 있다는 사실 자체를 기록할 필요가 없다. 하지만 그 다음에 B, C 중 하나가 나타나야 한다는 것은 알고 있으므로 이 경우는 1비트로 다음에 B가 오는지, C가 오는지를 아주 간결하게 표현할 수 있다.
• 스키마에 표현된 데이터 형식을 이용, 문자열을 숫자나 날짜 같은 데이터로 해석해 더 간결한 바이너리 표현으로 기술 - 일례로 65535는 ISO-8859-1로 표현하면 5바이트지만, 부호 없는 정수라는 것을 알면 16비트, 즉 2바이트면 표현 가능하다.

여기에 EXI는 인코딩하는 대상이 XML이라는 사실을 고려해서 최적화를 한다. 이제 위의 기본 원리를 기본으로 EXI가 XML을 효율적으로 인코딩하기 위해 어떤 전제를 세우고 있고 구체적으로 어떻게 인코딩하는지를 살펴보자.

XML 데이터가 아닌 정보 집합(information set)에 명시된 정보를 인코딩 대상으로 한다
일반적으로 데이터 자체에는 고유 엔트로피(entropy)가 있어 어느 이상 크기를 줄일 수는 없다. 그 한계를 넘어서려면 정보 자체를 줄이는 수 밖에 없다. 당연하지만 생략할 정보는 사용하는 쪽에서 봤을 때 무의미하거나 중요도가 낮아야 한다. 이런 손실 압축을 사용하는 대표적인 경우가 JPEG 같은 손실 이미지 압축이나 가청 주파수만을 선택적으로 압축하는 오디오 압축 기술이다.

EXI에서는 XML이 가지고 있는 모든 데이터를 그대로 인코딩하기보다는 효율을 높이기 위해 XML 정 보 집합(XML Information Set)에 정의된 정보를 인코딩 대상으로 한다. XML에 관련된 규격은 대부분 XML 자체보다는 XML 정보 집합에 정의된 정보만을 활용하므로 충분히 의미 있는 생략이라고 할 수 있다. 예를 들어 XML에서 속성 값을 둘러싸는 데 홑 따옴표(‘)를 쓸 수도 있고 겹 따옴표(“)를 쓸 수도 있는데 정보 집합에서 이 둘을 구분하지 않으므로 이런 데이터는 인코딩 과정에서 사라진다.

충실도 지정을 통해 보존하지 않을 정보를 추가로 제외할 수 있도록 한다
EXI는 인코딩 시 충실도(fidelity)를 다음처럼 지정할 수 있도록 하고 있다. 다음 표를 보면 알겠지만 일반적인 경우 없어도 크게 문제가 없는 정보다. 그런 이유로 EXI 1.0에서는 특별히 지정하지 않으면 아래 언급한 모든 정보를 보존하지 않는다.

물론 예외도 있다. EXI 모범 사례에서 나오는 것처럼 암호화(Encryption) 및 서명(Signature) 같은 규격은 정보 집합 이외의 정보에 영향을 받는다. 정규화(canonicalization)를 적용하고 일부 충실도 옵션을 켜 주어야 한다.

FA(Finite Automaton) 사용
FA는 흔히 regex라고 알려진 정규식을 실행하는 데 사용되는 수단으로 EXI는 물론이고 BiM 등 스키마 정보를 활용하는 인코딩 방법에서 많이 쓰는 방법이다(참고로 우리가 사용하는 정규식은 엄밀히 FA로 처리할 수 없다. ‘()’를 이용한 그룹 기능을 구현하려면 그보다 더 복잡한 pushdown automaton이 있어야 한다). 다음 그림은 EXI 입문서에서 추출한 것이다.

EXI는 XML 문서를 SAX(Simple API for XML) 파서로 파싱할 때처럼 일련의 이벤트로 인지한다. 위에서 SE는 엘리먼트 시작을 나타내고 AT는 속성을 나타낸다. EE는 엘리먼트의 끝이다. 이 경우는 스키마가 있는 경우인데 다음은 스키마 부분에 대한 FA다.

<xs:element name="note">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="subject" type="xs:string"/>
      <xs:element name="body" type="xs:string"/>
    </xs:sequence>
    <xs:attribute ref="date" use="required" />
    <xs:attribute name="category" type="xs:string"/>
  </xs:complexType>
</xs:element>

풀어 보면 note라는 엘리먼트 내에 subject와 body 엘리먼트가 순서대로 나온다. 여기에 note 엘리먼트는 date라는 필수 속성과 category라는 선택 속성을 가진다. 여기서 각 상태별 이벤트(연결선으로 표시)에는 짧은 코드가 할당되는데 이 코드는 1~3개의 부호 없는 정수다. EXI는 일반적인 XML의 특성(예를 들어 엘리먼트가 PI보다는 많다는 특성)이나 스키마로부터 얻은 정보에 따라 통계적으로 많이 나올 것 같은 이벤트에는 짧은 코드를(즉 정수 하나로 구성), 덜 나오는 이벤트에는 긴 코드를 할당함으로써 인코딩 효율을 높인다.

실제 인코딩은 초기 상태부터 인코딩할 이벤트가 들어 왔을 때 그 이벤트가 표시된 화살표를 따라 다음 상태로 가면서 따라간 연결선에 할당된 코드를 출력하는 방식으로 이뤄진다. 여기서는 note라는 엘리먼트의 내용만을 표현한 것이지만 XML 문서는 하나의 FA로는 다 표현할 수 없다. 따라서 다른 하부 엘리먼트의 내용을 인코딩하는 경우 필요에 따라 현재 FA를 스택에 푸시하고 새로운 FA를 사용하고, 하부 엘리먼트의 인코딩이 끝나면 나중에 다시 끄집어 내는 방식으로 여러 개의 FA를 이용해서 인코딩을 해야 한다.

이 FA에서는 각 상태(원으로 표현)에서 나타날 수 있는 이벤트가 명기되어 있는데 StartTag3 상태의 경우 사실 무조건 Element1 상태로 옮겨가므로 인코딩할 때는 그 사실을 기록할 필요조차 없다. StartTag1 상태에서는 속성에 category가 있나를 표시해야 하므로 1비트가 필요할 것이다. 이처럼 각 상태마다 밖으로 나가는 선의 수가 한정되어 있으므로 선의 수를 나타내기 위한 최소한의 비트만 있으면 다음 일어나는 이벤트가 뭔지를 나타낼 수 있다.

스키마가 없거나 스키마와 차이가 있는 경우의 FA 사용
보통 FA를 사용하는 인코딩 방식은 스키마가 있는 경우에만 사용하는 것이 보통이다. EXI 1.0은 스키마가 없는 경우에도 FA를 사용한다. 기본적으로 기본 문법(built-in grammar)을 사용하고, 이를 문서를 처리해 가면서 동적으로 변경해 나간다. 다음 그림은 EXI 입문서에서 발췌한 내용으로 스키마가 있는 경우와 마찬가지로 FA 형태로 나타낸 것이다.

여기서 AT(*)나 SE(*)는 임의의 속성이나 엘리먼트를 나타내는 이벤트로 실제 인코딩할 때는 이벤트 코드는 물론이고 속성이나 엘리먼트 이름을 명시적으로 기록해야 한다. 반면 AT(category)처럼 이름이 나오는 경우는 해당 이름의 속성 혹은 엘리먼트를 만나는 이벤트를 나타낸 것으로 인코딩할 때는 코드로 표현되고 이름을 문자열로 기록하지 않아 간결하다.

먼저 이 그림에서는 맨 아래 문서 전체(DocContent)를 나타내는 FA가 있고 거기서 notebook이라는 엘리먼트 내부를 나타내는 FA를 사용했다가 다시 note 엘리먼트를 나타내는 FA가 사용되고 있는 상황이다. Note 엘리먼트에 대한 처리가 끝나면 다시 notebook 엘리먼트를 위한 FA의 상태로 돌아간다.

다시 note 엘리먼트의 내용을 나타내는 맨 위 FA로 돌아와 보면, 이 FA는 처음에는 SE(*)와 AT(*)처럼 지극히 일반적인 이벤트만 처리할 수 있다. 하지만 특정 엘리먼트나 속성을 한번이라도 만나면 거기에 대한 SE나 AT를 추가하므로(붉은 색), 해당 엘리먼트나 속성이 다시 나올 때는 간단한 코드로 나타낼 수 있다. 즉 ZIP 같은 압축 알고리즘처럼 문서를 처리하면서 문서 구조에 점진적으로 적응하면서 인코딩을 한다. 스키마가 없는 XML 문서라도 note라는 엘리먼트에 date라는 속성이 있었다면 나중에 다시 note라는 엘리먼트를 만났을 때는 date가 다시 나올 가능성이 높다.

문맥에 따른 문자열 인코딩
EXI는 문자열을 처리하는 데 있어서도 아주 영리한 방법을 사용한다. 일반적으로 문자열 중복을 막는 가장 쉬운 방법은 문자열 표를 만들어 놓고 새로운 문자열을 만나면 표에 등록하고 새로운 코드를 할당하고 그 다음부터는 같은 문자열은 할당한 코드를 할당하면 된다. EXI는 한 단계 더 나가 현재 인코딩하는 위치, 즉 어떤 엘리먼트 아래인지 등에 따라 같은 문자열이라도 더 짧은 코드를 할당하려고 노력한다. 다음 그림은 EXI 입문서에서 발췌하였다.

항상 문자열을 만나면 먼저 현 문맥(오른쪽의 date, category, body, subject 등의 엘리먼트 혹은 속성에 해당)에서 이전에 같은 문자열이 나타났는지 살펴본다. 만약 이미 있으면 문자열 표 전체를 대상으로 할당한 코드(왼쪽의 3비트)에 비해 짧은 코드(0~1비트)를 사용할 수 있다. 만약 없으면 표 전체를 대상으로 해당 문자열이 있는지를 검사한다. 보통 특정 문자열은 특정 속성 값으로 반복되는 경우가 많으므로 더욱 효율적인 인코딩이 가능하다.

압축
지금까지 이야기한 인코딩 자체가 효율 높은 압축이기도 하지만 EXI는 기존 GZIP 같은 압축 방법을 추가로 활용할 수 있는 여지도 열어 놓았다. 예를 들어 문자열만 따로 모아 압축해도 분명히 크기가 줄어들 것이다. EXI는 자바 클래스 압축에 사용되는 Pack200 형식과 비슷하게 바이트 단위에 최적화되어 있는 압축 알고리즘을 적용하기 쉽도록 하고 비슷한 형태의 데이터를 압축 전에 연속된 공간에 모으는 방식으로 압축 효율을 높인다. 다음 그림은 EXI 1.0 초안에서 발췌한 것으로 압축 과정을 나타낸 것이다.

대략 설명하면 그 과정은 다음과 같다.

• 1. 먼저 그림에서 보듯이 EXI 이벤트를 정해진 크기의 블록으로 나눈다. 문서 전체를 대상으로 하지 않는 것은 스트리밍이 가능한 속성을 버리지 않게 하기 위한 것이다.
• 2. 각 블록 내의 이벤트를 재배치해 연관 있는 것끼리 모아 채널들을 형성한다. 첫 채널은 문서 구조를 나타낸 정보만 담고 있고, 나머지 채널은 같은 속성이나 엘리먼트에 해당하는 값을 각기 모은 것이다. 같은 속성이나 엘리먼트 내의 값은 비슷할 여지가 높으므로 압축 알고리즘이 압축 효율을 더욱 높일 수 있다.
• 3. 너무 짧은 채널끼리는 묶어 압축 효율을 높인다.
• 4. 각 채널을 압축한다.

위로

텍스트 시대의 종말인가?

앞서 언급한 바 있지만 바이너리 형식이 텍스트 형식에 비해 무조건 좋은 것은 아니다. 전자 문서의 경우처럼 애당초 텍스트가 핵심 정보인 문서도 있고, 사람이 편집하거나 살펴볼 일이 종종 있는 경우도 많다. 결국 성능이나 대역폭, 저장 공간 문제가 없는 경우 굳이 애써 바이너리 인코딩을 사용할 필요는 없다. 예를 들어 Ant 빌드 스크립트나 애플리케이션의 옵션 정보를 저장해 놓은 XML 파일을 바이너리로 인코딩할 필요는 없을 것이다. 이미 앞서 개괄적인 내용은 언급했지만 EXI를 사용하면 좋을 것으로 기대되는 분야는 다음과 같다.

• 고속 메시징이 필요한 경우: .NET이나 자바의 경우 XML 웹 서비스를 주창하고 상호 운영 시험까지 하면서도 성능 문제로 .NET 리모팅에는 SOAP 이외의 별도의 바이너리 인코딩을 지원하고 있으며 썬은 Fast Infoset을 사용하고 있었다. 이 경우가 EXI로 가장 득을 볼 수 있는 분야가 될 것이다.
• 무선망이나 방송망을 통한 데이터 전달: 무선망은 대역폭이 낮고 패킷 단위 과금이 일반적이라 데이터 크기에 민감하다. 또한 방송망은 단방향이라는 특성 상 반복 전송을 통해 신뢰성 있게 데이터를 전달하므로 절대 대역폭에 비해 실제 대역폭은 무척 제약이 있다. 특히 방송망은 보내는 쪽과 받는 쪽(수신기) 간의 규약이 엄격하게 정해지므로 스키마를 공유한 상태에서 EXI를 활용하면 더욱 좋은 성과를 얻을 수 있을 것이다.
• 자원이 제약된 장치에서 사용: 메모리나 CPU 면에서 제약이 많은 휴대전화, STB 등의 장치에서는 크기도 작고 처리하는 부하가 적은 EXI가 많은 이점을 줄 것이다. 만약 이런 장치가 텍스트 형태의 XML을 쓰는 서버에 접속하려고 한다면 중간에 EXI 인코딩/디코딩을 담당하는 프록시(proxy)를 둘 수도 있을 것이다.

이처럼 EXI가 일반화되면 메시징은 물론이고 기존에 대역폭이나 자원 제약 때문에 바이너리 형식을 고안해 사용하던 많은 분야에서 XML로 넘어오는 좋은 계기가 될 것으로 보인다.

마치면서

이번 글에서는 조용히 표준화가 진전되고 있는 EXI에 대해 살펴 봤다. 개인적으로는 방송 관련 일을 하고 있기 때문에 지상파 DMB나 DVB-H 등에서 XML을 활용하는 과정에서 GZIP으로 압축한 XML의 한계를 늘 보아 왔던 터라 더욱 관심이 가는 부분이었다. 로열티 문제가 해결된 EXI가 나오면 XML 순수론자들의 우려에도 불구하고 메시징이나 방송/무선망을 통한 정보 전달 등 많은 부분에서 EXI가 활용될 것으로 기대한다.

그리고 매번 XML에 대해서 살펴 보면서 느끼는 것이지만 XML만큼 형이상학적인 논쟁이 많은 기술이 또 없는 것 같다. XML의 바이너리 인코딩을 살펴 보면서 이러한 논쟁에 대해서도 객관적이고 다양한 시각을 가져볼 수 있었으면 더욱 좋을 것 같다.

mar.gar.in

naver

eolin

del.icio.us

위로

[지난 developerWorks Column 보기]