사용자 검수 전 — “정적·동적”이라는 말은 경로의 모양에도, 페이지를 만드는 시점에도 쓰인다. 동적 주소를 미리 생성할 수도 있으므로 두 축을 섞지 않고 각각 읽는다.
§ 00 · 라우팅 — URL을 화면에 연결한다
라우팅은 브라우저의 URL을 어떤 화면과 연결할지 정하는 일이다. /about처럼 주소 조각이 그대로 정해진 경로는 고정 경로다. /products/42처럼 일부 값이 페이지마다 달라지는 경로는 동적 세그먼트를 사용해 하나의 규칙으로 여러 URL을 처리한다.
Next.js App Router에서는 폴더가 URL 세그먼트를 만들고, page 파일이 그 경로에서 보일 UI를 만든다. products/[id]/page는 /products/42와 /products/99를 같은 페이지 규칙으로 받으며, id 값은 params로 읽는다.
§ 01 · 정적 라우트와 동적 라우트
정적 라우트는 /about, /pricing처럼 경로 조각이 고정된다. 동적 라우트는 [id]나 [slug]처럼 이름 붙인 자리에 실제 URL 값을 받아 상품·글·사용자처럼 데이터에 따라 여러 페이지를 표현한다. 여기서 동적이라는 말은 주소 규칙의 일부가 변수라는 뜻이며, 이 구분을 흔히 정적 라우팅과 동적 라우팅이라고 부른다.
폴더를 중첩하면 URL도 중첩된다. /shop/[category]/[product]처럼 동적 세그먼트를 여러 개 둘 수 있고, catch-all 세그먼트는 뒤에 이어지는 여러 조각을 한 번에 받는다. 동적 값을 그대로 신뢰하지 말고 존재 여부와 형식을 검사해 잘못된 주소는 404로 보낸다.
§ 02 · 이동해도 공통 화면은 남길 수 있다
Link는 애플리케이션 내부 경로로 이동할 때 사용하는 탐색 수단이다. 일반 링크의 의미와 접근성을 유지하면서, 프레임워크가 미리 가져오기와 클라이언트 전환을 적용할 수 있게 한다. 버튼으로 주소를 바꾸기보다 문서 이동은 링크로 표현하는 것이 기본이다.
layout은 여러 하위 경로가 공유하는 UI를 감싸며 이동 중에도 유지될 수 있다. loading은 기다리는 동안의 화면, error는 오류 경계, not-found는 찾을 수 없는 경로의 응답을 맡는다. 라우팅은 주소 목록만이 아니라 이동·대기·실패까지 포함한 사용자 흐름이다.
§ 03 · 렌더링 — 화면을 언제, 어디서 만드는가
클라이언트 렌더링(CSR)은 브라우저가 JavaScript를 실행해 UI를 만든다. 서버 렌더링(SSR)은 요청을 받을 때 서버가 HTML을 만든다. 사전 렌더링은 빌드나 재검증 시점에 HTML을 미리 만들어 캐시한다. 한 애플리케이션 안에서도 경로와 컴포넌트에 따라 이 방식을 섞을 수 있다.
서버가 만든 HTML도 상호작용하려면 브라우저의 JavaScript가 이벤트를 연결해야 한다. 이 과정을 hydration이라 한다. 서버 렌더링과 클라이언트 전환은 서로 반대되는 선택지라기보다, 첫 화면은 서버에서 빠르게 보여 주고 이후 이동은 부드럽게 잇는 식으로 함께 사용된다.
§ 04 · 주소의 모양과 생성 시점을 섞지 않는다
동적 라우트라고 반드시 요청 때마다 서버에서 만들어지는 것은 아니다. 가능한 slug나 id 목록을 빌드 시 알 수 있다면 동적 세그먼트의 여러 페이지를 미리 생성할 수 있다. 반대로 URL이 고정돼 있어도 요청의 쿠키나 검색 조건을 읽어 매번 동적으로 렌더링할 수 있다.
따라서 “정적인가, 동적인가”라는 질문을 받으면 먼저 무엇을 묻는지 확인한다. URL 패턴을 묻는가, HTML 생성 시점을 묻는가. 이 두 질문을 분리하면 정적 라우팅과 동적 렌더링처럼 비슷한 단어가 한 문장에 나와도 혼동하지 않는다.
Read this note at sass.studio.