이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
쿠폰 시스템 개발에서 가장 복잡한 부분은 쿠폰 상태 전이 관리였습니다. 발급·적용·사용·만료·취소 각 상태가 명확히 정의되지 않으면 이미 사용된 쿠폰이 다시 적용되거나 취소 시 복원이 안 되는 문제가 생겼습니다.
동시성 처리도 중요한 설계 과제였습니다. 선착순 쿠폰처럼 발급 수량이 제한된 경우, 여러 사용자가 동시에 요청할 때 수량이 초과되는 문제가 생겼습니다. 비관적 락이나 레디스 기반 분산 락을 적용해 초과 발급을 방지했습니다.
포인트 시스템에서는 적립·소멸·사용 이력을 모두 기록하는 이벤트 소싱 방식을 사용했습니다. 현재 잔액을 업데이트하는 것보다 변경 이력을 쌓고 집계로 현재 값을 계산하면 감사 추적과 오류 복구가 수월했습니다.
학부 프로젝트에서 선착순 쿠폰 기능을 만들다가 동시 발급 중복 문제를 처음 만났습니다. 처음에는 단순히 발급 수량 체크 후 INSERT를 했는데, 동시에 요청이 몰리면 수량 초과 발급이 발생했습니다. 재고가 충분하다고 읽고, 발급 처리하는 사이에 다른 요청이 끼어드는 것이었습니다. 해결책으로 DB의 낙관적 락을 적용해 발급 시점에 version 컬럼을 비교하도록 바꿨고, 충돌이 발생하면 재시도 로직을 추가했습니다. 테스트로 100개 쿠폰에 200개 동시 요청을 보냈더니 정확히 100건만 발급됐습니다. 처음에 락 없이 짜면 충분하다고 생각했던 게 얼마나 위험한지 그 과정에서 배웠습니다. 지금도 수량 제한이 있는 기능을 만들 때는 동시성 시나리오를 먼저 그려봅니다.
인턴 기간에 포인트 시스템의 적립·차감 내역이 가끔 맞지 않는 버그를 맡아 원인을 찾았습니다. 로그를 보니 같은 트랜잭션 안에서 포인트를 읽고 차감하는 사이에 다른 요청이 들어와 잔액이 꼬이는 경우였습니다. 저는 포인트 차감 쿼리를 UPDATE ... WHERE balance >= amount 형태로 바꿔 잔액 확인과 차감을 단일 원자 연산으로 묶었습니다. 조건을 만족하지 않으면 영향 행이 0이 되므로, 응답에서 그 값을 체크해 실패로 처리했습니다.
SELECT 후 UPDATE 패턴이 얼마나 위험한지 처음 실감한 경험이었습니다. 배포 후 2주 동안 동일한 불일치 버그가 재현되지 않아서 원인이 맞았다는 걸 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.