BLOG ·

앱 결제 연동, 인앱결제와 PG 중 무엇을 써야 할까 — 로그인·결제가 코드보다 허가에서 막히는 이유

앱 외주 상담에서 "결제는 그냥 붙이면 되죠?"라는 말을 자주 듣습니다. 그런데 결제와 로그인은 일정이 가장 자주 빗나가는 구간입니다. 코드가 어려워서가 아닙니다. 앱 결제 연동은 어떤 방식을 써야 하는지가 스토어 규정과 가맹 심사로 정해지고, 그 허가 절차가 코드 작성보다 오래 걸리기 때문입니다. 방식을 거꾸로 고르면 다 만든 뒤 심사에서 돌아오고, 서류를 늦게 내면 코드가 끝나도 테스트 결제밖에 못 합니다.

저희는 '플린앱스'라는 이름으로 앱을 만들어 온 대전의 에이전시, 주식회사 굿데이터랩입니다. 이 글은 어느 업체에 맡기시든, 혹은 직접 만드시든 그대로 쓰실 수 있도록 결제와 로그인에서 기획 단계에 미리 정해 둘 것만 정리한 것입니다. 심사 거절 전반은 앱스토어 심사 거절 글에 있고, 여기서는 결제와 로그인만 다룹니다.

결제 방식은 '무엇을 파느냐'가 정합니다

앱에서 돈을 받는 방법은 크게 두 가지입니다. 하나는 애플과 구글이 제공하는 스토어 인앱결제이고, 다른 하나는 카드사와 앱 사이에서 결제를 중개하는 결제대행사(PG) 입니다. 어느 쪽을 쓸지는 취향이 아니라 규정입니다. 기준은 단순합니다. 앱 안에서 소비되는 디지털 상품이면 인앱결제, 앱 밖에서 소비되는 실물·오프라인 서비스면 PG입니다.

파는 것 예시 결제 방식
앱 안에서 쓰는 디지털 상품 구독 멤버십, 프리미엄 기능 해제, 포인트·코인, 유료 콘텐츠 스토어 인앱결제
앱 밖에서 소비되는 상품·서비스 실물 배송 상품, 음식 주문, 예약·방문 서비스, 오프라인 수업 일반 PG

두 스토어 모두 이 구분을 심사 기준으로 씁니다. 앱 안에서 소비되는 기능을 PG로 받으면 애플은 가이드라인 3.1.1(인앱 구매)을 근거로 거절하고, 반대로 실물 상품을 인앱결제로 받는 것도 허용되지 않습니다. 가장 흔한 실수는 "수수료가 싸니까 구독도 PG로 받자"입니다. 코드로는 되지만 심사에서 돌아오고, 그때 결제 모듈을 바꾸면 결제 화면·서버·관리자 정산까지 다시 만듭니다.

애매한 경우도 있습니다. 앱에서 재생하는 강의는 디지털 상품이지만, 같은 강의가 오프라인 수업권이면 PG 쪽입니다. 경계는 "사용자가 결국 무엇을 손에 쥐는가"로 갈라야 하고, 두 종류를 다 판다면 결제 방식도 둘 다 붙일 각오를 해야 합니다.

수수료 구조가 수익 모델을 바꿉니다

두 방식은 수수료 구조가 완전히 다릅니다.

같은 만원짜리 상품도 인앱결제면 손에 남는 돈이 7천원에서 8천5백원 사이이고, PG면 9천원대입니다. 구독형 서비스를 PG 수수료로 계산해 두었다면 출시 뒤 숫자가 달라집니다. 국내에서는 전기통신사업법 개정 이후 앱 안에 제3자 결제를 함께 둘 수 있게 됐지만, 그 경우에도 스토어가 별도 수수료를 받는 구조라 기대만큼 줄지 않습니다. 결제 방식은 수익 모델을 짜는 단계에서 같이 정하는 항목이지, 개발 끝에 붙이는 옵션이 아닙니다.

어느 쪽을 쓰든 이 수수료는 개발비 바깥의 외부 실비입니다. 노에이전트도 800만원(부가세 포함) 정액에 결제 연동 작업은 포함하지만, 수수료 자체는 상담에서 예상 금액을 미리 안내할 뿐 대신 낼 수 있는 돈이 아닙니다.

PG는 코드보다 가맹 심사가 먼저입니다

PG를 쓰기로 했다면 개발과 별개로 서류 절차가 시작됩니다. 사업자등록증, 통신판매업 신고증, 정산 계좌, 대표자 확인, 그리고 상품과 가격이 보이는 화면이 통상 요구됩니다. 심사는 며칠에서 길면 한두 주가 걸리고, 그동안 개발은 테스트 환경으로 진행할 수 있습니다. 문제는 심사가 끝나기 전에는 실제 결제를 한 건도 해볼 수 없다는 점입니다.

그래서 순서가 중요합니다. 결제 방식이 PG로 정해졌다면 그 주에 가맹 신청을 넣는 것이 맞습니다. 개발이 끝난 뒤에 신청하면 심사 기간만큼 출시가 밀립니다. 통신판매업 신고가 아직이라면 그것부터입니다. 업종에 따라 가맹이 까다롭거나 거절되는 경우도 있어서(성인·의료·금융 등 일부 업종), 기획 단계에서 확인해야 합니다.

인앱결제는 가맹 심사가 없는 대신 스토어 개발자 계정과 세금·은행 정보 등록이 선행됩니다. 이 계정에도 대기 기간이 있으니 개발자 계정 만들기 글의 순서대로 먼저 신청해 두세요.

로그인도 '작동하는 것'과 '통과하는 것'이 다릅니다

로그인은 간단해 보이지만 심사 요건이 따로 있습니다.

카카오를 넣으면 애플도 넣어야 합니다. iOS 앱이 카카오·구글·네이버 로그인을 제공하면, 애플은 Apple로 로그인(또는 애플이 인정하는 동등한 수준의 로그인)을 함께 제공할 것을 요구합니다. 안드로이드에서는 필요 없는 버튼이 iOS 심사에서는 필수이므로 화면 설계 때 분기해 두어야 합니다.

카카오 로그인은 사업자 인증을 거쳐야 받을 수 있는 항목이 있습니다. 이메일을 필수 동의로 받으려면 카카오 쪽 비즈니스 인증(비즈 앱 전환)이 필요합니다. 테스트 때는 되던 로그인이 출시용으로 바꾸면서 막히는 경우가 여기서 생깁니다.

가입보다 탈퇴가 더 자주 걸립니다. 애플과 구글 모두 계정을 만들 수 있는 앱이라면 앱 안에서 계정을 삭제하는 기능을 요구합니다. 탈퇴 화면이 없다는 걸 심사 제출 직전에 발견하는 일이 잦습니다. 소셜 로그인은 연동 해제까지 함께 처리해야 합니다.

개인정보처리방침 주소는 두 스토어 공통 필수입니다. 로그인을 붙이는 순간 개인정보를 수집하는 앱이 되고, 스토어 등록 화면에 공개된 처리방침 URL을 적어야 합니다. 앱 안에서도 열려야 합니다. 이 페이지가 없어서 제출이 멈추는 경우가 생각보다 많습니다.

본인인증(휴대폰 인증)이 필요하면 인증 사업자와의 계약이 또 붙습니다. 이것도 계약이 먼저입니다.

기획 단계에서 정해 둘 다섯 가지

일정이 밀리는 원인은 대부분 아래 다섯 가지를 개발 끝에 정했기 때문입니다. 킥오프에서 미리 적어 두면 코드는 순서대로 나옵니다.

  1. 파는 것이 디지털 상품인가, 실물·오프라인인가. 이 답이 인앱결제와 PG를 가르고 수익 모델을 정합니다.
  2. 둘 다 파는가. 그렇다면 결제 모듈이 두 개이고 정산 화면도 둘입니다. 1차 출시는 한쪽만 가는 것도 방법입니다.
  3. 사업자 서류가 있는가. 사업자등록증·통신판매업 신고·정산 계좌. PG라면 기획 확정 직후 가맹 신청을 넣습니다.
  4. 어떤 로그인을 제공하는가. 소셜 로그인을 하나라도 넣으면 iOS에는 Apple 로그인이 따라오고, 탈퇴·연동 해제 화면이 필요합니다.
  5. 개인정보처리방침은 어디에 올릴 것인가. 공개 URL 하나가 필요합니다. 랜딩 페이지가 없다면 간단한 페이지라도 먼저 만듭니다.

이 다섯 가지가 적혀 있으면 견적서의 "결제 연동 포함" 한 줄이 무엇을 포함하는지 물어볼 수 있습니다. 인앱결제인지 PG인지, 가맹 신청은 누가 하는지, 탈퇴와 처리방침은 범위에 있는지입니다.

결제·로그인이 걱정이라면

노에이전트는 결제 방식 판단부터 인앱결제·PG 연동, 소셜 로그인과 Apple 로그인, 탈퇴 화면, 스토어 심사 제출과 거절 대응까지 800만원(부가세 포함) 정액에 포함합니다. 결제 수수료와 스토어 계정 등록비처럼 정액 바깥의 외부 실비는 킥오프에서 항목별로 미리 안내합니다. 내 서비스가 인앱결제인지 PG인지만 확인하고 싶으셔도 괜찮습니다. 상담은 무료입니다.