배포 빌드 시간이 자꾸 길어진다면

빌드 시간이 늘어나면 배포 파이프라인 전체가 느려진다. 사소한 최적화도 누적되면 상당한 시간 절약이 된다. 로컬에서 괜찮았던 설정이 배포 환경에서는 다르게 보일 수 있다.

재현 조건 파악하기

빌드가 느린 게 정말 최근에 시작된 건지, 아니면 항상 그런 건지 확인한다. 최근 변경사항을 git 로그로 보면서 어디서부터 느려졌는지 추적한다.

빌드 로그 분석

실제 빌드 시간을 측정한다. 전체 시간과 각 단계별 시간을 본다.

# 빌드 시간 측정
time npm run build

불필요한 의존성 제거

node_modules 크기가 커지면 번들링도 느려진다. 실제로 사용하지 않는 패키지가 있는지 확인하고 제거한다. npm ls 나 분석 도구로 의존성 트리를 본다.

빌드 설정 최적화

번들러 설정(webpack, esbuild, vite 등)에서:

1. 소스맵 생성 여부 (프로덕션에서는 필요 없을 수 있음)
2. 캐시 설정
3. 병렬 처리 옵션
4. 불필요한 플러그인 제거

캐시 활용

동일한 파일을 다시 빌드할 때는 캐시를 활용하면 시간이 크게 줄어든다. CI/CD 환경에서는 캐시 설정이 특히 중요하다.

배포 환경에서의 빌드

CI/CD 서버에서 빌드하는 시간과 로컬 개발 환경에서의 시간이 다를 수 있다. 서버의 CPU, 메모리, 디스크 속도가 모두 영향을 준다. 필요하면 병렬 빌드나 분산 빌드를 고려한다.

점진적 개선

한 번에 모든 걸 최적화하려고 하면 부작용이 생길 수 있다. 가장 효과가 큰 것부터 하나씩 적용하고, 각 단계에서 결과를 측정한다.

모니터링

빌드 시간을 정기적으로 기록한다. 추세를 보면 언제부터 느려지기 시작했는지 알 수 있다.

# 빌드 시간 로그 추가 (CI/CD 스크립트)
echo "Build time: $(date)" >> build-log.txt
time npm run build >> build-log.txt 2>&1

마지막 확인

최적화 전후로 실제 기능이 정상 동작하는지 테스트한다. 빌드 시간을 줄인다고 기능을 손상시키면 안 된다. 특히 프로덕션 빌드에서는 모든 테스트를 다시 실행해야 한다.

이런 최적화 작업이 반복되면 배포 파이프라인이 점점 효율적으로 변한다. 작은 개선들이 모이면 상당한 시간을 절약할 수 있다.