바이브 코딩(Vibe-Coded)된 결제 앱이 앱 스토어에서 거부되는 이유

바이브 코딩(Vibe-coded)된 결제 앱은 심사 대기열에 있는 다른 어떤 앱보다 앱 스토어에서 거부되는 비율이 높으며, 그 이유는 대개 코드 품질과 아무런 관련이 없습니다. 바이브 코딩된 앱(AI 어시스턴트에게 원하는 바를 설명하고 작성된 코드를 그대로 배포하여 구축한 앱)은 전문가의 작업과 구별할 수 없을 정도로 훌륭해 보일 수 있습니다. Apple의 심사는 코드의 등급을 매기지 않습니다. 대신 누가 앱을 제출했는지, 어떤 결제 메커니즘이 어떤 유형의 상품을 처리하는지, 하드웨어 권한이 별도로 승인되었는지, 심사위원이 실제 거래를 완료할 수 있는지 여부를 확인합니다. 이것이 바로 AI 어시스턴트가 생성할 수 없는 것들입니다.

이것이 바로 AI 모델로 맞춤형 POS를 구축한 후 모두가 부딪히는 장벽입니다. 코드는 반나절 만에 완성되지만, 이를 실제 결제 앱으로 iPhone에 설치하는 것은 코딩 작업이 아니라 규정 준수(Compliance) 프로세스입니다.

AI가 결제를 잘못된 시스템으로 라우팅했나요?

가장 흔한 거부 사유는 판매되는 상품에 잘못된 결제 메커니즘을 사용하는 것이며, AI 어시스턴트는 유독 이 부분을 자주 틀립니다. Apple의 앱 심사 가이드라인은 엄격한 기준을 제시합니다. 앱 내에서 소비되는 디지털 콘텐츠 및 서비스는 가이드라인 3.1.1에 따라 Apple의 인앱 결제를 사용해야 합니다. 반면 실물 상품 및 오프라인 서비스(커피, 이발, 배송 주문 등)는 가이드라인 3.1.5(a)에 따라 정반대로 처리해야 합니다. 즉, 인앱 결제를 전혀 사용할 수 없으며 외부 결제 수단이 필요합니다.

코딩 모델은 사용자가 무엇을 판매하는지 묻지도 않고, 학습 데이터에서 가장 비중이 높았던 결제 패턴(구독 튜토리얼의 인앱 결제 상용구 또는 이커머스 예제의 웹 결제 SDK)을 그대로 재현합니다. '결제를 처리하는 앱'을 프롬프트로 입력하면 Apple의 규칙이 아닌 통계적 확률에 따라 두 가지 중 하나를 제공받게 됩니다. 또한 이 규칙은 스토어 국가별로 다릅니다. 2025년 Epic 판결 이후 미국 스토어의 앱은 디지털 상품에 대해 외부 결제 옵션 링크를 제공할 수 있게 되었지만, 이러한 예외는 미국에만 적용됩니다. 전 세계에 배포되는 앱은 다른 모든 지역에서 여전히 더 엄격한 규칙을 충족해야 합니다.

결제 앱을 제출할 자격이 있나요?

Apple은 자금 관리 또는 금융 서비스를 처리하는 앱의 경우, 해당 서비스를 실제로 제공하는 기관이 앱이 제공되는 모든 지역에서 필요한 라이선스를 보유한 상태로 제출할 것을 요구합니다(가이드라인 3.2.1). AI가 생성한 결제 앱을 배포하는 개인 개발자는 라이선스를 보유한 금융 기관이 아니며, 고객을 대신해 제출하는 대행사도 마찬가지입니다. 자금 이동 라이선스가 없는 국가에서 앱을 제공하는 것은 거부 사유가 되며, 단지 거부 통지서의 발송지만 달라질 뿐입니다.

Apple의 심사위원은 귀사의 규정 준수 프로그램이 우수한지 평가하지 않습니다. 올바른 주체가 앱을 제출했는지만 확인하고, 그렇지 않은 경우 거부합니다. 어떤 프롬프트로도 이를 해결할 수 없습니다.

왜 Tap to Pay는 별도의 승인 프로세스가 필요한가요?

iPhone에서 비접촉식 카드를 결제받으려면 Tap to Pay on iPhone 권한(Entitlement)이 필요합니다. 이는 앱 심사와는 무관하게 Apple에 별도로 신청해야 하며, 코드베이스가 아닌 법인에 부여됩니다. 개발 권한은 보통 하루 이틀 만에 승인됩니다. 하지만 배포 권한은 Apple의 운영 팀을 거치며 일반적으로 1~2주일이 소요되고, 지원되는 결제 서비스 제공업체와의 협력이 필요합니다. AI 어시스턴트는 이러한 사항을 전혀 언급하지 않고 기꺼이 Tap to Pay 코드를 작성해 주지만, 권한이 부여되기 전에 제출하면 앱은 반려됩니다.

대면 카드 결제 수락에는 Apple의 소관이 아닌 요구사항도 수반됩니다. 인증된 리더기 하드웨어, EMV 규칙, 카드 데이터에 접근하는 모든 것에 적용되는 PCI 범위 등이 이에 해당합니다. Swift 코드를 작성하는 모델은 이러한 것들을 해결해 주지 못합니다.

심사위원이 실제로 거래를 완료할 수 있나요?

가이드라인 2.1 '앱 완성도'는 결제 규칙보다 더 많은 결제 앱을 소리 없이 탈락시킵니다. 심사위원은 결제 흐름을 포함하여 앱의 모든 기능을 실행할 수 있어야 합니다. 결제 앱은 일반적으로 가맹점 계정, 신원 확인, 때로는 은행 계좌가 필요하지만, 심사위원이 심사 중에 이러한 것들에 가입할 수는 없습니다. 바이브 코딩된 제출물은 이 단계에서 끊임없이 실패합니다. 개발자가 직접 실제 가맹점 계정을 개설한 적이 없고, 앱이 AI가 생성한 가상 데이터로만 테스트되었기 때문입니다. 작동하는 데모 계정과 테스트 거래를 실행할 방법이 없다면 앱은 미완성으로 거부되며, 재제출할 때마다 또 다른 심사 주기가 소요됩니다.

그렇다면 실제로 배포되는 것은 무엇인가요?

어려운 부분은 결코 코드가 아니었습니다. AI 어시스턴트는 반나절 만에 작동하는 결제 인터페이스를 만들어낼 수 있지만, 앱 스토어 배포는 프롬프트가 도달할 수 없는 권한, 라이선스, 심사 정책이라는 험난한 과정을 거쳐야 합니다. 데모는 작동하지만, 인프라는 아직 존재하지 않는 것입니다.

실물 상품을 판매하는 가맹점의 경우, 실질적인 결론은 더 간단합니다. 심사 대기열에 들어가지 마십시오. 귀사의 비즈니스에 필요한 것은 작동하는 결제 시스템이지, 앱 스토어에 등록된 자체 앱이 아닙니다. 라이선스, 하드웨어 인증, 심사 오버헤드는 결제 소프트웨어 자체가 제품인 회사에만 의미가 있습니다. 이미 이러한 비용을 감당하고 있는 POS 플랫폼에서 카운터를 운영하고(Final이 바로 이 방식으로 구축되었습니다. 자체 앱을 게시할 필요 없이 인증된 단말기 하드웨어와 Final Pay를 통해 결제 처리), 심사 주기에 낭비될 돈을 더 빠른 결제 흐름이나 더 낮은 실질 카드 수수료와 같이 매출을 높이는 데 투자하십시오.

Apple의 심사 프로세스가 존재하는 데는 타당한 이유가 있습니다. 실패한 금융 앱은 실제 사람들에게 피해를 주기 때문입니다. 하지만 누가 또는 무엇이 앱을 작성했든 간에, 대부분의 가맹점이 이 프로세스를 통과할 필요는 없습니다.