거래대사(Transaction Reconciliation)

결제 시스템 거래대사(Transaction Reconciliation) 개념 정리

결제 시스템을 개발하다 보면 반드시 마주하게 되는 단어가 바로 거래대사입니다.
처음 들으면 생소할 수 있지만, 금융/결제 도메인에서는 시스템의 신뢰도를 결정짓는 가장 중요한 프로세스입니다.

거래대사는 단순히 "숫자를 맞추는 일"을 넘어 시스템의 마지막 방어선입니다.
특히 환불이나 취소 건에서 "우리 쪽은 성공인데, 매입은 완료된" 상태 등을 잡아내어 업무 혼선을 줄여주는 아주 중요한 역할을 합니다.

---

1. 거래대사란?

"내 장부와 상대방 장부가 똑같은지 맞춰보는 작업"
우리 서비스의 DB에 기록된 결제 내역과 PG사(결제대행사)나 은행이 가진 결제 내역을 대조하여 데이터의 무결성을 증명하는 과정입니다.

2. 왜 거래대사가 필요한가?

네트워크는 완벽하지 않습니다. 결제 과정에서 다음과 같은 이슈가 발생할 수 있기 때문입니다.

타임아웃(Timeout): 우리 서버는 요청을 보냈지만, PG사의 응답을 받기 전에 연결이 끊긴 경우.
데이터 유실: 네트워크 오류로 인해 한쪽 시스템에만 성공 기록이 남은 경우.
상태 불일치: 우리는 PENDING(대기)인데 실제 결제사는 SUCCESS(성공)인 경우.
이런 간극을 방치하면 "사용자는 돈이 나갔는데, 서비스는 이용 못 하는" 최악의 경험을 주게 됩니다.

3. 거래대사의 2가지 유형

구분	실시간/단기 대사	정기/정산 대사
시점	결제 직후 ~ 수 분 이내	익일(D+1) 또는 특정 주기
방식	API를 통한 개별 상태 조회 (SEARCH)	대사 파일(CSV/TXT) 전체 비교
목적	미확정 상태(PENDING)의 빠른 업데이트	전체 거래액 확정 및 정산 데이터 검증

4. 개발자가 마주하는실무 시나리오

스케줄러 기반의 대사 로직을 예로 들어보겠습니다.

1. 대상 추출: DB에서 상태가 PENDING 또는 PROCESSING이면서 최근 10일 이내의 데이터를 조회합니다.
2. 외부 조회: 주기적(예: 1분마다)으로 외부 PG사의 inquiry API를 호출합니다.
3. 상태 동기화:
   외부 상태에 따라 (SUCCESS/DECLINE/FAILED)라면? 우리 장부도 동일한 업데이트.
   여전히 처리 중이라면? 다음 스케줄러 타임에 재시도합니다.