EC2를 사용할때 생기는 다양한 문제

1. 로컬에선 잘 되는데, 서버에선 안 된다

Next.js를 처음 EC2에 올리면 대부분 이 단계에서 막힌다.

• npm run dev → 로컬에선 정상
• EC2에서 실행 → 에러 또는 접속 불가

📌 이유는 단순하다

로컬 환경 ≠ 서버 환경

서버에는 기본적으로 아무것도 없다.

• Node.js 없음
• 환경변수 없음
• 포트 열려 있지 않음
• HTTPS 없음

👉 “잘 된다”의 기준이 달라진다

2. 환경 변수 관리가 생각보다 어렵다

로컬에서는

NEXT_PUBLIC_API_URL=http://localhost:8080

EC2에서는?

• .env 파일 직접 관리
• GitHub에 올리면 안 됨
• 배포할 때마다 신경 써야 함

특히 Next.js는

• NEXT_PUBLIC_ → 브라우저 노출
• 서버 전용 변수 → Node 실행 환경

이 구분을 서버 배포 후에야 체감하게 된다.

👉 환경 변수 실수 = 빌드 실패 / 런타임 에러

3. 포트 문제 (진짜 자주 터짐)

Next.js 기본 포트는 3000.

하지만 EC2에서는:

• 보안 그룹에서 3000 포트 열어야 함
• 방화벽 설정 확인
• 이미 다른 프로세스가 쓰고 있을 수도 있음

그리고 실무에서는 보통 이렇게 구성함:

80 / 443 (Nginx)
   ↓
3000 (Next.js)

👉 결국 Nginx 같은 리버스 프록시를 써야 함

👉 이때부터 배포 난이도가 확 올라감

4. HTTPS 설정이 기본이 아니다

Vercel에선 자동인데, EC2는 다르다.

EC2에 올리면 기본 상태는:

• HTTP only
• 브라우저에서 “안전하지 않음” 경고

그래서 해야 할 것들:

• 도메인 연결
• SSL 인증서 발급 (Let’s Encrypt)
• 인증서 갱신 자동화

👉 Next.js 문제가 아니라 서버 문제지만

👉 Next.js 배포하면서 같이 떠안게 됨

5. 서버 재시작 = 서비스 중단

로컬에서는 새로 켜면 끝.

EC2에서는?

• 서버 재부팅
• 프로세스 종료
• 배포 중 서버 다운

그래서 필요한 것들:

• pm2 같은 프로세스 매니저
• 또는 Docker + restart 정책

👉 **“서버가 죽지 않게 유지하는 일”**이 생김

6. 빌드 & 실행 전략을 직접 정해야 한다

Next.js는 선택지가 많다.

• next dev
• next build + next start
• standalone
• output: export

EC2에선 보통:

npm run build
npm run start

하지만 여기서도 문제가 생긴다.

• 빌드 시간이 김
• 메모리 부족으로 빌드 실패
• 서버 스펙에 따라 속도 차이

👉 서버 사양이 곧 배포 안정성

7. 로그 확인이 불편하다

Vercel:

• 에러 로그 바로 UI로 확인

EC2:

• 터미널
• pm2 logs
• journalctl
• 직접 로그 파일 열기

👉 에러 원인 찾는 데 시간이 더 걸림

8. 자동 배포(CI/CD)를 안 하면 지옥이다

수동 배포 흐름:

로컬에서 빌드
→ git push
→ EC2 접속
→ git pull
→ npm install
→ build
→ restart

몇 번만 해도 느낀다.

“이걸 매번 수동으로 할 건 아니잖아…”

그래서 결국:

• GitHub Actions
• Jenkins
• Docker 기반 배포

👉 EC2 + Next.js = CI/CD 필수

9. 그래서 사람들이 Vercel을 쓰는 이유

정리해보면:

👉 편의성 vs 자유도의 차이

10. 그래도 EC2에 Next.js를 올리는 이유

문제가 많아도 EC2를 쓰는 이유는 분명하다.

• 백엔드(Spring, Node)와 같은 서버에 배포
• 비용 최적화
• 인프라 구조 이해
• 커스텀 설정 필요

👉 “왜 힘든지 아는 것 자체가 실력”

마무리

Next.js는 프레임워크 자체는 편하지만

EC2에 올리는 순간부터는 인프라 영역이다.

• Next.js 문제 ❌
• 서버 운영 문제 ⭕

그래서 EC2 배포를 한 번이라도 해보면

배포, 서버, 인프라 개념이 한 번에 정리된다.