크리에이터–콘텐츠–구독 ERD 설계 복습

1. 관계 구조 정리

1) 크리에이터 – 콘텐츠

• 한 명의 크리에이터는 여러 콘텐츠를 만든다.
  → Creator (1) : Content (N)

2) 사용자 – 크리에이터

• 한 명의 사용자는 여러 크리에이터를 구독할 수 있다.
• 한 명의 크리에이터는 여러 사용자에게 구독될 수 있다.

즉,

User ↔ Creator 는 N:M 관계이며,
이를 표현하기 위해 Subscription(구독) 테이블이 필요하다.

---

2. ERD 초안

User

User
- id (PK)
- email
- name
- created_at

Creator

Creator
- id (PK)
- user_id (FK → User.id)
- channel_name
- description
- created_at

Content

Content
- id (PK)
- creator_id (FK → Creator.id)
- title
- body
- status (DRAFT / PUBLISHED)
- created_at

Subscription

Subscription
- id (PK)
- user_id (FK → User.id)
- creator_id (FK → Creator.id)
- status
- started_at
- ended_at

---

3. Creator를 별도 테이블로 분리한 이유

모든 사용자가 크리에이터로 활동하는 것은 아니다.

• 일반 사용자
• 크리에이터 사용자

이 둘은 역할이 다르다.

User는 “서비스 사용자”라는 기본 엔티티이고,
Creator는 “콘텐츠를 생산하는 역할”을 가진 확장 엔티티다.

이는 역할 분리이자 책임 분리다.

---

4. Subscription 테이블이 필요한 이유

User ↔ Creator는 N:M 관계다.

데이터베이스는 N:M 관계를 직접 표현할 수 없으므로
중간 테이블로 분리해야 한다.

하지만 Subscription은 단순 연결 테이블이 아니다.

구독은 다음과 같은 비즈니스 상태를 가진다.

• 언제 시작했는가
• 어떤 요금제를 사용 중인가
• 현재 활성 상태인가
• 다음 결제일은 언제인가

따라서 Subscription은
“관계 표현 + 비즈니스 상태 관리”를 담당하는 독립 엔티티다.

---

5. 구독 테이블 컬럼 설계 (확장 버전)

Subscription
- id (PK)
- user_id (FK → User.id)
- creator_id (FK → Creator.id)
- plan_type (FREE / PREMIUM)
- price
- billing_cycle (MONTHLY / YEARLY)
- next_billing_at
- started_at
- canceled_at
- expired_at
- status (ACTIVE / PAUSED / CANCELED / EXPIRED)
- created_at
- updated_at

설계 포인트

• 단순 연결이 아니라 “구독 계약”을 표현한다.
• status로 현재 상태를 관리한다.
• canceled_at, expired_at 등으로 이력 추적이 가능하다.

---

6. 중복 구독 가능 여부

한 사용자가 같은 크리에이터에 중복 구독할 수 있는가?

일반적으로는 불가능하다.

따라서 다음과 같은 제약이 필요하다.

• UNIQUE (user_id, creator_id)

이를 통해 동일 사용자–크리에이터 조합의 중복 구독을 방지한다.

---

7. 구독 취소 시 처리 방식

구독을 취소하면 row를 삭제할 것인가?

일반적으로는 삭제하지 않는다.

이유는 다음과 같다.

• 결제 이력 추적 필요
• 통계 및 매출 분석 필요
• 재구독 판단 근거 필요

따라서 soft delete 또는 status 변경 방식으로 처리한다.

예시

• status = CANCELED
• canceled_at 기록

데이터는 유지하고 상태만 변경한다.

---

8. 기본 API 설계

크리에이터 생성

POST /api/creators

• 사용자 중 크리에이터 역할을 생성

구독 생성

POST /api/subscriptions

• user_id는 로그인 사용자 기준
• creator_id와 요금제 정보 전달

구독 취소

DELETE /api/subscriptions/{id}

• 실제 삭제 대신 상태 변경 처리 권장

특정 크리에이터의 콘텐츠 조회

GET /api/creators/{id}/contents

• Creator 1 : N Content 관계 반영

내 구독 목록 조회

GET /api/users/me/subscriptions

• 로그인 사용자 기준 구독 목록 조회

---

9. 최종 정리

• Creator는 모든 사용자가 아닌, 역할이 분리된 엔티티다.
• Content는 크리에이터가 생산한 콘텐츠를 관리한다.
• User ↔ Creator는 N:M 관계이며 Subscription이 이를 풀어낸다.
• Subscription은 단순 연결 테이블이 아니라,
  요금제, 결제 주기, 상태를 가지는 독립적인 비즈니스 엔티티다.

결론적으로,

구독 테이블은 단순 연결이 아니라
“비즈니스 상태를 가지는 독립 엔티티”다.

이 관점이 잡히면 ERD 설계 수준이 한 단계 올라간다.