코드를 배우기 전에, ChatGPT·Claude·Gemini로 화면부터 만들어보고 눈으로 보고 눌러보며 연습해요. 화면을 만든 다음에는 그 화면을 거꾸로 문제 정의 → 사용자 시나리오 → 데이터 설계 → PRD → 검증으로 뜯어보는 역기획 방식으로, 데이터 중심의 서비스 기획 흐름을 처음부터 끝까지 이해합니다.
이 교안은 전문 기획자나 개발자가 따로 없는 현장에서, 초보 실무자가 회사 홈페이지나 시스템 개선을 스스로 기획해야 하는 상황을 목표로 만들어졌어요. AI를 활용해 화면을 먼저 만들어보고, 그 화면을 거꾸로 문제 정의·시나리오·PRD·데이터 설계로 뜯어보는 과정을 연습합니다. 코드를 직접 작성하는 것보다 UI/UX와 데이터 흐름을 이해하는 기획자의 사고방식을 익히는 데 초점을 둡니다.
이런 상황을 상상해보세요. 작은 회사에 다니는데 전담 기획자가 따로 없어서, 갑자기 여러분이 상품 랜딩페이지 하나를 만들어야 하는 일을 맡게 됐어요. 디자이너도 개발자도 아닌데, 화면을 어떻게 만들어야 할지 막막하죠. 이 장에서는 이런 상황에서 AI가 어떤 역할을 해줄 수 있는지, 그리고 기획자의 일이 예전과 어떻게 달라지는지부터 살펴봅니다.
먼저 원래는 하나의 서비스가 어떤 단계를 거쳐 만들어졌는지부터 알아둘게요. 이 흐름을 알아야, 이후 AI가 어느 단계를 빠르게 만들어주는지 비교할 수 있어요.
앞서 본 흐름 중에서도 특히 기획 초반부(아이디어~UX/UI 설계)가 AI로 인해 크게 달라지고 있어요. 예전에는 화면 없이 문서로만 설명해야 했다면, 지금은 어떻게 다른지 비교해볼게요.
문서와 와이어프레임으로 설명한 뒤 디자인·개발 결과가 나와야 실제 화면을 확인하는 경우가 많았어요.
기획자가 자연어로 화면을 만들고 직접 확인한 뒤 수정하면서 요구사항을 더 구체화할 수 있어요.
그렇다면 앞의 랜딩페이지 사례로 돌아가볼게요. 디자이너·개발자에게 바로 넘기기 전에, 기획자가 AI로 직접 화면을 만들어보면 어떤 점이 좋을까요?
문서로만 설명하던 아이디어를 화면으로 만들며 실제 사용 모습을 더 빠르게 확인해요.
직접 화면을 보면서 빠진 정보·불편한 흐름·수정할 요소를 발견해요.
디자인·개발 단계로 넘어가기 전에 기획 의도를 시각적으로 확인해요.
계속해서 랜딩페이지를 맡게 된 상황이라고 해볼게요. AI가 화면을 만들어줬는데, 동료가 "이거 백엔드는 어떻게 처리돼요?", "데이터베이스에는 뭐가 저장되나요?"라고 물어보면 당황할 수 있어요. AI에게 서비스를 설명하고 결과를 판단하려면 코드를 외우기보다, 화면·기능·데이터·서비스 공개 단계가 어떻게 구분되는지 먼저 이해하는 것이 중요해요. 특히 데이터가 어디에 저장되고 어떻게 오가는지를 아는 것은 이후 5장의 데이터 설계와 바로 연결됩니다. 이후 실습에서 계속 등장하는 최소 용어부터 잡아봅니다.
AI가 만들어준 화면이 실제 서비스가 되려면, 화면 뒤에서 어떤 부분들이 함께 움직이는지 알아야 해요. 아래 세 용어는 실무에서 가장 자주 쓰는 최소 단위입니다.
머릿속 아이디어가 실제 화면이 되기까지는 몇 단계를 거쳐요. 이번 실습에서 AI에게 요청할 결과물이 이 단계 중 어디쯤에 해당하는지 알아두면, 원하는 결과를 더 정확히 요청할 수 있어요.
| 용어 | 쉽게 설명하면 | 기획자가 확인하는 것 |
|---|---|---|
| 와이어프레임 | 화면의 구조와 정보 배치를 단순하게 잡은 초안 | 무엇이 어디에 배치되는가? |
| 프로토타입 | 실제 화면처럼 보이거나 일부 동작을 시험해볼 수 있는 결과물 | 사용 흐름이 자연스러운가? 요구사항이 화면에 반영됐는가? |
일상에서는 셋 다 그냥 "홈페이지"라고 뭉뚱그려 부르는 경우가 많아요. 하지만 AI에게 무엇을 만들어달라고 요청할 때는, 세 단어가 가리키는 규모와 필요한 기술이 다르다는 걸 알아두면 더 정확하게 요청할 수 있어요.
| 구분 | 쉽게 말하면 | 예시 | 필요한 것 |
|---|---|---|---|
| 홈페이지 | 정보 전달 위주의 페이지 한두 장. 회사·가게를 소개하는 "대문" 역할 | 식당 소개 페이지, 개인 포트폴리오 | 화면(프론트엔드)만으로도 충분한 경우가 많음 |
| 웹사이트 | 여러 페이지가 메뉴로 연결된 정보 모음 전체. 홈페이지는 그중 첫 화면을 가리킬 때가 많음 | 뉴스 사이트, 회사 소개+채용+블로그가 있는 사이트 | 화면 여러 개 + 페이지 간 이동 구조(IA) |
| 웹서비스 | 로그인해서 나만의 데이터로 무언가를 "하는" 서비스 | 온라인 쇼핑몰, SNS, 이메일 서비스 | 화면(프론트엔드) + 요청 처리(백엔드) + 데이터베이스 전부 필요 |
회사에서 업무를 받았는데, 개발자와 함께 웹사이트를 만들어야 한다고 해볼게요. 화면이 하나가 아니라 여러 개로 늘어나면, 기획자는 정보 구조·사용자 흐름·기능·화면을 서로 다른 문서로 정리하면서 설계를 구체화합니다. AI를 활용할 때도 이 문서들의 역할을 알면 더 정확한 결과를 요청할 수 있어요.
아래 문서들은 반드시 왼쪽부터 순서대로 만드는 산출물이 아니에요. 프로젝트에 따라 필요한 문서를 선택하고, 설계 과정에서 서로 영향을 주고받으며 반복해서 수정합니다.
앞서 IA·플로우차트·기능정의서 등의 이름만 훑어봤다면, 이번에는 각 문서가 정확히 무엇을 담고 어떤 질문에 답하는 문서인지 하나씩 짚어볼게요.
| 문서 | 무엇을 정리하나? | 대표 질문 |
|---|---|---|
| IA Information Architecture | 콘텐츠·메뉴·페이지·내비게이션 등 서비스의 정보 구조 | 어떤 정보가 필요하고, 어떻게 분류·연결·탐색되게 할 것인가? |
| 플로우차트 | 사용자 행동이나 시스템 처리의 순서 | 사용자가 이 버튼을 누르면 다음에는 어디로 가는가? |
| 기능정의서 | 서비스에서 제공할 기능과 동작 조건 | 이 기능은 무엇을 하고, 어떤 조건에서 동작하는가? |
| 와이어프레임 | 화면의 기본 구조와 정보 배치 | 어떤 정보를 어느 위치에 보여줄 것인가? |
| 화면설계서 | 화면별 UI 요소·동작·예외·연결 조건 | 이 화면에서 사용자가 무엇을 보고, 누르고, 어떤 결과를 받는가? |
아래 이미지는 각 산출물의 형태를 빠르게 구분하기 위한 참고 예시예요. 회사와 프로젝트마다 문서 양식은 달라질 수 있으므로, 모양을 그대로 외우기보다 각 문서가 무엇을 전달하는지에 집중해보세요.
IA는 콘텐츠·메뉴·내비게이션 등의 정보 구조를 설계하는 개념이고, 사이트맵은 그 구조를 페이지 계층 형태로 표현하는 대표적인 방법 중 하나예요.
출처: Ucraft · UX Sitemaps
시작점에서 사용자의 행동과 조건에 따라 다음 단계가 어떻게 달라지는지 화살표로 표현해요. 로그인·회원가입처럼 분기가 있는 기능을 설명할 때 특히 유용합니다.
출처: Slickplan · User Flow Diagram Example
기능을 화면 모양이 아니라 ‘무엇을 해야 하는가’ 중심으로 항목화한 예시예요. 실무 양식은 표 형태 등으로 다양하게 작성됩니다.
교안용 재현 예시
색상이나 완성된 디자인보다 헤더·CTA·콘텐츠·이미지 등의 위치와 우선순위를 단순한 박스로 확인하는 단계예요.
출처: Design by Draft · Website Wireframe Draft
화면의 각 UI 요소에 번호를 붙이고, 오른쪽에 동작·조건·정책을 상세하게 설명하는 형태예요. 실제 양식과 포함 항목은 조직과 프로젝트에 따라 달라질 수 있습니다.
교안용 재현 예시아니에요. 프로젝트 규모와 팀의 협업 방식에 따라 필요한 문서는 달라질 수 있어요. 작은 프로토타입에서는 간단한 IA와 화면 설명만으로도 충분할 수 있고, 기능이 복잡해질수록 플로우차트·기능정의서·화면설계서가 더 중요해집니다.
지금까지는 IA·플로우차트·기능정의서 같은 문서의 형태를 익혔어요. 하지만 문서를 채우기 전에 먼저 정리해야 할 것이 있습니다. 바로 무엇을, 왜 만드는가예요. 이 파트에서는 문제를 정의하고 가설·지표까지 잡은 뒤, 마지막에는 이 내용을 하나의 간단한 기획서로 모아봅니다. 계속해서 온라인 강의 탐색·신청 서비스를 예시로 사용할게요.
좋은 문제 정의는 ① 타깃 + ② 타깃에게 일어나는 현상 + ③ 타깃이 겪는 문제, 이 세 가지가 하나로 합쳐질 때 만들어져요. 해결책을 먼저 적지 않고, 누가·무엇 때문에·어떤 어려움을 겪는지부터 사실 위주로 적는 것이 핵심입니다.
| 구성요소 | 무엇을 적나? | 주의할 점 |
|---|---|---|
| ① 타깃 | 문제를 겪는 구체적인 상황과 행동 | ‘20대 직장인’처럼 넓게 잡지 말고 ‘퇴근 후 강의를 듣는 직장인’처럼 좁혀요. |
| ② 타깃에게 일어나는 현상 | 눈에 보이는 불편함 그 자체 | 내 판단이 아니라 ‘~하기 어렵다’ 같은 사실 위주로 적어요. |
| ③ 타깃이 겪는 문제 | 그 현상 때문에 겪는 부정적 결과 | ‘~하다’, ‘~겪는다’처럼 서술형 문장으로 손실이나 리스크를 적어요. |
예시
| ① 타깃 | ② 타깃에게 일어나는 현상 | ③ 타깃이 겪는 문제 |
|---|---|---|
| 퇴근 후 강의를 듣는 직장인 | 강의 목록에서 난이도와 선수 지식 요구사항을 확인하기 어렵다 | 맞지 않는 강의를 결제했다가 환불을 요청하는 경우가 많다 |
| 수강 후기를 비교하는 예비 수강생 | 후기가 여러 페이지에 흩어져 있어 비교하기 어렵다 | 결정을 미루다가 할인 기간을 놓치는 손실을 겪는다 |
문제 정의가 나왔다면, ‘왜 이런 문제가 발생할까?’를 반복해서 물으며 근본 원인을 찾아보세요. 눈에 보이는 현상만 고치면 같은 문제가 반복될 수 있어요. 1940년대 Toyota가 생산 현장의 문제를 원인이 나올 때까지 반복해서 물었던 방식에서 시작된 기법으로, 오늘날에는 서비스 기획에서도 널리 쓰입니다.
여기서 첫 현상은 ‘환불 요청 증가’였지만, 근본 원인은 ‘난이도 표기 정책 부재’에 가까워요. 따라서 해결책은 안내 문구를 늘리는 것보다 난이도 입력을 필수 항목으로 바꾸는 정책이 될 수 있습니다.
문제 정의를 검증 가능한 가설로 바꾸면, 이 서비스가 방향대로 가고 있는지 나중에 지표로 확인할 수 있어요. 가설은 “[특정 타깃]이 [어떤 행동]을 한다면, [어떤 긍정적인 변화]가 생길 것이다. 왜냐하면 [근거]가 있기 때문이다” 형식으로 작성합니다.
| 문제 정의 | 가설 |
|---|---|
| 퇴근 후 강의를 듣는 직장인은 강의의 난이도와 선수 지식을 미리 확인하기 어려워, 맞지 않는 강의를 결제했다가 환불을 요청하는 리스크를 겪는다. | [강의를 탐색하는 직장인]이 [강의 상세 화면에서 난이도·선수 지식을 미리 확인]한다면, [환불 요청이 줄어들] 것이다. 왜냐하면 [구매 전 판단 오류를 줄일 수 있기] 때문이다. |
가설을 세웠다면, 이 가설이 맞았는지 판단할 지표도 함께 정해야 해요. 지표는 서비스의 건강 상태를 보여주는 신호등과 같습니다. 아래는 유명 서비스들이 실제로 보는 지표 사례예요.
멤버십 가입자 수보다 가입 후 구매 빈도 변화를 봅니다. 락인 효과를 증명하는 지표예요.
주문 완료율을 중요하게 봅니다. 메뉴 선택부터 결제까지 어디서 이탈하는지 찾아냅니다.
송금 성공 경험을 넘어 DAU와 다른 금융 상품 이용률을 함께 관리합니다.
업종이 다르면 지표와 가설도 완전히 달라져요. 아래는 서로 다른 세 가지 서비스의 예시예요.
| 서비스 | 문제 상황 | 가설(요약) | 핵심 지표 |
|---|---|---|---|
| 간단한 출석 체크 앱 | 학생 출석을 수기로 관리해 누락·지연이 잦다 | QR로 출석하면 누락이 줄어들 것이다 | 출석 누락률, 출석 처리 소요 시간 |
| 중고거래 플랫폼 | 거래 상대를 믿을 수 없어 거래를 포기한다 | 거래 후기·인증 배지를 보여주면 거래 완료율이 오를 것이다 | 채팅 시작 대비 거래 완료율 |
| 기업용 회계 서비스 | 반복 입력 업무로 담당자 시간이 많이 든다 | 반복 항목을 자동 분류하면 입력 시간이 줄어들 것이다 | 전표 1건당 평균 처리 시간 |
잘 알려진 서비스들의 초기 지표·가설도 짐작해볼 수 있어요. (공식 발표 자료가 아니라 서비스 구조로 미루어 짐작한 추정이에요.)
게스트가 숙소 사진만 보고 예약해도 실제로 만족했는지가 중요했을 거예요. 예약 완료율·후기 평점이 핵심 지표였을 것으로 보여요.
게시물 수보다 얼마나 자주 다시 열어보는가(재방문·DAU)가 더 중요한 신호였을 것으로 보여요.
한 번의 답변 품질도 중요하지만, 다시 돌아와서 또 질문하는가(재사용률)를 핵심으로 봤을 가능성이 커요.
지표나 가설은 많다고 좋은 게 아니에요. 제가 예전에 몸담았던 스타트업은 당시 직원 50~100명 규모였고, 지금은 상장까지 한 회사예요. 그 시절엔 변변한 체계가 거의 없었지만, 회사 전체가 함께 보는 지표는 딱 하나, 매출이었어요. 그리고 그건 지금도 크게 다르지 않아요.
지표나 가설이 복잡하다고 더 좋은 기획이 되는 건 아니에요. 오히려 복잡할수록 설계 비용, 관리 비용, 동료를 설득하는 비용만 커져요. 기획자든 디자이너든 마케터든 누가 봐도 명확한 기준 하나가 훨씬 강력할 때가 많습니다.
| 가설 | 핵심 지표와 측정 방법 |
|---|---|
| [강의를 탐색하는 직장인]이 [난이도·선수 지식을 미리 확인]한다면, [환불 요청이 줄어들] 것이다. | ● 지표: 결제 후 7일 이내 환불률 ● 방법: 결제 완료 로그 대비 환불 신청 로그 비율로 계산 |
문제와 가설이 정해졌다면, 이제 사용자가 실제로 서비스를 어떻게 이용하게 될지 구체적인 장면으로 그려볼 차례예요. 시나리오 한 편을 사용자 흐름으로 잘게 나누고, 예외 상황까지 점검한 뒤, 필요한 화면을 모아 전체 구조도(IA)로 정리합니다.
시나리오를 쓰기 전에 먼저 짚어야 할 질문이 있어요. 바로 "누가 이 서비스를 쓰는가?"예요. 많은 초보 기획자가 사용자를 한 명으로만 생각하고 시나리오를 쓰기 시작하는데, 실제로는 같은 서비스 안에도 여러 종류의 사용자가 섞여 있는 경우가 훨씬 많아요.
배달앱을 예로 들어볼게요. 이 서비스 안에는 최소 세 종류의 사용자가 있어요.
음식을 주문하는 사람. 메뉴를 탐색하고, 주문하고, 리뷰를 남겨요.
메뉴를 등록하고 주문을 받는 사람. 재고·영업시간을 관리해요.
주문을 실제로 배달하는 사람. 콜을 수락하고 경로를 확인해요.
같은 "고객" 안에서도 다시 나눌 수 있어요. 아래처럼 비회원 → 무료회원 → 유료회원 순서로 서비스에 관여하는 깊이가 달라지고, 그 안에서도 더 세분화할 수 있습니다.
| 사용자 유형 | 무엇을 하는가 | 기획할 때 중요한 요소 |
|---|---|---|
| 비회원(게스트) | 가입 전, 둘러보기만 하는 상태 | 어디까지 로그인 없이 보여줄지, 회원가입을 언제 유도할지 |
| 무료회원 | 가입은 했지만 결제는 하지 않은 상태 | 무료로 어디까지 제공할지의 경계선, 유료 전환 유도 시점 |
| 유료회원 | 결제·구독을 통해 핵심 기능을 이용하는 상태 | 결제·환불 정책, 등급별(구독 단계별) 혜택 차이 |
| 공급자(파트너) | 상품·콘텐츠를 등록하고 운영하는 다른 축의 사용자 | 승인 절차, 정산 방식, 고객과는 다른 화면·정책이 필요 |
그럼 프롬프트로 내 서비스의 사용자 유형을 나눠볼까요?
시나리오는 사용자가 서비스를 이용하는 장면을 한 편의 이야기로 정리한 것이에요. 다만 이야기 형태만으로는 어떤 화면과 기능이 필요한지 바로 알기 어려워서, 이를 ‘사용자의 행동’ 또는 ‘시스템의 처리’ 최소 단위로 잘게 나눈 표로 다시 정리합니다. 이것이 사용자 흐름(User Flow)이에요.
| 순서 | 행동 및 처리 | 화면명 |
|---|---|---|
| 1 | 사용자가 서비스를 실행한다 | 시작 화면 |
| 2 | 사용자가 관심 분야를 선택한다 | 관심 분야 선택 화면 |
| 3 | 시스템이 관련 강의를 보여준다 | 강의 목록 화면 |
| 4 | 사용자가 강의 하나를 선택한다 | 강의 상세 화면 |
| 5 | 사용자가 강의를 장바구니에 담는다 | 강의 상세 화면 |
| 6 | 사용자가 결제를 진행한다 | 결제 화면 |
| 7 | 시스템이 결제 결과를 처리하고 완료 상태를 보여준다 | 신청 완료 화면 |
성공 흐름만 정의하면 실제 사용 중 발생하는 문제를 놓치기 쉬워요. 실패·예외 상황까지 함께 정의해야 사용자가 다시 정상 흐름으로 돌아올 수 있는 방법까지 설계할 수 있습니다. 실패와 예외는 새로운 화면이 아니라 같은 화면의 다른 상태로 표현되는 경우가 많아요.
| 구분 | 상황 | 행동 및 처리 | 관련 화면 |
|---|---|---|---|
| 성공 | 장바구니에 강의가 담겨 있음 | 결제를 진행하고 완료 상태를 보여준다 | 결제 화면 |
| 실패 | 결제 승인에 실패함 | 실패 이유와 다시 시도 버튼을 보여준다 | 결제 화면 |
| 예외 | 이미 신청한 강의임 | 이미 신청된 강의임을 알려준다 | 강의 상세 화면 |
| 예외 | 선택한 분야에 강의가 없음 | 다른 분야 선택 또는 전체 강의 보기를 안내한다 | 강의 목록 화면 |
사용자 흐름의 화면명을 모아 중복을 제거하면, 전체 서비스에 몇 개의 화면이 필요한지, 그리고 그 화면들이 어떤 위계로 연결되는지 보이기 시작해요. 이것이 3.1~3.3에서 배운 IA(Information Architecture)를 실제로 채우는 과정입니다.
지금까지 배운 내용을 하나로 취합해 간단한 요구사항 기획서(축약형 PRD)를 만들어볼게요. 문제와 해결 방안이 한 문서에 모이면, AI에게 프로토타입을 요청할 때도, 다른 사람과 기획 의도를 공유할 때도 훨씬 정확하게 전달할 수 있습니다.
| 항목 | 작성 내용 |
|---|---|
| 개요 | 퇴근 후 강의를 듣는 직장인이 난이도·선수 지식을 미리 확인하고 신청까지 마치는 온라인 강의 탐색·신청 서비스 |
| 문제, 가설, 지표 | 3.5에서 정리한 문제 정의·가설·핵심 지표(결제 후 7일 이내 환불률) |
| 전체 메뉴 구조도 | 3.6.4에서 정리한 IA — 홈 / 탐색 / 구매 / MY |
| 유즈케이스 시나리오 | 3.6.2의 성공 흐름 + 3.6.3의 실패·예외 흐름 |
본격적인 서비스 기획에 들어가기 전에, 먼저 AI에게 화면을 요청하고 눈으로 보고 눌러보는 경험부터 해볼게요. 프롬프트 1~2개로 끝나는 가벼운 실습이에요. 코드를 계속 고치는 바이브코딩까지는 들어가지 않고, "AI에게 말하면 화면이 생긴다"는 감각을 익히는 데만 집중합니다.
프롬프트를 넣기 전에, 채팅 AI가 만든 화면을 어디서 어떻게 확인하는지부터 알아둘게요. ChatGPT·Claude·Gemini는 각각 이름은 다르지만, 대화창 옆(또는 안)에 결과 화면을 띄워서 바로 눌러볼 수 있게 해주는 기능이 있어요.
답변에 코드가 텍스트(코드블럭)로만 나올 때가 있어요. 그럴 땐 "이 코드를 Canvas(또는 코드 블럭)에서 실행 가능한 형태로 보여줘"라고 요청하세요.
왼쪽 아티팩트 메뉴가 꺼져 있으면 결과가 텍스트로만 나와요. 안 열리면 "이 결과를 실행 가능한 아티팩트로 만들어줘"라고 요청하세요.
보통 우측 캔버스 패널에 자동으로 뜨지만, 안 보이면 "Canvas에서 실행 가능한 웹 앱으로 만들어줘"라고 요청하세요.
숫자와 표로 된 데이터를 AI에게 주면, 그래프와 표가 있는 화면으로 바꿔줄 수 있어요. 아래 샘플 매출 데이터 파일을 다운로드해서 준비해주세요.
파일을 받았다면 ChatGPT·Claude·Gemini 중 편한 도구를 열고, 파일을 첨부한 뒤 아래 프롬프트를 순서대로 입력해보세요.
미리보기(캔버스/아티팩트)로 화면이 뜨면, 그래프와 표가 어떻게 배치되었는지 살펴보세요. 이어서 아래처럼 한 가지만 더 고쳐봅니다.
마지막으로 이 결과물을 다운로드해서 직접 열어볼게요. 캔버스/아티팩트 화면 우측 상단의 다운로드 버튼으로 .html 파일을 저장한 뒤, 내 컴퓨터에서 그 파일을 더블클릭해 브라우저로 직접 열어보세요. AI 안에서 보던 것과 똑같이 동작하나요?
확인 포인트 · 테스트 체크리스트
기본 대시보드가 완성됐다면, 아래 4가지 프롬프트로 하나씩 더 고쳐볼게요. 순서대로 진행해도 되고, 관심 있는 것부터 골라서 해도 괜찮아요.
1) 모바일 화면에서 표가 깨지는 부분을 고쳐볼까요?
2) 표 데이터를 30개의 가상 데이터로 늘려볼까요?
3) 검색 영역을 추가해볼까요?
4) 정렬 기능을 추가해볼까요?
심화 프롬프트 체크리스트
이번에는 데이터 없이, 말로만 설명해서 화면을 만들어볼게요. 목록형 화면은 서비스 기획에서 아주 자주 등장하는 패턴이에요. 먼저 정해진 항목을 체크만 하는 정적인 버전부터 만들어봅니다.
체크박스를 눌러 완료 표시가 잘 되는지 확인해보세요.
확인 포인트 · 테스트 체크리스트
지금 만든 화면은 새로고침하면 체크 상태가 사라져요. 이번엔 추가·수정·삭제 기능을 만들고, 브라우저에 저장(로컬 스토리지)해서 새로고침해도 남아있게 만들어볼게요.
1) 먼저 항목을 추가하고 저장하는 기능부터 만들어볼까요?
2) 항목을 수정하는 기능도 추가해볼까요?
3) 마지막으로 삭제 기능을 추가해볼까요?
심화 프롬프트 체크리스트
이번엔 규모가 더 커져서, 여러분이 아예 작은 서비스 하나를 처음부터 기획하는 담당자가 됐다고 해볼게요. 이번 파트에서는 순서를 바꿔봅니다. 기획서를 먼저 쓰고 화면을 만드는 대신, AI에게 화면부터 만들어달라고 요청하고, 그 화면을 보면서 거꾸로 기획서를 채워나가요. 실무에서도 완성된 화면이나 경쟁 서비스를 보고 "이건 어떤 문제를 풀려고 이렇게 만들었을까?"를 분석하는 역기획은 자주 쓰이는 방법이에요.
많은 스타트업이나 중소기업은 데이터를 제대로 분석할 수 있는 환경 자체가 갖춰져 있지 않은 경우가 많아요. 그렇다고 회사에 데이터가 없는 건 아니에요. 어떤 형태로든 비즈니스를 하고 있다면 이미 무수히 많은 데이터가 쌓여 있을 가능성이 커요. 진짜 문제는 그 데이터가 여기저기 산발적으로 흩어져 있다는 것이었어요.
요즘은 AI 덕분에 데이터를 통째로 내려받아 직접 분석을 맡기거나, 내가 모르던 영역까지 AI가 함께 탐색해볼 수 있는 방법이 많아졌어요. 그래서 오히려 "우리가 왜 이 제품을 만들었고, 무엇을 증명하고 검증하려 했는가"를 계속 고민하는 쪽이 더 중요해졌습니다. 이 질문만 분명하면, 데이터 분석 자체는 예전보다 훨씬 쉬워져요.
상품 하나를 소개하고 구매(또는 상담 신청)까지 유도하는 랜딩페이지를 만들고, 이 화면을 거꾸로 기획서로 정리해볼게요.
먼저 AI에게 화면을 요청하고, 만들어진 결과를 미리보기(캔버스/아티팩트)로 직접 눌러보며 확인하는 단계예요. 완벽한 화면을 만드는 게 목표가 아니라, 화면의 구조와 흐름을 눈으로 파악하는 것이 이번 스텝의 목표입니다.
아래 이미지는 상품 참고 이미지예요. 이미지 위 "이미지 복사" 버튼을 누르면 클립보드에 복사돼요. AI 프롬프트 입력창에 Ctrl+V(Mac은 Cmd+V)로 붙여넣고, 이 상품으로 랜딩페이지를 만들어달라고 요청해보세요. 버튼이 동작하지 않으면 이미지를 길게 눌러(우클릭) 저장한 뒤 파일로 첨부해도 돼요.
그럼 이미지를 붙여넣고, 프롬프트로 한번 만들어볼까요?
방금 만든 화면을 보고, 이 화면이 왜 만들어졌는지 거꾸로 추론해보는 단계예요. 화면의 각 요소가 어떤 사용자의 어떤 불편을 해결하려는 건지 생각하면서 살펴보세요.
아래는 예시예요. AI의 답변이 이 표와 똑같지 않아도 괜찮아요.
| 타깃 | 타깃에게 일어나는 현상 | 타깃이 겪는 문제 |
|---|---|---|
| 텀블러를 선물할지 고민하는 예비 구매자 | 제품 상세 페이지에서 소재·용량·보온 시간 같은 핵심 정보를 한눈에 비교하기 어렵다 | 비교하다 지쳐 페이지를 이탈하고 다른 쇼핑몰에서 구매를 결정한다 |
그럼 프롬프트로 화면을 보고 문제 정의를 역으로 추론해볼까요?
사용자가 화면에서 어떤 순서로 행동하는지, 그리고 일이 잘못됐을 때는 어떻게 되는지 성공·실패 두 갈래로 나눠 생각해보는 단계예요.
아래는 예시예요.
| 구분 | 행동 및 처리 | 화면/결과 |
|---|---|---|
| 성공 | 사용자가 제품 정보를 확인하고 "구매하기"를 누른다 | 결제 페이지로 이동한다 |
| 실패 | 재고가 없는 상태에서 "구매하기"를 누른다 | 품절 안내와 "재입고 알림 받기" 버튼을 보여준다 |
그럼 프롬프트로 성공·실패 시나리오를 정리해볼까요?
화면 뒤에서 어떤 데이터가 새로 생기고, 저장되고, 지워지는지 짚어보는 단계예요. 눈에 보이지 않는 부분까지 상상해보는 연습입니다.
아래는 예시예요.
| 데이터 | 구분 | 설명 |
|---|---|---|
| 구매 수량 | 입력 | 사용자가 화면에서 직접 선택 |
| 주문 정보 | 저장 | 구매하기를 누르면 주문 테이블에 생성 |
| 재입고 알림 신청 | 추가 | 품절 상태에서 알림 신청 시 목록에 추가 |
| 재입고 알림 신청 | 삭제 | 재입고 안내 발송 후 목록에서 제거 |
사용자가 아무 행동도 하기 전에, 이 화면이 정상적으로 뜨려면 시스템에 이미 어떤 데이터가 준비되어 있어야 하는지 생각해보는 단계예요.
아래는 예시예요.
| 데이터 | 설명 |
|---|---|
| 제품 정보 | 이름·설명·가격·이미지 — 화면을 열기 전에 이미 존재해야 함 |
| 재고 수량 | 구매 가능 여부를 판단하는 기준값 |
그럼 프롬프트로 데이터까지 한번에 정리해볼까요?
이제 STEP 1~4에서 정리한 문제 정의·시나리오·데이터 설계를 하나로 모아 최종 기획서(PRD)로 완성하는 단계예요. 이 표가 이번 실습 전체의 결과물이라고 생각하면 됩니다.
아래는 예시예요.
| 항목 | 작성 내용 |
|---|---|
| 개요 | 텀블러 신제품 정보를 소개하고 구매까지 유도하는 상품 랜딩페이지 |
| 문제 | STEP 1의 문제 정의 |
| 핵심 기능 | 제품 정보 노출, 구매하기, 재고 없음 안내 |
| 주요 시나리오 | STEP 2의 성공·실패 시나리오 요약 |
| 데이터 설계 | STEP 3·4의 입력·저장·삭제 데이터 및 기본 데이터 요약 |
| 성공 지표 | 랜딩페이지 방문 대비 구매 전환율 |
그럼 프롬프트로 지금까지 내용을 모두 합쳐 PRD를 완성해볼까요?
직접 만든 결과와 비교해보고 싶다면, 아래에서 완성 예시(모범 답안) PDF를 받아 참고해보세요.
이번에는 특정 이벤트에 참여 신청을 받는 설문 폼을 만들고, 같은 방식으로 역기획해볼게요.
이번에도 먼저 AI에게 화면을 요청하고 미리보기로 직접 눌러보며 확인해요. 입력창·선택지·버튼이 어떤 순서로 배치되어 있는지 눈여겨보세요.
그럼 프롬프트로 한번 만들어볼까요?
방금 만든 화면을 보고, 이 화면이 왜 만들어졌는지 거꾸로 추론해보는 단계예요. 신청 폼을 운영하는 담당자 입장에서 어떤 불편이 있었을지 생각해보세요.
아래는 예시예요.
| 타깃 | 타깃에게 일어나는 현상 | 타깃이 겪는 문제 |
|---|---|---|
| 체험단 이벤트를 운영하는 마케팅 담당자 | 신청자 정보를 메신저·메일로 따로따로 받아 취합하기 어렵다 | 취합이 늦어져 선정·안내 일정이 밀리고 신청자 응대가 지연된다 |
그럼 프롬프트로 화면을 보고 문제 정의를 역으로 추론해볼까요?
신청을 완료하는 성공 흐름과, 입력을 잘못하거나 중복 신청하는 실패 흐름을 나눠 생각해보는 단계예요.
아래는 예시예요.
| 구분 | 행동 및 처리 | 화면/결과 |
|---|---|---|
| 성공 | 필수 항목을 모두 입력하고 신청하기를 누른다 | 신청 완료 화면을 보여준다 |
| 실패 | 연락처를 형식에 맞지 않게 입력한다 | 어떤 항목이 잘못됐는지 표시하고 제출을 막는다 |
| 실패 | 이미 신청한 사람이 같은 이메일로 다시 신청한다 | 중복 신청임을 안내한다 |
그럼 프롬프트로 성공·실패 시나리오를 정리해볼까요?
신청자가 입력한 정보가 어디에 저장되고, 취소하면 어떻게 되는지 짚어보는 단계예요.
아래는 예시예요.
| 데이터 | 구분 | 설명 |
|---|---|---|
| 이름·연락처·이메일·참여 시간대 | 입력 | 신청자가 화면에서 직접 입력 |
| 신청 내역 | 저장 | 신청하기를 누르면 신청자 목록에 생성 |
| 신청 취소 | 삭제 | 신청자가 마감 전 취소하면 목록에서 제거 |
사용자가 아무 행동도 하기 전에, 이 화면이 정상적으로 뜨려면 시스템에 이미 어떤 데이터가 준비되어 있어야 하는지 생각해보는 단계예요.
아래는 예시예요.
| 데이터 | 설명 |
|---|---|
| 이벤트 정보 | 이벤트명·모집 인원·마감일 — 신청 가능 여부 판단에 필요 |
| 참여 가능 시간대 목록 | 사용자가 선택할 수 있도록 미리 정의되어 있어야 함 |
그럼 프롬프트로 데이터까지 한번에 정리해볼까요?
이제 STEP 1~4에서 정리한 문제 정의·시나리오·데이터 설계를 하나로 모아 최종 기획서(PRD)로 완성하는 단계예요.
아래는 예시예요.
| 항목 | 작성 내용 |
|---|---|
| 개요 | 체험단 이벤트 참여 신청을 한 화면에서 받는 설문 신청 페이지 |
| 문제 | STEP 1의 문제 정의 |
| 핵심 기능 | 신청 정보 입력, 유효성 검사, 중복 신청 방지, 신청 완료 안내 |
| 주요 시나리오 | STEP 2의 성공·실패 시나리오 요약 |
| 데이터 설계 | STEP 3·4의 입력·저장·삭제 데이터 및 기본 데이터 요약 |
| 성공 지표 | 신청서 제출 완료율 |
그럼 프롬프트로 지금까지 내용을 모두 합쳐 PRD를 완성해볼까요?
직접 만든 결과와 비교해보고 싶다면, 아래에서 완성 예시(모범 답안) PDF를 받아 참고해보세요.
마지막으로 거의 모든 서비스에 들어가는 로그인·회원가입 화면을 만들고 기획서로 정리해볼게요.
로그인 화면과 회원가입 화면, 두 화면이 어떻게 연결되고 전환되는지 눈여겨보면서 만들어봅니다.
그럼 프롬프트로 한번 만들어볼까요?
방금 만든 화면을 보고, 이 화면이 왜 만들어졌는지 거꾸로 추론해보는 단계예요. 로그인이 없다면 사용자에게 어떤 불편이 생길지 생각해보세요.
아래는 예시예요.
| 타깃 | 타깃에게 일어나는 현상 | 타깃이 겪는 문제 |
|---|---|---|
| 서비스를 다시 방문한 기존 사용자 | 매번 처음부터 정보를 입력해야 한다면 내 데이터(찜 목록, 신청 내역 등)를 이어서 확인할 수 없다 | 이전 활동 이력을 잃어버려 서비스 이용을 포기하게 된다 |
그럼 프롬프트로 화면을 보고 문제 정의를 역으로 추론해볼까요?
로그인에 성공하는 흐름과, 비밀번호를 틀리거나 이메일이 중복되는 실패 흐름을 나눠 생각해보는 단계예요.
아래는 예시예요.
| 구분 | 행동 및 처리 | 화면/결과 |
|---|---|---|
| 성공 | 가입된 이메일과 올바른 비밀번호로 로그인한다 | 환영 화면으로 이동한다 |
| 실패 | 비밀번호를 잘못 입력한다 | 비밀번호가 일치하지 않는다는 오류를 보여준다 |
| 실패 | 이미 가입된 이메일로 다시 가입을 시도한다 | 이미 사용 중인 이메일임을 안내한다 |
그럼 프롬프트로 성공·실패 시나리오를 정리해볼까요?
가입·로그인 과정에서 어떤 데이터가 새로 생기고 저장되는지, 탈퇴하면 어떻게 되는지 짚어보는 단계예요.
아래는 예시예요.
| 데이터 | 구분 | 설명 |
|---|---|---|
| 이메일·비밀번호 | 입력 | 가입·로그인 화면에서 사용자가 직접 입력 |
| 회원 계정 | 저장 | 가입 완료 시 회원 테이블에 생성 |
| 로그인 세션 | 추가 | 로그인 성공 시 로그인 상태 정보 생성 |
| 회원 탈퇴 | 삭제 | 탈퇴 요청 시 계정 정보 제거 또는 비활성 처리 |
사용자가 아무 행동도 하기 전에, 이 화면이 정상적으로 뜨려면 시스템에 이미 어떤 데이터가 준비되어 있어야 하는지 생각해보는 단계예요.
아래는 예시예요.
| 데이터 | 설명 |
|---|---|
| 이메일 중복 확인용 계정 목록 | 새 가입 시도가 있을 때마다 대조해야 하는 기준 데이터 |
| 비밀번호 규칙(최소 길이 등) | 가입·로그인 화면에서 검증 기준으로 사용 |
그럼 프롬프트로 데이터까지 한번에 정리해볼까요?
이제 STEP 1~4에서 정리한 문제 정의·시나리오·데이터 설계를 하나로 모아 최종 기획서(PRD)로 완성하는 단계예요.
아래는 예시예요.
| 항목 | 작성 내용 |
|---|---|
| 개요 | 이메일 기반으로 가입하고 로그인하는 인증 화면 |
| 문제 | STEP 1의 문제 정의 |
| 핵심 기능 | 회원가입, 이메일 중복 확인, 로그인, 로그인 오류 안내 |
| 주요 시나리오 | STEP 2의 성공·실패 시나리오 요약 |
| 데이터 설계 | STEP 3·4의 입력·저장·삭제 데이터 및 기본 데이터 요약 |
| 성공 지표 | 가입 완료율, 로그인 성공률 |
그럼 프롬프트로 지금까지 내용을 모두 합쳐 PRD를 완성해볼까요?
직접 만든 결과와 비교해보고 싶다면, 아래에서 완성 예시(모범 답안) PDF를 받아 참고해보세요.
랜딩페이지를 만들어 배포했다고 상상해볼게요. 며칠 뒤 대표님이 묻습니다. "그래서, 잘 되고 있어요?" 이 질문에 "화면은 잘 나왔어요"라고만 답할 수는 없어요. 실제로 3.5.3에서 세웠던 가설과 지표를 다시 꺼내서, 그 가설이 맞았는지 확인해야 진짜 답이 됩니다. 이 장에서는 만든 것을 어떻게 검증하는지 알아봅니다.
기획자의 일은 화면을 출시하는 순간 끝나지 않아요. 오히려 그때부터 진짜 확인이 시작됩니다. 우리가 세운 가설이 맞았는지, 지표는 어떻게 움직였는지를 살펴보는 검증(Validation) 과정이 필요해요.
가장 직관적인 방법은 사용자에게 직접 묻는 거예요. "왜"라는 이유까지 들을 수 있다는 게 가장 큰 장점이지만, 시간이 걸리고 소수의 의견에 치우칠 수 있다는 한계도 있어요.
소수의 사용자와 직접 대화하며 왜 그렇게 행동했는지, 어디서 불편했는지 깊이 있게 들어봐요.
더 많은 사용자에게 짧은 질문을 보내 만족도·재사용 의향 등을 수치로 확인해요.
그럼 프롬프트로 인터뷰 질문지를 만들어볼까요?
업계에서는 흔히 "몇 명에게만 피드백을 받아도 충분하다"는 이야기를 해요. 실제로 닐슨노먼그룹(NN/g)의 제이콥 닐슨은 2000년 발표한 연구에서, 사용성 테스트 참가자 5명만으로도 인터페이스 문제의 약 85%를 발견할 수 있다는 결과를 제시했어요(참가자 1명이 특정 문제를 발견할 평균 확률을 31%로 가정한 계산, Nielsen & Landauer 1993 데이터 기반). 다만 이 수치는 "왜 불편한지"를 깊이 듣는 정성적 사용성 테스트에 한정된 기준이고, 만족도·전환율처럼 숫자로 비교하는 정량 조사에는 적용되지 않는다고 NN/g는 별도로 강조해요. 하지만 제가 실제로 겪어본 바로는, 1명의 피드백에서 시작해서 조금씩 늘려간 경우가 훨씬 많았어요. 현장에는 "처음부터 10명, 20명은 모아야 한다"는 기준 같은 건 없었어요. 그냥 많으면 많을수록 좋고, 없는 게 문제였어요.
그래서 발품을 팔아 여기저기 오픈채팅방에 글을 올리고, 한 명 한 명 피드백을 받아가며 시작했던 적도 많아요. 그런데 요즘은 사람들이 점점 자기 데이터를 잘 안 주려고 해요. 개인정보라고 생각하기 때문이죠. 그래서 앞으로는 제품을 만들기는 점점 쉬워지는 대신, 누가 더 빨리 진짜 사용자 데이터를 모아서 가치를 증명하는지가 더 중요한 경쟁력이 될 거라고 생각해요.
모든 사용자를 인터뷰할 수는 없어요. 이럴 때는 서비스를 운영하면서 쌓이는 행동 데이터를 분석해서 가설을 간접적으로 검증합니다. 이런 데이터는 크게 두 가지 출처로 나눠서 봐요. 하나씩, 아주 쉬운 예시로 살펴볼게요.
광고를 집행하면 얼마나 많이 보여졌고(노출), 그중 몇 명이 눌렀는지(클릭)를 숫자로 알 수 있어요.
아래는 5.1 텀블러 랜딩페이지를 2주간 광고로 운영했다고 가정한 예시예요.
| 지표 | 수치 | 쉽게 말하면 |
|---|---|---|
| 광고 노출수 | 50,000회 | 광고가 화면에 보여진 횟수 |
| 광고 클릭수 | 1,200회 | 그중 실제로 눌러본 횟수 |
| 클릭률(CTR) | 2.4% | 노출 대비 클릭한 비율 (1,200 ÷ 50,000) |
그럼 프롬프트로 비교 기준(벤치마크)부터 찾아볼까요?
광고를 눌러 페이지에 들어온 사람이 실제로 구매까지 이어졌는지는 또 다른 데이터예요.
| 지표 | 수치 | 쉽게 말하면 |
|---|---|---|
| 랜딩페이지 방문자 | 1,200명 | 광고를 눌러 실제로 페이지에 들어온 사람 수 |
| 구매 완료 수 | 18건 | 그중 실제로 구매까지 완료한 수 |
| 구매 전환율 | 1.5% | 방문자 대비 구매한 비율 (18 ÷ 1,200) |
그럼 이번에도 프롬프트로 비교 기준부터 찾아볼까요?
오늘 교안에서 다룬 내용을 다섯 가지 흐름으로 정리해볼게요. 실제 업무에서 막막할 때, 이 순서를 그대로 따라가보세요.
| 단계 | 핵심 내용 | 관련 파트 |
|---|---|---|
| 1. 기획자의 제품 개발 흐름 | AI로 기획 초반부(아이디어~화면 확인)가 어떻게 빨라지는지, 역기획이 무엇인지 이해했어요. | 1장 |
| 2. 기초 용어 개념 확인하기 | 프론트엔드·백엔드·데이터베이스, 와이어프레임·프로토타입, 배포·출시의 차이를 정리했어요. | 2장 |
| 3. 데이터 기반의 지표와 가설 | 문제의 3구성요소, 5 Whys로 근본 원인 찾기, 가설과 지표로 정리하는 방법을 연습했어요. | 3.5 |
| 4. 데이터 기반의 서비스 기획 | AI로 만든 화면을 문제 정의·시나리오·데이터 설계·PRD로 거꾸로 정리하는 역기획을 세 가지 사례로 연습했어요. | 5장 |
| 5. 데이터 기반의 사용자 피드백 및 검증 | 가설이 실제로 맞았는지 인터뷰·설문과 행동 데이터 분석으로 확인하는 방법을 배웠어요. | 6장 |