바이브코딩으로 만든 서비스, PG 없이 오늘 결제를 받는 법

주말에 AI 코딩 도구로 뚝딱 만든 서비스가 있는데, 결제 하나 때문에 못 열고 있는 경우가 많습니다. 카드 결제를 붙이려면 PG 계약과 심사를 먼저 통과해야 하는데, 이 절차는 "만들고 바로 써본다"는 바이브코딩의 속도와 애초에 리듬이 안 맞습니다.

이럴 때 현실적인 선택지가 무통장입금(계좌이체)입니다. 은행 계좌 하나만 있으면 오늘 바로 결제를 받을 수 있습니다. 문제는 입금 확인인데, 이걸 사람이 통장 들여다보면서 하는 순간 자동화는 거기서 끝나버립니다. 페이싱크는 이 확인 구간을 대신 처리해서, 입금이 들어오면 주문과 매칭한 결과를 웹훅으로 넘겨줍니다.

이 글은 AI 코딩 도구로 만든 서비스에 무통장입금 결제를 붙이는 전체 흐름과, AI 에이전트에게 그대로 지시할 때 자주 틀리는 지점을 정리합니다.

왜 바이브코딩엔 무통장입금이 잘 맞나요?

바이브코딩으로 만든 서비스가 결제 앞에서 멈추는 이유는 대개 코드가 아니라 준비물입니다. 카드 결제를 붙이려면 PG 계약·심사·필요 서류가 먼저인데, 이 기간이 "주말에 만들어서 다음 주에 열어본다"는 속도와 맞지 않습니다.

무통장입금은 시작점이 다릅니다. 고객이 상점의 실제 계좌로 직접 이체하는 방식이라 은행 계좌만 있으면 시작할 수 있고, 정산 주기를 기다릴 필요 없이 받은 돈이 바로 계좌에 들어옵니다. 아직 규모가 크지 않은 초기 서비스, 혹은 신청서·모임·강의처럼 '주문'이라는 개념이 느슨한 서비스에서 특히 현실적입니다.

대신 숙제가 남습니다. 입금이 들어왔는지 사람이 확인해야 하고, 입금자명이 주문자명과 다른 경우도 흔합니다. 이 구간을 직접 구현하려면 통장 내역 읽기부터 주문 찾기, 상태 변경, 안내 발송까지 전부 스스로 만들어야 합니다. 이 부분을 대신 처리해주는 서비스를 쓰면, 직접 붙일 코드는 두 지점으로 줄어듭니다.

실제로 붙이는 흐름

작업은 크게 대시보드에서 하는 준비와, 코드로 붙이는 연동으로 나뉩니다.

준비 (사람이 직접 해야 하는 구간)
상점 정보를 등록하고, 입금 받을 계좌를 연동하면서 해당 은행의 입금통지 서비스를 신청하고, API 키를 발급받아 결과를 받을 웹훅 주소를 등록합니다. 화면에서 진행하는 일이라 AI가 대신할 수 없는 구간입니다.

연동 (코드로 붙이는 구간)

주문 등록 — 사용자가 주문을 만드는 순간, 그 주문 정보를 페이싱크에 등록합니다. 입금 안내 화면을 보여주기 전에 등록이 끝나 있어야 합니다.
결과 수신 — 실제 입금이 들어와 주문과 매칭되면 페이싱크가 그 결과를 웹훅으로 보냅니다. 이 요청을 받을 주소를 만들어두고, 받은 결과로 주문을 결제완료로 바꾸고 후속 처리를 잇습니다.

정리하면 사람이 준비물을 만들고, AI가 코드를 쓰고, 마지막 검증은 다시 사람이 합니다. 실제 돈이 오가는 구간인 만큼, 마지막 확인만은 실제 소액 입금 한 건으로 직접 해보는 편이 안전합니다.

AI 에이전트에게 어떻게 지시하면 되나요?

바이브코딩에서 결제 연동이 어긋나는 가장 흔한 이유는, AI가 문서를 읽지 않고 그럴듯한 요청 형식을 지어내는 것입니다. 그래서 지시문의 핵심은 기능 설명이 아니라 "정본 문서를 못 박아주는 것"입니다. 연동 스펙은 페이싱크 개발자센터 문서를 정본으로 지정해두고, 그 문서에 없는 항목은 추측해서 채우지 말라고 명시하면 AI가 상상으로 채울 가능성이 크게 줄어듭니다.

아래 지시문을 사용 중인 AI 코딩 도구에 그대로 붙여넣고 쓰면 됩니다. (문서 주소는 실제 페이싱크 개발자센터 URL로 채워 넣으세요.)

[목표]
내가 만들고 있는 서비스에 무통장입금 결제(입금 자동확인)를 붙인다.
사용 서비스: 페이싱크

[문서]
- 연동 스펙 정본: https://docs.paysync.kr/llms.txt
위 문서를 먼저 읽고, 문서에 적힌 요청 방식과 항목, 응답 규칙을 그대로 따른다.
문서에 없는 항목이나 주소를 추측해서 만들지 않는다.
확인이 안 되면 코드를 쓰기 전에 나에게 묻는다.

[구현할 것]
1. 주문이 만들어지는 시점에 페이싱크에 주문을 등록한다.
2. 입금이 주문과 매칭되면 페이싱크가 결과를 보내준다.
   그 결과를 받을 수신 엔드포인트를 만든다.
3. 결과를 웹훅으로 받으면 정의된 성공 응답을 먼저 반환하고,
   주문 상태 변경과 알림 발송 같은 후속 처리는 그 뒤에 이어서 처리한다.
4. 같은 결과가 다시 도착해도 주문당 한 번만 처리되도록 멱등하게 만든다.
5. 인증 키와 상점 식별값은 환경변수로 읽는다. 소스와 저장소에 남기지 않는다.
6. 주문 등록 실패와 수신 처리 실패를 구분해서 로그로 남긴다.

[주의]
- 주문 등록이 입금보다 늦으면 매칭되지 않는다.
- 매칭 기준이 되는 입금자명은 주문자명과 다를 수 있다.
  별도 입력값으로 다루고 앞뒤 공백을 제거한다.
- 문서에 없는 재시도, 타임아웃, 상태값을 임의로 가정하지 않는다.

바이브코딩이 자주 놓치는 것

AI가 만든 결제 연동에서 반복되는 문제는 대체로 정해져 있습니다. 연동할 때 한 번, 배포 전에 한 번씩 확인하면 좋습니다.

주문을 입금보다 먼저 등록했는가. 매칭은 입금이 들어온 시점에 이뤄집니다. 주문 등록이 늦으면 이미 지나간 입금과는 매칭되지 않습니다.
입금자명을 따로 받고 있는가. 매칭 기준은 주문자명이 아니라 실제 이체할 때 쓰는 입금자명입니다. 가족이나 회사 이름으로 보내는 경우가 흔하니, 주문서에서 따로 입력받고 앞뒤 공백을 다듬어 보내야 합니다.
수신 주소가 외부에서 접근 가능한가. 로컬 개발 주소로는 웹훅을 받을 수 없습니다. 공개된 주소와 유효한 보안 인증서가 필요합니다.
정해진 응답을 돌려주고 있는가. 문서에 정의된 성공 응답을 반환하지 않으면 전송이 실패로 간주돼 재전송 대상이 됩니다. 시간이 걸리는 처리는 응답을 먼저 보낸 뒤로 넘기는 게 안전합니다.
같은 결과가 다시 와도 안전한가. 재전송 구조에서는 한 주문에 처리가 두 번 일어날 수 있습니다. 주문 단위로 한 번만 처리되게 해두면 중복 발송을 막을 수 있습니다.
키를 코드에 그대로 넣지 않았는가. AI가 예시 코드의 키를 그대로 살려 소스에 박아두는 일이 흔합니다. 환경변수로 옮기고 저장소에 올라가지 않는지 확인해야 합니다.

매칭이 실패하는 경우도 있습니다. 그때는 알림을 받고 대시보드에서 입금과 주문을 직접 맞춰 처리할 수 있어, 모든 예외를 코드로 다 막아두지 않아도 운영은 이어갈 수 있습니다.

핵심 정리

바이브코딩과 무통장입금은 궁합이 좋습니다. PG 계약과 심사를 기다리지 않고, 은행 계좌만으로 오늘부터 결제를 받을 수 있습니다.
붙일 코드는 두 지점뿐입니다. 주문이 만들어질 때 등록하고, 입금 매칭 결과를 받아 결제완료로 잇습니다. 통장 확인과 매칭은 페이싱크가 처리합니다.
AI 지시문의 핵심은 정본 문서 고정입니다. 개발자센터 주소를 명시하고, 문서에 없는 항목을 지어내지 말라고 못 박아야 합니다.
자주 놓치는 건 순서·이름·응답입니다. 주문을 입금보다 먼저 등록하고, 입금자명을 따로 받고, 정해진 응답을 돌려주고, 같은 결과가 다시 와도 한 번만 처리되게 하면 대부분 해결됩니다.
마지막 검증은 사람이 합니다. 실제 소액 입금 한 건으로 결제완료까지 이어지는지 직접 확인하고 배포하세요.