Next.js 운영 Do Not Do List¶
운영 서버(Production Server) 환경에서
Next.js 서비스를 운영할 때 절대 사용해서는 안 되는 패턴을 정리한 문서임.
Node.js 운영 Do Not Do List를 전제로 하며,
그 위에서 Next.js의 역할 오해, 프레임워크 특성 오인으로 인해
실제 운영 환경에서 반복적으로 발생하는 사고 패턴만을 추가로 기록함.
대안을 제시하지 않음
“왜 이걸 하면 반드시 사고가 나는가”를 명확히 남기는 것이 목적임
0. 전제 (중요)¶
다음 항목들은 이미 Node.js 운영 금기로 정의되어 있으며,
Next.js에서도 동일하게 적용됨.
- nvm 운영 서버 사용
/var/www에서 npm install/var/www에서 개발 작업- node / next 직접 실행
- PM2 없이 서비스 운영
- Node.js / Next.js 포트 외부 직접 노출
👉 본 문서에서는 위 항목들을 반복 설명하지 않음
👉 위 항목을 위반하면 Next.js 여부와 무관하게 운영 실패
1. Next.js를 “백엔드 서버”로 취급¶
잘못된 사고¶
- “Next.js도 서버니까 API 서버 역할까지 하면 되지”
- “굳이 Express를 둘 필요가 있나”
- “인증, 권한, DB 접근도 Next.js에서 처리”
왜 문제인가¶
- Next.js 서버는 프론트엔드 런타임
- 요청 생명주기, 상태 관리, 장애 허용 범위가 백엔드 서버와 완전히 다름
- 트래픽 증가 시:
- SSR 지연
- 메모리 급증
- 전체 페이지 렌더링 장애로 직결
운영 기준¶
Next.js는 UI 렌더링 런타임이지, 비즈니스 서버가 아님
2. Next.js를 Gateway / Reverse Proxy처럼 사용¶
잘못된 패턴¶
- TLS 처리
- Rate limit
- IP 차단
- 인증 우회 제어
- 외부 서비스 직접 프록시
왜 문제인가¶
- Next.js에는:
- Connection 관리 기능 없음
- 공격 방어 기능 없음
- 네트워크 계층 제어 기능 없음
- 동일 기능을 Nginx에서 이미 제공함
실제 발생하는 사고¶
- 대량 요청 시 Next.js 프로세스 다운
- 인증 우회 경로 생성
- 프론트엔드 장애 = 전체 서비스 장애
운영 기준¶
Next.js 앞에는 반드시 Nginx가 존재해야 함
Next.js는 Gateway가 아님
3. Next.js 서버를 외부에 직접 노출¶
next start -p 3000
firewall-cmd --add-port=3000/tcp
왜 문제인가¶
- TLS 없음
- Rate limit 없음
- 인증/차단 없음
- 스캔 공격 즉시 노출
자주 나오는 오해¶
- “어차피 SSR 서버니까 괜찮다”
- “프론트엔드 서버라 공격 대상 아니다”
👉 완전히 틀림
운영 기준¶
외부 트래픽은 Nginx만 수신
Next.js는 localhost 또는 내부 네트워크에서만 listen
4. build 없이 next start 실행¶
잘못된 패턴¶
next start
- build 단계 생략
.next상태 불명확- 서버마다 결과 불일치
왜 문제인가¶
- Next.js는 빌드 산출물 기반 프레임워크
- build 결과가 곧 “실행 코드”
- 빌드 없이 실행하면:
- 캐시 불일치
- 페이지 누락
- 런타임 에러
운영 기준¶
Next.js는 반드시 build → 배포 → start 순서
5. next dev를 운영 환경에서 사용¶
잘못된 패턴¶
NODE_ENV=production next dev
왜 문제인가¶
- Hot Reload 활성화
- 메모리 누수
- 예측 불가능한 코드 변경
- 성능 최적화 비활성
실제 사고¶
- “운영 중인데 코드가 바뀜”
- “갑자기 페이지 구조 깨짐”
- “서버 재시작 없이 상태 변경”
운영 기준¶
운영 서버에서 next dev 사용은 즉시 장애
6. PM2 cluster + Next.js 구조 오해¶
잘못된 기대¶
- “cluster면 무조건 빠르다”
- “SSR은 많이 띄울수록 좋다”
실제 문제¶
- SSR은 CPU/메모리 집약적
- 클러스터 수 증가 = 메모리 선형 증가
- 잘못 설정 시:
- OOM
- 랜덤 장애
- GC 폭증
운영 기준¶
PM2 cluster는 서버 스펙 기반으로 제한적으로 사용
무조건적인 scale out 금지
7. App Router / Server Component에 상태 저장¶
잘못된 패턴¶
- 전역 변수 사용
- 서버 컴포넌트에 캐시/상태 저장
- 요청 간 상태 공유 기대
왜 문제인가¶
- Next.js 서버는:
- stateless 전제
- 요청 단위 실행
- 클러스터/재시작 시:
- 상태 즉시 소실
- 예측 불가 동작
운영 기준¶
Next.js 서버는 상태를 가지지 않는다
8. Next.js 로그를 “운영 로그”로 오해¶
잘못된 사고¶
- console.log면 충분
- PM2 로그만 보면 된다
왜 문제인가¶
- SSR 오류
- hydration mismatch
- build/runtime 구분 불가
운영 기준¶
운영 로그의 기준은 Gateway(Nginx) + Backend
Next.js 로그는 보조 정보일 뿐
9. Next.js에 보안을 “구현”하려는 시도¶
잘못된 접근¶
- JWT 직접 검증
- CORS 정책 구현
- CSRF 대응 로직 작성
왜 문제인가¶
- 보안 로직 중복
- 버그 발생 시 프론트 장애
- 공격 표면 확대
운영 기준¶
보안은 Nginx + Backend의 책임
Next.js는 결과만 소비
10. 정리 (핵심)¶
- Next.js는 프론트엔드 런타임
- 서버라고 해서 서버의 책임을 지면 안 됨
- 대부분의 운영 사고는:
- “할 수 있다”와
- “해도 된다”를 구분하지 못해서 발생함
Next.js 운영의 핵심은
역할을 넘지 않는 것이다.