💳 결제 시스템, 어떤 고민 속에서 탄생할까? (인터뷰 전문)

🍳 오늘의 레시피 ’결제’

결제는 단순히 구매하고 거래하는 행위가 아니라, 서비스 신뢰와 사용자 만족을 좌우하는 중요한 순간이에요. 사용자가 망설임 없이 결제 과정을 마칠 수 있다면 그 자체로 긍정적인 경험이 되고, 작은 불편이라도 생기면 쉽게 이탈로 이어지죠.

특히 기획자와 PM에게 결제는 단순한 기능 구현이 아닌, 고객 여정의 핵심 퍼널이에요. 어떤 지점에서 사용자가 포기하는지, 어떻게 심리적 마찰을 줄일 수 있을지가 곧 비즈니스 성과와 직결되곤 합니다. 오늘은 이 결제 경험을 어떻게 설계하고 개선할 수 있을지, 실제 사례와 함께 이야기를 담았어요.

🧑‍🍳 오늘의 메이커 : 11년차 결제/정산 PM, 익명의 매디

안녕하세요. 올해로 11년 차가 된 PM 익명의 매디입니다. 현재는 플랫폼 서비스 결제/정산을 담당하고 있고, 이전 10년간 온오프라인 커머스에서 결제/정산을 담당했습니다. 이제는 많은 서비스에서 당연한 결제 기능이지만, 특수 도메인인 만큼 많은 분들이 관심 갖고 재미있게 읽어주시면 감사드리겠습니다.

🥕 핵심 재료

🔥 조리 방법

1. 사용자가 결제를 포기하는 지점은 어디라고 보셨고, 그걸 해결하기 위해 어떤 설계부터 시작하셨나요?

저는 지난 10년 가까이 온·오프라인 커머스 서비스에서 결제 관련 업무를 담당해왔어요. 결제 퍼널을 지속적으로 개선하고 데이터를 분석하는 일을 하면서, 이 과정에서 중요한 문제 하나를 발견하게 되었는데요. 바로 사용자들이 쿠폰이나 포인트 같은 혜택이 있는 걸 제대로 인지하지 못해 결제를 포기하는 경우가 많다는 점이었어요.

특히 신규 사용자나 가끔씩만 서비스를 이용하는 분들은 “뭔가 혜택이 있긴 하겠지”라고 막연히 생각하다가, 결제 직전 단계에서 그런 혜택이 눈에 띄지 않으면 “손해 보는 것 같다”라는 심리 때문에 결제를 멈춰버리더라고요. 실제 유저 인터뷰에서도 “쿠폰이 있었는데 모르고 결제할 뻔했어요”라는 피드백을 자주 들을 수 있었고요.

이 문제를 해결하기 위해, 지금은 당연한 UI가 되었지만, 당시에는 흔하지 않았던 혜택을 강조하는 UI 개편 작업을 진행하게 됐어요. 바로 결제 전 단계에서의 ‘적용 가능한 쿠폰/포인트 자동 표시’ 기능이었어요.

장바구니 화면에서 결제 예상 금액과 함께 ‘최대 혜택 바로 적용하기’ 버튼을 배치해서, 사용자가 별도로 쿠폰이나 포인트를 찾지 않아도 자동으로 적용 여부를 확인할 수 있도록 했어요. 이렇게 UI를 개선한 결과, 혜택을 놓쳐서 결제를 포기하는 비율이 눈에 띄게 줄었고, 실제 결제 전환율도 약 10% 가까이 상승했어요.

이 개선은 단순히 결제 경험을 매끄럽게 만드는 것을 넘어서, “내가 받을 수 있는 혜택을 놓치지 않았다”는 안도감을 주는 것이 얼마나 중요한지를 느꼈던 경험이었어요.

2. PG사 연동부터 정산까지, 기술 도입보다 더 신경 썼던 ‘운영상의 리스크’가 있다면요?

서비스 초창기에 결제가 PG사에서 정상적으로 처리된 직후, 본사 서비스로 돌아오는 과정에서 발생하는 오류를 제대로 트래킹하지 못한 적이 있었어요. 결제 자체는 성공했지만, 우리 쪽 화면에서는 결제 완료로 표시되지 않아 사용자가 혼란을 겪었던 일이었어요.

더 큰 문제는 이 오류가 왜 발생했는지, 어떤 상황에서 발생했는지를 기록조차 하지 못하고 대사 처리 과정에서 그 사유를 알 수 없었다는 거였습니다. PG사에서는 응답 처리가 완료됐지만, 우리 서비스에서는 관련 이벤트가 누락된 채 남아서 디버깅 자체가 거의 불가능했어요.

이 문제를 해결하기 위해, 지금은 많은 서비스에서 채택하고 있는 방식처럼 결제 완료나 취소 완료 시, 자체 모달을 한 번 더 띄워 추가 확인 과정을 거치도록 변경했어요. 이 단계에서 오류 코드와 트랜잭션 로그를 수집할 수 있도록 설계했어요.

그 덕분에 특정 조건에서 반복적으로 발생하는 오류가 있다는 점을 파악할 수 있었고, 해당 케이스에 대해 API 버전 업그레이드를 진행하면서 오류율을 줄일 수 있었어요.

결제와 정산은 아주 작은 오차라도 매출과 서비스 신뢰도에 큰 영향을 줄 수 있는 영역이에요. 그래서 단순히 기술적인 해결을 넘어서, 사업적인 관점과 운영 리스크까지 함께 고려하는 사고방식이 꼭 필요하다고 생각해요.

3. 쿠폰, 포인트, 구독, 인앱결제 등 다양한 결제 조건 중, 어떤 기능부터 우선 도입했는지와 그 이유는요?

프로젝트 초기에는 욕심이 나서 다양한 결제 옵션을 한꺼번에 도입하고 싶었어요. 하지만 PG사별 혜택, 수수료율, 정산 방식 등을 고려해 우선순위를 정하는 게 훨씬 중요했어요.

당시 저희 팀은 ‘재구매 유도’와 ‘주문서 내 이탈 최소화’를 최우선 과제로 설정했었고, 그 과정에 B2B 매출 비중이 높아지는 시기였기 때문에, 단순 할인보다는 한때 유행했던 ‘외상 결제(후불/청구 기반 결제)’를 도입하기로 결정했어요. 특히 대기업이나 공공기관에서는 결제 한도를 미리 카드로 설정하기보다는, 월 단위 청구서를 받아 내부 프로세스에 따라 정산하는 방식을 선호했기도 했고요.

그런데 처음에는 단순히 월말에 일괄 청구하는 형태로 시작했는데, 금방 한계가 드러나게 되었어요. 바로 고객사마다 결제 주기, 회계 기준, 세금계산서 처리 요건이 모두 달라서 하나의 방식으로는 대응이 어려웠던 거예요.

이 문제를 해결하기 위해, 고객사별로 결제 주기(예: 매월 10일, 20일, 말일)를 직접 설정할 수 있도록 했고, 미납 시 자동 알림 발송, 연체 발생 시 계정 제한 기능을 함께 도입해 리스크를 관리했어요. 이후에야 쿠폰이나 포인트 같은 기능도 도입했었어요.

결과적으로는 우리 비즈니스 모델에서 고객이 가장 필요로 하는 것을 기준으로 삼아 외상 결제를 먼저 안정화했기 때문에 핵심 B2B 고객을 확보할 수 있었고, 이후에는 다른 부가 기능도 자연스럽게 확장할 수 있었어요.

이 경험을 통해 느낀 건, 기능 개발의 순서는 기술적인 복잡도보다 고객의 사용 맥락과 운영 리스크를 기준으로 정하는 것이 훨씬 더 중요하다는 점이었습니다.

4. 결제 전환율을 높이기 위해 실제로 효과 있었던 개선이나 실험이 있다면요? (예: 버튼 문구, 카드 순서, 실패 메시지 UX 등)

결제 실패 메시지 노출 방식을 개선했던 사례가 기억에 남아요. 대응 공수는 적은 데에 비해 결과가 굉장히 좋았거든요.

처음에는 결제 실패 시 단순한 실패 메시지와 재시도를 요청하는 안내만 제공했어요. 그런데 이 방식에서는 사용자가 재시도하더라도 결제가 된 건지 아닌지 불확실한 상태가 계속되다 보니, 결국 고객센터에 문의하거나 결제를 포기하는 사례들이 발견됐어요.

그래서 “실패 사유를 사용자에게 정확히 보여주자”라는 의견으로 방향을 잡고 개선 작업을 진행했어요. 이때 기억에 남는 점은, 실패 사유를 바로 호출하기 어려운 환경이었기 때문에, 메시지를 바로 띄우는 대신 [도움말 보기] 버튼을 추가해 사용자가 클릭할 때 실패 코드를 호출하고 그에 맞는 사유를 노출하는 방식으로 구현했어요.

예를 들어 사용자가 도움말을 클릭하면 “결제가 실패했어요. 카드 유효기간이나 한도를 확인해 주세요.” 같은 메시지를 확인할 수 있도록 했고, 이 간단한 개선만으로도 결제 재시도율이 약 2배 가까이 증가했던 걸로 기억해요.

또 하나 기억에 남는 개선 사례는 카드 선택 순서 UX를 바꿨던 작업이에요.

초기에는 사용자가 카드사를 먼저 선택하고 나서 카드 번호를 입력하는 구조였는데요, 이를 카드 번호를 먼저 입력하면 자동으로 카드사를 인식하는 방식으로 바꾸니 UX가 훨씬 자연스러워졌고, 실제로 전환율도 꽤 개선되어서 기억에 남습니다.

5. ‘이 결제 시스템은 잘 작동한다’고 판단하기 위해 어떤 지표들을 실제로 추적하고 계신가요?

결제 시스템의 성과를 판단할 때 단순히 매출 지표만으로는 충분하지 않다고 생각해요. 그래서 저는 결제 성공률, 즉 시도 대비 성공 비율을 최우선 지표로 보고 있어요. 개인적으로는 98% 이상을 안정적인 기준선으로 잡고 있고요.

이 외에도 결제 실패 유형 분포(네트워크, 한도, 인증 실패 등), 실패 후 재시도율, 자동화되지 않은 환불 비율, CS 문의 비중 등을 세밀하게 추적해야 한다고 생각해요. 특히 CS 문의 중 결제 관련 문의가 10% 이상을 차지한다면, 사용자 경험에 분명한 문제가 있다고 판단하고, 반드시 개선 과제를 도출하는 편이에요.

무엇보다도 운영팀 입장에서 중요한 건 ‘복구 속도’예요. 오류 자체보다도, 오류 발생 후 평균 대응 시간이 길어질수록 사용자 신뢰도에 더 치명적인 영향을 줄 수 있기 때문이죠. 그래서 저는 단순히 지표를 추적하는 데 그치지 않고, 이상 징후를 빠르게 감지할 수 있는 알람 체계를 함께 구축하는 것 또한 중요하다고 생각해요.

🍬 디저트

이 아티클에서는 배달의민족 결제 담당자의 실전 장애 대응 사례를 중심으로, 결제 시스템 운영에서 신뢰 확보까지 이어지는 복구 프로세스를 세밀하게 엿볼 수 있어요. 특히 결제 성공률 관리, 실패 사유 추적, 사용자 혼란 최소화, 복구 속도 향상 같은 실제 운영자의 시각이 잘 녹아 있어, 결제 시스템을 기획하거나 운영 리스크를 고민하는 PM 분들에게 실무적인 인사이트를 줄 수 있을 거예요.

오픈채팅방을 통해 뉴스레터로 다 소개하지 못한 정보를 확인해보세요!