광고 빌드 의존성 자동 설치를 공유 헬퍼로 분리해 배포 스크립트 안정화

publish.sh 에서 빌드 의존성 자동 설치 로직을 공유 헬퍼로 뽑아내는 수정을 했다.

배경 — "왜 지금 이게 필요했나"

배포 자동화 스크립트를 손댄 이유는 단순했다. build-ads 노드 의존성이 있는 환경에서 publish 파이프라인이 돌 때, 해당 deps 가 설치되어 있지 않으면 그냥 조용히 실패하거나 엉뚱한 에러를 뱉는 상황이 생겼다. 팀원이 로컬에서 처음 세팅할 때나, CI 환경이 클린 상태일 때 특히 자주 터졌다.

문제는 "왜 설치가 안 됐냐"가 아니라 "왜 스크립트가 이걸 보장하지 않았냐"였다. 배포 스크립트는 의존성이 이미 있다고 가정 하고 있었고, 그 가정이 깨지면 디버깅에 시간이 많이 낭비된다. 팀 리드 입장에서 이런 암묵적 전제조건은 최대한 빨리 제거하는 게 맞다고 봤다.

작업 내용 — shared helper 로 뽑아낸 이유

단순히 npm install 한 줄 추가하는 방식으로도 해결은 됐을 것이다. 근데 그렇게 하지 않고 공유 헬퍼(shared helper) 로 분리한 데는 이유가 있다.

# Before — publish.sh 안에 직접 박혀 있거나, 아예 없는 형태
# (의존성 설치 없이 빌드 커맨드만 호출)
build_ads

# After — 공유 헬퍼를 통해 deps 보장 후 실행
install_build_ads_deps   # shared helper 함수 호출
build_ads

publish.sh 만 쓰는 게 아니라 다른 스크립트들도 같은 build-ads deps 를 필요로 할 가능성이 높다. 그때마다 install 로직을 복붙하게 되면 나중에 deps 버전이 바뀌거나 설치 방식이 달라질 때 수정 포인트가 흩어진다. shared helper 하나만 고치면 되는 구조가 훨씬 낫다.

배포 스크립트에서 의존성 보장이 중요한 이유

배포/빌드 스크립트는 "잘 동작하는 환경"에서만 테스트되는 경향이 있다. 작성한 사람 로컬에는 이미 다 깔려 있으니까. 근데 CI/CD 환경은 매번 클린 컨테이너에서 시작하거나, 새 팀원이 온보딩하면서 처음 실행하는 경우가 반드시 생긴다.

이때 스크립트가 "내가 필요한 건 내가 챙긴다" 원칙을 지키지 않으면 아래 같은 상황이 반복된다.

• 신입이나 새 팀원이 스크립트 실행 → 이해하기 어려운 에러 → 팀 리드한테 질문
• CI 파이프라인 간헐적 실패 → 원인 추적에 시간 소모
• "그거 먼저 설치해야 해" 같은 암묵지가 슬랙이나 위키에만 살아있는 상태

스크립트 자체가 self-contained 하게 동작하도록 만들어두면 이 문제가 사라진다. 온보딩 비용도 낮아지고, "왜 나는 안 되냐" 류의 환경 디버깅도 줄어든다.

코드리뷰에서도 이런 부분을 항상 체크하는 편이다. 스크립트가 전제조건을 주석에만 기록해두고 있으면 "이걸 자동화할 수 있지 않냐"고 코멘트를 남긴다. 주석은 읽히지 않을 때가 많고, 코드는 실행되기 때문이다.

변경 파일이 publish.sh 하나지만 영향 범위는 더 넓다. 이 헬퍼를 앞으로 다른 스크립트들이 참조하게 되면 deps 관리의 단일 진입점이 생기는 거라서, 이번 수정이 그 토대를 깐 셈이다.

다음 단계는 자연스럽게 다른 빌드 관련 스크립트들도 같은 헬퍼를 바라보도록 통일하는 것.

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

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

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