Blog

안녕하세요? 저는 오픈마루 서비스 개발팀의 jangxyz라고 합니다. 이 글은 jangxyz의 이야기입니다.

오픈마루에 들어와 부지런히 여러 컨퍼런스에 참석하는 동료 개발자들을 부러운 눈으로 바라보다, 드디어 저도 컨퍼런스란 곳에 가보게 되었습니다.(두근 두근) 시작하기 30분 전 도착해보니 분주히 돌아다니거나 멀거니 서 있는 자원봉사자 분들을 발견할 수 있었습니다. 오늘 하루 동안 열심히 안내하고 도와주신 분들이지요.

사용자 삽입 이미지

[이번에도 어김없이 자원봉사자로 활동하고 있는 humbroll님]

그 외에도 일찍 온 부스들에서는 벌써부터 간단한 이벤트를 진행하고 있었습니다. 에이콘 출판사에서도 재밌는 책들을 많이 진열해놓고 세일을 하고 있었네요. 야후 거기! 부스에서 지도 이벤트에 참가하고, 파란에 가서 구경하다가 오전 세션에 들어갔습니다.

오전에는 프론트엔드와 백엔드 두 파트로 나눠서 세션이 진행됐는데, 프론트엔드에는 주로 클라이언트 레벨에서 다루는 최적화, 표준화 등의 세션이 있었고, 백엔드에는 서버 레벨에서 다루는 서버 사이드 프로그래밍, 데이터 관리, 검색 등의 이슈를 다루고 있었습니다. 양쪽 다 관심이 있었지만 쉽게 들을 기회가 별로 없는 백엔드 파트에 들어갔습니다.



[아침 일찍부터 와서 준비하고 있는 에이콘 출판사와 야후]

첫 세션에서는 IDtail의 최호진 님이 CakePHP 프레임웍을 이용하여 PHP로 MVC 패러다임을 이용한 프로그래밍 하는 것에 대한 이야기를 했습니다. IDtail에서는 CakePHP를 이용하는구나. IDtail은 오픈마루와도 비슷한 서비스를 하고 있었는데 알고보니 개발 방식도 비슷했군요. CakePHP가 Rails와 꼭 닮은 꼴이라 프레임웍 자체보다 PHP의 문법이 더 낯설게 느껴졌습니다.

오픈마루의 루비스트들도 여러가지 다른 프레임웍에 관심이 많이 있습니다. 라우팅이나 마이그레이션은 Rails와 어떻게 다른지 궁금했으나, 너무 테크니컬한 얘기로 빠질까봐 차마 질문은 못하겠더라구요.

이어서 NexR의 한재선 대표의 Cloud Computing에 대한 세션이 열렸습니다. 수도나 전기처럼 점차 data도 공공재가 될 것이라는 전망은 흥미롭더라구요. 각 회사마다 별도로 data center를 두어 그곳에서 자신들의 데이터를 직접 관리하는 것이 아니라, 전기를 쓰듯, 물을 쓰듯 다른 곳에서 스토리지를 필요한 만큼 가져다 쓰고, 사용한 만큼 돈을 낸다면 얼마나 편리할까. 역으로, 자기가 필요로 하는 물과 전기를 직접 만들어서 사용한다면 얼마나 불편할까.

그러면서 이와 비슷한 분산 컴퓨팅, 유틸리티 컴퓨팅, 오토노믹 컴퓨팅 등과의 차이에 대해서도 간단히 설명해준 뒤(클라우드 컴퓨팅은 현재의 분산 컴퓨팅 기술에 바탕을 하고 있고, 유틸리티 컴퓨팅처럼 공공재로 사용하면서 쓴 만큼 돈을 지불하는 시스템으로 자동 관리가 이루어지는 결합된 모델이라고 하네요),

이런 서비스들의 일환인 Amazon Web ServiceGoogle App Engine에 대해 소개해주었습니다. AWS를 이용해서 실제로 남의 컴퓨터로 몇분 만에 웹 서버를 구동시키는 것을 보여주는 데모는 정말 흥미로웠습니다. 유료서비스인데 가격도 싸고 사용하기 편리하도록 웹으로 관리할 수 있도록 돼 있는 시스템은 무척 편리해보이더라구요.

실제로 벤처 기업 하나는 오픈하고 며칠 사이에 수만명의 신규 사용자가 갑작스레 들이닥쳤는데 (좋겠다!), 여느 벤처 기업과는 달리 서버 증설을 고민할 필요 없이 AWS 서버 사용량을 늘리는 것으로 해결했다고 합니다. New York Times는 TIFF 파일 형식으로 제공하던 문서 형식을 PDF 형식으로 바꾸는 작업을 수행하는데 단 사흘만에 뚝딱 해치웠다고 하네요. 이 정도면 군침 흘릴만 해 보이지 않아요?

하지만 (아직까지는) 무턱대고 맡길 수 있을 정도로 안정/안전해 보이지는 않다는 것이 문제네요. 첫째, 스토리지를 마음껏 사용하지만, 물과 전기와는 달리 내 데이터가 그곳에 저장이 됩니다. 사생활 침해나 기업 비밀 보장과 같이 중대한 정보를 남의 손에 무턱대고 맡기기는 힘들겠죠. Gmail만 하더라도 구글님께서 열심히 내 메일을 읽은 뒤 '적합한' 광고를 띄워주지 않나요. 둘째, 시스템의 안정성에 대한 문제도 있습니다. 이는 전기로 따지자면 발전소가 나가서 정전이 되는 사태와 비슷하다고 할 수 있겠죠. 내가 직접 관리하는 data center와는 달리, amazon 서버가 나가면 여기에 데이터를 맡기고 있는 사용자로서는 손 놓고 기다릴 수 밖에 없습니다. 태평양을 직접 건너갈 것도 아니고 말이죠 (또 막상 건너간다고 해서, 뭘 할 수 있겠습니까). 실제로 이 시장이 뜨면서 수많은 호스팅 업체들이 이런 형태의 서비스로 전환하고 있는데, 개중에는 잘 운영되다 망한 곳도 있다고 하네요. 내 데이터 어쩔 겁니까. 아마존, 구글 같은 업체들도 올해 몇차례씩 다운되서 전 사용자들이 사용할 수 없었던 적이 있다고 하니, 아직은 무작정 신뢰하긴 힘들 것 같아요.

어쨌거나, 그러면 어떻습니까. 회사가 사용 못 할 정도라도, 개인이 부담 없이 써볼 수 있는 정말 매력적으로 보이는 서비스가 아닌가요 *_* 더 이상 집에서 전기세 걱정하며 서버 돌리지 않아도 됩니다. 더 이상 컴퓨터 윙윙대는 소리 견디며 잠들지 않아도 됩니다. 하드 나갈 걱정, 리눅스 설정하느라 뺏길 시간 걱정, 메모리 늘릴 걱정에서 벗어날 수 있네요.

세번째 세션은 오픈마루의 윤종완 팀장님 차례였습니다. 종완님은 최근에 번역하신 '집단지성 프로그래밍'에 대한 톡을 하셨는데, 다수의 의견을 취합하고 집계해서 보다 더 나은, 혹은 나의 취향과 좀 더 유사한 결과를 제시해주는 데에 쓰인다고 합니다. 구글의 페이지랭크는 이미 고전이 되어버린 집단지성의 예라고 하네요.

마지막 세션에서는 DERI 연구소의 김학래 님이 시맨틱웹과 링크드데이터에 관해 이야기해 주셨습니다. 현재의 웹 2.0 경향은 사용자의 적극적인 참여가 곧 컨텐츠가 되고 이를 이용한 소통에 중점을 두는 데 비해, 시맨틱웹은 컨텐츠가 아닌 인프라에 초점을 맞추는 미래의 웹이라고 하네요. 두 페이지(정보)를 이어주는 링크에서 시작해 점점 더 구조를 갖추면서 형성되는 정보를 가공하고 사용할 수 있도록 하기 위해서는 컴퓨터가 웹을 이해하는 것이 필수적입니다.

그리고 처음에 시맨틱웹이 부상했던 때와는 달리, 지금은 웹 2.0이 새로운 아군을 많이 준비해준 것 같네요. 대표적인 예가 사용자가 직접 만든 대형 정보화 구조인 위키피디아겠죠. 위키피디아에서 정보를 뽑아내 재가공할 수 있도록 만든 DBpedia란 것이 있다는 얘긴 참 신선했습니다. 또 요새 웹의 최대 화두인 소셜 네트워킹을 바라볼 때도 관계에 태깅을 하는 것에 초점을 맞추어서 바라보더라구요.

사용자 삽입 이미지

[오전 세션에 발표한 여러가지 주제들]

이렇게 해서 오전 세션이 끝났습니다. 기대했던대로, 평소에 쉽게 들을 수 없었던 분야에 대해 전문가들의 정성스런 말빨에 녹아들 수 있는 시간이었습니다 :) 생소한 분야도 많았지만 다 듣고 나니, 왠지 당장이라도 AWS에 서버 물리고 집단지성을 이용하며 시맨틱웹을 구현해야 할 것 같은 느낌이 들더군요 (그래도 구현은 Ruby on Rails로 해야지 ㅋㅋ) 하지만 참가하지 못한 프론트엔드 쪽 얘기도 아쉬웠습니다.

점심 식사 후에는 현재 사용 중이거나 새로이 시도되고 있는 서비스들 위주의 톡이 이어졌습니다. 국내의 웹문화를 선도하는 대기업들이 바라보는 관점이나 당면하고 있는 과제에 대한 이야기도 있었고, 새로운 환경에 도전장을 내민 패기 넘치는 벤처 회사의 생생한 이야기도 들을 수 있었습니다. 위젯에 대한 표준화의 물결을 준비하고 있는 오페라다음, 위자드웍스의 패널토의 시간도 있었습니다. 생각해보면 웹은 다른 인터넷에 비해 열려 있음에도 불구하고, 자신들만의 방식이 난무해 더 큰 잠재성을 가지고 있음에도 불구하고 기대한 만큼의 힘을 내지 못하고 있는 것 같아요.

결국 어느 시점에서 표준이 만들어지고 또 그 위에서 다시 새로운 실험을 통해 계속 새로운 세상으로 나아가고 있긴 하지만, 정작 표준을 만드는 과정에는 참 고달픈 일이 많을 것 같습니다. 하지만 한편으론 한번 쓰면 어디서나 돌릴 수 있다는 위젯을 쓸 일이 그렇게 많을까 궁금합니다. 맥의 대시보드, 야후의 컨패뷰레이터(이제는 그냥 위젯이네요), 구글의 데스크탑 위젯을 떠올려보며, 앞으로 더 많은 용도가 생겨나고 뚝딱! 더 쉽게 만들 수 있는 기회가 많이 열렸으면 좋겠다는 생각을 해봅니다.

사용자 삽입 이미지

[오후 세션에 참가한 다양한 회사들]

그리고 드디어, 모든 사람이 기다려온 그 분, 날 이 컨퍼런스에 참가하게 한, 베스트셀러 조 작가, 넘치는 재치와 입담으로 순식간에 전세계에서 방문하는 유명 블로그를 갖게 된 조엘 스폴스키(Joel Spolsky)의 강연이 시작되었습니다. 정말 정성스레 만든 발표 자료로 생동감 넘치는 메세지를 전달해주는 그의 자신 있고, 명확하고 재치있는 모습은 아침부터 이어진 발표에 지쳐 있는 저에게 다시 활력을 불어 넣어주더라구요. 조엘이 제시한 1등 제품을 만드는 방법을 추려보면 다음과 같습니다.

1. 사용자를 행복하게 해줘라
자기가 직접 컴퓨터를 컨트롤 할 수 없다고 느끼는 사람은 불행해지게 됩니다. 심지어 컴퓨터가 자기를 싫어한다고 느끼기도 한다네요. 사용자가 직접 현재 상황을 제어할 수 있도록 해주는 것이 중요합니다. 사람은 자기 힘으로 상황을 제어할 수 없으면 불행해진다고 느끼기 경향이 있기 때문에, 사용자가 충분히 상황을 제어할 수 있도록 인터페이스 등을 설계하는 것이 중요하다고 하네요.

2. 아름다운 걸 만들어라
배터리 교환이 안되는 아이폰도, 발열이 심한 맥북 에어도(조엘이 보기에는) 그 기능상의 가치보다 훨씬 큰 가치로 평가 받고 있다고 합니다. 왜냐? “It's just awesome(그냥 짱이니까).” 비록 (모두가 다 알고 있듯이) 프로그래머에게 미적 감각을 요구하는 것은 어려운 일이지만, 그렇다고 스킨 기능을 제공하면서 문제를 해결했다고 생각하는건 말도 안된다고 하네요. (어차피 아무도 안 쓸 테니까요)
사용자 삽입 이미지

[조엘이 맥빠는 아닙니다. 그의 팟캐스트를 들어보면 혹평도 많이 하더라구요]

3. 컬쳐 코드
사고 발생율이 높은 SUV를 오히려 '안전하다'고 느끼는 이유는 뭘까? 거기에는 실제로 사람들이 안전하다고 느끼는 방식에 대한 고민이 있었기 때문입니다. 더 크고, 더 높고, 더 둥글둥글하고 포근하고 따스함을 전달해줄 수 있다면, 사실과 상관없이 그런 느낌을 받을 수 있다네요. 사람들이 받는 느낌이 결국 실제의 객관적인 차이보다 더 중요하다고 합니다.

놀랍게도 이런 문화적인 코드가 프로그래밍에도 적용된 예가 있는데, 바로 루비란 언어입니다. 루비는 다른 언어와 달리 자신을 표현할 때 아름다운, 행복한, 사랑스러운, 즐거운, 자부심 있는, 열정적인과 같은 수사어를 많이 사용 합니다. 아니 그럼, 루비와 비슷한 언어인 파이썬은, 못생기고 슬프기 짝이 없는 부끄럽고 불행한 언어란 말인가요? 실제 논리의 조합일 뿐인 언어에 저런 의미를 부여함으로써, 고의든 아니든 사용자가 저런 것을 느낀다고 믿게 한 것이 루비의 성공 요인이라고 조엘은 말하네요. (실제로 이렇게 말하고 다니는 분도 있는데요 ^^ 어쩜 이렇게 딱 맞아떨어지고, 한편으론 우습고 다른 한편으론 아름답고 공감가는 광경이었는지!)

사용자 삽입 이미지

[읽을 책 목록에 하나 또 추가 되었네요]

사용자 삽입 이미지

[보기에는 안전해 보이는 SUV?]

사용자 삽입 이미지
[다이아몬드가 여자의 가장 소중한 친구라면, 프로그래머에겐 루비가 있다는군요]

결국, 조엘은 가장 중요한 것은 사용자의 '인식의 오류'를 잘 이용하는 것이라고 강조했습니다. 실제 어떠한가보다 실제 어떠했다고 느꼈는지가 중요하다는 거죠. 피드백을 바로바로 보여주는 인터페이스, 세련된 아름다움, 문화적인 코드 모두가 하는 일은 사용자가 멋진 프로그램을 사용하고 있다고 느끼게 해주는 것입니다. 마치 높은 곳에서 프로포즈해서 가슴이 뛰는 걸 착각하게 하는 구혼자처럼. 마치 화려한 파워포인트와 멋진 말빨로 청중을 휘어잡는 조엘처럼. 그러면 상대방은 멋진 경험을 했다고 반할 수 밖에 없습니다. 마치 그 때의 톡이 그랬던 것처럼 말이죠.

조엘 다음에는 야후의 정진호님이 해커 문화에 대해 소개를 해주셨습니다. 재미있는 것을 찾고, 열정적이며, 자신의 한계를 극복하고 아이디어를 프로토타입으로 승화시키며 자신의 지식을 공유하는 사람을 무엇이라고 할까? 프로그래머들 사이에서 당연하게 인식되고 있는 '해커'라는 대상을 놀랍게도 '이노베이터'라는 멋진 이름을 불러주시다니, 감격했습니다. Flickr 직원들이 자전거에 GPS와 카메라폰을 달고 태양열 전지판을 붙여 'Flickr Bike' 라 부르면서 사진을 찍고 돌아다닌 이야기며(아 재밌겠다, 나도 해보고 싶다), 야후에서 실행하고 있는 Hack Day에 대한 소개도 인상 깊었습니다.

프로그래머들이 스스로의 에너지를 발산할 장을 마련해주어 자기가 만들고 싶은 것을 만들고, 그것을 모든 사람에게 보여줌으로써 스스로의 존재감을 확인시켜주는 것, 그래서 결국 행복한 직장을 만드는 것. 프로그래머라면 누구나 꿈꾸는 소소한 바람이 아닐까요? 그런 환경을 조성해주기 위해 노력하는 회사는 정말 누구나 바라는 곳이겠죠. 우리 회사의 좋은 분위기도 만족스럽지만 저런 모습도 정말 부럽고 탐이 나더라구요. (우리도 저런거 하자! 하자 하자!)

사용자 삽입 이미지

[누구나 생각해봤을 법한, 그러나 아무나 시도해보지 못한 자전거]
사용자 삽입 이미지
[로고도 재밌네요 ^^]

이렇게 해서 오후 세션이 끝났습니다.컨퍼런스룸 밖에서는 어느덧 조엘의 사인회가 열리고 있었고(조엘 온 소프트웨어2가 나왔다는데, 몇권 가져왔으면 원서인거 모른체 하고 사주려 했는데 없어서 싸인도 못 받았네요), 곳곳에서 각 스폰서 회사의 부스 소개와 공개세션도 열리고 있었습니다.

컨퍼런스의 톡은 일방적인 세미나 형식이었던 반면, 밖에서는 부담없이 스피커와 관중들이 서로 묻고 답하느라 왁자지껄했습니다. 스피커끼리 즉석에서 토론을 하는 모습도 좋아 보였습니다.


[총알도 없이 사인회 하고 있는 조씨 아저씨와 그의 신간]


사용자 삽입 이미지

[int.ere.st라는 소셜네트워크서비스와 시멘틱웹 결합 프로젝트에 대해 설명하고 있는 humble programmer 님]


사용자 삽입 이미지

[앗 외국인이다! 수줍은 한국말을 구사하던 오페라 외국 개발자]

그러는 한편 안에서는 런치패드라는 이름으로 신규 서비스들의 소개 및 심사가 이루어지고 있었습니다. '신기하다', '재밌다', '와 저런거 나도 생각해봤는데 정말 나오다니', '어 저게 저 서비스 꺼였어?' 등의 이야기가 오가는 흥미진진한 자리가 진행되고 있었습니다. 1등을 한 썬데이토즈 팀 다시 한번 축하드려요~ (나도 가끔 토요일날 노트북 들고 토즈 가는데!)

마지막에는 5분이라는 짧은 시간 동안 새로운 주제에 대해 소개를 하는 라이트닝 토크가 있었습니다. 앞의 세션에서는 20~40분 사이에 자신들이 한 일이나 관점에 대해 자세히 설명을 하는 반면, 라이트닝 토크에서는 짧은 시간 안에 주제의 요점만을 정리해 청중들에게 전달해주게는 형식입니다. 김기창 교수님의 오픈웹 운동, 오픈 아이디의 현 상황과 사라질지 모르는 미래의 운명, 1년 동안 매쉬업이 걸어온 길과 가야할 길, 새로운 준비를 맞이하고 있는 자랑스러운 한국 소프트웨어 텍스트큐브와 제로보드, 구글 인프라를 재구현하는 오픈소스 프로젝트 Hadoop에 대한 소개, 아름다운 개발자들로 이루어진 섬세하고 유연한, 감수성 있는 여성 개발자 모임터, 국내의 여러 웹표준 커뮤니티 소개 등등의 다양한 내용을 짧은 시간 안에 다 듣는 것도 새롭고 즐거운 경험이었습니다.

사용자 삽입 이미지

[라이트닝 토크에서 들었던 주제들 중 몇가지]

웹앱스콘이란 이름에 나타나듯이 웹을 이용한 꺼리에 대해 이야기하는 장이라, 정말 웹에 대한 많은 이야기가 나왔던 것 같습니다. 현재의 웹 개발 기술, 이를 좀 더 발전시키려는 기술, 미래의 웹의 모양과 이를 위해 지금 당장 시도할 수 있는 일, 새로운 도전, 좀 더 크게 준비하고, 좀더 개방하고, 표준을 만들어내고, 그러면서 사용자를 고려하는 방법, 개발자를 고려하는 방법 등등... 여기에 이미 큰 포션을 차지하고 있는 대기업이, 새로 진입하는 기업이, 젊음과 패기로 도전장을 내미는 벤처가 모두 달려들고 있더군요. 정말 수많은 서비스, 수많은 개발자들을 보면서 나도 당장 뭔가 하고 싶어 근질근질거렸습니다.

처음 갈 때는 뭘 기대해야 하는지도 모른체 딸랑 몸만 챙겨 갔는데, 그곳에서 마치 하루종일 잘 정리된 식사를 먹은 것 같은 기분이 들더군요. 개중에는 소화하기 어렵거나 맛이 잘 안 맞는 것도 있었지만, 전체적으로 이렇게 정성스레 준비된 메뉴를 넙죽넙죽 받아먹어도 되는건지 미안한 마음이 들 정도였습니다. 결국 꾸역꾸역 먹다 과식해버렸지만, 곧 찬찬히 소화가 되겠죠? ;)
사용자 삽입 이미지

다음날 출근길에 이걸 보고 오픈아이디가 생각나버렸습니다 :)


둘째날 오후에는 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 였습니다. 두런두런 모여서 이야기를 나누는 분위기이다 보니 알아듣기도 좀 더 어렵고, 대화에 끼어들기엔 더욱 부담스럽다는 단점이 있지만, 단순히 앉아서 듣고만 있어도 어지간한 트랙에 비해 훨씬 얻는 게 많았습니다.

사용자 삽입 이미지
(위에 있는 Jason BOF는 오타이고 아래쪽에 있는 JSON BOF는 Comet BOF를 잘못 적은 것. 자세히 안봤으면 JSON BOF를 놓칠 뻔 했습니다. 국내건 해외건 이벤트 대행사를 잘 골라야...)

남는 시간엔 복습

이런저런 기준으로 필터링을 하고 나면 중간 중간에 몇 시간씩 구멍이 생기는데, 이 시간엔 주로 복습(혹은 뒷조사 ㅎㅎ)을 합니다.

사용자 삽입 이미지
(첫 번째 트랙은 대부분 스폰서 세션. 여기에서 점심 시간, 이벤트 등을 더 빼고 나면 여기저기 시간 구멍이 생깁니다)

오늘은 어제 들었던 “Advanced JSON”의 각종 스팩들(JSON, JSONP, JSONT, JSPON, …)을 다시 살펴보고(Advanced JSON 발표 내용 정리는 이 포스트에 정리하여 올렸습니다. JSON BOF는 이 포스트를 참고하세요), 오늘 오전에 들은 “Javascript – The Good Parts”에서 발표자가 굉장한 속도로 나열하면서 지나간 각종 이디움과 원칙, 스타일 추천 등에 대한 구글 뒷조사를 하며 보냈습니다(컨퍼런스 때 들은 내용 및 뒷조사 결과는 이 포스트를 참고하세요).

이제 착한 어린이는 잘 시간~

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

사용자 삽입 이미지사용자 삽입 이미지
(자바스크립트 계의 요다, Douglas Crockford)

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

자바스크립트는 장점도 많고 단점도 많은 언어이다. 단점을 피하고 장점을 슬기롭게 잘 살려서 쓰면 자바스크립트 안에 숨어있는 새로운 언어를 발견할 수 있다.

정도가 될 것 같습니다.

그가 첫번째로 지적한 자바스크립트의 단점은 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년 동안 유지될 수 있었다는 점입니다:
사용자 삽입 이미지
(약간 냉소적으로, 1999년 이후로 새로운 설계 오류가 없었다고 표현하고 있습니다)

이 덕에 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" 이었습니다.

사용자 삽입 이미지
(이 양반이 바로 Kris Zyp. 자꾸 이리저리 서성이는 바람에 초점이 대략...)

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 객체들을 트리 형식으로 브라우징 하거나, 수정할 수 있습니다:
사용자 삽입 이미지
(JSPON Browser)

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가 시연한 내용이 완전히 새로운 것은 아니지만 이런 개발 도구가 계속 나와주고 발전하는 것은 환영할 만한 일입니다 =)

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