앱 다크모드 설정 화면을 설계해 줘 — 시스템/밝게/어둡게 3단

## 역할과 목표

너는 모바일 또는 웹 앱의 UI 설계자다. 사용자가 제공한 요구를 바탕으로 앱의 다크모드 설정 화면을 설계하라. 화면의 핵심 설정값은 **시스템·밝게·어둡게** 3단이며, 사용자가 현재 선택 상태와 변경 결과를 명확히 이해하고 조작할 수 있어야 한다.

산출물은 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰으로 구성된 실무용 설계안이어야 한다. 완료 기준은 세 가지 모드의 선택·표시·적용 흐름, 로딩·빈 상태·오류 상태, 키보드 조작과 스크린리더 라벨이 모두 명시되어 있고, 확인되지 않은 앱 정보는 슬롯으로 남아 있는 것이다.

## 범위와 전제

다음 범위만 다룬다.

- 다크모드 설정 진입 화면
- 시스템·밝게·어둡게 선택 UI
- 현재 선택값과 변경 결과의 시각적 표시
- 설정 저장 또는 적용 상태
- 로딩·빈 상태·오류 상태
- 키보드 조작, 포커스, 스크린리더 접근성
- 한글 텍스트의 줄바꿈·행간·입력 형식이 필요한 경우의 조판 기준

앱의 운영체제나 플랫폼은 확인되지 않았으므로 **[입력 필요: 앱의 대상 운영체제 또는 플랫폼]**으로 둔다. 이 슬롯은 iOS, Android, 웹 등 실제 설계 대상 플랫폼으로 채운다. 브랜드 색상·타이포그래피·간격 토큰은 제공되지 않았으므로 **[입력 필요: 브랜드 색상·타이포그래피·간격 토큰]**으로 둔다. 설정이 즉시 적용되는지 저장 버튼을 거치는지는 알 수 없으므로 **[입력 필요: 설정 저장 방식과 적용 시점]**으로 남긴다.

다크모드와 직접 관련 없는 계정, 알림, 언어, 개인정보 설정은 설계 범위에서 제외한다. 위 슬롯을 앱의 기본값이나 특정 플랫폼의 관례로 임의로 채우지 마라. 특히 선택 후 적용 시점과 브랜드 토큰을 추측해 확정하지 마라.

## 작업 규칙

1. 먼저 설정 화면의 핵심 과업을 “현재 테마 확인 → 세 가지 옵션 중 하나 선택 → 적용 결과 확인”의 순서로 정리한다. 사용자가 선택 가능한 값은 시스템, 밝게, 어둡게뿐이며 네 번째 옵션을 추가하지 않는다.
2. 세 옵션은 상호 배타적인 단일 선택 컨트롤로 설계한다. 라디오 버튼, 선택 행, 세그먼트 컨트롤 중 하나를 선택하되, 선택 기준을 설명한다.
   - 설정 목록형 화면이면 각 옵션의 설명과 선택 상태를 함께 보여 주는 라디오 행을 우선 검토한다.
   - 화면 폭이 좁고 세 옵션을 짧게 비교해야 하면 세그먼트 컨트롤을 검토하되, 긴 한글 설명을 컨트롤 안에 억지로 넣지 않는다.
3. “시스템”은 기기 또는 운영체제의 테마를 따른다는 의미로만 설명한다. 운영체제별 동작을 입력받지 않았다면 특정 플랫폼의 자동 전환 시각이나 API를 지어내지 않는다.
4. “밝게”와 “어둡게”는 앱의 표시 테마를 고정하는 선택으로 설명한다. 각 모드의 실제 색상값은 브랜드 토큰이 없으면 슬롯으로 남긴다.
5. 설정 변경 후 동작은 분기로 명시한다.
   - 즉시 적용이 확정된 경우: 선택 순간 화면 테마가 바뀌고, 선택 상태와 확인 메시지를 갱신한다.
   - 저장 버튼 방식이 확정된 경우: 선택값을 임시 상태로 표시하고, 저장 전후의 차이를 설명한다.
   - 적용 방식이 확인되지 않은 경우: 두 방식을 모두 제시하지 말고 **[입력 필요: 설정 저장 방식과 적용 시점]**을 채우도록 표시한다.
6. 로딩 중에는 현재 처리 중인 상태와 중복 조작 방식을 정의한다. 오류가 발생하면 선택 전 상태를 유지할지, 재시도할지, 오류 문구를 어떻게 제공할지 명시한다. 실패 원인이나 복구 가능성을 입력 없이 단정하지 않는다.
7. 접근성은 KWCAG를 기준으로 검토한다. 색상만으로 선택 상태를 전달하지 말고, 텍스트·아이콘·테두리·보조기술 상태를 함께 사용한다. 키보드 포커스 순서, 포커스 표시, Enter 또는 Space 조작 여부를 플랫폼에 맞게 구분한다.
8. 스크린리더 라벨에는 화면 제목, 각 옵션의 이름, 선택 여부, 설명, 변경 결과를 포함한다. 실제 접근성 API 명칭은 대상 플랫폼이 확인된 뒤 확정한다.
9. 한글 문장은 어절 단위 줄바꿈을 고려하고, `word-break`와 `line-break`가 필요한 웹 화면이면 적용 방향을 적는다. 본문 행간은 라틴 문자 기준을 그대로 복사하지 말고 읽기 편한 값으로 검토하되, 수치를 제공받지 않았다면 토큰 슬롯으로 남긴다.
10. 측정되지 않은 사용성 개선 효과, 전환율, 성능 수치를 주장하지 않는다.

## 산출물 구조

다음 네 부분을 순서대로 작성하라.

1. **화면 목록**
   - 설정 화면의 이름
   - 진입 위치
   - 이 화면의 목적
   - 별도 화면이나 모달이 필요한지 여부
   - 필요 여부가 확정되지 않은 항목은 **[입력 필요: 항목]**으로 표시한다.

2. **화면별 구성요소**
   설정 화면마다 아래 항목을 표로 제시한다.
   - 영역
   - 구성요소
   - 표시 문구
   - 기본 상태
   - 사용자 조작
   - 접근성 정보
   - 비고

   반드시 화면 제목, 현재 설정 요약, 시스템·밝게·어둡게 3개 옵션, 선택 상태 표시, 적용 결과 또는 저장 제어를 다룬다. 표시 문구는 짧고 자연스러운 한국어로 작성하되, 앱 이름이나 브랜드 문구가 없으면 슬롯으로 남긴다.

3. **상태별 동작**
   다음 상태를 각각 분리해 설명한다.
   - 기본 상태
   - 시스템 선택 상태
   - 밝게 선택 상태
   - 어둡게 선택 상태
   - 로딩 상태
   - 빈 상태
   - 오류 상태
   - 재시도 또는 복구 상태
   - 키보드 포커스 상태
   - 스크린리더 안내 상태

   각 상태마다 화면 변화, 사용자 조작 가능 여부, 안내 문구, 다음 상태로 이동하는 조건을 적는다. 설정 저장 방식이 확정되지 않았으면 그 부분은 슬롯으로 남긴다.

4. **디자인 토큰**
   아래 항목을 표로 제시한다.
   - 색상: 배경, 본문, 보조 문구, 선택 표시, 오류 표시
   - 타이포그래피: 제목, 본문, 보조 문구, 행간
   - 간격: 화면 여백, 옵션 간격, 터치 영역
   - 모서리·테두리·아이콘
   - 포커스 표시
   - 밝게·어둡게 모드별 대비 검토

   실제 색상값·폰트명·간격값은 입력되지 않았으므로 **[입력 필요: 해당 디자인 토큰]**으로 표시하고, 필요한 토큰을 무엇으로 채워야 하는지 한 줄로 덧붙인다. 플랫폼별 구현 차이는 대상 플랫폼 슬롯에 따라 구분한다.

## 문체 규칙

문체는 **hybrid(혼합)**로 쓴다. 화면 목록, 구성요소 표, 상태별 동작의 조건과 점검 항목은 개조식·표 형식으로 작성한다. 화면 목적과 선택 방식의 이유, 접근성 판단의 근거, 적용 흐름 설명은 짧은 서술형 문단으로 작성한다. 디자인 용어는 실무적으로 사용하되, “직관적”, “깔끔한”, “사용자 친화적”처럼 근거 없이 평가하는 상투어는 구체적인 화면 동작이나 시각 기준으로 바꾼다.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 모달리티가 UI 설계로 분류되었고, 산출물이 화면 목록·구성요소·상태별 동작·디자인 토큰 순서를 지키는지 확인하라.
2. 다크모드 옵션이 시스템·밝게·어둡게 정확히 3개인지 확인하고, 다른 모드나 임의의 기본값을 추가하지 않았는지 점검하라.
3. 로딩·빈 상태·오류 상태와 재시도 또는 복구 동작이 각각 포함되었는지 확인하라.
4. 키보드 조작, 포커스 표시, 스크린리더 라벨과 선택 여부 안내가 빠지지 않았는지 확인하라.
5. KWCAG 기준과 한글 조판 요구를 언급했는지, 색상만으로 상태를 전달하도록 설계하지 않았는지 확인하라.
6. 앱 플랫폼, 브랜드 토큰, 저장 방식처럼 입력에 없던 사실을 추가하지 않았는지 확인하라.
7. `[입력 필요: 앱의 대상 운영체제 또는 플랫폼]`, `[입력 필요: 브랜드 색상·타이포그래피·간격 토큰]`, `[입력 필요: 설정 저장 방식과 적용 시점]`을 임의의 값으로 채우지 않았는지 확인하라.
8. 설정 화면과 직접 관련 없는 계정·알림·언어·개인정보 기능으로 범위를 이탈하지 않았는지 확인하라.
9. 즉시 적용과 저장 후 적용을 조건 없이 동시에 확정하지 않았는지, 미확정 부분을 분기로 정확히 표시했는지 확인하라.
10. 측정하지 않은 성능, 전환율, 접근성 개선 효과를 사실처럼 주장하지 않았는지 확인하라.
11. 각 표와 문단이 실제 다크모드 설정 화면의 설계 판단에 기여하는지 확인하고, 일반적인 UI 원칙만 반복하는 문장을 삭제하라.