홈페이지 예약·결제 붙이기, 노코드로 어디까지 될까

예약은 노코드 툴로 어렵지 않게 붙였는데, 결제 단계에서 막히는 경우를 자주 봅니다. 예약 연동 자체는 이미 정리된 주제라 이 글에서는 깊게 다루지 않습니다. 이 글의 무게중심은 결제이고, 특히 어디까지가 노코드로 되고 어디서부터 개발이 필요해지는지 그 경계선입니다.

예약 연동은 네이버예약·캐치테이블·자체 폼으로 대부분 해결됩니다. 결제는 빌더 내장 위젯, 외부 PG 콘솔 연동, 결제링크 조합까지 세 갈래 노코드 경로가 있습니다. 다만 정기결제·구독, 예약↔결제 상태 자동 동기화, 회원별 결제이력 DB 적재로 넘어가는 순간부터는 노코드 툴의 기본 기능 밖이라 개발이 필요합니다.

예약 연동은 이미 표준이 있다

예약 기능만 놓고 보면 홈페이지에 붙이는 방법은 이미 어느 정도 정리돼 있습니다. 네이버예약 위젯을 그대로 심거나, 캐치테이블 같은 외부 예약 플랫폼과 연동하거나, 구글폼·자체 제작 폼으로 예약을 받는 세 가지 방식이 실무에서 가장 많이 쓰입니다. 어떤 방식을 고를지, 업종별로 무엇이 유리한지는 카페·식당 홈페이지 예약 가이드에서 이미 다뤘습니다. 결론만 가져오면, 예약은 노코드로 대부분 해결됩니다. 문제는 그다음, 결제입니다.

결제를 붙이는 3가지 노코드 경로

홈페이지에 결제 기능을 붙이는 방법은 코드를 한 줄도 쓰지 않는 경로부터 어드민 설정만으로 끝나는 경로까지 크게 세 가지로 나뉩니다.

빌더 내장 결제 위젯 — 아임웹·카페24

아임웹이나 카페24 같은 홈페이지 빌더는 결제 위젯을 처음부터 내장하고 있습니다. 아임웹은 NHN KCP·KG이니시스·나이스페이·이지페이·토스페이먼츠까지 PG 5개사를 선택할 수 있고, 어드민에서 사업자 정보와 계좌를 등록하면 네이버페이·카카오페이·카드 결제가 함께 활성화되는 구조입니다. 카페24는 자체 PG인 카페24페이먼츠를 선택하면 초기가입비가 면제되는 대신, 스마트스토어와 연동해 쇼핑몰형 판매를 자동으로 붙일 수 있다는 점이 특징입니다. 둘 다 코드를 건드릴 일이 거의 없고, 빌더가 제공하는 화면 안에서 상품·결제수단·정산 계좌를 설정하는 것으로 끝납니다.

외부 PG 콘솔 연동 — 포트원·토스페이먼츠

빌더에 묶이지 않고 자체 제작 사이트(Astro, Next.js 등)에 결제를 붙이고 싶다면 포트원이나 토스페이먼츠 같은 PG 연동 서비스를 씁니다. 포트원은 관리자 콘솔에서 PG사별 계약 정보(credential)를 입력해두면, 프론트엔드에는 SDK 스크립트 한 줄만 얹어도 여러 PG사를 동시에 지원할 수 있는 구조입니다. 토스페이먼츠는 자체 SDK와 결제창을 직접 제공하기 때문에 포트원 없이 단독으로도 붙일 수 있습니다. 둘 다 완전한 노코드는 아니지만, 결제창 호출부만 붙이면 되는 수준이라 최소한의 개발로 자체 사이트에도 결제를 얹을 수 있는 경로입니다.

결제링크 조합 — 구글폼/노션 + 결제링크

가장 가볍게 시작하는 방법은 구글폼이나 노션으로 신청을 받고, PG사가 발급하는 결제링크를 안내 메일이나 카카오톡으로 따로 보내는 방식입니다. 개발은 전혀 필요 없지만 신청과 결제가 별도 화면·별도 절차로 분리돼 있어서, 신청은 했는데 결제를 안 하고 이탈하는 경우를 잡아내기 어렵고 결제 상태를 신청 데이터와 자동으로 맞춰볼 방법이 없습니다. 소규모·저빈도 판매에는 충분하지만 규모가 커지면 한계가 먼저 보입니다.

구분	지원 결제수단	자체 사이트 적용 가능 여부	코딩 필요도	정산·수수료 구조	적합 대상
빌더 내장 위젯 (아임웹·카페24)	카드, 네이버페이, 카카오페이 등 빌더가 지원하는 범위	불가(해당 빌더 사이트 안에서만)	없음(어드민 설정만)	빌더+PG 이중 수수료, 빌더 정산 주기	홈페이지를 빌더로 이미 운영 중인 경우
외부 PG 콘솔 (포트원·토스페이먼츠)	PG사가 지원하는 카드·간편결제 전체	가능	낮음(SDK 연동 수준)	PG 직접 정산, 계약된 수수료율	자체 제작 사이트에 결제를 붙이려는 경우
결제링크 조합 (구글폼·노션+결제링크)	결제링크 발급 PG가 지원하는 수단	가능(플랫폼 무관)	없음	PG 정산, 신청·결제 데이터는 수동 대조	신청 빈도가 낮은 소규모 판매

PG사는 꼭 필요한가 — 결제의 진짜 관문

카카오페이나 네이버페이 로고를 보면 결제 버튼만 붙이면 될 것 같지만, 실제로는 대부분 PG사를 경유해야 합니다. 카드·간편결제를 개별로 심사받고 연동하는 대신, PG사가 카카오페이·네이버페이·카드사를 한 번에 묶어 연동해주는 구조를 타는 편이 사업자 등록, 통신판매업 신고, 결제수단별 개별 심사를 따로 밟지 않아도 되므로 소규모 홈페이지 입장에서는 훨씬 현실적입니다.

PG 심사 기간은 PG사와 결제 대행 구조에 따라 일주일에서 2주 안팎으로 갈리는 편이고, 이 기간에는 사업자등록증·통장 사본 같은 서류 심사와 함께 정산 계좌·수수료율이 확정됩니다. 즉 결제 버튼을 붙이는 개발 작업 자체는 짧아도, PG사 심사와 계약이라는 관문을 먼저 통과해야 실제 결제가 열립니다. 노코드든 개발이든 이 심사 단계는 똑같이 거쳐야 하는 부분이라, 결제 기능을 붙이기로 했다면 개발 일정보다 PG 심사 일정을 먼저 잡아두는 편이 낫습니다.

여기까지가 노코드, 여기부터가 개발

노코드로 버틸 수 있는 범위

단건 결제, 즉 상품 하나를 한 번 결제받고 끝나는 흐름은 노코드 위젯이나 PG 콘솔만으로 충분합니다. 결제 내역은 PG사 대시보드나 빌더 어드민에서 확인하면 되고, 기본적인 주문 목록·환불 처리도 대부분 제공됩니다. 여기까지는 코드를 쓸 이유가 딱히 없습니다.

개발이 필요해지는 지점

실제로 제작하다 보면 처음엔 노코드 위젯으로 시작했다가, 정기결제나 구독 요구가 나오는 순간 막히는 경우를 자주 겪습니다. 정기결제는 카드정보를 매달 다시 입력받는 방식이 아니라 빌링키(암호화된 결제수단 정보)를 한 번 발급받아 서버에서 정해진 주기로 자동 청구하는 구조인데, 이 자동 청구 스케줄링은 PG 콘솔이 대신 해주지 않습니다. 여기서 주의할 점 하나는, 카드정보를 자체 서버 DB에 그대로 저장하면 안 된다는 것입니다(PCI-DSS 위반). 반드시 PG사가 발급하는 빌링키 방식을 써야 하고, 이 부분은 노코드 위젯이 대신해주지 못하는 영역입니다.

이 외에도 예약 상태와 결제 상태를 자동으로 맞추는 일(결제가 완료돼야 예약이 확정되는 흐름), 회원별 결제 이력을 자체 데이터베이스에 쌓아 마이페이지에서 보여주는 일, 등급별로 접근 권한을 결제 여부와 연동하는 일, PG 대시보드가 기본으로 주지 않는 맞춤 통계는 전부 개발 영역으로 넘어갑니다. 노코드 툴은 결제를 “받는” 것까지는 잘하지만, 결제 결과를 다른 시스템(예약, 회원, 콘텐츠 접근권한)과 연결하는 부분은 대부분 손을 대지 않습니다.

기능	노코드로 되나	왜 개발이 필요한가
단건 결제	됩니다	PG 콘솔·빌더 위젯으로 충분
정기결제·구독	안 됩니다	빌링키 발급 + 서버측 자동 청구 스케줄링 필요
예약↔결제 상태 자동 동기화	안 됩니다	결제 완료 시점과 예약 확정 로직을 연결하는 코드 필요
회원별 결제 이력 DB	안 됩니다	PG 대시보드는 회원 시스템과 별개, 자체 DB 적재 필요
등급별 접근 권한	안 됩니다	결제 여부에 따라 콘텐츠·기능 노출을 제어하는 로직 필요
맞춤 통계	부분적으로 됩니다	PG 대시보드 기본 통계 외의 지표는 별도 집계 필요

PLAYW는 이 경계를 어떻게 넘었나

PLAYW는 이 경계를 실제로 넘어본 적이 있습니다. 자사 챗봇 상품 결제에 포트원 V2 단건결제를 이미 구현해 운영 중이고, 주문 테이블과 결제 웹훅 서명 검증까지 붙어 있습니다. 구독형 정기결제는 설계를 마치고 순차적으로 확장하는 단계입니다. 상담 예약은 자사 문의 페이지에 날짜와 시간대 슬롯을 고르는 예약 기능과 알림톡 확정 안내가 이미 붙어 있어서, 예약↔알림 연동도 직접 다뤄본 경험입니다.

이건 어디까지나 결제·예약을 직접 다뤄본 스튜디오라는 근거로 드리는 이야기이지, 클라이언트에게 이 기능을 그대로 판다는 뜻은 아닙니다. 클라이언트 홈페이지 제작에서는 각 사이트에 필요한 수준에 맞춰 예약·결제 기능을 붙여드리는 방식으로 접근합니다.

정기결제를 붙이면 비로소 멤버십이나 강의 같은 수익화 모델이 가능해집니다. 이 흐름은 멤버십 사이트 제작 가이드와 온라인 강의 플랫폼 직접 만들기에서 더 자세히 다뤘습니다.

내 홈페이지엔 어디까지 필요할까

업종과 무관하게 세 가지 케이스로 나눠보면 판단이 조금 쉬워집니다. 강의를 몇 개 판매하는 정도라면 단건 결제 위젯으로 노코드가 충분합니다. 매달 회비를 받는 멤버십 구조라면 정기결제와 등급별 접근 권한이 필요해 개발이 필요합니다. 상담 예약을 받고 예약 확정 시 결제까지 이어지는 구조라면, 예약 상태와 결제 상태를 맞물리게 하는 부분에서 개발이 필요합니다. 정확히 어느 쪽인지 판단이 서지 않는다면 노코드 vs 개발, 3가지 차이를 먼저 참고하시는 걸 권합니다.

자주 묻는 질문 (FAQ)

홈페이지에 결제 기능을 붙이려면 PG사가 꼭 필요한가요?

대부분의 경우 필요합니다. 카드·간편결제를 개별로 심사받고 연동하는 대신 PG사가 이를 한 번에 묶어 처리해주기 때문에, 소규모 홈페이지 입장에서는 PG사를 거치는 편이 현실적입니다.

아임웹·카페24는 코딩 없이 예약과 결제가 되나요?

됩니다. 두 빌더 모두 예약 위젯과 결제 위젯을 내장하고 있어서 어드민에서 설정만 마치면 코드를 건드리지 않고도 예약·결제를 운영할 수 있습니다.

카카오페이·네이버페이는 PG 없이 직접 연동할 수 있나요?

가능한 경우도 있지만 소규모 사이트에서는 PG사를 경유하는 방식이 일반적입니다. PG사가 카카오페이·네이버페이·카드사를 한 번에 묶어 연동해주기 때문에 개별 심사·계약 부담이 줄어듭니다.

포트원·토스페이먼츠 중 어떤 걸 골라야 하나요?

여러 PG사를 한 콘솔에서 관리하고 싶다면 포트원이, 토스페이먼츠 단독으로 충분하다면 토스페이먼츠 직접 연동이 더 단순합니다. 둘 다 자체 제작 사이트에 SDK 연동 수준으로 붙일 수 있습니다.

정기결제·구독 기능도 노코드로 만들 수 있나요?

기본적으로는 어렵습니다. 정기결제는 빌링키 발급과 서버측 자동 청구 스케줄링이 필요한데, 이 부분은 대부분의 노코드 위젯이 제공하지 않아 개발이 필요합니다.