NEXT LOGGING

Next 로깅 실행 위치 기준

Next.js 앱의 로그는 브라우저, Middleware, Route Handler, Server Component, background job에서 서로 다른 위치에 남는다. 요청 하나를 따라가기 위한 request id와 PII redaction, log drain, edge/runtime 제약을 함께 설계해야 운영에서 쓸 수 있다.

요청 추적 request id와 trace id로 middleware부터 handler까지 연결한다
기록 위치 client, route handler, server component의 책임을 분리한다
운영 전송 마스킹 후 log drain, APM, alert 기준으로 흘려보낸다
01

실행 위치 구분

브라우저 로그와 서버 로그, edge runtime 로그가 어디에 남는지 먼저 나눈다.

console 위치가 곧 수집 위치다
02

요청 ID 발급

Middleware나 진입점에서 request id를 만들고 응답 헤더와 서버 로그에 연결한다.

한 요청을 여러 로그에서 찾기 위한 키다
03

민감정보 제거

쿠키, Authorization, email, payment 값은 저장 전 마스킹하거나 제외한다.

디버깅 편의보다 유출 위험이 크다
04

오류 형태 통일

Route Handler와 Server Action 오류를 code, message, cause, status로 정리한다.

사용자 메시지와 내부 로그를 분리한다
05

수집 경로 확인

호스팅 환경의 stdout, log drain, APM, alert가 같은 필드를 받는지 확인한다.

로컬 로그는 운영 관측의 일부일 뿐이다
Middleware
요청 초입 request id, 인증 상태, rewrite/redirect 결정을 남기기 좋다.
edge 제약을 고려한다
Route Handler
API 경계 method, path, status, latency, validation 실패를 구조화한다.
body 원문 저장은 위험하다
Server Component
렌더 데이터 fetch 실패와 cache 상태를 서버 로그로 남길 수 있다.
사용자별 데이터 노출을 조심한다
Client
사용자 환경 브라우저 오류와 Web Vitals를 별도 수집으로 보낸다.
PII와 sampling을 설정한다

로그 실행 위치

요청 추적 한 오류 요청을 request id로 middleware부터 route handler까지 따라갈 수 있는지 본다.
마스킹 토큰과 개인정보가 로그 수집기에 남지 않는지 샘플을 확인한다.
알림 연결 오류율과 latency 기준이 알림으로 이어지는지 확인한다.