이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
결제 플랫폼에서 데이터 정합성 검증의 핵심은 PG사 원장과 내부 DB를 주기적으로 대사하는 것이라고 이해하고 있습니다. 결제 요청 금액, 승인 금액, 정산 금액이 각각 다른 시스템에 기록되는데 이 세 값이 일치하는지 자동 reconciliation 배치로 주기적으로 검증했습니다. 불일치가 발생하면 PG사 오류, 내부 처리 실패, 네트워크 단절로 인한 미확정 세 유형으로 분류하고 각각 다른 복구 흐름을 적용했습니다.
타임아웃 후 미확정 상태가 가장 까다로운 케이스였는데, PG사 API로 최종 상태를 조회해 확정하는 재시도 로직을 붙였습니다. 대사 오류는 건수가 아니라 금액 기준으로 심각도를 분류하는 게 실용적이라고 생각합니다.
PG 대사 작업에서 처음으로 실제 금액 불일치를 마주한 케이스는 환불 처리 시점이 PG사와 내부 시스템에서 달리 기록된 경우였습니다. 고객이 당일 취소를 요청했는데 PG사는 취소 확정을 익일 새벽 배치로 처리했고, 그 사이 내부 정산 배치가 먼저 돌아 미취소 상태로 정산금이 잡혀버렸습니다. 대사 배치를 돌리니 해당 일자 정산 금액이 PG 명세와 불일치했고, 원인을 찾는 데 PG사 API 응답 타임스탬프와 내부 이벤트 로그를 교차 비교하는 과정이 필요했습니다. 이 경험으로 취소·환불 이벤트는 PG사 처리 완료 시점을 기준으로 상태를 갱신해야 하고, 정산 배치 전에 미확정 건을 먼저 조회해 제외하는 로직이 필요하다는 것을 배웠습니다. 대사 오류는 금액 규모에 따라 즉시 알람 vs 익일 검토로 심각도를 분리하는 것이 운영에 현실적입니다.
PG 대사 접근 방식으로 이벤트 소싱(Event Sourcing) 기반 재계산을 도입한 경험이 있습니다. 기존엔 현재 DB 상태만 보고 PG 명세와 비교했는데, 취소·환불이 섞인 복잡한 케이스에서 어떤 이벤트가 원인인지 추적하기 어려웠습니다. 결제 이벤트(승인·취소·부분취소·정산)를 이벤트 로그 테이블에 전부 남기고, 기간별로 이벤트를 재계산한 금액과 PG 명세를 비교하도록 바꿨습니다. 불일치가 발생하면 어느 이벤트 단계에서 금액이 갈라지는지를 로그 한 줄씩 비교해 원인을 좁힐 수 있었습니다.
Audit Trail을 남기면 이상 건 발생 시 규제 대응 자료로도 활용 가능해 운영 팀의 수동 조사 시간이 크게 줄었습니다. 대사 검증은 현재 상태 비교보다 이벤트 흐름을 재현할 수 있는 구조가 더 신뢰도가 높습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.