이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
PG 연동 시스템에서 가장 먼저 파악한 것은 결제 요청부터 승인·취소까지 전체 상태 흐름이었습니다. 결제 상태가 중간에 틀어지면 사용자 경험과 정산에 모두 영향을 주기 때문에, 각 상태 전이의 조건과 예외 케이스를 문서화하고 팀과 공유했습니다.
웹훅 안정성도 중요한 설계 과제였습니다. PG사에서 보내는 결제 완료 알림이 네트워크 이슈로 누락될 수 있기 때문에, 웹훅 수신 외에도 주기적으로 결제 상태를 재조회하는 폴링 로직을 병행했습니다. 이 이중 구조가 누락된 알림으로 인한 미처리 건을 줄여줬습니다.
데이터 정합성 검증도 직접 구축했습니다. 서버 내부 결제 기록과 PG사 정산 파일을 일별로 대사해 불일치가 발생하면 알림이 오도록 했습니다. 누락·중복·금액 불일치 케이스를 자동으로 감지하면서 수작업 정산에서 발생하던 오류를 크게 줄였습니다.
PG 연동 시스템을 개발하면서 테스트 환경과 실제 환경의 차이가 문제를 만드는 경험을 했습니다. 샌드박스 환경에서 충분히 테스트했다고 생각했는데, 실제 PG사 운영 환경에서 다르게 동작하는 경우가 있었습니다. 특정 카드사의 응답 포맷이 샌드박스와 운영 환경에서 달랐고, 이것이 실제 서비스에서 예외 처리가 되지 않아 오류로 이어졌습니다. 이 경험에서 PG 연동은 샌드박스 테스트만으로는 모든 케이스를 검증하기 어렵고, 운영 환경에서 발생하는 예외 케이스를 빠르게 감지하고 대응하는 구조가 함께 필요하다는 것을 배웠습니다. 또한 PG사마다 운영 정책이나 응답 형식이 달라서 한 PG사 경험이 다른 PG사에서 그대로 통하지 않는다는 것도 알게 됐습니다. PG 연동 경험이 쌓일수록 예외 처리를 더 촘촘하게 설계하는 방향으로 접근이 바뀌었습니다.
PG 연동 시스템에서 결제 취소 처리가 생각보다 복잡하다는 것을 경험했습니다. 결제 승인은 성공/실패 두 가지 경우가 대부분인데, 취소는 부분 취소와 전체 취소, 이미 취소된 건을 재취소하려는 경우, 취소 요청이 PG사에 전달됐지만 응답이 오지 않는 경우 등 다양한 케이스가 있었습니다. 초기 설계에서 일부 케이스를 고려하지 못해서, 특정 조건에서 취소 처리가 되지 않는 문제가 발생한 적이 있었습니다. PG 연동에서 정상 흐름만 테스트하면 예외 케이스가 운영 중에 드러나는 구조가 된다는 것을 이 경험에서 배웠습니다. 이후에는 새로운 결제 기능을 추가할 때 정상 케이스뿐 아니라 실패, 부분 처리, 중복 요청 등의 예외 케이스를 먼저 정의하는 방식으로 접근이 바뀌었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.