이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 간편 결제 기능을 구현하며 정합성 문제를 처음 실감했습니다. 결제 API 호출이 성공한 뒤 DB 업데이트 직전에 서버가 죽는 케이스를 테스트 중에 재현했고, 결제는 됐지만 주문 상태가 미결제로 남는 상황이 생겼습니다. idempotency_key를 결제 요청에 붙여 중복 처리를 막고, 결제 게이트웨이 상태를 주기적으로 조회해 보정하는 로직을 추가했습니다. 또한 payment_events 테이블에 이벤트를 먼저 기록하고 처리를 분리하는 outbox 패턴을 작게 적용해봤습니다. 부분 실패 시나리오를 항상 '결제는 됐지만 주문 확정이 안 됐다면?'이라는 질문을 먼저 던지는 습관이 생겼습니다.
정합성은 행복 경로가 아니라 장애 경로 설계에서 만들어진다는 걸 그때 배웠습니다.
결제 시스템에서 운영 단계의 정합성 검증이 구축 못지않게 중요하다는 것을 실감했습니다. 서비스 오픈 후 일부 결제 건이 내부 DB에는 성공으로 기록됐지만 PG사 원장에는 실패로 남는 케이스가 발생했습니다. 빠른 원인 파악이 가능했던 것은 감사 로그(Audit Log)에 모든 상태 전이를 기록해뒀기 때문입니다.
payment_id, event_type, before_status, after_status, timestamp를 로그에 남겨 어느 단계에서 상태가 엇갈렸는지 추적할 수 있었습니다. 이후 PG사 원장과 내부 DB를 매일 자동 대조하는 배치를 만들어, 불일치 건이 발생하면 알람이 오도록 했습니다.
정합성은 처음 한 번 설계하고 끝나는 것이 아니라, 운영 중 계속 들여다보고 이상 징후를 빨리 잡는 체계가 함께 있어야 유지된다는 것을 배웠습니다.
분산 환경에서 주문·결제·재고 서비스를 분리할 때 SAGA 패턴(코레오그래피 방식)으로 정합성을 설계했습니다. 각 서비스가 이벤트를 발행하고 구독하는 구조라, 중간 서비스가 실패해도 보상 이벤트를 통해 앞 단계를 롤백할 수 있도록 했습니다. 가장 까다로웠던 시나리오는 결제는 성공했지만 재고 차감 서비스가 타임아웃된 경우였습니다. 이때 결제를 취소해야 하는데 취소 요청도 실패할 수 있어 재시도 큐와 최종 실패 알람을 함께 설계해야 했습니다.
멱등성 키를 보상 이벤트에도 붙여 같은 보상이 중복 실행되지 않도록 했습니다. 부분 실패 시나리오를 열거할수록 여기도 보상이 필요한 케이스가 계속 나왔고, 이 목록이 곧 통합 테스트 케이스가 됐습니다. 장애 경로를 먼저 그리는 것이 결제 시스템 설계의 시작이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.