🚨
외부에 소개된 다음 날 실결제 장애가 발생했습니다. 당일 결제를 잠가 추가 피해를 끊고, 두 달에 걸쳐 해제 조건을 하나씩 지우며 결제 신뢰성을 복구했습니다.
배경
전날 외부 네트워크 행사에서 voidx 서비스가 잠재 고객에게 소개됐습니다. 회원가입 후 결제해 멤버십이 되면 에이전트를 체험하는 구조인데, 당시 결제·멤버십 백엔드는 레거시 코드와 중단된 리팩터링이 겹쳐 정상 동작하지 않는 상태였습니다. 결제·멤버십 백엔드 구현은 별도 담당자 소관이고, 제 역할은 문제 규명과 프론트엔드 방어 계층 구축, 검증, 결제 잠금 판단이었습니다.
한 일
- 장애를 가장 먼저 발견: 직접 만들어 운영하던 관리자 도구의 문의 기능으로 외부 사용자의 문의가 들어왔습니다. "첫 결제 후 실패 메시지가 떠 한 번 더 결제했더니 2회 실결제됐고, 멤버십은 조회되지 않는다." 즉시 팀에 공유했습니다.
- 프론트엔드에서 결제를 잠가 추가 피해 차단: 결제 파이프라인과 멤버십 백엔드가 정상 동작하지 않았고 담당자의 장기 부재로 즉시 손대기 어려웠습니다. 익숙하지 않은 언어의 코드를 단기간에 정상화하긴 어렵다고 보고, 백엔드를 고치는 대신 프론트엔드에서 결제를 막는 쪽을 택했습니다. CTA를 비활성화하고 문구를 오픈 일정 안내로 바꿨습니다.
- 피해 사용자 당일 응대: 백엔드 환불 API가 동작하지 않아 PG사 대시보드에서 직접 환불하고 사과 메일로 회신했습니다. 원인은 대형 CMS 기준으로 기획된 권한·멤버십 구조가 방향이 바뀌는 동안 정리되지 못하고 덧붙여지기만 한 데 있었습니다.
- 잠금을 해제 조건이 붙은 게이트로 설계: 임시방편으로 두지 않았습니다. "백엔드 중복 방지 처리와 보상 트랜잭션 배포 완료"를 선결 조건으로 문서에 못 박고, 환경변수로 잠금을 제어하되 기본값이 잠금이 되도록 뒀습니다.
- 두 달에 걸쳐 프론트엔드 방어 계층을 쌓음: HTTP 상태 코드만 보던 판정을 응답 본문의 코드와 데이터까지 확인하도록 바꿨고, 본문 없는 204 응답에서 화면이 죽던 문제를 공통 응답 처리 계층에서 일괄 정리했습니다. 백엔드 원문 오류가 사용자 화면에 그대로 노출되던 것은 응답 13개 케이스를 전수 매핑하고 순수 함수 해석기로 정규화했습니다. 백엔드에 중복 방지 키가 들어온 뒤에는 코드를 직접 읽어 확인한 다음 결제 흐름에 연결하고 실제 카드로 검증했습니다.
결과
- 당일: 장애 인지 즉시 추가 결제 차단, 피해 사용자 환불·사과 완료
- 13개 케이스: 결제 응답 전수 매핑 (한국어·영어 16키)
- 22건 → 47건: 결제 관련 단위 테스트
- 15건: 실제 카드 시나리오 검증 통과 (재청구 없음·환불 중복 없음·타인 결제 403 차단 포함)
- 4건: 유료 오픈 전 선제 발견한 백엔드 결함
가장 빠른 수단으로 피해를 멈춘 뒤, 다시 열어도 되는 조건을 정의하고 그 조건을 하나씩 지워 나간 대응입니다.
정리
이를 코드만의 문제가 아니라 정책의 문제로 봤습니다. 리팩터링을 하려면 먼저 유즈케이스 기획이 정해져야 하고, 그 뼈대가 될 현 시점 기준의 권한·멤버십·유료 정책이 필요하다는 점을 담당자에게 팔로우업했습니다. 같은 일이 반복되지 않으려면 코드 이전에 정책이 먼저 정리돼야 한다는 것을 확인한 케이스입니다.