1. 문제 상황
특정 유료상품의 결제내역이 조회되지 않는 문의가 발생했다.
연장 결제는 정상적으로 완료된 상태였지만,
결제내역 리스트에는 해당 기록이 노출되지 않았다.
사용자 입장에서는
“결제를 했는데 기록이 없다”는 상황으로 인식될 수 있는 구조였다.
2. 구조적 원인
1⃣ 현재 결제 구조
연장 결제는 최초 메인 결제건 하위에 종속되는 구조
결제내역 리스트는 최초 결제일 기준 6개월 이내 데이터만 노출
2⃣ 충돌 지점
해당 유료상품의 최초 결제일이 6개월을 초과하면서
리스트 필터 조건에 의해 최초 결제건이 노출 제외되었다.
문제는 여기서 끝나지 않는다.
연장 결제는 상위 결제건에 종속되는 구조이기 때문에,
상위 데이터가 필터링되자 하위 연장 결제건 역시 함께 노출되지 않았다.
결제 데이터는 존재했지만,
노출 조건에 의해 화면에서는 보이지 않는 상태였다.
3. 생각의 빈틈
연장 결제를 6개월 동안 지속하는 경우가 실제로 있을까.
보통의 기업은 길어야 한두 달 내에 종료된다.
그래서 자연스럽게 이런 가정이 생긴다.
“누가 6개월이나 계속 연장하겠어.”
그 판단 아래 6개월이라는 기준이 설정되었을 가능성이 있다.
하지만 QA를 하며 느낀 점은 분명했다.
발생할 가능성이 있다면, 현실에서도 반드시 나타난다.
실제로 한 기업은 6개월 동안 지속적으로 연장 결제를 진행하고 있었다.
예외라고 여겼던 케이스가 실제 운영 데이터로 존재했다.
이건 단순한 오류라기보다,
가정이 만든 설계의 빈틈에 가까웠다.
4. 필터라는 기준의 애매함
여기서 또 하나의 질문이 남는다.
왜 하필 6개월이었을까.
3개월도 아니고, 4개월도 아니었다.
만약 1년이었다면 이 문제는 발견되지 않았을까.
필터는 기준처럼 보이지만,
실제로는 누군가의 판단값이다.
그리고 그 판단은 언제든 현실과 어긋날 수 있다.
5. 개선 조치
이번 사례를 통해 두 가지 보완을 진행했다.
연장 결제가 존재하는 경우에는
마지막 연장 결제일을 기준으로 6개월 범위 내 결제 내역이 함께 조회되도록 조건을 보완했다.해당 노출 기준을 명시적으로 안내하도록 수정하여
사용자가 결제 내역 조회 방식에 대해 혼란을 겪지 않도록 정리했다.
데이터는 존재하지만 보이지 않는 상태를 최소화하는 방향으로 구조를 조정했다.
6. 운영 회고
이번 사례는 기능 오류라기보다는
설계 단계에서의 가정이 만든 사각지대에 가까웠다.
기능이 정상 작동한다고 해서
사용자에게도 정상처럼 보이는 것은 아니다.
그리고 운영에서 가장 위험한 것은
버그보다도 “당연하다고 믿는 전제”일지도 모른다.