XML의 미래
미래의 XML은 어떤 모습일까?
Elliotte Harold, 교수, Polytechnic University
2008 년 3 월 04 일
Elliotte Rusty Harold가 XML 저장과 관련하여 자신이 생각하는 바를 예상합니다.
비록 느리지만 진보의 수레바퀴는 돌아간다. 마법의 수정구는 흐릿할지 몰라도 XML의 미래는 점차 윤곽이 드러나고 있다. 정확한 시기를 예측하기는 어려우나 적어도 목적지는 분명하다. XML의 미래는 웹, 구체적으로 웹 출판에 있다.
막 상 말하고 보니 웃기다. 웹과 출판은 동음이의(同音異意)가 아니던가? 애초에 웹 자체가 정보를 게시할 목적으로 생겨나지 않았던가? 출판 외에 웹으로 무엇을 할 수 있단 말인가? 아주 많은 일을 할 수 있다. 최근 3년 동안 기존 웹 사이트의 한계를 극복하는 웹 응용 프로그램에 대한 관심이 가히 폭발적으로 증가했다. 문서편집기, 스프레드시트, 게임, 다이어그램 그리기 도구 등 점차 많은 도구가 브라우저로 통합되고 있으며 이러한 추세는 웹 브라우저의 지역 저장소 기능으로 오프라인 작업이 가능해짐에 따라 앞으로 더욱 확산될 전망이다. 그러나 XML은 여전히 웹 1.0 출판에 뿌리를 두고 있으며 우리는 이 사실을 주목해야 한다.
올 해는 몇 가지 꿈이 이뤄질 전망이다. 네트워크 상에서 응용 프로그램을 배포하고 사용한다는 썬 사의 꿈이 한 걸음 현실로 다가왔다. 충격적이게도 현실에서는 응용 프로그램 언어로 자바(Java™)가 아니라 자바스크립트(JavaScript™)를 선택했지만 말이다. 10여전 전에도 충분히 실현이 가능했지만 경험과 비전과 클라이언트의 관심 부재로 썬 사는 진짜로 멋진 기회를 놓치고 말았다. 이제 회사는 '따라잡기'라는 필사적인 (그리고 실패할) 게임에 뛰어들어 고전 중이다.
브라우저로 운영체제를 대체하겠다는 넷스케이프 사의 꿈도 한 걸음 현실로 다가왔다. 넷스케이프 사는 미래를 내다보는 비전이 있었다. 하지만 불행하게도 원대한 비전을 실현할 비즈니스 능력과 예술적인 감각이 없었다. 그럼에도 불구하고 넷스케이프 브라우저의 직계 후손인 파이어폭스(Firefox)와 모질라 재단(Mozilla Foundation)은 이 용감무상한 신세계를 현실로 만들어 줄 핵심 주자로 활약 중이다.
젊고 민첩한 경쟁사가 자신을 집어 삼킬지도 모른다는 마이크로소프트(Microsoft®) 사의 악몽도 현실로 다가왔다. 회사는 썬 사와 넷스케이프 사에 정신을 파느라 구글이 오피스와 윈도우 시장을 넘본다는 사실을 알아채지 못했다. 지메일(GMail), 구글 독스(Google Docs) 등과 같은 응용 프로그램은 급속하게 기반 운영체제로부터 독립을 선언하고 있다.
물론 브라우저를 돌리려면 아직도 운영체제가 필요하다. 하지만 점차 운영체제 이름 자체는 무의미해지리라. 마이크로소프트 윈도우(Windows®) 운영체제가 돌아가는 한 아무도 PC 제조업체 이름을 신경쓰지 않았던 지난 10여년처럼 말이다. 이제는 구글이 돌아가는 한 아무도 운영체제 개발업체 이름을 신경쓰지 않는 시기가 다가왔다. PC가 그랬듯이 운영체제도 점차 일반재화가 되어가고 있다. 마이크로소프트 윈도우 왕국은 패배했다기보다 버려졌으며, 마이크로소프트 사는 빈 성문을 지키고 있을 따름이다.
 |
|
|
|
관 심과 이목을 한 몸에 받아온 기술치고 XML은 이 상황과 거의 무관하다. 혹자는 비동기 자바스크립트(Asynchronous JavaScript) + XML (Ajax)을 들먹이며 Ajax에서 x는 XML을 뜻한다고 주장할지도 모르지만, 실제 이 목적으로 XML을 사용하는 사람은 거의 없다. Ajax라는 약어가 출현함과 거의 동시에 웹 개발자들은 XML을 원시 자바스크립트 코드로 교체하여 데이터로 넘긴 후 eval()로 계산하기 시작했다. 보안 구멍이 훤히 뚫힌 셈이다.
문 제는 자료 형식이 아니라 API에 있다. 구체적으로 DOM(Document Object Model)이라는 API가 문제다. 대다수 개발자들은 DOM부터 배운 후 다른 대안을 배우지 못했다. DOM과 XML을 구분하지 않는 탓에 DOM에 대한 근거 있는 혐오와 XML에 대한 근거 없는 혐오를 혼돈한다. DOM은 최소의 공분모 API가 아니라 최악의 공분모 API다. 일부러 노력해도 DOM보다 못한 XML API를 설계하기 어려울 정도다. 그러나 개발자들은 새로운 기술을 배우기를 극도로 꺼린다. 자바 공동체 내에서는 JDOM과 dom4j가 다소 진전을 보였을 뿐이지만, 자바 공동체를 벗어나면 E4X와 아마라 XML 툴킷(Amara XML Toolkit)처럼 더 나은 대안이 존재한다. 그러나 이 대안들은 거의 알려지지 않았으며 대놓고 거부 당하고 있다. JSON(JavaScript Serialized Object Notation)이라는 천재적인 개념 역시 커다란 취약점이다. JSON은 실행 가능한 자바스크립크 코드이므로 자바스크립트 프로그래머 입장에서는 새로운 내용을 익힐 필요가 없다. 더욱 안전한 데이터 전송 방법이 있더라도 받아들이지 않는다.
|
|
DOM 은 XML 목에 걸린 맷돌이다. 소프트웨어 개발 분야가 XML을 폭넓게 활용하지 못하는 가장 큰 걸림돌이 DOM이다. 프로그래밍 측면에서 XML은 이 2000파운드짜리 닻을 질질 끌면서 나갈 만큼 나갔다. W3C(World Wide Web Consortium)와 브라우저 제조업체가 DOM을 이성적인 대안으로 교체하지 않는 한(되도록이면 이성적인 대안 여러 가지로 교체하면 좋겠다. 한 API로 모든 문제를 처리하려다가는 DOM짝이 나기 십상이다) XML은 소프트웨어 개발, 특히 (앞으로 점차 중요해지는) 웹 소프트웨어 개발에서 더 이상 앞으로 나가기 어렵다. W3C는 현장 개발자들의 필요를 인식하되 나쁜 명세는 반대해야 한다.
그래서 XML이 죽었느냐고? 천만의 말씀이다. 나는 XML의 미래가 밝고 중요하다고 믿는다. 단지 기존 소프트웨어 개발이나 웹 소프트웨어 개발과는 별다른 관련이 없다고 믿는다. 2008년도 이후에 XML이 움직일 방향을 이해하려면 먼저 1997년 이전으로 돌아가 XML의 기원을 살펴보자.
|
|
XML 은 결코 소프트웨어 개발에 사용하려던 언어가 아니었다. 적어도 초창기에는 그랬다. XML 1.0, XPath, XSLT(Extensible Stylesheet Language Transformation), XML 네임스페이스(XML Namespace), XHTML(Extensible Hypertext Markup Language), DOM 등 초기 명세를 살펴보면 어느 것도 소프트웨어 개발자를 염두에 두지 않았다. XML을 소프트웨어 개발용으로 만들었다면 JSON처럼 리스트와 맵과 다양한 자료 유형을 지원했으리라. XML은 출판, 좀더 구체적으로 웹 출판에 사용하려고 설계한 언어였다.
XML은 전자문서 출판을 목적으로 20여년 동안 사용해 온 기술인 SGML에서 나왔다. IBM®의 코드(Codd) 박사가 데이터를 순서 없는 작은 조각으로 나누어 구조화하는 방법을 깨달았던 바로 그 시기에 같은 IBM의 찰스 F. 골드파브(Charles F. Goldfarb), 에드워드 모셔(Edward Mosher), 레이몬드 로리(Raymond Lorie)는 표 형식으로 정리하기 불가능한 대규모의 정렬된 문서를 구조화하는 방법을 알아냈다. 코드 박사가 재고와 재정 기록같은 비즈니스 데이터를 고려한 반면, 골드파브와 모셔와 로리는 연간 보고서와 항공기 기술 매뉴얼같은 비즈니스 문서를 고려했다.
SGML은 출판 문제를 해결하려는 언어였다. 즉, 프로세서와 문자 집합과 자연 언어와 운영체제와 제조업체가 다른 여러 가지 플랫폼에 흩어진 수십만 장의 문서를 읽고, 쓰고, 보수하고, 고치고, 인쇄하고, 검색하는 방법을 제시하는 언어였다. SGML은 정부 기관과 군대에서 다소 성공을 거두었으며, 오라일리(O’Reilly)와 같은 일부 기술서 출판사가 때때로 사용했을 뿐 일반인들이 사용하기에는 너무 무겁고 복잡했다. 심지어 출판 업계 사람들조차도 꺼릴 정도였다.
SGML의 가장 큰 성공이자 가장 큰 실패는 HTML이었다. 애초에 HTML은 SGML 응용 프로그램으로 출발했으나 브라우저나 편집기나 웹 페이지를 개발하는 사람들 누구도 SGML이 Standard Generalized Markup Language를 줄인 말이라는 사실 외에 SGML에 관해 아는 바가 없었다(이 사실조차 모르는 사람도 많았다). 결국 무질서한 확장으로 말미암아 HTML이 SGML 구조를 따라야 한다는 주장은 급속히 힘을 잃어갔다. 심지어 1996년 당시 존재했던 몇 안 되는 고가 SGML 도구도 실제 사용 중인 HTML의 난잡한 내용을 인식하지 못할 정도였다.
바로 이런 난국을 타계하고자 XML이 나왔다. 다른 한 편으로 SGML을 합리적으로 단순화하여 모두가 충실하게 지킬 표준 부분집합을 만들려는 목적이 있었다. SGML보다 단순한 명세로 SGML보다 널리 받아들여지리라 여겨졌고, 이 점에서 XML은 대체로 성공을 거두었다.
다른 한 편으로 XML은 브라우저 간 호환성 문제와 특이성을 줄이고 형식이 갖춰진(well-formed) 웹을 유도하려는 의도였는데 이 점에서 XML은 대체로 실패를 맛보았다. 엉망진창인 태그 짬뽕을 교체하기는 커녕 XML과 XHTML은 브라우저가 처리해야 할 또 다른 HTML 사투리가 되고 말았다.
성공이든 실패든 XML은 책, 매뉴얼, (가장 중요하게) 웹 페이지를 출판할 목적으로 만들어진 언어다. 소프트웨어 개발에 사용할 의도도 아니었고 소프트웨어 개발에 맞게 최적화되지도 않았다. 환경 설정 파일, 원격 프로시저 호출, 개체 직렬화, 데이터베이스 덤프, 기타 객체 지향 작업을 수행하리라 예측하지도 계획하지도 않았다. 그러니 XML이 이런 잡무에 100% 적합하지 못하더라도 놀랄 일이 아니다. 그럼에도 불구하고 XML은 개발자들에게 이제껏 없었던 가능성을 보여주었다. 플랫폼 독립적이고, 언어 중립적이고, 국제화가 쉬운 자료 형식에다 우수한 공짜 구문 분석기를 구하기도 수월했다. 정수나 부동소수와 같은 자료 유형과 리스트나 맵과 같은 기본 자료 구조가 없다는 단점에도 불구하고 프로그래머들은 이러한 장점을 거부하기 어려웠다.
그러나 프로그래밍은 XML이 원래 의도했던 목적이 아니므로 프로그래밍 언어로서 XML을 판단해서는 안 된다. 프로그래밍 언어로서 강점을 찾거나 가능성을 점쳐서도 안 된다. XML의 강점과 가능성을 찾으려면 원래 XML이 목적한 용도인 출판, 특히 웹 출판으로 돌아가야 한다. 웹에서 출판은 다음과 같은 세 가지 구성요소로 나눠진다.
- 저작자
- 출판사
- 독자
독자쪽은 문제가 없다. 브라우저가 있으니까. 현재 주요 브라우저는 모두 XML을 지원한다. 그러나 저작과 출판과 둘 사이 연결은 이제 막 시작 단계다.
|
|
문 서를 출판하려면 작성부터 해야 한다. 이 부분에서 승패는 이미 판가름 났다. XML이 승자다. 이제 주요 오피스 프로그램은 기본적으로 문서를 XML 압축 파일로 저장한다. 여기에는 마이크로소프트 오피스, 오픈오피스, 스타오피스, 워드퍼펙트 오피스, 로터스 노츠(Lotus® Notes®)가 포함된다. 심지어 어도비 일러스트레이터(Adobe® Illustrator®)와 같은 그래픽 응용 프로그램도 이제는 문서를 XML로 저장한다. 아직 이 진영에 속하지 않은 주요 소프트웨어로는 iWorks가 있지만 내년 즈음에는 가담하리라 예상한다.
|
|
이 러한 변화는 중요한 발전임에도 불구하고 별다른 주목을 끌지 못했다. XML은 (당연히 그래야 하듯이) 사용자에게 보이지 않기 때문이다. 일반 스프레드시트 사용자 입장에서는 엑셀(Excel®)이 자료를 디스크에 저장하는 정확한 방식을 알 필요가 없고 별 관심도 없다. 그러나 협력 개발업체 입장에서 XML 텍스트 구조는 역공학으로 분석하여 응용 프로그램에 접목하기가 한결 수월하다. 어휘 문서가 부실하고 일관성도 떨어지는 오픈오피스 XML조차도 예전 이진(binary) 형식에 비하면 수천 배는 편하다. 게다가 오픈독(OpenDoc)처럼 좀더 합리적이고 좀더 플랫폼에 무관하고 좀더 기존 기존 형식에서 자유롭다면 금상첨화라 하겠다.
2008 년 현재, 오피스 문서에서 사용하는 XML 어휘를 놓고 상당한 불평이 터져나오지만 어느 쪽이든 건설적인 논쟁은 거의 없다. 나는 마이크로소프트 사가 2월에 OOXML을 ISO 표준으로 통과시키려는 시도가 실패하리라 예상하지만 확신은 못하겠다. 어쨌거나 메시지는 분명하다. 앞으로 마이크로소프트 오피스는 오픈오피스, iWorks 등 기타 경쟁 제품에 계속 시장 점유율을 잃어갈 것이다.
오피스가 나쁜 제품이라서가 아니다(오피스는 나쁜 제품이 아니다). 오픈 소스가 아니라서도 아니다(오피스는 오픈 소스가 아니다). 더 이상 올라갈 데가 없기 때문이다. 더 이상 성장할 여지가 없기 때문이다. 이제는 어느 정도 깊이, 어느 정도 빨리 추락하느냐는 질문만 남았다. 현재 마이크로소프트 왕국이 당면한 위협은 네델란드와 노르웨이처럼 오픈독과 오픈소스 솔루션을 필수적으로 요구하는 정부가 점차 많아지리라는 사실이다. 심각도는 덜하지만 PC가 널리 퍼지면서 윈도우와 오피스 가격이 전체 PC 가격의 절반을 넘는다는 사실 또한 희소식은 아니다. 어떤 면에서 마이크로소프트 사는 이미 문제를 인식하고 교사와 학생 가족과 학교와 눈꼽만치라도 연관되는 모든 사람을 대상으로 저가 학생/교사용 오피스 에디션을 내놓았다. 그러나 동시에 오피스의 불법복제방지 기능을 강화하고 있으니 ‘왼손이 하는 일을 오른손이 모르게 하라’라는 교훈을 확실히 실천하는 중이라 하겠다. 그렇다고 불법복제가 줄어들 가망성은 없으나 사용자를 오픈 소스 대안으로 몰아갈 가능성은 충분하다.
이제 모든 오피스 문서가 XML 형식이므로 한 형식을 다른 형식으로 바꾸기가 놀랍도록 쉬워졌다. 2008년은 XML 계열 중에서도 업계 판도를 뒤집은 기술인 XSLT가 나온 10주년이다. 새로운 2.0 버전은 더욱 강력하다. 조만간 경쟁 제품끼리 문서 형식을 변환하기가 너무도 쉬워져 대다수 사람은 더 이상 문서 형식을 따지지 않을 것이다. 변환 과정에서 몇몇 스타일이나 매크로를 잃을지도 모르지만, 어차피 범용적으로 사용하지 않는 기능이니 상관이 없다. 제품 개발업체가 문서 형식을 독점하는 현상은 이제 소소한 문제가 되었다.
물론 가장 중요한 변환은 오픈독과 OOXML 사이에 일어나는 변환이 아니라 오픈독이나 OOXML에서 XHTML로 이루어지는 하향 변환(down-conversion)이다. 현재 오픈오피스와 마이크로소프트 오피스가 제공하는 HTML 변환 기능은 아주 형편없다. 다른 개발업체가 끼여들 틈새가 충분하다. 가장 중요하게 기업 사이트 개발자들이나 웹 마스터들이 자기네 사이트용으로 내놓는 사용자 정의 템플릿(custom template)에 주목한다. 이런 템플릿 덕택에 일반인들은 기존 방식으로 마이크로소프트 워드 문서를 작성한 후 CMS(Content Management System)로 직접 읽어들일 수 있다. 편집 도구와 검토 도구도 제작하기 쉽다. (사람은 GUI 인터페이스를 사용하지만) 컴퓨터가 마크업을 모두 생성하므로 문법 오류와 양식 오류가 사라지기 때문이다. 2008년 말까지 모든 웹은 아니지만 지금보다 많은 웹이 이러한 상태에 이르리라 생각한다.
또 한 XSLT와 XML 오피스 형식은 기존에 숨겨졌던 자료를 드러내는 역할도 한다. 지난 수십 년 동안 수많은 비즈니스 문서가 읽히지 않은 채 파일 시스템 속에 묻혀 있었다. 물론 더 이상 쓸모 없는 문서도 당연히 많겠지만, 중요한 정보가 담겼으나 찾아낼 방도가 없어 잊혀진 문서도 있다. 기업 개발자들은 이러한 기존 오피스 문서를 새로운 XML 기반 형식으로 자동 변환한 후 XSLT와 XQuery로 조회가 가능하게 만듦으로써 잊혀진 정보에 생명을 불어넣을 것이다.
워드나 오픈 오피스 라이터와 같은 기존 오피스 프로그램을 저작 도구로 사용한다면 서버에서는 이를 어떻게 처리할까? 문서 내용을 클라이언트에서 서버로 옮기는 방법은? 여기서 2007년에 나온 두 가지 중대한 1.0 배포 기술이 진가를 발휘한다. 바로 APP(Atom Publishing Protocol)와 XQuery다.
|
|
흔 히 기술에 익숙치 못한 사람들에게 웹 저작 방법을 가르칠 때는 두 가지 난제에 직면한다. 하나는 의미론적 마크업(Semantic Markup)을 이해시키는 일이고, 또 하나는 FTP 사용법을 가르치는 일이다. (표준 파일 열기 대화 상자조차 사용할 줄 모르는 컴맹이 많다는 사실을 명심한다. 그들은 모든 문서를 “내 문서” 폴더나 바탕화면에 저장한다. 실수로 다른 곳에 넣으면 찾지 못한다. 프로그래머는 계층이라는 개념을 알지만 많은 사용자는 그 정도로 추상적인 사고를 하지 못한다.)
오픈오피스 와 마이크로소프트 워드처럼 XML을 지원하는 워드프로세서는 첫 번째 문제를 해결한다. APP는 두 번째 문제를 해결한다. APP는 사전에 협약하거나 개념적인 모델을 공유하지 않고도 독립적인 클라이언트와 서버가 서로 통신할 수 있도록 표준 프로토콜을 제공한다. 웹 검색에서 HTTP가 맡았던 역할을 웹 저작에서는 APP가 맡는 셈이다.
소프트웨어 개발업체는 각 서버에서 돌아가는 APP 서비스와 통신하는 저작 도구를 개발할 수 있다. 독자적인 편집기 형태도 가능하고 워드나 오픈오피스와 같이 기존 오피스 제품의 플러그인 형태도 가능하다. 문서를 업로드하는 방법은 지역 디스크에 파일을 저장하는 방법만큼이나 쉽다. 아니, 때로는 더 쉬울지도 모른다. 새 문서를 제작하려면 게시할 URL과 사용자 이름과 암호만 있으면 충분하다(위키 스타일 사이트라면 사용자 이름과 암호도 필요 없다). 문서를 편집할 때는 문서 URL만 있으면 된다.
|
|
이제 2008년에 (워드나 오픈오피스로) XML 문서를 작성하는 방법과 서버로 저장하는 방법을 알았다. 그럼 마지막으로 이 멋진 XML 문서를 어디다 저장할까?
전 통적으로 두 가지 방법이 있다. 하나는 파일 시스템에 저장하는 방법이고, 다른 하나는 관계형 데이터베이스에 BLOB(Binary Large Object)로 구겨넣는 방법이다. 둘다 많이 쓰는 방법이지만 어느 쪽도 웹 문서에는 적합하지 않다.
파일 시스템은 간단하고, 안정적이며, 널리 알려진 기술이지만 검색 기능이 매우 부실하다. 같은 데이터를 여러 곳에다 중복하여 저장하며, 문서 내부 구조를 전혀 알지 못하며, 하위 문서(subdocument) 단위로 쪼개지도 못한다.
관계형 데이터베이스는 특정한 순서가 없고 중복이 적은 데이터 조각을 저장하기에 아주 적합하다. 그러나 XML은 어느 쪽에도 속하지 않는다. 관계형 테이블을 XML 문서로 변환하기는 쉽지만(각 행을 요소로 만들고 각 필드를 속성이나 자식 요소로 만들면 된다), XML 문서를 관계형 테이블로 변환하기는 쉽지 않다. 많은 XML 문서는 순서가 있으며, 공백이 많고, 요소 유형이 섞여 있으며, 반복적이면서도 고유한 요소를 가지고, 중첩 단계를 예측하기 어려운 등 관계형 테이블에 적합하지 못한 특징이 다분하다. 특히 HTML이나 XHTML 등과 같은 웹 페이지는 이러한 특성을 모두 지닌다. HTML 문서와 XML 문서를 관계형 데이터베이스에 저장해도 되지만(간혹 MySQL을 사용하는 경우도 있다) 결과는 깔끔하지도 빠르지도 못하다. 문서를 작은 단위로 낱낱이 쪼개면 자료를 검색하고 선택하고 순서를 변경할 수는 있다. 그러나 적당한 성능을 얻기 위해 소모하는 비용 탓에 배보다 배꼽이 더 커져버린다. 비교적 간단한 작업이라도 원래 SQL 용도와 무관한 탓에 SQL 쿼리는 반 페이지를 훌쩍 넘어버리고, 복잡한 쿼리를 개발하고 유지보수하는 작업 또한 악몽이 된다.
또 다른 방법으로 각 문서를 BLOB로 저장해도 된다. 간단하고 빠른 방법이지만 문서 일부를 선택하거나 다른 문서와 결합하는 기능은 모두 포기해야 한다. 현재 응용 프로그램 논리는 PHP나 루비 등과 같은 서버측 프레임워크에서 구현하는 추세다. 데이터베이스는 그저 파일 시스템보다 문서 분리가 나은 대안에 불과하다.
우리에게 필요한 데이터베이스는 일반 웹 문서가 지니는 계층 구조를 (잘라내지 않고) 포용하는 데이터베이스다. 그리고 처음으로 이런 데이터베이스가 시장에 나왔다. 가격대가 다양하고, 안정적이며, 곧바로 쓸 수 있다. 저가 제품으로는 eXist와 버클리 DBXML이 두각을 나타낸다. 마크 로직(Mark Logic)과 같은 고가 XML 데이터베이스는 초기 비용을 감당할 여력이 되는 대형 출판사를 끌어들이고 있다. IBM DB2® 9 pureXML™과 같은 제품은 XML 문서와 테이블형 문서를 혼합하려는 고객들에게 XQuery를 퍼트리리라 예상된다.
이 같은 초기 제품과 비교하여 새로 나오는 제품은 더욱 안정적이고, 더욱 확장성이 있고, 더욱 신뢰성이 높다. 가장 중요하게는 모두가 여러 해 동안 개발한 끝에 나온 표준 언어인 XQuery 1.0을 공유한다. 한 데이터베이스에서 다른 데이터베이스로 응용 프로그램을 이식할 가능성은 필요 이상으로 강조된 반면, 한 서버에서 다른 서버로 개발자의 기술을 이식할 가능성은 필요 이상으로 간과되어 왔다. 여섯 종류나 되는 다양한 쿼리 언어를 그것도 6개월마다 배우고픈 사람은 없다. 이제는 배울 필요도 없다.
XQuery에서 갱신(Update) 부분은 급속도로 진전을 보이고 있다. 2008년 내에는 끝나지 않겠지만 이미 구현해도 좋을 정도로 안정적이다. 새 안이 나올 때마다 코드를 조금씩 손봐야 하는 수고를 꺼리지 않는다면 말이다. 올해 안으로 상황은 나아질 전망이다.
마지막으로 2008년에는 javax.xml.xquery가 출시될 예정이다. 이는 자바 프로그램을 XQuery 엔진/데이터베이스와 연결하는 표준 API다. XQuery용 JDBC라 하겠다. 이 API를 사용하면 자바 코드와 XQuery를 섞어쓸 수 있다. 2009년 자바 7이 출시된 후에야 표준 자바 라이브러리 클래스에 들어가겠지만, 이미 많은 제품에서 이를 지원하며, 앞으로 그 수가 늘어날 전망이다.
|
|
|
| |||||||||||||||||||
XQuery 는 드디어 실전에 투입될 준비를 갖추었다. APP는 막 출전하려는 참이다. 나더러 XML에 시간과 돈을 투자하라면 바로 이 두 가지 기술을 주목하겠다. CMS, 블로그 엔진, 게시판은 이미 넘치게 많다. 그러나 문서를 쉽게 저장하고 게시하는 방법은 부실하다. 전용 XML 데이터베이스와 APP가 이러한 요구를 충족시킨다.
그리고 이 자리를 빌어 개발자 도구를 하나 더 요청한다. 앞서 소프트웨어 개발에서 XML은 미래가 없다고 말했지만 그래도 아직 생명은 남아 있다. JSON이 가르치는 교훈을 살펴보면, 응용 프로그램은 그리 확장성 있는 자료 구조를 필요로 하지도 않고 원하지도 않는다. 기본 자료 유형과 리스트와 맵을 지원하는 기본 XML 형식이면 충분하다. Listing 1처럼 간단한 XML 말이다.
| <PRE class=displaycode> <data xmlns="http://www.w3.org/data"> <list> <string>Foo</string> <int>17</int> <year>1999</year> <list> <map> <entry> <string>Boston</string><string>Red Sox</string> </entry> <entry> <string>New York</string><string>Yankees</string> </entry> </map></data></PRE> |
위와 같은 XML 문서를 자바, 자바스크립트, 파이썬(Python), 펄(Perl), 루비(Ruly)와 같은 언어의 고유(native) 자료 구조로 변환하는 라이브러리는 어떨까? JSON과 비슷하지만 XML 확장성을 고려하면서도 보안 문제가 없는 도구가 가능할까? 도전해 볼 해커가 있는가?
교육
- DB2 9 pureXML로 Microsoft Office 2007 문서 관리하기 (Chris C. Gruber, developerWorks, 2007년 8월): IBM DB2 9를 사용하여 PHP의 PDO와 XQuery로 데이터를 저장하고 검색하는 방법
- Manage a media collection with the Atom Publishing Protocol (Nicholas Chase, developerWorks, 2007년 4월): Atom Cyndication Format과 Atom Publishing Protocol을 결합하여 웹 기반 미지어 저장소를 생성하는 방법
- An introduction to XQuery (Howard Katz, developerWorks, 2006년 1월): XQuery W3C 표준 둘러보기
- 왜 XForms인가? (Elliotte Rusty Harold, developerWorks, 2006년 10월): XForms이란? 국제화, 접근성, 디바이스 독립성 살펴보기
- XML 2007 (한글) (Elliotte Rusty Harold, developerWorks, 2008년 2월): 2007년 XML을 돌아보며
- IBM XML 인증: XML과 관련 기술 분야에서 IBM 인증 개발자가 되는 법
- XML 기술 라이브러리: 기사와 팁, 튜토리얼, 표준, IBM 레드북 등 다양한 기술 자료를 제공한다.
- developerWorks 기술 행사와 웹 캐스트: 최신 기술 동향 파악
- 기술 온라인 서점: 다양한 기술 서적을 제공한다.
제품 및 기술 얻기
- eXist 전용(native) XML 데이터베이스: 전적으로 XML 기술에 기반을 둔 오픈 소스 데이터베이스 관리 시스템으로, XML 데이터 모델에 따라 XML 데이터를 저장하고 XQuery를 사용할 수 있다.
- IBM 평가판 소프트웨어: IBM 평가판 소프트웨어를 developerWorks에서 바로 내려받을 수 있다.
토론
- 포럼에 참여하기.
- XML 영역 토론 포럼: XML과 관련하여 다양한 토론을 나눌 수 있다.
- developerWorks 블로그: 블로그를 읽어보고 developerWorks 공동체에 참여해 보라.
| ||
|
Elliotte Harold: 교수, Polytechnic University | |