이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
주로 다뤄본 건 회원과 프로모션 로직입니다. 회원 등급에 따라 할인율·포인트·배송비 면제 조건이 달라지는 구조를 설계할 때, 처음엔 조건 분기로 짰다가 등급이 추가될 때마다 코드 전체를 바꿔야 하는 문제가 생겼습니다. 정책 테이블로 분리하고 등급별 혜택을 DB에서 읽어오는 방식으로 바꾸니 코드 변경 없이 정책을 조정할 수 있게 됐습니다. 프로모션은 중복 적용 여부, 유효 기간, 적용 우선순위를 동시에 관리해야 해서 룰 엔진 패턴을 도입했습니다. 비즈니스 규칙이 복잡할수록 코드보다 설정으로 제어하는 비율을 높이는 게 유지보수 비용을 낮춘다는 걸 이 과정에서 배웠습니다.
회원과 프로모션 로직은 직접 구현해봤지만 정산 도메인은 경험이 거의 없다는 걸 솔직하게 인정합니다. PG사 정산 주기, 수수료 계산, 취소·환불 시 상태 머신이 얼마나 복잡한지는 이론으로만 알고 있습니다. 정산 버그는 금전적 손실로 이어지기 때문에, 잘 모르는 채로 짜면 위험하다고 생각합니다. 현재 부족한 부분을 보완하려고 PG사 API 문서와 오픈소스 정산 모듈 코드를 직접 읽는 중입니다.
환불 상태 머신을 작은 사이드 프로젝트로 직접 구현해보면서 예외 경로를 파악하고 있습니다. 도메인 복잡도가 높은 영역일수록 섣불리 자신 있다고 하는 것보다 모르는 부분을 파악하고 채우는 게 더 중요하다고 봅니다.
인벤토리 로직에서 동시에 여러 주문이 들어올 때 재고가 음수가 되는 문제를 직접 경험했습니다. 재고 조회 후 감소를 두 단계로 처리했는데, 조회와 감소 사이에 다른 요청이 끼어드는 레이스 컨디션이 생겼습니다. 처음엔 애플리케이션 레이어에서 락을 잡으려 했는데, 분산 환경에서는 동작하지 않았습니다.
UPDATE stock SET count = count - 1 WHERE count > 0 형태의 원자적 감소 쿼리로 바꾸니 DB 레벨에서 음수가 방지됐습니다. 동시 요청 100건을 시뮬레이션했을 때 재고 0 이하로 내려가는 케이스가 사라졌습니다. 재고 처리는 비즈니스 로직이 아니라 DB 연산 수준에서 원자성을 보장해야 한다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.