웹 개발 트렌드가 변해온 과정에 대한 간단한 정리와 Next.js를 사용하게 된 이유에 대한 글이다.
Next.js 소개와 기능에 관한 내용은 다음 포스팅에서 중점적으로 다룰 예정
기술 스택 선택
많은 사람들이 무작정 트렌드를 따라간다는 이유로 새로운 기술을 사용하지만, 사람들이 그 기술을 선택하는 이유를 알고 상황에 맞게 선택하는 것이 중요하다.
예를 들어, 나는 지금부터 얘기할 Next.js는 웹 사이트의 관리자 페이지처럼 검색엔진에 노출이 필요없는 경우에는 사용하는 데에 이점이 크지 않다고 생각한다.
그래서, 웹 개발의 트렌드가 변화해온 과정을 보면서 React와 Next.js 같은 최신 기술을 어떤 기준으로 선택해서 사용할지 생각해보면 좋을 것 같다.
웹 개발의 트렌드
웹 개발은 JavaScript의 표준화와 AJAX 기술 등으로 인해 정말 많은 트렌드의 변화가 있었다.
특히, 초기의 웹 개발은 프론트엔드와 백엔드를 분리하지 않고 서버에서 모든 페이지를 만들어 전송하고, 그에 따라 사용자의 상호작용에 따른 브라우저의 동적인 기능도 많이 제한되었다.
웹 개발 트렌드의 변화를 살펴보면서 왜 Next.js같은 프레임워크 사용을 선호하게 되었는지 알아보자.
(물론, Next.js에 불편함을 느끼고 다시 React 기반의 SPA(Single Page Application)으로 돌아가는 사람들도 많지만...)
ASP(Active Server Pages)
1990년대 후반 ~ 2000년대 초중반
페이지의 HTML 구조를 서버에서 완전히 생성하여 클라이언트로 전송하는 방식
사용자 상호작용
- 브라우저에서 버튼 클릭 → 폼 제출
- 새로고침되며 서버에서 처리
장점
- 당시 기준으로는 (제한적이지만) 동적인 웹페이지 구현이 쉬웠음
- 많이 사용하던 Visual Basic과 유사한 문법으로, 학습이 쉬웠음
단점
- 코드와 HTML 혼합 → 규모가 커질수록 유지보수 어려움
- 객체지향 지원 부족, 재사용 어려움
구조적인 개발이 필요한 시대가 오면서 자연스럽게 밀림
PHP(Personal Home Page Tools)
2000년대 중반 ~ 현재도 일부 레거시 페이지에 사용됨
페이지의 HTML 구조를 서버에서 완전히 생성하여 클라이언트로 전송
사용자 상호작용
- 여전히 폼 제출 + 새로고침
- 나중에는 jQuery와 결합하여 사용하기도 함 (AJAX 도입)
장점
- 배우기 쉬움, 웹 호스팅 환경에서 거의 무조건 지원
- 수많은 프레임워크 → MVC 아키텍처 적용, 원활한 협업 가능
단점
- 코드 품질이 개발자에 따라 천차만별 (초보자 접근성은 높지만 유지보수 어려움)
- 느슨한 문법 → 대규모 프로젝트에는 부적합한 경우 많음
품질 관리와 대형화의 한계가 존재함
JavaScript는?
JavaScript를 사용하면 동적인 브라우저 렌더링이 가능한데 왜 ASP나 PHP 같은 기술을 사용했을까?
2000년대까지도 JavaScript를 사용하지 않은 이유는 다음과 같다.
- 브라우저마다 스크립트 호환성이 다름
- 성능이 느리고, 일부 유저는 JavaScript를 꺼놓기도 했음
- 당시에는 서버 중심 아키텍처에, 클라이언트는 그냥 화면 보여주는 역할만 하는 것이 일반적
ECMA 표준이 생김
JavaScript는 브라우저마다 호환성이 달라서 1997년에 ECMA TC39라는 문서를 통해 단일화의 움직임이 있었지만, 웹 브라우저 벤더들의 비협조적인 태도로 실패했었다.
그 이후 일명 2차 브라우저 전쟁이 끝난 후에야 ECMA Script 5가 제정되면서 대부분의 브라우저에서 동일하게 호환되었다.
프론트엔드와 백엔드의 분리
JavaScript의 브라우저 호환성 문제가 해결됨에 따라 모든 브라우저에서 동일한 방식으로 UI를 구현할 수 있게 되었고, 브라우저가 더 많은 할 수 있게 되면서 자연스럽게 프론트엔드와 백엔드 개발이 분리되는 추세가 되었다.
JavaScript + JQuery
2006년 ~ 2015년경
페이지를 새로고침하지 않고 빠르게 뷰를 변경할 수 있는 SPA(Single Page Application)를 구현할 수 있게 되어 자연스럽게 해당 방식으로 트렌드가 바뀜
사용자 상호작용
- onClick, onChange 등을 쉽게 바인딩
- 페이지 리로드 없이 UI 업데이트 가능
장점
- DOM 조작, 이벤트 처리, AJAX를 쉽게 만들어줌
- 웹 UI의 풍부한 사용자 상호작용 가능
단점
- 코드 구조가 스파게티처럼 얽히기 쉬움
- 상태 관리, 화면 갱신 복잡 → 규모 커지면 힘듦
DOM을 직접 조작하기 때문에 상태 관리가 힘들다는 문제점으로 밀림
React
2013년 ~ 현재
컴포넌트 기반으로 UI를 관리하고, 상태 관리와 Virtual DOM을 통한 빠른 렌더링으로 SPA 구축에 사용됨
사용자 상호작용
- javascript를 사용하기 때문에 여전히 onClick, onChange 등을 쉽게 바인딩하고, 페이지 리로드 없이 UI 업데이트가 가능함
사용자 상호작용 발생 → state 변경 → 화면 자동 갱신의 과정을 거침
장점
- 빠른 렌더링 (Virtual DOM)
- 재사용 가능한 컴포넌트 구조
- DOM 조작을 React가 내부적으로 수행하기 때문에 관리가 쉬움(선언형 프로그래밍)
선언형 프로그래밍에 대한 설명은 아래 포스팅을 참고하면 좋음!
useState와 선언형 프로그래밍
https://velog.io/@juwon98/React-useState
단점
- 서버 사이드 렌더링이 없음 (SEO 문제)
- 초기 세팅이 복잡함 (webpack, babel 등)
- 첫 페이지 로딩이 느릴 수 있음
SEO 문제가 있고, 퍼포먼스(첫 페이지 로딩 등)를 개선하고 싶어하는 개발자들이 많아짐
-> React 기반의 프레임워크인 Next.js를 사용하게 됨
위와 같은 트렌드의 변화를 거치면서 많은 개발자들이 Next.js를 사용해 SEO 문제를 쉽게 해결하고, SSR, SSG 등의 기술을 통해 퍼포먼스를 개선하려는 시도를 하고 있다.
