본문으로 건너뛰기
[온디맨드 웨비나] 2026년 확장 가능한 크리에이티브[온디맨드 웨비나] 2026년: 최고의 모바일 팀이 광고 크리에이티브로 승리하는 방법
그로쓰

iOS 결제를 자체적으로 처리하시나요? MMP를 사용하여 측정하는 방법을 알려드립니다

iOS 결제를 자체적으로 처리하시나요? 좋습니다... 하지만 해당 수익을 사용자 확보 비용(UA)과 연결해야 한다는 점을 잊지 마세요. 그 방법을 알려드리겠습니다.

콘텐츠

디지털 마케팅 최신 소식을 받아보세요

분석어트리뷰션블로그크로스 디바이스 어트리뷰션전자상거래게임뉴스 & 트렌드

요약

  • 새로운 결제 모델 도입: 사내 iOS 결제의 합법성을 고려할 때, 마케터는 세 가지 결제 옵션을 검토해야 합니다. 앱 스토어 결제(Apple 관리), 웹 스토어 결제(타사 결제 업체 이용), 웹뷰 결제(앱 내 브라우저 이용)입니다. 웹 스토어 모델은 사용자 인증 및 결제 처리가 더 간편하다는 장점이 있는 반면, 웹뷰는 사용자를 앱 환경 내에 머물게 하지만 쿠키 제한으로 인해 불편을 초래할 수 있습니다.

  • 채널 추적 정리 유지: 마케터가 모든 iOS 결제—앱 내 결제든 웹 인터페이스를 통한 결제든—를 채널 혼란을 피하기 위해 인앱 구매로 보아야 합니다. 이 접근법은 수익을 사용자 획득 노력에 연결해 정확한 ROI와 LTV 계산을 보장하고, 마케팅 캠페인 최적화를 향상시킵니다.

  • Android 변화 대비: Android가 iOS와 비슷하게 결제 정책이 바뀌고 있습니다. 마케터는 법적 동향을 파악하고 Google의 사용자 선택 결제 등 프로그램에 참여해야 합니다. 변화를 이해하면 사용자 확보와 결제 처리 전략에 유리합니다.

iOS 결제를 자체적으로 처리할 계획이신가요? 좋습니다. 하지만 이제 MMP를 사용하여 앱스토어 외부에서 발생하는 결제를 측정하는 방법도 알아야 합니다.

방법은 다음과 같습니다…

결제하기 인앱 구매 타사 또는 자체 전자상거래 솔루션을 통해 이제 미국에서 iOS 앱에 대해 완전히 합법입니다, Epic Games’의 Apple에 대한 소송 덕분입니다. (만약 당신이 바로 그걸 하려고 생각한다면, 여기’는 결정을 돕기 위한 프레임워크입니다) 하지만 숙련된 마케터들은 쿠퍼티노 메인 스트리트에서 축하 퍼레이드를 열기 전에, 사용자 수익을 비용과 연결하여 스마트한 사용자 획득 캠페인을 지속할 수 있어야 한다는 것을 알고 있습니다. 

그렇지 않으면 눈을 가리고 비행하는 것과 같습니다. 비용과 매출을 연결하지 못하기 때문에 광고 캠페인 최적화 피드백 주기가 무너진 것입니다.

이제 연결하는 방법은 MMP 측정 을 iOS 인하우스 결제와 연결합니다.

iOS 결제 옵션이 이제 3가지로 늘어났습니다

현재 iOS 결제를 받는 방법은 크게 세 가지가 있으며, 기존 방식처럼 애플이 직접 관리하도록 두는 방법도 포함됩니다.

  1. 앱 스토어 iOS 결제
    예전과 동일… Apple이 중개하는 인앱 구매. 간단하고 마찰 없이, 15-30% 수수료만 부담.
  2. iOS 웹 스토어 결제
    주로 web2app 획득 흐름이나 dip‑outs … 사용자를 인앱 컨텍스트에서 꺼내 웹 기반 스토어로 이동시켜 구매를 진행하고, 딥링크로 다시 앱으로 돌아오게 합니다. 앱 설치 전에도 가능하며, 많은 web2app 구독 흐름에서 일반적이고 앱 세션과 완전히 독립적입니다.
  3. Webview iOS payments
    Though technically it’s close to #2 above, it’s not exactly equivalent. Webview is popping open a browser instance in-app, thereby keeping your users in context as much as possible.

앱스토어 모델에서 애플은 결제를 처리할 뿐만 아니라 매우 중요한 또 다른 작업을 수행합니다. 바로 사용자가 X에 대한 비용을 지불했으므로 이제 앱에서 X를 제공할 수 있다는 사실을 앱 개발팀에 알리는 것입니다.

웹 스토어 모델에서는 Stripe나 PayPal 같은 결제 프로세서, 혹은 현재 페이월을 제공하는 RevenueCat 같은 서비스가 결제를 받고, 종종 SDK, 앱이 제품을 제공하도록 알려줍니다. 웹 스토어 모델의 큰 장점은 전체 브라우저 경험을 제공하며 기존 쿠키와 로그인에 완전 접근이 가능하다는 점입니다. 사용자가 한 번 결제하고 계정을 만들면, 결제 정보가 저장되어 이후 구매 시 재입력 없이 재사용됩니다. 또한 이론적으로 사용자는 다른 기기— 예를 들어 노트북—에서 구매를 완료하고, 앱에서 그 혜택을 확인할 수 있습니다.

웹뷰 모델은 사용자를 앱의 컨텍스트 내에 유지하는 데 가장 적합하지만, 잠재적인 단점도 있습니다. iOS(WKWebView)와 Android(WebView)의 웹뷰는 모두 샌드박스 환경에서 실행됩니다. 즉, 웹 콘텐츠는 네이티브 앱의 내부 데이터 및 기타 시스템 리소스와 격리되어 있으며, 경우에 따라 사용자의 기존 쿠키 및 로그인 정보에 접근할 수 없습니다.

(예외: SFSafariViewController와 같이 앱 내에 완전한 Safari 인스턴스가 포함된 인앱 브라우저를 실제로 배포하는 경우)

즉, 사용자가 Stripe, PayPal 또는 RevenueCat에 기존 계정이 있더라도 로그인 절차 없이는 접근할 수 없어 불편함을 겪을 수 있다는 뜻입니다. 또한, 결제 처리 업체에 기존 계정이 없는 사용자는 지갑을 꺼내 신용카드를 찾고 모든 정보를 일일이 입력해야 하는 번거로운 과정을 거쳐야 할 수도 있습니다.

(알 수 없는 상점에서 카드 결제를 시도하는 것을 감지한 카드 발급사가 의심스러운 거래에 대해 2단계 인증을 요구할 가능성은 차치하더라도 말입니다.)

바로 그곳에서 심각한 마찰이 발생할 수 있습니다.

중요: 채널을 깨끗하게 유지하세요

과거에는 채널 혼란이 소비재(CPG) 업체들만 걱정해야 할 문제였습니다. TV 광고, 매장 전단지, 인플루언서, 아니면 다른 유통 또는 마케팅 채널 중 어떤 것이 매출에 영향을 미쳤을까요?

이제 더 이상 수동적인 선택이 아닙니다. 앱 개발사들도 이 점을 고려해야 합니다.

만약 "채널"을 제품이 판매되는 장소로 일반화한다면, 모바일 앱 결제의 경우 위에서 언급한 세 가지 구체적인 채널이 분명히 존재합니다.

하지만 정말 3개일까요? 웹 스토어와 웹뷰는 결제 처리 및 앱으로의 데이터 공유 측면에서 본질적으로 동일한 기능을 사용하므로 2개면 충분하지 않을까요? 어느 정도는 맞지만, 혼란스러울 수 있습니다. 

아직 초기 단계이지만, Singular 에서는 인앱 구매가 실제로 어디에서 발생하든 인앱 구매로 간주해야 한다고 주장합니다. 이는 핵심적인 결과물이 앱 내에 있기 때문에 수익을 앱 중심적으로 바라보는 방식입니다.

즉, 궁극적으로 앱 외부에서 이루어진 모든 iOS 결제 또는 구매는 해당 모바일 사용자/기기에 연결되어 보고되어야 한다는 의미입니다. 실제로 구매한 상품이나 서비스를 사용자, 고객 또는 구독자에게 제공해야 하기 때문에 이는 필수적인 절차입니다. 또한, 이러한 방식은 수익이 사용자 확보와 연관되도록 보장하여 ROI/ROAS/LTV 계산을 정확하게 유지하는 데 도움이 됩니다.

(물론 다른 방법은 이러한 앱 스토어 외부 결제를 웹 이벤트 또는 기기 간 수익으로 추적하는 것입니다. 하지만 결제 포털은 앱 게시자이자 마케터인 여러분이 아닌 결제 대행업체가 소유하고 있을 가능성이 높기 때문에 어떤 경우에도 어려움이 따를 것입니다.)

iOS 결제를 사람들과 연결하기

모바일 사용자/기기에 웹 결제를 연결하는 기술적 방법은 다양하며, 각 방법은 앱 내 통합 및 결제 처리 과정에서의 어려움 측면에서 장단점이 있습니다.

  1. 각 결제 업체와의 직접적인 통합 및 기기 ID 및/또는 customVendorID를 사용한 이벤트 전송은 서버 간 통신을 통해 이루어집니다
  2. 결제 업체 SDK/API에서 "결제 성공" 콜백을 서버 측 또는 클라이언트 측에서 수신하고, Singular SDK에서 해당 수익 이벤트를 Singular 로 전달합니다

결국에는 아주 명확하고 간단한 선택지들이 나올 테지만, 현재로서는 2번이 충분히 실현 가능합니다.

가장 중요한 질문은 주요 결제 플랫폼들이 이 문제를 어떻게 해결할 것인가 하는 점입니다. 궁극적으로 마케터들은 채널 혼동을 피하고 ROI/ROAS를 추적하기 위해 사내 구매를 웹 구매가 아닌 인앱 구매로 측정해야 하며, Singular 이를 지원할 것입니다.

안드로이드와 자체 결제 시스템은 어떻습니까?

흥미로운 점은 iOS 결제에서 이러한 모든 일들이 벌어지고 있다 보니 안드로이드를 쉽게 잊어버린다는 것입니다.

지난 몇 년 동안 안드로이드는 구글의 정책과 법적 의무를 통해 타사 결제 옵션과 관련하여 상당한 변화를 겪어왔습니다. 예를 들어, 구글의 "사용자 선택 결제(User Choice Billing)" 시범 프로그램은 자격을 갖춘 개발자가 구글 플레이 스토어의 결제 시스템과 함께 대체 결제 시스템을 제공할 수 있도록 지원합니다. 이 프로그램은 현재 미국, 영국, 캐나다, 호주, 브라질, 일본, 유럽 경제 지역(EEA)을 포함한 35개국 이상에서 운영되고 있습니다.

했던 문제와 매우 유사합니다 수수료나 요금을 폐지하라고 명령 앱 외부 결제에 대한

구글의 수수료가 완전히 사라지는 것은 아닙니다. 단지 조금 줄어들 뿐입니다. 아주 조금 줄어드는 것이죠. 개발자는 대체 결제 시스템을 통해 처리되는 거래에 대한 서비스 수수료가 4% 할인됩니다. 단, 참여하려면 구글의 대체 결제 API를 사용해야 하므로 모든 수익은 구글에 돌아갑니다.

하지만 이러한 상황은 바뀔 수 있으며, 그 이유는 애플이 바뀐 것과 같은 이유일 것입니다.

에픽은 애플뿐만 아니라 구글도 고소했습니다.

2024년 10월, 미국 연방 판사는 구글을 상대로 제기된 반독점 소송에서 에픽 게임즈의 손을 들어주며 구글의 안드로이드 앱 스토어가 불법적인 독점을 하고 있다고 판결했습니다. 법원은 구글에게 경쟁을 촉진하기 위해 플레이 스토어 운영 방식을 대폭 개선할 것을 명령했습니다. 

의무적으로 변경해야 하는 사항은 다음과 같습니다

  • 타사 앱 스토어를 Google Play 내에 배포할 수 있도록 허용
  • 개발자가 사용자에게 Google Play 스토어 외부의 대체 결제 방법 및 다운로드 옵션에 대해 알릴 수 있도록 허용합니다
  • 구글이 플레이 스토어에서 배포되는 앱에 대해 구글 플레이 결제 사용을 의무화하는 것을 금지합니다
  • 구글이 개발자나 기기 제조업체에게 경쟁 앱 스토어보다 구글 플레이를 선호하도록 인센티브를 제공하는 것을 제한합니다

해당 변경 사항은 2024년 11월에 발효될 예정이었지만, 구글은 항소를 제기하고 금지 명령 집행 중지를 요청했습니다. 

그래서 지금은 그 자리에 그대로 있습니다.

저희에게 말씀해 주세요... 도와드리겠습니다

인앱 구매 기능을 자체적으로 운영할 계획이시라면 저희에게 문의하세요. 측정, 분석 및 캠페인 최적화 기능을 그대로 유지하면서 인앱 구매를 성공적으로 도입할 수 있도록 단계별로 지원해 드리겠습니다.

오늘 시간을 좀 내주세요.

저자 소개
John Koetsier

John Koetsier

John Koetsier는 저널리스트이자 분석가입니다. 그는 Forbes의 선임 기고자이며 Singular의 Growth Masterminds 팟캐스트와 TechFirst 팟캐스트를 진행합니다. Singular에서 그는 VP, Insights로 활동하고 있습니다.

디지털 마케팅 최신 소식을 받아보세요

이메일 주소를 입력하시면 바로 구독하실 수 있습니다! 스팸을 보내지 않겠다고 약속드립니다.