웹사이트 배포 자동화 — Git Push부터 프로덕션 반영까지
코드를 수정하고, 커밋하고, 서버에 접속해서 pull 받고, 빌드하고, PM2 재시작하고... 매번 이 과정을 반복하면 시간도 아깝고 실수가 생기기 마련입니다.셸 스크립트 하나로 이 과정을 자동화하면 배포가 명령어 한 줄로 끝납니다. CI/CD 도구 없이도 충분히 안정적인 배포 파이프라인을 구축하는 방법을 정리했습니다.
1줄
배포 명령어
30초
배포 소요 시간
즉시
롤백 복구
0원
도구 비용
1배포 파이프라인 설계
배포 파이프라인의 핵심은 "반복 가능한 자동화"입니다. 사람이 직접 하면 실수가 생기고, 실수가 생기면 장애가 됩니다. 배포 과정을 단계별로 정의하고 스크립트로 만들어야 합니다.
배포 파이프라인 흐름
개발 PC에서 코드 수정 → git commit → git push
프로덕션 서버에서 git pull (또는 webhook으로 자동 트리거)
의존성 설치: npm ci (clean install)
빌드: npm run build (Next.js .next 폴더 생성)
PM2 reload (무중단 배포)
배포 결과 확인 및 알림
npm install 대신 npm ci를 쓰세요
npm ci는 package-lock.json을 기준으로 정확한 버전의 패키지를 설치합니다. npm install과 달리 lock 파일을 수정하지 않아서 개발 환경과 프로덕션 환경의 패키지 버전이 항상 동일하게 유지됩니다.
2배포 셸 스크립트 작성
아래 스크립트는 실제로 사용하는 배포 스크립트를 정리한 것입니다. 에러가 발생하면 즉시 중단하고, 각 단계의 성공/실패를 출력합니다.
deploy.sh
#!/bin/bash set -e # 에러 발생 시 즉시 중단 APP_DIR="/home/deploy/my-app" BACKUP_DIR="/home/deploy/backups" TIMESTAMP=$(date +%Y%m%d_%H%M%S) echo "=== 배포 시작: $TIMESTAMP ===" # 1. 이전 빌드 백업 echo "[1/5] 이전 빌드 백업..." mkdir -p $BACKUP_DIR if [ -d "$APP_DIR/.next" ]; then cp -r "$APP_DIR/.next" "$BACKUP_DIR/.next_$TIMESTAMP" fi # 2. 최신 코드 가져오기 echo "[2/5] Git pull..." cd $APP_DIR git pull origin main # 3. 의존성 설치 echo "[3/5] 패키지 설치..." npm ci # 4. 빌드 echo "[4/5] 빌드 중..." npm run build # 5. PM2 재시작 (무중단) echo "[5/5] PM2 reload..." pm2 reload my-app echo "=== 배포 완료: $(date +%H:%M:%S) ===" echo "소요 시간: $SECONDS초"
# 배포 실행
# 실행 권한 부여 chmod +x deploy.sh # 배포 실행 ./deploy.sh # 또는 원격에서 SSH로 배포 ssh deploy-server "cd /home/deploy/my-app && ./deploy.sh"
3롤백 전략
배포가 실패했을 때 빠르게 이전 버전으로 돌아갈 수 있어야 합니다. 빌드 결과물을 백업해두고, 롤백 스크립트를 미리 준비해놓으면 장애 시간을 최소화할 수 있습니다.
rollback.sh
#!/bin/bash set -e APP_DIR="/home/deploy/my-app" BACKUP_DIR="/home/deploy/backups" # 최신 백업 찾기 LATEST_BACKUP=$(ls -t $BACKUP_DIR/.next_* -d 2>/dev/null | head -1) if [ -z "$LATEST_BACKUP" ]; then echo "백업 파일이 없습니다." exit 1 fi echo "롤백 대상: $LATEST_BACKUP" # .next 교체 rm -rf "$APP_DIR/.next" cp -r "$LATEST_BACKUP" "$APP_DIR/.next" # PM2 재시작 pm2 reload my-app echo "롤백 완료: $(date +%H:%M:%S)"
| 롤백 방식 | 복구 시간 | 장점 | 단점 |
|---|---|---|---|
| 빌드 백업 교체 | 5초 | 빌드 과정 불필요 | 디스크 사용량 증가 |
| git revert + rebuild | 2~5분 | Git 이력 추적 가능 | 빌드 시간 소요 |
| Docker 이미지 교체 | 10~30초 | 완벽한 환경 복원 | Docker 인프라 필요 |
백업은 최소 3개를 유지하세요
이전 빌드 백업을 최소 3개는 보관해야 합니다. 직전 배포뿐 아니라 그 이전 버전으로도 돌아갈 수 있어야 합니다. 오래된 백업은 자동으로 삭제하는 로직을 넣어두면 디스크 관리도 편합니다.
4환경변수 관리
환경변수는 절대 Git에 커밋하면 안 됩니다. .env 파일은 서버에 직접 생성하고 관리해야 합니다. .gitignore에 .env를 반드시 추가하세요.
.gitignore — 환경변수 파일 제외
# 환경변수 파일 제외 (필수) .env .env.local .env.production .env.*.local
.env.example — Git에 포함하는 템플릿
# .env.example (이것만 Git에 커밋) # 실제 값은 서버에서 .env 파일에 직접 입력 DATABASE_URL= AUTH_SECRET= NEXT_PUBLIC_SITE_URL=
.env가 Git에 올라갔다면 즉시 시크릿을 변경하세요
실수로 .env를 커밋했다면, git에서 삭제하는 것만으로는 부족합니다. 커밋 이력에 남아 있기 때문에 API 키, DB 비밀번호 등 모든 시크릿을 즉시 변경해야 합니다.
5다중 서버 동기화
서버가 2대 이상인 경우, 배포 스크립트가 모든 서버에 순차적으로 배포해야 합니다. 한 서버에서 배포가 실패하면 나머지 서버의 배포도 중단하는 안전 장치가 필요합니다.
deploy-all.sh — 다중 서버 배포
#!/bin/bash
set -e
SERVERS=("server1" "server2")
DEPLOY_SCRIPT="/home/deploy/my-app/deploy.sh"
for server in "${SERVERS[@]}"; do
echo "=== $server 배포 시작 ==="
ssh $server "bash $DEPLOY_SCRIPT"
if [ $? -ne 0 ]; then
echo "ERROR: $server 배포 실패. 중단합니다."
exit 1
fi
echo "=== $server 배포 완료 ==="
done
echo "전체 서버 배포 완료"| 동기화 방식 | 적합한 경우 | 주의점 |
|---|---|---|
| 서버별 git pull + build | 서버 수가 적을 때 | 빌드 시간이 서버 수만큼 |
| 빌드 서버에서 빌드 → rsync | 빌드 시간이 긴 앱 | 빌드 서버 환경 일치 필요 |
| Docker 이미지 배포 | 대규모 서비스 | Docker 인프라 구축 비용 |
6배포 후 모니터링
배포가 끝났다고 안심할 수 없습니다. 배포 직후에는 반드시 서비스 상태를 확인해야 합니다. 사이트 접속 확인, PM2 상태 확인, 에러 로그 체크는 배포 프로세스의 일부입니다. Grafana + Prometheus 통합 모니터링으로 배포 후 서버 상태를 실시간 감시할 수 있습니다.
# 배포 후 확인 명령어
# 1. PM2 상태 확인 (재시작 횟수, 메모리 등)
pm2 status
# 2. 최근 에러 로그 확인
pm2 logs my-app --err --lines 20
# 3. HTTP 상태 코드 확인
curl -s -o /dev/null -w "%{http_code}" https://example.com
# 4. 응답 시간 측정
curl -s -o /dev/null -w "응답시간: %{time_total}s\n" https://example.com배포 결과를 알림으로 받으세요
배포 스크립트 마지막에 Slack webhook이나 Discord webhook으로 결과를 전송하면, 팀원 모두가 배포 상태를 실시간으로 파악할 수 있습니다. 배포 성공/실패, 소요 시간, 배포자 정보를 포함하면 좋습니다.
요약 체크리스트
배포 자동화 핵심 요약
- ✓배포 스크립트를 작성하여 수동 작업을 제거한다
- ✓npm ci를 사용하여 패키지 버전 일관성을 보장한다
- ✓빌드 백업을 보관하여 즉시 롤백할 수 있게 한다
- ✓.env 파일은 절대 Git에 커밋하지 않는다
- ✓다중 서버는 순차 배포하고 실패 시 자동 중단한다
- ✓배포 후 상태 확인과 알림을 자동화한다
본 글의 배포 스크립트는 예시 목적으로 작성되었으며, 실제 환경에 맞게 수정이 필요합니다. 특히 보안 관련 설정(SSH 키, 환경변수 등)은 각 조직의 보안 정책에 따라 구성하시기 바랍니다. 본 콘텐츠의 비상업적 공유는 자유이나, 상업적 이용 시 문의 페이지를 통해 연락 바랍니다.
배포 자동화를 구축하고 싶으신가요?
Treeru는 Git 기반 자동 배포 파이프라인을 설계하고 구축해 드립니다. 롤백, 모니터링, 알림까지 포함된 완벽한 배포 환경을 상담받으세요.
배포 자동화 상담 신청댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
다중 서버 동기화 부분이 실전적입니다. rsync 대신 git pull 방식을 쓰는 이유와 장단점을 잘 설명해주셨네요.
환경변수 관리 부분에서 .env 파일을 Git에 넣지 않고 서버에 직접 관리하라는 팁이 중요한 것 같아요. 실수로 올린 적 있거든요...
롤백 전략이 특히 유용했어요. 이전 빌드를 보관해두고 심볼릭 링크로 전환하는 방식이 간단하면서도 효과적이네요.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.