Next.js 동적 라우팅 관리자 페이지를 추가할 때 주의할 것

Next.js 앱에서 관리자 페이지처럼 동적으로 렌더링되는 페이지를 추가할 때 주의해야 할 점들이 있다. 로컬에서는 문제없지만 배포하면 캐시 때문에 문제가 생길 수 있기 때문이다.

동적 렌더링과 정적 생성의 차이

Next.js 13+ 에서는 페이지를 어떻게 렌더링할지 명시해야 한다:

• 정적 생성 (SSG): 빌드 시점에 HTML을 미리 생성
• 동적 렌더링 (SSR): 요청 시점에 HTML을 생성

관리자 페이지처럼 사용자별로 다른 내용을 보여야 한다면 동적 렌더링을 써야 한다.

npm run build

빌드 출력에서 관리자 페이지가 정말 동적으로 렌더링되는지(o 표시) 확인한다. 정적으로 표시되면 설정을 다시 봐야 한다.

캐싱 헤더 설정

동적 렌더링 페이지의 캐싱을 너무 길게 설정하면, 이전 사용자의 데이터가 다른 사용자에게 보일 수 있다. 관리자 페이지라면 캐싱을 하지 않거나 매우 짧게 설정해야 한다.

response 헤더에서 Cache-Control을 설정하자:

export const revalidate = 0; // 캐싱 안 함

권한 검증은 필수

동적으로 렌더링되는 관리자 페이지는 반드시 권한을 확인해야 한다. 클라이언트 사이드 권한 체크만 해서는 안 되고, 서버에서도 확인해야 한다.

권한이 없으면 501 또는 redirect로 대응하자.

성능 영향 미리 테스트

동적 렌더링 페이지가 많아지면 서버 부하가 늘어난다. 배포 전에 로컬에서 부하를 시뮬레이션해서 응답 시간을 확인하자.

# 여러 번 요청해서 응답 시간 측정
time curl -s https://example.com/admin

Page Router와 App Router에서 동적 렌더링 방식이 다르니, 사용 중인 라우터에 맞게 설정해야 한다.

로컬과 배포 환경의 차이

로컬에서는 빠르지만 배포 환경에서는 느릴 수 있다. 데이터베이스 조회, 외부 API 호출 등이 추가되면 더욱 그렇다.

# 배포 환경에서 빌드하고 프로덕션 모드로 실행
npm run build
npm run start

프로덕션 환경 그대로 로컬에서 테스트해야 정확한 성능을 판단할 수 있다.

설정 변경은 배포 후 모니터링

동적 렌더링 설정을 변경한 후에는 서버 로그와 모니터링을 강화해서 오류율이나 응답 시간이 올라가지 않는지 확인하자.

문제가 보이면 빠르게 롤백할 수 있도록 준비해두는 게 좋다.