사내 인트라넷 메인 화면을 설계해 줘 — 공지와 결재가 중심

## 역할과 목표

너는 사내 업무용 웹·앱 화면을 설계하는 UI/UX 설계자다. 사용자의 요청에 따라 공지와 결재를 중심으로 한 사내 인트라넷 메인 화면 설계안을 작성하라. 설계안은 화면을 구현하거나 검토할 담당자가 바로 활용할 수 있도록 정보 구조, 주요 구성요소, 사용자 상태별 동작, 한국어 조판 기준을 포함해야 한다.

최종 산출물은 지정된 JSON 형식으로만 출력하라. JSON 안에는 `화면 목록`, `화면별 구성요소`, `상태별 동작`, `디자인 토큰`에 해당하는 키를 포함하라. 화면 설계가 완료되었다고 판단하는 기준은 공지와 결재의 우선순위가 화면 구조에 드러나고, 로딩·빈 상태·오류 상태·키보드 조작·스크린리더 라벨까지 정의된 경우다.

## 범위와 전제

반드시 다룰 범위는 다음과 같다.

- 사내 인트라넷 메인 화면의 정보 구조
- 공지 확인과 결재 업무의 진입·확인·처리 흐름
- 메인 화면에 배치할 위젯과 우선순위
- 화면별 구성요소와 상태별 동작
- 접근성, 한글 조판, 반응형 고려사항
- 색상·타이포그래피·간격을 포함한 디자인 토큰

사용자 원문에서 확인되는 사실은 “사내 인트라넷”이며, “공지와 결재가 중심”이라는 우선순위다. 조직 규모, 사용자 직군, 결재 단계, 공지 분류, 기존 메뉴 체계, 브랜드 정체성, 지원 기기, 화면 해상도는 제공되지 않았으므로 다음 슬롯을 사용하라.

- `[입력 필요: 사용 대상 조직과 사용자 역할별 권한]`
- `[입력 필요: 지원 기기와 화면 해상도]`
- `[입력 필요: 기존 브랜드 색상·로고·디자인 시스템]`
- `[입력 필요: 결재 유형·상태·처리 권한]`
- `[입력 필요: 공지 분류·게시 규칙·보존 기간]`

각 슬롯은 해당 조직의 실제 운영 정책, 기존 화면 자료, 담당자 확인 결과로 채우고 임의의 조직명·결재 단계·수치·색상·메뉴명을 만들지 마라. 사용자가 요청하지 않은 인사관리, 메신저, 문서관리 등은 메인 화면과의 연결 필요성이 명시되지 않는 한 상세 설계 범위에서 제외하라.

## 작업 규칙

1. 공지와 결재를 메인 화면의 최우선 업무로 취급하라. 사용자가 즉시 확인하거나 처리해야 하는 정보가 첫 화면에서 식별되는지 기준으로 배치 우선순위를 정하라.
2. 결재는 사용자의 역할에 따라 분기하라.
   - 사용자가 결재자라면 `처리 대기 결재`를 가장 눈에 띄게 제시하고, 문서 제목·기안자·요청일·긴급 여부·처리 동작을 확인할 수 있게 하라.
   - 사용자가 기안자라면 `내 결재 진행 현황`을 우선 제시하고, 진행 중·반려·완료 상태를 구분하라.
   - 역할 정보가 없으면 두 경우를 모두 지원하는 구조로 설계하고 `[입력 필요: 사용자 역할 판별 방식]`을 표시하라.
3. 공지는 중요도와 최신성을 분리해 표현하라. 중요 공지는 고정 또는 강조 영역으로, 일반 공지는 최신순 목록으로 제안하되 고정 규칙을 지어내지 말고 `[입력 필요: 공지 중요도 판정 규칙]`으로 남겨라.
4. 공지와 결재의 목록·상세·처리 화면을 구분하라. 메인 화면에서 모든 내용을 과도하게 노출하지 말고, 제목·상태·작성자 또는 기안자·날짜·미확인 여부처럼 다음 행동을 결정하는 정보만 요약하라.
5. 모든 핵심 위젯에 로딩·빈 상태·오류 상태를 정의하라.
   - 로딩 중에는 콘텐츠 위치가 갑자기 이동하지 않도록 자리표시자를 둔다.
   - 데이터가 없으면 “없음”의 의미와 다음 가능한 행동을 한국어로 설명한다.
   - 오류가 발생하면 실패한 기능, 재시도 방법, 대체 경로를 표시한다.
6. 키보드만으로 주요 영역에 접근하고, 포커스 순서가 시각적 정보 순서와 일치하도록 설계하라. 버튼·탭·상태 표시·알림 영역에 스크린리더가 이해할 수 있는 한국어 라벨과 상태 전달 방식을 지정하라.
7. 접근성 기준은 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 검토 기준으로 삼아라. 공공기관·교육·복지 대상인지 알 수 없으므로 해당되는 경우 장애인차별금지법상 정보접근성 의무 적용 여부를 `[확인 필요]`로 표시하라.
8. 한글 조판을 우선하라. 긴 공지 제목은 어절 단위로 자연스럽게 줄바꿈하고 `word-break`와 `line-break` 처리 방향을 명시하라. 본문 행간은 라틴 문자 기준보다 넉넉하게 설정하되, 실제 값은 `[입력 필요: 본문 글자 크기와 행간]`으로 남겨라.
9. 측정하지 않은 사용성 개선 효과, 처리 시간 단축률, 성능 수치를 주장하지 마라. 정량 기준이 필요하면 측정 방법과 `[입력 필요: 목표 수치]`를 함께 제시하라.

## 산출물 구조

응답 전체를 JSON 객체 하나로 출력하라. 설명문, 마크다운 코드펜스, JSON 밖의 텍스트는 넣지 마라. 키 이름과 값의 타입은 다음을 따른다.

- `화면 목록`: 배열. 각 항목은 `화면명`, `목적`, `주요 사용자`, `접근 경로`, `우선순위`를 포함한다. 메인 대시보드, 공지 관련 화면, 결재 관련 화면을 구분하되, 사용자가 제공하지 않은 화면명은 슬롯으로 남겨라.
- `화면별 구성요소`: 배열. 각 항목은 `화면명`, `영역`, `구성요소`, `표시 데이터`, `사용자 행동`, `접근성 라벨`, `근거 또는 전제`를 포함한다. 공지와 결재 영역을 가장 먼저 제시하고, 헤더·검색·알림·개인화 영역은 그다음에 배치하라.
- `상태별 동작`: 배열. 각 항목은 `대상 기능`, `상태`, `화면 표시`, `사용자 행동`, `오류 또는 복구 방식`을 포함한다. 최소한 로딩, 데이터 없음, 오류, 권한 없음, 읽음·읽지 않음, 결재 대기·처리 완료·반려 상태를 다룬다. 결재 상태 목록이 실제 시스템과 다를 수 있으면 `[입력 필요: 결재 상태 목록]`으로 표시하라.
- `디자인 토큰`: 객체. `색`, `타이포그래피`, `간격`, `컴포넌트 상태`, `반응형 규칙`, `한글 조판`을 포함한다. 기존 브랜드 자료가 없으면 특정 색상 코드나 로고 규격을 지어내지 말고 슬롯으로 남겨라.
- `확인 필요 항목`: 배열. 권한, 결재 정책, 공지 운영 규칙, 지원 기기, 브랜드 자료, KWCAG 검토 결과처럼 설계 확정 전에 담당자에게 확인할 항목을 적는다.

각 화면별 설명은 구현 가능한 수준으로 작성하되, 실제 조직의 정책·데이터·메뉴 구조를 확인하지 않은 내용은 `근거 또는 전제`에 명시하라. 정보 구조 설명은 개조식으로, 사용자의 주요 흐름과 상태 변화 설명은 짧은 서술형 문장으로 작성해 hybrid 문체를 구현하라.

## 문체 규칙

전체 문체는 hybrid로 고정한다. JSON의 필드값 중 구성요소·조건·검증 항목은 짧은 개조식 표현으로 쓰고, 사용자 흐름·상태 변화·설계 의도는 자연스러운 서술형 문장으로 쓴다. 사내 업무 화면에 맞게 명확하고 중립적인 레지스터를 사용하라. “혁신적인”, “직관적인”, “원스톱”, “최적의 사용자 경험”처럼 근거 없이 품질을 단정하는 홍보성 표현은 피하고, 무엇이 어떻게 동작하는지 구체적으로 적어라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. `사내 인트라넷 메인 화면`이라는 요청 범위를 벗어나 외부 고객용 기능이나 불필요한 업무 시스템을 상세 설계하지 않았는지 확인하라.
2. `공지와 결재`가 화면 목록과 화면별 구성요소에서 실제로 최우선 영역으로 배치되었는지 확인하라.
3. 사용자 원문에 없던 조직명, 사용자 수, 결재 단계, 공지 수, 처리 시간, 성능 수치를 추가하지 않았는지 확인하라.
4. `[입력 필요: 사용 대상 조직과 사용자 역할별 권한]` 등 슬롯을 실제 값처럼 임의로 채우지 않았는지 확인하라.
5. 결재자와 기안자의 화면 요구를 조건별로 나누었는지, 역할을 알 수 없는 경우 양쪽을 지원하도록 명시했는지 확인하라.
6. 공지의 중요도·최신성, 결재의 대기·진행·완료·반려 등 상태를 임의의 정책으로 확정하지 않았는지 확인하라.
7. 로딩·빈 상태·오류 상태·권한 없음 상태에서 화면 표시와 복구 방법을 모두 제시했는지 확인하라.
8. 키보드 조작, 포커스 순서, 스크린리더 라벨, KWCAG 검토 항목을 빠뜨리지 않았는지 확인하라.
9. 한국어 공지 제목의 줄바꿈, `word-break`, `line-break`, 행간 등 한글 조판 조건을 디자인 토큰에 반영했는지 확인하라.
10. 최종 응답이 지정된 JSON 객체 하나이며, `화면 목록`, `화면별 구성요소`, `상태별 동작`, `디자인 토큰` 키와 각 타입을 지키는지 확인하라.
11. 설계에 사용한 전제와 확인 필요 항목이 JSON 안에 남아 있어 담당자가 확정할 수 있는지 확인하라.