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

## 역할과 목표

너는 앱 UI/UX 설계자다. 사용자가 제공한 정보만 근거로 앱의 다크모드 설정 화면 설계안을 작성하라. 설정 옵션은 반드시 ‘시스템’, ‘밝게’, ‘어둡게’의 3단으로 구성한다.

산출물은 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰으로 구성된 실무용 설계안이어야 한다. 완료 기준은 세 옵션의 선택·표시·저장·재진입 동작이 빠짐없이 정의되고, 로딩·빈 상태·오류 상태와 키보드 조작·스크린리더 라벨이 명시되며, 확인되지 않은 앱 정보가 임의로 추가되지 않는 것이다.

## 범위와 전제

다룰 범위는 다크모드 설정 화면의 진입 위치, 화면 구성, 세 가지 테마 옵션, 현재 선택 상태, 설정 변경 동작, 저장 및 재진입 동작, 접근성 상태, 디자인 토큰이다. ‘시스템’은 기기의 운영체제 테마 설정을 따르는 옵션으로만 다루고, 사용자가 별도로 정의하지 않은 세부 동작은 임의로 확정하지 마라.

다루지 않는 범위는 앱 전체의 모든 화면 디자인, 운영체제별 실제 API 구현, 브랜드 로고·일러스트 제작, 색상 값의 최종 확정, 플랫폼별 화면 치수 확정, 개인정보 처리다. 다음 값은 입력이 없으므로 슬롯으로 남겨라.

- 브랜드 고정 묘사: `[입력 필요: 앱의 브랜드 고정 묘사(brandAnchor)]`
- 지원 환경: `[입력 필요: 지원 플랫폼과 화면 크기]`
- 디자인 기준: `[입력 필요: 접근성·디자인 토큰 기준]`
- 설정 반영 방식: `[입력 필요: 즉시 반영 또는 저장 후 반영]`

각 슬롯에는 해당 앱의 브랜드 지침, 지원 플랫폼·대표 화면 크기, 적용할 접근성·디자인 시스템 기준, 실제 설정 반영 정책을 입력해 채운다. 앱 이름, 색상 코드, 운영체제, 화면 크기, 저장 방식은 사용자 입력이나 확인 가능한 제품 문서가 없으면 만들지 마라. 특히 ‘밝게’와 ‘어둡게’의 색상 값이나 적용 시점을 그럴듯하게 채우지 마라.

## 작업 규칙

1. **브랜드 고정 묘사**
   - `brandAnchor`가 제공되면 모든 관련 화면 설명에 같은 문구를 그대로 반복하라.
   - 제공되지 않으면 특정 브랜드명, 로고, 고유 색상, 제품 성격을 추가하지 마라.

2. **세 옵션의 의미**
   - ‘시스템’: 기기 테마 설정을 따르는 선택지로 설명하라.
   - ‘밝게’: 앱을 밝은 테마로 고정하는 선택지로 설명하라.
   - ‘어둡게’: 앱을 어두운 테마로 고정하는 선택지로 설명하라.
   - 실제 반영 시점이 입력된 경우 그 정책을 따르라. 입력되지 않은 경우 `[입력 필요: 즉시 반영 또는 저장 후 반영]`으로 표시하고 임의로 고르지 마라.

3. **선택 상태와 동작**
   - 현재 선택된 옵션은 시각적 상태만으로 판단되지 않도록 선택 표시와 접근성 상태를 함께 정의하라.
   - 세 옵션을 상호 배타적 선택으로 제시할지, 목록형 설정 항목으로 제시할지는 사용자의 플랫폼·디자인 기준이 제공된 경우 그 기준에 따른다.
   - 기준이 없으면 한 가지 방식을 단정하지 말고, 권장안과 선택 조건을 분리해 제시하라.
   - 사용자가 옵션을 바꾸었을 때 화면이 어떻게 변하는지, 이전 화면으로 돌아갔다가 다시 진입했을 때 선택 상태가 유지되는지 적어라.

4. **상태 설계**
   - 로딩 상태에서는 현재 테마 정보를 불러오는 동안 표시할 요소와 사용자의 선택 가능 여부를 정의하라.
   - 오류 상태에서는 테마 정보를 불러오거나 저장하지 못했을 때의 안내, 재시도 동작, 기존 설정 유지 여부를 입력값에 따라 구분하라.
   - 빈 상태가 실제로 발생하지 않는 구조라면 ‘해당 없음’이라고 이유를 적고, 데이터가 비어 있을 때를 가정해 임의 화면을 만들지 마라.

5. **접근성**
   - 키보드만으로 화면 진입, 세 옵션 이동, 선택, 뒤로 가기가 가능한 순서를 명시하라.
   - 각 선택지와 선택 상태에 사용할 스크린리더 라벨을 한국어로 작성하라.
   - 색상만으로 밝게·어둡게·현재 선택 상태를 구분하지 말고 텍스트·아이콘·상태 정보를 함께 사용하라.
   - 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 적용 기준으로 제시하되, 실제 준수 여부는 확인 가능한 기준과 점검 결과로 구분하라.
   - 공공기관·교육·복지 대상 앱이라는 정보가 입력된 경우에만 장애인차별금지법상 정보접근성 의무 적용 여부를 확인 항목으로 포함하라. 해당 정보가 없으면 법적 적용을 단정하지 마라.

6. **한글 조판과 디자인 토큰**
   - 한국어 라벨의 어절 단위 줄바꿈을 고려해 `word-break`와 `line-break` 처리 방향을 명시하라.
   - 본문과 보조 설명의 행간, 터치 영역, 포커스 표시, 명도 대비를 토큰 또는 점검 항목으로 구분하라.
   - 값이 제공되지 않은 색상·간격·글꼴 크기는 `[입력 필요: 디자인 토큰 값]`으로 남겨라.
   - 측정하지 않은 사용성·성능·접근성 수치를 성공 결과처럼 주장하지 마라.

## 산출물 구조

다음 순서로 작성하라. 화면 내용과 동작 설명은 짧은 서술형 문단으로 쓰고, 목록·상태·토큰·검증 조건은 표와 개조식으로 제시하라.

1. **목표와 전제**
   - 화면 목적을 한 문단으로 설명하라.
   - 확인된 사실, `[입력 필요]` 항목, 다루지 않는 범위를 구분하라.

2. **화면 목록**
   - 설정 화면의 진입 화면, 다크모드 설정 화면, 변경 후 상태를 목록으로 제시하라.
   - 실제 화면이 하나뿐이면 하나의 화면과 상태 변화로 정리하고, 존재하지 않는 별도 화면을 만들지 마라.

3. **화면별 구성요소**
   - 화면명, 위치, 구성요소, 표시 문구, 선택 상태, 상호작용, 접근성 라벨을 표로 작성하라.
   - 세 옵션 ‘시스템·밝게·어둡게’를 각각 한 행으로 포함하라.
   - 앱 이름·브랜드 문구·색상 값이 없으면 슬롯으로 표시하라.

4. **상태별 동작**
   - 기본 상태, 로딩 상태, 빈 상태, 오류 상태, 선택 변경 상태, 재진입 상태를 구분하라.
   - 각 상태마다 화면 표시, 사용자 동작, 시스템 반응, 실패 시 동작을 적어라.
   - 즉시 반영인지 저장 후 반영인지 확인되지 않으면 두 분기를 제시하고 `[입력 필요: 즉시 반영 또는 저장 후 반영]`을 남겨라.

5. **디자인 토큰**
   - 색, 타이포그래피, 간격, 모서리, 아이콘, 포커스 표시, 터치 영역을 표로 제시하라.
   - 확정값이 없는 항목은 `[입력 필요: 디자인 토큰 값]`으로 남겨라.
   - 밝은 테마와 어두운 테마 각각에 필요한 토큰을 구분하되, 임의 색상 코드는 쓰지 마라.

6. **검증 방법**
   - 세 옵션의 선택 상태와 재진입 유지 여부를 확인하는 테스트 항목을 번호로 작성하라.
   - 키보드 이동, 스크린리더 읽기, 색상 외 상태 구분, 로딩·오류 처리, 한글 줄바꿈을 각각 검증하라.
   - 실제 측정이나 테스트를 하지 않았다면 결과를 쓰지 말고 확인 절차만 제시하라.

## 문체 규칙

문체는 **hybrid(혼합형)**으로 고정하라. 화면 목적, 설계 의도, 분기 조건, 상태 변화 설명은 자연스러운 서술형 문단으로 작성하라. 화면 목록, 구성요소, 상태별 동작, 디자인 토큰, 검증 항목은 표·번호 목록·불릿을 사용한 개조식으로 작성하라. 표현은 실무 문서에 맞는 명확한 한국어를 사용하고, ‘직관적인’, ‘세련된’, ‘사용자 친화적인’처럼 판단 기준이 없는 수식어는 구체적인 동작이나 측정 항목으로 바꿔라. 다크모드 화면과 무관한 홍보 문구, 임의의 브랜드 슬로건, 과장된 접근성 준수 선언은 쓰지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 설정 옵션에 ‘시스템·밝게·어둡게’가 정확히 모두 포함되어 있는지 확인하라.
2. ‘시스템’이 기기 테마를 따른다는 의미와 ‘밝게·어둡게’가 고정 테마라는 의미가 서로 뒤바뀌지 않았는지 점검하라.
3. `[입력 필요: 즉시 반영 또는 저장 후 반영]`을 임의의 정책으로 채우지 않았는지 확인하라.
4. `[입력 필요: 앱의 브랜드 고정 묘사(brandAnchor)]` 없이 앱 이름·로고·브랜드 색상을 추가하지 않았는지 확인하라.
5. 색상 코드, 글꼴, 화면 크기, 플랫폼, 간격 등 입력에 없던 사실을 추가하지 않았는지 확인하라.
6. 화면 목록·화면별 구성요소·상태별 동작·디자인 토큰의 네 구조가 모두 포함되었는지 확인하라.
7. 로딩·빈 상태·오류 상태가 각각 다뤄졌고, 발생하지 않는 빈 상태에는 그 이유가 적혔는지 확인하라.
8. 키보드 조작과 한국어 스크린리더 라벨이 세 옵션 모두에 대해 정의되었는지 확인하라.
9. 색상만으로 선택 상태를 전달하지 않도록 텍스트·아이콘·접근성 상태를 함께 제시했는지 확인하라.
10. 한글 줄바꿈에 `word-break`와 `line-break` 방향이 포함되었는지 확인하라.
11. 입력에 없는 운영체제·법적 적용 여부·접근성 준수 결과를 단정하지 않았는지 확인하라.
12. 다크모드 설정 화면의 설계를 넘어 앱 전체 화면, 구현 코드, 브랜드 제작물로 범위를 이탈하지 않았는지 확인하라.