[Android] 멀티 앱 배포 실수 줄이기: Release Matrix 관리 방법

앱이 하나일 때는 배포 체크리스트가 비교적 단순합니다. 빌드가 정상적으로 되고, 서명 설정이 맞고, Play Store에 올릴 버전 정보만 확인하면 끝나는 경우가 많죠.

그런데 운영하는 앱이 여러 개로 늘어나면 이야기가 전혀 달라집니다. packageName, applicationId, Firebase 설정, keystore 파일, 배포 트랙(Track), 릴리즈 노트까지 서로 뒤섞이기 딱 좋습니다. 이 상태에서 정신없이 급하게 배포하다 보면 다른 앱의 설정 파일을 잘못 넣거나, 내부 테스트용 빌드를 프로덕션에 올려버리는 대형 사고가 터지곤 합니다.

이래저래 멀티 앱을 운영하다 보니, 배포 사고를 막아줄 확실한 기준표가 필요하겠다는 생각이 들었습니다. 그래서 저의 경우 release matrix(릴리즈 매트릭스)를 만들어 한 표로 관리하고 있습니다. 나중에 문제가 생겼을 때 어떤 앱을 어떤 설정으로 배포했는지 추적하기도 편해서 자꾸 까먹는 저를 위해 기록으로 남겨둡니다.

왜 release matrix가 필요할까?

여러 앱을 같은 코드베이스나 비슷한 구조로 관리하다 보면 자연스럽게 복사-붙여넣기 같은 반복 작업이 많아집니다.

작업이 반복되면 CI/CD로 자동화를 돌리기 마련인데, 이걸 잘못 세팅하면 한 번에 여러 앱에 동시에 문제가 생길 수 있습니다. 빌드가 실패하면 그나마 다행입니다. 진짜 무서운 건 빌드는 정상적으로 성공했는데 설정이 뒤바뀐 경우입니다.

• A 앱에 들어가야 할 Firebase 설정 파일(google-services.json)이 B 앱 빌드에 포함됨
• 내부 테스트용 빌드(Internal track)로 나가야 할 파일이 프로덕션(Production)으로 업로드됨

이런 문제는 스토어에 올라간 뒤에야 발견되는 경우가 많아서 정말 조심해야 합니다. 배포 전에 앱별 설정을 한눈에 직관적으로 확인할 수 있는 기준표가 있어야 담당자도 검토하고, 나아가 자동화 스크립트의 빌드 기준값으로도 활용할 수 있습니다.

release matrix에 넣을 항목 정리

모든 정보를 다 집어넣으면 표가 지저분해져서 오히려 보기 힘듭니다. 딱 배포 판단에 필요한 핵심 항목만 추려야 합니다.

특히 keystore 비밀번호, Google Play API 키, Firebase 설정 파일 원문처럼 민감한 정보는 보안상 절대로 matrix 문서에 직접 적지 않는 것이 좋습니다.

항목설명공개 및 관리 시 주의점

profileId	내부 프로파일 식별자	내부 네이밍 규칙이 외부에 드러나도 되는지 확인
packageName / applicationId	Play Store 앱 식별 기준	오타가 나면 엉뚱한 앱으로 등록되므로 정확히 기재
Firebase app	앱별 Firebase 연결 정보	설정 파일 원문을 적지 말고, 프로젝트 ID 등으로 매핑
signing key	서명 키 매핑 이름	keystore 경로 정보나 비밀번호는 노출 금지
track	internal, closed, production 구분	실제 배포될 스토어 트랙 확인
versionCode	배포 순서 관리 버전 코드	이전 배포보다 무조건 높아야 하므로 자동 증가 규칙 확인
release note	사용자 변경 안내 문구	미확정 기능이나 과장된 문구 포함 금지
evidence	빌드 및 테스트 결과 근거	내부 로그를 남길 때 민감 정보는 제거 후 링크 처리

 

실무에서 사용하는 release matrix 예시

실제 문서를 작성할 때는 아래와 같은 형태로 깔끔하게 한 표로 떨어지게 만듭니다. 중요한 건 모든 데이터를 욱여넣는 게 아니라, 내가 지금 배포하려는 정보가 맞는지 '크로스 체크'하는 용도로 쓰는 것입니다.

profileIdapplicationIdFirebasesigningtrackrelease note상태

tourSampleA	com.example.tour.a	firebase-tour-a	shared-tour-key	internal	지도 화면 안정화	준비
fileSampleB	com.example.file.b	firebase-file-b	shared-file-key	closed	검색 필터 개선	검토
utilitySampleC	com.example.util.c	firebase-util-c	utility-key	production	버그 수정	완료

 

비밀번호나 인증 토큰 같은 값들은 별도의 안전한 자격 증명 저장소(Vault나 CI/CD Secret 환경변수)에 두고, 여기서는 매핑할 규칙(Key 이름)만 명시하는 게 안전합니다.

배포 전 필수 체크리스트 (확인 흐름)

배포 당일에는 이 matrix를 띄워두고 위에서 아래로 흐름을 쭉 따라가며 체크합니다. 앱이 많아질수록 이 짧은 과정이 배포 실수를 엄청나게 줄여줍니다.

1. 식별자 일치 확인: profileId와 applicationId가 정확히 매치되는지 확인합니다.
2. 빌드 변형 및 서명 확인: 빌드 배리언트(Build Variant)와 signing 설정이 맞게 물렸는지 체크합니다.
3. Firebase 프로젝트 확인: Firebase 및 Crashlytics 매핑이 엉뚱한 곳으로 되어있지 않은지 봅니다.
4. 버전 코드 체크: versionCode가 이전 배포 버전보다 정상적으로 증가했는지 확인합니다.
5. 사전 테스트 검증: 내부 테스트(Internal) 또는 스모크 테스트 결과에 문제가 없는지 확인합니다.
6. 릴리즈 노트 검토: 스토어에 노출될 release note 문구에 오타가 없는지 최종 확인합니다.
7. 트랙 지정 확인: Play Store 업로드 트랙(Internal / Closed / Production)을 제대로 선택했는지 체크합니다.
8. 상태 업데이트: 최종 업로드가 끝나면 matrix의 상태를 '완료'로 업데이트하고 이력을 남깁니다.

자동화(CI/CD)와 문서의 역할 분리

release matrix를 만든다고 해서 자동화 스크립트가 필요 없어지는 건 아닙니다. 둘은 같이 가야 효과가 좋습니다.

• release matrix: 어떤 앱을 어떤 설정값으로 내보낼지 정의하는 '기준점'
• CI workflow: 정의된 설정값을 바탕으로 빌드, 서명, 검증을 수행하는 '수행 주체'
• Play Console: 최종적으로 파일이 올라가서 배포 승인과 트랙이 관리되는 '목적지'

운영할 때 가장 피해야 하는 상황은 문서와 실제 CI 설정이 따로 노는 경우입니다. 문서에는 분명 closed 트랙이라고 적혀 있는데, CI 스크립트 실수로 production에 바로 꽂혀버리면 난감하겠죠. matrix는 한 번 쓰고 버리는 문서가 아니라, 배포 프로세스가 돌 때마다 계속 동기화하고 갱신하는 실무 기준서로 보셔야 합니다.

흔히 하는 배포 실수 4가지

1. 앱 이름만 보고 대상을 판단하는 경우
   • 프로젝트 내에서 앱 이름은 비슷하게 지을 수 있어도 applicationId는 고유합니다. 배포할 때는 항상 이름이 아니라 식별자(ID)를 기준으로 움직여야 안전합니다.
2. 다른 앱의 Firebase 설정을 넣는 경우
   • 빌드가 정상적으로 성공하기 때문에 알아채기 힘든 실수입니다. 그대로 배포되면 Crashlytics 로그나 푸시 알림이 엉뚱한 앱으로 가버리는 지옥을 맛보게 됩니다.
3. 프로덕션 트랙에 잘못 올리는 경우
   • 내부 테스트용 빌드는 무조건 internal 트랙으로 가야 합니다. 배포 버튼을 누르기 직전 마지막 단계에서 트랙 지정을 다시 확인하는 습관이 필요합니다.
4. matrix에 민감 정보를 노출하는 경우
   • 파일 경로, keystore 비밀번호, Play Console 인증 API 키 등을 텍스트로 그대로 적어두는 경우가 있습니다. 문서 권한이 탈취되면 보안 사고로 이어지니 민감 정보는 무조건 분리하세요.

요약

Android 멀티 앱 운영 환경에서 release matrix는 단순한 문서가 아니라 일종의 안전장치입니다.

앱 개수가 늘어날수록 배포는 단순한 파일 업로드가 아니라, 추적 가능한 운영 절차가 되어야 합니다. 빌드가 잘 끝났는지 확인하는 것만큼이나, 어떤 설정을 가지고 올라갔는지 기록을 남기는 것이 배포 사고를 막는 지름길입니다. 배포 전 5분만 투자해서 표를 확인하는 습관을 들이면 밤에 발 뻗고 편하게 잘 수 있습니다.