본문으로 건너뛰기

User 도메인 요구사항

1. 기능 요구사항​

1.1 사용자 계정 관리​

백엔드 요구사항​

  • USR-FR-BE-001: 시스템은 사용자 계정을 생성할 수 있어야 한다.
    • 모바일 앱을 통한 회원 가입 시 Access Code 유효성 검증이 필요하다. (Access Code 도메인 의존)
    • 회원 가입 시 이메일 인증 과정을 거쳐야 한다. (Auth 도메인 의존)
    • 가입 시 필요한 동의 항목 수집 및 처리는 Auth 도메인에서 담당한다. (Auth 도메인 의존)
    • 게스트 온보딩 경로에서는 Access Code 및 이메일 인증을 요구하지 않으며, 약관 동의와 디바이스 인증만으로 계정을 발급해야 한다.
  • USR-FR-BE-002: 시스템은 사용자 계정 정보를 조회할 수 있어야 한다. (ID, 이메일, 상태, 프로필 등)
  • USR-FR-BE-003: 시스템은 사용자 계정 정보를 수정할 수 있어야 한다. (프로필 정보 등)
    • 이메일, 비밀번호 변경은 Auth 도메인 책임이다.
  • USR-FR-BE-004: 시스템은 사용자 계정을 비활성화(탈퇴)할 수 있어야 한다. (GDPR 등 규정 준수)
  • USR-FR-BE-005: 시스템은 비활성화된 계정은 즉시 익명화 하고 일정 기간 후 삭제할 수 있어야 한다. (GDPR 등 규정 준수)
  • USR-FR-BE-006: 시스템은 모든 사용자가 생성 또는 초대 시점에 반드시 하나 이상의 그룹(Group)에 속하도록 보장해야 한다. (그룹의 상세 정의 및 관리는 Group 도메인 책임)
  • USR-FR-BE-007: 시스템은 모든 사용자(USER 타입)가 생성 시점에 반드시 하나의 Plan에 직접 연결되도록 보장해야 한다. (Plan의 상세 정의, 유효성 검증, 할당 관리는 Plan 도메인 책임). 플랜은 그룹과 독립적으로 관리되며, 사용자는 그룹 변경 없이 플랜을 변경할 수 있다. 이는 특히 환자(Patient) 역할 사용자의 서비스 수준(치료 기간, 기능 접근 범위 등)을 정의하는 데 중요하다.
  • USR-FR-BE-074: 시스템은 사용자 계정 타입을 GUEST와 REGISTERED로 구분하고 생명주기를 관리해야 한다.
    • 게스트 생성 시 기본 그룹(patients.guest.*)과 게스트 플랜을 자동 할당해야 한다.
    • 계정 타입이 GUEST에서 REGISTERED로 전환될 때 기존 그룹/플랜 할당의 무결성을 검증하고 필요한 재배치를 수행해야 한다.
    • 타입 전환 이벤트는 Auth, IAM, Plan, Group 도메인으로 브로드캐스트되어 교차 도메인 상태를 동기화해야 한다.
  • USR-FR-BE-075: 시스템은 게스트 계정의 데이터 보존 주기를 분리 관리해야 한다.
    • 게스트 계정은 마지막 활동 시점으로부터 30일 이후 자동 삭제 또는 익명화 대상이 되어야 한다.
    • TimeMachineService를 사용하여 게스트 만료 타이머를 예약하고, 만료 전 업그레이드 유도 알림을 발행해야 한다.
    • 게스트 삭제 시 수집된 동의 이력과 디바이스 바인딩 데이터를 함께 정리해야 한다.
  • USR-FR-BE-076: 시스템은 게스트 계정의 자발적 탈퇴(비활성화) 요청을 처리할 수 있어야 한다.
    • 게스트 계정도 일반 사용자와 동일한 DELETE /v1/users/me API를 통해 탈퇴를 요청할 수 있어야 한다.
    • 자발적 탈퇴 시 Soft Delete 방식으로 처리하며, status를 INACTIVE로 변경하고 deletedAt을 설정해야 한다.
    • 자발적 탈퇴 시 기존 게스트 만료 타이머(TimeMachine 스케줄)는 해제되어야 한다.
    • 비활성화된 게스트 계정은 기존 데이터 보존 정책에 따라 후속 처리(삭제/익명화)되어야 한다.
  • USR-FR-BE-008: 시스템은 개발 및 테스트 환경에서 사용자 데이터를 완전히 삭제할 수 있는 기능을 제공해야 한다. (데이터베이스에서 물리적으로 삭제)
    • 이 기능은 개발/테스트 환경에서만 사용 가능해야 하며, 프로덕션 환경에서는 적절한 보안 제한이 있어야 한다.
    • 사용자 데이터 삭제 시 관련된 모든 도메인의 연관 데이터에 대한 처리 방안을 명확히 정의해야 한다.
    • 이 기능은 사용자의 자발적 탈퇴(1.1.4)와는 구분되며, 주로 개발 및 테스트 과정에서 데이터 초기화를 위해 사용된다.

1.2 사용자 프로필 관리​

백엔드 요구사항​

  • USR-FR-BE-009: 시스템은 사용자의 선호 언어 설정을 저장하고 관리해야 한다. (예: 'ko', 'en', 'de')
  • USR-FR-BE-010: 시스템은 사용자의 타임존 설정을 저장하고 관리해야 한다. (예: 'Asia/Seoul', 'Europe/Berlin')
  • USR-FR-BE-011: 시스템은 기타 필요한 사용자 프로필 정보를 확장 가능하게 관리할 수 있어야 한다.

프론트엔드 요구사항​

TBD

1.3 사용자 상태 관리​

백엔드 요구사항​

  • USR-FR-BE-012: 시스템은 사용자 계정 자체의 상태를 관리해야 한다. 이 상태는 계정의 유효성(로그인 가능 여부, 활성화 여부 등)을 나타내며, 특정 UserCycle의 상태와는 독립적이다:
    • ACTIVE: 활성 상태. 서비스 이용 가능.
    • INACTIVE: 비활성 상태. 사용자의 자발적 탈퇴 요청 등으로 서비스 이용 불가. 이 상태 후 실제 데이터 삭제/익명화 처리될 수 있음 (요구사항 1.1.5 참조).
    • LOCKED: 일시 잠김 상태. 로그인 실패 등 특정 조건으로 인해 일시적으로 서비스 접근 제한.
    • PENDING: 활성화 대기 상태. 이메일 인증 등 계정 활성화 절차 필요.
    • SUSPENDED: 이용 정지 상태. 정책 위반 등으로 인해 관리자가 설정한 기간 동안 서비스 이용 제한.
    • BANNED: 영구 정지 상태. 심각하거나 반복적인 정책 위반으로 인해 영구적으로 서비스 접근 차단.
    • (참고: 여기서 정의된 계정 상태는 사용자가 자발적으로 치료 활동을 일시 정지하는 것과는 별개로 관리됩니다. 치료 활동 일시 정지는 1.6 섹션을 참조하십시오.)
  • USR-FR-BE-013: 시스템은 계정 상태 변경 이력을 추적할 수 있어야 한다.
  • USR-FR-BE-014: 시스템은 특정 조건(예: 연속 로그인 실패, 관리자 조치)에 따라 계정 상태를 자동으로 변경할 수 있어야 한다. (Auth 도메인 연관)

1.4 사용자 역할 및 권한 관리​

백엔드 요구사항​

  • USR-FR-BE-015: 시스템은 다양한 사용자 역할(System Admin, IAM Admin, Service Account, Regular User 등)을 정의하고 관리할 수 있어야 한다. (역할의 상세 정의, 생성, 권한 매핑 등은 IAM 도메인 책임)

  • USR-FR-BE-016: 시스템은 사용자에게 특정 역할을 할당하고 관리할 수 있어야 한다. (역할 할당의 세부 로직 및 제약 조건은 IAM 도메인 참조)

  • USR-FR-BE-017: 시스템은 역할 기반 접근 제어(RBAC)를 지원해야 한다. (세부 권한(Permission) 및 정책(Policy) 정의, 평가는 IAM 도메인 책임)

  • USR-FR-BE-018: 사용자의 최종 권한은 그룹(Group) 기반 권한과 플랜(Plan) 기반 권한의 교집합으로 결정된다. IAM 도메인은 두 경로의 권한을 모두 계산하여 최종 권한을 도출한다:

    • 그룹 기반 권한: User → Group → Role → Permission (조직/기능적 권한)
    • 플랜 기반 권한: User → Plan → Role → Permission (서비스 수준 권한)
    • 최종 권한: 그룹 권한 ∩ 플랜 권한 (두 권한 집합의 교집합)

    참고: 그룹(Group)과 플랜(Plan)의 독립적 역할:

    • 그룹(Group): 사용자를 조직적, 기능적으로 분류 (예: 서울병원, 의료진, 연구팀). 사용자의 소속과 역할을 나타낸다.
    • 플랜(Plan): 서비스 이용 수준과 기능 범위를 정의 (예: Therapeutic Plan, Limited Access Plan). 사용자가 이용할 수 있는 서비스의 등급을 나타낸다.
    • 독립성: 그룹과 플랜은 서로 독립적으로 변경 가능하며, 한쪽 변경이 다른 쪽에 영향을 주지 않는다.

1.4.5 사용자 플랜 유형 (Plan Types)​

  • 시스템은 다음과 같은 사용자 플랜 유형을 지원할 수 있다. (플랜의 상세 정의, 권한 매핑, 할당 로직은 IAM 도메인 책임) 이 플랜들은 주로 Patient 역할 사용자 또는 관련 사용자(예: 체험 사용자)에게 적용된다.
    • 치료 플랜 (Therapeutic Plan): 불면증 진단을 받은 사용자를 대상으로 하며, 앱의 모든 주요 기능을 사용할 수 있다. (일반적으로 90일 이용 기간 적용 대상)
    • 제한 플랜 (Limited Access Plan): 치료 플랜 기간(예: 90일) 만료 후 사용자를 위한 플랜으로, 기능 사용이 제한된다. (예: 과거 기록 열람 가능, 신규 기록/처방 불가)
    • 샘플 플랜 (Sample Plan): 불면증 진단을 받지 않은 사용자가 앱 기능을 체험할 수 있는 플랜으로, 모든 주요 기능을 사용할 수 있다. (이용 기간 제한 가능성 있음 - TBD)
    • 의료진 플랜 (Clinician Plan): 의료 전문가를 위한 플랜으로, 환자 관리 등 특정 기능 접근 권한을 가질 수 있다.

1.5 사용자 주기(Cycle) 관리​

백엔드 요구사항​

  • USR-FR-BE-019: User 도메인은 사용자의 치료 또는 학습 주기(UserCycle) 정보를 관리할 수 있어야 한다. (주기의 세부 활동 내용은 각 관련 도메인에서 관리)
  • USR-FR-BE-020: 사용자 주기 정보에는 시작일, 종료일, 그리고 해당 주기의 진행 상태가 포함되어야 한다. 이 상태는 User 계정 상태와는 별개로 관리된다: (예: ACTIVE, COMPLETED, CANCELLED)
    • (참고: 여기서 정의된 주기 상태는 사용자가 치료 활동을 일시 정지하는 것과는 별개로 관리됩니다. 치료 활동 일시 정지는 1.6 섹션을 참조하십시오.)
  • USR-FR-BE-021: 시스템은 사용자별로 여러 주기를 가질 수 있도록 지원해야 한다. (필요시)
  • USR-FR-BE-022: 시스템은 UserCycle 시작 이후, 서비스 이용이 활성 상태였던 날짜 수를 기준으로 '치료 주기 일차'(dayIndex)를 계산할 수 있어야 한다.
  • USR-FR-BE-023: 치료 주기 일차(dayIndex) 계산 시, 치료 활동을 일시 정지 기간은 제외되어야 한다. 이를 위해 상세한 정지 이력 정보(1.6.6 참조, UserCycleSuspensionHistory)가 필요하다.

프론트엔드 요구사항​

TBD

1.6 치료 활동 일시 정지 및 서비스 이용 기간 관리​

백엔드 요구사항​

  • USR-FR-BE-024: 시스템은 사용자에게 할당된 Plan(IAM 도메인 책임)에 정의된 서비스 이용 기간을 설정해야 한다. (예: Therapeutic Plan은 일반적으로 가입 시점부터 90일)
  • USR-FR-BE-025: 시스템은 사용자의 서비스 이용 만료일을 관리해야 한다. (만료일은 Plan 정의에 따라 계산됨)
  • USR-FR-BE-026: 시스템은 사용자가 **치료 활동을 일시 정지(suspend)**하고 재개(resume)할 수 있도록 지원해야 하며, 이 정지 상태를 추적하기 위한 별도의 정보(예: UserCycle의 정지 여부 플래그, 정지/재개 시점 기록 등)를 관리해야 한다.
  • USR-FR-BE-027: 시스템은 사용자의 치료 활동을 일시 정지 요청을 처리할 수 있어야 한다.
  • USR-FR-BE-028: 시스템은 일시 정지된 치료 활동의 재개 요청을 처리할 수 있어야 한다.
  • USR-FR-BE-029: 시스템은 치료 활동을 일시 정지 및 재개 이력을 상세하게(각 정지 건별 시작 및 종료 시점 포함) 관리해야 한다. (UserCycleSuspensionHistory 테이블)
  • USR-FR-BE-030: 시스템은 치료 활동이 일시 정지된 동안에는 ((1.6.6에서 관리하는 이력 정보 또는 UserCycle.isSuspended 상태에 따라) 읽기 전용 접근 등 일부 필수 기능을 제외하고 Plan에 정의된 대부분의 핵심 치료 기능 접근을 제한해야 한다.
    • 예시: 정지 기간 동안에는 새로운 수면 기록 생성, 설문 참여, 학습 콘텐츠 진행 등 dayIndex 진행과 관련된 주요 데이터 입력 및 상호작용 기능이 제한될 수 있다. (기록 조회, 일반 콘텐츠 열람 등은 가능)
    • 제한되는 기능의 구체적인 범위는 관련 도메인 설계 완료 후 추후 정의되며, IAM 도메인의 정책을 통해 최종 관리될 수 있다.
  • USR-FR-BE-031: 시스템은 치료 활동이 일시 정지된 동안에는 (1.6.6에서 관리하는 UserCycleSuspensionHistory 정보를 바탕으로 계산된 총 정지 기간을 반영하여) 만료일 계산에서 해당 기간을 제외해야 한다.
  • USR-FR-BE-032: 시스템은 사용자의 남은 서비스 이용 기간 정보를 제공할 수 있어야 한다. ((1.6.6에서 관리하는 UserCycleSuspensionHistory 정보를 바탕으로 계산된) 치료 활동을 일시 정지 기간 제외)
  • USR-FR-BE-033: 시스템은 서비스 이용 기간이 만료된 사용자(실제 이용일 기준 91일차부터)에 대해 접근 가능한 기능 범위를 제한해야 한다. (제한되는 기능의 구체적인 범위는 추후 정의 필요 - TBD)
    • 기능 제한 상태에서도 사용자는 자신의 과거 기록(예: 수면 기록, 학습 기록 등)은 계속 열람할 수 있어야 한다.
    • 이 기능 제한은 IAM 도메인의 Plan/Role/Permission과 연계하여 구현될 수 있다. (예: 기간 만료 시 'Limited Access Plan'으로 자동 변경)
  • 1.6.11 (신규): 시스템은 사용자의 가상 시간을 특정 치료 활동 일시 정지 기간 내의 N번째 날짜로 설정하는 기능을 제공해야 한다. (TimeMachine 기능)
    • 이 기능은 TimeMachine 도메인과 연계되어 구현될 수 있다.
    • 시간 설정 시, 사용자의 정지 이력(UserCycleSuspensionHistory)을 참조하여 N번째 정지 기간과 해당 기간 내의 N번째 날짜를 정확히 계산해야 한다.
    • 설정된 시간은 해당 날짜의 시작(00:00, 사용자 타임존 기준)이어야 한다.
    • 이 기능은 테스터 등 특정 권한을 가진 사용자만 사용할 수 있어야 한다.

프론트엔드 요구사항​

TBD

1.7 개인정보 보호 및 규정 준수​

백엔드 요구사항​

  • USR-FR-BE-034: 시스템은 GDPR 및 관련 개인정보 보호 규정을 준수해야 한다.
  • USR-FR-BE-035: 시스템은 사용자의 데이터 접근 권한 요청을 처리할 수 있어야 한다.
  • USR-FR-BE-036: 시스템은 사용자의 데이터 삭제 요청("잊힐 권리")을 처리하고 관련 데이터를 익명화하거나 삭제할 수 있어야 한다.
  • USR-FR-BE-037: 시스템은 사용자 데이터 처리 활동에 대한 로그를 기록하고 관리해야 한다. ([Audit 도메인] 의존)

1.8 사용자 계정 유형 구분​

백엔드 요구사항​

  • USR-FR-BE-038: 시스템은 일반 사용자 계정(USER 타입)을 관리할 수 있어야 한다.
    • 모바일 앱을 통해 서비스를 이용하는 실제 사용자 계정
    • 이메일 인증, 프로필 관리, 치료 주기 관리 등이 필요한 계정
  • USR-FR-BE-039: 시스템은 일반 사용자 계정 생성 시 사용자 유형을 USER로 지정해야 한다.
  • USR-FR-BE-040: 시스템은 일반 사용자에게 적용되는 정책과 제약 조건을 관리할 수 있어야 한다.
    • 비밀번호 정책, 이메일 인증 요구사항
    • Plan 할당 및 치료 주기 관리
    • 개인정보 보호 및 GDPR 준수

참고사항​

  • Service Account 관리: 시스템 간 통신을 위한 Service Account는 IAM 도메인에서 관리됩니다.

2. 비기능 요구사항​

2.1 성능​

  • USR-NFR-001: 사용자 정보 조회 API는 평균 100ms 이내 응답 시간을 보장해야 한다.
  • USR-NFR-002: 사용자 정보 수정 API는 평균 200ms 이내 응답 시간을 보장해야 한다.
  • USR-NFR-003: 시스템은 최소 10,000명 이상의 사용자 정보를 효율적으로 관리할 수 있어야 한다.

2.2 보안​

  • USR-NFR-004: 사용자 비밀번호 등 민감 정보는 안전하게 해싱하여 저장해야 한다 (Auth 도메인 책임).
  • USR-NFR-005: (공통 정책 참조) 개인 식별 정보(PII) 암호화는 Platform 표준을 따른다 - PLT-SEC-001, PLT-SEC-003
  • USR-NFR-006: API 요청 시 적절한 인증 및 인가를 거쳐야 한다.
  • USR-NFR-007: 사용자 데이터 접근은 최소 권한 원칙에 따라 제어되어야 한다.
  • USR-NFR-008: 개인정보 처리 관련 작업에 대한 감사 로그를 기록해야 한다. ([Audit 도메인] 의존)

2.3 확장성​

  • (공통 정책 참조) 확장성 원칙은 Platform 도메인 기준을 따른다: PLT-NFR-001
  • USR-NFR-009: 시스템은 사용자 수 증가에 따라 수평적으로 확장 가능해야 한다.
  • USR-NFR-010: 사용자 프로필 정보는 새로운 필드를 쉽게 추가할 수 있는 유연한 구조를 가져야 한다.
  • USR-NFR-011: 다양한 국가 및 언어 지원을 위한 기반을 마련해야 한다 (i18n).

2.4 가용성​

  • (공통 정책 참조) 가용성/복구/백업/무중단 배포는 Platform 도메인 기준을 따른다: PLT-NFR-004, PLT-NFR-005, PLT-NFR-006, PLT-NFR-007
  • USR-NFR-012: 사용자 관련 핵심 기능(조회, 상태 확인 등)은 99.95% 이상의 가용성을 보장해야 한다.
  • USR-NFR-013: 데이터베이스 등 의존 시스템 장애 시에도 읽기 작업은 가능한 한 영향을 받지 않도록 캐싱 전략을 고려해야 한다.

3. 제약사항​

3.1 기술적 제약​

  • USR-CR-001: 시스템은 NestJS 프레임워크 및 TypeScript를 사용해야 한다.
  • USR-CR-002: 시스템은 PostgreSQL 데이터베이스를 사용해야 한다.
  • USR-CR-003: 사용자 관련 민감 정보는 private 스키마에 저장해야 한다.

3.2 규제 제약​

  • USR-CR-004: GDPR, HIPAA 등 관련 법규 및 규제를 준수해야 한다.

4. 가정사항​

4.1 시스템 환경​

  • USR-AR-001: 시스템은 마이크로서비스 아키텍처 내에서 다른 도메인과 상호작용한다.
  • USR-AR-002: 인증 및 인가 처리는 주로 Auth 도메인에서 담당한다.

4.2 사용자 환경​

  • USR-AR-003: 사용자는 주로 모바일 앱을 통해 서비스와 상호작용한다.
  • USR-AR-004: 관리자는 별도의 관리 도구를 통해 사용자 정보를 관리한다.

5. 의존성​

5.1 내부 의존성​

  • USR-DR-001: Auth 도메인: 사용자 인증, 비밀번호 관리, 이메일 인증, 동의 관리 등 의존.
  • USR-DR-002: Access Code 도메인: 회원 가입 시 코드 검증, 사용자 유형별 권한 정의 참조 의존.
  • USR-DR-003: Sleep 도메인: 사용자의 수면 관련 데이터 관리. (UserCycle 정보는 User 도메인에서 제공받아 사용)
  • USR-DR-004: Learning 도메인: 사용자 식별 정보 의존. (UserCycle 정보는 User 도메인에서 제공받아 사용)
  • USR-DR-005: Group 도메인: 사용자-그룹 할당 관리, 그룹 정보 참조. 사용자는 하나 이상의 그룹에 속해야 함. (Group 도메인 참조)
  • USR-DR-006: Plan 도메인: 사용자-플랜 할당 관리, 플랜 정보 참조. 사용자는 정확히 하나의 플랜에 속해야 함. (Plan 도메인 참조)
  • USR-DR-007: IAM 도메인: 역할(Role), 권한(Permission), 정책(Policy)의 상세 정의, 관리, 평가 로직 의존. 그룹 및 플랜 기반 권한의 교집합을 계산하여 최종 권한을 결정. (IAM 도메인 참조)
  • USR-DR-008: Audit 도메인: 사용자 활동 및 변경 이력 로깅 의존 (예상).
  • USR-DR-009: TimeMachine 도메인: 가상 시간 설정 기능(특히, 일시 정지 기간 내 날짜 이동) 구현 시 연동 필요.
  • USR-DR-010: Mobile 도메인: 모바일 앱 관련 사용자 설정 및 권한 관리 (push notification, health data, 카메라, 앨범, 스크린샷, 동영상 녹화 등의 권한 설정은 Mobile 도메인의 UserMobileSettings에서 관리)

5.2 외부 의존성​

  • USR-DR-011: (필요시 명시)

6. GDPR 컴플라이언스 (개인정보 보호)​

6.1 개인정보 처리 원칙​

백엔드 요구사항​

  • USR-FR-BE-055: 시스템은 사용자의 개인정보 처리 목적을 명확히 정의하고 문서화해야 한다.
    • 치료 목적의 건강 데이터 수집 및 처리
    • 서비스 제공을 위한 필수 정보 처리
    • 법적 의무 준수를 위한 정보 보관
  • USR-FR-BE-056: 시스템은 데이터 주체(사용자)의 권리를 보장하는 API를 제공해야 한다.
    • 개인정보 열람권: 수집된 모든 개인정보 조회 기능
    • 정정권: 부정확한 정보의 수정 요청 처리
    • 삭제권(잊힐 권리): 개인정보 삭제 요청 처리
    • 처리 제한권: 특정 데이터 처리 제한 요청
    • 데이터 이동권: 구조화된 형식으로 데이터 내보내기
  • USR-FR-BE-057: 시스템은 개인정보 최소화 원칙을 적용해야 한다.
    • 서비스 제공에 필요한 최소한의 정보만 수집
    • 불필요한 정보의 자동 삭제 메커니즘
    • 수집 정보의 목적 외 사용 금지
  • USR-FR-BE-058: 시스템은 개인정보 익명화/가명화 기능을 제공해야 한다.
    • 통계 분석용 데이터의 익명화 처리
    • 연구 목적 데이터의 가명화 처리
    • 재식별 위험 평가 및 방지
  • USR-FR-BE-059: 시스템은 개인정보 보관 기간을 관리해야 한다.
    • 데이터 유형별 보관 기간 정의 (의료 데이터: 최소 5년, 일반 데이터: 서비스 종료 후 1년)
    • 보관 기간 만료 시 자동 삭제/익명화
    • 법적 보관 의무 기간 준수 (의료법, 개인정보보호법)
  • USR-FR-BE-060: 시스템은 제3자 데이터 전송을 관리해야 한다.
    • 데이터 전송 전 사용자 동의 확인
    • 전송 기록 및 감사 로그 생성
    • 국가 간 전송 시 적절성 평가

6.2 동의 관리​

백엔드 요구사항​

  • USR-FR-BE-061: 시스템은 세분화된 동의를 관리해야 한다.
    • 필수 동의와 선택 동의 구분
    • 동의 항목별 개별 관리
    • 동의 버전 관리 및 이력 추적
  • USR-FR-BE-062: 시스템은 동의 철회 프로세스를 제공해야 한다.
    • 실시간 동의 철회 처리
    • 철회 시 데이터 처리 즉시 중단
    • 철회 이력 기록 및 보관
  • USR-FR-BE-063: 시스템은 아동 개인정보 보호를 강화해야 한다.
    • 만 14세 미만 아동의 법정대리인 동의 확인
    • 연령 확인 메커니즘
    • 아동 데이터 특별 보호 조치

7. ISO27001 정보보호 관리​

7.1 정보 자산 관리​

백엔드 요구사항​

  • USR-FR-BE-064: 시스템은 정보 자산을 분류하고 관리해야 한다.
    • 개인정보 등급 분류 (일반/민감/특별)
    • 자산별 소유자 및 관리자 지정
    • 자산 목록 유지 및 정기 검토
  • USR-FR-BE-065: 시스템은 데이터 처리 활동을 기록해야 한다.
    • 처리 활동 유형 및 목적
    • 데이터 카테고리 및 정보주체 유형
    • 데이터 수령자 및 보관 기간

7.2 접근 통제 강화​

백엔드 요구사항​

  • USR-FR-BE-066: 시스템은 강화된 접근 통제를 구현해야 한다.
    • 최소 권한 원칙 적용
    • 정기적인 접근 권한 검토 (분기별)
    • 비활성 계정 자동 비활성화 (90일 미사용 시)
  • USR-FR-BE-067: 시스템은 특권 계정을 관리해야 한다.
    • 특권 계정 목록 관리
    • 특권 작업 모니터링 강화
    • 특권 계정 정기 검토

7.3 보안 사고 대응​

백엔드 요구사항​

  • USR-FR-BE-068: 시스템은 개인정보 유출 대응 체계를 구축해야 한다.
    • 개인정보 유출 탐지 메커니즘
    • 72시간 내 감독기관 신고 프로세스
    • 데이터 주체 통지 자동화
  • USR-FR-BE-069: 시스템은 보안 사고 대응 절차를 자동화해야 한다.
    • 사고 등급 자동 분류
    • 대응 팀 자동 알림
    • 사고 처리 타임라인 관리

7.4 암호화 및 키 관리​

백엔드 요구사항​

  • USR-FR-BE-070: (공통 정책 참조) 암호화 키 관리는 Platform 도메인 표준을 따른다:
    • PLT-SEC-004 참조
    • Google Cloud KMS 활용
    • 키 로테이션 정책 (연 1회 이상)
  • USR-FR-BE-071: (공통 정책 참조) 데이터 암호화는 Platform 도메인 표준을 따른다:

7.5 개인정보 영향평가​

백엔드 요구사항​

  • USR-FR-BE-072: 시스템은 개인정보 영향평가(DPIA)를 지원해야 한다.
    • 고위험 처리 활동 자동 식별
    • 위험 평가 템플릿 제공
    • 완화 조치 추적 관리
  • USR-FR-BE-073: 시스템은 정기적인 위험 평가를 수행해야 한다.
    • 분기별 위험 평가 실시
    • 위험 수준별 대응 방안
    • 위험 평가 결과 문서화

변경 이력​

버전날짜작성자변경 내용
0.1.02025-04-17bok@weltcorp.com최초 작성
0.1.12025-05-08bok@weltcorp.com개발 환경용 사용자 데이터 삭제 기능 요구사항(1.1.8) 추가
0.1.22025-07-11bok@weltcorp.comMobile 도메인 의존성 추가 - 모바일 앱 권한 설정은 Mobile 도메인의 UserMobileSettings에서 관리
0.2.02025-07-16bok@weltcorp.comGroup-Plan 독립성 확보 (1.1.7, 1.4.4 수정) - 사용자가 Group과 Plan을 독립적으로 가지도록 변경, 다차원 권한 계산 모델 도입
0.3.02025-08-07bok@weltcorp.com요구사항 ID 체계 적용 - USR 도메인 코드 적용 (USR-FR-BE-xxx, USR-FR-FE-xxx, USR-NFR-xxx, USR-CR-xxx, USR-AR-xxx, USR-DR-xxx)
0.4.02025-01-21bok@weltcorp.comGDPR 및 ISO27001 컴플라이언스 요구사항 추가 (섹션 6, 7) - 개인정보 보호 원칙, 데이터 주체 권리, 동의 관리, 정보보호 관리 체계
0.5.02025-10-27bok@weltcorp.com게스트 계정 타입, 생명주기, TimeMachine 기반 만료 관리 요구사항 추가 (1.1절)
0.6.02025-12-17bok@weltcorp.com게스트 계정 자발적 탈퇴 요구사항 추가 (USR-FR-BE-076)