Repository navigation
Google Play 구매·복원 구현에 필요한 서버·상품·화면 계약을 확인한다 #881
Description
문제
#470의 구독 유도 화면에서 구독 후 기록하기를 눌러도 현재는 팝업만 닫히며 실제 상품 조회, 구매, 복원, 서버 권한 동기화가 없습니다.
BE #223은 현재 플랜·타임레터 한도와 provider-neutral entitlement 경계를 제공하고, Afternote/Afternote-BE#224는 Google Play 구매 검증·RTDN을 담당합니다. Android 앱은 Google Play Billing으로 구매를 시작하되, 클라이언트 결과만으로 권한을 부여하지 않고 서버 검증 결과를 다시 조회해야 합니다.
- 구독 유도 UI·진입점: 등록 한도 도달 시 구독 유도·구매 후 복귀를 PM에게 확인한다 #470
- BE 플랜·한도 기반: [feat] 구독·플랜 조회 및 타임레터 등록 한도 서버 계약 추가 Afternote-BE#223
- BE Google Play 검증·RTDN: [feat] Google Play 구독 검증·RTDN entitlement 연동 Afternote-BE#224
- Google Play Billing 연동: https://developer.android.com/google/play/billing/integrate
사용자 목표
- 무료 한도에 도달한 사용자는 앱 안에서 실제 구독 상품과 현지 가격을 확인하고 안전하게 결제할 수 있습니다.
- 구매 완료 후 서버 검증된 무제한 권한을 즉시 확인하고 중단했던 타임레터 등록을 재시도할 수 있습니다.
- 재설치·재로그인·다른 기기에서도 기존 구독을 복원해 같은 플랜을 확인할 수 있습니다.
- 보류·취소·오류 상태에서는 결제 성공으로 오해하지 않고 다음 행동을 안내받습니다.
선행 조건
- Afternote/Afternote-BE#223의
GET /api/v1/subscriptions/me와 한도 오류 계약이 병합·배포됨 - Afternote/Afternote-BE#224의 구매 검증 API가 내부 테스트 환경에서 사용 가능함
- #470의 구독 화면 1안/2안 정본과 구매 후 복귀 UX 확정
- Play Console 구독 상품 ID·기본 플랜·오퍼와 license tester 계정 준비
- 서버와 합의한
obfuscatedAccountId생성·전달 규칙 확정
현재 범위: 구현 선행 결정
서버 검증과 Play Billing을 사용한다는 방향은 유지한다. 상품·오퍼·계정 귀속 규칙, 검증 API, 구매 후 복귀와 pending UI가 준비되기 전 세부 화면·ViewModel·repository 구현 계획은 제거한다.
- 선행 조건의 확정 근거와 대상 테스트 환경을 확인한다.
- 서버 권한을 클라이언트 구매 콜백으로 추정하지 않는 원칙을 유지한다.
- 확정된 계약과 기존 구현을 대조한 후 필요한 구매·복원 작업과 검증 범위를 정한다.
제외 범위
- Google Play Developer API 검증, acknowledgement, RTDN 처리
- 서버 entitlement·월 한도 계산
- iOS App Store 결제
- 대체 결제와 외부 결제 프로그램
- 일회성 인앱 상품
- Play Console 내부 트랙 배포 자동화(Google Play 내부 테스트 트랙 배포 자동화 #852)
완료 조건
- 서버 검증·상품·계정 귀속·화면 계약과 테스트 환경의 준비 근거가 연결된다.
- 미확정 세부 구현을 예약하지 않고, 확정 계약 기준의 필요한 작업 범위를 정한다.
구현 전 결정할 질문
- 구매 성공 뒤 타임레터 등록을 자동 재시도할지, 구독 화면만 닫고 사용자가 다시 제출하게 할지?
- pending 상태를 구독 화면과 원래 진입 화면 중 어디에서 지속 표시할지?
- 여러 Play 계정 또는 앱 계정 전환 시 구매 귀속 불일치를 어떤 문구와 복구 흐름으로 안내할지?
Activity
1hyok commentedon Aug 23, 2026
08-23 회의에서 Play스토어 인앱 결제 수수료 30%를 이유로 외부 결제 경로 검토가 시작됐습니다(회의록: "수수료 사이트 플레이스토어 30프로인데 결제 사이트 알아보기" — PM 액션).
이 이슈는 Google Play Billing 전제이고 "대체 결제와 외부 결제 프로그램"을 제외 범위로 못박고 있어, 결제 경로 결론에 따라 전제가 바뀔 수 있습니다. 착수 전 PM 결론 확인 필요 — BE 측 전제(Afternote/Afternote-BE#224 Google Play 검증·RTDN)도 같은 영향권입니다.
참고: 구독 상품이 아니라 기록 책 인쇄 같은 단건 결제는 BM 문서 기준 실물 상품이라 Play Billing 의무 대상이 아니므로, 외부 결제 검토가 구독에 적용될지 단건에 적용될지도 결론에서 갈립니다.
[-]feat(subscription): Google Play Billing 구매·복원 및 구독 화면 연결[/-][+]Google Play Billing 구매·복원 및 구독 화면 연결[/+][-]Google Play Billing 구매·복원 및 구독 화면 연결[/-][+]Google Play 구매·복원 구현에 필요한 서버·상품·화면 계약을 확인한다[/+]1hyok commentedon Sep 13, 2026
착수 가능 여부 재실측 (2026-09-13)
기준은
origin/develop7d87aa3f와 GitHub API 실조회입니다. 결론부터 적으면, 지금 이 이슈에서 코드로 뗄 수 있는 독립 범위가 없습니다. 완료 조건 두 항목이 모두 블로커 산출물에서 나오는데 셋 다 열려 있고, BE 쪽은 미배포가 아니라 코드 부재입니다. 다만 develop 실코드가 본문 전제와 어긋나는 지점이 있어 그것을 남깁니다.1. 블로커 3건은 항목별로 따져도 전부 미충족
blocked_by 에 #470, Afternote/Afternote-BE#223, Afternote/Afternote-BE#224 셋이 걸려 있고 전부 OPEN 입니다.
BE 쪽은 "병합은 됐는데 배포가 안 됐다" 가 아니라 코드가 없는 상태입니다.
Afternote-BEmain(3593aa30) 트리를 전수로 훑으면 파일 482건 중 subscription, entitlement, billing, purchase, plan 이 이름에 들어가는 파일 0건입니다.1hyok/feat/223-entitlement-foundation은 main 대비 3 커밋 앞, 66 커밋 뒤이고 마지막 커밋이85abc9cb(2026-08-22 18:19 UTC)입니다. 담긴 파일은SubscriptionEntitlementEvent.java,UserEntitlement.java,EntitlementEventServiceTest.java셋뿐이라 컨트롤러가 없습니다.그래서 선행 조건 1번(
GET /api/v1/subscriptions/me병합·배포)과 2번(검증 API 내부 테스트 환경 사용 가능)은 근거를 연결할 대상 자체가 아직 없습니다. 완료 조건 1번의 "준비 근거 연결" 과 2번의 "확정 계약 기준 범위 확정" 도 같은 산출물이 원천이라, 항목을 쪼개도 지금 닫히는 게 없습니다.2. develop 실측: "BE 계약이 오면 조회만 갈아끼우면 된다" 는 전제가 틀렸습니다
무료 한도 게이트가 세는 축이 BE#223 확정 정책과 다릅니다. 값만 바꾸는 문제가 아니라 판정 주체를 걷어내야 하는 문제입니다.
TimeLetterWriteViewModel.kt:172-186이고 상수는 같은 파일:708의FREE_PLAN_REGISTER_LIMIT = 3입니다. 세는 값의 출처는timeLetterRepository.getTimeLetters().totalCount인데, 그 엔드포인트는TimeLetterApiService.kt:18-20주석대로 SCHEDULED 목록입니다. 즉 FE 가 세는 것은 "지금 SCHEDULED 로 남아 있는 건수" 이지 달력월 누적이 아닙니다.TimeletterViewModel.kt:82-98에서 등록건 삭제가 성공하면load()가 목록을 다시 읽으므로 카운트가 줄고, 무료 슬롯이 로컬에서 되살아납니다. BE#223 의 "삭제하거나 DRAFT 로 되돌려도 이미 사용한 월 등록 건수는 복구하지 않습니다" 와 정면으로 어긋납니다.2800이 서로 다른 답을 냅니다.originalEditingStatus != SCHEDULED일 때만 검사하므로, 기존 SCHEDULED 수정은 재차감하지 않는다는 BE 규칙과 결과가 같습니다.팝업 확인 버튼은 여전히 닫기만 합니다.
TimeLetterNavGraph.kt:89-92에// TODO: 구독 화면 및 관련 플로우 구현 시 구독 화면 이동으로 변경이 남아 있고, 문구는TimeLetterWriteScreen.kt:456-466입니다.3. 진입점은 코드상 한 곳뿐입니다
develop 전체에서
FREE_PLAN,freePlanLimit을 grep 하면 걸리는 파일이feature/timeletter5개뿐이고,feature/afternote와feature/home에는 한도 게이트도 구독 팝업도 0건입니다(두 모듈의 "구독" 문자열은 전부 Flow 구독 관련 주석입니다). 본문의 "구매 후 복귀" 질문을 정할 때, 현재 코드 기준 복귀 지점이 하나라는 것을 전제로 놓아야 합니다.4. core 는 선행 작업이 없고, Play Billing 의존성도 없습니다
core/network는 이미 준비돼 있습니다.ApiErrorCallAdapterFactory.kt:115-134가 HTTP 400..599 본문의code를 그대로 실어ApiException(status, code, serverMessage, fallbackMessage)로 올리므로,2800식별에 core 변경이 필요 없습니다.gradle/libs.versions.toml에 Play Billing 의존성이 없습니다(play매치는credentials-play-services-auth하나뿐). develop 전체에서 billing, subscription, entitlement 는 프로덕션·설정 코드 0건이고, 생성물인 baseline profile 의 Compose 클래스명만 걸립니다. "이미 부분적으로 돼 있는가" 는 아니오입니다.5. 이 이슈를 무는 열린 PR 은 없습니다
열린 PR 62건 본문을 전수로 훑어
881이 걸린 것은 #2008 하나인데, 그마저 커밋 SHAfc881bf...안의 우연한 문자열이라 Closes 가 아닙니다. 타임레터를 만지는 #1365(base develop)도TimeLetterWriteViewModel.kt를 수정하지만 diff 에 한도 게이트·구독 관련 변경은 0건입니다. 다만 그 PR 이 병합되면 위 줄 번호는 밀리므로, 인용은7d87aa3f기준으로 읽어 주세요.본문에서 고쳐야 할 전제
본문은 아직 고치지 않았습니다. 완료 조건을 좁히는 편집이 아니라 서술 정정이라, 아래 네 가지를 기록으로만 남깁니다.
feature/timeletter에 있고, 그 버튼이 갈 구독·결제 화면은 시안에도 없습니다. 본문에 없는 세 번째 게이트인데 #470 의 2026-08-31 코멘트에만 기록돼 있습니다. 정본 페이지 TEXT 6,482건 전수에서 990, 무제한, 결제, subscription, billing 이 각 0건이고, 선행 조건 3번의 1안4327:66610과 2안4327:66687은 둘 다 살아 있어 정본도 아직 안 갈렸습니다.다음 착수자에게
BE#223 이 병합·배포돼도 이 이슈는 바로 열리지 않습니다. 구독·결제 목적지 화면이 시안에 없고(위 3번), 한도 판정 주체를 FE 에서 걷어내는 작업이 별도로 필요합니다(위 2번). BE 대기와 병렬로 먼저 풀 수 있는 것은 시안 요청 쪽이고, 그건 #470 이 추적합니다.
1hyok commentedon Sep 18, 2026
PM 결정 대기 항목은 깃허브 이슈로 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 결정). 이 이슈의 질문은 피그마 스레드에 걸려 있다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4823-17385#1932508488 답이 오면 그 답을 근거로 구현 이슈를 새로 만든다.