본문으로 건너뛰기

TimeMachine 도메인 요구사항

관련 문서

TBD

1. 기능 요구사항

1.1 시간 관리

백엔드 요구사항

  • TMC-FR-BE-001: 시스템은 사용자별로 현재 가상 시간을 조회할 수 있어야 한다.
  • TMC-FR-BE-002: 시스템은 사용자 ID를 기반으로 해당 사용자의 가상 시간을 식별하고 반환해야 한다. (가상 시간은 UTC 타임스탬프와 Timezone ID로 구성됨)
  • TMC-FR-BE-003: 시스템은 Mobile App과 Backend가 동일한 시간을 참조할 수 있도록 해야 한다.
  • TMC-FR-BE-004: 시스템은 REST API를 통해 현재 가상 시간 정보(UTC 타임스탬프, Timezone ID, 로컬 시간 문자열 등)를 제공해야 한다.
  • TMC-FR-BE-005: 시스템은 자정 도달 또는 시간 조작으로 인한 시스템의 날짜 변경을 자동으로 감지하고 SystemDayChanged 이벤트를 발행하여 모든 사용자에게 영향을 미치는 전역 일차별 로직을 트리거해야 한다.
  • TMC-FR-BE-006: 시스템은 사용자의 TimeMachine 조작으로 인한 가상 날짜 변경을 감지하고 UserVirtualDayChanged 이벤트를 발행하여 해당 사용자의 컨텐츠 해금, rTIB 계산 등 개별 일차별 로직을 트리거해야 한다.
  • TMC-FR-BE-007: 시스템은 테스터가 특정 사용자의 가상 시간을 특정 치료 주기 일차(dayIndex, >= 2)를 기준으로 설정할 수 있도록 해야 한다.
    • 설정 시 사용자의 UserCycle 시작일 및 모든 UserSuspensionHistory를 참조하여 목표 날짜를 계산해야 한다 (DE-User 도메인 의존).
    • 설정되는 시간은 계산된 목표 날짜의 시작(00:00)이며, 사용자의 타임존이 적용되어야 한다.
  • TMC-FR-BE-008: 시스템은 시간 변경 이력을 저장하고 추적할 수 있어야 한다 (변경 전/후 시간, 변경자, 변경 유형 등).
  • TMC-FR-BE-009: 시스템은 테스터 권한을 가진 사용자만 시간을 설정할 수 있도록 제한해야 한다.
  • TMC-FR-BE-010: 시스템은 가상 시간을 1일차(dayIndex=1) 이전으로 설정할 수 없도록 제한해야 한다.(2일차 이상만 가능)
  • TMC-FR-BE-011: 시스템은 각 사용자마다 별도의 가상 시간을 관리할 수 있어야 한다.
  • TMC-FR-BE-012: 시스템은 사용자 ID를 기반으로 가상 시간을 분리하여 저장해야 한다.
  • TMC-FR-BE-013: 시스템은 특정 사용자의 가상 시간이 변경되더라도 다른 사용자의 가상 시간에 영향을 주지 않아야 한다.
  • TMC-FR-BE-014: 시스템은 사용자의 TimeMachine 기능 활성화/비활성화 상태를 저장하고 관리해야 한다. 활성 상태는 관리자가 명시적으로 시간을 설정했거나, TimeMachine Access Code로 생성되어 초기 가상 시간이 적용되는 경우를 의미한다.
  • TMC-FR-BE-015: 시스템은 TimeMachine 기능이 비활성화된 사용자(활성 상태가 아닌 사용자)에게는 항상 실제 시간을 반환해야 한다.
  • TMC-FR-BE-016: 시스템은 TimeMachine Access Code를 통해 생성된 사용자의 경우, 관리자가 명시적으로 가상 시간을 변경하기 전까지 해당 사용자의 시간은 초기 가상 생성 시점에 고정되어 흘러가지 않아야 한다.
  • TMC-FR-BE-017: 시스템은 사용자별로 TimeMachine 기능의 사용/비사용 상태를 저장하고 관리해야 한다.
  • TMC-FR-BE-018: 시스템은 사용자의 TimeMachine 기능 활성화/비활성화를 위한 API를 제공해야 한다.
  • TMC-FR-BE-019: 시스템은 TimeMachine 기능 활성화 상태 변경 이력을 저장하고 추적할 수 있어야 한다.
  • TMC-FR-BE-020: 시스템은 사용자 자신만 자신의 TimeMachine 기능 활성화/비활성화 상태를 변경할 수 있도록 제한해야 한다(테스터 제외).
  • TMC-FR-BE-021: 시스템은 PROD 환경에서 TimeMachine 관련 API 접근에 대한 엄격한 권한 검증을 수행해야 한다.
  • TMC-FR-BE-022: 시스템은 PROD 환경에서 TimeMachine 기능 활성화 요청 시 특별한 권한 검증 및 로깅을 수행해야 한다.
  • TMC-FR-BE-023: 시스템은 환경(개발, 테스트, 스테이징, PROD)에 따라 TimeMachine 기능의 접근 정책을 다르게 적용해야 한다.
  • TMC-FR-BE-024: 시스템은 캐시를 통해 빠른 응답 시간을 보장해야 한다.
  • TMC-FR-BE-025: 시스템은 특정 사용자의 가상 시간을 해당 사용자의 특정 치료 활동 일시 정지 기간 내의 N번째 날짜를 기준으로 설정할 수 있어야 한다.
    • 설정 시 사용자의 UserSuspensionHistory 이력을 참조하여 요청된 순서(suspensionSequence)의 정지 기간 및 해당 기간 내 날짜(dayWithinSuspension)를 계산해야 한다.
    • 유효성 검증(존재하는 정지 순서, 기간 내 유효한 날짜)을 수행해야 한다.
    • 설정되는 시간은 계산된 목표 날짜의 시작(00:00)이며, 사용자의 타임존이 적용되어야 한다.
  • TMC-FR-BE-026: 시스템은 특정 사용자의 가상 시간을 실제 시간으로 재설정하고 TimeMachine 기능을 비활성화할 수 있어야 한다.
  • TMC-FR-BE-027: 시스템은 가상 시간 변경 이력을 기록하고 조회할 수 있어야 한다 (변경자, 변경 시각, 이전/이후 시간, 변경 사유, dayIndex 또는 정지 기간 정보(선택적) 포함).
  • TMC-FR-BE-028: 시스템은 PROD 환경에서 TimeMachine 기능 사용을 제한하고, 활성화 시 알림을 보내야 한다 (별도 보안 정책 필요).

프론트엔드 요구사항

  • TMC-FR-FE-001: TBD

1.2 데이터 정합성 관리

백엔드 요구사항

  • TMC-FR-BE-029: 시스템은 과거 시점 (더 낮은 dayIndex에 해당하는 과거 날짜)으로 시간이 이동되었을 경우, 이동된 시점 이후의 데이터가 존재하지 않도록 해야 한다.
  • TMC-FR-BE-030: 시스템은 과거 시점 이후 데이터를 영구적으로 삭제하는 롤백 기능을 구현해야 한다.
  • TMC-FR-BE-031: 시스템은 롤백된 데이터를 복구하지 않고 영구적으로 제거해야 한다.
  • TMC-FR-BE-032: 시스템은 롤백 이력을 관리하고 조회할 수 있는 기능을 제공해야 한다.
  • TMC-FR-BE-033: 시스템은 미래 시점 (더 높은 dayIndex에 해당하는 미래 날짜)으로 시간 이동 시 시간 변경만 담당하고, 테스트에 필요한 데이터 생성은 처리하지 않아야 한다.
  • TMC-FR-BE-034: 시스템은 시간 이동에 따른 이벤트만 발행하고 데이터 처리는 담당하지 않아야 한다.
  • TMC-FR-BE-035: 시스템은 사용자별 데이터 롤백을 수행하여 다른 사용자의 데이터에 영향을 주지 않아야 한다.
  • TMC-FR-BE-036: 시스템은 사용자별 데이터 격리를 지원하여 가상 시간의 변경이 해당 사용자의 데이터만 영향을 받도록 해야 한다.
  • TMC-FR-BE-037: 시스템은 TimeMachine 기능을 비활성화하는 경우, 해당 사용자의 가상 시간과 실제 시간 간의 차이로 인한 데이터 불일치를 처리하는 방안을 제공해야 한다.
  • TMC-FR-BE-038: 시스템은 TimeMachine 기능을 비활성화하는 경우, 사용자의 가상 시간을 해당 사용자의 Timezone 기준 현재 실제 날짜의 00:00으로 재설정해야 한다. (dayIndex 기반이 아님)
  • TMC-FR-BE-039: 시스템은 TimeMachine 기능 비활성화로 인해 시간이 재설정된 후, 해당 시간 이후에 생성된 모든 사용자 데이터를 자동으로 식별하고 영구 삭제해야 한다 (기존 롤백 메커니즘 활용).
  • TMC-FR-BE-040: 시스템은 TimeMachine 기능 비활성화로 인한 시간 재설정 및 데이터 삭제 작업을 사용자별로 처리하고 이력을 관리해야 한다.

프론트엔드 요구사항

  • TMC-FR-FE-002: TBD

1.3 이벤트 관리

백엔드 요구사항

  • TMC-FR-BE-041: 시스템은 테스터가 가상 시간의 날짜를 변경할 경우 (dayIndex 변경으로 인해 실제 날짜가 변경될 때) GCP Pub/Sub으로 이벤트를 발행해야 한다.
  • TMC-FR-BE-042: 시스템은 시스템의 날짜가 변경될 때 (자정 도달 또는 시간 조작으로 인한 날짜 변경) SystemDayChanged 이벤트를 GCP Pub/Sub으로 발행하여 다른 도메인의 일차별 로직(컨텐츠 해금, rTIB 계산 등)을 트리거해야 한다.
  • TMC-FR-BE-043: 시스템은 사용자의 TimeMachine 조작으로 인한 가상 날짜 변경을 감지하고 UserVirtualDayChanged 이벤트를 발행하여 해당 사용자의 컨텐츠 해금, rTIB 계산 등 개별 일차별 로직을 트리거해야 한다.
  • TMC-FR-BE-044: 시스템은 이벤트에 변경 전/후 시간(UTC 타임스탬프), 변경 전/후 dayIndex, 변경자 정보 등을 포함해야 한다.
  • TMC-FR-BE-045: 시스템은 이벤트 발행 실패 시 재시도 메커니즘을 구현해야 한다.
  • TMC-FR-BE-046: 시스템은 이벤트 발행 로그를 기록하고 조회할 수 있는 기능을 제공해야 한다.
  • TMC-FR-BE-047: 시스템은 GCP Pub/Sub의 날짜 변경 이벤트를 구독하는 기능을 제공해야 한다.
  • TMC-FR-BE-048: 시스템은 구독한 이벤트를 특정 Backend 엔드포인트로 푸시할 수 있어야 한다.
  • TMC-FR-BE-049: 시스템은 이벤트 처리 결과를 기록하고 모니터링할 수 있어야 한다.
  • TMC-FR-BE-050: 시스템은 이벤트에 어떤 사용자의 가상 시간이 변경되었는지 식별하는 정보를 포함해야 한다.
  • TMC-FR-BE-051: 시스템은 사용자별 이벤트 필터링을 지원하여 필요한 시스템만 특정 사용자의 시간 변경 이벤트를 수신할 수 있어야 한다.
  • TMC-FR-BE-052: 시스템은 TimeMachine 기능의 활성화/비활성화 상태 변경 시에도 이벤트를 발행해야 한다.
  • TMC-FR-BE-053: 시스템은 PROD 환경에서 TimeMachine 기능 활성화 시 관리자에게 알림을 발송해야 한다.
  • TMC-FR-BE-054: 시스템은 PROD 환경에서 TimeMachine 기능 사용에 대한 감사 로그를 상세하게 기록해야 한다.

프론트엔드 요구사항

  • TMC-FR-FE-003: TBD

1.4 시간대 및 서머 타임(DST) 처리

  • TMC-FR-BE-055: 시스템은 다양한 시간대(Timezone) 정보를 관리하고, 특정 시간대에 대한 현재 시각을 반환할 수 있어야 한다. (dayIndex 계산 시 사용자의 Timezone 기준 00:00 설정 필요)
  • TMC-FR-BE-056: 시스템은 지정된 시간대와 날짜/시각에 대해 서머 타임(DST) 적용 여부를 판단하고, 올바른 오프셋(offset)을 적용하여 UTC와 로컬 시간 간 변환을 수행해야 한다.
  • TMC-FR-BE-057: 시스템은 서머 타임 시작/종료 시각을 걸치는 기간 계산 시 실제 경과 시간을 정확하게 계산해야 한다. (예: 단순히 시각 차이만 계산하는 것이 아니라 DST로 인한 시간 변경을 반영해야 함)
  • TMC-FR-BE-058: 시스템은 dayIndex 기반 날짜 계산 시 DST 전환을 고려한 정확한 계산을 수행해야 한다.
    • 타임존 오프셋 변화로 인한 날짜 계산 오류 방지
    • DST 전환일의 하루 길이 변화(23/25시간) 정확 반영
    • date-fns-tz 라이브러리의 DST 처리 기능 활용 필수

2. 비기능 요구사항

2.1 성능

  • TMC-NFR-001: 시스템은 시간 조회 API에 대해 50ms 이내의 응답 시간을 제공해야 한다(99번째 백분위수).
  • TMC-NFR-002: 시스템은 시간 설정 API에 대해 200ms 이내의 응답 시간을 제공해야 한다(99번째 백분위수).
  • TMC-NFR-003: 시스템은 이벤트 발행을 500ms 이내에 완료해야 한다.
  • TMC-NFR-004: 시스템은 SystemDayChanged 이벤트 발행을 100ms 이내에 완료해야 한다.
  • TMC-NFR-005: 시스템은 UserVirtualDayChanged 이벤트 발행을 100ms 이내에 완료해야 한다.
  • TMC-NFR-006: 시스템은 초당 100개 이상의 시간 조회 요청을 처리할 수 있어야 한다.
  • TMC-NFR-007: 시스템은 초당 10개 이상의 시간 설정 요청을 처리할 수 있어야 한다.
  • TMC-NFR-008: 시스템은 초당 20개 이상의 이벤트 발행 및 처리를 수행할 수 있어야 한다.
  • TMC-NFR-009: 시스템은 동시에 최소 1,000명의 서로 다른 사용자에 대한 가상 시간을 관리할 수 있어야 한다.
  • TMC-NFR-010: 시스템은 TimeMachine 기능 활성화/비활성화 전환 시 100ms 이내에 처리해야 한다.
  • TMC-NFR-011: 시스템은 롤백 처리 성능을 최적화해야 한다.
  • TMC-NFR-012: 시스템은 대용량 데이터의 롤백을 효율적으로 처리할 수 있는 방안을 제공해야 한다.

2.2 보안

  • TMC-NFR-013: 시스템은 역할 기반 접근 제어(RBAC)를 구현해야 한다.
  • TMC-NFR-014: 시스템은 테스터 권한을 가진 사용자만 시간 변경이 가능하도록 제한해야 한다.
  • TMC-NFR-015: 시스템은 모든 API 호출에 대한 인증을 필수로 해야 한다.
  • TMC-NFR-016: (공통 정책 참조) 저장 데이터 암호화는 Platform 표준을 따른다 - PLT-SEC-001
  • TMC-NFR-017: (공통 정책 참조) 통신 보안은 Platform 표준을 따른다 - PLT-SEC-002
  • TMC-NFR-018: 시스템은 감사 로그의 위변조를 방지해야 한다.
  • TMC-NFR-019: 시스템은 시간 변경 이력이 변경되지 않도록 보장해야 한다.
  • TMC-NFR-020: 시스템은 테스터가 자신에게 할당된 사용자의 가상 시간만 변경할 수 있도록 제한해야 한다.
  • TMC-NFR-021: 시스템은 보안 취약점에 대한 정기적인 검사 및 패치 프로세스를 구현해야 한다.
  • TMC-NFR-022: (공통 정책 참조) 강화된 보안은 Platform 표준을 따른다 - PLT-SEC-003, PLT-SEC-005

2.3 확장성

  • (공통 정책 참조) 확장성 원칙은 Platform 도메인 기준을 따른다: PLT-NFR-001, PLT-NFR-002
  • TMC-NFR-023: 시스템은 수평적 확장이 가능한 아키텍처를 구현해야 한다.
  • TMC-NFR-024: 시스템은 MSA 환경에서 원활하게 통합되어야 한다.
  • TMC-NFR-025: 시스템은 데이터 증가에 따른 성능 저하를 최소화해야 한다.
  • TMC-NFR-026: 시스템은 다양한 서비스에서 시간 조회 API를 사용할 수 있도록 설계해야 한다.
  • TMC-NFR-027: 시스템은 다중 테스터 환경을 지원해야 한다.
  • TMC-NFR-028: 시스템은 사용자 수가 증가해도 성능 저하 없이 확장 가능해야 한다.
  • TMC-NFR-029: 시스템은 사용자별 가상 시간 저장소를 샤딩하여 대규모 사용자를 지원할 수 있어야 한다.
  • TMC-NFR-030: 시스템은 지역적으로 분산된 사용자를 지원하기 위한 분산 캐시 전략을 구현해야 한다.
  • TMC-NFR-031: 시스템은 대규모 사용자 환경에서의 성능 최적화를 위한 추가 기능을 제공해야 한다.

2.4 가용성

  • (공통 정책 참조) 가용성/복구는 Platform 도메인 기준을 따른다: PLT-NFR-004, PLT-NFR-005
  • TMC-NFR-032: 시스템은 99.9% 이상의 서비스 가용성을 보장해야 한다.
  • TMC-NFR-033: 시스템은 단일 구성요소 장애 시에도 서비스를 지속할 수 있어야 한다.
  • TMC-NFR-034: 시스템은 자동 복구 메커니즘을 구현해야 한다.
  • TMC-NFR-035: 시스템은 장애 발생 시 5분 이내에 감지할 수 있어야 한다.
  • TMC-NFR-036: 시스템은 장애 발생 후 15분 이내에 자동 복구를 시도해야 한다.
  • TMC-NFR-037: 시스템은 복구 실패 시 관리자에게 알림을 발송해야 한다.

2.5 운영성

  • TMC-NFR-038: 시스템은 실시간 상태 모니터링을 제공해야 한다.
  • TMC-NFR-039: 시스템은 성능 지표를 수집하고 분석할 수 있어야 한다.
  • TMC-NFR-040: 시스템은 알림 임계치 설정 기능을 제공해야 한다.
  • TMC-NFR-041: 시스템은 캐시 무효화 메커니즘을 구현해야 한다.
  • TMC-NFR-042: 시스템은 배치 작업을 통한 데이터 정리를 지원해야 한다.
  • TMC-NFR-043: 시스템은 운영 관리를 위한 관리자 도구를 제공해야 한다.
  • TMC-NFR-044: 시스템은 사용자별 가상 시간 데이터의 백업 및 복구 메커니즘을 제공해야 한다.
  • TMC-NFR-045: 시스템은 특정 사용자의 가상 시간을 리셋하거나 동기화하는 관리 기능을 제공해야 한다.
  • TMC-NFR-046: 시스템은 TimeMachine 기능 활성화/비활성화 상태 통계를 제공해야 한다.
  • TMC-NFR-047: 시스템은 데이터 롤백 과정에서 일관성을 유지할 수 있는 트랜잭션 메커니즘을 제공해야 한다.
  • TMC-NFR-048: 시스템은 미래 시점 이동 후 데이터 생성을 지원하는 보조 도구를 제공해야 한다.
  • TMC-NFR-049: 시스템은 테스트 데이터 생성 템플릿을 제공해야 한다.
  • TMC-NFR-050: 시스템은 미리 정의된 시간 변경 시나리오를 저장하고 실행할 수 있어야 한다.
  • TMC-NFR-051: 시스템은 테스트 시나리오 실행을 예약할 수 있어야 한다.
  • TMC-NFR-052: 시스템은 시나리오 실행 결과를 기록하고 분석할 수 있어야 한다.

3. 제약사항

3.1 기술적 제약

  • TMC-CR-001: 시스템은 NestJS 프레임워크를 사용하여 구현되어야 한다.
  • TMC-CR-002: 시스템은 GCP Pub/Sub을 사용해야 한다.
  • TMC-CR-003: 시스템은 Redis 캐시를 사용해야 한다.
  • TMC-CR-004: 시스템은 Docker 컨테이너화가 필수적이다.
  • TMC-CR-005: 시스템은 Typescript 기반으로 개발되어야 한다.
  • TMC-CR-006: 시스템은 PostgreSQL 데이터베이스를 사용해야 한다.
  • TMC-CR-007: 시스템은 사용자별 가상 시간 데이터를 효율적으로 저장하기 위해 적절한 인덱싱 전략을 사용해야 한다.

3.2 환경 제약

  • TMC-CR-008: 시스템은 GCP 클라우드 환경에서 운영되어야 한다.
  • TMC-CR-009: 시스템은 Kubernetes 기반으로 운영되어야 한다.
  • TMC-CR-010: 시스템은 다중 가용영역 구성을 지원해야 한다.
  • TMC-CR-011: 시스템은 무중단 배포를 지원해야 한다. (참조: PLT-NFR-007)

3.3 통합 제약

  • TMC-CR-012: 시스템은 Mobile App과 원활하게 통합되어야 한다.
  • TMC-CR-013: 시스템은 기존 서비스 아키텍처와의 호환성을 유지해야 한다.
  • TMC-CR-014: 시스템은 마이크로서비스 간 독립성을 보장해야 한다.
  • TMC-CR-015: 시스템은 표준 API 형식을 준수해야 한다.
  • TMC-CR-016: 시스템은 사용자 식별을 위해 기존 인증 시스템과 통합되어야 한다.

3.4 데이터 저장 제약

  • TMC-CR-017: 시스템은 시간 변경 이력을 영구 보관해야 한다.
  • TMC-CR-018: 시스템은 이벤트 발행 이력을 추적해야 한다.
  • TMC-CR-019: 시스템은 데이터 롤백 이력을 보관해야 한다.
  • TMC-CR-020: 시스템은 사용자별 가상 시간 데이터를 분리하여 저장해야 한다.
  • TMC-CR-021: 시스템은 TimeMachine 기능 활성화/비활성화 이력을 저장해야 한다.

4. 가정사항

4.1 시스템 환경

  • TMC-AR-001: 시스템은 클라우드 기반으로 운영될 것이다.
  • TMC-AR-002: 시스템은 컨테이너화된 배포 방식을 사용할 것이다.
  • TMC-AR-003: 시스템은 마이크로서비스 아키텍처를 따를 것이다.

4.2 사용자 환경

  • TMC-AR-004: 테스터는 적절한 권한을 부여받을 것이다.
  • TMC-AR-005: 사용자는 모바일 앱을 통해 서비스를 이용할 것이다.
  • TMC-AR-006: 관리자는 백엔드 관리 도구를 통해 시스템을 모니터링할 것이다.
  • TMC-AR-007: 테스터는 별도의 Web Chat 서비스를 통해 dayIndex 기반으로 시간 변경 기능을 사용할 것이다.
  • TMC-AR-008: 앱은 TimeMachine의 존재를 인식하지 않고 Backend에서 제공하는 시간만 사용할 것이다.
  • TMC-AR-009: 각 사용자는 자신만의 독립적인 가상 시간을 가질 것이다.
  • TMC-AR-010: 사용자는 고유 식별자를 통해 구분될 것이다.
  • TMC-AR-011: 사용자는 앱에서 TimeMachine 기능을 켜고 끌 수 있는 옵션을 가질 것이다.
  • TMC-AR-012: TimeMachine 기능이 비활성화된 경우, 사용자는 실제 시간을 사용할 것이다.
  • TMC-AR-013: PROD 환경에서는 일반 사용자에게 TimeMachine 기능이 노출되지 않을 것이다.
  • TMC-AR-014: TimeMachine 기능은 주로 개발 및 테스트 환경에서 사용될 것이다.
  • TMC-AR-015: dayIndex 및 "일시 정지 기간 중 날짜" 계산에 필요한 사용자 주기 시작일 및 상세 정지 이력 정보는 User 도메인에서 안정적으로 제공받을 수 있다.

5. 의존성

5.1 내부 의존성

  • TMC-DR-001: 시스템은 User 도메인에 의존할 것이다 (사용자의 타임존 정보, UserCycle 시작일 및 UserSuspensionHistory(치료 활동 일시 정지 이력) 상세 정보 조회).
  • TMC-DR-002: 시스템은 IAM 도메인에 의존할 것이다.
  • TMC-DR-003: 시스템은 Audit 도메인에 의존할 것이다.
  • TMC-DR-004: 시스템은 Healthcare 도메인에 의존할 것이다.

5.2 외부 의존성

  • TMC-DR-005: 시스템은 GCP Pub/Sub 서비스에 의존할 것이다.
  • TMC-DR-006: 시스템은 Redis 캐시 서비스에 의존할 것이다.
  • TMC-DR-007: 시스템은 PostgreSQL 데이터베이스에 의존할 것이다.
  • TMC-DR-008: 시스템은 Kubernetes 클러스터에 의존할 것이다.
  • TMC-DR-009: 시스템은 Web Chat 서비스에 의존할 것이다.

6. 구현 우선순위

기본 기능 (우선순위 높음)

  1. 기본 가상 시간 조회/설정 API
  2. GCP Pub/Sub 연동 - 날짜 변경 이벤트 발행
  3. 기본 인증/인가
  4. 과거 시점 이동 시 데이터 처리 기본 기능
  5. Web Chat 서비스 연동
  6. 사용자별 가상 시간 관리 기본 기능
  7. TimeMachine 기능 활성화/비활성화 API 및 앱 UI

고도화 기능 (우선순위 중간)

  1. 이벤트 구독 및 처리 고도화
  2. 데이터 롤백 기능 개선
  3. 모니터링 시스템
  4. 관리자 도구
  5. 사용자별 가상 시간 관리 고도화
  6. TimeMachine 기능 활성화/비활성화 이력 관리 및 통계

확장 기능 (우선순위 낮음)

  1. 성능 최적화
  2. 고급 보안 기능
  3. 미래 시점 데이터 처리 고도화
  4. 자동화된 테스트 시나리오 지원
  5. 대규모 사용자 지원을 위한 확장성 개선

7. 용어 정의

용어설명
가상 시간TimeMachine이 관리하는 테스트용 시간 (UTC 타임스탬프 + Timezone ID)
시간 이동가상 시간을 특정 dayIndex에 해당하는 날짜/시간으로 변경하는 행위
dayIndex사용자의 치료 주기 내에서의 상대적인 일차 (1부터 시작, 중단 기간 제외)
데이터 롤백과거 시점(낮은 dayIndex)으로 이동 시 미래 데이터를 처리하는 작업
이벤트 발행날짜 변경 시 GCP Pub/Sub으로 메시지를 보내는 행위
프로그램 언락시간 변경(dayIndex 변경)에 따라 사용자의 학습 프로그램을 이용 가능한 상태로 만드는 것
Web Chat 서비스테스터가 시간 변경(dayIndex 기반) 기능을 사용할 수 있는 별도의 웹 기반 인터페이스
사용자별 가상 시간각 사용자마다 독립적으로 관리되는 별도의 가상 시간
TimeMachine 활성화/비활성화사용자가 가상 시간 기능을 켜고 끌 수 있는 상태를 나타내는 기능

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

8.1 가상 시간 데이터

백엔드 요구사항

  • TMC-FR-BE-051: 시스템은 가상 시간 데이터를 보호해야 한다.
    • 사용자별 가상 시간 격리
    • 테스트 데이터 익명화
    • 롤백 데이터 처리 정책
    • 테스트 완료 후 데이터 삭제
  • TMC-FR-BE-052: 시스템은 시간 조작 기록을 관리해야 한다.
    • 시간 변경 이력 보호
    • 테스트 목적 명시
    • 개인정보 영향 평가
    • 데이터 복원 추적

9. ISO27001 정보보호 관리

9.1 시간 조작 보안

백엔드 요구사항

  • TMC-NFR-021: 시스템은 가상 시간 변경을 통제해야 한다.
    • 가상 시간 변경 권한 통제
    • 데이터 롤백 무결성 보장
    • 시간 변경 감사 로그
    • 테스트 환경 격리
  • TMC-NFR-022: 시스템은 데이터 일관성을 보장해야 한다.
    • 시간 변경 시 데이터 정합성
    • 이벤트 순서 보장
    • 롤백 시 무결성 검증
    • 복구 메커니즘

10. 변경 이력

버전날짜작성자변경 내용
0.1.02025-04-01bok@weltcorp.com최초 작성
0.2.02025-06-02bok@weltcorp.com시스템 날짜 변경 감지 및 SystemDayChanged 이벤트 발행 요구사항 추가
0.3.02025-08-07bok@weltcorp.com요구사항 ID 체계 적용 - TMC 도메인 코드 적용 (TMC-FR-BE-xxx, TMC-FR-FE-xxx, TMC-NFR-xxx, TMC-CR-xxx, TMC-AR-xxx, TMC-DR-xxx)
0.4.02025-08-12bok@weltcorp.comGDPR 및 ISO27001 컴플라이언스 요구사항 추가 (섹션 8, 9) - 가상 시간 데이터 보호, 시간 조작 보안