이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
주문·배송 관리 시스템 개발에서 가장 먼저 고민한 것은 주문 상태 전이를 명확히 정의하는 것이었습니다. 주문 생성부터 배송 완료까지 상태가 복잡하게 얽히기 때문에, 상태 머신으로 허용된 전이만 허용하고 잘못된 상태 변경을 차단했습니다. 이 설계가 버그를 사전에 막는 데 효과적이었습니다.
배송사 연동이 주요 도전 과제였습니다. 외부 배송사 API의 불안정성과 응답 지연에 대비해 재시도 로직과 타임아웃을 설정했고, 배송사별로 인터페이스가 달라 표준 어댑터 레이어를 두어 내부 시스템은 동일한 방식으로 호출할 수 있게 했습니다.
재고 정합성도 핵심이었습니다. 동시에 여러 주문이 같은 재고를 차지하는 상황에서 낙관적 락을 적용해 재고 초과 판매를 방지했습니다. 결제 완료 시점에 재고를 최종 차감하는 흐름을 트랜잭션으로 묶어 일관성을 유지했습니다.
주문 배송 시스템에서 외부 배송사 API 연동이 반복적으로 실패하면서 주문이 처리되지 않는 상황을 경험했습니다. 처음에는 오류가 발생하면 즉시 재시도하는 방식으로 처리했는데, 배송사 측에서 일시적인 장애가 있을 때 재시도가 연속으로 몰려서 오히려 더 많은 오류가 쌓이는 상황이 생겼습니다. 재시도 간격을 점점 늘리는 지수 백오프 방식으로 바꾸니 배송사 장애 상황에서 불필요한 요청이 줄었습니다. 또한 배송사 API 실패가 주문 전체를 실패로 처리하지 않도록, 배송 등록을 비동기 처리로 분리해서 주문 생성은 성공하고 배송 등록은 나중에 재시도하는 구조를 도입했습니다. 외부 시스템과의 연동은 상대방이 항상 정상 동작한다는 가정을 해서는 안 되고, 장애 상황에서 내 시스템이 어떻게 동작할지를 처음부터 설계에 포함해야 한다는 것을 이 경험에서 배웠습니다.
주문 배송 관리 시스템에서 재고 초과 판매가 실제로 발생한 경험이 있습니다. 동시에 여러 주문이 들어왔을 때 각각 재고 조회를 한 후 차감하는 사이에 타이밍 문제가 생겨, 재고가 1개 남은 상황에서 두 주문 모두 성공으로 처리되는 경우가 발생했습니다. 락 없이 조회와 차감이 분리된 구조가 원인이었는데, 재고 차감 시점에 현재 재고를 다시 확인하면서 조건이 맞을 때만 차감하는 방식으로 원자적으로 처리하는 구조로 바꿨습니다. 이 버그가 실제로 발생하기 전에는 타이밍 문제가 생길 수 있다는 것을 인지하지 못했는데, 발생하고 나서야 동시성 문제를 처음부터 설계에서 고려해야 한다는 것을 알게 됐습니다. 재고 관련 로직은 단순해 보여도 동시 접근 상황을 고려하지 않으면 실제 운영에서 데이터 정합성 문제로 이어진다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.