결제/정산 시스템 운영 체크리스트

오프라인 결제 쪽을 오래 하다 보니, 한 가지는 분명해졌다.
기능을 예쁘게 만드는 것보다 운영이 버티는지가 먼저다.

왜 체크리스트부터 만들었는가 (이유)

결제는 “새로운 걸 빨리 붙이고 싶은 마음”과 “하나라도 틀리면 돈이 어긋난다는 공포”가 정면으로 부딪히는 영역이었다. 사원카드 결제, QR 쿠폰 결제, QR 바우처(상품교환), 가맹점 본인인증까지 결제 흐름을 늘려가면서 깨달은 건, 개인의 집중력으로 막는 사고는 반드시 언젠가 뚫린다는 점이었다.

그래서 ‘이번엔 잘하자’는 다짐 대신, ‘빠뜨려도 시스템이 잡아주는 기준’을 글로 고정하기로 했다. 체크리스트는 나를 못 믿어서가 아니라, 야근한 새벽의 나와 신규 입사자를 같은 기준선에 세우기 위한 장치였다.

배포 전에 꼭 확인했던 것

외부 PG 연동 타임아웃을 어디서 끊을지 정해뒀다.
재시도할 때 중복 결제를 막는 키가 있는지 봤다.
정산 배치가 실패했을 때 재처리 루트를 정해뒀다.
알림톡/메일이 실패해도 대체 알림이 가는지 확인했다.

운영하면서 계속 보던 지표

승인 성공률, 취소 실패율, 정산 지연 건수
외부 API 응답 시간과 에러율
배치 처리 시간과 누락 건수
인증/권한 실패 로그가 갑자기 늘지 않는지

내가 실제로 밟았던 함정

단순 재시도만 넣고 멱등성이 해결됐다고 착각했다.
운영 로그를 비즈니스 지표와 연결하지 않아, 원인 추적이 늦어졌다.
장애 대응 절차를 문서로만 두고, 팀에 공유하지 않았다.

비슷한 경험 — 취소를 위한 가맹점 본인인증

가맹점 본인인증 서비스를 만든 계기도 결국 같은 맥락이었다. 결제 “승인”은 잘 됐는데, 취소 쪽에서 본인 확인 수단이 마땅치 않아 운영자가 수기로 개입하는 일이 반복됐다.

이유: 외부 인증을 매번 태우자니 비용·연동 리스크가 컸고, 그렇다고 확인 없이 취소를 열어두면 분쟁이 났다. 새 기능 욕심과 안정성 사이의 또 다른 갈림길이었다.
당시 결론: 취소 시나리오에 한해 가맹점 본인인증을 도입하되, 민감한 승인 흐름은 기존 검증된 경로를 그대로 두기로 했다. “바꿀 곳”과 “건드리지 말 곳”을 먼저 선을 그은 셈이다.
이 경험이 결국 위 체크리스트의 “재처리·대체 경로” 항목을 더 단단하게 만들었다.

지금의 결론과 개선점

나중에야 알았다. 체크리스트를 CI와 런북에 붙여야 운영 품질이 올라간다는 걸.
그래도 아직 부족한 부분이 분명하다.

지표(승인 성공률·취소 실패율·정산 지연)를 사람이 대시보드를 봐야 알아챈다. 임계치 자동 알림이 약하다.
체크리스트가 결제 도메인마다 조금씩 다른데, 공통 기준과 도메인별 예외가 아직 깔끔히 분리돼 있지 않다.
런북은 있지만, 실제 장애 상황에서 그대로 따라 했을 때의 리허설(훈련) 이 부족하다.

앞으로 나가야 할 방향

핵심 지표에 임계치 기반 알림을 붙여, “장애가 난 뒤 확인”이 아니라 “징후 단계에서 개입”으로 옮긴다.
체크리스트를 공통 + 도메인별로 계층화해, 새 결제 수단을 붙일 때 빠지는 항목이 없게 한다.
멱등성·재처리 시나리오는 정산 배치 멱등성 기준과 묶어, 운영 설명과 테스트를 한 흐름으로 정리한다.
분기마다 한 번은 장애 대응 리허설을 돌려, 런북이 “읽는 문서”가 아니라 “손이 기억하는 절차”가 되게 만든다.

결제는 결국 화려함이 아니라 버티는 힘으로 평가받는 영역이었다. 그 힘을 개인기에서 팀의 기준으로 옮기는 게, 지금도 진행 중인 일이다.