둘째날 오후에는 Douglas Crockford의 JSON BoF 에 참석했습니다.

대략 1시간 조금 넘게 진행되었는데, 초반에는 사람도 별로 없고 해서(5~6 명 정도) 오손도손 모여앉아 "JSON"의 역사에 대한 Crockford의 이야기를 듣는 분위기였습니다. 대충 요약하자면 "꽤 오래 전에 JSON을 만들었는데, Ajax라는게 뜨면서 덩달아 유명세를 타고 있다"고 말했습니다. 처음엔 얘기하는 사람이 Crockford 혼자여서 그랬는지, 중간 중간 어색한 정적이 이어지다가 누군가의 질문을 시작으로 열띤 토론 분위기가 연출되기 시작했습니다.

"JSON의 각종 응용들에 대해 어떻게 생각하느냐?"

는 질문이었는데, JSONT, JSONP 등을 염두한 질문이었던 것 같습니다. Crockford의 대답은:

"JSONT는 매우 흥미롭다(JSONT is very interesting). 하지만 JSONP는 안좋다(JSONP is bad thing)"

였습니다. 재미있었던 점은 Crockford가 "JSONP is bad thing"을 말하던 찰나, 전날 "Advanced JSON" 세션을 발표한 Kris Zyp이 성큼성큼 걸어들어오고 있었다는 것인데요 그는 열성적인 JSONP 옹호자 중 한 명입니다.

Crockford가 JSONP를 안 좋게 생각하는 이유는 바로 보안 문제 때문입니다. 지난 글에서 간단히 설명한 바와 같이 JSONP는 "Dynamic Script Tags" 혹은 "On Demend Javascript"라고 불리는 기술을 이용하여 브라우저의 "Same Origin Policy"를 피해가고 있습니다. 신뢰할 수 없는 서드파티와 JSONP로 통신을 할 경우 XSS(Cross Site Scripting) 공격에 노출될 위험에 고스란히 노출되게 됩니다.

Crockford는 클라이언트 사이드에서 매시업이 활발히 일어나려면 몇 가지 근본적인 문제들이 해결되어야 한다고 말합니다. 예를 들어 자바스크립트는 모든 객체를 하나의 공용 공간(common global space)에 몽땅 담아버리기 때문에 하나의 매시업 컴포넌트가 가지는 데이터를 다른 매시업 컴포넌트로부터 숨길 방도가 없습니다. 따라서 하나의 컴포넌트에서 접근할 수 있는 모든 데이터에 다른 컴포넌트들도 마음껏 접근할 수 있는거죠. 이러한 문제를 해결하기 위한 보안 모델이 "Same Origin Policy"인데 그는 이 보안 모델 자체가 임시 방편적인 것이라고 주장합니다.

또 다른 문제는 DOM인데, 모든 HTML 요소가 하나의 Tree에 연결되어 있다는 점, 그리고 각 Element가 Sibling, Parent, Child 관계를 따라 연결되어 있다는 점입니다. 따라서, 어떠한 하나의 Element라도 얻게 되면, 이 Element를 통해 전체 HTML Tree에 접근할 수 있게 된다는 것이죠.

이러한 문제들로 인해서 결국은 "둘 이상의 서버에서 전송된 스크립트가 하나의 페이지에 공존하는 모든 경우에" 해당 웹 애플리케이션은 근본적으로 안전하지 못한 것으로 간주되어야 한다는 주장입니다.

이에 대한 대안으로 Crockford가 제안하고 있는 큰 그림은 JSONRequest 입니다. 작동하지도 않는 "Same Origin Policy"를 없애버리고(이미 Dynamic Script Tags 같은 일종의 "hack"을 이용하면 깨져버리기 때문), "JSON"만 주고 받을 수 있는 안전한 통신 규약을 만들자는 아이디어 입니다.

좋은 이야기입니다만 이 제안이 실현되려면 브라우저 벤더들이 이를 적극적으로 수용해야 하는데, 이런 방식으로는 최소 앞으로 5년 이내에는 JSONRequest를 지원하는 브라우저가 널리 보급될 것을 기대하긴 힘들다는 것이 문제입니다.

차라리 Google Gears에 넣어버리는 것이 매우 현실적인 방법이 아닐까 하는 생각이 들어서 컨퍼런스가 끝난 후 검색을 해봤더니, 아니나 다를까 (Yahoo의) Crockford가 이미 몇 달 전 Google에 방문해서 강연 겸 제안을 했더군요. Gears의 WorkerPool을 Sandbox로 만들고, WorkerPool 간의 통신 채널을 JSONRequest로 제한하는 등의 아이디어였습니다. 즉, 현재 Offline 지원에 집중하고 있는 GoogleGears가 매시업 애플리케이션을 위한 보안 문제도 다루어주길 바란다는 제안이었습니다(이 제안이 수용되면 정말 좋겠습니다 ^^).

다시 BoF 얘기로 돌아와서, 이러한 비판에 대한 Kris Zyp의 대답은 CrossSafe 였습니다. CrossSafe는 (역시나) Kris Zyp이 직접 개발한 트릭으로써 Proxy를 쓰지 않고 "Dynamic Script Tags"를 사용하면서도 XSS 공격을 피하갈 수 있도록 해주며, Crockford가 제안한 JSONRequest API를 따르고 있습니다(물론 기술적인 제약 때문에 API를 완전히 구현하지는 못했지만 말이죠).

CrossSafe가 JSONP의 문제를 어느정도 해결할 수 있다는 Kris Zyp의 대답에 대해 Crockford는 마지 못해 긍정하는 투였습니다:

"임시방편의 hack이지만 안 쓰는 것 보다는 좋다고 본다"

좀 더 큰 그림을 생각하고 있는 Crockford의 입장에서는 이러한 "땜빵질"이 그리 달갑지 않은거겠죠.

이런 이야기가 오가던 도중 한 동양인(아마도 일본 사람 같았습니다)이 기초적인 질문을 하나 던지면서 토론의 주제가 전환되게 됩니다:

"JSON이 XML이랑 대체 뭐가 다른가?"

속으로 시시한 질문이라고 생각했는데, 이 질문을 계기로 BoF 세션에 불이 붙었습니다. 여러 JSON 옹호자들(?)이 XML에 비해 JSON이 갖는 장점들을 동시에 쏟아내는 분위기가 짧게 지속되는가 싶더니, 뒷자리에 조용히 앉아 있던 한 젋은 개발자가 갑자기 JSON에 비해 XML이 좋은 점에 대해 "매우 흥분된 어조로" 이야기 하기 시작했습니다. 처음엔 뻔한 이야기로 논쟁하는가 싶었지만 XML Schema 얘기가 나오면서 토론이 생산적인 방향으로 전개되었습니다.

즉, JSON에는 XML의 DTD나 Schema에 해당하는 개념이 없어서 데이터의 정확한 구조를 명시할 수가 없다는 지적이었는데, "JSON은 원래 가볍게 쓰기 위한 포멧"이라는 반론부터 시작해서 "JSON도 JSON Schema이라는 것을 만들면 되는 것 아니냐"는 반론 등 다양한 이야기가 오갔습니다. 그래서 결론은?

네, 만들면 되는거죠. 컨퍼런스가 끝나자 마자 Kris Zyp의 블로그에는 "JSON Schema를 위한 RFC를 같이 쓸 사람"을 구한다는 포스트가 올라왔고, 대략 5일 후에 "스팩 제안서"가 공개되었습니다. 정말 놀라운 실행력입니다. --; 앞으로 어떻게 진행될지 두고 보아야 되겠습니다.

첫째 날 제일 재미있게 들은 세션은 Kris Zyp의 "Advanced JSON" 이었습니다.


JSON은 JavaScript Object Notation의 약자로, XML과 같은 데이터 교환 포맷입니다. 재미있는 점은 JSON이 전혀 새로운 포맷이 아니라 자바스크립트 언어의 작은 부분집합이라는 사실입니다.

예를 들어 다음 자바스크립트 코드들에서 변수와 대입연산자를 제거하면 그대로 적법한(valid) JSON 포맷이 되는데, 어떤 면에서는 YAML과 비슷해 보이기도 합니다.

    // 일반적인 배열
    a = [1, 2, 3]

    // 일반적인 객체
    b = {“first”: “Alan”, “last”: “Kang”}

    // 복합
    c = {“name”: {“first”: “Alan”, “last”: “Kang”}, “age”: 29, “favs”:[“game”, “music”]}

JSON에 대한 자세한 설명은 이곳, RFC 문서는 이곳을 참고하시기 바랍니다.

"Advanced JSON" 세션에서는 JSON 자체에 대한 기본적인 설명 보다는 "XML과의 비교", "다양한 JSON 응용들"을 주로 다루었는데요, 특히 후반부의 JSON 응용들이 흥미로웠습니다.

예를 들면 XSLT의 JSON 버전이라고 볼 수 있는 JSONT는 JSON 객체에 Transformation Rules를 적용하여 결과물을 만들어내는데, 아래와 같이 데이터와 규칙이 주어지면:

    data = ["red", "green", "blue"]
    rule = ["self": "<ul>\n{$}</ul>", "self[*]": "  <li>{$}</li>\n"]

다음 결과물을 얻게 됩니다:

    <ul>
      <li>red</li>
      <li>green</li>
      <li>blue</li>
    </ul>

재미있는 아이디어 입니다. ^^

다음으로, JSONR(Regular JSON)은 클라이언트 측 혹은 서버 측에서 Form Validation을 수행하거나, 데이터로부터 HTML 폼을 자동으로 생성하는 등의 용도로 쓰이는데, 이곳에서 JSONR을 이용한 폼 생성 데모를 보시면 쉽게 이해가 될 것 같습니다.

JSONP(JSON with Padding)는 "Dynamic Script Tags" 혹은 "On Demend Javascript"라고 불리는 기술을 이용하여 다른 웹사이트로 HTTP 요청을 보내고 자바스크립트 콜백 함수를 통해 실행결과를 통보 받는 방식으로 수행되는 JSON 기반 RPC 규약입니다. 이렇게 하면 브라우저의 보안 정책인 “Same Origin Policy” 제약을 넘어서서 원격 서버와의 통신이 가능해지는데, 야후의 일부 API들, 그리고 최근 개선된 Google Calendar API 등이 이미 이러한 방식을 사용하고 있습니다.

문제는 Dynamic Script Tags 방식은 HTTP GET으로만 요청을 보낼 수 있기 때문에 서버로 보낼 문자 수에 제한이 있다는 점입니다. 이 문제는 (조금 지저분하긴 하지만) 큰 데이터를 여러 조각으로 나누어(chunking) HTTP 요청을 여러 번 보내는 방식으로 해결할 수 있습니다. Kris Zyp의 세션과 시간이 겹치는 바람에 직접 듣지는 못했지만 "Improve Existing AJAX Apps with Dynamic Script Tags"라는 제목의 세션에서 Geoff Hendrey라는 사람이 이 방식에 대해 자세히 다루었던 것 같습니다.

JSONP와 관련하여 재미있는 점 한 가지는 JSON을 최초로 제안했으며 현재 야후에서 근무하고 있는 Douglas Crockford가 JSONP를 좋지 않게 본다는 사실인데(그의 말을 직접 인용하자면 "JSONP is a bad thing"이라고 합니다), 이에 대해서는 다음 포스트에 쓰도록 하겠습니다.

마지막으로 소개할 JSON 응용은 JSONT, JSONR, JSONP와 달리 Kris Zyp이 직접 고안한 JSPON(JavaScript Persistent Object Notation, 제이에스-폰이라고 발음하더군요)입니다. 간단히 요약하자면 JSPON은 ID를 통한 객체 래퍼런싱, 지연된 로딩(lazy loading) 등을 지원할 수 있도록 기존 JSON에 몇 가지 컨벤션을 추가한 JSON 객체 직렬화 규약입니다. 그가 직접구현한 JSPON Browser를 이용하면 JSPON 규약을 이용하여 서로 다른 사이트들에 분산되어 있는 JSON 객체들을 트리 형식으로 브라우징 하거나, 수정할 수 있습니다:

Kris Zyp은 JSPON 서버인 Jsponic(역시 직접 개발)을 이용하여 일종의 CMS를 개발하기도 하였는데, JSPON 공식 홈페이지가 이 CMS를 이용하여 관리되고 있습니다. 따라서, 해당 사이트에서 소스보기를 해 보시면 어떠한 본문 텍스트도 나오지 않는 것을 확인할 수 있는데, 접근성이나 SEO 측면에서 볼 때 좋은 방법은 아닌 것 같습니다(noscript 태그에 적절한 링크를 넣어서 구글에 인덱싱되어있기는 합니다만). 단점은 단점이고, 아무튼 훌륭하지 않습니까? ^^; 하지만 불행하게도 구글 그룹스의 맴버가 단 한 명 뿐이라는 안타까운 사실.

계속 두고 보면 뭔가 하나 일을 낼 사람이라는 느낌이 옵니다. 다음 날 Douglas Crockford의 JSON BoF에서도 Kriz Zyp을 만날 수 있었는데, 그 이야기는 다음 포스트에 쓰도록 하겠습니다.