이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 트래픽에서 결제 시스템의 안정성을 유지하려면 단일 장애점 제거가 핵심입니다. 결제 처리 서비스를 독립 도메인으로 분리하고, DB 이중화와 읽기/쓰기 분리를 통해 트래픽이 몰려도 핵심 결제 경로가 영향받지 않도록 설계했습니다.
분산 환경에서는 트랜잭션 원자성 보장이 어려워집니다. 결제 승인과 재고 차감이 다른 서비스에 있을 때 둘 중 하나가 실패하면 보상 트랜잭션으로 이전 상태를 되돌리는 구조를 적용했습니다.
피크 트래픽 대비는 부하 테스트로 병목을 미리 파악하는 것에서 시작합니다. k6 같은 도구로 예상 최대 요청 수의 1.5배 부하를 걸어보고, 응답 지연이 발생하는 구간을 최적화한 뒤 배포했고, 실제 피크 타임에도 안정적으로 동작했습니다.
결제 모듈을 구현하면서 처음으로 멱등성 문제를 직접 만났습니다. 모바일 앱에서 결제 요청을 보냈는데 응답이 오지 않으면 앱이 자동으로 재시도하는 로직이 있었고, 서버에서 중복 처리가 되는 상황이 발생했습니다.
해결책으로 요청마다 클라이언트가 생성한 고유 키를 함께 보내고, 서버에서 해당 키로 이미 처리된 요청인지 확인하는 방식을 적용했습니다. 동일한 키가 들어오면 기존 결과를 그대로 반환하도록 했습니다. 간단한 구현이었지만 중복 결제 케이스를 차단하는 데 효과적이었습니다.
서킷 브레이커 패턴은 외부 결제 API가 응답이 느려지는 상황을 실험해보면서 처음 접했습니다. 타임아웃이 길면 요청이 쌓이면서 전체 서비스가 느려지는 것을 확인하고, 일정 횟수 이상 실패하면 일정 시간 동안 외부 호출을 차단하는 간단한 로직을 추가했습니다. 대규모 환경의 완성된 패턴은 아니었지만, 외부 장애가 내부로 전파되는 구조를 처음으로 직접 설계한 경험이었습니다.
분산 환경에서 결제 처리를 구현하면서 가장 까다로웠던 것은 롤백 처리였습니다. 결제 승인은 성공했는데 재고 차감 서비스에서 오류가 발생하는 경우, 이미 승인된 결제를 어떻게 되돌릴 것인가가 문제였습니다.
팀 프로젝트 수준에서는 단순한 보상 로직을 적용했습니다. 결제 승인 이후 재고 차감이 실패하면 결제 취소 API를 호출하는 방식이었는데, 취소 API 호출도 실패하는 경우를 처리하는 것이 추가 과제가 됐습니다. 이 상황에서 재시도 큐에 취소 요청을 넣어두고 나중에 처리하는 방식을 적용했습니다.
이 경험에서 배운 것은 분산 시스템에서 완전한 원자성을 보장하는 것이 어렵고, 오류가 발생했을 때 결국 정합성으로 수렴하는 보상 로직이 현실적인 접근이라는 점입니다. 완벽한 트랜잭션 대신 결국 맞춰지는 시스템을 만드는 것이 대규모 결제 시스템에서 더 실용적인 결이라는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.