인앱 리뷰 요청 타이밍과 제한
인앱 리뷰 팝업을 붙였는데 원할 때 뜨지 않는다고 버그를 의심하는 경우가 많습니다. 사실 구글과 애플 모두 이 팝업이 "항상" 뜨지 않도록 의도적으로 설계해 두었습니다. 이 글은 구글 플레이 인앱 리뷰 API와 iOS의 리뷰 요청 API가 실제로 어떻게 동작하는지, 왜 CTA 버튼으로 직접 띄우면 안 되는지, 그리고 좋은 타이밍은 언제인지를 정리합니다. 답변을 받은 뒤 대응하는 방법은 스토어 리뷰 답변 가이드에 있습니다.
구글 플레이 인앱 리뷰 API: 뜨지 않는 게 정상일 수 있다
공식 문서는 이 API를 호출한다고 다이얼로그가 항상 뜨는 건 아니라고 분명히 밝힙니다. 구글 플레이는 사용자 경험을 위해 시간 기반 쿼터를 두고 있는데, 이 쿼터는 "구현 세부사항"이라 정확한 수치가 공개되지 않고 사전 고지 없이 바뀔 수 있습니다. 문서에 나온 예시로는 짧은 기간(예: 한 달 미만) 안에 launchReviewFlow를 반복 호출해도 다이얼로그가 안 뜰 수 있다는 정도입니다. 정확한 "몇 번, 며칠"이라는 숫자로 단정할 수는 없다는 뜻입니다.
UI 커스터마이징도 금지됩니다. 다이얼로그는 시스템이 제공하는 기본 디자인 그대로 써야 하고, "만족하셨나요?" 같은 질문으로 만족한 유저만 걸러서 리뷰를 요청하는 방식도 가이드라인 위반입니다. 또 하나 중요한 점은, 공식 문서가 리뷰 요청용 버튼(CTA)을 UI에 따로 만들어 두는 것을 권장하지 않는다는 것입니다. 이미 쿼터를 다 쓴 유저에게는 버튼을 눌러도 아무 일도 안 일어나는 "먹통 버튼"이 되기 때문입니다. 이런 용도로는 차라리 유저를 플레이 스토어 페이지로 바로 연결하는 딥링크를 쓰는 게 낫다고 안내합니다.
테스트는 두 가지 방법이 있습니다. 내부 앱 공유(Internal App Sharing)나 내부 테스트 트랙으로 설치하면 다이얼로그 UI 자체는 볼 수 있지만 실제 리뷰 제출 버튼은 비활성화되어 있습니다. 코드 레벨 테스트에는 FakeReviewManager를 쓰는데, 이건 UI를 흉내내는 게 아니라 API 호출 결과(성공 여부, ReviewInfo 객체)만 시뮬레이션하는 유닛 테스트용 도구입니다. 유니티로 개발한다면 구글이 공식 배포하는 com.google.play.review 패키지를 붙이면 되고, Play Core 라이브러리와 EDM4U(External Dependency Manager) 의존성이 함께 필요합니다.
iOS: 365일 3회라는 자동 조절
iOS는 SKStoreReviewController(또는 SwiftUI의 RequestReviewAction)로 리뷰를 요청합니다. 애플의 RequestReviewAction 공식 문서는 이 다이얼로그의 표시 조건을 명확히 규정합니다. 사용자가 해당 기기에서 이 앱을 아직 평가하거나 리뷰한 적이 없다면 365일 동안 최대 3번까지 요청 창을 표시하고, 이미 평가·리뷰를 남긴 사용자에게는 새 버전이 나왔고 이전 리뷰로부터 365일이 지난 경우에만 다시 표시합니다.
빌드 환경에 따라 동작이 다르다는 점도 공식 문서에 명시되어 있습니다. SKStoreReviewController.requestReview() 문서와 위 RequestReviewAction 문서 모두, 개발 중(디버그 빌드)에는 호출할 때마다 항상 요청 창이 표시되고, TestFlight로 배포한 베타 앱에서는 이 요청이 아무 효과도 내지 않는다고 밝힙니다. 즉 TestFlight에서 다이얼로그가 안 뜨는 것은 커뮤니티의 경험적 관찰이 아니라 애플이 문서에 직접 적어 둔 동작입니다. 실제 빈도 조절 로직은 프로덕션(App Store 배포) 환경에서만 작동합니다.
애플 가이드라인이 명시하는 것
App Review Guidelines 5.6.1은 리뷰 요청 방식을 직접적으로 규정합니다. "제공된 API를 사용해 사용자에게 리뷰를 요청하라"고 명시하면서, 커스텀 리뷰 프롬프트는 허용하지 않는다고 못박습니다. 즉 자체 UI로 "별점 주세요" 화면을 만드는 방식 자체가 가이드라인 위반입니다. 5.6.3은 차트, 검색, 리뷰 같은 앱스토어 경험 요소를 조작하는 행위를 금지하는 조항입니다. 그리고 보상형 리뷰에 대해서는 3장(Business) 서두에서 "유료, 보상형, 필터링된, 가짜 피드백으로 평점이나 차트 순위를 부풀리려 한 것이 확인되면 개발자 프로그램에서 제외될 수 있다"고 밝힙니다. 흔히 "2.3.13 조항"으로 알려진 경우가 있는데, 그 조항은 실제로는 인앱 이벤트(In-App Events)를 다루는 조항이라 리뷰 조작과는 무관하니 혼동하지 않는 것이 좋습니다.
구글 플레이도 마찬가지로 사용자 평점·리뷰·설치 정책에서 금전이나 보상을 대가로 리뷰·평점을 유도하는 행위를 명시적으로 금지합니다. "별 5개 주면 코인 지급" 같은 방식은 두 스토어 모두에서 위반입니다.
좋은 타이밍은 언제인가
가이드라인이 정해주지는 않지만, 업계에서 공통적으로 권장하는 관행은 있습니다. 유저가 방금 긍정적인 경험을 한 직후에 요청을 넣는 것입니다.
- 레벨이나 스테이지를 클리어한 직후
- 새로운 보상이나 아이템을 획득한 직후
- 튜토리얼을 마치고 첫 성취를 경험한 직후
- 여러 세션 동안 꾸준히 접속한 유저(예: 3~5회차 접속)
반대로 튜토리얼 첫 화면이나 로딩 직후, 오류가 난 직후처럼 부정적인 경험 뒤에 요청하는 것은 피하는 게 좋습니다. 이건 어디까지나 업계에서 흔히 쓰이는 경험적 관행이고, 구글이나 애플이 "이 타이밍에 요청하라"고 못박은 공식 지침은 아닙니다.
쿼터에 걸려 팝업이 안 뜰 때의 대안
API를 호출했는데 쿼터 때문에 다이얼로그가 안 뜨는 유저에게도 리뷰 경로를 남겨두고 싶다면, 설정 화면이나 마이페이지 같은 곳에 스토어 페이지로 바로 연결하는 딥링크를 두는 방법이 있습니다. 안드로이드는 market://details?id=패키지명 형태의 URI로 플레이 스토어 앱을 직접 열 수 있고, iOS는 앱스토어 상세 페이지 URL에 리뷰 작성 화면으로 바로 이동하는 파라미터를 붙이는 방식이 흔히 쓰입니다. 이 방식은 인앱 리뷰 API가 아니라 유저가 직접 스토어로 이동해서 리뷰를 남기는 것이므로 가이드라인상 CTA 버튼 제한과는 별개이고, 구글 문서도 이런 용도에는 딥링크를 권장한다고 안내합니다.
정리
인앱 리뷰 팝업이 원할 때마다 안 뜨는 것은 대부분 정상 동작입니다. 구글은 쿼터를, 애플는 365일 3회라는 자동 조절을 각자 시스템 레벨에서 관리하고 있고, 개발자가 손댈 수 있는 부분은 "언제 API를 호출할지"뿐입니다. CTA 버튼으로 강제로 띄우려 하거나 만족도를 먼저 물어 걸러내는 방식은 두 플랫폼 모두 가이드라인 위반이므로, 긍정적 경험 직후에 API를 호출하고 나머지는 시스템에 맡기는 것이 가장 안전한 접근입니다.