멀티 모듈 기반 영화 예매 서비스 설계기 : 테이블 및 엔티티 설계(1) - ERD 모델링

설계 목표

이 프로젝트에서 내가 세운 데이터 설계의 핵심 목표는 다음과 같았다.

1. 비즈니스 흐름을 자연스럽게 표현할 수 있어야 한다
   예매가 어떤 흐름으로 일어나는지, 각 데이터가 어떻게 연결되는지를 모델링 안에서 바로 드러나게 하고 싶었다.
2. 단순하지만 확장 가능한 구조를 만들자
   처음에는 단순하게 시작하되, "할인 정책 추가", "좌석 상태 관리", "복수 사용자 인증" 같은 변화에도 잘 견딜 수 있도록 설계하고자 했다.
3. 테이블 간의 책임을 명확하게 나누자
   하나의 테이블이 너무 많은 역할을 하지 않도록, 도메인 별로 기능을 쪼개고 의존성을 줄이려 했다.

---

테이블 설계 흐름

처음에는 그냥 머릿속에서 "사용자가 로그인하고, 영화를 보고, 예매를 한다"는 시나리오를 자연어로 풀어보는 데서 시작했다.
그 다음으로 각 개체(Entity)를 도출했고, 자연스럽게 다음과 같은 구조가 잡혔다.

사용자(USERS)
  ↳ 여러 건의 예매(RESERVATIONS)
    ↳ 각각 상영 일정(SCHEDULES)과 좌석(SEATS)에 연결
      ↳ 상영 일정은 영화(MOVIES)와 극장(THEATERS)에 연결됨
영화(MOVIES) ↔ 여러 이미지(IMAGES)
극장(THEATERS) ↔ 여러 좌석(SEATS)

이 흐름을 기반으로 실제 ERD를 구성했고, 아래는 그 결과다.

---

최종 ERD

---

📌 설계 시 고민했던 포인트

1️⃣ 좌석은 정적인가, 동적인가?

처음엔 좌석을 schedule_id에 종속시켜서 "회차별 좌석 구성"을 상정했는데,
이 구조는 너무 복잡해지고 데이터 중복이 발생할 수 있었다.

그래서 좌석은 극장 단위로 고정된 정적 구조로 두고, 예매는 seat_id + schedule_id 조합으로 처리했다.

2️⃣ 영화 정보와 상영 정보는 분리해야 한다

영화 정보는 정적인 데이터지만, 상영 일정은 시간표처럼 계속 바뀐다.
따라서 MOVIES와 SCHEDULES를 분리하고, 상영 회차별 좌석 예약도 이 SCHEDULES를 기준으로 연결했다.

---

마무리하면서

다음 글에서는 이 ERD를 바탕으로 실제 JPA 엔티티를 어떻게 구현했는지,
각 연관관계를 어떻게 정의했고, 공통 속성은 어떻게 처리했는지를 정리할 예정이다.

특히 createdAt, updatedAt 같은 공통 속성을 BaseTimeEntity로 분리해서 처리한 방식과,
연관관계 설정에서 고민했던 Lazy vs Eager, 단방향 vs 양방향 같은 결정 포인트들을 하나하나 정리해보려 한다.