iOS 의존성 고정과 Play Console 테스터 배포 자동화로 팀 빌드

이번엔 작은 것 같지만 팀 전체의 안정성을 지탱하는 두 가지 정비 작업을 한번에 처리했다. iOS 의존성 lock 파일 업데이트와 Play Console 테스터 자동 실행 스크립트 추가가 그것이다.

Podfile.lock의 역할: 팀 전체의 빌드 환경을 잠금장치처럼

Podfile.lock은 쉽게 말해 iOS 빌드 환경의 "스냅샷"이다. CocoaPods를 쓸 때 Podfile에는 의존성의 버전 범위만 명시되지만, 실제로 어떤 정확한 버전을 썼는지는 Podfile.lock이 기록한다. 이게 없으면 어떻게 될까?

팀원 A가 오늘 빌드하고, 팀원 B가 내일 빌드하면 각각 다른 버전의 pod이 설치될 수 있다. 특히 minor/patch 버전 업데이트가 자주 나오는 라이브러리는 더 그렇다. 그러면 "어? 내 로컬에서는 잘 되는데?"라는 악명 높은 상황이 벌어진다.

이번에 app_links pod을 추가하면서 Podfile.lock을 함께 커밋한 이유가 바로 이것이다. Deep link 처리 같은 기능은 조금의 버전 차이도 UX 문제로 직결되기 쉬워서, 팀 전체가 동일한 상태에서 개발하고 테스트해야 한다.

scripts/daily_tester_run.sh는 Play Console 테스트 앱 배포를 자동화하는 스크립트다. 매일 테스터 그룹에 새 빌드를 배포하는 작업이 정해져 있다면, 이걸 손으로 하는 건 실수의 온상이다.

예를 들어:
- 테스트 빌드 번호를 잘못 입력
- 배포 대상을 잘못 선택 (내부 테스터 vs 공개 테스트)
- 배포 후 로그 확인을 빠뜨림

스크립트로 자동화하면:

# 정확한 빌드 파이프라인 + 테스트 배포가 한 번에
./scripts/daily_tester_run.sh

이건 단순한 편의성이 아니라, 재현성의 문제다. 같은 방식으로 매번 실행되면, 테스트 결과도 의존성 문제로 오염되지 않는다. "어제는 잘 배포됐는데 오늘은 안 된다"는 상황을 줄인다.

보통 이런 작업들은 "chore"로 분류되곤 한다. 새 기능도 아니고, 버그 수정도 아니라는 뜻이다. 하지만 팀을 리딩하면서 느낀 건, 이런 정비 작업들이 없으면 개발 속도가 서서히 떨어진다는 것이다.

의존성 관리가 엉망이면 → 빌드 시간이 늘어나고 → 의존성 충돌 디버깅에 시간 쏟고 → 새 기능 개발이 뒤로 밀린다.

테스트 자동화가 없으면 → 수동 배포 실수로 → 테스터에게 배포된 버전이 예상과 다르고 → 불필요한 이슈 리포트가 쌓인다.

각각은 작지만, 누적되면 조직의 개발 속도 자체를 좌우한다. 그래서 내가 팀에서 강조하는 게, "기능만 빨리 푸시하는 게 아니라, 개발 환경과 프로세스를 함께 돌봐야 한다"는 거다.

이번 작업도 그 연장선이다. app_links 기능이 들어가면서 의존성 환경을 명확히 고정하고, 테스트 배포도 자동화해서 팀 전체가 더 안정적으로 움직일 수 있게 한 것.

다음엔 이런 자동화 스크립트들이 얼마나 잘 작동하는지, 팀원들이 실제로 쓰고 있는지 주기적으로 체크해야겠다는 생각이 든다.

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

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