쇼핑몰 결제 플로우 화면 3단계를 설계해 줘

## 역할과 목표

너는 쇼핑몰 결제 플로우를 설계하는 UI/UX 전문가다. 사용자가 제공한 정보만 근거로 결제 과정을 정확히 3단계로 나누고, 각 단계의 화면 구성과 상호작용을 설계하라. 산출물은 화면 목록, 화면별 구성요소, 상태별 동작, 디자인 토큰을 포함하는 JSON 설계안이어야 한다. 완료 여부는 결제 플로우가 정확히 3개 화면 단계로 구분되고, 각 단계에 필요한 입력·검증·이동·오류 처리가 빠짐없이 정의되었는지로 판단한다. 대상 플랫폼이나 정책이 정해지지 않았다면 임의로 확정하지 말고 해당 값을 `[입력 필요: 항목]`으로 표시하라.

## 범위와 전제

다루는 범위는 쇼핑몰의 결제 플로우 화면 3단계 설계다. 각 단계의 목적, 구성요소, 입력 필드, 버튼, 유효성 검사, 로딩·빈 상태·오류 상태, 이전·다음 이동, 결제 완료 또는 실패 후 동작을 포함하라. 화면 밖의 상품 상세, 장바구니 운영 정책, 주문 처리 백엔드, 실제 결제 연동 구현, 법률 검토 결과는 설계 범위에 포함하지 않는다. 다만 화면 동작에 영향을 주는 정책은 확인 항목으로 표시하라.

사용자 입력에서 확인되는 사실은 “쇼핑몰 결제 플로우”와 “3단계”뿐이다. 다음 값은 입력되지 않았으므로 슬롯으로 남겨라.

- 대상 플랫폼: `[입력 필요: 웹 또는 모바일 앱]`
- 인증 방식: `[입력 필요: 비회원·회원·간편인증 정책]`
- 배송 방식과 입력 항목: `[입력 필요: 배송 정책]`
- 결제수단: `[입력 필요: 지원 결제수단]`
- 브랜드 디자인 기준: `[입력 필요: 색상·서체·간격·컴포넌트 기준]`

위 슬롯의 실제 값이 없으면 대표 사례처럼 보이는 임의의 결제수단, 배송비, 할인율, 브랜드 색상 또는 정책을 넣지 말고, 해당 정보가 필요한 위치에 슬롯과 확인 조건을 함께 적어라. 금액·세금·배송비·할인 정보가 주어지지 않았다면 숫자를 생성하지 말고 표시 영역의 구조만 설계하라.

## 작업 규칙

1. 결제 플로우는 반드시 3단계로 설계하라. 단계 수를 늘리거나 줄이지 말고, 각 단계의 책임이 중복되지 않도록 분리하라.
2. 단계의 배치는 다음 조건으로 결정하라.
   - 배송 정보가 필요한 쇼핑몰이면 배송지와 배송 옵션을 한 단계에 묶되, 입력과 검토가 충돌하면 해당 단계 안에서 하위 구역으로 분리하라.
   - 결제수단 선택과 최종 주문 확인을 별도로 검증해야 하면 결제수단 단계와 주문 확인 단계를 나누어라.
   - 비회원 구매가 허용되는지 알 수 없으면 회원 전용 흐름으로 단정하지 말고 `[입력 필요: 회원·비회원 구매 정책]`을 표시하라.
3. 각 화면에는 사용자가 현재 위치를 알 수 있는 단계 표시, 핵심 정보, 주요 행동 버튼, 보조 행동을 정의하라. 주요 버튼은 해당 단계의 필수 입력과 검증이 완료되었을 때만 활성화되는 조건을 적어라.
4. 입력 필드마다 필수·선택 여부, 형식, 오류 메시지, 검증 시점을 구분하라. 입력값의 형식이 정해지지 않았다면 `[입력 필요: 입력 형식]`으로 남겨라.
5. 로딩 상태에서는 중복 제출을 막고, 오류 상태에서는 사용자가 원인을 이해하고 수정할 수 있게 하라. 네트워크 오류, 결제 승인 실패, 세션 만료처럼 결과가 다른 경우를 하나의 성공 메시지로 합치지 말고 별도로 정의하라.
6. 결제 완료 화면은 실제 주문번호, 승인번호, 배송 예정일 등을 입력받지 않았다면 생성하지 말고 `[입력 필요: 표시 데이터]`로 표시하라.
7. 키보드 조작 순서, 포커스 이동, 스크린리더 라벨, 오류 메시지 연결을 설계 항목에 포함하라. 접근성 기준은 한국형 웹 콘텐츠 접근성 지침(KWCAG)을 기준으로 검토하고, 대상이 공공기관·교육·복지 서비스라면 장애인차별금지법상 정보접근성 의무 해당 여부를 `[확인 필요]`로 남겨라.
8. 한글 UI의 줄바꿈은 어절 단위를 우선 고려하고 `word-break`·`line-break` 처리 방향을 명시하라. 본문 행간은 라틴 문자 화면을 그대로 복사하지 말고 한글 가독성을 검토해 설계하라.
9. 이름·주소·전화번호 입력란은 한국형 입력 형식을 적용하되, 구체적인 형식이나 검증 규칙이 제공되지 않았다면 `[입력 필요: 한국형 입력·검증 규칙]`으로 남겨라.
10. 개인정보를 입력받는 화면이면 수집 항목, 이용 목적, 보유 기간, 파기 방법을 주석이 아닌 설계 산출물의 개인정보 처리 항목에 적어라. 법적 적용 여부를 확정하지 말고 개인정보 보호법 확인 항목으로 표시하라.
11. 사실, 정책, 수치, 법적 결론을 지어내지 마라. 확인되지 않은 결제수단명, 배송비, 할인액, 주문번호, 성공률 또는 성능 수치를 넣지 말라.

## 산출물 구조

응답 전체를 유효한 JSON 객체 하나로 반환하라. 마크다운 코드펜스, JSON 밖의 설명, 주석은 포함하지 마라. 모든 키와 문자열 값은 한국어로 작성하되, 필요한 기술 속성명은 코드 표기로 병기할 수 있다.

최상위 키와 타입은 다음과 같다.

- `"목표와_스택"`: 객체
- `"수용_기준"`: 문자열 배열
- `"에지_케이스"`: 객체 배열
- `"검증_방법"`: 객체

`"목표와_스택"`에는 결제 플로우 목표, 대상 플랫폼, 인증 정책, 결제수단 정책, 배송 정책, 디자인 기준을 넣어라. 제공되지 않은 값은 슬롯으로 표시하라.

`"수용_기준"`에는 관찰 가능한 완료 조건을 번호 순서의 문자열로 작성하라. 반드시 정확히 3단계인지, 각 단계의 필수 입력 검증이 작동하는지, 이전·다음 이동이 정의되었는지, 로딩·빈 상태·오류 상태가 포함되었는지, 키보드·스크린리더 접근성이 기술되었는지 확인할 수 있어야 한다.

`"에지_케이스"`에는 각 사례를 객체로 작성하고 `"조건"`, `"화면_반응"`, `"사용자_복구_방법"` 키를 사용하라. 최소한 필수 입력 누락, 잘못된 주소·전화번호 형식, 결제 승인 실패, 네트워크 오류, 중복 제출, 세션 만료, 뒤로 가기, 새로고침, 빈 결제수단 목록을 포함하라. 실제 오류 문구가 정해지지 않았다면 문구 자체를 확정하지 말고 메시지 목적과 `[입력 필요: 오류 문구]`를 표시하라.

`"검증_방법"`에는 다음 객체를 포함하라.

- `"화면_목록"`: 정확히 3개 화면을 담은 배열. 각 항목은 `"단계"`, `"화면명"`, `"목적"`, `"핵심_구성요소"`를 포함한다.
- `"화면별_구성요소"`: 화면별 객체 배열. 각 객체는 `"단계"`, `"입력_필드"`, `"버튼과_이동"`, `"유효성_검사"`, `"접근성"`을 포함한다.
- `"상태별_동작"`: 로딩·빈 상태·오류·성공 상태별 동작을 담은 배열.
- `"디자인_토큰"`: `"색"`, `"타이포그래피"`, `"간격"`, `"한글_조판"`, `"반응형_규칙"`을 포함한다. 브랜드 기준이 없으면 각 값에 슬롯을 사용하고, 가상의 색상 코드나 수치를 만들지 마라.
- `"정책_확인_항목"`: 개인정보 보호법, KWCAG, 공공·교육·복지 대상 여부, 결제·배송·회원 정책의 확인 항목을 담은 배열.
- `"설계_근거"`: 각 단계를 왜 그렇게 배치했는지 짧은 서술형으로 적는다. 근거는 사용자 입력 또는 명시된 슬롯에 한정하라.

## 문체 규칙

전체 문체는 hybrid로 작성하라. 화면 목록, 필드 정의, 수용 기준, 에지 케이스, 디자인 토큰은 짧고 검토 가능한 개조식 JSON 배열·객체로 작성하라. 단계 배치 이유와 사용자 흐름의 연결 관계는 각 단계의 `"설계_근거"`에서 간결한 서술형으로 작성하라. 마케팅식 과장, 임의의 제품명, 근거 없는 확정 표현, 숫자를 포함한 가상 예시는 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 최상위 응답이 JSON 객체 하나인지, JSON 밖의 문장이나 코드펜스가 없는지 확인하라.
2. `"화면_목록"`에 결제 플로우 단계가 정확히 3개만 있는지 확인하라.
3. 3개 단계 각각에 목적, 핵심 구성요소, 주요 버튼, 다음·이전 이동이 정의되어 있는지 확인하라.
4. 입력에 없던 쇼핑몰 사실, 결제수단명, 배송비, 할인액, 주문번호, 날짜, 오류 수치를 추가하지 않았는지 확인하라.
5. 대상 플랫폼, 인증 방식, 배송 정책, 결제수단, 브랜드 기준 슬롯을 임의 값으로 채우지 않았는지 확인하라.
6. 결제 플로우 3단계라는 요청 범위를 벗어나 상품 탐색, 백엔드 구현, 운영 조직 절차를 산출물의 본문 내용으로 확장하지 않았는지 확인하라.
7. 로딩·빈 상태·오류 상태·성공 상태가 모두 정의되고, 중복 제출과 결제 승인 실패가 구분되는지 확인하라.
8. 키보드 조작, 스크린리더 라벨, 포커스 이동, KWCAG 확인 항목이 누락되지 않았는지 확인하라.
9. 한국형 이름·주소·전화번호 입력 형식이 임의로 확정되지 않았고, 필요한 경우 입력 형식 슬롯이 남아 있는지 확인하라.
10. 개인정보 수집 화면에 수집 항목·보유 기간·파기 방법과 개인정보 보호법 적용 확인 항목이 포함되어 있는지 확인하라.
11. 각 디자인 토큰에 가상의 색상 코드, 폰트명, 간격 수치를 사실처럼 넣지 않았는지 확인하라.
12. 오류 메시지는 실제 정책이 없는 경우 `[입력 필요: 오류 문구]` 또는 메시지 목적만으로 남겼는지 확인하라.