JSON vs XML
Posted by 大山 Tue, 26 Dec 2006 23:30:00 GMT
지난 9월쯤에 XML에 태클을 거는 글을 쓴적이 있었습니다. 그에 이어지는 글에서도 많은 분들이 토론에 참여해 주셔서 저도 생각의 폭을 넓히는 계기가 되었구요. (그때의 토론을 기반으로 제가 짧은 글을 마소에 기고하기도 했습니다.)
이제 미국쪽 블로고스피어에서도 비슷한 토론이 시작된 것 같습니다. 관심있으신 분들은 참고하시면 좋을 것 같습니다.
Posted by 大山 Tue, 26 Dec 2006 23:30:00 GMT
지난 9월쯤에 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 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은 어디에 유용할까?