[CI/CD] 모바일 CI/CD 1편

배경

모바일 앱 배포는 FE, BE와 달리 여러 가지 특별한 요소들을 고려해야 합니다.

모바일(Android) 기준으로 다음과 같은 요소들이 빌드 결과물을 구성합니다.

• 개발환경 (Build Flavor): dev, qa 등
• 빌드타입 (Build Type): Debug, Release
• 파일 형식 (File Type): .aab, .apk
• 서명 키 (Signing Key)
• 배포 플랫폼: Firebase, Play Console

또한, 모바일 앱 배포는 배포 플랫폼을 통해 심사를 거쳐야 진정한 의미에서 배포가 완료됩니다.

 

배포 사고 사례

모바일 배포는 다양한 경우의 수로 인해 실수할 여지가 많습니다.

실제로 일부 서비스에서는 다음과 같은 배포 사고가 발생했습니다.

• 서비스 이름에 "000개발"로 출시된 사례
• Dev 환경의 앱이 일반 사용자에게 배포된 사례

운영중인 서비스는 심지어 dev1/2, qa1/2 등 총 6개의 환경이 있었고

빌드 조합의 경우의 수는 96가지(6 x 2 x 2 x 2 x 2)나 되어 많은 주의가 필요했습니다.

 

모바일 전용 CI/CD  전략 수립

 

1. 빌드 요소 구성 단순화

자동화된 CI/CD 환경을 구축하여 누구나 쉽고 안전하게 배포할 수 있는 환경을 만들고자 했습니다.

가장 먼저 진행한 작업은 빌드 조합을 간소화하는 것이었습니다.

모바일 앱은 다양한 빌드 조합을 가질 수 있지만, 실제로 자주 사용되는 조합은 제한적입니다.
이에 따라 Build Flavor 하나로 나머지 변수들을 자동으로 확정하는 방식을 도입했습니다.

 

예를들어 prod Build Flavor를 취할때는는 일반적으로 출시용 빌드를 할 때이고

이 경우 아래 요소들을 고정했습니다.

• Build Type: Release
• File Type: .aab
• 배포 플랫폼: Play Console

물론 다른 조합이 필요한 상황이 얼마든지 있을 수 있습니다.

출시된 앱에서 버그가 발생하여 디버깅이 필요하다면 BuildType 이 debug 인 빌드물이 있어야 합니다.

그러나 이는 앞의 상황보다 훨씬 마이너한 상황이기 때문에 수동으로 빌드 결과물을 뽑아내는 식의 방식을 취했습니다.

 

이러한 단순화 작업을 통해 기존 96가지의 경우에수는 6개로 줄어들게 되었습니다.

 

2. 브랜치 전략을 고려한 Tag Push 배포  

 

전략1: Master 브랜치 trigger

앱 심사같은경우. Android 최대 7일 , iOS 평균적으로 1 ~ 5 일정도의 - 심사기간을 거쳐야만 배포가 될 수 있습니다. 그러나 이때 reject 될 가능성이 있기 때문에 master 브랜치에는 심사 통과후에 코드를 올리게 됩니다. 이에 따라 마스터 브랜치를 배포 trigger 로 사용하기는 어렵다는 결론에 이르렀습니다.

 

전략2: 배포 환경별 브랜치 trigger

Dev,qa,stage,prod 와 같은 아주 많은 빌드환경이 존재했고 배포만을 위해 이들  각각에 대응하는 branch 를 만들고 관리하는 것은 비효율적으로 보였습니다. 

 

전략3: Tag trigger

tag trigger 는 앞에 있던 두 전략이 갖던 문제에서 자유로웠으며 추가로 얻는 이점이 있었습니다.

tag triggering 사용시 테그이름을 통해 여러 환경으로 배포를 지원하도록 구현하기가 쉬웠습니다. 여러 환경을 tag 이름에 추가하거나 All tag 를 사용함으로써 기존에 한개씩 한개씩 배포해야했던 불편함을 해소할 수 있었습니다.

 

배포 안정성 증진

 

배포 편의성 증징

 

 

---

 

모바일 CI/CD 구축 구체 전략

1. Tag Trggier 기반 Github Action 을 사용하여 배포한다.
2. 민감한 요소들은 Github Secret 에 설정하고 Workflow 런타임에 디코딩하여 사용한다
3. 모바일 배포 편의를 위해 Workflow 내부에서 Fastlane 을 사용하다.

 

 Github Secret  세팅

 

사이닝키를 비롯한 민감 정보들을 workflow에 직접 명시하는 것은 매우 위험하다

해당 값들을 Github Secret 에 보관하고 필수 인원에게 접근 권한을 주는 방식이 바람직하다

추가적인 보안을위해 Github Secret 에도 암호화된 값을 넣고 

Workflow 런타임 시 디코딩하여 사용하는 방식을 채택했습니다.

1. Release Keystore를 위한 값들
   • alias
   • key password
   • key store password
   •  release keystore (release keystore 파일을 base64로 인코딩해야 함)
2. app Id 및 google services json
   • Firebase에 생성된 앱의 ID
   • app Id 개수에 맞게 작성된 google services json 파일 (firebase에서 제공)
3. service account key
   • play console 서비스 계정에 접근하기 위한 키

 

마치며

항상 '왜?' 라는 질문을 의식적으로 던지는 자세의 중요성을 느꼈습니다.

일반화된 전략이나 통일성을 맹목적으로 따르며 그 장점에 사용성을 끼워 맞추다보니

 어느새 프로젝트의 본질에서 멀어져 갔습니다.

 

이번 프로젝트에서도 팀의 편의성을 높이는 것이 목표였지만,
'왜 이 방식이어야 하는가?', 왜 이 과정을 거쳐야 하는가?'라는 질문을 계속 던지다 보니
자연스럽게 효율성을 높이는 방향으로 유연하게 사고할 수 있었습니다.

결국 '왜?'라는 물음은 단순한 의문을 넘어, 올바른 방향성을 찾는 나침반이 되어주었습니다.