BillingMeld: 왜 구매 확인은 서버가 해야 하며 앱이 아닌가

모바일 앱 내 구매는 일반 사용자에게는 간단해 보입니다. 버튼을 누르고 결제를 확인하며, 기능이나 구독에 접근하고 — 이후에는 자동으로 작동하리라 기대하는 것.

그러나 개발자에게는 훨씬 복잡한 과정이 시작됩니다. 구매 자체를 확인하고, 갱신, 구독 종료, 환불, 거래 내역 검토, 기기 변경, 그리고 Apple과 Google 간의 차이까지 고려해야 합니다.

가장 큰 문제는 서버가 클라이언트 애플리케이션을 진실의 출처로 간주할 때 발생합니다.

앱이 “구매 완료”를 알리면 서버는 접근 권한을 열고, 한번 받은 상태에 계속 의존합니다. 그러나 구매의 생명주는 여기서 끝나지 않습니다.

구독이 연장될 수도 있고, 자동 연장이 꺼질 수도 있으며, 결제가 환불될 수도 있고, 거래 자체가 스토어에 의해 철회될 수 있습니다.

이 때문에 BillingMeld는 구매를 앱이 아닌 서버가 확인합니다.

클라이언트는 알리지만 결정하지는 않는다

BillingMeld 아키텍처에서 모바일 앱은 구매에 관한 핵심 정보의 주된 출처가 아닙니다.

클라이언트는 거래를 수행했다는 데이터를 전달할 수 있지만, 이 정보는 검증의 근거일 뿐입니다. 최종 결정은 BillingMeld 서버가 내리며, Apple 또는 Google의 인프라를 통해 정보를 검증합니다.

이것이 근본적인 차이점입니다.

전화상의 앱은 오래된 상태를 가지고 있거나, 적시에 업데이트를 받지 못하거나, 이미 변경된 상태를 전달할 수 있습니다.

또한, 클라이언트는 사용자에게 유료 접근 권한이 있다고 임의로 판단하는 기능을 가져선 안 됩니다.

BillingMeld는 예를 들어 다음을 검증합니다:

• 이 구매가 실제로 존재하는가

• 해당 앱과 제품에 관련 있는가

• 현재 유효한 결제 기간인가

• 연장이 있었는가

• 자동 연장은 껐는가

• 환불이 처리되었는가

• 거래가 취소되었는가

• 지불된 기간이 아직 끝나지 않았는가

이와 같이, 클라이언트의 메시지는 구매의 증거가 아니라, 실제 상태를 검증할 계기가 됩니다.

서버를 위한 진실의 유일한 출처

연결된 서비스들은 Apple과 Google 각각의 통합을 모두 구현할 필요가 없습니다.

그들은 BillingMeld에 요청하여, 이미 표준화된 구매 상태 정보를 받습니다.

예를 들어: 접근 권한이 활성화되어 있거나, 결제 기간이 끝났거나, 갱신이 확인되었거나, 자동 연장이 꺼졌거나, 구매가 취소되었거나 하는 것들.

이것이 책임 구분을 명확히 합니다.

Apple과 Google은 모두 거래 상태의 원천이지만, BillingMeld는 이 데이터를 검증하고, 공통의 모델로 변환하며, 최신 정보를 저장합니다. 최종적으로 접근 권한에 관한 결정은 BillingMeld의 상태를 기준으로 이루어집니다.

이것은 제품 서버에게 여러 독립된 통합 대신 하나의 계약을 의미합니다.

개별 서비스에서 App Store 또는 Google Play 규칙을 별개로 구현할 필요도, 다양한 포맷이나 이벤트를 하나의 논리로 맞추려고 애쓸 필요도 없습니다.

클라이언트를 완전히 신뢰할 수 없는 이유

클라이언트 애플리케이션은 사용자 디바이스에서 작동합니다.

이 애플리케이션은 종료하거나, 재시작하거나, 백업에서 복원하거나, 나중에 업데이트하거나, 다른 디바이스에서 실행할 수 있습니다. 오래된 정보를 유지하거나, 최초 구매 이후 발생한 이벤트를 전달하지 못할 수도 있습니다.

이것은 사용자의 개입이 없더라도, 클라이언트를 최종 구독 상태의 신뢰할 수 있는 출처로 볼 수 없게 만듭니다.

예를 들어, 사용자가 구독 후 접근 권한을 받았다고 해도, 나중에 환불이 되거나 스토어가 거래를 취소하는 일이 있을 수 있습니다.

서버가 최초의 클라이언트 메시지만 알면, 여전히 구매가 유효하다고 생각할 가능성이 높습니다.

또는, 사용자가 자동 연장을 껐을 때, 이미 결제된 기간은 만료일 때까지 계속 유효하다는 사실이 서버에 반영되지 않을 수도 있습니다.

이 경우, 상태가 단순히 “구독 존재 / 존재하지 않음”이라면, 잘못된 권한 폐쇄 또는 무효시에도 적절하지 않게 계속 접근이 허용될 수 있습니다.

BillingMeld는 다른 논리를 따릅니다: 클라이언트가 자신의 권리를 확인하지 않습니다. 이벤트를 알리고, 서버가 이행 상태를 판단합니다.

구매는 하나의 사건이 아니다

빌링 아키텍처의 주요 실수 중 하나는 구매를 하나의 이벤트로 보는 것 입니다.

실제로, 구매는 생명주기를 갖고 있습니다.

처음에는 거래가 발생합니다. 이후 스토어에서 검증됩니다. 구독이 시작되고, 결제 기간이 정해집니다. 이후에도 갱신이 일어날 수 있습니다.

사용자가 자동 연장을 중단해도, 이미 결제한 기간까지는 계속 사용할 수 있습니다.

다음 결제 실패, 환불, 거래 취소 등 다양한 이벤트들이 발생할 수 있습니다.

따라서, “이 구매가 한때 있었다”라는 것만으로는 충분하지 않습니다.

서버는 지금 이 구매가 어떻게 되어가고 있는지 이해하는 게 중요합니다.

환불이 발생하면 즉시 인지된다

특히 환불이나 거래 철회와 같은 경우에 서버 아키텍처의 중요성이 드러납니다.

처음 구매는 정당했을 수 있습니다. 사용자가 실제 결제 후 접근 권한을 얻었다면, 나중에 상태가 변경될 수 있습니다.

BillingMeld는 상태 변화 정보를 받으면, 구매 상태를 갱신하고 필요 시 다시 검증합니다.

이후 연결된 서비스는 최신 상태를 기준으로 동작합니다.

이로써, 앱은 몇 주 또는 몇 달 전 고객이 성공적으로 구매했다고 하는 사실을 무한히 신뢰하지 않게 됩니다.

스토어가 더 이상 권한이 유효하다고 인정하지 않으면, BillingMeld도 이를 반영합니다.

구독 취소와 접근 종료 — 차이점

여기에는 중요한 차이가 있습니다.

사용자가 자동 연장을 껐다고 해서 바로 접근을 종료하는 것은 아닙니다.

현재 결제된 기간은 계속 유효할 수 있습니다.

이 경우, BillingMeld는 자동 연장 해제를 저장하면서도, 이미 결제된 종료일을 파악해야 합니다.

그리고 그 기간이 끝나면, 별도의 갱신이 없을 경우 접근권한은 종료됩니다.

이것이 왜 단순히 subscription = true와 같은 부울값만으로는 충분하지 않은지 보여줍니다. 구독 상태는 언제나 시간과 사건에 기반한 생명주기와 연결되어 있기 때문입니다.

갱신도 별도 검증 대상

구독은 첫 결제로 끝나지 않습니다.

서버는 다음 갱신이 일어났는지, 그리고 그 다음 결제가 스토어에 의해 확인되었는지 이해해야 합니다.

BillingMeld는 이러한 변경들을 감시하여 상태를 갱신합니다.

갱신이 확인되면, 접근 권한이 유지됩니다.

혹은 결제가 실패하거나, 더 이상 스토어가 다음 기간을 승인하지 않으면, 시스템은 단순히 접근권을 연장하지 않습니다.

사용자 입장에서는 이렇게 자연스럽게 보여집니다: 결제된 구독 기간 동안만 접근권이 유지됩니다.

이것은 개발자에게, 매번 모든 앱에서 동일한 갱신 논리를 다시 구현하지 않아도 됨을 의미합니다.

일반적인 시나리오는 어떻게 되나

사용자가 모바일 앱에서 구독을 신청한다.

클라이언트는 구매 정보를 받고, 필요한 데이터를 BillingMeld로 전달합니다. 하지만 이 메시지 자체가 바로 구매가 확정된 증거가 되지 않습니다.

BillingMeld는 해당 거래를 관련 스토어를 통해 검증합니다.

App Store 또는 Google Play가 구매를 승인하고, 상태가 규칙을 만족하면, BillingMeld는 활성 권한을 기록합니다.

그 후, 연결된 서비스는 결제된 기능을 제공합니다.

이후 상태는 클라이언트의 초기 메시지와 무관하게 지속됩니다.

구매가 갱신되면, BillingMeld는 새 결제 기간을 반영합니다.

자동 연장 해제 후에는, 현재 기간이 끝날 때까지 계속 접근 가능합니다.

거래 환불 또는 취소 시, 상태가 다시 변경됩니다.

이 방식에서 앱은 자체 “진실”을 저장하지 않으며, BillingMeld가 검증하고 저장하는 상태를 사용하는 것 입니다.

기기 변경시 어떻게 되나

이 서버 모델은 특히 사용자가 기기를 바꾸거나, 앱을 다시 설치할 때 유용합니다.

구매 권한은, 단순히 어떤 디바이스가 거래를 완료했다고 해서 존재하는 게 아닙니다.

반대도 마찬가지입니다. 앱의 재설치는 사용자 권한을 무효로 하지 않습니다.

구매 상태가 서버에 저장되고 검증된 거래와 연관되어 있다면, 새 기기에서도 서버를 통해 최신 상태를 받아볼 수 있습니다.

이것이 클라이언트 내부에만 접근 논리를 저장하는 것보다 더 나은 이유입니다.

개발자에게 의미하는 것

여러 모바일 앱을 운영하거나 iOS와 Android 모두를 지원하는 팀에게는, 빌링이 빠르게 별도 인프라 과제로 변모합니다.

이때 고려할 것은:

• Apple과 Google의 데이터 포맷 차이

• 초기 구매의 검증

• 구독 갱신

• 결제 종료

• 자동 연장 차단

• 환불

• 거래 철회

• 앱 재설치

• 기기 교체

• 구매 복구

• 이벤트 없이 변경된 상태

BillingMeld는 이러한 로직을 별도 계층으로 분리합니다.

제품 서버들은 이를 하나의 통합 계약으로 연결하여, 각각의 스토어별 특성을 직접 해석하거나 구현할 필요를 줄입니다.

이로 인해 코드 중복을 줄이고, 동일한 결제 시나리오를 여러 앱에서 다르게 이해하는 문제도 피할 수 있습니다.

중요한 것은 체크가 아니라 권리 상태

이 아키텍처에서 가장 흥미로웠던 점은, 개별 구매 검증에서 실시간 상태 확인으로의 전환입니다.

지불 자체는 과거의 기록일 뿐, 중요한 질문에 답하진 않습니다: 현재 사용자가 유료 기능을 사용할 권리 있는가?

처음 구매 후 유효하던 기간이 끝났거나, 자동 연장이 꺼졌다면? 이미 갱신된 상태이지만, 권한이 유지되는가? 환불 또는 평가 취소가 발생했는가? 스토어가 거래를 철회했는가?

이러한 상황에서는 체크와 초기 상태의 응답이 아니라, ‘현재 권리 상태’를 판단하는 게 중요합니다. BillingMeld는 이 상태를 다른 서비스에 전달합니다.

BillingMeld의 역할: 스토어와 제품 간의 경계

이로써 명확한 아키텍처 구분이 형성됩니다.

한쪽에는 App Store와 Google Play가 있고, 그들의 포맷, 이벤트, 규칙, 생애 주기가 존재합니다.

다른 쪽에는 앱과 내부 서비스들이 있으며, 대개는 훨씬 간단한 답변, 즉 ‘현재 사용자 권리’가 필요합니다.

이 둘 사이를 BillingMeld가 가로지릅니다.

그는 스토어 데이터를 수신, 검증, 내부 모델로 변환하며, 이미 정제된 결과를 인프라에 제공합니다.

이로써 제품 체계는 각 스토어의 내부 특성을 알 필요 없이, 표준화된 정보를 활용할 수 있습니다.

사용자에게 왜 중요할까?

최종적으로, 사용자를 위한 올바른 빌링 구조는 거의 눈에 띄지 않아야 합니다.

구매가 검증되고, 유효한 구독 시간이 지속되는 한, 접근 권한은 항상 유효하게 유지되어야 합니다.

사용자가 자동 연장 해제를 하더라도, 결제된 기간이 종료되기 전까지는 접속이 차단되지 않아야 합니다.

갱신이 성공하면, 접근권이 유지됩니다.

환불 또는 취소 시에는 권리 변경을 정확히 반영해야 합니다.

다른 기기로 변경하거나 앱을 재설치하는 경우, 복잡한 혜택 주장을 일일이 증명하는 과정 없이, BillingMeld가 검증한 상태로 자연스럽게 유지됩니다.

최종 규칙은 다음과 같습니다:

클라이언트는 구매를 알리고, 스토어는 상태의 외부 출처이며, BillingMeld가 검증하고 표준화한 상태를 기반으로, 나머지 서비스들이 결정한다.

이것이 바로 BillingMeld가 단순한 결제 모듈이 아니라는 이유입니다.

앱, Apple과 Google 스토어, 그리고 제품 간의 신뢰 서버 계층입니다. 사용자에게 현재 유료 권리의 명확한 상태를 전달하여, 정확한 권리 표시와 관리를 가능케 하는 핵심 역할입니다.

자세한 내용은 billingmeld.de에서 확인하세요.