광고 빌드 의존성 자동화와 배포 스크립트 에러 리포팅 개선

publish.sh 한 파일에서 빌드 자동화 구멍 두 개를 동시에 막았다.

배경 — 왜 이게 문제였나

배포 스크립트에서 "가끔씩만" 터지는 버그는 제일 피곤한 종류다. 재현이 안 되니 대충 넘어가게 되고, 그러다 운 없는 날 CI가 통째로 빨간 불이 켜진다. 이번 케이스가 딱 그랬다. publish.sh가 실행되는 환경에 따라 build-ads 관련 노드 의존성이 설치되어 있을 수도 있고 없을 수도 있는 상황이었다. 로컬에서 잘 돌아가던 게 CI에서 터지거나, 새 팀원이 처음 셋업할 때 뜬금없이 실패하는 그 패턴.

이런 걸 방치하면 팀 전체 비용이 생각보다 크다. 누군가 빌드가 깨졌다고 슬랙에 메시지를 올리고, 원인 파악하는 데 30분 쓰고, "아 그 의존성 직접 설치해야 해요"라고 온보딩 문서에 주석 하나 달고 끝나는 사이클이 반복된다. 그 시간을 전부 합산하면 결코 작은 숫자가 아니다.

실제로 뭘 바꿨나

크게 두 갈래였다.

1. build-ads 노드 의존성 자동 설치

기존엔 스크립트가 해당 deps가 이미 있다고 전제하고 실행했다. 이번에 스크립트 내에서 직접 설치 단계를 추가해서, 실행 환경이 뭐든 deps가 보장되도록 만들었다. 대략 이런 구조다:

# before: 그냥 빌드 커맨드 호출
build_ads

# after: 실행 전 deps 보장
echo "[publish] Installing build-ads node dependencies..."
npm install --prefix ./build-ads
build_ads

중요한 건 멱등성(idempotency)이다. 이미 설치되어 있어도 다시 실행해도 안전하게 만드는 것. 배포 스크립트가 "한 번만 돌려야 하는 것"이 되면 그 순간 팀 전체의 발목을 잡는다.

2. 에러 리포팅 강화

이게 사실 더 중요한 부분이었다. 기존 스크립트가 중간에 실패해도 exit code가 0으로 끝나거나, 에러 메시지가 너무 뭉뚱그려져 있어서 어디서 터졌는지 파악하기 어려웠다. 바꾼 포인트:

에러 핸들링을 강화할 때 항상 드는 생각인데, 스크립트 에러는 "왜 틀렸나"보다 "어디서 틀렸나"를 빠르게 알려주는 게 우선이다. 특히 CI 환경에서는 로그가 전부이기 때문에, 에러 메시지 퀄리티가 곧 디버깅 속도다.

리뷰 관점에서 본 이번 변경

코드리뷰에서 이런 스크립트 변경은 종종 가볍게 넘어가는 경우가 많다. "그냥 배포 스크립트잖아요" 하고. 근데 나는 반대로 배포/빌드 스크립트 PR을 제일 꼼꼼히 보는 편이다. 이유는 단순하다 — 영향 범위가 팀 전체이고, 한번 잘못되면 롤백도 귀찮기 때문이다.

이번에 체크했던 항목들:

• 기존 동작 방식을 깨지 않는가 (기존에 의존성이 있는 환경에서도 안전한가)
• 에러 메시지가 사람이 읽을 수 있는 수준인가
• 스크립트 실행 권한이나 환경변수 의존이 암묵적으로 추가된 건 없는가
• CI 파이프라인에서 이 스크립트가 불리는 방식에 변화가 생기는가

마지막 포인트를 놓치는 경우가 많다. publish.sh 하나 바꿨는데 사실 CI yaml 쪽에서 이 스크립트를 어떻게 호출하는지, 환경변수가 어떻게 주입되는지도 같이 검토해야 한다. 파일은 하나지만 영향 반경은 훨씬 넓다.

결국 이번 작업의 핵심은 "사람이 기억하지 않아도 되게 만들기"였다. 의존성 설치를 개발자가 직접 챙겨야 한다는 암묵적 전제를 스크립트 안으로 끌어들이고, 에러가 나면 어디서 났는지 스크립트가 직접 말하게 만드는 것. 좋은 자동화란 사람의 판단이 개입하는 지점을 줄이는 방향으로 가야 한다.

끝.

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

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

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