To XML or Not to XML

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

사람이라면 누구나 막연한 믿음과 편견, 고집이 있기 마련이지만, 프로그래머만큼 기술에 대한 종교적인 추종과 그에 수반하는 상호비방(flame war)이 빈번한 집단을 찾기는 어려울 것이다. 경우에 따라서는 흑백이 명확할 리 없는 주제를 가지고도 나름 참고할 가치가 있는 이성적인 논의가 오가지만, 기술에 대한 이해가 부족한 상황에서 엄한 설전이 오고 가는 경우도 비일비재하다.

예를 들어보자. 리눅스가 처음 개발될 때 그 당시 유행하던 마이크로커널(microkernel) 대신 일체형 커널(monolithic kernel)을 택한 탓에 리눅스를 만든 리누스 토발즈(Linus Tovalds)와 미닉스(Minix)로 유명한 앤드류 탄넨바움(Andrew Tanenbaum) 사이에 오갔던 설전은 꽤 유명하다(http://people.fluidsignal.com/~luferbu/misc/Linus_vs_Tanenbaum.html). 마이크로커널을 고집했던 Mach 3.0이나 초기 윈도 NT가 고질적인 성능 문제로 손을 든 마당에 이미 마이크로커널이 판정패 했다고도 볼 수 있지만 그래도 당시로는 충분한 논쟁거리가 될 만한 주제였다.

반면에 지금 이 글을 적고 있는 맥북의 운영체제인 맥 OS X이 Mach 기반이기 때문에 마이크로커널을 사용하고 있고 따라서 리눅스 등에 비해 느리다는 믿음은 무지에서 나오는 소모적인 논쟁의 대표적인 예라 할 수 있다. 맥 OS X이 Mach 운영체제를 활용하기는 하지만 사실 마이크로커널 구조도 아니고 느리지도 않다(http://www.roughlydrafted.com/0506.mk1.html).

1998년 XML 1.0 권고안이 나온 이후 필자는 국내 컴퓨터 관련 잡지에 여러 차례 XML 관련 기고를 했지만, 많은 문헌에서 주장하는 "XML을 써야 하는 이유"에 대해 솔직히 동의할 수 없는 경우가 많았다. 마치 막연한 선문답 같은 내용이었다고 할까. 이런 맥락에서 이 글에서는 "모든 것은 XML이어야 한다"는 막연한 믿음과 "자술적인(self-descriptive) XML 특징을 지키기 위해 XML은 반드시 텍스트 형태여야만 한다" 같은 XML을 둘러싼 해묵은 논쟁에 대해 실용적인 관점에서 딴죽을 걸어 보고자 한다. 물론 개인적으로 XML을 많이 적용해 왔고 XML을 둘러싸고 축적된 많은 자원의 혜택을 누리고 있기에 무용론을 펼치려는 것은 아니다. 그저 "기술에 중독되지는 말자"라는 메시지를 전달하고 싶다.

위로

XML을 쓰는 진짜 이유

XML 반대론자라도 인정하는 것은 "너도 나도 XML을 쓰니, 안 쓸 수는 없다"라는 점이다. 이미 업계에서 충분한 모멘텀을 얻은 이상 다른 월등한 대안이 아니라면 XML을 대체하기는 힘들다는 것이다. 또 한 가지 인정하는 점은 XML은 "최선은 아니더라도 최악은 아니다"라는 점이다. XML이 뭔가 가려운 곳을 긁어줬기 때문에 널리 사용하게 됐다는 것이다.

개인적으로는 XML은 기존 문제를 해결한 획기적인 해법이었다기보다는 문제를 해결하려는 과정에서 영향력 있는 단체(W3C)의 후광을 입고 적절한 특성을 가지고 시기 적절하게 나타났기에 널리 퍼진 기술이라고 생각한다. 이는 오늘날 성공적인 기술로 평가 받는 C와 유닉스, C++, Java 같은 기술의 성공과도 일맥상통 한다.

일례로 Java는 데뷔 당시 획기적인 프로그래밍 언어로 포장되었지만, 당시 잘 알려진 개념들을 적절히 엔지니어링 한 작품일 뿐이다. 물론 Java를 만들어 낸 제임스 고슬링의 훌륭한 균형 감각과 엔지니어링 센스에 대해선 존경을 표하지만, Java의 성공에는 그 못지않게 썬 마이크로시스템즈라는 유력한 업체의 훌륭한 마케팅이 더 큰 영향을 줬다고 생각한다.

결국 흔히 XML의 장점이라고 이야기되는 것들은 "텍스트 형식"이거나 "열린 규격"이면 보편적으로 공유하는 특징인 경우가 많다. 꼭 XML이 단 하나의 “텍스트 형식의 열린 규격”일 이유는 없다는 것이다. 그럼 왜 하필 XML을 사용할까? 그것은 XML 자체 때문이기 보다 이미 XML을 중심으로 축적된 많은 사람의 노력 때문일 것이다.

• 많은 XML 도구들: XML 문법을 이해하는 에디터, 파서, XML을 사용하는 많은 콘텐트 관리 시스템 등 많은 소프트웨어 도구가 다양한 운영체제, 다양한 언어를 위해 개발되어 축적되어 있다는 점은 XML의 명백한 장점이다.
• 방대한 XML 사용자 그룹: XML을 좋아하든 아니든, 이해의 정도가 깊든 일천하든, 그래도 XML을 사용하고 관련 문헌을 읽어본 사람이 많다는 것은 사실이다. 이는 내가 남과 일할 때 그만큼 뭔가를 설명하고 맞출 필요가 덜하다는 뜻이다. 물론 그렇다고 내가 만든 XML 응용을 아무나 이해할 수 있다는 의미는 아니다.
• 유용한 XML 기반 규격: 개인적으로 XML 스키마를 싫어하기는 하지만 Relax NG같은 스키마 언어는 어떤 구조를 표현하는데 있어서 꽤 유용하며 쓰고도 쉽다. W3C의 SVG 1.2 버전은 DTD나 XML 스키마 대신 Relax NG 스키마로 기술된다. 이런 XML과 연계된 유용한 규격이 제정되어 있다는 점도 XML의 연륜이 주는 장점이라고 볼 수 있다.

위로

XML 중독에서 벗어나자!

하지만 시쳇말로 XML이 너무 들이대는 경우도 있다. 가장 대표적인 예는 아이러니하게도 XML의 고향인 W3C에서 볼 수 있다. W3C에는 수많은 XML 기반 많은 마크업 언어가 나와 있다. 하지만 실제 사용되고 있는 것은 그리 많지 않다. 그 뿐만 아니라 괜히 XML 형태의 스크립트 언어를 만들거나 소프트웨어 컴파일과 링크 과정을 XML로 표현해서 쉬운 일을 어렵게 만들기도 한다. 이미 눈치 챘겠지만 필자는 Ant 빌드 파일이 XML 형식인 것이 불만인 사람 중 하나다.

논란의 여지가 있지만 개인적으로 이런 XML의 남용은 XML의 특성에 대한 광범위한 오해에서 비롯된다고 생각한다. 몇 가지를 꼽아 보자.

XML은 사람이 읽고 쓰기 쉽다.
흔히 XML의 장점이라고 이야기하는 것 중 하나가 기계가 처리하기 쉬운 것은 물론이고 사람이 읽고 쓰기 쉽다는 것이다. 하지만 정말 그럴까? 예를 들어 간단한 자바 스크립트 코드를 XML 문법을 사용하는 비슷한 스크립트 코드(http://www.xmlscript.org/)와 비교해 보라. 읽을 수 있는 것과 읽기 쉬운 것은 엄연히 다르다.
그리고 읽을 수 있다고 작성하기 쉬운 것은 아니다. 각 XML 응용마다 적절한 편집기의 도움이 없이 XML 문서를 제대로 편집하기는 여간 어려운 일이 아니다. 여는 태그와 닫는 태그가 짝이 맞다고 모두 유효한 XML 문서는 아니다. 예를 들어 XML 스키마는 이해하기도 어려울뿐더러 텍스트 편집기로 제대로 작성하는 건 거의 불가능하다.
이 같이 XML이 반드시 읽기 쉽고 쓰기 쉬운 것은 아니다. 특히 프로그래머가 아닌 일반인에게 XML은 재앙일 뿐이다. 그리고 비록 프로그래머라도 XML 규격을 온전히 이해하는 사람은 그리 많지 않다. 뭔가 사람이 읽고 써야 하는 데이터가 필요하다면 대상이 누군가 생각하고 그에 맞는 데이터 형식이나 도구를 제공해야 한다.

XML은 어떤 형태의 정보든 “잘” 표현할 수 있다.
XML이 어떤 형태의 정보든 표현할 수 있는 유연성을 가졌다는 점은 사실이다. 하지만 그게 ‘효과적’이냐를 봤을 때는 항상 그런 건 아니다. 우선 XML에 base64 인코딩으로 바이너리 데이터를 삽입할 수는 있지만 이미지 파일 같은 대용량의 데이터를 XML로 삽입해 텍스트 형태로 표현하는 것은 단순히 아둔한 짓이다. 꼭 바이너리 형태가 아니더라도 데이터 자체가 대용량이거나 데이터 구조가 복잡하고 꼭 사람이 읽고 써야 하는 것이 아니라면 뭔가 다른 형식을 생각해 봐야 한다.
심지어 XML 관련 규격이라도 모든 것을 XML로 표현하지는 않는다. SVG는 속성값으로 공백으로 구분된 숫자를 사용하기도 하고, CSS는 아예 XML 문법을 사용하지 않는다. 앞서 언급한 것처럼 사람이 읽거나 써야 하는 경우를 생각한다면 XML을 사용해도 정말 읽고 쓰기 쉬운지 꼼꼼히 검증해 봐야 한다. 종종 <key>=<value> 형태의 간단한 텍스트 파일이나 훨씬 읽고 쓰기 쉽거나, 전용 파서를 만들더라도 독자적인 텍스트 파일 형식을 만드는 편이 나은 선택인 경우도 많다.

XSLT를 쓰면, XML 스키마를 쓰면 이러이러한 일을 간단히 처리할 수 있다.
단순히 XSLT를 사용하면 프로그래밍이 없이 하나의 XML을 다른 XML로 바꿀 수 있다고 믿는 경우가 많다. 그래서 심지어 다른 형식의 데이터를 XML로 변환하고 XSLT로 여러 차례 변환을 거친 후 다시 원래 형식으로 돌리기까지 한다. 하지만 XSLT가 배우기 어렵고 어지간한 스크립트 프로그래밍보다 더 어렵다는 건 알고 있는지.
또 XML 스키마를 사용하면 내가 설계한 XML 문서가 제대로 작성되었는지 자동으로 검사할 수 있다고 막연한 믿음도 문제다. 때론 XML 스키마 작성이 프로그램에서 문서가 유효한 지 검사하는 것보다 힘든 경우도 많다. 아울러 잘 작성된 스키마로 걸러낸 문서도 XML 문서 자체의 의미에 따라 추가적인 검증을 해야 하는 경우가 비일비재하다.

이 같이 XML을 활용한 마법과 같은 기술을 머리에 떠올렸다면 어디까지가 진짜인지 잘 살펴봐야 한다. 세상에 공짜는 없다.

XML은 자술적(self-descriptive)이라 효용성이 높다.
XML이 자술적이라고 하는 것은 통상 태그와 속성 등에 이름이 붙어 있는 XML의 특성을 일컫는 경우가 많다. 하지만 생각해 보자. 누군가 만든 주소록을 표현하기 위해 XML로 FooML을 만들었다면, FooML 문서를 사람이 봐서 짐작은 할 수 있겠지만, 완전히 이해할 수 있을까. 그리고 컴퓨터가 그게 주소를 표현하는 것인지 이해하고 거기에 맞춰서 문서를 내 아웃룩 주소록에 등록시켜 줄 수 있을까. 천만의 말씀이다. 물론 바이너리 형태의 잘 알려지지 않은 형식보다는 변환해서 주소를 추출해 낼 가능성은 높겠지만 말이다. 통상 문법과 의미를 미리 알지 못하는 XML 문서는 거의 활용할 여지가 없다.

XML 형태의 데이터 형식은 확장성이 좋다.
시간에 따라 데이터 구조가 확장되면서 이전 버전의 데이터를 처리하는데 문제가 있거나 기존 프로그램이 새 버전의 데이터를 처리하는데 문제가 발생하기도 한다. XML로 표현된 데이터 구조를 확장할 때 문법적으로는 새로운 엘리먼트나 속성을 끼워 넣기만 하면 된다. 하지만, XML 문서의 의미에 따라서는 버전 간의 차이점이 자동으로 처리되는 것은 아니다.
반면에 바이너리 형식이라도 데이터 인코딩이 다소 비효율적이 되는 것을 감안하면 충분히 확장성 있는 데이터 구조를 표현할 수 있다. 고정관념을 버리자.

XML은 시스템 간의 상호운영성(interoperability)을 담보하는 유일한 수단이다.
과거 CORBA나 RPC 등이 구현 간의 미묘한 차이로 인해 임의의 시스템 간의 완벽한 통신과 연동에 실패 했었던 것은 사실이다. 하지만 이는 이런 규격이 통신을 위해 바이너리 규격을 사용했기 때문이라기보다는 시스템 간의 연결 방식과 절차가 복잡했기 때문이다. 통상 복잡한 소프트웨어 규격은 구현 간의 미묘한 차이점을 부른다.
많은 네트워크 프로토콜은 HTTP처럼 텍스트 형태로 기술되거나 ASN.1처럼 스키마를 작성해 바이너리 형태 메시지를 사용하고 있다. 하지만 그 자체의 문제로 프로토콜의 상호운영성에 문제가 생기지는 않는다.
요즘 떠드는 SOAP을 이용한 웹 서비스, SOA 등의 개념은 시스템 간의 느슨한 연결을 지향한다. 하지만, CORBA나 RPC와 다른 방향을 추구해서지, 단순히 XML을 사용하기 때문에 새로운 대안으로 주목 받는 것은 아니다.

위로

옳은 도구를 선택하기

"Why XML"이나 "XML sucks"를 구글에서 찾아보면 읽을 만한 내용들이 꽤 많이 나온다. 한 가지 재미있는 것은 "Why XML"보다는 "XML sucks" 쪽이 오히려 논리이고 실용적인 논지를 전개하고 있다는 점이다. 그런 사이트를 잘 살펴보다 보면 상황에 맞는 XML의 대안을 찾아낼 수도 있다. 경우 별로 살펴보면 다음과 같다.

사람이 쉽게 읽고 작성할 수 있어야 하는 경우
물론 내용 자체가 그렇게 복잡하지 않거나 HTML처럼 텍스트 내용의 일부에 특별한 의미를 부여하는 문서 형태의 데이터라면 XML을 사용해도 무방하겠지만, 경우에 따라서는 별도의 파서를 작성하는 편이 더 나은 경우도 많다. Java라면 JavaCC 같은 스캐너, 파서 생성기를 사용하면 생각보다 쉽게 새로운 텍스트 형식을 만들 수 있다. 아예 내용이 단순하다면 Java 프로퍼티 파일처럼 간단히 미리 정의된 파일 형식을 사용하는 것도 좋은 아이디어다. 다음은 이미 XML을 사용하고 있으면서도 별도의 문법을 정의한 경우들로 좋은 참고가 될 것이다.

• http://groovy.codehaus.org/Ant+Scripting

JVM에서 돌아가는 스크립트 언어인 Groovy에는 XML 문법으로 기술된 Ant 스크립트를 스크립트 문법으로 표현할 수 있는 옵션이 있다.

• https://xsltxt.dev.java.net/

장황해서 읽기 힘든 XSLT를 XML이 아닌 다른 형태로 표현할 수 있게 해 주는 도구이다.

대역폭이나 저장 장소, 성능에 민감한 경우
혹자는 XML이 너무 크면 GZIP으로 압축해서 보내면 된다고 이야기한다. 그렇게 하면 크기도 작아질 뿐 아니라 잘 구현하면 그렇게 성능도 저하되지 않는다고 이야기한다(http://www.xml.com/pub/a/2001/04/18/binaryXML.html). 하지만 상식적으로 TLV(태그, 길이, 내용) 형식으로 변환된 XML을 처리하는 것이 텍스트 형태의 XML 파일을 파싱하는 것보다 느릴 수도 있다는 논리는 상식적으로도 말이 안 된다.

GZIP으로도 충분히 줄지 않는 문서도 많다. 그리고 GZIP과 텍스트 형태의 XML을 처리해야 하기 때문에 생기는 성능 저하를 감당 못하는 경우도 상당하다. 휴대폰 쪽은 어떤가. 0.5K마다 과금되는 패킷에 그냥 덩치 큰 텍스트를 전송해야 할까.
이런 경우 XML을 적절히 바이너리 인코딩 해 주는 방법을 사용하면 유용하다. 프로그래밍을 하거나 데이터 형식을 설계할 때는 텍스트 형태의 XML과 Relax NG, XML 스키마 등 이미 다양한 도구가 제공되는 표준 방법을 사용하고 전송이나 저장 시에는 바이너리 형식을 사용할 수 있다.

이런 바이너리 인코딩 방법으로 유명한 것은 MPEG-7에서 사용하는 BiM(Binary format for Metadata)가 있다. 이 외 다양한 바이너리 인코딩 형식에 대해서는 사이트 http://en.wikipedia.org/wiki/Binary_XML을 참고한다. 통상 이러한 바이너리 인코딩 방법은 XML 문서의 스키마를 참고해서 그 구조를 활용, 파일의 크기를 줄이고 처리 속도를 높이는 방식을 사용한다. 앞으로 W3C에서 EXI(Efficient XML Interchange)라는 이름으로 표준 바이너리 인코딩이 개발될 예정이다. 이 규격이 나오면 로열티가 없는 효율적인 바이너리 인코딩 기술로서 널리 사용될 것으로 예상된다.

데이터의 교환 범위가 제한적인 경우
이 경우 시도해 볼 수 있는 여지가 많다. YAML은 XML과 비슷하면서도 훨씬 작고 쉽게 읽을 수 있는 마크업 언어이다(http://yaml.org/). YAML 사이트의 링크 부분을 보면 유사한 다른 시도들이 언급되어 있으니 참고하기 바란다.

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

결론

기술 분야에서는 흔히 최적의 기술이 승리하지는 않는다. 그렇다고 널리 쓰이는 기술이 열등하기만 한 것은 아니다. 하지만 기술을 활용하는 입장에서는 “기술에 중독” 되어서는 안될 것이다. XML을 맘껏 활용하되 XML을 남용하지 않아야 하며, 따라서, 항상 XML의 대안과 보완책에 대해서도 마음을 열어두는 것이 필요하다.

위로

[지난 developerWorks Column 보기]