POS 결제 취소 응답 파싱 오류와 지점 코드 검증 누락 수정

웹 POS 결제 응답 파싱 로직에서 발생하던 배열 처리 문제를 손봤다. 단순해 보이지만 결제 흐름에서 꽤 치명적일 수 있는 부분이었다.

결제 응답 구조의 불일치 문제

POS 시스템에서 내려오는 응답 데이터 구조를 다시 살펴보니, result_data 필드가 배열로 감싸져 있는 경우가 있었다. 원래는 직접 객체로 접근하고 있었는데, 이게 특정 거래 시나리오(특히 취소 관련)에서 null이나 파싱 에러를 유발하고 있었다.

실제 결제 게이트웨이 연동에서 자주 마주치는 패턴이다. 같은 API 엔드포인트라도 요청 타입이나 결제 상태에 따라 응답 스키마가 살짝 다르게 내려올 때가 있고, 그걸 클라이언트에서 탄력적으로 처리하지 못하면 일부 거래만 실패하는 상황이 생긴다. 디버깅할 때도 재현이 어려워서 은근히 오래 끌리는 종류의 버그다.

cancel/netCancel 흐름의 branchCode 검증

동시에 취소(cancel) 또는 순취소(netCancel) 처리 중에 branchCode 값이 누락되거나 잘못 전달되는 경우가 있었다. 결제 취소는 원거래 데이터를 기반으로 하는데, 여기서 지점 정보가 없으면 나중에 정산이나 거래 추적에서 문제가 될 수 있다.

왜 이런 가드가 필요했나

결제 취소는 환불이나 거래 롤백과 직결되는 작업이다. branchCode 같은 메타데이터가 부정확하면, 나중에 "어느 점포에서 어떤 거래가 이루어졌는가"를 추적하기 어려워진다. 특히 여러 지점을 운영하는 시스템이라면 정산 시점에 불일치가 발생할 수 있다.

배열 unwrap 처리도 마찬가지다. POS 응답이 항상 일관된 형식이 아니라면, 파싱 단계에서 그 편차를 흡수하는 게 낫다. 그래야 상위 비즈니스 로직은 결과 데이터가 항상 일정한 형태로 들어온다고 가정할 수 있고, 불필요한 null 체크나 타입 변환 로직이 나머지 코드에 흩어지지 않는다.

코드 리뷰 관점

이런 fix는 한 줄짜리 null check나 try-catch 추가처럼 보이기 쉽지만, 사실 응답 스키마를 정확히 이해하고 거래 생명주기 전체에서 그 필드가 어떤 역할을 하는지 파악해야 한다. 팀원과 코드 리뷰할 때는 "왜 이 지점에 검증이 필요한가", "이 필드가 비었을 때 어떤 부작용이 생기나"를 함께 짚고 넘어갔다. 단순 '방어 코드 추가'가 아니라 시스템의 데이터 일관성을 지키는 작업이라는 맥락을 공유하는 게 중요했다.

앞으로도 외부 시스템(PG, 결제 게이트웨이 등)과의 연동 코드는 응답 스키마가 변할 여지가 있다고 가정하고, 파싱 단계에서 최대한 탄력적으로 처리하되 비즈니스 로직에는 명확한 가정을 제공하는 방식으로 진행하려 한다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.