Next.js를 계속 사용해 오면서 왜 이런 프레임워크가 등장하게 되었는지, 그리고 어떤 문제들을 해결하기 위해 만들어졌는지 고민해본 적이 없는 것 같다. 이번 기회에 프론트엔드 개발의 흐름을 정리하면서 Next.js가 등장하게 된 배경을 짚어보고자 한다.
초창기 웹 개발
과거에는 서버 개발자들이 웹 페이지 전체를 생성했다. Java와 JSP 템플릿 엔진을 통해 고정된 HTML에 변동되는 데이터를 서버에서 넣어 완성된 HTML을 만들고, 이를 클라이언트에 응답했다. 추후 사용자 인터랙션이 많아지게 되며 이러한 과정들은 UX를 크게 저하시키는 요인이 되었다. 서버에서 변동되는 데이터를 넣어주고 새로운 HTML을 응답 받는 과정까지 사용자는 아직 렌더링 되지 않은 흰 화면을 보고 있어야 하기 때문이다.
AJAX의 등장
이를 위해 AJAX(Asynchronous JavaScript and XML), 말 그대로 비동기적으로 서버와 통신하며 필요한 데이터만 받아올 수 있는 기술이 등장하게 되었다. 페이지 전체를 리로드하는 것이 아닌 일부만 갱신하여 부자연스러웠던 사용자 경험을 해결할 수 있게 된 것이다.
기존 레이어를 분리하게 되며 데이터 패칭과 화면 렌더링의 역할이 명확해지게 되었다.
CSR의 등장
하지만 앱의 규모가 점점 커지며 AJAX로는 유지보수가 복잡하게 되었다. 따라서 이를 체계적으로 만들기 위한 CSR이 등장하게 되었다. React를 예로 들어보자. HTML에는 <div id="root">만 있으며 필요한 경우에만 특정 js 파일이 번들링되어 다운 받고 브라우저에서 이를 실행하는 것이다. 하지만 여기서도 문제는 발생했다.
- js 번들 크기가 클 경우 초기 로딩 속도가 느리다.
- 검색 엔진은 html 파일을 기반으로 하기 때문에 빈 html만 읽는다.
SSR의 등장
이 문제들을 해결하고자 서버에서 HTML을 미리 렌더링하여 클라이언트로 보내주는 방식인 SSR이 등장한다. 클라이언트 단에서 필요한 인터랙션은 브라우저로 전달된 HTML에 Hydration으로 js를 연결해준다. 기능적으로는 준수해졌지만 렌더링의 위치가 서버로 바뀌며 프론트엔드 개발자가 감당해야할 범위가 서버를 위한 설정부터 라우팅 등까지 늘어났다.
Next.js의 등장
이처럼 프론트엔드 개발자가 감당해야 할 복잡성이 커지자, 이를 해결해주는 프레임워크가 등장했으니, 바로 Next.js다.
Next.js는 React 기반의 풀스택 웹 프레임워크로, 서버 사이드 렌더링, 정적 사이트 생성(SSG), API 라우트, 이미지 최적화 등 다양한 기능을 자동화하거나 추상화하여, 프론트엔드 개발자가 보다 쉽고 일관된 방식으로 웹 앱을 개발할 수 있도록 돕는다.
