이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 소규모 중고 거래 플랫폼을 만들며 커머스 도메인을 처음 경험했습니다. 주문 상태를 단순 completed/pending으로만 설계했다가 상태 전이 엣지 케이스가 계속 터지는 문제를 겪었습니다. '결제 완료 후 배송 전 취소' 같은 중간 상태를 처음부터 설계에 넣지 않은 게 원인이었고, 상태 머신 패턴으로 9개 상태·12개 전이를 명시적으로 정의하는 방식으로 리팩터링했습니다. 이후 환불 관련 버그가 0건이 됐고, 새 상태 추가도 기존 로직을 건드리지 않고 가능해졌습니다. 이 경험으로 커머스 도메인의 복잡성은 기능 수가 아니라 상태 관리와 예외 흐름에 집중돼 있다는 것을 직접 배웠습니다.
커머스 플랫폼에서 결제 외에 가장 복잡한 것이 정산 처리라는 걸 직접 경험했습니다. 판매자와 구매자 사이의 수수료 정산을 처음엔 단순 계산으로 생각했는데, 취소·부분 환불·배송비 별도 청구 케이스가 생기자 계산이 맞지 않는 문제가 생겼습니다. 환불 금액이 정산 이후에 발생하면 이미 정산된 금액을 어떻게 차감할지 플로우가 설계에 없었기 때문이었습니다.
정산 상태를 pending·confirmed·paid·partially_refunded로 분리하고 각 전이 조건을 명시적으로 정의했습니다. 그 이후 환불 발생 시 자동으로 정산 조정이 계산되도록 만드니 수작업 계산이 사라졌습니다. 커머스 플랫폼은 눈에 보이는 기능보다 돈 흐름을 추적하는 로직이 가장 단단해야 한다는 걸 배웠습니다.
커머스 플랫폼에서 상품 검색 결과가 전환율에 직접 영향을 준다는 걸 데이터로 확인했습니다. 처음엔 단순 텍스트 매칭으로 검색을 구현했는데, 사용자가 유사어로 검색했을 때 관련 상품이 나오지 않아 이탈하는 패턴이 로그에서 보였습니다. 검색 쿼리와 이탈률을 교차 분석하니 상위 5개 검색어 중 3개에서 결과가 0건으로 나오는 케이스가 전체 이탈의 상당 부분을 차지했습니다.
Elasticsearch의 동의어 사전과 fuzzy 검색을 적용하니, 해당 검색어의 결과 0건 비율이 32%에서 4%로 줄었고 같은 기간 검색 후 상품 클릭률도 올랐습니다. 검색 품질은 트래픽이 아니라 사용자가 찾으려는 걸 찾게 해주는 것이라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.