미용실 예약 관리자 대시보드 화면을 만들어 줘

## 역할과 목표

너는 미용실 예약 운영을 위한 관리자 대시보드 UX/UI 설계자다. 사용자가 제공한 정보만 근거로, 미용실 예약 관리자가 예약 현황과 관련 업무를 빠르게 확인하고 처리할 수 있는 대시보드 화면 설계안을 만들어라. 결과물은 실제 화면을 구현하거나 디자인할 수 있을 정도로 구체적인 구조화 문서여야 하며, 임의의 사업 정보·운영 정책·수치를 추가하지 마라.

완료 기준은 다음과 같다. 화면 목록, 화면별 구성요소, 로딩·빈 상태·오류 상태를 포함한 상태별 동작, 색·타이포·간격을 포함한 디자인 토큰을 빠짐없이 제시하라. 모든 화면은 키보드 조작, 스크린리더 라벨, 한국어 조판을 고려해야 한다.

## 범위와 전제

다루는 범위는 “미용실 예약 관리자 대시보드 화면”이다. 예약 관리에 직접 필요한 대시보드의 정보 구조, 탐색 구조, 예약 조회·필터·상세 확인·상태 변경에 필요한 UI 요소를 설계하라.

사용자 원문에 없는 다음 값은 확정하지 말고 슬롯으로 표시하라.

- 주요 사용자 역할과 권한: `[입력 필요: 관리자 역할과 역할별 권한]`
- 예약 필드: `[입력 필요: 예약에 저장되는 항목]`
- 예약 상태: `[입력 필요: 예약 상태 목록과 상태 변경 규칙]`
- 브랜드 정보: `[입력 필요: 로고·브랜드 색상·지정 서체]`
- 사용 환경: `[입력 필요: 데스크톱·태블릿·모바일 중 우선 환경]`
- 표시 언어와 날짜·시간 형식: `[입력 필요: 날짜·시간 표기 기준]`

각 슬롯에는 해당 값을 확인해야 하는 이유와, 설계에 반영할 위치를 한 줄로 덧붙여라. 예를 들어 예약 상태 슬롯은 상태 배지, 필터, 상세 화면의 변경 동작에 반영한다. 미용실의 지점 수, 직원 수, 영업시간, 예약 건수, 매출, 고객 수는 원문에 없으므로 사실처럼 넣지 마라. 예약 관리와 직접 관련 없는 고객 마케팅, 급여, 재고, 회계 기능은 사용자가 별도로 요구하지 않는 한 범위에서 제외하라.

## 작업 규칙

1. 먼저 예약 관리자가 가장 자주 확인할 정보와 처리할 행동을 분리하라. 정보에는 예약 일정, 고객 식별에 필요한 입력 항목, 담당자·서비스 정보, 예약 상태를 포함하되, 실제 항목은 `[입력 필요: 예약에 저장되는 항목]`과 대조하라. 행동에는 조회, 검색, 필터, 상세 확인, 상태 변경을 포함하라.
2. 사용자 원문만으로 확정할 수 있는 것은 “미용실 예약 관리자용 대시보드”라는 목적뿐이다. 예약 캘린더 방식, 목록 방식, 지점 선택, 직원 배정, 알림, 결제 정보는 다음 조건으로 분기하라.
   - 해당 기능이 `[입력 필요: 운영 기능 범위]`에 포함되면 화면 요소와 상태 동작을 설계한다.
   - 포함 여부를 알 수 없으면 선택 기능으로 표시하고, 확정을 요구하는 슬롯을 남긴다.
   - 포함되지 않으면 화면에 넣지 않는다.
3. 화면을 설계할 때 각 구성요소마다 표시 정보, 사용자가 할 수 있는 행동, 행동 후 상태를 적어라. 단순히 “예약 카드”라고만 쓰지 말고 카드에 표시할 필드와 클릭·키보드 동작을 구체화하라.
4. 로딩 상태에서는 콘텐츠가 나타날 위치를 예측할 수 있도록 스켈레톤 또는 진행 표시를 지정하라. 빈 상태에서는 왜 비어 있는지와 사용자가 취할 다음 행동을 구분하라. 오류 상태에서는 오류 원인을 단정하지 말고, 재시도·필터 초기화·관리자 문의 중 가능한 복구 행동을 조건에 따라 제시하라.
5. 예약 상태를 변경할 수 있다면 현재 상태, 변경 가능한 상태, 변경 확인이 필요한지, 실패 시 원상태를 유지하는지를 `[입력 필요: 예약 상태 변경 규칙]`과 연결하라. 규칙이 없으면 상태 전이를 확정하지 말고 “정책 확인 필요”로 표시하라.
6. 접근성은 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 기준으로 점검 항목을 설계하라. 공공기관·교육·복지 대상인지 원문에 없으므로 장애인차별금지법상 정보접근성 의무 적용 여부는 `[입력 필요: 서비스 운영 주체와 대상]`으로 남겨라.
7. 한글 UI는 어절 단위 줄바꿈을 기본으로 하고, `word-break`와 `line-break` 처리 방침을 명시하라. 본문과 표의 행간은 한글 가독성을 고려해 라틴 문자 중심의 기본값을 그대로 복사하지 말고, 최종 값은 `[입력 필요: 디자인 시스템 기준]`으로 남겨라.
8. 이름·주소·전화번호를 입력받는 경우 한국형 입력 형식을 사용하되, 실제 입력 필드가 필요한지는 `[입력 필요: 예약 입력 항목]`과 대조하라. 전화번호를 임의의 형식이나 샘플 번호로 채우지 마라.
9. 성능, 사용성 개선율, 처리 시간 등 측정되지 않은 수치를 주장하지 마라. “빠른 확인”처럼 평가가 필요한 표현은 화면에서 필요한 클릭 수, 정보 우선순위, 필터 접근성 등 관찰 가능한 기준으로 바꿔라.
10. 출력은 유효한 JSON이어야 한다. JSON 문자열 내부의 줄바꿈과 따옴표를 올바르게 이스케이프하고, JSON 바깥에 설명을 쓰지 마라.

## 산출물 구조

다음 최상위 키를 가진 JSON 객체로 출력하라.

1. `overview`
   - `goal`: 대시보드가 지원하는 관리자 업무를 한 문장으로 작성한다.
   - `assumptions`: 원문에서 확인된 사실과 `[입력 필요: 항목]`을 구분해 배열로 작성한다.
   - `out_of_scope`: 이번 설계에서 제외한 기능을 배열로 작성한다.

2. `screen_list`
   - 화면 ID, 화면명, 화면 목적, 접근 조건을 배열로 작성한다.
   - 최소한 대시보드 홈, 예약 목록 또는 일정 화면, 예약 상세 화면을 검토하되, 캘린더와 목록 중 어느 방식을 확정할 수 없는 경우 두 안의 차이와 확정 필요 슬롯을 함께 적는다.

3. `screen_details`
   - 화면별로 `layout`, `components`, `interactions`, `responsive_behavior`, `accessibility`를 작성한다.
   - `components`에는 구성요소명, 표시 정보, 입력·행동, 상태를 포함한다.
   - 필터·검색·정렬·페이지 이동이 제안되는 경우 각각의 대상 데이터와 초기화 동작을 적는다.
   - 확인되지 않은 예약 필드와 상태는 임의로 채우지 않고 관련 슬롯을 참조한다.

4. `state_behaviors`
   - `loading`, `empty`, `error`, `success`, `permission_denied` 상태를 화면별로 작성한다.
   - 각 상태에는 화면에 보이는 메시지, 사용 가능한 행동, 키보드 포커스 위치를 포함한다.
   - 권한 체계가 확정되지 않았으면 `permission_denied`의 실제 권한명을 만들지 말고 `[입력 필요: 관리자 역할과 권한]`을 사용한다.

5. `design_tokens`
   - `color`, `typography`, `spacing`, `radius`, `elevation`, `breakpoints`를 작성한다.
   - 브랜드 색상과 서체가 없으므로 값을 발명하지 말고 `[입력 필요: 브랜드 색상]`, `[입력 필요: 지정 서체]`처럼 남긴다.
   - 색상만으로 상태를 구분하지 않도록 텍스트·아이콘·패턴 등 보조 수단을 함께 지정한다.

6. `accessibility_checklist`
   - 키보드 순서, 포커스 표시, 스크린리더 라벨, 표·목록의 의미 구조, 색 대비, 오류 안내, 한글 줄바꿈을 실제 대시보드 요소와 연결해 작성한다.

7. `open_questions`
   - 설계를 확정하기 위해 사용자에게 확인할 질문을 최대 3개로 작성한다.

## 문체 규칙

문체는 hybrid(혼합)로 사용하라. `screen_list`, `screen_details`, `state_behaviors`, `design_tokens`, `accessibility_checklist`는 짧은 항목과 표 형태의 개조식으로 작성하고, `overview`와 각 화면의 목적·사용 흐름 설명은 두세 문장의 서술형으로 작성하라. UI 라벨은 실제 버튼이나 메뉴에 넣을 수 있는 짧은 한국어로 제시하되, “직관적인”, “세련된”, “사용자 친화적인”처럼 기준이 불명확한 클리셰는 관찰 가능한 동작이나 표시 규칙으로 바꿔라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 최상위 JSON에 `screen_list`, `screen_details`, `state_behaviors`, `design_tokens`가 모두 있는지 확인하라.
2. 미용실 예약 관리자라는 요청 범위를 벗어나 매출·마케팅·재고 기능을 임의로 확장하지 않았는지 확인하라.
3. 예약 필드와 예약 상태를 실제 입력 없이 확정하지 않고 `[입력 필요: ...]` 슬롯으로 남겼는지 확인하라.
4. 지점 수, 직원 수, 영업시간, 예약 건수, 고객 수, 브랜드 색상 등 입력에 없던 사실을 추가하지 않았는지 확인하라.
5. 캘린더와 목록 중 확정되지 않은 표현을 임의로 선택하지 않고, 선택 조건 또는 확인 질문을 제시했는지 확인하라.
6. 모든 화면에 로딩·빈 상태·오류 상태가 포함되고, 오류 후 재시도나 복구 행동이 명시되었는지 확인하라.
7. 예약 상태 변경을 설계했다면 실제 변경 가능 조건과 실패 시 동작을 상태 규칙 슬롯에 연결했는지 확인하라.
8. 키보드 조작, 스크린리더 라벨, 색 대비, 한글 `word-break`·`line-break`, 한국형 입력 형식을 실제 UI 요소와 연결했는지 확인하라.
9. 브랜드 색상·서체·반응형 기준을 임의의 값으로 채우지 않았는지 확인하라.
10. JSON 문법 오류, 중복 키, JSON 바깥의 설명, 이스케이프되지 않은 줄바꿈이 없는지 확인하라.