"AI가 다 만들어주는 시대에 왜 기획을 배워야 할까? — AI의 구조적 한계부터 JTBD·5Whys·HMW·가치 제안까지"
1차시 OT — AI 시대, UX의 중요성과 주요 서비스 기획 방법
AI 기반 UX/UI 기획부터 Figma 개발 연계까지 다루는 6일 과정의 첫 번째 수업.
오늘의 한 문장: "AI는 성능의 문제가 아니라 구조의 문제다."
1. 전체 과정 구성: 기획에서 개발 연계까지
실습 워크플로우 (총 6단계)
[기획: 문제 정의 및 리서치] [AI 자동생성] [정교화 → 개발연계]
STEP 01 STEP 02 STEP 03 STEP 04 STEP 05 STEP 06
UX의 중요성과 → AI 리서치· → UI/GUI → 수정·고도화 → 화면 요구사항 → Dev Mode
서비스 기획 아이데이션 자동 생성 Userflow 정의 & MCP- 화면 기획·정의(1~2) → AI 자동 생성(3~4) → 정교화·시스템화(5) → 개발 연계(6)
Module 1의 학습 목표
| # | 목표 | 내용 |
|---|---|---|
| 1 | AI의 한계를 구조로 설명 | 왜 생성형 AI가 실제 사용자를 알 수 없는지, 작동 원리에서 출발해 3가지 이상의 이유로 말할 수 있다 |
| 2 | UX 자동화 경계 | 합성 페르소나가 왜 위험한지, 그럼에도 어디까지는 쓸 수 있는지 구분한다 |
| 3 | AI 협업 및 역할 분업화 | 발산·수렴 × 일반론·현실 접점의 2축 프레임으로 '어디에 AI를 쓸지' 판단한다 |
| 4 | 핵심 질문 도출 | 문제 정의(JTBD·5 Whys) → 리서치 → HMW → 가치 제안까지 각 단계의 핵심 질문을 안다 |
Part 1. AI 시대 기획의 목적과 필요성
Chapter 2. 문제 제기와 LIVE 시연
"AI가 자동으로 만들어주는 시대에 왜 기획을 배워야 할까요?"
[시연 1] 프롬프트를 통한 앱 화면 생성
- 도구: ChatGPT (https://chatgpt.com/ko-KR/)
- 프롬프트:
"취준생용 면접 준비 앱 화면 만들어줘." - 모델: 즉시 5.5 (26.07.10 기준)
- 결과: 한 줄 프롬프트만으로 홈 화면(목표 진행률, 추천 메뉴, 오늘의 추천 공고, 하단 탭바 등)이 그럴듯하게 완성됨.
[시연 결과에 대한 평가하기]
- 방금 생성된 UI 디자인을 어떻게 생각하나요?
- 실제로 사용할 것 같나요?
자동화된 영역 vs 자동화되지 않은 영역
| 🤖 자동화 된 것 — AI 작업 영역 | 🙋 자동화되지 않은 것 — 사람 작업 영역 |
|---|---|
| 화면을 그리는 일 | 무엇을 만들지 정하는 일 |
| 코드를 작성하는 일 | 만든 것이 옳은지 판단하는 일 |
| 디자인 초안을 만드는 일 | 실제 사용자의 현실을 아는 일 |
개발 관점에서 비유: 잘못된 요구사항 기반의 코드는 빠르게 완성된 실패작이다.
Chapter 3. AI의 구조적 한계
1) LLM의 작동 원리: 확률 기반으로 다음 토큰값 예측
입력(프롬프트) → 확률계산 → 출력
"취준생의 니즈는?" 학습 데이터 전체에서 평균적으로 무난한 답
통계적으로 가장 '그럴듯한' 답으로 구성- 핵심 문제: 일반론(학습데이터에 다수 존재하는 내용)에는 강하나, 특정 사용자·맥락의 개별 정보는 데이터 부재로 파악 불가.
2) 네 가지 구조적 한계
[한계 1] 평균화 — 통계적 중심으로의 수렴과 니즈의 소실
AI의 답이 너무 일반적이라면, 숨은 사용자 문제를 놓치고 있을 수 있음
- AI의 구조적 특징: 평균적인 데이터 위주로 결론을 내는 한계로 인해, 소수 사용자의 페인포인트와 특이 사용 방식이 응답에 포함되지 않음.
- '인터뷰 핏' 기획 시: 질문을 하면 보편적 답변(예: 예상 질문, 모의 면접)만 도출됨. '비전공 개발자라 기술 질문이 어렵다', '최종 면접에서만 계속 떨어진다', '시간이 하루 남았다' 등 개별적이고 구체적인 질문 시 문제가 발생.
[한계 2] 환각(Hallucination) — 사실이 아닌 정보 제공
그럴듯한 답변도 사실과 다를 수 있으므로, 결과에 대한 검증이 필요함
- AI의 구조적 특징: 데이터 공백 발생 시, 통계적으로 그럴듯한 거짓 문장으로 답변을 대체함.
- '인터뷰 핏' 기획 시: 취준생의 취업준비 평균 기간을 물으면 존재하지 않는 통계 수치, 실존하지 않는 기업, 가짜 출처 표기 등이 나타남.
[한계 3] 맥락 부재 — 사용자 환경·감정·상황 정보의 결여
AI는 사용 상황에 대한 맥락을 알지 못함
- AI의 구조적 특징: 텍스트 데이터에 담기지 않는 사용자의 물리적·감정적·사회적 맥락을 직접 경험하거나 해석할 수 없음.
- '인터뷰 핏' 기획 시: 예를 들어 면접 30분 전, 불안해하며 앱을 여는 사용자 — 면접 현장에서 긴장한 채 빠르게 정보를 확인하고 싶은 상황을 AI는 이해하지 못해 사용성이 떨어질 수 있음.
[한계 4] 최신성과 편향 — 학습 시점 이후 변화와 로컬 맥락의 누락
실시간 정보와 로컬(예: 한국 채용 시장) 정보는 웹 검색과 확인이 필요함
- AI의 구조적 특징: 학습 시점 이후의 실시간 변화를 반영하지 못하며, 영어권 데이터와 다수 데이터 편향으로 인해 한국 고유 맥락이 반영되지 않음.
- '인터뷰 핏' 기획 시: 국내 채용 프로세스의 최근 변화, 이번 분기 한국 기업 채용 정보 등을 물으면 잘못된 답변 또는 회피성 답변이 발생.
3) [시연 2] SSAFY 교육생에 대한 AI 응답 검증
- 프롬프트:
"SSAFY 교육생의 하루 일과와 가장 큰 페인포인트를 알려줘" - 방법: AI 생성 결과와 실제 경험을 대조하기
- 일치하는 항목 (일반론 구간): 누구에게나 해당되는 내용일 가능성
- 불일치하는 항목 (개별 사실 구간): 당사자만 파악 가능한 디테일일 가능성
"AI는 성능의 문제가 아니라 구조의 문제"
모델 성능이 향상되어도 '사용자를 실제로 모른다'는 사실은 변하지 않음.
따라서 사용자의 니즈, 가치를 파악하는 일(UX 리서치와 기획)은 사람의 영역임.
Chapter 4. 자동 UX의 함정
1) AI가 UX 리서치를 대체하려는 시도
AI 기반 리서치 도구가 늘어나면서, 사용자를 직접 만나지 않고도 리서치를 할 수 있다는 기대가 커지고 있음.
| 대표 시도 01 | 대표 시도 02 | 대표 시도 03 |
|---|---|---|
| 합성 사용자 AI가 가상의 사용자 역할을 수행하도록 하는 방식 | AI 인터뷰 시뮬레이션 페르소나를 부여한 AI와 모의 인터뷰를 진행하는 방식 | 자동 사용성 평가 AI가 화면을 분석해 사용성 문제를 예측하는 방식 |
위 흐름 자체는 유용하지만, 문제는 이것을 '리서치 보조'가 아니라 '사용자 대체제'로 사용할 때 발생함.
2) [함정 1] 그럴듯하지만 근거가 없음
AI가 만든 페르소나와 인터뷰 답변은 자연스러워 보이지만, 실제 사용자를 대표하지 못함.
- AI 페르소나 답변 예시: "이 기능은 바쁜 취준생에게 큰 도움이 될 것 같아요."
- → 위 문장은 그럴듯하지만, 다음을 알 수 없음
- 실제 사용자가 그런 말을 했는지
- 얼마나 많은 사용자가 같은 문제를 겪는지
- 실제 행동으로 이어지는 니즈인지
- 돈이나 시간을 쓸 만큼 중요한 문제인지
3) [함정 2] 내가 원하는 답을 더 잘 만들어줌
AI는 질문자가 원하는 방향을 빠르게 읽고, 그 방향에 맞는 답을 만들어내는 경향이 있음.
- ❌ Don't 질문: "이 기능을 좋아할 사용자를 설명해줘."
- ✅ DO 질문: "이 기능이 필요 없거나 불편할 수 있는 사용자를 설명해줘."
4) [함정 3] 핵심 인사이트를 발견하기 어려움
사용자 인터뷰의 가치는 예상하지 못한 말, 이상한 행동, 모순된 반응에서 나옴. 하지만 AI는 이미 학습된 패턴 안에서 가장 그럴듯한 답을 만듦.
- 실제 사용자 인터뷰에서 나오는 답변 예시: "좋긴 한데, 저는 이런 앱 켜는 것도 부담스러워요."
- → 위 같은 답변은 기획 방향까지 바꿀 수 있음. AI는 평균적인 답은 잘 만들지만, 실제 사용자들은 평균대로 행동하지 않음.
5) 합성 페르소나 vs 실데이터 페르소나 비교
판단 기준: 이 페르소나를 근거로 특정 기능을 빼도 되는가? 답이 "아니오"라면 아직 검증된 페르소나가 아님.
| 🟦 합성 페르소나 — 김취준 27세 | 🟩 실데이터 페르소나 — 박현서 (26세, 비전공 6개월차) | |
|---|---|---|
| 바이오 | "열정적이고 성장을 추구하는 취준생" | "CS 질문 받으면 아는 것도 백지가 돼요" |
| 목표 | 좋은 회사에 취업하기 | 밤 10시 귀가 후 30분간 면접 연습 |
| 페인포인트 | 면접이 어렵다, 정보가 부족하다 | 모의 면접은 부끄러워하고, 스터디도 참여하지 못함 |
| 특징 | · 빠르게 만들 수 있음 · 초기 아이디어 발산에 유용함 · 하지만 실제 근거가 부족함 · 화면 제외, 기능 우선순위 결정의 근거로 쓰기 어려움 | · 인터뷰, 관찰, 설문, 로그 기반 · 말과 행동의 근거가 있음 · 기능 결정, 화면 제외, 우선순위 판단에 활용 가능 |
6) 합성 페르소나는 어디까지 쓸 수 있는가
합성 페르소나는 다음 단계에서 유용함:
- 리서치 전 가설 만들기: 어떤 사용자가 있을지 넓게 상상
- 인터뷰 질문 점검: 질문이 유도적이지 않은지 사전 확인
- 엣지 케이스(Edge case) 탐색: 놓치기 쉬운 사용자 상황 점검
- 실습용 시나리오 제작: 교육, 워크숍, 초기 기획 연습에 활용
실무 적용 기준
AI는 리서치를 시작하게 해주는 도구이며, 리서치를 끝내주는 도구가 아님.
검증은 사용자가 직접 해야 함.
Part 2. 실전 기획 프로세스
Chapter 1. AI 활용 역할 분담 프레임워크
1) 디지털 프로덕트 제작의 7단계 파이프라인
[ 기획의 영역 ] [ 제작의 영역 ]
1단계 → 2단계 → 3단계 → 4단계 → 5단계 → 6단계 → 7단계
문제정의 리서치 인사이트 컨셉 UI 설계 디자인 개발- 각 단계에서 AI가 할 수 있는 일과 사람이 반드시 판단해야 하는 일을 구분할 수 있는가?
- 초기 기획 오류는 뒤 단계에 영향이 미치기 때문에, AI 활용보다 먼저 역할 분담 기준이 필요함.
2) 단계별 역할 정의
기획 영역
| 단계 | 내용 | 역할 |
|---|---|---|
| 1단계. 문제 정의 | 무엇을 만들지보다, 누구의 어떤 문제를 해결할지 결정하는 단계 | 🟢 사람 필수 |
| 2단계. 리서치 | 사용자·시장·경쟁 환경을 조사하고 가설을 검증하는 단계 | 🔵 AI 보조 + 사람 검증 |
| 3단계. 인사이트 | 조사 결과에서 반복되는 문제와 기회를 도출하는 단계 | 🔵 AI 보조 + 사람 판단 |
| 4단계. 컨셉 | 서비스 가치, 핵심 기능, MVP 범위를 결정하는 단계 | 🟢 사람 필수 |
제작 영역
| 단계 | 내용 | 역할 |
|---|---|---|
| 5단계. UI 설계 | 화면 목록, 사용자 흐름, 와이어프레임을 구성하는 단계 | 🔵 AI 보조 + 사람 검증 |
| 6단계. 디자인 | GUI 시안, 디자인 시스템, 컴포넌트 구조를 만드는 단계 | 🟣 AI 초안 생성 가능 |
| 7단계. 개발 | 코드 구현, 배포, 디자인-개발 연계를 진행하는 단계 | 🔵 AI 보조 + 사람 검증 |
3) AI 활용 판단 프레임: 2개의 축, 2개의 질문
판단 축 구분
- 판단 축 1. 작업 성격 (발산 ↔ 수렴)
- 발산: 아이디어, 대안, 예시, 초안을 많이 만드는 작업
- 수렴: 선택, 삭제, 우선순위, 최종 결정을 내리는 작업
- 판단 축 2. 근거 수준 (일반론 ↔ 현실 접점)
- 일반론: 공개 정보, 일반 패턴, 기존 사례로 답할 수 있는가?
- 현실 접점: 실제 사용자, 실제 데이터, 내부 제약, 조직 판단이 필요한가?
핵심 질문
- Q1. 이 작업은 발산인가, 수렴인가?
- Q2. 일반 지식으로 충분한가, 실제 사용자·실데이터가 필요한가?
2×2 프레임
| 발산 | 수렴 | |
|---|---|---|
| 일반론 | 발산 × 일반론 아이디어 초안, 대안 생성, 일반 지식 요약 → 🟦 AI 위임 | 수렴 × 일반론 요약·정리·구조화의 최종 채택 판단 → 🔵 AI 보조 + 사람 검증 |
| 현실 접점 | 발산 × 현실 접점 사용자 가설 브레인스토밍 (단, 검증 전제) → 🔵 AI 보조 + 사람 검증 | 수렴 × 현실 접점 무엇을 만들지 결정, 실사용자 검증, 우선순위 → 🟢 사람 필수 |
적용 예시: 취준생 면접 준비 서비스 '인터뷰핏'
- 적용 순서
- 1단계: 질문을 통한 사분면 결정 (Q1 → Q2)
- 2단계: 정해진 사분면을 기준으로 정리 → 해당 사분면의 신뢰 수준(위임 / 보조+검증 / 사람 필수)에 따라 진행
| 발산 | 수렴 | |
|---|---|---|
| 일반론 | 면접 준비 앱 아이디어 25개 생성, 경쟁 서비스 기능 목록 초안 → AI 위임 | 인터뷰 요약 정리, 유사 의견 묶기, 표현 다듬기 → AI 보조 × 사람 검증 |
| 현실 접점 | 취준생 페르소나 가설 생성, 예상 페인포인트 정리 → AI 보조 + 사용자 검증 필요 | MVP 기능 선택, 기능 제외, 우선순위 결정 → 사람 필수 |
4) 파이프라인 적용: 3가지 역할 구분
1단계 2단계 3단계 4단계 5단계 6단계 7단계
문제정의 리서치 인사이트 컨셉 UI 설계 디자인 개발
사람 필수 AI보조+검증 AI보조+검증 사람 필수 AI보조+검증 AI초안생성 AI보조+검증- 🟢 사람 필수 — 문제 정의, 컨셉 결정 → 무엇을 만들지 결정하는 구간
- 🔵 AI 보조 + 사람 검증 — 리서치, 인사이트, UI 설계, 개발 → AI가 초안을 만들고 사람이 근거와 결과를 확인하는 구간
- 🟣 AI 초안 생성 가능 — 디자인 → 화면 형태와 시각 초안을 빠르게 만드는 구간
5) 핵심 질문의 전환
"AI를 쓸 수 있는가?"가 아니라,
"이 결과를 어느 수준까지 믿고 의사결정에 사용할 수 있는가?"를 물어야 함
Chapter 2. 고객 중심 서비스 기획 방법론
1) 더블 다이아몬드 프로세스
정의
- 영국 Design Council이 제시한 디자인·혁신 프로세스 모델.
- 문제를 넓게 탐색한 뒤 핵심 문제를 좁히고, 다시 다양한 해결책을 탐색한 뒤 실행할 해결책을 결정하는 구조.
네 단계의 의미
문제 발견과 정의
1. 발견 Discover: 사용자에게 실제로 어떤 문제가 있는가?
2. 정의 Define: 지금 가장 먼저 해결해야 할 문제는 무엇인가?
해결책 개발 및 구현
3. 개발 Develop: 이 문제를 해결할 수 있는 방법은 무엇인가?
4. 전달 Deliver: 어떤 해결책을 구현하고 검증할 것인가?
대표적인 실패 방식
문제 탐색과 정의를 건너뛰고 곧바로 해결책을 만들면 다음과 같은 결과가 발생함.
발생 문제 예시
사용자는 말하기 연습이 필요한데,
기획자는 예상 질문 목록을 많이 제공하는 앱부터 제작
- → 화면과 기능은 완성되었지만, 사용자가 실제로 겪는 문제는 해결하지 못하는 상황이 발생함
- → 즉, 첫 번째 다이아몬드(문제 발견과 정의)가 틀리면, 두 번째 다이아몬드(해결책 개발 및 구현)를 잘 수행해도 의미가 없음
2) JTBD 관점의 문제 정의
JTBD (Jobs to Be Done Theory)
- 정의: JTBD는 사용자가 제품의 기능 자체가 아니라, 특정 상황에서 원하는 결과를 얻기 위해 제품이나 서비스를 선택한다는 관점. 기능적 요구뿐 아니라 감정적·사회적 동기도 함께 살펴봐야 함.
- JTBD를 구성하는 세 요소
- 상황: 언제, 어떤 맥락에서 문제가 발생하는가?
- 동기: 사용자는 무엇을 하고 싶어 하는가?
- 기대 결과: 그것을 통해 어떤 상태가 되기를 원하는가?
JTBD 문장 템플릿
"(상황)일 때, (동기)하고 싶다. 그래야 (기대 결과)할 수 있으니까."'인터뷰핏' 적용 예시
"(상황) 서류 합격 통보를 받고 면접까지 일주일 남았을 때,
내 수준에 맞는 (동기) 예상 질문으로 말하기 연습을 하고 싶다.
그래야 면접장에서 (기대 결과) 머릿속이 하얘지지 않고 핵심 답변을 할 수 있으니까."
3) 5Whys
정의
- 문제나 현상의 원인을 파악하기 위해 "왜?"를 반복하며 표면적 증상에서 근본 원인으로 내려가는 분석 방법.
- 도요타 생산방식과 품질 개선 분야를 통해 널리 알려졌으며, 반드시 정확히 다섯 번 질문해야 한다는 의미보다는 원인이 명확해질 때까지 단계적으로 파고드는 방식.
'인터뷰핏' 적용 예시
| 단계 | 발화 |
|---|---|
| 표면적인 요구 사항 | "면접 예상 질문 리스트가 필요해요" |
| ↓ 왜? | "뭘 물어볼지 몰라서 불안하니까요" |
| ↓ 왜 불안한가? | "아는 것도 실전에서는 말로 안 나와서요" |
| ↓ 왜 말로 안 나오나? | "말로 답해 본 연습이 거의 없어서요" |
| ➡ 근본 니즈 | "불확실성을 통제하고 싶다, 연습으로 실전을 예측 가능하게 만들고 싶다" |
사용할 때 주의할 점
- 5Whys는 사용자를 추궁하는 인터뷰 기법이 아님.
- "왜 안 하셨어요?"를 반복하기보다는 다음과 같이 맥락과 행동을 확인해야 함.
- "그때 어떤 상황이었나요?"
- "그다음에는 어떻게 하셨나요?"
- "그렇게 행동한 이유를 조금 더 설명해주시겠어요?"
- "비슷한 일이 또 있었나요?"
4) 문제 정의문 작성
역할
- 문제 정의문은 발견한 내용을 한 문장으로 압축하여, 팀이 해결해야 할 문제와 탐색 범위를 공유하는 문장.
- 해결책을 만들기 전에 사용자와 니즈를 명확히 하는 기준으로 사용함.
템플릿
"(누가), (어떤 상황에서), (무엇 때문에) 어려움을 겪는다."'인터뷰핏' 적용 예시
"(누가) 비전공 출신 개발 취준생이, (어떤 상황에서) 면접을 앞두고 시간이 부족한 상황에서,
(무엇 때문에) 말로 답하는 연습을 할 상대가 없어 어려움을 겪는다."
좋은 문제 정의문의 조건
- 사용자 명시: 누가 문제를 겪는지 구체적으로 표현
- 상황 명시: 문제가 언제 발생하는지 설명
- 원인 또는 장애물 명시: 사용자가 목표를 달성하지 못하는 이유 표현
- 해결책 제외: AI 챗봇, 음성 분석, 예상 질문 기능과 같은 구체적 해결책을 미리 포함하지 않음
- 근거 수준 표시: 아직 사용자 조사를 하지 않았다면 [가설], 조사로 확인했다면 [검증]으로 구분
➡ 사용자 니즈는 기술이나 기능이 아니라 사용자가 해결하려는 문제와 결과를 중심으로 작성해야 함
5) 리서치의 두 가지 유형
데스크 리서치와 사용자 리서치의 관계
- 서로 대체하는 방법이 아니라 순서와 목적이 다른 방법임.
- 데스크 리서치로 가설 수립 → 사용자 리서치로 현실 검증
- 사용자 리서치는 사용자가 누구인지, 어떤 경험과 니즈를 가지고 있는지 이해하는 데 사용되며, 실제 서비스 기획에서는 연구 목적에 따라 인터뷰, 관찰, 사용성 테스트, 설문 등 여러 방법을 조합함.
비교표
| 구분 | 데스크 리서치 | 사용자 리서치 |
|---|---|---|
| 대상 | 문헌, 기사, 통계, 기존 연구, 경쟁 서비스, 리뷰 | 실제 사용자와 사용 상황 |
| 목적 | 시장과 문제에 대한 사전 이해 | 사용자 행동과 니즈 검증 |
| 발견 대상 | 이미 기록된 정보 | 아직 기록되지 않은 현실 |
| 주요 방법 | 자료 조사, 경쟁 분석, 리뷰 분석 | 인터뷰, 관찰, 사용성 테스트 |
| 대표 산출물 | 시장 동향, 경쟁 기능, 사용자 가설 | 실제 행동, 페인포인트, 니즈 |
| AI 역할 | 자료 수집·요약·비교·구조화 | 질문 초안·전사·정리 보조 |
| 주의점 | 자료의 출처와 최신성 확인 | 참여자 적합성과 해석 편향 관리 |
6) 소수 인터뷰의 효과
적은 인원으로 반복 패턴 발견하기
- 초기 정성 리서치의 목적은 전체 사용자의 비율을 통계적으로 추정하는 것이 아니라, 사용자의 행동과 문제를 깊이 이해하고 반복되는 패턴을 찾는 것.
- 초기 리서치에서는 많은 사람의 얕은 의견보다, 적합한 사용자의 구체적인 경험이 중요함.
참여자 수에 따른 구분
| 참여자 수 | 기대할 수 있는 인사이트 |
|---|---|
| 1~2명 | 개별 경험과 예상하지 못한 문제의 최초 발견 |
| 3~5명 | 동일한 문제·행동·요구의 반복 출현, 핵심 가설과 우선 검증 대상의 구체화 |
| 5명 이후 | 새로운 발견은 점차 줄고, 기존 패턴의 반복과 세부 맥락의 보완 증가 |
📎 참고 자료: Why You Only Need to Test with 5 Users (NN/g) — "왜 5명으로도 충분한가?"에 대한 논문
소수 인터뷰의 실무적 의미
- 대규모 설문 이전에도 리서치 착수 가능
- 취준생이나 소규모 팀 프로젝트에서도 실행 가능
- 첫 라운드에서 핵심 문제와 가설을 정리
- 다음 라운드에서 반례와 다른 사용자 유형 확인
- 새로운 발견이 계속 나오면 참여자를 추가
- 발견이 반복되기 시작하면 다음 설계 단계로 전환
7) 인터뷰 질문 설계의 3원칙
[원칙 1] 미래의 의향보다 과거 행동을 묻기
- 사람은 미래에 자신이 어떻게 행동할지 정확하게 예측하기 어려움.
- 인터뷰에서는 실제로 있었던 최근 경험과 행동을 물어야 구체적인 데이터를 얻을 수 있음.
| 질문 | |
|---|---|
| ❌ Don't | "이런 앱이 나오면 사용하시겠어요?" |
| ✅ Do | "지난 면접을 준비할 때 실제로 무엇을 하셨나요?" |
[원칙 2] 답을 정해놓고 유도하지 않기
- 유도 질문은 연구자가 기대하는 답을 참여자에게 암시함.
- 열린 질문을 사용해야 사용자가 자신의 경험을 설명할 수 있음.
| 질문 | |
|---|---|
| ❌ Don't | "연습할 곳이 없어서 힘드셨죠?" |
| ✅ Do | "면접 준비 과정에서 가장 어려웠던 점은 무엇이었나요?" |
[원칙 3] '왜?'로 추궁하기보다 '어떻게?'로 재구성하기
- '왜 안 하셨어요?'는 사용자를 방어적으로 만들 수 있음.
- 행동의 순서와 맥락을 재구성할 수 있도록 구체적인 후속 질문을 사용함.
| 질문 | |
|---|---|
| ❌ Don't | "왜 연습하지 않으셨어요?" |
| ✅ Do | "그때 어떻게 준비하셨나요?" / "그다음에는 무엇을 하셨나요?" / "그 과정에서 가장 어려웠던 순간은 언제였나요?" |
8) 인터뷰 워크플로우의 역할 분담
이 구분은 특정 표준의 공식 분류가 아니라, 본 과정에서 AI를 안전하게 활용하기 위한 실무 운영 기준임.
| 단계 | 주요 업무 | 역할 | 세부 내용 |
|---|---|---|---|
| 1단계. 질문지 초안 | 3원칙 기반 질문 초안 생성·점검 | 🔵 AI 보조 | · 연구 목적을 기준으로 질문 후보 생성 · 미래 의향 질문을 과거 행동 질문으로 수정 · 유도 질문 여부 점검 · 질문 순서와 표현 정리 |
| 2단계. 인터뷰 진행 | 경청, 후속 질문, 비언어 반응 확인 | 🟢 사람 필수 | — |
| 3단계. 스크립트 요약 | 전사, 발언 정리, 키워드·패턴 후보 추출 | 🔵 AI 보조 | · 녹취 내용 구조화 · 반복 키워드와 행동 패턴 후보 추출 · 사용자별 공통점과 차이점 비교 · 발언 인용문 후보 정리 |
| 4단계. 해석과 판단 | 중요도 결정, 반례 검토, 문제 채택 | 🟢 사람 필수 | · 단순 반복과 중요한 패턴 구분 · 의견과 실제 행동의 차이 판단 · 어떤 문제를 해결 대상으로 채택할지 결정 · 제품 범위와 우선순위에 미칠 영향 판단 |
9) HMW를 통한 기회 정의
HMW (How Might We)
- HMW는 문제나 페인포인트를 "어떻게 하면 우리가 …할 수 있을까?"라는 기회 탐색형 질문으로 바꾸는 방법.
- 해결책을 하나로 고정하지 않으면서도 팀이 해결해야 할 문제에 집중하게 함.
HMW 작성 템플릿
"어떻게 하면 우리가 …할 수 있을까?"작성 기준 — 좋은 HMW는 다음 조건을 충족해야 함
- 사용자와 문제의 방향이 드러남
- 여러 해결책을 상상할 수 있음
- 특정 기술이나 기능을 미리 고정하지 않음
- 너무 광범위하거나 지나치게 세부적이지 않음
범위 비교
| 구분 | 예시 | 이유 |
|---|---|---|
| ❌ Don't (너무 넓음) | "어떻게 하면 취준생의 삶을 개선할 수 있을까?" | 문제 범위가 지나치게 큼 / 무엇부터 탐색해야 할지 불명확 / 아이디어 평가 기준을 만들기 어려움 |
| ✅ Do (적절함) | "어떻게 하면 혼자서도 부끄럽지 않게 말하기 연습을 하게 할 수 있을까?" | 사용자 행동과 장벽이 명확함 / 여러 해결책을 상상할 수 있음 / 기능을 미리 결정하지 않음 |
| ❌ Don't (너무 좁은 질문) | "어떻게 하면 AI 챗봇 모의면접 기능을 만들 수 있을까?" | AI 챗봇이라는 해결책이 이미 결정됨 / 다른 해결 방법을 탐색하기 어려움 / 질문이 아니라 구현 결론에 가까움 |
10) 가치 제안 문장: 화면 설계 판단의 기준
- 가치 제안(Value Proposition): 타깃 고객에게 제공할 핵심 가치와 차별점을 한 문장으로 규정한 선언문.
- 판단 기준으로서의 역할: UI 단계의 모든 화면은 '가치 제안 기여 여부'로 평가됨.
가치 제안 문장 템플릿
"(1) 타깃 고객이 (2) 문제/니즈를 겪을 때, 우리 서비스는 (3) 핵심 가치를 제공한다.
(4) 기존 대안과 달리 (5) 차별점이 있기 때문이다."| 구성 요소 | 출처 |
|---|---|
| (1) 타깃 고객 | 페르소나에서 |
| (2) 문제 / 니즈 | 문제 정의문에서 |
| (3) 핵심 가치 | HMW의 방향에서 |
| (4) 기존 대안 | 경쟁 리서치에서 |
| (5) 차별점 | 포지셔닝 갭에서 |
Chapter 3. 실습 및 모듈 1 정리
[시연 1] 가치 제안 문장 작성
1단계 — 발산 (AI)
- 도구: ChatGPT / 모델: 즉시 5.5
- AI 활용 판단 프레임: 발산 = AI
- 프롬프트: 오늘 만든 내용(JTBD - 문제 정의문 - HMW)을 입력하여 가치 제안 문장 초안 생성
다음 정보를 바탕으로 서비스의 가치 제안(Value Proposition) 문장을 작성해줘.
[JTBD]
"서류 합격 통보를 받고 면접까지 일주일 남았을 때, 내 수준에 맞는 예상 질문으로 연습하고 싶다.
그래야 면접장에서 머릿속이 하얘지지 않을 수 있으니까."
[문제 정의문]
비전공 출신 개발 취준생이, 면접을 앞두고 시간이 부족한 상황에서, 말로 답하는 연습을 할 안전한
상대와 방법이 없어 어려움을 겪는다.
[HMW]
"어떻게 하면 혼자서도 부끄럽지 않게 말하기 연습을 하게 할 수 있을까?"
아래 형식의 가치 제안 문장을 참고하여 작성해줘.
"( 타깃 고객 )이 ( 문제/니즈 )를 겪을 때, ( 우리 서비스 )는 ( 핵심 가치 )를 제공한다.
( 기존 대안 )과 달리 ( 차별점 )이 있기 때문이다."
위 형식을 그대로 복사하지 말고, 입력 내용에 맞게 자연스럽게 다듬어서 3가지 버전으로 제안해줘.- 결과: 버전 1. 문제 해결 중심 / 버전 2. 자신감 중심 / 버전 3. 맞춤형 학습 중심 — 초안 3개
- 시연에서 볼 포인트: 초안 3개의 무난한 답변 내용 → 선택할 초안 검토
2단계 — 수렴 (사람)
- 차별점을 만들어 가치제안 문장 수정하기
- 시연에서 볼 포인트: 초안을 고르고 고쳐서 뾰족한 차별점 만들기 → 발산·수렴 프레임의 실제 작동
최종 수정 문장 예시
[타깃 고객] 비전공 출신 개발 취준생이 [문제/니즈] 면접을 앞두고 제한된 시간 안에 핵심 답변을 빠르게 준비해야 할 때,
우리 서비스는 [핵심 가치] 부족한 답변 영역을 진단하고 우선순위가 높은 질문부터 집중적으로 연습할 수 있는 맞춤형 면접 훈련을 제공한다.
[기존 대안] 모든 예상 질문을 동일하게 반복하는 기존 방식과 달리, [차별점] 남은 준비 시간과 개인의 취약 영역을 기준으로 최적의 연습 순서를 제안하기 때문이다.
모듈 1 최종 산출물, 가치제안
- 완성된 가치 제안은 모듈 2 페르소나·여정맵의 입력 컨텍스트로 활용
HMW 작성 템플릿 (실습용)
HMW 문장 구성
"어떻게 하면 ~할 수 있을까?"
기획하고자 하는 서비스에 대한 HMW 문장 작성
"(어떻게: )하면,
(무엇을: )할 수 있을까?"2. 핵심 정리
- AI의 구조적 한계: 사용자 맥락(Context) 인지 결여
- 평균화·환각·맥락 부재·최신성 → 성능이 아니라 구조의 문제
- 역할 분담 원칙: AI의 발산, 사람의 판단(수렴)
- 2축 프레임: 발산·수렴 × 일반론·현실 접점
- 문제 정의의 선행: JTBD · 5Whys · HMW
- JTBD → 5Whys → 문제 정의문 → HMW
- 가치 제안 문장: 화면 설계의 판단 기준
- UI 단계의 판단 기준. 모듈 2에서 잔여 항목(기존 대안·차별점) 보완
3. 남은 질문 / 더 알아볼 것
MVP와 MDP의 차이점?
| 구분 | MVP (Minimum Viable Product) | MDP (Minimum Delightful/Desirable Product) |
|---|---|---|
| 목적 | 가설 검증 — 이 문제가 실제로 존재하고, 우리 해결책이 통하는가? | 사용자 만족 — 사용자가 계속 쓰고 싶어 하는가? |
| 기준 | 작동하는 최소 기능 (Viable = 생존 가능) | 최소한의 '좋은 경험'까지 포함 (Delightful = 만족스러운) |
| 초점 | 학습(Learning)과 검증 | 완성도, 경험 품질, 리텐션 |
| 리스크 | 경험이 조악해 사용자가 이탈 → 가설이 틀린 건지 UX가 나쁜 건지 구분 불가 | 범위가 커져 출시가 늦어짐 |
정리: MVP는 "이게 필요한가?"를 검증하고, MDP는 "이걸 계속 쓸 만한가?"를 검증한다.
강의의 4단계(컨셉)에서 MVP 범위를 결정하는 것은 사람 필수 구간이라는 점과 연결됨.
실습 링크
- Figma 링크: buly.kr/FLafGW4
회고
- 가장 인상 깊었던 문장: "잘못된 요구사항 기반의 코드는 빠르게 완성된 실패작", 그리고 "AI는 리서치를 시작하게 해주는 도구이지, 끝내주는 도구가 아니다."
- AI를 쓸지 말지를 고민하는 대신, 발산/수렴 × 일반론/현실 접점 2축에 작업을 얹어보는 습관을 들이자.
- 다음 시간(2일차)에는 AI 기반 UX/UI 기획, 리서치, 아이데이션 — 오늘 만든 가치 제안 문장이 페르소나·여정맵의 입력값이 된다.
뭘봐