결제만 붙이면 끝나는 서비스가, 결제 때문에 몇 주째 못 열리고 있진 않나요? PG 심사는 바이브코딩의 속도와 애초에 맞지 않습니다. 은행 계좌 하나로 오늘 결제를 받는 방법이 있습니다 — 무통장입금(계좌이체)입니다. 문제는 입금 확인인데, 그걸 사람이 하는 순간 자동화는 끝납니다. 페이액션은 입금을 1초 만에 자동 확인해 주문과 매칭하고, 결과를 웹훅으로 넘겨 줍니다.
이 글은 AI 코딩 도구로 만든 서비스에 무통장입금 결제를 붙이는 전체 순서와, AI 에이전트에게 그대로 붙여 넣을 수 있는 지시문, 그리고 AI가 특히 자주 틀리는 지점을 정리합니다. 요청 형식과 보내야 할 항목, 응답 규칙 같은 연동 스펙은 페이액션 개발자센터에 공개돼 있으니 구현할 때 그 문서를 기준으로 삼으면 됩니다.
왜 바이브코딩에는 무통장입금이 잘 맞나요?
바이브코딩으로 만든 서비스가 결제 앞에서 멈추는 이유는 대개 코드가 아니라 준비물입니다. 카드 결제를 붙이려면 PG 계약과 심사를 먼저 거쳐야 하고, 필요한 서류와 심사 기간이 ‘주말에 만들어 다음 주에 열어 보는’ 속도와 잘 맞지 않습니다.
무통장입금은 출발점이 다릅니다. 고객이 상점의 실제 계좌로 직접 이체하는 방식이라 은행 계좌만 있으면 시작할 수 있고, 받은 돈은 정산 주기를 기다리지 않고 내 계좌로 바로 들어옵니다. 아직 규모가 크지 않은 초기 서비스나, 신청서·모임·강의처럼 주문 개념이 느슨한 서비스에서 특히 현실적인 선택입니다.
대신 숙제가 하나 남습니다. 입금이 들어왔는지를 사람이 통장에서 확인해야 한다는 점입니다. 입금자명이 주문자와 다른 경우도 흔해서, 직접 만들려고 하면 통장 내역 읽기부터 주문 찾기, 상태 변경, 안내 발송까지 전부 스스로 구현해야 합니다. 이 구간을 대신 처리해 주는 서비스를 쓰면 내가 붙일 코드는 두 지점으로 줄어듭니다.
두 결제 방식의 차이를 더 자세히 견주고 싶다면 가상계좌와 무통장입금 차이와 선택 기준에서 확인할 수 있습니다.
붙이는 흐름은 어떻게 되나요?
전체 작업은 대시보드에서 하는 준비와 코드로 붙이는 연동으로 나뉩니다. 준비는 페이액션 대시보드에서 순서대로 진행합니다. 상점 정보를 등록하고, 입금을 받을 은행 계좌를 연동하면서 안내에 따라 해당 은행의 입출금 통지 서비스를 신청하고, 마지막으로 API 키를 만들고 결과를 받을 웹훅 주소를 등록합니다. 화면에서 사람이 해야 하는 일이라 AI가 대신할 수 없는 구간입니다.
코드로 붙일 부분은 두 지점입니다.
- 주문 등록 — 사용자가 주문을 만드는 순간 그 주문 정보를 페이액션에 등록합니다. 입금 안내 화면을 보여 주기 전에 등록이 끝나 있어야 합니다.
- 결과 수신 — 실제 입금이 들어와 주문과 매칭되면 페이액션이 그 결과를 웹훅으로 보냅니다. 이 요청을 받을 주소를 만들어 두고, 받은 결과로 주문을 결제완료로 바꾸고 이후 처리를 잇습니다.
그래서 바이브코딩으로 맡길 수 있는 일과 사람이 해야 하는 일이 비교적 뚜렷하게 갈립니다.
| 구간 | AI 코딩 도구에 맡길 수 있는 것 | 사람이 해야 하는 것 |
|---|---|---|
| 상점·계좌 준비 | — | 대시보드 등록, 은행 통지 서비스 신청 |
| 키·주소 설정 | 환경변수 구조 잡기 | API 키 발급, 웹훅 주소 등록 |
| 주문 등록 코드 | 요청 코드 작성과 연결 | 어느 시점에 등록할지 결정 |
| 결과 수신 코드 | 수신·응답·후속 처리 작성 | 공개 주소와 보안 인증서 준비 |
| 검증 | 테스트 시나리오 작성 | 실제 소액 입금으로 확인 |
정리하면 사람이 준비물을 만들고, AI가 코드를 쓰고, 마지막 확인은 다시 사람이 합니다. 실제 돈이 오가는 구간이니 마지막 검증만은 실제 입금 한 건으로 직접 확인하는 편이 안전합니다.
AI 에이전트에게 어떻게 지시하면 되나요?
바이브코딩에서 결제 연동이 어긋나는 가장 큰 이유는, AI가 문서를 읽지 않고 그럴듯한 요청 형식을 지어내는 것입니다. 그래서 지시문의 핵심은 기능 설명이 아니라 정본 문서를 못 박아 주는 일입니다. 페이액션은 개발자센터를 누구나 볼 수 있는 공개 문서로 제공하고, AI 도구가 참고하는 서비스 요약 파일에서도 개발자센터를 정본 문서로 지정해 두었습니다. 지시문에 이 주소를 넣어 두면 AI가 상상해서 채우는 대신 문서를 읽고 맞출 가능성이 크게 올라갑니다.
아래 지시문을 사용 중인 AI 코딩 도구에 그대로 붙여 넣으면 됩니다.
[목표]
내가 만들고 있는 서비스에 무통장입금 결제(입금 자동확인)를 붙인다.
사용 서비스: 페이액션
[문서]
- 연동 스펙 정본: https://payaction.app/developer
- 서비스 요약: https://payaction.app/llms.txt
위 문서를 먼저 읽고, 문서에 적힌 요청 방식과 항목, 응답 규칙을 그대로 따른다.
문서에 없는 항목이나 주소를 추측해서 만들지 않는다.
확인이 안 되면 코드를 쓰기 전에 나에게 묻는다.
[구현할 것]
1. 주문이 만들어지는 시점에 페이액션에 주문을 등록한다.
2. 입금이 주문과 매칭되면 페이액션이 결과를 보내 준다.
그 결과를 받을 수신 엔드포인트를 만든다.
3. 결과를 웹훅으로 받으면 정의된 성공 응답을 먼저 반환하고,
주문 상태 변경과 알림, 발송 같은 후속 처리는 그 뒤에 이어서 처리한다.
4. 같은 결과가 다시 도착해도 주문당 한 번만 처리되도록 멱등하게 만든다.
5. 인증 키와 상점 식별값은 환경변수로 읽는다. 소스와 저장소에 남기지 않는다.
6. 주문 등록 실패와 수신 처리 실패를 구분해서 로그로 남긴다.
[주의]
- 주문 등록이 입금보다 늦으면 매칭되지 않는다.
- 매칭 기준이 되는 입금자명은 주문자명과 다를 수 있다.
별도 입력값으로 다루고 앞뒤 공백을 제거한다.
- 문서에 없는 재시도, 타임아웃, 상태값을 임의로 가정하지 않는다.바이브코딩이 자주 놓치는 것은 무엇인가요?
AI가 만든 결제 연동에서 반복되는 문제는 대체로 정해져 있습니다. 아래 항목은 연동할 때 한 번, 배포하기 전에 한 번 확인하면 좋습니다.
- 주문을 입금보다 먼저 등록했는가. 매칭은 입금이 들어온 시점에 이뤄집니다. 주문이 그보다 늦게 등록되면 이미 지나간 입금과는 매칭되지 않습니다. 주문이 만들어진 직후에 등록하는 것이 원칙입니다.
- 주문 시각을 실제 주문 시점으로 넣었는가. 주문에 담는 시각이 입금보다 나중이거나 미래로 들어가면 매칭 대상에서 빠집니다. 서버 시각을 그대로 쓰고 시간대를 임의로 더하거나 빼지 않아야 합니다.
- 입금자명을 따로 받고 있는가. 매칭 기준은 주문자명이 아니라 실제로 이체할 때 쓰는 입금자명입니다. 이 이름과 금액이 함께 맞고 해당하는 주문이 하나일 때 자동으로 매칭됩니다. 가족이나 회사 이름으로 보내는 경우가 흔하니 주문서에서 따로 입력받고, 앞뒤 공백이 섞이지 않게 다듬어 보내야 합니다.
- 수신 주소가 외부에서 접근 가능한가. 로컬 개발 주소로는 받을 수 없습니다. 공개된 주소여야 하고, 유효한 보안 인증서와 방화벽·보안 그룹 설정도 함께 확인해야 합니다.
- 정해진 응답을 돌려주고 있는가. 문서에 정의된 성공 응답을 반환하지 않으면 전송은 실패로 간주되고 재전송 대상이 됩니다. 시간이 걸리는 처리는 응답을 먼저 보낸 뒤로 넘기는 편이 안전합니다.
- 같은 결과가 다시 와도 안전한가. 재전송이 있는 구조에서는 한 주문에 대해 처리가 두 번 일어날 수 있습니다. 주문 단위로 한 번만 처리되게 만들어 두면 중복 발송과 중복 처리를 막을 수 있습니다.
- 키를 코드에 넣지 않았는가. AI가 예시를 그대로 살려 인증 키를 소스에 박아 두는 일이 자주 있습니다. 환경변수로 옮기고 저장소에 올라가지 않는지 확인합니다.
매칭이 실패할 수도 있습니다. 그때는 알림을 받고 대시보드에서 입금과 주문을 직접 맞춰 처리할 수 있어, 모든 예외를 코드로 막아 두지 않아도 운영을 이어 갈 수 있습니다. 재전송 간격과 횟수, 매칭 대상 기간 같은 세부 기준은 개발자센터에 정리돼 있습니다.
주문 등록에 현금영수증 정보까지 함께 담으면 발행까지 이어서 자동화할 수 있습니다. 주문 없이 계좌의 입금·출금 이벤트만 받고 싶다면 은행 입출금 내역을 웹훅으로 실시간 받는 방법이 더 맞을 수 있습니다.
핵심 정리
- 바이브코딩과 무통장입금은 궁합이 좋습니다. PG 계약과 심사를 기다리지 않고 은행 계좌만으로 결제를 받을 수 있어, 거래가 많지 않은 초기 서비스에서도 현실적인 선택이 됩니다.
- 붙일 코드는 두 지점입니다. 주문이 만들어질 때 주문을 등록하고, 입금이 매칭된 결과를 받아 결제완료로 잇습니다. 통장 확인과 매칭은 페이액션이 처리합니다.
- 지시문의 핵심은 정본 문서 고정입니다. 개발자센터 주소를 명시하고 문서에 없는 항목을 지어내지 말라고 못 박으면 AI의 추측을 크게 줄일 수 있습니다.
- 자주 놓치는 것은 순서와 이름, 그리고 응답입니다. 주문을 입금보다 먼저 등록하고, 입금자명을 따로 받고, 정해진 응답을 돌려주고, 같은 결과가 다시 와도 한 번만 처리되게 해 두면 대부분 해결됩니다.
- 마지막 확인은 사람이 합니다. 실제 소액 입금 한 건으로 결제완료까지 이어지는지 직접 확인하고 배포합니다.
AI 코딩 도구로 만든 서비스에도 무통장입금 결제를 붙일 수 있습니다. 연동 스펙은 페이액션 개발자센터에서 바로 확인하고 연동을 시작할 수 있습니다. 입금 자동확인 API를 쓸 수 있는 플랜은 페이액션 요금 안내에서 확인할 수 있고, 유료 플랜은 결제 전에 무료로 체험해 볼 수 있습니다.



