위의 제목은 Ajax라는 단어를 처음 사용한 것으로 알려진 Jesse James Garrett의 Ajax에 대한 소개글의 제목입니다. 제목에서 알 수 있듯이 Ajax는 웹 응용 프로그램 개발을 위한 새로운 접근법입니다. Garrett의 원문을 읽고 싶으신 분은 여기를 클릭해 주세요.
위 글을 보면 아시겠지만 Garrett은 이미 2005년 2월에 Ajax라는 새로운 접근 방법을 제시했습니다. 그리고 그것을 가장 먼저 채택하고 발전시켜 온 곳이 바로 구글(www.google.com) 이지요.
일반적으로 Ajax를 소개할 때 단골손님처럼 빠지지 않고 등장하는 것이 바로 구글 Earch와 구글 Suggest입니다. 구글 Suggest는 네이버나 다음등 국내 대형 포털에서도 이제는 익숙하게 사용하고 있는 기능들이지요.
재미있는 것은 웹 응용 프로그램에 대한 새로운 접근법으로 제시된 Ajax가 결코 새롭지 않은 기술들을 이용하고 있다는 것입니다. 자바스크립트는 이미 1990년대 중반 월드 와이드 웹의 폭발적으로 보편화되기 시작하던 때부터 존재하고 있었습니다.
XML 또한 제법 오래전에 표준으로 제정된 개념이었고 Ajax의 핵심을 담당하는 XmlHttpRequest 역시 IE 4.0부터 제공이 되던 기술이었습니다. 다만 그 당시에는 지금과 같은 초고속 인터넷 망의 보급이 여의치 않았던 시절이었고 그런 상태에서 XmlHttpRequest를 이용한 비동기 통신을 시도했다면 아마도 느린 속도 때문에 사용자들은 웹 브라우저가 멈춰버린 것으로 오해했을지도 모릅니다.
어찌됐든 지금은 눈깜짝할 새에 웹 페이지를 보여줄 수 있는 고속 인터넷 시대가 되었고 Ajax는 오랜 무명의 터널을 지나 웹 개발자들의 수퍼스타가 되어 버렸습니다.
Ajax를 정의하는 요소들
Ajax의 가장 큰 특징은 자바 스크립트와 XML 등의 표준 기술들을 이용하여 클라이언트와 서버 사이의 비동기 통신을 가능하게 한다는 것입니다. 웹 응용 프로그램의 관점에서 보면 사용자가 라운드트립을 느끼지 못하게 하면서도 서버와 데이터 교환이 가능해 진다는 것입니다.
경력이 조금있는 웹 개발자라면 누구나 한 번쯤 깜박임 없는 웹 응용 프로그램의 개발을 시도해 보았을 것입니다. 적어도 Ajax를 모르기 전에는 숨겨진 프레임이나 IFRAME 등을 이용한 꽁수(?)를 써서 비슷한 기능을 구현하기도 했었지요. 그러나 실제로 Ajax 기법이 적용된 웹 사이트들은 여전히 숨겨진 프레임이나 IFRAME을 함께 사용하고 있으니 단지 꽁수라고 치부해 버리기는 어렵습니다.
앞서 소개했던 Garrett은 자신의 글에서 Ajax를 정의하는 요소를 다음과 같이 소개하고 있습니다.
1. 표준을 따르는 UI 표현 방법
XHTML과 CSS와 같은 표준화된 기술을 이용하여 웹 브라우저 독립적인 UI의 표현이 가능합니다.
2. DOM을 이용한 동적인 페이지 표현
DOM (Document Object Model)을 이용하여 동적으로 웹 페이지의 컨텐츠를 변경하거나 페이지 요소와 상호작용할 수 있습니다.
3. XML/XSLT를 이용한 데이터 교환 및 표현
표준 기술인 XML과 XSLT를 이용하여 데이터를 교환하고 표현할 수 있습니다.
4. XMLHttpRequest를 이용한 비동기 데이터 전송
XMLHttpRequest를 이용하여 비동기 데이터 통신이 구현될 수 있습니다.
5. 이 모든 것들을 어우르기 위한 자바 스크립트
그리고 이러한 모든 것들은 자바스크립트를 통해 제어할 수 있습니다.
Garrett은 이와 같은 5가지 조건이 바로 Ajax 스타일의 웹 응용 프로그램을 개발하는데 필요한 요소라고 말하고 있습니다. 그러나 이 5가지가 반드시 사용되어야 하는 것은 아닙니다. 자바 스크립트와 XMLHttpRequest를 이용하여 비동기 통신을 구현할 수 있다면 이것도 Ajax 스타일의 웹 응용 프로그램이라 할 수 있지요.
Ajax, 대체 어떤 장점이?
그렇다면 우리가 Ajax를 사용할 경우 어떤 장점이 있을까요? 우리는 왜 Ajax에 열광하고 이것을 배우기 위해 안달복달 하는 것일까요? 왜 많은 개발자들이 자신이 사용하는 웹 개발 언어를 지원하는 Ajax 라이브러리를 앞다투어 개발하고 공개하고 있는 것일까요?
먼저 기존의 웹 응용 프로그램과 Ajax를 채택한 웹 응용 프로그램의 동작 방식이 어떻게 다른지 Garrett이 제시한 그림을 보면서 이야기 해보도록 하겠습니다.
그림 1: 기존 웹 응용 프로그램과 Ajax 스타일 웹 응용 프로그램의 동작 방식
그림에서 보듯이 기존의 웹 응용 프로그램은 웹 브라우저와 웹 서버 사이에서 사용자의 특정 동작이 발생할 때마다 매번 라운드 트립이 발생했었습니다. 이 과정에서 사용자는 라운드 트립 이후 서버로부터 웹 브라우저가 페이지를 다운로드 하는 동안에 늘 썰렁한 하얀 화면을 보고 있어야 했었지요.
그에 반해 Ajax 스타일의 웹 응용 프로그램은 XMLHttpRequest를 이용하여 백그라운드에서 서버와의 통신을 수행합니다. 또한 HTML이나 CSS, 자바 스크립트 등이 모두 새로 전송되는 것이 아니라 필요한 데이터만 XML 형태로 전송되므로 네트워크 트래픽을 줄일 수 있다는 장점도 있지요.
제가 생각하기에 가장 큰 장점은 서버가 해야 할 일을 클라이언트에게 나누어 줄 수 있다는 것입니다. 즉, 서버는 데이터만 전송해 주고 이 데이터를 가공하고 UI에 표시하는 것은 자바스크립트를 통해 클라이언트 측에서 처리할 수 있다는 것이지요. 계속해서 발전하는 클라이언트 컴퓨터의 성능을 제대로 활용할 수 있는 방법이라 할 수 있습니다.
Ajax 모델을 채택할 경우 우리가 얻을 수 있는 장점을 간단히 소개해 보면 다음과 같습니다.
1. 비동기 통신을 통한 UI 성능의 향상
웹 브라우저가 서버와 통신하는 동안 사용자는 자신이 원하는 다른 작업을 수행할 수도 있습니다. 왜냐하면 브라우저와 서버의 통신이 비동기적으로 진행되기 때문이지요. 버튼 한 번 클릭하고 서버로부터 응답이 오기까지 아무것도 할 수 없었던 것과 비교해 볼 때 이는 활용 정도에 따라 대단히 생산적인 일을 할 수 있는 좋은 방법이 됩니다.
2. 네트워크 트래픽의 감소와 서버/클라이언트의 분업
웹 브라우저가 현재 페이지 데이터를 서버로 전송한 후 서버에서 처리된 결과는 다시 클라이언트로 전달됩니다. 이 때 페이지를 재구성하기 위해 모든 HTML 코드와 CSS 코드, 자바 스크립트 코드 등이 함께 다운로드되고 실행됩니다. ASP.NET의 이벤트 드리븐 웹 폼 페이지의 경우 버튼을 클릭하면 해당 페이지가 다시 로드됩니다. 같은 페이지를 보여주기 위해 매번 많은 양의 데이터가 서버로부터 클라이언트로 전송되는 것이지요.
그러나 Ajax를 이용하면 서버는 최소한의 데이터만을 클라이언트로 보내게 됩니다. 클라이언트는 이 데이터를 받아 DOM을 이용하여 페이지의 컨텐츠를 업데이트 해주게 되지요. 클라이언트 또한 서버가 작업하는데 필요한 최소한의 정보만 골라서 보낼 수 있습니다.
3. C/S 환경과의 차이점을 최소화
최근에는 많은 기업용 소프트웨어들이 웹을 기반으로 만들어지고 있습니다. 인터넷과 웹 브라우저만 있으면 언제 어디서든 활용할 수 있다는 장점 때문이지요. 그러나 한편으로는 특정 작업을 수행할 때마다 라운드 트립 때문에 멀뚱멀뚱 기다려야 한다는 것, 그리고 웹이 가진 한계로 인해 기존의 기업용 소프트웨어들이 제공하던 것과 유사한 UI를 구현한다는 것이 매우 어려웠다는 점입니다.
그러나 Ajax를 통해 이러한 웹 기반 응용 프로그램의 단점을 어느 정도 커버할 수 있게 되었습니다. 가장 대표적인 예가 바로 얼마전 발표된 구글 스프레드 시트입니다.
그림 2: 구글 스프레드 시트의 모습
그림에서 보듯이 구글은 웹 브라우저에서 마이크로소프트의 엑셀과 유사한 UI를 구현해 두었습니다. 우리가 알고 있는 것과 같은 방법으로 이 스프레드 시트를 사용할 수 있으며 작성된 시트는 엑셀 파일이나 CSV 파일로 내 컴퓨터로 다운로드 할 수도 있습니다.
물론 엑셀과 비교해 볼 때 매우 단순한 기능만이 제공될 뿐이지만 업무에 꼭 필요한 기능들을 구현하는데는 필요한 시간이 그다지 길지 않을 것으로 예상됩니다.
이처럼 기존의 데스크톱 응용 프로그램과의 차이점을 줄이고 거기에 웹이 가진 장점을 더욱 극대화함으로써 Ajax는 새로운 형태의 응용 프로그램 개발 방향을 제시하고 있습니다.
Ajax, 그럼 누구나 좋아라해야 하는걸까?
세상 모든 이치가 그렇듯 좋은 점이 있으면 나쁜 점도 있게 마련이겠지요. Ajax라고 무슨 용빼는 재주가 있어서 모든 것이 다 좋기만 하지는 않을 것입니다. Ajax가 가지는 단점, 어떤 것들이 있을까요?
1. 아직은 쉽지 않은 브라우저 독립적인 웹 페이지
아시다시피 웹 브라우저들은 그동안 인터넷 시장을 차지하기 위한 기업들의 이해관계 덕분에 각기 제멋대로 발전해 왔습니다. 물론 최근에는 이러한 차이점을 줄이고 표준을 받아들이려는 노력이 가시화 되고 있으며 Ajax가 그런 노력들에 많은 보탬이 되고 있습니다.
그러나 아직까지도 브라우저 독립적인 페이지를 개발하는 것은 쉬운 일이 아니며 특히 초보 웹 개발자들에게는 매우 곤욕스러운 일이 아닐 수 없습니다. 그렇다면 반드시 Ajax 스타일의 웹 응용 프로그램은 브라우저 독립적이어야 하는 것일까요?
물론 그렇게 할 필요는 없습니다. 그러나 Ajax를 구성하는 요소들이 모두 인터넷 표준을 따르고 있으므로 (사실 XMLHttpRequest는 표준은 아닙니다만) 가급적 브라우저에 독립적인 웹 페이지를 구현하는 것이 보다 Ajax 스러운 웹 응용 프로그램이라는 것이지요.
어쨌든 쉬운 일만은 아니니 우리 웹 개발자들은 Ajax 덕분에 또 한 가지 시련을 겪게 되었습니다. 모쪼록 마이크로소프트와 모질라 재단이 W3C의 표준을 적극적으로 준수해 주기를 바랄 뿐이지요.
2. 늘어나는 코딩량
서버와 클라이언트 사이에 전달되는 데이터와 트래픽은 감소할 지언정 우리가 작성해야 하는 코드는 획기적으로 늘어날 수 있다는 안타까운 현실이 우리를 기다리고 있습니다. 언뜻 이해가 안가시지요?
만일 여러분이 <TABLE>태그를 페이지에 표시해야 한다고 가정해 보겠습니다. 기존의 방법이라면 그저 서버 측 페이지에서 <TABLE>태그를 작성하기만 해주면 끝이었습니다. 그러나 Ajax를 채택하게 되면 이야기는 달라집니다. 서버에서 전달되는 것은 <TABLE>태그를 작성하는데 필요한 데이터 뿐입니다. 나머지는 자바 스크립트를 통해 제어해야 한다는 것이지요.
<table border="0" cellpadding="0">
<tr>
<td>Hello, World!</td>
</tr>
</table>
이 코드를 만들기 위해 우리가 작성해야 하는 자바 스크립트 코드는 다음과 같습니다.
function buildTable() {
var objTable = document.createElement("table");
objTable.border = 0;
objTable.cellpadding = 0;
var objTr = objTable.insertRow(0);
var objTd = objTr.insertCell(0);
objTd.innerText = "Hello, World";
document.body.appendChild(objTable);
}
이게 끝일까요? 아니지요. 위의 코드가 잘 동작하는지 테스트와 디버깅을 해야합니다. 작업이 몇 배로 늘어날 수도 있다는 것, 미리 알아두셔야 하지 않을까요?
3. 디버깅, 완전 대박이다
그렇습니다. Ajax 스타일을 채택하면 디버깅, 완전 대박입니다. 기존에는 라운드 트립 과정에서 서버 코드에 오류가 발생한 경우 브라우저 상에 오류 내용이 표시되었습니다. ASP.NET의 경우 강력한 디버깅 기능과 추적 기능으로 정말 한 눈에 알아볼 수 있을 정도로 상세한 정보가 출력됩니다.
그런데 Ajax를 채택하면 이러한 디버깅 정보는 더 이상 볼 수가 없습니다. 왜냐하면 그 오류 데이터는 XMLHttpRequest 덕분에 백그라운드로 숨겨지기 때문이지요. 물론 다른 여러 가지 방법을 통해 디버깅을 할 수는 있습니다. 그.러.나 여러분은 지금까지 알고 있던 디버깅 방법을 버리고 새로운 디버깅 방법을 배우고 경험해야 합니다. 산너머 산이네요.
(다행히 이러한 작업들은 Ajax.NET이나 Atlas 등의 Ajax 프레임워크를 이용할 경우 어느 정도 도움을 받을 수 있습니다. 그러나 분명 우리가 지금까지 해오던 방법과는 많은 면에서 다를 수 있다는 것도 사실입니다.)
4. 새롭게 대두되는 보안 문제
Ajax를 사용하게 되면 보안에 구멍이 뚫릴 우려가 상당히 높습니다. 왜냐하면 Ajax는 일단 자바스크립트에 의해 제어가 되며, 자바 스크립트는 js파일만 다운로드하면 간단히 열어볼 수 있기 때문입니다. (그래서인지 자바스크립트를 읽기 어렵도록 난독처리해 주는 웹 사이트도 있더군요. ㅡㅡ;;)
자바스크립트 파일이 노출되면 우리가 개발한 웹 응용 프로그램이 어떤 패턴으로 서버와 데이터를 주고받는지 적나라하게 공개되는 것입니다. 완전 해커들 앞에서 벌거벗고 춤추는 것과 다름이 없지요.
다행히 Ajax는 SSL로 보호를 할 수도 있습니다만 그렇다고 모든 페이지에 SSL 보안을 걸기도 우습거니와 다양한 암호화 기술을 적절히 활용하고 중요한 데이터나 정보는 가급적 서버 쪽에서 처리할 수 있도록 하는 것이 최선의 대책이 아닐까 생각됩니다.
이 외에도 몇 가지 단점들이 존재하지만 대부분 소소한 것들이므로 일단은 패스 하도록 하겠습니다. 사실 제가 여기서 장점과 단점을 늘어놓아봤자 여러분이 Ajax를 이용하여 웹 페이지를 개발하면서 느끼는 것에 비하면 아무것도 아닐테니까요.
Ajax - 선택과 활용은 여러분의 판단에 좌우됩니다.
지금까지 Ajax란 무엇이고 어떤 장점을 가지는지, 또 어떤 단점을 가지는지 살펴보았습니다. 저로서는 솔직히 Ajax의 단점들을 경험한 후로 Ajax를 정말 사용해야 하는 것인지 한때 의심하기도 했습니다.
그러나 모든 도구들이 그러하듯이 언제, 어떻게, 누가, 왜 사용하느냐에 따라 그 결과는 천차만별로 달라질 수 있다는 것을 굳이 제가 말씀드리지 않아도 충분히 아실 것입니다. 다만 무분별한 사용보다는 반드시 필요한 부분에 꼭 필요한 만큼만 사용한다면 아마도 웹 응용 프로그램은 지금보다 훨씬 나은 모습을 갖출 수 있을 것입니다.
Ajax가 새로운 웹 응용 프로그램의 초석이 되느냐 아니면 말도많고 탈도많은 천덕꾸러기 신세가 되느냐는 바로 우리들, 웹 개발자의 손에 달려있다는 점을 명심해야 하겠습니다.
written by webgenie
www.bullog.net
Microsoft ASP/ASP.NET MVP