Next.js 운영 로그 (Winston) 설정 기준¶
Next.js 애플리케이션 운영 환경에서
Winston 기반 파일 로그를 왜 기본적으로 사용하지 않는지,
그리고 불가피하게 필요한 경우 어떤 기준을 따라야 하는지를 설명함.
Winston 설정 방법이나 코드 예제를 제공하지 않음.
“Next.js 운영 관점에서 로깅의 책임 범위”를 명확히 하는 것이 목적임.
1. 결론부터 정리¶
Next.js 운영 환경에서는 Winston 기반 파일 로그를 기본적으로 사용하지 않음
Next.js는 다음 전제를 기반으로 운영됨.
- Nginx 앞단에서 트래픽 제어
- PM2 기반 프로세스 관리
- stdout / stderr 로그 수집
- 중앙 로그 수집 또는 PM2 로그 로테이션 활용
즉,
Next.js는 “프론트엔드 애플리케이션 런타임”으로 취급하며
전통적인 백엔드 서버 수준의 파일 로그 관리 대상이 아님
2. Next.js에서 Winston이 기본적으로 불필요한 이유¶
2.1 책임 계층이 다름¶
Next.js 운영에서의 로그 책임 분리:
| 계층 | 책임 |
|---|---|
| Nginx | 접근 로그 / 에러 로그 |
| PM2 | 프로세스 로그 / stdout / stderr |
| Next.js | 애플리케이션 로직 결과 |
Next.js 자체는:
- 장기 파일 로그 관리 ❌
- 로그 로테이션 책임 ❌
- 로그 보관 정책 ❌
을 직접 가지지 않음.
2.2 PM2 + stdout 구조가 기본 전제¶
Next.js 운영 표준은 다음과 같음.
console.log,console.error사용- 로그는 stdout / stderr로 출력
- 수집 / 로테이션은 PM2가 담당
이 구조에서 Winston 파일 로그를 추가하면:
- 로그 저장 경로 이중화
- 로테이션 정책 중복
- 장애 분석 시 로그 분산
→ 운영 복잡도만 증가함.
3. Winston이 필요한 경우 (예외적 케이스)¶
아래 조건을 모두 또는 일부 만족하는 경우에만
Next.js에서 Winston 도입을 검토할 수 있음.
- Next.js를 BFF(Backend For Frontend) 로 사용
- 서버 액션 / API Route에 중요 비즈니스 로직 포함
- 장애 발생 시 장기 로그 보관이 필수
- 감사(Audit) 또는 규제 요건 존재
- 단순 프론트엔드 서버가 아닌 백엔드 성격으로 운영
이 시점부터는:
Next.js는 더 이상 “프론트엔드 서버”가 아니라
Node.js 백엔드 애플리케이션으로 취급됨
4. Winston을 사용하는 경우의 운영 기준¶
Next.js에서 Winston이 필요해지는 순간,
운영 기준은 Next.js 문서가 아니라 Node.js 운영 문서를 따른다.
필수 참조 문서¶
해당 문서에 정의된 다음 기준을 그대로 적용함.
- 파일 기반 로그 저장
- 로그 레벨 분리
- 일 단위 로테이션
- 고정된 로그 디렉터리
- PM2 실행 사용자 권한 기준
⚠️ Next.js 전용으로 축약하거나 단순화하지 않음
운영 기준은 Node.js 서버와 동일하게 적용함
5. 권장하지 않는 패턴 (주의)¶
다음과 같은 사용은 운영 기준 위반임.
- Next.js에 Winston만 “가볍게” 붙이는 경우
- 파일 로그는 남기되 로테이션 없는 구조
- PM2 로그 + Winston 로그 혼용
- 장애 분석 시 로그 위치가 분산되는 구조
“일부 로그만 파일로 남기자”는 발상은
운영 사고의 시작점임.
6. 운영 기준 요약¶
- Next.js 운영에서는 Winston이 기본값이 아님
- stdout / stderr + PM2 로그 구조가 표준
- Winston 도입 시
- Next.js 문서는 종료
- Node.js 운영 문서를 기준으로 전환
- 중간 단계는 존재하지 않음
Winston을 붙이는 순간
우리는 프론트엔드 서버를 운영하는 것이 아니라
Node.js 백엔드 서버를 운영하는 것이다.
7. 정리¶
- “쓰지 말라”는 문서가 아님
- “언제부터 책임이 바뀌는가”를 명확히 하는 문서임
- 이해 없이 Winston을 추가하면 반드시 운영 사고가 발생함
필요하면 쓴다.
하지만 쓰는 순간, 운영 기준도 함께 가져온다.