예약 상태 설계 면접 질문: 대기·확정·취소·노쇼를 status 하나로 덮을 때

이런 화면입니다

식당 예약 앱에서 테이블을 신청하면 「확정 대기」가 뜹니다. 가게가 받으면 「확정」으로 바뀌고, 사정이 생기면 취소합니다. 안 나타나면 노쇼가 됩니다.

예약마다 상태 배지가 붙고, 시간이 흐르며 배지가 바뀝니다. 배지가 바뀌는 순간마다 손님과 가게의 요청이 엇갈려 도착할 수 있습니다.

면접관이 이렇게 묻습니다

범위부터 좁힙니다

한 줄로 좁힙니다. 상태는 대기, 확정, 취소, 노쇼 넷이고, 가게와 손님이 각자 상태를 바꾼다. 테이블 배정과 결제는 접어 둡니다.

가장 많이 나오는 답

예약 테이블에 status 칸 하나를 두고, 기능마다 필요한 값으로 자유롭게 덮어씁니다.

UPDATE reservations SET status = 'CONFIRMED' WHERE id = :id;  -- 가게 수락
UPDATE reservations SET status = 'CANCELED'  WHERE id = :id;  -- 손님 취소

기능 하나하나는 단순하고, 화면도 잘 바뀝니다.

그런데 여기서 깨집니다

손님이 취소를 누른 직후 가게의 수락이 도착합니다. 수락 쪽 UPDATE는 지금 상태를 보지 않고 CONFIRMED를 씁니다. 취소된 예약이 확정됩니다.

노쇼 처리된 예약이 어느 기능의 실수로 대기로 돌아가는 일도 생깁니다. 규칙이 코드 여기저기의 if 문으로 흩어져 있어서 어디서 새는지 찾기 어렵습니다.

떨어지는 답은 이런 모양입니다

• status를 기능마다 자유롭게 덮어씁니다.
• 버튼을 숨기면 된다고 답합니다.
• 전이 규칙이 코드 여기저기의 if 문으로 흩어집니다.

면접관은 여기서 멈추지 않습니다

1. 언제 누가 상태를 바꿨는지 이력을 남기려면요?

   마지막 상태만 남기는 설계의 한계를 아는지 봅니다.

2. 남의 예약을 취소하는 요청이 오면요?

   상태 규칙과 권한 확인을 따로 생각하는지 봅니다.

3. 상태가 바뀔 때 알림, 정산, 통계까지 따라 움직여야 하면요?

   상태 변화를 다른 기능이 어떻게 알게 할지 봅니다.