본문으로 건너뛰기

Mobile 도메인 비즈니스 규칙

1. 시스템 초기화 규칙​

1.1 앱 초기화 통합 정보 조회 규칙​

  • Mobile App은 초기화 과정에서 단일 엔드포인트 호출을 통해 시스템 전반의 설정, 정책 및 주요 콘텐츠의 최신 버전 정보를 통합적으로 조회해야 함.
  • 이 조회는 사용자 인증과 무관하게 App Token을 사용하여 수행해야 함.
  • 조회된 정보는 로컬에 캐싱되어 네트워크 요청 횟수를 최소화하고 앱 실행 환경 정보를 일관성 있게 제공해야 함.
  • 조회 후 캐싱된 정보는 필요시 앱에서 활용되어야 함 (예: 버전 판단, 상세 정보 조회 기준).

1.2 시스템 설정 정보 규칙​

  • 통합 응답에는 dta-wide 서비스의 주요 시스템 설정 정보가 포함되어야 함.
  • 필수 포함 정보:
    • 서비스의 주요 API 엔드포인트 주소 목록
    • 주요 기능의 활성화/비활성화 상태를 나타내는 기능 플래그(Feature Flags) 목록
    • Android 모바일 앱의 최소 지원 버전
    • iOS 모바일 앱의 최소 지원 버전
    • 시스템에서 지원하는 사용자 인증 방식 목록 (예: 이메일/비밀번호, 소셜 로그인 등)
  • 시스템 설정 정보는 [Configuration 도메인]에서 제공받음.

1.3 약관 버전 정보 규칙​

  • 통합 응답에는 현재 활성화된 약관(Agreements)의 최신 버전 정보가 포함되어야 함.
  • 앱은 캐싱된 버전 정보를 기반으로, 이후 사용자 동의가 필요한 시점 또는 사용자 요청 시 해당 버전의 약관 상세 내용을 별도 조회해야 함.
  • 약관 버전 정보는 [Agreement 도메인]에서 제공받음.

1.4 설문지 버전 정보 규칙​

  • 통합 응답에는 현재 활성화된 설문지(Questionnaire)의 최신 버전 정보가 포함되어야 함.
  • 앱은 캐싱된 버전 정보를 기반으로, 이후 특정 조건(예: 사용자 가입 시, 주기적 업데이트)에 따라 해당 버전의 설문지 상세 구조를 별도 조회하여 사용할 수 있어야 함.
  • 설문지 버전 정보는 [Questionnaire 도메인]에서 제공받음.

1.5 공지사항 정보 규칙​

  • 통합 응답에는 최신 시스템 공지사항의 요약 또는 새로운 공지 존재 여부가 포함되어야 함.
  • 앱은 캐싱된 정보를 바탕으로 사용자에게 공지사항을 안내하고, 필요시 상세 내용을 별도 조회하여 표시할 수 있어야 함.
  • 공지사항 정보는 [Notification/Announcement 도메인]에서 제공받음.

1.6 새로운 치료주기 시작 시 사용자 설정 초기화 규칙​

  • 사용자의 새로운 치료주기가 시작되면, Mobile App의 사용자별 설정을 자동으로 기본값으로 초기화해야 함.
  • 이를 통해 각 치료주기마다 일관된 사용자 경험을 제공하고, 이전 주기의 설정이 새로운 치료 과정에 영향을 주지 않도록 해야 함.
  • 스크린샷 허용 설정은 환경별로 다른 기본값을 가져야 함:
    • 개발환경: 기본값 true (허용)
    • 프로덕션환경: 기본값 false (비허용)
  • 앱 알림 및 시스템 알림 설정은 사용자가 새로 설정하도록 유도하거나 시스템 정책에 따른 기본값을 적용해야 함.
  • Analytics 설정은 다음 기본값으로 초기화해야 함:
    • isEnabled: true
    • viewStateTypes: ['all']
    • componentCategories: ['all']
    • componentTypes: ['all']
  • Health 데이터 접근 권한 설정은 다음과 같이 초기화해야 함:
    • iOS HealthKit 접근 권한: 기본값 비허용 (사용자가 새로 설정하도록 유도)
    • Android Health Connect 접근 권한: 기본값 비허용 (사용자가 새로 설정하도록 유도)
    • 플랫폼별 Health 데이터 접근 권한은 각 OS의 시스템 설정과 연동되며, 앱에서는 권한 요청 상태만 관리해야 함
  • 위치 접근 권한 설정은 다음과 같이 초기화해야 함:
    • 날씨정보 제공을 위한 위치 접근 권한: 기본값 비허용 (사용자가 새로 설정하도록 유도)
    • 위치 접근 권한은 각 OS의 시스템 설정과 연동되며, 앱에서는 권한 요청 상태만 관리해야 함
  • 설정 초기화는 User 도메인에서 발생하는 치료주기 시작 이벤트를 수신하여 자동으로 실행되어야 함.

2. 성능 규칙​

2.1 초기화 성능 규칙​

  • 앱 초기화 시 필요한 모든 필수 정보 조회 및 처리는 3초 이내에 완료되어야 함 (네트워크 환경 양호 기준).
  • API 서버는 통합 정보 조회 요청에 대해 평균 300ms 이내 응답 시간을 목표로 함.
  • 클라이언트 측에서는 조회된 정보를 효율적으로 캐싱하여 앱 재실행 시 로딩 시간을 최소화해야 함.

2.2 데이터 최적화 규칙​

  • 통합 응답 데이터는 불필요한 중복이나 과도한 상세 정보 없이 필수 정보만 포함하여 크기를 최적화해야 함.
  • 앱은 캐싱된 기본 정보를 기반으로 필요시에만 추가 상세 정보를 조회하는 지연 로딩 방식을 적용해야 함.

3. 보안 규칙​

3.1 통신 보안 규칙​

  • API 요청 시 HTTPS를 사용하고, 모든 민감 데이터는 전송 중 암호화되어야 함.
  • 통합 정보 조회 API는 App Token을 사용하여 인증해야 함.
  • App Token은 정기적으로 갱신되어야 하며, 유효 기간이 적용되어야 함.

3.2 데이터 보안 규칙​

  • 로컬에 저장되는 민감 정보(토큰, 개인 식별 정보 등)는 안전하게 암호화되어야 함.
  • 캐싱된 데이터는 필요한 최소 기간 동안만 보존되어야 함.
  • 사용자 개인 정보는 통합 정보 조회 API를 통해 직접 제공되지 않아야 함.

3.3 앱 보안 규칙​

  • 앱은 코드 난독화, 리패키징 방지 등 기본적인 모바일 보안 위협에 대응할 수 있어야 함.
  • 루팅/탈옥 기기 탐지 및 대응 메커니즘을 구현해야 함.
  • 보안 취약점이 발견된 이전 버전의 앱에 대한 강제 업데이트 메커니즘을 구현해야 함.

4. 가용성 규칙​

4.1 오프라인 지원 규칙​

  • 앱은 네트워크 연결이 불안정하거나 없는 상황에서도 캐싱된 기본 정보를 활용하여 제한된 기능을 제공할 수 있어야 함.
  • 오프라인 상태에서 수행된 작업은 네트워크 연결 복구 시 자동으로 동기화되어야 함.

4.2 에러 처리 규칙​

  • 통합 정보 조회 API 호출 실패 시, 적절한 에러 메시지와 함께 재시도 메커니즘을 제공해야 함.
  • 만약 최신 정보 조회에 실패할 경우, 이전에 캐싱된 정보를 사용하여 앱 기능의 기본적인 동작을 유지해야 함.
  • 반복적인 API 호출 실패 시 단계적 백오프 전략을 적용해야 함.

5. 비즈니스 운영 규칙​

5.1 버전 관리 규칙​

  • 시스템 설정, 약관, 설문지 등의 정보는 버전 관리되어야 하며, 각 버전에 대한 유효 기간 정보가 제공되어야 함.
  • 앱은 캐싱된 버전 정보와 서버에서 제공하는 최신 버전 정보를 비교하여 업데이트 필요성을 판단해야 함.
  • 필수 업데이트가 필요한 경우 사용자에게 적절한 안내를 제공해야 함.

5.2 알림 관리 규칙​

  • 새로운 공지사항이나 중요 업데이트가 있을 경우, 앱은 사용자에게 적절한 알림을 제공해야 함.
  • 알림은 중요도에 따라 분류되어야 하며, 사용자의 알림 설정에 따라 표시 여부가 결정되어야 함.
  • 알림 시스템은 과도한 알림으로 인한 사용자 피로를 방지하기 위한 제한 메커니즘을 가져야 함.

6. 의존성 규칙​

6.1 내부 도메인 의존성​

  • Auth 도메인: 사용자 인증 토큰 관리, 세션 유효성 검증 등.
  • User 도메인: 사용자 프로필 정보, 치료 기간, 사용 기간, 계정 상태 등 조회.
  • IAM 도메인: 사용자 플랜, 역할, 권한에 따른 기능 접근 제어 로직.
  • Configuration 도메인: 서비스 전반의 설정 정보(API 엔드포인트, 기능 플래그 등) 조회.
  • Agreement 도메인: 활성화된 약관 버전 및 내용 조회.
  • Questionnaire 도메인: 활성화된 설문지 버전 및 구조 조회.
  • Notification/Announcement 도메인: 시스템 공지사항 조회.

6.2 외부 의존성​

  • 모바일 기기의 운영체제 및 API
  • 푸시 알림 서비스 (예: Firebase Cloud Messaging, Apple Push Notification Service)
  • 앱 스토어 정책 및 가이드라인 (Google Play Store, Apple App Store)

7. 앱 설정 이력 관리 규칙​

7.1 변경 이력 기록 규칙​

  • AppSettings는 Immutable 구조로 관리되며, 변경 시 새 버전을 생성하고 기존 버전은 AppSettingsHistory로 자동 이관되어야 함.
  • 새 버전 생성 시 기존 AppSettings는 자동으로 AppSettingsHistory에 기록되어야 함.
  • 변경 이력에는 변경자 정보, 변경 사유, 변경 시점이 반드시 포함되어야 함.
  • 시스템에 의한 자동 변경과 사용자에 의한 수동 변경을 구분하여 기록해야 함.
  • AppSettings 테이블에는 항상 최신 버전만 유지되어야 함.

7.2 버전 관리 규칙​

  • 동일한 AppSettings ID에 대한 버전 번호는 순차적으로 증가해야 함.
  • 버전 번호는 1부터 시작하며, 각 변경마다 1씩 증가해야 함.
  • 삭제된 AppSettings의 이력도 유지되어야 하며, 감사 목적으로 조회 가능해야 함.
  • 버전 롤백 시에도 새로운 버전 번호를 할당하여 모든 변경 사항을 추적해야 함.

7.3 감사 및 컴플라이언스 규칙​

  • 변경 이력은 최소 7년간 보관되어야 함 (규제 준수 목적).
  • 변경 이력 데이터는 수정이 불가능하며, 읽기 전용으로만 접근해야 함.
  • 민감한 정보가 포함된 변경 이력은 적절한 암호화 처리가 되어야 함.
  • 정기적인 감사 리포트 생성을 통해 비정상적인 변경 패턴을 탐지해야 함.

7.4 성능 최적화 규칙​

  • 이력 조회는 페이징 처리를 통해 성능을 최적화해야 함.
  • 오래된 이력 데이터는 아카이빙을 통해 운영 데이터베이스 부하를 줄여야 함.
  • 이력 테이블에 적절한 인덱스를 설정하여 조회 성능을 보장해야 함.
  • 대량의 이력 데이터 처리 시 배치 처리를 활용해야 함.

7.5 사용자 AppSettings 추적 규칙​

  • 사용자가 현재 사용 중인 AppSettings 정보는 UserMobileSettings에 자동으로 기록되어야 함.
  • AppSettings 조회 API 호출 시 사용자의 currentAppSettingsId, currentAppSettingsVersion, appSettingsLastCheckedAt 정보가 자동 업데이트되어야 함.
  • 별도의 API 호출 없이 기존 API 사용 중에 자동으로 추적 정보가 갱신되어야 함.
  • 문제 발생 시 사용자가 어떤 버전의 AppSettings를 사용했는지 추적 가능해야 함.
  • AppSettings 추적 정보 업데이트는 실패하더라도 주요 API 응답에 영향을 주지 않아야 함 (Best Effort).

8. 변경 이력​

버전날짜작성자변경 내용
0.1.02025-05-15bok@weltcorp.com최초 작성
0.2.02025-06-04bok@weltcorp.com새로운 치료주기 시작 시 사용자 설정 초기화 규칙 추가 (1.6절)
0.3.02025-08-03bok@weltcorp.com앱 설정 이력 관리 규칙 추가 (7절) - 변경 이력 기록, 버전 관리, 감사 컴플라이언스, 성능 최적화 규칙
0.3.12025-08-03bok@weltcorp.com앱 설정 이력 관리 구조 개선 - Immutable 버전 관리로 변경, 새 버전 생성 시 기존 버전 자동 이관
0.3.22025-08-03bok@weltcorp.com사용자 AppSettings 추적 규칙 추가 (7.5절) - UserMobileSettings에 추적 정보 저장, 자동 업데이트