← 전체 글로 돌아가기

Next.js

Next.js 앱 배포 후 첫 번째로 볼 로그들

배포 직후 문제를 찾으려면, 빌드 로그와 런타임 로그를 순서대로 확인해야 한다. 초보자가 놓치기 쉬운 진단 포인트들을 정리했다.

Next.js 앱을 배포했는데 뭔가 이상하다면, 로컬에서 괜찮던 설정도 배포 환경에서는 다르게 작동할 수 있다. 이럴 때 가장 먼저 봐야 할 것들을 정리했다.

HTML head 섹션을 먼저 확인한다

검색 엔진 최적화나 SNS 공유 기능에 문제가 있으면, 브라우저에서 페이지 소스를 보거나 curl로 확인한다.

curl -s https://example.com | grep -Ei 'title|description|canonical|og:|twitter:'

canonical, OG 태그, title, description 같은 메타데이터가 제대로 렌더링되었는지 확인한다. 이 값들이 동적으로 생성된다면, 각 페이지마다 다르게 나타나야 한다.

빌드 경고 메시지를 살펴본다

배포 로그에서 빌드 경고(warning)가 있었는지 다시 확인한다. 경고는 에러는 아니지만, 나중에 런타임 문제로 이어질 수 있다.

npm run build

특히 리소스 로딩 실패, 타입 관련 경고, 성능 최적화 제안 같은 메시지를 주의 깊게 본다.

라우팅이 제대로 작동하는지 확인한다

Dynamic Routes를 사용한다면, 각 경로에서 메타데이터와 콘텐츠가 정확하게 로드되는지 확인한다. [id].tsx 같은 동적 라우트는 로컬 개발에서 놓친 경로가 배포 환경에서 드러날 수 있다.

환경 변수를 다시 확인한다

로컬 .env 파일과 배포 환경의 환경 변수 설정이 일치하는지 확인한다. API 엔드포인트, 데이터베이스 URL, 인증 정보 같은 중요한 값이 제대로 전달되는지 검증한다.

API 요청과 응답이 정상인지 본다

배포 후 API 호출이 실패하면 보통 타임아웃이나 인증 오류가 발생한다. 브라우저 DevTools의 Network 탭에서 API 요청을 직접 살펴본다.

빌드 시간과 번들 크기를 확인한다

프로덕션 빌드가 예상보다 느리거나 번들이 너무 크면, 불필요한 의존성이 포함되었을 수 있다. next/bundle-analyzer 같은 도구를 사용해서 번들 구성을 분석한다.

배포 직후의 확인은 문제를 조기에 발견하는 가장 효과적인 방법이다.