결제는 "되는 것"과 "안전한 것"이 완전히 다르다

AI에게 "결제 기능 넣어줘"라고 하면 PG사 SDK 연동부터 결제 완료 페이지까지 한 번에 만들어준다. 테스트 결제도 잘 된다. 하지만 결제 보안은 "잘 되는 것"이 아니라 "조작이 불가능한 것"이다.

결제 로직의 보안 결함은 곧 직접적인 금전 피해로 이어진다. 아래 5가지는 AI 코딩 결제 시스템에서 가장 많이 발견되는 취약점이다.

1. 클라이언트에서 결제 금액 결정

가장 치명적인 실수다:

// 클라이언트
const amount = document.getElementById('price').value;
IMP.request_pay({ amount: amount, ... });

브라우저 개발자 도구에서 amount를 100원으로 바꾸면 10만원짜리 상품을 100원에 결제할 수 있다. AI는 프론트엔드에서 가격을 설정하는 코드를 자연스럽게 만든다.

수정법: 결제 금액은 반드시 서버에서 DB의 상품 가격을 조회해서 결정한다. 클라이언트가 보내는 금액은 신뢰하지 않는다. PG사 결제 완료 후 서버에서 결제 금액과 상품 금액이 일치하는지 검증한다.

PG사에서 결제 성공 응답이 오면 바로 "결제 완료" 처리하는 코드:

// PG 콜백
if (response.success) {
  // 바로 주문 완료 처리 — 서버 검증 없음!
  await createOrder(response);
}

클라이언트 측 응답은 조작이 가능하다. 실제로 결제가 되지 않았는데 success 응답을 만들어 보낼 수 있다. 반드시 PG사 API를 서버에서 호출해서 실제 결제 여부와 금액을 검증해야 한다.

같은 결제 건으로 여러 번 주문 완료 처리가 되는 경우. 네트워크 지연이나 새로고침으로 콜백이 두 번 오면 상품이 두 번 지급되거나 포인트가 두 번 충전된다.

수정법: 주문 생성 시 결제 ID(paymentId)로 중복 체크. DB에 unique 제약 조건을 걸어 물리적으로 중복 삽입을 차단한다.

환불 API가 로그인한 사용자 누구나 호출 가능한 경우. 다른 사용자의 주문을 환불하거나, 이미 환불된 건을 다시 환불할 수 있다.

수정법: 환불 API에서 (1) 해당 주문이 요청자 본인의 것인지 (2) 이미 환불된 건이 아닌지 (3) 환불 가능 기간 내인지를 서버에서 검증한다.

같은 할인 코드를 여러 번 적용하거나, 여러 할인 코드를 동시에 적용해서 0원 또는 마이너스 결제가 되는 경우. AI는 할인 로직을 단순하게 구현해서 이런 엣지 케이스를 놓친다.

수정법: 할인 적용 후 최종 금액이 0원 이하인지 서버에서 체크. 할인 코드 사용 횟수를 DB에서 관리한다.

결제 보안은 코드 레벨 점검이 필수지만, 먼저 외부에서 보이는 취약점(API 키 노출, 보안 헤더 누락, SSL 설정)부터 확인하자. 30초면 된다.