배포 스크립트에서 생성 책임만 분리해 단일 역할로 정리

배포 스크립트에서 "생성" 책임만 남기고 나머지를 쳐냈다.

publish.sh가 원래 어떤 모습이었냐면, 생성(generate)과 배포(publish) 단계가 한 파일에 뒤섞여 있었다. 스크립트 하나가 여러 역할을 맡고 있으면 처음엔 편해 보이는데, 시간이 지날수록 유지보수 비용이 슬금슬금 올라온다. 팀원이 "이거 어디서 뭘 하는 거예요?"라고 물어보는 순간이 오면, 그게 리팩터링 신호다.

왜 generate-only로 단순화했나

스크립트 하나가 두 가지 이상의 관심사를 가지면 테스트도 어렵고, 부분 실행도 어렵다. 예를 들어 "빌드 결과물만 확인하고 싶은데 배포까지 터져버리는" 상황이 생긴다. 이런 경우 대부분 임시방편으로 중간에 exit 0를 꽂거나, 스크립트 내부 플래그를 주석으로 껐다 켰다 하게 된다. 그게 쌓이면 스크립트 자체가 기술 부채가 된다.

이번 작업의 핵심 판단은 "생성과 배포는 분리되어야 한다" 는 거였다. 생성은 순수하게 결과물을 만들어내는 역할만 해야 하고, 그 결과물을 어디에 어떻게 올릴지는 별도 단계에서 결정하는 게 맞다. CI/CD 파이프라인에서도 이 원칙은 동일하게 적용된다. 보통 build → test → deploy 단계를 명시적으로 분리하는 이유가 여기 있다.

# 변경 전 (개념 예시)
# publish.sh 안에 generate + upload + notify 가 섞여 있던 구조
generate_artifacts
upload_to_remote
notify_slack

# 변경 후 (generate-only)
# publish.sh 는 이제 generate 역할만
generate_artifacts

단순히 줄을 지운 게 아니라, "이 파일이 무슨 책임을 갖는가"를 다시 정의한 작업이다.

작은 스크립트 리팩터링이 팀에 미치는 영향

이런 작업은 PR 올리면 보통 "별거 없네요" 반응이 나오기 쉽다. 실제 기능 변경이 없으니까. 근데 팀장 입장에서 이런 류의 리팩터링을 가볍게 보지 않는 이유가 있다.

• 온보딩 비용: 새 팀원이 스크립트를 처음 봤을 때 "이게 뭐 하는 거야?"를 5초 안에 답할 수 있어야 한다
• 사고 대응: 새벽에 배포 이슈 터졌을 때 스크립트 복잡도가 낮을수록 원인 파악 속도가 다르다
• 부분 실행 가능성: generate만 돌려서 결과 확인하고 싶은 케이스가 분명히 생긴다

리팩터링 타이밍 선택

이런 작업을 "언제 하느냐"가 항상 트레이드오프다. 기능 개발이 바쁠 때는 뒤로 밀리기 쉽고, 밀리다 보면 결국 더 큰 부채가 된다. 나는 이 작업이 funeral 관련 기능을 건드리는 시점에 같이 묶어서 처리하는 게 낫다고 판단했다. 해당 스크립트를 어차피 다시 들여다봐야 하는 타이밍이었고, 그 김에 손보는 게 효율적이다. "이왕 열어봤으면 정리하고 나온다" — 보이스카우트 룰이라고 부르기도 하는데, 작은 영역에서라도 일관성 있게 적용하면 코드베이스 전체 품질이 조금씩 올라간다.

변경 파일이 publish.sh 하나인 게 오히려 이 작업의 집중도를 잘 보여준다. 산만하게 여러 파일 건드린 게 아니라, 딱 한 파일의 역할을 명확히 정의하는 데만 집중했다. 이런 핀포인트 리팩터링이 쌓여야 나중에 큰 구조 변경도 무서워지지 않는다.

끝.