내가 XML을 싫어하는 이유

Posted by 大山 Sat, 09 Sep 2006 13:45:00 GMT

내 생각에 XML이 가져온 효과는 단 한가지이다. 바로 오픈 포맷의 확산에 기여했다는 것. 그런데 그렇게 확산된 오픈 포맷이 하필 XML이라는 것은 다행중 불행인 것 같다.

우선 XML 마크업은 가독성이 매우 낮다. XML의 주요 설계 목적 중 하나가 사람 눈에 읽힐 수 있어야 한다는 것이었는데, 말 그대로 읽히기만 한다. 차라리 Lisp 코드의 가독성이 더 나을듯.

XML을 둘러싼 hype이 워낙에 거셌다 보니까, ant처럼 빌드 파일 포맷에 XML이 사용되기도 하고, 각종 설정 파일에도 XML이 단골이다. 개중에는 SOAP처럼 원격 프로시져 호출에 XML을 사용한 경우도 있다. 그런데 사실 따지고 보면, XML 포맷이란 트리 구조의 데이타를 단순히 텍스트 형태로 나타낸 것에 불과하다. 트리 구조를 표현하기에 적합한 텍스트 포맷은 XML 말고도 여럿 있다. 위에서 살짝 언급한 Lisp의 리스트도 좋은 예이고, 해시 리터럴(literal), YAML, JSON 등도 있다. 이들은 가독성도 뛰어나고, 파싱도 쉽고, 처리속도도 빠르고, 저장 공간도 더 적게 차지한다.

물론 XML에는 네임스페이스나 문서 검증 기능도 있지만, 자바에서 네임스페이스 충돌을 원천적으로 막겠다고 네임스페이스 이름에 도메인 주소를 집어넣는 만행을 저지른걸 떠올려 보면, XML의 네임스페이스도 다소 오버한 느낌이다. 지난 10여년간 HTML이 발전해온 과정을 보면 문서 검증 기능도 그다지 중요한 것 같지는 않고.

결과적으로 XML은 가독성도 나쁘고, 핸드 코딩도 힘들고, 파싱도 복잡하고, 처리속도도 느리다. 과연 XML은 어디에 유용할까?

관련글: Re: 내가 XML을 싫어하는 이유, JSON vs XML

Posted in  | Tags , , ,  | 6 comments | no trackbacks

Comments

  1. 1.
    Redlia said about 3 hours later:

    안녕하세요~ 올블로그 타와 왔습니다. 님 생각에 동의합니다만 그렇게 생각하면 TCP/IP 부터 바꿔야 하지 않을까요? 주의를 둘러보면 의외로 더 나은 대안이 있음에도 그대로 유지되는 것들이 많죠... 하지만 그대로 유지되는 것은 그 나름대로 이유가 있어서가 아닐까요?


  2. 2.
    dukgun said about 21 hours later:

    물론, XML에 단점도 많이 있지만 구조적이고 확장성이 있기 때문에 그러한 것들이 필요한 곳에 계속 쓰이고 있다고 생각합니다.^^ 그리고, XML은 원래 데이터를 기술(describe)하기 위해 설계된 것이기 때문에 display보다는 데이터 내용에 초점이 있습니다. XML 문서를 보여주기 위해서 XSL이나 CSS가 사용됩니다. (여기서...iexplorer 등과 같은 XML 파싱 프로그램이 필요하는 것도 단점이죠^^)


  3. 3.
    mkseo said 1 day later:
    1. 낮은 XML가독성에 동의합니다. 사실은 사람이 읽을수 있는 형태로 만든다고 만든건데, 만들고나니 온갖 관련 스펙이 (예: 웹서비스) 너무 복잡해 도저히 인간이 편집할 수 없죠, 요즘은.

    2. 네임스페이스 문제는.. 일단 현재로선 필요한 듯 합니다. 가령 시맨틱웹에서 쓰이는 OWL만 봐도 rdf, rdfs 등 2개의 네임스페이스는 기본으로 쓰이고, 내가 만드는 태그의 대상 네임스페이스도 존재하는 등 현재로선 거의 필수적으로 쓰이고 있죠.. rdf와 rdfs같이 특정 도메인에서 자주 쓰이는 네임스페이스는, 최소한 그 도메인내에서 쓰이는 경우에서는 하나로 합쳐버리고 그 둘은 꼭 네임스페이스를 안적어도 implicit 하게 포함되게 한다던가하는 방법들을 생각해볼 수도 있겠으나, 그렇게 되면 xml이 적용되는 도메인마다 서로 다른 점이 너무 많이 생깁니다.

      그렇게 되버리면, 여기저기서 툴을 다 따로 만들어야하는 등 힘들어지겠죠. 결국 확장성 좋은 기본 틀로부터 출발 할 수 밖에 없는 듯. 그리고 이게 이미 표준으로 정해진거라, 망하든 말든 일단 끝까지 가는거죠;;

    3. XML이 중요한 곳은 이기종 머신/소프트웨어간의 데이터 공유입니다. 그래서 검증이 꼭 필요한거고, 파싱이 용이해야하죠. 예를들어, html만해도 렌더링이 브라우저마다 상이하잖아요. 그게 well-structured안된 언어는 피하기 힘든 문제같습니다.

      아시다시피 하나의 de facto standard가 정해지면, 거기서 벗어나오게 되면 자신의 이익을 보장하기 힘들어집니다. 더구나 XML처럼 완전히 표준이 된 경우엔, 더 유용한 데이터 교환방식이 있어도 어떻게 해보기가 힘들죠..

      XML friendly하게 XML 파싱 및 작성이 프로그램내에서 쉬워질 필요는 있어보입니다. 자바도 그래서 문법을 추가해보자는 논의가 있는 듯한데, 코드보는게 괴롭더군요. 자바를 누더기로 만들자는 것 같았서말이죠..


  4. 4.
    이원구 said 2 days later:

    XML에 대해 깊게 알진 못하지만 XML이 복잡해질 수 밖에 없는 이유는 범용적이기 때문인 것 같습니다.

    모든 목적에 사용할 수 있는 텍스트 기반의 표준적인 문법을 만들다보면 어떻게 만들더라도 복잡해질 수 밖에 없지 않을까요? 예를 들어 ASN.1같은 표준도 얼마나 복잡한가요? 파싱은 말할 것도 없죠.

    그리고 프로그램 내부에서 저장이나 작업 용도로 굳이 XML을 사용할 필요는 없겠죠. 더 나은 트리 구조를 사용하는 방법이 있다면 그걸 쓰면 되니까요. XML은 이 데이터를 외부와 인터페이스하기 위해 사용되겠지요.

    그리고 XML 역시 사람을 위한 문법이 아니라 기계를 위한 문법입니다. 우리가 XML을 사용할 때 이 내용을 사람이 인쇄해서 읽는 용도로 사용할 것이라고 생각하진 않으니까요. 이런 기계를 위한 문법을 사람이 텍스트 에디터에서 열어서 간단히 확인하고 수정도 할 수 있다는 것이 ASN.1같은 표준과 차별화되는 XML의 장점이라고 해야 하지 않을까 싶네요. :-)


  5. 5.
    공성식 said 2 days later:

    저는 개인적인 프로젝트 또는 구조화된 메모에서는 주로 YAML을 사용합니다. XML보다 더 인간에게 친숙하고 신택스도 훨씬 간단하기 때문입니다. (루비에서 특히 잘 지원한다는 점도 있구요)

    그런데 쉬운 만큼 단점도 있는 것 같습니다. YAML의 경우 Python처럼 significant white space를 이용합니다. 이미 작성된 데이터에 대해 depth-level을 변경하는 게 용이하지 않습니다. indentation을 일괄적으로 바꿔줘야 하니까요. 또한 메일로 복사할 때 indentation을 잃어버리게 되면 낭패입니다. XML의 경우엔 이런 문제가 없죠.

    물론 XML은 인간이 쉽게 쓰거나 읽기 위한 구조는 아닌 것 같습니다. 기계 간의 통신이나 표준 데이터 스펙에 더욱 적합할 것 같아요.

    또다른 유용성을 따져보자면, HTML과의 호환성이라고나 할까요. 물론 직접적인 것은 아니고 XHTML을 거쳐야 하는 것이지만, 이 경우엔 다른 어떤 자료 기술법보다 나은 선택이 될 것 같습니다.

    네임스페이스에 도메인명을 사용하는 것 말고 더 확실한 대안이 있을까요? 자바처럼 글로벌하게 사용되는 경우엔 이름 충돌의 문제가 아주 심각할 것 같습니다. 썬에서도 많은 고민을 하여 내린 결정이 아닐까요?


  6. 6.
    noname said 7 months later:

    이 글과 댓글을 보고나니 비로소 xml의 문제점이라고 여겨졌던 태깅이 실제론 그리 나쁜 것만은 아니구나 하고 납득했습니다. xml이 손으로 치고 눈으로 읽기엔 불편한 점이 있긴 하지만 범용성과 확장성을 생각할 때, 그리고 이식성까지 염두에 둔다면 가장 적절한 타협안이 아니었나 싶군요.

    foo = bar 나 foo: bar 같은 초 단순한 문법은 읽기도 쓰기도 쉽지만.. bar 를 선택할 수 밖에 없는 이유가 엿보이기 시작했습니다.


Trackbacks

Use the following link to trackback from your own site:
http://beyond.daesan.com/articles/trackback/2378

Comments are disabled