JSON 대 XML에 대한 심층 분석, 1부: 각 표준의 역사
게시 됨: 2022-03-11데스크탑에서 웹, 모바일에 이르기까지 오늘날 우리가 사용하는 거의 모든 컴퓨터 애플리케이션은 JSON과 XML이라는 두 가지 주요 메시지 표준 중 하나에 의존합니다. 오늘날 JSON은 가장 널리 사용되는 형식이지만 지난 5년 이내에 XML을 추월했습니다. "JSON vs. XML"에 대한 빠른 온라인 검색은 두 표준을 비교하는 수많은 기사와 블로그 게시물을 가져올 것이며, JSON의 단순성을 칭찬하고 XML의 장황함을 비판하는 편견이 점차 확대되는 것에 해당합니다. 많은 기사에서 JSON이 간결한 의미 체계와 과거의 비효율적이고 혼란스러운 표준으로 XML을 할인했기 때문에 XML보다 우수하다고 주장합니다. 언뜻 보면 JSON이 가장 인기 있는 것 같습니다. 그래서 JSON이 단순히 XML보다 낫습니까? "JSON 대 XML"의 싸움은 표면적으로는 JSON으로 갈 수 있지만 깊이는 눈에 보이는 것 이상의 것이 있습니다.
이 기사의 1부에서는 다음을 수행합니다.
- XML과 JSON의 원래 목적을 밝히기 위해 웹의 역사를 자세히 살펴보십시오.
- JSON이 XML보다 더 대중화된 이유를 확인하려면 최근 몇 년 동안의 소프트웨어 동향의 발전을 고려하십시오.
JSON과 XML의 역사
XML보다 JSON이 인기 있는 이유를 알아보기 위해 웹의 역사와 웹 1.0에서 웹 2.0으로의 진화가 개발 동향에 어떤 영향을 미쳤는지 살펴보겠습니다.
웹 1.0: HTML
1990년대 초반은 웹 1.0의 여명기였습니다. HTML은 1991년에 도입되었으며 대학, 기업 및 정부 기관에서 웹 언어로 널리 채택되었습니다. HTML은 1970년대 IBM에서 발명한 SGML 또는 "표준 일반화 마크업 언어"에서 유래했습니다. 대규모 채택 외에도 HTML은 멀티미디어, 애니메이션, 온라인 응용 프로그램, 전자 상거래 등을 지원하기 위해 포함된 대규모 적응 을 보았습니다. SGML의 파생물인 HTML은 회사가 원래 개념을 넘어서는 요구 사항을 충족하기 위해 자유롭게 확장하는 것을 제한하는 엄격한 사양이 부족했습니다. Netscape와 Microsoft 간의 가장 인기 있는 웹 브라우저 경쟁은 빠른 진전을 가져왔지만 표준의 끊임없는 파편화로 이어졌습니다. 치열한 경쟁은 두 회사의 HTML 확장으로 인해 브라우저가 고유한 버전의 HTML을 지원하게 되면서 "다이버전스 재앙"을 초래했습니다. 개발자들이 브라우저를 위한 상호 운용 가능한 코드를 작성하는 데 어려움을 겪으면서 이 분기 재앙은 웹 애플리케이션에 큰 문제가 되었습니다.
웹 1.1: XML + HTML = XHTML
1990년대 후반에 Jon Bosak, Tim Bray, James Clark 등을 포함한 그룹의 사람들이 "eXtensible Markup Language"라는 XML을 고안했습니다. SGML과 마찬가지로 XML은 그 자체가 마크업 언어가 아니라 마크업 언어의 정의를 위한 사양입니다. XML은 구조화된 콘텐츠를 정의하고 시행하는 수단을 제공하도록 설계된 SGML에서 진화한 것입니다. "컴퓨팅의 성배"로 간주되는 1 XML 언어는 "이종 시스템 간의 보편적인 데이터 교환 문제를 해결하기 위해" 노력했습니다(Dr. Charles Goldfarb) 2 . HTML의 지속적인 단편화 대신에 World Wide Web 위원회(W3C)는 World Wide Web에 대한 새로운 표준의 채택에 있어 업계 간의 호환성과 합의를 촉진하기 위해 구성되었습니다. 3 W3C는 HTML을 XML 응용 프로그램으로 재구성하는 것에 대해 설정했으며 결과는 XHTML이 되었습니다.
XHTML은 XML에 대한 관심을 불러일으키는 큰 이니셔티브였지만 XML에 관한 모든 것의 작은 부분일 뿐입니다.
XML은 업계에서 엄격한 의미 체계로 모든 응용 프로그램에 대한 사용자 지정 마크업 언어를 지정할 수 있는 방법을 제공했습니다. "엄격한 의미론"이라는 키워드로 XML은 모든 XML 문서, XML 하위 언어의 데이터 무결성을 주장할 수 있는 표준을 정의했습니다. 이종 시스템과 인터페이스하는 분산 엔터프라이즈 응용 프로그램을 개발하는 소프트웨어 회사의 경우 데이터 무결성을 주장할 수 있는 마크업 언어가 중요했습니다. 기업은 XML로 구조화된 콘텐츠를 정의함으로써 이 기술의 기능을 활용하여 모든 플랫폼과 상호 운용하고 모든 데이터 교환의 데이터 무결성을 강화하며 시스템의 소프트웨어 위험을 체계적으로 줄였습니다. 업계에서 XML은 모든 플랫폼의 응용 프로그램이 쉽게 읽고 처리할 수 있는 형식으로 모든 종류의 데이터를 저장, 통신 및 검증하는 기술을 제공했습니다. HTML의 경우 XML은 "다이버전스 재앙"을 해결하겠다고 약속했습니다.
자바 및 .NET
2000년대 초, 웹은 Sun과 Microsoft의 두 회사에서 관리했습니다. 당시 프로그래밍 언어의 지형은 서버 측에 크게 기울어져 있었습니다. 웹 애플리케이션을 위한 공통 아키텍처는 브라우저에 전달될 백엔드의 HTML 페이지를 렌더링하는 서버에 의존했습니다. 이 접근 방식은 백엔드 기술을 강조하여 최고의 백엔드 플랫폼인 Java 및 C#.NET을 대중화했습니다. Sun Microsystems에서 개발한 Java는 새로운 "Write Once Run Anywhere" 4 접근 방식으로 아키텍처 간 문제를 해결한 차세대 객체 지향 프로그래밍 언어를 주도했습니다. Microsoft는 .NET, C# 및 CLR(공용 언어 런타임)을 따랐고 데이터 상호 운용성 퍼즐을 해결하기 위한 선택 접근 방식으로 XML을 주목했습니다. Microsoft는 XML의 가장 큰 옹호자가 되었으며 회사는 XML을 탁월한 .NET 이니셔티브의 필수적인 부분으로 선택했습니다. "XML 웹 서비스를 위한 플랫폼"으로 광고되는 5개의 .NET 응용 프로그램은 다른 플랫폼과의 통신에 XML을 사용하도록 설계되었습니다. Microsoft의 데이터 교환 표준으로 선택된 XML은 SQL Server 및 Exchange와 같은 주력 서버 제품에 통합되었습니다.
웹 1.2: AJAX
브라우저에 미리 렌더링된 HTML 페이지를 전달하는 것은 확장할 수 없었고 웹에는 대안이 필요했습니다. 서버에서 새 페이지를 로드해야 하는 각 사용자 작업과 함께 더 많은 사람들이 웹을 확장함에 따라 프로세스 로드와 대역폭 소비가 문제가 되었습니다.
Netscape와 Microsoft는 ActiveX 및 JavaScript와 같은 비동기 콘텐츠 전달을 통해 이 문제를 해결하기 위해 노력했습니다. 1998년에 Microsoft Outlook Web Access 팀은 나중에 Mozilla, Safari, Opera 및 기타 JavaScript 브라우저에서 XMLHttpRequest 객체로 구현한 ActiveX 6 의 개념을 개발했습니다.
AJAX는 Microsoft의 ActiveX와 Netscape의 JavaScript에서 탄생했습니다.
"Asynchronous JavaScript and XML"의 약어인 AJAX라는 용어는 페이지를 다시 로드할 필요 없이 백그라운드에서 서버와 통신하는 웹 애플리케이션을 구현하는 데 사용할 수 있는 광범위한 웹 기술을 나타냅니다. AJAX라는 용어를 만든 기사에서 Jesse James Garrett 은 주요 개념을 다음과 같이 설명했습니다.
- 프레젠테이션용 HTML(또는 XHTML) 및 CSS.
- 데이터의 동적 표시 및 상호 작용을 위한 DOM(문서 개체 모델)입니다.
- 데이터 교환을 위한 XML과 조작을 위한 XSLT.
- 비동기 통신을 위한
XMLHttpRequest객체. - 이러한 기술을 결합하는 JavaScript.
서버 부하를 줄이고 상당한 대역폭을 절약하는 것으로 입증된 비동기식 콘텐츠 전달을 통해 AJAX는 게임 체인저였습니다. 브라우저에 XMLHttpRequest 를 도입함으로써 개발자는 프런트 엔드에서 더 복잡한 로직을 구현할 수 있었습니다. Google은 2004년 Gmail과 2005년 Google 지도를 통해 표준 호환 브라우저 간 AJAX를 광범위하게 배포했습니다. 9 그리고 2004년 10월 Kayak.com의 공개 베타 릴리스는 AJAX를 사용한 최초의 대규모 전자 상거래 중 하나였습니다. 10
웹 2.0: 단일 페이지 애플리케이션
웹 애플리케이션을 위한 확장 가능한 아키텍처로 AJAX를 채택하면서 Web 2.0: SPA(단일 페이지 애플리케이션)가 시작되었습니다. 11 각 사용자 상호 작용에 대해 전체 페이지를 다시 로드하는 대신 SPA는 브라우저 내에서 현재 페이지를 동적으로 다시 작성합니다. 서버 부하 및 대역폭 소비의 상당한 감소 외에도 SPA 접근 방식을 사용하면 사용자 상호 작용 중 원활하고 중단되지 않는 경험으로 인해 웹 응용 프로그램이 데스크톱 응용 프로그램과 유사할 수 있습니다.
2002년 4월 Stuart Morris는 slashdotslash.com 12 에서 최초의 SPA 중 하나를 작성했으며 같은 해 말 Lucas Birdeau, Kevin Hakman, Michael Peachey 및 Evan Yeh는 미국 특허 8,136,109에서 단일 페이지 애플리케이션 구현을 설명했습니다. 13 특허에서는 JavaScript를 사용하여 사용자 인터페이스를 표시하고 애플리케이션 로직을 실행하며 웹 서버와 통신하는 웹 브라우저에 대해 설명했습니다.
Google의 Gmail, Google 지도, Kayak의 공개 베타는 웹 애플리케이션 개발의 새로운 시대를 열었습니다. AJAX가 지원되는 브라우저를 통해 개발자는 웹용으로 풍부한 애플리케이션을 작성할 수 있습니다. JavaScript의 쉬운 의미는 모든 분야의 프로그래머가 응용 프로그램 개발을 가능하게 했습니다. 소프트웨어 개발에 대한 진입 장벽이 크게 줄어들었고 전 세계의 개별 개발자들이 자신의 라이브러리와 프레임워크로 기여하기 시작했습니다. 여러 제조업체의 브라우저에서 AJAX 동작을 정규화하는 jQuery와 같은 인기 있는 라이브러리는 AJAX 혁명을 더욱 발전시켰습니다.
JSON의 부상
2001년 4월 Douglas Crockford와 Chip Morningstar는 Morningstar의 Bay Area 차고에 있는 컴퓨터에서 첫 번째 JSON 메시지를 보냈습니다. Crockford와 Morningstar는 "AJAX"라는 용어가 만들어지기 훨씬 전에 AJAX 애플리케이션을 구축하려고 시도했지만 달성하려는 브라우저 지원이 좋지 않았습니다. 그들은 페이지가 로드된 후 애플리케이션에 데이터를 전달하기를 원했지만 이것이 모든 브라우저에서 작동하도록 허용하는 방법을 찾지 못했습니다.
2001년에 AJAX의 개발은 막 시작되었고 Internet Explorer 5와 Netscape 4에는 아직 상호 운용 가능한 XMLHttpRequest 개체 형식이 없었습니다. 그래서 Crockford와 Morningstar는 두 브라우저 모두에서 작동하는 다른 접근 방식을 사용했습니다.
첫 번째 JSON 메시지는 다음과 같습니다.
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session," do: "test," text: "Hello world" } ) </script></head></html> 이 메시지는 실제로 일부 JavaScript가 포함된 HTML 문서이며 메시지의 일부만 오늘날 우리가 알고 있는 JSON과 유사합니다. Crockford와 Morningstar는 <iframe> 을 위와 같은 HTML 문서를 반환하는 URL로 지정하여 비동기적으로 데이터를 로드할 수 있었습니다. 응답이 수신되면 HTML의 JavaScript가 실행되고 하위 창에서 상위 창에 액세스하는 것을 방지하는 브라우저 보호를 우회하여 개체 리터럴이 응용 프로그램의 기본 프레임으로 다시 전달되었습니다. 때때로 "숨겨진 프레임 기술"이라고 하는 이 프레임 기반 기술은 XMLHttpRequest 가 널리 구현되기 전인 90년대 후반에 일반적으로 사용되었습니다. 14
이 접근 방식은 모든 브라우저에서 상호 운용성을 제공했기 때문에 개발자에게 매력적이었습니다. 메시지는 JavaScript일 뿐이므로 특별한 구문 분석이 필요하지 않습니다. 이런 방식으로 JavaScript를 사용한다는 아이디어는 너무 간단해서 Crockford 자신이 이를 처음 사용한 사람이 아니라고 말했습니다. 그는 Netscape의 누군가가 1996년에 정보를 전달하기 위해 JavaScript를 사용하고 있었다고 주장합니다. 15
Crockford와 Morningstar는 모든 종류의 애플리케이션에 사용할 수 있는 무언가가 있다는 것을 깨달았습니다. 그들은 형식에 "JavaScript Object Notation"을 줄인 JSON이라고 명명했습니다. 그들은 고객에게 그것을 피칭하기 시작했지만 곧 많은 사람들이 공식 사양이 없는 새로운 기술에 대한 기회를 내키지 않는다는 것을 알게 되었습니다. 그래서 Crockford는 하나를 쓰기로 결정했습니다. 2002년에 Crockford는 도메인 JSON.org를 구입하고 JSON 문법과 파서의 참조 구현을 올렸습니다. 2013년에 비준된 JSON ECMA 표준에 대한 눈에 띄는 링크가 포함되어 있지만 웹사이트는 여전히 운영 중입니다. 16 웹사이트를 개설한 후 Crockford는 JSON을 홍보하기 위해 조금 더 노력했지만 곧 다른 프로그래밍 언어에 대한 JSON 파서 구현을 제출하는 사람들을 찾았습니다. JSON의 기원은 분명히 JavaScript와 연결되어 있지만 JSON이 임의의 언어 간에 데이터를 교환하는 데 적합하다는 것이 분명해졌습니다.
AJAX의 JSON
2005년 Jesse James Garrett은 블로그 게시물에서 "AJAX"라는 용어를 만들어 AJAX가 하나의 새로운 기술이 아니라 "각각 고유하게 번성하고 강력한 새로운 방식으로 함께 모인 여러 기술"이라고 강조했습니다. 16 그의 블로그 게시물에서는 개발자가 JavaScript 및 XMLHttpRequest 를 활용하여 일반적인 웹 페이지보다 응답성이 높고 상태를 저장하는 새로운 종류의 응용 프로그램을 구축할 수 있는 방법에 대해 설명했습니다. 그는 AJAX 기술을 사용하는 웹사이트의 예로 Gmail, Google Maps 및 Flickr를 지적했습니다. "AJAX"의 "X"는 XML을 의미하지만 Garrett은 JSON을 완전히 수용 가능한 대안으로 지적했습니다. 그는 "XML은 AJAX 클라이언트 안팎으로 데이터를 가져오는 가장 완벽하게 개발된 수단이지만 JavaScript Object Notation 또는 유사한 데이터 구조화 수단을 사용하여 동일한 효과를 달성하지 못할 이유가 없습니다."라고 썼습니다. 17
JavaScript와 JSON은 분명히 함께 의미가 있습니다. JSON의 의미 체계는 JavaScript에 직접 매핑되어 언어에 대한 기본 데이터 교환 형식이 됩니다. 개발자들은 JSON이 JavaScript에서 작업하기 더 쉽다는 것을 빠르게 발견했고 많은 사람들이 XML보다 선호하게 되었습니다.
JSON이 블로고스피어의 관심을 끌면서 JSON의 확산이 시작되었습니다.
JSON이 XML보다 더 대중화된 이유
JSON은 JavaScript 애플리케이션의 데이터에 대한 기본 형식입니다. 지난 10년 동안 JavaScript의 대중화로 인해 다른 데이터 형식보다 더 많은 JSON 메시지가 생성되었습니다. JavaScript로 애플리케이션을 작성하려면 데이터 교환에 JSON을 사용해야 합니다. 다른 형식도 가능하지만 JSON보다 더 많은 노력이 필요합니다. JavaScript가 애플리케이션 개발을 위해 인기를 얻으면서 JSON은 사용하기 쉽고 기본적으로 통합된 데이터 교환 형식으로 그 뒤를 이었습니다.
블로고스피어에 관한 한, 다른 어떤 프로그래밍 플랫폼보다 JavaScript(따라서 JSON)에 대해 더 많은 기사, 샘플 및 자습서가 작성되었습니다.
웹의 역사와 진화 경로는 JSON의 대중화에 중요한 역할을 했습니다. 스택 오버플로에 따르면 이제 다른 데이터 교환 형식보다 JSON에 대해 더 많은 질문이 제기됩니다. 18
Google 트렌드에 따르면 JSON과 XML에 대한 검색 관심도를 비교하는 유사한 프로필이 표시됩니다. 19
JavaScript의 확산은 JSON이 XML보다 낫다는 것을 의미합니까?
개발자 커뮤니티는 JSON이 간결한 선언 범위와 간단한 의미로 인해 XML보다 더 대중적이라고 주장합니다. Douglas Crockford는 JSON.org에서 JSON의 장점 중 일부를 다음과 같이 요약했습니다. 20 XML에 대한 다른 비평가들은 "꺾쇠 괄호 세금"으로 XML의 장황함에 초점을 맞췄습니다. 21 XML 형식에서는 각 여는 태그가 닫는 태그와 일치해야 하므로 압축 해제 시 XML 문서를 동등한 JSON 문서보다 훨씬 더 크게 만들 수 있는 중복 정보가 생성됩니다. 그리고 아마도 더 중요한 것은 개발자들이 "또한 XML 문서를 읽기 어렵게 만듭니다."라고 말합니다. 22
JSON은 단순함과 간결한 의미로 인해 쉽게 찬사를 받았고 XML은 장황하고 지나치게 복잡해 보이기 때문에 과거의 구식 표준으로 분류되었습니다. 많은 기사와 블로그 게시물은 JSON을 XML과 비교할 때 제한된 관점을 제공하므로 독자는 JSON이 XML을 대체한다고 믿게 됩니다. 그렇지 않다!
기사와 블로그 게시물이 제공하는 제한된 관점으로 인해 독자들은 XML을 구식으로 간주하여 소프트웨어 아키텍처와 변화에 대한 탄력성을 개선하고 소프트웨어 위험을 체계적으로 줄이는 데 도움이 될 수 있는 강력한 기능을 많은 사람들이 알지 못합니다.
JSON은 오늘날 가장 널리 사용되는 언어로서 JavaScript가 우세하기 때문에 XML보다 더 대중적입니다. JavaScript가 지난 10년 동안 소프트웨어 트렌드에 영향을 미치면서 JSON은 다른 어떤 데이터 교환 형식보다 계속해서 더 많은 관심을 받고 있습니다. 블로고스피어는 "JSON이 XML보다 낫다"고 재빨리 되풀이하지만, 대부분의 경우 이러한 진술은 정당화되지 않거나 의미 체계 및 장황함에 관한 단순한 비교로 뒷받침됩니다. 그렇다면 두 표준 중 하나가 다른 표준보다 더 나은가요? 이 질문에 대한 답은 각 표준에 대한 더 깊은 평가를 통해서만 얻을 수 있습니다.
결론
1990년부터 오늘날까지 웹은 먼 길을 왔습니다. Netscape와 Microsoft 간의 브라우저 전쟁은 HTML의 다이버전스 재앙으로 이어졌고 웹을 저장하기 위한 솔루션이 필요했습니다. XML은 XHTML을 공식화하고 전체 컴퓨팅을 위한 성배 솔루션을 제공하기 위해 발명되었습니다. 백엔드 서버에 의한 전체 HTML 페이지 렌더링에서 AJAX 및 SPA에 이르기까지 웹 아키텍처 및 브라우저 개발의 추세는 JavaScript에 초점을 맞추고 전 세계 개발자를 JSON으로 이끌고 있습니다.
JSON의 인기는 JavaScript의 인기와 상관관계가 있습니다. 사용 용이성과 짧은 학습 곡선으로 JavaScript는 다른 어떤 언어보다 소프트웨어를 작성하는 새로운 개발자를 더 많이 데려왔습니다. 가장 인기 있는 개발 플랫폼과 JSON의 기본 통합을 통해 다른 데이터 교환 형식보다 Stack Overflow에서 JSON에 대해 더 많은 질문을 하는 것은 놀라운 일이 아닙니다.
최근 몇 년 동안 더 많은 JavaScript 개발자를 업계에 끌어들이는 소프트웨어 동향으로 JSON은 "가장 인기 있는 데이터 교환 형식"이라는 칭호를 얻었습니다.
표면적으로 "JSON 대 XML"의 싸움은 JSON으로 진행되지만, 깊이에는 눈에 보이는 것 이상의 것이 있습니다.
이 기사의 2부에서는 JSON과 XML의 기술적 강점과 약점을 자세히 살펴보고 각 표준이 공통 애플리케이션과 기업에 적합한지 평가할 것입니다. "데이터 교환"을 자세히 살펴보면 전체 응용 프로그램의 소프트웨어 위험에 미치는 영향의 폭을 알 수 있습니다. JSON과 XML의 근본적인 차이점을 더 깊이 이해하면 개발자가 프로젝트 요구 사항과 관련하여 각 표준의 소프트웨어 위험을 더 잘 평가할 수 있으므로 개발자가 더 안정적이고 버그와 미래에 더 강한 소프트웨어를 빌드할 수 있습니다. 알려지지 않은.
그건 그렇고, JSON 사양의 흥미로운 단점은 자식 속성이 부모 속성을 참조하는 양방향 관계가 있는 JavaScript 개체를 JSON으로 변환할 수 없다는 것입니다. 그렇게 하면 Uncaught TypeError: Converting circular structure to JSON 오류가 발생합니다. 이 제한 사항에 대한 해킹 은 JSON의 양방향 관계 지원을 참조하세요.
참고문헌
1. 인터넷: 역사 백과사전. 연대기, 3권, p. 130(ABC-CLIO, 2005)
2. 메타데이터, 의미론 및 온톨로지 핸드북, p. 109 (World Scientific, 2013년 12월)
3. WebDiy.org - 월드 와이드 웹 컨소시엄(W3C) - 연혁
4. "JavaSoft는 Java 1.0을 제공합니다."(Sun Microsystems, 1996년 1월)
5. 차세대 인터넷을 공간적으로 활성화(David Engen, 2002년 1월)
6. XMLHTTP 이야기(AlexHopmann.com, 2007년 1월)
7. Ajax 시작하기 - 2페이지(Wiley Publishing, 2007년 3월)
8. Ajax: 웹 애플리케이션에 대한 새로운 접근(Jesse James Garrett, 2005년 2월)
9. Ajax의 간략한 역사(Aaron Swartz, 2005년 12월)
10. "Kayak.com은 무엇입니까?" (기업 백그라운더, 2008년 10월)
11. 이너 브라우징: 브라우징 탐색 패러다임 확장(Netscape, 2003년 5월)
12. "DHTML을 사용한 독립형 웹사이트" (SlashDotSlash.com, 2012년 7월)
13. 클라이언트 측 조작을 허용하는 데이터 및 형식 지정 정보 전달(미국 특허국, 2002년 4월)
14. "Ajax란 무엇인가?" 전문 Ajax, 2nd ed. (Wiley, 2007년 3월)
15. Douglas Crockford: JSON 사가(Yahoo!, 2009년 7월)
16. ECMA 표준 404(ECMA International, 2017년 12월)
17. Ajax: 웹 애플리케이션에 대한 새로운 접근(Jesse James Garrett, 2005년 2월)
18. 스택 오버플로 추세(스택 오버플로, 2009-2019)
19. 구글 트렌드(Google, 2004-2019)
20. JSON: XML에 대한 무지방 대안(Crockford, 2006)
21. XML: 앵글 브래킷 세금(Coding Horror, 2008년 5월)
22. Xml 짜증 (WikiWikiWeb, 2016)