본문으로 건너뛰기

Plan 도메인 비즈니스 규칙

1. 일반 규칙​

1.1 스키마 정의​

  • Plan 도메인 관련 모든 데이터(Plan, PlanRole, 플랜 메타데이터 등)는 plan PostgreSQL 스키마에 저장되어야 합니다.
  • 플랜과 연결된 역할(Role) 정보는 IAM 도메인(iam 스키마)을 참조합니다.
  • 플랜은 사용자(User)에게 직접 할당되며, User 도메인에서 관리됩니다.

1.2 고유성 제약​

  • 플랜(Plan) 이름(name)은 시스템 내에서 고유해야 합니다.
  • 플랜 식별자(id)는 생성 후 변경할 수 없습니다.
  • 플랜 코드(code)가 있는 경우 시스템 내에서 고유해야 합니다.

1.3 감사 로깅​

  • 플랜 데이터에 대한 모든 접근 및 변경은 감사 로그로 기록되어야 합니다.
  • 플랜-역할 할당 및 해제에 대한 감사 로그를 기록해야 합니다.
  • 플랜 상태 변경(활성화/비활성화)에 대한 감사 로그를 기록해야 합니다.
  • Audit 도메인과의 의존성을 가집니다.

2. 플랜(Plan) 정의 규칙​

2.1 플랜 목적​

  • 플랜은 사용자가 이용할 수 있는 서비스의 범위, 기능 세트, 또는 프로그램 수준을 정의합니다.
  • 플랜은 "이 사용자는 무엇을 사용할 수 있는가?"에 대한 답을 제공합니다.
  • 플랜은 사용자의 상태(예: 치료 기간, 구독 상태)에 따라 할당되며, 이용 가능한 기능의 범위를 나타냅니다.

2.2 플랜 구성 요소​

  • 플랜은 여러 역할(Role)의 집합으로 구성됩니다.
  • 플랜은 서비스 기간, 기능 접근 범위, 제한 사항 등의 메타데이터를 포함합니다.
  • 플랜은 비즈니스 규칙과 정책을 정의할 수 있습니다.
  • 플랜은 그룹과 독립적으로 운영되며, 서비스 수준에 따른 권한을 부여합니다.
  • 게스트 플랜은 정규 플랜과 명확히 분리하여 관리되며, Step-up 완료 시 지정된 등록 플랜으로 전환되어야 합니다.

3. 플랜 유형 및 분류 규칙​

3.1 표준 플랜 유형​

시스템에서 지원하는 표준 플랜 유형은 다음과 같습니다:

3.1.1 치료 플랜 (Therapeutic Plan)​

  • 목적: 불면증 진단을 받은 사용자를 대상으로 하는 기본 치료 플랜
  • 대상: 활성 치료 중인 환자
  • 기능: 전체 치료 프로그램 접근 권한
  • 기간: 일반적으로 6-12주 (설정 가능)

3.1.2 제한 플랜 (Limited Access Plan)​

  • 목적: 치료 플랜 기간이 만료된 사용자를 위한 제한된 기능 플랜
  • 대상: 치료 완료 후 사용자
  • 기능: 기본 모니터링 및 유지 관리 기능
  • 기간: 무제한 (단, 기능 제한)

3.1.3 샘플 플랜 (Sample Plan)​

  • 목적: 체험용 또는 데모용 플랜
  • 대상: 잠재 고객, 체험 사용자
  • 기능: 제한된 기능 세트
  • 기간: 일반적으로 7-14일

3.1.4 게스트 플랜 (Guest Access Plan)​

  • 목적: 이메일/소셜 인증 없이 약관 동의만으로 온보딩한 사용자를 위한 제한 플랜
  • 대상: guests.* IAM Group 소속 사용자
  • 기능: 서비스 정책에 따라 정의된 제한된 기능
  • 기간: 서비스 설정에 따른 일정 기간 (TimeMachine 기반 만료 타이머 필수)

3.1.4 개발 플랜 (Development Plan)​

  • 목적: 개발 및 테스트 환경용 플랜
  • 대상: 개발자, QA 테스터
  • 기능: 개발/테스트용 특수 기능
  • 기간: 개발 주기에 따라 가변

3.1.5 클리니션 플랜 (Clinician Plan)​

  • 목적: 의료진용 전문 플랜
  • 대상: 의사, 간호사, 임상 전문가
  • 기능: 환자 관리, 진료 기록, 분석 도구
  • 기간: 고용 기간 동안 유지

3.2 플랜 분류 체계​

  • 플랜은 사용자 유형(환자/내부 운영자)에 따라 분류됩니다.
  • 플랜은 서비스 수준(Basic/Standard/Premium)에 따라 분류될 수 있습니다.
  • 플랜은 지역별, 언어별로 분류될 수 있습니다.

4. 플랜 생명주기 관리 규칙​

4.1 플랜 상태 관리​

  • 플랜은 다음 상태를 가집니다:
    • ACTIVE: 활성 상태, 새로운 사용자에게 할당 가능
    • INACTIVE: 비활성 상태, 새로운 할당 불가능하지만 기존 사용자는 유지
    • DEPRECATED: 폐기 예정, 점진적 제거 단계
    • ARCHIVED: 보관됨, 이력 조회용으로만 유지

4.2 플랜 버전 관리​

  • 플랜 변경 시 버전 관리를 지원해야 합니다.
  • 이전 버전의 플랜을 사용하는 사용자에 대한 마이그레이션 계획이 필요합니다.
  • 플랜 변경 이력을 추적할 수 있어야 합니다.

4.3 플랜 마이그레이션 규칙​

  • 플랜 변경 시 기존 사용자들의 서비스 연속성을 보장해야 합니다.
  • 플랜 업그레이드/다운그레이드 시 데이터 무결성을 유지해야 합니다.
  • 플랜 마이그레이션은 단계적으로 진행되어야 합니다.

5. 플랜-역할 관계 규칙​

5.1 플랜-역할 할당​

  • 플랜에 여러 역할(Role)을 추가하거나 제거할 수 있어야 합니다.
  • 플랜-역할 관계는 PlanRole 테이블을 통해 관리됩니다.
  • 역할 정보는 IAM 도메인에서 참조합니다.

5.2 역할 충돌 해결​

  • 한 플랜 내에서 상충되는 역할이 할당되지 않도록 검증해야 합니다.
  • 역할 간 의존성을 확인하여 필수 역할이 포함되도록 해야 합니다.
  • 역할 변경 시 플랜의 일관성을 유지해야 합니다.

5.3 권한 계산 연동​

  • 플랜을 통한 권한 계산은 IAM 도메인과 연동하여 수행됩니다.
  • 플랜 권한 경로: User → Plan → Role → Permission (서비스 수준 권한)
  • 그룹과 독립적: 플랜 기반 권한은 그룹 기반 권한과 독립적으로 계산됩니다.
  • 플랜 변경 시 관련 사용자들의 권한 캐시 무효화가 필요합니다.
  • 최종 권한은 플랜 권한과 그룹 권한의 교집합으로 결정됩니다.

6. 플랜 기능 및 제한사항 관리 규칙​

6.1 기능 범위 정의​

  • 각 플랜은 접근 가능한 기능 목록을 명확히 정의해야 합니다.
  • 기능별 사용 한도(예: API 호출 횟수, 데이터 용량)를 설정할 수 있습니다.
  • 시간대별 접근 제한을 설정할 수 있습니다.
  • 게스트 플랜은 민감 기능(치료 기록, 메시징 등)에 접근할 수 없도록 Feature Flag 및 IAM 정책과 연동해야 합니다.

6.2 서비스 수준 정의​

  • 플랜별 서비스 수준 협약(SLA)을 정의할 수 있습니다.
  • 플랜별 지원 수준(기본/우선/프리미엄)을 설정할 수 있습니다.
  • 플랜별 데이터 보존 기간을 정의할 수 있습니다.

6.3 제한사항 관리​

  • 플랜별 사용 제한사항을 정의하고 관리해야 합니다.
  • 제한사항 위반 시 처리 방안을 정의해야 합니다.
  • 제한사항 모니터링 및 알림 체계를 구축해야 합니다.

7. 플랜 할당 및 변경 규칙​

7.1 플랜 할당 원칙​

  • 사용자는 직접 플랜에 연결됩니다 (User 도메인에서 관리).
  • 사용자는 특정 시점에 정확히 하나의 활성 플랜에만 연결됩니다.
  • 모든 USER 타입 사용자는 플랜에 연결되어야 합니다.
  • 플랜 변경은 그룹 멤버십에 영향을 주지 않습니다.
  • 게스트 계정은 기본적으로 plan.guest.default에 할당되며, Step-up 완료 시 등록 사용자 플랜(예: plan.therapeutic.default)으로 전환되어야 합니다.
  • 게스트 플랜 만료 시 사용자 accountType과 연계하여 서비스 접근을 자동 제한해야 합니다.

7.2 플랜 변경 규칙​

  • 플랜 변경은 비즈니스 규칙에 따라 검증되어야 합니다.
  • 플랜 다운그레이드 시 데이터 손실 가능성을 사용자에게 알려야 합니다.
  • 플랜 변경 시 기존 데이터의 호환성을 확인해야 합니다.

7.3 플랜 변경 이력​

  • 모든 플랜 변경 이력을 기록하고 추적해야 합니다.
  • 변경 사유, 변경 시점, 변경 주체를 기록해야 합니다.
  • 플랜 변경으로 인한 권한 변화를 추적해야 합니다.
  • 게스트 플랜에서 등록 플랜으로 전환 시 PlanAssignmentHistory에 전환 사유와 트리거(예: Step-up, 관리자 조치)를 기록해야 합니다.
  • 게스트 플랜 만료로 인한 플랜 종료 사건은 GuestAccountLifecycle과 Audit 로그에 함께 기록해야 합니다.

8. 플랜 템플릿 및 프리셋 관리 규칙​

8.1 플랜 템플릿​

  • 자주 사용되는 플랜 구성을 템플릿으로 저장할 수 있습니다.
  • 템플릿을 기반으로 새로운 플랜을 빠르게 생성할 수 있습니다.
  • 템플릿의 버전 관리를 지원해야 합니다.

8.2 기본 플랜 설정​

  • 시스템에는 최소 하나의 기본 플랜이 존재해야 합니다.
  • 새로운 사용자에게 할당할 기본 플랜을 지정할 수 있습니다.
  • 기본 플랜은 삭제할 수 없습니다.

8.3 플랜 복사 및 파생​

  • 기존 플랜을 복사하여 새로운 플랜을 생성할 수 있습니다.
  • 플랜 간 상속 관계를 설정할 수 있습니다.
  • 부모 플랜 변경 시 자식 플랜에 미치는 영향을 관리해야 합니다.

9. 플랜 모니터링 및 분석 규칙​

9.1 사용량 모니터링​

  • 플랜별 사용자 수를 실시간으로 모니터링해야 합니다.
  • 플랜별 기능 사용률을 추적해야 합니다.
  • 플랜별 리소스 사용량을 모니터링해야 합니다.

9.2 성능 분석​

  • 플랜별 사용자 만족도를 측정할 수 있어야 합니다.
  • 플랜 변경 패턴을 분석할 수 있어야 합니다.
  • 플랜별 수익성을 분석할 수 있어야 합니다.

9.3 알림 및 경고​

  • 플랜 사용량이 임계치를 초과할 때 알림을 발송해야 합니다.
  • 플랜 만료 예정 사용자에게 사전 알림을 제공해야 합니다.
  • 플랜 관련 시스템 오류 시 관리자에게 알림해야 합니다.

10. 플랜 연동 및 통합 규칙​

10.1 도메인 간 연동​

  • IAM 도메인: 플랜-역할 매핑을 통한 권한 부여, 플랜 권한 계산
  • User 도메인: 사용자-플랜 직접 할당 관리, 사용자 상태 기반 플랜 자격 검증
  • Billing 도메인: 결제 상태 기반 플랜 접근 제어
  • 참고: Group 도메인과는 독립적으로 운영되며, 서로 다른 차원의 권한을 제공합니다.

10.2 외부 시스템 연동​

  • 결제 시스템과 연동하여 플랜 상태를 동기화해야 합니다.
  • CRM 시스템과 연동하여 고객 상태를 반영해야 합니다.
  • 분석 시스템에 플랜 사용 데이터를 제공해야 합니다.

10.3 API 연동 규칙​

  • 플랜 정보는 REST API를 통해 조회할 수 있어야 합니다.
  • 플랜 변경은 적절한 권한을 가진 사용자만 수행할 수 있습니다.
  • 플랜 관련 이벤트는 이벤트 버스를 통해 전파되어야 합니다.

11. 보안 규칙​

11.1 접근 제어​

  • 플랜 정보에 대한 접근은 적절한 권한을 가진 사용자만 가능합니다.
  • 플랜 수정은 관리자 권한을 가진 사용자만 수행할 수 있습니다.
  • 민감한 플랜 정보는 암호화하여 저장해야 합니다.

11.2 데이터 보호​

  • 플랜 데이터의 무결성을 보장해야 합니다.
  • 플랜 변경 시 데이터 백업을 수행해야 합니다.
  • 플랜 삭제 시 관련 데이터의 처리 방안을 정의해야 합니다.

11.3 감사 및 규정 준수​

  • 모든 플랜 관련 활동을 감사 로그로 기록해야 합니다.
  • GDPR 등 개인정보 보호 규정을 준수해야 합니다.
  • 플랜 데이터 보존 정책을 수립하고 준수해야 합니다.

12. 성능 규칙​

12.1 응답 시간 목표​

  • 플랜 조회 API 평균 응답 시간: < 100ms
  • 플랜 권한 계산 API 평균 응답 시간: < 150ms
  • 플랜 수정 API 평균 응답 시간: < 500ms
  • 플랜 생성/삭제 API 평균 응답 시간: < 1초

12.2 처리량 목표​

  • 초당 최소 500건의 플랜 조회 요청 처리 가능해야 합니다.
  • 초당 최소 100건의 플랜 권한 계산 요청 처리 가능해야 합니다.
  • 초당 최소 50건의 플랜 변경 요청 처리 가능해야 합니다.

12.3 캐싱 전략​

  • 플랜 정보를 캐싱하여 조회 성능을 향상시켜야 합니다.
  • 플랜-역할 매핑 정보를 캐싱해야 합니다.
  • 플랜 변경 시 관련 캐시를 적절히 무효화해야 합니다.

13. 데이터 제약 규칙​

13.1 플랜 데이터 제약​

  • 플랜 이름은 시스템 내에서 고유해야 합니다.
  • 플랜 설명의 최대 길이는 1000자로 제한합니다.
  • 플랜에 할당될 수 있는 역할의 최대 개수는 50개로 제한합니다.

13.2 관계 제약​

  • 플랜-역할 관계에서 순환 참조는 허용되지 않습니다.
  • 삭제된 역할을 참조하는 플랜이 있으면 역할 삭제를 제한합니다.
  • 플랜 삭제 시 연관된 사용자가 있으면 삭제를 제한합니다.

13.3 비즈니스 제약​

  • 기본 플랜으로 지정된 플랜은 삭제할 수 없습니다.
  • 활성 사용자가 있는 플랜은 비활성화할 수 없습니다.
  • 플랜 변경 시 최소 7일의 유예 기간을 두어야 합니다.

14. 변경 이력​

버전날짜작성자변경 내용
0.1.02025-07-15bok@weltcorp.com최초 문서 생성 (IAM 도메인에서 분리)
0.2.02025-07-16bok@weltcorp.comGroup-Plan 독립성 확보: 1.1 그룹 참조 제거, 2.2 독립성 명시, 5.3 다차원 권한 계산, 7.1 직접 플랜 할당, 10.1 Group 연동 제거, 13.2 수정
0.3.02025-10-27bok@weltcorp.com게스트 플랜 정의 및 전환/만료 규칙 추가 (3.1.4, 2.2, 6.1, 7.1, 7.3 보강)