블로그에 붙일 뉴스레터 구독 위젯을 설계해 줘

## 역할과 목표

너는 블로그에 삽입할 뉴스레터 구독 위젯을 설계하는 UI/UX 설계자다. 사용자가 제공한 정보만 근거로, 블로그 운영자와 구현 담당자가 바로 검토할 수 있는 설계안을 작성하라. 위젯의 화면 구성뿐 아니라 구독 입력, 제출 결과, 오류 처리, 접근성 동작을 정의하라.

완료 기준은 다음과 같다.

- 위젯이 블로그 안에서 어디에 어떤 목적으로 표시되는지 설명되어 있다.
- 기본·로딩·빈 상태·오류·성공 상태의 동작이 구분되어 있다.
- 키보드 사용자와 스크린리더 사용자가 모든 핵심 기능을 이용할 수 있다.
- 입력되지 않은 블로그 레이아웃, 구독 연동, 브랜드 값은 슬롯으로 남아 있다.
- 구현 가능한 화면 목록, 구성요소, 디자인 토큰이 제시되어 있다.

## 범위와 전제

다루는 범위는 블로그에 붙일 뉴스레터 구독 위젯의 다음 요소다.

- 표시 위치와 반응형 배치
- 제목·설명·입력 필드·구독 버튼
- 개인정보 또는 마케팅 수신 동의가 필요한 경우의 표시 영역
- 제출 전, 제출 중, 제출 성공, 제출 실패 상태
- 빈 상태가 발생하는 경우의 안내
- 키보드 포커스 순서와 스크린리더 라벨
- 한글 텍스트의 줄바꿈, 행간, 입력 형식
- 색상·타이포그래피·간격 등의 디자인 토큰

확인되지 않은 값은 다음 슬롯으로 표시하라.

- 위치와 폭: `[입력 필요: 위젯 표시 위치와 화면 폭 제약]`
- 구독 연동: `[입력 필요: 뉴스레터 발송 서비스 또는 API 연동 방식]`
- 입력 항목: `[입력 필요: 구독 시 수집할 항목]`
- 브랜드: `[입력 필요: 브랜드 색상·서체·로고 사용 여부]`
- 성공 후 동작: `[입력 필요: 구독 완료 뒤 표시할 화면 또는 메시지]`

이 요청에는 블로그와 뉴스레터 구독 위젯만 확인되므로, 임의의 브랜드명, 이메일 발송 서비스명, 개인정보 수집 항목, 법적 동의 문구, 화면 크기, 전환율을 추가하지 마라. 슬롯은 실제 운영 정책이나 구현 사양으로 채울 수 있도록 무엇을 입력해야 하는지 한 줄로 설명하라.

## 작업 규칙

1. 먼저 위젯의 기본 목적을 “뉴스레터 구독을 시작하게 하는 블로그 내 입력·제출 UI”로 한정하라. 구독자 관리 시스템, 뉴스레터 본문, 블로그 전체 개편은 포함하지 마라.
2. 입력 항목이 확정되지 않았으면 이메일 필드만 임의로 확정하지 말고 `[입력 필요: 구독 시 수집할 항목]`으로 남겨라. 이메일만 받는 경우와 이름 등 추가 항목을 받는 경우를 분기로 제시하라.
3. 위젯이 블로그 본문 안에 배치되는지, 사이드바에 배치되는지, 고정 영역에 노출되는지는 정하지 말고 `[입력 필요: 위젯 표시 위치와 화면 폭 제약]`으로 표시하라. 위치가 확정되면 해당 위치에 맞춰 폭, 정렬, 모바일 배치를 설명하라.
4. 구현 연동 방식이 없으면 성공·실패 동작의 원인을 구체적으로 지어내지 마라. 연동이 정상 응답을 반환하는 경우에는 성공 상태를, 유효성 검증이나 서버 응답이 실패하는 경우에는 입력 오류 또는 제출 실패 상태를 각각 설계하라.
5. 로딩 상태에서는 중복 제출을 막고 진행 중임을 시각적으로 표시하라. 성공 상태에서는 사용자가 결과를 인지할 수 있는 메시지와 다음 행동을 정의하되, 실제 문구나 후속 화면이 없으면 슬롯으로 남겨라.
6. 빈 상태는 입력값이 아직 없거나 위젯에 표시할 뉴스레터 정보가 없는 상황을 구분해 다뤄라. 뉴스레터 설명·발행 주기·혜택을 입력받지 않았다면 이를 사실처럼 만들지 말고 해당 콘텐츠 슬롯을 표시하라.
7. 접근성은 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 기준으로 검토하라. 모든 입력에는 식별 가능한 라벨을 제공하고, 오류 메시지는 해당 필드와 연결하라. 색상만으로 상태를 구분하지 말고 텍스트나 아이콘을 함께 사용하라.
8. 키보드 포커스는 제목이나 장식 요소로 불필요하게 이동하지 않도록 설계하고, 입력 필드·동의 항목·구독 버튼의 순서를 자연스럽게 제시하라. 성공·오류 메시지가 동적으로 나타나면 스크린리더가 인지할 수 있는 방법을 지정하라.
9. 한글 UI는 어절 단위 줄바꿈을 기본으로 검토하고, `word-break`와 `line-break` 처리 방향을 명시하라. 본문 행간은 라틴 문자 중심의 기본값보다 넉넉하게 설정하도록 제안하되, 실제 수치를 입력받지 않았다면 슬롯으로 남겨라.
10. 이름·주소·전화번호 입력을 포함하는 경우에만 한국형 입력 형식과 필드 순서를 설계하라. 해당 항목이 없으면 입력 항목을 추가하지 마라.
11. 개인정보를 수집하거나 마케팅 수신 동의를 받는다면 필요한 문구·보유 기간·철회 방식은 운영 정책과 적용 법령을 확인하도록 표시하라. 법령의 세부 내용을 지어내지 말고 확인 필요 항목으로 남겨라.

## 산출물 구조

다음 순서로 설계안을 작성하라. 화면 설계의 이유와 사용자 흐름은 짧은 서술형으로 쓰고, 상태·요소·토큰은 표나 목록으로 정리하라.

1. **화면 목록**
   - 위젯의 기본 화면
   - 입력 검증 화면
   - 제출 중 화면
   - 제출 성공 화면
   - 제출 실패 화면
   - 뉴스레터 정보가 없을 때의 빈 상태
   - 각 화면의 목적과 노출 조건

2. **화면별 구성요소**
   - 위젯 제목
   - 설명 문구
   - 뉴스레터 정보 영역
   - 입력 필드와 필드 라벨
   - 동의 항목
   - 구독 버튼
   - 보조 안내와 오류 메시지
   - 모바일·데스크톱 배치
   - 실제 콘텐츠가 없는 값은 `[입력 필요: 항목]`으로 표시

3. **상태별 동작**
   표의 열은 `상태 / 진입 조건 / 화면 변화 / 사용자 행동 / 접근성 처리`로 구성하라.
   - 초기 상태
   - 입력 중
   - 유효성 오류
   - 제출 중
   - 구독 성공
   - 구독 실패
   - 뉴스레터 정보 없음
   - 네트워크 또는 연동 오류
   각 상태에서 버튼 활성화 여부, 오류 제거 시점, 재시도 방법을 구체적으로 적어라.

4. **디자인 토큰**
   표의 열은 `토큰 / 적용 대상 / 값 또는 슬롯 / 사용 원칙`으로 구성하라.
   - 기본·강조·오류·성공 색상
   - 본문·제목·라벨 타이포그래피
   - 위젯 내부 여백과 요소 간격
   - 입력 필드 높이와 모서리
   - 포커스 표시
   - 반응형 중단점
   값이 제공되지 않았으면 슬롯으로 남기고, 대비·가독성·한글 줄바꿈 기준을 함께 적어라.

마지막에 **구현 확인 항목**을 별도 목록으로 두고, KWCAG 검토, 키보드 테스트, 스크린리더 테스트, 모바일 화면 테스트, 실제 구독 연동 테스트, 동의 문구와 개인정보 처리 검토를 포함하라. JSON 응답을 요구받으면 최상위 키를 `화면목록`, `화면별구성요소`, `상태별동작`, `디자인토큰`, `구현확인항목`으로 하고 모두 배열 타입으로 반환하라. 각 배열의 항목은 객체로 구성하되, 확정되지 않은 값은 문자열 슬롯으로 남겨라.

## 문체 규칙

문체는 **hybrid(혼합)**로 고정하라. 위젯의 목적, 사용자 흐름, 설계 판단의 근거는 짧은 서술형 문단으로 작성하고, 화면 목록·구성요소·상태별 동작·디자인 토큰·구현 확인 항목은 표와 번호 목록 중심의 개조식으로 작성하라. UX 용어는 필요할 때만 사용하고, “최적의 경험”, “직관적인 인터페이스”처럼 근거 없이 평가하는 표현은 쓰지 마라. 버튼 문구와 오류 문구는 실제 값이 없으면 임의로 확정하지 말고 슬롯으로 표시하라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. **모달리티 확인**: 요청을 뉴스레터 구독 위젯의 UI 설계로 처리했으며, 웹페이지 전체나 뉴스레터 본문 설계로 범위를 넓히지 않았는지 확인하라.
2. **화면 목록 확인**: 기본, 입력 오류, 제출 중, 성공, 실패, 빈 상태를 모두 화면 목록에 포함했는지 확인하라.
3. **구성요소 확인**: 제목, 설명, 입력 필드, 구독 버튼, 동의 항목, 오류 안내를 각각 다뤘는지 확인하라.
4. **접근성 확인**: KWCAG 기준, 키보드 포커스 순서, 스크린리더 라벨, 동적 성공·오류 메시지를 명시했는지 확인하라.
5. **한글 조판 확인**: `word-break`, `line-break`, 한글 행간과 반응형 텍스트 처리를 빠뜨리지 않았는지 확인하라.
6. **입력 항목 확인**: 이메일, 이름, 주소, 전화번호 중 어떤 항목이 필요한지 입력되지 않았다면 임의로 확정하지 않았는지 확인하라.
7. **연동 확인**: 뉴스레터 발송 서비스나 API 이름을 입력 없이 추가하지 않았는지, 성공·실패 조건을 연동 응답에 맞춰 슬롯 또는 분기로 처리했는지 확인하라.
8. **입력 사실 검증**: 브랜드 색상, 화면 폭, 발행 주기, 구독 혜택, 법적 동의 문구 등 사용자 입력에 없던 사실을 추가하지 않았는지 확인하라.
9. **슬롯 검증**: `[입력 필요: 위젯 표시 위치와 화면 폭 제약]`, `[입력 필요: 뉴스레터 발송 서비스 또는 API 연동 방식]` 등 실제 미확정 항목을 임의 값으로 채우지 않았는지 확인하라.
10. **범위 이탈 검증**: 구독 위젯 설계와 직접 관련 없는 블로그 개편, 캠페인 전략, 발송 콘텐츠 작성이 섞이지 않았는지 확인하라.
11. **산출물 구조 확인**: 화면 목록 / 화면별 구성요소 / 상태별 동작 / 디자인 토큰 순서를 지켰고, 구현 확인 항목을 덧붙였는지 확인하라.
12. **응답 형식 확인**: JSON 응답을 요구받은 경우 키가 `화면목록`, `화면별구성요소`, `상태별동작`, `디자인토큰`, `구현확인항목`인지와 각 값이 배열 타입인지 확인하라.