의존성 버전 명시로 팀 빌드 일관성 확보

url_launcher pod 의존성을 Podfile.lock에 반영했다. 사소해 보이는 작업이지만, 팀 프로젝트에서는 꽤 중요한 동기화 작업이다.

왜 lock 파일인가

iOS 프로젝트에서 CocoaPods를 쓸 때 흔한 문제가 있다. 개발자 A가 새 라이브러리를 Podfile에 추가하면, Podfile만 커밋되고 Podfile.lock은 빠진다. 팀원 B가 받으면 pod install을 돌렸을 때 최신 버전이 자동 설치되는데, A는 다른 버전을 쓰고 있을 수 있다는 것. 이렇게 되면 "내 환경에선 잘 되는데 왜 넌 안 되냐"는 대화가 반복된다.

Podfile.lock은 정확히 이걸 막기 위해 존재한다. 각 의존성의 정확한 버전, 빌드 설정, 해시값까지 기록해두는 파일다. url_launcher pod를 추가했다는 건 새 외부 라이브러리가 프로젝트에 들어왔다는 뜻이고, 이걸 lock 파일에 명시함으로써 "모든 팀원이 동일한 이 버전을 사용하세요"라고 선언하는 것이다.

실제 영향

언뜻 단순한 파일 변경처럼 보이지만, 실은 여러 개발자가 함께 일하는 환경에서 일종의 계약서 역할을 한다.

특히 url_launcher 같은 네이티브 기능을 건드리는 라이브러리는 버전 차이가 바로 런타임 에러로 튀어나올 수 있다. iOS 버전별 호환성, 권한 처리, 심지어 App Store 빌드까지 미치는 영향이 크기 때문이다.

팀 협업 관점의 교훈

이런 종류의 "chore" 커밋이 모이면 실제로 팀 개발 속도를 좌우한다. 개별 기능 개발도 중요하지만, 빌드 환경의 일관성이 깨지면 다들 환경 설정에 시간을 쓰게 된다. "왜 내 로컬에서는 에러가 안 나는데" 하는 이슈가 터지면 코드 리뷰도 제대로 못 한다.

비슷한 사례가 node_modules를 package-lock.json과 함께 관리하는 것, Python 프로젝트의 requirements.txt + 가상 환경, Java 프로젝트의 gradle.lock 같은 것들이다. 모두 같은 원칙이다: 팀이 동일한 의존성 상태에서 일한다.

내가 코드 리뷰를 할 때도 신경 쓰는 부분인데, 라이브러리 추가할 땐 반드시 lock 파일까지 함께 커밋되었는지 확인한다. lock 파일이 빠진 풀 리퀘스트는 "문제 없습니다만 lock 파일도 포함해주세요" 코멘트를 단다. 작은 습관이 팀 전체의 안정성을 좌우한다.

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

• 맥북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

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