What's new with in-app purchase

♪ 잔잔한 힙합 연주 음악 ♪ ♪ 안녕하세요, 환영합니다 '앱 내 구입의 새로운 사항'입니다 저는 Dani고 StoreKit 팀의 엔지니어입니다 오늘 저는 동료 Ian과 발표할 건데요 올해 우리가 앱 내 결제에 도입할 새로운 개선 사항들을 알아보겠습니다 작년에 우린 StoreKit 2를 공개했습니다 처음부터 다시 설계한 신규 API의 집합으로 앱 내 결제 통합을 단순하게 했습니다 StoreKit 2는 최신 언어 기능을 사용하는데요 그것엔 async/await 패턴을 사용한 Swift 동시 실행도 포함됐습니다 서버 쪽에서는 이런 신규 StoreKit 기능들을 완전히 새로운 App Store Server 엔드포인트들로 보완했습니다 이 서버 엔드포인트들은 거래 정보 회수를 쉽게 해주고, 서버의 구독 상태를 확인해줍니다 App Store 서버 알림의 두 번째 버전도 출시해서 서버의 구독 수명 주기의 추적을 그 어느 때보다 쉽게 했습니다 오늘 저는 이 신규 API들과 함께 신규 StoreKit 모델에 도입하는 개선 사항들도 알려드리겠습니다 그리고 흥미진진한 신규 서버 업데이트를 Ian이 설명해주겠습니다 App Store Server API 개선 사항들과 App Store 서버 알림의 새로운 API까지 포함해서요 먼저 제가 여러분 앱의 구매를 확인해주는 신규 App Transaction API를 설명하겠습니다 다음으로 StoreKit 모델들에 우리가 추가한 신규 속성들을 자세히 알아볼 겁니다 그리고 새로운 SwiftUI 친화적 API를 소개하겠습니다 구독 제공 코드 획득과 고객에게 앱을 평가해달라고 부탁하기 위한 겁니다 그리고 StoreKit Messages를 소개해드리겠습니다 고객들에게 App Store 메시지를 표시하는 데 사용되는 API입니다 그리고 마지막으로 여러분이 원래의 StoreKit API에서 최신형으로 마이그레이션할 때 applicationUsername의 보존을 위해 우리가 추가하는 개선 사항도 설명하겠습니다 이번 발표 내내 저는 참 좋아하는 앱 Food Truck을 사용하겠습니다 Food Truck 앱에서 저는 여러 도시를 방문하여 도넛을 바달하는 도넛 푸드 트럭을 관리합니다 그럼 시작해보죠 App Transaction을 소개합니다 App Transaction은 새로운 API로 여러분 앱의 구매를 확인해줍니다 앱 거래는그것이 돌아가고 있는 기기에서의 앱 구매에 대한 서명된 정보를 나타냅니다 그건 JWS를 사용해서 서명됩니다 그리고 원래의 StoreKit API에서 앱 영수증의 앱 세부 사항 부분을 대체합니다 거래 확인과 마찬가지로 StoreKit는 여러분을 위해 앱 거래를 자동으로 확인해줍니다 그런데 여러분이 원하면 자신만의 승인을 수행할 수 있습니다 JWS 서명 승인은 기록이 잘 된 표준입니다 여러분은 공개 기록을 참고해서 자신만의 승인을 수행하면 됩니다 StoreKit는 필요할 때 앱 거래의 자동 업데이트를 처리해줍니다 그런데 사용자가 뭔가 잘못됐다고 생각하는 드문 경우에는 그걸 새로 고침 할 수 있습니다 여러분은 앱에 있는 UI를 제공해서 고객들이 앱 거래를 새로 고침 할 수 있게 해야 합니다 이는 사용자 동작에 대한 반응으로만 사용되어야 합니다 앱 거래를 새로 고침 하는 건 사용자의 인증을 유도하기 때문입니다 App Transaction을 반길 이유엔 사기 방지만 있는 게 아닙니다 여러분이 사업 모델을 유료 앱에서 앱 내 결제를 제공하는 무료 앱으로 전환하고자 할 때나 여러분의 고객 중 누가 앱을 사전 주문했는지 궁금할 때나 앱이 언제 구매됐는지만 알고 싶을 때 그 모든 걸 App Transaction으로 처리할 수 있습니다 앱 영수증에서 영수증 페이로드는 여러분의 애플리케이션에 관한 구매 데이터를 발생한 모든 앱 내 결제를 통합했습니다 StoreKit에서 이제 그것들은 두 가지의 구성 요소로 분리됐습니다 그것들 중 하나는 거래 이력입니다 StoreKit의 거래 API는 사용자의 앱 내 결제 이력 전체에 관한 통찰을 전달합니다 바로 그 기기에서요 이 API들은 여러분에게 필요한 정확한 정보를 찾게 해줍니다 사용자의 최신 거래와 완료되지 않은 거래와 현재 자격을 포함해서요 여러분이 이런 계산을 서버에서 수행하는 걸 선호한다면 App Store Server API에서 사용자 구매 이력을 얻을 수도 있습니다 이와 관련된 흥미로운 업데이트는 나중에 이 세션에서 Ian이 설명할 겁니다 두 번째 구성 요소는 App Transaction입니다 거기에는 여러분의 앱이 돌아가는 기기에서 그것의 유효성 확인에 필요한 데이터가 있습니다 App Transaction을 사용해서 앱의 구매를 확인하는 일은 쉽고 잠시 후에 제가 그 사용법의 예를 설명해드리겠습니다 하지만 먼저 제가 제일 좋아하는 앱에 관한 배경 설명을 조금 해보죠 Food Truck으로 저는 도넛을 배송하고 기본적인 소셜 피드를 확인하고 제 판매 이력을 시각화할 수 있습니다 이 모든 정보를 데이터베이스에 보관하는 일은 제 앱에 꾸준한 비용이 들어서 비용 충당에 도움을 받기 위해 연간 판매 이력 차트를 일시 구매로 바꾸겠습니다 추가로 저는 소셜 피드도 강화하고 싶습니다 그래서 다른 사람들이 제 푸드 트럭에 관해 말하는 내용을 보는 것에 그치지 않고, 도구를 제공해서 저도 고객들의 의견에 관여하려고 합니다 이건 구독 서비스가 될 것이고 월간 이용권과 연간 이용권이 있을 겁니다 Food Truck은 유료 앱으로 시작했지만, 제가 앱 내 결제를 제공하는 무료 앱으로 바꿀 겁니다 하지만 Food Truck을 이미 구매한 제 기존 고객들이 소외감을 느끼지 않게 하고 싶습니다 그래서 전 App Transaction을 사용해서 Food Truck을 구매한 고객들이 비용을 지불한 프리미엄 콘텐츠를 계속 이용할 수 있게 하고 싶습니다 이건 Food Truck의 연대표입니다 최초 출시 때 Food Truck은 가격이 4달러 99센트인 유료 앱으로 시작했습니다 버전 1.0은 도넛 배송과 기본적인 소셜 피드와 판매 이력 차트를 제공했습니다 나중에 버전 8.0이 출시됐을 때 제 사업 모델이 바뀌었습니다 Food Truck은 이제 무료입니다 다만 다양한 앱 내 결제로 프리미엄 기능들을 이용할 수 있죠 이 연간 판매 이력 차트는 이제 비소모성 일시 구매가 됐고, 현재 프리미엄 소셜 피드에 대한 신규 구독 서비스가 생겨서 그걸로 고급 참여 도구를 받을 수 있습니다 이것에 영향을 받을 수 있는 두 종류의 고객을 지금 살펴보겠습니다 Alice는 버전 2.5인 제 Food Truck 앱을 발견했고 디지털 세계에서 도넛을 향한 자신의 열정을 알려야겠다고 결정했습니다 그래서 Alice는 제 앱을 4달러 99센트에 구매했고 자신의 도넛 배송 여정을 시작했습니다 두 번째 고객인 Bob은 친구를 통해 제 Food Truck 앱을 알게 되어 App Store에서 버전 8.2를 무료로 다운받았습니다 이 경우에 무료가 되기 전에 제 앱을 구매한 Alice는 이미 돈을 지불한 모든 프리미엄 콘텐츠를 여전히 이용할 수 있어야 합니다 Alice한텐 프리미엄 소셜 피드 구독을 구매할 선택권이 있지만 저는 처음에 포함됐던 연간 판매 이력 차트 이용권을 거부하고 싶진 않습니다 그런데 Bob은 제 앱을 무료로 구했습니다 그러니 전 알죠, Bob이 앱 내 결제를 완료하기 전엔 기능과 콘텐츠 사용을 열어줄 수 없다는 걸요 그럼 코드에 있는 App Transaction으로 그걸 할 수 있는 방법을 살펴보죠 먼저 앱 거래를 가져오겠습니다 AppTransaction.shared를 호출해서요 이 호출로 제 앱 거래가 들어 있는 VerificationResult를 얻습니다 그 결과 내의 AppTransaction 타입에는 JWS 페이로드가 들어 있습니다 다음으로는 결과를 켭니다 결과가 확인되지 못하면 사용자에게 알리기가 좋은 때입니다, 그들의 앱 구매가 App Store에서 확인되지 못했다는 점을요 그리고 전 그들이 앱 거래를 새로 고침 하도록 유도할 수 있죠 이때 저는 제 앱에 대한 최소한의 체험을 제공할 겁니다 결과가 확인되면 사용자가 제 앱을 구매했는지 확인할 기회로 저는 이걸 활용할 겁니다 제 앱을 구매한 고객들은 그들이 지불한 것에 대한 서비스를 받아야 합니다 이를 위해 저는 원래 앱 버전의 속성을 사용하겠습니다 이 속성은 고객이 제 앱을 처음으로 다운받았을 때의 앱 버전을 알게 해줍니다 제 앱이 앱 내 결제가 있는 무료가 됐던 건 버전 8.0입니다 저는 고객의 원래 앱 버전을 제 기능에 전달할 텐데 그건 사용자가 제 앱을 버전 8.0 이전에 구매했는지 확인해줍니다 그리고 그걸로 저는 사용자들에게 프리미엄 콘텐츠를 제공해야 할 방식을 정보에 근거해 판단할 수 있습니다 제 앱을 구매한 Alice 같은 고객들을 위해 저는 그들이 구매 시점에 받을 자격이 있었던 콘텐츠를 제공할 겁니다 제 경우에는 Alice의 배송을 위해 연간 판매 이력 차트의 잠금을 풀어줄 겁니다 또한 그들이 했던 추가 앱 내 결제도 확인하고 싶습니다 그것도 제공할 수 있게요 그 외에는 제가 사업 모델을 바꾼 다음에 사용자가 제 앱을 다운받았다는 걸 확신할 수 있죠, Bob의 경우처럼요 이때는 사용자의 현재 자격을 확인하기 좋을 수 있습니다 그들이 지불했던 기능들과 콘텐츠의 잠금을 풀 수 있게요 그리고 코드 몇 줄만으로 저는 제 앱의 구매 여부를 확인하고 사용자가 제 앱의 유료 버전을 다운받았는지 확인할 수 있었고 고객이 제 앱을 구매했든 안 했든 제 프리미엄 콘텐츠를 곧바로 제공하기 시작할 수 있습니다 App Transaction으로 여러분은 고객들을 쉽게 지원할 수 있습니다 그들이 초기 지지자였든 최근에 여러분의 앱을 다운받았든 말이죠 이제 StoreKit 모델에 우리가 추가하는 신규 속성들로 넘어가고 싶습니다 이런 속성들 중 첫 번째는 '프라이스 로케일'입니다 프라이스 로케일은 이제 StoreKit 제품들에 포함됩니다 여러분은 본래 구매 API에 접속했던 것에서 프라이스 로케일이 이미 낯익을지도 모릅니다 다음으로는 서버 환경 속성을 자세히 알아보겠습니다 이제 여러분은 거래나 갱신 정보가 발생했던 서버 환경을 구분할 수 있습니다 그리고 최근 구독 시작 일자 속성으로 넘어가보겠습니다 여러분은 고객들의 구독 패턴을 바탕으로 그걸 그들을 위한 정보에 근거한 판단을 내리는 도구로 사용할 수 있습니다 마지막으로 이 속성들에 대한 특별한 고려 사항들을 살펴보겠습니다, 그걸 Xcode에서 StoreKit Testing과 함께 사용할 때요 이 속성들은 예전 운영 체제에서 센티넬 값을 돌려주는데요 그게 무슨 뜻인지는 잠시 후 설명하겠습니다 StoreKit API는 유연성을 감안해서 설계됐습니다 다음을 발표하게 되어 자랑스럽습니다 여러분은 이런 새 속성들을 작년 운영 체제까지 거슬러 올라가 이전 기기들에서도 활용할 수 있습니다 원래는 그것들과 함께 출시되지 않았는데도요 이렇게 하기 위해 여러분이 할 일은 Xcode 14로 앱을 구축하는 겁니다 그럼 이전의 운영 체제들에서 이 속성들을 사용할 수 있습니다 이것이 가능한 건 이 속성들에 대한 실행이 여러분의 앱 내에 컴파일되어 있기 때문입니다 따라서 고객들이 새 버전으로 업데이트할 때 이런 개선 사항들의 혜택을 볼 수 있습니다 운영 체제를 업데이트할 필요 없이 말이죠 그런데 이 속성들을 사용할 때 염두에 둬야 할 게 하나 있습니다 이 속성들은 센티넬 값을 돌려줍니다 여러분이 오래된 운영 체제에서 Xcode의 StoreKit 테스팅을 사용할 때요 제가 센티넬 값이라고 할 때 지칭하는 건 플레이스 홀더 값으로 그것들은 여러분이 갖고 작업해야 할 실제 값이 아니란 걸 표시합니다 이런 일이 일어나는 이유를 설명해드리죠 샌드박스와 생산 환경은 이 속성들을 활용합니다 App Store 서버 반응에서의 값들을 추출하는 방식으로요 하지만 Xcode의 StoreKit 테스팅은 로컬 테스팅 환경으로 App Store 서버와 독립적으로 운영됩니다 그건 이런 속성들의 값을 그곳의 이전 운영 체제로 되돌려 포팅할 수 없다는 뜻입니다 여러분은 이런 한계를 쉽게 처리할 수 있습니다 자신의 테스트 기기를 새 운영 체제에 맞게 업데이트하면 로컬 환경에서 이 값들을 테스트할 준비가 모두 끝납니다 이 새로운 속성들을 쓰기 시작할 수 있는 방법을 잘 보여주는 몇 가지 상황을 설명해보죠 그중 첫 번째는 프라이스 로케일입니다 StoreKit 제품들에는 구매 가격을 보여주는 가격 표시 속성이 이미 있습니다 하지만 프라이스 로케일로 제품의 소수점 가격에서 파생된 숫자의 포맷을 여러분이 정할 수 있습니다 여러분에게 연간 구독이 있으면 이를 기회로 이용해서 매월 비용이 얼마나 들지 고객들에게 보여줄 수 있습니다 이 예에서 연간 구독을 계산하면 매월 4달러 17센트가 되는 걸 알 수 있습니다 아니면 여러분은 고객들이 월간 서비스가 아닌 연간 서비스를 구매하면 얼마를 절약할지 보여주고 싶을 수 있습니다 이 정보로 여러분의 고객들은 구매 옵션을 고려할 때 정보에 근거한 판단을 내릴 수 있습니다 이제 환경 속성으로 넘어가보죠 환경 속성은 Transaction 및 Renewal 정보에서 이용 가능합니다 이 속성은 거래나 갱신 정보가 유래된 서버 환경을 알려줍니다 그건 Xcode나 샌드박스나 생산이 될 수 있습니다 여러분의 앱은 고객이 구매한 후 거래 정보를 서버에 전달할 수 있습니다 회계 업무와 분석을 위해서요 여러분의 앱이 이런 거래를 생성하면 그건 이런 서버 환경 중 어느 곳에서든 할 수 있습니다 많은 분처럼 저도 관련 없는 테스트 데이터로 제 분석에 노이즈를 넣고 싶진 않습니다 따라서 환경을 아는 건 불필요한 정보가 서버로 올라가는 걸 걸러주는 데 도움이 될 수 있죠 마지막으로 살펴보려는 건 최근 구독 시작 일자입니다 최근 구독 시작 일자는 제품의 구독 정보 내에 있고 그건 가장 최근에 연속적으로 구독한 기간을 나타냅니다 구독이 연속적으로 간주되는 건 두 구독 기간의 공백이 60일을 초과하지 않는 경우입니다 명심할 점은 이 기간에는 고객이 여러분의 제품을 구독하지 않았을 때의 공백도 포함될 수 있다는 겁니다 그러니 이걸 고객이 구독해온 일수의 지표로 사용하진 마세요 최근 구독 시작 일자는 여러분과 고객들 사이의 충성도 패턴을 판단하는 데 도움이 될 수 있어요 충성스런 고객을 위해 여러분은 제품에 대한 그들의 관심을 유지할 방법으로 그들에게 보상을 제공할 수 있습니다 아니면 고객이 서비스 구독을 해지했다는 걸 여러분이 발견하면 그걸 계약이 소멸된 고객을 되찾을 기회로 쓸 수 있습니다 제품을 다시 쓰기 시작하면 장려책을 제공하는 방식으로요 제가 앞에서 이 속성들의 센티넬 값을 자세히 살펴볼 거라고 말씀드렸는데요 알려드릴 건 제가 센티넬 값이라고 할 때 지칭하는 건 플레이스 홀더 값으로 실제 값의 부재를 표시해주는 역할을 합니다 이 속성들의 센티넬 값은 파악하기 쉽습니다 프라이스 로케일을 다룰 때 센티넬 값은 식별자가 xx_XX인 로케일입니다 환경 속성의 경우 그건 빈 문자열이 됩니다 그리고 마지막으로 최신 구독 시작 일자의 경우 이 값은 Date.distantPast입니다 운 좋게도 이 센티넬 값의 발생은 예측 가능합니다 여러분은 예전 운영 체제에서 Xcode의 StoreKit 테스팅을 사용할 때만 이것들을 접할 수 있을 거고 테스트 기기를 업데이트해서 이를 해결할 수 있어요 이제 여러분은 StoreKit 모델에 적용한 개선 사항들을 보셨습니다 저는 그게 구버전 호환이 가능하단 부분이 참 좋습니다 그 모델이 도입됐던 시기의 운영 체제까지 거슬러 올라가서요 여러분의 고객들은 앱을 업데이트만 해도 그 혜택을 바로 알 수 있습니다 여러분이 가격 값으로 계산할 때 프라이스 로케일은 그 형식을 올바르게 만들게 해서 App Store의 로케일과 일치하게 해줍니다 거래 및 구독 정보의 경우 환경은 그것이 비롯된 곳을 정확하게 알려줍니다 따라서 여러분이 이 데이터를 서버에 저장하면 여러분은 환경에 따라 적절하게 조치를 취할 수 있습니다 최근 구독 시작 일자는 여러분이 고객 충성도를 아는 데 도움을 줍니다 그래서 여러분이 장기 고객들에게 구체적인 제안을 맞춰서 만들거나 구독을 중단한 고객들에게 장려책을 제공할 수도 있겠죠 혹시라도 궁금하셨다면 환경과 최근 구독 시작 일자도 App Store Server API와 App Store 서버 알림을 통해 이용 가능합니다 그건 Ian이 설명해줄 거예요 이제 제가 말씀드리고 싶은 건 프로모션 코드 사용과 평가 요청을 위해 우리가 제공하는 SwiftUI API입니다 프로모션 코드는 여러분이 구독자들을 획득하고 유지하고 되찾아오는 데 도움이 될 수 있죠 한정 기간 동안 구독을 할인이나 무료로 제공해서요 App Store Connect에서는 고유한 이름을 붙인 맞춤형 코드를 만들 수 있습니다 거기에서 여러분은 최대 사용 한계를 정하고 만기를 정할지의 여부도 선택할 수 있습니다 여러분의 앱에서 프로모션 코드 사용 시트를 제시할 SwiftUI 실행을 살펴봅시다 여기에는 SwiftUI view가 있는데 여기 있는 버튼은 프로모션 코드 사용 시트를 작동시킵니다 제공 코드 사용 시트엔 이제 SwiftUI에 자체 뷰 변경자가 있습니다 뷰 변경자는 사용하기 쉽습니다 과정을 시작하려면 그것엔 결합용 불리언만 있으면 됩니다 그리고 일단 프로모션 코드 시트가 처리되면 여러분은 시트 제시의 성공 여부를 나타내는 결과를 얻을 겁니다 고객이 여러분 앱의 프로모션 코드를 사용하면 결과로 나오는 거래는 거래 리스너로 전송됩니다 따라서 앱이 시작되지마자 거래 리스너를 반드시 준비해놔서 앱이 돌아가는 동안 업데이트된 새로운 거래를 수신할 수 있게요 제공 코드 뷰 변경자는 iOS 16에서부터 이용 가능합니다 다음으로는 평가 요청에 대한 업데이트를 얘기하고 싶습니다 고객 피드백을 받는 건 중요합니다 잠재적인 신규 고객들은 여러분의 앱을 다운받을지 판단할 때 평가를 결정적 요인으로 쓸 수 있습니다 다른 사람들은 피드백이나 제안을 제시하는 방법으로 평가를 남기고 싶을 수 있습니다 어느 쪽이든 우린 여러분에게 고객들에게 평점을 요구하는 걸 쉽게 해줄 도구를 드리고 싶습니다 여러분이 경청한다는 걸 고객들에게 알리고 그들과의 관계를 이어갈 수 있게요 그 코드를 살펴봅시다 여기에 Request Review API를 시연할 아주 간단한 뷰를 마련했습니다 SwiftUI에는 이제 requestReview라는 환경 값이 있습니다 이 값을 사용해서 RequestReviewAction의 인스턴스를 얻을 수 있습니다 여러분이 평점을 요청할 준비가 됐으면 그 인스턴스를 함수로 호출해서 평가 프롬프트를 표시해달라고 요청하면 됩니다 앱에 대한 평가를 요청하기에 적절한 시간은 여러분이 선택할 수 있습니다 하지만 여러분이 알아야 할 건 그 프롬프트가 365일 기간 이내에 고객들에게 최대 3회만 표시될 거란 겁니다 그리고 여러분은 동일 버전의 앱을 여러 번 평가해달라고 고객들에게 요청하면 안 됩니다 평가 팝업 창으로 고객들을 방해하는 일은 피하세요 평가를 요청하기에 좋은 때는 그들이 긍정적 상호 작용을 한 후가 될 수 있겠죠 가령 전자 상거래 앱에서 구매를 완료했거나 게임에서 어떤 레벨에 오르고서요 마지막으로 고객들은 자신의 기기에 요청이 나오는 걸 막아버릴 수 있으니 사용자 동작의 결과로 평가를 요구하면 안 됩니다 이 API들은 여러분의 SwiftUI 앱에 아주 편리할 겁니다 다음으로 제가 소개하고 싶은 건 StoreKit 메시지를 위한 신규 API입니다 StoreKit 메시지는 사용자에게 중요한 메시지를 표시해주기 위해 여러분의 앱 위에 나타나는 시트를 나타냅니다 메시지는 App Store에서 판매합니다 각각의 메시지에는 이유가 있는데 그건 메시지 메타데이터에 포함되어 있습니다 StoreKit 메시지는 여러분의 앱이 전경으로 나오면 회수됩니다 하나의 예로 메시지 이유 중 하나인 가격 인상 동의를 살펴봅시다 여러분이 구독 요금을 올릴 때 거기에 사용자의 동의가 필요하면 App Store는 이메일 푸시 공지 앱 내 가격 동의 시트를 통해 영향을 받는 구독자들에게 알립니다 이 경우에 App Store는 사용자가 새 구독 요금에 동의해줄 것을 요구합니다 인상된 요금으로 갱신하기 전에요 따라서 여러분이 구독 요금을 인상하기로 결정한다면 사용자가 여러분의 앱을 열 때 요금 인상 동의 시트가 뜰 수 있습니다, 사용자가 아직 요금 인상에 답하지 않았다면요 초기 설정으로 사용자가 여러분의 앱을 전경에 올리면 StoreKit 메시지가 여러분의 앱에 뜨고 그건 사용자에게 여러분의 앱과 관련해서 동작을 취해달라고 요구할 수 있습니다 이걸 자세히 살펴보죠 전체 과정은 여러분의 앱에서 시작합니다 여러분의 앱이 전경에 들어가면 StoreKit는 표시해야 할 계류 중인 메시지가 있는지 확인해야 하는 걸 알죠 그리고 그게 있다면 StoreKit는 App Store에 연락합니다 App Store는 그 메시지에 관한 정보를 StoreKit에 돌려줍니다 이때 StoreKit는 여러분의 앱이 메시지를 수신할 수 있게 설정되어 있는지 확인합니다 여러분의 앱에 메시지 리스너를 마련하면 이렇게 할 수 있는데 그건 곧 자세히 설명하죠 여러분의 앱이 메시지 리스너를 준비시켰으면 StoreKit는 메시지에 관한 정보를 여러분의 앱으로 전송합니다 이제 여러분의 앱이 그 메시지를 표시하기에 좋은 때인지를 결정할 기회입니다 아니면 그 표시를 나중으로 연기할지도요 여러분이 메시지 리스너를 마련해 놓지 않으면 StoreKit는 그 메시지를 곧바로 표시합니다 그 메시지 시트를 여러분의 앱에 제시해서요 이걸 코드로 하는 방법을 알아보겠습니다 그런데 그렇게 하기 전에 App Store 메시지의 제시를 제어하는 데 유용한 상황을 설명하겠습니다 Food Truck 앱에서 저는 다양한 도시에 배송하는 도넛을 맞춤형으로 만들 수 있습니다 이 시간에 메시지가 제 앱으로 전송되면 메시지 시트로 갑자기 방해받은 사용자는 혼란스러울 테니 저는 Messages API를 실행해서 이런 일이 일어나지 않게 할 겁니다 유입되는 메시지가 제시되는 때를 제어해서요 이제 코드로 들어가봅시다 여기에는 도넛 편집기에 대한 간단한 뷰가 있습니다 앞에서 말씀드렸듯이 여러분의 앱이 전경에 나올 때마다 계류 중인 메시지가 전송됩니다 그래서 전 각각의 뷰에 메시지 리스너를 구성하고 싶어요 그걸로 저는 메시지 제시를 연기하고 싶습니다 저는 2진법 배열을 추가해서 편집 작업 뷰에 있는 동안 제 앱에 전달되는 메시지들을 수집합니다 이건 중요해요, 제가 메시지 리스너를 준비하지 않으면 제 앱이 전경으로 올 때 StoreKit는 메시지 시트를 바로 표시할 것이기 때문입니다 뷰가 나타나자마자 저는 제 메시지 리스너를 준비합니다 저는 이걸 메시지 타입의 정적 특성에서 반복되는 작업을 설정하는 방법으로 하겠습니다 이 특성은 비동기 시퀀스이고 저는 메시지가 들어올 때 수신할 수 있습니다 제 이용 사례에서 저는 계류 중인 메시지 배열에 메시지를 저장해 놓겠습니다 계류 중인 메시지들은 여러분의 앱이 전경에 갈 때마다 전달되므로 여러분의 앱은 동일한 메시지를 한 번을 초과해서 받을 수 있어서 저한텐 조건이 있습니다 제 배열에 중복 메시지를 넣는 걸 피하는 조건이죠 그리고 일단 그 뷰가 처리되면 저는 상위 보기에 메시지를 표시할 겁니다 이게 도넛 편집기로의 내비게이션 링크를 보유한 상위 보기입니다 여기에서 저는 이 계류 중인 메시지 배열에서 표시해야 할 계류 중 메시지를 모두 수집했습니다 그럼 이 계류 중인 메시지는 어떻게 표시할까요? 이제 환경 값인 displayStoreKitMessage가 있습니다 이건 DisplayMessageAction의 인스턴스를 여러분에게 주는데 그럼 여러분을 그걸 써서 주어진 메시지를 표시할 수 있습니다 그 뷰가 나타나면 저는 계류 중인 메시지들을 반복해서 displayStoreKitMessage를 호출하여 제가 표시하길 원하는 메시지를 전달해 넣습니다 StoreKit는 메시지 시트 제시를 처리해줍니다 앞에서 제가 말했죠 동일한 메시지가 한 번을 초과해서 여러분의 앱으로 전달될 수 있다고요 그 이유는 메시지가 사용자에게 제시된 다음에야 읽은 걸로 표시되기 때문입니다 따라서 StoreKit는 각각의 고유한 메시지가 반드시 한 번만 제시되게 합니다 지금까지 Messages API의 간단한 수행이었습니다 잊지 마세요, StoreKit 메시지는 여러분의 앱이 전경에 나올 때마다 거기로 전송된다는 걸요 그러니 여러분은 메시지 리스너를 각각의 뷰에 마련해 놓고 거기에서 메시지가 제시되는 때를 제어하는 것이 좋습니다 여러분은 고객들이 멋진 체험을 하게 할 수 있어요, 메시지 시트가 예상치 못한 순간에 나타나지 않게 해서요 아니면 여러분은 특정 메시지 타입에 논리를 맞추고 싶을 수도 있습니다 가격 인상 동의 메시지로 여러분은 자신이 제공하는 추가 가치를 고객에게 알리고 싶을 수 있습니다 가격 인상 동의 시트가 나타나기 전에요 마지막으로 StoreKit가 applicationUsername을 appAccountToken으로 보존하는 방식을 알아보죠 사용자가 구매한 후에요 여러분의 서버에 사용자 계정 시스템이 있다면 여러분은 이미 applicationUsername 속성을 사용하고 있을 가능성이 높습니다 applicationUsername은 여러분이 만드는 문자열로 거래를 여러분의 기기에 있는 사용자 계정과 연관시키는 겁니다 앱 내 결제를 위한 원래 API에서는 여러분이 지불 큐에 지불할 때 applicationUsername 값을 정합니다 applicationUsername은 어떤 문자열이든 받아들이지만 UUID의 문자열 표현을 제공할 것을 우린 추천합니다 거기에 UUID 문자열을 넣으면 StoreKit는 그 값을 지속시키고 큐가 업데이트하는 거래에서 그게 보일 겁니다 applicationUsername에 대한 UUID 문자열을 제공하지 않으면 StoreKit는 그걸 지속시키지 않을 수 있습니다 그 값이 지속될 거란 보장이 없죠 여러분이 지불 거래를 큐에 추가할 때부터 큐가 거래를 업데이트할 때까지 말이죠 UUID의 문자열 표현을 제공할 때 앱의 사용자 계정 중 어떤 것이 거래를 시작해서 완료했는지 파악할 수 있습니다 최신 StoreKit API에서 우린 이런 개념을 appAccountToken이란 구매 옵션으로 실행하고 거기엔 UUID 형식이 필요합니다 여러분이 applicationUsername을 지불 중에 UUID 문자열로 정해주면 App Store 서버는 그걸 appAccountToken으로 저장합니다 따라서 그것의 UUID가 App Store Server API에 의해 돌려받은 서명된 거래 정보와 V2 App Store 서버 알림에 나타나는 게 보일 겁니다 UUID는 최신 StoreKit transaction API에서 appAccountToken와 호환됩니다 이제 여러분은 확신할 수 있죠 최신 StoreKit API에 자신의 코드베이스를 업데이트할 때 applicationUsername으로 썼던 UUID가 StoreKit 거래 내에 appAccountToken으로 보존된다는 점을요 오늘 우린 많은 걸 다뤘습니다 서버 업데이트로 넘어가기 전에 올해의 StoreKit 업데이트를 복습해보죠 설명 내용은 이렇습니다 App Transaction으로 앱 구매 인증하기 프로모션 코드 사용하기 SwiftUI에서 평가 요청하기 StoreKit 메시지 제시 제어하기였습니다 그리고 설명했던 건 신규 프라이스 로케일, 환경 최근 구독 시작 일자 속성이었습니다 그리고 applicationUsername을 위한 UUID의 문자열 표현 사용의 중요성을 알아봤습니다 그걸 앱 계정 토큰으로 지속시키기 위해서요 다른 세션 'StoreKit 테스팅의 새로운 기능'을 확인해보시길 강력 추천합니다 StoreKit 2 API를 다시 알아보고 싶다면 작년 세션 'Meet StoreKit 2'을 확인해보세요 이제 Ian한테 진행을 넘겨 App Store 서버 업데이트에 관한 설명을 부탁하겠습니다 고마워요, Dani 모두 안녕하세요 제 이름은 Ian입니다 저는 App Store Server 팀의 엔지니어예요 이제 여러분은 StoreKit의 앱 내 결제에 관한 최신 소식을 들어봤으니 저는 주제를 바꿔서 서버 얘기를 해보겠습니다 먼저 작년에 있었던 진전 사항들을 검토한 다음 App Store Server API와 App Store 서버 알림 버전 2에 나올 흥미진진한 신규 업데이트로 넘어가보겠습니다 그럼 시작해보죠 작년은 대단했습니다 우린 여러분에게 완전히 새로운 엔드포인트 세트를 선사했죠 App Store Server API와 App Store 서버 알림 V2로요 수많은 신규 기능들에 대한 전체 샌드박스 테스팅 지원을 포함해서요 우리가 알려드린 건 Get Transaction History 엔드포인트를 사용해서 사용자의 앱 내 결제 전체 이력을 얻는 방법이나 Get All Subscription Status 엔드포인트를 확보해서 사용자 구독의 현 상태를 최신으로 유지하게 하는 방법이었습니다 이 두 엔드포인트 모두는 사용자의 originalTransactionId를 편리하게 키로 끌 수 있게 해서 이 단순한 값 하나만 저장해서 이 데이터 집합을 이용할 수 있습니다 또한 우리가 다뤘던 건 App Store 서버 알림의 버전 2가 여러분 서버의 이벤트 처리를 단순화할 수 있고 App Store Server API를 보완하는 방법이었습니다 V2 Notifications로 App Store 서버는 여러분의 서버를 직접 호출해서 앱 내 결제가 발생할 때 업데이트를 제공해줍니다 간결한 공지 타입과 서브타입은 무슨 일이 일어나는지 알기 쉽게 해줍니다 여러분은 이걸 써서 앱 내 구독과 기타 이벤트와 관련된 변동을 추적할 수 있습니다 이렇게 많은 데이터 출처로 우린 그 데이터의 파싱을 최대한 쉽게 하려고 했습니다 영수증은 이제 옛날 겁니다 이 신규 서비스들은 서명된 JSON 형식으로 앱 내 데이터를 제공해서 그걸 쉽게 파싱할 수 있게 하고 그게 App Store 서버에서 왔다는 걸 신뢰할 수 있게 합니다 작년은 App Store 서버에 중대한 한 해였습니다 여러분에게도 중대했을 수 있어요 여러분의 서버 코드를 업데이트해서 수많은 새 기능들을 활용하기 위한 작업을 하셨다면요 그 노력은 계속 결실을 맺을 테니 안심하세요 App Store Server API와 App Store 서버 알림 V2에 강력한 개선과 기능을 새롭게 선사할 테니까요 여기까지 한 해를 정리했는데 올해의 업데이트를 들은 다음 더 자세히 알아보고 싶다면 WWDC21에서 다음 제목의 세션을 꼭 확인해보세요 'Manage in-app purchases on your server'와 'Meet StoreKit 2'와 'Support customers and handle refunds'입니다 이제 WWDC22 App Store 서버에 대한 완전히 새로운 업데이트로 넘어가보죠 먼저 거래 및 갱신 정보 필드에 대한 업데이트를 알려드리겠습니다 다음으론 App Store Server API에 대한 새로운 개선 사항들을 알려드리겠습니다 그리고 마지막으로 App Store 서버 알림 V2에 나올 흥미로운 새 기능들을 알려드리죠 그럼 새로운 주제 중 첫 번째로 시작해보겠습니다 거래 및 갱신 정보에서 볼 수 있는 새 필드들입니다 앞에서 Dani가 말했죠 앱 내 결제의 거래 및 갱신 정보에 새롭게 나올 새 필드 두 가지를요 이 필드들인 환경과 recentSubscriptionStartDate는 App Store Server API와 V2 App Store 서버 알림에서 여러분이 수신하는 거래 및 갱신 정보 페이로드에도 나옵니다 여러분이 이 새 필드들이 포함된 App Store 서버에서 수신하길 예상할 수 있는 데이터를 새롭게 살펴보죠 첫째는 거래 정보 페이로드인데요 디코딩 후의 그걸 여기에서 볼 수 있습니다 하단에 새 필드인 환경이 보입니다 이걸 사용해서 단번에 구분할 수 있습니다 거래가 생산 환경과 샌드박스 환경 중 어디에서 일어났는지를요 다음은 갱신 정보 페이로드입니다 이것 역시 디코딩 후 모습입니다 보시다시피 환경 필드가 여러분이 참고하실 수 있게 여기에서도 이용 가능합니다 게다가 recentSubscriptionStartDate는 이제 모든 갱신 정보 페이로드에 나옵니다 이건 사용자의 가장 최근 갱신 문자열에서 첫 번째 구독 구매의 시작 일자로 60일 미만 간격을 무시한 겁니다 recentSubscriptionStartDate 고객의 충성심을 한눈에 알기 위한 쉬운 방법입니다 그런데 여러분이 서비스 간격의 타이밍과 길이를 포함해서 자세한 걸 알고 싶으면 Get Transaction History 엔드포인트를 호출해서 사용자의 구독 갱신 구매의 전체 이력을 검토해볼 수 있습니다 혹은 더욱 자세히 알고 싶다면 App Store 서버 알림 V2로 App Store 서버는 사용자 구독에 관한 업데이트를 여러분의 서버로 자동으로 전송해줍니다 이런 공지는 다음 이벤트들의 타이밍에 대한 최대한의 통찰을 전해주는데요 그 이벤트들은 갱신 선호 변동, 프로모션 사용 청구 실패 등등입니다 보시다시피 recentSubscriptionStartDate는 고객 충성도를 판단하기 위한 옵션들의 세트를 완성해줍니다 이런 도구들을 사용해서 제안할 대상을 정하고 충성도가 최고인 분들에게 보상하십시오 이제 Get Transaction History 엔드포인트에 대한 편리한 개선 사항들로 넘어가겠습니다 Get Transaction History 엔드포인트로 여러분은 앱 사용자들 구매의 전체 이력을 얻을 수 있습니다 엔드포인트 반응에는 페이지 번호가 매겨져 있으니 이 데이터를 적당한 덩어리로 처리할 수 있습니다 각각의 반응에는 다음 번 요청에서 여러분이 제공하는 개정 토큰이 들어 있습니다 다음 페이지를 얻기 위해서요 그리고 페이지는 변경 일자 순으로 정리되어 있습니다 그다음 페이지 각각에 더 최근에 변경된 거래가 들어 있다는 뜻이죠 이게 작동되는 방식을 살펴보죠 Get Transaction History 엔드포인트를 호출해서 originalTransactionId를 제공합니다 App Store 서버는 그 사용자에 대한 최대 20개의 서명된 거래를 돌려줍니다 그건 이 사용자에 대한 다음 페이지 요청에서 여러분이 제공할 업데이트된 개정 값도 돌려줍니다 반응에 있는 hasMore 필드가 참이면 더 많은 데이터가 있다는 걸 여러분은 알게 됩니다 이 경우에는 이용 가능한 데이터의 페이지가 하나 더 있다고 가정해보죠 엔드포인트에 요청을 다시 하고 첫 번째 반응에서의 그 개정 값을 포함시킵니다 그럼 업데이트된 개정 값을 포함하여 다음 데이터 페이지를 받게 되죠 hasMore는 이제 거짓이어서 여러분은 최신 거래 데이터가 업데이트됐다는 걸 압니다 다만 이번에는 반응에서 최종 거래와 관련된 뭔가를 여러분은 발견합니다 전에 본 적이 있는 거네요 첫 요청에 대한 반응으로 여러분이 받았던 원래의 20개 중 하나였습니다 이는 거래가 변경됐을 거란 뜻입니다 그래서 그건 정렬 순서 최상위에 다시 놓였습니다 이제 여러분은 그 거래의 데이터를 검토하고 바뀐 것에 주목할 수 있습니다 이 경우에는 revocationDate와 revocationReason 필드가 이제 채워졌다는 걸 여러분이 발견합니다 거래가 취소됐다는 뜻이죠 여러분은 그 구매와 관련된 모든 콘텐츠를 취소해서 조치를 취할 수 있습니다 이 최종 반응에서의 개정 값을 저장하는 게 좋은 생각입니다 사용자를 파악하기 위해 썼던 originalTransactionId와 함께요 다음 번에 여러분이 이 사용자에 대한 엔드포인트를 호출하면 그 개정 내용을 제공할 수 있고 지난 요청 이후로 변경된 새로운 거래 데이터만을 돌려 받는다는 걸 압니다 보신 것처럼 Get Transaction History 엔드포인트는 앱 내 결제 데이터의 포괄적인 집합을 회수하는 간단한 방법을 제공해줍니다 그런데 때로 그건 과하게 포괄적일 수 있습니다 사용자들 일부의 구매 이력은 몇 년 전으로 거슬러 올라갈 만큼 너무 깁니다 그런 사용자들의 경우 이 엔드포인트는 다양한 종류의 수백 건의 구매를 돌려줄 수 있습니다 페이지가 있어도 처리하기에 너무 많을 수 있죠 그래서 올해 우리는 이 엔드포인트를 다양한 정렬 및 필터 옵션으로 개선합니다 이제 여러분은 처음부터 정확하게 원하는 데이터를 알려줘서 여러분 서버의 처리 시간을 절약하고 이용 가능한 모든 페이지를 회수하는 데 필요한 네트워크 호출의 수를 줄입니다 결과의 첫 페이지에 가장 최근에 변경된 구매를 보는 데 관심이 있으면 변경 일자를 내림차순으로 정렬할 수 있습니다 또한 몇 가지 유용한 필드로 필터링 할 수 있습니다 제품 종류, 제품 ID 가족 공유 상태 등으로요 이런 새로운 정렬 및 필터 옵션을 적용하려면 그걸 쿼리 파라미터로 덧붙이세요 Get Transaction History의 엔드포인트로 가는 요청에요 그게 작동되는 방식은 어떤지 자세히 살펴보죠 여기에서는 새 파라미터 옵션들을 모두 볼 수 있습니다 이것들은 낯익어 보일 수 있습니다 대부분이 거래 정보 페이로드에서 직접 가져온 거라서요 이 파라미터들을 짜 맞춰서 아주 구체적인 결과를 얻을 수 있습니다 예를 들어 우린 올해에 들어서며 사용자의 비소모성 구매만을 불러오길 원할 수도 있습니다 또한 모든 취소된 구매를 제외시키길 원합니다 우린 맞춤형 요청을 구축합니다 productType을 NON_CONSUMABLE로 정하고 startDate를 100분의 1초로 표현된 올해 초로 명시하는 방식으로요 마지막으로 excludeRevoked를 참으로 정합니다 저게 우리의 요청입니다 정렬 순서를 명시하지 않았으므로 그 반응은 변경 일자를 오름차순으로 정렬해주는 초기 설정을 수행합니다 이렇게나 요청이 구체적이어도 회수할 구매 페이지는 여러 개가 될 수 있습니다 후속 요청의 경우 정확히 동일한 쿼리 파라미터를 꼭 포함시켜야 합니다 이전 반응에서의 개정에 덧붙여서요 유연성을 더욱 늘리기 위해 필터 필드 중 세 개가 다수의 값을 지원해서 여러분은 제공된 값 중 최소한 하나와 일치하는 구매들만 필터링 할 수 있습니다 이 필드들은 productType, productId subscription GroupIdentifier입니다 이들 파라미터에 다수의 값을 제공하려면 그것들을 여러 번 정의하기만 하면 됩니다 다음으론 App Store 서버 알림 업데이트로 넘어가죠 App Store 서버 알림 V2로 여러분 서버의 수준을 더 높일 수 있습니다 V2 Notifications는 앱 내 결제 이벤트에 관한 상세한 통찰을 전해주는데 그건 다른 어디에서도 얻을 수 없습니다 이것들은 여러분의 앱에서 제공되는 자동 갱신형 구독의 수명 주기를 추적하는 데 특별히 유용합니다 이 통찰을 써서 고객을 유지하고 떠났던 분들을 되찾아오고 고객 지원 요청을 해결하는 등 많은 걸 할 수 있습니다 이렇게 이점이 많으니 여러분은 시작할 방법이 궁금할 수 있습니다 여느 새 기능과 마찬가지로 시작하기에 가장 좋은 곳은 샌드박스 테스팅 환경입니다 그래서 작년에 우린 App Store Connect에서 별도의 서버 URL을 설정하는 능력을 추가했습니다 App Store 서버 알림을 샌드박스에서 받는 용도로요 여러분의 서버 URL을 등록한 후 여러분의 서버가 App Store 서버에서 공지를 받는지 확인하고 싶으실 겁니다 여러분은 사용자 동작을 통한 공지 촉발만을 목적으로 샌드박스 계정을 마련할 수도 있습니다 예를 들어 여러분이 그 샌드박스 계정을 사용해서 구독을 처음으로 구매한다고 가정해봅시다 여러분은 타입 SUBSCRIBED와 서브타입 INITIAL_BUY의 V2 공지를 받을 겁니다 그런데 그 공지가 오지 않으면 어떨까요? 서버나 공지를 촉발시키려고 취한 조치들에 문제가 있는지 궁금할 수 있습니다 이 상황은 여러분이 시작할 때 많은 불확실성을 야기할 수 있습니다 우린 이 체험을 단순하게 하고 App Store 서버 알림이 서버에 도달할 수 있다는 걸 쉽게 입증할 방법을 드리고 싶습니다 그래서 올해 우린 Request a Test Notification 엔드포인트를 새롭게 도입합니다 이 간단한 엔드포인트를 호출해서 여러분은 부탁할 수 있죠 타입 TEST의 V2 Notification을 App Store Connect의 여러분 앱에 등록된 서버 URL을 전송해달라고요 새로운 TEST Notification 타입은 이 엔드포인트에 전용으로 사용됩니다 여러분은 샌드박스나 생산에 있는 엔드포인트를 호출해서 저장된 URL을 두 환경에서 테스트할 수 있습니다 이 새로운 엔드포인트를 사용해서 새 서버 URL과 설정을 빠르게 테스트하세요 이것이 최초 구성을 단순하게 하는 방식을 살펴보죠 이제 여러분이 첫 공지를 촉발하기만을 원한다면 샌드박스 계정을 구성하거나 구매를 수행할 필요는 없습니다 여러분이 테스트하고 싶은 어떤 환경에서든 새 엔드포인트를 호출하세요 그럼 여러분은 요청을 확인해주는 HTTP 200 반응을 받을 겁니다 그 반응에 들어 있는 건 새 필드와 testNotificationToken인데 이는 여러분의 서버가 수신할 테스트 공지를 파악합니다 이 필드는 나중에 다시 살펴보죠 곧 여러분의 서버는 App Store Connect에 저장된 URL에 있는 타입 TEST의 V2 공지를 받을 겁니다 이제 이 엔드포인트를 어떻게 호출할지 알아보죠 간단한 POST 요청을 App Store 서버에 있는 이 새 경로로 보내세요 여러분은 HTTP 200 반응을 받고 자신의 요청이 제출됐다는 걸 알 겁니다 그 반응에는 제가 언급했던 새 필드인 testNotificationToken이 포함됩니다 나중을 위해 그것에 주목하세요 곧 여러분은 서명된 TEST Notification을 받을 겁니다 이건 그 공지가 일단 디코딩됐을 때의 모습입니다 거기에는 V2 공지의 평소 상위 레벨 필드가 모두 포함됐다는 걸 알게 될 겁니다 새로운 공지 타입인 TEST도 포함해서요 데이터 오브젝트의 콘텐츠는 일반 공지보다 조금 짧습니다 이건 테스트에 불과하므로 포함시킬 거래 관련 데이터가 없습니다 그래서 우린 거래 전용 필드를 생략하는데 가장 주목할 만한 건 signedTransactionInfo입니다 새로운 Request a Test Notification 엔드포인트를 호출할 때 명심할 점은 App Store 서버 알림이 비동기로 전송된다는 겁니다 엔드포인트로의 호출이 성공하면 HTTP 200을 되돌려 받지만 실제 테스트 공지는 조금 지나 별도로 도착합니다 이 엔드포인트에서 중요한 게 서버 설정을 테스트하는 거라는 점을 감안할 때 여러분은 테스트가 실패하면 어떡할지 궁금할 수 있습니다 다시 말해 테스트 공지가 도착하지 않으면 어쩌냐는 거죠 여러분의 테스팅 능력을 더욱 강화하기 위해 우린 Get Test Notification Status 엔드포인트를 출시합니다 여러분은 그걸 Request a Test Notification 엔드포인트와 곁들여 사용하실 겁니다 이 신규 엔드포인트로 여러분은 이전에 요청된 TEST 공지의 상태를 확인할 수 있습니다 엔드포인트 반응은 App Store 서버가 여러분의 서버에 도달할 수 있었는지와 TEST 공지 전송에 성공했는지 알려줄 겁니다 전송이 실패했다면 그 이유에 대한 인상을 줘서 여러분의 서버 설정 문제를 더 잘 해결하게 해줍니다 이 엔드포인트를 어떻게 사용하실지 확인해보죠 App Store 서버의 이 경로에 GET 요청을 전송하세요 그 경로에 Request a Test Notification 엔드포인트에서 받은 testNotification Token을 포함시킵니다 이는 상태를 확인하면 좋은 테스트 공지가 뭔지 우리에게 알려줍니다 이제 반응을 알아보죠 signedPayload 필드에는 App Store 서버가 여러분의 서버에 보내려고 했던 TEST 공지 페이로드가 포함되어 있습니다 그리고 firstSendAttemptResult 필드는 그 전송 시도의 결과를 나타냅니다 이때 SUCCESS는 전송이 성공했다는 걸 나타내는데 그건 App Store 서버가 HTTP 200 반응을 여러분의 서버에서 받았다는 뜻입니다 전송이 실패했다면 여러분은 다양한 오류 값 중 하나를 보게 될 겁니다 이 값들은 App Store 서버가 테스트 공지로 여러분의 서버에 도달하려다 겪은 오류를 나타냅니다 이 정보로 여러분은 서버 문제를 정정하고 필요에 따라 새로운 테스트 공지를 요청하고 서버를 믿을 수 있게 돌아가게 할 수 있습니다 전체로서 이 테스트 엔드포인트들은 사용하기에 간단하고 고생을 많이 줄여줄 수 있습니다 V2 App Store 서버 공지를 받기 위해 여러분의 서버를 구성하거나 재설정할 때 말이죠 이 엔드포인트들의 도움으로 서버를 구성하고 그게 순조롭게 돌아가는 걸 확인할 수 있습니다 하지만 서버는 완벽하지 않고 중단이 일어나기도 합니다 여러분의 서버가 다운되어 App Store 서버 공지를 놓치게 된다면 어떻게 회복할까요? 이것에 대한 현재 해결책은 재시도 시스템입니다 App Store 서버가 여러분의 서버에 도달하는 데 실패하면 그건 재시도 과정에 착수합니다 동일한 공지를 보내려고 최대 5회까지 재시도하는데 각 시도 사이의 대기 시간을 늘립니다 이런 재시도는 생산 환경에서만 일어납니다 재시도는 여러분이 결국 중단에서 회복할 수 있게 하지만 모든 상황에 완벽하지는 않습니다 예를 들어 일부 중단은 대규모일 수 있습니다 여러분의 서버가 너무 오래 다운되어서 App Store 서버의 최종 재시도를 놓친다면 그 공지는 손실됩니다 또는 그보다 흔한 일은 여러분의 서버가 아주 짧은 문제를 겪는데 그동안 몇 개의 공지만을 놓치는 겁니다 하지만 단 한 개의 공지를 놓치는 것도 고객 기록들 일부의 일자가 최소 한 시간 동안 안 맞는다는 뜻입니다 그런데 여러분은 어떤 게 그런지 모르죠 서버 중단은 분명 스트레스를 받게 하고 거기에서 회복되는 건 복잡한 작업일 수 있습니다 그래서 우린 놓친 App Store 서버 공지를 회복하는 일을 가능한 한 쉽게 하려 합니다 여러분이 서버를 최대한 빨리 정상 가동시킬 수 있게요 그래서 올해 우리는 Get Notification History 엔드포인트를 새로 도입합니다 이 엔드포인트로 여러분은 앱을 위해 생성된 V2 App Store 서버 공지의 이력을 가져올 수 있습니다 여러분의 서버가 공지 수신에 성공했든 실패했든 그 공지는 이 엔드포인트에 대한 반응으로 나타날 겁니다 이 엔드포인트를 호출할 때 여러분은 가져올 공지의 일자 범위를 명시할 겁니다 WWDC 중에 우린 이 데이터를 기록하기 시작했고 이용 가능한 단계적인 이력에서 최근 6개월의 한계까지 구축할 겁니다 여러분은 선택에 따라 요청을 타입과 서브타입으로 필터하거나 단일 사용자의 공지들만 가져올 수 있습니다 originalTransactionId를 제공해서요 그리고 기존의 재시도 시스템도 여전히 이용 가능하니 그걸 이 새로운 엔드포인트와 동시에 사용할 수 있습니다 이 엔드포인트를 호출할 방법을 살펴보죠 POST 요청을 App Store 서버의 이 새로운 경로로 전송합니다 요청 본문에 startDate와 endDate를 포함시킵니다 반응에는 이 창에 우리가 처음에 보내려 했던 공지들만 포함되어 있을 겁니다 명심해야 할 건 이용 가능한 가장 이른 공지들은 여러분의 요청 일자에서 6개월 전에 전송됐다는 점입니다 선택 사항으로 notificationType과 notificationSubtype을 명시할 수 있습니다 그렇게 하면 이력은 이 두 값에 일치하는 공지들만 걸러내줄 겁니다 명심할 점은 일부 공지에는 서브타입이 없다는 겁니다 그 외에도 여러분은 사용자의 originalTransactionId를 제공해서 그 사용자만의 공지 이력을 가져올 수 있습니다 마지막으로 여러분은 paginationToken을 모든 후속 요청을 위한 쿼리 파라미터로 제공해야 합니다 다음 페이지를 얻기 위해서요 후속 요청에 대해 동일한 요청 본문을 반드시 사용하시고 paginationToken만 바꾸세요 이제 반응을 살펴보겠습니다 notificationHistory 배열에는 최대 20개의 공지가 들어 있고 가장 오래된 공지가 먼저 나옵니다 이 배열에서 각각의 입력은 공지를 나타내고 그 안에서 여러분은 signedPayload를 볼 겁니다 그건 평소처럼 여러분이 디코딩해서 거래 데이터를 볼 수 있습니다 그 내부의 데이터는 원래 공지에서 App Store 서버가 전송했던 페이로드와 동일합니다 우리가 이 엔드포인트 반응에 firstSendAttemptResult 필드를 새롭게 가져온 것도 발견하실 겁니다 이 필드를 써서 중단 시간의 순서와 다른 오류들을 찾아보고 여러분의 서버가 과거에 공지들을 놓친 이유를 더 잘 알게 될 겁니다 회수할 페이지들이 더 있다면 그 반응에도 paginationToken이 들어 있습니다 여러분은 다음 요청에서 이걸 제공해야 공지들의 다음 페이지를 얻을 수 있습니다 hasMore 필드가 참인 한 회수할 페이지가 더 있다는 걸 여러분은 알 겁니다 여기까지가 이 유용한 신규 엔드포인트에 관해 여러분이 알아야 할 전부였습니다 이것으로 오늘의 App Store 서버 업데이트를 마치겠습니다 오늘 발표한 모든 서버 기능은 샌드박스와 프로덕션 모두에서 지금 이용 가능합니다 여러분이 이 새로운 기능들을 활용해서 서버를 최상의 상태로 만드실 수 있길 바랍니다 기존 클라이언트를 지원하면서 최신 기능들의 사용법을 포함하여 앱 내 결제가 있는 서버의 사용과 관련된 멋진 콘텐츠를 추가로 찾으신다면 WWDC22의 또 다른 세션을 확인할 것을 권합니다 '앱 내 구입 통합 및 마이그레이션 살펴보기'입니다 WWDC22에서 우리와 함께해주셔서 감사합니다 ♪