CocoaPods Binary Cache 사용기
회사에서 build 속도 개선작업을 진행중이어서 그 작업의 일환으로 Cocoapods Binary Cache 를 테스트 해 본 경험을 공유한다.
작년에 Cocoapods Binary 를 사용했을 때는 iOS 팀 인원 중 일부가 Pod 이 깨져서 pre-build 를 재수행하는 경우가 계속 발생되어 아쉽게도 사용을 포기했던 경험이 있지만, Cocoapods Binary Cache 의 경우는 개인이 아닌 Grab 사에서 직접 관리하는 프로젝트라서 조금 다르지 않을까 하는 기대와 함께 이런저런 테스트를 진행해보았다.
1. Cocoapods Binary Cache 적용 전 테스트
일단 Grab 에서 테스트 한 환경과 동일한(Pod) 구성의 프로젝트를 만들고 build 속도를 테스트 해보았다.
일단 위의 구성과 동일한 구성의 Podfile 을 적용하고 테스트 한 결과 아래와 같이 clean-build 속도가 측정되었다.
- 1차 Clean-Build 속도 : 64초
- 2차 Clean-Build 속도 : 70초
- 3차 Clean-Build 속도 : 65초
Grab 에서 Benchmark 진행한 내용과 크게 다르지 않게 60초를 조금 넘기는 build 속도가 측정되었다. (본인이 사용중인 iMac 은 6년 전 모델이니 이를 감안하고…)
2. Cocoapods Binary Cache 적용 후 테스트
일단 Cocoapods Binary Cache 의 Plugin 설치방법은 Grab 의 github 페이지에 자세히 나와있으니 생략하고,
실제로 적용을 해보기 위해서 적용 전 테스트에 사용했던 프로젝트의 Podfile 을 수정하기로 한다.
- 일단 Podfile 의 최상단에 plugin 을 지정해주고
- 각각의 pod 에 binary 를 사용할 것인지에 대한 flag 를 설정
- 마지막으로 실제 pre-build 된 내용들이 local, remote 의 어디에 저장될 것인지를 설정해준다.
- 참고로 `remote` 에 설정하는 git repository 는 꼭 현재 프로젝트와 동일하게 설정할 필요는 없다. (본인도 별도의 git repository 로 설정해서 사용해 봄)
Podfile 수정이 모두 끝나면 터미널에서 아래 명령을 실행시켜서 Pod 들을 pre-build 하도록 해준다.
pre-build 가 모두 완료되면 프로젝트 디렉토리 하위에 다음의 디렉토리들이 추가로 생성된다.
실제로 어떤 내용들이 있는지 해당 디렉토리로 들어가 보면 아래와 같이 framework 이 pre-build 된 형태로 생성되어 있는 것을 확인할 수 있다.
참고로 Podfile 에서 설정한 local cache-repo 인 .cocoapods-binary-cache/prebuilt-frameworks 내부에는 pre-build 된 framework 들이 압축된 형태(zip 파일)로 들어가 있는데, bundle exec pod binary fetch 명령을 실행하면 여기(혹은 remote cache-repo)에 있는 내용을 복사하여 프로젝트 내부의 _Prebuild 디렉토리 내부로 복사하는 용도로 사용된다.
참고로 pre-build 가 모두 끝나면 무려 2,000 개 정도의 파일이 프로젝트에 추가되는데
.gitignore 파일에 '_Prebuild*' 구문을 추가해서 심신을 보호하자.
어차피 bundle exec pod binary fetch 를 실행하면 빠르게 불러올 수 있는 내용이라 굳이 repository 에 추가할 필요도 없다.
일단 모든 준비를 마쳤으니 Cocoapods Binary Cache 적용 전과 마찬가지로 3회의 clean-build 속도 측정을 해보기로 한다.
- 1차 Clean-Build 속도 : 6초 (64초에 비해 10배 정도 빨라진 듯?)
- 2차 Clean-Build 속도 : 3.8초
- 3차 Clean-Build 속도 : 3.7초
우와 엄청나게 빨라졌다!!!
3. Cocoapods Binary Cache 무조건 적용해야 할까?
Cocoapods Binary Cache 킹왕짱!!! 무조건 써야 돼!!!
혹시라도 이런 말이 나올 것을 대비해서 개인적으로 생각되는 단점을 몇 가지 나열해보기로 한다.
- pre-build 를 manually 실행해주지 않으면 적용 전과 후에 아무런 차이가 없다.
결국 누군가는 Pod 설정이 변경된 이후에 pre-build 를 수동으로 실행해줘야 한다. 물론… 자동화 가능하겠지만 tool-level 에서의 지원은 현재는 없다.
Cocoapods Binary 는 pod install 할 때 pre-build 를 tool-level 에서 자동으로 실행되도록 지원해줬기에 (기억이 맞다면…) 매번 수동으로 pre-build 를 해줘야 하는 점은 개인적으로 불편하게 느껴진다.
왜…냐…하…면… 팀원들을 쫓아다니면서 이러한 과정 혹은 자동화시킨 script 실행을 학습시켜야 할 수도 있기 때문이다 ^^;;;
개인적으로 이런 설정들은 communication-cost 를 줄이기 위해서라도 tool-level 에서 강제할 수 있는 게 최고라고 생각한다.
- clean-build 에서는 확실히 효과적이지만, incremental-build 에는 별 의미가 없을 것 같은데?
일단 CocoaPods 의 Pod 들을 미리 build 해놓고 재사용 한다는 의미에서 보면 clean-build 속도를 줄여주니 좋다고 할 수 있지만, 평상시의 개발 작업은 incremental-build 를 하는 경우가 대부분이라 과연 일상적인 작업에서의 체감할 수 있는 효과가 얼마나 될 지 아리송하다.
회사마다 빌드 환경이나 프로젝트 구조가 천차만별이라 이 효과라는 것이 상황에 따라 크게 달라질 수 있는 부분이라고 생각이 된다.
(작년의 경우는 회사에서 디자인 시스템을 한창 개발 중이었기에 clean-build 를 거의 매일 실행했었고, 이 때 적용할 수 있었다면 또 느낌이 달랐을 것 같다.)
Grab 에서 아주 좋은 시도를 해주어 향후 많은 iOS 개발자들의 고충을 덜어줄 수 있는 tool 이 만들어지고 있다고 생각된다.
하지만 아직 Beta 버전의 느낌이 강하게 들기도 하고, 몇몇 귀찮은 프로세스들을 팀원들 모두에게 숙지시켜야 하는 점 등이 있어, 회사 프로젝트에 반영시켜야 할 지에 대해서는 애매하게 생각된다.
팀원들의 의견을 모두 수렴한 후에 결정되기는 하겠지만, 현재 생각으로는 아직 production 에 반영하기는 조금 이르다는 느낌.
여기까지 읽어주셔서 감사하고,
모든 iOS 개발자에게 행복 있기를~
추가작성 (2022.05.09)
결국 회사에서 2021년 11월 경에 CocoaPods Binary Cache 를 도입해서 지금까지 6개월 정도 사용하고 있는데, 위에 언급한 문제 외에도 몇 가지 문제가 더 발견되었다.
- 대부분의 팀원들이 CocoaPods Binary Cache 관련하여 빌드 과정에서 문제가 발생했을 때 스스로 해결을 못한다.
(인간은 역시 예상을 벗어나는 동물이 아니다…) - pre-build 과정의 결과물이 framework 인지라, Pod 으로 가져온 외부 라이브러리의 source code 를 볼 수가 없다.
이게 좀 치명적인데, config 설정으로 이 문제를 해결할 수 있는 건가 싶기도 한데, 본진의 설명이 너무 부실하다 ㅠㅜ - 더 이상 업데이트가 없다… Best Practice 도 여전히 공사중이고, Troubleshooting 도 여전히 공사중이다.
만약 여러분의 회사에서 CocoaPods Binary Cache 를 도입하려고 준비중이라면 굳이 말리지는 않겠지만, 본격적인 도입 전에 아래 몇 가지 사항을 꼭 체크하자.
- CocoaPods Binary Cache 레벨에서 빌드관련 문제가 발생했을 때 누군가 적극적으로 대처할 준비가 되어있는가?
- 외부 Pod 들의 source code 를 볼 필요가 없는 환경인가? 만약 일부 Pod 의 source code 를 봐야 할 필요가 있고 해당 Pod 한정하여 pre-build 를 하지 않는다고 가정했을 경우에도 CocoaPods Binary Cache 가 매력적인가?
- 향후 Grab 에서 추가적인 지원을 하지 않아서 더 이상 CocoaPods Binary Cache 를 사용하지 못하게 되는 경우가 발생하더라도 지금 당장의 빌드속도만 개선된다면 적극적으로 사용할 것인가?
여기까지 읽어주셔서 감사하고,
모든 iOS 개발자에게 행복 있기를~
