요구사항을 화면 흐름으로 바꾸는 프롬프트

기능이 아니라 사용자가 하려는 일에서 출발합니다. 전제를 표시합니다.

분류	디자인 › 화면·제품 설계
태그	분석질문생성초안작성

프롬프트 (영어 본문 · 답은 한국어로 옵니다)

Turn this request into a screen flow. ***Do not design anything yet.***

1. **State what the user is trying to get done.** ***In their terms, not in features*** — **"find out if my order shipped", not "order tracking page"**
2. **Break it into steps**, and per step: ***what the user has to know, what they have to decide, and what they have to do***
3. **Mark where the request assumes something:**
   - ***That the user arrives already knowing something***
   - That data exists that may not
   - **That there is only one path.** *Most requests describe the happy path only*
4. **Screens the flow needs**, ***derived from the steps — not from the request's own wording***
5. **What the request did not say** — ***where the user comes from, what happens when they leave mid-way, whether they come back***

**Then:**
- ***The question I have to answer before designing*** — usually one, and usually about who this is actually for
- **Where two different users need two different flows**, if so
- **What to cut** — *a step that exists because the system needs it, not because the user does*

⚠️ ***You cannot see the screen. Work only from what I described*** — **do not assume a layout, a component, or a platform convention I did not state.** Where my description is not enough, **say what you would need to see.**

붙여 넣으면 맨 아래에 채울 칸(요청받은 것 · 쓰는 사람)이 나옵니다

어떤 프롬프트인가

요구사항이 기능 이름으로 오면("주문 조회 페이지") 그 이름이 화면 구조를 미리 정해버린다. 사용자가 하려는 일("내 주문이 출발했나")에서 출발해야 다른 답이 나온다. 이 프롬프트는 단계로 쪼갠 뒤 화면을 도출하고, 요청문이 행복 경로만 말하고 있는 지점을 표시한다.

모델 비교

ChatGPT는 근거 있는 분기와 가정 표시가 가장 충실하다. Gemini는 구조는 좋지만 입력에 없는 맥락과 UI를 단정했고, [C]는 답변이 없다.

ChatGPT종합 1위

46/ 50

＋ 가입 방식별 분기와 누락 정책을 충실히 짚었다.

－ 내용이 다소 길고 일부 정책 질문이 반복된다.

Gemini

37/ 50

＋ 메일 확인 이탈과 복귀 맥락을 구체적으로 포착했다.

－ 쇼핑 목적·코드 자릿수·버튼 등 미제공 정보를 지어냈다.

기준	ChatGPT	Gemini	앞선 모델
지시 준수	10	7	ChatGPT +43%
정확성	9	6	ChatGPT +50%
구체성	10	8	ChatGPT +25%
구성·가독성	9	9	동점
분량 적정성	8	7	ChatGPT +14%

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력

요청받은 것: PM이 '비밀번호 찾기 기능 추가해주세요, 이메일로 인증코드 보내는 방식으로요'라고 요청함

쓰는 사람: 카카오·네이버 소셜 로그인으로 가입한 사용자와 이메일로 직접 가입한 사용자가 섞여 있는 커머스 서비스

gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

1. 사용자가 하려는 일

이메일로 직접 가입한 사용자는 내 계정의 비밀번호를 새로 설정해서 다시 로그인하고 싶다.
소셜 로그인 사용자는 내 계정에 비밀번호가 필요한 상황인지, 아니면 카카오·네이버로 계속 로그인해야 하는지 알고 싶다.

즉, 모든 사용자가 실제로 “비밀번호를 찾는” 것은 아닙니다. 특히 소셜 가입자는 서비스에 등록된 비밀번호가 없을 수 있습니다.

2. 사용자 흐름

단계	사용자가 알아야 하는 것	사용자가 결정할 것	사용자가 할 일
1. 로그인에 실패함	어떤 방식으로 가입했는지, 현재 로그인하려는 계정이 무엇인지	비밀번호 재설정이 필요한지, 소셜 로그인을 다시 시도할지	로그인 화면에서 비밀번호 재설정을 선택
2. 계정 식별	비밀번호를 재설정할 계정의 이메일 주소	어떤 이메일 주소를 입력할지	이메일 주소 입력
3. 인증 요청	해당 이메일로 인증코드가 전송된다는 것, 코드의 유효 시간과 재전송 가능 여부	입력한 이메일 주소가 맞는지	인증코드 발송 요청
4. 이메일 인증	받은 코드가 무엇인지, 만료됐는지, 재전송할 수 있는지	코드를 다시 받을지, 처음부터 다시 입력할지	이메일에서 코드를 확인하고 입력
5. 가입 방식 및 계정 상태 확인	이 계정이 이메일 가입인지, 소셜 가입인지, 재설정 가능한 상태인지	안내받은 로그인 방식을 따를지, 이메일 계정으로 비밀번호를 설정할지	인증 결과에 따라 비밀번호 재설정 또는 소셜 로그인으로 이동
6. 새 비밀번호 설정	새 비밀번호 조건, 기존 비밀번호와 달라야 하는지	어떤 비밀번호를 사용할지	새 비밀번호와 확인값 입력
7. 완료 후 로그인	비밀번호 변경이 완료됐는지, 현재 로그인된 상태인지	바로 로그인할지	로그인하거나 이전 로그인 화면으로 돌아감

3. 요청에 포함된 가정

사용자가 이미 알고 있다고 가정한 것

사용자가 로그인에 사용하는 이메일 주소를 알고 있다.
해당 이메일 계정에 접근할 수 있다.
인증코드를 받기 위해 메일함을 확인할 수 있다.
사용자가 자신의 가입 방식을 알고 있거나, 비밀번호 방식으로 가입했다고 생각한다.
인증코드를 입력하면 비밀번호를 바꿀 수 있다는 흐름을 이해한다.

데이터가 존재한다고 가정한 것

입력한 이메일 주소와 연결된 계정이 있다.
그 계정에 인증 가능한 이메일 주소가 등록되어 있다.
인증코드를 보낼 수 있는 메일 발송 시스템이 정상 작동한다.
소셜 가입 계정과 이메일 가입 계정을 구분할 수 있다.
하나의 이메일이 여러 로그인 방식 또는 여러 계정과 연결될 수 있는지에 대한 정책이 정해져 있다.
인증코드 만료, 재전송, 시도 횟수 제한을 처리할 수 있다.
비밀번호를 설정해도 되는 계정인지 판단할 수 있다.

하나의 경로만 있다고 가정한 부분

요청은 다음과 같은 단일 경로만 설명합니다.

이메일 입력 → 인증코드 수신 → 코드 입력 → 새 비밀번호 설정

하지만 실제로는 최소한 아래 경로가 나뉩니다.

이메일 직접 가입 사용자
카카오로 가입한 사용자
네이버로 가입한 사용자
이메일 주소가 존재하지 않는 사용자
이메일은 존재하지만 인증 메일을 받지 못하는 사용자
인증코드가 만료되거나 틀린 사용자
이메일 가입자이지만 계정이 정지된 사용자
동일 이메일에 소셜 로그인과 이메일 가입이 함께 연결된 사용자

특히 소셜 가입자에게 무조건 비밀번호를 설정하게 할지, 원래 사용한 소셜 로그인으로 안내할지가 핵심 정책입니다.

4. 필요한 화면

요청 문구가 아니라 사용자 단계에서 도출하면 다음 화면이 필요합니다.

비밀번호 재설정 시작 화면
- 계정 식별에 필요한 이메일 입력
- 재설정 대상과 절차에 대한 안내
이메일 인증코드 입력 화면
- 인증 대상 이메일 안내
- 코드 입력
- 재전송
- 이메일 주소 수정
- 만료·오류·시도 제한 상태
가입 방식 또는 계정 상태 안내 화면
- 이메일 가입자라면 비밀번호 설정으로 연결
- 카카오·네이버 가입자라면 해당 소셜 로그인으로 안내
- 정책에 따라 비밀번호 설정 가능 여부 안내
새 비밀번호 설정 화면
- 새 비밀번호 입력
- 비밀번호 확인
- 조건 및 오류 안내
완료 화면 또는 로그인 복귀 상태
- 변경 완료 안내
- 로그인으로 이동

별도의 화면이 필요하지 않을 수도 있는 상태도 있습니다. 예를 들어 인증코드 재전송, 잘못된 코드, 만료 코드는 기존 인증 화면 안의 상태로 처리할 수 있습니다. 다만 실제 화면 구조는 기존 로그인·인증 경험을 봐야 판단할 수 있습니다.

5. 요청에서 말하지 않은 것

사용자는 어디에서 이 기능으로 진입하는가?
- 로그인 화면
- 로그인 실패 후
- 고객센터
- 앱 설정
이미 로그인한 사용자가 비밀번호를 바꾸는 기능도 포함하는가?
소셜 가입자에게는 무엇을 보여주는가?
- 카카오·네이버 로그인을 다시 하도록 안내
- 이메일 인증 후 별도 비밀번호 설정 허용
- 해당 기능 자체를 제공하지 않음
이메일 주소가 존재하지 않을 때 계정 존재 여부를 알려줄 것인가?
인증 메일이 오지 않을 때 어떤 도움을 줄 것인가?
사용자가 중간에 나가면 인증 상태를 유지하는가?
인증코드가 발송된 뒤 다시 들어오면 어디서 이어지는가?
인증코드 유효 시간과 재전송 제한은 얼마인가?
비밀번호 변경 후 자동 로그인하는가?
변경된 비밀번호로 기존 세션을 로그아웃시키는가?
계정이 휴면·정지·탈퇴 상태일 때 어떻게 처리하는가?
모바일 앱과 웹에서 동일한 흐름인가?
이메일이 로그인 ID인지, 연락처 이메일인지?
하나의 이메일로 여러 가입 방식이 연결될 수 있는가?

6. 디자인 전에 답해야 할 질문

가장 먼저 정해야 할 질문은 이것입니다.

이 기능의 대상은 이메일 직접 가입자만인가, 아니면 카카오·네이버 소셜 가입자도 포함하는가?

이 질문에 따라 흐름이 달라집니다.

이메일 직접 가입자: 이메일 인증 후 새 비밀번호 설정
소셜 가입자: 비밀번호 재설정 대상이 아닐 수 있으므로, 원래의 카카오·네이버 로그인으로 안내
두 방식을 모두 지원: 인증 후 계정의 가입 방식을 판별하고 분기

추가로 다음 정책도 디자인 전에 확정해야 합니다.

인증한 이메일이 소셜 가입 계정이라면, 사용자가 서비스용 비밀번호를 새로 만들 수 있는가?

7. 서로 다른 사용자의 서로 다른 흐름

이메일 직접 가입자

로그인 화면
→ 이메일 입력
→ 인증코드 확인
→ 새 비밀번호 설정
→ 로그인

카카오·네이버 소셜 가입자

로그인 화면
→ 비밀번호 재설정 선택
→ 이메일 입력
→ 계정이 소셜 가입임을 확인
→ 카카오 또는 네이버 로그인 안내
→ 해당 소셜 로그인으로 이동

소셜 가입자에게 이메일 인증 후 임의로 비밀번호를 설정하게 하면, 계정 보안 정책과 가입 방식의 의미가 달라질 수 있습니다. 이를 허용할지는 제품·보안 정책 결정이 필요합니다.

8. 잘라낼 수 있는 것

사용자에게 필요하지 않고 시스템 처리에 가까운 단계는 별도 화면으로 만들지 않는 것이 좋습니다.

“인증코드 발송 중”을 별도 화면으로 만들기
내부적으로 가입 방식을 조회하는 과정
코드 유효성 검사를 별도 단계로 노출하기
비밀번호 변경 후 내부 세션 갱신을 사용자 단계로 보여주기
성공 여부와 관계없이 이메일 존재 여부를 자세히 알려주는 화면

사용자에게 필요한 것은 결국 다음 세 가지입니다.

내 계정을 식별한다.
내가 그 이메일에 접근할 수 있음을 인증한다.
내가 사용할 로그인 방식을 안내받고, 필요한 경우 새 비밀번호를 설정한다.

현재 설명만으로는 기존 로그인 화면, 가입 방식 저장 구조, 동일 이메일의 중복 연결 정책, 비밀번호 정책과 오류 처리 방식을 볼 수 없으므로 화면 수와 각 상태의 구체적인 표현은 확정할 수 없습니다.

같은 분류의 프롬프트

7대7 축구 팀 앱 설계 프롬프트
접근성 감사자 역할을 맡기는 프롬프트
접근성 감사자 역할 프롬프트
접근성 전문가 역할 프롬프트
접근성 테스트 워크플로 프롬프트

많이 찾는 것

분류