결제 시스템 구조와 간편 결제 시스템 아키텍처에서 고려해야 하는 점

결제 서비스는 모든 비즈니스 도메인에서 중요한 서비스라고 생각한다. 일반적인 결제는 두가지 분류로 나눌 수 있다. 첫 번째로 오프라인 결제, 두 번째로 온라인 결제 "단순히 온라인에서 결제하던 방식을 모바일 기기나 웹에서 하는 거 아니야?" 라고 생각할 수 있지만 조금 다른 부분이 있다.

온오프라인 결제 대해서 알려면 VAN사와 PG사에 대해서 자세히 알아야한다.

 

VAN

우리가 매장에 가서 옷을 사거나 식당이나 카페에서 결제를 할때 카드로 결제를 한다. 이때 카드를 꽂거나 긁어서 결제를 하게 되는데, 그 과정에서 통신을 수행하는 것이 VAN이라고 한다.

VAN 은 Value Added Network 의 약자로 부가가치통신망을 말한다. 오프라인 결제의 핵심인 부가가치통신망은 가맹점과 카드사를 이어주는 통신망이다. VAN사는 이러한 망을 제공하는 부가가치 통신망 사업자 회사를 말한다. 국내에서는 NHN 한국 사이버 결제, 나이스정보통신, 페이히어등이 있다.

 

 

과거에 VAN 이 있기 전엔 각 카드사마다의 카드 단말기가 있어야 했다. 전용 단말기가 없으면 해당 카드로 결제를 하지 못했다. VAN 사의 등장으로 이 문제는 해결 됐다. VAN 사는 카드사별 단말기를 하나로 모은 통합 단말기를 제공하며 카드사와 가맹점 사이 계약과 거래를 도와주었다. 이 과정에서 VAN는 가드사로부터 수수료를 받아 이익을 챙기는 구조를 갖추었고, 카드 결제 서비스는 VAN의 등장으로 더욱 널리 쓰였다.

 

PG

PG 사는 온라인 결제의 핵심으로 카드사, 은행, 통신사 등 금융기관과 온라인 몰 사이에서 결제를 대행하는 관문이다. 이름 자체도 Payment Gateway 의 약자이고 PG사는 이런 결제 대행사를 말한다. 신용카드사와 직접 계약하기 힘든 온라인 쇼핑몰을 대신해 결제업무를 처리해주는 역할을 했다. 마치 프록시처럼 말이다. 

 

온라인 결제는 여러가지 형태로 이루어질 수 있는데, 온라인 카드결제, 계좌이체, 휴대폰 결제, 무통장 입금 등 이런 서비스들을 제공하고 가맹점으로부터 수수료 받게 된다. VAN 사와 동일하게 카드 결제 데이터를 안정적으로 주고 받는 역할을 수행하지만, 매출 정산 서비스를 제공한다는 차별점이 있다.

대표적인 PG사로는 KG이니시스, NHN한국사이버결제, 나이스페이먼츠 등이 있다.

 

PG사가 탄생하게 된 이유는 수수료 불평등에 있다.

온라인 결제 시장이 커지면서 카드사는 매출이 높은 특정 가맹점에서는 수수료를 적게 받고, 매출이 낮은 가맹점에서는 수수료를 많이 받았다. 카드사 입장에서 보면 당연한 수순이다. 매출이 잘나오는 곳에 계약 유지를 위해서라도 수수료를 적게 받을 수 밖에 없기 때문이다. 다만 그렇다 보니 규모가 작은 가맹점 입장에서는 비용 측면에서 다소 불합리한 경험을 할 수 밖에 없었다.

 

이러한 수수료 불균형 문제를 해결하기 위해 PG사가 등장했다. PG사는 여러 가맹점을 모아 본인이 이들의 대표 가맹점 역할을 한다. PG 사에 소속된 가맹점이 많을 수록 개별 가맹점이 부담해야하는 수수료는 적어지니 사업체가 작은 개별 가맹점 입장에서는 매우 기쁜 일이었다. 그래서 가맹점들은 PG사 밑으로 들어가서 자신들을 대신해서 대표로 결제를 해달라고 요청했다. 대표 가맹점 역할인 PG사는 카드 결제를 위해 여러 카드사와 계약을 맺었고 카드사와 가맹점 사이를 중계했다.

 

 

PG 사는 소비자의 결제 정보를 인증하고 승인을 받은 후  카드사에 전달하게 된다. 결제 승인이 이뤄졌다면 매출 전표가 카드사에 전달되고, 카드사는 결제 대금을 PG사에 지급한다. PG사는 정산받은 대금을  수수료를 제외하고 가맹주들에게 정산한다.

 

간편 결제

시간이 지나 국내 공인인증서 의무사용이 폐지되고 나서부터 간편 결제라는 서비스가 널리 쓰이게 됐다. 간편 결제는 사용자가 카드나 계좌를 미리 등록해 두고 쉽고 빠르게 결제할  수 있는 서비스를 말한다. 충전 선불금이나 신용카드, 계좌 등을 이용해 비밀번호나 지문, 생체 인식 등으로 쉽게 결제가 가능해졌다.

 

 

이런 편리함과 사용자의 사용 경험 개선을 무기로  간편 결제 서비스를 도입하는 회사들이 늘어났다. 개발 공수 대비 간편 결제 사용률이 작으면 손해를 볼 수 있지만 매출 규모가 있는 서비스에서는 자사 페이들 도입하는 것을 볼 수 있다. 

브랜딩 등 이유가 있겠지만 더 큰 이유는 데이터 확보와 수수료 절약이다. 자체 페이 서비스를 만들면 PG 사가 독점하던 소비자 데이터를 얻을 수 있게 된다. 또한 중간 중간 거치던 서비스의 수수료를 아낄 수도 있다.

 

간편 결제 시스템 아키텍처에서 고려해야 하는 점

간편 결제 서비스 시스템을 구축한다면 고려해야할 점은 무엇일까?

 

1.보안

첫 번째로 금융 도메인에 속하기 때문에 무엇보다도 데이터의 일관성과 안정성이 제일 중요하다고 생각한다. 개인의 결제 정보가 담겨져 있기 때문에 데이터는 전송 중 암호화 되어야 하고, PCI DSS 준수 규칙을 따라야 한다. PCI DSS (결제 산업 데이터 보안 표준) 은 고객의 결제 정보를 안전하게 처리하기 위해 결제 데이터는 특정 보안 기준에 맞춰 처리해야한다는 규칙이다.

 

2. 결제 트랜잭션 처리

외부 은행사와 연동되는 결제 트랜잭션이 실패하거나 중복되지 않도록 트랜잭션의 ACID 속성을 유지해야 한다. 결제 요청과 그에 대한 응답이 일관되게 처리되는지 확인하고, 실패 시 롤백 기능을 제공해야 한다.

또한 간편 결제 시스템에서는 동일한 요청이 여러 번 반복되더라도 한 번만 처리되도록 멱등성을 보장해야 한다. 네트워크 장애나 외부 은행사 서버의 불안정성으로 인해 재시도되는 요청에 대비해야 한다.

결제 과정에서 외부 은행사의 응답이 지연될 수 있으므로, 비동기 처리 및 메시지 큐를 사용하여 시스템의 병목 현상을 방지하고, 트랜잭션의 신뢰성을 높일 수 있다. MSA 환경에서는 단일 엔드 포인트 마다 독립된 데이터베이스를 가지므로 롤백 과정이 일어날 시 보상 트랜잭션을 활용할 수 있다.

 

3. 외부 API 통신과 실패 처리 및 재시도 정책

외부 은행사의 API와 연동할 때, 각 은행마다 API 사양이 다를 수 있으므로, 호환성을 고려해야 한다. 외부 은행사의 응답이 느리거나 가용성 문제가 있을 수 있으므로, 타임아웃 설정을 적절히 조정하고, 병렬 요청 처리와 캐싱을 적용하여 시스템 성능을 최적화할 수도 있다.

외부 은행사와의 통신 중 네트워크나 서버 오류가 발생할 수 있으므로, 일정 시간 후 자동으로 요청을 재시도하는 리트라이 정책이 필요하다. 이를 통해 일시적인 장애가 발생하더라도 결제 처리가 중단되지 않도록 할 수 있다.

외부 은행사와의 통신에서 잦은 장애가 발생하면 시스템 전체에 악영향을 미칠 수 있으므로, 서킷 브레이커 패턴을 적용하여 장애가 발생했을 때 일정 기간 요청을 멈추고 안정된 후 다시 시도할 수 있도록 해야 한다.

 

4. 결제 시스템의 고가용성 및 확장성

결제 시스템은 무중단 서비스가 매우 중요하므로, 서버 이중화 및 로드 밸런싱을 통해 고가용성을 보장해야 하지만, 네트워크 분할이 일어날 시 데이터베이스는 CAP 이론에 따라 가용성보다 일관성을 선택할 수 있게 해야한다.

https://programmer-may.tistory.com/223

CAP 이론 - 데이터베이스의 분산 시스템 이론

 

트래픽 증가에 대비하여 수평적 확장이 가능하도록 시스템을 설계해야 한다. 결제 요청이 폭주하는 경우를 대비하여, 오토 스케일링을 설정하고, 시스템 성능을 주기적으로 모니터링해야 한다.

 

5. 규제 준수 및 법적 요구사항 준수

간편 결제 서비스는 금융 도메인에 속한다. 외부 은행사와 통신하는 결제 시스템은 국가별 금융 규제를 준수해야 한다. 예를 들어 금융위원회의 규제, 전자금융거래법, 개인정보 보호법 등이 있다.

 

6. 장애 대비 및 대응

시스템 장애나 외부 은행사의 API 다운타임에 대비하여, 데이터 백업과 폴백 전략을 수립해야 한다. 결제 실패나 장애가 발생했을 때 빠르게 대응할 수 있도록 모니터링 도구(예: Prometheus, Grafana)와 알림 시스템(예: Slack 알림)을 연동하여 장애 대응 체계를 갖춰야 한다.

 

참고

https://yozm.wishket.com/magazine/detail/2585/

https://toss.tech/article/slash23-corebanking