AJAX는 Asynchronous JavaScript and XML 의 약자로, 비동기적 웹 어플리케이션의 제작을 위해 사용하는 웹 개발 기법이다. 용어와 실제 기술간의 차이가 커져서 요즘에는 약어가 아닌 고유명사 취급하고 있다.
Ajax는 자체가 하나의 특정 기술을 말하는 것이 아니며,
함께 사용하는 기술의 묶음을 지칭하는 용어이다.
- 표현 정보를 위한 HTML (또는 XHTML) 과 CSS
- 동적인 화면 출력 및 표시 정보와의 상호작용을 위한 DOM, 자바스크립트
- 웹 서버와 비동기적으로 데이터를 교환하고 조작하기 위한 XML, XSLT, XMLHttpRequest (Ajax 애플리케이션은 XML/XSLT 대신 미리 정의된 HTML이나 일반 텍스트, JSON, JSON-RPC를 이용할 수 있다).
Ajax 어플리케이션은 실행을 위한 플랫폼으로 위에서 열거한 기술들을 지원하는 웹 브라우저를 이용한다. 지원하는 브라우저로는 파이어폭스, 익스플로러, 오페라, 사파리, 크롬등이 있다.
Ajax의 보급
다른 웹 브라우저들이 XMLHttpRequest를 도입할 즈음에 구글은 2004년 4월 1일에 발표된 Gmail, 2005년 2월 8일에 발표된 구글 지도가 아무런 플러그인 없이 AJAX로 구현된 웹 애플리케이션으로 밝혀지면서 화제거리가 되었다.
구글 지도의 발표로부터 열흘 뒤 Jesse James Garrett가 이러한 비동기 통신을 "웹 애플리케이션에 대한 새로운 접근 방식, Ajax"라고 부르면서 짧은 글자와 쉬운 발음 덕분에 점차 고유명사처럼 굳어졌다.
특히, 구글 지도가 막 나왔을 때의 충격적인 반응은 국내에서 더욱 두드러졌는데, 당시 한국의 지도 서비스는 열이면 열 ActiveX 기반이었기 때문이다. ActiveX 없이 지도 같은 서비스가 구현된다는 사실이 국내에서는 큰 충격으로 다가왔고, 국내에서는 너도나도 지도를 AJAX 기반으로 바꾸었다.
Ajax를 사용할 때 장점
기존의 웹 어플리케이션은 브라우저에서 폼을 채우고 이를 웹 서버로 제출하면 하나의 요청으로 웹 서버는 요청된 내용에 따라서 데이터를 가공하여 새로운 웹 페이지를 작성하고 응답으로 되돌려준다. 이때 최초에 폼을 가지고 있던 페이지와 사용자가 이 폼을 채워 결과물로서 되돌려 받은 페이지는 일반적으로 유사한 내용을 가진 경우가 많다.
결과적으로 중복되는 HTML 코드를 다시 한번 전송을 받음으로써 많은 대역폭을 낭비하게 된다.
대역폭의 낭비는 금전적 손실을 야기할 수 있으며 사용자와 대화(상호 반응)하는 서비스를 만들기 어렵게도 한다.
또한 사용자 경험에도 악영향을 끼쳤는데 Ajax 기술을 사용하지 않는 사이트가 특유의 깜빡거림 현상이 생기는 이유가 매번 페이지를 싹 지우고 처음부터 다시 모든 것을 그려내기 때문이다.
반면에 Ajax 어플리케이션은 필요한 데이터만을 웹 서버에 요청해서 받은 후 클라이언트에 대한 처리를 할 수 있다. Ajax는 웹 페이지의 디자인 요소와 정보 요소를 분리한다. 처음 사이트에 접속하면 웹 서버는 해당 페이지의 스타일과 레이아웃을 정의하는 정적 HTML 파일과 CSS 파일, 그리고 데이터를 어떻게 요청하면 되는지를 설명한 JavaScript 파일을 전달한다.
브라우저는 일단 이 내용으로 페이지의 기본적인 골격을 구축해 놓는다. 그리고 골격의 구축이 끝나면 브라우저는 전달받은 JavaScript를 실행해서 서버에 데이터만을 별도로 요청한다.
이때 서버에서 주는 응답은 순수한 데이터 객체 즉 XML 또는 JSON 데이터이다. 브라우저가 이 데이터를 수신하면 미리 만들어 둔 틀 안에 적절한 방법으로 데이터를 끼워 넣는다.
보통 SOAP나 XML 기반의 웹 서비스 프로토콜이 사용되며, 웹 서버의 응답을 처리하기 위해 클라이언트 쪽에서는 자바스크립트를 쓴다. 웹 서버에서 전적으로 처리되던 데이터 처리의 일부분이 클라이언트 쪽에서 처리되므로 웹 브라우저와 웹서버 사이에 교환되는 데이터량과 웹 서버의 데이터 처리량도 줄어들기 때문에 어플리케이션의 응답성이 좋아진다.
또한 웹서버의 데이터 처리에 대한 부하를 줄여주는 일이 요청을 주는 수 많은 컴퓨터에서 일어나기 때문에 전체적인 웹 서버 처리량도 줄어들게 된다.
정리하자면
1) 페이지 이동없이 고속으로 화면을 전환할 수 있다.
2) 서버 처리를 기다리지 않고, 비동기 요청이 가능하다.
3) 수신하는 데이터 양을 줄일 수 있고, 클라이언트에게 처리를 위임할 수도 있다.
4) 플러그인 없이도 인터렉티브한 웹페이지 구현이 가능하다.
Ajax를 사용할 때 단점
1) Ajax를 쓸 수 없는 브라우저에 대한 문제
2) HTTP 클라이언트의 기능이 한정되어 있음
3) 페이지 이동없는 통신으로 인한 보안상의 문제
4) 지원하는 문자집합(charset)이 한정되어 있음
5) 반드시 JavaScript로 작성되므로 디버깅이 용이하지 않음
6) 요청을 남발하면 역으로 서버 부하가 늘 수 있음
레이아웃이 너무 복잡한 사이트는 웹 브라우저가 렌더링하는 데 힘겨워할 수도 있다.
또는 아주 신속하게 첫 화면을 보여 줄 필요가 있는 경우에도 Ajax는 최소 두 번의 데이터 요청
(일반적으로 4회 이상. HTML, CSS, JS 로딩 후 Ajax call 1회)을 해야 한다는 문제가 있다.(속도 저하가 필연적으로 발생한다.) 이런 경우에는 의도적으로 옛 방식 그대로 서버가 모든 페이지를 그려서 전달한다. '서버 사이드 렌더링'이라는 새로운 포장(?)을 두르고 있는데 결국 옛 기술의 현대적 재해석이다.
7) 다른 도메인과는 통신이 불가능함
사용 예시
GET을 사용하여 Ajax 요청을 하는 단순한 예제
// 클라이언트-사이드 스크립트
// Ajax 요청을 초기화합니다
var xhr = new XMLHttpRequest();
xhr.open('get', 'send-ajax-data.php');
// 요청의 상태 변화를 추적합니다
xhr.onreadystatechange = function(){
if(xhr.readyState !== 4) return;
// readyState 4: 완료
if(xhr.status === 200) {
// status 200: 성공
console.log(xhr.responseText); // '반환된 텍스트'
} else {
console.log('에러: ' + xhr.status); // 요청 도중 에러 발생
}
}
<?php
// 서버-사이드 스크립트
// 내용의 형식을 설정합니다
header('Content-Type: text/plain');
// 데이터를 보냅니다
echo "반환된 텍스트";
?>
대체/보완 기술
Ajax는 비동기 데이터 전송 기술이지만 '양방향' 기술이 아니며 또한 '요청-응답' 사이클이 지나고 나면
통신 소켓을 닫아버린다는 문제가 있다. 따라서 완전한 실시간 통신을 지원하기 위해 웹 소켓이라는 새로운 기술이 구현되었다.
웹 소켓은 요청-응답 사이클이 지나도 통신 소켓을 닫지 않고 계속해서 송수신할 수 있도록 기존의 HTTP프로토콜에 약간의 변형을 가한다.
웹 소켓이 TCP에 기반하고 있어 대규모 실시간 데이터 전송에 적합하지 않기 때문에 UDP에 기반한 WebRTC라는 기술이 구현되었다. WebRTC는 여기서 한 발 더 나아가 서버의 중개를 필요로 하지 않는 브라우저간 P2P 통신 채널을 형성하는 기능도 가지고 있다.
Ajax기술 위에서 구현된 실시간 통신기술로 Long polling 기술이 있다. Long polling은 서버에 요청을 보내면 서버는 즉시 응답을 주는 게 아니라 새로운 정보가 갱신될 때까지 소켓을 열어둔 채 응답을 미룬다. 그러다 새로운 정보가 들어오면 그 때 열려 있는 소켓을 통해 응답을 돌려주며 클라이언트(웹 브라우저)는 응답을 받는 즉시 새로운 요청을 서버에 날린다. 이렇게 해서 '응답하면 통신 채널이 닫히는' 문제를 우회한다.
Socket.io 라이브러리의 웹 소켓 대체모드가 이 Long polling 방식으로 이루어진다.
