샌드박스에서 구독 취소를 진행했는데 Retention Message가 보이지 않습니다.
이번 주에는 구성 메시지와 실시간 API 경로부터 구분한 뒤, 메시지 상태·구독 연결·시스템 취소 절차를 차례로 확인하세요. 샌드박스 테스터는 최신 초안을 볼 수 있으므로 미승인 상태만으로 원인을 단정할 수 없습니다.
이 글은 자동 갱신 구독 앱을 만드는 iOS 개발자, StoreKit 및 서버 엔지니어, Sandbox 테스트와 배포 준비를 맡은 CI 담당자를 위한 점검 안내입니다. 인터페이스 미리보기와 실제 취소 흐름을 구별하고, 구독 식별자와 혜택 조건, 실시간 응답을 각각 검증합니다.
마지막 업데이트: 2026년 11월 8일. Apple의 Retention Messages 안내, App Store Connect 도움말, API 문서와 WWDC26 발표 자료를 기준으로 확인했습니다.
먼저 구분할 두 가지 Retention Messaging 경로
App Store Connect의 Retention Messaging은 한 가지 방식으로만 작동하지 않습니다. 문제를 재현하기 전에 메시지를 App Store Connect에서 직접 구성했는지, 서버가 실시간 요청에 따라 선택하는지 확인해야 합니다. 경로를 잘못 구분하면 설정 화면만 계속 수정하거나, 반대로 서버 로그만 살피게 됩니다.
Apple은 Retention Messages가 자동 갱신 구독 취소 과정에서 문구, 이미지 또는 혜택을 보여주는 기능이라고 2026년 11월 4일 안내했습니다. 발표 내용과 WWDC26 공식 설명을 기준으로, 먼저 테스트 중인 기능 경로를 기록하세요.
- App Store Connect 구성 메시지: 설정된 메시지 규칙과 구독 연결을 확인합니다. 미리보기와 상태 정보가 주요 증거입니다.
- 실시간 Retention Messaging API: App Store가 보낸 요청, 서버의 응답, 선택한 메시지와 구독의 일치 여부를 확인합니다. App Store Connect의 기본 메시지 등 대체 경로도 함께 살펴야 합니다.
두 경로를 함께 쓰는 팀이라면 한 번의 재현에서 각 경로의 로그와 표시 결과를 구분하세요. Retention Messaging API를 사용하는 경우, 구성 메시지가 정상이라는 사실만으로 서버 선택 결과까지 검증되지는 않습니다.
초안·승인 상태와 테스트 환경은 별도로 판단
메시지 상태는 초안, 심사 대기, 승인, 거절처럼 구분됩니다. Apple의 메시지 상태 설명에서 현재 상태를 확인하고, 해당 상태가 실제 테스트 환경에서 어떤 의미인지 함께 살펴보세요.
특히 Sandbox와 프로덕션을 혼동하면 원인 판단이 어긋납니다. Apple은 Sandbox 테스터가 최신 초안 메시지를 볼 수 있다고 안내합니다. 그러므로 “아직 승인되지 않음”은 표시 실패의 충분한 증거가 아닙니다. 반대로 미리보기가 보인다는 사실만으로 실제 구독 취소 중 표시까지 확인한 것도 아닙니다. Retention Message 구성 안내와 Apple의 기능 발표를 함께 확인하세요.
정책상 심사 상태를 확인할 때는 테스트 계정이 Sandbox Apple Account인지, 앱이 올바른 테스트 환경에서 실행되는지도 별도로 기록하세요. 팀에서 App Store Connect API 4.6을 사용해 구성 정보를 다루더라도, 그 확인과 실시간 메시지 선택은 같은 검증으로 취급하지 마세요. 구성 경로와 API 선택 경로에서 얻는 증거가 다릅니다.
구성은 되어 있지만 연결 또는 적용 조건이 어긋난 경우
메시지가 보이지 않는 원인은 메시지 자체보다 연결 관계일 수 있습니다. 다음 순서로 점검하면 설정 오류와 테스트 대상 오류를 나눌 수 있습니다.
- App Store Connect에서 메시지가 연결된 자동 갱신 구독을 확인합니다.
- 테스트 중인 상품의 구독 식별자가 해당 메시지의 연결 대상과 일치하는지 대조합니다.
- Sandbox Apple Account가 사용 중인 테스트 환경과 맞는지 확인합니다.
- 메시지에 혜택이 있다면 테스트 계정과 구독이 적용 조건을 충족하는지 확인합니다.
- 혜택이 없는 메시지와 혜택이 있는 메시지를 각각 미리보기로 검토합니다.
- 미리보기와 실제 취소 과정의 결과를 따로 남깁니다.
여기서 핵심은 “메시지 표시”와 “혜택 적용”을 같은 결과로 보지 않는 것입니다. 혜택 조건에 맞지 않는 계정이라면 혜택이 보이지 않을 수 있지만, 그것만으로 연결된 메시지 전체가 사용할 수 없다고 단정할 수는 없습니다. 조건과 표시 내용을 각각 확인하세요.
주의: 앱 안에 자체적으로 만든 구독 취소 버튼이 있더라도 이를 시스템이 제공하는 취소 흐름의 대체 검증으로 사용하지 마세요. 테스트는 Apple이 안내하는 Sandbox 구독 취소 절차로 진행해야 합니다.
Apple의 Sandbox 자동 갱신 구독 취소 안내에 따라 테스트 계정과 구독을 확인한 뒤, 해당 계정의 실제 취소 절차를 재현하세요. 취소를 시작한 위치, 테스트한 구독, 사용한 환경을 기록하면 계정 불일치와 메시지 설정 오류를 구분하기 쉽습니다.
실시간 API 응답과 대체 메시지 경로 점검
실시간 API 경로에서는 App Store의 요청을 받았는지, 서버가 기대한 형식으로 응답했는지, 응답에서 지정한 메시지와 구독이 맞는지 살펴야 합니다. 요청을 수신하지 못한 경우와 응답이 유효하지 않은 경우, 유효한 선택을 반환한 경우를 로그에서 구분하세요. 서버 로그에 “요청 없음”만 남기면 App Store 측 호출 여부와 앱 서버 처리 문제를 판별하기 어렵습니다.
Apple의 Retention Messaging API 문서는 요청과 응답 구조 및 메시지 선택 경로를 안내합니다. 문서에서 설명하는 우선순위에 맞춰 실시간 응답을 확인하고, 응답을 사용할 수 없는 상황에서 App Store Connect에 구성한 메시지와 API 기본 메시지가 어떻게 이어지는지도 점검하세요. 한 단계의 응답 오류만 보고 최종 화면 내용을 단정하지 마세요.
프로덕션으로 옮기기 전에는 Apple의 성능 테스트 절차와 API 요청 제한 안내를 확인하세요. 문서에 명시된 요구사항과 실제 운영 로그를 기준으로 검증하고, 여기에 없는 처리 시간이나 성능 기준을 임의로 가정하지 않는 편이 안전합니다.
원인별 재현 결과를 비교하는 기준
아래 표는 같은 증상처럼 보여도 무엇을 먼저 확인할지 나누기 위한 기준입니다. 아직 원인을 확정하지 못했다면, 가장 이른 단계에서 결과가 어긋나는 경로를 찾으세요.
| 확인 경로 | 먼저 볼 증거 | 결과가 맞지 않을 때의 다음 점검 |
|---|---|---|
| App Store Connect 구성 메시지 | 메시지 상태, 미리보기, 연결된 구독 | Sandbox 환경과 테스트 계정, 혜택 적용 조건 |
| Sandbox 취소 과정 | 테스트 계정, 대상 구독, 시스템 취소 절차 | 앱 자체 취소 동작으로 대체하지 않았는지 확인 |
| 실시간 Retention Messaging API | 요청 수신 기록, 응답 유효성, 메시지·구독 일치 | 구성 메시지 및 API 기본 메시지 대체 경로 |
| CI와 배포 준비 | 테스트 빌드가 올바른 환경을 사용하는지, 재현 결과가 남는지 | 빌드·서명 문제와 메시지 표시 문제를 분리 |
재현은 다음 순서로 진행하세요.
- App Store Connect 미리보기에서 문구, 이미지, 연결된 구독과 혜택을 확인합니다.
- 사용하려는 경로가 구성 메시지인지 실시간 API인지 테스트 기록에 명시합니다.
- 올바른 Sandbox Apple Account와 대상 구독을 준비합니다.
- 시스템의 Sandbox 취소 절차를 실행하고, 표시 결과를 미리보기와 별도로 기록합니다.
- 실시간 API를 쓰는 경우 요청, 응답, 선택한 메시지와 대체 경로를 함께 점검합니다.
- 결과가 예상과 다르면 상태, 연결, 계정·환경, 서버 응답 중 처음 어긋난 지점으로 돌아갑니다.
자주 묻는 질문
FAQ의 세부 답변은 페이지 하단에 함께 제공됩니다.
원인이 메시지 상태나 구독 연결이라면 개발 환경을 바꾸는 것보다 해당 설정과 테스트 과정을 바로잡는 편이 우선입니다. 반면 재현에 필요한 테스트 빌드를 만들거나 서명할 macOS/Xcode 환경이 없다면, Linux 환경만으로 해결하기 어려운 빌드 작업과 테스트 메시지 표시 문제를 분리해야 합니다. Linux에서는 필요한 macOS 도구 체인을 그대로 대체할 수 없고, 자체 Mac을 구매하면 초기 장비 비용과 유지 관리 부담이 생깁니다. 기간이 정해진 검증이라면 OSXPort의 원격 Mac 개발 환경 안내와 서울 Mac mini 옵션을 비교해 보세요. 장기간 상시 고부하 작업이나 물리 기기 연결이 필수라면 자체 장비가 더 적합할 수 있으며, 원격 Mac을 선택해도 실제 기기 검증이 자동으로 해결되는 것은 아닙니다.
자주 묻는 질문
샌드박스에서 구독을 취소했는데 Retention Message가 나타나지 않는 이유는 무엇인가요?
먼저 App Store Connect에서 메시지를 직접 구성했는지, 서버가 실시간 Retention Messaging API로 메시지를 선택하는지 구분하세요. 다음으로 테스트 계정과 구독의 연결, 메시지 적용 조건, 샌드박스 취소 흐름을 확인합니다. 앱 안의 자체 취소 화면만으로는 시스템 구독 취소 과정을 검증할 수 없습니다.
App Review 승인을 받지 않은 Retention Message도 샌드박스에서 확인할 수 있나요?
Apple 안내에 따르면 샌드박스 테스터는 최신 초안 메시지를 볼 수 있습니다. 따라서 아직 승인되지 않았다는 사실만으로 샌드박스에 표시되지 않는다고 판단하지 마세요. 메시지 상태와 테스트 환경을 따로 확인하고, App Store Connect 미리보기와 실제 샌드박스 취소 과정의 결과를 구분해 기록해야 합니다.
메시지는 설정했는데 구독자가 보지 못하면 어떤 연결부터 확인해야 하나요?
Retention Message가 현재 시험 중인 자동 갱신 구독에 연결되어 있는지 먼저 살펴보세요. 이어서 테스트 계정이 메시지나 연결된 혜택의 적용 조건을 충족하는지 확인합니다. 혜택이 있는 메시지와 없는 메시지는 각각 미리보기와 실제 표시 결과를 대조해야 하며, 혜택 자격이 없는 상황을 메시지 전체의 오류로 단정하면 안 됩니다.
실시간 Retention Messaging API가 응답하지 않으면 사용자에게 어떤 메시지가 표시되나요?
결과는 실시간 요청의 성공 여부와 응답의 유효성, App Store Connect에 구성한 메시지 및 기본 메시지 설정에 따라 달라집니다. 따라서 응답 없음, 형식이 맞지 않는 응답, 정상 응답을 각각 기록하고 Apple 문서에 안내된 대체 경로를 점검하세요. 네트워크 오류만으로 특정 문구가 반드시 표시된다고 가정하지 마세요.