개발 slecs

결제 수단 변경 이력 감사 로직 구현과 설계 고민

목차

결제 주문의 결제 수단 변경을 감시하고 기록하는 감사 로직을 구현했다. 외부 영향이 크거나 민감한 부분인 만큼 어떤 배경과 고민이 있었는지 정리해본다.

결제 수단 변경, 왜 감시하는가

주문이 생성된 후 최종 결제 전까지 결제 수단이 변경되는 시나리오는 생각보다 자주 일어난다. 사용자가 마음을 바꿔서 카드를 바꾸거나, 결제 실패 후 다른 수단으로 재시도하거나, 관리자가 수동 개입하는 경우도 있다. 문제는 이런 변경이 제대로 추적되지 않으면 나중에 분쟁이 생겼을 때 "어떤 수단으로 결제됐는데, 왜 다른 계좌로 환불되었는가?"라는 의문이 남는다.

결제 관련 시스템에서 감사(audit) 로직은 단순 로깅을 넘어서 법적/운영적 책임을 보호하는 도구다. 특히 결제 수단처럼 금융과 직결된 정보는 변경 이력이 명확해야 한다. 나중에 고객 클레임, 결제사 문의, 혹은 내부 감사에서 "이 주문에 어떤 수단이 사용됐고, 언제 누가 변경했는가"를 빠르게 답할 수 있어야 한다.

어떤 정보를 기록할 것인가

감사 로직을 만들 때 맞닥뜨리는 고민은 "얼마나 디테일하게 기록할 것인가"다. 몇 가지 고려사항이 있다.

  • 변경 전/후 값: 결제 수단이 "카드"에서 "계좌이체"로 바뀌었는가, 같은 카드 내에서 번호가 변경되었는가를 구분해야 한다. before-after 패턴이 기본.
  • 변경자 정보: 사용자 자신이 변경했는지, 관리자가 개입했는지, 자동화 로직이 변경했는지 구분.
  • 타임스탬프: 변경이 일어난 정확한 시점. 결제 전/후를 구분하는 데 중요.
  • 변경 사유: 가능하면 "재시도로 인한 변경", "고객 요청", "시스템 오류" 같은 사유 코드.

일반적으로 감사 테이블은 이렇게 구성된다:

컬럼 의미
audit_id 감사 기록 고유 ID
order_id 어느 주문인가
old_paymethod 변경 전 결제 수단
new_paymethod 변경 후 결제 수단
changed_by 누가 변경했는가 (user_id 또는 system/admin)
changed_at 변경 시각
reason 변경 사유 (optional)

민감한 정보 보호의 균형

결제 수단 감사를 기록할 때 한 가지 더 신경 써야 할 부분은 민감 정보다. 카드 전체 번호를 기록하면 보안 리스크가 된다. 따라서 보통 마스킹 처리를 한다:
- 카드: 뒷자리 4-6자리만 (예: ****-****-****-1234)
- 계좌: 뒷자리 4자리만 (예: **-***-****)

이렇게 하면 "어떤 카드에서 어떤 카드로 변경됐는가"는 추적할 수 있으면서도 전체 카드 정보 노출은 피할 수 있다.

회고: 작은 변경, 큰 신뢰

이 작업은 기능적으로는 "결제 수단 변경 시 한 줄 기록 남기기" 정도로 보일 수 있지만, 운영 관점에서는 꽤 중요한 토대가 된다. 나중에 누군가 "어? 결제가 이상하게 됐는데" 하고 물어올 때, 우리가 그 이유를 빠르게 찾아줄 수 있기 때문이다.

결제/금융 시스템을 다루는 개발자로서 배운 점은 이거다: 기능만 동작한다고 끝이 아니다. 특히 돈이 오가는 부분은 투명성과 추적성이 신뢰의 기초다. 감사 로직은 버그 해결과 함께 운영팀, 고객 지원팀, 경영진 모두에게 신뢰를 주는 인프라다.

댓글 0

첫 댓글 달아줘.