cleanUrl: /programming/my-ios-ci-know-how

CI(Continuous Integration) 환경이 중요하다는 것은 이제 많은 사람들이 알고 있습니다. 하지만 막상 CI 환경을 만드는 것은 어렵기도 하지만 굉장히 많은 시간을 투자해야 하는 일입니다. 그래서 적지 않은 분들이 CI도입을 망설이거나, 도전했다가 포기하는 경우가 많은 것 같습니다. 제가 시행착오를 통해 알게 된 사소한 노하우 몇 가지를 공유해, 그 분들에게 용기를 드리거나, 또는 몇 시간의 작업시간이라도 아껴드릴 수 있다면 대단히 기쁠 것 같습니다.

CI 구축은 언제나 생각보다 어렵다는 것을 받아들여야

앱스토어에서 앱을 리뷰 받을 때 그런 경험 없으신가요? 앱스토어에서 리젝을 먹여서, 문제 되는 부분을 수정해서 다시 제출했는데, 이번에는 또 다른 이유로 리젝을 먹이고, 그래서 그것을 다시 수정해서 제출했는데 또 다른 이유로 리젝을 먹는.. 그런 경험 말이죠. 사실 리뷰어가 앱을 전체적으로 다 검수하고 문제가 되는 부분을 한 번에 정리해서 알려주고, 그 부분들을 한 번에 싹 고쳐서 제출한다면, 한 번의 핑퐁으로 앱스토어에 앱을 올릴 수 있었을 것입니다. 하지만 언제나 앱스토어 리뷰어는 문제가 되는 부분을 하나라도 발견하면 그 즉시 검수를 멈추고, 리젝을 먹이고, 그 리젝에 대한 응답이 오기 전까지 절대로 검수를 재개하지 않죠. 그 결과 우리는 길고, 불확실하며, 매우 짜증나는 핑퐁을 짧으면 며칠 길게는 몇 주에 걸쳐 진행하게도 되는 것입니다.

CI를 구축하는 것은 그런 면에서 앱스토어 리뷰와 매우 닮았습니다. 내 컴퓨터에서는 분명 잘 돌아갔던 명령어들이 CI에서 말썽을 일으키는 일은 흔합니다. 그래서 그것을 고치면, 바로 짜잔 하고 CI가 완성되지를 않습니다. 그 명령어는 넘어가더라도, 또 그 다음 부분에서 얼마든지 불만을 제기 할 수 있는 것이 CI입니다. CI의 에러메시지들은 결코 한 번에 출력되지 않고, 그럴 수도 없습니다.

CI작업에 시간이 오래 걸리는 이유 중 하나는 "이 에러만 해결하면 이제 정말로 다 잘 될 것 같은" 느낌에 속기 아주 쉽기 때문입니다. 그것은 정말 느낌일 뿐입니다. 그 에러만 해결한다고, 방금 전까지 실패하던 빌드가 이번에는 잘 될 것이라는 보장은 전혀 없습니다. CI 작업자는 이 사실을 겸허하게 받아들여야 합니다. 최초로 CI 환경을 구축하는 일에는 아무리 적게 잡아도 최소 1~2주의 시간을 온전히 투자해야 한다고 생각합니다.

에러 메시지를 어떻게든 빨리 만날 수 있는 환경을 만들어야

CI 환경 구축에 오랜 시간이 걸리는 가장 중요한 이유는, 에러 메시지를 만나서, 그 부분에 해당하는 수정을 했을 때, 그 수정이 효과가 있는지의 여부를 알기까지 아주 오랜 시간이 걸릴 수 있기 때문입니다. 왜냐하면 결국 "iOS앱을 빌드"하는 과정이 모든 CI 파이프라인에서 필요한데, 일반적으로 iOS앱의 빌드는 아주 오래 걸리기 때문입니다.

따라서 어떻게 해서든 "더 빨리 에러메시지를 더 많이 만날 수 있는 환경을 구축하는 것, 그리고 거기에 시간과 노력을 쏟는 것"이 핵심입니다. 이런 환경을 만드는 몇 가지 노하우들이 있습니다.

1. 내 컴퓨터에서 쓸 수 있는 CLI 도구를 만들자

무턱대고 CI 환경을 설치하거나, CI 도구들을 구매하기 이전에, 내가 원하는 파이프라인을 최대한 그런 도구들 없이 만들어봐야 합니다. 예컨대 "누구나 쓸 수 있는 배포 도구"를 만들기 전에, "내 노트북에서 커맨드 하나 실행시켜서 바로 배포 할 수 있는 환경"을 만드는 것을 선행 목표로 잡아야 합니다. 그리고 CI 도구는 이 때 내가 만든 커맨드라인 도구를 트리거 하는 역할만 맡긴다고 생각해야 합니다. 이런 마음가짐으로 CI 환경을 만들면 여러 이점이 있습니다.

• 똑같이 iOS앱을 빌드하더라도, 내 컴퓨터에서는 증분빌드를 쓸 수 있기 때문에 더 빨리 빌드되고, 에러가 발생해도 디버거를 연결하기도 쉽습니다. 문제 파악, 문제 대응의 레벨이 훨씬 쉽기 때문에 더 빨리 만들 수 있습니다.
• 설령 나중에 여러 이유로 CI 환경 구축이 엎어지더라도, 최소한 "내가 더 편하게 배포 할 수 있는 환경"이라는 산출물이 남습니다.
• 나중에 다른 CI 서비스로 이전을 할 때, 고려 할 것이 적어집니다. 예컨대 Jenkins에서만 쓰는 특정한 도구를 활용해 CI 환경을 구축했다면, 그 도구가 없는 다른 CI 서비스로의 이전은 고려하기 어려울 수 있습니다. 하지만 그런 의존성이 없다면, 언제든 내가 원하는 CI 서비스로 갈아탈 수 있습니다.

2. 가장 작은 앱으로 CI를 길들여보자

단순한 얘기입니다. 더 작은 앱은 더 빨리 빌드되고, 에러메시지도 더 빨리 받을 수 있습니다. 가장 작은 앱으로 가장 단순한 CI 파이프라인을 구축하면서 경험을 쌓으면, 이런 에러메시지를 읽고 대처하는 노하우를 빨리 쌓을 수 있습니다. 이런 노하우를 쌓을 시간에, 그냥 CI 환경을 바로 구축하는 것이 낫겠다는 생각이 드시나요? 하지만 "**CI구축은 언제나 생각보다 어렵다"**는 것을 잊지 마세요.

3. 내게 필요한, CI 서비스에서 제공하는 환경변수들을 "출력만" 해보자.

내 컴퓨터에서 잘 돌아가는 CI 파이프라인이, 왜 CI가 실제로 돌아가는 다른 컴퓨터에서는 잘 돌아가지 않을까요? 다양한 요소가 있을 수 있지만, 아마 가장 중요한 요인은, git으로 관리되지 않으면서도 빌드에 중요한 역할을 하는 다양한 환경변수들일 것입니다.

예컨대 저는 $BUILD_URL이라는 환경변수에 언제나 특정 값이 들어있을 것이라 기대하고 파이프라인을 만들었습니다. 하지만 환경변수를 선언하는 방법이 틀렸거나, 혹은 그 환경변수에 제가 기대하지 않은 값이 들어있을 때, 제 CI 파이프라인을 실패하거나 제 기능을 못하게 될 것입니다. 이런 식으로 발생하는 문제가 경험상 CI 구축에서 만나는 오류의 5~60%는 되는 것 같습니다.