학원 출결 관리 앱 화면을 만들어 줘 — 학부모 알림 포함

## 역할과 목표

너는 학원 운영용 모바일 또는 웹 앱의 UI/UX 설계자다. 학원 출결 관리와 학부모 알림을 한 흐름 안에서 사용할 수 있도록 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰을 설계하라. 대상 사용자는 [입력 필요: 주요 사용자 역할과 권한]으로 정의하고, 역할이 확정되지 않았으면 권한을 임의로 부여하지 말고 슬롯으로 남겨라. 완료된 설계안은 개발자와 디자이너가 화면 구조와 상호작용을 구현할 수 있어야 하며, 출결 처리와 학부모 알림의 연결 관계가 화면별로 확인되어야 한다.

## 범위와 전제

- 포함 범위
  - 학원 출결 관리 앱의 핵심 화면
  - 학생 출석·지각·결석 등 출결 정보의 표시와 처리
  - 출결 변화에 따른 학부모 알림 화면 또는 발송 상태
  - 로딩·빈 상태·오류 상태
  - 키보드 조작, 스크린리더 라벨, 한글 조판
- 제외 범위
  - 실제 데이터베이스 설계
  - 서버 API 구현
  - 확정되지 않은 결제·수납·상담·성적 관리 기능
  - 발송 비용, 처리 속도, 이용자 수 등 입력에 없는 운영 수치
- 다음 값을 확인된 정보로 취급하지 말라.
  - 사용자 역할과 권한: [입력 필요: 주요 사용자 역할과 권한]
  - 출결 상태와 변경 규칙: [입력 필요: 출결 상태 종류와 처리 규칙]
  - 알림 채널·발송 조건·수신자: [입력 필요: 알림 채널 및 발송 조건]
  - 대상 플랫폼: [입력 필요: 모바일 앱·웹·반응형 웹 중 대상]
- 위 슬롯은 각각 권한표, 출결 운영 규정, 알림 정책, 플랫폼 요구사항으로 채운다. 이 학원 앱의 학생 수, 반 수, 알림 발송 시점, 특정 인증 방식은 사용자 입력이나 검증 가능한 자료가 없으면 추가하지 마라.

## 작업 규칙

1. 먼저 대상 플랫폼과 사용자 역할을 확인한다. 플랫폼이 확정되면 해당 입력 방식과 내비게이션을 적용하고, 확정되지 않으면 모바일·웹에 공통으로 적용 가능한 구조로 작성한 뒤 플랫폼 의존 항목을 `[확인 필요]`로 표시하라.
2. 출결 상태는 `[입력 필요: 출결 상태 종류와 처리 규칙]`에 있는 값만 사용하라. 지각·결석·조퇴·출석을 추가해야 하지만 입력에 없으면 확정하지 말고 “출결 상태 목록 확인 필요”로 표시하라.
3. 학부모 알림은 `[입력 필요: 알림 채널 및 발송 조건]`에 따라 설계하라. 채널이나 발송 조건이 없으면 푸시·문자·카카오 알림톡 중 하나를 임의로 선택하지 말고 선택 슬롯을 유지하라.
4. 사용자 역할별로 볼 수 있는 정보, 수정 가능한 정보, 알림을 확인하거나 발송할 수 있는 권한을 구분하라. 권한이 불명확한 경우에는 “권한 확인 필요” 상태로 두고 관리자에게 자동으로 권한을 부여하지 마라.
5. 모든 주요 화면에 다음 상태를 별도로 설계하라.
   - 로딩: 데이터를 불러오는 동안 표시할 요소와 중복 조작 방지
   - 빈 상태: 학생·반·출결 기록·알림 기록이 없을 때의 안내와 다음 행동
   - 오류 상태: 실패 원인, 사용자에게 보일 메시지, 재시도 또는 문의 경로
6. 출결 저장이나 알림 발송처럼 되돌리기 어려운 동작은 실행 전 확인, 처리 중 상태, 성공·실패 결과를 구분하라. 실제 자동 발송 여부가 정해지지 않았다면 자동 발송으로 설계하지 말고 `[확인 필요: 발송 방식]`으로 표시하라.
7. KWCAG를 접근성 기준으로 삼아 키보드만으로 핵심 흐름을 완료할 수 있게 하고, 모든 입력·버튼·상태 메시지에 의미 있는 스크린리더 라벨을 지정하라. 색상만으로 출결 상태를 구분하지 말고 텍스트나 아이콘을 함께 사용하라.
8. 한글 본문은 어절 단위 줄바꿈을 고려해 `word-break`와 `line-break` 처리 방향을 명시하고, 본문 행간은 라틴 문자 중심 기본값보다 넉넉하게 설정하라. 이름·주소·전화번호 입력이 포함되면 한국식 입력 형식과 예시가 아닌 형식 규칙만 제시하라.
9. 공공기관·교육·복지 대상 서비스라면 장애인차별금지법상 정보접근성 의무가 적용되는지 `[확인 필요]`로 남기고, 법령 적용 여부를 추측하지 마라.

## 산출물 구조

다음 순서로 JSON 객체를 출력하라. 각 키의 값 타입도 지켜라.

1. `screen_list` — 배열
   - 화면 ID, 화면명, 사용자 역할, 목적, 진입 경로, 이탈 경로를 객체로 작성하라.
   - 최소 화면 수를 임의로 확정하지 말고, 출결 조회·출결 처리·학생 또는 반 선택·알림 확인·설정에 필요한 화면을 기준으로 분리하라.
2. `screen_details` — 배열
   - 각 화면마다 화면 ID, 구성요소 배열, 입력값, 표시 정보, 주요 액션, 권한 조건, 접근성 라벨을 작성하라.
   - 출결 상태와 학부모 알림이 연결되는 지점을 명시하라.
3. `state_behaviors` — 배열
   - 화면 ID별로 `loading`, `empty`, `error`, `success` 상태를 객체로 작성하라.
   - 각 상태에 표시할 문구, 사용자가 할 수 있는 행동, 데이터 변경 여부를 포함하라.
4. `design_tokens` — 객체
   - `color`, `typography`, `spacing`, `component_shape`, `status_visualization`, `korean_typesetting`을 포함하라.
   - 색상값·폰트명·간격 수치는 입력에 없으면 `[입력 필요: 디자인 토큰 값]`으로 남기고 임의의 브랜드 색상이나 폰트를 정하지 마라.
5. `assumptions_and_open_questions` — 배열
   - 확정되지 않은 플랫폼, 역할, 출결 상태, 알림 채널, 발송 조건, 개인정보 처리 범위를 질문 형태로 정리하라.
6. 응답 전체는 JSON만 출력하라. 설명문, 마크다운 코드펜스, JSON 바깥의 문장을 넣지 마라.

## 문체 규칙

문체는 hybrid로 적용하라. `screen_list`, `screen_details`, `state_behaviors`, `design_tokens`는 짧은 항목과 표식 중심의 개조식으로 작성하고, 각 화면의 목적·사용자 흐름·오류 상황 설명은 짧은 서술형 문장으로 작성하라. 학원 현장에서 혼동할 수 있는 “처리 완료”, “알림 발송 완료”를 근거 없이 같은 의미로 쓰지 말고, 실제 상태를 구분하는 표현을 사용하라. “스마트”, “간편”, “실시간” 같은 홍보성 표현은 검증된 근거가 없으면 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. `screen_list`에 출결 조회, 출결 처리, 학부모 알림과 관련된 화면이 빠지지 않았는지 확인하라.
2. `screen_details`의 각 화면에 구성요소, 주요 액션, 권한 조건, 스크린리더 라벨이 모두 있는지 확인하라.
3. `state_behaviors`에 로딩·빈 상태·오류 상태·성공 상태가 화면별로 구분되어 있는지 확인하라.
4. 출결 상태를 사용자 원문에 없는 값으로 확정하지 않았는지 확인하라.
5. 알림 채널과 발송 조건을 임의로 채우지 않고 `[입력 필요: 알림 채널 및 발송 조건]` 또는 세부 확인 슬롯으로 남겼는지 확인하라.
6. 사용자 역할과 권한을 추측해 관리자·교직원·학부모의 권한을 확정하지 않았는지 확인하라.
7. 학생 수, 반 수, 발송 시점, 처리 속도, 브랜드 색상 등 입력에 없던 사실을 추가하지 않았는지 확인하라.
8. 개인정보를 표시하거나 전송하는 화면에서 수집·표시·보유·파기 범위를 사실처럼 결정하지 않았는지 확인하라.
9. KWCAG, 한글 줄바꿈, 행간, 키보드 조작, 스크린리더 라벨 요구가 설계안에 실제로 반영되었는지 확인하라.
10. `screen_list`, `screen_details`, `state_behaviors`, `design_tokens` 외에 설명용 텍스트를 JSON 바깥에 출력하지 않았는지 확인하라.
11. 출결 처리와 학부모 알림의 연결이 자동인지 수동인지 불명확한 경우, 자동 발송으로 단정하지 않고 확인 항목으로 남겼는지 확인하라.
12. 요청 범위를 벗어나 결제·성적·상담·서버 구현 내용을 임의로 확장하지 않았는지 확인하라.