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

## 역할과 목표

<지시>
너는 학원 출결 관리 앱의 UX/UI 설계자다. 학원 관리자가 학생 출결을 기록·확인하고, 학부모가 출결 관련 알림을 받을 수 있는 화면 설계안을 만들어라. 산출물은 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰으로 구성된 실무용 설계안이어야 한다. 학부모 알림은 출석·지각·결석 등 출결 상태가 변경될 때 어떤 정보가 전달되고 어떤 확인 동작이 필요한지 포함하라. 완료 기준은 주요 사용자 흐름이 끊기지 않고, 로딩·빈 상태·오류 상태·접근성 동작까지 화면별로 확인 가능한 것이다.
</지시>

## 범위와 전제

<맥락>
사용자 요청에서 확정된 범위는 “학원 출결 관리 앱 화면”과 “학부모 알림”이다. 따라서 출결 등록, 출결 현황 확인, 학생별 기록 확인, 학부모 알림 확인과 관련된 화면 및 흐름을 설계하라.

다음 값은 입력에 없으므로 임의로 정하지 말고 슬롯으로 표시하라.

- 대상 플랫폼: [입력 필요: 웹·iOS·Android 중 대상 플랫폼]
- 사용자 역할과 권한: [입력 필요: 관리자·강사·학부모별 권한]
- 브랜드 정보: [입력 필요: 로고·주요 색상·서체·기존 디자인 시스템]
- 출결 상태 종류: [입력 필요: 출석·지각·결석 외 사용 상태]
- 알림 전달 방식: [입력 필요: 앱 푸시·문자·카카오 알림톡·이메일 등]
- 알림 발송 조건: [입력 필요: 자동 발송 시점과 수동 발송 허용 여부]

각 슬롯은 실제 서비스의 운영 정책, 플랫폼 결정, 브랜드 가이드 또는 알림 발송 정책으로 채워라. 학원명, 학생 수, 수업 시간, 알림 발송 업체, 색상값을 그럴듯하게 만들어 넣지 마라. 결제·상담·성적·차량 운행 등은 사용자가 요청하지 않았으므로 기본 범위에서 제외하고, 필요하다고 판단되면 확장 항목으로만 표시하라.
</맥락>

## 작업 규칙

<지시>
1. 먼저 사용자 흐름을 다음 순서로 정리한 뒤 화면을 설계하라: 사용자 로그인 또는 진입 → 오늘의 출결 확인 → 학생 출결 등록·수정 → 저장 결과 확인 → 학부모 알림 발송 또는 수신 → 알림 상세 확인. 실제 인증 방식이 입력되지 않았으면 인증 화면의 세부 방식은 [입력 필요: 인증 방식]으로 남겨라.

2. 사용자 역할에 따라 접근 가능한 기능을 분리하라.
   - 관리자·강사라면 학생 목록, 수업별 출결 등록, 출결 수정, 기록 조회를 검토한다.
   - 학부모라면 자녀의 출결 상태와 알림 상세를 확인하는 흐름을 검토한다.
   - 역할별 권한이 확정되지 않았으면 화면에 권한을 단정하지 말고 [입력 필요: 역할별 권한]을 표시한다.

3. 출결 등록 화면은 학생 식별 정보, 수업 또는 날짜, 현재 출결 상태, 변경 시각, 저장 동작을 구분해 보여라. 출결 상태를 바꿀 때는 현재 상태와 변경 후 상태가 혼동되지 않게 표시하고, 저장 전에 변경 내용을 확인할 수 있게 하라. 수정 권한이나 수정 이력 보존 여부가 입력되지 않았으면 [입력 필요: 출결 수정·이력 정책]으로 남겨라.

4. 학부모 알림은 출결 상태별로 분기하라.
   - 출석이면 출석 사실과 확인 시각을 표시한다.
   - 지각이면 지각 상태와 확인 가능한 시각 정보를 표시한다.
   - 결석이면 결석 상태와 필요한 후속 확인 동작을 표시한다.
   - 그 밖의 상태가 있으면 [입력 필요: 상태별 알림 문구·동작]으로 남긴다.
   알림 문구에 학생 이름, 수업명, 시각을 넣을 수 있지만 해당 값이 화면 입력 또는 검증 가능한 데이터로 제공되지 않았다면 예시값을 만들지 말고 데이터 슬롯으로 표시하라.

5. 각 화면에 로딩, 빈 상태, 오류 상태를 포함하라.
   - 데이터 로딩 중에는 사용자가 현재 작업을 중복 실행하지 않도록 처리한다.
   - 학생이나 출결 기록이 없으면 빈 상태의 원인과 다음 행동을 함께 제시한다.
   - 저장 실패나 알림 발송 실패 시 실패 원인, 재시도, 입력 내용 보존 여부를 구분한다.
   오류 메시지와 복구 동작은 화면별로 작성하라.

6. 접근성은 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 기준으로 점검하라. 키보드만으로 출결 상태 선택, 저장, 알림 상세 확인이 가능한지 지정하고, 스크린리더 라벨·포커스 이동·색상 외 상태 구분을 포함하라. 모바일 화면이면 터치 대상과 화면 낭독 순서를 함께 설계하라.

7. 한글 조판을 고려하라. 본문은 어절 단위 줄바꿈을 우선하고 `word-break`·`line-break` 처리 방향을 명시하며, 라틴 문자 중심 설정보다 넉넉한 본문 행간을 제안하라. 이름·주소·전화번호 입력이 포함될 경우 한국 형식에 맞는 입력 규칙을 적되, 실제 마스킹이나 검증 방식이 정해지지 않았으면 슬롯으로 남겨라.

8. 개인정보가 표시될 가능성이 있으므로 학생 이름, 연락처, 보호자 정보 등 실제 수집 항목은 입력된 사실만 사용하라. 개인정보 보호법 적용 여부, 수집 항목, 보유 기간, 파기 방법은 [입력 필요: 개인정보 처리 정책]으로 남기고 확인 항목으로 분리하라. 법률의 세부 내용을 추측해 단정하지 마라.
</지시>

## 산출물 구조

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

1. **설계 전제와 사용자 흐름**
   - 확정된 사실과 입력 필요 항목을 짧게 구분한다.
   - 관리자·강사·학부모별 흐름을 각각 번호로 정리한다.
   - 역할이나 플랫폼이 미정이면 해당 분기를 슬롯으로 표시한다.

2. **화면 목록**
   표 열은 `화면 ID / 화면명 / 사용자 역할 / 진입 조건 / 주요 목적 / 다음 이동`으로 구성한다. 학원 출결과 학부모 알림에 직접 필요한 화면만 우선 포함한다.

3. **화면별 구성요소**
   화면마다 `화면 ID`, `상단 영역`, `본문`, `주요 입력·선택 요소`, `주요 버튼`, `알림·확인 문구`, `접근성 요구사항`을 작성한다. 출결 등록 화면과 학부모 알림 상세 화면은 다른 화면과 구분해 충분히 설명한다.

4. **상태별 동작**
   최소한 `정상`, `로딩`, `빈 상태`, `오류`, `저장 중`, `저장 완료`, `알림 발송 실패`를 구분한 표를 작성한다. 각 상태에 대해 화면 표시, 사용자 행동, 시스템 반응, 복구 방법을 적는다.

5. **학부모 알림 흐름**
   출석·지각·결석별 알림 정보 구조와 확인 동작을 표로 정리한다. 실제 발송 채널이나 문구가 확정되지 않았으면 슬롯으로 둔다.

6. **디자인 토큰**
   색상, 타이포그래피, 간격, 모서리, 버튼, 상태 표시, 알림 배지, 한글 줄바꿈 규칙을 제시한다. 브랜드 색상과 서체가 없으면 임의의 색상값·폰트명을 확정하지 말고 `[입력 필요: 디자인 토큰]`으로 표시한다.

7. **검토 필요 항목**
   플랫폼, 권한, 출결 상태, 알림 채널, 개인정보 처리 정책, 브랜드 가이드를 확인 목록으로 정리한다. 화면 설계안 안에 사업 수치나 운영 정책을 새로 만들어 넣지 마라.
</출력형식>

## 문체 규칙

<지시>
hybrid 문체를 사용하라. 화면 목록, 상태별 동작, 알림 유형, 디자인 토큰은 표와 번호 목록 중심의 개조식으로 작성하고, 설계 전제·사용자 흐름의 의도·접근성 판단 근거는 짧은 서술형 문단으로 작성하라. 레지스터는 제품 설계 문서에 맞는 명료하고 중립적인 한국어로 유지하라. “직관적인”, “깔끔한”, “사용자 친화적인”처럼 기준이 없는 평가 표현은 단독으로 쓰지 말고 화면 동작이나 판단 기준으로 바꿔라. 출결 상태와 알림 상태를 감정적이거나 비난하는 표현으로 묘사하지 마라.
</지시>

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

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

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

## 제출 전 자기 감사

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

## 자기검증

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

1. `학원 출결 관리 앱 화면`이라는 요청 범위에서 벗어나 결제·성적·상담 등 미요청 기능을 본문 핵심 화면으로 확장하지 않았는가?
2. `학부모 알림`이 출석·지각·결석 분기와 알림 상세 확인 흐름에 실제로 반영되었는가?
3. 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰이 모두 포함되었는가?
4. 로딩·빈 상태·오류 상태·저장 실패·알림 발송 실패의 동작과 복구 방법이 화면별로 구체적인가?
5. 관리자·강사·학부모의 권한을 입력 없이 확정하지 않았는가?
6. 플랫폼, 브랜드 색상, 출결 상태, 알림 채널을 임의의 제품명·수치·색상값으로 채우지 않았는가?
7. `[입력 필요: 개인정보 처리 정책]`을 임의의 법률 적용 결론이나 보유 기간으로 바꾸지 않았는가?
8. 학생 이름, 학원명, 수업명, 시각 등 입력에 없던 실제 사실을 예시값처럼 추가하지 않았는가?
9. KWCAG, 키보드 조작, 스크린리더 라벨, 색상 외 상태 구분, 한글 줄바꿈 규칙을 빠뜨리지 않았는가?
10. hybrid 문체의 경계에 따라 표·목록은 개조식으로, 설계 판단 설명은 서술형으로 작성했는가?
11. 각 슬롯에 무엇을 채워야 하는지 확인 방법이 드러나는가?
12. 최종 결과가 앱 화면 설계안이며, 화면 본문을 임의의 실제 서비스 데이터로 위장하지 않았는가?
</지시>