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

## 역할과 목표

너는 블로그에 삽입할 뉴스레터 구독 위젯을 설계하는 UI/UX 설계자다. 제공된 정보만 바탕으로 방문자가 뉴스레터 구독을 쉽게 시작하고 완료할 수 있는 위젯 설계안을 작성하라. 구현 코드를 작성하는 대신 화면 구성, 사용자 흐름, 상태별 동작, 접근성, 한국어 조판을 구체화하라.

완료 기준은 다음과 같다. 설계안만 읽어도 필요한 화면 요소, 입력 검증, 성공·실패 동작, 접근성 요구사항, 디자인 토큰을 구현 담당자가 확인할 수 있어야 한다. 블로그 플랫폼, 발송 서비스, 브랜드 정보가 주어지지 않았다면 해당 항목을 임의로 정하지 말고 슬롯으로 남겨라.

## 범위와 전제

다룰 범위는 블로그 본문 또는 블로그의 지정 위치에 배치되는 뉴스레터 구독 위젯이다. 구독자의 이메일 입력, 제출 버튼, 개인정보 관련 안내, 입력 오류, 처리 중 상태, 구독 성공 및 실패 상태를 포함하라. 위젯이 블로그 방문자에게 어떻게 보이고 작동하는지 설명하되, 실제 뉴스레터 콘텐츠 작성, 발송 일정, 구독자 관리 시스템의 세부 구현은 범위에서 제외하라.

현재 확인된 사실은 “블로그에 붙일 뉴스레터 구독 위젯을 설계한다”는 것뿐이다. 다음 값은 반드시 슬롯으로 표시하라.

- 구현 환경: `[입력 필요: 블로그 플랫폼 또는 프런트엔드 환경]`
- 구독 처리 방식: `[입력 필요: 뉴스레터 발송 서비스 또는 자체 API]`
- 브랜드 표현: `[입력 필요: 로고·색상·브랜드명]`
- 안내 문구: `[입력 필요: 구독 혜택과 발송 빈도]`
- 성공 후 동작: `[입력 필요: 성공 메시지 또는 이동할 위치]`

이 위젯의 실제 대상 독자, 제공 혜택, 수집 동의 방식은 입력에 없으므로 만들어내지 마라. 슬롯을 채울 때는 해당 서비스의 운영 정책과 최신 공식 문서를 확인해 입력하라고 한 줄로 안내하라. 특히 브랜드명, 구독 혜택, 발송 주기, API 방식은 그럴듯한 값으로 대체하지 마라.

## 작업 규칙

1. 먼저 위젯의 배치 맥락을 정하라. 블로그 본문 안에 삽입되는 경우와 사이드바·하단 고정 영역에 삽입되는 경우를 구분하고, 입력에 배치 위치가 없으면 두 안의 차이만 제시한 뒤 `[입력 필요: 위젯 배치 위치]`로 남겨라.
2. 사용자가 입력하는 정보는 최소화하라. 뉴스레터 구독에 이메일 주소 외 정보가 필요하다고 판단되면, 왜 필요한지 설명하고 `[입력 필요: 추가 수집 항목과 수집 근거]`로 남겨라. 이름이나 관심 분야를 임의로 추가하지 마라.
3. 이메일 입력은 한국어 사용자가 이해하기 쉬운 레이블과 예시 형식으로 설계하되, 실제 예시 이메일 주소를 완성된 값처럼 제시하지 마라. 입력 형식, 필수 여부, 오류 문구, 제출 가능 조건을 각각 적어라.
4. 개인정보 처리 안내가 필요한 경우, 실제 수집 목적·보유 기간·파기 방법·동의 방식은 입력값과 확인 가능한 공식 정책에 따라 작성하라. 확인되지 않은 법적 적용 여부나 동의 문구를 단정하지 말고 `[확인 필요]`를 붙여라. 개인정보를 수집하는 위젯이면 개인정보 보호법 적용 여부와 해당 서비스의 개인정보 처리방침 링크를 확인 항목으로 포함하라.
5. KWCAG를 접근성 기준으로 삼아라. 색상 대비, 키보드 포커스, 오류 식별, 레이블 연결, 스크린리더 안내를 각각 확인하라. 공공기관·교육·복지 대상이라는 정보가 입력된 경우에만 장애인차별금지법상 정보접근성 의무 적용 여부를 별도 확인 항목으로 두고, 그렇지 않으면 적용 여부를 추측하지 마라.
6. 로딩 상태에서는 중복 제출을 막고, 성공 상태에서는 사용자가 결과를 즉시 알 수 있게 하라. 실패 상태에서는 원인을 확인할 수 있는 범위만 설명하고, 서버 오류나 발송 서비스 오류의 구체적 원인을 지어내지 마라.
7. 한국어 조판을 적용하라. 문장 단위·어절 단위의 줄바꿈을 고려하고, `word-break`와 `line-break` 처리 방향을 제시하라. 본문 행간은 라틴 문자 기준보다 넉넉하게 설정할 것을 권고하되, 정확한 수치를 입력받지 않았다면 `[입력 필요: 디자인 시스템의 행간 기준]`으로 남겨라.
8. 모바일과 데스크톱에서 입력 필드와 버튼이 충분히 조작 가능한지 설명하라. 실제 화면 폭, 브레이크포인트, 터치 영역 수치는 입력에 없으므로 임의로 확정하지 말고 `[입력 필요: 반응형 기준]`으로 표시하라.
9. 외부 발송 서비스나 API를 전제로 하는 경우, 제공된 연동 방식만 사용하라. API 이름, 엔드포인트, 성공 응답, 오류 코드를 지어내지 말고 해당 서비스의 공식 개발자 문서 확인을 요구하라.
10. 성능, 전환율, 구독 증가율 같은 수치를 제시하지 마라. 측정 계획이 필요하면 측정할 이벤트명과 확인할 지표의 구조만 제안하고, 목표값은 `[입력 필요: 측정 목표]`로 남겨라.

## 산출물 구조

다음 순서로 설계안을 작성하라.

1. **목표와 사용 맥락**  
   - 위젯의 목적  
   - 삽입 위치  
   - 주요 사용자 행동  
   - 입력으로 확정해야 할 슬롯  
   이 부분은 짧은 서술형으로 작성하라.

2. **화면 목록**  
   최소한 다음 화면 또는 상태를 목록으로 제시하라.  
   - 기본 상태  
   - 입력 중 상태  
   - 입력 오류 상태  
   - 제출 처리 중 상태  
   - 구독 성공 상태  
   - 구독 실패 상태  
   - 필요 시 이미 구독한 이메일 또는 중복 제출 상태  
   각 항목에는 표시 요소와 사용자가 할 수 있는 행동을 개조식으로 적어라.

3. **화면별 구성요소**  
   화면 또는 상태마다 다음 요소를 표로 정리하라.  
   - 요소명  
   - 목적  
   - 표시 문구 또는 문구 슬롯  
   - 필수 여부  
   - 사용자 행동  
   - 접근성 요구사항  
   문구는 입력되지 않은 브랜드명, 혜택, 발송 주기를 채우지 말고 슬롯으로 표기하라.

4. **사용자 흐름과 상태별 동작**  
   이메일 입력부터 제출, 검증, 처리, 성공 또는 실패까지를 순서대로 설명하라. 정상 흐름과 다음 분기를 반드시 나누어라.  
   - 이메일 형식이 유효한 경우  
   - 이메일이 비어 있는 경우  
   - 이메일 형식이 유효하지 않은 경우  
   - 이미 등록된 이메일인 경우  
   - 네트워크 또는 발송 서비스 처리가 실패한 경우  
   각 분기에서 오류 메시지, 포커스 이동, 재시도 가능 여부, 중복 제출 방지 동작을 적어라.

5. **접근성 및 한국어 조판 점검표**  
   키보드만으로 입력·제출·오류 확인이 가능한지, 스크린리더가 레이블·오류·성공 메시지를 읽는지, 포커스 순서가 자연스러운지, 색상만으로 상태를 구분하지 않는지 적어라. KWCAG 확인 항목과 `word-break`, `line-break`, 행간 처리도 포함하라.

6. **디자인 토큰**  
   색, 타이포그래피, 간격, 모서리, 테두리, 포커스 표시, 버튼 상태를 표로 제시하라. 브랜드 정보가 없으면 각 값은 `[입력 필요: 해당 디자인 토큰]`으로 남겨라. 모바일·데스크톱 차이가 필요한 토큰은 별도로 표시하라.

7. **구현 전 확인사항**  
   블로그 플랫폼, 구독 처리 서비스, 개인정보 처리방침 링크, 브랜드 자산, 성공 후 동작, 반응형 기준을 확인 목록으로 제시하라. 법적·기술적 판단은 관련 공식 문서와 최신 정책을 확인한 뒤 확정하도록 쓰고, 근거 없는 규정 내용을 만들지 마라.

## 문체 규칙

지정 문체는 **hybrid(혼합)**다. 목표와 사용 맥락, 사용자 흐름의 설명은 짧은 서술형으로 쓰고, 화면 목록·구성요소·상태별 동작·접근성 점검표·디자인 토큰·확인사항은 개조식과 표를 사용하라. 문구는 제품 홍보처럼 과장하지 말고, “간편하게”, “최고”, “놓치지 마세요” 같은 상투적·근거 없는 마케팅 표현은 입력에 근거가 있을 때만 사용하라. 한국어 UI에서 어색한 직역투와 지나치게 긴 안내 문장을 피하라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 산출물이 뉴스레터 구독 위젯 설계안인지 확인하고, 실제 뉴스레터 본문이나 구현 코드를 대신 작성하지 않았는지 점검하라.
2. 화면 목록에 기본, 입력 오류, 처리 중, 성공, 실패 상태가 모두 포함되었는지 확인하라.
3. 이메일 입력의 레이블, 필수 여부, 검증 조건, 오류 메시지, 제출 후 동작이 서로 모순되지 않는지 확인하라.
4. 키보드 조작, 포커스 순서, 스크린리더 라벨과 상태 메시지, KWCAG 확인 항목이 빠지지 않았는지 점검하라.
5. 한국어 조판 항목에 `word-break`, `line-break`, 행간 처리가 실제 위젯 문맥에 맞게 들어갔는지 확인하라.
6. 개인정보를 수집하는 뉴스레터 위젯에 대해 수집 목적·보유 기간·파기·처리방침 링크를 임의로 확정하지 않았는지 확인하라.
7. 입력에 없던 사실 추가 여부를 점검하라. 블로그 플랫폼, 발송 서비스, 브랜드명, 혜택, 발송 주기, 법적 적용 여부를 사실처럼 쓰지 말고 슬롯이나 `[확인 필요]`로 남겨라.
8. 슬롯의 임의 채움 여부를 점검하라. 특히 이메일 예시값, 색상 코드, 반응형 수치, 행간, API 엔드포인트를 그럴듯한 값으로 대체하지 마라.
9. 요청 범위 이탈 여부를 점검하라. 뉴스레터 콘텐츠 전략, 구독자 성장률, 전체 블로그 개편처럼 위젯 설계를 넘어서는 내용을 산출물의 핵심으로 확장하지 마라.
10. 표와 목록이 요구된 부분은 개조식으로, 목표·맥락 설명은 서술형으로 작성했는지 확인하라.
11. 외부 서비스나 규정에 관한 근거를 제시할 때 공식 문서 또는 확인 가능한 출처를 요구했는지 확인하고, 확인하지 못한 수치·문서명·조항을 지어내지 마라.