[Android Release] 여러 개의 Android 앱을 Play Store에 관리할 때 필요한 release matrix

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

그런데 앱이 여러 개로 늘어나면 이야기가 조금 달라집니다. packageName, applicationId, Firebase 설정, keystore, 배포 track, release note, Data Safety 항목이 서로 뒤섞이기 쉽습니다. 이런 상태에서 급하게 배포하면 다른 앱의 설정 파일을 넣거나, 잘못된 track에 업로드하는 실수가 생길 수 있습니다.

release matrix는 앱별 배포 정보를 한 표로 관리하는 방식입니다. 단순 문서처럼 보이지만, 여러 앱을 운영할 때는 배포 사고를 줄이는 기준표가 됩니다.

운영 흐름을 따라가다 보면 빌드 성공 여부만큼 중요한 것이 있습니다. 어떤 앱을 어떤 설정으로 배포했는지 나중에 추적할 수 있어야 한다는 점입니다. 이 글에서는 여러 Android 앱을 관리할 때 release matrix를 어떻게 정리하면 좋은지 살펴보겠습니다.

왜 release matrix가 필요한가

여러 앱을 같은 코드베이스나 비슷한 구조로 관리하면 반복 작업이 많아집니다. 반복 작업은 자동화하기 좋지만, 잘못 자동화하면 한 번에 여러 앱이 영향을 받을 수도 있습니다.

예를 들어 특정 앱에만 들어가야 할 Firebase 설정이 다른 앱 빌드에 포함되거나, 내부 테스트용 빌드를 production track에 올리는 실수가 생길 수 있습니다. 이런 문제는 빌드 자체가 실패하지 않을 수도 있어서 더 조심해야 합니다.

그래서 배포 전에 앱별 설정을 한눈에 확인할 수 있는 기준표가 필요합니다. release matrix는 배포 담당자가 확인할 문서이면서, CI 자동화가 참고할 수 있는 기준이 될 수도 있습니다.

release matrix에 넣을 항목

release matrix에는 모든 정보를 다 넣기보다 배포 판단에 필요한 항목을 빠짐없이 넣는 것이 좋습니다. 특히 keystore 비밀번호, Google Play 계정 정보, Firebase 설정 파일 원문처럼 민감한 값은 matrix에 넣지 않는 편이 안전합니다.

항목	설명	공개 시 주의점
profileId	내부 프로파일 식별자	내부 규칙이 드러나도 되는지 확인
packageName/applicationId	Play Store 식별 기준	공개 가능한 범위만 사용
Firebase app	앱별 Firebase 연결	설정 파일 원문 공개 금지
signing key	서명 키 매핑	keystore 경로/비밀번호 공개 금지
track	internal, closed, production 구분	계정 화면 캡처 공개 금지
versionCode	배포 순서 관리	자동 증가 규칙 문서화
release note	사용자 변경 안내	과장 또는 미확정 기능 금지
evidence	빌드/테스트 근거	민감 로그 제거

코드를 나눠보다 보면 배포 정보도 코드처럼 기준이 필요하다는 생각이 듭니다. 어떤 항목은 자동화에 필요하고, 어떤 항목은 사람이 최종 검토할 때 필요합니다. 이 둘을 구분해두면 matrix가 단순 기록을 넘어 배포 기준표 역할을 하게 됩니다.

예시 release matrix

profileId	applicationId	Firebase	signing	track	release 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	버그 수정	완료

이 표에서 중요한 것은 모든 정보를 다 적는 것이 아닙니다. 배포 판단에 필요한 항목을 빠짐없이 확인하는 것입니다. 특히 비밀번호, 인증 파일, 계정 정보는 matrix에 직접 넣지 않고 안전한 저장소나 내부 권한 관리 기준을 따르는 편이 좋습니다.

배포 전 확인 흐름

배포 전에는 matrix를 기준으로 아래 흐름을 확인해볼 수 있습니다. 단계가 많아 보일 수 있지만, 앱이 늘어날수록 이 과정이 배포 실수를 줄여줍니다.

1. profileId와 applicationId가 일치하는지 확인한다.
2. 빌드 variant와 signing 설정을 확인한다.
3. Firebase/Crashlytics 매핑을 확인한다.
4. versionCode 증가 여부를 확인한다.
5. 내부 테스트 또는 smoke test 결과를 확인한다.
6. release note 문구를 확인한다.
7. Play Store track 선택을 확인한다.
8. 최종 업로드 후 matrix 상태를 업데이트한다.

이 과정은 처음 접할 때는 조금 번거롭게 느껴질 수 있습니다. 다만 앱이 많아질수록 이번 배포에서 무엇을 바꿨는지 나중에 찾는 시간이 더 오래 걸립니다. 배포 전 기준을 남겨두면 장애나 문의가 생겼을 때 추적하기가 훨씬 쉬워집니다.

자동화와 문서의 역할 분리

release matrix는 자동화를 대체하지 않습니다. 오히려 자동화가 읽을 기준 문서가 될 수 있습니다.

구분	역할
release matrix	어떤 앱을 어떤 설정으로 배포할지 정의
CI workflow	정의된 설정으로 빌드/검증 수행
Play Console	실제 배포 승인과 트랙 관리
변경 이력	배포 후 추적과 회고

운영 관점에서는 matrix와 실제 CI 설정이 어긋나지 않는지도 중요합니다. 문서에는 production으로 되어 있는데 CI는 closed track으로 올라가거나, 반대로 내부 테스트 빌드가 production 설정을 타는 상황은 반드시 피해야 합니다.

그래서 matrix는 한 번 작성하고 끝내기보다 배포 흐름과 함께 계속 갱신되는 문서로 보는 편이 좋습니다. 자동화가 늘어날수록 사람이 확인할 기준도 함께 정리되어 있어야 합니다.

테스트 기준

release matrix는 문서처럼 보이지만 테스트 기준과도 연결됩니다. 배포 전에 최소한 아래 항목은 확인하는 편이 좋습니다.

• 앱별 applicationId가 Play Store 등록 정보와 일치하는지 확인한다.
• 앱별 Firebase 설정이 올바른 프로젝트와 연결되어 있는지 확인한다.
• signing key 매핑이 앱별 기준과 일치하는지 확인한다.
• versionCode가 이전 배포보다 증가했는지 확인한다.
• release note가 실제 반영된 변경 사항과 일치하는지 확인한다.
• 선택한 track이 배포 목적과 맞는지 확인한다.
• matrix에 keystore 비밀번호나 계정 정보가 포함되지 않았는지 확인한다.

특히 track 선택은 한 번 더 확인하는 편이 좋습니다. internal에 올려야 할 빌드를 production에 올리는 실수는 작은 설정 실수처럼 보여도 운영 영향이 큽니다.

자주 하는 실수

1. 앱 이름만 보고 배포 대상을 판단하는 경우가 있습니다. 앱 이름은 비슷할 수 있지만 applicationId는 다릅니다. 배포 기준은 앱 이름보다 식별자를 중심으로 확인하는 편이 안전합니다.

2. 다른 앱의 Firebase 설정 파일을 넣는 경우도 있습니다. 빌드가 성공하더라도 Crashlytics, Analytics, push 설정이 엉뚱한 앱으로 연결될 수 있습니다.

3. internal track에 올려야 할 빌드를 production에 올리는 경우가 있습니다. track 선택은 배포 전 마지막 단계에서 다시 확인해야 합니다.

4. matrix에 민감 정보를 직접 넣는 경우도 있습니다. keystore 경로, 비밀번호, Play Console 계정 정보, Firebase 설정 파일 원문은 matrix에 넣지 않는 편이 안전합니다.

결론

여러 Android 앱을 관리한다면 release matrix는 선택이 아니라 안전장치에 가깝습니다. 앱별 package, Firebase, signing, track, release note를 한눈에 확인할 수 있어야 배포 실수를 줄일 수 있습니다.

좋은 release matrix는 배포에 필요한 기준을 명확히 보여주되, 민감 정보는 직접 담지 않는 문서입니다. applicationId, Firebase 매핑, signing 기준, versionCode, track, release note를 확인할 수 있으면 배포 전 검토가 훨씬 쉬워집니다.

앱이 많아질수록 배포는 단순한 업로드 작업이 아니라 추적 가능한 운영 절차가 됩니다. 빌드가 성공했는지뿐 아니라 어떤 앱을 어떤 설정으로 배포했는지 기록하는 습관이 배포 사고를 줄이는 데 도움이 됩니다.