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

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

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

새벽 로그 앞에서

결제는 ‘새로운 걸 빨리 붙이고 싶은 마음’과 ‘하나라도 틀리면 돈이 어긋난다는 공포’가 정면으로 부딪히는 영역이었다. 사원카드, QR 쿠폰, QR 바우처, 가맹점 본인인증… 흐름을 늘릴 때마다 배포 전엔 자신 있었고, 배포 후엔 로그를 더 자주 봤다.

한번은 재시도만 넣고 멱등이 해결됐다고 믿었던 적이 있다. QA는 통과했는데, 운영에서 타임아웃과 재시도가 겹치며 같은 건이 두 번 처리된 것처럼 보이는 로그가 남았다. 그날 새벽, ‘이번엔 잘하자’는 다짐만으로는 한계가 있다는 걸 몸으로 알았다.

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

배포 전에 꼭 확인했던 것

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

운영하면서 계속 보던 지표

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

내가 실제로 밟았던 함정

• 단순 재시도만 넣고 멱등성이 해결됐다고 착각했다. 정산 배치 멱등성 글을 쓸 때도 같은 교훈이었다.
• 운영 로그를 비즈니스 지표와 연결하지 않아, 원인 추적이 늦어졌다. ‘로그는 있는데 무슨 숫자랑 맞춰야 하지’가 새벽의 시간을 잡아먹었다.
• 장애 대응 절차를 문서로만 두고, 팀에 공유하지 않았다. 내 머릿속 런북은 회복이 아니라 병목이 됐다.

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

결제 ‘승인’은 잘 됐는데, 취소 쪽에서 본인 확인 수단이 마땅치 않아 운영자가 수기로 개입하는 일이 반복됐다.

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

지금의 결론과 개선점

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

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

앞으로 나가야 할 방향

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

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