Purple주문 검색 SQL과 정기결제

문제

관리자 주문 검색은 회원·상품·결제 조건을 주문마다 상관 서브쿼리로 확인했습니다. 조회 기간이 길수록 이 반복 비용이 커져, 전체 기간에서 원번으로 검색하면 count SQL만 4.73초가 걸렸습니다.

해결 과정

1. 실행 계획 확인

먼저 EXPLAIN을 돌렸습니다. 주문 테이블 전체를 훑으면서(type: ALL), 관련 테이블 조건마다 DEPENDENT SUBQUERY가 7개 붙어 있었습니다. 주문 한 건마다 서브쿼리가 다시 실행되는 구조였습니다.

2. 인덱스 확인

주문 테이블에 생성일·유형 인덱스가 없어 정렬(filesort)이 생기는 것도 보였습니다. 하지만 정렬 없는 count(0.55초)와 정렬한 목록 20건(0.49초)이 거의 같아, 정렬은 병목이 아니라고 보고 인덱스는 추가하지 않았습니다.

3. 한 SQL 안에서 ID 먼저 고르기

o.id IN (SELECT … UNION …) 형태로 바꿔 봤습니다. 그런데 MySQL이 이를 다시 DEPENDENT SUBQUERY/DEPENDENT UNION으로 실행해 실행 계획이 원래와 같았고, 시간도 4.55초로 그대로였습니다.

4. 쿼리를 둘로 나누기

검색어에 맞는 주문 ID를 별도 쿼리로 먼저 모으고, 바깥 쿼리는 그 ID로 PK 조회만 하게 했습니다. SQL 왕복은 한 번 늘었지만 원번 검색은 0.33초 + 0.56초 = 0.89초가 됐습니다.

주문 테이블 자체의 검색 조건은 그대로 두었고, 검색 안내 문구에는 있었지만 실제로 연결되지 않았던 환불요청 검색도 함께 연결했습니다.

측정

MySQL 8.0.42, 주문 약 11.6만 행, 전체 기간 기준입니다. 기존 count와 변경 후 ID 선별+count의 SQL 시간을 비교했습니다.

다섯 조건 모두 변경 전후 결과 건수가 같았습니다. 같은 규모의 데이터로 조건마다 15번씩 다시 측정했을 때도 다섯 조건 모두 중앙값이 줄었습니다(원번 2.14초 → 0.55초).

문제

정기결제 배치, 관리자 수동 청구, 학부모 재결제가 같은 구독을 동시에 청구할 수 있었습니다. 관리자 API와 웹 API는 별도 프로세스라서, 경로마다 따로 막아서는 서로의 청구를 막을 수 없었습니다.

내 기여와 해결

팀의 공용 Redis 락을 관리자·배치 청구에 구독 단위로 적용하고 TTL을 조정했습니다. 학부모 재결제에도 같은 락 키 규칙을 적용해, 세 경로가 같은 구독에 대해 하나의 락을 다투게 했습니다.

락을 잡은 뒤에는 구독과 결제 상태를 다시 조회하도록 했습니다. 락을 기다리는 사이 다른 경로가 먼저 청구를 끝냈을 수 있기 때문입니다.

검증 결과

두 앱의 실제 락 코드와 Redis를 쓰고 청구 함수만 테스트용으로 바꿔, 같은 구독에 30개 요청을 동시에 보내는 시험을 20번 반복했습니다. 매번 청구는 1번만 실행되고 나머지 29개는 거절됐습니다.

서로 다른 구독은 동시에 청구됐고, 처리 중 예외가 나거나 프로세스가 강제 종료돼도 락이 풀리는 것을 확인했습니다.

문제

PG에서 결제가 완료됐어도 응답이 유실되면 서비스는 결과를 알 수 없습니다. 이를 바로 실패로 처리하면 실패 안내가 나가고, 같은 회차를 다시 청구할 수 있었습니다.

내 기여와 해결

카드·브랜드페이 승인과 자동결제에 조회 기반 복구를 적용했습니다. 상태 코드가 없는 오류, 5xx, “이미 처리된 결제” 오류가 나면 주문번호로 PG에 결제를 다시 조회합니다. 조회 결과가 같은 주문번호, 같은 금액, 완료(DONE) 상태일 때만 기존 성공 흐름으로 이어갑니다.

명확한 4xx 거절은 조회하지 않습니다. 404, 미완료, 주문·금액 불일치, 조회 실패는 성공으로 처리하지 않고 원래 오류를 그대로 둡니다. 성공으로 복구한 건은 로그를 남겨 나중에 추적할 수 있게 했습니다.

검증 결과

실제 관리자 주문·결제 코드와 Redis를 쓰고 PG와 DB만 테스트용으로 바꿔, PG가 결제를 완료한 뒤 응답만 유실되는 상황을 재현했습니다. 같은 결제에 10개 요청을 동시에 보내자 1개만 성공으로 복구되고 9개는 거절됐습니다.

청구, 복구 조회, 결제 저장은 각각 1번씩만 일어났고, 실패 안내는 한 번도 나가지 않았습니다.

문제

정기결제가 실패했을 때 학부모가 직접 재결제할 수 있는 기능을 만들면서, 재결제 API가 Toss의 약관 동의 절차를 거치지 않고 서버에서 대신 동의한 뒤 청구하고 있다는 것을 확인했습니다. 사용자가 확인하지 않은 약관에 동의가 기록되는 구조였습니다.

학부모가 직접 재결제할 때는 약관 동의가 기록되지 않은 상태라 오류가 발생했습니다. 서버의 대리 동의를 그대로 붙이면 오류는 바로 사라지지만, 같은 구조를 사용자 재결제에도 넓히는 셈이었습니다.

해결 과정

1. 보고와 과제화

이 구조를 리스크로 판단해 경영지원팀과 경영진에 보고했고, 정식 과제로 맡아 진행했습니다.

2. Toss 위젯의 약관 박스로 해결 시도

처음에는 Toss Payments 콘솔에서 결제 위젯의 약관 박스에 해당 약관을 명시적으로 추가했습니다. 그런데 개발 서버에서 QA를 해 보니, 재결제 상황에서는 그 박스에서 동의해도 PG로 전송되지 않았습니다. 재결제는 결제 요청 호출을 거치지 않고 저장된 결제수단으로 바로 청구하기 때문이었습니다.

3. 청구 직전 차단과 직접 동의 장치

그래서 동의를 Toss 위젯에 맡기지 않고 직접 받기로 했습니다. 재결제 API는 청구 직전에 미동의 필수 약관이 있는지만 확인하고, 남아 있으면 청구를 차단합니다. 이 경로에서는 서버가 동의 API를 호출하지 않습니다. 화면에서는 동의 체크를 하기 전까지 재결제 버튼을 막고, 동의 API는 화면에 표시된 미동의 약관을 모두 받은 경우에만 Toss에 동의를 기록합니다. 일부만 보내 우회하면 다시 거절합니다.

4. 동작하지 않는 Toss 박스 정리

재결제 화면에는 전송되지 않는 Toss 박스가 새 동의 체크와 함께 남아 있어 사용자를 헷갈리게 했습니다. 이 화면에서만 Toss 박스를 숨기고, 같은 형태의 자체 약관 박스로 바꿨습니다. 미동의 항목만이 아니라 필수 약관 전체를 보여주고, 이미 동의한 항목은 체크된 채 비활성으로 표시해 사용자가 자신이 동의한 약관을 한눈에 볼 수 있게 했습니다. 약관 전문은 Toss가 내려주는 원문 링크를 그대로 써서 사본과 원문이 어긋나지 않게 했습니다.

구현하며 확인한 점

Toss의 약관 동의 기록은 상점별로 따로 관리됩니다. 같은 고객이라도 상점이 다르면 동의 상태가 다르기 때문에, 그 주문의 결제 이력에 남은 상점 기준으로 조회하고 동의하도록 맞췄습니다. 또 Toss의 약관 조회 API는 이름과 달리 이미 동의한 약관까지 함께 내려주어, 이를 이용해 약관 전체와 항목별 동의 여부를 함께 내려주게 했습니다.

검증 결과

재결제·약관 조회·동의 관련 Jest 22건이 통과했습니다. 개발 서버에 배포한 뒤 미동의 계정에서 약관 3건이 미체크 상태로 표시되고, 전부 체크하기 전에는 결제 버튼이 비활성인 것을 확인했습니다. 전부 체크한 뒤 동의 API가 호출되고, Toss 조회에서 해당 약관이 미동의에서 동의로 바뀐 것을 직접 확인했습니다. 이미 전부 동의한 계정은 약관이 체크된 채 비활성으로 표시됐습니다.

운영 서버에 반영한 뒤, 같은 약관 미동의 오류가 더 이상 발생하지 않는 것을 확인했습니다.