목적
이전 블로그를 참고해주길 바란다.
jQuery의 등장
파이어폭스, 오페라, 사파리 등 다양한 브라우저가 등장했지만, 당시 높은 점유율을 차지하던 인터넷 익스플로러(IE) 는 ECMAScript 표준을 완전히 준수하지 않았고, 오히려 자체적인 비표준 기능들을 구현하곤 했다.
다른 브라우저들 역시 ECMAScript 스펙 지원 수준이 제각각이었기 때문에, 웹 개발자들은 브라우저별로 다른 코드를 작성해야 했고, 크로스 브라우징 이슈로 인해 큰 어려움을 겪었다.
이 문제를 해결하기 위해 등장한 것이 바로 한 시대를 풍미한 jQuery였다.
2006년 John Resig이 발표한 jQuery는 단순한 문법으로 DOM 조작과 Ajax 기능을 쉽게 구현할 수 있었고, 특히 브라우저 간 호환성 문제를 해결하여 동일한 동작을 보장한다는 점에서 당시 웹 개발자들에게 폭발적인 인기를 끌었다.
현재는 JavaScript의 발전, 브라우저 표준화, 그리고 React, Vue와 같은 SPA 프레임워크의 등장으로 jQuery는 점차 레거시로 취급되고 있다. 그럼에도 불구하고 2025년 최근 기준, 전 세계 웹사이트의 약 70~73%가 여전히 jQuery를 사용하고 있다고 한다.
AJAX(Asynchronous JavaScript and XML)
AJAX(아작스, 에이잭스)는 웹 페이지 전체를 다시 로드하지 않고도 브라우저가 비동기적으로 서버와 데이터를 교환할 수 있도록 해주는 기술이다.
과거에는 데이터를 전송하기 위해 form을 submit하면, 결과를 포함한 완성된 HTML 문서 전체를 다시 받아야 했기 때문에 동기적 방식으로 동작했다.
반면 AJAX를 사용하면 서버로부터 필요한 응답(주로 JSON)만 받아와 UI 일부만 갱신하면 되므로 훨씬 효율적이다. 이러한 특성은 이후 SPA(Single Page Application) 의 기반 기술이 되었다.
이 기술은 브라우저에서 제공하는 XMLHttpRequest 객체를 통해 구현되었는데, 이 객체는 인터넷 익스플로러(IE)에서 처음 도입되었다. 이후 다른 브라우저들도 지원하기 시작했고, 구글의 Gmail이나 Google Maps 같은 서비스가 AJAX를 활용하면서 널리 알려지게 되었다.
현재는 더 이상 XMLHttpRequest 객체를 직접 다루는 경우가 많지 않고, Fetch API 같은 웹 표준 API(프로미스 기반)나, Axios 같은 라이브러리를 활용하는 경우가 많다. 참고로 Axios도 내부적으로는 XMLHttpRequest를 사용해 동작한다고 한다.
좋습니다 👍
주신 글에서 역사적인 흐름에 초점을 맞추고, 불필요하게 기술적 디테일이 과도하게 들어간 부분은 정리해서 매끄럽게 다듬어드렸습니다.
Chrome(V8)의 등장
2008년, 구글은 크롬(Chrome) 브라우저를 공개하며 웹 환경에 큰 변화를 가져왔다. 크롬에는 C++로 개발된 자바스크립트 엔진 V8이 탑재되었는데, 이는 단순히 코드를 한 줄씩 해석하는 기존 방식과 달리, 필요한 경우 코드를 네이티브 머신 코드로 변환해 실행하는 JIT(Just-In-Time) 컴파일러를 적용한 것이 특징이었다. 이를 통해 자바스크립트 실행 속도는 크게 향상되었고, 브라우저 기반 애플리케이션 개발의 가능성이 더욱 넓어졌다.
크롬과 V8의 등장은 웹 브라우저 시장에 큰 파급력을 불러왔고, 자바스크립트가 단순한 보조 언어를 넘어 다양한 영역에서 활용될 수 있는 잠재력을 보여주었다.
이후 2009년, Ryan Dahl은 V8 엔진을 브라우저 밖에서도 독립적으로 실행할 수 있도록 포팅하였다. 여기에 이벤트 루프와 비동기 I/O를 제공하는 libuv를 결합하여 Node.js의 초기 버전을 개발했다. 이로써 자바스크립트는 브라우저 환경을 넘어 서버 사이드 영역에서도 사용할 수 있는 언어로 발전하게 되었다.
SPA와 CSR의 등장
2010년 전후, 스마트폰과 모바일 앱이 대중화되면서 사용자들은 앱에서 경험했던 빠르고 부드러운 인터랙션을 웹에서도 기대하게 되었다. 이런 요구는 곧 SPA(Single Page Application) 의 등장을 이끌었다.
SPA는 하나의 페이지 안에서 동적으로 화면을 업데이트하는 방식으로, 전통적인 MPA(Multi Page Application) 에서 발생하던 문제들, 페이지 전환 시 깜빡임, 데이터 전체 재로딩 등을 해결해 주었다. 초기에 필요한 리소스를 한 번에 불러온 뒤, 사용자의 행동에 따라 AJAX를 활용해 서버와 비동기적으로 데이터를 주고받으며, 클라이언트 측에서 UI를 다시 그려주는 방식이다. 덕분에 네이티브 앱과 유사한 사용자 경험을 제공할 수 있게 되었다.
SPA의 확산은 CSR(Client Side Rendering) 과 밀접한 관련이 있다. CSR은 서버가 최소한의 HTML만 내려주고, 이후 화면 렌더링은 클라이언트의 JavaScript가 담당하는 방식이다. SPA는 바로 이 CSR을 기반으로 구현된다.
이 시기에 Angular, React, Vue.js와 같은 프론트엔드 라이브러리와 프레임워크가 등장하면서 SPA 개발이 본격화되었다. 이로 인해 프론트엔드와 백엔드의 역할이 점차 분리되었고, 오늘날과 같은 프론트엔드 개발자라는 전문적인 역할이 자리 잡게 되었다.
다시 SSR로
트렌드는 돌고 도는 것일까. 한때 SSR(Server Side Rendering)에서 CSR(Client Side Rendering)로 전환되었던 흐름은, 다시 CSR에서 SSR로 돌아오는 추세다.
그 핵심적인 이유는 검색엔진 최적화(SEO) 때문이다. CSR 기반의 웹사이트는 검색엔진 크롤러가 콘텐츠를 제대로 읽어내지 못하는 경우가 많았다. 검색엔진이 사이트를 색인화하려면 크롤러가 해당 페이지를 방문해야 하는데, CSR 방식에서는 콘텐츠가 초기 HTML에 담겨 있지 않고, 자바스크립트 실행 이후에야 로드되기 때문에 크롤러가 이를 누락하는 문제가 있었다.
이런 한계 속에서, SPA 개발 방식의 장점을 유지하면서도 SSR을 지원하는 새로운 프레임워크들이 등장했다. 대표적으로 React 생태계의 Next.js와 Vue 생태계의 Nuxt.js가 있다. 이름에서도 알 수 있듯, 두 프레임워크는 비슷한 철학을 공유하며, SSR과 CSR을 유연하게 결합해 제공한다.
이러한 프레임워크들은 초기 요청 시 이미 완성된 HTML을 서버에서 내려주어 SEO 문제를 해결하고, 이후 필요한 부분은 CSR을 통해 동적으로 업데이트한다. 최근 채용 공고에서도 Next.js 경험을 요구하는 경우가 많을 정도로, SSR을 지원하는 프레임워크는 이제 프론트엔드 개발의 대세로 자리 잡았다.
마무리
이렇게 두 편에 걸쳐서 웹 개발의 발전 과정을 정리해 보았다. 주제가 방대하다 보니 예상보다 글을 작성하는 데 시간이 오래 걸렸다. 최대한 오류 없이 작성하려 노력했으나, 혹시 잘못된 부분이나 보완할 점이 있다면 댓글 부탁드립니다.
