화면이 깜빡이던 시절
예전 웹사이트는 메뉴를 누를 때마다 화면이 잠깐 하얘졌다. 인터넷이 느리면 길게, 빠르면 짧게 보였을 뿐 구조는 같았다.
이유는 단순하다. 페이지를 옮길 때마다 브라우저가 서버에 그 주소에 해당하는 새 문서를 달라고 요청하고, 받은 것으로 화면을 통째로 다시 그렸기 때문이다. 이 방식을 여러 페이지 방식이라고 한다.
화면 하나가 곧 문서 하나이므로 구조가 단순하다는 장점이 있었다. 검색 엔진도 주소마다 완성된 문서를 받으니 읽기 쉬웠다.
모바일 앱이 눈높이를 올렸다
그러다 모바일 앱이 나왔다. 앱은 웹과 근본이 다르다. 앱스토어에서 내려받을 때 화면을 그리는 데 필요한 것들을 이미 기기에 받아 둔다.
그래서 화면을 옮길 때 서버에 문서를 새로 달라고 하지 않는다. 이동은 즉시 하고, 그 화면에 채울 값만 서버에서 받아 채운다. 깜빡임이 없고 부드럽다.
이 감각을 겪은 사용자들의 기준이 올라갔다. 웹에서도 안 되느냐는 물음이 생겼고, 답은 된다였다.
한 페이지 방식이 그 답이다. 처음 들어올 때 필요한 것을 받아 두고, 사용자가 다른 화면으로 가겠다고 하면 숨겨 둔 화면을 꺼내 보여 준다. 버리고 새로 받는 것이 아니라 숨겼다 꺼내는 것이다.
| 여러 페이지 방식 | 한 페이지 방식 | |
|---|---|---|
| 이동할 때 | 서버에 새 문서 요청 | 받아 둔 화면을 꺼냄 |
| 체감 | 한 번 깜빡임 | 즉시 전환 |
| 검색 엔진 | 읽기 쉬움 | 주의 필요 |
| 첫 로딩 | 가벼움 | 무거울 수 있음 |
그래서 생긴 문제와 그 해법
한 페이지 방식에는 대가가 있었다. 화면을 브라우저에서 그리면, 검색 엔진이 방문했을 때 JavaScript가 실행되기 전의 빈 화면을 볼 수 있다.
이 문제는 예전만큼 심각하지 않다. 검색 엔진들이 JavaScript를 실행해 결과를 읽게 된 지 오래됐다. 다만 링크를 공유했을 때 뜨는 미리보기 카드처럼, 여전히 서버가 미리 그려 둔 내용을 필요로 하는 자리가 남아 있다.
그래서 서버에서 먼저 그려 보내는 방식이 함께 쓰인다. 서버 사이드 렌더링이라고 부른다. 완성된 화면을 서버에서 만들어 보내고, 그다음부터는 브라우저가 이어받아 부드럽게 움직인다.
이 둘을 한 프로젝트 안에서 화면별로 골라 쓰게 해 주는 것이 Next.js다. 첫 화면과 공유되는 글 페이지는 서버에서 그리고, 로그인 후 대시보드는 브라우저에서 그리는 식으로 나눌 수 있다.
프레임워크라고 부르는 진짜 이유
Next.js를 프레임워크라고 부르는 이유는 렌더링 방식 때문만이 아니다. 지금 웹 개발이 어떻게 이루어지는지와 관련이 있다.
요즘 사이트를 만들 때 모든 것을 처음부터 짜지 않는다. 로그인, 달력, 영상 재생기처럼 많은 사람이 반복해서 쓰는 기능은 이미 누군가 만들어 두었다. 그렇게 만들어 둔 묶음을 패키지라고 하고, 내려받는 창고가 npm이다.
그래서 내 프로젝트는 남이 만든 부품 더미와 내가 쓴 코드의 조합이 된다. 문제는 이 상태 그대로는 브라우저가 못 읽는다는 것이다. 브라우저가 읽는 것은 2편에서 본 HTML·CSS·JavaScript 셋뿐이다.
그 변환을 해 주는 과정이 빌드다. 부품과 내 코드를 합쳐 쪼개고 묶어 브라우저가 읽을 수 있는 형태로 바꾼다. 배포가 몇 분 걸리는 건 대부분 이 빌드 시간이고, 정해진 규칙대로 코드를 쓰면 나머지를 대신 해 주기 때문에 프레임워크라고 부른다.
npm 에서 받은 부품들
+ → 빌드 → 브라우저가 읽을 수 있는
내가 쓴 소스 코드 HTML · CSS · JavaScript
배포에 걸리는 몇 분은 대부분 이 화살표 구간이다