AI와 만든 앱에 결제를 붙이는 가장 현명한 방법들 (Feat. MoR)

“SaaS 만들어줘”라고 AI에 말하면 진짜로 하루 만에 돌아가는 앱이 나오는 시대입니다. 그런데 “여기에 월 9,900원 구독 결제 붙여줘”라고 던지는 순간, 대화가 뚝 끊기곤 합니다. 화면은 멀쩡한데 결제 앞에서 프로젝트가 멈춰 서는 거죠. 이게 요즘 말하는 바이브 코딩의 진짜 병목입니다.

많은 분이 결제를 버튼 하나 붙이면 끝나는 기능쯤으로 생각합니다. 하지만 실제 결제는 다른 일반 기능들과 차원이 다릅니다. 사업/세금/환불/심사/정산이 한 덩어리로 묶인 운영 시스템에 가깝죠. 그래서 단순 연동처럼 보이지만, 중간에 PG 심사나 세금 처리 같은 현실 이슈가 튀어나옵니다. 이 지점부터는 AI도 “그건 상황에 따라 달라요” 모드로 멍청해집니다.

그런 만큼 제대로 결제를 도입하려면 더 많은 것을 알아야 하지만요, 이 글에서는 복잡한 설명은 최대한 하지 않겠습니다. 대신 딱 3가지 질문으로 상황을 먼저 분류하고, 케이스별로 가장 빠르게 첫 결제를 받는 경로까지 연결해 보겠습니다. 중요한 건 최고의 결제 도구가 아니라 지금 내 상황에서 제일 빨리 돈이 들어오는 선택지니까요. 이제부터 같이 보겠습니다.

결제가 없다면 “검증”은 모두 거짓말

’결제’라는 운영 시스템은 크게 세 가지로 나눠 보면 편합니다. 돈 받기(결제), 돈을 누구 이름으로 받는지(판매 주체), 돈을 받은 뒤 책임(세금·환불·증빙)을 관리하는 방식이죠. 이 셋을 한 번에 생각하지 않으면, 연동은 어렵습니다. 그리고, 이러한 결제가 없다면 검증은 모두 거짓말에 가깝습니다. SNS 글에 좋아요를 1,000개 받아도 결제 1건보다 검증 수치는 약하니까요.

왜 바이브 코딩에서 결제는 병목이 되는가

AI가 코드는 뽑아줄 수 있습니다. 하지만 사업자 요건, PG 심사, 세금, VAT, 환불정책은 자동완성이 잘 안 됩니다. 예를 들어 “구독 취소하면 남은 기간은 어떻게 환불하지?” 같은 질문은 제품 정책에서 나옵니다. 또, 여기서부터는 사회 규범과 법이 함께합니다. 돈을 받고 모른 척 하면 그때부터는 심판의 문제가 된다는 겁니다. 해외 결제라면 국가별 VAT 같은 이슈가 튀어나옵니다. 그러니까 이건 어떻게든 적당히 넘길 수 없습니다. 반드시 사람이 깊이 개입해 결정해야 합니다.

그래서 PMF(사람들이 진짜 돈 내는지 확인하는 단계) 이전에는 완벽한 결제보다 검증 가능한 과금이 우선입니다. 여기서 말하는 핵심은 첫 결제입니다. 첫 결제가 찍히면 누군가는 돈을 낸다는 가정이 사실이 됩니다. 그때부터 결제 UX, 세금 처리, 환불 로직을 고도화해도 늦지 않습니다.

물론 계좌번호를 띄워놓고 무통장 입금을 받을 수도 있습니다. 카카오페이·네이버페이 QR을 올려두는 방법도 있습니다. 하지만 그 방식은 보통 “운영자가 매번 처리해야 하는” 형태입니다. 제품이 알아서 돌아가는 시스템으로는 약합니다. 그래서 한 번은 제대로 된 결제 시스템을 얹어봐야 합니다. 그때 꼭 알아야 할 개념이 MoR과 PG입니다.

MoR(Merchant of Record) vs 일반 PG/PSP

헷갈릴 수 있으니 비유로 풀어보겠습니다.

MoR(Merchant of Record)은 판매 대행상에 가깝습니다. 고객에게 돈을 받고, 영수증을 끊고, 세금과 환불까지 책임지는 쪽이 MoR입니다. 쉽게 말해 돈이 들어오는 순간부터 뒤처리까지 모두 같이 떠안습니다. 그래서 그런 작업에 대한 수수료를 떼고 남은 돈을 보내줍니다.

반대로 일반 PG/PSP는 카드 단말기에 가깝습니다. 결제는 시스템까지 관리해 통과시켜 주지만, 그 뒤의 운영 책임은 내 몫입니다. 예를 들어 Stripe나 국내 PG는 보통 이쪽에 가깝습니다. 결제 창은 붙일 수 있지만 세금·VAT·환불 정책 같은 건 내가 설계해야 한다는 뜻입니다.

그래서 이 두 가지의 선택 기준은 의외로 단순합니다. “나는 지금 결제 뒤처리까지 떠안을 여력이 있나?”라는 질문을 던져보는 겁니다. 여력이 없다면 MoR이 빠르고, 여력이 있다면 일반 PG/PSP가 유연합니다. 바이브코딩으로 속도를 내고 싶을수록 이 차이가 더 크게 느껴질 겁니다.

시작 전에 3가지만 결정하면, 도구는 80% 자동으로 좁혀진다

결제 도구를 고르기 전에 먼저 우리 제품이 무슨 문제를 푸는지 정의해야 합니다. 그러면 곧바로 누가 그 문제를 겪고 있는지, 즉, 고객을 알 수 있겠죠. 그래서 그 고객을 아래 질문과 대응시켜야 합니다. 기능 비교표를 펼치기 전에 방향부터 잡으면 선택지가 자동으로 줄어듭니다. 아래 3가지 질문에 답해보면 됩니다.

질문 1. 결제하는 사람이 한국 유저인가, 해외 유저인가?

이건 결제창을 붙이는 방법이 아니라 결제 뒤에서 터지는 일이 달라지는 문제입니다. 한국 유저라면 카드와 간편결제 UX가 핵심이고, 해외 유저라면 세금과 통화, 실패 처리 같은 운영 이슈가 먼저 튀어나옵니다. 쉽게 말해, 한국은 결제수단이 다양해서 흐름이 복잡하고, 해외는 국가가 다양해서 규칙이 복잡합니다.

한국 유저가 주로 결제한다면 PG 연동이 일단 최우선입니다. 다만 이건 연동한다고 끝나는 문제가 아니라, 심사와 정산까지 포함된 운영 계약에 가깝습니다. 특히 나중에 고객응대나 회계 처리에서 발목 잡히지 않으려면 처음부터 흐름을 그려두는 게 좋습니다. 당연히 안전하지만, 속도는 느릴 겁니다. 물론 그런 만큼 한국 유저들에 익숙한 흐름입니다. 결제 과정이 이탈의 요소가 될 가능성은 적죠.

해외 유저가 결제한다면 질문이 바뀝니다. 결제가 되는지보다 결제가 된 다음 세금과 분쟁을 감당할 수 있냐는 문제가 더 중요해집니다. 특히 SaaS는 결제 실패와 차지백이 생각보다 자주 생기고, 그때의 대응 방식이 곧 운영 비용이 됩니다. 그래서 이슈가 생겼을 때 어떻게 대응할지를 공부해야 합니다.

질문 2. 구독 vs 일회성 vs 사용량 기반

같은 결제라도 과금 모델이 달라지면 필요한 기능이 완전히 달라집니다. 요금제 변경과 환불, 실패 복구 같은 운영 로직도 붙기 때문입니다. 그래서 도구를 고를 때도, 결제창보다 운영 시나리오를 먼저 적어보는 게 안전합니다.

구독이라면 결제는 시작일 뿐입니다. 유저는 중간에 플랜을 바꾸고, 무료체험을 쓰고, 결제를 놓치기도 합니다. 이걸 매번 사람이 처리하면 앱이 커질수록 운영이 무너집니다.

일회성 결제는 단순해 보이지만, 막상 운영하면 환불이 핵심입니다. “환불해 주세요”라는 요청은 거의 반드시 오고, 부분환불도 종종 생길 겁니다. 또 디지털 상품이라면 결제 완료 후 전달하는 프로세스가 분명히 만들어져야 CS가 줄어듭니다.

사용량 기반은 계량(usage metering)이 전부입니다. 특히 AI 앱은 토큰이나 요청 수를 정확히 집계해야 하는데, 이게 성능과 정확도 둘 다에서 병목이 되기 쉽습니다. 즉, 결제 연동보다 먼저 무엇을, 어떤 단위로, 언제 집계할지 결정해야 합니다.

질문 3. 사업자등록이 있는가, 없는가?

사실 이것이야말로 애초에 가능한 선택지가 뭔지 가르는 질문입니다. 특히 국내에서는 PG가 거의 모두 사업자 기반으로 움직이는 경우가 많아 사업자등록 유무가 곧 출발선이 됩니다.

사업자등록이 없다면, 현실적으로 국내 PG 연동이 막히는 경우가 많습니다. 그래서 이 단계에서는 MoR(Merchant of Record) 같은 대안이나 노코드형 우회가 더 빠른 선택이 될 수 있습니다.

사업자등록이 있다면, 이제부터는 장기 운영이 가능한 구조를 고르는 게 중요합니다. 심사 통과만이 아니라 정산 주기와 세무 처리까지 이어지는 흐름이 있기 때문입니다. 처음엔 작은 앱이어도 결제가 붙는 순간부터는 운영이 ’업무’가 됩니다. 그러니 심사, 정산, 세무 프로세스를 맞춰야 합니다.

3가지 기준, 즉, “국내/해외 × 과금모델 × 사업자 유무” 매트릭스를 만들면 내 케이스가 한 칸으로 떨어집니다. 다음 단계는 간단합니다. 그 칸에서 정답에 가까운 결제 도구를 고르고, 가장 빠른 연동 경로로 첫 결제를 받는 겁니다.

내가 처리 안 하는 게 첫 런칭에 유리하다: Polar·Lemon Squeezy·Paddle

결제를 시도할 때 사람들이 가장 많이 멈칫하는 지점은 따로 있습니다. 세금과 증빙입니다. “VAT는 누가 처리하지?”, “환불하면 영수증은?”, “나는 사업자도 아닌데 괜찮나?” 같은 질문이 한꺼번에 몰려옵니다. 운영의 책임이 눈앞에 나타나기 때문입니다.

그래서 이럴 때는 MoR을 검토해 보는 것을 권합니다. 물론 모두 해외 서비스여서 한국 사람에게 익숙한 UX를 지원하지 않는데다 제한되는 상황도 많습니다. 수수료도 쎄고요. 그래도 운영의 책임을 큰 폭으로 줄여주는 것은 분명합니다. PG 심사를 위해 사업자등록증부터 발급해야 한다는 상황이라면, 더더욱이요. 역으로 생각해도 좋습니다. 해외 타깃으로도 시도해 볼 수 있다는 거니까요.

Polar: AI 앱 메이커를 위한 판매자의 역할

Polar는 오픈소스 MoR(Merchant of Record) 입니다. 특히 해외 결제에서 골치 아픈 세금·VAT 처리를 Polar가 대행해줍니다. 처음 런칭할 때 “세금 설계부터 해야 하나?”라는 부담을 크게 줄여줍니다.

Polar의 첫 번째 강점은 사용량 기반 과금(usage-based) 을 기본으로 깔고 있다는 점입니다. 특히 OpenAI·Anthropic API 사용량을 자동으로 수집해서, 유저별로 쓴 만큼 청구하는 흐름이 자연스럽게 이어집니다. AI 앱은 비용 구조가 토큰 사용량에 붙어있는 경우가 많습니다. 이때 Polar는 결제 모델과 제품 구조가 잘 맞습니다.

두 번째 강점은 비용입니다. Polar는 수수료가 4% + 40¢로 알려져 있습니다. MoR 계열 중에서도 저렴한 축에 속합니다. 첫 매출이 작을수록 이런 고정 비용 차이가 체감됩니다.

세 번째 강점은 디지털 혜택을 결제와 바로 묶는 능력입니다. 예를 들어 GitHub 레포 접근권, 라이선스 키 같은 혜택을 구독과 연결할 수 있습니다. 즉, 결제가 끝나면 권한이 자동으로 열리는 그림이 나오는 거죠. 운영자가 손으로 처리할 일이 줄어듭니다.

현실적인 측면에서, Polar는 사업자등록 없이도 시작할 수 있습니다. 그래서 일단 팔리는지 검증이 목표인 단계에 특히 유리합니다. 첫 런칭에서 중요한 건 완벽한 구조가 아니라 빠른 학습 속도입니다.

Lemon Squeezy: AI가 아닌 일반 SaaS/디지털 상품에 범용

Lemon Squeezy도 MoR이라 세금 부담이 상대적으로 적습니다. 체크아웃과 기본 설정이 직관적이라 결제 연동에 시간을 많이 쓰고 싶지 않을 때 편합니다. 일단 결제 페이지부터 띄우자는 목표에 잘 맞습니다.

특히 처음엔 제품 내에서 예쁜 결제 페이지와 빠른 판매를 연결하는 게 더 중요한 경우가 많습니다. 개인 메이커나 소규모 팀이라면 더 그렇습니다. 이럴 때 Lemon Squeezy는 설정하다 지쳐서 출시가 밀리는 상황을 줄여줍니다.

마찬가지로 개인도 시작할 수 있다는 점이 장점입니다. 법인부터 만들고 오는 대신 작은 시작을 받아주는 쪽에 가깝습니다. 첫 런칭의 허들을 낮추는 선택지입니다.

Paddle: B2B SaaS로 커질 계획이라면

Paddle은 MoR 기반이면서, 인보이스와 엔터프라이즈 기능까지 제공합니다. 쉽게 말해, 결제가 개인 카드 결제에서 끝나지 않는 환경을 염두에 둔 도구입니다. B2B SaaS는 자연스럽게 나중에 견적서, 인보이스, 내부 결재 같은 흐름이 따라오는데요. 그때 필요한 기능을 한 번에 묶어둔 쪽입니다.

다만 1인 메이커의 첫 런칭이라면 Paddle은 오버스펙일 수 있습니다. 처음부터 큰 조직의 프로세스를 들고 오면 출시 속도가 느려질 수 있거든요. 그래서 지금 필요한지, 나중에 필요한지, 성장 계획이 명확할 때 선택하는 편이 낫습니다.

한국에 있어야 결국에는 더 빠르다: 토스페이먼츠·스텝페이·포트원

국내 결제는 “코드만 붙이면 끝”이 아닙니다. 보통 사업자등록이 먼저 필요하고, 그다음에 PG 심사가 끼어듭니다. 이 심사가 보통 1~3일은 걸리다 보니 오늘 당장 결제 받기가 목표라면 도구 선택이 꺼려질 수도 있습니다.

하지만, 같은 기능이라도 연동 과정이 매끄러운 쪽이 결국 더 빨리 출시됩니다. 여기서 말하는 속도는 단지 개발 속도가 아닙니다. 심사, 정산, 운영까지 감안했을 때의 체감 속도입니다. 문제가 생겼을 때, 한글로 쓰여진 가이드, 한글이 편한 상담원과 대화할 수 있는 것이 마음에 훨씬 편하죠. 그래서 국내 유저를 받을 때 무작정 MoR을 먼저 떠올리기보다, 내 상황에 맞는 결제 도구가 무엇인지부터 보는 게 안전합니다.

토스페이먼츠: 바이브코딩과 궁합이 좋은 포지션

토스페이먼츠는 국내에서 개발자 경험(DX)이 좋기로 유명한 쪽입니다. 연동 문서와 흐름이 비교적 매끄러워서 일단 붙여서 돌아가게 만들기가 빠릅니다. 최근에는 MCP 서버까지 도입하면서 바이브 코딩 흐름과의 궁합이 더 좋아졌습니다.

쉽게 말해, Cursor나 Claude Code에서 “결제창 연결해줘” 같은 자연어 지시를 했을 때, 연동에 필요한 코드가 생성되는 길이 열린 겁니다. 예전에는 문서 읽고, 샘플 찾고, 키를 맞추는 시간이 컸다면, 이제는 그 구간이 짧아질 수 있습니다. 다만 여기서 기대치는 관리해야 합니다. 코드는 당일에 붙어도, 상용 오픈은 PG 심사 이후라는 점은 그대로입니다.

스텝페이: 구독 운영을 제품으로 제공하는 길

스텝페이는 결제창을 연동하는 도구라기보다, 구독 운영을 제품으로 묶어서 제공하는 쪽에 가깝습니다. 노코드로 구독 스토어를 만들 수 있고, 정기결제에 필요한 기능들이 기본으로 들어 있습니다. 개발 리소스가 적을수록 이 차이가 크게 느껴집니다. 특히 구독 SaaS에서 진짜 어려운 건 결제 버튼이 아닙니다. 요금제 운영과 미납 처리가 본게임입니다. 스텝페이는 이런 구간을 제품 기능으로 제공합니다. 예를 들면 아래 같은 것들입니다.

• 사용량 기반 과금
• 무료 체험
• 결제 복구(미납 시 카톡 청구서 등)

그래서 요금제가 복잡하거나, 정기결제 운영을 빨리 검증해야 하거나, 일단 팔아보고 고치자가 목표일 때 또 고려할 만한 선택지입니다. 결제를 붙이는 속도뿐 아니라, 운영까지 포함한 속도가 빨라집니다.

포트원: 결제수단을 여러 개 붙일 때의 통합 레이어

포트원은 여러 결제수단을 한 번에 다루고 싶을 때 빛납니다. 토스페이먼츠, KG이니시스, 카카오페이, 네이버페이 같은 것들을 하나의 SDK로 통합하는 방식입니다. 쉽게 비유하면, 결제사마다 다른 리모컨을 쓰는 대신 리모컨 하나로 여러 기기를 조작하는 느낌입니다.

다만 이 방식이 처음부터 좋다고는 말하기 어렵습니다. 결제가 하나도 안 나오는데 창구는 10개 열어둬봤자니까요. 핵심 이점은 나중에 나옵니다. 처음에 선택을 잘못했을 때면 보통은 연동 코드를 다시 갈아엎어야 하는데요. 포트원은 PG사를 변경/추가하는 비용을 낮춰서 초기 선택 실수 비용을 줄여줍니다.

그래서 결제수단을 빠르게 다변화해야 하거나, 특정 PG에 락인(lock-in) 되는 게 걱정될 때 붙이기 좋습니다. 지금은 하나로 시작하되, 다음 분기에 확장할 가능성이 높다면 특히 안정적인 선택이 됩니다.

물론 사실 이 모든 것보다 중요한 건 수수료가 아닐까요? 수수료는 조금씩 달라지기도 하고, PG를 제공하는 기업이 워낙 많은 만큼 따로 정리하지는 않았습니다. 국내 PG를 붙이기로 마음 먹었다면 웬만하면 여러 PG를 꼼꼼하게 검토하기를 추천드립니다. 여기 남긴 것들은 좀 특수한 성격을 가진 것들 위주입니다.

+ 그 전에, 불안을 줄이는 “고객 체크리스트” 먼저

첫 결제를 빨리 받는 것만큼, 사용자의 불안을 줄이는 것도 중요합니다. 거창한 문서가 아니라 최소한 아래 다섯 가지는 화면 어딘가에 보이게 두는 게 좋습니다. 여기 돈 내도 괜찮다는 느낌이 생겨야 결제 전환이 생깁니다.

• 환불 기준: 언제까지, 어떤 조건이면 환불되는지 한 문장으로
• 결제 실패 안내: 결제 오류가 나면 무엇을 확인해야 하는지
• 고객문의 채널: 이메일/오픈채팅 등 연락할 곳 하나는 고정
• 이용약관 위치: 링크 한 줄이라도 찾을 수 있게
• 영수증/세금 처리 방식: 영수증 제공 여부, 세금계산서 가능 여부 등

결국 첫 결제는 기능이 아니라 신뢰의 문제입니다. 정책을 크게 만들 필요는 없고 불안 포인트만 먼저 제거하면 됩니다. 그렇게 하면 결제, 연동, PG라는 큰 산도 생각보다 빨리 넘어갈 수 있습니다.

마치며

바이브코딩 시대에 결제의 난이도는 코드가 아니라 내 상황에 맞는 도구 선택에 가깝습니다. 연동만 붙이면 끝처럼 보이지만, 막상 들어가면 PG, 세금, 환불, 정책이 한꺼번에 따라오니까요. 그래서 복잡하게 시작하지 말고 딱 세 가지 질문으로 갈라타면 됩니다. 핵심은 (1) 국내/해외 (2) 과금모델 (3) 사업자 유무입니다.

이제 남은 건 실행입니다. 오늘은 내 서비스 조합을 먼저 적어보세요. 예를 들어 “빠른 시도 + 구독 + 사업자 없음” 같은 형태로요. 조합이 정해지면 루트는 거의 자동으로 좁혀집니다. Polar/Lemon Squeezy 중 하나를 골라 첫 결제까지 하루 안에 도달하는 걸 목표로 잡으면 됩니다.

그리고 여기서 중요한 마인드셋이 하나 있습니다. 진짜 어려운 건 결제를 붙이는 것이 아니라 결제해줄 유저를 찾는 것이라는 마인드입니다. 결제, 연동, PG에 에너지를 다 쓰며 매달리기보다 가능한 한 빨리 마케팅과 세일즈로 이동하는 편이 훨씬 현명합니다. 돈 낼 사람을 찾고, 그 사람의 마음이 어느 정도인지 알아보는 것이 바이브 코딩에는 더 중요할지 모르겠습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.