Data Model

가장 먼저 구현하는 테이블은 users, roles, 둘을 잇는 user_roles입니다. 한 사람이 여러 역할을 가질 수 있도록 연결 테이블로 나눴습니다. 전체 컬럼은 저장소의 docs/MeerKit_테이블명세서.xlsx를 보세요.

users

id와 user_id의 차이

• id: 데이터베이스 내부에서 사용자를 구분하는 고유 번호입니다.
• user_id: 사용자가 로그인할 때 입력하는 ID입니다. 중복되지 않아야 합니다.

roles

user_roles

Relationship

┌───────────────────┐        ┌──────────────┐        ┌──────────────┐
│       users       │ 1    N │  user_roles  │ N    1 │    roles     │
│ id (PK)           ├────────┤ user_id (FK) ├────────┤ id (PK)      │
│ login_id (UNIQUE) │        │ role_id (FK) │        │ code         │
│ hashed_password   │        └──────────────┘        │ name         │
│ email, name       │                                └──────────────┘
│ is_active         │
│ deactivated_at    │
│ deleted_at        │
└───────────────────┘

사용자와 역할은 다대다입니다. 한 사람이 VIEWER와 WRITER를 함께 가질 수 있고, VIEWER가 100명이어도 roles에는 VIEWER가 한 번만 있습니다.

Frontend type

API가 돌려주는 사용자는 역할이 배열로 펼쳐진 형태입니다. 비밀번호 해시는 포함되지 않습니다.

export interface User {
  id: number;
  user_id: string;
  email: string;
  name: string;
  email_verified: boolean;
  roles: { id: number; name: RoleName }[];  // 여러 개일 수 있음
  is_active: boolean;
  created_at: string;
  updated_at: string;
  deactivated_at: string | null;  // 탈퇴 시각
  deleted_at: string | null;      // 개인정보 파기 시각
}

Optional columns

가입 폼의 선택 항목(Signup Form 참고)을 켜면 users에 같은 컬럼이 필요합니다. 기본 스키마에는 포함되어 있지 않습니다.

Terms agreements

약관 동의는 누가 어떤 약관에 언제 동의했는지 남겨야 분쟁 때 증빙할 수 있습니다. 가입 요청의 agreed_terms를 받아 서버가 별도 테이블에 저장하는 방식을 권장합니다.

Email verifications

이메일 인증(signup.emailVerification)을 켰다면 인증번호와 증표를 저장할 곳이 필요합니다.

Password reset tokens

AI usage (planned)

멤버 AI 사용량 화면(Member AI Usage, Member AI Usage History)은 현재 프론트 UI만 작업된 상태입니다. 사용량을 기록·집계하는 테이블과 API는 추후 적용 예정입니다.

Future extensions

• permissions, role_permissions: 세부 기능별 권한이 필요할 때 추가합니다.
• projects: Owner가 여러 프로젝트를 소유하는 구조가 필요할 때 추가합니다.
• refresh_tokens: 토큰 해시, 만료, 폐기 시각을 저장합니다.