객체 지향 설계 사례: 예약·대여 시스템

풀이 순서와 여러 사례에 공통으로 쓰는 부품(계정과 사람, 정의와 인스턴스 분리, Search 인터페이스, 알림·결제)은 객체 지향 설계 면접: 풀이 순서와 반복되는 설계 부품에 있다. 이 노트는 사례별로 다른 부분만 적는다.

예약 시스템의 공통 골격

영화·항공·호텔·식당 예약은 활동 다이어그램이 거의 같다.

flowchart TB
  s["고객이나 직원이 검색 조건 입력<br>(날짜, 인원, 등급 등)"] --> q{"예약 가능한 대상이 있나?"}
  q -->|"아니요"| again{"다시 검색?"}
  again -->|"예"| s
  again -->|"아니요"| stop["불가 안내"]
  q -->|"예"| pick["대상 고르기<br>(회차·좌석·객실·테이블)"]
  pick --> cust{"기존 고객인가?"}
  cust -->|"예"| find["고객 정보 찾기"]
  cust -->|"아니요"| reg["신규 고객 등록"]
  find --> pay{"결제 수단"}
  reg --> pay
  pay -->|"카드"| card["카드 결제"]
  pay -->|"현금"| cash["현금 결제"]
  card --> out{"확인서 받는 방법"}
  cash --> out
  out -->|"인쇄"| prt["인쇄"]
  out -->|"이메일"| mail["이메일 발송"]

취소는 「예약 번호(와 성)로 예약 찾기 → 취소하고 남은 좌석·객실 수 되돌리기 → 환불 가능 기간이면 환불, 아니면 환불 없음 → 취소 내역을 인쇄 또는 이메일로」다. 사례마다 다른 것은 예약 대상의 계층, 환불 규칙, 부가 요금이다.

도서관 관리 시스템

요구 사항

• 회원은 제목, 저자, 주제, 출판일로 책을 검색한다.
• 책마다 고유 번호와 서가 번호(실물 위치)가 있다. 같은 책의 사본 한 권 한 권을 책 항목(book item) 이라 부르고, 대출과 예약은 항목 단위다.
• 특정 책을 누가 빌렸는지, 특정 회원이 무엇을 빌렸는지 조회한다.
• 한 회원은 최대 5권, 한 권을 최대 10일 빌린다. 반납일을 넘기면 연체료를 걷는다.
• 지금 없는 책은 예약하고, 예약한 책이 돌아오면 알림을 받는다. 반납일을 넘겨도 알림이 간다.
• 책과 회원증에 고유 바코드가 있고, 시스템이 바코드를 읽는다.

액터와 유스케이스

유스케이스: 책 추가·삭제·수정, 카탈로그 검색, 회원 가입·탈퇴, 대출, 예약, 연장(다시 빌리기), 반납.

핵심 클래스

대출·반납·연장 규칙

flowchart TB
  a["회원증과 책 바코드 스캔"] --> b{"빌린 권수가 5권 미만인가?"}
  b -->|"아니요"| err["오류 안내"]
  b -->|"예"| c{"다른 회원이 예약했나?"}
  c -->|"예"| err
  c -->|"아니요"| d{"참고 도서인가?"}
  d -->|"예"| err
  d -->|"아니요"| e["대출 기록 생성, 상태 LOANED"]
  e --> f["빌린 권수 1 증가"]
  f --> g["본인 예약이 있었으면 COMPLETED"]

권수 한도와 예약 검사는 Member가, 참고 도서 검사와 상태 변경은 BookItem이 맡는다. 규칙을 그 정보를 가진 객체에 둔 배치다.

영화 티켓 예매 시스템

요구 사항

• 제휴 영화관이 있는 도시 목록을 보여 준다. 영화관에는 상영관이 여럿이고, 한 상영관은 한 번에 한 회차만 상영한다. 영화 하나에 회차가 여럿이다.
• 제목, 언어, 장르, 개봉일, 도시로 영화를 검색한다. 영화를 고르면 상영하는 영화관과 회차를, 회차를 고르면 좌석 배치도를 보여 준다.
• 좌석을 여러 개 고르고, 빈 좌석과 팔린 좌석을 구분해 보여 준다.
• 새 영화 개봉, 예매, 취소 때 알림을 보낸다. 카드나 현금으로 결제하고 할인 쿠폰을 적용한다.
• 두 고객이 같은 좌석을 예매할 수 없다.

액터와 클래스

유스케이스: 영화 검색, 예매 생성·수정·조회, 결제, 쿠폰 적용, 좌석 지정, 환불(허용 기간 안에 취소하면 결제 금액을 돌려준다).

예매 흐름은 공통 골격에 좌석 고르기와 쿠폰 입력이 더해진다. 검색 조건에는 날짜, 좌석 수, 제목·장르·개봉일·언어·도시가 들어간다.

같은 좌석의 동시 예매 막기

DB 트랜잭션으로 행을 잠근다. 가장 높은 격리 수준인 SERIALIZABLE은 더티 리드, 반복 불가능 읽기, 팬텀 읽기를 모두 막는다. 트랜잭션 안에서 읽은 행에는 쓰기 잠금이 걸려 다른 트랜잭션이 갱신하지 못한다.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
  -- 회차 99의 좌석 54, 55, 56을 잡으려 한다
  SELECT * FROM ShowSeat
   WHERE ShowID = 99 AND ShowSeatID IN (54, 55, 56) AND isReserved = 0;
  -- 돌아온 행이 3개가 아니면 실패를 돌려준다
  UPDATE ShowSeat ...;
  UPDATE Booking ...;
COMMIT TRANSACTION;

커밋에 성공하면 그 좌석은 이 고객 것으로 확정되고, 다른 고객은 같은 좌석을 잡을 수 없다. 격리 수준과 이상 현상은 트랜잭션과 회복에 있다.

항공사 관리 시스템

요구 사항

• 날짜와 출발·도착 공항으로 항공편을 검색하고, 예정된 항공편의 표를 예약한다. 여러 구간을 잇는 여정을 만들 수 있고, 여정 하나에 승객 여럿을 예약한다.
• 운항 일정, 출발·도착 시각, 남은 좌석 같은 정보를 조회한다.
• 기체·항공편·운항 일정은 관리자만 추가한다. 관리자가 예정된 항공편을 취소하면 관련된 모두에게 알린다.
• 고객은 예약과 여정을 취소한다. 조종사와 승무원을 항공편에 배정한다. 결제와 알림(예약 생성·변경, 운항 상태 변경)을 처리한다.

액터와 클래스

유스케이스: 항공편 검색, 예약 생성·수정·조회, 승객 좌석 지정, 결제, 운항 일정 변경, 조종사·승무원 배정.

관계와 흐름

이 사례는 UML 클래스 다이어그램 설명의 예제로도 쓰인다.

예약 흐름은 공통 골격에 검색 조건(날짜, 좌석 등급, 승객 수), 승객 정보 입력, 승객별 좌석 고르기가 더해진다. Java 예제의 ReservationService는 예약 생성 → 승객에게 좌석 배정 → 결제가 성공하면 CONFIRMED로 바꾸고 확정 이메일 → 취소하면 취소 이메일 순으로 묶는다. 취소는 성과 예약 번호로 예약을 찾고, 취소하면서 운항 회차의 좌석을 되돌린다.

호텔 관리 시스템

요구 사항

• 스탠더드, 디럭스, 패밀리 스위트 같은 객실 종류를 예약한다. 손님은 객실 재고를 검색해 빈 방을 예약한다.
• 누가 어느 방을, 어느 고객이 어떤 방들을 예약했는지 조회한다.
• 체크인 24시간 전까지 취소하면 전액 환불한다.
• 체크인·체크아웃이 다가오면 알림을 보낸다. 객실 청소 기록을 남긴다.
• 룸서비스와 음식, 어메니티를 추가한다. 카드, 수표, 현금으로 결제한다.

액터와 클래스

유스케이스: 객실 추가·삭제·수정, 객실 검색, 계정 등록·해지, 객실 예약, 체크인, 체크아웃(예약 종료와 객실 키 반납), 객실 요금 추가, 청소 기록 갱신.

체크인은 「리셉션이 예약 검색 → 예약이 있나 → 객실이 준비됐나(아니면 기다려 달라고 안내) → 객실 키 발급 → 예약 상태를 CHECKED_IN으로」다. 부가 요금을 RoomCharge 하위 클래스로 덧붙이는 구조는 데코레이터처럼 기본 숙박료에 요금을 쌓는다.

식당 관리 시스템

요구 사항

• 식당에 지점이 여럿 있고, 지점마다 메뉴가 있다. 메뉴는 메뉴 섹션으로, 섹션은 메뉴 항목으로 이뤄진다.
• 웨이터는 테이블의 주문을 만들고 좌석마다 식사(meal) 를 추가한다. 식사는 식사 항목 여러 개로 이뤄지고, 식사 항목 하나는 메뉴 항목 하나에 대응한다.
• 바로 들어온 손님(walk-in)에게 내줄 빈 테이블을 조회한다. 리셉션은 날짜·시각으로 빈 테이블을 찾아 예약하고, 고객은 예약을 취소한다.
• 예약 시각이 다가오면 알림을 보낸다. 카드, 수표, 현금으로 결제한다. 지점마다 테이블 배치도가 여러 개일 수 있다.

액터와 클래스

유스케이스: 테이블 추가·수정, 테이블 검색, 주문, 주문 수정(식사·식사 항목 추가·변경), 예약 생성, 예약 취소, 체크인, 결제.

flowchart TB
  a["웨이터가 시스템에 로그인"] --> b["테이블의 새 주문 생성"]
  b --> c["좌석 하나의 식사 생성"]
  c --> d["식사에 식사 항목 추가"]
  d --> e{"주문할 좌석이 더 있나?"}
  e -->|"예"| c
  e -->|"아니요"| f["주방으로 주문 전송"]

예약은 「인원과 날짜·시각을 받아 빈 테이블 검색 → 기존 고객 찾기 또는 신규 등록 → 테이블 예약 → 인쇄·이메일로 확인」, 취소는 「예약 검색 → 취소하고 테이블 상태를 FREE로」다.

렌터카 시스템

요구 사항

• 승용차, 트럭, SUV, 밴, 오토바이를 빌려준다. 차량마다 고유 바코드와 주차 칸 번호(위치)가 있고, 시스템이 바코드를 읽는다.
• 누가 어느 차를, 어느 회원이 어떤 차들을 빌렸는지 조회한다.
• 반납일을 넘기면 연체료를 걷는다. 회원은 재고를 검색해 예약하고, 예약을 취소한다.
• 인수일이 다가올 때, 반납일이 다가올 때, 반납일을 넘겼을 때 알림을 보낸다.
• 차량에 일어난 모든 사건을 차량 로그로 남긴다.
• 회원은 렌터카 보험, 추가 장비(내비게이션, 카시트, 스키 랙), 추가 서비스(긴급 출동, 추가 운전자, 와이파이)를 예약에 붙인다.
• 지점이 여러 곳이라 빌린 곳과 다른 지점에 반납할 수 있다.

액터와 클래스

유스케이스: 차량 추가·삭제·수정, 카탈로그 검색(차종·재고 여부), 회원 가입·탈퇴, 예약, 인수(대여 시작), 반납, 장비 추가, 차량 로그 갱신(주유, 세차, 파손).

정리

• 예약 계열은 「검색 → 대상 고르기 → 고객 확인 → 결제 → 확인서」와 「찾기 → 취소 → 환불 판단」 두 흐름이 공통이고, 차이는 대상 계층과 규칙이다.
• 예약은 언제나 인스턴스(책 항목, 회차 좌석, 운항 회차 좌석, 객실, 테이블, 차량)를 대상으로 한다.
• 숫자 규칙(5권·10일, 24시간 전 환불)은 상수로 두고, 그 규칙을 검사하는 책임은 정보를 가진 객체에 준다.
• 동시 예약은 객체 설계만으로 막지 못한다. DB 트랜잭션과 잠금까지 말해야 답이 끝난다.

관련 노트: 객체 지향 설계 면접: 풀이 순서와 반복되는 설계 부품, 객체 지향 설계 사례: 주차장·ATM과 카드·보드 게임, 객체 지향 설계 사례: 커머스·커뮤니티·플랫폼, 트랜잭션과 회복, 소프트웨어 설계와 공학