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

## 역할과 목표
너는 앱 UI/UX 설계자다. 사용자가 앱의 다크모드 설정을 변경할 수 있는 설정 화면 설계안을 작성하라. 설정 선택지는 반드시 `시스템`, `밝게`, `어둡게` 3단으로 구성하라.

산출물은 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰을 포함하는 실무용 설계안이어야 한다. 완료 기준은 세 선택지의 의미와 선택 상태가 명확하고, 사용자가 설정을 변경·확인·복구할 수 있으며, 접근성 및 오류 상황이 빠짐없이 정의된 것이다.

응답은 아래 JSON 구조로만 반환하라.

```json
{
  "screenList": [],
  "screenDetails": [],
  "stateBehaviors": [],
  "designTokens": {},
  "assumptionsAndInputs": []
}
```

각 키의 값은 지정된 타입을 지켜라. `screenList`, `screenDetails`, `stateBehaviors`, `assumptionsAndInputs`는 배열이며, `designTokens`는 객체다. JSON 외의 설명, 마크다운, 주석은 출력하지 마라.

## 범위와 전제
다루는 범위는 앱 설정 화면에서 다크모드 옵션을 확인하고 선택하는 흐름이다. 화면에는 다음 세 옵션을 반드시 제공하라.

- `시스템`: 기기의 시스템 테마 설정을 따름
- `밝게`: 앱을 밝은 테마로 표시
- `어둡게`: 앱을 어두운 테마로 표시

각 옵션의 설명 문구, 현재 선택 상태, 선택 직후의 적용 방식, 화면을 다시 열었을 때의 상태를 정의하라. 세 옵션 중 하나만 선택되는 단일 선택 구조로 설계하라.

다음 정보는 입력에 없으므로 임의로 채우지 말고 슬롯으로 남겨라.

- `[입력 필요: 앱 플랫폼과 운영체제]`
- `[입력 필요: 브랜드 색상·서체·기존 디자인 토큰]`
- `[입력 필요: 설정 저장 방식과 적용 시점]`

각 슬롯에는 해당 값을 무엇으로 채워야 하는지 한 줄로 덧붙여라. 특히 앱 플랫폼을 임의로 iOS, Android, 웹 중 하나로 정하거나, 브랜드 색상·서체를 만들어내거나, 설정이 즉시 저장된다고 단정하지 마라.

다루지 않는 범위는 전체 앱의 모든 화면 디자인, 실제 코드 구현, 특정 운영체제의 미확인 기본 동작, 브랜드 자산 제작이다. 필요한 경우 해당 사항을 `[입력 필요: 항목]`으로 표시하라.

## 작업 규칙
1. 화면 구조를 결정할 때 다음 순서를 지켜라.
   - 설정 화면의 위치와 상위 메뉴 관계를 제시한다.
   - 화면 제목과 다크모드 옵션 영역을 배치한다.
   - 세 옵션을 단일 선택 컨트롤로 표현한다.
   - 선택 변경, 저장, 되돌리기 및 재진입 동작을 정의한다.
2. `시스템`, `밝게`, `어둡게`의 차이를 사용자가 한 번 읽고 이해할 수 있는 짧은 설명으로 구분하라. 운영체제별 실제 동작이 입력되지 않았다면 특정 플랫폼의 명칭이나 동작을 추가하지 마라.
3. 설정 저장 방식은 분기로 작성하라.
   - `[입력 필요: 설정 저장 방식과 적용 시점]`이 즉시 적용이면 선택 직후 테마를 적용하고 저장 완료 피드백을 정의한다.
   - 저장 버튼 방식이면 변경 전·후 상태, 저장 버튼 활성화 조건, 저장 성공·실패 동작을 정의한다.
   - 저장 방식이 확인되지 않으면 두 방식 중 하나를 임의로 선택하지 말고, 확인이 필요한 설계 결정으로 표시한다.
4. 선택 상태를 시각적 표시만으로 전달하지 마라. 색상, 모양, 텍스트, 보조 설명 중 최소 두 가지 방식으로 현재 선택을 전달하고, 스크린리더가 선택 여부와 옵션 의미를 읽도록 라벨을 작성하라.
5. 로딩 상태는 설정값을 불러오는 동안의 표시와 입력 가능 여부를 정의하라. 빈 상태는 저장된 테마 설정이 없을 때의 처리로 정의하되, 세 옵션 중 기본값을 임의로 확정하지 말고 `[입력 필요: 초기 테마값]`으로 남겨라. 오류 상태는 불러오기 실패와 저장 실패를 나누어 정의하라.
6. 키보드 조작을 정의하라. 포커스 순서, 화살표 키 또는 탭 이동 방식, 선택 확정 방식, 포커스 표시를 구체적으로 적어라. 플랫폼이 확인되지 않은 동작은 `[입력 필요: 플랫폼별 키보드 상호작용]`으로 남겨라.
7. KWCAG를 접근성 검토 기준으로 삼아 색 대비, 포커스 표시, 대체 텍스트가 필요한 장식 요소, 명확한 레이블, 상태 변화 알림을 점검하라. 실제 준수 여부를 측정하지 않았다면 “준수”라고 단정하지 말고 확인 항목으로 표시하라.
8. 공공기관·교육·복지 대상 앱인지 입력에 없으므로 해당 여부를 `[입력 필요: 서비스 대상]`으로 남기고, 해당할 경우 장애인차별금지법상 정보접근성 의무 적용 여부를 확인하도록 하라.
9. 한국어 UI 문구는 짧고 일관되게 작성하라. 시스템 설정과의 관계를 설명하는 문구는 확인된 동작만 사용하라.
10. 성능, 저장 속도, 접근성 점수, 특정 운영체제의 기본 스타일을 측정하거나 확인하지 않았다면 수치나 사실로 주장하지 마라.

## 산출물 구조
다음 필드를 모두 포함하는 JSON을 반환하라.

1. `screenList` 배열
   - `screenName`: 화면 이름
   - `purpose`: 화면의 역할
   - `entryPath`: 진입 경로. 확인되지 않은 경로는 `[입력 필요: 진입 경로]`로 표시
   - `screenType`: 설정 화면인지 여부
2. `screenDetails` 배열
   - `screenName`
   - `layoutOrder`: 위에서 아래로 정렬한 구성요소 목록
   - `components`: 각 구성요소의 이름, 역할, 표시 문구, 선택 상태 표현, 접근성 라벨
   - `interaction`: 사용자의 선택 및 이동 동작
   - `copyGuidance`: 제목·설명·옵션 문구 작성 지침
3. `stateBehaviors` 배열
   - `stateName`: 정상, 선택됨, 변경 중, 로딩, 빈 상태, 불러오기 오류, 저장 오류 등
   - `condition`
   - `visualBehavior`
   - `interactionBehavior`
   - `screenReaderAnnouncement`
   - `recoveryAction`
4. `designTokens` 객체
   - `color`: 밝은 테마와 어두운 테마에서의 배경·표면·본문·보조 문구·구분선·선택 표시 색상. 브랜드 값이 없으면 토큰 이름과 `[입력 필요: 색상값]`을 사용
   - `typography`: 제목·본문·보조 문구의 크기·굵기·행간. 서체가 없으면 `[입력 필요: 서체]`로 표시
   - `spacing`: 화면 여백, 섹션 간격, 옵션 행 간격, 터치 또는 클릭 영역
   - `focusAndSelection`: 포커스 링, 선택 표시, 비활성 상태의 시각 규칙
   - `koreanTypesetting`: 한글 줄바꿈 단위, `word-break`·`line-break` 처리, 본문 행간 기준
5. `assumptionsAndInputs` 배열
   - 입력 필요 슬롯
   - 슬롯을 채울 자료
   - 해당 결정이 영향을 주는 화면 요소
   - 미확정 상태에서의 임시 설계 원칙

화면 수는 실제로 필요한 최소 범위로 유지하라. 다크모드 설정 화면 하나로 충분하면 별도 확인 화면을 만들지 말고, 저장 실패 복구가 별도 화면을 요구하는 경우에만 그 이유를 명시하라. 값이 없는 표나 토큰은 임의의 수치로 채우지 말고 구조와 확인할 자료를 제시하라.

## 문체 규칙
지정 문체는 hybrid다. `screenList`, `screenDetails`, `stateBehaviors`, `designTokens`의 세부 값은 짧은 목록과 객체 필드 중심의 개조식으로 작성하라. 반면 `copyGuidance`, `assumptionsAndInputs`의 설명과 분기 조건은 완전한 문장으로 작성하라. 디자인 토큰은 이름과 값의 대응이 빠르게 보이도록 간결하게 쓰고, 사용자에게 표시되는 한국어 문구는 자연스러운 서술형 문장으로 제시하라.

다크모드 설정 화면에 어울리지 않는 과장된 홍보 문구, 감성적 수식어, 개발 구현을 완료했다고 오해하게 하는 단정 표현은 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증
1. `screenDetails`에 `시스템`, `밝게`, `어둡게`가 모두 있고, 세 옵션이 동시에 선택되는 구조로 기술되지 않았는지 확인하라.
2. 각 옵션의 표시 문구가 서로 다른 동작을 설명하며, 확인되지 않은 운영체제 세부사항을 추가하지 않았는지 확인하라.
3. `stateBehaviors`에 로딩, 빈 상태, 불러오기 오류, 저장 오류가 각각 포함되어 있는지 확인하라.
4. `[입력 필요: 앱 플랫폼과 운영체제]`, `[입력 필요: 브랜드 색상·서체·기존 디자인 토큰]`, `[입력 필요: 설정 저장 방식과 적용 시점]`을 임의의 값으로 채우지 않았는지 확인하라.
5. 저장 방식이 미확정인데 즉시 저장이나 저장 버튼 방식을 사실처럼 단정하지 않고, 두 분기와 확인 지점을 제시했는지 확인하라.
6. 키보드 조작, 포커스 표시, 스크린리더 라벨, 선택 상태의 비색상 표현이 산출물에 들어갔는지 확인하라.
7. KWCAG를 접근성 검토 기준으로 언급하되, 측정하지 않은 대비 수치나 준수 결과를 만들어내지 않았는지 확인하라.
8. 입력에 없던 특정 플랫폼, 브랜드 색상, 서체, 기본 테마값, 진입 경로를 추가하지 않았는지 확인하라.
9. 슬롯을 임의로 채운 부분이 없는지 확인하고, 모든 슬롯에 무엇을 제공해야 하는지 한 줄 설명이 붙었는지 확인하라.
10. 전체 내용이 다크모드 설정 화면 설계 범위를 벗어나 전체 앱 디자인이나 실제 코드 구현으로 확장되지 않았는지 확인하라.
11. JSON 문법을 검증하고, 최상위 키가 `screenList`, `screenDetails`, `stateBehaviors`, `designTokens`, `assumptionsAndInputs`로 정확히 구성되었는지 확인하라.
12. 개조식과 서술형의 사용 경계가 지정 문체인 hybrid에 맞게 지켜졌는지 확인하라.