이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 소규모 배송 추적 서비스를 만들어봤습니다. 물류 백엔드를 설계할 때 가장 먼저 고려하는 건 배송 상태 전이의 정확성이라고 생각합니다. 픽업 대기→픽업 완료→배송 중→완료→반송 흐름에서 상태가 역순으로 바뀌거나 누락되면 고객에게 잘못된 정보가 보입니다. 다음으로 중요한 건 외부 물류사 API 연동의 신뢰성인데, 외부 API가 지연되거나 응답이 없을 때도 내부 시스템이 정상 동작하는 구조를 갖추는 게 중요하다는 걸 배웠습니다. 재고 쪽에서는 동시 주문 시 재고 초과 예약이 생기지 않도록 동시성 처리가 중요하다는 걸 작은 규모에서도 경험했습니다. 정산 로직은 설정 테이블로 뽑아서 코드 수정 없이 배송비 정책을 바꿀 수 있는 구조를 만들었습니다.
물류 백엔드는 상태 전이와 외부 연동 신뢰성이 나머지 기능의 전제 조건이라는 게 제 생각입니다.
물류 백엔드를 설계하면서 재고 이중 차감이 실제로 발생하는지 확인하고 싶었습니다. 두 요청이 동시에 들어왔을 때 둘 다 재고가 있다고 판단하고 각각 차감하는 상황을 테스트로 재현했습니다. 예상대로 재고가 음수가 되는 케이스가 나왔습니다. 낙관적 잠금으로 해결했는데, 버전 컬럼을 읽어두고 업데이트 시 버전이 같을 때만 차감하는 방식이었습니다. 버전이 다르면 재시도하도록 구현했고, 실제 동시 주문 테스트에서 재고 음수가 더 발생하지 않는 것을 확인했습니다.
물류 시스템에서 동시성 문제는 직접 재현해보지 않으면 코드 리뷰에서 놓치기 쉬운 결이 있다는 것을 이 경험에서 배웠습니다.
물류 서비스에서 오배송이나 반품 같은 예외 상황이 발생했을 때 어떻게 처리할지를 설계 단계에 포함해야 한다는 것을 배웠습니다. 처음에는 정상 배송 흐름만 설계하고 예외는 나중에 추가하려 했는데, 예외 상태에서 어떤 전이가 가능한지 정의하지 않으면 코드가 지저분해지는 결이 됐습니다.
State Machine으로 주문 상태를 정의했더니, 어떤 상태에서 어떤 전이가 허용되는지 명확해졌습니다. 오배송 접수 후 반품 대기→반품 완료→환불 처리 흐름이 코드로 표현하기 훨씬 쉬워졌습니다. 배송 서비스는 정상 흐름보다 예외 흐름의 복잡도가 더 높은 결이 있다는 것을 이 경험에서 배웠습니다. 설계 초기에 예외 흐름을 함께 정의하는 것이 나중에 엣지 케이스 처리 비용을 줄이는 결이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에코마케팅 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.