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

## 역할과 목표

<지시>
너는 앱 UX/UI 설계자다. 사용자가 제공한 요구를 바탕으로 앱의 다크모드 설정 화면을 설계하라. 설정값은 반드시 ‘시스템’, ‘밝게’, ‘어둡게’의 3단으로 구성하라.

완료 기준은 다음과 같다. 사용자가 세 옵션의 의미와 현재 선택 상태를 즉시 이해할 수 있고, 각 선택이 앱 화면에 어떻게 적용되는지 확인할 수 있어야 한다. 또한 로딩·빈 상태·오류 상태, 키보드 조작, 스크린리더 라벨, 한국어 조판과 접근성 고려사항이 설계안에 포함되어야 한다.
</지시>

## 범위와 전제

<맥락>
확인된 범위는 앱의 다크모드 설정 화면과 세 가지 테마 선택 흐름이다. ‘시스템’은 운영체제 설정을 따르는 선택지로 다루고, ‘밝게’와 ‘어둡게’는 앱에서 직접 지정하는 선택지로 구분하라. 운영체제와 앱의 구체적인 플랫폼, 브랜드 색상, 기존 디자인 시스템은 제공되지 않았다.

다음 값은 임의로 채우지 말고 슬롯으로 남겨라.

- 플랫폼 및 실행 환경: [입력 필요: 앱의 운영체제 및 개발 플랫폼]
- 브랜드와 기존 디자인 토큰: [입력 필요: 브랜드 고정 묘사와 색상 토큰]
- 화면의 사용 목적과 대상 사용자: [입력 필요: 화면 산출물의 사용 목적과 대상 사용자]

각 슬롯 뒤에 해당 값을 무엇으로 채워야 하는지 한 줄로 설명하라. 플랫폼 슬롯에는 지원 운영체제와 UI 구현 환경을, 브랜드 슬롯에는 로고·색상·타이포그래피 규칙을, 사용자 슬롯에는 주요 이용자와 사용 맥락을 적는다. 앱 이름, 브랜드 색상, 특정 화면 경로를 추측해 만들지 마라.
</맥락>

## 작업 규칙

<지시>
1. 먼저 화면의 목적, 사용자가 해야 하는 결정, 세 옵션의 차이를 짧게 분석한 뒤 설계안을 제시하라. 내부 사고의 장황한 전개는 출력하지 말고, 판단 근거만 간결하게 기록하라.
2. 세 옵션을 다음 조건으로 구분하라.
   - ‘시스템’: 운영체제 테마 변경을 앱이 따르는 경우. 운영체제 설정을 확인할 수 없거나 동기화에 실패하면 오류 처리 방안을 별도로 제시하라.
   - ‘밝게’: 앱의 밝은 테마를 고정하는 경우.
   - ‘어둡게’: 앱의 어두운 테마를 고정하는 경우.
3. 사용자가 현재 선택값을 알아볼 수 있도록 선택 상태, 설명 문구, 적용 시점을 설계하라. 즉시 적용인지 저장 후 적용인지 입력에 없으므로 [입력 필요: 테마 적용 시점]으로 남기고, 이 값을 무엇으로 정할지 한 줄로 설명하라. 적용 시점이 즉시라면 화면 전환 없이 결과를 확인할 수 있는 방식을, 저장 후라면 저장·취소 동작을 제시하라.
4. 로딩·빈 상태·오류 상태를 빠뜨리지 마라.
   - 로딩: 운영체제 테마를 불러오는 동안 현재 상태를 오인하지 않게 표시하라.
   - 빈 상태: 테마 미설정 또는 초기값이 존재하지 않는 경우의 표시를 정의하라.
   - 오류: 시스템 테마를 읽지 못한 경우와 설정 저장에 실패한 경우를 구분하라.
5. 접근성을 설계 기준에 포함하라. 색상만으로 선택 상태를 전달하지 말고 텍스트·아이콘·테두리·상태 라벨을 함께 사용하라. 키보드만으로 세 옵션에 이동하고 선택할 수 있게 하며, 각 컨트롤에 스크린리더 라벨과 선택 상태를 제공하라. 실제 색상 대비값이나 WCAG 충족 수치를 입력에서 받지 못했으면 수치를 지어내지 말고 [입력 필요: 접근성 검증 기준]으로 남겨 확인 대상으로 표시하라.
6. 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 접근성 확인 기준으로 지목하라. 공공기관·교육·복지 대상 앱이라면 장애인차별금지법상 정보접근성 의무가 적용되는지 확인 항목으로 두되, 적용 여부나 규정 내용을 단정하지 마라.
7. 한글 조판을 반영하라. 한국어 문장이 어절 단위로 자연스럽게 줄바꿈되도록 `word-break`·`line-break` 처리 방향을 적고, 본문 행간을 라틴 문자 중심 화면보다 넉넉하게 설정하도록 제안하라. 이름·주소·전화번호 입력은 이 화면의 핵심 범위가 아니므로 임의의 입력 양식을 추가하지 마라.
8. 브랜드 고정 묘사나 기존 디자인 시스템이 입력되면 모든 화면 요소에 일관되게 적용하라. 입력되지 않았다면 브랜드의 색상·로고·서체를 만들지 말고 확인 대상으로 남겨라.
</지시>

## 산출물 구조

<출력형식>
다음 순서로 작성하라.

1. **설계 요약** — 화면의 목적, 세 옵션의 의미, 적용 시점의 전제를 서술형으로 정리한다. 입력에 없는 값은 슬롯으로 표시한다.
2. **화면 목록** — 개조식 목록으로 설정 화면, 테마 적용 확인 상태, 오류 안내 상태를 구분한다. 별도 화면이 불필요하면 같은 화면의 상태 변화로 설명한다.
3. **화면별 구성요소** — 각 화면 또는 상태마다 다음 항목을 포함한다.
   - 화면 제목
   - 설명 문구
   - ‘시스템·밝게·어둡게’ 선택 컨트롤
   - 현재 선택 상태 표현
   - 보조 안내
   - 오류·재시도·저장·취소 동작
   - 키보드 포커스 순서
   - 스크린리더 라벨과 상태 전달 방식
4. **상태별 동작** — 정상, 로딩, 빈 상태, 시스템 테마 읽기 실패, 설정 저장 실패를 나누어 작성한다. 각 상태에서 사용자에게 보이는 문구와 다음 행동을 함께 제시한다.
5. **디자인 토큰** — 색, 타이포그래피, 간격, 테두리, 포커스 표시, 아이콘 사용 원칙을 제안한다. 브랜드 정보가 없으면 구체적인 색상값·서체명·간격 수치를 발명하지 말고 슬롯으로 남긴다.
6. **접근성 및 한국어 조판 점검** — KWCAG 기준 확인 항목, 색상 외 선택 상태, 키보드 조작, 스크린리더 라벨, `word-break`·`line-break`, 행간을 개조식으로 정리한다. 공공기관·교육·복지 대상이면 장애인차별금지법 적용 여부를 확인 대상으로 표시한다.
7. **구현 확인사항** — [입력 필요: 앱의 운영체제 및 개발 플랫폼], [입력 필요: 테마 적용 시점], [입력 필요: 브랜드 고정 묘사와 색상 토큰], [입력 필요: 접근성 검증 기준]을 확인 목록으로 제시한다. 각 슬롯은 담당자가 어떤 정보를 입력해야 하는지 한 줄로 설명한다.

전체 산출물은 화면 설계안으로 작성하되, 화면별 구성요소의 설명과 설계 근거는 짧은 서술형으로 쓰고, 목록·상태·토큰·점검 항목은 개조식으로 작성하라. 표를 사용할 경우 모바일 화면에서 읽기 어렵지 않도록 열 수를 최소화하고, 표 안에 임의의 수치를 채우지 마라.
</출력형식>

## 문체 규칙

<지시>
저작 문체는 hybrid다. 설계 목적과 선택 근거는 짧은 서술형 문단으로 작성하고, 화면 구성요소·상태별 동작·접근성 점검·디자인 토큰은 개조식으로 제시하라. 문단과 목록의 경계를 명확히 하라. ‘사용자 친화적’, ‘직관적’, ‘깔끔한 디자인’처럼 근거 없이 평가하는 표현은 피하고, 해당 표현을 쓸 때는 어떤 화면 요소나 동작을 뜻하는지 구체화하라.
</지시>

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

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

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

## 제출 전 자기 감사

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

## 자기검증

<지시>
제출 전에 다음 항목을 번호 순서대로 점검하고, 하나라도 충족하지 못하면 산출물을 수정하라.

1. 앱 다크모드 설정 화면만 다루고, 로그인·프로필·알림 등 요청에 없는 기능을 추가하지 않았는가?
2. 선택지가 정확히 ‘시스템’, ‘밝게’, ‘어둡게’ 3단으로 제시되었는가?
3. ‘시스템’이 운영체제 테마를 따르고, ‘밝게’와 ‘어둡게’가 앱 테마를 고정한다는 차이를 명확히 했는가?
4. 입력에 없던 앱 이름, 브랜드 색상, 플랫폼, 수치, 저장 방식 또는 적용 시점을 사실처럼 추가하지 않았는가?
5. `[입력 필요: 앱의 운영체제 및 개발 플랫폼]`, `[입력 필요: 테마 적용 시점]`, `[입력 필요: 브랜드 고정 묘사와 색상 토큰]`, `[입력 필요: 접근성 검증 기준]`을 임의의 값으로 채우지 않았는가?
6. 로딩·빈 상태·시스템 테마 읽기 실패·설정 저장 실패를 각각 다루었는가?
7. 키보드 포커스 순서와 스크린리더의 선택 상태 전달을 포함했는가?
8. 색상만으로 선택 상태를 표현하지 않았는가?
9. KWCAG를 확인 기준으로 지목하고, 공공기관·교육·복지 대상일 때 장애인차별금지법 적용 여부를 단정하지 않고 확인 대상으로 남겼는가?
10. 한국어 어절 줄바꿈을 위한 `word-break`·`line-break`와 넉넉한 본문 행간을 언급했는가?
11. 요청의 범위를 벗어난 입력 양식이나 기능을 추가하지 않았는가?
12. 서술형 설명과 개조식 목록의 경계가 문체 규칙에 맞게 유지되었는가?
</지시>