신규 결제 수단 추가로 충전 유입 다양화

지갑 결제 시스템에 두 가지 새로운 결제 수단을 추가했다: 특정 카드 결제 PG와 가상계좌 통합인증.

결제 수단 다양화가 중요한 이유

결제 서비스에서 지원하는 수단이 많을수록 사용자의 선택 폭이 넓어지고, 그만큼 충전 완료율이 올라간다. 예를 들어 신용카드가 없는 사용자도 가상계좌로 충전할 수 있고, 카드를 선호하는 사용자는 빠른 결제 경험을 얻는다. 특히 결제 시스템을 처음 구축할 땐 한두 가지 수단만 지원하기 쉽지만, 실제 운영에 들어가면 "이 결제 방법도 지원해달라"는 요청이 자주 들어온다. 미리 다양성을 고려해 설계하면 나중에 수정 비용을 크게 줄 수 있다.

작업 구성: 백엔드 골격과 프론트엔드 통합

이번 작업은 두 부분으로 나뉜다.

백엔드 (Java): 결제 PG 연동을 위한 기본 클래스 골격을 egovframework/com/slecs/co/wallet/web/ 경로에 추가했다. "골격"이라고 한 건, 실제 PG사와의 API 통신 로직은 다음 단계에서 구현하고, 여기선 결제 요청/응답 처리의 기본 구조만 세운다는 뜻이다. 팀이 작을 땐 골격-구현 단계를 나눔으로써 인수인계와 검토가 더 명확해진다.

프론트엔드 (JSP): charge.jsp 에서 충전 페이지 UI를 수정해 새로운 결제 수단을 선택할 수 있도록 했고, 가상계좌 결제 시 통합 인증 절차를 거친다. 결제 수단별로 필요한 파라미터와 검증 로직이 다르기 때문에, 프론트에서도 분기 로직이 늘어난다.

결제 수단 추가 시 자주 만나는 패턴들

여러 번 결제 시스템을 확장하면서 배운 것들:

• 인증 흐름의 표준화: 가상계좌든 카드든 기본 골격은 "사용자 인증 → 결제 요청 → 결과 콜백" 이다. 각 수단마다 상세 구현은 다르지만, 큰 흐름을 일관되게 유지하면 유지보수가 훨씬 쉽다.
• PG 테스트 환경 관리: 실제 거래를 처리하는 코드이므로, 개발/테스트 단계에서 테스트 계정을 따로 관리해야 한다. 실 결제로 실수하면 환불 처리가 복잡해진다.
• 에러 핸들링의 층화: PG사마다 에러 코드와 메시지가 다르다. 우리 시스템에서는 PG 에러를 표준화된 형식으로 변환해서 사용자에게 보여준다.
• 결제 기록 감시(audit trail): 결제가 실제로 일어난 상품·금액과 기록된 데이터가 일치하는지 로그로 추적할 수 있어야 한다.

팀 관점에서의 교훈

이번 작업에서 주의한 점은 "병렬 작업 설계"다. 백엔드 팀이 골격을 만드는 동안 프론트엔드 팀은 UI와 클라이언트 로직을 진행할 수 있도록, 양쪽 인터페이스(request/response 형식, 파라미터명 등)를 먼저 정의했다. 그래야 한쪽 완성을 기다릴 시간을 줄인다.

PG 연동은 외부 의존성이 크므로 충분한 테스트 기간을 확보하는 게 중요하다. 개발 초반엔 테스트 환경(샌드박스)에서만 검증하고, 실 운영 환경에 반영하기 전에 카드사/은행과 공동으로 모의 거래를 진행한다. 이 단계에서 발견되는 문제들이 실 거래 장애를 막을 수 있기 때문이다.

마지막으로, 새 결제 수단이 추가될 때마다 보안 점검이 필수다. 결제 정보(카드번호, 계좌번호)는 절대 우리 서버에 저장하면 안 되고, PG사의 보안 프로토콜을 그대로 따라야 한다. 코드 리뷰 때 "이 부분에서 민감한 정보가 로그에 남지는 않나?", "토큰은 안전한 채널로만 전송되나?" 같은 질문이 필수인 이유다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.