Next.js에서 Docker 빌드 최적화하기

현대 웹 서비스에서의 빠른 배포와 효율적인 인프라 관리는 필수 요소입니다. 대규모 트래픽을 처리하거나 신속한 업데이트가 중요한 서비스는 경쟁력을 좌우합니다.

프론트엔드와 인프라 개발자 간의 지식 격차가 있으며, Frontend 개발자는 Docker의 멀티스테이지 빌드나 CI/CD 캐싱에 익숙하지 않고, 인프라 개발자는 Next.js의 standalone 빌드에 생소할 수 있습니다. 이 글에서는 두 영역 간의 간극을 좁히고, 배포 속도와 인프라 비용을 최적화하는 방법을 소개합니다.

Next.js standalone 모드로 Docker 빌드 최적화하기

Next.js 프로젝트는 파일 용량이 커지기 쉬운데, standalone 모드를 활용하면 웹 애플리케이션 실행에 필요한 최소한의 파일로 경량화된 빌드를 만들 수 있습니다.

Next.js standalone이란?

standalone 모드는 output: ‘standalone’ 설정으로 활성화되며, 실행에 필요한 최소한의 코드만을 /standalone 폴더에 추출합니다.

standalone 최적화 방법

1. 불필요한 파일 제거

standalone 모드를 사용하면 실제 운영 환경에서 필요한 파일만 포함하여 Docker 이미지 크기를 줄일 수 있습니다.

2. node_modules 최적화

필요한 패키지만 포함되며, 개발 과정에서 사용된 불필요한 패키지는 제외됩니다.

최적화 결과:

• Docker 이미지 크기 감소
• 업로드 시 전송 속도 증가
• 컨테이너 시작 시간 단축

Next.js standalone 설정 예시

간단히 next.config.js 파일에 설정 후 next build 명령어를 실행하여 .next/standalone 디렉터리를 생성합니다.

standalone 모드로 작성된 Dockerfile을 최적화하여 실행 파일만 포함하도록 해야합니다.

Docker 멀티스테이지 빌드

Next.js standalone 빌드와 함께 Docker 멀티스테이지 빌드를 고려해야 합니다. 이를 통해 최종 이미지를 가볍고 안전하게 만들 수 있습니다.

멀티스테이지 빌드란?

모든 빌드 요소를 포함하여 커지지 않도록, 실행 환경에 필요한 파일만 최종 이미지로 전달합니다.

멀티스테이지 최적화 방법

1. 빌드 스테이지

소스 코드 컴파일 및 빌드 단계입니다.

2. 런타임 스테이지

실행에 꼭 필요한 파일만 복사해 사용합니다.

멀티스테이지 빌드 이점

1. 이미지 크기 최소화

최종 런타임 이미지는 실행에 필요한 파일만 담고 크기를 줄입니다.

2. 단계별 분리

빌드와 런타임 환경을 명확히 분리하여 최적 상태를 유지합니다.

3. 효율적인 캐시 전략

캐시 재사용 전략이 쉽고 배포 시간 단축에 기여합니다.

GitHub Actions와 Docker 캐시

GitHub Actions는 새로운 환경에서 워크플로를 실행하지만, Docker 레이어 캐시를 유지하지 못하는 한계가 있습니다. 해결책으로 Docker Buildx와 actions/cache를 조합하여 최적화할 수 있습니다.

• 의존성 설치와 빌드 단계를 명확히 분리하여 캐시 최적화
• 최종 이미지는 빌드 산출물만 포함
• Docker Buildx로 각 스테이지 별로 캐시 독립적 관리 가능

standalone vs 멀티스테이지 빌드

두 방식은 Docker 배포 최적화 목표가 같지만, 적용 방식과 역할이 다릅니다. standalone은 Next.js 프로젝트를 최적화하고, 멀티스테이지는 Docker의 애플리케이션 환경을 최적화합니다. 두 방법을 함께 사용하는 것이 가장 효과적입니다.

마치며

배포와 인프라 효율성은 현대 웹 서비스의 핵심입니다. 프론트엔드와 인프라 개발자가 서로의 기술을 이해하고, 최적화된 환경을 통해 배포 효율성을 높일 수 있습니다.

지금 팀의 빌드와 배포 프로세스를 점검하고, Next.js standalone 모드와 Docker 멀티스테이지 빌드로 최적화를 실천해 보세요.