단계적 출시 (staged rollout, 인앱 업데이트)

일부 사용자에게 먼저 배포해 문제를 조기에 잡는다.

트랙
  내부 테스트   최대 100명. 즉시 반영. 팀 검증용
  비공개 테스트  지정한 그룹
  공개 테스트   누구나 참여 (오픈 베타)
  프로덕션      전체

프로덕션에서 1% → 5% → 20% → 50% → 100% 로 올린다

왜 100%로 바로 안 내보내나

한 번 배포하면 되돌릴 수 없다 Play 는 '이전 버전으로 롤백' 을 지원하지 않는다 (출시 중단은 되지만, 이미 업데이트한 사용자는 그대로다)

1% 에서 크래시율이 튀면

출시를 중단(halt) 한다
나머지 99% 는 영향을 받지 않는다
수정 버전을 새 버전 코드로 올린다

무엇을 보고 판단하나

Android vitals
  크래시율        사용자 인지 크래시 1.09% 초과 시 불이익
  ANR 율          0.47% 초과 시 불이익
  과도한 배터리 사용
  느린 시작 시간

임계를 넘으면 스토어 노출이 줄어든다 — 배포 후 며칠은 반드시 본다

인앱 업데이트

appUpdateManager.appUpdateInfo.addOnSuccessListener { info ->
    if (info.updateAvailability() == UPDATE_AVAILABLE &&
        info.isUpdateTypeAllowed(AppUpdateType.IMMEDIATE)) {
        appUpdateManager.startUpdateFlowForResult(info, IMMEDIATE, activity, REQ)
    }
}

IMMEDIATE — 전체 화면을 막고 업데이트한다 — 구버전이 서버와 호환되지 않을 때
FLEXIBLE — 백그라운드로 내려받고 사용자가 원할 때 재시작 — 일반적인 개선
IMMEDIATE 를 남발하면 사용자가 앱을 못 쓴다 — 정말 필요할 때만

인앱 결제 — 서버 검증이 필수인 이유

클라이언트만 믿으면

앱을 리버싱해 "결제 성공" 응답을 위조할 수 있다
결제 우회 도구가 실제로 존재한다
환불 후에도 권한이 남는다

올바른 흐름

① 앱에서 결제 → purchaseToken 을 받는다
② 토큰을 서버로 보낸다
③ 서버가 Google Play Developer API 로 검증한다
④ 서버가 사용자 권한을 부여한다
⑤ 서버가 acknowledge/consume 한다

3일 안에 acknowledge 하지 않으면 자동 환불된다 — 실제로 자주 놓치는 지점 RTDN(실시간 개발자 알림) 으로 갱신·취소·환불을 받아 처리한다

면접 함정

❌ "Play는 롤백을 지원한다" → 하지 않는다. 단계적 출시가 사실상 유일한 안전장치다.
❌ "결제는 라이브러리가 검증해 준다" → 클라이언트 검증은 우회 가능하다. 서버 검증이 유일한 신뢰 지점이다.

버전 코드와 버전 이름

versionCode = 142        // 정수. Play 가 '어느 것이 최신인지' 판단하는 유일한 기준
versionName = "3.4.1"    // 사용자에게 보이는 문자열. Play 는 신경 쓰지 않는다

versionCode 는 되돌릴 수 없다 — 한 번 올리면 그보다 낮은 것을 못 올린다 출시를 중단해도 그 코드는 소모된 것이다

수정본은 반드시 더 높은 코드로 올린다

사전 출시 보고서

업로드하면 Play 가 실제 기기 팜에서 앱을 자동으로 돌린다

크래시 · ANR
접근성 문제 (터치 영역 · 대비 · 레이블 누락)
보안 취약점 (알려진 취약 라이브러리)
화면 캡처

무료이고 배포 전에 나온다 — 안 보는 것이 손해다

타깃 API 요구

Play 는 매년 targetSdk 하한을 올린다 기한이 지나면 새 앱·업데이트를 올릴 수 없고, 더 지나면 신규 사용자에게 노출되지 않는다

targetSdk 를 올린다는 것은 그 버전의 동작 변경을 전부 받아들인다는 뜻이다

올릴 때마다 동작 변경 목록을 확인하고 테스트한다