::: 한량모드 발동!! :::

글자를 칠 때, 제안되는 단어들이 변경되는 순간을 유심히 살펴보자. 거의 즉시 이루어진다. Google Maps의 경우에도 줌 인을 하거나 지도를 여기저기로 이동시켜 보아도 거의 즉시 모든 것이 이루어진다. 기다리라는 페이지를 보여주거나 페이지 전체가 리로드되는 일은 없다.

Google Suggest와 Google Maps는 Ajax라고 불리는 것이 적용된, 웹 어플리케이션의 새로운 접근방식의 실 예다. Ajax는 Asynchronous Javascript + XML의 줄임 말이며 웹이 할 수 있는 가능성의 근본적인 변화를 말해주고 있다.

Ajax 정의하기
Ajax는 특정한 하나의 기술이 아니다. 몇 가지 각 영역에서 활약하던 기술들로 이루어져있으며, 강력한 새로운 방법들로 뭉쳤다. Ajax는 다음의 것들을 통합한다.

* XML과 CSS를 이용한 표준에 기반 프레젠테이션
* DOM(Document Object Model)을 이용한 동적인 디스플레이와 상호작용
* XML과 XSLT를 이용한 데이터 교체와 조작
* XMLHttpRequest를 이용한 비동기식 데이터 검색
* 모든것을 함께 묶어주는 Javascript

전통적인 웹 어플리케이션 모델은 이렇게 작동한다.: 대부분의 사용자의 인터페이스에서의 액션은 웹 서버로의 HTTP Request를 유발한다. 서버는 데이터 검색, 수 처리, 여러 레거시 시스템들과의 소통 같은 몇 가지 프로세스를 하게 되고, 클라이언트에게 HTML페이지를 돌려준다. 이는 하이퍼텍스트를 매개체로 한 웹의 기본적인 사용법을 채용한 모델이다. 그러나 하이퍼텍스트는 소프트웨어 어플리케이션을 충분히 만족시키기엔 부족했다.


이런 접근법은 많은 기술적인 감각을 만들어냈지만 사용자에게 만족할만한 결과를 주지는 못했다. 서버가 할 일을 하는 동안 유저는 무엇을 하는가? 그렇다. 기다려야만 한다. 그리고 작업의 모든 스텝마다 사용자는 기다린다.

당연하게도, 어플리케이션들을 모두 긁어 모으는 식으로 웹을 디자인한다면 유저들을 기다리게 만들지 않을 수 있었을 것이다. 인터페이스가 한번 로드 되고 나면, 왜 사용자는 어플리케이션이 서버에게 무언가를 필요로 하는 모든 시간마다 기다려야 하는가? 진짜, 도대체 사용자들은 왜 어플리케이션이 서버로 가는 것을 보아야 하는가?

Ajax는 어떻게 다른가
Ajax 어플리케이션은 사용자와 서버 사이의 중개자- Ajax 엔진 –를 소개함으로써 웹에서의 소통의 본성인 가다 서는 반복행위를 제거한다. 응답을 더 낮춰주는 어플리케이션을 한층 더 두는 것 같으나 그 반대가 맞다.

세션이 시작될 때 웹 페이지를 로딩하는 것 대신, 브라우저는 Ajax엔진(Javascript로 코딩되고 항상 숨겨진 프레임 안에 집어넣어진)을 로드 한다. 이 엔진은 사용자가 접하는 인터페이스를 구성하는것과 유저를 위해 서버와 통신하는 것 모두를 책임진다. Ajax엔진은, 사용자가 서버와의 통신에 의존하지 않는, 비동기식으로 이루어지는 어플리케이션과 의사소통 할 수 있도록 한다. 그래서 사용자는 결코 빈 페이지나 모래시계 아이콘 같은 것들을 볼 수 없게 되고 서버가 무언가를 하는 동안 초조하게 기다리지 않아도 된다.

< 전통적인 웹 어플리케이션의 동기식 인터랙션 패턴(위)과 Ajax 어플리케이션의 비동기식 패턴과의 비교 >

일반적으로 HTTP request를 만들어내곤 하는 모든 사용자의 액션은 대신 Ajax엔진을 호출하는 자바스크립트의 형태를 한다. 서버로 되돌아갈 것을 요구하지 않는 사용자의 액션에 대한 어떤 응답- 간단한 데이터 검증, 메모리에서의 데이터 수정, 네비게이션 같은 것들 까지도 -도 엔진은 직접 다룬다. 엔진이 응답을 위해 서버로부터 무언가를 필요로 한다면- 프로세싱과 추가적인 인터페이스를 로딩하기 위해 혹은 새로운 데이터를 검색해오기 위해 데이터를 송신한다면 - 엔진은 비동기적이면서 XML을 항상 사용하고, 사용자의 어플리케이션과의 인터랙션을 멈추지 않도록 해주는 그런 리퀘스트들을 만들어낸다.


누가 Ajax를 사용하는가

Google은 Ajax에 다가가기 위한 개발에 엄청난 투자를 하고 있다. Google이 작년 이전에 소개해 온 모든 주된 품목들- Orkut, Gmail, Google Groups의 최신 베타 버전, Google Suggest, Google Maps –은 Ajax 어플리케이션이다. (이 Ajax 구현에 관한 더 많은 기술적인 너트와 볼트들을 얻고 싶다면 다음의 대단히 잘된 분석들- Gmail(http://johnvey.com/features/gmailapi/), Google Suggest (http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html), Google Maps (http://jgwebber.blogspot.com/2005/02/mapping-google.html)) -을 보시라. 다른 것들도 선례를 따르고 있다. : Ajax에 의존하고 있는 Flickr(http://www.flickr.com/) 에 사람들이 푹 빠져버린 수많은 특징이라든지, 유사한 기술을 적용한 Amazon의 A9.com 검색 엔진 등.

이 프로젝트들은 Ajax가 기술적인 장점뿐만 아니라 실 세계의 어플리케이션들에도 유용하다는 것을 보여주고 있다. 이것은 연구실에서만 이루어지는 별개의 기술이 아니다. 그리고 Ajax 어플리케이션들은 정말 단순한 Google Suggest에서부터 그 복잡하고 정교한 Google Maps에 이르기 까지 어떤 크기로도 될 수 있다.

Adaptive Path에서, 지난 몇 달 동안 우리의 일을 Ajax로 해오면서 Ajax 어플리케이션이 제공할 수 있는 풍부한 인터랙션과 응답성의 겨우 표면만을 긁어봤다는 것을 깨닫고 있는 중이다. Ajax는 웹 어플리케이션을 위한 중요한 발전이고 그 중요성은 막 성장해가고 있다. 그리고 이 기술을 어떻게 사용하는 아는 개발자들이 이미 매우 많기 때문에, Google의 선도를 따르는 조직들이 더욱 많이 볼 수 있기를 기대한다.


앞으로 나아가기

Ajax 어플리케이션을 만드는데 있어서 가장 큰 도전은 기술적인 것이 아니다. 이미 코어 Ajax 기술들은 성숙되어있고 안정되었으며 이해하기 쉽다. 그보다, 도전은 이러한 어플리케이션들의 디자이너들을 위한 것이다. 웹의 제한성 대한 우리가 생각하고 아는 것을 잊어버리도록 해주고, 더 넓게 상상할 수 있도록 하고 가능성의 범위를 풍부하게 하는 것.