한빛출판네트워크

저자: 켄달 그랜트 클라크(Kendall Grant Clark), 역 전순재

대부분의 전문서, 튜토리얼, 또는 프로그래머들을 위한 XML 처리에 관한 논의에서 그냥 지나가는 주제라고 할지라도 XML을 처리하는 두 개의 뛰어난 API인 DOM과 SAX는 반드시 언급되는 주제 중에 하나이다. 일반적으로 XML 프로그래밍을 논의하면서 DOM과 SAX를 생략한다면 이것은 마치 전제군주의 신하가 왕실에 들어가면서 왕과 왕비를 알아보지 못하는 근무태만과도 같은 것이다. 군주를 알아 보지 못하는 행동은 절대 있을 수 없는 일이 아닌가?

왕족을 의무적으로 인지하도록 허용된 형태가 고도로 의식화되고 관습적인 것처럼, DOM과 SAX 역시 관습적으로 소개되는 형태가 똑같다. 이미 소개에서 보았듯이 DOM은 XML 실체의 표현을 메모리 안에 구축하는 트리 기반의 API라는 설명을 듣게 될 것이다. 마찬가지로 SAX는 사건 주도형 API이며, XML의 메모리 내 표현을 구축하기 보다는 XML 실체의 특정한 측면을 연속적으로 마주할 때마다, 사건 처리자들을 호출한다. 이렇게 고도로 경직화된 이야기가 주는 교훈은 변하지도 않는다. 사람들은 종종 DOM 파싱(parsing)을 원하지만 XML 실체의 크기가 시스템 메모리를 초과하는 경우에는 SAX가 도움이 된다.

사람들은 실무 경험을 가진 능력있는 프로그래머들이 완전히 XML을 마스터 하지는 않았을지라도 DOM과 SAX를 상당 부분 이해하고 있으리라 가정한다. 그리고 전문가 청중들은 광범위한 능력을 이미 가지고 있기 때문에 DOM과 SAX에 대해 더 이야기할 만한 재미있는 일이 남아 있지 않을 것이라고 생각한다. 그러나 XML-DEV 토론에서 볼 수 있듯이, 상황은 항상 변하기 마련이다. 사람들이 논리적으로 가정하는 것처럼 되지도 않고, 또 사람들의 생각처럼 항상 순수하게 기술적인 면만 파고드는 것도 아니기 때문이다.

실제로 사용되는 DOM과 SAX

논의는 렌 불라드(Len Bullard)가 게시한 질문에서 촉발되었다.

SAX가 더 적절한 작업에 DOM을 사용하는 것을 얼마나 자주 목격하곤 하는가? 그 사람들에게 왜 그런지 물어보면 그들은 무어라고 말하는가? 엉뚱한 API를 선택한 대가는 무엇인가?

너무나도 간단한 문제이다. 그러나 불라드(Bullard)는 다음과 같은 아주 특별한, 약간은 흥미로운 문제를 제기한다. 함께 일하고 있는 프로그래머들이 DOM에 너무 의존하고 있지는 않은가? SAX가 더 적절한 경우에도 어떤 경우에는 DOM을 사용하고 있지는 않은가?

불라드(Bullard)의 질문에 모두가 일치된 응답을 보이는 것을 보면 그가 아주 꼭 맞게 질문한 것을 알 수 있다. 대부분의 응답자들은 경험이 부족한 프로그래머들이 DOM을 혹사한다고 보고 있다. 이에 반해, 경험이 적은 프로그래머들이 SAX를 혹사한다는 그 반대의 의견을 보이는 사람은 아무도 없는 것 같다.

블라드(Bullard)의 질문에 재미있는 질문들이 꼬리를 문다. 왜 DOM은 혹사당하는데? SAX는 그렇지 않은가? 그리고 XML 처리 API의 미래는 어떤 모습일까? 등등.

SAX의 심리구조

불라드(Bullard)에 대한 다비드 헌터(David Hunter)의 답변은 중대한 현실을 암시하고 있었다. SAX는 어떤 프로그래머들에게는 어렵다는 사실이다.

많은 프로그래머가 실제로 이벤트(event) 기반의 프로그래밍을 사용하지 않는다. 그런데 SAX는 바로 이러한 이벤트 기반 프로그래밍이다. 프로그래머들은 이벤트 등이 건네짐에 따라 상황정보(context)를 추적 유지하는 것보다는 메모리 적재(in-memory) 객체 모델 환경에서 더 편안하게 작업한다.

헌터(Hunter)가 여기에서 언급하는 주제는 토론 내내 약간씩 변형을 더해 가면서 계속 반복되었다. SAX 처리의 이벤트 주도적 본성은 어떤 프로그래머에게는 불편하기 때문에 되도록이면 DOM 처리를 사용하는 듯하다.

이런 불편함을 여러 각도에서 진단한 여러 가지 결과가 제시되었다. 마이크 참피언(Mike Champion)은 다음과 같이 말했다.

이벤트 처리 패러다임은 대학을 졸업한 이후로 저수준의 문법/해석기를 다루어 보지 못한 대부분의 사람들에게 정말 생소한 것이다. 생각컨데 이러한 상황은 대다수의 전문 프로그래머들에게도 마찬가지일 거라고 생각한다. (어쩌면 내가 틀렸을 수도 있지만 ... 저수준의 GUI API들은 이벤트 주도적이다... 그러나 많은 사람들이 "OK/Cancel" 버튼 이벤트 처리자는 처리할 수 있겠지만, SAX 애플리케이션을 작성하는데 필요한 세부적인 사고력에는 압도당할 것이 분명하다.)

마이클 브레넌(Michael Brennan)은 이 점을 확장하여 SAX의 이벤트 처리적 본성 때문에 상태 기계(state-machine)로 프로그래밍을 하게 되는데, 이 역시 어떤 프로그래머들에게는 상당히 프로그래밍하기 어렵게 느껴진다.

...[여]기에서의 어려움은 그저 이벤트 기반 프로그래밍을 이해하는데 있는 것이 아니라, 오히려 한 컴포넌트의 디자인을 상태-기계(state-machine)로 개념화하는데 있다. 내가 목도한 바로는 어떤 이유에서든 간에 많은 프로그래머들이 그러한 용어들을 습득하는 것을 어렵게 생각한다는 것이다.

그렇기 때문에 어떤 프로그래머들에게 SAX의 이벤트 주도적 본성과, 그리고 SAX가 필수적으로 요구하는 개념적 방법이 당황스러운 것이다. 그리고 물론 그 반대편은 마이크 케이(Mike Kay)가 재차 강조하였듯이 프로그래밍 흐름을 개념화하는 방식에는 훨씬 더 친숙한 DOM 처리가 더 적합한 것 같다. 다음과 같이 케이(Kay)는 언급한다.

대다수의 미숙한 프로그래머들이 편안하다고 느끼는 유일한 모델은 명령적인(imperative) 항해 스타일일 것이다. 명령적인 항해 스타일에서는 프로그램이 통제 하에 있으며 다른 하부시스템에 요청을 보낸다. 그것은 통제된 것으로, 프로그래머가 하는 일은 컴퓨터에게 다음으로 할 일이 무엇인지 명령하는 것이라고 생각하는 것이다.

어쩌면 어떤 프로그래머들에게는 이벤트(event)와 상태 머신(state machine)이 편안하게 느껴질 수 있지만, SAX는 자신이 가진 많은 장점과 매력에도 불구하고, 상당히 엄격한 인터페이스이다. 밥 허친슨(Bob Hutchinson)도 똑같이 지적한다.

나는 SAX가 나와 함께 일하는 프로그래머들에게 쉽지 않은 것임을 알았다. 심지어 구이(GUI)에 대한 폭넓은 경험이 있는 프로그래머들에게 조차도 말이다... 그리고 SAX에 관하여 배우고 난 후에도 언제나 그들은 어떻게 처리해야 할지 잘 몰랐다. 이것이 전적으로 그들의 잘못이라고 할 수는 없다. 우리는 멋진 프레임워크(frameworks)을 가지고 구이(GUIs)가 만들어 내는 이벤트들을 처리할 수 있다. 내가 아는 한 SAX에는 그러한 프레임워크가 전혀 없다. 개발자들이 사건의 흐름과 마주치지만 그 이벤트들을 처리할 프레임워크가 전혀 없는 것이다. 몰론, 나도 안다. 여러분은 즉시 무언가를 조립할 수 있고 나도 수 년간 그렇게 해왔지만, 모두가 다 그런 것은 아니다.

SAX가 불편한 이유 두 가지가 토론 중에 제기되었다. 미경험(inexperience)과 심리학적(psychology) 측면에서 말이다. 많은 사람들은 SAX가 어렵다고 생각하는데 그 이유는 SAX가 새로 탄생한 것이고 가끔씩 사용하는 것이기 때문이다. 이제 더 이상 새로운 것이 아님에도 불구하고, 많은 사람들이 SAX를 어렵게 생각하는 이유는 SAX가 사람들이 쉽게 친숙하게 느끼지 못하는 일종의 개념화를 요구하기 때문이다. 여기에는 옳고 그름이 없다. 단지 사람들의 두뇌는 다양하게 돌아간다는 잘 알려진 사실이 있을 뿐이다. 사람들은 다른 분야에서는 이 사실을 아주 잘 알고 있다. 그리고 이것이 컴퓨터 프로그래밍에도 적용된다는 사실은 별로 놀랄만한 일은 아니다. 예를 들어 스킴(Scheme) 그리고 재귀 함수들과 한바탕 전투를 치루어 본 사람이나, 혹은 그런 사람들을 도와본 적이 있다면 누구라도 서로 다른 프로그래밍 패러다임은 종종 다른 종류의 개념화 능력이나 경향을 필요로 한다는 사실을 부인할 수 없을 것이다. 미쉘 로드리게쯔(Michel Rodriguez)는 이 점을 다음과 같이 산뜻하게 요약한다.

내가 알고 있는 대다수의 프로그래머들이 SAX 처리보다 DOM류 (트리지향의) 처리를 훨씬 더 쉽게 이해하는 것 같다. 문서를 "통제하는 것"이 더 쉽다고 느끼며 코드를 제멋대로 하도록 놓아 두기 보다 그것에 영향을 미치는 것이 더 쉽다고 느낀다.

by Kendall Grant Clark

DOM의 사회적 점유율

렌 불라드(Len Bullard)가 자신이 제시한 질문에 대해 덧붙인 설명을 들어보면, 왜 그가 그런 질문을 했는지 속마음을 들여다 볼 수 있다.

나는 이 주제를 흥미롭게 생각하는데 그 이유는 아주 조금 배운 사람도, DOM에 익숙해지고, DOM을 모든 것에 사용하는 것을 쭉 지켜보았기 때문이다... XML이 그 정도로 배우기 어려운가, 너무 복잡하며, 너무나 다른가, 그렇지 않으면 그저 수년간에 걸쳐서 코드를 복사하면서 기저에 숨은 것들을 보지 않은 결과로 그냥 고착화된 것 일뿐인가?

이 관점은 다른 방식으로 이 문제를 바라 보도록 만든다. (어떤 사람들에게는) SAX가 심리적 생소함이 있을 뿐만 아니라, DOM이 사회적으로 우세하다고 생각하기 때문이다. 결국 DOM은 바로 W3C가 축복한 XML 처리 API이다. DOM은 그 뒤에 있는 자원들을 교육하고 파는 방대한 기업차원의 시장이 있다.

불라드(Bullard)의 질문에 답변한 사람 중에는 그들이 알고 있는 XML 프로그래머들이 DOM은 잘 다루지만 SAX에 관해서는 전혀 모른다는 것을 암시하였다.

XML 세계에서 우세한 프로그래밍 플랫폼의 문제는 마이크로소프트사와 자바로 귀착된다고 여러 사람들이 언급했다. 둘 모두 이유야 어쨌든 간에 DOM 우호적이다.

마이클 브레넌(Michael Brennan)은 DOM이 아주 널리 사용되게 된 매우 중요한 이유를 다음과 같이 지적하였다.

MSXML은 어째서 많은 프로그래머들이 DOM을 사용하는지 그 이유를 보여주는 훌륭한 예이다. 마이크로소프트사의 DOM에는 XPath 지원이 통합되어 있다. 개발자들은 XML을 DOM 안으로 적재할 수 있으며, 그렇게 해주면 추적하고 있는 데이터를 XPath로 추출하여 쉽게 그 구조를 질의할 수 있다. SAX로 전환하고 나면 그 코드가 상당히 복잡해지며, 이제 어느 순간에나 문서에서 어디에 위치하고 있는지를 추적유지하는 상태 관리 전략을 처리해야만 한다.

나는 마이크로소프트 세계에 있는 많은 개발자들이 통합된 XPath 지원을 당연한 것으로 여기고 있으며, 그 지원이 표준 DOM의 사양이 아니라는 것을 (아직까지도) 깨닫지 못하고 있음을 알았다.

이것이 실제로 암시하는 바는 종종, 상당히 자주, XPath가 그 작업에 꼭 맞는 도구라는 것이며, (공식적이든 비공식적이든) DOM과 관련되어 중대한 역할을 한다는 것이다. 그러나 SAX를 더 널리 사용하기보다 DOM을 과도하게 사용하는 이유를 찾아 보는데 있어서, 우세한 클라이언트측 컴퓨팅 플랫폼, 우세한 웹 브라우저, 그리고 우세한 서버 플랫폼 중의 하나라는 사실이 마이크로소프트사 제품이라는 것을 과소평가할 수는 없다. MSXML는 세 가지 제품 모두에서 널리 사용되며, DOM과 XPath에 우호적이다.

XPath의 유용성을 보면 갖가지 XML 처리에 있어서 그의 역할이 당연히 앞으로 확대될 것이라는 것을 알 수 있다. 다시, 마이클 브레넌(Michael Brennan)은 누구보다도 명료하게 이 점을 지적하였다.

나는 요즘들어 dom4j, SAXPath, Jaxen 같은 것들을 아주 관심있게 살펴 보고 있다... [다]음과 같이 처리자를 등록하여 XPath에 기반한 하부트리들을 맡도록 한다는 사실을 인식하는 것은 아주 흥미로운 일이다. XPath를 객체 모델 사이의 접착제로 사용하여 인포셋 추상층(infoset abstraction)을 지원하도록 한다는 발상 역시 아주 흥미롭다. 우리는 그저 XPath의 이점을 활용하려고 흔히 XML을 DOM 안으로 적재한다. 우리는 XML 요소(elements)/속성(attributes)을 내부 데이터 구조와 기능에 XPath 표현식을 사용하여 짝짓기 하기 위한 도구들을 사용한다. DOM을 적재하지 않고서도 그와 똑같은 추상층과 구현의 용이함을 확보한다면 정말 좋을 것이다....

나는 이러한 종류의 접근법이 더욱 널리 인식되고 채택되기를 기대한다. Jaxen이 제공하는 종류의 추상층을 확보하는 것이, DOM(심지어 SAX도 역시)을 XML과 다른 객체 모델들 사이의 접착제로 고려하는 것보다, 결국 훨씬 더 큰 잠재력이 있다고 나는 생각한다.

오픈 소스 공동체에서, 종종 XML 프로그래밍은 자바 프로그래밍을 의미한다. 물론 Perl과 Python 그리고 다른 많은 오픈 소스 언어도 훌륭하게, 심지어 탁월하게 XML을 지원한다. 그러나 자바가 도구의 개수, 그러한 도구들에 대한 회사차원의 지원, 훈련 재료의 개수, 등등에 있어서 더 우위에 있다. 자바에서 SAX를 훌륭하게 지원하지만, 막상 자바 DOM 프로그래밍을 고려해야 할 상황에 부딪치면 풍요 속의 빈곤이란 단어가 떠오를 것이다. 밥 맥퀄터(Bob McWhirter)는 이 점을 다음과 같이 지적하였다.

오픈 소스 자바 세계에서, 초점은 주어진 객체 모델 보다 인포셋(infoset)에 더 초점이 맞추어 지고 있다고 생각한다. 보통의 DOM과 더불어 JDOM, dom4j, EXML이 있기 때문에, 그리고 오직 특정 유틸리티들만이 특정 모델에서 지원되기 때문에 (즉, Xalan는 dom4j 문서들에 직접적으로 작동하지 않는다), 한 모델에서 다른 모델로 번역할 일이 많이 남아있다.

그러면 dom4j의 ElementHandler 인터페이스와 같은 것들을 가지게 되고, 객체 트리를 처리하는데 익숙한 사람들이 이 인터페이스를 사용하면 아주 방대한 datasets을 적절하게 처리할 수 있다. 그리고 특별한 하부트리를 맡아줄 처리자(handler)를 등록할 수 있다. (XPath 표현식을 포함하여) 필요한 무엇이든지 처리하면 된다. 그런 후에 하부 트리들을 떼어내어, 남은 해석(parse) 처리를 위해 메모리를 놓아주면 된다....

나의 경험으로 보아, 그것은 단순히 DOM 대 SAX의 싸움이 아니라, 오히려 (때로는 같은 애플리케이션에 여러 개가 섞여 있는) DOM들과 SAX 사이의 경쟁이다. 그리고 일반적으로, dom4j의 하부 트리 메커니즘 덕분에 나는 유지보수하기 어려운 SAX 코드에 모험을 걸지 않아도 되었다.

간단히 말해, 자바로 XML을 처리할 때, 종종 DOM으로 작업을 할 이유가 기술적으로도 충분히 있다는 말이다. SAX 방식으로 처리하려면 (어떤 사람들에게) 추가로 부담이 되므로 회피하고서 말이다. 이런 풍부한 DOM 구현들이 자바 그 자체의 기술적 특징 덕분인지는 확실하지 않다. 그 보다는 서버측 인터넷 프로젝트에서 자바의 우세한 시장 점유율 덕분일 가능성이 더욱 높다. 서버쪽 인터넷 프로젝트는 XML이 자신의 유용성을 명백하게 보여주는 첫 번째 분야였다.

앞으로 나아갈 길

기술적인 요소와 사회적 요소 그리고 심리학적 요소가 이렇게 하나로 합쳐지면, DOM인가?, SAX인가?, 아니면 모두 다인가?, 그렇지 않으면 모두 아닌가?를 결정하는 문제로 인해 일반적인 설명으로 해결될 수 있는 것보다 훨씬 더 복잡해진다. 그 문제들은 단순히 메모리 사용법보다 훨씬 더 복잡하다.

그리고 전략적으로 중요한 결정이 될 수도 있는데, 밥 허친슨(Bob Hutchinson)은 다음과 같이 우리에게 주의를 환기시켜 준다.

잘못 선택한 결과는 무엇인가? 심각한 곤란에 봉착한다. 결국 여러분의 코드는 느리고, 보기 흉하고, 유지보수가 불가능한 결과로 끝나 버린다. 더 나쁘다면, 어떤 개발자들은 XML을 함께 사용하지 않기 위해 그런 결과를 초래하는 난잡함을 감수하기도 한다 (실제로 우리는 여전히 XML의 초기상태에 있다).

그렇다면, 마이크 참피언(Mike Champion)이 언급했듯이 앞으로 나아갈 길은 무엇인가? 자, 다른 어떤 독재 권력에도 항상 반독재 세력들이 흩어져 있는데, 왕과 왕비를 몰아 낼 그 때를 기다리면서, 필사적으로 국민들에게 대안을 제시하려고 한다. 왕정에서 그랬던 것처럼, XML 세계에서도 마찬가지로 그런 일이 일어난다. 여러 대안들이 DOM과 SAX에 대하여 언급되었다. 여기에는 XML 데이터 바인딩(binding), XML 풀 파서(pull parser), 그리고 트리(tree)와 이벤트(event)의 다른 조합, 메모리-적재(in-memory) 처리와 연속적(seriatim) 처리 등이 포함된다.

XML 개발 공동체는 우세한 패러다임에 기술적인 대안이 중요하다는 말에 귀 기울일 필요가 없지만, 때로는 그것을 상기할 필요도 있다. 나는 그것이 xml-개발 리스트가 가지는 미덕중의 하나라고 생각한다. xml-개발 리스트에서 똑같은 문제는 부서진 후 다시 또 부서지고 또 다시 부서지는 경향이 있다. 때로 토론은 그저 그런 쓸모없는 짓처럼 보일 수도 있지만, 또다른 접근법과 아이디어에 다시 불을 붙이는 심지가 될 수도 있기 때문에 아주 의미있는 일일 수도 있다.

마지막으로 반드시 기억해야 할 것은, 밥 허친슨(Bob Hutchinson)이 현명하게 지적했듯이 가끔 일어나는 기술적 지루함(ennui)에도 불구하고, 지금은 실제로 XML의 초창기라는 것이다. 세력을 점유하고는 있지만, DOM과 SAX는 각각 자신만의 결점과 단점을 가지고 있다. XML 개발자들이 결국 DOM과 SAX를 퇴출시킬 것이라는 것은 거의 확실하지만, 아마도 그렇게 하려면 미래의 고수준 XML 처리 API의 토대가 DOM과 SAX가 되도록 만드는 것이 유일한 방법일 것이다.

최근 토론에서 두 명의 참여자가 그 점을 정확하게 제시하였다. 그리고 그들의 말을 빌어 결론을 대신하겠다. 폴 치스토폴스키(Paul Tchistopolskii)는 새로운 고수준 API가 목전에 도래하고 있다고 예언하였다.

내 생각으로는 (SAX라고 불리는) 저수준 렉서(lexer)와 (DOM이라고 불리는) 저수준 모델(model)은 수명을 다했고 곧 더 높은 수준의 바인딩(bindings)이 이러한 저수준 APIs위에 (아니면 다른 API위에 나타나게) 나타나게 될 것이다.

개발자들에게 모든 코드를 SAX나 DOM API의 관점에서 코딩하기를 요구하는 것은 마치 어셈블리 언어로 프로그램을 작성하라고 그들에게 요구하는 것과 똑 같은 것이라고 나는 생각한다.

마이클 브레넌(Michael Brennan)도 원칙적으로 동의하였다.

전적으로 동의한다. DOM과 SAX는 총괄적인 XML 처리를 하는 애플리케이션들을 위한 영역이 될 것이다. 비즈니스 문제를 해결하려고 시도하는 개발자들은 XML 종속적인 모든 API들을 추상화 해놓은 도구들을 사용하게 될 것이다. 고수준 모델링 도구나 선언적인 짝짓기/변환 언어를 이용한 변환 테크놀러지를 사용하거나, 더욱 간단하고 더 친숙한 객체 모델 아래로 XML을 감추어 주는 데이터 바인딩 (data-binding) 기술을 사용하게 될 것이다.

DOM과 SAX는 처리해야 할 XML 문서들이 있는 동안 죽 군림해 왔다.이제 DOM과 SAX가 오래도록 살아 남아 더욱 더 강력하고 우아한 후손을 보게 될 것이라고 희망을 가져보자.