카톡으로 .apk 보내던 시절 끝 — Firebase App Distribution으로 QA 배포 자동화한 기록

 

지난 분기 어느 금요일 저녁 7시였습니다. QA 팀장님한테 카톡이 왔습니다. "어제 보내주신 apk 어디 갔어요? 카톡 만료됐는데요." 그때 다시 빌드 돌리면서 결심했습니다. 이번 주말 안에 무조건 갈아엎겠다고요.

 

카톡 APK 배포의 한계, 단톡방에 쌓이던 정체불명 빌드들

가장 큰 문제는 버전 추적이 안 된다는 점이었습니다. 단톡방에 .apk 파일이 한 주에 대여섯 개씩 쌓이는데, QA 분들이 "지금 보는 게 최신 맞나요?" 물어보면 저도 다시 빌드 번호를 확인해야 했어요. 그 확인 작업에만 주 2~3시간이 그냥 녹았더라고요.

 

카톡 파일은 일정 기간이 지나면 만료됩니다. 회귀 테스트 들어가서 "지난주 빌드 다시 깔아주세요" 요청이 오면, 그 자리에서 빌드를 다시 돌리거나 사내 NAS 를 뒤져야 했지요. 클라이언트 단톡방에 디버그 빌드가 그대로 떠다니는 보안 리스크도 마음에 걸렸습니다.

 

QA 가 두세 명일 땐 어찌어찌 굴러갔는데, 외부 디자이너랑 클라이언트까지 합쳐 일곱 명이 넘어가니까 1:1 안내 메시지만 하루 30분씩 잡아먹었어요. 이쯤 되면 도구를 갈아야 할 신호라고 봅니다.

 

 

Firebase App Distribution 무료 플랜으로 프로젝트 붙이기

Firebase App Distribution(이하 FAD)은 무료입니다. Spark 요금제, 그러니까 신용카드 등록 없는 무료 플랜으로도 결제 걱정 없이 돌릴 수 있어요. 한도는 프로젝트당 테스터 500명, 그룹당 200명까지인데 대부분의 사내 QA 규모엔 차고 넘치는 수준입니다.

 

콘솔 세팅은 30분 안에 끝납니다. Firebase 프로젝트 만들고, 앱을 등록하고, App ID 를 받아두면 절반은 한 셈이에요. 자동화에 쓸 서비스 계정을 IAM 에서 따로 만들어 "Firebase App Distribution Admin" 역할을 부여하고, JSON 키를 발급받아 보관해두면 됩니다. 이 JSON 키는 나중에 깃허브 액션(GitHub Actions) 에서 시크릿으로 등록할 자료라 잘 챙겨두세요. 장수명 키 부담이 크다면 Workload Identity Federation 으로 단기 토큰을 발급받는 방식도 옵션입니다.

 

테스터는 그룹 alias 단위로 묶어서 관리하는 게 편하더라고요. qa-internal, designers, client-acme 같은 alias 를 미리 설계해두면, CI 에서 브랜치별로 어디에 뿌릴지 분기시키기가 깔끔합니다.

 

Gradle 플러그인으로 릴리스 노트까지 자동 작성

com.google.firebase.appdistribution 플러그인을 build.gradle 에 붙이면 appDistributionUploadRelease task 가 자동으로 생깁니다. CLI 한 줄로 배포가 끝나는 구성이지요.

 

firebaseAppDistribution {
    artifactType = "APK"
    releaseNotesFile = "release-notes.txt"
    groups = "qa-internal,designers"
    serviceCredentialsFile = System.getenv("FIREBASE_SA_PATH")
}

 

릴리스 노트는 매번 손으로 쓰지 마시고 git log 로 자동 생성하는 게 낫습니다. 최근 머지 커밋 메시지 10개 정도 뽑아 텍스트 파일로 떨어뜨리고, 그 경로를 releaseNotesFile 에 물려주면 됩니다. 이렇게 한 다음부터는 QA 분들이 App Tester 앱에서 "이번 빌드에 뭐가 바뀌었나" 한눈에 보시더라고요.

 

groups 파라미터에 alias 를 콤마로 구분해 넣으면 동시에 여러 그룹으로 뿌릴 수 있습니다. 클라이언트 데모용 빌드는 client-acme 만, 사내 일일 빌드는 qa-internal,designers 묶음으로 분기하는 식이에요.

 

 

깃허브 액션으로 안드로이드 QA 배포 자동화하기

저는 깃허브 액션에서 Fastlane 의 firebase_app_distribution 플러그인으로 묶어 돌리고 있습니다. 핵심은 시크릿 등록이에요. 서비스 계정 JSON 은 그대로 넣으면 줄바꿈이 깨질 수 있으니 base64 로 인코딩해서 FIREBASE_SA_JSON 같은 이름으로 등록한 다음, 워크플로 안에서 디코드해 임시 파일로 쓰는 흐름이 안전합니다.

 

브랜치별 분기는 이렇게 잡아두면 운영이 편해져요.

 

1. develop 푸시 → qa-internal 그룹으로 매 커밋마다 배포
2. release/* 브랜치 → qa-internal + client-acme 묶음으로 배포
3. 태그 푸시(v*.*.*) → 별도 잡으로 Play Console 내부 테스트 트랙 업로드

 

이 흐름으로 넘어간 다음부터는 한 빌드 뿌리는 시간이 25분에서 7분으로 줄었습니다. 더 큰 변화는 시간이 아니라 "내가 의식하지 않아도 빌드가 알아서 가 있다"는 점이에요. 빌드가 실패하거나 업로드가 죽으면 사내 슬랙 채널로 즉시 알림이 와서, 금요일 저녁의 카톡 알림 같은 일이 사라졌습니다.

 

 

TestFlight·Play 내부 테스트와 FAD 위치 비교

iOS 단독이라면 솔직히 TestFlight 가 거의 항상 우위입니다. UDID 수집이나 프로비저닝 갱신 같은 번거로움 없이 네이티브로 깔리니까요. 다만 안드로이드와 iOS 를 동시에 굴리는 팀이라면 FAD 가 한 곳에서 두 OS 빌드를 묶어 관리해줘서 운영 비용이 확 줄어듭니다.

 

Play Console 의 내부 테스트 트랙과 비교하면 FAD 는 리뷰 절차가 없어서 배포 속도가 빠릅니다. 반대로 실제 Play Store 설치 경로·서명 환경을 검증해야 하는 단계라면 Play 내부 테스트가 더 정확한 편이지요. 개인적으로는 일상 QA 는 FAD, 출시 직전 리허설은 Play 내부 테스트로 이원화해서 굴리고 있습니다.

 

사이드로드 방식이라 Play Integrity 가 끼는 기능이나 인앱 결제 같은 영역은 FAD 만으로 검증이 안 된다는 점은 미리 알아두시는 게 좋겠습니다.

 

App Tester 설치로 테스터 초대 흐름 한 번에 정리

테스터 입장에서 가장 깔끔한 흐름은 안드로이드 네이티브 "App Tester" 앱을 깔게 하는 겁니다. 최초 1회만 초대 메일로 들어와서 앱을 깔면, 이후 신규 빌드는 푸시 알림으로 알아서 잡혀요. APK 파일을 사람이 1:1 로 전달할 일이 사라집니다.

 

저는 사내 가이드 문서 첫 줄에 "App Tester 설치"를 박아두고, 그 이후로는 단톡방에 올라오는 .apk 파일은 일단 회수합니다. 한 번 정책을 세워두면 누수가 잘 안 생기거든요.

 

Crashlytics 와 연동해두면 베타 빌드에서 터진 크래시가 자동으로 모이고, App Tester 안의 흔들기 제스처로 인앱 피드백도 받을 수 있습니다. QA 분들이 스크린샷 따로 첨부할 필요 없이 한 화면에서 보고가 끝나는 흐름이 만들어져요.

 

---

지난 분기 숫자 한 줄만 남기고 닫겠습니다. 카톡으로 뿌리던 시절 주 2~3시간 잡아먹던 빌드 추적·전달 작업이 거의 0분, 한 빌드 배포 시간은 25분에서 7분. 자동화가 돌려준 건 그 시간만큼의 금요일 저녁이었습니다.