"파일 이름이 라우트를 만들고, 각 라우트 컴포넌트의 props가 그 주소의 계약을 드러내."
app 디렉터리의 역할
App Router에서는 app/page.tsx가 페이지를, layout.tsx가 공유 레이아웃을 정의해. app/posts/[id]/page.tsx 같은 동적 세그먼트는 주소의 id를 페이지 입력으로 연결하지. 로딩과 오류, 찾지 못한 항목을 보여 주는 UI도 정해진 파일 경계에 둔다.
규약 파일이 요구하는 내보내기 이름과 실행 환경은 일반 컴포넌트 파일과 다를 수 있어. 임의 이름을 추가하기 전에 해당 버전의 Next 타입 생성과 빌드 검사를 통과시켜.
비동기 라우트 props
현대 App Router의 페이지에서는 params와 searchParams가 Promise 형태로 전달되는 계약을 만나. 페이지를 async로 만들고 필요한 값을 await한 뒤, URL에서 온 문자열을 도메인 값으로 검증해.
id: string이라는 타입은 존재하거나 데이터베이스에 유효하다는 뜻이 아니야. 숫자 변환과 허용 값 검사, 없는 레코드 처리는 라우트 경계의 책임으로 남아.
데이터 캐시는 명시적으로 읽기
Next 15부터 fetch 요청은 기본적으로 캐시되지 않고 Next 16도 이 동작을 이어가. 캐시가 필요하면 cache: 'force-cache', next: { revalidate: n }, 또는 use cache 같은 명시적 정책을 골라.
서버 컴포넌트에서 외부 JSON을 받으면 반환 타입 주석만 붙이지 말고 런타임 검증을 거쳐. 빌드 성공 뒤에도 대표 동적 라우트, 오류 경로, 재검증 후 데이터 갱신을 배포 환경에서 시험해야 해.
params와 searchParams가 Promise인 변화는 Next 15 이상에서 들어왔어. 온라인의 예전 예시는 동기 props를 보여 줄 수 있으니 npx next --version과 해당 버전 문서를 함께 확인해야 해.