배포 스크립트 누락된 SSR 프로세스 재시작 단계 추가

배포 스크립트에 SSR 서비스 재시작 단계가 빠져 있던 걸 뒤늦게 발견했다.

배경 — 왜 이게 문제였나

publish.sh는 프로젝트 배포를 한 번에 처리하는 셸 스크립트다. 코드 풀링, 의존성 설치, 빌드, 프로세스 교체까지 일련의 단계를 순서대로 실행하는 구조인데, 문제는 SSR 서비스 재시작 단계가 통째로 빠져 있었다는 것. 빌드 결과물은 교체됐는데 프로세스는 여전히 이전 번들을 물고 돌아가는 상황이었다.

CSR(클라이언트 사이드 렌더링) 위주 프로젝트였다면 정적 파일만 교체해도 다음 요청부터 새 코드가 서빙되니까 이런 실수가 바로 드러나지 않는다. 그런데 SSR은 다르다. 서버 프로세스 자체가 살아있는 상태에서 새 코드를 인식하려면 재시작이 명시적으로 필요하다. 이걸 빠뜨리면 배포 후에도 구 버전 HTML이 그대로 내려오고, 캐시가 없는 상황에서도 변경 사항이 반영되지 않는다.

실제로 배포 후 "왜 안 바뀌지?"를 반복하다 결국 수동으로 프로세스를 재시작하고 나서야 정상 동작을 확인했던 흐름이었을 것이다. 자동화 스크립트의 목적 자체가 이런 수동 작업을 없애는 것인데, 핵심 단계 하나가 누락된 채로 운영되고 있었던 셈이다.

작업 내용

변경 파일은 publish.sh 단 하나다. 통계도 따로 기록하지 않았는데, 이런 스크립트 수정은 라인 수가 적어도 영향 범위가 크다. 실제 추가된 내용은 SSR 서비스를 재시작하는 커맨드 한 줄 혹은 몇 줄이겠지만, 이 변경 이전과 이후의 배포 결과는 완전히 다르다.

일반적으로 SSR 서비스 재시작 단계를 스크립트에 추가할 때 고려할 패턴은 대략 이렇다:

# 빌드 완료 후 SSR 서비스 재시작
echo "[deploy] Restarting SSR service..."
pm2 restart ssr-app --update-env

# 또는 systemd 기반이라면
# sudo systemctl restart ssr-app

# 재시작 후 상태 확인
pm2 status ssr-app
echo "[deploy] SSR service restarted."

--update-env 옵션 같은 세부 플래그도 중요하다. 환경변수가 바뀐 배포라면 재시작만으로는 부족하고 환경 갱신도 함께 이루어져야 한다.

배포 스크립트 단계 체크리스트

이 표 기준으로 보면, 이번 fix는 SSR 프로세스 재시작이 누락된 채 운영되고 있었던 것을 채워 넣은 작업이다.

회고 — 팀 관점에서 이 fix의 의미

팀장 입장에서 이 커밋을 보면 두 가지 생각이 든다.

첫째, 배포 스크립트도 코드 리뷰 대상이다. publish.sh 같은 운영 스크립트는 "인프라 쪽 일"로 치부되어 리뷰가 느슨해지는 경우가 많다. 그런데 이 스크립트 한 줄이 배포의 정합성 전체를 좌우한다. 앞으로 운영 스크립트 변경은 반드시 리뷰 프로세스에 포함시켜야 한다.

둘째, 배포 후 검증 단계가 명시적으로 정의되어 있어야 한다. 재시작 커맨드를 추가하는 것도 중요하지만, 재시작 이후 실제로 새 코드가 서빙되는지 확인하는 스모크 테스트나 헬스체크 커맨드도 스크립트 말미에 붙어 있어야 한다. 지금 이 fix가 재시작 단계를 채워 넣은 것이라면, 다음 단계는 배포 완료 여부를 스크립트 안에서 자동으로 검증하는 흐름을 추가하는 것이다.

작은 fix지만, 이런 걸 발견하고 고치는 과정이 쌓여서 배포 신뢰도가 올라간다.

끝.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.