둘째날 오후에는 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일 후에 "스팩 제안서"가 공개되었습니다. 정말 놀라운 실행력입니다. --; 앞으로 어떻게 진행될지 두고 보아야 되겠습니다.

지금은 첫째 날과 둘째 날을 보내고 마지막 날을 남겨둔 새벽입니다. 시차적응에 실패하여 밤이면 밤마다 좀비처럼 거리로 나가서 야식(주로 팬케익)을 먹는데요, 오늘도 어김없이 팬케익과 오믈렛으로 배에 빠다(아니, 버러)를 바르고 왔습니다.


이번엔 기술적인 내용보다는 느낀점이나 요령 등을 적어볼까 합니다.

트랙이 무려 10개이고 하루에 세션이 12개나 있다 보니(게다가 행사 당일에 일정이 변경되거나 다음날 발표 일정이 미정 – TBA – 으로 되어 있는 경우도 있어서) 어떤 트랙의 어떤 세션에 참가해야 할지 정하는 게 쉬운 일이 아니었습니다. 발표 자료를 미리 읽어보면 좋겠지만 이벤트 대행사 측에서 나눠준 CD에는 전체 발표자료의 1/3 정도 밖에 실려있지 않았습니다.

그렇다고 아무 세션이나 들어갈 수는 없는 노릇이어서 나름대로 “옥석”을 가려내기 위해 고민을 꽤 했는데, 하루쯤 시행착오를 겪고 나니 몇 가지 요령이 생겼습니다.

스폰서 세션 피하기

IBM, Oracle, Microsoft, Sun 등의 소위 “빅 플레이어”들을 비롯하여 Laszlo, Backbase, TIBCO 등 수많은 스폰서들이 세션을 차지하고 있는데, 이 중 상당수가 “제품 홍보”에 가깝습니다. 한 발표자와 참가자의 평가도 크게 다르지 않군요.

다행스럽게도(?) 대부분의 참가자들이 이런 세션들을 슬기롭게 피해가는 바람에, 대형 룸에 자리잡은 스폰서 세션들에 파리만 날리는 진풍경이 연출되곤 했습니다:

제목에 낚이지 않기

제목만 가지고는 주제를 거의 짐작할 수 없는 경우가 많습니다. 제목과 요약 설명만 읽고 들어갔다가 “아차 낚였구나” 했던 적이 몇 번 있었죠(ㅜㅠ). 그 이후로는 제목보다도 발표자 이름을 먼저 보는 방법을 택했는데, 결과적으로 훌륭한 방법임이 입증(?)되었습니다. 문제는 Douglas Crockford( http://www.crockford.com/ ) 같은 몇몇 대가들을 제외하고는 이 분야(Ajax) 유명인사의 이름을 제가 잘 모른다는 점인데, 구글 검색은 이럴 때 쓰라고 있는 거죠 ^^; 간단한 뒷조사만으로도 발표자에 대한 충분한 정보를 얻을 수 있었습니다. (Dojo Toolkit을 만든 Alex Russell도 컨퍼런스에 참석했다고 하는데, 만나볼 기회는 없었습니다. 살짝 아쉽네요)

BOF 참여하기

가장 밀도가 높았던 시간은 역시나 BOF 였습니다. 두런두런 모여서 이야기를 나누는 분위기이다 보니 알아듣기도 좀 더 어렵고, 대화에 끼어들기엔 더욱 부담스럽다는 단점이 있지만, 단순히 앉아서 듣고만 있어도 어지간한 트랙에 비해 훨씬 얻는 게 많았습니다.

첫째 날에는 하루가 거의 끝날 무렵에야 간신히 좋은 세션을 들을 수 있었는데(Advanced JSON), 둘째 날엔 운 좋게도 오전부터 한 건 건졌습니다. 자바스크립트 계의 요다라고 불리는 Douglas Crockford의 "Javascript - The Good Parts" 입니다.


이번 세션의 주제를 요약하자면:


정도가 될 것 같습니다.

그가 첫번째로 지적한 자바스크립트의 단점은 for in 루프입니다. for in 루프는 자바스크립트 객체의 모든 속성들을 하나씩 열거하며 반복할 때 쓰이는 구문인데, 문제는 "모든 속성"이라고 했을 때 여기에 prototype 체인을 통해 상속된 속성도 포함되는지 여부 등 여러가지 혼란스러운 점이 있다는 사실입니다. 그는 다음과 같은 컨벤션을 제안하고 있습니다:

    for(var name in obj) if(obj.hasOwnProperty(name)) {
       ...
    }

즉, for-in 구문 안에는 반드시 filtering 조건을 명시하는 단 하나의 if 블럭이 오도록 하는 것이죠. 수월하게 읽히기도 하고 그렇게 너저분하지도 않은 괜찮은 방법 같습니다.

또 한가지 재미있는 지적은(자바스크립트를 어느 정도 써왔던 분들은 다들 이 문제 때문에 고생 좀 했을텐데요) 자바스크립트의 세미콜론 자동 삽입에 관련된 문제입니다. 그는 이 문제를 보여주기 위해 다음 예제를 제시했습니다:

    // 1
    return {
       ok: true
    };

    // 2
    return
    {
       ok: false
    };

1번 예제는 아무 문제 없이 잘 실행되는 코드입니다. 2번 예제도 그럴 것 같지만, 사실은 문제가 있습니다. 보통의 C 계열 언어들은 세미콜론(;)으로 문장의 끝을 구분하지만 자바스크립트는 몇몇 경우에 세미콜론이 없더라도 이를 자동으로 보정 해주는 특징(스팩에 의하면 "to accommodate non-professional programmers, some aspects of the language may be somewhat less strict"라고 합니다)이 있기 때문에 2번 예제는 1번 예제와 다른 방식으로 해석됩니다. 우선 return 문과 "{" 사이에 세미콜론이 자동으로 삽입되어 다음과 같이 변형되는 과정을 거치게 됩니다:

    return;
    {
       ok: false
    };

함수는 "return;" 부분에서 끝나고 그 뒤에 나오는 문장은 무시되는 것이죠. 하지만 에러는 나지 않습니다. 첫 번째 이유는 도달할 수 없는 문장(unreachable statment)은 자바스크립트에서 아무런 에러도 발생시키지 않기 때문이고, 두 번째 이유는 { ... } 부분이 그 자체로 "올바른" 자바스크립트 구문이기 때문입니다:

    {
        ok: false
    };

에서 "{"과 "}"은 블럭(block)으로 취급됩니다. 자바스크립트에서는 블럭이 자동변수를 위한 범위(scope)을 새로 만들지 않기 때문에 아무 의미가 없습니다. 블럭 뒤에 오는 세미콜론(")은 빈 문장(empty statment)으로 해석됩니다.  가운데 "ok: false"에서 "ok:" 부분은 레이블(label)로 해석되고( --; ), false 는 expression이자 statement이기도 하기 때문에 문제 없이 넘어갑니다. 물론 "false" 뒤에는 자동으로 세미콜론이 삽입되겠죠. 최종적으로, 다음과 같은 모양이 됩니다:

    return;

    // unreachable
   { // block-start
       ok: // label
            false; // expression statement
   } // block-end
    ; // empty statement

직접 당해보면 황당하고 억울하지만, 이렇게 분석해보면 재미있습니다. 요지는, 다른 C 계열 언어에서는 "개발자의 주관적인 스타일"로 볼 수 있는 것들이 자바스크립트에서는 그렇지 않은 경우가 있으므로 이를 일관된 방식으로 통일해서 표현하자는 것이죠. 비슷한 예로 파이선(python)에서는 들여쓰기(indentation)가 "주관적인 스타일" 문제 이상이죠.

그 밖에도, C 계열 언어로부터 받은 안 좋은 유산들(그는 자바스크립트를 "C의 옷을 입은 LISP"이라고 표현합니다)을 지적하고 있는데 간단히 언급하자면:

• 표현식(expression)이면서 동시에 문장(statement)이기도 한 문법( foo; ),
• 정확하지 않은 부동소수점 연산(0.1 + 0.2 != 0.3),
• 단항 증감연산자(++, --),
• break 문 없이 쓰면 fallback이 되는 switch 문

등입니다.

그렇다면 자바스크립트의 좋은 점에 대해서는 뭐라고 했을까요? 크게, Lambda, Dynamic Objects, Loose Typing을 이야기 했습니다. 이 중 Loose Typing은 생략하고, Lambda와 Dynamic Objects에 대해 이야기해보려고 합니다.

Lambda는 Alonzo Church(네, Church-Turing thesis의 바로 그 Church 입니다)의 "Lambda Calculus"에서 따온 말로 LISP과 같은 함수형 프로그래밍 언어의 핵심이라고 할 수 있는 강력한 개념입니다. 자바스크립트에서는 함수 자체가 일반 상수처럼 변수에 대입될 수도 있고, 다른 함수의 인자로 전달되거나, 함수의 결과로써 반환될 수도 있을 뿐 아니라(이를두고 "함수가 first class object이다"라고 표현합니다), 익명 함수(이름 없는 함수)를 만들 수도 있는데, 바로 이러한 특성이 자바스크립트의 가장 훌륭한 장점 중 하나라고 말하고 있습니다.

저도 이점에 대해 적극 동의합니다. 하지만 문제라면 익명 함수를 만드는 문법이 너무 너저분(verbose)하다는 점인데, 예를 들어 Groovy 같은 언어에서 다음과 같이 표현될 수 있는 문장이:

    [1,2,3].collect({it * it})

자바스크립트에서는 다음과 같이 표현되어야 합니다:

    [1,2,3].collect(function(it) {return it * it})

함수가 first-class object가 아닌 자바 같은 언어에서는 이와 동일한 것을 구현하기 위해 인터페이스 및 해당 인터페이스를 구현하는 익명 클래스를 만들어주어야 하기 때문에 더욱 너저분해지죠.

용기를 내서 이 문제에 대해 어떻게 생각하느냐는 질문을 했었는데, Douglas Crockford는 별로 중요하게 생각하지 않는 모양입니다. 답변은 간단했는데 "익명 함수를 만드는 문법이 일반적인 함수 선언 문법과 유사하여 개념적 혼동을 일으킬 소지가 있긴 한데, 그것만 잘 구분할줄 안다면 표현이 조금 길다는 것은 문제라고 생각하지 않는다" 라고 했습니다.

하지만 자바스크립트의 lambda 표현이 너무 너저분하다고 느끼는 사람은 저 뿐은 아니어서, 한 개발자는 String Lambda(이름을 보면 감이 오시죠?)라는 개념을 고안하여 이를 이용한 일종의 라이브러리(Functional Javascript)를 공개하기도 했습니다(간단하지만 훌륭한 아이디어라고 생각합니다. 이 라이브러리는 단순히 익명 함수 선언의 길이를 줄여주는 것 이상의 많은 일들을 해줍니다. 조만간 꼭 활용해볼 생각입니다).

두번째로, Dynamic Objects는 이미 만들어진 객체에 동적으로 속성을 추가하거나 제거할 수 있는 특정을 말합니다. 정적인 언어를 주로 쓰는 사람들은 자바스크립트의 이 같은 특성을 "허술한 것으로" 여기는 경우가 많은데, Douglas Crockford는 "동적인 객체" 개념이 자바스크립트의 훌륭한 점 중 하나라고 얘기합니다.

혹자는 "class" 키워드가 없기 때문에 자바스크립트는 객체지향언어가 아니라고 말하기도 하지만 이는 큰 오해입니다. 객체지향언어를 객체지향언어로 만드는 것은 키워드가 아니라 특정한 스타일 - 다형성(polymorphism) 등을 기반으로 한 의존성의 역전(dependency inversion) - 이니까요. 자바스크립트에서는 프로토타입 체인(prototype chaining)과 동적 객체 개념을 통해 이를 지원하고 있습니다. 이를 클래스 기반 객체지향 프로그래밍(class based OOP)에 대비되는 말인 프로토타입 기반 객체지향 프로그래밍(prototype based OOP)이라고 표현합니다.

그는 단순히 장/단점을 나열하는 것에서 그치지 않고, 자바스크립트를 향상시키기 위한 현실적은 방안들을 제시합니다(그가 요다라고 불리는 것은 아마 이런 면 때문이 아닐까 싶습니다. 현실적이고 현명한 조언을 해주니까요).

예를 들면, 그가 직접 개발한 JSLint라는 소스코드 분석기가 있는데, 이 프로그램은 자바스크립트 코드의 안 좋은 부분들(위에서 설명한 것과 같은)을 검사하여 좋은 스타일에 대한 가이드를 제공해줍니다. 자바스크립트의 좋지 못한 일부 문법을 제약하는 것이죠(제약이란 어떤 의미에서는 좋은 것입니다 ^^ ). JSLint가 제안하는 가이드는 이 문서들(Part 1, Part 2)과 밀접한 관련이 있습니다.

또는 문법을 변화시키지 않는 소소한 수정을 통한 개선에 대해서도 이야기하고 있습니다. 여기서 중요한 것은 "문법을 변화시키지 않는" 부분인데요, 그가 얘기하는 자바스크립트의 아주아주 훌륭한 점은 바로, 1999년 이후로 새로운 변화 없이(99년은 ECMAScript 3rd edition이 발표된 연도입니다) 현재까지 무려 8년 동안 유지될 수 있었다는 점입니다:

이 덕에 Ajax라는 기술도 가능해진 것이라고 말하고 있는데, 적극 공감합니다. 각종 표준안이 실제로 널리 퍼지는데에 걸리는 시간이 극히 오래 걸린다는 사실을 감안하면 웹 개발자들은 자바스크립트가 지난 8년 간 바뀌지 않고 유지됐다는 점에 감사해야 합니다. 그가 제안하는 문법을 변화시키지 않는 개선에는 다음과 같은 것들이 있습니다:

• Object, String, Array 등에 toJSONString과 parseJSON 추가하기
• object.dontEnum(name) 추가하기(for-in을 개선하기 위해)
• 안전한 eval 메서드

앞의 두 가지는 딱 들으면 알겠는데, 안전한 eval 메서드에 대해서는 잘 감도 안오고, 특별히 길게 설명을 해주지도 않아서 인터넷을 좀 뒤져봤습니다.

    result = "a + b * c".eval({a: 1, b: 2, c: 3}); // result is 7

eval의 문제는 동적으로 평가되는 코드가 전체 프로그램의 모든 부분에 대해 접근할 수 있다는 점인데, 위와 같이 제공된 컨텍스트( {a: 1, b: 2, c: 3} 부분)로만 접근을 제한할 수 있게 하자는 아이디어였습니다.

이 밖에도 더 많은 이야기들이 있었지만, 이 정도에서 마무리하도록 하겠습니다. Douglas Crockford는 다음날 JSON BoF에서도 만날 수 있었는데요, 여기에서도 재미있는 얘기들을 많이 들을 수 있었습니다.

첫째 날 제일 재미있게 들은 세션은 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을 만날 수 있었는데, 그 이야기는 다음 포스트에 쓰도록 하겠습니다.

Ajax World Expo

AJAXWorld Conference & Expo 2007 West

AJAXWorld 컨퍼런스를 가다

한국에서는 추석이 한창인 가운데 스프링노트 팀의 두 사람(강규영, 신기배)은 추석 연휴도 마다 않고 AJAX 컨퍼런스를 위해 캘리포니아 산타클라라로 날아왔습니다. 가서 밥이나 먹고 다닐 수 있을까, 호텔까지 찾아갈 수나 있을까.. 하는 많은 사람들의 우려 속에서 24일부터 26일(미국 서부 시간 기준, 23일 boot camp제외)까지 3일간의 소식을 전해드리도록 하겠습니다 =)
이 행사의 홈페이지입니다.
http://www.ajaxworld.com/

엔터프라이즈 매시업 #1

오전 7시 30분 - Oracle의 첫 키노트

일찍도 시작하네요 ^^; 아침 7시부터 등록이 시작되었습니다. 태어나서 외국인들이 이렇게 많이 모여있는걸 본 건 처음입니다. 웹에 있어서 기술적인 메인 스트림 중 하나인 AJAX의 인기를 실감할 수 있었습니다. 다양한 나라, 다양한 회사에서 이 행사를 위해 참석하였습니다.

이번 컨퍼런스는 10개의 트랙, 총 140여개의 발표와 BOF로 구성되어 있습니다. 따라서 AJAX 응용 기술, 개발 환경, 프레임웍, 테스트 환경, 표준화, 보안, 매시업, RIA 등 다양한 주제들이 많았는데 컨퍼런스 서두의 두 세션은 웹으로 옮겨 오고 있는 엔터프라이즈 솔루션에 대한 이야기 입니다 =)

오라클은 엔터프라이즈 솔루션들이 가져야 할 여러가지 특성을 강조했습니다.

1. 협업
2. 정보의 공유
3. 권한에 대한 제한
4. Data is king! - Users don’t own it
5. 비즈니스가 컨텐츠를 생산하고 사용자가 그것을 확대하라~

4번 항목은 일반적인 인터넷 서비스라면 좀 아리송? 하지만 기업내에서 사용되는 솔루션이라면 그럭저럭(?) 이해가 됩니다 ^^; 어쨌든~ 그리고 가져야 할 여러가지 기능의 가이드 라인을 제시했습니다.

1. 통합 검색
2. 개인 공간, 그룹 공간
3. 커뮤니케이션과 문서 관리(위키, 블로그, RSS)
4. 메일/이벤트/캘린더

오라클은 콤포넌트 화 된 이런 기능들을 GUI 개발도구에서 드래그&드롭만으로 엔터프라이즈 RIA 솔루션을 만드는 것을 시연했습니다. 각 콤포넌트들을 엮어서(매시업) 웹기반의 어플리케이션을 만들어 냅니다.

엔터프라이즈 매시업 #2

Let My People Mash!

JackBe는 재치있는 두번째 세션으로 그 뒤를 이었습니다.
“Let My People Mash!” 라는 슬로건으로 세션을 시작하고 중간에 영화 식스 센스의 “I see dead people” 대사를 “I see mashups...”으로 패러디 한 이 회사는 누구나 쉽게 매시업을 할 수 있게 하는 서비스를 선보였습니다.

언듯 보면 야후의 pipes와 유사한 인터페이스와 기능을 가지고 있습니다. 하지만 내용은 많이 다릅니다 =)

JackBe의 “Presto Wires”는 OpenAPI 뿐 아니라 웹서비스를 위해 필요한 기본적인 기능들(Login, Search 등)까지 모듈로 만들어서 다른 모듈들과 이어 붙일 수 있게 합니다. 이른바 Internal Mashup이랄까요?

위의 사진은 Wires를 시연하는 장면인데 이미 꽤 많은 모듈들이 준비되어 있고 안정적으로 돌아가는 것을 보여주었습니다. 복수의 RSS를 엮고 자동화 된 또는 검색어를 기반으로 한 필터를 통해 원하는 데이터를 만들어 내는 내용이었습니다. 그동안 매시업이라면 대부분 적잖은 기반 지식을 가지고 있어야 가능했습니다. JackBe가 "Let My People Mash!"라는 슬로건에 걸맞는 솔루션을 완성시켜서 줬으면 하는 바램입니다 =)

아! 위의 화면은 웹브라우저(FireFox)에서 돌아가는 화면입니다 =) 보면서 아.. 누군가 또 코피 쏟으며 엄청난 노가다를 했구나 싶었습니다 -.-

JackBe의 홈페이지 주소는 http://www.jackbe.com/ 입니다. 위의 Wires라는 솔루션은 아직 공개되지 않은 개발 버전인듯 합니다.

RIA와 AJAX, Enterprise

RIA(Rich Internet Application)를 구현하는 방법에는 여러가지가 있습니다. Flash, Silverlight기반의 기술도 있지만 JavaScript 기반의 RIA와 AJAX는 뗄래야 뗄 수 없는 관계입니다.

이번 컨퍼런스의 세션들에서는 특히나 for Enterprise라는 수식어가 많았습니다. 기존의 서버/클라이언트 기반의 엔터프라이즈 어플리케이션들이 웹이라는 새로운 환경으로 옮겨오고 있고 거기에 대한 많은 솔루션들이 쏟아져 나오고 있습니다 =)

AJAX로 구현되는 솔루션들은 개발하기도 힘들고 테스트 하기도 어렵습니다. 그동안의 JavaScript/AJAX관련 기술들의 행보가 Cross-Browser 지원에서 서버 기술과의 통합으로 바뀌었다면 이제는 개발 도구와 테스팅 환경과의 통합으로 발전해 나가고 있는 듯 합니다.
오라클과 JackBe가 시연한 내용이 완전히 새로운 것은 아니지만 이런 개발 도구가 계속 나와주고 발전하는 것은 환영할 만한 일입니다 =)

속이 니글니글~한 점심을 주지만 어쨌든 먹었으니 밥심으로 계속 해보겠습니다~ ^^; 즐거운 한가위 되세요~