PG사를 직접 붙이면 안 될까요?
결제 시스템을 붙이는 방법
쇼핑몰을 운영하다 보면 생각보다 다양한 요청이 들어온다.
어떤 요청은 기능 추가이고,
어떤 요청은 정책 변경이다.
그리고 가끔은 시스템 구조 자체를 바꾸는 요청도 들어온다.
내가 담당하던 쇼핑몰에서도
한 번 그런 요청이 있었다.
회의 자리에서 사업팀이 말했다.
“지금 결제 통합 플랫폼을 쓰고 있는데, PG사랑 직접 붙이면 안 될까요?”
이 질문은 생각보다 간단하지 않았다.
결제 시스템을 어떻게 붙일지는
서비스 구조 자체를 바꾸는 문제였기 때문이다.
당시 우리 서비스의 결제 구조
당시 내가 담당한 쇼핑몰은
결제 통합 플랫폼을 통해 결제 기능을 사용하고 있었다.
구조는 비교적 단순했다.
사용자가 결제를 하면
쇼핑몰 → 결제 통합 플랫폼 → PG사 → 카드사
이 흐름으로 결제가 진행됐다.
결제 통합 플랫폼은
여러 PG사를 연결해주는 중간 레이어 역할을 한다.
대표적인 서비스로는 '포트원(PortOne, 구 아임포트)'이다.
포트원 같은 플랫폼을 사용하면
개발팀은 하나의 API만 연동하면 된다.
그리고 그 뒤에서 결제의 경우
토스페이먼츠, KSNET, 카카오페이, 네이버페이, 스마트로, 나이스정보통신,
페이팔, KG이니시스, 한국결제네트웍스(KPN), NHN KCP, 토스페이
등과 같은 여러 PG를 사용할 수 있다.
덕분에 개발팀 입장에서는
PG 연동을 단순하게 관리할 수 있는 구조였다.
하지만 사업팀의 질문은
이 구조를 다시 생각하게 만들었다.
“굳이 중간 플랫폼을 거칠 필요가 있을까?”
결제 통합 플랫폼 vs PG사 직접 연동
우리는 PG사를 직접 연동하는 방식과
결제 통합 플랫폼을 사용하는 방식
두 가지 방식을 비교하게 됐다.
표면적으로 보면 단순히 중간 레이어가 하나 줄어드는 구조처럼 보여지지만
이 문제는 그렇게 단순하지 않기 때문이다.
1. 결제 통합 플랫폼을 사용하는 방식
결제 통합 플랫폼은 여러 PG사를 하나의 API로 통합해 제공한다.
대표적인 서비스가 '포트원(PortOne)'이다.
포트원 공식 문서에서도
'하나의 API로 여러 PG사와 간편하게 연동할 수 있는 결제 인프라'라고 설명한다.
구조는 다음과 같다.
사용자 → 쇼핑몰 → 결제 통합 플랫폼 → PG사 → 카드사
'결제 통합 플랫폼'을 이용하면 중간 단계가 하나 늘어나지만 유연성이 생긴다.
장점 1. PG 확장이 쉽다
결제 통합 플랫폼의 가장 큰 장점은 PG를 쉽게 추가할 수 있다는 것이다.
예를 들어 KG이니시스, 나이스페이, 토스페이먼츠 등과 같은 PG를
같은 API로 사용할 수 있다.
때문에 PG사 변경이나 장애 대응도 훨씬 수월해진다.
장점 2. 개발 속도가 빠르다
결제 통합 플랫폼은 보통
SDK,
샘플 코드,
개발가이드 가 잘 정리되어 있다.
그래서 신규 서비스에 결제 시스템을 붙일 때
개발 속도가 빠른 편이다.
그래서인지 스타트업이나 초기 서비스에서 이 구조를 많이 사용한다.
장점 3. 운영 도구가 제공된다
결제 통합 플랫폼은 보통
결제 승인이나 취소/정산 정보도 확인이 가능하지만
결제 API 로그,
요청/응답 기록,
webhook 이벤트 등과 같은
연동 로그를 확인할 수 있는 기능을 제공한다.
처음에는 결제 통합 플랫폼을 사용하면 모든 결제 정보를 한 곳에서 관리할 수 있을 거라고 생각했다.
하지만 실제 운영을 해보니 그렇지는 않았다.
결제 승인이나 취소 같은 실제 거래 정보는 대부분 PG사 관리자에서도 확인이 필요한 경우가 있다.
2. PG사를 직접 붙이는 방식
PG(Payment Gateway)는
온라인 결제를 중개하는 서비스로
PG는 카드사와 가맹점 사이에서
결제 승인과 정산을 처리하는 역할을 한다.
대표적인 국내 PG사로는
KG이니시스, 나이스페이, KCP, 토스페이먼츠 등이 있다.
PG를 직접 연동 시, 결제 구조는 이렇게 된다.
사용자 → 쇼핑몰 → PG사 → 카드사
중간 플랫폼이 사라지기 때문에 구조는 더 단순해보인다.
장점 1. 비용 구조가 단순해진다
결제 통합 플랫폼을 사용할 경우
플랫폼 이용 수수료가 발생할 수 있다.
하지만 PG를 직접 연동하면
기본적으로 PG 수수료만 고려하면 된다.
그래서 거래 규모가 큰 서비스에서는
직접 연동을 선택하는 경우도 많다.
장점 2. 결제 흐름을 직접 제어할 수 있다
PG를 직접 연동하면
결제 승인이나 취소 API를 서비스에서 직접 호출하게 된다.
그래서 주문 상태, 재고 상황, 배송 상태 같은 서비스 로직에 맞춰
결제 처리 흐름을 설계할 수 있다.
다만 실제 결제 승인 자체는
결국 PG와 카드사가 처리하는 것으로,
서비스에서 제어할 수 있는 것은
결제 API를 언제 호출할지에 대한 것에 가깝다.
하지만 운영 관점에서 문제가 존재한다
PG 직접 연동의 가장 큰 문제는
PG마다 연동 방식이 다르다는 것이었다.
PG사마다 API 구조, 인증 방식, 결제 프로세스 등이 모두 다르다.
PG사를 붙일때 가이드를 보면 아래와 같은 부분이 언급된다.
"PG사별 결제 연동 방식이 상이하기 때문에
가맹점은 PG사에 맞춰 별도의 개발이 필요합니다."
즉 PG를 변경하거나 추가하려면 개발을 다시 해야 할 가능성이 높으며,
이 점은 운영팀 입장에서는 꽤 큰 리스크가 된다.
내가 속한 프로젝트 팀에서는...
내가 참여한 프로젝트에서는 기존 구조(결제 통합 플랫폼)를 유지하기로 했다.
가장 큰 이유는 세 가지였다.
PG 변경 가능성, 개발 리소스, 운영 안정성.
우리 서비스는 향후 결제 수단이 추가될 가능성이 있었기 때문이다.
때문에 특정 PG에 종속되는 구조보다는
유연한 구조가 더 낫다고 판단했다.
결제 시스템 설계시 고려할 점
결제 시스템을 처음 설계할 때
기획자는 보통 이런 것에 집중한다.
결제 UX, 결제 수단, 할인 정책 등.
하지만 운영을 하다 보면
장애 대응, 확장성, 유지보수도 중요하게 다가온다.
즉, 결제를 붙이는 것은 단순한 기능 추가가 아니라
서비스 인프라에 가깝다.
그래서 결제 구조를 선택할 때는
기능도 중요하지만 운영 관점도 고려해서 결정해야 한다.