자동화 slecs

배포 스크립트에서 광고 빌드 동기화 단계 누락을 뒤늦게 복구

목차

배포 스크립트에서 build-ads.js 동기화가 누락된 걸 뒤늦게 발견했다.

배경: 왜 이 단계가 빠져 있었나

publish.sh는 서비스 배포 전 필요한 빌드·동기화 작업을 순서대로 실행하는 스크립트다. 그런데 어느 시점부터 build-ads.js에 대한 자동 동기화 단계가 누락된 채로 운영되고 있었다. 이 파일이 언제부터 파이프라인에서 빠졌는지 바로 추적하기 어려웠는데, 아마도 스크립트를 리팩터링하거나 다른 단계를 추가하는 과정에서 슬쩍 빠진 게 아닐까 싶다.

배포 스크립트가 이런 식으로 조금씩 어긋나는 건 생각보다 자주 있는 일이다. 각자 필요한 단계를 추가하다 보면 전체 흐름을 한눈에 파악하기 어려워지고, "이건 당연히 들어가 있겠지"라고 암묵적으로 믿는 단계가 실제로는 빠져 있는 경우가 생긴다. 팀이 커질수록 이런 암묵적 지식이 위험하다.

무엇을 고쳤나

publish.shbuild-ads.js 자동 동기화 단계를 명시적으로 추가했다. 변경 자체는 한 파일, 아마 몇 줄 수준이었을 것이다. 코드 규모로만 보면 핀포인트 수정이지만, 이 한 줄이 빠져 있을 때의 영향은 작지 않다.

# publish.sh — 수정 전 (단계 누락 상태 예시)
run_step "build core"
# build-ads.js 동기화 없음
run_step "deploy"

# publish.sh — 수정 후
run_step "build core"
run_step "sync build-ads.js"   # 자동 동기화 단계 추가
run_step "deploy"

이런 류의 누락은 테스트 환경에서는 잘 안 잡힌다. 로컬이나 스테이징에서는 이미 동기화된 상태로 돌아가고 있어서 문제가 없어 보이다가, 실제 배포 파이프라인에서 "왜 반영이 안 되지?"라는 물음이 나올 때 비로소 발견되는 패턴이다.

배포 스크립트를 대하는 태도에 대해

관점 놓치기 쉬운 함정
단계 누락 리팩터링·추가 작업 중 기존 단계가 슬쩍 빠짐
암묵적 의존 "어디선가 처리되겠지"라는 가정
변경 추적 publish.sh 변경 이력이 PR 리뷰에서 가볍게 넘어감
검증 부재 dry-run 또는 단계별 로그 확인 없이 운영 적용

팀장 입장에서 이번 건이 아쉬웠던 이유는 코드 자체보다 프로세스 때문이다. publish.sh 같은 배포 스크립트 변경은 기능 코드보다 훨씬 꼼꼼하게 리뷰해야 한다. 기능 코드는 잘못되면 롤백하면 그만이지만, 배포 스크립트가 틀리면 롤백 자체가 불완전해질 수 있다.

코드리뷰 때 배포 관련 파일(*.sh, CI 설정, Dockerfile 등)은 변경 라인이 적더라도 전체 흐름을 한 번 소리 내어 읽어보는 습관을 팀 내에 심어두는 게 맞다. 한 줄짜리 diff가 가장 위험한 diff일 수 있다는 걸 이번에 다시 한 번 체감했다.

멘토링할 때도 자주 하는 말인데, 배포 스크립트는 "작동하는 것"과 "올바르게 작동하는 것" 사이의 간극이 가장 조용하게 벌어지는 영역이다. 지표 이상이 없어도 무언가가 조용히 누락되고 있을 수 있다. 이번 build-ads.js 동기화 단계 추가는 그 간극을 하나 메운 작업이었다.


다음엔 publish.sh 단계 목록을 주석으로 명세화해두거나, 단계별 체크섬 검증 로직을 붙이는 것도 검토해볼 만하다.


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

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

댓글 0

첫 댓글 달아줘.