본문으로 건너뛰기

User 도메인 비즈니스 규칙

1. 사용자 계정 관리 규칙​

1.1 계정 생성 규칙​

  • 모바일 앱을 통한 회원 가입 시, 유효한 Access Code가 필요함 (Access Code 도메인 의존).
  • 회원 가입 시, 이메일 인증 절차가 필수임 (Auth 도메인 의존).
  • 가입 시 필요한 동의 항목 수집 및 처리는 Auth 도메인에서 담당함.
  • 모든 사용자는 생성 시점에 최소 하나 이상의 그룹(Group)에 자동으로 할당되어야 함 (Group 도메인 책임).
  • USER 타입의 모든 사용자는 생성 시점에 유효한 Plan에 직접 연결되어야 함 (Plan 도메인 책임).
  • Group과 Plan은 독립적으로 관리됨: 그룹 변경이 플랜에 영향을 주지 않으며, 플랜 변경이 그룹에 영향을 주지 않음.
  • 게스트 계정 생성 규칙
    • 게스트 계정은 필수 약관 동의와 디바이스 검증이 완료되어야 생성 가능하며, 이메일/소셜 자격 증명을 저장하지 않음.
    • 게스트 계정 생성 시 게스트 그룹(guests.{region})과 게스트 플랜(plan.guest)이 자동 할당되어야 함.
    • 게스트 계정은 생성 즉시 TimeMachine 기반 만료 타이머(서비스 설정에 따른 기간)를 예약해야 함.
    • 게스트와 정식 사용자의 구분은 IAM Group(guests.* vs patients.*)으로 관리됨.

1.2 계정 정보 관리 규칙​

  • 사용자 정보(ID, 이메일, 이름, 상태, 프로필 등) 조회 가능.
  • 사용자 정보(이름, 프로필 정보 등) 수정 가능.
  • 이메일 및 비밀번호 변경은 Auth 도메인의 책임임.

1.3 계정 상태 관리 규칙​

  • 사용자 계정 상태는 다음 중 하나로 관리됨:
    • ACTIVE: 활성, 서비스 이용 가능.
    • INACTIVE: 비활성(탈퇴), 서비스 이용 불가. 즉시 익명화 처리되고, 일정 기간 후 삭제 처리될 수 있음.
    • LOCKED: 일시 잠김, 특정 조건(예: 로그인 연속 실패)으로 인한 일시적 접근 제한 (Auth 도메인 연관).
    • PENDING: 활성화 대기, 계정 활성화(예: 이메일 인증) 필요.
    • SUSPENDED: 이용 정지, 관리자가 설정한 기간 동안 서비스 이용 제한.
    • BANNED: 영구 정지, 영구적 서비스 접근 차단.
    • (참고: 여기서 정의된 계정 상태는 사용자가 자발적으로 치료 활동을 일시 정지하는 것과는 별개로 관리됩니다. 치료 활동 일시 정지는 5번 섹션을 참조하십시오.)
  • 계정 상태 변경 이력은 추적 및 기록되어야 함.
  • 특정 조건(예: 연속 로그인 실패, 관리자 조치) 발생 시 계정 상태 자동 변경 가능.
  • 게스트 계정 승격/만료 규칙
    • Step-up 인증이 완료되면 IAM Group(guests.* → 서비스 정책에 따른 대상 그룹)과 Plan(plan.guest → 서비스 정책에 따른 대상 플랜)을 변경하고, upgradedAt을 기록하고 게스트 만료 타이머를 해제해야 함. userId(UUID)는 변경되지 않음.
    • 게스트 계정이 만료 시 EXPIRED 이벤트를 기록하고, IAM/Group/Plan 도메인과 협력하여 게스트 권한을 제거해야 함.
    • 만료된 게스트 계정은 정책에 따라 INACTIVE 처리 또는 삭제 프로세스를 시작해야 함.

1.4 계정 비활성화/삭제 규칙 (GDPR 준수)​

  • 사용자는 계정 비활성화(탈퇴)를 요청할 수 있음.
  • 게스트 계정(guests.* IAM Group 소속)도 자발적으로 탈퇴를 요청할 수 있으며, 일반 사용자와 동일한 비활성화(Soft Delete) 방식이 적용됨.
  • 비활성화된 계정은 정책에 따라 일정 기간 후 영구 삭제 되어야 함.
  • 데이터 삭제/익명화 시 관련 규정(예: GDPR "잊힐 권리")을 준수해야 함.
  • 사용자 데이터 삭제는 다음 유형으로 구분됨:
    • SOFT_DELETE: 비활성화, 데이터 보존 및 계정 복구 가능
    • ANONYMIZE: 익명화, 개인식별정보 제거 및 기록 유지
    • HARD_DELETE: 영구 삭제, 전체 데이터 완전 제거 (개발 환경용)
  • 비활성화된 사용자 계정은 관리자에 의해 재활성화될 수 있음(정책 및 권한에 따라).
  • 익명화된 사용자 계정은 재활성화가 불가능함.
  • 게스트 계정 자발적 탈퇴 규칙
    • 게스트 계정이 자발적으로 탈퇴를 요청하면 status를 INACTIVE로 변경하고 deletedAt을 설정함.
    • 자발적 탈퇴 시 기존 게스트 만료 타이머(TimeMachine 스케줄)는 해제됨.
    • 비활성화된 게스트 계정은 기존 데이터 보존 정책에 따라 삭제/익명화 처리됨.
  • 게스트 만료 및 정리 규칙
    • 게스트 계정이 만료되면 Access Token 및 Refresh Token을 모두 폐기하고, 게스트 그룹/플랜에서 제거해야 함.
    • 게스트 계정이 만료된 상태에서 7일 이상 업그레이드가 이루어지지 않으면 자동으로 삭제 또는 익명화 프로세스를 시작해야 함.
    • 게스트 계정 만료/정리 이벤트는 GuestAccountLifecycle 로그에 기록되어야 하며, 감사 목적으로 Audit 도메인에도 통지해야 함.

1.5 익명화 및 데이터 삭제 처리 규칙​

  • 사용자 데이터 삭제 프로세스는 전체 시스템에 걸쳐 도메인별로 일관되게 수행되어야 함.
  • 삭제 프로세스는 상태 추적 메커니즘을 통해 모니터링되어야 함:
    • PENDING: 요청 접수 대기 중
    • IN_PROGRESS: 처리 진행 중
    • COMPLETED: 성공적으로 완료
    • FAILED: 처리 실패
    • PARTIALLY_COMPLETED: 일부 도메인에서만 완료
  • 각 도메인별 삭제 상태는 개별적으로 추적되어야 함.
  • 실패한 삭제 프로세스는 관리자에 의해 재시도될 수 있어야 함.
  • 익명화 처리 시 다음 규칙이 적용됨:
    • 모든 개인식별정보(PII)는 식별 불가능한 값으로 대체되어야 함.
    • 이메일은 난수화된 고유 값으로 대체되어야 함.
    • 이름, 연락처 등 식별 가능한 정보는 모두 제거되어야 함.
    • 익명화된 사용자는 로그인이 불가능해야 함.
    • 각 익명화 프로세스는 고유한 anonymizationId로 식별되어야 함.
    • 다른 도메인에서의 익명화를 추적하기 위해 anonymizationId가 공유되어야 함.
  • 익명화 및 삭제 관련 모든 작업은 감사 로그에 기록되어야 함 ([Audit 도메인] 의존).

2. 사용자 프로필 관리 규칙​

2.1 프로필 정보 규칙​

  • 사용자 이름 정보는 필수적으로 관리되어야 함.
  • 사용자 선호 언어 설정(예: 'ko', 'en', 'de')은 관리되어야 함.
  • 사용자 타임존 설정(예: 'Asia/Seoul', 'Europe/Berlin')은 관리되어야 함.
  • 프로필 정보는 새로운 필드 추가에 유연한 구조여야 함 (확장성).

2.2 프로필 접근 규칙​

  • 사용자는 자신의 프로필 정보(이름, 선호 언어, 타임존 등)를 조회하고 수정할 수 있어야 함 (프론트엔드 제공).

3. 사용자 역할 및 권한 규칙 (IAM 도메인 책임)​

3.1 역할/권한 정의 규칙​

  • 시스템 역할(System Admin, IAM Admin, Service Account, Regular User 등)은 IAM 도메인에서 정의하고 관리함.
  • 세부 권한(Permission) 및 정책(Policy)은 IAM 도메인에서 정의하고 평가함.

3.2 역할 할당 규칙​

  • 사용자에게 역할을 할당하고 관리하는 로직은 IAM 도메인의 책임임.

3.3 접근 제어 규칙 (다차원 권한 계산)​

  • 역할 기반 접근 제어(RBAC)는 IAM 도메인에서 처리함.
  • User 도메인은 사용자와 Group/Plan의 연결 정보를 제공함.
  • 최종 권한은 그룹 권한과 플랜 권한의 교집합으로 결정됨:
    • 그룹 권한: User → Group → Role → Permission (조직/기능적 권한)
    • 플랜 권한: User → Plan → Role → Permission (서비스 수준 권한)
    • 최종 권한: GroupPermissions ∩ PlanPermissions
  • 그룹과 플랜은 서로 다른 차원의 권한을 제공하며, 두 권한 집합 모두를 만족해야 접근이 허용됨.

4. 사용자 주기(Cycle) 관리 규칙 (User 도메인 책임)​

4.1 주기 정보 관리 규칙​

  • 사용자별 치료 또는 학습 주기(UserCycle) 정보(시작일, 종료일, 상태)는 User 도메인에서 관리되어야 함.
  • 사용자 주기의 상태(ACTIVE, COMPLETED, CANCELLED, PENDING)는 사용자 계정 상태와 별개로 관리됨.
    • (참고: 여기서 정의된 주기 상태는 사용자가 치료 활동을 일시 정지하는 것과는 별개로 관리됩니다. 치료 활동 일시 정지는 5번 섹션을 참조하십시오.)
  • 한 사용자는 여러 주기를 가질 수 있음 (필요시).
  • UserCycle 시작 이후, 서비스 이용이 활성 상태였던 날짜 수를 기준으로 '치료 주기 일차'(dayIndex)가 계산되어야 함. 이 값은 활성 치료일 기준의 상대적인 일차임.
  • 치료 주기 일차 계산 시, 누적된 총 치료 활동 일시 정지 기간은 제외되어야 함 (이를 위해 상세한 정지 이력(5.2 참조)이 필요함).
  • DST(일광절약시간) 고려: 일차 계산 시 사용자 타임존의 DST 전환을 정확히 반영해야 함
    • DST 전환으로 인한 타임존 오프셋 변화 자동 처리
    • 하루 길이 변화(23시간 또는 25시간)를 고려한 정확한 날짜 계산
    • 타임존별 DST 규칙에 따른 자동 보정
  • 사용자는 동시에 여러 개의 ACTIVE 상태 UserCycle을 가질 수 없음.
  • UserCycle의 상태 전이 규칙(PENDING -> ACTIVE -> COMPLETED/CANCELLED)을 준수해야 함.

5. 치료 활동 일시 정지 및 서비스 이용 기간 관리 규칙​

5.1 이용 기간 설정 및 만료 규칙​

  • 사용자의 서비스 이용 기간은 할당된 Plan(Plan 도메인 책임)에 따라 설정되어야 함 (예: Therapeutic Plan은 90일).
  • 사용자의 서비스 이용 만료일은 관리되어야 하며, Plan 정의에 따라 계산되어야 함.

5.2 치료 활동 일시 정지 및 재개 규칙​

  • 사용자는 **치료 활동을 일시 정지(suspend)**하고 재개(resume)할 수 있어야 함.
    • 이 정지 상태를 추적하기 위한 별도의 정보(예: User 엔티티의 isSuspended 플래그, UserSuspensionHistory 레코드 등)가 관리되어야 함.
  • 치료 활동 일시 정지 및 재개 요청 처리 로직이 필요함.
  • 치료 활동 일시 정지 및 재개 이력은 각 정지 건별로 시작 및 종료 시점을 포함하여 상세하게 관리되어야 함 (UserSuspensionHistory 엔티티).
  • 서비스 이용 만료일 계산 시, 치료 활동이 일시 정지된 동안의 기간은 제외되어야 함 ((5.2에서 관리하는 상세 이력 정보를 바탕으로 계산된 총 정지 기간 반영)).
  • 사용자의 남은 서비스 이용 기간 정보는 치료 활동 일시 정지 기간을 제외하고 제공되어야 함.

5.3 기능 접근 제한 규칙​

  • 치료 활동이 일시 정지된 동안에는 (5.2에서 관리하는 이력 정보 또는 User 엔티티의 isSuspended 플래그 상태에 따라) Plan에 정의된 대부분의 핵심 치료 기능(예: 기록 생성, 프로그램 진행 등 dayIndex 증가와 연관된 기능) 접근이 제한되어야 함 (읽기 전용 접근 등 일부 필수 기능 제외, 구체적 범위는 IAM 도메인 정책 연계).
  • 서비스 이용 기간이 만료된 사용자(실제 이용일 기준 만료일 초과)에 대해서도 접근 가능한 기능 범위가 제한되어야 함 (구체적 범위는 IAM 도메인 정책 연계, 예: Limited Access Plan으로 전환).
  • 기능 제한 상태에서도 사용자는 자신의 과거 기록 열람은 가능해야 함.

5.4 일시 정지 기간 중 날짜 이동 규칙 (TimeMachine 연동)​

이 규칙들은 TimeMachine 도메인에서 가상 시간을 설정할 때 User 도메인의 데이터를 참조하여 적용될 수 있는 규칙임.

  • 기능 정의: TimeMachine 기능을 통해 사용자의 가상 시간을 특정 치료 활동 일시 정지 기간 내의 N번째 날짜로 설정할 수 있어야 함 (요구사항 1.6.11 참조).
  • 목표 날짜 계산: 목표 날짜는 다음 규칙에 따라 계산됨:
    1. 사용자의 UserSuspensionHistory 이력을 suspendedAt 기준으로 정렬하여 요청된 순서(suspensionSequence)의 정지 기록을 찾음.
    2. 해당 정지 기록의 suspendedAt 날짜를 기준으로, 요청된 일수(dayWithinSuspension - 1)만큼 더하여 목표 날짜를 결정함.
  • 유효성 검증:
    • 요청된 suspensionSequence가 사용자의 실제 정지 이력 내 유효한 순서여야 함.
    • 요청된 dayWithinSuspension은 1 이상이어야 함.
    • 계산된 목표 날짜는 해당 정지 기간의 실제 범위 내에 있어야 함 (즉, 해당 UserSuspensionHistory 레코드의 suspendedAt 이후이고, resumedAt이 존재한다면 그 이전이어야 함).
  • 시간 설정 시각: 설정되는 시간은 계산된 목표 날짜의 시작 시각 (00:00:00.000)이며, 사용자의 개별 Timezone ID가 적용되어야 함.
  • 권한: 이 기능은 테스터 등 특정 권한을 가진 사용자만 TimeMachine 인터페이스를 통해 사용할 수 있어야 함 (IAM 도메인 연계).
  • 데이터 롤백: 이 방식으로 시간을 과거로 설정하는 경우에도 기존 데이터 롤백 규칙이 적용됨 (TimeMachine 도메인 책임).

6. 테스터 관리 규칙 (IAM 도메인 책임)​

6.1 테스터 지정 규칙​

  • 특정 사용자는 Group 도메인에서 관리하는 그룹(예: Testers 그룹) 할당을 통해 '테스터'로 지정될 수 있음.
  • 테스터 지정 및 해제는 Group 도메인의 그룹 할당을 통해 이루어지며, 지정된 권한을 가진 사용자만 가능함.
  • User 도메인은 Group 도메인으로부터 사용자의 그룹 정보를 조회하여 테스터 여부를 판단할 수 있음.

7. 사용자 계정 유형 관리 규칙​

7.1 일반 사용자 계정 규칙​

  • User 도메인은 일반 사용자 계정(USER 타입)만을 관리함.
  • 모든 일반 사용자 계정은 다음 특징을 가져야 함:
    • 모바일 앱을 통한 서비스 이용
    • 이메일 인증 및 프로필 관리 필요
    • Plan 할당을 통한 치료 주기 관리
    • 개인정보 보호 및 GDPR 준수

7.2 Service Account 관리 위임​

  • Service Account 관리: 시스템 간 통신을 위한 Service Account는 IAM 도메인에서 관리됩니다.
  • User 도메인은 Service Account와 관련된 비즈니스 규칙을 정의하지 않습니다.

8. 개인정보 보호 및 규정 준수 규칙 (GDPR 등)​

8.1 규정 준수 규칙​

  • 시스템은 GDPR, HIPAA 등 관련 개인정보 보호 규정을 준수해야 함.
  • 개인 식별 정보(PII)는 암호화하여 저장해야 함.
  • 사용자 데이터 접근은 최소 권한 원칙에 따라 제어되어야 함.

8.2 사용자 권리 규칙​

  • 사용자의 데이터 접근 권한 요청 처리 가능해야 함.
  • 사용자의 데이터 삭제 요청("잊힐 권리") 처리 및 관련 데이터 익명화/삭제 가능해야 함 (1.4 및 1.5 규칙 참조).
  • 사용자 데이터 익명화 작업은 각 도메인에서 일관된 방식으로 수행되어야 함.
  • 사용자 데이터 익명화/삭제 요청은 추적 가능하고 감사 가능한 방식으로 처리되어야 함.
  • 사용자 데이터 접근/삭제 요청 처리 결과는 명확하게 기록되고 필요시 보고되어야 함.

8.3 데이터 처리 로그 규칙​

  • 사용자 데이터 처리 활동(생성, 조회, 수정, 삭제 등)에 대한 로그는 기록 및 관리되어야 함 ([Audit 도메인] 의존).
  • 특히 개인정보 처리 관련 작업(접근, 수정, 삭제 요청 처리 등)에 대한 감사 로그는 상세히 기록되어야 함 ([Audit 도메인] 의존).

8.4 데이터 보존 규칙​

  • 사용자 데이터는 관련 법규 및 정책에 따라 적절한 기간 동안 보존되어야 함.
  • 비활성화된 계정은 정책에 따라 일정 기간(예: 30일, 60일 등) 동안 보존 후 삭제 또는 익명화됨.
  • 익명화 처리된 데이터에는 보존 종료일(dataRetentionEndDate)이 기록되어야 함.
  • 보존 종료일에 도달한 익명화 데이터는 정책에 따라 추가 처리(예: 통계 목적으로 분리 저장, 완전 삭제 등)될 수 있음.
  • 개인정보 보존 기간은 사용자 동의 내용과 적용 가능한 규정에 따라 결정되어야 함.

9. 성능 규칙​

  • 사용자 정보 조회 API 평균 응답 시간: 100ms 이내 목표.
  • 사용자 정보 수정 API 평균 응답 시간: 200ms 이내 목표.
  • 시스템은 최소 10,000명 이상의 사용자 정보를 효율적으로 관리할 수 있는 구조여야 함.

10. 보안 규칙​

  • 사용자 비밀번호 등 민감 정보 해싱 저장은 Auth 도메인 책임임.
  • 개인 식별 정보(PII)는 암호화 저장 필수 (8.1 규칙 참조).
  • 모든 API 요청은 적절한 인증 및 인가 절차를 거쳐야 함.
  • 사용자 데이터 접근은 최소 권한 원칙 적용 (8.1 규칙 참조).
  • 개인정보 처리 작업에 대한 감사 로그 기록 필수 ([Audit 도메인] 의존, 8.3 규칙 참조).

11. 확장성 규칙​

  • 시스템은 사용자 수 증가에 대응하여 수평 확장이 가능한 구조여야 함.
  • 사용자 프로필 정보는 필드 추가에 유연한 구조여야 함 (2.1 규칙 참조).
  • 다국어 지원(i18n)을 위한 기반 구조를 고려해야 함.

12. 가용성 규칙​

  • 사용자 관련 핵심 기능(조회, 상태 확인 등)은 99.95% 이상의 가용성을 목표로 함.
  • 의존 시스템 장애 시 읽기 작업 영향을 최소화하기 위한 캐싱 전략 고려.

13. 기술 제약 규칙​

  • 개발 언어 및 프레임워크: TypeScript, NestJS.
  • 데이터베이스: PostgreSQL.
  • 민감 정보 저장 스키마: private.

14. 의존성 규칙​

14.1 내부 도메인 의존성​

  • Auth: 인증, 비밀번호 관리, 이메일 인증, 동의 관리.
  • Access Code: 회원 가입 시 코드 검증.
  • Sleep: 사용자 식별 정보 및 UserCycle 상태/정보 사용 (예: 해당 주기에 맞는 수면 데이터 기록/조회).
  • Learning: 사용자 식별 정보 및 UserCycle 상태/정보 사용 (예: 해당 주기에 맞는 학습 콘텐츠 제공/진행).
  • Group: 사용자-그룹 할당 관리, 그룹 정보 참조. 사용자는 하나 이상의 그룹에 속해야 함.
  • Plan: 사용자-플랜 할당 관리, 플랜 정보 참조. 사용자는 정확히 하나의 플랜에 속해야 함.
  • IAM: 역할, 권한, 정책 정의/관리/평가. 그룹 및 플랜 기반 권한의 교집합을 계산하여 최종 권한 결정. 서비스 이용 기간 및 기능 접근 제한 정책 연계.
  • Audit: 사용자 활동, 계정 상태 변경, 치료 활동 정지/재개, 데이터 처리 활동 및 개인정보 관련 감사 로그 기록. 특히 데이터 삭제/익명화 프로세스, 데이터 접근 요청, GDPR 관련 처리 등 중요 작업의 로깅.
  • TimeMachine: User 도메인의 정보(주기 시작일, 정지 이력 등)를 참조하여 dayIndex 기반 및 일시 정지 기간 내 날짜 기반 가상 시간 설정 기능을 구현.

14.2 외부 의존성​

  • (현재 명시된 외부 의존성 없음)

15. 변경 이력​

버전날짜작성자변경 내용
0.1.02025-04-18bok@weltcorp.com최초 작성
0.2.02025-05-08bok@weltcorp.com사용자 데이터 삭제 및 익명화 관련 규칙 추가: 익명화 및 데이터 삭제 처리 규칙(1.5), 데이터 보존 규칙(8.4) 추가 및 기존 규칙 상세화
0.3.02025-06-14bok@weltcorp.comService Account 관련 규칙을 IAM 도메인으로 이관, 7절을 일반 사용자 계정 관리 규칙으로 변경
0.4.02025-07-16bok@weltcorp.comGroup-Plan 독립성 확보: 1.1 계정 생성 규칙 수정(Group/Plan 독립 할당), 3.3 다차원 권한 계산 모델 도입, 14.1 의존성에 Group/Plan 도메인 추가
0.5.02025-10-27bok@weltcorp.com게스트 계정 타입/만료/Step-up 관련 규칙 추가 (1.1, 1.3, 1.4절 보강)
0.6.02025-12-17bok@weltcorp.com게스트 계정 자발적 탈퇴 규칙 추가 (1.4절) - Soft Delete 방식 적용, 만료 타이머 해제