앱 내 구입 통합 및 마이그레이션 살펴보기

♪ ♪

안녕하세요 세션에 오신 걸 환영합니다 '앱 내 구입 통합 및 마이그레이션 살펴보기'죠 이 세션은 2부로 나눠집니다 App Store 서버 API로의 마이그레이션과 App Store 서버 알림 V2로 마이그레이션으로 나눠지죠 제 이름은 Gabriel이고 App Store 서버 API로 마이그레이션하는 걸 다룹니다 제 이름은 Alex고 App Store 서버 알림 버전 2로 마이그레이션하는 과정을 다루도록 하죠 먼저 App Store 서버 API와 App Store 서버 알림을 간단하게 소개하겠습니다 작년 도입된 App Store 서버 API는 강력하고 안전하고 효율적으로 데이터를 획득하고 서버 작업을 수행하죠 JSON 웹 서명이나 비슷한 형식으로 서명한 데이터를 여러분께 제공하여 수신하는 데이터가 조작되지 않았는지 수신자가 맞는지 App Store가 서명했는지 인증할 수 있습니다 예를 들어 App Store 서버 API의 엔드포인트 중 하나는 거래 이력 가져오기 엔드포인트와 새로운 필터 및 정렬 기능과 함께 사용하여 여러분이 상세한 거래를 originalTransactionId로 가져올 수 있죠 App Store 서버 알림 버전 2의 창에는 구독에 관한 상황을 더 많이 포괄하며 알림 버전 2는 실시간으로 구독 상태에 관해 알려 줍니다 여러분께 필요한 정보를 선제적으로 제공하여 우리에게 정보를 묻기 전에 구독자에게 생긴 일을 알려 드리죠 Alex가 이 부분에 관해 소개할 예정입니다 이런 기능을 쉽고 효율적으로 사용하고 싶다면 이 세션을 시청하세요 App Store 서버 API와 App Store 서버 알림 버전 2를 시작하는 방법을 알려 드리고 마이그레이션 비법과 모범 사례를 살펴보겠습니다 각 항목에 관한 추가 정보는 아래 열거된 세션을 참고하십시오

App Store 서버 API로의 마이그레이션 방법부터 논의하죠 첫째, App Store 서버 API를 어떻게 사용하는지부터 얘기하고 둘째, JSON 웹 토큰 서명의 상세 내용을 다루며 셋째, App Store에서 수신한 서명한 거래가 진짜인지 인증하는 방법을 시현한 뒤 마지막으로 verifyReceipt에서 App Store 서버 API로 마이그레이션하는 방법을 논하겠습니다 이제 시작하죠 먼저 App Store 서버 API를 여러 버전의 StoreKit와 함께 사용하는 방법 즉 StoreKit와 StoreKit 2에 관해 다루고 StoreKit 2를 지원하는 iOS 버전인 iOS 15 이후의 클라이언트와 그렇지 않은 클라이언트를 지원하는 방법을 논의할게요 먼저 App Store 서버 API로의 요청이 어떤 모습인지 살펴보죠 여기 있는 5개의 API는 originalTransactionId를 경로 매개 변수로 활용합니다 따라서 originalTransactionId를 사용하는 API를 호출하기 쉬운데 영수증과 서명한 거래, 서명한 갱신과 알림에서 수신하죠 다음은 탐색 및 주문 ID 엔드포인트입니다 이 엔드포인트는 고객이 제공한 orderId를 사용하여 쿼리를 지원하죠 이를 통해 고객 질문에 잘 대응할 수 있는데 고객은 각 거래의 영수증으로 orderId를 받지만 originalTransactionId를 받지 않기 때문입니다 이를 통해 고객의 질문에 바로 응답할 수 있고 고객이 손에 쥔 데이터를 참고할 수 있죠 마지막 엔드포인트는 알림과 연관되어 있는데 Alex가 담당한 세션에서 다루겠습니다

이제 originalTransactionId를 기존 StoreKit의 어디에서 구할 수 있는지 보죠 통합 앱 영수증으로 verifyReceipt를 호출하면 App Store 서버 API를 호출할 때 사용하는 originalTransactionId는 사용자가 구매한 거래의 영수증의 in_app 필드에 나타나며 latest_receipt_info와 pending_renewal_info에도 나오죠 originalTransactionId를 기존 StoreKit 거래 중 어디에서 얻는지 알았으니 고객과 App Store 서버와 여러분의 서버 사이의 전체 흐름을 살펴봅시다

먼저 여러분의 서버에서 앱 영수증을 확보하고 여러분 서버에서 verifyReceipt로 앱 영수증을 호출하세요

그러면 해독한 영수증을 반환할 겁니다 해독한 영수증에서 이전에 보여준 방법으로 모든 originalTransactionId를 수집하세요 다음은 거래 이력 가져오기 엔드포인트를 호출할 때 수집한 originalTransactionId 중 하나만 사용하면 이 사용자의 거래 이력을 서명한 거래로 반환할 겁니다 거래에는 비소모성 재화 환불된 소모성 재화 비갱신 구독과 자동 갱신 구독을 포함하죠 그리고 특정 구독의 최신 서명 거래와 서명 갱신 정보를 원하면 모든 구독 상태 엔드포인트를 해당 originalTransactionId로 호출하십시오 그러면 제시한 originalTransactionId에 해당하는 구독의 서명 거래 및 갱신 정보를 반환할 겁니다 이제 StoreKit 2 거래에서 originalTransactionId가 어떻게 활용되는지 보죠 이건 거래에서 originalTransactionId를 획득하는 클라이언트의 코드입니다 StoreKit 2를 지원하는 기기 그러니까 iOS 15 이후의 기기에서는 인증 및 해독한 거래에서 originalID 속성을 얻어 originalTransactionId를 알아낼 수 있죠 서버 측의 예시로 서명한 JWS 거래가 있는데 App Store 서버 API와 App Store 서버 알림에서 서명한 거래 및 갱신에서 받는 데이터 유형의 예입니다 여기서는 originalTransactionId가 위쪽에 있는 필드죠

다음은 StoreKit 2 거래에서 고객과 App Store 서버 여러분 서버의 전체 흐름을 봅시다 먼저 기기의 서명한 거래를 보죠 StoreKit 2로 기기에서 이 거래를 인증할 수 있습니다 기기의 상태 리스너와 거래 리스너 또는 마지막 거래가 최신 거래와 취소, 환불 정보를 업데이트하여 기록 보관을 위해 여러분의 서버로 전송되죠 예를 들어 구독 갱신과 구독 프로모션 만료 날짜 등에 업데이트됩니다

여러분의 서버에 거래를 전송하세요 Alex가 다음 섹션에서 설명할 App Store 서버 알림과 함께 이용하면 App Store 서버 API를 호출하지 않고도 구독에 관한 최신 상태를 알 수 있습니다 구독 갱신 날짜를 연장하는 것처럼 구독에 대한 작업이 필요한 경우 서명한 거래의 originalTransactionId로 해당 엔드포인트를 호출하여 필요한 데이터를 받으십시오 StoreKit와 StoreKit 2에서 App Store 서버 API를 사용하는 방법을 알았으니 StoreKit와 StoreKit 2를 지원하는 것에 관해 얘기해 보죠 App Store 서버 API를 활용할 때 StoreKit 2를 완벽히 채택하지 않아도 됩니다 이전에 본 것처럼 originalTransactionId를 기존 StoreKit의 영수증에서 얻을 수 있죠 StoreKit 2는 JWS 거래에서 originalTransactionID를 받습니다

App Store 서버 API를 다른 API와 별도로 사용할 수 있죠 특정 버전의 다른 API에 연동되지 않았습니다 App Store 서버 알림의 경우 버전 1 또는 버전 2 알림과 사용할 수 있죠 하지만 버전 2 사용을 추천하는 이유는 구독의 변경 사항을 알리고 안전한 JWS 형식을 사용하며 Alex의 세션에서 더 많은 이유를 다룰 겁니다 하지만 App Store 서버 API를 버전 1 알림과 사용하거나 알림과 사용하지 않아도 되죠 다음은 이전에 소개해 드린 마이그레이션 작업 완료 후 새로운 구입을 처리하는 방법을 논의하겠습니다 StoreKit를 사용하는 기기의 새로운 구입을 지원하려면 새로운 영수증을 받아 여러분의 서버로 전송하여 이전에 보여 드렸던 것과 똑같은 단계를 통해 새로운 데이터를 수집하면서 새로운 영수증으로 verifyReceipt를 호출하고 latest_receipt에서 새로운 originalTransactionId가 있는 해독 영수증을 받아 다른 originalTransactionId와 영수증의 in_app 섹션을 비교하여 여러분의 거래 정보를 묶으면 되죠 그리고 새로운 originalTransactionId로 필요에 따라 App Store 서버 API를 호출하여 모든 구독 상태 엔드포인트 등을 호출해야 한다면 해당 구독에 관한 최신 상태를 얻을 수 있습니다 App Store 서버 API를 StoreKit와 StoreKit 2에서 어떻게 사용하는지 다뤘으니 JSON 웹 토큰 서명의 자세한 내용을 알아보죠 App Store 서버 API를 호출하는 요구 조건입니다 여러분의 개발자 계정이 App Store 서버 API의 호출자임을 인증하기 위해서 JSON 웹 토큰을 사용하는데 JWT라고도 부르며 이거로 요청을 인증하죠 이 토큰은 모든 요청 시 여러분의 서버 호출의 인증 헤더로 포함해야 합니다 JWT는 헤더, 페이로드, 서명으로 구성되죠 다음은 여러분의 앱에 맞게 JWT를 구성하는 법을 살펴볼게요

여기서는 JSON 웹 토큰이 어떻게 구성되는지 볼 수 있고 헤더와 페이로드의 구조도 볼 수 있죠 토큰 자체는 세 부분으로 나뉘며 마침표로 분리되는데 base64 인코딩 헤더 base64 인코딩 페이로드 그리고 base64 인코딩 헤더와 페이로드로 구성된 서명으로 서명용 시크릿으로 서명한 거죠 헤더를 구성하는 필드에 포함된 메타데이터는 데이터에 서명하는 방식입니다 여기서 중요한 필드는 키 ID로 App Store Connect의 개인 키 ID죠 JWT를 서명할 때 사용하는 키와 같아야 합니다

페이로드에는 애플리케이션 고유의 추가 정보가 포함되어 있죠 'App Store 서버 API에 사용할 API 키 생성'이라는 문서를 참고하여 API 키를 획득하는 추가 정보와 지침을 얻으십시오 각 필드의 자세한 사항은 'API 요청을 위한 토큰 생성' 문서를 참고하세요

헤더와 페이로드에 적절한 정보를 입력했으면 JWT를 서명해야 하는데 키 ID에 맞는 인증서를 사용해야 하죠 언어와 상관없이 사용할 수 있는 핵심 의사 코드입니다 먼저 아까 봤던 헤더에 제공한 키 ID에 맞는 개인 키를 가졌는지 확인하십시오 그리고 개인 키와 헤더 페이로드가 있는 JWT 라이브러리가 노출하는 서명 함수를 호출하세요 헤더에 서명 알고리즘이 포함돼 있으므로 JWT 라이브러리가 제공된 알고리즘에 따라 서명하죠

마지막으로 모든 구독 정보 엔드포인트로 cURL 호출 인증 시 이 토큰을 사용하는 예시가 나와 있습니다 $token과 $originalTransactionId를 여러분이 생성한 토큰 값과 원하는 originalTransactionId로 각각 대체하십시오 이제 서명한 거래가 여러분에게 전송됐는지 App Store에 의해 서명됐는지 인증하는 방법을 보죠 서명한 거래의 핵심은 JavaScript Object Notation 또는 JSON으로 암호학적으로 서명된 오브젝트여서 App Store와 서버 사이의 조작을 감지할 수 있죠 서명한 거래는 JSON 웹 서명 또는 JWS 형식으로 서명합니다 App Store가 전송한 서명 거래는 JWS 형식으로 도착하죠 수신한 JWS를 인증하면 데이터가 App Store에서 왔고 콘텐츠가 조작되지 않았음을 인증할 수 있습니다 이제 서명한 거래를 인증하는 방법을 살펴보죠 먼저 base64로 헤더를 해독하고 alg 클레임으로 사용할 서명 알고리즘을 결정합니다 이는 JWS 인증의 일부로 사용되죠 x5c 클레임의 인증 체인은 Apple이 발급하며 클레임의 인증은 데이터가 제대로 서명됐고 조작되지 않았음을 나타냅니다 App Store 개발 문서를 참고하여 추가 정보와 JWS 인증 방법을 알아보세요 요약하면 x5c 체인은 인증서 체인이죠 성공적인 인증서 체인의 인증은 데이터를 믿을 수 있고 Apple이 서명했음을 알려 줍니다 인증서 체인은 순서가 중요하죠 먼저 루트 인증서가 옵니다 루트 인증서 뒤에 추가 인증서가 뒤를 잇는데 각 인증서를 이전 인증서로 서명하는 거죠 체인의 마지막 인증서를 리프 인증서라고 하겠습니다

첫 인증서는 루트 인증서라고 하며 자체적으로 서명하죠 이 인증서는 Apple의 인증 기관에서 획득하는 루트 인증서와 일치해야 합니다 인증서가 맞지 않으면 체인을 신뢰할 수 없죠 체인의 마지막 인증서인 리프 인증서는 JWS에 서명하는데 사용되는 인증서입니다 App Store가 보내는 JWS의 헤더가 어떤 모습인지 보여 주는 예죠 먼저 JWS 서명에 사용된 알고리즘이 있습니다 다음은 x5c 인증서 체인으로 인증서가 순서대로 나열돼 있죠 이제 높은 수준에서 x5c 인증서 체인을 생성하는 모습을 보겠습니다 먼저 Apple 인증 기관의 루트 인증서에서 시작하죠 그리고 루트 인증서로 중간 인증서에 서명합니다 중간 서명 인증서는 다시 리프 인증서에 서명하는 데 쓰죠

x5c 인증서 체인 생성에 관해 다뤘으니 체인 인증은 어떻게 하는지 살펴봅시다 리프 인증서부터 시작하여 중간 서명 인증서로 서명했는지 확인하죠 그리고 중간 서명 인증서를 루트 인증서가 서명했는지 확인합니다 추가로 루트 인증서는 Apple 인증 기관의 인증서와 같아야 하죠 모든 단계에 성공했다면 전체 체인이 진짜인 것으로 인증합니다 인증서 체인을 확인할 수 있는 메서드를 얘기해 보죠 OpenSSL을 이용하여 x5c 인증서 체인을 인증하는 명령어죠 부분으로 나누면 포괄적으로 verify 명령어가 인증을 위한 인증서를 통과하게 해 줍니다 -trusted 플래그는 인증서를 신뢰할 수 있게 하는데 다음 인증서를 인증하는데 사용하는 인증서라는 의미죠 이 경우 Apple 인증 기관에서 획득한 루트 인증서를 통과시키므로 신뢰할 수 있습니다 이를 이용하여 체인의 다음 인증서인 WWDR 인증서를 인증하죠

-untrusted 플래그는 인증을 원하는 인증서에 신뢰하는 인증서를 쓸 수 있게 해 줍니다 여기서는 먼저 Apple 인증 기관의 WWDR 인증서를 통과하는데 루트 인증서로 서명한 거죠 이는 x5c 체인의 두 번째 인증서와 일치해야 합니다 최종적으로 리프 인증서가 마지막 인증서인데 이전 인증서로 서명했죠 인증이 성공하면 성공 코드를 반환합니다 이제 해독한 정보를 사용할 수 있죠 인증에 성공하지 못한 경우 반환된 에러 코드를 바탕으로 문제를 식별합니다 인증이 불가능하면 데이터가 조작되어 사용하면 안 되죠 App Store 개발자 문서를 통해 OpenSSL을 사용하는 x5c 인증서 체인 인증 설명서를 참조하세요 서명된 거래를 인증하기 위해 작성할 만한 의사 코드입니다 먼저 인증하려는 JWS를 획득하죠 그리고 JWS 라이브러리가 요구하는 인증서를 가져가세요 적절한 인증서로 JWS 라이브러리의 verify 함수를 호출하세요 JWS에 서명하는 인증서가 리프 인증서인데 일부 라이브러리는 전체 체인 통과를 요구하죠

호출이 성공하면 과업을 계속할 수 있습니다 App Store 서버 API 호출로 인한 결과라면 인증된 데이터를 저장할 수 있죠 알림의 경우 Alex가 담당한 세션에서 자세히 설명할 겁니다 JWS를 인증할 수 없는 경우 JWS를 사용하지 마세요 데이터가 조작됐거나 App Store가 보낸 게 아닌 거죠 알림으로 보안을 강화하는 방법은 Alex가 자세히 설명할 겁니다 App Store 개발자 문서를 통해 JWS의 인증과 처리에 관한 지침을 확인하세요 이제 verifyReceipt에서 App Store 서버 API로 마이그레이션하는 사례를 검토하죠 먼저, 최신 상태를 확인하고 싶은 구독자의 사례를 살펴봅시다 개인 구독의 모든 변화에 관해 최신 정보를 알 수 있죠 이전에는 구독자의 최신 상태를 열람하려면 verifyReceipt를 호출하고 expirationIntent나 gracePeriodExpiresDate 등의 필드를 바탕으로 현재 상태를 판단했습니다 이제 App Store 서버 API의 모든 구독 상태 보기를 호출하여 구독 상태의 최신 정보를 얻을 수 있죠 상태 필드에 포함되는 정보는 현재 상태와 가장 최근에 서명한 거래 갱신 정보 등이 있습니다 이를 실행할 수 있는 흐름을 살펴보죠 먼저 해독한 영수증을 통해 앞에서 살펴본 것처럼 originalTransactionId를 구하세요 그리고 모든 구독 상태 보기 엔드포인트를 호출할 때 originalTransactionId를 사용하면 가장 최근에 서명한 거래와 거래의 갱신 정보를 반환합니다 이제 최신 거래를 획득하는 사례를 살펴보죠 최신 거래를 획득하는 건 사용자가 구입한 항목과 갱신한 항목, 구독 상태 변화 등을 알 수 있습니다 이전에는 사용자의 최신 거래 정보를 획득하려면 verifyReceipt를 호출하여 in_app 배열을 사용하고 latest_receipt_info를 검토하여 사용자의 모든 거래 정보를 살펴봐야 했죠 App Store 서버 API로 최신 거래 정보를 얻으려면 거래 이력 가져오기 엔드포인트로 사용자의 모든 구입 이력을 볼 수 있습니다 또한 페이지 매김과 새로운 필터 및 정렬 기능을 다룬 WWDC 22 세션 '앱 내 구매 신규 기능'으로 필요한 데이터를 효율적으로 가져올 수 있죠

이 작업의 흐름을 살펴봅시다 해당 사용자의 originalTransactionId로 거래 이력 가져오기 엔드포인트를 호출하면 이 사용자의 거래 이력을 반환하는 것을 비롯해 서명한 거래를 원하는 대로 필터, 정렬, 페이지 매김 하죠

마지막으로 appAccountToken을 채택하는 사례를 살펴봅시다 appAccountToken 필드는 UUID를 제공하여 StoreKit 2 거래를 사용자와 연관 지을 수 있죠 그리고 서명한 거래와 서명한 갱신 해당 거래의 알림에 appAccountToken이 나타납니다 StoreKit에서는 appAccountToken을 지원하지 않았는데 StoreKit 2에 새로 추가된 기능이기 때문이죠 이제 StoreKit에서도 applicationUsername 필드에 UUID를 공급하여 기존 StoreKit 클라이언트와 호환되도록 했습니다 이 조건에서 UUID는 appAccountToken의 모든 기능을 지원하죠 기존 사용자의 appAccountToken은 verifyReceipt로 돌아오며 App Store 서버 API 호출과 App Store 서버 알림은 StoreKit와 StoreKit 2 사용자 모두에게 나타납니다 App Store 서버 API 부분을 마쳤습니다 이제 Alex가 App Store 서버 알림 버전 2 마이그레이션을 다룰 거죠 고마워요, Gabriel 제 이름은 Alex이며 App Store 서버 알림 버전 2를 소개할 수 있어 기쁩니다 먼저 버전 2 알림을 시작하는 방법을 다루고 다른 모델과의 차이점과 개선점을 살펴본 뒤 알림을 놓쳤을 때 복구하는 경우를 얘기하고 복구를 도울 수 있는 새로운 자원을 소개하죠 마지막으로 알림을 통해 고객 행동의 통찰을 얻고 구독 생애 주기에 관한 정보 습득의 기회로 활용하는 방법을 알아보겠습니다 먼저 알림에 관한 짧은 소개와 사용 범위를 살펴보죠 App Store 서버 알림은 여러분 앱의 사용자가 특정 행동을 취했을 때 여러분께 보내는 메시지입니다 알림은 크게 두 카테고리로 나뉘는데 구독 소식과 환불 소식이며 추가 상황을 포함하기 위해 작업 중이죠 사용자 행동 분석을 위해 알림을 제공하며 여러분의 앱에는 이런 기능이 없을 수 있습니다 예를 들어 가장 흔한 사례 중 하나는 구독 갱신이죠 이 거래가 가능해졌을 때 사용자가 앱에 없을 수도 있습니다 App Store 서버 알림은 이런 문제를 해결하기 위해 구독을 갱신해야 할 때 선제적으로 최신 거래 정보를 여러분의 서버로 전송하죠 버전 2 알림은 StoreKit 2 모델과 비슷한 점이 많고 방금 Gabriel이 언급한 App Store 서버 API와 비슷합니다 하지만, 함께 사용할 수 있어도 별도의 도구이며 서로 다른 시점에 채택할 수 있죠 가장 중요한 건 버전 2 서버 알림으로 StoreKit 2가 없는 iOS 15 이전의 클라이언트를 계속 지원할 수 있습니다 우리는 버전 2 알림을 전체 구독 생애 주기에 걸친 사용자의 정보를 가장 면밀하고 유연하게 제공하는 도구로 만들려고 노력했죠 프레젠테이션 후반에 더 깊이 다루겠지만 알림에서 제공하는 정보는 앱 외부에서 발생했을 때 거의 포착할 수 없는 것들입니다 알림과 버전 2 알림에 대해 관심이 생기셨기를 바랍니다 이 프레젠테이션에서는 알림을 도입하는 방법과 알림 수신의 모범 사례를 다루지만 그게 전부는 아닙니다 알림에 관한 정보와 사례 적용을 다루는 최근 영상을 참고하여 더 많은 정보를 확인하십시오 먼저 버전 2 알림을 설정하는 법을 보죠 알림을 설정하는 것부터 첫 알림을 받는 것까지 소개할 겁니다 먼저 App Store Connect의 앱 페이지로 가세요 스크롤 하면 아래쪽에 App Store 서버 알림 섹션이 있죠 프로덕션과 샌드박스 옵션이 있습니다 환경마다 별도의 URL과 별도의 알림 버전이 포함돼 있죠 프로덕션 설정을 위한 옵션 페이지의 예시입니다 샌드박스 설정도 똑같죠 만약 버전 1 알림을 사용하신다면 샌드박스 환경에서 버전 2 알림을 먼저 사용해 보세요 알림을 테스트하기 좋은 환경이며 프로덕션 설정에도 영향을 주지 않죠 샌드박스 설치 버튼을 선택하고 여러분의 서버 URL을 입력한 뒤 버전 2 알림을 선택하세요

알림을 발동하기 전에 여러분의 서버 엔드포인트에 인증받은 HTTPS 인증서가 있는지 확인하십시오 Apple의 공개 IP 접근을 서버에 허용했는지도 확인하세요 알림 설정 시 가장 일반적인 실수가 방화벽과 인증서에 관련돼 있죠 갑자기 알림이 오지 않는다면 초기 문제 해결 단계에 이런 것들을 확인해 보세요 이제 첫 알림을 받을 준비가 됐습니다 샌드박스에서는 앱 내 구독처럼 다양한 행위가 알림을 작동하게 하죠 하지만 테스트 때는 사용이 쉽도록 알림 발동은 App Store 서버 API의 일부인 테스트 알림 요청 엔드포인트의 사용을 추천합니다 이 엔드포인트는 알림 테스트 절차를 자동화하죠 테스트 알림 요청 엔드포인트를 발동하면 곧 알림이 도착할 겁니다 알림 수신에 문제가 있으면 테스트 알림 상태 보기 엔드포인트를 참조하여 알림 발송이 실패한 원인에 대한 현재 상태를 확인하십시오 예를 들어 SSL_ISSUE와 같은 상태는 HTTPS 인증서를 다시 확인하라는 단서죠 설정을 바꿀 때마다 테스트 알림을 발송하는 걸 추천합니다 설정이 바뀐 후에도 알림을 잘 받는지 확인할 수 있죠 이제 방금 수신한 알림을 이해하는 단계로 넘어갑시다

Gabriel이 설명한 거래처럼 알림도 JWS 형식이죠 알림 페이로드를 해독하고 인증하는 방법을 알아봅시다 먼저, 알림을 수신할 때 JSON 바디의 signedPayload 필드를 추출해야 하죠 다음은 Gabriel이 서명한 거래를 인증하는 것과 같은 절차를 밟으면 됩니다 서명한 데이터를 인증하는 것과 같은 절차죠 알림에서 온 서명한 알림 페이로드와 App Store 서버 API에서 온 서명한 거래의 절차가 같습니다 다음은 어떤 앱의 알림인지 확인하는 게 중요하죠 같은 엔드포인트를 공유하는 여러 앱이 있으면 여기서 목표 앱을 정하는 게 좋습니다 그리고 알림을 보낼 앱이 여러분의 앱인지 확인하고 다른 개발자에게 의도된 알림이 아닌지 검토하십시오 마지막으로 알림을 설정한 환경이 여러분이 의도한 환경과 일치하는지 확인하세요 프로덕션 또는 샌드박스가 있죠 App Store Connect는 환경마다 별도의 URL을 허용하므로 이 요구 조건을 확인할 수 있으며 만약 URL을 공유한다면 환경별로 알림을 저장하고 처리하는지 점검하십시오 이제 JWS는 완벽히 인증되어 처리를 위해 저장할 수 있습니다 기본적인 확인 사항 외에도 서버가 알림을 비동기적으로 처리하는지 확인하세요 알림 처리가 너무 오래 걸리면 서버가 타임아웃을 기록하며 알림이 제대로 발송되지 않았다고 가정합니다 그러면 알림을 다시 보내야 하죠 따라서 급하지 않은 처리는 이 함수 밖으로 빼서 App Store 서버가 알림 발송을 성공으로 기록하여 여러분의 서버가 재전송하기 위해 재처리하지 않아도 됩니다 이제 인증 후 알림의 바디를 살펴보죠 첫 필드는 알림 유형과 선택적인 하위 유형입니다 종합하여 알림을 보낸 상황을 알 수 있죠 마지막 알림으로부터 뭐가 변경됐는지 알 수 있고 이런 변화가 생긴 이유를 알려 줍니다 notificationUUID는 알림 고유의 식별자죠 서버가 알림을 재시도하면 재시도한 알림은 같은 notificationUUID를 포함합니다 이를 통해 서버가 알림을 처리했지만 성공적인 HTTP 반응 코드를 받지 못한 사례를 감지할 수 있죠 이 필드를 기반으로 재시도로 인한 중복 알림 감지를 추가하는 것도 추천합니다 signedDate 필드는 알림을 생성한 시점을 알려 주죠 재시도 알림을 감지할 때 특히 유용합니다 다음은 appAppleId와 bundleId죠 목표 앱을 감지하는데 중요한 항목입니다 앞에서 얘기한 것처럼 이런 항목을 확인하여 예상값이 맞다는 걸 확인하여 리플레이 공격을 방지할 수 있죠 또한 알림의 환경이 의도한 환경과 맞도록 샌드박스 환경이 프로덕션 데이터로 기록되거나 그 반대 경우가 발생하지 않도록 하십시오

signedTransactionInfo와 선택적인 signedRenewalInfo입니다 서명 시점에 발생한 구입에 관한 최신 상태죠 이 시점에는 알림을 파싱하여 최신 거래와 갱신 정보 상태 변화가 있었던 가장 최근 이유가 남습니다 이제 특정 알림의 설정과 수신을 다뤘으니 버전 2 알림 모형을 살펴보고 구독 생애 주기를 추적하는데 알림을 어떻게 사용할지 버전 2 알림의 설계 원리는 무엇인지 버전 1 알림과 비교하여 알아보죠 버전 2는 구입 상태에 관한 정보를 보내는 것에 있어 다른 철학을 도입했습니다 최근 이력과 모든 알림을 전부 전송하는 대신 버전 2 알림은 가장 최신의 정보에 집중하죠 가장 최신의 거래 정보와 구독의 경우에는 임박한 갱신 정보입니다

알림을 통해 구독 생애 주기의 모든 단계에 관한 정보를 제공하죠 따라서 알림은 구입이나 구독에 관한 가장 최신 정보만 포함합니다 이를 통해 알림은 구독 상태에 관한 완벽한 타임라인을 생성하죠 만약 전체 거래 이력을 봐야 하는데 거래 이력에 접근할 수 없다면 거래 이력 보기 엔드포인트와 함께 사용하여 사용자의 전체 거래 이력을 페이지 매김 및 필터로 검색하세요 둘째, 버전 1 알림은 클라이언트의 StoreKit 2 사용을 요구하지 않죠 예상하신 대로 버전 2도 그렇습니다 클라이언트에서 어떤 프레임워크를 사용하든 바로 버전 2 알림의 이점을 활용할 수 있죠 마지막으로, 버전 2 알림은 정보를 더 자세하게 제공하고 새로운 유형과 새로운 하위 유형을 추가하여 처리할 수 있는 상황을 확장합니다 이를 통해 더 많은 상황에 대처하고 구독 생애 주기의 모든 단계에 알림을 제공하죠 추가한 주요 상황으로는 기한 만료가 있고 자동 갱신 상태 변화와 관련된 자세한 정보도 있고 환불 과정과 관련된 상황도 포함합니다 이제 지금까지 다룬 상황의 복잡성을 보여 주고 구체적인 예시를 제공하기 위해 구독의 처음부터 끝까지 각 단계에서 알람이 어떤 정보를 줄 수 있는지 보죠 구독을 앞둔 사용자를 상상해 보십시오 구독 시 사용자는 구독 갱신 상태로 진입하여 SUBSCRIBED의 하위 유형인 INITIAL_BUY 알림을 보내거나 프로모션이면 OFFER_REDEEMED의 INITIAL_BUY 알림을 보냅니다 알림에는 처음 서명한 거래와 서명한 갱신 정보를 포함합니다 시간이 지나 구독이 갱신되고 갱신 상태에 남아 있죠 매번 갱신할 때 DID_RENEW 알림을 보내고 다음 서명한 거래 정보도 함께 보냅니다 사용자가 자동 갱신을 비활성화하여 구독 만료 상태가 되면 DID_CHANGE_RENEWAL_STATUS의 하위 유형인 AUTO_RENEW_DISABLED 알림을 받죠

기간 끝에 자동 갱신을 활성화하지 않으면 만료 상태가 되고 EXPIRED의 하위 유형인 VOLUNTARY 알림을 받습니다 이제 궁금해하시겠죠 다른 알림 유형은 어디 있는지를요

알림을 통해 본 구독 생애 주기입니다 많은 일이 벌어지고 있죠 이 도표도 전체 경우를 다루지 않습니다 예를 들어 환불 및 취소 생애 주기는 제외돼 있죠 이 도표는 버전 2 알림이 아우르는 온갖 상황을 나타내며 구독 생애 주기의 모든 단계에 관한 정보를 제공합니다

또한 모든 전환 상태도 아우르기 위해 노력하죠 이는 알림이 구독을 추적하는 단일 정보원이 되어 알림의 효용을 높이고 구독자 여정의 모든 단계를 관장하고 있다는 자신감을 높일 수 있습니다 하지만 모든 데이터가 여기 있음에도 불구하고 가용한 모든 유형을 작업할 필요는 없죠 갱신 설정의 변경과 관련된 알림을 처리하는 것만으로도 가치를 제공할 수 있습니다 특히 지금 입문하셨다면 여러분의 상황에 가장 유용한 알림 유형부터 시작하세요 이제 서버를 설정한 뒤 어떻게 되는지 알아보죠 모든 것이 순조롭게 흘러가다가 서버가 장애를 일으킵니다 그게 며칠이 됐든, 몇 분이 됐든 아니면 알림을 하나만 놓쳤든 이 문제를 해결하기 위한 절차를 알아보도록 하죠 여러분의 서버를 상상해 보세요 설정을 완료하여 알림을 수신하고 있습니다 언젠가 서버에 문제가 생겨 알림을 못 받게 되죠 계속 여러분의 서버에 전송을 시도하지만 요청이 실패하기 시작합니다 이런 상황을 처리하는 방법은 여러 가지가 있죠 하나는 그냥 기다리는 겁니다 서버로부터 성공적인 상태 코드를 받지 못하거나 아예 접속이 안 되면 문서화된 재시도 정책에 맞게 알림을 다시 보내죠 버전 2 알림에서는 재시도 주기가 바뀌는데 처음에는 1시간 뒤에 보내고 다음에는 12시간 뒤 24시간, 48시간, 그리고 마지막으로 72시간 뒤에 보냅니다 서버 장애가 1시간 미만이면 기다리는 게 좋죠 알림이 첫 실패 후 1시간 뒤에 다시 전송되니까요

언젠가는 서버를 복구하여 다시 알림을 받을 수 있겠죠 먼저, 못 받은 알림과 관련 없는 새 알림을 받습니다 알림은 지연 시간 후에 전송되므로 서버가 다시 켜져도 못 받았던 알림들을 즉시 수신할 수 없죠

시간이 조금 지나면 못 받았던 알림이 들어오고 그중에는 새 알림도 섞여 있을 겁니다

그러면 이게 궁금할 수 있죠 이때 받는 알림이 첫 알림인지 재시도된 알람인지요 알림을 살펴봅시다

이 알림은 몇 개의 필드만 있죠

알림에는 signedDate 필드가 있습니다 재시도를 감지하기에 유용한 필드인데 서명 날짜와 수신 날짜를 비교해 볼 수 있죠 만약 서명한 날짜가 알림을 받은 날짜보다 훨씬 이르다면 서버 장애가 있었음을 알 수 있습니다

이런 상황을 상상해 보십시오 같은 구독으로 인한 알림인데 매겨진 숫자가 6과 3인 거죠 originalTransactionId를 비교하여 알 수 있습니다 3번 알림이 6번 알림보다 나중에 도착했다고 해서 6번 알림보다 최신 정보를 포함한다는 의미는 아니죠 때로는 여러분의 서버가 알림을 수신했는데 성공적인 HTTP 200 상태 코드로 응답하지 못했을 수도 있습니다 그러면 여러분의 서버에 알림이 재전송되죠 앞에서 얘기한 것처럼 notificationUUID 필드를 확인하여 중복 요청을 걸러내십시오 성공적으로 알림을 기록했더라도 재시도된 알림 수가 많을 수도 있습니다 이런 경우에는 알림을 수신할 때마다 HTTP 200 응답을 보내도록 확인하십시오 또한, 시의적절하게 대응하시고 성공적으로 응답할 때까지 대규모로 처리하여 우리 측에서 타임아웃을 기록하고 알림을 재전송하지 않도록 하세요 때로는 서버 장애가 길어져서 다음 재시도가 며칠 이후거나 장애가 너무 길어져서 재전송 횟수가 소진될 수도 있죠 받지 못한 알림을 복구하는 다음 방법은 알림 이력 가져오기 엔드포인트입니다

새롭게 알림 이력 가져오기 엔드포인트를 도입하여 여러분의 서버에 전송한 알림의 6개월 기록을 제공하죠 '앱 내 구입 새로운 소식' 영상에서 이 엔드포인트의 개요와 다른 멋진 기능을 확인하실 수 있습니다 이 영상에서는 이 엔드포인트의 모범 활용 사례에 집중하고 도움이 되는 상황을 상정할게요 서버 장애를 해결하면 장애의 시작과 종료 시점을 기록하십시오 알림 이력 가져오기 엔드포인트는 특정 시간대를 검색할 수 있습니다 장애의 시작과 종료 시점을 명시하여 놓친 알림만 처리하여 전체 이력을 검토하는 수고를 아낄 수 있죠 복구 속도도 빨라지고 이미 기록된 알림의 재처리 작업도 줄어듭니다 알림 이력 가져오기 엔드포인트는 알림 유형에 따른 필터도 가능하죠 만약 장애가 길어져서 알림 개수가 많다면 유형에 따라 알림을 필터하세요 즉시 영향을 주는 유형인 DID_RENEW와 EXPIRED부터 말이죠 그러면 중요한 사례부터 대처할 수 있을 겁니다 알림 유형을 통과시킬 때 notificationSubtype 필드가 빠져 있으면 하위 유형이 없는 알림만 반환하죠 따라서 예에 나온 DID_RENEW notificationType은 DID_RENEW의 하위 유형인 BILLING_RECOVERY를 반환하지 않습니다

마지막으로 알림 이력 가져오기 엔드포인트는 originalTransactionId를 이용하여 특정 사용자로 필터할 수 있죠 다시 구독 생애 주기를 생각해 보면 사용자 여정의 모든 단계를 알림으로 알 수 있도록 작업했다고 했습니다 따라서 단계를 건너뛰는 걸 인지하셨다면 예를 들어 구독 갱신에서 만료로 바로 넘어갔다면 해당 사용자의 알림을 놓쳤다는 것을 나타내죠 고객 지원의 맥락에서도 유용한데 사용자의 계정이 예상과 다른 상태에 있을 때 해당 사용자의 알림 이력을 검색할 수 있습니다

알림 이력 가져오기 엔드포인트의 응답을 살펴보죠 간단하게 응답의 특정 값만 표시했습니다

notificationHistory 배열 안에 응답에 반환된 값이 있죠

배열의 각 항목은 하나의 알림을 나타냅니다

서명 페이로드 필드는 여러분에게 전송된 알림을 포함하죠

둘째, firstSendAttemptResult 필드가 있습니다 이 필드는 우리 서버에서 기록한 초기 알림 시도 결과에 따른 여러 값 중 하나를 포함하죠 성공적인 사례면 값이 SUCCESS입니다 하지만 방금 얘기한 것처럼 알림이 서버에 도착하지 않는 경우가 있죠 이 메시지는 여러분이 문제를 찾을 수 있도록 올바른 방향을 제시하고 해결 절차를 간소화합니다 예를 들어 여기는 SSL_ISSUE가 있죠 이는 SSL 인증서나 서버 절차에 문제가 있다는 걸 나타냅니다 이 필드는 도착하지 않은 알림으로 서버 문제를 진단하는 더 나은 가시성을 제공하죠 테스트 알림 상태 가져오기 엔드포인트에도 이 필드가 있어 테스트 알림을 사용할 때 이 기능을 제공합니다 온보딩이나 문제 해결 중에 사용하거나 서버 장애의 근본 원인을 알아낼 때 사용할 수도 있죠 알림은 사용자 이력의 모든 사례를 포함하지 못할 수 있습니다 방금 알림을 채택했다면 기존 고객의 이력은 포함할 수 없죠 알림 이력 가져오기 엔드포인트보다 더 긴 시간에 관한 이력을 살펴보고 싶을 수도 있습니다 그때는 거래 이력 가져오기 엔드포인트가 필요하죠 이 엔드포인트는 앞서 Gabriel이 설명한 것처럼 여러분이 알림을 사용하기 전의 고객 이력을 제공하여 이런 문제를 해결할 수 있습니다 이제 알림이 구입 이력을 넘어 어떤 통찰과 기회를 제공할 수 있는지 보죠 버전 2 알림에 추가된 것 중 하위 유형 필드가 있는데 notificationType 필드에 맥락을 더해 줍니다 이 필드는 특정 상황에서 더 많은 정보를 제공하는데 EXPIRED나 DID_CHANGE_ RENEWAL_STATUS 등이 있죠 예를 들어, EXPIRED에서는 같은 조처를 하게 되는데 구독을 비활성화 처리하고 제품 접근을 막는 거죠 하지만 사용자가 만료된 이유를 아는 것이 유용할 수 있습니다 청구 문제나 자발적인 선택일 수도 있고 동의하지 않은 가격 인상 때문일 수도 있죠 다른 알림인 DID_CHANGE_RENEWAL_STATUS는 알림을 통해 추가 정보와 기회를 얻는 아주 좋은 예입니다 겉으로 봤을 때는 우선순위가 낮아 보이죠 즉시 조처할 필요가 없습니다 제품 접근을 철회해야 하는 중요한 알림은 EXPIRED 알림이죠 속지 마십시오 여기에도 기회가 많습니다 이 알림은 구독이 만료되기 전에 고객의 마음을 돌리는 좋은 기회를 제공하죠 특히 애플리케이션 밖에서 자동 갱신을 취소할 수 있으므로 만료 날짜 전에 갱신 상태의 변화에 관해 받는 마지막 알림일 수 있습니다 이 알림은 고객 행동에 관한 통찰도 제공하죠 이 알림으로 구독자가 갱신 기간 중 언제 취소하는지 알 수 있죠 갱신 하루 전인지 새로운 구독자가 서비스에 가입하고 바로 자동 갱신을 취소하는지 말이죠 이 정보는 취소 원인을 파악하고 제품을 개선하는데 중요한 역할을 할 수 있습니다 마지막으로 특정 상황은 사용자의 이력에 알림으로만 기록될 수 있죠 예를 들어 사용자가 자동 갱신을 취소했다가 구독 기간이 만료되기 전에 다시 활성화할 수 있는데 전부 구독 기간 안에 벌어지는 일이어서 구독의 장기 상태에는 영향을 주지 않습니다 이러한 결정들은 고객을 이해하는데 중요하며 알림은 이런 상황을 감지하고 기록하여 정보를 제공합니다 종합적으로 알림은 고객의 행동을 이해하는 기회를 만들고 개선하기 위해 고객 여정의 모든 단계와 상황을 포괄하여 정보를 제공하죠 결론적으로 오늘은 App Store 서버 API와 App Store 서버 알림을 다뤘습니다 이는 구입을 관리하고 추적하는 능력을 개선하기 위한 도구죠 개선된 메시지 유형을 사용하여 많은 사례를 포함합니다 모든 클라이언트에서 사용할 수 있고 StoreKit와 StoreKit 2에서 모두 호환되어 구독 생애 주기를 관찰하는 능력을 개선할 수 있죠 마지막으로, 샌드박스와 프로덕션에 모두 제공되며 어떤 시스템에 추가해도 좋습니다 함께해 주셔서 감사드리며 멋진 WWDC 되세요