Re: 내가 XML을 싫어하는 이유

Posted by 大山 Tue, 12 Sep 2006 17:44:00 GMT

내가 XML을 싫어하는 이유에 답글을 쓰다가 너무 길어지는 것 같아 별도의 글로 엮어 봅니다.

우선 XML, Lisp 리스트, 해시 리터럴, JSON, YAML 등은 모두 트리형 데이타를 기록하기 위한 포맷입니다. 이 점에서 이들 포맷은 모두 같은 위상을 가지고 있습니다. 이들은 모두가 다 구조적이며 얼마든지 확장이 가능하지요. (XML의 차이점은 이렇게 확장된 포맷을 DTD, XML Schema, RELAX NG 등으로 엄밀하게 정의할 수 있다는 점인데, 이 때문에 validation도 가능합니다.)

XML 포맷의 가독성이 떨어지는 이유는 크게 두가지인데 첫째로는 오픈(open) 태크와 클로즈(close) 태그에서 태그 이름이 중복되어 표시되고 있고, 둘째로는 자동으로 생성된 XML 마크업 코드의 Indentation이 임의적이 경우가 많기 때문이죠. 물론 attribute 값을 표시하는 방법이 두가지인 등, 불필요하게 복잡한 요소가 있기도 하구요. 저는 XML의 가독성 문제가 기본적으로 신택스에 있다고 생각합니다.

네임스페이스가 구분되어 있다보니까, 한 파일에서 여러 XML 규격을 mix & match하는 것이 가능한데, 과연 이게 필요한 것인지 저는 다소 회의적이네요. 새로 합쳐진 통합 규격을 지원하는 애플리케이션이 아니라면, 어짜피 이런 포맷을 처리할 수는 없겠죠. 이러한 애플리케이션 군이 필요하다면 서민구님이 언급하신 것처럼 두가지 XML 규격이 합쳐진 새로운 규격을 만드는게 더 적합한 해결책이라고 생각합니다.

포맷 validation과 HTML 렌더링이 브라우저마다 달라지는 이슈는 별도의 문제인 것 같습니다. 렌더링이 달라지는 것은 브라우저마다 각 태그를 렌더링할 때 사용하는 default 값이 다르기 때문으로, validation으로 해결될 문제는 아니라는 생각입니다. validation이 체크해 주는 것은 신택스일 뿐이고, 시맨틱적인 해석에는 별 도움을 줄 수 없지요. 사실 DTD 등이 없이도 기본적인 XML 신택스는 검증할 수 있기 때문에, 실질적인 validation의 역할은 해당 파일에서 허가된 키워드만을 쓰고 있느냐를 확인하는 역할에 제한됩니다.

이원구님의 말씀처럼 XML이 복잡해진 이유는 범용적이기 때문이라고 생각합니다. 지나치게 범용적인 도구는 막상 적합한 용처가 드물 수 있지요. XML의 장점은 분명하지만, killer 애플리케이션이 그렇게 많지는 않은 것 같습니다.

공성식님께서 YAML의 장점과 단점을 잘 지적해 주셨는데, 사실 제가 하고 싶었던 이야기도 크게 다르지 않습니다. 상황에 따라 여러 적합한 포맷이 있는데 맹목적으로 XML을 고집하지는 말자는 것이죠. 설정파일에는 YAML이 편리하지만, 문서 파일에는 YAML이 적합하지 않을 수 있습니다. (depth-level 변경 정도는 텍스트 편집기에서 지원할 수 있지 않을까요?) 빌드 파일에서는 rake처럼 아예 프로그래밍 코드를 직접 사용하는게 더 편리하다는 생각이고, Ajax에서는 JSON의 사용이 더 자연스럽다고 생각합니다. 애플리케이션에서 데이타를 저장할때는 그냥(오픈 형식의?) 바이너리 파일을 사용하는 것이 어떨까요? 파일이 열리는 속도가 훨씬 빨라질텐데 말이죠.

자바 프레임워크의 설정 파일, ant의 빌드 파일, Ajax에서의 XML, 애플 Keynote의 파일 포맷, SOAP 등은 모두 XML을 잘못 활용한 예였다고 생각합니다. 반대로 RSS, DocBook 등의 경우에는 XML이 딱이라는 생각이 들더군요. 다른 분들의 생각은 어떠신지요? :)

관련글: JSON vs XML

Posted in  | Tags , , ,  | 16 comments | 1 trackback

Comments

  1. 1.
    골빈해커 said 27 minutes later:

    SOAP 나 Keynote 파일포맷등의 경우는 나쁘지 않다고 생각하는 편이긴 합니다만(약간의 절충은 필요했다고 생각합니다), 다른건 몰라도 자바 설정파일에 대한 것은 백만배 동감합니다. 정말 짜증 이빠이죠..ㅜ_ㅜ;;


  2. 2.
    공성식 said about 2 hours later:

    Ajax에서는 JSON의 사용이 더 자연스럽다고 생각합니다.

    클라이언트쪽을 보면 당연한 거지만 아직 JSON을 지원하는 라이브러리가 그리 많지 않아 서버쪽에서 문제가 되는 것 같습니다. 그런데 어차피 이것은 인간이 직접 다루는 문제는 아니고 라이브러리 차원에서 해결되기 때문에 큰 문제는 아니라고 봅니다.

    애플리케이션에서 데이타를 저장할때는 그냥(오픈 형식의?) 바이너리 파일을 사용하는 것이 어떨까요?

    serialize (또는 pickle)을 의미하시나요? 만약 동일 언어 간의 데이터 교환이라면 별 문제가 없을 것 같습니다만 서로 다른 플랫폼이나 언어 간의 교환에선는 곤란할 것 같습니다. 사실 동일한 언어 간이라 하더라도 텍스트 포맷으로 저장할 경우 잇점이 있겠죠. 어플리케이션 없이 텍스트 에디터만으로 내용을 확인할 수 있다는 점이죠. 물론 속도야 떨어지겠지만서두요.

    OT: 대산님, 저도 몇달 전부터 맥(파워북)을 사용하고 있습니다. 그런데 가끔 한/영 전환에 문제가 있는 것 같은데 대산님은 괜찮으세요? 즉, 한글로 타이핑하다가 Cmd+Space를 누르면 바로 영문으로 전환돼야 하는데 간혹 한번에 안 돼서 두세번을 눌러야 합니다. 왜 그럴가요?


  3. 3.
    大山 said about 9 hours later:

    아, 골빈해커님 안녕하세요? 반갑습니다. :)

    Keynote가 처음 나왔을 때, 저도 XML 포맷을 사용한다는 것에 많은 기대가 있었습니다. 애플에서도 Keynote가 아닌 다른 프로그램으로 Keynote Presentation을 만들 수 있다는 홍보를 하곤 했었지요. 이제 Keynote가 나온지 3년반 정도 지났지만, 그러한 상호호환성(Interoperability)의 필요성은 이론상으로만 존재하는 것은 아닐까 하는 생각이 듭니다.

    요즘은 컴퓨터가 빨라졌어도 Keynote 파일을 열고 저장하는 것은 여전히 느리다는 답답함과 아직도 Autosave가 안되는 애플리케이션이 있다는 당황스러움 그리고 rsync로 백업하기 전에 먼저 zip으로 압축해 주어야 하는 번거로움에 조금 회의적인 입장으로 바뀐 것 같습니다.

    SOAP의 경우는 이미 HTTP에 CRUD와 관련한 오퍼레이션이 빌트인 되어 있는데 굳이 별도의 RPC 레이어를 만들 필요가 있었을까 하는 생각입니다. REST 정도면 충분하지 않을까요?


  4. 4.
    大山 said about 9 hours later:

    @공성식: 바이너리 파일은 Keynote 같이 애플리케이션 데이타를 저장하는 경우를 말한 것이었구요, 가뜩이나 lag이 문제가 되는 Ajax에서는 처음부터 JSON을 사용하는게 맞지 않았을까 싶어서요. :)

    저는 한/영 전환 문제는 없습니다만, 이전에 Spotlight의 단축키와 충돌이 나던게 생각나네요. Spotlight의 단축키도 default는 Cmd-Space거든요. System Preferences => Spotlight에 가셔서 키보드 단축키를 한번 확인해 보세요.


  5. 5.
    공성식 said about 10 hours later:

    제 생각에 애플리케이션 데이터라 하더라도 바이너리보다는 XML처럼 텍스트로 저장하는 게 장기적으로 좋다고 생각합니다. 다른 어플리케이션과의 호환 문제에 도움이 되기 때문이죠. MS 오피스도 예전부터 XML로 바꾸겠다고 공언했지만 아직 제대로 안 이뤄지고 있어 눈총을 받고 있습니다. 애플리케이션 별로 자체 구조를 갖기보다는 개방하는 것이 좋지 않을까요?

    저도 Spotlight의 단축키는 Disable시켰습니다. 그걸 안 하면 아예 한/영 전환이 안 되더군요. 뭐, 그리 큰 불편이 있는 것은 아니구요. 가끔 약간 신경쓰이는 정도... 아직 윈도우즈의 IME는 못 따라가는 것 같습니다.


  6. 6.
    大山 said about 11 hours later:

    @공성식: 저도 오픈 데이타 포맷에는 절대적으로 동의합니다. 다만 그러한 오픈 데이타 포맷을 꼭 텍스트 기반의 XML로 해야한다고 생각하지는 않습니다. Keynote/Pages 등을 써보니 불편한 점이 있더라구요. 속도 문제도 있고, 데이타가 여러 파일에 나뉘어 저장되는 문제도 있고.

    보통 같은 개발환경에서는 Serializing 방식이 어느 정도 표준화 되어 있으니까, 개별 애플리케이션이 바이너리 포맷을 사용한다고 해도 호환문제가 크리라고 보지는 않구요. 사실 특정 애플리케이션 파일이 다른 애플리케이션에서 호환되어야 하는 상황이 일반적인 것은 아니라는 생각입니다. MS 오피스의 경우는 많이 예외적이지 않은가요? (운영체제와 엮어진 독점 문제도 있었고, MS에서 일부러 파일 포맷을 obfuscate 하기도 했었지요.)

    한/영 전환 문제는 저는 겪어보지 못했습니다만..


  7. 7.
    CN said about 14 hours later:

    저는 대부분의 경우에 바이너리 포맷으로 된 데이터를 매우 싫어합니다. 그들은 유닉스 툴들에 친화적이지 못하고 유연하지 못합니다. http://www.catb.org/~esr/writings/taoup/html/textualitychapter.html

    일반화된 자료교환으로 XML은 여전히 의미가 있다고 생각하고 있습니다. JSON등은 조금 불명확하다는 느낌을 받고 있습니다. (물론 Ajax를 한다면 전 JSON쪽에 큰 의미를 두겠습니다.)


  8. 8.
    大山 said about 15 hours later:

    @CN: 저는 XML도 유닉스 툴에 친화적이지는 않다는 생각입니다. recursive한 데이타 포맷은 정규식으로 처리하기가 애매하더라구요. (JSON은 Ajax/JavaScript에서 사용되는게 맞습니다.)

    바이너리가 적합한 형식인 경우도 있지 않을까요? 예를 들면, MP3라든가 JPEG이라든가. Keynote나 PowerPoint 파일의 경우에는 쉘에서 처리해야 할 경우가 있을지 모르겠구요~ :)


  9. 9.
    가짜집시 said about 18 hours later:

    만약 AJAX 에 E4X를 사용할 수 있는 상황이라면 굳이 JSON 을 써야할 이유란 것도 별로 없습니다. 아마도 그런게 XML의 매력이겠지요. :)


  10. 10.
    大山 said about 18 hours later:

    @가짜집시: XML 지원을 위한 JavaScript 신택스의 확장이라.. JSON에 별다른 단점이 있는 것도 아니고, 파싱 효율성도 분명 XML 보다는 우수할 텐데, 그렇게까지 XML 사용을 추구했을때 어떤 장점이 있을까요? :)


  11. 11.
    골빈해커 said 1 day later:

    성능이야 범용성이냐의 문제로 크게 나뉘는 것 같군요 ^^ 하드웨어 성능은 나날이 발전해갑니다. 그렇다면, 그러니까 미래를 생각한다면 역시 범용성쪽으로 가는게 맞지 않을까요? ^^


  12. 12.
    大山 said 1 day later:

    @골빈해커: 음, 이원구님의 말씀대로, XML은 단지 기계를 위한 인터페이스일 수도 있겠죠. 골빈해커님 말씀처럼 하드웨어의 성능은 앞으로도 계속 나아질 것이구요.

    하지만 저는 오픈 포맷이기만 하다면, 어떤 포맷인지가 중요하지는 않다는 생각입니다. 그냥 상황에 적합한 포맷을 사용하면 되겠지요.

    Ajax에서는 XML을 파싱하기 위해서만도 클라이언트가 매번 별도의 라이브러리를 다운로드 받아야 하기 때문에, JSON을 사용하는 것이 여러모로 더 합리적이라는 생각입니다. ant나 자바 프레임워크에서 XML을 핸드 코딩하는 것은 상당히 괴로운 일이었구요. ruby의 빌드 프로그램인 rake와 레일스를 사용하게 되면서, 맹목적인 XML 사용에도 문제가 많다는 생각이 들었습니다.

    이미 표준으로 확립된 XHTML과 RSS나 여러 포맷으로 변환할 필요가 있는 DocBook 같은 경우에는 굳이 XML을 마다할 필요가 없지요. REST 또한 과도적인 표준이라는 생각이긴 하지만, 나름의 역할이 없지는 않구요. 하지만 그 외에는 XML이 적합한 곳이 저로서는 별로 눈에 띄지 않는군요.

    물론 시맨틱웹 쪽에서는 XML을 많이 사용하지만, 저는 시맨틱웹 자체에 회의적이기 때문에, 여기에 큰 의미를 두지는 않습니다. (이 내용은 나중에 다른 글에서 다루도록 하지요.)

    단지 RSS, DocBook, XHTML, REST 때문이었다면.. XML이 몰고왔던 그 엄청난 hype에 허탈함이 느껴지는건 저만인지요? (물론 RSS의 중요성을 간과하는 것은 아닙니다.)


  13. 13.
    nohmad said 1 day later:

    JSON은 자바스크립트와 통신하기 위해 자바스크립트 스펙을 차용한 것이므로, 애초에 Ajax를 위해 만들어졌다고 봐도 좋을 것 같습니다. JSON이 아니면 클라이언트측 자바스크립트에서 구조적인 데이터를 파싱하고 빌드하기 위한 방법이 마땅치 않습니다. 천상 XML을 DOM으로 접근해서 쓰는 정도 외에는 마땅한 방법이 없는데, DOM의 그 성실함이 느껴지는 길고 지루한 인터페이스를 데이터 획득에 쓴다는 건 어울리지 않아 보입니다. 루비나 파이썬, 자바 등에서도 DOM을 직접 사용하는 예는 거의 찾아보기 힘들지요. JSON의 경우는 다들 아시다시피 eval 한 번이면 끝입니다.

    여기서부터는 그냥 제 가정입니다. 구현의 관점에서 보더라도 DOM 파싱은 자바스크립트 엔진에서 직접 구현하는 것보다는 렌더링 엔진에 맡기고 그 인터페이스를 사용하는 식으로 구현하는 경우가 많을 것 같은은데, 렌더링이 필요없는 순수 데이터를 렌더러에 의지한다는 것도 이상하죠.


  14. 14.
    大山 said 1 day later:

    @nohmad: JSON이 아직도 널리 알려지지 않은 것 같습니다. 노팀장님께서 언제 JSON 소갯글 하나 써주세요~ :)

    JavaScript 기반의 XML 파서가 있기는 한데요, same origin policy 때문에 이게 과연 쓸모가 있을지 모르겠습니다.. ;)


  15. 15.
    大山 said 2 days later:

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

    @공성식: 저는 그냥 사람들이 스스로 라이브러리 이름을 짓게 해도 괜찮다고 생각합니다. 개발자는(저를 포함한) 모든 경우의 수에 대비하여 계획을 세우는 경향이 있지만, 그러지 않아도 사람들은 잘 적응을 하더라구요. 이런 문제는 '법' 보다는 '관례'가 효과적인 것 같습니다~ :)


  16. 16.
    noname said 7 months later:

    열기와 닫기 태그가 중복되는 건 오히려 명시적인 방법이라고 봅니다. 잘 생각해보면 앞의 태그만 명시되어 있고 뒤의 태그명은 end 이런 식이라면 포함하는 요소가 길 경우 뒤의 태그만으론 뭐가 적혀있는지 알 수가 없습니다.

    그러고보니 xml이 사람이 읽기 편한 문서라는 걸 전제로 해서 그런 생각이 들지 않는가 싶은데.. xml이 읽을 수는 있지만 결코 읽기 편하게 만들려고 제정한 표준은 아닌 것 같습니다.어디까지나 사람이 읽을 수 있다.. 그 정도랄까요. (바이너리 코드는 눈으론 못 읽으니까요)

    애플리케이션에서 데이터 저장 형식을 바이너리로 할 것이냐 아스키로 할 것이냐는 오래된 이슈가 아닐까 싶네요. 바이너리가 빠르긴 하겠지만 프로그램을 통하지 않는 디버깅이 필요할 때도 있다고 봅니다. 물론 이때 선택할 아스키 형식을 단순 정의 text냐 xml이냐 os에서 채택하고 있는 방식이냐는 선택 사항입니다.

    Ajax의 경우 굳이 데이터 교환에 xml형식을 쓸 필요가 없습니다. 사실 x가 붙어 있어서 그렇지 괜한 오버헤드라는 생각이 듭니다. Aj로 써도 충분. 단순 데이터 통신/교환에는 굳이 xml로 주고 받을 필요도 없고 그게 클라이언트 측의 부담으로까지 이어지니까요. (=브라우저 응답 속도 하락)


Trackbacks

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

  1. From
    JSON in Ajax
    JSON in Ajax

Comments are disabled