이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 소규모 스터디 공간 예약 서비스의 예약·결제 백엔드를 개발한 경험이 있습니다. 예약 충돌 방지를 위해 SELECT FOR UPDATE로 행 잠금을 걸고 트랜잭션을 설계했는데, 동시 예약 요청에서 중복이 발생하지 않는지 테스트하는 과정이 가장 까다로웠습니다. 결제 연동에서는 외부 PG사 API가 실패했을 때 DB 상태와 결제 상태가 불일치하는 케이스를 처리하기 위해 멱등성 키를 사용하고 재처리 로직을 설계했습니다.
결제 시스템에서 가장 중요한 건 부분 실패 케이스를 처음부터 설계에 포함하는 것이었는데, 정상 흐름만 구현하면 실제 운영에서 금액 불일치가 생길 수 있다는 걸 배웠습니다. 지금도 결제 관련 코드를 짤 때 실패 시나리오를 먼저 나열하는 방향을 따릅니다.
예약 플랫폼 백엔드에서 동시에 같은 시간대를 예약하려는 요청이 겹쳤을 때 중복 예약이 생기는 경험을 했습니다. DB 트랜잭션만으로는 여러 서버 인스턴스가 동시에 처리하는 경우를 막기 어려웠습니다.
이후엔 Redis를 이용한 분산 락을 도입해서 같은 시간대 예약 요청이 들어오면 첫 번째만 처리되고 나머지는 즉시 실패로 돌아가게 했습니다. 락 획득에 실패한 요청은 재시도가 아닌 즉시 실패로 응답하게 해서 사용자가 다른 시간대를 선택하게 유도했습니다.
이 경험으로 예약 백엔드에서 DB 락만으로는 분산 환경의 동시성 문제를 완전히 막을 수 없다는 걸 배웠습니다. 인프라 레이어의 락이 함께 필요했습니다.
결제 플랫폼에서 가장 처리하기 어려운 자리는 결제는 성공했는데 예약 완료 처리가 실패하는 경우였습니다. 사용자 입장에서는 돈이 빠졌는데 예약이 안 됐다는 상태가 됩니다.
이 문제를 완전히 해결하지 못한 채 보상 트랜잭션을 일부만 구현해서 운영했습니다. 결제 성공 후 예약 실패 시 자동 환불 흐름을 결제 취소 API로 연결했지만, API 호출 자체가 실패하면 수동 처리가 남는 구조였습니다.
이 경험으로 분산 시스템에서 부분 실패를 처리하는 것은 정상 흐름을 만드는 것보다 훨씬 복잡하다는 걸 배웠습니다. 한계를 인정하고 모니터링과 수동 처리 절차를 함께 갖추는 것도 설계의 일부였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.