웹 서핑을 하다 보면 이런 경험, 한 번쯤 해봤을 것이다. 검색창에 ‘맛집’이라고 입력하자마자 떠오르는 자동 완성 단어들. SNS에서 좋아요 버튼을 눌렀더니 숫자가 바로 바뀌는 마법. 혹은 쇼핑몰에서 상품을 장바구니에 넣었는데 페이지가 새로고침 없이도 ‘담겼습니다’라는 알림이 뜨는 순간.
이 모든 ‘부드러운 경험’의 배후에는 Ajax(Asynchronous JavaScript and XML)라는 기술이 버티고 있다 . 겉보기엔 단순한 ‘클릭’처럼 보이지만, 그 안에는 서버와 클라이언트가 눈치 싸움 없이 대화하는 세련된 비동기 통신의 미학이 숨어 있다.
이 글에서는 단순한 개념 설명을 넘어, 왜 Ajax가 웹 개발의 ‘상식’이 되었는지, 그리고 지금 이 순간에도 어떻게 우리의 온라인 경험을 지배하고 있는지 ‘잘난 척’ 좀 해보려 한다.
왜 굳이 Ajax를 써야 할까? (그냥 페이지 새로고침 하면 안 되나?)
과거의 웹은 ‘동기적(Synchronous)’이었다. 사용자가 링크를 클릭하거나 버튼을 누르면, 브라우저는 서버에 “나 여기 좀 바꿔줘”라고 외친다. 그러면 서버는 HTML 파일을 통째로 다시 만들어서 보내주고, 브라우저는 화면을 깜빡이며 새로고침을 한다 .
이 방식의 문제는 뭘까? 마치 편의점에서 물건 하나 살 때마다 건물 전체를 다시 짓는 것과 같다. 페이지의 1%만 바뀌어도 100%를 다시 로드해야 하니, 시간은 느려지고, 데이터는 낭비되고, 사용자 경험은 처참해진다 .
Ajax는 이 지루한 반복에서 탈출구를 제시한다.
- 비동기성(Asynchronous): 사용자가 버튼을 누르면, JavaScript가 조용히 뒤에서 서버에 “이 데이터만 보내줘”라고 요청한다. 서버가 대답하는 동안에도 사용자는 페이지에서 다른 걸 보고 클릭할 수 있다 .
- 부분 갱신(Partial Update): 서버는 HTML 같은 ‘꾸러미’ 대신, JSON이나 XML 같은 ‘필요한 정보’만 딱 보낸다. 그러면 JavaScript는 그 정보를 받아서 화면의 특정 부분만 몰래 바꿔치기 한다 .
결과적으로 웹페이지는 ‘살아있는 듯한’ 반응성을 얻게 된다. AWS의 문서에서도 이 방식을 통해 불필요한 서버 부하를 줄이고, 사용자 경험을 극적으로 개선할 수 있다고 강조하고 있다 .
이 기술, 어떻게 돌아가는 거지? (동작 원리)
Ajax의 동작 과정은 꽤 직관적이다. 마치 비서와의 커뮤니케이션을 떠올리면 쉽다.
- 이벤트 발생: 사용자가 검색어를 입력하거나 버튼을 클릭한다.
- 중간 관리자 호출: JavaScript가
XMLHttpRequest객체를 생성한다 . 이 객체가 바로 ‘비서’ 역할을 한다. - 서버에 몰래 요청: 이 비서가 서버에 가서 “사장님, 사용자가 이거 달라는데요?” 하고 데이터를 요청한다.
- 서버 처리 및 응답: 서버는 요청을 처리한 뒤, 필요한 데이터를 JSON 형태로 가볍게 돌려준다 .
- 화면 업데이트: 비서가 데이터를 가지고 돌아오면, JavaScript는 이를 해석해 DOM(Document Object Model)을 조작한다. 페이지 전체는 그대로 둔 채, 딱 그 부분만 새 콘텐츠로 교체한다 .
이 모든 과정은 사용자가 전혀 인지하지 못하는 사이에, 0.1초 만에 완료된다.
Ajax, 이 정도면 완벽한가? (장점과 단점)
물론 세상에 공짜는 없다. 이렇게 매끄러운 경험 뒤에는 몇 가지 ‘성격 차이’도 존재한다.
✅ 장점:
- 속도: 필요한 데이터만 주고받으니, 전체 페이지를 다시 그리는 것보다 압도적으로 빠르다.
- 자원 절약: 서버 입장에서도 매번 무거운 HTML을 렌더링하지 않아도 되니, 비용과 자원을 아낄 수 있다 .
- 사용자 경험(UX): 깜빡임 없는 인터페이스는 현대 웹에서 ‘예의’나 다름없다.
❌ 단점:
- 히스토리 관리: 페이지 이동 없이 내용이 바뀌다 보니, 브라우저의 ‘뒤로 가기’ 버튼이 오작동할 수 있다 . (물론 이건 지금은
pushState같은 기술로 어느 정도 해결했다.) - SEO 이슈: 예전에는 검색엔진 봇이 JavaScript를 실행하지 못해 Ajax로 불러온 콘텐츠를 읽지 못하는 문제가 있었다. 하지만 2024년 현재, 구글 봇은 자바스크립트를 꽤 똑똑하게 실행하고, HTML5의
pushStateAPI를 활용하면 Ajax로 구성된 SPA(Single Page Application)도 충분히 SEO 친화적으로 만들 수 있다 .
지금은 어떻게 쓰일까? (현대적 관점)
옛날에는 Ajax라고 하면 XMLHttpRequest를 직접 코딩하거나, jQuery의 $.ajax() 메서드를 떠올렸다. 하지만 지금은 더 세련된 도구들이 등장했다.
- Fetch API: 브라우저에 내장된 최신 표준. Promise 기반이라 콜백 지옥에서 벗어나게 해준다.
axios에 비해 기능이 약간 부족하다는 평이 있지만, 별도 설치 없이 바로 쓸 수 있다는 장점이 있다 . - Axios: Node.js와 브라우저 환경 모두에서 사용 가능한 강력한 라이브러리. Request Timeout 설정이나, JSON 데이터 자동 변환 등 실무에서 필요한 편의 기능이 잘 갖춰져 있다 .
기술의 본질은 변하지 않는다. 도구가 jQuery에서 Fetch나 Axios로 바뀌었을 뿐, “페이지를 새로고침하지 않고 서버와 대화한다”는 Ajax의 핵심 원리는 지금도 모든 모던 웹 애플리케이션(React, Vue, Angular)의 근간을 이루고 있다 .
이 기술이 빛나는 순간 (실제 사례)
Ajax는 이론만큼이나 실전에서 빛난다. 우리가 매일 사용하는 서비스들은 Ajax 없이는 존재하기 어렵다.
| 사용 사례 | 설명 | 대표 서비스 |
|---|---|---|
| 실시간 검색 | 검색어를 입력할 때마다 서버에 요청을 보내 연관어를 즉시 표시한다 . | Naver, Google |
| 소셜 미디어 피드 | 페이지를 새로고침하지 않고도 새로운 게시물을 무한 스크롤로 불러온다 . | Twitter(X), Instagram |
| 폼 검증 | 회원가입 시 ‘아이디 중복 확인’ 버튼을 누르면, 페이지 전환 없이 바로 사용 가능 여부를 알려준다 . | 대부분의 웹사이트 |
| 지도 서비스 | 지도를 드래그하거나 확대/축소할 때, 해당 영역의 이미지나 정보를 즉시 불러온다 . | Google Maps, Kakao Maps |
결국, Ajax는 끝난 건가?
Ajax는 특정 기술을 넘어 ‘웹의 패러다임’이 되었다. 사용자는 더 이상 ‘기다림’을 용납하지 않는다. 클릭 한 번에 즉각 반응하지 않는 웹사이트는 ‘느리다’는 낙인 대신, ‘오래됐다’는 혹평을 받는다.
Ajax를 이해한다는 것은 단순히 XMLHttpRequest 객체의 사용법을 아는 것을 넘어, ‘효율적인 통신’과 ‘매끄러운 경험’이라는 웹 개발의 핵심 가치를 이해하는 것이다.
당신이 지금 보고 있는 이 블로그 페이지도, 혹시 댓글을 작성한다면 아마도 Ajax를 통해 조용히 전송될 것이다. 기술은 계속 진화하지만, ‘사용자를 기다리게 하지 않겠다’는 그 철학은 영원하다.
더 알아보기
Ajax의 개념을 확실히 잡았다면, 이제 실전 코드를 보고 싶을 것이다. 다음 기술들을 살펴보며 당신의 웹 페이지를 한 단계 업그레이드해보라.
- 비동기 통신의 최전선:
[REST API와 Ajax의 차이점](https://pointer81.tistory.com/entry/ajax-vs-rest-api) - 모던한 코드 작성법:
[Fetch API vs Axios, 뭘 써야 할까?](https://cocoon1787.tistory.com/756)
혹시 Ajax를 사용하다가 ‘이전 페이지’ 이동이 꼬인 경험이 있는가? 아니면 SEO 때문에 골치를 앓은 적이 있는가? 댓글로 당신의 경험을 공유해보자. 우리 함께 이 ‘비동기’의 늪에서 헤엄쳐 나가보자.
