Sleep 도메인 요구사항

1. 기능 요구사항

참고: 본 도메인의 모든 기능 요구사항에서 시간 관련 처리(타임스탬프, 기간 계산, 날짜 비교 등)는 반드시 TimeMachine 도메인이 제공하는 현재 시간(가상 또는 실제)을 기준으로 수행되어야 합니다. 시스템 시간을 직접 사용해서는 안 됩니다. (제약사항 3.6 참조)

1.1 수면 기록 관리

백엔드 요구사항

• SLP-FR-BE-001: 시스템은 사용자의 일일 수면 기록을 저장하고 관리할 수 있어야 한다.
  • 수면 기록 항목: 수면 여부(DNS), 잠자리에 든 시각, 일어난 시각, 수면 중 깬 시간 총합, 긍정적/부정적 영향 요인(텍스트 배열, 각 요인 유형별 자유 입력 최대 10개), 수면제 복용 여부, 낮잠 총 시간, 수면의 질(Enum).
    • DNS(Did Not Sleep) 선택 시 필수 입력 항목:
      • 수면 여부(dns = true)
      • 수면에 부정적인 영향을 준 요인(negativeFactorIds)
      • 수면제 복용 여부(pill)
      • 낮잠을 잔 시간(napMinutes)
    • 잠을 잤을 경우(dns = false) 필수 입력 항목:
      • 수면의 질(SE)
      • 잠자리에 든 시각(LOT) - 눈을 감고 잠을 청한 시각(LOT)
      • 일어난 시각(AET) - 잠에서 깬 시각(AET)
      • 잠들기까지 걸린 시간(SOL, 기본값: 0분)
      • 수면 중 깬 시간 총합(WASO, 기본값: 0분)
      • 수면에 부정적인 영향을 준 요인(negativeFactorIds)
      • 수면에 긍정적인 영향을 준 요인(positiveFactorIds)
      • 수면제 복용 여부(pill)
      • 낮잠을 잔 시간(napMinutes)
    • 긍정적 영향 요인 목록:
      • 없다
      • 야외에서의 운동
      • 좋은 기분
      • 낮 동안의 햇빛
      • 이완 운동
      • 편안한 저녁 루틴
      • 따뜻한 차 한 잔
      • 그 외 (자유 입력, 최대 10개, 각 입력별로 최대 100자 까지 저장 가능)
    • 부정적 영향 요인 목록:
      • 없다
      • 스트레스나 걱정
      • 늦은 시간까지 일하거나 활동
      • 저녁에 카페인/알코올 섭취
      • 통증이나 불편함
      • 불안한 수면 환경 (빛, 소음, 더위)
      • 집고양이의 갑작스러운 달리기 발작
      • 그 외 (자유 입력, 최대 10개, 각 입력별로 최대 100자 까지 저장 가능)
  • 수면 기록 수정 요구사항:
    • 수면 기록 생성 시에는 위에 명시된 필수 입력 항목들이 모두 유효성 검증을 통과해야 한다.
    • 수면 기록 수정 시에는 부분 업데이트(Partial Update)가 지원되어야 하며, 사용자가 변경하고자 하는 특정 필드만 전송하여 업데이트할 수 있어야 한다.
    • 수정 API는 변경된 필드만 검증하고 업데이트해야 한다.
    • 수면 여부(dns) 필드를 변경할 경우에는 해당 상태에 맞는 필수 입력 항목 검증을 다시 적용해야 한다.
    • 수면 여부(dns)를 false에서 true로 변경하는 경우, DNS에 필요한 데이터(부정적 영향 요인, 수면제 복용 여부, 낮잠 시간) 이외의 모든 항목(수면의 질, 잠자리에 든 시각, 일어난 시각, 잠들기까지 걸린 시간, 수면 중 깬 시간 총합, 긍정적 영향 요인, 계산된 수면 지표 등)은 자동으로 초기화(null 또는 기본값으로 설정)되어야 한다.
    • 수정은 3.8 제약사항에 명시된 대로 기록 당일 자정까지만 가능하다.
  • 수면 기록 시간 검증 요구사항:
    • 시스템은 수면 기록 생성 및 수정 시마다 다음과 같은 시간 관련 검증을 수행해야 한다:
      • AET(일어난 시각)는 LOT(잠자리에 든 시각)보다 이전일 수 없다. (AET > LOT)
      • SE(수면 효율)는 1.0을 넘을 수 없다. (0 ≤ SE ≤ 1.0)
      • LOT(잠자리에 든 시각)는 18:00 이후여야 한다.
    • 위 조건 중 하나라도 충족하지 않는 경우, 시스템은 해당 요청을 거부하고 적절한 오류 메시지를 반환해야 한다.
    • 검증 오류 발생 시 어떤 항목이 유효하지 않은지와 허용 가능한 값의 범위를 명확히 안내해야 한다.
  • 임시 수면 기록 요구사항:
    • 시스템은 웨어러블 장치나 AI와의 대화를 통해 부분적으로 수집된 수면 데이터를 임시 수면 기록으로 저장할 수 있어야 한다.
    • 임시 수면 기록은 일부 필수 필드가 누락되어도 저장이 가능해야 하며, 이를 위한 별도의 상태 플래그(isTemporary = true)를 포함해야 한다.
    • 임시 수면 기록에는 최소한 다음 정보 중 하나 이상이 포함되어야 한다:
      • 잠자리에 든 시각(lot)
      • 일어난 시각(sleepEndTime)
      • 수면의 질(sleepQuality)
      • 수면제 복용 여부(pill)
    • 임시 수면 기록은 사용자가 나머지 필수 정보를 입력하면 완전한 수면 기록으로 전환되어야 한다.
    • 임시 수면 기록이라도 취침(lot) 또는 기상(sleepEndTime) 시각 정보가 포함되어 있다면, 해당 정보를 기반으로 수면 목표 달성 여부 계산에 부분적으로 포함해야 한다. 두 시각 모두 있을 경우 완전한 목표 달성 평가를, 하나만 있을 경우 해당 항목에 대한 부분 평가를 진행한다.
    • 웨어러블 장치로부터 수집된 수면 데이터가 있는 경우, 사용자가 수면 기록을 작성할 때 이를 기본값으로 제시하여 사용자 입력을 보조해야 한다.
    • 임시 수면 기록도 수정은 당일 자정까지만 가능하며, 삭제 기능은 제공하지 않는다.
  • 수면 효율 계산 요구사항:
    • 시스템은 수면 기록 생성 및 수정 시 수면 효율(SE, Sleep Efficiency)을 즉시 계산하여 저장해야 한다.
    • 수면 효율은 총 수면 시간(TST)을 침대에 있던 총 시간(TIB)으로 나눈 값으로 계산된다.
    • TST = AET - (LOT + SOL) - WASO 공식을 사용하여 계산한다. (AET: 일어난 시각, LOT: 잠자리에 든 시각, SOL: 잠들기까지 걸린 시간, WASO: 수면 중 깬 시간 총합)
    • TIB = AET - LOT 공식을 사용하여 계산한다.
    • 수면 효율은 0과 1 사이의 소수점 두 자리까지의 값으로 정규화하여 저장해야 한다.
    • DNS(Did Not Sleep) 기록의 경우 수면 효율은 null로 설정한다.
• SLP-FR-BE-002: 시스템은 수면 기록(SleepLog)이 저장될 때마다 해당 날짜의 수면 목표(SleepGoal)를 확인하고, 목표 달성 여부(SleepGoalAdherence)를 즉시 계산하여 저장/업데이트해야 한다.
• SLP-FR-BE-003: 시스템은 사용자의 주차별 수면 데이터를 계산하고 제공할 수 있어야 한다. 주차는 연속된 7일 단위이며, 시작 일차(dayIndex)를 기준으로 해당 일차부터 7일간의 데이터를 의미한다.
  • 주차별 일간 수면 시간 (잠자리에 든 시각 ~ 일어난 시각), 각 데이터는 일차별로 제공되어야 한다.
  • 주차별 취침/기상 목표 준수 횟수.
  • 주차별 일간 잠들지 못한 시간 (잠들기까지 걸린 시간 + 도중에 깬 시간), 각 데이터는 일차별로 제공되어야 한다.
  • 주차별 평균 잠들기까지 걸린 시간 및 평균 도중에 깬 시간.
  • 주차별 수면의 질 통계 (각 수면의 질 등급별 빈도수 및 비율).
  • 주차별 총 수면 시간(TST) 통계 (평균, 최소, 최대, 일차별 데이터).
  • 주차별 수면제 복용 빈도 및 패턴 (복용 일수, 복용 비율).
  • 주차별 SOL(잠들기까지 걸린 시간) 통계 (평균, 최소, 최대, 일차별 데이터).
  • 주차별 낮잠 시간 통계 (평균, 총합, 일차별 데이터).
  • 주차별 수면 영향 요인 통계 (긍정적/부정적 요인별 빈도수 및 비율).
  • 모든 주차별 데이터 조회 API에는 시작 일차(dayIndex) 파라미터가 포함되어야 한다.
• SLP-FR-BE-004: 백엔드 시스템은 앱의 7일 단위 표시 외에도 다양한 기간 범위로 데이터를 조회할 수 있는 유연한 API를 제공해야 한다.
  • 사용자의 전체 치료 주기에 걸친 데이터 조회가 가능해야 한다.
  • 특정 일차 범위(예: 10-30일차)를 지정하여 조회할 수 있어야 한다.
  • 월별, 분기별 등 다양한 시간 단위로 집계된 통계 데이터를 제공할 수 있어야 한다.
  • 이러한 유연한 범위의 데이터 조회는 특히 데이터 분석 및 관리 목적으로 중요하다.
  • 앱의 사용자 인터페이스는 주로 7일 단위로 최적화되어 있지만, 백엔드 API는 더 다양한 범위의 데이터 접근을 지원해야 한다.
• SLP-FR-BE-005: 시스템은 오늘의 수면 기록 요약 정보(누워있던 시간, 잠자리 든 시각, 일어난 시각)를 제공할 수 있어야 한다.
• SLP-FR-BE-006: 시스템은 rTib 알고리즘 계산에 필요한 데이터(TST, SE, DSE 등)를 수면 기록 기반으로 계산할 수 있어야 한다. (1.2 연관)
• SLP-FR-BE-007: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 수면 목표 준수 여부를 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 결과에는 각 일차별 목표 취침/기상 시각과 실제 취침/기상 시각, 목표 달성 여부가 포함되어야 한다.
  • 목표 달성 기준(±30분)을 적용하여 달성 여부를 계산해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
• SLP-FR-BE-008: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 수면 효율(SE) 지표를 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 수면 효율 수치와 범주(Poor, Moderate, Good)를 함께 제공해야 한다.
  • 수면 효율 계산에 사용된 상세 데이터(TST, TIB 등)도 요청 시 함께 제공할 수 있어야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
• SLP-FR-BE-009: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 수면의 질(Sleep Quality) 데이터를 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 수면의 질 데이터(Enum 값)를 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
  • DNS(Did Not Sleep) 기록에 대해서는 수면의 질 정보가 없음을 명확히 표시해야 한다.
• SLP-FR-BE-010: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 총 수면 시간(Total Sleep Time, TST)을 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 총 수면 시간(분 단위)을 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
  • DNS(Did Not Sleep) 기록에 대해서는 총 수면 시간이 0분임을 명확히 표시해야 한다.
• SLP-FR-BE-011: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 수면제 복용 여부(pill)를 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 수면제 복용 여부(Boolean)를 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
• SLP-FR-BE-012: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 잠들기까지 걸린 시간(SOL, Sleep Onset Latency)을 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 잠들기까지 걸린 시간(분 단위)을 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
  • DNS(Did Not Sleep) 기록에 대해서는 SOL 정보가 없음을 명확히 표시해야 한다.
• SLP-FR-BE-013: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 낮잠 시간(napMinutes)을 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 낮잠 시간(분 단위)을 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
• SLP-FR-BE-014: 시스템은 사용자가 치료 주기 일차(dayIndex)별로 수면에 영향을 미친 요인(긍정적/부정적)을 조회할 수 있는 API를 제공해야 한다.
  • 조회는 주차(7일) 단위로 이루어져야 하며, 각 일차별 긍정적 영향 요인(positiveFactorIds) 및 부정적 영향 요인(negativeFactorIds)을 제공해야 한다.
  • API는 시작 일차(dayIndex)를 입력받아 해당 일차부터 최대 7일(또는 가용한 데이터) 범위의 정보를 일차별로 반환해야 한다.
  • 자유 입력된 요인도 함께 제공해야 한다.
  • DNS(Did Not Sleep) 기록에 대해서는 긍정적 영향 요인 정보가 없음을 명확히 표시해야 한다.

프론트엔드 요구사항

TBD

1.1.1 치료 일시 정지와 수면 기록 관리

백엔드 요구사항

• SLP-FR-BE-015: 시스템은 User 도메인에서 제공하는 사용자의 치료 활동 일시 정지 상태 정보를 확인하고, 일시 정지 상태에서는 수면 기록 생성 및 수정을 제한해야 한다.
• SLP-FR-BE-016: 시스템은 수면 기록에 치료 주기 일차(dayIndex) 정보를 저장해야 한다. 이 dayIndex는 User 도메인에서 제공한다.
• SLP-FR-BE-017: 시스템은 수면 기록 조회 시 치료 주기 일차(dayIndex) 정보와 함께 해당 일차에 해당하는 실제 달력상 날짜 정보도 함께 제공해야 한다.
• SLP-FR-BE-018: 시스템은 User 도메인으로부터 제공받은 dayIndex를 기반으로 수면 데이터 분석 및 시각화를 수행해야 한다. 특히 rTIB 계산 및 차트 표시에서는 단순 날짜 순서가 아닌 치료 주기 일차 순서로 데이터를 처리해야 한다.
• SLP-FR-BE-019: 시스템은 수면 기록이 생성될 때마다 해당 사용자의 치료 활동 일시 정지 여부를 확인하고, 일시 정지 상태가 아닌 경우에만 기록을 허용해야 한다.
• SLP-FR-BE-020: 치료 일시 정지와 주차 단위 조회 예시:
  • 주차 단위 데이터 조회 시 일시 정지 기간은 무시되며, dayIndex 기준으로 연속된 치료 일차를 하나의 주차로 처리한다.
  • 예시 1: 사용자가 1-5일차까지 기록 - 3일간 일시 정지 - 6-10일차 기록 상태에서
    • startDayIndex=1로 주차 조회 시: 1, 2, 3, 4, 5, 6, 7일차 데이터를 반환한다.
    • 여기서 6, 7일차는 일시 정지 이후의 실제 날짜이지만, dayIndex 기준으로 연속된 7일로 처리된다.
  • 예시 2: 사용자가 1-3일차 기록 - 10일간 일시 정지 - 4-12일차 기록 상태에서
    • startDayIndex=1로 주차 조회 시: 1, 2, 3, 4, 5, 6, 7일차 데이터를 반환한다.
    • 이때 4-7일차는 실제 달력상으로는 1-3일차와 10일 이상 떨어져 있지만, 치료 주기 일차 기준으로 연속된 데이터로 처리된다.
  • 이러한 방식으로 시스템은 실제 날짜의 연속성이 아닌 치료 진행의 연속성을 기준으로 주차 데이터를 구성하여 제공한다.

프론트엔드 요구사항

TBD

1.1.2 관리자 및 서비스 계정의 수면 데이터 접근

백엔드 요구사항

• SLP-FR-BE-021: 시스템은 적절한 권한을 가진 다른 역할의 사용자(System Admin, IAM Admin, Service Account 등)가 데이터 분석, 품질 관리, 연구 등의 목적으로 사용자의 수면 데이터에 접근할 수 있도록 해야 한다.
• SLP-FR-BE-022: 시스템은 다음과 같은 역할별 접근 범위를 지원해야 한다:
  • System Admin: 모든 사용자의 수면 기록, 수면 목표, rTIB 처방 데이터 등 전체 수면 도메인 데이터에 접근 가능.
  • IAM Admin: 관리 권한이 할당된 범위 내 사용자들의 수면 기록, 수면 목표 데이터에 접근 가능.
  • Service Account: 할당된 권한에 따라 API를 통해 특정 사용자 또는 익명화된 집계 데이터에 접근 가능.
• SLP-FR-BE-023: 시스템은 다음과 같은 데이터 접근 API를 제공해야 한다:
  • 특정 사용자 또는 사용자 그룹의 모든 수면 기록 조회
  • 특정 기간 동안의 수면 기록 통계 및 집계 데이터 조회
  • 사용자별 rTIB 처방 이력 및 수면 목표 달성률 조회
  • 수면 영향 요인 분포 및 트렌드 분석 데이터 조회
• SLP-FR-BE-024: 시스템은 관리자와 서비스 계정을 위해 특히 유연한 데이터 조회 옵션을 제공해야 한다:
  • 사용자의 전체 치료 주기에 걸친 모든 수면 데이터 조회
  • 여러 사용자 또는 그룹 간의 비교 분석을 위한 데이터 추출
  • 특정 조건(수면 효율, 수면제 복용 여부 등)에 따른 필터링 및 집계 기능
  • 일별, 주별, 월별, 분기별 등 다양한 시간 단위로 데이터 집계 및 분석
  • 치료 일차(dayIndex) 기준으로 특정 기간(예: 치료 초기 vs 후기)에 따른 데이터 비교 분석
  • 특정 기간 동안의 rTIB 변화 추세 및 수면 패턴 변화 분석
• SLP-FR-BE-025: 시스템은 관리자 및 서비스 계정의 데이터 접근에 대해 상세한 감사 로그를 기록해야 한다. (Audit 도메인 의존)
• SLP-FR-BE-026: 시스템은 데이터 분석 목적으로 익명화된 데이터 추출 API를 제공해야 한다.
• SLP-FR-BE-027: 모든 데이터 접근은 IAM 도메인에서 정의한 권한 체계를 따라야 하며, 최소 권한 원칙을 준수해야 한다.

프론트엔드 요구사항

TBD

1.2 수면 목표(rTIB) 관리

백엔드 요구사항

• SLP-FR-BE-028: rTIB 계산 및 처방:
  • 시스템은 7일 주기로 사용자별 rTIB(Recommended Time In Bed)를 계산해야 한다. (제약사항 3.1 참조)
  • 최초 rTIB 계산 및 제공:
    • 최초 rTIB 계산을 위해 최소 4개의 유효한 수면 기록이 필요하다.
    • 기본적으로 8일차(D-8)가 최초 rTIB 제공의 기준일이다.
    • 사용자가 1일차부터 7일차까지 4개 이상의 유효한 수면 기록을 작성한 경우, 8일차에 최초 rTIB가 제공된다.
    • 1일차부터 7일차까지 4개 미만의 수면 기록을 작성한 경우, 총 4개의 유효한 기록이 작성될 때까지 rTIB 제공이 지연된다. (예: 16일차에 총 4개가 작성되면 17일차에 최초 rTIB가 제공됨)
  • 후속 rTIB 제공:
    • rTIB는 최초 rTIB 제공 날짜를 기준으로 7일 주기로 제공된다.
    • 이상적인 경우의 제공 주기: 8일차 → 15일차 → 22일차 → 29일차 등.
    • 최초 rTIB 제공이 지연된 경우에도 이후 rTIB는 최초 제공일 기준으로 7일 주기를 유지한다. (예: 17일차에 최초 rTIB를 받았다면, 이후 rTIB는 24일차, 31일차 등에 제공)
  • 데이터 활용 규칙:
    • 시스템은 최근 7일간의 유효한 수면 기록을 기반으로 avgTST, avgSE, avgDSE를 계산해야 한다. (제약사항 3.2, 3.3 참조)
    • 주간 데이터 사용 원칙:
      • 특정 주에 5개 이상의 유효한 수면 기록이 있는 경우, 해당 주의 모든 데이터를 사용하여 rTIB를 계산한다. (예: 9-15일차에 총 6개의 기록이 있다면 6개 모두 사용)
      • 특정 주에 5개 미만의 유효한 수면 기록이 있는 경우, 이전 주의 데이터를 포함하여 최대 5개의 가장 최근 데이터를 사용한다.
    • 유효 기록 정의: DNS(Did Not Sleep) 및 TST > 720분 기록은 평균 계산에서 제외된다.
    • 평균 계산: 유효한 기록의 합 / 유효한 일수. 소수점 셋째 자리에서 반올림하여 두 자리까지 표현한다.
  • rTIB 계산 알고리즘:
    • 시스템은 계산된 avgSE를 기준으로 수면 효율 범주(Good, Poor, Moderate)를 판별해야 한다.
    • 시스템은 수면 효율 범주에 따라 rTIB 계산 공식을 적용해야 한다.
      • Good SE (avgSE ≥ 0.95): rTib = avgDSE
      • Poor SE (avgSE ≤ 0.87): rTib = avgTST
      • Moderate SE (0.87 < avgSE < 0.95): rTib = avgTST + (avgDSE - avgTST) * (avgSE - 0.87) * 10
  • rTIB 조정 제한:
    • 새로 계산된 rTIB 값은 이전 계산값에서 최대 ±30분 범위 내에서만 변경될 수 있다. 단, 최초 rTIB 계산 시에는 이 제한이 적용되지 않는다.
    • 이는 사용자가 새로운 수면 스케줄에 점진적으로 적응할 수 있도록 하기 위한 것이다.
  • 시스템은 rTIB 값을 최소 270분(4.5시간)에서 최대 600분(10시간) 범위로 제한해야 한다. (제약사항 3.16 참조)
  • 시스템은 최종 산출된 rTIB를 15분 단위로 올림해야 한다. (제약사항 3.4 참조)
  • rTIB 계산 트리거:
    • 시스템은 매일 밤 조건을 만족하는 모든 사용자를 대상으로 rTIB 계산 및 처방 로직을 수행해야 한다. (배치 작업은 시스템의 해당 로컬 시간대 기준 00:00에 실행)
      • 단, 해당 날짜에 수면 기록 작성 시점에 이미 rTIB가 계산된 사용자는 배치 작업 대상에서 제외한다.
      • 배치 작업은 당일에 rTIB 계산이 되지 않은 사용자들에 대해서만 수행되어야 한다.
    • 사용자가 수면 기록을 작성하는 시점에 rTIB 계산:
      • 시스템은 사용자가 수면 기록을 작성하여 저장하는 시점에 해당 사용자가 rTIB 계산 조건을 만족하는지 확인하고, 조건 충족 시 즉시 새로운 rTIB를 계산하여 제공해야 한다.
      • rTIB 계산 조건:
        • 최초 rTIB의 경우, 4개 이상의 유효 기록이 누적된 경우 (사용 8일차 이후)
        • 후속 rTIB의 경우, 직전 rTIB 제공일로부터 7일이 경과했으며, 해당 기간 내 5개 이상의 유효 기록이 있는 경우 (또는 기록이 5개 미만이면, 이전 기록을 포함해 최대 5개 이상의 유효 기록이 있는 경우)
        • 직전 rTIB 제공일로 부터 7일이 경과했을 때 rTIB 계산 조건에 부합하지 않으면 이후 7일 동안은 직전 rTIB를 유지한다.
      • 계산 로직은 배치 작업에서 사용하는 것과 동일하게 적용한다.
      • 계산된 새로운 rTIB는 즉시 저장되고, 사용자에게 알림을 통해 새로운 수면 목표가 설정되었음을 알려야 한다.
      • 생성된 수면 목표의 type은 ALGORITHM으로 설정한다.
    • 사용자가 특정 날짜의 수면 목표 정보를 요청했을 때 처리 로직:
      • 만약 해당 날짜의 수면 목표 정보가 야간 배치 작업을 통해 이미 계산 및 저장되어 있다면, 저장된 값을 반환한다.
      • 만약 배치 작업이 아직 완료되지 않았거나 실패하여 정보가 없다면, 시스템은 실시간으로 해당 날짜의 수면 목표를 계산하여 응답해야 한다. 이때의 계산 로직은 다음과 같다:
        • rTIB 재계산 조건 충족 시 (예: 7일 주기 도래 및 유효 데이터 충족 등 1.2의 'rTIB 제공 규칙'에 명시된 조건 만족 시):
          • 새로운 rTIB(분)를 계산한다.
          • 사용자가 설정/유지한 목표 기상 시각을 고정하고, 계산된 rTIB에 맞춰 새로운 목표 취침 시각을 조정한다.
          • 생성된 수면 목표의 type을 ALGORITHM으로 설정한다.
        • rTIB 재계산 조건 미충족 시 (예: 7일 주기 사이의 날짜):
          • 전날의 수면 목표 시간(취침/기상 시각)을 그대로 사용하되, 날짜만 요청된 날짜로 설정한다.
          • 생성된 수면 목표의 type을 SYSTEM으로 설정한다.
  • 시스템은 rTIB 처방 시, 해당 계산에 사용된 수면 데이터 기간 내 median AET(Asleep End Time)를 기반으로 목표 기상/취침 시각을 함께 제안해야 한다. (제약사항 3.5 참조)
• SLP-FR-BE-029: rTIB 제공 규칙:
  • 시스템은 앱 사용 시작 후 첫 7일차까지는 rTIB가 적용되지 않는다.
  • rTIB 계산 시점은 다음과 같은 조건과 상황에 따라 결정된다:
    • 7일차에 수면 기록을 작성하고 조건(4개 이상의 유효 기록)을 충족하는 경우: 수면 기록 작성 시점에 즉시 rTIB가 계산된다.
    • 7일차에 수면 기록을 작성하지 않거나 조건을 충족하지 못한 경우: 8일차 00:00의 배치 작업에서 조건 충족 여부를 다시 확인한다.
    • 이후에도 조건을 충족하지 못하는 경우: 추가 수면 기록 작성 시점 또는 후속 배치 작업에서 조건 충족 시 계산된다.
    • 어떤 경우든 계산된 rTIB는 계산 시점의 다음 일차부터 적용된다 (예: 7일차에 계산되면 8일차부터, 10일차에 계산되면 11일차부터 적용).
  • 최초 rTIB 계산 시: 사용 1~7일 사이 기록이 4개 이상이면 해당 기록 전체 사용. 4개 미만이면 4번째 기록 작성 시점까지 기다려야 한다.
  • 이후 rTIB 계산 시: 직전 rTIB 제공일로부터 7일간의 기록 사용. 해당 기간 기록이 5개 이상이면 모두 사용. 5개 미만이면 이전 기록 중 최신 기록을 포함하여 최대 5개 사용.
  • 시스템은 최초 rTIB 제공일 기준 +7일 간격으로 후속 rTIB를 제공해야 한다.
• SLP-FR-BE-030: rTIB 처방 및 적용 흐름:
  • 사용자가 7일차에 수면 기록을 작성하면, 최소 4개 이상의 유효한 수면 기록이 확보된 경우 즉시 rTIB가 계산되어야 한다.
  • 계산된 rTIB는 8일차부터 적용될 수면 목표를 위한 것이다.
  • 사용자는 7일차에 처방받은 rTIB에 대해 목표 기상 시각을 설정할 수 있으며, 이렇게 설정된 목표는 8일차부터 적용된다.
  • 이 흐름은 이후 rTIB 계산 주기에도 동일하게 적용된다. 즉, N일차에 rTIB 처방을 받으면 (N+1)일차부터 적용된다.
• SLP-FR-BE-031: 데이터 부족 시 처리:
  • 시스템은 7일차에 수면 기록이 4개 미만인 경우, 총 4개의 유효한 수면 기록이 쌓일 때까지 rTIB 계산 및 제공을 보류해야 한다.
  • 후속 rTIB 계산 시(7일 주기), 해당 주에 수면 기록이 5개 미만인 경우 이전 주의 데이터를 포함하여 최대 5개의 최신 수면 기록을 활용해 rTIB를 계산해야 한다.
  • 데이터 부족으로 rTIB 계산이 지연될 경우, 사용자에게 적절한 알림을 제공하여 수면 기록 작성을 독려해야 한다.
• SLP-FR-BE-032: 목표 시간 관리:
  • 시스템은 사용자가 rTIB를 처방받은 당일에 한해 목표 기상 시각을 변경할 수 있도록 허용해야 한다. 단, 처방된 rTIB(총 목표 수면 시간, 분 단위) 자체는 변경할 수 없으며, 목표 기상 시각을 변경하면 시스템은 해당 rTIB를 유지하면서 목표 취침 시각을 자동으로 재계산하여 설정해야 한다. (예: rTIB가 420분이고 목표 기상 시각을 07:00으로 설정하면, 목표 취침 시각은 자동으로 00:00으로 설정됨)
  • 시스템은 사용자가 목표 시각을 변경하지 않으면 기존 설정된 기상 시각을 유지하여 목표 취침/기상 시각을 설정해야 한다.
  • 시스템은 설정된 수면 목표(기상/취침 시각)를 다음 rTIB 처방일까지 유지해야 한다.
• SLP-FR-BE-033: 피드백 및 변화량 관리:
  • 시스템은 rTIB 산출 시 이전 값과 비교하여 큰 변화가 없을 경우 긍정적 피드백 메시지를 생성할 수 있어야 한다.
  • 시스템은 데이터 부족으로 rTIB 설정이 지연될 경우 안내 메시지를 생성할 수 있어야 한다.
  • (옵션) 시스템은 ESS(Epworth Sleepiness Scale) 점수 변화를 반영하여 rTIB를 조정하는 로직을 포함할 수 있다. (알고리즘 D.4 참조)
  • (옵션) 시스템은 사용자의 주간 졸림 정도 피드백에 따라 rTIB 조정 협상(+15분 window) 기능을 제공할 수 있다.
• SLP-FR-BE-034: 알림:
  • 시스템은 사용자의 목표 기상 시각이 되면 푸시 알림을 보내야 한다. (알림 도메인 의존)
  • 시스템은 사용자의 목표 취침 시각 1시간 전에 푸시 알림을 보내야 한다. (알림 도메인 의존)

프론트엔드 요구사항

TBD

1.3 개인정보 및 GDPR 데이터 처리

백엔드 요구사항

• SLP-FR-BE-035: 시스템은 GDPR 및 국내 개인정보보호법을 준수하는 수면 데이터 처리 메커니즘을 구현해야 한다.
• SLP-FR-BE-036: 데이터 아카이빙 처리:
  • 시스템은 비활성 사용자의 데이터를 자동으로 식별하고 아카이빙하는 배치 작업을 구현해야 한다.
  • 비활성 사용자 기준: 최근 6개월간 앱에 로그인하지 않았거나, 치료 종료 후 6개월이 경과한 사용자.
  • 아카이빙 대상 데이터: 수면 기록, 수면 목표, rTIB 계산 이력, 수면 영향 요인 등 모든 수면 관련 데이터.
  • 아카이빙은 다음과 같은 단계로 진행된다:
    1. 비활성 사용자 식별 및 'inactive' 플래그 설정 (6개월 경과 시점)
    2. 주 데이터베이스에서 데이터 추출 및 콜드 스토리지로 이전 (비활성 상태 1년 경과 시점)
    3. 콜드 스토리지 데이터 압축 및 암호화
    4. 주 데이터베이스에서 데이터 삭제 (단, 사용자 식별 정보 및 최소한의 메타데이터는 유지)
• SLP-FR-BE-037: 데이터 복원 메커니즘:
  • 시스템은 아카이빙된 사용자가 다시 서비스를 이용할 경우 자동 복원 프로세스를 구현해야 한다.
  • 복원 프로세스는 다음 단계로 이루어진다:
    1. 사용자 로그인 시 아카이빙 상태 확인
    2. 아카이빙된 데이터가 있는 경우 콜드 스토리지에서 데이터 추출
    3. 데이터 복호화 및 압축 해제
    4. 주 데이터베이스로 데이터 복원
    5. 사용자에게 데이터 복원 알림 제공
  • 복원된 데이터는 이전 치료 주기와 현재 치료 주기를 명확히 구분할 수 있도록 메타데이터를 포함해야 한다.
• SLP-FR-BE-038: 개인정보 파기 및 익명화:
  • 사용자 탈퇴 또는 데이터 삭제 요청 시 시스템은 다음과 같은 프로세스를 수행해야 한다:
    1. 주 데이터베이스와 콜드 스토리지에서 해당 사용자의 개인 식별 정보 삭제
    2. 수면 데이터는 익명화하여 통계 및 연구 목적으로 보관 (사용자가 완전 삭제를 요청한 경우 제외)
    3. 삭제 작업 수행 기록을 감사 로그에 저장
  • 데이터 보관 기간(5년) 경과 후 자동 삭제 프로세스를 구현해야 한다.
• SLP-FR-BE-039: 데이터 추출 및 이동성:
  • 시스템은 사용자가 요청할 경우 자신의 모든 수면 데이터를 표준 형식(JSON, CSV)으로 추출할 수 있는 API를 제공해야 한다.
  • 데이터 추출 요청은 적절한 인증을 거친 후에만 처리되어야 한다.
  • 추출된 데이터는 압축 및 암호화하여 안전하게 전송되어야 한다.
• SLP-FR-BE-040: 관리자 도구:
  • 시스템은 데이터 보관 정책을 관리하고 모니터링할 수 있는 관리자 도구를 제공해야 한다.
  • 관리자 도구는 다음 기능을 포함해야 한다:
    1. 아카이빙 대상 사용자 목록 조회 및 수동 아카이빙 실행
    2. 아카이빙 작업 로그 및 상태 모니터링
    3. 데이터 복원 내역 조회 및 수동 복원 실행
    4. 데이터 보관 정책 설정 (보관 기간, 비활성 기준 등)

프론트엔드 요구사항

TBD

2. 비기능 요구사항

(현재 명세에는 비기능 요구사항이 구체적으로 정의되지 않았습니다. 추후 정의 필요)

2.1 성능

• SLP-NFR-001: rTIB 계산 로직은 야간 배치 작업으로 수행되어 사용자 경험에 영향을 주지 않아야 한다.
• SLP-NFR-002: 수면 기록 조회 및 차트 표시는 2초 이내에 응답해야 한다.
• SLP-NFR-003: 데이터 아카이빙 및 복원 성능:
  • 데이터 아카이빙 배치 작업은 시스템 부하가 적은 시간대에 수행되어야 한다.
  • 사용자 데이터 복원은 사용자 로그인 후 최대 5초 이내에 완료되어야 한다.
  • 대량의 데이터 아카이빙/복원 작업은 서비스 성능에 미치는 영향을 최소화해야 한다.

2.2 보안

• SLP-NFR-004: 수면 기록 데이터는 사용자의 민감 정보로 간주되어 안전하게 저장 및 전송되어야 한다. (GDPR 등 규정 준수 필요)
• SLP-NFR-005: (공통 정책 참조) 데이터 암호화는 Platform 도메인 표준을 따른다:
  • PLT-SEC-001 저장 시 암호화
  • PLT-SEC-002 전송 중 암호화
  • 콜드 스토리지로 이전되는 데이터는 추가 암호화 고려
• SLP-NFR-006: 데이터 접근 제어:
  • 사용자 개인정보 및 수면 데이터에 대한 접근은 최소 권한 원칙에 따라 제한되어야 한다.
  • 모든 관리자 접근 및 데이터 처리 작업은 감사 로그에 기록되어야 한다.
  • 콜드 스토리지 데이터에 대한 접근은 전용 API를 통해서만 가능하며, 직접 접근은 제한되어야 한다.
• SLP-NFR-007: 익명화 및 가명화:
  • 통계 및 연구 목적으로 보관되는 데이터는 GDPR 제5조 및 제89조에 따라 적절히 익명화되어야 한다.
  • 익명화 과정은 재식별이 불가능하도록 충분한 조치를 취해야 한다.
  • 가명화된 데이터는 식별 정보와 분리하여 저장하고, 별도의 엄격한 접근 제어를 적용해야 한다.
• SLP-NFR-008: 데이터 침해 대응:
  • 데이터 침해 발생 시 72시간 이내에 감독 기관에 통보할 수 있는 체계를 갖추어야 한다.
  • 사용자의 권리와 자유에 높은 위험을 초래할 수 있는 침해의 경우, 해당 사용자에게도 지체 없이 통보해야 한다.
  • 데이터 침해 대응 프로세스는 정기적으로 테스트 및 업데이트되어야 한다.

2.3 가용성

• SLP-NFR-009: rTIB 처방 시스템은 정해진 주기에 맞춰 안정적으로 운영되어야 한다.
• SLP-NFR-010: 데이터 아카이빙 및 복원 가용성(Platform 연계):
  • (공통 정책 참조) 가용성/재해복구/백업 기준은 Platform 도메인의 정책을 따른다: PLT-NFR-004, PLT-NFR-005, PLT-NFR-006
  • 데이터 복원 요청은 우선순위 큐에서 관리되어 서비스 과부하 상황에서도 순차적으로 처리되어야 한다.

2.4 운영 품질 속성(Platform 연계)

• (공통 정책 참조) 무중단 배포는 Platform 도메인의 기준을 따른다: PLT-NFR-007

2.5 규제 준수(감사 추적)

• (교차참조) 도메인 데이터 및 설정의 중요 변경은 Audit 기준을 준수한다: AUD-NFR-023, AUD-NFR-024, AUD-NFR-026

3. 제약사항

3.1 rTIB 계산 주기

• SLP-CR-001: rTIB 계산은 직전 7일간의 유효 수면 기록을 기반으로 수행된다.
• SLP-CR-002: 첫 rTIB 계산은 사용 8일차에 1~7일차 데이터를 사용하여 이루어지며, 이후 7일 간격 (15일차, 22일차 등)으로 직전 7일간의 데이터를 사용하여 계산된다.

3.2 최소 유효 기록 수

• SLP-CR-003: rTIB 계산에는 최소 5개 이상의 유효한 수면 기록 데이터가 필요하다. (단, 최초 rTIB 및 데이터 부족 시 예외 규칙 적용 - 기능 요구사항 1.2 참조)

3.3 유효 기록 정의

• SLP-CR-004: DNS(Did Not Sleep) 기록은 평균 계산에서 제외(null 처리)되어야 한다.
• SLP-CR-005: TST(Total Sleep Time) > 720분 기록은 평균 계산에서 제외(null 처리)되어야 한다.

3.4 rTIB 올림

• SLP-CR-006: 최종 계산된 rTIB 값은 15분 단위로 올림되어야 한다. (예: 314분 -> 315분, 316분 -> 330분)

3.5 AET(Asleep End Time) 고정 원칙

• SLP-CR-007: rTIB 처방 시 목표 기상 시각은 사용자가 설정한 시간을 우선적으로 유지하거나, 최근 7일 유효 기록의 median AET를 기반으로 제안되어야 한다. 일관된 기상 시간 유지를 권장한다.

3.6 기술적 제약

• SLP-CR-008: (만약 있다면 NestJS, TypeScript, PostgreSQL 등 사용 기술 명시)
• SLP-CR-009: 수면 도메인 내 모든 시간 관련 로직은 시스템 시간을 직접 사용하지 않고, 반드시 TimeMachine 도메인이 제공하는 가상 시간 또는 실제 시간을 사용해야 한다. 모든 시간 처리는 TimeMachine 도메인을 통해 이루어지며, 이는 서머 타임(DST) 규칙을 포함한 시간대 변환을 포함한다.

3.7 시간 입력 단위 제약

• SLP-CR-010: 사용자가 입력하는 모든 수면 관련 시간 값(예: 잠자리에 든 시각, 일어난 시각, 수면 중 깬 시간, 낮잠 시간, 목표 기상 시각)은 5분 단위로만 입력 가능해야 한다. 프론트엔드 입력 UI 및 백엔드 유효성 검사에서 이를 강제해야 한다.

3.8 수면 기록 수정/삭제 제약

• SLP-CR-011: 사용자는 기록 당일에 한해 해당 날짜의 수면 기록을 수정할 수 있다.
• SLP-CR-012: 수정은 당일 자정(TimeMachine 시간 기준)까지만 가능하며, 이후에는 기록이 확정되어 수정 및 삭제가 불가능하다.
• SLP-CR-013: 과거 날짜의 수면 기록은 조회만 가능하며 수정 및 삭제는 불가능하다.

3.9 수면 기록 생성/수정 시 날짜 검증 제약

• SLP-CR-014: 수면 기록은 오늘(현재 날짜)에 한해서만 생성/수정이 가능하다.
• SLP-CR-015: 클라이언트에서 dayIndex를 수면 기록 입력 정보로 전송할 때, 시스템은 해당 dayIndex가 현재 사용자의 치료 일차와 일치하는지 검증해야 한다.
• SLP-CR-016: 현재 치료 일차와 요청의 dayIndex가 일치하지 않는 경우, 시스템은 오류를 발생시키고 수면 기록 생성/수정을 거부해야 한다.
• SLP-CR-017: 이는 과거 또는 미래 일차에 대한 수면 기록 조작을 방지하기 위함이다.

3.10 TimeMachine 시간 변경에 따른 데이터 삭제

• SLP-CR-018: TimeMachine 도메인에서 시스템 시간을 현재보다 과거 시점으로 변경하는 경우, 수면 도메인은 변경된 과거 시점 이후에 해당하는 모든 사용자별 수면 관련 데이터(수면 기록, 계산된 주간 요약, rTIB 처방 내역 등)를 자동으로 삭제해야 한다. 이는 데이터의 시간적 일관성을 유지하기 위함이다.

3.11 치료 일시 정지 관련 제약

• SLP-CR-019: 사용자가 User 도메인을 통해 치료 활동을 일시 정지한 상태에서는 새로운 수면 기록을 생성하거나 수정할 수 없다.
• SLP-CR-020: 일시 정지 기간 중 발생한 날짜들은 치료 주기 일차(dayIndex) 계산에서 제외되어야 한다. (이 계산은 User 도메인에서 담당)
• SLP-CR-021: 치료 활동 일시 정지 상태에서는 과거 수면 기록 조회만 가능하며, 일시 정지 기간 중 발생한 날짜에는 수면 기록이 존재하지 않는 것으로 처리되어야 한다.

3.12 GDPR 준수 및 데이터 보관 정책

• SLP-CR-022: 시스템은 GDPR 및 관련 개인정보 보호 법률을 준수하여 사용자 데이터를 처리해야 한다.
• SLP-CR-023: 데이터 보관 기간:
  • 수면 기록 및 관련 분석 데이터는 개인정보 처리방침에 명시된 대로 5년간 보관한다.
  • 회원 탈퇴 시 사용자 식별 정보는 즉시 삭제하되, 익명화된 형태로 수면 데이터는 통계 및 연구 목적으로 보관할 수 있다.
• SLP-CR-024: 비활성 사용자 데이터 처리:
  • 치료 종료 또는 마지막 활동으로부터 6개월이 경과한 사용자의 데이터는 '비활성(inactive)' 상태로 표시한다.
  • 비활성 상태로 1년이 경과한 사용자 데이터는 주 서비스 데이터베이스에서 '콜드 스토리지'로 이전한다.
  • 콜드 스토리지로 이전된 데이터는 압축 및 암호화되어 저장되며, 필요시 복원 가능한 형태로 유지한다.
• SLP-CR-025: 데이터 복원 메커니즘:
  • 비활성 사용자가 서비스에 재접속하거나 새로운 치료를 시작할 경우, 콜드 스토리지에서 해당 사용자의 과거 데이터를 자동으로 복원한다.
  • 복원 과정은 사용자에게 투명하게 이루어져야 하며, 복원 완료 후 사용자에게 과거 데이터가 복원되었음을 알린다.
  • 복원된 데이터는 사용자의 새로운 치료 주기와 연결되어야 하며, 이전 치료 주기와 구분할 수 있는 메타데이터를 포함해야 한다.
• SLP-CR-026: 데이터 삭제 요청 처리:
  • 사용자는 언제든지 자신의 모든 수면 데이터 삭제를 요청할 수 있으며, 시스템은 이를 지체 없이 처리해야 한다.
  • 삭제 요청 시 주 데이터베이스와 콜드 스토리지 모두에서 해당 사용자의 데이터를 영구적으로 삭제한다.
  • 데이터 삭제 처리는 감사 로그에 기록하여 삭제 증명이 가능해야 한다.
• SLP-CR-027: 데이터 이동성:
  • 사용자가 요청할 경우, 수면 기록 데이터를 표준 형식(JSON, CSV 등)으로 추출하여 제공할 수 있어야 한다.
  • 다른 서비스에서 데이터를 가져올 수 있는 가능성도 고려해야 한다.
• SLP-CR-028: 관리자 및 시스템 관리 도구:
  • 시스템 관리자는 데이터 보관 정책에 따라 자동화된 방식으로 데이터 아카이빙 및 복원을 모니터링하고 관리할 수 있어야 한다.
  • 데이터베이스 최적화를 위한 자동 아카이빙 스케줄러가 구현되어야 한다.
  • 콜드 스토리지 데이터에 대한 접근 권한은 최소 권한 원칙에 따라 제한되어야 한다.

3.15 rTIB 조정 범위 제한

• SLP-CR-029: rTIB 값은 이전 계산값에서 최대 ±30분 범위 내에서만 변경될 수 있다. 단, 최초 rTIB 계산 시에는 이 제한이 적용되지 않는다.
• SLP-CR-030: 이는 급격한 수면 시간 변화로 인한 사용자의 적응 어려움을 방지하고, 점진적인 수면 패턴 개선을 유도하기 위함이다.

3.16 rTIB 최소/최대값 제한

• rTIB 값은 최소 270분(4.5시간)에서 최대 600분(10시간) 범위로 제한되어야 한다.
• 이는 의학적으로 안전한 수면 시간 범위를 보장하기 위함이다.

4. 가정사항

4.1 사용자 행동

• SLP-AR-001: 사용자는 비교적 꾸준히(최소 주 5회 이상) 수면 기록을 작성할 것이다.
• SLP-AR-002: 사용자는 처방된 rTIB와 수면 목표를 인지하고 수면 습관 개선에 활용할 것이다.

4.2 시스템 환경

• SLP-AR-003: 시스템은 사용자별 데이터를 독립적으로 처리하고 저장할 수 있다.
• SLP-AR-004: 시스템은 야간 배치 작업을 통해 rTIB 계산을 수행할 수 있는 환경이다.

5. 의존성

5.1 내부 의존성

• SLP-DR-001: 사용자 도메인: 사용자 식별 및 사용자별 데이터 관리를 위해 의존한다. 특히 치료 주기 일차(dayIndex) 계산과 치료 활동 일시 정지 상태 정보를 제공받아 수면 기록 관리에 활용한다.
• SLP-DR-002: 알림 도메인: rTIB 처방 알림, 피드백 메시지 전달 등을 위해 의존할 수 있다.

5.2 외부 의존성

• SLP-DR-003: (만약 있다면 외부 라이브러리, 시간 동기화 서비스 등 명시)

6. API 데이터 구조

• SLP-DR-004: 예상 DTO: CreateSleepLogDto, SleepLogDto, WeeklySleepSummaryDto, RtibDto, UpdateSleepGoalDto 등

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

6.1 수면 데이터 처리

백엔드 요구사항

• SLP-FR-BE-041: 시스템은 수면 데이터 처리 목적을 명확히 정의해야 한다.
  • 수면 패턴 분석 및 개선 목적
  • 개인화된 수면 권고 제공 목적
  • 치료 효과 측정 목적
  • 연구 목적 활용 (별도 동의 필요)
• SLP-FR-BE-042: 시스템은 수면 데이터 보관 기간을 체계적으로 관리해야 한다.
  • 원시 수면 데이터: 치료 종료 후 1년
  • 집계 데이터: 3년
  • 익명화 데이터: 연구 목적 무기한
  • 자동 삭제 스케줄러 구현
• SLP-FR-BE-043: 시스템은 수면 데이터 익명화를 구현해야 한다.
  • 개인 식별 정보 제거
  • 간접 식별자 처리
  • k-익명성 보장 (k≥5)
  • 재식별 위험 평가

6.2 데이터 주체 권리

백엔드 요구사항

• SLP-FR-BE-044: 시스템은 수면 데이터 열람권을 보장해야 한다.
  • 수집된 모든 수면 기록 조회 API
  • 수면 분석 결과 조회 기능
  • 데이터 처리 이력 제공
  • 제3자 공유 현황 정보
• SLP-FR-BE-045: 시스템은 데이터 이동권을 지원해야 한다.
  • 표준 형식(JSON/CSV) 내보내기
  • Sleep Data API 표준 준수
  • 타 수면 앱으로 데이터 이전 지원
  • 웨어러블 디바이스 데이터 통합
• SLP-FR-BE-046: 시스템은 데이터 정정/삭제권을 보장해야 한다.
  • 수면 기록 수정 기능
  • 선택적 데이터 삭제
  • 완전 삭제 요청 처리
  • 삭제 증명 제공

6.3 제3자 데이터 공유

백엔드 요구사항

• SLP-FR-BE-047: 시스템은 연구 기관 데이터 공유를 관리해야 한다.
  • 연구 목적 공유 시 별도 동의
  • 공유 데이터 최소화
  • 공유 이력 완전 추적
  • 데이터 사용 계약 관리
• SLP-FR-BE-048: 시스템은 의료진 데이터 공유를 관리해야 한다.
  • 치료 목적 공유 승인
  • 접근 권한 시간 제한
  • 열람 이력 기록
  • 환자 통제권 보장

7. ISO27001 정보보호 관리

7.1 수면 데이터 보안

백엔드 요구사항

• SLP-FR-BE-049: (공통 정책 참조) 수면 데이터 암호화는 Platform 도메인 표준을 따른다:
  • PLT-SEC-001 저장 시 암호화
  • PLT-SEC-002 전송 중 암호화
  • PLT-SEC-003 특별 민감 필드 추가 암호화
• SLP-FR-BE-050: 시스템은 접근 통제를 강화해야 한다.
  • 역할 기반 접근 제어
  • 민감도별 데이터 분류
  • 최소 권한 원칙
  • 정기 권한 검토

7.2 데이터 무결성

백엔드 요구사항

• SLP-FR-BE-051: 시스템은 수면 데이터 무결성을 보장해야 한다.
  • 데이터 입력 검증
  • 체크섬 검증
  • 변경 이력 추적
  • 타임스탬프 검증
• SLP-FR-BE-052: 시스템은 데이터 품질을 관리해야 한다.
  • 이상치 탐지
  • 데이터 완전성 검증
  • 일관성 검증
  • 품질 메트릭 모니터링

7.3 감사 및 모니터링

백엔드 요구사항

• SLP-FR-BE-053: 시스템은 포괄적인 감사 로그를 생성해야 한다.
  • 모든 데이터 접근 기록
  • 수정/삭제 활동 로그
  • 권한 변경 이력
  • 로그 무결성 보장
• SLP-FR-BE-054: 시스템은 이상 행동을 탐지해야 한다.
  • 비정상 접근 패턴 감지
  • 대량 데이터 추출 탐지
  • 실시간 알림
  • 자동 차단 메커니즘

7.4 사고 대응

백엔드 요구사항

• SLP-FR-BE-055: 시스템은 데이터 유출 대응 체계를 구축해야 한다.
  • 유출 탐지 메커니즘
  • 72시간 내 신고 프로세스
  • 영향 평가 자동화
  • 사용자 통지 시스템
• SLP-FR-BE-056: 시스템은 복구 절차를 구현해야 한다.
  • 정기 백업 (일 단위)
  • 복원 테스트 (월 단위)
  • RTO: 4시간
  • RPO: 1시간

변경 이력

버전	날짜	작성자	변경 내용
0.1.0	2025-04-14	bok@weltcorp.com	최초 작성
0.2.0	2025-04-15	bok@weltcorp.com	수면 기록 수정 요구사항 및 임시 수면 기록 요구사항 추가
0.3.0	2025-04-15	bok@weltcorp.com	임시 수면 기록의 목표 달성 여부 계산 기준 수정
0.4.0	2025-05-03	bok@weltcorp.com	임시 수면 기록 삭제 기능 제거
0.4.1	2025-05-12	bok@weltcorp.com	수면 기록 생성시 날짜 항목을 제외
0.5.0	2025-05-13	bok@weltcorp.com	GDPR 준수 및 데이터 보관 정책 요구사항 추가
0.6.0	2025-08-07	bok@weltcorp.com	요구사항 ID 체계 적용 - SLP 도메인 코드 적용 (SLP-FR-BE-xxx, SLP-FR-FE-xxx, SLP-NFR-xxx, SLP-CR-xxx, SLP-AR-xxx, SLP-DR-xxx)
0.6.1	2025-08-08	bok@weltcorp.com	Platform 연계 명시: 가용성/DR/백업/무중단 배포는 PLT-NFR-004~007 준수
0.7.0	2025-08-12	bok@weltcorp.com	GDPR 및 ISO27001 컴플라이언스 요구사항 추가 (섹션 6, 7) - 수면 데이터 처리, 데이터 주체 권리, 데이터 보안, 무결성 관리
0.8.0	2025-08-20	bok@weltcorp.com	첫 rTIB 계산 조건 변경 (3개→4개 수면기록) 및 AET 계산 방식 개선 (평균→median) - SLP-FR-BE-028, SLP-CR-007 수정