docs: stage-1 i18n coverage + news
This commit is contained in:
sanbuphy
@@ -0,0 +1,82 @@
|
||||
# 프로젝트 소개
|
||||
|
||||
2025년은 많은 사람들에게 AI 프로그래밍의 원년으로 불리고 있습니다. 점점 더 많은 사람들이 AI로 코드를 작성하기 시작했지만, 여전히 장난감 수준에 머물러 있는 경우가 많습니다. Vibe Coding으로 개발 프로세스를 어떻게 구성해야 할지, 어떤 도구를 선택해야 할지, 그리고 프로토타입에서 서비스 출시까지 어떤 핵심 단계가 필요한지 모르는 경우가 많습니다.
|
||||
|
||||
우리는 단계적인 **3단계 실전 학습 경로**를 채택했습니다. 초보자 입문 단계에서는 소규모 게임을 통해 AI 프로그래밍에 빠르게 익숙해지고, 1단계에서는 Vibe Coding 작업 방식을 마스터하여 웹 애플리케이션 프로토타입을 완성합니다. 2단계에서는 풀스택 개발과 배포를 학습하고, 3단계에서는 크로스 플랫폼 복잡 애플리케이션을 구축합니다.
|
||||
|
||||
각 단계에는 완전한 프로젝트 실전이 포함되어 있어, 실제 도전을 통해 장난감에서 제품으로 나아가며, 최종적으로 **어떤 아이디어든 사용 가능한 애플리케이션으로 구현하는 능력**을 갖추게 됩니다.
|
||||
|
||||
우리는 Vibe Coding을 마스터하고 체계적인 훈련과 결합하면, 한 사람이 **프론트엔드/백엔드 개발, AI 역량 통합, 제품 설계를 모두 갖춘 올라운드 개발자**가 될 수 있다고 믿습니다.
|
||||
|
||||
본 프로젝트는 주로 세 가지 유형의 학습자를 대상으로 합니다:
|
||||
|
||||
- **초보자 (일반인 / 제품 및 운영 직무)**: 비기술적 배경을 가진 분들과 입문 학습자가 핵심 개념을 이해하고 첫 번째 AI 소규모 도구나 제품 프로토타입을 완성할 수 있도록 돕습니다.
|
||||
- **초중급 개발자 (기초 지식이 있는 학생 및 개발자)**: vibe coding과 네이티브 AI 애플리케이션 개발을 체계적으로 마스터합니다.
|
||||
- **고급 개발자 (기업 및 스타트업, 오픈소스 및 인디 개발자)**: 팀과 개인이 네이티브 AI 애플리케이션을 빠르게 구축, 검증 및 반복할 수 있도록 지원합니다.
|
||||
|
||||
## 📖 콘텐츠 내비게이션
|
||||
|
||||
### 총 부록
|
||||
|
||||
[AI 역량 사전: 일반적인 AI 핵심 개념과 용어, 시나리오 설명](/ko-kr/appendix/8-artificial-intelligence/ai-capability-dictionary)
|
||||
|
||||
### 0단계: 유치원
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :------------------------------------------------------------------------------------- | :----------------------------------------- | :--- |
|
||||
| [초보자 입문: 학습 지도](/ko-kr/stage-1/learning-map/) | 전체 학습 경로 가이드 | ✅ |
|
||||
| [초보자 입문: AI 시대, 말할 수 있으면 코딩할 수 있다](/ko-kr/stage-1/ai-capabilities-through-games/) | 뱀 게임 등의 사례로 AI 프로그래밍 능력 체감 | ✅ |
|
||||
|
||||
### 1단계: AI 제품 매니저
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :---------------------------------------------------------------------------- | :------------------------------------------------------- | :--- |
|
||||
| [초급 2: AI IDE 도구 이해하기](/ko-kr/stage-1/introduction-to-ai-ide/) | IDE 사용법 학습, 인터페이스 구조와 효율적인 프롬프트 방식 마스터 | ✅ |
|
||||
| [초급 3: 직접 프로토타입 만들기](/ko-kr/stage-1/building-prototype/) | 제품 분석 및 분해부터 다중 페이지 제품 프로토타입 구현까지의 완전한 사이클 | ✅ |
|
||||
| [초급 4: 프로토타입에 AI 능력 추가하기](/ko-kr/stage-1/integrating-ai-capabilities/) | 일반적인 AI 능력(텍스트, 이미지, 비디오)의 API 연동 이해 및 완성 | ✅ |
|
||||
| [초급 5: 완전한 프로젝트 실전](/ko-kr/stage-1/complete-project-practice/) | 실제 시나리오 시뮬레이션, 사용자 피드백 반복 및 프로젝트 발표 완료(대과제 포함) | ✅ |
|
||||
|
||||
#### 부록
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :-------------------------------------------------------------------- | :---------------------------------------- | :--- |
|
||||
| [부록 A: 제품 사고 보충](/ko-kr/stage-1/appendix-a-product-thinking/) | 아이디어 평가부터 요구사항 분해와 MVP까지의 제품 사고 프레임워크 | ✅ |
|
||||
| [부록 B: 일반적인 오류 및 해결 방법](/ko-kr/stage-1/appendix-b-common-errors/) | vibe coding에서의 일반적인 오류 및 해결 방법 | ✅ |
|
||||
| [부록: 아이디어를 어디서 찾을까](/ko-kr/stage-1/appendix-idea-sources/) | 참고 앱, 트렌드, VC 목록에서 세부 방향 발굴 | ✅ |
|
||||
| [부록: 더블 다이아몬드 모델](/ko-kr/stage-1/appendix-double-diamond/) | 먼저 문제를 정의한 후 솔루션 설계를 전개하는 완전한 리듬 이해 | ✅ |
|
||||
| [부록: Jobs to Be Done](/ko-kr/stage-1/appendix-jobs-to-be-done/) | JTBD 방법으로 사용자가 정말로 완료하고 싶은 일 파악 | ✅ |
|
||||
| [부록: The Mom Test 사용자 인터뷰 방법](/ko-kr/stage-1/appendix-mom-test/) | 사용자 인터뷰를 통한 요구사항 검증 조사 방법 | ✅ |
|
||||
|
||||
### 2단계: 초중급 개발 엔지니어
|
||||
|
||||
#### 프론트엔드 부분
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------- | :--- |
|
||||
| lovart로 소재 제작 | lovart를 사용하여 인물, 장면 등 시각 소재를 대량 생성하고, UI 디자인과 프론트엔드 개발을 위한 소재 기반 제공 | 🚧 |
|
||||
| Figma와 MasterGo 입문 | 디자인 도구로 정보 구조와 페이지 구조를 정리하고, 프론트엔드 구현을 위한 기반 마련 | 🚧 |
|
||||
| 첫 번째 모던 애플리케이션 구축 - UI 디자인 | 디자인 시안을 기반으로 컴포넌트화된 인터페이스 완성, 디자인에서 코드로의 첫 번째 연결 구현 | 🚧 |
|
||||
| UI 디자인 가이드라인을 참고하여 페이지와 버튼 디자인 | 주류 디자인 가이드라인을 사용하여 페이지 구조, 버튼 계층을 조직하고, AI를 활용한 디자인 제안 생성 학습 | 🚧 |
|
||||
| [함께 호그와트 초상화 만들기](/ko-kr/stage-2/frontend/hogwarts-portraits/) | 0부터 1까지 AI 능력을 연동한 프론트엔드 애플리케이션 제작, 디자인과 개발 연결 | 🚧 |
|
||||
|
||||
#### 백엔드 개발 부분
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------ | :--- |
|
||||
| API란 무엇인가 | HTTP 인터페이스와 요청-응답 모델 이해, 백엔드 통합 및 연동 준비 | 🚧 |
|
||||
| [데이터베이스부터 Supabase까지](/ko-kr/stage-2/backend/database-supabase/) | Supabase에서 데이터베이스와 API 구축, 데이터 모델과 프론트엔드 페이지 연결 | 🚧 |
|
||||
| 대형 언어 모델 보조 인터페이스 코드 및 인터페이스 문서 작성 | 대형 언어 모델을 활용하여 인터페이스 및 데이터베이스 문서와 코드를 생성하고, 가독성과 테스트가 가능한 백엔드 구현 | 🚧 |
|
||||
| Git 워크플로우와 Zeabur 배포 | Git 워크플로우에서 코드 관리, 애플리케이션을 Zeabur에 배포하여 서비스 | 🚧 |
|
||||
| 모던 CLI 개발 도구 | CLI 유형 AI 프로그래밍 도구를 사용하여 개발과 디버깅을 가속화하고 개인 엔지니어링 워크플로우 형성 | 🚧 |
|
||||
| stripe 등 결제 시스템을 통합하는 방법 | 결제 시스템 연동, 결제 플로우와 기본 정산 프로세스 완성 | 🚧 |
|
||||
| 첫 번째 모던 애플리케이션 구축 - 풀스택 애플리케이션 | 프론트엔드, 백엔드, 결제 모듈을 종합하여 서비스 가능한 풀스택 웹 애플리케이션 완성 | 🚧 |
|
||||
| 모던 프론트엔드 컴포넌트 라이브러리 + Trae 실전 | 모던 프론트엔드 컴포넌트 라이브러리와 Trae를 사용하여 로그인/회원가입을 지원하고 유료화가 가능한 제품 독립 완성 | 🚧 |
|
||||
|
||||
#### AI 역량 부록
|
||||
|
||||
| 챕터 | 핵심 콘텐츠 | 상태 |
|
||||
| :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------- | :--- |
|
||||
| [Dify 입문과 지식 베이스 통합](/ko-kr/stage-2/ai-capabilities/dify-knowledge-base/) | Dify Workflow와 기본 RAG로 도구 유형 제품 구축, 후속 애플리케이션 업그레이드를 위한 샘플 제공 | 🚧 |
|
||||
| AI 사전 조회 및 멀티모달 API 통합 학습 | 적합한 모델과 API를 찾는 방법 학습, 텍스트, 이미지 등 멀티모달 능력을 제품에 연동 | 🚧 |
|
||||
|
||||
### 3단계: 고급 개발 엔지니어
|
||||
@@ -762,3 +762,7 @@ Karpathy의 공유 내용을 더 보려면 여기에서 확인할 수 있습니
|
||||
description="“게임화 경험”에서 출발해 로컬 개발과 제품 실습으로 계속 들어가 보기를 추천합니다."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
---
|
||||
title: 'Beginner 1: Talking Is Programming'
|
||||
description: 'Build an AI-native snake game through conversation, then reuse the workflow to create your own mini game or demo.'
|
||||
---
|
||||
|
||||
+172
-169
@@ -2,130 +2,130 @@
|
||||
|
||||
## 이 장의 가이드
|
||||
|
||||
수많은 AI 코딩 도구 중에서 어떤 도구가 가장 나에게 잘 맞을까요? 이 장에서는 하나의 통일된 실습 과제인 “스네이크 + AI 시 쓰기” 게임 개발을 통해 Lovable, Replit, Z.ai 등 7가지 주요 Web Vibe Coding 플랫폼을 깊이 있게 가로로 비교합니다. 초보자 친화성, 코드 제어 가능성, 배포 편의성 등 여러 관점에서 비교하여, 가장 강력한 개발 보조 도구를 빠르게 고를 수 있도록 돕습니다.
|
||||
수많은 AI 코딩 도구 중에서 어떤 도구가 가장 나에게 잘 맞을까요? 이 장에서는 하나의 통일된 실습 과제인 "스네이크 + AI 시 쓰기" 게임 개발을 통해 Lovable, Replit, Z.ai 등 7가지 주요 Web Vibe Coding 플랫폼을 깊이 있게 가로로 비교합니다. 초보자 친화성, 코드 제어 가능성, 배포 편의성 등 여러 관점에서 비교하여, 가장 강력한 개발 보조 도구를 빠르게 고를 수 있도록 돕습니다.
|
||||
|
||||
---
|
||||
|
||||
# 1. Vibe Coding으로 스네이크 게임 만들기: 전체 실습 튜토리얼
|
||||
# 1. Vibe Coding으로 스네이크 게임 만들기: 완전 실전 튜토리얼
|
||||
|
||||
이 글은 새로운 소프트웨어 개발 실천 방식인 “Vibe Coding(분위기식 코딩)”을 소개합니다. Vibe Coding은 인공지능을 활용해 애플리케이션 구축 과정을 가속합니다.
|
||||
이 글에서는 새로운 소프트웨어 개발 방식인 "Vibe Coding(분위기 코딩)"을 소개합니다. 이 방식은 인공지능을 활용해 애플리케이션 구축 과정을 가속화합니다.
|
||||
|
||||
이제 Vibe Coding의 핵심 개념을 차례대로 소개하고, AI Agent가 무엇인지 설명한 뒤, 실용적인 프롬프트 작성 방법을 제시합니다. 마지막에는 “스네이크(Snake)” 게임을 처음부터 구축하는 전체 실습을 진행하고, 여러 주요 Vibe Coding 플랫폼을 상세히 비교 평가하여 자신에게 가장 적합한 도구 조합을 선택할 수 있도록 돕습니다.
|
||||
앞으로 Vibe Coding의 핵심 개념, AI Agent의 의미, 실용적인 프롬프트 작성 방법을 차례로 소개하겠습니다. 마지막으로, 제로에서 "스네이크(Snake)" 게임을 구축하는 완전한 실전을 통해 여러 주요 Vibe Coding 플랫폼을 상세히 비교 평가하여, 자신에게 가장 적합한 도구 조합을 선택할 수 있도록 돕겠습니다.
|
||||
|
||||
## 배우게 될 것
|
||||
## 배울 내용:
|
||||
|
||||
- **Vibe Coding이란 무엇인가:** 정의, 워크플로, 핵심 장점을 이해합니다.
|
||||
- **AI Agent의 역할:** AI Agent의 작동 방식과 전통적인 프로그램과의 차이를 이해합니다.
|
||||
- **좋은 프롬프트를 쓰는 법:** 더 좋은 결과를 얻기 위해 명확하고 구체적인 프롬프트 작성법을 익힙니다.
|
||||
- **Vibe Coding 도구:** 주요 AI 코딩 및 디자인 플랫폼들을 알아봅니다.
|
||||
- **플랫폼 비교:** 초보자의 관점에서 7가지 서로 다른 AI Agent 플랫폼의 장단점을 평가하고 비교합니다.
|
||||
- **UI / UX 도구:** Figma, Mastergo 같은 UI/UX 도구를 전체 워크플로에 통합하는 방법을 배웁니다.
|
||||
- **Vibe Coding이란:** 정의, 워크플로, 핵심 장점 이해
|
||||
- **AI Agent의 역할:** AI Agent의 작동 방식과 전통적인 프로그램과의 차이 이해
|
||||
- **프롬프트 잘 쓰는 법:** 명확하고 구체적인 프롬프트 작성법 마스터
|
||||
- **Vibe Coding 도구:** 주요 AI 프로그래밍 및 디자인 플랫폼 소개
|
||||
- **플랫폼 비교:** 초보자 관점에서 7개 AI Agent 플랫폼의 장단점 평가 및 비교
|
||||
- **UI / UX 도구:** Figma, Mastergo 등 UI/UX 도구를 전체 워크플로에 통합하는 방법 학습
|
||||
|
||||
## 1. 들어가며
|
||||
## 1. 서론
|
||||
|
||||
이전 수업에서는 계속 z.ai의 풀스택 개발 모델을 사용해 프로그래밍 과제를 완성해 왔습니다.
|
||||
이전 수업에서는 z.ai의 풀스택 개발 모델을 사용하여 프로그래밍 작업을 완료했습니다.
|
||||
|
||||
하지만 우리는 생각해 본 적이 있을까요? 그 핵심은 사실 “AI Agent”입니다. 일반적인 채팅형 AI와는 다르고, 훨씬 더 지능적입니다. 단지 당신과 대화만 하는 것이 아니라 생각할 수 있고(당신이 작업을 주면 먼저 계획을 세웁니다), 주도적으로 행동할 수도 있기 때문입니다. 예를 들어 웹 검색 호출, 컴퓨터 명령 실행, 웹페이지 열기 같은 도구를 사용할 수 있습니다. 뒤에서 더 자세히 소개하겠습니다.
|
||||
하지만, 그 핵심이 사실 "AI Agent"(일반적인 채팅형 AI와 다르며, 훨씬 더 지능적)라는 것을 생각해 본 적 있나요? 그 이유는 단순히 대화만 하는 것이 아니라, 사고할 수 있고(작업을 주면 먼저 계획을 수립), 능동적으로 행동할 수 있기(예: 웹 검색, 컴퓨터 명령 실행, 웹 페이지 열기 등의 도구 호출) 때문입니다. 자세한 내용은 나중에 다루겠습니다.
|
||||
|
||||
## 1. Vibe Coding이란 무엇인가?
|
||||
## 1. Vibe Coding이란?
|
||||
|
||||
Vibe Coding은 AI를 활용해 애플리케이션 개발 흐름을 가속하는 새로운 소프트웨어 개발 방식입니다. 전통적인 프로그래밍의 대체물이 아니라, 더 “대화식”인 프로그래밍 모델에 가깝습니다. 이 개념은 AI 연구자 Andrej Karpathy가 제시했습니다. 이 워크플로에서 개발자는 더 이상 코드를 한 줄씩 직접 작성하는 데 중심을 두지 않고, 주로 AI Agent를 이끌어 애플리케이션을 생성하고, 최적화하고, 디버깅합니다.
|
||||
Vibe Coding은 AI를 활용해 애플리케이션 개발 과정을 가속화하는 새로운 소프트웨어 개발 방식입니다. 이것은 전통적인 프로그래밍을 대체하는 것이 아니라, 더 "대화형" 프로그래밍 모드입니다. 이 개념은 AI 연구자 Andrej Karpathy가 제안했습니다: 이 워크플로에서 개발자는 더 이상 코드를 한 줄씩 수동으로 작성하지 않고, 주로 AI Agent를 안내하여 애플리케이션을 생성, 최적화 및 디버깅합니다.
|
||||
|
||||
Vibe Coding의 핵심 생각은 **“코드 중심(code-first)”** 에서 **“의도 중심(intent-first)”** 으로 전환하는 것입니다. 더 이상 첫 번째 코드 줄부터 구상할 필요가 없습니다. 자연어로 원하는 결과를 설명하면 됩니다.
|
||||
Vibe Coding의 핵심 사상은 **"코드 중심(code-first)"**에서 **"의도 중심(intent-first)"**으로 전환하는 것입니다. 더 이상 첫 번째 줄의 코드부터 구상할 필요 없이, 자연어로 원하는 결과를 설명하면 됩니다.
|
||||
|
||||
전형적인 Vibe Coding 워크플로는 끊임없이 반복되는 순환입니다.
|
||||
전형적인 Vibe Coding 워크플로는 끊임없이 반복되는 순환입니다:
|
||||
|
||||
- **목표 설명:** 먼저 한 문장이나 한 단락으로 구현하고 싶은 기능을 설명합니다. 예: “Python 백엔드가 있고 시를 생성할 수 있는 간단한 스네이크 게임을 만들어줘.”
|
||||
- **AI가 코드 생성:** AI Agent가 요구사항을 해석하고, 기본 구조, 프론트엔드 페이지, 백엔드 로직을 포함한 첫 번째 코드 버전을 생성합니다.
|
||||
- **실행하고 관찰:** 생성된 코드를 실행해 예상대로 동작하는지 확인하고, 동시에 버그나 부족한 점을 찾습니다.
|
||||
- **피드백하고 반복:** 오류가 있거나 결과가 마음에 들지 않으면 대화에서 계속 지시합니다. 예: “뱀이 너무 느리게 움직여. 속도를 더 빠르게 해줘”, 또는 “지금 `.env` 파일의 API Key가 제대로 읽히지 않아. 백엔드 코드를 고쳐줘.”
|
||||
- **위 단계를 반복:** “설명 → 생성 → 실행 → 피드백” 순환을 계속 반복해 애플리케이션이 만족스러운 상태에 도달할 때까지 개선합니다.
|
||||
- **목표 설명:** 한 문장이나 한 단락으로 구현하고 싶은 기능을 설명합니다. 예: "Python 백엔드가 있고, 시를 생성할 수 있는 간단한 스네이크 게임을 만들어 줘."
|
||||
- **AI 코드 생성:** AI Agent가 요구사항을 분석하여 초안 코드를 생성하고, 기본 구조, 프론트엔드 페이지, 백엔드 로직을 포함합니다.
|
||||
- **실행 및 관찰:** 생성된 코드를 실행하고, 예상대로 작동하는지 확인하며, 버그나 부족한 점을 발견합니다.
|
||||
- **피드백 및 반복:** 오류가 있거나 효과가 만족스럽지 않으면 대화에서 계속 지시를 내립니다. 예: "뱀의 이동 속도가 너무 느려, 속도를 올려 줘" 또는 "지금 `.env` 파일의 API Key가 제대로 읽히지 않아, 백엔드 코드를 수정해 줘."
|
||||
- **위 단계 반복:** "설명 -> 생성 -> 실행 -> 피드백"의 순환을 계속 반복하여 애플리케이션이 만족스러운 상태에 도달할 때까지 진행합니다.
|
||||
|
||||
### Vibe Coding의 주요 장점
|
||||
### Vibe Coding의 주요 장점:
|
||||
|
||||
- **진입 장벽 감소:** 프로그래밍 경험이 부족한 디자이너, 창업자, 학생 등도 자연어를 통해 애플리케이션 개발에 참여할 수 있습니다.
|
||||
- **빠른 프로토타입:** 아이디어에서 최소 기능 제품(MVP)까지 걸리는 시간이 크게 줄어듭니다.
|
||||
- **효율 향상:** 템플릿 코드처럼 반복적이고 기계적인 코딩 작업을 자동으로 처리하여, 개발자가 아키텍처 설계와 문제 추상화에 더 집중할 수 있게 합니다.
|
||||
- **실험에 유리:** 먼저 빠르게 만들어 보고 계속 개선하는 방식을 장려하므로, 새로운 아이디어와 기능을 시도하기가 더 쉽습니다.
|
||||
- **진입 장벽 감소:** 프로그래밍 경험이 없는 디자이너, 창업자, 학생 등도 자연어로 애플리케이션 개발에 참여할 수 있습니다.
|
||||
- **빠른 프로토타이핑:** 아이디어에서 최소 실행 가능 제품(MVP)까지의 시간이 대폭 단축됩니다.
|
||||
- **효율성 향상:** 반복적이고 기계적인 코딩 작업(예: 템플릿 코드)을 자동으로 처리하여, 개발자가 아키텍처 설계와 문제 추상화에 집중할 수 있게 합니다.
|
||||
- **실험 유리:** 먼저 빠르게 결과물을 내고, 지속적으로 개선하는 방식을 장려하여, 새로운 아이디어와 기능을 시도하기 편합니다.
|
||||
|
||||
## 2. Vibe Coding 온라인 플랫폼(Web-based)이란 무엇인가?
|
||||
## 2. Vibe Coding 온라인 플랫폼(Web-based)이란?
|
||||
|
||||
이번 실제 테스트에서 평가한 도구는 **Web-based(온라인 플랫폼)** 과 **IDE(로컬 개발 환경)** 두 종류로 나뉩니다.
|
||||
이번 실측에서는 평가 도구가 두 가지 범주로 나뉘어 있음을 알 수 있습니다: **Web-based(온라인 플랫폼)**과 **IDE(로컬 개발 환경)**.
|
||||
|
||||
둘 다 핵심은 AI가 코드를 작성하도록 돕는 것이지만, 사용 경험과 적합한 상황에는 큰 차이가 있습니다.
|
||||
핵심은 모두 AI가 코드를 작성하는 것을 돕는 것이지만, 사용 경험과 적용 시나리오에서 큰 차이가 있습니다:
|
||||
|
||||
### Vibe Coding 온라인 플랫폼(Web-based)
|
||||
### Vibe Coding 온라인 플랫폼 (Web-based)
|
||||
|
||||
**대표 도구:** Lovable, Replit, Z.ai, v0
|
||||
|
||||
이는 “짐만 들고 들어가면 되는” 호텔식 아파트와 비슷합니다.
|
||||
이것은 "짐만 들고 바로 입주할 수 있는" 호텔식 아파트와 같습니다.
|
||||
|
||||
- **환경 설정 불필요:** Python 환경이 무엇인지, Node.js 버전이 무엇인지 신경 쓸 필요가 없고, 의존성 설치도 신경 쓰지 않아도 됩니다. 브라우저를 열고 주소를 입력하면 바로 코딩을 시작할 수 있습니다.
|
||||
- **원클릭 미리보기와 배포:** 코드가 생성되면 플랫폼은 보통 오른쪽 창에 실행 결과를 자동으로 보여줍니다. 완성되면 버튼 하나로 링크를 생성해 친구에게 공유할 수 있습니다.
|
||||
- **적합한 상황:**
|
||||
- **아이디어 빠른 검증(MVP):** 머릿속에 아이디어가 있고, 30분 정도 써서 만들 수 있는지 보고 싶을 때.
|
||||
- **초보자 입문:** 복잡한 환경 오류에 막혀 포기하고 싶지 않고, AI 코딩의 재미를 경험하고 싶을 때.
|
||||
- **가벼운 애플리케이션:** 간단한 도구 웹페이지, 미니게임, 개인 소개 페이지를 만들 때.
|
||||
- **환경 설정 불필요:** Python 환경이 무엇인지, Node.js 버전이 무엇인지 신경 쓸 필요가 없고, 의존성 설치도 필요 없습니다. 브라우저를 열고 URL을 입력하면 바로 코드를 작성할 수 있습니다.
|
||||
- **원클릭 미리보기 및 배포:** 코드가 생성되면 플랫폼이 보통 오른쪽 창에 자동으로 실행 효과를 보여 줍니다. 완성되면 버튼 하나로 링크를 생성해 친구에게 공유할 수 있습니다.
|
||||
- **적합한 시나리오:**
|
||||
- **빠른 아이디어 검증(MVP):** 머릿속에 아이디어가 있고, 30분 안에 만들 수 있는지 확인하고 싶을 때.
|
||||
- **초보자 입문:** 복잡한 환경 오류에 좌절하고 싶지 않고, AI 프로그래밍의 재미만 경험하고 싶을 때.
|
||||
- **경량급 애플리케이션:** 간단한 도구 웹페이지, 소규모 게임 또는 개인 소개 페이지 만들기.
|
||||
|
||||
### AI IDE(로컬 개발 환경)
|
||||
### AI IDE (로컬 개발 환경)
|
||||
|
||||
**대표 도구:** Cursor, Trae, VS Code + AI 플러그인
|
||||
|
||||
이는 “고급 인테리어가 된” 자가 주택과 비슷합니다.
|
||||
이것은 "인테리어가 완료된" 자가 주택과 같습니다.
|
||||
|
||||
- **강력한 로컬 능력:** 당신의 컴퓨터에서 실행되며, 모든 로컬 파일에 직접 접근하고 컴퓨터의 연산 자원을 활용할 수 있습니다.
|
||||
- **전문 워크플로와 매끄러운 연결:** 대형 프로젝트에 적합하며, 다양한 플러그인을 자유롭게 설치하고, 로컬 데이터베이스에 연결하고, 복잡한 디버깅을 수행할 수 있습니다.
|
||||
- **적합한 상황:**
|
||||
- **전문 프로젝트 개발:** 장기 유지보수가 필요하고 구조가 복잡한 상업 프로젝트.
|
||||
- **깊은 맞춤화:** 코드 세부 사항을 극도로 제어해야 하거나 Git, Docker 같은 기존 로컬 워크플로와 깊게 결합해야 할 때.
|
||||
- **데이터 프라이버시:** 코드가 완전히 로컬에 있으므로 일부 기업의 보안 규정에 더 잘 맞습니다.
|
||||
- **강력한 로컬 기능:** 컴퓨터에서 실행되며, 모든 로컬 파일에 직접 접근할 수 있고, 컴퓨터의 컴퓨팅 파워를 활용할 수 있습니다.
|
||||
- **전문 워크플로와 원활한 연동:** 대규모 프로젝트에 적합하며, 다양한 플러그인을 자유롭게 설치하고, 로컬 데이터베이스에 연결하며, 복잡한 디버깅을 수행할 수 있습니다.
|
||||
- **적합한 시나리오:**
|
||||
- **전문 프로젝트 개발:** 장기간 유지보수가 필요하고 구조가 복잡한 상업 프로젝트.
|
||||
- **딥 커스터마이징:** 코드 세부 사항에 대한 완벽한 제어가 필요하거나 기존 로컬 워크플로(Git, Docker 등)와 깊은 통합이 필요한 경우.
|
||||
- **데이터 프라이버시:** 코드가 완전히 로컬에 있어 특정 기업의 보안 규정에 더 부합합니다.
|
||||
|
||||
**정리하면:** AI 코딩을 막 시작했거나 작은 것을 빠르게 만들어 보고 싶다면 **온라인 플랫폼**이 훌륭한 출발점입니다. 전문 개발자이거나 프로젝트가 점점 복잡해진다면 **로컬 IDE**가 더 높은 상한을 제공합니다.
|
||||
**요약하자면:** AI 프로그래밍을 처음 접하거나, 간단한 것을 빠르게 만들어 보고 싶다면 **온라인 플랫폼**이 훌륭한 출발점입니다. 전문 개발자이거나 프로젝트가 점점 복잡해진다면 **로컬 IDE**가 더 높은 상한을 제공할 것입니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. AI Agent란 무엇인가?
|
||||
## 3. AI Agent란?
|
||||
|
||||
### AI Agent란 무엇인가?
|
||||
### AI Agent란?
|
||||
|
||||
AI Agent는 환경을 감지하고, 결정을 내리고, 특정 목표를 달성하기 위해 자율적으로 행동할 수 있는 소프트웨어 시스템입니다. 고정된 지시를 따르고 흐름이 단일한 전통적인 소프트웨어와 비교하면, AI Agent는 더 유연하고 적응적입니다.
|
||||
AI Agent는 환경을 인식하고, 의사결정을 내리며, 특정 목표를 달성하기 위해 자율적으로 행동하는 소프트웨어 시스템입니다. 고정된 지시를 따르고 단일한 흐름을 가진 전통적인 소프트웨어와 비교하여, AI Agent는 더 유연하고 적응력이 뛰어납니다.
|
||||
|
||||
아래는 AI Agent를 전통적인 프로그램과 구분하는 몇 가지 핵심 특징입니다.
|
||||
다음은 AI Agent를 전통적인 프로그램과 구분하는 핵심 특징입니다:
|
||||
|
||||
- **자율성(Autonomy):** AI Agent는 비교적 높은 독립성을 가집니다. 전통적인 프로그램은 보통 사람이 한 단계씩 트리거해야 하지만, Agent는 목표에 따라 다음에 무엇을 할지 스스로 결정할 수 있습니다.
|
||||
- **지각과 기억(Perception & Memory):** Agent는 환경에서 데이터를 수집합니다. 예를 들어 API 응답, 센서 데이터, 사용자 입력 등이 있습니다. 또한 “기억”을 통해 맥락을 보존하여 이후 행동에서 경험을 재사용하고 결과를 지속적으로 개선합니다.
|
||||
- **합리성과 목표 지향(Rationality & Goal-Orientation):** Agent는 주어진 목표를 중심으로 분석하고 계획하며, 더 높은 “성과 지표”를 추구하기 위해 가장 적절한 행동 순서를 선택합니다.
|
||||
- **도구 사용(Tool Use):** 현대 AI Agent의 큰 특징 중 하나는 외부 도구를 호출할 수 있다는 점입니다. 더 이상 “텍스트 생성”에만 갇혀 있지 않습니다. 예를 들어 웹을 탐색하고, 코드를 실행하고, 데이터베이스를 조회하고, 이메일을 보낼 수 있습니다. 즉 “도구를 조율하는” 두뇌입니다.
|
||||
- **자율성(Autonomy):** AI Agent는 높은 독립성을 가집니다. 전통적인 프로그램은 보통 사람이 한 단계씩 트리거해야 하지만, Agent는 목표에 따라 다음에 무엇을 해야 할지 자율적으로 결정할 수 있습니다.
|
||||
- **인식과 기억(Perception & Memory):** Agent는 환경에서 데이터를 수집(예: API 응답, 센서 데이터, 사용자 입력 등)하고, "기억"을 통해 컨텍스트를 보존하여, 후속 행동에서 경험을 재사용하고 효과를 지속적으로 개선합니다.
|
||||
- **합리성과 목표 지향성(Rationality & Goal-Orientation):** Agent는 주어진 목표를 중심으로 분석하고 계획하며, 더 높은 "성과 지표"를 추구하기 위해 가장 적합한 행동 순서를 선택합니다.
|
||||
- **도구 사용(Tool Use):** 현대 AI Agent의 중요한 특징은 외부 도구를 호출할 수 있다는 것으로, 더 이상 "텍스트 생성"에만 국한되지 않습니다. 예를 들어, 웹을 탐색하고, 코드를 실행하고, 데이터베이스를 쿼리하고, 이메일을 보내는 등 "도구를 스케줄링하는" 두뇌입니다.
|
||||
|
||||
다음과 같이 비유해 이해할 수 있습니다.
|
||||
이렇게 비유해 볼 수 있습니다:
|
||||
|
||||
- **전통적인 프로그램**은 계산기와 같습니다. 숫자와 연산자를 입력하면, 버튼을 눌렀을 때만 계산을 수행합니다.
|
||||
- **AI 어시스턴트**는 인간 비서와 같습니다. “근처 식당을 찾아줘”라고 하면 검색 결과를 주고 선택지를 나열하지만, 최종 결정은 여전히 당신이 합니다.
|
||||
- **AI Agent**는 자동화된 연구팀에 더 가깝습니다. 당신은 “일본 여행 일정을 계획해줘” 같은 상위 목표만 주면 됩니다. 그러면 Agent는 작업을 분해하고, 인터넷에서 자료를 찾고, 항공권과 호텔을 예약하고(API를 통해), 일정을 정리한 뒤 최종 결과를 전달합니다. 전체 과정에서 세부 사항에 대한 당신의 개입은 거의 필요하지 않습니다.
|
||||
- **전통적인 프로그램**은 계산기와 같습니다. 숫자와 연산자를 입력하면 버튼을 누를 때만 계산을 실행합니다.
|
||||
- **AI 어시스턴트**는 인간 비서와 같습니다. "근처 식당을 찾아줘"라고 하면 검색 결과를 보여주고 옵션을 나열하지만, 최종 결정은 여러분이 내립니다.
|
||||
- **AI Agent**는 자동화된 연구 팀과 더 비슷합니다. 고수준 목표(예: "일본 여행 일정을 짜줘")만 주면, 작업을 분해하고, 인터넷에서 자료를 찾고, 항공편과 호텔을 예약(API를 통해)하고, 일정을 정리하여 결과를 전달합니다. 전체 과정에서 세부 사항에 거의 개입할 필요가 없습니다.
|
||||
|
||||
---
|
||||
|
||||
# 2. 프롬프트 작성에 대하여
|
||||
|
||||
## 1. 프롬프트를 한 번에 다 쓰는 것이 좋을까, 여러 단계로 나누는 것이 좋을까?
|
||||
## 1. 프롬프트를 한 번에 작성하는 것이 좋은가, 여러 단계로 나누는 것이 좋은가?
|
||||
|
||||
많은 사람은 “완전한 풀스택 애플리케이션을 만들어줘”라는 내용을 하나의 프롬프트 안에 한 번에 다 설명하고 싶어 합니다. 실제로 현재 도구들은 이미 충분히 강력해서, 한 번에 꽤 괜찮아 보이는 결과를 내놓을 가능성도 있습니다. 하지만 전체 경험과 성공률을 보면, 작업을 작은 단계로 나누고 단계별로 반복하는 편이 대체로 더 좋습니다. “더 이상 고쳐지지 않는” 막다른 길에 빠질 가능성도 줄어듭니다.
|
||||
많은 사람들이 "완전한 풀스택 애플리케이션 만들기"를 하나의 프롬프트에 한 번에 설명하고 싶어 합니다. 사실 현재 도구는 충분히 강력하여, 한 번에 꽤 괜찮은 결과를 낼 수 있습니다. 하지만 전체적인 경험과 성공률 측면에서, 작업을 작은 단계로 나누고 단계별로 반복하는 것이 더 나은 결과를 내며, "더 이상 고칠 수 없는" 막다른 골목에 빠질 가능성도 적습니다.
|
||||
|
||||
> **작은 팁:** “한 번에 완성”을 기대하기보다, 큰 목표를 실행 가능한 작은 할 일(To-do)들로 나누는 편이 좋습니다.
|
||||
> 예를 들어 “build me a Snake game”이라고 바로 말하지 말고, 다음처럼 나누세요.
|
||||
> “1. 먼저 스네이크 게임의 프론트엔드를 만들어줘”,
|
||||
> “2. 그다음 점수를 기록하는 백엔드를 구현해줘”,
|
||||
> “3. 마지막으로 프론트엔드와 백엔드를 연결해줘”.
|
||||
> 이렇게 하면 AI가 요구사항을 더 정확히 이해하고 더 신뢰할 수 있는 출력을 낼 수 있습니다.
|
||||
> **작은 팁:** "한 번에 완벽하게" 기대하기보다, 큰 목표를 실행 가능한 작은 할 일(To-do)로 나누는 것이 좋습니다.
|
||||
> 예를 들어, "build me a Snake game"이라고 바로 말하지 말고, 다음과 같이 나누세요:
|
||||
> "1. 먼저 스네이크 게임의 프론트엔드를 만들어 줘",
|
||||
> "2. 그 다음 점수를 기록하는 백엔드를 구현해 줘",
|
||||
> "3. 마지막으로 프론트엔드와 백엔드를 연결해 줘".
|
||||
> 이렇게 하면 AI가 여러분의 요구사항을 더 정확하게 이해하고 더 안정적인 결과를 낼 수 있습니다.
|
||||
|
||||
## 2. 명확할수록 좋다
|
||||
## 2. 명확할수록 좋습니다
|
||||
|
||||
- Vibe Coding에서 당신이 쓰는 프롬프트는 당신이 쓰는 코드만큼 중요합니다. 프롬프트가 명확하고 구체적일수록 결과는 당신이 마음속으로 생각한 것에 더 가까워집니다.
|
||||
- 처음부터 목표와 제약 조건을 명확히 말하면 이후 반복 수정 횟수를 줄일 수 있습니다. 이는 시간을 아낄 뿐 아니라 사용량과 비용도 절약합니다.
|
||||
- Vibe Coding에서 작성하는 프롬프트는 작성하는 코드만큼 중요합니다. 프롬프트가 명확하고 구체적일수록 결과가 여러분의 생각에 더 가까워집니다.
|
||||
- 처음에 목표와 제약 조건을 명확히 설명하면, 후속 수정 횟수를 줄일 수 있으며, 이는 시간 절약일 뿐만 아니라 사용량과 비용도 절약할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
# 3. 도구 개요(Vibe Coding / UIUX 도구)
|
||||
# 3. 도구 개요 (Vibe Coding / UIUX 도구)
|
||||
|
||||
## 1. AI Agent 플랫폼
|
||||
|
||||
@@ -148,9 +148,9 @@ AI Agent는 환경을 감지하고, 결정을 내리고, 특정 목표를 달성
|
||||
|
||||
---
|
||||
|
||||
# 4. 실습 튜토리얼(Vibe Coding + UI 결합)
|
||||
# 4. 실전 튜토리얼 (Vibe Coding + UI 결합)
|
||||
|
||||
1. Vibe Coding을 진행하려는 플랫폼의 채팅창에 원하는 프로그램 설명을 입력합니다.
|
||||
1. Vibe Coding을 진행할 플랫폼의 채팅 창에 원하는 프로그램 설명을 입력합니다.
|
||||
예시:
|
||||
|
||||
> 프론트엔드와 백엔드가 있는 간단한 스네이크(Snake) 웹 애플리케이션을 만들어 주세요.
|
||||
@@ -160,197 +160,200 @@ AI Agent는 환경을 감지하고, 결정을 내리고, 특정 목표를 달성
|
||||
> - 페이지 1: 게임 페이지
|
||||
> - 키보드로 뱀의 이동을 제어합니다.
|
||||
> - 뱀이 먹는 것은 음식이 아니라 영어 단어입니다.
|
||||
> - 페이지 사이드바에 수집한 단어와 개수를 표시합니다.
|
||||
> - 게임이 끝난 뒤에도 수집한 단어는 그대로 남아 있고, 새 게임에서도 이어집니다.
|
||||
> - 페이지 2: 시 쓰기 페이지(Make Poem)
|
||||
> - 게임 페이지와 같은 단어 목록을 표시합니다. 데이터는 동일해야 합니다.
|
||||
> - 현재 수집한 단어를 백엔드로 보내 시를 생성하는 버튼을 제공합니다.
|
||||
> - 시가 생성된 뒤, 사용된 단어를 목록에서 제거하거나 개수를 줄입니다.
|
||||
> - 페이지 사이드바에 수집된 단어와 수량을 표시합니다.
|
||||
> - 게임이 끝난 후에도 수집된 단어는 유지되며, 새로운 게임에서도 계속됩니다.
|
||||
> - 페이지 2: 시 쓰기 페이지 (Make Poem)
|
||||
> - 게임 페이지와 동일한 단어 목록을 표시합니다(데이터 일관성).
|
||||
> - 현재 수집된 단어를 백엔드로 보내 시를 생성하는 버튼을 제공합니다.
|
||||
> - 시가 생성되면, 사용된 단어는 목록에서 제거되거나 카운트가 감소합니다.
|
||||
>
|
||||
> * Game과 Make Poem 두 페이지 사이를 전환할 수 있도록 간단한 내비게이션을 추가합니다.
|
||||
> * 수집된 단어가 두 페이지 모두에서 보이도록 보장합니다.
|
||||
> * Game과 Make Poem 두 페이지 사이를 전환하는 간단한 내비게이션을 추가합니다.
|
||||
> * 수집된 단어가 두 페이지 모두에서 보이도록 합니다.
|
||||
>
|
||||
> 2. 백엔드
|
||||
>
|
||||
> - 수집한 단어를 받아 시를 반환하는 백엔드 API를 제공합니다.
|
||||
> - DeepSeek API를 사용해 시를 생성합니다.
|
||||
> - API Key는 `.env` 파일에 저장하고, `.gitignore`에서 해당 파일을 무시합니다.
|
||||
> - 수집된 단어를 받아 시를 반환하는 백엔드 인터페이스를 제공합니다.
|
||||
> - DeepSeek API를 사용하여 시를 생성합니다.
|
||||
> - API Key를 `.env` 파일에 저장하고, `.gitignore`에서 이 파일을 무시합니다.
|
||||
|
||||
2. DeepSeek API Key를 입력합니다. ([https://platform.deepseek.com/](https://platform.deepseek.com/) 에서 받을 수 있습니다.)
|
||||
1. LLM의 API Key는 자신의 프로젝트에서 대형 모델을 호출하는 데 사용됩니다. 민감한 정보이기 때문에 공개하면 안 되며, 별도의 설정 파일에 작성해야 합니다.
|
||||
**왜 `.env` 파일을 사용하고 GitHub에 업로드하면 안 될까요?**
|
||||
- `.env` 파일은 **키 또는 비밀번호**를 저장하는 데 전용으로 쓰입니다. 예: DeepSeek API Key.
|
||||
- 이 파일이 GitHub에 업로드되면 전 세계 사람이 당신의 키를 보고 도용할 수 있습니다.
|
||||
- 보안을 위해 `.gitignore` 파일에 `.env`를 무시하도록 선언하여 Git이 추적하지 않게 해야 합니다.
|
||||
- 이렇게 하면 프로젝트는 여전히 로컬에서 이 키들을 정상적으로 사용할 수 있지만, 저장소에는 유출되지 않습니다.
|
||||
2. DeepSeek API Key를 입력합니다. ([https://platform.deepseek.com/](https://platform.deepseek.com/)에서 얻을 수 있습니다)
|
||||
1. LLM의 API Key는 자신의 프로젝트에서 대형 모델을 호출하는 데 사용됩니다. 이것은 민감한 정보이므로 공개할 수 없으며, 별도의 설정 파일에 작성해야 합니다.
|
||||
**왜 `.env` 파일을 사용하고, 이것을 GitHub에 업로드하지 않아야 할까요?**
|
||||
- `.env` 파일은 **비밀키나 비밀번호**(예: DeepSeek API Key)를 저장하는 데 특화된 파일입니다.
|
||||
- 이 파일이 GitHub에 업로드되면, 전 세계 사람이 여러분의 비밀키를 보고 도용할 수 있습니다.
|
||||
- 안전을 위해 `.gitignore` 파일에 `.env`를 무시하도록 선언하여, Git이 이를 추적하지 않게 합니다.
|
||||
- 이렇게 하면 프로젝트는 로컬에서 이러한 비밀키를 정상적으로 사용할 수 있지만, 저장소에서 유출되지 않습니다.
|
||||
|
||||
3. 생성 결과를 확인한 뒤 오류가 있거나 수정할 부분이 있으면 채팅창에 바로 수정 요청을 입력할 수 있습니다.
|
||||
4. 페이지 디자인이 마음에 들지 않으면 Figma나 Mastergo에서 인터페이스를 다시 디자인한 뒤, 디자인 의도를 Agent에게 피드백할 수도 있습니다.
|
||||
3. 생성 결과를 확인한 후, 오류나 수정이 필요한 부분이 있으면 채팅 창에서 직접 수정 요청을 입력합니다.
|
||||
4. 페이지 디자인이 만족스럽지 않다면, Figma나 Mastergo에서 인터페이스를 다시 디자인한 후, 디자인 아이디어를 Agent에게 피드백할 수도 있습니다.
|
||||
|
||||
- **예시**
|
||||
|
||||
> _Word-Snake_ 라는 이름의 **두 페이지 Web 애플리케이션**을 설계해 주세요.
|
||||
> _Word-Snake_ 라는 이름의 **2페이지 웹 애플리케이션**을 디자인해 주세요.
|
||||
>
|
||||
> - **Game 페이지:**
|
||||
> - 뱀은 키보드로 이동을 제어합니다.
|
||||
> - 뱀이 먹는 것은 일반 음식이 아니라 영어 단어입니다.
|
||||
> - 오른쪽 패널에 수집한 단어와 수량을 표시합니다.
|
||||
> - 게임 종료 후에도 단어 재고는 초기화되지 않고, 다음 라운드에서 계속 사용됩니다.
|
||||
> - 오른쪽 패널에 수집된 단어와 수량을 표시합니다.
|
||||
> - 게임이 끝나도 단어 재고는 초기화되지 않고, 새로운 라운드에서 계속 사용합니다.
|
||||
> - **Make Poem 페이지:**
|
||||
> - 같은 공유 단어 재고를 표시합니다.
|
||||
> - 동일한 공유 단어 재고를 표시합니다.
|
||||
> - 사용자가 일부 단어를 선택하고 **Generate Poem** 버튼을 클릭합니다.
|
||||
> - 이 단어들을 백엔드로 보내 DeepSeek API가 시를 생성하게 합니다.
|
||||
> - 시가 생성된 뒤, 사용된 단어를 재고에서 삭제하거나 줄입니다.
|
||||
> - **내비게이션:** 간단한 Tab 또는 상단 메뉴로 두 페이지 사이를 전환합니다.
|
||||
> - **공유 상태:** 수집된 단어가 두 페이지에서 항상 동기화되어 보이도록 보장합니다.
|
||||
> - 이 단어들을 백엔드로 보내 DeepSeek API가 시를 생성합니다.
|
||||
> - 시가 생성되면, 사용된 단어는 재고에서 삭제되거나 카운트가 감소합니다.
|
||||
> - **내비게이션:** 간단한 Tab이나 상단 메뉴로 두 페이지 사이를 전환합니다.
|
||||
> - **공유 상태:** 수집된 단어가 두 페이지에서 항상 동기화되어 보이도록 합니다.
|
||||
|
||||
- **결과 예시**
|
||||
- **효과 예시**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. AI Agent 플랫폼 비교(간단한 프로젝트에 가장 좋은 조합을 고르는 법)
|
||||
# 5. AI Agent 플랫폼 비교 (간단한 프로젝트에 최적의 조합 선택하기)
|
||||
|
||||
서로 다른 Vibe Coding 플랫폼은 각기 다른 특징과 워크플로를 가지고 있습니다. 우리는 같은 “DeepSeek API가 포함된 스네이크 게임” 요구사항을 여러 플랫폼에서 실제로 테스트하고, 초보자의 관점에서 장단점을 평가했습니다. 아래는 요약입니다.
|
||||
각 Vibe Coding 플랫폼은 특징과 워크플로가 다릅니다. 우리는 "DeepSeek API가 있는 스네이크 게임"이라는 동일한 요구사항을 사용하여 여러 플랫폼에서 실측하고, 초보자 관점에서 장단점을 평가했습니다. 다음은 요약입니다.
|
||||
|
||||
## 1. 비교 기준
|
||||
|
||||
1. **목표(Goal)**
|
||||
DeepSeek API를 연결한 스네이크(Snake) 웹 애플리케이션을 구축합니다.
|
||||
|
||||
DeepSeek API가 연동된 스네이크(Snake) 웹 애플리케이션 구축.
|
||||
2. **게임 세부 사항(Game Details)**
|
||||
1. 게임은 DeepSeek LLM API를 통해 시를 생성합니다.
|
||||
2. 뱀이 먹는 것은 영어 단어이며, 수집한 단어는 게임 종료 후에도 유지되고 새 게임에서도 계속 사용됩니다. 같은 단어를 여러 번 수집할 수 있으며 각각 개수가 계산됩니다.
|
||||
3. 시를 하나 생성한 뒤, 사용된 단어는 재고에서 제거됩니다.
|
||||
1. 게임은 DeepSeek LLM API를 사용하여 시를 생성합니다.
|
||||
2. 뱀이 먹는 것은 영어 단어이며, 수집된 단어는 게임이 끝난 후에도 유지되고 새로운 게임에서 계속 사용됩니다. 동일한 단어는 여러 번 수집될 수 있으며, 각각 개별적으로 카운트됩니다.
|
||||
3. 시가 생성되면, 사용된 단어는 재고에서 제거됩니다.
|
||||
|
||||
3. **필수 기능(Must-Haves)**
|
||||
1. 스네이크 게임을 포함한 실행 가능한 프론트엔드 페이지. 키보드 제어와 Canvas 렌더링을 포함합니다.
|
||||
2. 단어 수집 메커니즘. 단어가 보드에 나타나고, 뱀이 단어를 먹으면 사이드바 목록이 업데이트됩니다.
|
||||
3. 여러 게임 라운드 사이에서도 단어 재고를 지속적으로 유지합니다.
|
||||
4. DeepSeek API를 사용하는 백엔드. API Key가 없으면 먼저 가짜 시를 반환해도 됩니다.
|
||||
5. “시 생성” 버튼. 클릭하면 백엔드를 호출하고, 시를 표시하며, 사용 상황에 따라 단어 재고를 업데이트합니다.
|
||||
6. API Key를 위한 `.env` 지원과 `.gitignore`를 통한 키 유출 방지.
|
||||
1. 실행 가능한 프론트엔드 페이지, 스네이크 게임 포함(키보드 제어, Canvas 렌더링).
|
||||
2. 단어 수집 메커니즘(단어가 보드에 나타나고, 뱀이 단어를 먹으면 사이드바 목록이 업데이트됨).
|
||||
3. 여러 라운드의 게임 사이에서 단어 재고의 지속성 유지.
|
||||
4. DeepSeek API를 사용하는 백엔드(API Key가 없는 경우, 먼저 모의 시를 반환).
|
||||
5. "시 생성" 버튼: 클릭 후 백엔드를 호출하고, 시를 표시하며, 사용량에 따라 단어 재고를 업데이트.
|
||||
6. API Key에 대한 `.env` 지원, 그리고 `.gitignore`를 통한 비밀키 유출 방지.
|
||||
|
||||
4. **있으면 좋은 기능(Nice-to-Haves)**
|
||||
1. 사용자가 시 생성에 사용할 단어를 선택할 수 있습니다.
|
||||
2. 사용자 경험이 친절합니다. 예를 들어 사이드바에 단어 목록을 명확히 보여 주고, 시 표시 영역의 레이아웃이 합리적이어야 합니다.
|
||||
3. 초보자를 위해 코드에 주석을 추가하여 핵심 로직을 설명합니다.
|
||||
4. **보너스 항목(Nice-to-Haves)**
|
||||
1. 사용자가 시를 생성할 단어를 선택할 수 있음.
|
||||
2. 사용자 친화적인 경험(예: 사이드바에 단어 목록이 명확히 표시, 시 표시 영역의 레이아웃이 합리적).
|
||||
3. 초보자를 위해 코드에 주석을 추가하여 핵심 로직 설명.
|
||||
|
||||
## 2. 코딩 출력 비교
|
||||
|
||||
### 1. Lovable(Web-based)
|
||||
### 1. Lovable (Web-based)
|
||||
|
||||
- **플랫폼 유형:** Web
|
||||
- **주요 특징과 워크플로:** Lovable은 통합과 협업 측면에서 잘 만들어져 있습니다. Supabase 데이터베이스 연결 같은 초기화 작업을 자동으로 처리하여 프로젝트 구축 과정이 매우 매끄럽습니다. 프로젝트 요구사항만 설명하면 Agent가 각종 서비스를 연결하고 기본 구조를 만들어 줍니다.
|
||||
- **적합한 사용자:** Vibe Coding을 처음 시도하는 초보자에게 Lovable은 매우 친절한 선택입니다. 여러 서비스를 함께 연결하는 복잡도를 단순화해 주므로 환경 설정이 아니라 프롬프트와 반복 개선에 집중할 수 있습니다. 높은 자동화 덕분에 실행 가능한 프로토타입을 빠르게 얻을 수 있습니다.
|
||||
- **플랫폼 유형:** 웹
|
||||
- **주요 특징 및 워크플로:** Lovable은 통합과 협업 측면에서 매우 우수합니다. Supabase 데이터베이스 연결 등의 초기화 작업을 자동으로 완료하여, 프로젝트 설정 과정을 매우 원활하게 만듭니다. 프로젝트 요구사항만 설명하면 Agent가 다양한 서비스를 연결하고 기본 구조를 구축해 줍니다.
|
||||
- **적합한 사용자:** 처음 Vibe Coding을 시도하는 초보자에게 Lovable은 매우 친근한 선택입니다. 다중 서비스 연동의 복잡성을 단순화하여, 환경 설정이 아닌 프롬프트와 반복에 집중할 수 있게 합니다. 높은 자동화 덕분에 실행 가능한 프로토타입을 빠르게 얻을 수 있습니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:** 비교적 비싼 편이지만, 학교 이메일이 있으면 학생 인증을 통해 반값으로 사용할 수 있습니다.
|
||||
- **가격:** 상대적으로 비싼 편이지만, 학교 이메일이 있다면 학생 인증으로 반값에 사용할 수 있습니다.
|
||||
|
||||
|
||||
### 2. Cursor(IDE)
|
||||
### 2. Cursor (IDE)
|
||||
|
||||
- **플랫폼 유형:** 데스크톱 애플리케이션(PC)
|
||||
- **주요 특징과 워크플로:** Cursor는 AI 기능이 통합된 전용 IDE이며 Windows, macOS, Linux를 지원합니다. 코드 생성, 지능형 재작성, 코드베이스 질의 같은 기능을 개발 환경 안에 직접 넣었습니다. Web 도구와 비교하면 전통적인 로컬 개발 경험에 더 가깝습니다. 로컬 환경이기 때문에 컴퓨터마다 설정이 다르고, 때때로 환경 관련 문제가 발생할 수 있습니다. 장점은 프로젝트가 내 컴퓨터에 있으므로 추가로 다운로드하거나 실행 환경을 설정할 필요가 적고, Cursor가 많은 번거로운 단계를 처리해 준다는 점입니다.
|
||||
- **적합한 사용자:** 어느 정도 프로그래밍 기초가 있는 사용자에게 Cursor는 매우 강력하고 익숙한 환경입니다. 그러나 완전 초보자에게는 프로젝트 구조, 의존성 관리, 파일 구성 같은 개념을 스스로 이해해야 하므로 학습 곡선이 더 가파를 수 있습니다. 전통적인 코딩 흐름에 AI 어시스턴트를 추가하고 싶은 개발자에게 더 적합합니다.
|
||||
- **플랫폼 유형:** 데스크톱 앱 (PC)
|
||||
- **주요 특징 및 워크플로:** Cursor는 AI 기능이 통합된 전용 IDE로, Windows, macOS, Linux를 지원합니다. 코드 생성, 지능형 재작성, 코드베이스 쿼리 등의 기능을 개발 환경에 직접 내장합니다. 웹 도구와 비교하여 전통적인 로컬 개발 경험에 더 가깝습니다. 로컬 환경이므로 컴퓨터마다 설정이 다를 수 있어, 때때로 환경 관련 문제가 발생할 수 있습니다. 장점은 프로젝트가 로컬에 있어 추가로 다운로드하거나 실행 환경을 설정할 필요가 없으며, Cursor가 많은 번거로운 단계를 처리해 준다는 것입니다.
|
||||
- **적합한 사용자:** 이미 어느 정도 프로그래밍 기반이 있는 사용자에게 Cursor는 매우 강력하고 익숙한 환경입니다. 하지만 완전한 제로 베이스 초보자에게는 프로젝트 구조, 의존성 관리, 파일 구성 등의 개념을 이해해야 하므로 학습 곡선이 더 가파릅니다. 전통적인 코딩 워크플로에 AI 어시스턴트를 추가하고 싶은 개발자에게 더 적합합니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:**
|
||||
|
||||
|
||||
### 3. Z.ai(Web-based)
|
||||
### 3. Z.ai (Web-based)
|
||||
|
||||
- **플랫폼 유형:** Web
|
||||
- **주요 특징과 워크플로:** Z.ai의 사용 방식은 비교적 직접적이지만, 뚜렷한 어려움이 하나 있습니다. **생성된 코드를 수동으로 복사해 붙여 넣어야 한다**는 점입니다. 플랫폼 자체에 실시간 미리보기 창이 부족하여 코드 실행 결과를 즉시 보기 어렵습니다.
|
||||
- **적합한 사용자:** 이 플랫폼은 비교적 “직접 손을 대는” 사용 방식을 요구합니다. 자동화가 부족하다는 것은 코드와 직접 마주해야 한다는 뜻이고, AI 출력 내용을 깊이 이해하고 싶은 사람에게는 오히려 훈련이 될 수 있습니다. 하지만 잦은 복사 붙여넣기는 효율 문제와 실수 위험을 가져옵니다. 원클릭 경험을 원하는 사람보다는 “AI가 원시적으로 출력한 코드”를 보고 싶은 학생에게 더 적합합니다.
|
||||
- **플랫폼 유형:** 웹
|
||||
- **주요 특징 및 워크플로:** Z.ai의 사용 방식은 비교적 직접적이지만, 한 가지 명백한 도전은 **생성된 코드를 수동으로 복사하여 붙여넣기**해야 한다는 것입니다. 플랫폼 자체에 실시간 미리보기 창이 없어, 코드 실행 효과를 바로 확인하기 어렵습니다.
|
||||
- **적합한 사용자:** 이 플랫폼은 비교적 "손으로 하는" 사용 방식을 요구합니다. 자동화가 부족하다는 것은 코드와 직접적으로 상호작용해야 한다는 의미이며, 이는 AI 출력 내용을 깊이 이해하고 싶은 사람에게는 오히려 훈련이 됩니다. 하지만 빈번한 복사 붙여넣기는 효율성 문제와 오류 위험을 가져옵니다. "원클릭 경험"을 추구하는 사람보다 "원래 AI 출력 코드"를 보고 싶은 분들에게 더 적합합니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:**
|
||||
|
||||
|
||||
### 4. Replit(Web-based)
|
||||
### 4. Replit (Web-based)
|
||||
|
||||
- **플랫폼 유형:** Web
|
||||
- **주요 특징과 워크플로:** Replit은 통합 온라인 개발 및 배포 환경입니다. 브라우저 안에서 코드를 작성하고, 프로그램을 실행하고, 온라인 접속 주소를 생성할 수 있습니다. 코딩을 시작하기 전에 명확한 실행 계획을 제시합니다. 또한 시각적 편집기도 제공하므로 미리보기 창에서 UI를 직접 수정할 수 있고, 소스 코드는 자동으로 동기화되어 업데이트됩니다. 이를 통해 AI 출력이 기대와 맞는지 수시로 확인할 수 있어 왕복 수정 횟수를 크게 줄일 수 있습니다.
|
||||
- **플랫폼 유형:** 웹
|
||||
- **주요 특징 및 워크플로:** Replit은 올인원 온라인 개발 및 배포 환경으로, 브라우저에서 코드를 작성하고, 프로그램을 실행하고, 온라인 접속 주소를 생성할 수 있습니다. 코딩을 시작하기 전에 명확한 실행 계획을 보여주며, 시각적 편집기도 제공하여 미리보기 창에서 UI를 직접 수정하면 소스 코드가 자동으로 동기화됩니다. 이렇게 하면 AI의 출력이 기대에 부합하는지 언제든 확인할 수 있어, 수정을 위한 반복 작업을 크게 줄일 수 있습니다.
|
||||
|
||||
|
||||
|
||||
- **적합한 사용자:** Replit은 초보자에게 매우 친절합니다. 코딩부터 배포까지의 전체 폐쇄 루프를 단순화하여 서버나 호스팅 서비스를 직접 따로 설정할 필요가 없습니다. 협업 기능도 강력해 학생들이 함께 프로젝트를 하거나 다른 사람에게 원격으로 코드 확인을 부탁하기에도 적합합니다.
|
||||
- **프롬프트 과정:** 구축 과정에서 AI가 처음부터 요구사항을 완전히 이해한 것은 아니었고, 중간에 약 3번의 반복을 거친 뒤에야 최종 출력이 이상적인 결과에 도달했습니다.
|
||||
- **적합한 사용자:** Replit은 초보자에게 매우 친근합니다. 코딩에서 배포까지의 완전한 루프를 단순화하여, 별도로 서버나 호스팅 서비스를 설정할 필요가 없습니다. 협업 기능도 강력하여, 학생들끼리 함께 프로젝트를 하거나 다른 사람에게 원격으로 코드를 확인해 달라고 요청하기에 적합합니다.
|
||||
- **프롬프트 과정:** 구축 과정에서 AI가 처음부터 요구사항을 완전히 이해한 것은 아니었고, 약 3라운드의 반복을 거쳐 최종 출력이 이상적인 효과에 도달했습니다.
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:**
|
||||
|
||||
|
||||
### 5. Minimax(Web-based)
|
||||
### 5. Minimax (Web-based)
|
||||
|
||||
- **플랫폼 유형:** Web
|
||||
- **주요 특징과 워크플로:** Minimax는 작업을 수행할 때 보통 시간이 꽤 걸립니다. 그 흐름은 대체로 AI가 자동으로 오류를 발견하고 수정하는 과정을 포함하므로 전체 과정이 느리거나 다소 번거롭게 느껴질 수 있습니다. 이 프로젝트를 예로 들면, Agent는 보통 먼저 상세 계획을 생성한 뒤 백엔드, 데이터베이스, 프론트엔드 로직을 단계적으로 구축합니다.
|
||||
- **적합한 사용자:** 자동으로 테스트를 실행하고 오류를 수정하기 때문에 시간과 Token 소비가 모두 큰 편입니다. 하지만 AI가 문제를 찾고 해결하는 과정을 분명히 볼 수 있으므로 학습 관점에서는 가치가 있습니다.
|
||||
- **플랫폼 유형:** 웹
|
||||
- **주요 특징 및 워크플로:** Minimax는 작업을 실행할 때 보통 시간이 많이 걸립니다. 그 과정에는 AI가 자동으로 오류를 발견하고 수정하는 것이 포함되므로, 전체 과정이 느리고 다소 번거로울 수 있습니다. 이 프로젝트를 예로 들면, Agent가 보통 먼저 상세한 계획을 생성한 다음, 단계별로 백엔드, 데이터베이스, 프론트엔드 로직을 구축합니다.
|
||||
- **적합한 사용자:** 자동으로 테스트를 실행하고 오류를 수정하므로, 시간과 Token 소모가 크지만, AI가 어떻게 문제를 파악하고 해결하는지 명확히 볼 수 있어 학습 관점에서 가치가 높습니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:** 무료 버전은 복잡한 프로젝트에서 처음부터 끝까지 순조롭게 실행되지 않을 가능성이 높으므로, 프로젝트를 완전히 구축하려면 유료 업그레이드를 더 추천합니다.
|
||||
- **가격:** 무료 버전은 복잡한 프로젝트에서 처음부터 끝까지 순조롭게 실행되기 어려울 가능성이 높으므로, 프로젝트를 완전히 구축하려면 유료 업그레이드를 권장합니다.
|
||||
|
||||
|
||||
### 6. Trae(IDE)
|
||||
### 6. Trae (IDE)
|
||||
|
||||
- **플랫폼 유형:** 데스크톱 애플리케이션(PC)
|
||||
- **주요 특징과 워크플로:** 데스크톱 애플리케이션인 Trae는 Web 도구와 비교했을 때 보통 성능과 응답 속도에서 더 유리합니다. 하지만 다운로드와 설치가 필요하므로 일부 사용자에게는 입문 장벽이 조금 높을 수 있습니다. 마찬가지로 로컬 환경이기 때문에 컴퓨터 설정과 의존성 환경의 차이에서 일정한 불확실성이 생깁니다. 장점은 Trae가 로컬에서 프로젝트 생성과 실행 설정을 도와주며, 사용자가 자신의 컴퓨터에서 바로 개발하고 디버깅할 수 있다는 점입니다.
|
||||
- **적합한 사용자:** 장기적으로 Vibe Coding 프로젝트를 진행할 계획이 있고, 전용 데스크톱 도구를 사용하고 싶은 사용자에게 더 적합합니다. “가끔 한 번 해보는” 정도를 원하는 학생에게는 가장 가벼운 선택이 아닐 수 있습니다.
|
||||
- **플랫폼 유형:** 데스크톱 앱 (PC)
|
||||
- **주요 특징 및 워크플로:** 데스크톱 앱으로서 Trae는 웹 도구보다 성능과 응답 속도에서 보통 더 유리합니다. 하지만 다운로드 및 설치가 필요하여 일부 사용자에게는 진입 장벽이 약간 높습니다. 마찬가지로 로컬 환경이므로, 컴퓨터 설정과 의존성 환경의 차이로 인해 어느 정도 불확실성이 발생할 수 있습니다. 장점은 Trae가 로컬에서 프로젝트 생성과 실행 설정을 도와주어, 로컬에서 직접 개발과 디버깅을 할 수 있다는 것입니다.
|
||||
- **적합한 사용자:** 장기간 Vibe Coding 프로젝트를 진행할 계획이 있고, 전용 데스크톱 도구를 사용하고자 하는 사용자에게 더 적합합니다. "가끔 놀아보고 싶은" 분들에게는 가장 가벼운 선택이 아닐 수 있습니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
|
||||
|
||||
- **가격:** 가격은 비교적 친근한 편이며, 무료 버전만으로도 품질이 괜찮은 작은 프로젝트를 완성하기에 충분합니다.
|
||||
- **가격:** 가격이 상대적으로 저렴하며, 무료 버전만으로도 품질이 꽤 좋은 소규모 프로젝트를 완성할 수 있습니다.
|
||||
|
||||
|
||||
### 7. V0(Web-based)
|
||||
### 7. V0 (Web-based)
|
||||
|
||||
- **플랫폼 유형:** Web
|
||||
- **주요 특징과 워크플로:** V0는 Vercel이 제공하는 React UI 컴포넌트 생성에 집중한 도구입니다. 고품질의 프로덕션 사용 가능한 인터페이스를 생성하는 데 뛰어납니다. 하지만 실제 사용 중에는 “코드 보기 화면을 찾기 어렵다”, “API Key를 어디에 설정해야 하는지 명확히 설명하지 않는다” 같은 문제가 나타납니다.
|
||||
- **적합한 사용자:** V0는 프론트엔드와 UI/UX 디자인에 집중하는 학생이나 디자이너에게 매우 적합합니다. 하지만 완전한 풀스택 솔루션은 아니므로 백엔드 로직과 API 통합을 구현하려면 여전히 다른 플랫폼을 사용해야 합니다. 따라서 목표가 “한 번에 완전한 애플리케이션 구축”이라면 최우선 선택은 아닐 수 있습니다.
|
||||
- **플랫폼 유형:** 웹
|
||||
- **주요 특징 및 워크플로:** V0은 Vercel에서 제공하는 React UI 컴포넌트 생성에 특화된 도구입니다. 고품질, 프로덕션 환경에서 사용 가능한 인터페이스 생성에 탁월합니다. 하지만 실제 사용에서 "코드 뷰를 찾기 어려움", "API Key를 어디에 설정해야 하는지 명확한 안내가 없음" 등의 문제가 발생할 수 있습니다.
|
||||
- **적합한 사용자:** V0은 프론트엔드와 UI/UX 디자인에 집중하는 학생이나 디자이너에게 매우 적합합니다. 하지만 완전한 풀스택 솔루션은 아니며, 백엔드 로직과 API 통합을 구현하려면 다른 플랫폼을 사용해야 합니다. 따라서 "원스톱으로 완전한 애플리케이션 구축"이 목표라면 최선의 첫 번째 선택이 아닐 수 있습니다.
|
||||
- **프롬프트 과정:**
|
||||
|
||||
|
||||
|
||||
|
||||
- **스네이크 게임 결과:**
|
||||
- **스네이크 게임 효과:**
|
||||
|
||||
- **가격:** 무료 사용자는 대략 4-5개의 간단한 프로젝트를 만들 수 있습니다.
|
||||
- **가격:** 무료 사용자는 약 4~5개의 간단한 프로젝트를 구축할 수 있습니다.
|
||||
|
||||
|
||||
## 3. 플랫폼 요약 비교
|
||||
|
||||
| **플랫폼** | **Review** | **Platform** | **Notes** |
|
||||
| ------------------------------------------ | ------------------------------------------------------------------------------- | ------------ | ------------------------------------------------------------------------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | AI 코딩 초보자에게 매우 친절하고, 시작이 쉽고 경험이 매끄러워 이상적인 입문 선택입니다. | Web-based | Supabase 같은 서비스 연결을 자동으로 완료하여 설정 비용을 줄입니다. |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | 개발 경험이 있는 사용자에게 적합하며, 생산성과 코드 품질을 크게 높입니다. | PC | 일정한 프로그래밍 기초가 필요하며, 로컬 환경에서 프로젝트 구조와 의존성을 스스로 이해해야 합니다. |
|
||||
| **[Z.ai](https://chat.z.ai/)** | 프로그래밍 기초가 있고 AI 출력 코드의 세부 사항을 직접 연구하고 싶은 사용자에게 더 적합합니다. | Web-based | 미리보기 창이 없어 결과 확인이 번거롭습니다. 코드를 수동으로 붙여 넣고, 폴더와 파일을 만들고, 서비스를 직접 실행해야 합니다. |
|
||||
| **[Replit](https://replit.com/~)** | 아이디어를 빠르게 접근 가능한 온라인 서비스로 바꾸고 싶은 사용자에게 추천합니다. | Web-based | 통합 온라인 개발과 배포를 제공하고, 협업과 시각적 편집기를 지원합니다. |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | AI가 자동으로 오류를 찾고 수정하는 전 과정을 보며 배우고 싶은 사람에게 적합하지만, 전체적으로 느리고 Token을 많이 씁니다. | Web-based | 전체 과정이 길고, AI가 여러 차례 자동으로 테스트를 실행하고 오류를 수정합니다. |
|
||||
| **[Trae](https://www.trae.ai/)** | 프로그래밍 경험이 있고 데스크톱 IDE + AI Agent 조합을 사용하고 싶은 사용자에게 효율을 높이는 강력한 도구입니다. | PC | 로컬 설치와 환경 설정이 필요하지만 성능이 더 좋고, 장기적인 Vibe Coding 프로젝트에 적합합니다. |
|
||||
| **[V0](https://v0.app/)** | React UI 시각 효과를 빠르게 만들고 싶은 비개발자에게 최적화되어 있으며, 프론트엔드 / 디자인 방향의 학생에게 적합합니다. | Web-based | React UI 생성에 집중하며, 백엔드와 전체 애플리케이션 구축은 다른 플랫폼과 함께 진행해야 합니다. |
|
||||
| **플랫폼** | **평가** | **플랫폼** | **비고** |
|
||||
| ------------------------------------------ | ------------------------------------------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | AI 프로그래밍 초보자에게 매우 친근하고, 시작이 간단하며 경험이 부드러워 이상적인 입문 선택입니다. | Web-based | Supabase 등 서비스 연결을 자동으로 완료하여 설정 비용을 줄입니다. |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | 이미 개발 경험이 있는 사용자에게 적합하며, 생산성과 코드 품질을 크게 향상시킵니다. | PC | 어느 정도의 프로그래밍 기반이 필요하며, 로컬 환경에서 프로젝트 구조와 의존성을 직접 이해해야 합니다. |
|
||||
| **[Z.ai](https://chat.z.ai/)** | 프로그래밍 기반이 있고, AI 출력 코드의 세부 사항을 직접 연구하고 싶은 사용자에게 더 적합합니다. | Web-based | 미리보기 창이 없어 결과 확인이 번거로움; 수동으로 코드를 붙여넣고, 폴더와 파일을 만들고 서비스를 수동으로 실행해야 합니다. |
|
||||
| **[Replit](https://replit.com/~)** | 아이디어를 빠르게 접근 가능한 온라인 서비스로 만들고 싶은 사용자에게 추천합니다. | Web-based | 올인원 온라인 개발 및 배포, 협업 지원 및 시각적 편집기 제공. |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | AI가 자동으로 오류를 찾고 수정하는 전체 과정을 보고 학습하고자 하는 분들에게 적합하지만, 전체적으로 느리고 Token 소모가 큽니다. | Web-based | 전체 과정이 길고, AI가 여러 번 자동으로 테스트를 실행하고 오류를 수정합니다. |
|
||||
| **[Trae](https://www.trae.ai/)** | 프로그래밍 경험이 있고, 데스크톱 IDE + AI Agent 조합을 사용하고자 하는 사용자에게 효율성을 높이는 강력한 도구입니다. | PC | 로컬 설치 및 환경 설정이 필요하지만, 성능이 더 좋고 장기 Vibe Coding 프로젝트에 적합합니다. |
|
||||
| **[V0](https://v0.app/)** | React UI 시각 효과를 빠르게 만들고 싶은 비개발자에게 최적화되어, 프론트엔드/디자인 지향 학생에게 적합합니다. | Web-based | React UI 생성에 특화되어 있으며, 백엔드와 완전한 애플리케이션 구축은 다른 플랫폼과의 협업이 필요합니다. |
|
||||
---
|
||||
title: 'Comparison Of 7 AI Coding Tools'
|
||||
description: 'A hands-on benchmark of popular Web Vibe Coding platforms using one unified task, covering beginner-friendliness, code control, and deployment.'
|
||||
---
|
||||
|
||||
+109
-105
@@ -2,7 +2,7 @@
|
||||
|
||||
## 이 장의 가이드
|
||||
|
||||
이 장에서는 디자인과 개발이 AI를 통해 어떻게 완벽하게 협업할 수 있는지 보여 줍니다. 당신은 제품 관리자의 역할을 맡아 “디자인 Agent”에게 로고 디자인, 색상 구성, 페이지 레이아웃을 지휘하고, 이어서 “코딩 Agent”와 협업해 시각 디자인을 실행 가능한 코드로 바꿉니다. 창의적인 구상부터 웹사이트 공개까지, 전 과정에서 AI가 개발을 지원하는 흐름을 경험하고 한 사람이 하나의 팀이 되는 방식을 체험합니다.
|
||||
이 장에서는 디자인과 개발이 AI를 통해 어떻게 완벽하게 협업할 수 있는지 보여 줍니다. 당신은 제품 관리자의 역할을 맡아 "디자인 Agent"에게 로고 디자인, 색상 구성, 페이지 레이아웃을 지휘하고, 이어서 "코딩 Agent"와 협업해 시각 디자인을 실행 가능한 코드로 바꿉니다. 창의적인 구상부터 웹사이트 공개까지, 전 과정에서 AI가 개발을 지원하는 흐름을 경험하고 한 사람이 하나의 팀이 되는 방식을 체험합니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -10,14 +10,14 @@
|
||||
|
||||
## 1. 튜토리얼 소개
|
||||
|
||||
AI 디자인 Agent와 코딩 Agent를 사용해 처음부터 완전한 웹사이트를 만들어 봅시다.
|
||||
AI 디자인 Agent와 코딩 Agent를 사용하여 제로에서 완전한 웹사이트를 구축해 봅시다.
|
||||
|
||||
- **디자인 Agent**: 로고, 웹페이지 레이아웃, 색상 구성, 기타 시각 요소를 만드는 역할을 합니다.
|
||||
- **코딩 Agent**: 프롬프트에서 제시한 요구사항과 레이아웃에 따라 HTML/CSS/JS 같은 실제 코드를 작성하고 실행 가능한 웹사이트를 구축합니다.
|
||||
- **디자인 Agent**: 로고 생성, 웹 페이지 레이아웃, 색상 구성 및 기타 시각적 요소의 생성을 담당합니다
|
||||
- **코딩 Agent**: 프롬프트에서 제시한 요구사항과 레이아웃에 따라 HTML/CSS/JS 등의 실제 코드를 작성하여 실행 가능한 웹사이트를 구축합니다
|
||||
|
||||
## 2. 디자인 Agent와 코딩 Agent
|
||||
|
||||
- **디자인 Agent**: 당신이 제공한 프롬프트에 따라 이미지, 페이지 모델, 디자인 스타일을 생성하는 AI입니다.
|
||||
- **디자인 Agent**: 제공한 프롬프트에 따라 이미지, 페이지 모형 또는 디자인 스타일을 생성하는 AI입니다.
|
||||
- Mastergo
|
||||
- Lovart
|
||||
- Figma MCP
|
||||
@@ -29,159 +29,159 @@ AI 디자인 Agent와 코딩 Agent를 사용해 처음부터 완전한 웹사이
|
||||
|
||||
---
|
||||
|
||||
# 2. 디자인 Agent로 로고 만들기
|
||||
# 2. 디자인 Agent를 사용하여 로고 만들기
|
||||
|
||||
## 1. 로고를 디자인할 때 고려해야 할 핵심 요소
|
||||
## 1. 로고 디자인 시 고려해야 할 핵심 요소
|
||||
|
||||
로고는 웹사이트의 첫인상을 결정하는 핵심 요소 중 하나입니다. AI 디자인 Agent로부터 만족스러운 결과를 얻으려면, 프롬프트에서 원하는 로고 유형을 명확하게 설명해야 합니다.
|
||||
로고는 웹사이트의 첫인상을 결정하는 핵심 요소 중 하나입니다. AI 디자인 Agent에서 만족스러운 결과를 얻으려면 프롬프트에서 원하는 로고 유형을 명확하게 설명해야 합니다.
|
||||
|
||||
1. **브랜드 이름 / 텍스트**
|
||||
|
||||
- 로고 안에 반드시 나타나야 하는 글자입니다. 예: 웹사이트 제목, 브랜드 이름 등.
|
||||
- 로고에 반드시 포함되어야 하는 텍스트(예: 웹사이트 제목, 브랜드 이름 등).
|
||||
|
||||
2. **스타일(정서 / 분위기)**
|
||||
2. **스타일(분위기 / 느낌)**
|
||||
|
||||
- 로고가 전달하기를 원하는 전체적인 느낌이나 분위기입니다.
|
||||
- _예시: 미니멀, 귀여움, 간결함, 모던, 레트로, 미래감 등._
|
||||
- 로고가 전달하고자 하는 전반적인 느낌이나 분위기.
|
||||
- _예시: 미니멀, 귀여움, 간결, 모던, 레트로, 미래지향적 등._
|
||||
|
||||
3. **색상 구성**(선택)
|
||||
|
||||
- 로고의 색상이 전체 웹사이트의 전반적인 톤과 어울리게 하는 것이 좋습니다.
|
||||
- 구체적인 16진수 색상 코드나 대략적인 색조(차가운 색, 따뜻한 색 등)를 지정할 수 있습니다.
|
||||
- 로고의 색상을 웹사이트 전체의 기본 톤과 일치시키는 것이 좋습니다.
|
||||
- 구체적인 hex 컬러 코드나 대략적인 색조(차가운 색, 따뜻한 색 등)를 지정할 수 있습니다.
|
||||
- _예시: **`#171721`**(검정), **`#FF7130`**(오렌지)._
|
||||
|
||||
4. **형태(모양 / 구조)**
|
||||
|
||||
- 로고에 특정한 모양이나 구도가 필요한지 명확히 합니다.
|
||||
- _예시: 원형 안에 텍스트 배치, 아이콘 + 텍스트 조합, 아이콘 중심 로고 등._
|
||||
- _예시: 원형 안에 텍스트, 아이콘 + 텍스트 조합, 아이콘 중심의 로고 등._
|
||||
|
||||
5. **아이콘 / 상징 요소**(선택)
|
||||
5. **아이콘 / 심볼 요소**(선택)
|
||||
|
||||
- 로고 안에 나타나기를 원하는 그래픽이나 상징입니다.
|
||||
- _예시: 책 아이콘, 번개 기호, AI와 관련된 그래픽, 추상 기하 도형 등._
|
||||
- 로고에 나타내고 싶은 그래픽이나 기호.
|
||||
- _예시: 책 아이콘, 번개 심볼, AI 관련 그래픽, 추상적인 기하학적 형태 등._
|
||||
|
||||
## 2. 로고 디자인 프롬프트 작성하기
|
||||
## 2. 로고 디자인 프롬프트 작성
|
||||
|
||||
**예시 프롬프트**
|
||||
**프롬프트 예시**
|
||||
|
||||
```
|
||||
"'My First Website'라는 브랜드 이름으로 미니멀 스타일의 로고를 디자인해 주세요.
|
||||
"미니멀 스타일의 로고를 디자인해 주세요. 브랜드 이름은 'My First Website'입니다.
|
||||
검정색(#171721)과 오렌지색(#FF7130)을 사용하고, 텍스트를 원형 안에 배치해 주세요."
|
||||
```
|
||||
|
||||
```
|
||||
"'AIID'를 브랜드명으로 하는 로고를 디자인해 주세요.
|
||||
전체 스타일은 미래적이고 깔끔하며 간결해야 하고, 주색은 파란색과 흰색입니다.
|
||||
AI를 상징하는 추상 그래픽과 텍스트를 결합하고, 투명 배경 PNG로 내보내 주세요."
|
||||
전체적인 스타일은 미래지향적이고 깔끔하게, 메인 컬러는 파란색과 흰색으로 해 주세요.
|
||||
AI를 상징하는 추상 그래픽과 텍스트를 결합하고, 투명 배경의 PNG로 내보내 주세요."
|
||||
```
|
||||
|
||||
## 3. Agent에게 디자인 요청하기
|
||||
|
||||
- 위 프롬프트 입력 → Agent가 생성한 여러 디자인 시안을 비교합니다.
|
||||
- 위 프롬프트 입력 -> Agent가 생성한 여러 디자인 시안 비교
|
||||
|
||||
|
||||
|
||||
## 4. 최종 로고 확정하기
|
||||
## 4. 최종 로고 확정
|
||||
|
||||
- 초안 중 가장 마음에 드는 버전을 선택해 다운로드합니다.
|
||||
- 시안 중 가장 마음에 드는 버전을 선택하여 다운로드합니다.
|
||||
|
||||
---
|
||||
|
||||
# 3. 웹사이트 구조 계획하기
|
||||
# 3. 웹사이트 구조 기획하기
|
||||
|
||||
## 1. 기본 섹션 이해하기
|
||||
|
||||
웹사이트를 실제로 만들기 전에 어떤 메뉴(섹션)를 포함할지 미리 계획하는 것은 매우 중요합니다. 메뉴 설계는 방문자에게 무엇을 보여 주고 싶은지, 그리고 방문자가 어떤 행동을 하길 원하는지에 따라 달라집니다.
|
||||
일반적으로 웹사이트는 보통 **Home / About / Contact** 같은 기본 섹션으로 구성됩니다.
|
||||
웹사이트 제작을 본격적으로 시작하기 전에 어떤 메뉴(섹션)를 포함할지 기획하는 것이 중요합니다. 메뉴 디자인은 방문자에게 무엇을 보여줄지, 그리고 어떤 행동을 유도할지에 따라 결정됩니다.
|
||||
일반적으로 웹사이트는 **Home / About / Contact** 등의 기본 섹션으로 구성됩니다.
|
||||
|
||||
## 2. 먼저 구조 스케치 직접 그리기(선택)
|
||||
## 2. 직접 구조 스케치하기(선택)
|
||||
|
||||
웹사이트의 목표에 따라 간단한 메뉴 구조를 대략 작성해 볼 수 있습니다.
|
||||
웹사이트의 목표에 따라 간단한 메뉴 구조를 먼저 작성해 볼 수 있습니다.
|
||||
|
||||
### 기본 메뉴
|
||||
|
||||
1. **Home**
|
||||
1. 방문자가 웹사이트에 들어온 뒤 처음 보게 되는 메인 페이지입니다.
|
||||
2. 보통 로고, 메인 비주얼 영역, 짧은 표어나 소개 문장을 포함합니다.
|
||||
1. 방문자가 웹사이트에 들어온 후 처음으로 보는 메인 페이지
|
||||
2. 보통 로고, 메인 비주얼 영역과 짧은 슬로건 또는 소개 포함
|
||||
2. **About**
|
||||
1. 당신이 누구인지, 또는 프로젝트 / 서비스의 목적을 소개합니다.
|
||||
2. 개인 포트폴리오: 자기소개 + 짧은 이력.
|
||||
3. 서비스형 웹사이트: 비전, 목표, 핵심 기능.
|
||||
1. 당신이 누구인지, 또는 프로젝트/서비스의 목적 소개
|
||||
2. 개인 포트폴리오: 자기소개 + 간단한 이력
|
||||
3. 서비스형 웹사이트: 비전, 목표 및 핵심 기능
|
||||
3. **Contact**
|
||||
1. 이메일, 전화번호, 소셜미디어 링크 같은 연락 방법입니다.
|
||||
2. 간단한 문의 양식을 추가할 수도 있습니다.
|
||||
1. 이메일, 전화번호, 소셜 미디어 링크 등 연락처 정보
|
||||
2. 간단한 문의 양식을 추가할 수도 있음
|
||||
|
||||
### 선택 메뉴
|
||||
|
||||
4. **Services / Projects**
|
||||
1. 제공하는 서비스 또는 프로젝트 / 포트폴리오를 보여 줍니다.
|
||||
2. 보통 목록이나 카드 형태로 표시합니다.
|
||||
1. 제공하는 서비스나 프로젝트/포트폴리오 전시
|
||||
2. 보통 목록이나 카드 형태로 전시
|
||||
|
||||
5. **Gallery**
|
||||
1. 이미지, 사진, 디자인 작업물을 보여 주는 데 사용합니다.
|
||||
1. 이미지, 사진 또는 디자인 작품 전시용
|
||||
|
||||
6. **Blog / News**
|
||||
1. 글, 소식, 로그를 게시하는 데 사용합니다.
|
||||
1. 글, 업데이트 또는 로그 게시용
|
||||
|
||||
7. **FAQ**
|
||||
1. 방문자가 자주 묻는 질문과 답변을 정리합니다.
|
||||
1. 방문자가 자주 묻는 질문과 답변 정리
|
||||
|
||||
## 3. 색상 구성 선택하기(선택)
|
||||
## 3. 색상 구성 선택(선택)
|
||||
|
||||
이미 로고가 있거나 특정 색상 조합을 사용해 웹사이트를 디자인하고 싶다면, 프롬프트에 사용할 색상 코드를 직접 써도 됩니다.
|
||||
이미 로고가 있거나, 특정 색상 조합으로 웹사이트를 디자인하고 싶다면 프롬프트에 사용할 색상 코드를 직접 적을 수 있습니다.
|
||||
|
||||
**예시:** `#171721, #872B97, #FF7130, #FF3C68`
|
||||
|
||||
아직 색상 구성이 떠오르지 않는다면, 색상 조합 사이트나 검색 키워드를 통해 영감을 얻을 수도 있습니다.
|
||||
당장 색상 구성이 떠오르지 않는다면, 색상 웹사이트나 키워드 검색으로 영감을 찾을 수 있습니다.
|
||||
|
||||
- **색상 조합 참고 사이트**
|
||||
- **색상 참고 웹사이트**
|
||||
- https://colorhunt.co/
|
||||
- https://coolors.co/
|
||||
|
||||
|
||||
|
||||
- **Google에서 키워드로 색상 조합 검색하기**
|
||||
- **Google에서 키워드로 색상 구성 검색**
|
||||
|
||||
|
||||
|
||||
## 4. 웹사이트 디자인 프롬프트 작성하기
|
||||
## 4. 웹사이트 디자인 프롬프트 작성
|
||||
|
||||
**예시 프롬프트**
|
||||
**프롬프트 예시**
|
||||
|
||||
```
|
||||
"Home, About, Contact 세 개 섹션으로 구성된 단일 페이지 웹사이트를 디자인해 주세요.
|
||||
색상 #171721, #FF7130, #FF3C68을 사용해 주세요.
|
||||
전체 스타일은 모던하고 간결해야 합니다."
|
||||
"Home, About, Contact 세 개의 섹션으로 구성된 싱글 페이지 웹사이트를 디자인해 주세요.
|
||||
색상은 #171721, #FF7130, #FF3C68을 사용해 주세요.
|
||||
전체적인 스타일은 모던하고 간결하게 해 주세요."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4. 디자인 Agent로 웹사이트 디자인하기
|
||||
|
||||
## 1. 프롬프트 입력 → 디자인 시안 생성
|
||||
## 1. 프롬프트 입력 -> 디자인 시안 생성
|
||||
|
||||
- 프롬프트에 계획한 구조와 선택한 색상 구성을 작성합니다.
|
||||
- 프롬프트에 기획한 구조와 선택한 색상을 작성합니다.
|
||||
|
||||
**Mastergo 프롬프트 예시**
|
||||
|
||||
|
||||
|
||||
## 2. 디자인 시안 검토하고 수정 의견 제시하기
|
||||
## 2. 디자인 시안 검토 및 수정 요청
|
||||
|
||||
자신의 필요에 따라 Agent에게 피드백을 줄 수 있습니다. 예:
|
||||
필요에 따라 Agent에게 피드백을 제출할 수 있습니다. 예를 들어:
|
||||
|
||||
- “너무 화려해요. 전체 스타일을 더 간결하게 바꿔 주세요.”
|
||||
- “다른 글꼴로 바꿔 주세요.”
|
||||
- “색상 조합을 조정해 주세요.”
|
||||
- “여기 이 블록을 삭제해 주세요.”
|
||||
- "너무 화려해요. 전체적인 스타일을 더 간결하게 바꿔 주세요."
|
||||
- "폰트를 바꿔 주세요."
|
||||
- "색상 조합을 조정해 주세요."
|
||||
- "여기 이 부분을 삭제해 주세요."
|
||||
|
||||
|
||||
|
||||
## 3. 최종 디자인 확정하기
|
||||
## 3. 최종 디자인 확정
|
||||
|
||||
디자인 시안을 여러 차례 수정해 만족한 뒤에는, 이 디자인을 코드로 변환하여 코딩 Agent가 이해하고 이어서 작업할 수 있게 합니다.
|
||||
디자인 시안을 여러 차례 수정하고 만족한 후에는 이 디자인을 코드로 변환하여 코딩 Agent가 이해하고 작업을 이어갈 수 있게 합니다.
|
||||
|
||||
디자인을 코드로 바꾸는 방식은 플랫폼마다 다르지만, 보통 디자인 플랫폼 안에서 특정 플러그인을 설치하고 사용하는 방식으로 진행합니다.
|
||||
디자인을 코드로 변환하는 방법은 플랫폼마다 다르지만, 보통 디자인 플랫폼에서 특정 플러그인을 설치하여 사용합니다.
|
||||
|
||||
**Mastergo 예시**
|
||||
|
||||
@@ -189,33 +189,33 @@ AI를 상징하는 추상 그래픽과 텍스트를 결합하고, 투명 배경
|
||||
|
||||
|
||||
|
||||
2. 디자인 페이지로 돌아가 **사각형 아이콘(플러그인)** 을 클릭합니다.
|
||||
2. 디자인 페이지로 돌아가서 **블록 아이콘(플러그인)**을 클릭합니다.
|
||||
|
||||
|
||||
|
||||
3. 코드로 변환하고 싶은 디자인 영역을 선택하고 **Generate** 버튼을 클릭해 코드를 생성합니다.
|
||||
3. 코드로 변환하고 싶은 디자인 영역을 선택하고 **Generate** 버튼을 클릭하여 코드를 생성합니다.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. 코딩 Agent로 웹사이트 만들기
|
||||
# 5. 코딩 Agent로 웹사이트 구축하기
|
||||
|
||||
## 1. HTML/CSS/JS의 기본 개념 이해하기
|
||||
|
||||
웹사이트는 본질적으로 세 가지 언어로 구성됩니다.
|
||||
웹사이트는 본질적으로 세 가지 언어로 구성됩니다:
|
||||
|
||||
- **HTML(HyperText Markup Language)** → 구조(뼈대)
|
||||
- **CSS(Cascading Style Sheets)** → 스타일(외관)
|
||||
- **JavaScript(JS)** → 기능(상호작용)
|
||||
- **HTML(HyperText Markup Language)** -> 구조(뼈대)
|
||||
- **CSS(Cascading Style Sheets)** -> 스타일(외관)
|
||||
- **JavaScript(JS)** -> 기능(상호작용)
|
||||
|
||||
이 세 가지가 함께 작동하여 우리가 보는 완전한 웹페이지를 구성합니다.
|
||||
|
||||
1. **🏗️ HTML(구조)**
|
||||
|
||||
- 페이지에서 “무엇을 보여 줄지” 정의합니다.
|
||||
- 텍스트, 이미지, 버튼, 링크 같은 요소를 배치하는 데 사용합니다.
|
||||
- 건축물의 **벽체와 프레임**과 비슷합니다.
|
||||
- 페이지에 "무엇을 표시할지"를 정의
|
||||
- 텍스트, 이미지, 버튼, 링크 등의 요소를 배치
|
||||
- 건물의 **벽과 뼈대**와 유사
|
||||
|
||||
**예시**
|
||||
|
||||
@@ -227,30 +227,30 @@ AI를 상징하는 추상 그래픽과 텍스트를 결합하고, 투명 배경
|
||||
|
||||
2. **🎨 CSS(스타일)**
|
||||
|
||||
- “내용을 어떻게 보여 줄지” 결정합니다.
|
||||
- 글자 크기, 색상, 간격, 배경, 버튼 모양 등을 제어합니다.
|
||||
- HTML에 “옷”과 시각 스타일을 입혀 줍니다.
|
||||
- "콘텐츠를 어떻게 표시할지"를 결정
|
||||
- 글자 크기, 색상, 간격, 배경, 버튼 모양 등을 제어
|
||||
- HTML에 "옷"과 시각적 스타일을 부여
|
||||
|
||||
**예시**
|
||||
|
||||
```css
|
||||
h1 {
|
||||
color: #FF7130; /* 글자 색상 */
|
||||
font-size: 36px; /* 글자 크기 */
|
||||
text-align: center; /* 가운데 정렬 */
|
||||
color: #FF7130; /* Text color */
|
||||
font-size: 36px; /* Font size */
|
||||
text-align: center; /* Center alignment */
|
||||
}
|
||||
|
||||
body {
|
||||
background-color: #171721; /* 배경 색상 */
|
||||
color: white; /* 기본 글자 색상 */
|
||||
background-color: #171721; /* Background color */
|
||||
color: white; /* Default text color */
|
||||
}
|
||||
```
|
||||
|
||||
3. **⚙️ JavaScript(JS)(기능)**
|
||||
|
||||
- 웹페이지가 사용자와 상호작용할 수 있게 합니다.
|
||||
- 버튼 클릭, 메뉴 펼치기, 이미지 캐러셀, 폼 제출 같은 동적 효과를 구현할 수 있습니다.
|
||||
- HTML/CSS가 정적인 뼈대와 외관이라면, JS는 웹페이지를 “살아 움직이게” 하는 **두뇌**입니다.
|
||||
- 웹페이지가 사용자와 상호작용할 수 있게 함
|
||||
- 버튼 클릭, 메뉴 펼치기, 이미지 슬라이드, 양식 제출 등의 동적 효과를 구현
|
||||
- HTML/CSS가 정적인 뼈대와 외관이라면, JS는 웹페이지를 "살아있게" 만드는 **두뇌**
|
||||
|
||||
**예시**
|
||||
|
||||
@@ -264,60 +264,60 @@ function showAlert() {
|
||||
<button onclick="showAlert()">Click me</button>
|
||||
```
|
||||
|
||||
## 2. 코딩 Agent가 코드를 생성하게 하기
|
||||
## 2. 코딩 Agent로 코드 생성하기
|
||||
|
||||
**예시 프롬프트**
|
||||
**프롬프트 예시**
|
||||
|
||||
```
|
||||
"Home, About, Contact 섹션을 포함한 단일 페이지 웹사이트의 HTML과 CSS를 작성해 주세요.
|
||||
색상 #171721, #FF7130, #FF3C68을 사용해 주세요.
|
||||
배경은 검정색, 글자는 흰색으로 해 주세요."
|
||||
"Home, About, Contact 섹션이 포함된 싱글 페이지 웹사이트의 HTML과 CSS를 작성해 주세요.
|
||||
색상은 #171721, #FF7130, #FF3C68을 사용해 주세요.
|
||||
배경은 검은색, 텍스트는 흰색으로 해 주세요."
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 3. 웹사이트 실행하기
|
||||
|
||||
초안 코드가 생성되면 Agent는 보통 프로젝트를 자동으로 시작하고, 생성된 웹사이트 페이지를 보여 줍니다.
|
||||
초안 코드가 생성되면, Agent가 보통 프로젝트를 자동으로 시작하고 완성된 웹사이트 페이지를 보여 줍니다.
|
||||
|
||||
Agent를 다시 시작했거나 웹사이트 화면이 나타나지 않는다면, 다음과 비슷한 프롬프트를 입력할 수 있습니다.
|
||||
Agent를 다시 시작했거나 웹사이트 화면이 나타나지 않는다면, 다음과 같은 프롬프트를 입력해 보세요:
|
||||
|
||||
```
|
||||
"Please activate the project"
|
||||
```
|
||||
|
||||
Agent가 프로젝트를 다시 시작하고 미리보기 페이지를 열어 현재 효과를 확인하기 쉽게 합니다.
|
||||
Agent가 프로젝트를 다시 시작하고 미리 보기 페이지를 열어, 현재 효과를 확인할 수 있게 해 줍니다.
|
||||
|
||||
## 4. 간단히 수정하기
|
||||
## 4. 간단한 수정하기
|
||||
|
||||
자연어로 초안을 계속 미세 조정할 수 있습니다. 예:
|
||||
자연어로 초안을 계속 미세 조정할 수 있습니다. 예를 들어:
|
||||
|
||||
- “버튼을 조금 더 크게 만들어 주세요.”
|
||||
- “글꼴을 조금 더 굵게 해 주세요.”
|
||||
- "버튼을 좀 더 크게 만들어 주세요."
|
||||
- "폰트를 좀 더 굵게 해 주세요."
|
||||
|
||||
|
||||
|
||||
## 5. 웹사이트 문구 내용 수정하기
|
||||
## 5. 웹사이트 카피 콘텐츠 수정하기
|
||||
|
||||
Agent가 생성한 첫 번째 웹사이트에는 보통 자동으로 생성된 자리표시자 텍스트가 포함됩니다. 실제 상황에 더 가깝게 만들려면, 미리 실제 내용을 준비한 다음 Agent에게 교체를 부탁할 수 있습니다.
|
||||
Agent가 생성한 초안 웹사이트에는 보통 자동으로 생성된 임시 텍스트가 포함되어 있습니다. 실제 시나리오에 더 가깝게 만들려면, 실제 콘텐츠를 미리 준비한 다음 Agent가 교체하도록 할 수 있습니다.
|
||||
|
||||
**적용 예시**: AIID 웹사이트의 About 페이지 업데이트
|
||||
|
||||
1. 먼저 About 페이지에 보여 주고 싶은 내용을 작성합니다. Agent가 이해하기 쉽도록 Markdown 형식으로 저장할 수 있습니다.
|
||||
1. About 페이지에 표시하고 싶은 콘텐츠를 먼저 작성합니다. Agent가 이해하기 쉽도록 Markdown 형식으로 저장할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
2. 그런 다음 대화에서 Agent에게 해당 파일의 내용을 지정한 페이지에 적용하라고 말합니다.
|
||||
2. 대화에서 Agent에게 해당 파일의 콘텐츠를 지정된 페이지에 적용하라고 알려 줍니다.
|
||||
|
||||
|
||||
|
||||
3. 내용이 적용된 업데이트 버전을 확인합니다.
|
||||
3. 콘텐츠 적용 후 업데이트된 버전을 확인합니다.
|
||||
|
||||
|
||||
|
||||
## 6. 이미지 삽입하기
|
||||
|
||||
특정 이미지(예: 로고, 배경 이미지 등)를 추가하고 싶다면, 먼저 이미지를 프로젝트 폴더에 업로드한 뒤 프롬프트에서 이 이미지를 페이지의 어느 위치에 사용할지 설명할 수 있습니다.
|
||||
특정 이미지(예: 로고, 배경 이미지 등)를 추가하고 싶다면, 먼저 이미지를 프로젝트 폴더에 업로드한 다음 프롬프트에서 페이지의 어느 위치에 이 이미지를 사용할지 설명합니다.
|
||||
|
||||
- **예시:**
|
||||
|
||||
@@ -331,9 +331,9 @@ Agent가 생성한 첫 번째 웹사이트에는 보통 자동으로 생성된
|
||||
|
||||
# 6. 디자인과 코드 통합하기
|
||||
|
||||
## 1. 디자인 파일과 웹사이트 코드 통합하기(선택)
|
||||
## 1. 디자인 파일과 웹사이트 코드 통합(선택)
|
||||
|
||||
디자인 Agent에서 코드 파일을 다운로드했다면, 해당 파일들을 현재 프로젝트 디렉터리로 옮긴 다음 코딩 Agent에게 이 디자인 코드와 기존 프로젝트를 합쳐 달라고 요청할 수 있습니다.
|
||||
디자인 Agent에서 코드 파일을 다운로드한 후, 이를 현재 프로젝트 디렉터리로 이동한 다음 코딩 Agent에게 이 디자인 코드를 기존 프로젝트와 병합하도록 요청할 수 있습니다.
|
||||
|
||||
- **예시:**
|
||||
|
||||
@@ -342,3 +342,7 @@ Agent가 생성한 첫 번째 웹사이트에는 보통 자동으로 생성된
|
||||
- **결과:**
|
||||
|
||||
|
||||
---
|
||||
title: 'Build A Website With Design + Coding Agents'
|
||||
description: 'From idea to launch: coordinate a design agent to produce visuals, then use a coding agent to turn it into a working website with a reusable workflow.'
|
||||
---
|
||||
|
||||
@@ -9,326 +9,317 @@ const duration = '약 <strong>30분</strong>'
|
||||
|
||||
# 코드를 쓰다가 오류를 만나면 어떻게 해야 할까
|
||||
|
||||
## 본 장 안내
|
||||
## 이 장의 가이드
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['디버깅 기법', 'AI 협업', '문제 조사', '개발자 도구']" coreOutput="표준화된 오류 조사 흐름 한 세트" expectedOutput="흔한 오류의 90%를 독립적으로 해결할 수 있음">
|
||||
<ChapterIntroduction :duration="duration" :tags="['디버깅 팁', 'AI 협업', '문제 파악', '개발자 도구']" coreOutput="표준화된 오류 파악 흐름" expectedOutput="일반적인 오류의 90%를 독립적으로 해결 가능">
|
||||
|
||||
AI 시대에는 오류를 조사하는 방식이 이미 바뀌었습니다.
|
||||
AI 시대에 오류를 파악하는 방식이 바뀌었습니다.
|
||||
|
||||
모든 오류 유형을 외울 필요도 없고, 디버깅 전문가가 될 필요도 없으며, 심지어 오류가 무슨 뜻인지 이해하지 못해도 됩니다.
|
||||
모든 오류 유형을 외울 필요도 없고, 디버깅 전문가가 될 필요도 없으며, 오류가 무슨 뜻인지 이해할 필요도 없습니다.
|
||||
|
||||
<strong>딱 한 가지, AI에게 어떻게 물어볼지만 배우면 됩니다.</strong>
|
||||
<strong>배워야 할 것은 단 하나: AI에게 어떻게 물어볼 것인가입니다.</strong>
|
||||
|
||||
이 장은 <strong>간단한 단계에서 고급 단계로 이어지는</strong> 조사 흐름을 알려 줍니다.
|
||||
이 장에서는 <strong>간단한 것부터 심화까지</strong>의 파악 흐름을 알려드립니다:
|
||||
|
||||
1. <strong>1단계: 바로 묻기</strong>: 현상 설명 + 스크린샷, 한 문장 질문
|
||||
2. <strong>2단계: 정보 보충</strong>: 해결되지 않으면 F12를 열어 핵심 정보 보충
|
||||
1. <strong>첫 번째 단계: 바로 물어보기</strong>: 현상 설명 + 스크린샷, 한마디로 질문
|
||||
2. <strong>두 번째 단계: 정보 보충</strong>: 해결되지 않으면 F12를 열어 핵심 정보 보충
|
||||
|
||||
이 흐름을 익히면 <strong>오류의 90%를 스스로 해결할 수 있습니다</strong>.
|
||||
이 흐름을 마스터하면 <strong>90%의 오류를 스스로 해결</strong>할 수 있습니다.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 설명
|
||||
이 장의 모든 방법은 Cursor/Trae/Claude 같은 AI IDE의 실제 사용 경험에 기반하며, 일상 개발에 바로 적용할 수 있습니다.
|
||||
이 장의 모든 방법은 Cursor/Trae/Claude 등 AI IDE의 실제 사용 경험을 기반으로 하며, 일상적인 개발에 바로 적용할 수 있습니다.
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '바로 질문', description: '현상 설명 + 스크린샷' },
|
||||
{ title: '정보 보충', description: 'F12를 열어 문제 위치 확인' },
|
||||
{ title: '정보 보충', description: 'F12를 열어 문제 위치 파악' },
|
||||
{ title: '반복 해결', description: '문제가 해결될 때까지' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 핵심 마음가짐: 스크린샷으로 AI에게 묻기
|
||||
## 1. 핵심 비법: 스크린샷으로 AI에게 물어보기
|
||||
|
||||
::: warning 이 장이 왜 중요한가요?
|
||||
::: warning 왜 이 장이 중요할까요?
|
||||
|
||||
많은 초보자가 오류를 만났을 때 가장 먼저 보이는 반응은 다음과 같습니다.
|
||||
많은 초보자가 오류를 만났을 때 첫 번째 반응은:
|
||||
- 당황해서 코드를 마구 고치기
|
||||
- 30분 동안 "xxx 오류 해결 방법" 검색하기
|
||||
- 스스로 오류의 의미를 이해하려고 시도하기
|
||||
- 혼자 밤새 디버깅하기
|
||||
|
||||
- 당황해서 코드를 아무렇게나 고치기 시작한다.
|
||||
- "xxx 오류 해결 방법"을 검색하는 데 30분을 쓴다.
|
||||
- 오류가 무슨 뜻인지 스스로 이해하려고 한다.
|
||||
- 혼자 밤늦게까지 debug한다.
|
||||
<strong>이런 방식은 모두 시간 낭비입니다.</strong>
|
||||
|
||||
<strong>이것들은 모두 시간을 낭비하는 방식입니다.</strong>
|
||||
|
||||
AI 시대에 디버깅은 매우 단순한 일이 되었습니다.
|
||||
AI 시대에는 디버깅이 아주 간단해졌습니다:
|
||||
|
||||
```
|
||||
오류를 본다 → 스크린샷을 찍는다 → AI에게 묻는다 → AI가 말한 대로 한다
|
||||
오류 발견 -> 스크린샷 -> AI에게 물어보기 -> AI가 알려준 대로 하기
|
||||
```
|
||||
|
||||
오류를 이해할 필요도, 디버깅을 할 줄 알 필요도, 심지어 문제가 어디 있는지 알 필요도 없습니다.
|
||||
오류를 이해할 필요도 없고, 디버깅을 할 줄 알 필요도 없으며, 문제가 어디 있는지 알 필요도 없습니다.
|
||||
|
||||
<strong>어떻게 물어볼지만 배우면 됩니다.</strong>
|
||||
<strong>배워야 할 것은 어떻게 물어볼 것인가뿐입니다.</strong>
|
||||
|
||||
:::
|
||||
|
||||
### 1.1 가장 간단한 질문 방식
|
||||
|
||||
복잡한 템플릿이 필요 없습니다. 두 방식 중 하나를 고르면 됩니다.
|
||||
복잡한 템플릿은 필요 없고, 두 가지 방식 중 하나를 선택하세요:
|
||||
|
||||
**방식 1: 현상 설명**
|
||||
|
||||
형식: 방금 무엇을 했고, 지금 무엇이 나타났는지
|
||||
|
||||
```
|
||||
방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 비어 있어요. 어떻게 해야 하나요?
|
||||
방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 변했어요. 어떻게 해야 하나요?
|
||||
```
|
||||
|
||||
**방식 2: 스크린샷**
|
||||
|
||||
현재 페이지나 오류 정보를 바로 캡처합니다.
|
||||
현재 페이지나 오류 메시지를 바로 스크린샷
|
||||
|
||||
```
|
||||
[스크린샷]
|
||||
|
||||
이 오류는 어떻게 해결하나요?
|
||||
이 오류 어떻게 해결하나요?
|
||||
```
|
||||
|
||||
**가장 좋은 방식: 설명 + 스크린샷**
|
||||
|
||||
```
|
||||
방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 비어 있어요.
|
||||
방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 변했어요.
|
||||
|
||||
[스크린샷]
|
||||
|
||||
어떻게 해야 하나요?
|
||||
```
|
||||
|
||||
**기억하세요: 맥락을 분명히 설명하고 스크린샷을 더하면, AI가 더 빨리 문제를 해결해 줄 수 있습니다.**
|
||||
**기억하세요: 맥락을 명확하게 설명하고 스크린샷을 추가하면, AI가 더 빠르게 문제를 해결할 수 있습니다.**
|
||||
|
||||
### 1.2 문제를 어떻게 명확히 말할까
|
||||
### 1.2 문제를 명확하게 설명하는 법
|
||||
|
||||
많은 초보자가 질문해야 한다는 것은 알지만 어떻게 말해야 할지 모릅니다. 사실 세 가지만 분명히 말하면 됩니다.
|
||||
많은 초보자가 질문을 해야 한다는 것은 알지만, 어떻게 말해야 할지 모릅니다. 사실 세 가지만 명확하게 말하면 됩니다:
|
||||
|
||||
**1. 방금 무엇을 했는가**
|
||||
**1. 방금 무엇을 했는지**
|
||||
|
||||
```
|
||||
방금 저장 버튼을 클릭했어요.
|
||||
방금 로그인 페이지 코드를 수정했어요.
|
||||
방금 페이지를 새로고침했어요.
|
||||
방금 저장 버튼을 클릭했어요
|
||||
방금 로그인 페이지 코드를 수정했어요
|
||||
방금 페이지를 새로고침했어요
|
||||
```
|
||||
|
||||
**2. 지금 무엇을 보았는가**
|
||||
**2. 지금 무엇이 보이는지**
|
||||
|
||||
```
|
||||
지금 페이지가 비어 있어요.
|
||||
지금 버튼을 눌러도 반응이 없어요.
|
||||
지금 오류 메시지가 표시돼요.
|
||||
지금 페이지가 비어 있어요
|
||||
지금 버튼을 눌러도 반응이 없어요
|
||||
지금 오류 메시지가 표시돼요
|
||||
```
|
||||
|
||||
**3. 어떤 효과를 원했는가**
|
||||
**3. 어떤 효과를 원하는지**
|
||||
|
||||
```
|
||||
데이터가 성공적으로 저장되게 하고 싶어요.
|
||||
페이지가 정상적으로 표시되게 하고 싶어요.
|
||||
버튼을 누르면 알림이 뜨게 하고 싶어요.
|
||||
데이터가 성공적으로 저장되길 원해요
|
||||
페이지가 정상적으로 표시되길 원해요
|
||||
버튼을 클릭하면 알림이 뜨게 하고 싶어요
|
||||
```
|
||||
|
||||
**완전한 예시:**
|
||||
|
||||
```
|
||||
방금 저장 버튼을 클릭했는데, 지금 페이지에 "저장 실패" 오류가 표시돼요.
|
||||
방금 저장 버튼을 클릭했는데, 페이지에 "저장 실패"라는 오류가 표시돼요.
|
||||
|
||||
[스크린샷]
|
||||
|
||||
폼 데이터가 데이터베이스에 성공적으로 저장되게 하고 싶은데, 어떻게 해야 하나요?
|
||||
양식 데이터를 데이터베이스에 성공적으로 저장하고 싶은데, 어떻게 해야 하나요?
|
||||
```
|
||||
|
||||
**핵심 원칙:**
|
||||
- 전문 용어 없이 일상적인 말로 설명하기
|
||||
- 시간 순서대로 말하기: 먼저 무엇을 했고, 그 다음 무슨 일이 일어났는지
|
||||
- 기대하는 바를 말하여 AI가 원하는 것을 알 수 있게 하기
|
||||
|
||||
- 전문 용어를 쓰지 말고 일상어로 설명합니다.
|
||||
- 시간 순서대로 말합니다. 먼저 무엇을 했고, 그다음 무엇이 일어났는지.
|
||||
- 기대한 결과를 말해 AI가 당신이 원하는 바를 알게 합니다.
|
||||
## 2. 첫 번째 단계: 현상을 바로 설명하고 질문하기
|
||||
|
||||
## 2. 1단계: 현상을 바로 설명하며 질문하기
|
||||
문제를 만났을 때, <strong>F12를 서둘러 열지 마세요</strong>. 먼저 현상을 설명하고, 현재 페이지를 스크린샷하여 AI에게 보여주세요.
|
||||
|
||||
문제를 만났을 때 <strong>급하게 F12를 열지 마세요</strong>. 먼저 현상을 직접 설명하고, 현재 화면을 캡처해 AI에게 던져 보세요.
|
||||
많은 경우 AI가 스크린샷만 보고도 바로 해결책을 줄 수 있습니다.
|
||||
|
||||
많은 경우 AI는 스크린샷만 보고도 바로 해결 방안을 줄 수 있습니다.
|
||||
### 2.1 일반적인 현상 설명 방법
|
||||
|
||||
### 2.1 흔한 현상은 어떻게 설명할까
|
||||
|
||||
::: tip 바로 설명하면 됩니다
|
||||
|
||||
**페이지가 하얗게 비어 있음**
|
||||
::: tip 그냥 설명하면 됩니다
|
||||
|
||||
**페이지가 하얗게 변함**
|
||||
```
|
||||
페이지를 열면 비어 있어요. 어떻게 해야 하나요?
|
||||
페이지를 열었는데 비어 있어요. 어떻게 해야 하나요?
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
**버튼을 클릭해도 반응이 없음**
|
||||
|
||||
**버튼 클릭해도 반응 없음**
|
||||
```
|
||||
이 버튼을 클릭해도 반응이 없어요. 한번 봐 주세요.
|
||||
이 버튼을 클릭해도 반응이 없어요. 확인해 주세요.
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
**데이터가 저장되지 않음**
|
||||
|
||||
```
|
||||
저장을 눌렀는데 데이터가 저장되지 않아요. 어떻게 해야 하나요?
|
||||
저장을 눌렀는데 데이터가 저장되지 않았어요. 어떻게 해야 하나요?
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
**스타일 표시가 이상함**
|
||||
|
||||
**스타일이 올바르지 않음**
|
||||
```
|
||||
이 버튼 위치가 어긋났어요. 어떻게 조정하나요?
|
||||
이 버튼의 위치가 어긋났어요. 어떻게 조정하나요?
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
**인터페이스 오류**
|
||||
|
||||
**API 오류**
|
||||
```
|
||||
인터페이스 호출에서 오류가 났어요. 봐 주세요.
|
||||
API를 호출했는데 오류가 발생했어요. 확인해 주세요.
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 2.2 AI가 바로 해결했다면
|
||||
### 2.2 AI가 바로 해결한 경우
|
||||
|
||||
축하합니다. 문제가 해결되었습니다. AI가 말한 대로 수정하면 됩니다.
|
||||
축하합니다, 문제가 해결되었습니다! AI가 알려준 대로 수정하면 됩니다.
|
||||
|
||||
### 2.3 AI가 "더 많은 정보가 필요하다"고 말한다면
|
||||
### 2.3 AI가 "추가 정보가 필요하다"고 한 경우
|
||||
|
||||
그때 F12를 열어 핵심 정보를 보충하면 됩니다. 아래를 계속 보세요.
|
||||
이때 비로소 F12를 열어 핵심 정보를 보충해야 합니다. 아래를 참고하세요.
|
||||
|
||||
## 3. 2단계: 핵심 정보 보충하기
|
||||
## 3. 두 번째 단계: 핵심 정보 보충
|
||||
|
||||
AI가 더 많은 정보가 필요하다고 말할 때는 문제 유형에 따라 F12를 열고 해당 내용을 캡처합니다.
|
||||
AI가 추가 정보가 필요하다고 하면, 문제 유형에 따라 F12를 열어 해당 내용을 스크린샷합니다.
|
||||
|
||||
### 3.1 언제 정보를 보충해야 할까
|
||||
### 3.1 언제 추가 정보가 필요한가
|
||||
|
||||
AI가 이렇게 답할 수 있습니다.
|
||||
|
||||
- "Console을 열어 오류가 있는지 확인해 주세요."
|
||||
- "Network 패널을 캡처해 주세요."
|
||||
- "구체적인 오류 정보가 필요합니다."
|
||||
AI가 이렇게 답변할 수 있습니다:
|
||||
- "Console을 열어 오류가 있는지 확인해 주세요"
|
||||
- "Network 패널을 스크린샷해서 보여 주세요"
|
||||
- "구체적인 오류 메시지를 봐야 합니다"
|
||||
|
||||
이때 아래 안내에 따라 스크린샷을 보충합니다.
|
||||
|
||||
### 3.2 Console 정보 보충하기(페이지 빈 화면/오류)
|
||||
### 3.2 Console 정보 보충 (페이지가 하얗게 변함/오류 발생)
|
||||
|
||||
::: tip 작업 단계
|
||||
::: tip 조작 단계
|
||||
|
||||
**1단계: F12를 눌러 개발자 도구 열기**
|
||||
**첫 번째: F12를 눌러 개발자 도구 열기**
|
||||
|
||||
Mac에서는 `Cmd+Option+I`를 누르거나, 페이지에서 우클릭 후 "검사"를 선택합니다.
|
||||
Mac은 `Cmd+Option+I`, 또는 페이지를 우클릭하고 "검사"를 선택하세요.
|
||||
|
||||
**2단계: Console 탭으로 전환**
|
||||
**두 번째: Console 탭으로 전환**
|
||||
|
||||
**3단계: 빨간색 오류 정보를 캡처**
|
||||
**세 번째: 빨간색 오류 메시지 스크린샷**
|
||||
|
||||
**4단계: AI에게 보내기**
|
||||
**네 번째: AI에게 보내기**
|
||||
|
||||
```
|
||||
Console 오류는 다음과 같습니다.
|
||||
Console 오류는 다음과 같습니다:
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.3 Network 정보 보충하기(데이터 문제/API 오류)
|
||||
### 3.3 Network 정보 보충 (데이터 문제/API 오류)
|
||||
|
||||
::: tip 작업 단계
|
||||
::: tip 조작 단계
|
||||
|
||||
**1단계: F12를 눌러 개발자 도구 열기**
|
||||
**첫 번째: F12를 눌러 개발자 도구 열기**
|
||||
|
||||
**2단계: Network 탭으로 전환**
|
||||
**두 번째: Network 탭으로 전환**
|
||||
|
||||
**3단계: 작업을 다시 한 번 수행**(저장 클릭/페이지 새로고침)
|
||||
**세 번째: 다시 한번 조작하기** (저장 클릭/페이지 새로고침)
|
||||
|
||||
**4단계: 해당 요청을 찾아 캡처**
|
||||
**네 번째: 해당 요청을 찾아 스크린샷**
|
||||
|
||||
- URL과 상태 코드 보기
|
||||
- Payload(전송한 파라미터) 보기
|
||||
- Response(반환 결과) 보기
|
||||
- URL과 상태 코드 확인
|
||||
- Payload(전달한 매개변수) 확인
|
||||
- Response(반환 결과) 확인
|
||||
|
||||
**5단계: AI에게 보내기**
|
||||
**다섯 번째: AI에게 보내기**
|
||||
|
||||
```
|
||||
Network 정보는 다음과 같습니다.
|
||||
Network 정보는 다음과 같습니다:
|
||||
|
||||
요청: [스크린샷1]
|
||||
파라미터: [스크린샷2]
|
||||
매개변수: [스크린샷2]
|
||||
반환: [스크린샷3]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.4 Elements 정보 보충하기(스타일 문제)
|
||||
### 3.4 Elements 정보 보충 (스타일 문제)
|
||||
|
||||
::: tip 작업 단계
|
||||
::: tip 조작 단계
|
||||
|
||||
**1단계: 요소 우클릭 → "검사"**
|
||||
**첫 번째: 요소를 우클릭 -> "검사"**
|
||||
|
||||
개발자 도구가 해당 요소로 자동 이동합니다.
|
||||
개발자 도구가 자동으로 해당 요소로 이동합니다.
|
||||
|
||||
**2단계: Styles 패널 캡처**
|
||||
**두 번째: Styles 패널 스크린샷**
|
||||
|
||||
**3단계: AI에게 보내기**
|
||||
**세 번째: AI에게 보내기**
|
||||
|
||||
```
|
||||
요소 스타일은 다음과 같습니다.
|
||||
요소 스타일은 다음과 같습니다:
|
||||
|
||||
[스크린샷]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
## 4. 3단계: 해결될 때까지 반복하기
|
||||
## 4. 세 번째 단계: 해결될 때까지 반복
|
||||
|
||||
### 4.1 비효율적인 방식
|
||||
### 4.1 비효율적인 방법
|
||||
|
||||
이런 방식은 시간을 낭비합니다.
|
||||
이런 방법은 시간을 낭비합니다:
|
||||
|
||||
오류를 보자마자 당황해서 코드를 마구 고치기
|
||||
오류 해결책을 검색하는 데 30분 쓰기
|
||||
모든 오류의 뜻을 스스로 이해하려 하기
|
||||
혼자 밤늦게까지 debug하기
|
||||
오류를 보고 당황해서 코드를 마구 고치기
|
||||
30분 동안 오류 해결 방법 검색하기
|
||||
모든 오류의 의미를 스스로 이해하려고 시도하기
|
||||
혼자 밤새 디버깅하기
|
||||
|
||||
### 4.2 효율적인 방식
|
||||
### 4.2 효율적인 방법
|
||||
|
||||
이 흐름을 따르세요.
|
||||
이 흐름에 따라 진행하세요:
|
||||
|
||||
먼저 현상 설명과 스크린샷으로 바로 질문하기
|
||||
AI가 더 많은 정보가 필요하다고 말할 때만 F12를 열어 보충하기
|
||||
먼저 현상을 설명하고 스크린샷으로 질문하기
|
||||
AI가 추가 정보가 필요하다고 하면, F12를 열어 보충하기
|
||||
제안에 따라 코드 수정하기
|
||||
수정 후 테스트하고, 문제가 남아 있으면 계속 캡처해 질문하기
|
||||
수정 후 테스트하고, 문제가 남아 있으면 계속 스크린샷으로 질문하기
|
||||
|
||||
## 5. 정리: 전체 흐름
|
||||
## 5. 요약: 전체 흐름
|
||||
|
||||
```
|
||||
문제 발생
|
||||
↓
|
||||
현상 설명 + 스크린샷
|
||||
↓
|
||||
AI에게 던지기: "어떻게 해야 하나요?"
|
||||
AI에게 보내기: "어떻게 해야 하나요?"
|
||||
↓
|
||||
AI가 바로 해결?
|
||||
↓ 예
|
||||
AI가 말한 대로 하기
|
||||
AI가 알려준 대로 하기
|
||||
↓
|
||||
해결됐는지 테스트
|
||||
해결되었는지 테스트
|
||||
↓
|
||||
↓ 아니오 / AI가 더 많은 정보 필요
|
||||
↓ 아니오 / AI가 추가 정보 필요
|
||||
F12를 열어 핵심 정보 보충
|
||||
↓
|
||||
다시 AI에게 보내기
|
||||
↓
|
||||
해결될 때까지 반복
|
||||
```
|
||||
|
||||
|
||||
@@ -11,535 +11,534 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## 본 장 안내
|
||||
## 이 장의 가이드
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', '디자인 사고', '요구사항 분석', '솔루션 설계']"
|
||||
coreOutput="더 명확한 문제 정의 1개와 더 합리적인 검증 진입점 1개"
|
||||
expectedOutput="처음부터 서둘러 프로토타입을 그리지 않고, 먼저 문제를 명확히 생각한 뒤 솔루션을 비교할 수 있게 됨"
|
||||
expectedOutput="처음부터 서둘러 프로토타입을 그리지 않고, 먼저 문제를 명확히 생각한 후 솔루션을 비교하게 됩니다"
|
||||
>
|
||||
|
||||
많은 사람이 처음 제품을 만들 때 가장 쉽게 빠지는 함정은 "노력이 부족하다"가 아니라 너무 빨리 해결책으로 들어가는 것입니다.
|
||||
많은 사람이 처음 제품을 만들 때 가장 많이 빠지는 함정은 "노력이 부족해서"가 아니라 너무 빨리 솔루션에 들어간다는 것입니다.
|
||||
|
||||
머릿속에 방향이 하나 떠오르자마자 페이지를 어떻게 그릴지, 버튼을 어디에 둘지, AI를 붙일지, 로그인/회원가입을 만들지, 어떤 도구로 프로토타입을 그릴지 생각하기 시작합니다. 한참 바쁘게 움직인 뒤에야 가장 근본적인 문제가 전혀 정리되지 않았다는 것을 깨닫습니다. 사용자가 정말 이 고통을 가지고 있는가? 지금 이 문제를 해결할 가치가 있는가? 프로젝트를 밀고 있다고 생각하지만, 사실은 잘못된 방향으로 열심히 가속하고 있을 뿐입니다.
|
||||
머릿속에 방향이 떠오르자마자, 페이지를 어떻게 그릴지, 버튼을 어디에 둘지, AI를 연동할지 말지, 로그인/회원가입을 만들지 말지, 프로토타입은 어떤 도구로 그릴지 생각하기 시작합니다. 한참을 바쁘게 돌아간 후에야, 가장 근본적인 문제를 전혀 생각하지 않았다는 것을 깨닫습니다: 사용자가 정말로 이 페인포인트를 가지고 있는지? 이 문제가 지금 해결할 가치가 있는지? 프로젝트를 진행하고 있다고 생각했지만, 사실은 잘못된 방향에서 열심히 가속하고 있었을 뿐입니다.
|
||||
|
||||
Double Diamond 모델은 바로 이런 상황을 피하기 위해 쓰입니다.
|
||||
Double Diamond(더블 다이아몬드) 모델은 바로 이런 상황을 피하기 위한 것입니다.
|
||||
|
||||
가장 가치 있는 알림은 이것입니다. **"올바른 일을 하는 것"과 "그 일을 제대로 하는 것"은 완전히 다른 두 단계입니다.** 문제가 명확해지기도 전에 프로토타입으로 달려가면, 보통 잘못된 방향을 더 완전하게 만들 뿐입니다.
|
||||
이것이 가장 가치 있는 교훈은: **"올바른 일을 하는 것"과 "일을 올바르게 하는 것"은 완전히 다른 단계라는 것입니다.** 문제를 아직 명확히 파악하지 못한 상태에서 서둘러 프로토타입을 만들면, 보통 잘못된 방향을 더 완성도 있게 만들 뿐입니다.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 최소 SOP
|
||||
**목적**: 읽고 나면 제품을 만들 때 언제 먼저 문제를 생각해야 하고, 언제부터 솔루션과 프로토타입을 생각해야 하는지 더 명확해집니다. 처음부터 잘못된 방향을 매우 성실하게 만드는 일을 피합니다.
|
||||
**목적**: 이 글을 읽은 후, 제품을 만들 때 언제 먼저 문제를 생각해야 하고, 언제 솔루션과 프로토타입을 생각하기 시작해야 하는지 더 명확해져서, 처음부터 잘못된 방향에서 열심히 하는 일을 피할 수 있습니다.
|
||||
|
||||
**행동 항목**: `Discover → Define → Develop → Deliver` 네 단계를 따라 내려가며, 각 단계에서는 현재 단계에서 해야 할 일만 합니다.
|
||||
**실행 항목**: `Discover -> Define -> Develop -> Deliver` 4단계로 진행하며, 각 단계에서 현재 단계에 해야 할 일만 합니다.
|
||||
|
||||
**결과**: 더 명확한 문제 정의, 비교 가능한 몇 가지 솔루션, 검증 가능한 최소 버전을 얻게 됩니다.
|
||||
**결과**: 더 명확한 문제 정의, 비교 가능한 여러 솔루션, 그리고 검증 가능한 최소 버전을 얻게 됩니다.
|
||||
|
||||
**키워드 이동**: [Double Diamond란 무엇인가](#dd-what) · [첫 번째 다이아몬드](#dd-first) · [AI는 어떻게 도와줄 수 있나](#dd-ai)
|
||||
**키워드 바로가기**: [Double Diamond란](#dd-what) · [첫 번째 다이아몬드](#dd-first) · [AI가 도와주는 방법](#dd-ai)
|
||||
:::
|
||||
|
||||
## 다음 내용을 배우게 됩니다
|
||||
## 배울 내용
|
||||
|
||||
1. Double Diamond가 무엇이고, 제로 베이스로 제품을 만들 때 왜 적합한지
|
||||
2. Discover, Define, Develop, Deliver 네 단계가 각각 무엇을 하는지
|
||||
3. "지금은 계속 발산해야 하는가"와 "지금은 수렴을 시작해야 하는가"를 구분하는 법
|
||||
4. Double Diamond를 AI 제품, 프로토타입 설계, 요구사항 검증에 적용하는 법
|
||||
1. Double Diamond 모델이란 무엇이며, 왜 제로 베이스 제품 개발에 적합한지
|
||||
2. Discover, Define, Develop, Deliver 네 단계에서 각각 무엇을 하는지
|
||||
3. "지금 계속 발산해야 하는지"와 "지금 수렴을 시작해야 하는지"를 어떻게 구분하는지
|
||||
4. Double Diamond 모델을 AI 제품, 프로토타입 설계, 요구사항 검증에 어떻게 적용하는지
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## [1. Double Diamond란 정확히 무엇인가](#top-dd)
|
||||
## [1. Double Diamond 모델이란 무엇인가](#top-dd)
|
||||
|
||||
Double Diamond는 영국 **Design Council**이 널리 알린 고전적인 디자인 프로세스 프레임워크입니다. 하나의 완전한 디자인과 혁신 과정을 연속된 두 개의 다이아몬드 모양으로 그립니다.
|
||||
Double Diamond 모델은 영국 **Design Council**이 보급한 고전적인 디자인 프로세스 프레임워크입니다. 완전한 디자인과 혁신 과정을 두 개의 연속된 다이아몬드 모양으로 표현합니다.
|
||||
|
||||
"다이아몬드"인 이유는 각 다이아몬드가 서로 반대지만 모두 중요한 두 가지 동작을 포함하기 때문입니다.
|
||||
"다이아몬드"인 이유는, 각 다이아몬드가 서로 반대되지만 모두 중요한 두 가지 동작을 포함하기 때문입니다:
|
||||
|
||||
- **발산**: 먼저 시야를 열고 더 많은 가능성을 본다.
|
||||
- **수렴**: 다시 범위를 좁혀 판단하고 취사선택한다.
|
||||
- **발산**: 먼저 시야를 넓혀 더 많은 가능성을 봅니다
|
||||
- **수렴**: 그런 다음 범위를 좁혀 판단하고 선택합니다
|
||||
|
||||
전체 과정은 네 단계입니다.
|
||||
전체 과정은 총 4단계입니다:
|
||||
|
||||
1. **Discover**: 사용자, 문제, 환경, 시장을 넓게 이해한다.
|
||||
2. **Define**: 많은 정보 속에서 진짜 해결할 가치가 있는 핵심 문제를 추출한다.
|
||||
3. **Develop**: 핵심 문제를 둘러싸고 여러 해결책을 발산한다.
|
||||
4. **Deliver**: 더 적합한 해결책을 선별하고, 프로토타입을 만들고, 테스트하고 전달한다.
|
||||
1. **Discover**: 사용자, 문제, 환경, 시장을 폭넓게 이해
|
||||
2. **Define**: 대량의 정보에서 정말로 해결할 가치가 있는 핵심 문제를 추출
|
||||
3. **Develop**: 핵심 문제를 중심으로 다양한 솔루션을 발산
|
||||
4. **Deliver**: 선별, 프로토타입, 테스트 및 더 적합한 솔루션 전달
|
||||
|
||||
이 네 단계를 가장 기억하기 쉬운 한 문장으로 압축하면 이렇습니다.
|
||||
이 네 단계를 가장 기억하기 쉬운 한 문장으로 압축하면:
|
||||
|
||||
- **첫 번째 다이아몬드**: 정확히 어떤 문제를 해결해야 하는지 먼저 파악한다.
|
||||
- **두 번째 다이아몬드**: 그다음 어떤 방법으로 해결할지 결정한다.
|
||||
- **첫 번째 다이아몬드**: 먼저 무엇을 해결해야 하는지 명확히 파악하기
|
||||
- **두 번째 다이아몬드**: 그 문제를 어떤 솔루션으로 해결할지 결정하기
|
||||
|
||||
이것이 방금 말한 아주 정확한 문장입니다.
|
||||
이것은 아까 정확하게 말씀하신 그 문장이기도 합니다:
|
||||
|
||||
- **첫 번째 다이아몬드: 올바른 일을 하기**
|
||||
- **두 번째 다이아몬드: 그 일을 제대로 하기**
|
||||
- **두 번째 다이아몬드: 일을 올바르게 하기**
|
||||
|
||||
## 2. 왜 Double Diamond는 초보자에게 특히 적합한가
|
||||
## 2. 왜 Double Diamond 모델이 특히 초보자에게 적합한가
|
||||
|
||||
초보자가 제품을 만들 때 가장 흔한 리듬은 보통 이렇습니다.
|
||||
초보자가 제품을 만들 때 가장 흔한 리듬은 보통 이렇습니다:
|
||||
|
||||
- 아이디어가 떠오른다.
|
||||
- 이 방향이 멋지다고 느낀다.
|
||||
- 바로 프로토타입을 그리기 시작한다.
|
||||
- 만들다 보니 기능이 점점 많아진다.
|
||||
- 마지막에는 자신이 정확히 어떤 문제를 해결하는지 모르게 된다.
|
||||
- 아이디어가 하나 떠오름
|
||||
- 이 방향이 멋지다고 느낌
|
||||
- 바로 프로토타입을 그리기 시작함
|
||||
- 하다 보니 기능이 점점 많아짐
|
||||
- 결국 자신이 무슨 문제를 해결하고 있는지 모르게 됨
|
||||
|
||||
Double Diamond의 가치는 프로세스를 복잡하게 만드는 데 있지 않습니다. **"문제 이해"와 "솔루션 설계"를 강제로 분리하게 하는 데** 있습니다.
|
||||
Double Diamond 모델의 가치는 프로세스를 복잡하게 만드는 것이 아니라, **"문제 이해"와 "솔루션 설계"를 분리하도록 강제**하는 데 있습니다.
|
||||
|
||||
이 말은 평범하게 들리지만 실제로는 매우 중요합니다. 실패한 제품의 상당수는 실행이 성실하지 않아서가 아니라 다음 이유 때문입니다.
|
||||
이것은 평범하게 들리지만, 실제로는 매우 중요합니다. 왜냐하면 많은 실패한 제품이 실행이 성실하지 않아서가 아니라:
|
||||
|
||||
- 문제를 잘못 골랐다.
|
||||
- 사용자를 오해했다.
|
||||
- 해결책을 너무 일찍 고정했다.
|
||||
- 방향 검증 없이 세부 다듬기에 많은 시간을 썼다.
|
||||
- 잘못된 문제를 선택했기 때문
|
||||
- 사용자를 오해했기 때문
|
||||
- 너무 일찍 솔루션에 고정되었기 때문
|
||||
- 방향을 검증하지 않고 세부 사항을 다듬는 데 많은 시간을 썼기 때문
|
||||
|
||||
Double Diamond는 계속해서 이렇게 상기시킵니다.
|
||||
Double Diamond 모델은 계속해서 다음을 상기시킵니다:
|
||||
|
||||
- 생각이 잘 이어진다고 해서 문제가 성립했다고 기본 가정하지 마세요.
|
||||
- 해결책을 만들 수 있다고 해서 그것이 만들 가치가 있다고 기본 가정하지 마세요.
|
||||
- 프로토타입이 완성되어 보인다고 해서 사용자가 정말 필요로 할 것이라고 기본 가정하지 마세요.
|
||||
- 아이디어가 편해서 문제가 이미 성립했다고 가정하지 마세요
|
||||
- 솔루션을 만들 수 있다고 해서 그것이 가치 있다고 가정하지 마세요
|
||||
- 프로토타입이 완성되어 보인다고 해서 사용자가 정말로 필요로 할 것이라고 가정하지 마세요
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## [3. 첫 번째 다이아몬드: 올바른 일을 하기](#top-dd)
|
||||
|
||||
첫 번째 다이아몬드는 **문제 자체**에 집중하며, 해결책에 집중하지 않습니다.
|
||||
첫 번째 다이아몬드가 주목하는 것은 **문제 자체**이며, 솔루션이 아닙니다.
|
||||
|
||||
한 문장으로 이해하면 이렇습니다. **서둘러 만들지 말고, 정말 만들 가치가 있는지 먼저 파악하세요.**
|
||||
한 문장으로 이해하자면: **서둘러 하지 말고, 먼저 할 가치가 있는지 확인하세요.**
|
||||
|
||||
### 3.1 Discover: 먼저 문제 공간을 열기
|
||||
|
||||
Discover 단계의 핵심 과제는 **넓게 조사하는 것**이지, 빠르게 결론을 내리는 것이 아닙니다.
|
||||
Discover 단계의 핵심 작업은 **폭넓은 조사이며, 빠른 결론을 내리는 것이 아닙니다.**
|
||||
|
||||
이 단계에서 보통 하는 일은 다음과 같습니다.
|
||||
이 단계에서 보통 하는 일은:
|
||||
|
||||
- 사용자가 실제 장면에서 어떻게 행동하는지 보기
|
||||
- 잠재 사용자를 인터뷰해 최근 언제 문제를 만났는지 이해하기
|
||||
- 지금은 어떻게 임시로 해결하고 있는지 관찰하기
|
||||
- 경쟁 제품과 대체 방안이 어떻게 처리하는지 보기
|
||||
- 시장, 프로세스, 제약, 상하류 정보를 수집하기
|
||||
- 사용자가 실제 시나리오에서 어떻게 행동하는지 관찰
|
||||
- 잠재 사용자를 인터뷰하여, 최근에 문제를 만난 것이 언제였는지 파악
|
||||
- 현재 어떻게 대충 해결하는지 관찰
|
||||
- 경쟁 제품과 대체 솔루션이 어떻게 처리하는지 확인
|
||||
- 시장, 프로세스, 제약 조건, 업스트림/다운스트림 정보 수집
|
||||
|
||||
많은 사람이 Discover를 "자료를 좀 더 많이 보는 것"으로 오해합니다. 사실 더 중요한 것은 **사람과 장면을 이해하는 것**이지, 정보만 잔뜩 검색하는 것이 아닙니다.
|
||||
많은 사람이 Discover를 "자료를 많이 보는 것"으로 오해합니다. 사실 더 중요한 것은: **정보를 한 무더기 검색하는 것이 아니라, 사람과 시나리오를 이해하는 것입니다.**
|
||||
|
||||
예를 들어 "AI가 회의록 정리를 도와주는 도구"를 만들고 싶다면, Discover 단계에서 더 집중해야 할 것은 다음입니다.
|
||||
예를 들어 "AI로 회의록 정리 도구"를 만들고 싶다면, Discover 단계에서 더 주목해야 할 것은:
|
||||
|
||||
- 사용자가 회의 후 정확히 어느 부분에서 가장 고통스러워하는지
|
||||
- 기록이 어려운지, 정리가 어려운지, 동기화가 어려운지
|
||||
- 지금은 직접 쓰는지, 인턴에게 시키는지, 녹음을 다시 듣는지, 아예 정리하지 않는지
|
||||
- 어떤 회의 장면에서 회의록이 가장 필요하고, 어떤 장면에서는 전혀 필요 없는지
|
||||
- 사용자가 회의 후 어디서 가장 고통스러워하는지
|
||||
- 기록이 어려운지, 정리가 어려운지, 아니면 공유가 어려운지
|
||||
- 현재 직접 작성하는지, 인턴에게 맡기는지, 녹음을 다시 듣는지, 아니면 아예 정리하지 않는지
|
||||
- 어떤 회의 시나리오에서 회의록이 가장 필요한지, 어떤 시나리오에서는 전혀 필요 없는지
|
||||
|
||||
이 단계에서 가장 중요한 목표는 답을 내는 것이 아니라, **너무 일찍 자신이 이미 답을 알고 있다고 착각하지 않는 것**입니다.
|
||||
이 단계의 가장 중요한 목표는 답을 얻는 것이 아니라, **너무 일찍 답을 알고 있다고 생각하지 않는 것입니다.**
|
||||
|
||||
### 3.2 Define: 많은 정보 속에서 핵심 문제 추출하기
|
||||
### 3.2 Define: 정보 더미에서 핵심 문제 추출
|
||||
|
||||
Discover가 시야를 여는 것이라면, Define은 수렴을 시작하는 것입니다.
|
||||
Discover가 시야를 넓히는 것이라면, Define은 수렴을 시작하는 것입니다.
|
||||
|
||||
Define 단계에서 해야 할 일은 모든 관찰을 그대로 보존하는 것이 아니라, 다음을 묻는 것입니다.
|
||||
Define 단계에서 해야 할 것은 모든 관찰을 보존하는 것이 아니라, 다음을 묻는 것입니다:
|
||||
|
||||
- 진짜로 가장 우선 해결할 가치가 있는 문제는 무엇인가?
|
||||
- 어떤 문제가 가장 자주 나타나고, 가장 아프고, 가장 가치 있는가?
|
||||
- 첫 번째 버전은 정확히 어떤 장면 하나만 겨냥할 것인가?
|
||||
- 정말로 우선적으로 해결할 가치가 있는 문제는 무엇인가
|
||||
- 어떤 문제가 가장 자주 나타나고, 가장 아프고, 가장 가치가 있는가
|
||||
- 우리 첫 번째 버전은 어떤 시나리오에만 집중할 것인가
|
||||
|
||||
이 단계의 핵심은 넓은 주제를 명확한 문제 정의로 수렴하는 것입니다.
|
||||
|
||||
처음에는 이렇게 말할 수 있습니다.
|
||||
예를 들어 처음에 이렇게 말했다면:
|
||||
|
||||
> 회의 효율을 높이는 AI 도구를 만들고 싶다.
|
||||
> 회의 효율을 높이는 AI 도구를 만들고 싶습니다.
|
||||
|
||||
Define 단계에 이르면 더 좋은 표현은 이렇게 바뀔 수 있습니다.
|
||||
Define 단계에 이르면, 더 나은 표현은 이렇게 될 수 있습니다:
|
||||
|
||||
> 우리는 먼저 프로젝트형 팀이 30~60분짜리 협업 회의가 끝난 뒤, 10분 안에 할 일, 담당자, 마감일이 포함된 회의록을 만들지 못하는 문제를 해결한다.
|
||||
> 프로젝트형 팀이 30~60분 협업 회의가 끝난 후, 10분 이내에 할 일, 담당자, 마감일이 포함된 회의록을 출력하지 못하는 문제를 먼저 해결하겠습니다.
|
||||
|
||||
이제 문제가 명확해지기 시작합니다.
|
||||
이때 문제가 명확해지기 시작합니다:
|
||||
|
||||
- 사용자는 누구인가
|
||||
- 장면은 무엇인가
|
||||
- 막히는 지점은 무엇인가
|
||||
- 성공 기준은 무엇인가
|
||||
- 사용자가 누구인지
|
||||
- 시나리오가 무엇인지
|
||||
- 막힌 곳이 어디인지
|
||||
- 성공 기준이 무엇인지
|
||||
|
||||
Define의 본질은 **"문제가 많다"에서 "이번에는 어떤 문제 하나를 먼저 해결할 것인가"로 수렴하는 것**입니다.
|
||||
Define의 본질은 **"문제가 많다"에서 "이번에 어떤 문제를 먼저 해결할 것인가"로 수렴하는 것입니다.**
|
||||
|
||||
## 4. 두 번째 다이아몬드: 그 일을 제대로 하기
|
||||
## 4. 두 번째 다이아몬드: 일을 올바르게 하기
|
||||
|
||||
첫 번째 다이아몬드를 완료한 뒤에야 진정으로 두 번째 다이아몬드에 들어가기에 적합합니다. 이때 해결하려는 것은 더 이상 모호한 방향이 아니라 수렴된 구체적인 문제이기 때문입니다.
|
||||
첫 번째 다이아몬드를 완료한 후에야 비로소 두 번째 다이아몬드에 진입하는 것이 적절합니다. 왜냐하면 이때 해결하는 것은 모호한 방향이 아니라, 수렴된 구체적인 문제이기 때문입니다.
|
||||
|
||||
### 4.1 Develop: 핵심 문제를 중심으로 솔루션 발산하기
|
||||
### 4.1 Develop: 핵심 문제를 중심으로 솔루션 발산
|
||||
|
||||
Develop 단계의 핵심은 **같은 문제를 중심으로 여러 가능한 솔루션을 탐색하는 것**입니다.
|
||||
Develop 단계의 핵심은 **같은 문제를 중심으로 여러 가능한 솔루션을 탐색하는 것입니다.**
|
||||
|
||||
주의할 점은 여기서의 발산은 Discover 단계와 다릅니다.
|
||||
주의할 점은, 여기서의 발산은 Discover 단계의 발산과 다릅니다.
|
||||
|
||||
- Discover의 발산은 문제 공간을 탐색하는 것입니다.
|
||||
- Develop의 발산은 해결책 공간을 탐색하는 것입니다.
|
||||
- Discover의 발산은 문제 공간을 탐색하는 것
|
||||
- Develop의 발산은 솔루션 공간을 탐색하는 것
|
||||
|
||||
회의록 예시를 계속 쓰면, Develop 단계에서는 다음을 생각할 수 있습니다.
|
||||
회의록 예시를 계속하면, Develop 단계에서는 이런 것들을 생각할 수 있습니다:
|
||||
|
||||
- 웹 도구를 만들 것인가, 회의 플러그인을 만들 것인가
|
||||
- 녹음 업로드 후 처리할 것인가, 실시간 기록할 것인가
|
||||
- 요약만 할 것인가, 할 일 추출에 집중할 것인가
|
||||
- 개인 효율을 강조할 것인가, 팀 동기화를 강조할 것인가
|
||||
- 사용자가 자유롭게 편집하게 할 것인가, 구조화된 템플릿을 바로 출력할 것인가
|
||||
- 웹 도구로 할지, 회의 플러그인으로 할지
|
||||
- 녹음을 업로드한 후 처리할지, 실시간 기록으로 할지
|
||||
- 요약만 할지, 할 일 추출을 중심으로 할지
|
||||
- 개인 효율을 강조할지, 팀 동기화를 강조할지
|
||||
- 사용자에게 자유로운 편집을 제공할지, 구조화된 템플릿을 직접 출력할지
|
||||
|
||||
이 단계는 브레인스토밍에 매우 적합하고, 팀과 함께 솔루션을 넓히기에도 좋습니다.
|
||||
이 단계는 브레인스토밍에 매우 적합하며, 팀과 함께 솔루션을 펼쳐보는 데도 좋습니다.
|
||||
|
||||
하지만 전제가 있습니다. **모든 솔루션은 이미 정의된 같은 문제를 섬겨야 합니다.**
|
||||
문제가 명확히 정의되지 않았다면 Develop은 쉽게 다시 기능이 난무하는 상태가 됩니다.
|
||||
하지만 여기에는 전제가 있습니다: **모든 솔루션은 동일하게 정의된 문제에 봉사해야 합니다.**
|
||||
문제가 명확하게 정의되지 않으면, Develop은 쉽게 다시 기능이 난무하는 상황이 됩니다.
|
||||
|
||||
### 4.2 Deliver: 솔루션 선택, 프로토타입, 테스트, 전달
|
||||
### 4.2 Deliver: 솔루션 선택, 프로토타입, 테스트 및 전달
|
||||
|
||||
Deliver 단계는 두 번째 다이아몬드 안의 수렴 단계입니다.
|
||||
Deliver 단계는 두 번째 다이아몬드의 수렴 단계입니다.
|
||||
|
||||
이때 해야 할 일은 더 많이 상상하는 것이 아니라 판단을 시작하는 것입니다.
|
||||
이때 해야 할 것은 계속 더 많은 것을 생각하는 것이 아니라, 판단을 시작하는 것입니다:
|
||||
|
||||
- 어떤 솔루션이 현재 단계에 가장 적합한가
|
||||
- 어떤 버전이 가장 작지만 가장 유용한가
|
||||
- 어떤 기능은 반드시 먼저 해야 하고, 어떤 기능은 나중으로 미뤄도 되는가
|
||||
- 어떻게 프로토타입을 만들고, 테스트하고, 작은 범위에서 검증할 것인가
|
||||
- 현재 단계에 가장 적합한 솔루션은 무엇인가
|
||||
- 가장 작지만 가장 유용한 버전은 무엇인가
|
||||
- 어떤 기능을 먼저 해야 하고, 어떤 것은 나중에 해도 되는가
|
||||
- 프로토타입, 테스트, 소규모 검증은 어떻게 할 것인가
|
||||
|
||||
많은 사람이 Deliver를 "출시"와 같다고 생각합니다. 사실 더 정확한 뜻은 **하나의 솔루션을 테스트 가능하고, 검증 가능하며, 반복 개선 가능한 것으로 바꾸는 것**입니다.
|
||||
많은 사람이 Deliver를 "출시"와 같다고 생각합니다. 사실 더 정확한 의미는: **솔루션을 테스트 가능하고, 검증 가능하고, 반복 가능한 것으로 만드는 것입니다.**
|
||||
|
||||
그것은 다음일 수 있습니다.
|
||||
그것은 다음과 같을 수 있습니다:
|
||||
|
||||
- 저충실도 흐름도 한 장
|
||||
- 저해상도 흐름도
|
||||
- Figma 프로토타입
|
||||
- 실행 가능한 MVP
|
||||
- 소규모 사용자 테스트
|
||||
- 실제 피드백 이후의 반복 개선 버전
|
||||
- 실제 피드백 후 반복 버전
|
||||
|
||||
Deliver의 핵심은 "완벽한 전달"이 아니라 **가능한 한 빨리 솔루션을 실제 환경에 넣어 검증하는 것**입니다.
|
||||
Deliver의 핵심은 "완벽한 전달"이 아니라, **최대한 빨리 솔루션을 실제 환경에서 검증하는 것입니다.**
|
||||
|
||||
## 5. 가장 기억하기 쉬운 대조표
|
||||
## 5. 가장 기억하기 쉬운 비교표
|
||||
|
||||
네 단계를 자꾸 헷갈린다면 아래 버전을 그대로 기억하세요.
|
||||
네 단계를 항상 헷갈린다면, 아래 버전을 바로 기억하세요:
|
||||
|
||||
| 단계 | 무엇을 하는가 | 키워드 | 흔한 산출물 |
|
||||
| 단계 | 하는 일 | 키워드 | 일반적 산출물 |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | 문제 이해 | 조사, 관찰, 인터뷰, 정보 수집 | 사용자 인사이트, 장면 메모, 문제 목록 |
|
||||
| Define | 문제 정의 | 추출, 집중, 취사선택, 문제 다시 쓰기 | 문제 정의, 우선순위, MVP 진입점 |
|
||||
| Discover | 문제 이해 | 조사, 관찰, 인터뷰, 정보 수집 | 사용자 인사이트, 시나리오 노트, 문제 목록 |
|
||||
| Define | 문제 정의 | 추출, 집중, 선택, 문제 재작성 | 문제 정의, 우선순위, MVP 진입점 |
|
||||
| Develop | 솔루션 탐색 | 브레인스토밍, 비교, 공동 창작, 프로토타입 구상 | 솔루션 목록, 흐름 스케치, 프로토타입 방향 |
|
||||
| Deliver | 솔루션 검증 | 프로토타입, 테스트, 반복 개선, 전달 | 프로토타입, 테스트 피드백, 최적화 버전 |
|
||||
| Deliver | 솔루션 검증 | 프로토타입, 테스트, 반복, 전달 | 프로토타입, 테스트 피드백, 최적화 버전 |
|
||||
|
||||
더 압축하면 이렇습니다.
|
||||
더 압축하면 이렇습니다:
|
||||
|
||||
- **Discover / Define**: "올바른 일을 하기"를 해결한다.
|
||||
- **Develop / Deliver**: "그 일을 제대로 하기"를 해결한다.
|
||||
- **Discover / Define**: "올바른 일을 하기" 해결
|
||||
- **Develop / Deliver**: "일을 올바르게 하기" 해결
|
||||
|
||||
## 6. Double Diamond의 가장 흔한 오해
|
||||
## 6. Double Diamond 모델의 가장 흔한 오해
|
||||
|
||||
### 6.1 Discover도 하지 않고 바로 Deliver하기
|
||||
### 6.1 Discover도 안 했는데 바로 Deliver
|
||||
|
||||
가장 흔한 경우입니다. 많은 사람이 아이디어가 생기자마자 프로토타입을 그리고, PRD를 쓰고, 모델을 붙이고, 페이지를 만듭니다.
|
||||
이것이 가장 흔한 경우입니다. 많은 사람이 아이디어가 떠오르자마자 프로토타입을 그리고, PRD를 쓰고, 모델을 연동하고, 페이지를 만듭니다.
|
||||
|
||||
문제는 당신이 성실하지 않다는 것이 아니라, 해결할 가치가 있는 문제인지 아직 확인하지 않았을 수 있다는 점입니다.
|
||||
문제는 성실하지 않다는 것이 아니라, 문제가 해결할 가치가 있는지 확인조차 하지 않았을 수 있다는 것입니다.
|
||||
|
||||
### 6.2 Discover는 오래 하지만 끝내 Define하지 않기
|
||||
### 6.2 Discover을 오래 하지만, Define을 계속하지 않음
|
||||
|
||||
또 다른 극단은 계속 조사하고, 계속 자료를 보고, 계속 인터뷰하지만 좀처럼 수렴하지 못하는 것입니다.
|
||||
또 다른 극단은 계속 조사하고, 계속 자료를 보고, 계속 인터뷰하지만, 수렴하지 못하는 것입니다.
|
||||
|
||||
Double Diamond는 무한 발산을 하라는 뜻이 아닙니다. 발산 후에는 반드시 판단과 취사선택으로 들어가야 한다고 알려 주는 것입니다.
|
||||
Double Diamond는 무한한 발산을 요구하는 것이 아니라, 발산 후에는 반드시 판단과 선택으로 진입해야 한다는 것을 상기시킵니다.
|
||||
|
||||
### 6.3 Define 이후 몰래 문제를 바꾸기
|
||||
### 6.3 Define 후, 몰래 문제를 바꿈
|
||||
|
||||
많은 팀은 Develop 단계에서 어떤 솔루션이 더 쉽게 만들 수 있다는 이유로, 기존 솔루션에 맞도록 문제 정의를 거꾸로 수정합니다.
|
||||
많은 팀이 Develop 단계에서 어떤 솔루션이 더 쉽게 만들 수 있다는 이유로, 문제 정의를 역으로 수정하여 기존 솔루션에 맞춥니다.
|
||||
|
||||
이것은 위험합니다. 문제를 해결하는 것이 아니라 자신이 선호하는 솔루션을 정당화하고 있을 수 있기 때문입니다.
|
||||
이것은 위험합니다. 왜냐하면 문제를 해결하는 것이 아니라, 자신이 좋아하는 솔루션을 위해 이유를 찾고 있을 수 있기 때문입니다.
|
||||
|
||||
### 6.4 Deliver를 "크고 완전한 출시"로 오해하기
|
||||
### 6.4 Deliver을 "크고 완전한 출시"로 오해
|
||||
|
||||
Deliver는 완전한 제품을 모두 만들어야 끝난다는 뜻이 아닙니다. 많은 경우 테스트 가능한 프로토타입 하나, 실제 사용자 테스트 한 번이면 이미 좋은 deliver입니다.
|
||||
Deliver이 반드시 완전한 제품을 모두 완성해야 끝나는 것은 아닙니다. 많은 경우, 테스트 가능한 프로토타입이나 한 차례의 실제 사용자 테스트만으로도 이미 훌륭한 deliver입니다.
|
||||
|
||||
## 7. AI 제품에서 Double Diamond는 어떻게 쓰나
|
||||
## 7. AI 제품에서 Double Diamond 모델을 어떻게 사용할까
|
||||
|
||||
AI 제품은 특히 "능력 우선" 함정에 빠지기 쉽습니다. 모델 능력이 너무 매력적으로 보이기 때문입니다. 당신은 곧장 이런 생각을 하고 싶어질 수 있습니다.
|
||||
AI 제품은 특히 "기능 우선" 함정에 빠지기 쉽습니다. 왜냐하면 모델의 능력이 너무 매력적으로 보이기 때문입니다. 바로 이런 것들을 생각하고 싶어집니다:
|
||||
|
||||
- 멀티모달을 붙일까
|
||||
- Agent를 만들까
|
||||
- 워크플로우를 넣을까
|
||||
- 음성, 이미지, 웹 검색을 연결할까
|
||||
- 멀티모달을 연동할지 말지
|
||||
- Agent를 만들지 말지
|
||||
- 워크플로를 추가할지 말지
|
||||
- 음성, 이미지, 인터넷 검색을 연동할지 말지
|
||||
|
||||
하지만 Double Diamond는 먼저 이렇게 묻게 합니다.
|
||||
하지만 Double Diamond 모델은 먼저 이것을 묻도록 합니다:
|
||||
|
||||
- 사용자는 정확히 어느 단계에서 정말 막혀 있는가
|
||||
- 이 막힘은 반드시 AI가 있어야 해결되는가
|
||||
- AI를 쓰지 않는다면 기존 방법은 정확히 어디가 가장 나쁜가
|
||||
- AI가 들어간 뒤 가장 핵심적인 진전은 무엇인가
|
||||
- 사용자가 정확히 어느 단계에서 막혀 있는지
|
||||
- 이 막힌 곳이 반드시 AI가 필요한 것인지
|
||||
- AI를 사용하지 않는다면, 기존 방법이 정확히 어디서 가장 나쁜지
|
||||
- AI를 넣은 후, 가장 핵심적인 진전은 무엇인지
|
||||
|
||||
이것은 흔한 상황을 피하게 해 줍니다. **능력은 강한데 가치는 약한 상황**입니다.
|
||||
이것은 흔한 상황을 피하는 데 도움이 됩니다: **능력은 강하지만, 가치는 약함.**
|
||||
|
||||
실용적인 순서는 다음과 같습니다.
|
||||
실용적인 순서는:
|
||||
|
||||
1. Discover 단계에서 사용자가 지금 어떻게 과제를 처리하는지 관찰한다.
|
||||
2. Define 단계에서 가장 아픈 장면 하나를 명확한 문제 정의 한 문장으로 쓴다.
|
||||
3. Develop 단계에서 어떤 AI 기능이 이 문제를 가장 잘 섬기는지 비교한다.
|
||||
4. Deliver 단계에서 최소 버전을 만들고 실제 사용자에게 테스트하게 한다.
|
||||
1. Discover 단계에서 사용자가 현재 작업을 어떻게 처리하는지 관찰
|
||||
2. Define 단계에서 가장 아픈 시나리오를 명확한 문제 정의 한 문장으로 작성
|
||||
3. Develop 단계에서 어떤 AI 능력이 이 문제에 가장 적합한지 비교
|
||||
4. Deliver 단계에서 최소 버전을 만들어 실제 사용자에게 테스트
|
||||
|
||||
## 8. 바로 적용할 수 있는 Double Diamond 템플릿
|
||||
## 8. 바로 사용할 수 있는 Double Diamond 템플릿
|
||||
|
||||
자기 제품을 만들고 있다면 이 순서대로 먼저 써 보세요.
|
||||
자신의 제품을 만들고 있다면, 다음 순서대로 작성해 보세요:
|
||||
|
||||
### Discover
|
||||
|
||||
- 내가 관찰한 사용자는 누구인가?
|
||||
- 그들이 최근 이 문제를 만난 것은 언제인가?
|
||||
- 지금은 어떻게 해결하고 있는가?
|
||||
- 가장 짜증 나고, 느리고, 불안한 지점은 무엇인가?
|
||||
- 그들이 최근에 이 문제를 만난 것은 언제인가?
|
||||
- 지금 어떻게 해결하고 있는가?
|
||||
- 가장 번거롭고, 가장 느리고, 가장 불안한 부분은 무엇인가?
|
||||
|
||||
### Define
|
||||
|
||||
- 이 문제들 중 가장 우선 해결할 가치가 있는 것은 무엇인가?
|
||||
- 어떤 장면이 가장 빈번하거나 가장 핵심적인가?
|
||||
- 첫 번째 버전은 누구만, 무엇만 섬길 것인가?
|
||||
- 성공적으로 해결되면 사용자의 상태는 어떻게 변하는가?
|
||||
- 이 문제들 중, 가장 먼저 해결할 가치가 있는 것은 무엇인가?
|
||||
- 어떤 시나리오가 가장 빈도가 높거나, 가장 핵심적인가?
|
||||
- 첫 번째 버전에서는 누구만 서비스하고, 무엇만 해결할 것인가?
|
||||
- 성공적으로 해결된 후, 사용자의 상태는 어떻게 변할 것인가?
|
||||
|
||||
### Develop
|
||||
|
||||
- 이 문제에 대해 어떤 가능한 솔루션이 있는가?
|
||||
- 어떤 솔루션이 가장 가볍고, 빠르고, 검증하기 쉬운가?
|
||||
- 반드시 해야 할 것은 무엇이고, 나중으로 미룰 것은 무엇인가?
|
||||
- 이 문제에 대해, 어떤 가능한 솔루션이 있는가?
|
||||
- 어떤 솔루션이 가장 가볍고, 가장 빠르고, 가장 검증하기 쉬운가?
|
||||
- 반드시 해야 할 것은 무엇이고, 나중에 해도 되는 것은 무엇인가?
|
||||
|
||||
### Deliver
|
||||
|
||||
- 이 방향을 검증하기 위해 가장 작게 무엇을 전달할 수 있는가?
|
||||
- 이 방향을 검증하기 위해 최소한 무엇을 전달할 수 있는가?
|
||||
- 흐름도인가, 프로토타입인가, MVP인가?
|
||||
- 누구에게 테스트해야 하는가?
|
||||
- 테스트 후 계속할지, 수정할지, 포기할지는 어떻게 판단할 것인가?
|
||||
- 누구에게 테스트를 맡겨야 하는가?
|
||||
- 테스트 후 계속할지, 수정할지, 포기할지 어떻게 판단할 것인가?
|
||||
|
||||
## 9. 제로 베이스도 이해할 수 있는 예시
|
||||
|
||||
"대학생의 취업 이력서 준비를 돕는 AI 도구"를 만들고 싶다고 가정해 봅시다.
|
||||
"대학생의 구직 이력서를 준비해 주는" AI 도구를 만들고 싶다고 가정해 봅시다.
|
||||
|
||||
많은 사람은 처음부터 두 번째 다이아몬드로 들어가 이런 생각을 시작합니다.
|
||||
많은 사람이 처음부터 두 번째 다이아몬드에 진입하여 이런 것들을 생각합니다:
|
||||
|
||||
- 원클릭 미화를 넣을까
|
||||
- 지능형 문장 개선을 넣을까
|
||||
- JD 자동 매칭을 할까
|
||||
- 자기소개서를 생성할까
|
||||
- 원클릭 미화를 할지 말지
|
||||
- 지능형 재작성을 할지 말지
|
||||
- 자동 JD 매칭을 할지 말지
|
||||
- 자기소개서를 생성할지 말지
|
||||
|
||||
하지만 Double Diamond를 따르면 더 좋은 과정은 이렇습니다.
|
||||
하지만 Double Diamond 모델에 따르면, 더 나은 과정은 이렇습니다:
|
||||
|
||||
### 첫 번째 다이아몬드
|
||||
|
||||
**Discover**
|
||||
|
||||
- 취업 준비생에게 최근 이력서를 고친 것이 언제인지 묻는다.
|
||||
- 그들이 이전 이력서를 어떻게 새 버전으로 바꾸는지 본다.
|
||||
- 가장 어려운 것이 "쓸 줄 모름"인지, "고칠 줄 모름"인지, "좋은지 판단할 줄 모름"인지 이해한다.
|
||||
- 최근 졸업생에게 마지막으로 이력서를 수정한 것이 언제였는지 물어보기
|
||||
- 그들이 기존 이력서에서 새 버전으로 어떻게 수정하는지 보기
|
||||
- 가장 고민인 것이 "작성 방법을 모름", "수정 방법을 모름", "좋은지 판단 방법을 모름" 중 어느 것인지 파악
|
||||
|
||||
**Define**
|
||||
|
||||
- 마지막에는 더 구체적인 문제로 수렴한다.
|
||||
- "대학생은 이력서를 만들 줄 모른다"가 아니다.
|
||||
- "처음 인턴십에 지원하는 학생은 기존 경험을 직무에 맞는 표현으로 바꾸기 어려워 지원을 미룬다"이다.
|
||||
- 마지막으로 더 구체적인 문제로 수렴:
|
||||
- "대학생이 이력서를 못 만드는 것이 아니라"
|
||||
- "처음으로 인턴십에 지원하는 학생이 기존 경험을 공고에 맞는 표현으로 재작성하기 어려워, 지원을 미루는 것"
|
||||
|
||||
### 두 번째 다이아몬드
|
||||
|
||||
**Develop**
|
||||
|
||||
- 몇 가지 솔루션을 생각한다. 템플릿 라이브러리, AI 문장 개선, 직무 대조, 이력서 점수화, 사례 참고.
|
||||
- 여러 솔루션 생각: 템플릿 라이브러리, AI 재작성, 공고 대조, 이력서 평가, 사례 참고
|
||||
|
||||
**Deliver**
|
||||
|
||||
- 첫 버전은 "직무 설명에 따라 경험 bullet point를 바꿔 쓰기"만 만든다.
|
||||
- 학생 5명에게 써 보게 하고, 더 빨리 첫 버전의 이력서를 제출하게 되는지 본다.
|
||||
- 첫 번째 버전은 "공고 설명에 따라 경험 bullet points를 재작성"만 하기
|
||||
- 5명의 학생에게 사용해 보고, 더 빨리 첫 번째 버전의 이력서를 제출하는지 확인
|
||||
|
||||
첫 번째 다이아몬드를 탄탄하게 하면 두 번째 다이아몬드가 훨씬 명확해진다는 것을 알 수 있습니다.
|
||||
첫 번째 다이아몬드를 탄탄하게 하면, 두 번째 다이아몬드가 훨씬 명확해지는 것을 발견할 것입니다.
|
||||
|
||||
## 10. 정리
|
||||
## 10. 요약
|
||||
|
||||
Double Diamond의 가장 강한 힘은 혼란스러운 덩어리를 네 개의 더 명확한 동작으로 나눠 준다는 데 있습니다.
|
||||
Double Diamond 모델의 가장 강력한 점은, 한 무더기의 혼란을 네 개의 더 명확한 동작으로 나누어 준다는 것입니다:
|
||||
|
||||
- 먼저 발산해 문제를 이해한다.
|
||||
- 다시 수렴해 문제를 정의한다.
|
||||
- 다시 발산해 솔루션을 탐색한다.
|
||||
- 마지막으로 수렴해 솔루션을 전달한다.
|
||||
- 먼저 발산하여 문제를 이해
|
||||
- 다시 수렴하여 문제를 정의
|
||||
- 다시 발산하여 솔루션을 탐색
|
||||
- 마지막으로 수렴하여 솔루션을 전달
|
||||
|
||||
이 모델은 당신을 느리게 만들기 위한 것이 아닙니다. **바빠 보이지만 사실 방향이 틀린 수많은 우회로를 줄이기 위한 것**입니다.
|
||||
이것은 여러분을 느리게 만드는 것이 아니라, **바쁘게 보이지만 실제로 방향이 잘못된 많은 우회를 덜 하게 해줍니다.**
|
||||
|
||||
특히 AI 시대에는 만드는 속도가 점점 빨라지기 때문에 Double Diamond가 오히려 더 중요해집니다. "만드는 것"이 점점 쉬워질수록 진짜 희소한 능력은 이렇게 바뀌기 때문입니다. **해결할 가치가 있는 문제를 풀고 있는가, 그리고 그것을 적합한 방식으로 풀고 있는가.**
|
||||
특히 AI 시대에는 것을 만드는 것이 점점 빨라지고 있어, Double Diamond 모델이 오히려 더 중요해집니다. 왜냐하면 "만들어 내는 것"이 점점 쉬워질수록, 진정으로 희귀한 능력은 다음이 되기 때문입니다: **해결할 가치가 있는 문제를 해결하고 있는지, 그리고 적절한 방식으로 해결하고 있는지.**
|
||||
|
||||
이 한 문장만 기억하면 됩니다.
|
||||
이 한 문장만 기억하면 됩니다:
|
||||
|
||||
**올바른 일을 먼저 하고, 그 일을 제대로 하세요.**
|
||||
**먼저 올바른 일을 하고, 그 다음에 일을 올바르게 하세요.**
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## [11. AI로 Double Diamond 흐름을 실행하는 방법](#top-dd)
|
||||
## [11. AI를 활용해 Double Diamond 프로세스를 실행하는 방법](#top-dd)
|
||||
|
||||
Double Diamond 자체는 AI 도구가 아니지만, AI는 네 단계에서 "가속기" 역할을 하기에 매우 적합합니다. 핵심은 AI가 대신 결정하게 하는 것이 아니라, 시야 확장, 정보 정리, 솔루션 비교, 검증 자료 생성을 돕게 하는 것입니다.
|
||||
Double Diamond 모델 자체는 AI 도구가 아니지만, AI는 네 단계에서 "가속기" 역할을 하기에 매우 적합합니다. 핵심은 AI가 대신 결정하게 하는 것이 아니라, 시야를 넓히고, 정보를 정리하고, 솔루션을 비교하고, 검증 자료를 생성하는 것을 돕게 하는 것입니다.
|
||||
|
||||
### 11.1 Discover 단계에서 AI로 정보 밑작업 한 번 하기
|
||||
### 11.1 Discover 단계: AI로 먼저 정보 기반 마련
|
||||
|
||||
정식 인터뷰와 조사를 시작하기 전에 AI에게 가벼운 문제 스캔을 맡길 수 있습니다. 예를 들면 다음입니다.
|
||||
공식 인터뷰와 조사 전에 AI에게 가벼운 문제 스캔을 먼저 맡길 수 있습니다. 예를 들어:
|
||||
|
||||
- 시장에서 흔한 대체 방안은 무엇인가
|
||||
- 사용자가 공개 커뮤니티에서 가장 자주 불평하는 것은 무엇인가
|
||||
- 이 문제는 어떤 장면과 사람군에서 자주 나타나는가
|
||||
- 기존 제품은 보통 무엇을 놓치고 있는가
|
||||
- 시장에서 흔한 대체 솔루션은 무엇인지
|
||||
- 사용자가 공개 커뮤니티에서 가장 많이 불만을 제기하는 것이 무엇인지
|
||||
- 이 문제가 어떤 시나리오와 사용자군에서 흔한지
|
||||
- 기존 제품이 보통 무엇을 간과하는지
|
||||
|
||||
이 단계는 실제 조사를 대체할 수 없지만, 문제 지도를 빠르게 만드는 데 매우 적합합니다.
|
||||
이 단계는 실제 조사를 대체할 수 없지만, 빠르게 문제 지도를 구축하는 데 매우 적합합니다.
|
||||
|
||||
아주 간단한 초보자 입력은 이렇게 쓸 수 있습니다.
|
||||
아주 간단한 초보자 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
대학생 이력서 수정을 도와주는 도구를 만들고 싶어.
|
||||
기능을 생각해 주지 말고, 이 문제에서 사람들이 가장 자주 겪는 어려움이 무엇인지 먼저 봐 줘.
|
||||
대학생의 이력서를 수정하는 도구를 만들고 싶습니다.
|
||||
먼저 기능을 생각하지 말고, 이 문제에서 사람들이 가장 많이 겪는 어려움이 무엇인지 먼저 봐 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
초기 문제 지도:
|
||||
|
||||
1. 어떤 경험을 써야 할지 모름
|
||||
2. 직무에 맞게 어떻게 수정해야 할지 모름
|
||||
3. 여러 번 고쳤는데도 충분히 좋은지 확신하지 못함
|
||||
4. 다른 사람에게 봐 달라고 해야 하지만 매번 부탁하기 불편함
|
||||
5. 확신이 없어서 계속 지원을 미룸
|
||||
2. 공고에 맞게 어떻게 수정해야 할지 모름
|
||||
3. 여러 번 수정해도 충분히 좋은지 확신이 안 됨
|
||||
4. 다른 사람에게 검토를 부탁해야 하지만, 매번 부탁하기가 불편함
|
||||
5. 확신이 없어서, 계속 지원을 미룸
|
||||
```
|
||||
|
||||
이 출력의 역할은 결론을 대신 내려 주는 것이 아니라, Discover에 더 빨리 들어가게 해 주는 것입니다.
|
||||
이런 출력의 역할은 대신 결론을 내리는 것이 아니라, 더 빨리 Discover에 진입하도록 돕는 것입니다.
|
||||
|
||||
### 11.2 Define 단계에서 AI에게 문제 정의 수렴을 돕게 하기
|
||||
### 11.2 Define 단계: AI가 문제 정의를 수렴하도록 돕기
|
||||
|
||||
많은 사람이 자료를 한가득 모은 뒤 가장 어려워하는 것은 문제를 진짜 명확한 한 문장으로 줄이는 일입니다. 조사 메모를 AI에게 주고 몇 가지 후보 문제 정의로 압축하게 할 수 있습니다.
|
||||
많은 사람이 자료를 많이 수집한 후, 가장 어려운 것은 문제를 정말로 명확한 한 문장으로 수렴하는 것입니다. 조사 노트를 AI에게 전달하여, 몇 가지 후보 문제 정의로 압축하도록 할 수 있습니다:
|
||||
|
||||
```text
|
||||
아래는 Discover 단계에서 모은 사용자 피드백과 조사 메모야.
|
||||
다음은 Discover 단계에서 수집한 사용자 피드백과 조사 노트입니다:
|
||||
[내용 붙여넣기]
|
||||
|
||||
다음 세 가지를 도와줘.
|
||||
1. 가장 자주 나타나는 문제 패턴을 요약
|
||||
2. 문제 빈도, 고통감, 검증 가능성을 기준으로 우선 해결할 가치가 있는 문제 3개 정리
|
||||
세 가지 일을 해 주세요:
|
||||
1. 가장 자주 나타나는 문제 패턴을 정리
|
||||
2. 문제 빈도, 고통 정도, 검증 가능성에 따라, 우선적으로 해결할 가치가 있는 문제 3개를 정리
|
||||
3. 각 문제를 구체적인 문제 정의 한 문장으로 작성
|
||||
```
|
||||
|
||||
이렇게 하면 "문제가 너무 많다"에 머무르지 않고 Define으로 들어가기 쉬워집니다.
|
||||
이렇게 하면 "문제가 많다"는 상태에 머물지 않고 Define에 더 쉽게 진입할 수 있습니다.
|
||||
|
||||
입력을 아주 간단하게 써도 됩니다.
|
||||
입력을 아주 간단하게 쓸 수도 있습니다:
|
||||
|
||||
```text
|
||||
지금 모은 문제는 이거야.
|
||||
1. 다들 이력서에 무엇을 써야 할지 모름
|
||||
2. 다들 어떻게 고쳐야 할지 모름
|
||||
3. 다들 잘 고친 건지 확신하지 못해 지원을 망설임
|
||||
내가 지금 수집한 문제는 다음과 같습니다:
|
||||
1. 다들 이력서에 뭘 써야 할지 모름
|
||||
2. 다들 어떻게 수정해야 할지 모름
|
||||
3. 다들 수정이 안 된 것 같아서, 지원을 못 함
|
||||
|
||||
첫 버전에서 어떤 문제를 먼저 해결하는 게 가장 적합한지 봐 줘.
|
||||
첫 번째 버전에서 가장 먼저 해결할 문제가 무엇인지 봐 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
우선 해결을 추천하는 문제:
|
||||
우선적으로 해결할 것을 권장하는 문제:
|
||||
|
||||
"처음 인턴십에 지원하는 학생은 이력서가 이미 지원 가능한 수준인지 확신하지 못해 반복 수정하고 지원을 미룬다."
|
||||
"처음으로 인턴십에 지원하는 학생이, 이력서가 이미 지원 가능한 수준에 도달했는지 확신하지 못해, 반복적으로 수정하며 지원을 미룸."
|
||||
|
||||
이유:
|
||||
1. 문제가 더 구체적이다.
|
||||
2. 지연 행동을 설명할 수 있다.
|
||||
3. 작은 버전을 설계해 검증하기 쉽다.
|
||||
1. 이 문제가 더 구체적임
|
||||
2. 지연 행동을 설명할 수 있음
|
||||
3. 작은 버전을 설계하여 검증하기 더 쉬움
|
||||
```
|
||||
|
||||
이런 출력은 유용합니다. 흐릿한 문제들 속에서 MVP 출발점에 가까운 정의 하나를 수렴하게 해 주기 때문입니다.
|
||||
이런 출력은 매우 유용합니다. 왜냐하면 많은 모호한 문제에서 MVP 출발점에 더 가까운 정의를 수렴해 주기 때문입니다.
|
||||
|
||||
### 11.3 Develop 단계에서 AI로 여러 솔루션 발산하기
|
||||
### 11.3 Develop 단계: AI로 여러 솔루션 발산
|
||||
|
||||
많은 사람은 문제를 정의하자마자 머릿속에 처음 떠오른 솔루션만 바라봅니다. 이 단계에서 AI는 강제로 발산시키는 데 매우 적합합니다.
|
||||
많은 사람이 문제를 정의한 후, 머릿속에 가장 먼저 떠오른 솔루션만 바라봅니다. AI는 이 단계에서 강제 발산을 도와주기에 매우 적합합니다:
|
||||
|
||||
```text
|
||||
핵심 문제를 이렇게 정의했어: [문제 정의]
|
||||
최종 답을 하나만 주지 말고, 아래 각도에서 2~3가지 해결 방향을 제안해 줘.
|
||||
핵심 문제를 정의했습니다: [문제 정의]
|
||||
최종 답을 바로 주지 말고, 다음 관점에서 각각 2~3가지 해결 방향을 제시해 주세요:
|
||||
1. 가장 가벼운 MVP
|
||||
2. 수요 검증에 가장 적합한 방안
|
||||
3. 경험 개선에 가장 적합한 방안
|
||||
4. AI에 의존하지 않는 방안
|
||||
5. AI에 의존하는 방안
|
||||
마지막에는 각 방안의 장점, 위험, 검증 비용을 비교해 줘.
|
||||
2. 수요를 검증하기에 가장 적합한 솔루션
|
||||
3. 경험을 개선하는 데 가장 적합한 솔루션
|
||||
4. AI에 의존하지 않는 솔루션
|
||||
5. AI에 의존하는 솔루션
|
||||
마지막으로 각 솔루션의 장점, 위험, 검증 비용을 비교해 주세요.
|
||||
```
|
||||
|
||||
이렇게 하면 너무 일찍 하나의 솔루션에 묶이지 않게 됩니다.
|
||||
이렇게 하면 너무 일찍 단일 솔루션에 갇히지 않습니다.
|
||||
|
||||
간단한 입력은 이렇게 쓸 수 있습니다.
|
||||
간단한 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
현재 문제 정의는 이거야.
|
||||
"대학생은 이력서가 이미 지원 가능한지 확신하지 못해 계속 미루고 있다."
|
||||
내 문제 정의는 다음과 같습니다:
|
||||
"대학생이 이력서가 이미 지원할 수 있는지 확신하지 못해, 계속 지원을 미룸."
|
||||
|
||||
서로 다른 해결책 4가지를 생각해 줘. 하나만 주지 마.
|
||||
4가지 다른 솔루션을 생각해 주세요. 한 가지만 주지 마세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
방안 1: 이력서 지원 가능 체크리스트
|
||||
방안 2: 직무 설명에 맞춘 맞춤형 문장 개선
|
||||
방안 3: 사용자가 이력서를 업로드하면 위험 알림 제공
|
||||
방안 4: 우수 사례 대조를 제공해 사용자가 차이를 판단하도록 도움
|
||||
솔루션 1: 이력서 지원 가능 체크리스트
|
||||
솔루션 2: 공고 설명에 따른 맞춤형 재작성
|
||||
솔루션 3: 사용자가 이력서를 업로드하면 위험 신호를 제시
|
||||
솔루션 4: 우수 사례 대조를 제공하여 사용자가 격차를 판단하도록 도움
|
||||
```
|
||||
|
||||
이때부터 "솔루션 비교"로 들어가기 쉬워지고, 처음부터 AI 문장 개선 하나만 바라보지 않게 됩니다.
|
||||
이때 "솔루션 비교"에 더 쉽게 진입할 수 있으며, 처음부터 AI 재작성이라는 한 방향만 바라보지 않게 됩니다.
|
||||
|
||||
### 11.4 Deliver 단계에서 AI로 프로토타입 문구와 테스트 자료 생성하기
|
||||
### 11.4 Deliver 단계: AI로 프로토타입 카피와 테스트 자료 생성
|
||||
|
||||
Deliver 단계에 들어가면 AI는 다음 작업을 빠르게 처리하는 데 매우 적합합니다.
|
||||
Deliver 단계에 진입하면, AI는 다음 작업을 가속화하는 데 매우 적합합니다:
|
||||
|
||||
- 저충실도 프로토타입의 페이지 문구 생성
|
||||
- 저해상도 프로토타입의 페이지 카피 생성
|
||||
- 사용자 테스트 스크립트 정리
|
||||
- 비교 가능한 여러 버전의 제목, 버튼, 설명문 생성
|
||||
- 비교 가능한 여러 버전의 제목, 버튼, 설명어 생성
|
||||
- 테스트 후 피드백과 문제 목록 정리
|
||||
|
||||
예를 들어 AI에게 20분 사용자 테스트 스크립트를 만들게 하거나, 사용자 5명의 피드백을 "계속 진행 / 방향 수정 / 중단" 판단 근거로 정리하게 할 수 있습니다.
|
||||
예를 들어 AI에게 20분 사용자 테스트 스크립트를 생성하거나, 5명의 사용자 피드백을 "계속 진행/방향 수정/일시 중지"의 판단 근거로 정리하도록 할 수 있습니다.
|
||||
|
||||
가장 작은 입력 예시는 다음입니다.
|
||||
최소 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
아주 간단한 프로토타입을 만들었어.
|
||||
사용자가 이력서를 업로드하면, 시스템이 어떤 부분이 아직 지원하기에 적합하지 않은지 알려 줘.
|
||||
아주 간단한 프로토타입을 만들었어요:
|
||||
사용자가 이력서를 업로드하면, 어느 부분이 아직 지원에 부적합한지 알려줘요.
|
||||
|
||||
15분짜리 사용자 테스트 스크립트를 만들어 줘.
|
||||
15분 사용자 테스트 스크립트를 생성해 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
15분 테스트 스크립트:
|
||||
|
||||
1. 먼저 사용자에게 최근 이력서 지원 경험을 설명하게 한다.
|
||||
2. 사용자가 독립적으로 이력서 업로드를 완료하게 한다.
|
||||
3. 피드백 결과를 이해하는지 관찰한다.
|
||||
4. 질문: 이 안내 중 어떤 것이 가장 도움이 되고, 어떤 것이 헷갈렸나요?
|
||||
5. 질문: 다음 지원 전에 다시 쓰고 싶나요?
|
||||
1. 먼저 사용자에게 최근 이력서 제출 경험을 설명해 달라고 요청
|
||||
2. 사용자가 독립적으로 이력서 업로드를 완료하게 함
|
||||
3. 피드백 결과를 이해할 수 있는지 관찰
|
||||
4. 질문: 이 안내 중 어떤 것이 가장 도움이 되었고, 어떤 것이 혼란스러웠는지
|
||||
5. 질문: 다음에 제출하기 전에 다시 사용하고 싶은지
|
||||
```
|
||||
|
||||
이 출력은 실용적입니다. "프로토타입을 만들었다"에서 "다음에는 어떻게 테스트할까"로 넘어가게 해 주기 때문입니다.
|
||||
이런 출력은 매우 실용적입니다. 왜냐하면 "프로토타입을 완성했다"에서 "다음에 어떻게 테스트할지"까지 나아갈 수 있게 해주기 때문입니다.
|
||||
|
||||
### 11.5 AI에게 "단계 문지기" 역할을 맡기기
|
||||
### 11.5 AI를 "단계 수문원"으로 활용
|
||||
|
||||
Double Diamond에서 가장 흔한 문제는 사람이 단계를 건너뛰는 것입니다. AI에게 직접 문지기 역할을 맡겨 현재 어느 단계에 있는지 알려 달라고 할 수 있습니다.
|
||||
Double Diamond 모델의 가장 흔한 문제는 단계를 건너뛰는 것입니다. AI에게 직접 수문원 역할을 맡겨, 지금 정확히 어느 단계에 있는지 상기시키도록 할 수 있습니다:
|
||||
|
||||
```text
|
||||
제품 프로세스 코치 역할을 해 줘.
|
||||
아래는 현재 내 프로젝트 상태야: [설명]
|
||||
내가 지금 Discover, Define, Develop, Deliver 중 어디에 더 가까운지 판단해 줘.
|
||||
그리고 알려 줘.
|
||||
1. 내가 너무 일찍 다음 단계로 넘어갔는지
|
||||
2. 현재 단계에서 가장 보충해야 할 행동은 무엇인지
|
||||
3. 지금은 먼저 하지 말아야 할 일은 무엇인지
|
||||
제품 프로세스 코치 역할을 해 주세요.
|
||||
다음은 내 현재 프로젝트 상태입니다: [설명]
|
||||
지금 내가 Discover, Define, Develop, Deliver 중 어느 단계에 더 가까운지 판단해 주세요.
|
||||
그리고 알려 주세요:
|
||||
1. 내가 너무 일찍 다음 단계로 건너뛰었는지
|
||||
2. 현재 단계에서 가장 보완해야 할 행동은 무엇인지
|
||||
3. 지금 하지 말아야 할 일은 무엇인지
|
||||
```
|
||||
|
||||
초보자에게 특히 유용합니다. "문제를 아직 명확히 생각하지 않았는데 프로토타입을 그리기 시작하는" 일이 매우 쉽게 일어나기 때문입니다.
|
||||
이것은 초보자에게 특히 도움이 됩니다. 왜냐하면 "문제를 아직 명확히 생각하지 않았는데 프로토타입을 그리기 시작하는" 경우가 매우 흔하기 때문입니다.
|
||||
|
||||
## 📚 Assignments
|
||||
## 📚 과제
|
||||
|
||||
위 내용을 바탕으로 다음 과제를 완료하세요.
|
||||
위 내용을 바탕으로 다음 과제를 완료해 주세요:
|
||||
|
||||
1. 최근 만들고 싶은 제품 아이디어 하나를 고르고, Discover, Define, Develop, Deliver 네 단계 초안을 작성하세요.
|
||||
2. Define 단계에서 문제를 구체적인 한 문장으로 강제로 줄이세요.
|
||||
3. Develop 단계에서 처음 떠오른 방법 하나만 바라보지 말고, 최소 3가지 다른 방안을 나열하세요.
|
||||
4. Deliver 단계에서 일주일 안에 전달 가능한 최소 검증 버전을 작성하세요.
|
||||
1. 최근에 만들고 싶은 제품 아이디어를 하나 골라, Discover, Define, Develop, Deliver 4단계의 초안을 작성하세요
|
||||
2. Define 단계에서, 문제를 구체적인 한 문장으로 줄이도록 강제하세요
|
||||
3. Develop 단계에서, 최소 3가지 다른 솔루션을 나열하고, 가장 먼저 떠오른 방법만 바라보지 마세요
|
||||
4. Deliver 단계에서, 1주일 이내에 전달할 수 있는 최소 검증 버전을 하나 작성하세요
|
||||
|
||||
## 더 읽어 보기
|
||||
## 더 읽어볼 만한 자료
|
||||
|
||||
이 글은 주로 Design Council의 Double Diamond 공식 자료를 참고했습니다. 이어서 보기 좋습니다.
|
||||
이 글은 주로 Design Council의 Double Diamond 공식 자료를 참고했습니다. 계속 읽어보세요:
|
||||
|
||||
- [Design Council: The Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
|
||||
- [Design Council: Framework for Innovation](https://www.designcouncil.org.uk/our-work/skills-learning/tools-frameworks/framework-for-innovation-design-councils-evolved-double-diamond/)
|
||||
- [Design Council: History of the Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/history-of-the-double-diamond/)
|
||||
|
||||
|
||||
@@ -11,171 +11,171 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
|
||||
<a id="top-idea-sources"></a>
|
||||
|
||||
## 본 장 안내
|
||||
## 이 장의 가이드
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['아이디어 찾기', '제품 방향', '수요 발견', '산업 관찰']"
|
||||
coreOutput="더 구체적이고 계속 조사할 만한 제품 방향 1개"
|
||||
expectedOutput="어디를 훑고, 어떻게 보고, 무엇을 먼저 봐야 하는지 알게 되어 더 이상 'AI + 어떤 산업'처럼 빈 생각만 남기지 않기"
|
||||
:tags="['아이디어 찾기', '제품 방향', '니즈 발견', '업계 관찰']"
|
||||
coreOutput="더 구체적이고 계속 조사해 볼 가치가 있는 제품 방향 1개"
|
||||
expectedOutput="어디서 훑어야 할지, 어떻게 봐야 할지, 먼저 무엇을 봐야 할지 알게 되어, 'AI + 특정 산업' 같은 막연한 생각에만 머물지 않게 됩니다"
|
||||
>
|
||||
|
||||
많은 사람이 첫 단계에서 막힙니다. 완전히 영감이 없어서가 아니라, 많은 내용을 훑고 나서도 머릿속에 남는 것이 여전히 큰 단어뿐이기 때문입니다.
|
||||
많은 사람들이 첫 번째 단계에서 막히는 것은 영감이 전혀 없어서가 아니라, 많은 콘텐츠를 훑은 후에도 머릿속에 남는 것은 여전히 큰 단어뿐이기 때문입니다:
|
||||
|
||||
- AI for education
|
||||
- AI for healthcare
|
||||
- AI for finance
|
||||
- AI agent for business
|
||||
|
||||
이것들은 아직 아이디어가 아닙니다. 단지 "방향이 크다"는 것을 알려 줄 뿐, 다음을 알려 주지 않습니다.
|
||||
이것들은 아직 아이디어가 아닙니다. 그것들은 단지 "방향이 크다"는 것만 말해 줄 뿐, 다음을 알려주지 않습니다:
|
||||
|
||||
- 누가 쓰는지
|
||||
- 어떤 장면에서 쓰는지
|
||||
- 지금은 어떻게 임시로 해결하고 있는지
|
||||
- 어느 단계를 먼저 잘라 들어갈 가치가 있는지
|
||||
- 누가 사용하는지
|
||||
- 어떤 시나리오에서 사용하는지
|
||||
- 지금 어떻게 대충 하고 있는지
|
||||
- 어느 단계를 먼저 공략하는 것이 가장 가치 있는지
|
||||
|
||||
이 글은 공허한 방법론을 말하지 않습니다. 바로 쓰기 좋은 출처들을 정리해 드립니다.
|
||||
이 글은 공허한 방법론을 다루지 않고, 바로 사용할 수 있는 더 나은 출처들을 정리해 드립니다.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 최소 SOP
|
||||
**목적**: 읽고 나면 아이디어가 없을 때 먼저 어디를 훑어야 하는지, 어떤 링크가 "구체적인 수요"를 보기에 적합한지, 어떤 링크가 "트렌드"를 보기에 적합한지, 어떤 링크가 "실제 비즈니스"를 보기에 적합한지 알게 됩니다.
|
||||
**목적**: 이 글을 읽은 후, 아이디어가 없을 때 어디서 훑어야 할지, 어떤 링크가 "구체적인 니즈"에 적합한지, 어떤 것이 "트렌드"에 적합한지, 어떤 것이 "실제 비즈니스"에 적합한지 알게 됩니다.
|
||||
|
||||
**행동 항목**: 먼저 idea 목록을 한 바퀴 훑고, 그다음 돈을 버는 작은 제품을 한 바퀴 봅니다. 이어서 트렌드와 더 비즈니스에 가까운 출처를 보고, 마지막에 계속 조사하고 싶은 방향 1개를 남깁니다.
|
||||
**실행 항목**: 먼저 idea 목록을 한 바퀴 훑고, 수익 내는 소규모 제품을 한 바퀴 보고, 트렌드와 더 비즈니스에 가까운 출처를 본 다음, 계속 조사해 보고 싶은 방향 1개를 남깁니다.
|
||||
|
||||
**결과**: 큰 단어에 머무르지 않고, 더 구체적이고 계속 검증할 만한 방향 1개를 얻습니다.
|
||||
**결과**: 큰 단어에 머물지 않고, 더 구체적이고 검증해 볼 가치가 있는 방향 1개를 얻게 됩니다.
|
||||
|
||||
**키워드 이동**: [참고 앱 목록](#idea-apps) · [트렌드 출처](#idea-trends) · [더 비즈니스에 가까운 출처](#idea-business) · [VC / 액셀러레이터 출처](#idea-vc) · [최단 경로](#idea-path) · [AI는 어떻게 도와줄 수 있나](#idea-ai)
|
||||
**키워드 바로가기**: [참고 앱 목록](#idea-apps) · [트렌드 출처](#idea-trends) · [더 비즈니스에 가까운 출처](#idea-business) · [VC / 가속기 출처](#idea-vc) · [최단 경로](#idea-path) · [AI가 어떻게 도와줄 수 있는지](#idea-ai)
|
||||
:::
|
||||
|
||||
## 다음 내용을 배우게 됩니다
|
||||
|
||||
1. 어떤 웹사이트가 idea를 바로 훑기에 적합한지
|
||||
2. 어떤 웹사이트가 이미 돈을 버는 작은 제품을 보기에 적합한지
|
||||
3. 어떤 출처가 트렌드와 산업 변화를 보기에 적합한지
|
||||
4. 어떤 출처가 실제 비즈니스와 실제 지불에 더 가까운지
|
||||
5. 제로 베이스에 적합한 가장 짧은 사용 경로
|
||||
2. 어떤 웹사이트가 이미 수익을 내는 소규모 제품을 보기에 적합한지
|
||||
3. 어떤 출처가 트렌드와 업계 변화를 보기에 적합한지
|
||||
4. 어떤 출처가 실제 비즈니스와 실제 결제에 더 가까운지
|
||||
5. 제로 베이스에게 적합한 최단 사용 경로 1가지
|
||||
|
||||
<a id="idea-apps"></a>
|
||||
## [1. 참고 앱 목록: 먼저 다른 사람이 이미 무엇을 하고 있는지 보기](#top-idea-sources)
|
||||
## [1. 참고 앱 목록: 먼저 남들이 이미 무엇을 하고 있는지 보기](#top-idea-sources)
|
||||
|
||||
이것은 초보자에게 가장 적합한 출발점입니다. 가장 구체적이기 때문입니다.
|
||||
|
||||
### 1군: 열자마자 idea 목록이 나오고 바로 고를 수 있는 곳
|
||||
### 1티어: 열면 바로 idea 목록, 바로 고르기
|
||||
|
||||
- [Reddit — r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
이 subreddit의 핵심 용도는 실제 사용자가 직접 "누가 XX 하나 만들어 줬으면 좋겠다"를 올리는 것입니다. 각 게시물은 보통 구체적인 제품 수요 하나이고, 약간의 상황 설명도 포함합니다. 들어간 뒤 `Top -> Past Month` 또는 `Top -> Past Year`로 정렬하면 20분 만에 실제 수요를 한 묶음 훑을 수 있습니다.
|
||||
이 subreddit의 핵심 용도는: 실제 사용자가 "누군가 XX를 만들어 주면 좋겠다"고 바로 게시하는 것입니다. 각 게시물은 보통 하나의 구체적인 제품 니즈이며, 약간의 시나리오 설명도 포함합니다. 들어간 후 `Top -> Past Month` 또는 `Top -> Past Year`로 정렬하면 20분 만에 실제 니즈를 한 무더기 훑을 수 있습니다.
|
||||
- [Reddit — r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
|
||||
위와 비슷하지만 소프트웨어/App 쪽에 더 가깝습니다. 게시물의 흔한 형식은 "XX를 할 수 있는 앱이 필요하다"이고, 입도가 더 작으며 작지만 아름다운 niche가 많습니다.
|
||||
위와 비슷하지만 소프트웨어/App에 더 치중합니다. 게시물의 일반적인 형식은 "XX를 할 수 있는 앱이 필요해"이며, 세분화 수준이 더 작고 대부분 작고 아름다운 니치입니다.
|
||||
- [Reddit — r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
|
||||
앞의 두 곳보다 더 완전합니다. 많은 게시물이 한 문장짜리 수요에 그치지 않고, 약간의 시장 분석, 비즈니스 모델, 왜 지금 할 만한지까지 포함합니다.
|
||||
앞의 두 개보다 더 완전합니다. 많은 게시물이 한 줄짜리 니즈가 아니라 시장 분석, 비즈니스 모델, 왜 지금 할 가치가 있는지에 대한 내용도 포함합니다.
|
||||
- [Unvalidated Ideas](https://unvalidatedideas.com/)
|
||||
검증되지 않은 창업 idea를 매주 발행합니다. 흔한 필드는 타깃 사용자, 수익화 방식, 초기 검증 아이디어입니다. 형식이 통일되어 있어 빠르게 훑기 좋습니다.
|
||||
매주 검증되지 않은 창업 idea를 발행합니다. 일반적으로 대상 사용자, 수익화 방식, 초기 검증 아이디어 등의 필드가 포함됩니다. 형식이 통일되어 있어 빠르게 훑기에 적합합니다.
|
||||
- [IdeasAI](https://ideasai.com/)
|
||||
AI로 창업 idea를 생성하며 계속 넘겨 볼 수 있습니다. 품질은 불안정하지만, "아무 감이 없을 때" 영감을 자극하고 다시 세부 장면으로 파고들기에 좋습니다.
|
||||
AI로 창업 idea를 생성하며, 계속 훑을 수 있습니다. 품질이 일정하지 않지만, "아무 감도 없을 때" 영감을 자극하는 데 매우 적합하며, 이후 스스로 세부 시나리오를 파고들면 됩니다.
|
||||
|
||||
### 2군: 다른 사람이 이미 하고 있는 돈 되는 작은 제품을 보고 idea를 역추적하기
|
||||
### 2티어: 남들이 이미 만들어서 수익 내는 소규모 제품 보고, idea 역추론하기
|
||||
|
||||
이런 플랫폼의 논리는 이렇습니다. 다른 사람이 이미 수요를 검증했고, 심지어 돈도 벌고 있습니다. 이것들을 보는 이유는 베끼기 위해서가 아니라, "어떤 작은 문제가 이미 유료로 해결되고 있는지" 보기 위해서입니다.
|
||||
이런 플랫폼의 논리는: 남이 이미 니즈를 검증했고, 심지어 이미 수익을 내고 있다는 것입니다. 이것들을 보는 것은 베끼기 위해서가 아니라 "어떤 작은 문제에 이미 누군가 돈을 지불하고 있는지" 보기 위해서입니다.
|
||||
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
실제 작은 비즈니스 사례를 많이 수록합니다. 보통 창업자 인터뷰, 매출 데이터, 시작 과정이 있습니다. 월수입 1만~10만 달러 수준의 작은 제품을 중점적으로 보세요. 보통 더 niche하고, 일반인이 이해할 수 있는 제품 규모에 더 가깝습니다.
|
||||
많은 실제 소규모 비즈니스 사례를 수록하고 있으며, 보통 창업자 인터뷰, 수익 데이터, 시작 과정이 포함됩니다. 월 수익 1만~10만 달러의 소규모 제품에 주목하세요. 보통 더 니치하고, 일반인이 이해할 수 있는 제품 규모에 더 가깝습니다.
|
||||
- [Indie Hackers — Products](https://www.indiehackers.com/products)
|
||||
독립 개발자가 제품을 보여 주는 곳입니다. 많은 제품이 수익과 성장을 공개합니다. 수익 순으로 정렬해 월수입 수천~수만 달러 제품들이 어떤 구체적 문제를 해결하는지 봅니다.
|
||||
인디 개발자가 제품을 전시하는 곳으로, 많은 경우 수익과 성장을 공개합니다. 수익순으로 정렬하여 월 수익 수천~수만 달러 제품들이 어떤 구체적인 문제를 해결하고 있는지 보세요.
|
||||
- [MicroConf Blog](https://microconf.com/blog)
|
||||
Micro SaaS 쪽에 가깝습니다. "충분히 작지만 누군가 돈을 낼 의향이 있는" 제품 진입점을 보기에 적합합니다.
|
||||
Micro SaaS에 편중되어 있습니다. "충분히 작지만, 누군가 돈을 지불할 의향이 있는" 제품 진입점을 보기에 적합합니다.
|
||||
- [1000 Tools](https://1000.tools/)
|
||||
AI 도구 모음 사이트입니다. 어떤 카테고리가 이미 만들어졌지만 완성도가 아쉬운지, 또는 국내/특정 수직 산업에서 아직 잘 커버되지 않은 방향이 무엇인지 보기에 좋습니다.
|
||||
AI 도구 집합 사이트입니다. 어떤 카테고리에 이미 누군가 만들었지만 보통 수준인지, 또는 어떤 방향이 국내/특정 수직 산업에서 아직 잘 커버되지 않았는지 보기에 적합합니다.
|
||||
- [Product Hunt](https://www.producthunt.com/)
|
||||
최근 반복해서 등장하는 제품 유형을 봅니다. 1위만 보지 말고, 어떤 카테고리가 계속 만들어지지만 아직 명확한 승자가 없는지에 집중하세요.
|
||||
최근에 반복적으로 등장하는 제품 유형을 보세요. 1위만 주시하지 말고, 어떤 카테고리가 계속해서 누군가 만들고 있지만 뚜렷한 승자가 없는지에 주목하세요.
|
||||
- [BetaList](https://betalist.com/)
|
||||
초기 제품과 아직 방향을 시험 중인 팀을 보기에 적합합니다.
|
||||
|
||||
### 제품을 볼 때는 제품 자체만 보지 말고, 낮은 평점과 "대행 서비스"도 보세요
|
||||
### 제품을 볼 때, 제품 자체만 보지 말고 부정적인 리뷰와 "대행 서비스"도 보세요
|
||||
|
||||
- [G2](https://www.g2.com/)
|
||||
사용법: 1점, 2점 리뷰를 봅니다. 낮은 평점에는 보통 "기존 제품의 어느 단계가 제대로 되지 않는지"가 숨어 있습니다.
|
||||
활용법: 1성, 2성 평가를 보세요. 부정적인 리뷰에는 보통 "기존 제품이 어느 부분을 잘못했는지"가 숨어 있습니다.
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
사용법: G2와 비슷합니다. SaaS 제품의 실제 불평을 보기에 적합합니다.
|
||||
- 타오바오 / Xianyu / [Fiverr](https://www.fiverr.com/) / [Upwork](https://www.upwork.com/) / Zhu Bajie
|
||||
사용법: "대행", "대신 정리", "대신 입력", "대신 녹취", "대신 변환" 같은 키워드를 검색합니다. 어떤 수작업 서비스가 잘 팔린다면, 그 뒤에는 대개 반복 가능하고 제품화 가능한 프로세스가 있습니다.
|
||||
활용법: G2와 비슷하게 SaaS 제품의 실제 불만을 보기에 적합합니다.
|
||||
- 타오바오 / 셴위 / [Fiverr](https://www.fiverr.com/) / [Upwork](https://www.upwork.com/) / 주바지에
|
||||
활용법: "대행", "대신 정리", "대신 입력", "대신 전사"를 검색하세요. 어떤 수작업 서비스가 잘 팔린다면, 그 배후에는 보통 반복 가능하고 제품화할 수 있는 프로세스가 있습니다.
|
||||
|
||||
판단 신호는 단순합니다.
|
||||
신호 판단은 간단합니다:
|
||||
|
||||
- 사용자가 기존 도구를 이미 불평하고 있다.
|
||||
- 사용자가 이미 돈을 내고 누군가에게 대행을 맡기고 있다.
|
||||
- 사용자가 이 프로세스에 많은 인력과 시간을 투입하고 있다.
|
||||
- 사용자가 이미 기존 도구에 불만을 가지고 있음
|
||||
- 사용자가 이미 돈을 지불하고 다른 사람에게 대행을 맡기고 있음
|
||||
- 사용자가 이미 이 프로세스에 많은 인력과 시간을 투입하고 있음
|
||||
|
||||
### 4군: 영상 보기. 누군가가 직접 idea를 분해해 준다
|
||||
### 4티어: 영상 보기, 누군가 직접 idea를 분석해 주는 콘텐츠
|
||||
|
||||
포럼이나 순위를 훑는 것을 좋아하지 않고 "누군가 생각의 흐름을 대신 풀어 주면 좋겠다"면 영상과 팟캐스트도 적합합니다.
|
||||
포럼이나 랭킹을 훑는 것보다 "누군가 내 생각을 정리해 주는" 영상이나 팟캐스트를 선호한다면, 이것도 매우 적합합니다.
|
||||
|
||||
- `Greg Isenberg startup ideas` 검색
|
||||
누군가가 구체적인 idea 2~3개를 직접 분해하고, 시장 규모, 경쟁 분석, 진입점을 함께 설명하는 콘텐츠를 보기에 좋습니다.
|
||||
구체적인 idea 2~3개를 직접 분석해 주며, 시장 규모, 경쟁 분석, 진입점도 함께 설명합니다.
|
||||
- `My First Million podcast` 검색
|
||||
두 진행자가 자주 한 회 전체를 비즈니스 idea 브레인스토밍에 씁니다. 밀도가 높고 매우 구체적인 niche가 자주 나옵니다.
|
||||
두 진행자가 종종 한 에피소드 전체를 비즈니스 idea 브레인스토밍에 사용합니다. 밀도가 높고, 매우 구체적인 니치가 자주 등장합니다.
|
||||
- `YC startup ideas` 또는 `Michael Seibel startup ideas` 검색
|
||||
초보자에게 적합합니다. 내용이 직설적이고, 방향을 고르는 법을 바로 설명하는 경우가 많습니다.
|
||||
초보자에게 적합하며, 내용이 직관적이고 방향 선택 방법을 직접 설명하는 경우가 많습니다.
|
||||
|
||||
<a id="idea-trends"></a>
|
||||
## [2. 트렌드 출처: 어떤 방향이 떠오르고 있는지 보기](#top-idea-sources)
|
||||
|
||||
트렌드 사이트의 역할은 직접 아이디어를 주는 것이 아니라, 어떤 방향이 뜨거워지고 있는지, 계속 볼 가치가 있는지 판단하게 도와주는 것입니다.
|
||||
트렌드 사이트의 역할은 직접 아이디어를 주는 것이 아니라, 특정 방향이 상승하고 있는지, 계속 살펴볼 가치가 있는지 판단하는 데 도움을 주는 것입니다.
|
||||
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
빠르게 성장하지만 아직 주류 시야에 완전히 들어오지 않은 주제와 제품 카테고리를 데이터로 추적합니다. "떠오르고 있지만 아직 지나치게 붐비지는 않은" 방향을 보기에 적합합니다.
|
||||
데이터로 성장이 빠르지만 아직 주류에 진입하지 않은 주제와 제품 카테고리를 추적합니다. "떠오르고 있지만 아직 특별히 붐비지 않은" 방향을 보기에 적합합니다.
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
키워드를 검색해 지난 1년의 추세선을 보고, "관련 검색어"의 "급상승" 단어를 봅니다.
|
||||
키워드를 검색하여 지난 1년간의 트렌드 선을 보고, "관련 검색어"에서 "급증" 단어를 확인합니다.
|
||||
- [Glimpse](https://meetglimpse.com/)
|
||||
Google Trends와 비슷합니다.
|
||||
- 산업 연구 보고서 요약 페이지
|
||||
이미 방향이 있고, 이 방향이 산업 안에서 어떤 위치에 있는지 빠르게 보고 싶을 때 적합합니다.
|
||||
- 업계 리서치 보고서 요약 페이지
|
||||
이미 방향이 있고, 그 방향이 업계에서 어떤 위치인지 빠르게 보고 싶을 때 적합합니다.
|
||||
- McKinsey / BCG / Gartner의 트렌드 콘텐츠
|
||||
기업과 큰 산업 관점에 더 가깝습니다. B2B, 산업, 전통 업종에 적합합니다.
|
||||
기업과 대규모 산업 관점에 더 치중되어, B2B, 산업, 전통 산업에 적합합니다.
|
||||
- [State of AI Report](https://www.stateof.ai/)
|
||||
방향이 AI 기술 자체와 관련 있다면, 이런 연례 보고서가 큰 그림을 잡는 데 좋습니다.
|
||||
방향이 AI 기술 자체와 관련이 있다면, 이런 연례 보고서는 큰 그림을 구축하는 데 매우 적합합니다.
|
||||
|
||||
트렌드를 볼 때는 세 가지만 중점적으로 봅니다.
|
||||
트렌드를 볼 때 다음 세 가지만 집중하세요:
|
||||
|
||||
- 이 단어가 지속적으로 뜨거워지고 있는가
|
||||
- 어떤 구체적 장면에 놓이는가
|
||||
- 누가 가장 먼저 시간, 전환 비용, 예산을 지불할 것인가
|
||||
- 이 단어가 지속적으로 상승하고 있는지
|
||||
- 그것이 어떤 구체적인 시나리오에 해당하는지
|
||||
- 누가 가장 먼저 시간, 전환 비용 또는 예산을 지불할 것인지
|
||||
|
||||
<a id="idea-business"></a>
|
||||
## [3. 더 비즈니스에 가까운 출처: 누가 돈을 쓰고, 누가 불평하고, 누가 수작업 서비스를 파는지 보기](#top-idea-sources)
|
||||
## [3. 더 비즈니스에 가 가까운 출처: 누가 돈을 쓰는지, 누가 불만을 가지고 있는지, 누가 수작업 서비스를 파는지 보기](#top-idea-sources)
|
||||
|
||||
"멋있어 보이는" 방향이 아니라 "실제 비즈니스에 더 가까운" 방향을 찾고 싶다면, 워크플로우에 더 가까운 출처를 봐야 합니다.
|
||||
"멋지게 들리는" 방향이 아니라 "실제 비즈니스에 더 가까운" 방향을 찾고 싶다면, 워크플로에 더 가까운 출처를 봐야 합니다.
|
||||
|
||||
### 누가 실제로 무엇에 돈을 쓰는지 보기
|
||||
|
||||
- [중국정부조달망](https://www.ccgp.gov.cn/)
|
||||
사용법: "스마트 건설 현장", "실험실 관리 시스템", "데이터 수집", "진료소 관리", "견적 시스템" 같은 단어를 검색해 예산, 기술 요구사항, 사용 장면을 봅니다.
|
||||
- 각 성/시 공공자원 거래센터
|
||||
사용법: 지방 정부와 국유기업이 실제로 어떤 시스템을 구매하는지 봅니다.
|
||||
- 비표망 / 천리마 입찰망 / 표사통
|
||||
사용법: 기업 측 구매 수요와 자주 등장하는 시스템 유형을 봅니다.
|
||||
- [중국 정부 조달망](https://www.ccgp.gov.cn/)
|
||||
활용법: "스마트 건설 현장", "실험실 관리 시스템", "데이터 수집", "진료소 관리", "견적 시스템" 같은 단어를 검색하여 예산, 기술 요구사항, 사용 시나리오를 확인합니다.
|
||||
- 각 성/시 공공자원거래센터
|
||||
활용법: 지방 정부와 국유 기업이 실제로 어떤 시스템을 구매하는지 확인합니다.
|
||||
- 비바오왕 / 천리마 입찰망 / 비아시통
|
||||
활용법: 기업 측의 조달 니즈와 고빈도 시스템 유형을 확인합니다.
|
||||
|
||||
이 출처들의 강한 신호는 미래를 토론하는 것이 아니라, "오늘 이미 누군가 이 일에 돈을 쓰려 한다"는 사실을 드러낸다는 점입니다.
|
||||
이런 출처의 강력한 신호는: 미래를 논의하는 것이 아니라 "오늘 이미 누군가 이 일에 돈을 지불하고 있다"는 것을 보여준다는 것입니다.
|
||||
|
||||
### 누가 실제로 무엇을 불평하는지 보기
|
||||
### 누가 실제로 무엇에 불만을 가지고 있는지 보기
|
||||
|
||||
- 제조업: 기계 커뮤니티, 공업 제어 포럼
|
||||
- 의료: Dingxiangyuan, Yimaitong
|
||||
- 건축 / 공정: 토목온라인, Guanglianda 커뮤니티
|
||||
- 재무 / 회계: 중국회계시야 포럼
|
||||
- 무역: Fubu 외무 포럼, Miker Circle
|
||||
- 외식 / 리테일: 직업외식망, Lianshang 포럼
|
||||
- [Reddit](https://www.reddit.com/)의 수직 게시판: `r/smallbusiness`, `r/Entrepreneur`, `r/SaaS`, `r/healthcare`, `r/manufacturing`
|
||||
- 제조업: 기계 커뮤니티, 공제어 제어 포럼
|
||||
- 의료: 딩샹위안, 이마이퉁
|
||||
- 건축 / 공학: 토목 온라인, 광리안다 커뮤니티
|
||||
- 재무 / 회계: 중국 회계 시야 포럼
|
||||
- 무역: 푸부 무역 포럼, 미케취안
|
||||
- 식음료 / 소매: 직업 식음료망, 연상망 포럼
|
||||
- [Reddit](https://www.reddit.com/)의 수직 섹션: `r/smallbusiness`, `r/Entrepreneur`, `r/SaaS`, `r/healthcare`, `r/manufacturing`
|
||||
- [V2EX](https://www.v2ex.com/)
|
||||
- Jike
|
||||
- Xiaohongshu
|
||||
- 지커
|
||||
- 샤오홍슈
|
||||
|
||||
검색할 때 "AI", "혁신"만 검색하지 마세요. 더 효과적인 검색어는 다음입니다.
|
||||
검색할 때 "AI", "혁신"만 검색하지 말고, 다음을 검색하는 것이 더 효과적입니다:
|
||||
|
||||
- 너무 번거롭다
|
||||
- 더 좋은 방법 없나요
|
||||
- 도구 추천 부탁
|
||||
- Excel로는 관리가 안 된다
|
||||
- 너무 번거로워
|
||||
- 더 좋은 방법이 없을까
|
||||
- 도구 추천해 주세요
|
||||
- Excel로 감당이 안 돼
|
||||
- I wish there was
|
||||
- is there a tool for
|
||||
- I hate
|
||||
@@ -184,104 +184,104 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
|
||||
- [Fiverr](https://www.fiverr.com/)
|
||||
- [Upwork](https://www.upwork.com/)
|
||||
- Zhu Bajie
|
||||
- 주바지에왕
|
||||
- 타오바오
|
||||
- Xianyu
|
||||
- 셴위
|
||||
|
||||
다음 서비스가 잘 팔리는 것을 보면 계속 조사할 가치가 있습니다.
|
||||
이런 서비스가 꽤 잘 팔린다면 계속 조사해 볼 가치가 있습니다:
|
||||
|
||||
- PDF 견적서를 Excel로 정리해 주기
|
||||
- 고객 자료를 대량 정리해 주기
|
||||
- 이력서/문구 수정, 녹취, 아카이빙 대행
|
||||
- PDF 견적서를 Excel로 정리해 드립니다
|
||||
- 고객 자료를 일괄 정리해 드립니다
|
||||
- 이력서 / 카피 수정 / 전사 / 보관 대행
|
||||
|
||||
이런 서비스 뒤에는 보통 일회성 수요가 아니라 반복적으로 발생하는 워크플로우가 있습니다.
|
||||
이런 서비스의 배후에는 보통 일회성 니즈가 아니라 반복적으로 발생하는 워크플로가 있습니다.
|
||||
|
||||
### idea 목록만 보지 말고 전체 워크플로우를 보세요
|
||||
### idea 목록만 보지 말고 전체 워크플로 보기
|
||||
|
||||
때로는 가장 직접적인 방법이 하나의 산업을 골라 프로세스를 한 번 훑고, 아직 WeChat, Excel, 종이와 펜, 전화에 의존하는 단계를 찾는 것입니다.
|
||||
때로는 가장 직접적인 방법은 하나의 산업을 골라 프로세스를 전부 살펴보고, 위챗, Excel, 종이와 펜, 전화로 아직 처리하는 단계를 찾는 것입니다.
|
||||
|
||||
- 무역: 공급업체 찾기, 문의, 가격 비교, 견적서 만들기, 고객에게 보내기, 회신 추적, 검품 준비, 선적 예약, 통관.
|
||||
볼 만한 진입점: 공급업체 견적을 고객용 견적서로 정리하기.
|
||||
- 치과: 접수, 촬영, 영상 판독, 치료 방안 소통, 후속 관리, 치료, 재진.
|
||||
볼 만한 진입점: 환자에게 치료 방안을 설명하고 계속 후속 관리하기.
|
||||
- 건설 현장: 순찰, 사진 촬영, 단체 채팅방 공유, 보고서 정리, 발주처 제출.
|
||||
볼 만한 진입점: 현장 사진에서 규정 준수 보고서까지.
|
||||
- 무역: 공급업체 찾기, 견적 요청, 가격 비교, 견적서 작성, 고객에게 발송, 답변 추적, 검수 주선, 선복 예약, 세관 신고.
|
||||
주목할 만한 진입점: 공급업체 견적을 고객 견적서로 정리.
|
||||
- 치과 진료소: 접수, 촬영, 판독, 상담, 치료, 추적 관찰, 재진.
|
||||
주목할 만한 진입점: 환자에게 치료 계획을 설명하고 지속적으로 추적 관리.
|
||||
- 건설 현장: 순찰, 사진 촬영, 그룹에 전송, 보고서 정리, 발주처에 전달.
|
||||
주목할 만한 진입점: 현장 사진에서 컴플라이언스 보고서 작성.
|
||||
|
||||
<a id="idea-vc"></a>
|
||||
## [4. VC / 액셀러레이터 출처: "파도가 어디로 치는지" 보기](#top-idea-sources)
|
||||
## [4. VC / 가속기 출처: "파도가 어디로 치는지" 보기](#top-idea-sources)
|
||||
|
||||
이런 출처는 큰 방향을 찾는 데 적합하지만, 검증을 직접 대체하기에는 적합하지 않습니다.
|
||||
이런 출처는 큰 방향을 잡는 데 도움이 되지만, 직접 검증을 대체하기에는 적합하지 않습니다.
|
||||
|
||||
- [Y Combinator — Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
사용법: 진입점을 찾기에 적합합니다. "우리는 누군가 이것을 만들기를 보고 싶다"고 직접 말하는 경우가 많기 때문입니다.
|
||||
활용법: 진입점을 찾기에 적합합니다. "우리는 누군가 이것을 만들어 주길 원한다"고 직접 말하는 경우가 많기 때문입니다.
|
||||
- [a16z — Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
사용법: 큰 트렌드와 분야 판단에 더 가깝습니다. 산업 감각을 만들기에 좋습니다.
|
||||
활용법: 대규모 트렌드와 트랙 판단에 더 치중되어, 업계 감각을 구축하는 데 적합합니다.
|
||||
- [NFX](https://www.nfx.com/)
|
||||
사용법: 창업 주제 묶음을 빠르게 훑기에 적합합니다.
|
||||
활용법: 창업 주제 세트를 빠르게 훑기에 적합합니다.
|
||||
- [Sequoia Capital](https://www.sequoiacap.com/article/)
|
||||
사용법: 반드시 아이디어를 직접 나열하지는 않지만, 어떤 플랫폼 변화와 기회를 설명하는 경우가 많습니다.
|
||||
활용법: 직접 아이디어를 나열하지 않을 수도 있지만, 특정 유형의 플랫폼 변화와 기회를 자주 다룹니다.
|
||||
- [First Round Review](https://review.firstround.com/)
|
||||
사용법: 특정 방향을 깊게 파기에 적합합니다. 반드시 아이디어 목록은 아니지만 글의 품질이 보통 높습니다.
|
||||
활용법: 어떤 방향을 깊이 파고들기에 적합합니다. 아이디어 목록이 아닐 수도 있지만, 글의 질이 보통 매우 높습니다.
|
||||
|
||||
이런 출처의 장점:
|
||||
|
||||
- 앞으로 어떤 방향을 볼 만한지 알려 준다.
|
||||
- 어떤 트랙이 계속 추진될 가능성이 있는지 알려 준다.
|
||||
- 특정 트랙의 맥락에 빠르게 들어가게 해 준다.
|
||||
- 미래에 어떤 방향이 살펴볼 가치가 있는지 알려줄 수 있음
|
||||
- 어떤 트랙이 지속적으로 추진될 가능성이 있는지 알려줄 수 있음
|
||||
- 특정 트랙의 맥락에 빠르게 진입할 수 있게 해줌
|
||||
|
||||
이런 출처의 한계:
|
||||
|
||||
- 보통 투자자 관점이다.
|
||||
- 구체적으로 어떤 역할이 가장 아픈지 반드시 알려 주지는 않는다.
|
||||
- 어떤 프로세스 단계가 가장 막히는지 반드시 알려 주지는 않는다.
|
||||
- 오늘 누가 이미 이것에 돈을 쓰고 있는지 반드시 알려 주지는 않는다.
|
||||
- 보통 투자자 관점
|
||||
- 구체적으로 어떤 역할이 가장 고통스러운지 반드시 알려주지는 않음
|
||||
- 어떤 프로세스 단계가 가장 막히는지 반드시 알려주지는 않음
|
||||
- 오늘 누가 이미 이것에 돈을 지불하고 있는지 반드시 알려주지는 않음
|
||||
|
||||
따라서 더 좋은 사용법은 이 출처들로 방향을 찾고, 다시 참고 제품, 산업 포럼, 조달 정보, 실제 워크플로우로 돌아가 더 구체적인 진입점을 찾는 것입니다.
|
||||
따라서 더 나은 활용법은: 먼저 방향을 잡기 위해 사용하고, 다시 참고 제품, 업계 포럼, 조달 정보와 실제 워크플로에서 더 구체적인 진입점을 찾는 것입니다.
|
||||
|
||||
<a id="idea-path"></a>
|
||||
## [5. "아이디어는 없고 어시스턴트를 만들고 싶다는 것만 아는 사람"에게 가장 적합한 최단 사용 경로](#top-idea-sources)
|
||||
## [5. "아이디어가 없고 어시스턴트 만들기만 아는 사람"에게 가장 적합한 최단 사용 경로](#top-idea-sources)
|
||||
|
||||
가장 짧은 경로 하나만 간다면 이렇게 하세요.
|
||||
최단 경로만 걷는다면 이렇게 하세요:
|
||||
|
||||
1. 1단계, 30분.
|
||||
[r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)를 열고 `Top -> Past Year`로 정렬합니다. 게시물 50개를 빠르게 훑으며 "이건 내가 만들 수 있을 것 같다"고 느끼는 방향을 모두 저장합니다.
|
||||
2. 2단계, 30분.
|
||||
[Starter Story](https://www.starterstory.com/) 또는 [Indie Hackers Products](https://www.indiehackers.com/products)를 열어 수익 순으로 정렬합니다. 중간 정도 수익의 제품을 보세요. 가장 성공한 제품만 보지 마세요. 1단계와 관련 있는 방향을 찾아, 그들이 정확히 누구에게 팔고 어느 단계를 해결하는지 봅니다.
|
||||
3. 3단계, 20분.
|
||||
[Google Trends](https://trends.google.com/)에서 관련 키워드를 검색해 추세가 성장 중인지 보고, "관련 검색어"의 급상승 단어를 봅니다.
|
||||
4. 4단계, 20분.
|
||||
G2 / Capterra / 산업 포럼 / 입찰 플랫폼 / Fiverr 같은 곳에서 이 방향의 오늘 가장 짜증 나는 지점이 어디인지, 아직 어디가 수작업에 의존하는지 봅니다.
|
||||
1. 첫 번째 단계, 30분.
|
||||
[r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)를 열고 `Top -> Past Year`로 정렬하여 게시물 50개를 빠르게 훑고, "이건 내가 할 수 있을 것 같은" 방향을 모두 먼저 저장합니다.
|
||||
2. 두 번째 단계, 30분.
|
||||
[Starter Story](https://www.starterstory.com/)나 [Indie Hackers Products](https://www.indiehackers.com/products)를 열고 수익순으로 정렬하여 중간 수익 제품을 보세요. 가장 성공한 것만 보지 마세요. 첫 번째 단계와 관련된 방향을 찾아, 그들이 구체적으로 누구에게 무엇을 파는지, 어느 단계를 해결하는지 보세요.
|
||||
3. 세 번째 단계, 20분.
|
||||
[Google Trends](https://trends.google.com/)에서 관련 키워드를 검색하고, 트렌드가 성장하고 있는지 확인한 후 "관련 검색어"의 급증 단어를 보세요.
|
||||
4. 네 번째 단계, 20분.
|
||||
G2 / Capterra / 업계 포럼 / 입찰 플랫폼 / Fiverr 같은 곳에서 이 방향이 오늘 어디가 가장 번거롭고, 어디가 여전히 수작업에 의존하는지 확인합니다.
|
||||
|
||||
다 보고 나서 아래 문장을 명확히 말할 수 있으면 충분합니다.
|
||||
다 본 후 다음 문장을 명확하게 말할 수 있으면 충분합니다:
|
||||
|
||||
- 어떤 유형의 사람이, 어떤 장면에서, 어느 프로세스 단계에 막혀 있고, 지금은 주로 어떤 서툰 방법으로 버티고 있다.
|
||||
- 특정 유형의 사람이, 특정 시나리오에서, 특정 프로세스 단계에 막혀 있고, 현재 주로 어떤 비효율적인 방법으로 버티고 있다.
|
||||
|
||||
<a id="idea-ai"></a>
|
||||
## [6. AI는 어떻게 도와줄 수 있나](#top-idea-sources)
|
||||
## [6. AI가 어떻게 도와줄 수 있는지](#top-idea-sources)
|
||||
|
||||
이 글의 중점은 AI가 아니지만, AI는 정리에 매우 적합합니다.
|
||||
이 글의 초점은 AI가 아니지만, AI는 정리에 매우 적합합니다.
|
||||
|
||||
가장 실용적인 사용법은 두 가지뿐입니다.
|
||||
가장 실용적인 활용법은 두 가지뿐입니다:
|
||||
|
||||
- 훑어 본 링크, 게시물 제목, 사용자의 원문을 AI에게 붙여 넣고 "사람군 / 장면 / 고통점 / 대체 방안"으로 분류하게 합니다.
|
||||
- AI에게 흩어진 정보를 후보 방향 3개로 수렴하게 합니다. 계속 기능 50개로 발산하게 하지 마세요.
|
||||
- 훑은 링크, 게시물 제목, 사용자의 원래 말을 AI에게 붙여넣어 "사용자군 / 시나리오 / 페인포인트 / 대체 방안"으로 분류해 달라고 요청하기
|
||||
- AI에게 흩어진 정보를 3개의 후보 방향으로 정리해 달라고 요청하고, 50개의 기능으로 계속 발산하지 않기
|
||||
|
||||
바로 이렇게 물어볼 수 있습니다.
|
||||
이렇게 직접 물어볼 수 있습니다:
|
||||
|
||||
```text
|
||||
최근에 이런 출처들을 봤어.
|
||||
1. [제목이나 원문 붙여넣기]
|
||||
2. [제목이나 원문 붙여넣기]
|
||||
3. [제목이나 원문 붙여넣기]
|
||||
최근 다음 출처를 훑었습니다:
|
||||
1. [제목이나 원래 말 붙여넣기]
|
||||
2. [제목이나 원래 말 붙여넣기]
|
||||
3. [제목이나 원래 말 붙여넣기]
|
||||
|
||||
기능 목록을 주지 마.
|
||||
딱 세 가지만 해 줘.
|
||||
1. 사람군과 장면별로 분류
|
||||
2. 반복해서 나타나는 번거로운 단계 찾기
|
||||
3. 더 구체적인 후보 방향 3개로 정리
|
||||
기능 목록은 주지 마세요.
|
||||
다음 세 가지만 해 주세요:
|
||||
1. 사용자군과 시나리오별로 분류
|
||||
2. 반복적으로 등장하는 번거로운 단계 찾기
|
||||
3. 3개의 더 구체적인 후보 방향으로 정리
|
||||
```
|
||||
|
||||
## 더 읽어 보기
|
||||
## 더 읽어볼 만한 자료
|
||||
|
||||
- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
@@ -299,4 +299,3 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
- [G2](https://www.g2.com/)
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
|
||||
|
||||
@@ -11,487 +11,486 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## 본 장 안내
|
||||
## 이 장의 가이드
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', '사용자 수요', '제품 사고', '수요 인사이트']"
|
||||
coreOutput="실제 수요에 더 가까운 JTBD 문장 1개"
|
||||
expectedOutput="흐릿한 아이디어를 더 구체적인 사용자 장면과 MVP 방향으로 수렴할 수 있음"
|
||||
:tags="['JTBD', '사용자 니즈', '제품 사고', '니즈 인사이트']"
|
||||
coreOutput="실제 니즈에 더 가까운 JTBD 문장 1개"
|
||||
expectedOutput="모호한 아이디어를 더 구체적인 사용자 시나리오와 MVP 방향으로 수렴 가능"
|
||||
>
|
||||
|
||||
많은 사람이 처음 제품을 만들 때 가장 쉽게 하는 실수는 모든 주의를 "내가 어떤 기능을 만들 것인가"에 두는 것입니다. 다른 제품에 지능형 분류가 있으면 나도 넣고 싶고, 자동 요약이 있으면 나도 붙이고 싶고, 다른 사람이 Agent, 멀티모달, 워크플로우를 만들면 나도 빼면 안 될 것 같습니다.
|
||||
많은 사람이 처음 제품을 만들 때, 가장 많이 하는 실수 중 하나는 주의를 전부 "어떤 기능을 만들지"에 집중하는 것입니다. 남이 스마트 분류를 하니까 나도 추가하고 싶고, 남이 자동 요약을 하니까 나도 연동하고 싶고, 남이 Agent, 멀티모달, 워크플로를 만들었으니 나도 빠지면 안 된다고 생각합니다.
|
||||
|
||||
하지만 현실에서 사용자는 "이 기능 이름이 멋있어서" 제품을 쓰는 경우가 드뭅니다. 그들은 더 자주 어떤 구체적인 순간에 어떤 일을 앞으로 밀고 싶어 합니다. 그래서 일시적으로 도구, 서비스, 심지어 사람을 "고용"해 그 한 단계를 완성합니다.
|
||||
하지만 현실에서, 사용자가 "이 기능 이름이 멋져서" 제품을 사용하기로 결정하는 경우는 거의 없습니다. 그들은 특정 순간에, 한 가지 일을 앞으로 밀고 나가고 싶어서, 임시로 도구 하나, 서비스 하나, 심지어 사람 하나를 "고용"하여 이 단계를 완수하도록 돕습니다.
|
||||
|
||||
이것이 바로 **Jobs to Be Done(JTBD)** 방법이 우리에게 상기시키는 것입니다. **사용자는 기능 자체를 구매하는 것이 아니라, 자신이 어떤 진전을 완성하도록 도와주는 해결책을 고용합니다.**
|
||||
이것이 바로 **Jobs to Be Done(JTBD)** 방법론이 우리에게 상기시키려는 것입니다: **사용자는 기능 자체를 구매하는 것이 아니라, 어떤 솔루션을 고용하여 자신의 진전을 완수하려고 합니다.**
|
||||
|
||||
이 글은 가능한 한 쉬운 언어로 JTBD를 처음부터 이해하게 하고, AI 애플리케이션을 만들 때 바로 쓸 수 있는 분석 도구로 바꾸도록 안내합니다.
|
||||
이 글은 가능한 한 알기 쉬운 언어로, 제로에서 JTBD를 이해하고, 이를 AI 애플리케이션을 만들 때 바로 사용할 수 있는 분석 도구로 만들어 드립니다.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 최소 SOP
|
||||
**목적**: 읽고 나면 흐릿한 아이디어를, 기능 이름만 잔뜩 있는 상태가 아니라 실제 사용자 장면이 있는 수요 한 문장으로 수렴하는 법을 더 명확히 알게 됩니다.
|
||||
**목적**: 이 글을 읽은 후, 모호한 아이디어를 실제 사용자 시나리오가 있는 진짜 니즈 한 문장으로 수렴하는 방법을 더 명확히 알게 되며, 머릿속에 기능 이름만 있는 상태에서 벗어나게 됩니다.
|
||||
|
||||
**행동 항목**: 흐릿한 아이디어 1문장을 쓰고, 잠재 사용자 3명에게 "최근 한 번은 어떻게 처리했는지"를 묻고, JTBD 문장 1개로 정리합니다.
|
||||
**실행 항목**: 모호한 아이디어 1문장을 쓰고, 잠재 사용자 3명을 찾아 "최근에 어떻게 처리했는지" 물어본 후, JTBD 문장 1개로 정리합니다.
|
||||
|
||||
**결과**: 더 명확한 수요 가설을 얻고, 첫 버전에서 무엇을 먼저 해결해야 하는지 알게 됩니다.
|
||||
**결과**: 첫 번째 버전에서 먼저 무엇을 해결해야 할지 아는, 더 명확한 니즈 가설을 얻게 됩니다.
|
||||
|
||||
**키워드 이동**: [JTBD란 무엇인가](#jtbd-what) · [한 문장 공식](#jtbd-formula) · [AI는 어떻게 도와줄 수 있나](#jtbd-ai)
|
||||
**키워드 바로가기**: [JTBD란](#jtbd-what) · [한 문장 공식](#jtbd-formula) · [AI가 도와주는 방법](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## 다음 내용을 배우게 됩니다
|
||||
## 배울 내용
|
||||
|
||||
1. Jobs to Be Done이 무엇이고, 왜 "기능 브레인스토밍"보다 실제 수요에 더 가까운지
|
||||
2. "사용자가 원한다고 말한 기능"과 "사용자가 진짜 완료하고 싶은 일"을 구분하는 법
|
||||
3. 간단한 템플릿으로 흐릿한 아이디어를 장면, 트리거, 장애물, 성공 기준으로 분해하는 법
|
||||
4. JTBD를 AI 제품, 인터뷰 질문, 프롬프트 정리에 활용하는 법
|
||||
1. Jobs to Be Done이란 무엇이며, 왜 "기능 브레인스토밍"보다 실제 니즈에 더 가까운지
|
||||
2. "사용자가 원한다고 말한 기능"과 "사용자가 진짜로 완수하고 싶은 일"을 어떻게 구분하는지
|
||||
3. 간단한 템플릿으로 모호한 아이디어를 시나리오, 트리거, 장애물, 성공 기준으로 분해하는 법
|
||||
4. JTBD를 AI 제품, 인터뷰 질문, 프롬프트 정리에 어떻게 활용하는지
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## [1. Jobs to Be Done이란 무엇인가](#top-jtbd)
|
||||
## [1. Jobs to Be Done이란](#top-jtbd)
|
||||
|
||||
Jobs to Be Done은 보통 **JTBD**라고 줄여 부릅니다. 그 핵심 생각은 Clayton Christensen 팀이 널리 알린 고전적인 표현과 관련 있습니다. **사용자는 어떤 제품을 "고용"해 하나의 일을 완성한다**는 것입니다.
|
||||
Jobs to Be Done은 보통 **JTBD**로 줄여 부릅니다. 그 배후의 핵심 아이디어는 Clayton Christensen 팀이 보급한 그 유명한 표현과 관련이 있습니다: **사용자는 어떤 제품을 "고용"하여 한 가지 일을 완수합니다.**
|
||||
|
||||
여기서 말하는 "일"은 할 일 목록의 표면적 동작이 아니라, 사용자가 자신의 상태에서 일으키고 싶은 어떤 **진전**입니다. 예를 들면 다음과 같습니다.
|
||||
여기서 "일"은 투두 리스트의 표면적인 동작이 아니라, 사용자가 자신의 상태에 일어나길 바라는 **진전**입니다. 예를 들어:
|
||||
|
||||
- "AI 회의록 도구가 필요하다"가 아니라, "회의 후 10분 안에 핵심, 할 일, 담당자를 정리해서 기억에 의존해 메모를 보충하지 않고 싶다"
|
||||
- "가계부 App이 필요하다"가 아니라, "돈이 정확히 어디로 갔는지 알고 싶어서 월말에 다시 불안해지고 싶지 않다"
|
||||
- "이력서 최적화기가 필요하다"가 아니라, "그럴듯한 이력서를 더 확신 있게 제출하고 싶고, 매번 지원할 때마다 내가 너무 못 쓴 건 아닌지 의심하고 싶지 않다"
|
||||
- "AI 회의록 도구가 필요해"가 아니라 "회의 후 10분 안에 핵심, 할 일, 담당자를 명확히 정리하고, 더 이상 기억에 의존해 노트를 보충하지 않았으면 좋겠어"
|
||||
- "가계부 App이 필요해"가 아니라 "돈이 어디에 쓰였는지 알고 싶어, 월말에 더 이상 불안해하지 않았으면 좋겠어"
|
||||
- "이력서 최적화 도구가 필요해"가 아니라 "제대로 된 이력서를 더 자신 있게 제출하고 싶어, 매번 제출할 때마다 너무 못 썼다고 의심하고 싶지 않아"
|
||||
|
||||
따라서 **JTBD가 주목하는 것은 제품이 어떻게 생겼는지가 아니라, 사용자가 왜 이 순간 그것을 필요로 하는가입니다.**
|
||||
따라서, **JTBD가 주목하는 것은 제품이 어떻게 생겼는지가 아니라, 사용자가 왜 이 순간에 그것이 필요한지입니다.**
|
||||
|
||||
그래서 겉으로는 서로 달라 보이는 제품도 실제로는 같은 job을 두고 경쟁할 수 있습니다. 사용자가 "출근길을 덜 지루하게 보내고 싶다"면 고용할 수 있는 대상은 숏폼 영상, 팟캐스트, 게임, 채팅, 심지어 잠깐 조는 것일 수 있습니다. 사용자가 "긴 PDF를 빠르게 이해하고 싶다"면 고용할 수 있는 대상은 AI 요약 도구, 인턴, 동료, 억지로 직접 읽기, 또는 일단 안 읽기일 수 있습니다.
|
||||
이것이 왜 겉보기에 다른 제품들이 실제로는 같은 job을 두고 경쟁하는지를 설명합니다. 사용자가 "출근길에 덜 지루하고 싶다"면, 고용할 수 있는 대상은 숏폼 영상, 팟캐스트, 게임, 채팅, 심지어 졸음일 수 있습니다. 사용자가 "긴 PDF를 빨리 이해하고 싶다"면, 고용할 수 있는 대상은 AI 요약 도구, 인턴, 동료, 스스로 억지로 읽기, 또는 그냥 안 읽기일 수 있습니다.
|
||||
|
||||
이 관점으로 문제를 보면 진짜 경쟁자는 대개 "당신과 비슷하게 생긴 다른 App"만이 아니라, **사용자가 현재 받아들일 수 있는 모든 대체 방안**이라는 것을 알게 됩니다.
|
||||
이런 관점으로 문제를 보면, 진짜 경쟁 상대가 보통 "당신과 비슷하게 생긴 다른 앱"이 아니라 **사용자의 현재 모든 수용 가능한 대체 솔루션**이라는 것을 발견하게 됩니다.
|
||||
|
||||
## 2. JTBD는 사용자 페르소나, 기능 목록과 무엇이 다른가
|
||||
## 2. JTBD와 사용자 페르소나, 기능 목록의 차이
|
||||
|
||||
많은 초보자는 수요 분석을 시작할 때 먼저 사용자 페르소나를 씁니다. 25세, 여성, 1선 도시, 직장인, 효율 도구를 좋아하고 새 제품을 시도할 의향이 있음. 이런 정보가 완전히 쓸모없다고 할 수는 없지만, 보통 **한 사람이 왜 이 순간 행동을 취하는지 설명하기에는 부족합니다.**
|
||||
많은 초보자가 요구사항 분석을 시작할 때, 먼저 사용자 페르소나를 작성합니다: 25세, 여성, 1선 도시, 화이트칼라, 효율 도구를 좋아하고, 새로운 제품을 시도하는 것을 좋아합니다. 이런 정보가 완전히 쓸모없는 것은 아니지만, 보통 **한 사람이 왜 이 순간에 행동을 취하는지를 설명하기에는 부족합니다.**
|
||||
|
||||
JTBD는 아래 질문에 더 관심이 있습니다.
|
||||
JTBD는 다음 질문들에 더 관심이 있습니다:
|
||||
|
||||
- 그는 어떤 장면에서 해결책을 찾기로 결정했는가
|
||||
- 당시 정확히 무엇에 막혔는가
|
||||
- 무엇을 다음 단계로 밀고 싶었는가
|
||||
- 지금은 어떤 서툰 방법으로 버티고 있는가
|
||||
- 일이 잘 해결된다면 어떤 결과가 "가치 있었다"고 느끼게 하는가
|
||||
- 어떤 시나리오에서 솔루션을 찾기로 결정했는지
|
||||
- 그때 정확히 무엇에 막혔는지
|
||||
- 무엇을 다음 단계로 밀고 나가고 싶은지
|
||||
- 지금 어떤 비효율적인 방법으로 버티고 있는지
|
||||
- 일이 잘 해결되면, 어떤 결과가 "가치 있었다"고 느끼게 하는지
|
||||
|
||||
즉, **사용자 페르소나는 "이 사람이 대략 누구인가"에 가깝고, JTBD는 "이 사람이 지금 정확히 무엇을 완료하고 싶은가"에 가깝습니다.**
|
||||
즉, **사용자 페르소나는 "이 사람이 대략 누구인지"에 더 가깝고, JTBD는 "이 사람이 지금 정말로 무엇을 완수하고 싶은지"에 더 가깝습니다.**
|
||||
|
||||
마찬가지로 기능 목록도 사람을 쉽게 빗나가게 합니다. 사용자가 "Word로 내보내고 싶어요", "AI 문장 개선이 있으면 좋겠어요", "음성 입력이 필요해요"라고 말할 수 있습니다. 하지만 이것들은 모두 표면 표현입니다. JTBD는 계속 아래로 묻습니다.
|
||||
마찬가지로, 기능 목록도 사람을 잘못된 방향으로 이끌기 쉽습니다. 사용자가 "Word로 내보내고 싶어", "AI 재작성을 원해", "음성 입력을 원해"라고 말하지만, 이것들은 표면적인 표현일 뿐입니다. JTBD는 계속해서 아래로 파고듭니다:
|
||||
|
||||
- 왜 지금 PDF가 아니라 Word 내보내기가 필요한가?
|
||||
- 문장을 고치고 싶은 이유는 문체가 나빠서인가, 아니면 대상에 맞게 바꿔야 해서인가?
|
||||
- 음성 입력이 필요한 이유는 타이핑이 귀찮아서인가, 아니면 자주 걸으면서, 운전하면서, 회의 직후에 바로 기록해야 해서인가?
|
||||
- 왜 지금 PDF가 아니라 Word로 내보내야 하는지?
|
||||
- 재작성을 원하는 것이 글 스타일이 너무 나빠서인지, 아니면 다른 대상에 맞춰야 해서인지?
|
||||
- 음성 입력을 원하는 것이 타자 치기 귀찮아서인지, 아니면 자주 걷거나, 운전하거나, 회의 직후에 바로 기록해야 해서인지?
|
||||
|
||||
많은 경우 **기능은 job의 임시 번역일 뿐**입니다. 기능만 수집하면 "사용자가 말하는 것을 전부 쌓는" 제품이 되기 쉽습니다. 뒤에 있는 job을 볼 수 있어야 진짜로 쓰기 편하고 경쟁력 있는 솔루션을 만들 가능성이 커집니다.
|
||||
많은 경우, **기능은 job의 일시적인 번역일 뿐입니다.** 기능만 수집하면 제품이 "사용자가 말하는 대로 쌓는 것"이 되기 쉽고, 배후의 job을 볼 수 있어야 비로소 정말로 편하고, 정말로 경쟁력 있는 솔루션을 만들 기회가 생깁니다.
|
||||
|
||||
## 3. 제로 베이스도 이해할 수 있는 예시
|
||||
|
||||
복잡한 AI 제품을 서둘러 생각하지 말고, 먼저 생활 속 예시에서 시작해 봅시다.
|
||||
복잡한 AI 제품을 먼저 생각하지 말고, 일상적인 예시로 시작해 봅시다.
|
||||
|
||||
어떤 사람이 아침에 나가기 전 늘 아침을 먹을 시간이 부족해서 지하철역 입구에서 샌드위치와 커피를 자주 산다고 가정해 봅시다. 표면적으로 그는 "아침 식사"를 구매합니다. 하지만 JTBD로 보면 그가 진짜 완료하고 싶은 일은 이럴 수 있습니다.
|
||||
누군가가 아침에 외출하기 전에 항상 아침 식사를 할 시간이 없어서, 지하철역 입구에서 샌드위치와 커피를 자주 산다고 가정해 봅시다. 겉보기에는 그가 "구매"하는 것은 아침 식사입니다; 하지만 JTBD로 보면, 그가 정말로 완수하고 싶은 일은:
|
||||
|
||||
- 바쁜 아침에 가장 머리를 덜 쓰는 방식으로 한 끼를 해결한다.
|
||||
- 회사에 도착하기 전에 배고파 불안해지지 않도록 한다.
|
||||
- 아침 식사 때문에 출근 리듬을 망치지 않는다.
|
||||
- 서두르는 아침에, 가장 적은 뇌력으로 한 끼를 해결
|
||||
- 회사에 도착하기 전에 배가 고파서 허기지지 않게 함
|
||||
- 아침 식사 때문에 통근 리듬이 깨지지 않게 함
|
||||
|
||||
이때 사용자가 고용한 것은 "어떤 고정 브랜드의 샌드위치"가 아니라, 아침을 순조롭게 앞으로 밀어 주는 해결책입니다. 옆 편의점이 더 빠르고, 더 가깝고, 더 안정적이면 그는 원래 선택을 바로 바꿀 수 있습니다.
|
||||
이때 사용자가 고용하는 것은 "어떤 특정 브랜드의 샌드위치"가 아니라, 아침을 순조롭게 진행하는 데 도움이 되는 솔루션입니다. 옆 편의점이 더 빠르고, 더 가깝고, 더 안정적이라면, 그는 즉시 원래 선택을 바꿀 수 있습니다.
|
||||
|
||||
이 논리를 AI 제품으로 옮기면 더 분명해집니다.
|
||||
이 논리를 AI 제품으로 가져오면 더 명확해집니다.
|
||||
|
||||
예를 들어 "AI 회의록 도구"를 만들고 싶다고 합시다. 기능 층위에만 머물면 쉽게 이런 생각을 하게 됩니다.
|
||||
예를 들어 "AI 회의록 도구"를 만들고 싶다고 가정해 봅시다. 기능 수준에서만 멈추면, 쉽게 이런 것들을 생각하기 시작합니다:
|
||||
|
||||
- 오디오 업로드를 지원할까
|
||||
- 화자 분리를 붙일까
|
||||
- Markdown 내보내기를 할까
|
||||
- 할 일을 자동 생성할까
|
||||
- 오디오 업로드를 지원할지 말지
|
||||
- 화자 분리를 연동할지 말지
|
||||
- Markdown으로 내보낼지 말지
|
||||
- 자동으로 할 일을 생성할지 말지
|
||||
|
||||
이것들은 모두 틀리지 않지만 충분하지 않습니다. JTBD로 한 층 더 물으면 사용자가 진짜 완료하고 싶은 것은 다음일 수 있습니다.
|
||||
이것들은 틀린 것이 아니지만, 아직 부족합니다. JTBD로 한 층 더 물으면, 사용자가 진짜로 완수하고 싶은 것은:
|
||||
|
||||
- 회의 후 10분 안에 참석하지 못한 사람에게 논의 결과를 동기화하고 싶다.
|
||||
- 할 일, 담당자, 마감일을 깔끔하게 뽑아 팀이 기억에 의존해 협업하지 않게 하고 싶다.
|
||||
- 회의 내용을 반복 정리하는 시간을 줄이고, 에너지를 의사결정과 추진에 남기고 싶다.
|
||||
- 회의 후 10분 안에, 논의 결과를 회의에 참석하지 않은 사람에게 동기화
|
||||
- 할 일, 담당자, 마감일을 깔끔하게 추출하여, 팀이 기억에 의존해 협업하지 않게 함
|
||||
- 회의 내용을 반복적으로 정리하는 시간을 줄이고, 의사결정과 진행에 에너지 집중
|
||||
|
||||
job이 명확해지면 많은 기능의 우선순위가 자동으로 떠오릅니다. 첫 버전에서 가장 중요한 것은 "12가지 내보내기 형식 지원"이 아니라 다음일 수 있습니다.
|
||||
job이 명확해지면, 많은 기능의 우선순위가 자동으로 떠오릅니다. 첫 번째 버전에서 가장 중요한 것은 "12가지 내보내기 형식 지원"이 아닐 수 있습니다:
|
||||
|
||||
- 회의록 구조가 충분히 명확해야 한다.
|
||||
- 할 일 추출이 안정적이어야 한다.
|
||||
- 공유 링크가 편리해야 한다.
|
||||
- 출력 결과를 팀에 바로 전달할 수 있을 만큼 믿을 수 있어야 한다.
|
||||
- 회의록 구조가 충분히 명확해야 함
|
||||
- 할 일 추출이 안정적이어야 함
|
||||
- 공유 링크가 편리해야 함
|
||||
- 출력 결과를 팀에 바로 전달할 수 있을 만큼 신뢰할 수 있어야 함
|
||||
|
||||
이것이 JTBD의 가치입니다. **"어떤 능력을 쌓을까"에서 "사용자가 어떤 진전을 이루도록 도울까"로 되돌려 줍니다.**
|
||||
이것이 JTBD의 가치입니다: **"어떤 능력을 쌓을지"에서 "사용자가 어떤 진전을 이루도록 도울지"로 되돌려 줍니다.**
|
||||
|
||||
## 4. 쓰기 좋은 JTBD 템플릿
|
||||
## 4. 유용한 JTBD 템플릿
|
||||
|
||||
제로 베이스라면 JTBD를 너무 학술적으로 생각하지 않아도 됩니다. 가장 실용적인 5개 요소만 잡으면 충분합니다.
|
||||
제로 베이스라면, JTBD를 너무 학술적으로 생각하지 마세요. 가장 실용적인 5가지 요소만 먼저 잡으면 됩니다.
|
||||
|
||||
### 4.1 장면
|
||||
### 4.1 시나리오
|
||||
|
||||
사용자는 어떤 순간, 어떤 환경에서 이 제품을 떠올리는가?
|
||||
|
||||
- 회의가 끝난 뒤인가
|
||||
- 상사가 갑자기 자료를 요구할 때인가
|
||||
- 밤에 이력서를 제출하려고 준비할 때인가
|
||||
- 월말에 돈이 또 부족하다는 것을 발견했을 때인가
|
||||
- 회의가 끝난 후
|
||||
- 상사가 갑자기 자료를 요구할 때
|
||||
- 밤에 이력서를 제출하려고 준비할 때
|
||||
- 월말에 돈이 또 부족하다는 것을 발견할 때
|
||||
|
||||
**장면이 없는 수요는 보통 아직 충분히 진짜가 아닙니다.**
|
||||
**시나리오가 없는 니즈는 보통 아직 충분히 실제적이지 않습니다.**
|
||||
|
||||
### 4.2 트리거
|
||||
|
||||
무엇이 그를 즉시 해결책을 찾게 만들었는가?
|
||||
무엇이 그가 즉시 솔루션을 찾기로 결정하게 했는가?
|
||||
|
||||
- 긴 문서에 눌려 어디서부터 봐야 할지 모른다.
|
||||
- 내일 제출해야 하는 자료가 있는데 오늘서야 형식이 엉망이라는 것을 발견했다.
|
||||
- 방금 리더에게 진행 상황을 추궁당했고, 자신이 정리를 제대로 해 두지 않았다는 것을 깨달았다.
|
||||
- 기록을 꾸준히 하고 싶지만 손글씨, 복사, 정리가 모두 너무 번거롭다.
|
||||
- 긴 문서에 압도되어, 어디서부터 읽어야 할지 모름
|
||||
- 내일 자료를 제출해야 하는데, 오늘에야 서식이 엉망이라는 것을 발견
|
||||
- 방금 리더에게 진행 상황을 추궁당해, 자신이 명확히 정리하지 않았다는 것을 깨달음
|
||||
- 기록을 계속하고 싶지만, 손글씨, 복사, 정리가 너무 번거로움
|
||||
|
||||
트리거에는 보통 감정이 함께 있습니다. 이 감정은 매우 중요합니다. 왜냐하면 사용자가 왜 바로 이 순간 행동하게 되는지를 결정하기 때문입니다.
|
||||
트리거는 종종 감정을 동반합니다. 이 감정이 중요한데, 사용자가 왜 이 순간에 행동을 일으키는지를 결정하기 때문입니다.
|
||||
|
||||
### 4.3 완료하고 싶은 진전
|
||||
### 4.3 완수하고 싶은 진전
|
||||
|
||||
그는 단지 "동작 하나"를 하고 싶은 것이 아니라, 자신을 어떤 새로운 상태로 밀어 넣고 싶은가?
|
||||
단지 "동작을 하고 싶은" 것이 아니라, 자신을 어떤 새로운 상태로 밀고 나가고 싶은 것인가?
|
||||
|
||||
- 혼란에서 명확함으로
|
||||
- 불안에서 안심으로
|
||||
- 미룸에서 시작으로
|
||||
- 비효율에서 매끄러움으로
|
||||
- 설명하지 못함에서 바로 전달 가능함으로
|
||||
- 지연에서 시작으로
|
||||
- 비효율에서 순조로움으로
|
||||
- 설명 못 함에서 바로 전달 가능함으로
|
||||
|
||||
이 단계에서 "진전"이라는 단어가 매우 중요합니다. 많은 사람이 진짜로 사는 것은 도구가 아니라 **상태 변화**이기 때문입니다.
|
||||
이 단계에서 "진전"이라는 단어가 매우 핵심적입니다. 왜냐하면 많은 사람이 진짜로 사는 것은 도구가 아니라 **상태 변화**이기 때문입니다.
|
||||
|
||||
### 4.4 현재 대체 방안
|
||||
### 4.4 현재 대체 솔루션
|
||||
|
||||
당신의 제품이 없을 때 그는 지금 어떻게 하는가?
|
||||
당신의 제품이 없을 때, 그는 어떻게 하는가?
|
||||
|
||||
- 수동 복사/붙여넣기
|
||||
- Excel이나 메모장으로 억지로 버티기
|
||||
- 동료에게 부탁하기
|
||||
- 미뤄 두기
|
||||
- 여러 도구 사이를 왔다 갔다 하기
|
||||
- 수동으로 복사 붙여넣기
|
||||
- Excel이나 메모로 버티기
|
||||
- 동료에게 도움 요청
|
||||
- 미루고 아무것도 안 하기
|
||||
- 여러 도구를 오가며 작업
|
||||
|
||||
대체 방안이 누구인지가 곧 당신의 실제 경쟁 환경입니다.
|
||||
대체 솔루션이 누구인지, 그것이 바로 당신의 실제 경쟁 환경입니다.
|
||||
|
||||
### 4.5 성공 기준
|
||||
|
||||
어떤 상태가 되어야 일이 진짜 해결되었다고 볼 수 있는가?
|
||||
일이 어떻게 되어야 정말로 해결된 것인가?
|
||||
|
||||
- 10분 안에 공유 가능한 결과를 얻는다.
|
||||
- 크게 다시 고치지 않아도 다른 사람에게 보낼 수 있다.
|
||||
- 누락, 오류, 잊어버림이 쉽게 생기지 않는다.
|
||||
- 처음 써도 다음에 무엇을 해야 하는지 안다.
|
||||
- 10분 안에 공유 가능한 결과 얻기
|
||||
- 큰 수정 없이 남에게 전달 가능
|
||||
- 항목 누락, 오류, 망각이 적어야 함
|
||||
- 처음 사용해도 다음 단계를 알 수 있어야 함
|
||||
|
||||
"사용자가 어떻게 가치 있다고 판단하는지"조차 말하지 못한다면, 이 방향은 아직 충분히 수렴되지 않았을 가능성이 큽니다.
|
||||
"사용자가 가치 있는지 어떻게 판단하는지"조차 말할 수 없다면, 이 방향은 아마 아직 잘 수렴되지 않은 것입니다.
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## [5. 바로 적용할 수 있는 한 문장 공식](#top-jtbd)
|
||||
## [5. 바로 사용할 수 있는 한 문장 공식](#top-jtbd)
|
||||
|
||||
제품 방향을 정리하고 싶을 때는 먼저 이 매우 실용적인 문장 형식을 사용할 수 있습니다.
|
||||
제품 방향을 정리할 때, 이 매우 실용적인 문장 형식을 먼저 사용해 보세요:
|
||||
|
||||
> __________ 할 때, 나는 __________ 하고 싶다. 그래야 __________ 할 수 있다.
|
||||
> 지금은 __________ 방식으로 겨우 이 일을 해내고 있다.
|
||||
> __________할 때, 나는 __________하고 싶고, __________하기 위해.
|
||||
> 지금 나는 __________을/를 통해서만 겨우 이 일을 완수할 수 있습니다.
|
||||
|
||||
예를 들면:
|
||||
예를 들어:
|
||||
|
||||
> 정보량이 많은 프로젝트 회의가 끝났을 때, 나는 할 일, 담당자, 마감일이 포함된 회의록을 빠르게 얻고 싶다. 그래야 팀에 바로 동기화하고 실행을 추진할 수 있다.
|
||||
> 지금은 기억을 더듬고, 채팅 기록을 뒤지고, 손으로 정리하는 방식으로 겨우 이 일을 해내고 있다.
|
||||
> 정보량이 많은 프로젝트 회의가 끝났을 때, 나는 할 일, 담당자, 마감일이 포함된 회의록을 빠르게 얻고 싶고, 팀에 즉시 동기화하고 실행을 진행하기 위해.
|
||||
> 지금 나는 기억에 의존하고, 채팅 기록을 뒤지고, 수동으로 정리하여 겨우 이 일을 완수할 수 있습니다.
|
||||
|
||||
또 다른 예:
|
||||
또 다른 예시:
|
||||
|
||||
> 새로운 직무에 지원하려고 할 때, 나는 기존 경험을 해당 직무에 더 맞는 표현으로 빠르게 고치고 싶다. 그래야 더 확신 있게 그럴듯한 이력서를 제출할 수 있다.
|
||||
> 지금은 예전 이력서를 반복해서 복사하고, 문구를 손으로 고치고, 마지막에는 점점 더 확신이 없어지는 방식으로 버티고 있다.
|
||||
> 새로운 직무에 지원하려고 준비할 때, 나는 기존 경험을 공고에 더 맞는 버전으로 빠르게 재작성하고 싶고, 제대로 된 이력서를 더 자신 있게 제출하기 위해.
|
||||
> 지금 나는 기존 이력서를 반복적으로 복사하고, 표현을 수동으로 수정하며, 수정할수록 점점 더 불확실해집니다.
|
||||
|
||||
이 한 문장을 이 정도로 명확하게 쓸 수 있다면, 뒤의 페이지 설계, 프롬프트 설계, 기능 우선순위 판단이 훨씬 쉬워집니다.
|
||||
한 문장을 이 정도의 명확도로 쓸 수 있다면, 이후의 페이지 설계, 프롬프트 설계, 기능 우선순위 판단이 훨씬 쉬워집니다.
|
||||
|
||||
## 6. AI 제품을 만들 때 특히 봐야 할 job의 세 층
|
||||
## 6. AI 제품을 만들 때, 특히 봐야 할 세 가지 job 레이어
|
||||
|
||||
많은 AI 제품은 기능 시연 때는 강력해 보이지만 실제 출시 후 사용자를 붙잡지 못합니다. 흔한 이유는 표면 동작만 해결하고 더 깊은 job을 해결하지 못했기 때문입니다.
|
||||
많은 AI 제품이 기능 데모에서는 매우 강력해 보이지만, 실제로 출시된 후 사용자를 유지하지 못합니다. 흔한 원인은 표면적인 동작만 해결하고, 더 깊은 job은 해결하지 못했기 때문입니다.
|
||||
|
||||
하나의 job을 대략 세 층으로 나누어 볼 수 있습니다.
|
||||
job을 대략 세 가지 레이어로 나누어 볼 수 있습니다:
|
||||
|
||||
### 6.1 기능 층
|
||||
### 6.1 기능 레이어
|
||||
|
||||
가장 표면적인 과제는 무엇인가?
|
||||
가장 표면적인 작업은 무엇인가?
|
||||
|
||||
- 문서 요약
|
||||
- 문구 재작성
|
||||
- 카피 재작성
|
||||
- 할 일 추출
|
||||
- 이미지 생성
|
||||
|
||||
사용자가 말로 가장 쉽게 말하는 층입니다.
|
||||
이것은 사용자가 입으로 가장 쉽게 말하는 레이어입니다.
|
||||
|
||||
### 6.2 감정 층
|
||||
### 6.2 감정 레이어
|
||||
|
||||
사용자는 어떤 불편한 감정을 줄이거나 어떤 느낌을 얻고 싶은가?
|
||||
사용자는 어떤 불편함을 줄이고 싶거나, 어떤 느낌을 얻고 싶어 하는가?
|
||||
|
||||
- 덜 당황하고 싶다.
|
||||
- 덜 비전문적으로 보이고 싶다.
|
||||
- 매번 처음부터 시작하고 싶지 않다.
|
||||
- 더 통제감을 갖고 싶다.
|
||||
- 당황하고 싶지 않음
|
||||
- 전문적이지 않아 보이고 싶지 않음
|
||||
- 매번 제로에서 시작하고 싶지 않음
|
||||
- 더 많은 통제감을 원함
|
||||
|
||||
많은 지불 의향은 실제로 감정 층과 큰 관련이 있습니다.
|
||||
많은 결제 의향이 사실 감정 레이어와 큰 관련이 있습니다.
|
||||
|
||||
### 6.3 사회적 층
|
||||
### 6.3 사회 레이어
|
||||
|
||||
사용자는 다른 사람 눈에 어떤 사람으로 보이고 싶은가?
|
||||
사용자는 다른 사람의 눈에 어떤 사람이 되고 싶어 하는가?
|
||||
|
||||
- 더 믿음직해 보이고 싶다.
|
||||
- 팀에서 더 조직적인 사람으로 보이고 싶다.
|
||||
- 고객 앞에서 더 전문적으로 보이고 싶다.
|
||||
- 소셜 플랫폼에서 더 잘 표현하는 사람으로 보이고 싶다.
|
||||
- 더 신뢰할 수 있어 보이고 싶음
|
||||
- 팀에서 조직 능력이 더 있어 보이고 싶음
|
||||
- 고객 앞에서 더 전문적이고 싶음
|
||||
- 소셜 미디어에서 더 표현을 잘하는 사람이고 싶음
|
||||
|
||||
기능 층만 만들면 제품은 쉽게 대체됩니다. 감정 층과 사회적 층까지 이해하면 진짜 끈적한 가치를 찾기 쉬워집니다.
|
||||
기능 레이어만 하면 제품이 대체되기 쉽고; 감정 레이어와 사회 레이어를 동시에 이해하면, 진짜로 끈기 있는 가치를 더 쉽게 찾을 수 있습니다.
|
||||
|
||||
## 7. JTBD로 제품 방향을 거꾸로 걸러내기
|
||||
## 7. JTBD를 역으로 사용해 제품 방향 선별
|
||||
|
||||
이미 제품이 있는 것이 아니라 손에 3~5개의 아이디어가 있고 무엇을 해야 할지 모르겠다면, JTBD는 선별에 매우 적합합니다.
|
||||
때로는 이미 제품이 있는 것이 아니라, 3~5개의 아이디어를 가지고 있고 어떤 것을 만들지 모르는 상황입니다. 이때 JTBD는 선별에 매우 적합합니다.
|
||||
|
||||
각 아이디어를 두고 다음 5가지 질문을 해 보세요.
|
||||
각 아이디어를 가지고, 각각 5가지 질문을 스스로에게 해보세요:
|
||||
|
||||
1. 이 아이디어가 대응하는 장면이 충분히 구체적인가?
|
||||
2. 사용자는 지금 이미 어떤 서툰 방식으로 해결하고 있는가?
|
||||
3. 이 job의 고통감이 충분히 강하거나 충분히 자주 발생하는가?
|
||||
4. 내가 잘 만들면 사용자가 "상태가 좋아졌다"고 분명히 느낄까?
|
||||
5. 첫 버전은 이 job의 핵심 한 단계만 중심으로 작지만 유용하게 만들 수 있을까?
|
||||
1. 이 아이디어에 해당하는 시나리오가 충분히 구체적인지?
|
||||
2. 사용자가 이미 어떤 비효율적인 방법으로 해결하고 있는지?
|
||||
3. 이 job의 고통이 충분히 강하거나, 충분히 빈번한지?
|
||||
4. 내가 잘 만들면, 사용자가 "상태가 좋아졌다"고 명확히 느낄 수 있는지?
|
||||
5. 첫 번째 버전을 이 job의 핵심 단계 하나만 중심으로, 아주 작지만 유용한 버전으로 만들 수 있는지?
|
||||
|
||||
어떤 방향을 끝까지 말해도 "느낌상 재미있다" 정도밖에 말하지 못하고 트리거, 대체 방안, 성공 기준을 말하지 못한다면, 그것은 아직 성숙한 방향이 아니라 흐릿한 영감일 가능성이 큽니다.
|
||||
어떤 방향이 끝까지 말해도 "꽤 흥미로운 것 같다"고만 할 수 있고, 트리거, 대체 솔루션, 성공 기준을 명확히 말할 수 없다면, 그것은 아마 성숙한 방향이 아니라 모호한 영감일 뿐입니다.
|
||||
|
||||
## 8. 사용자 인터뷰에 바로 가져갈 수 있는 질문
|
||||
## 8. 바로 사용자 인터뷰에 가져갈 수 있는 질문
|
||||
|
||||
많은 사람이 조사를 시작하면 "어떤 기능을 원하세요?"라고 묻습니다. 이런 질문은 표면적인 답을 얻기 쉽습니다.
|
||||
많은 사람이 조사를 할 때 "어떤 기능을 원하세요?"라고 묻습니다. 이런 질문은 표면적인 답을 얻기 쉽습니다.
|
||||
|
||||
JTBD에는 아래 질문들이 더 적합합니다.
|
||||
JTBD는 다음 질문들에 더 적합합니다:
|
||||
|
||||
- 최근에 이 문제를 만난 것은 언제인가요?
|
||||
- 최근에 이 문제를 만난 것은 언제였나요?
|
||||
- 그때 무엇을 하고 있었고, 왜 막혔나요?
|
||||
- 결국 어떻게 해결했나요?
|
||||
- 이 과정에서 가장 짜증 나고, 느리고, 불안한 지점은 무엇이었나요?
|
||||
- 도구가 도와준다면 어떤 결과가 정말 유용하다고 느껴질까요?
|
||||
- 어떤 대체 방법을 써 봤나요? 왜 충분하지 않았나요?
|
||||
- 마지막에 어떻게 해결했나요?
|
||||
- 그 과정에서 가장 번거롭고, 가장 느리고, 가장 불안한 곳은 어디였나요?
|
||||
- 도구가 하나 있다면, 어떤 결과가 정말로 유용하다고 느끼게 할까요?
|
||||
- 어떤 대체 방법을 시도해 보셨나요? 왜 충분히 좋지 않았나요?
|
||||
|
||||
이런 질문 방식의 장점은 대화를 상상 속 취향이 아니라 실제 경험으로 되돌린다는 점입니다.
|
||||
이런 질문 방식의 장점은: 대화를 상상 속의 선호에 머물게 하지 않고, 실제 경험으로 되돌린다는 것입니다.
|
||||
|
||||
## 9. AI로 JTBD 분해하기
|
||||
## 9. AI로 JTBD 분해 돕기
|
||||
|
||||
JTBD 자체는 AI가 발명한 것이 아니지만, AI는 JTBD를 정리하고 추출하는 데 매우 적합합니다.
|
||||
|
||||
예를 들어 사용자 피드백 5~10개를 이미 모았다면, 그것을 모델에게 던져 아래 구조로 요약하게 할 수 있습니다.
|
||||
예를 들어 사용자 피드백 5~10개를 이미 수집했다면, 모델에 전달하여 다음 구조로 정리하도록 할 수 있습니다:
|
||||
|
||||
```text
|
||||
제품 리서치 조수 역할을 해 줘.
|
||||
사용자 원문을 줄 테니 먼저 기능 제안을 하지 말고,
|
||||
Jobs to Be Done 프레임워크에 따라 정리해 줘.
|
||||
제품 연구 어시스턴트 역할을 해 주세요.
|
||||
사용자의 원래 말을 몇 개 드리겠습니다. 먼저 기능 제안을 하지 말고,
|
||||
Jobs to Be Done 프레임워크로 정리해 주세요:
|
||||
|
||||
1. 사용자는 어떤 장면에 있는가
|
||||
2. 사용자가 행동하게 된 트리거는 무엇인가
|
||||
3. 사용자가 진짜 완료하고 싶은 진전은 무엇인가
|
||||
4. 현재 대체 방안은 무엇인가
|
||||
5. 사용자가 가장 중요하게 보는 성공 기준은 무엇인가
|
||||
6. 이 피드백들에서 반복해서 등장하는 감정 단어는 무엇인가
|
||||
1. 사용자가 어떤 시나리오에 있는지
|
||||
2. 행동을 촉발한 이벤트가 무엇인지
|
||||
3. 정말로 완수하고 싶은 진전이 무엇인지
|
||||
4. 현재 대체 솔루션이 무엇인지
|
||||
5. 가장 중요하게 생각하는 성공 기준이 무엇인지
|
||||
6. 이 피드백에서 반복적으로 등장하는 감정 단어는 무엇인지
|
||||
|
||||
마지막으로 이 내용을 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.
|
||||
마지막으로, 이 내용을 우선적으로 검증할 가치가 있는 JTBD 가설 3개로 정리해 주세요.
|
||||
```
|
||||
|
||||
이미 아이디어가 있다면 AI에게 1차 수렴을 도와달라고 할 수도 있습니다.
|
||||
이미 아이디어가 있다면, AI에게 첫 번째 수렴을 도와달라고 할 수도 있습니다:
|
||||
|
||||
```text
|
||||
[제품 아이디어]를 만들고 싶어.
|
||||
기능 목록을 바로 주지 말고, Jobs to Be Done 방법으로 분석해 줘.
|
||||
[제품 아이디어]를 만들고 싶습니다.
|
||||
기능 목록을 바로 주지 말고, Jobs to Be Done 방법으로 분석해 주세요:
|
||||
|
||||
1. 이 제품이 섬길 수 있는 구체적인 장면은 무엇인가
|
||||
2. 각 장면에서 사용자가 완료하고 싶은 핵심 job은 무엇인가
|
||||
3. 기존 대체 방안은 무엇인가
|
||||
4. 어떤 job이 MVP 출발점으로 가장 적합한가, 왜 그런가
|
||||
5. 마지막으로 추천하는 job을 명확한 JTBD 문장 한 개로 작성해 줘
|
||||
1. 이 제품이 어떤 구체적인 시나리오를 서비스할 수 있는지
|
||||
2. 각 시나리오에서 사용자가 완수하고 싶은 핵심 job이 무엇인지
|
||||
3. 기존 대체 솔루션은 무엇인지
|
||||
4. 어떤 job이 MVP 출발점으로 가장 적합한지, 왜 그런지
|
||||
5. 최종 추천하는 job을 명확한 JTBD 문장 하나로 작성해 주세요
|
||||
```
|
||||
|
||||
이렇게 하면 처음부터 AI가 "기능 50개 브레인스토밍"으로 끌고 가지 않고, 먼저 방향을 명확하게 말하게 할 수 있습니다.
|
||||
이렇게 하면 처음부터 AI가 "기능 50개를 브레인스토밍"하는 것으로 이끌리지 않고, 먼저 방향을 명확히 할 수 있습니다.
|
||||
|
||||
## 10. 초보자가 가장 흔히 하는 4가지 오해
|
||||
## 10. 초보자의 가장 흔한 4가지 오해
|
||||
|
||||
### 10.1 job을 기능명으로 쓰기
|
||||
### 10.1 job을 기능 이름으로 쓰기
|
||||
|
||||
"AI 요약", "지능형 분류", "자동 생성"은 모두 job이 아닙니다. 그것들은 가능한 구현 방식일 뿐입니다.
|
||||
"AI 요약", "스마트 분류", "자동 생성"은 job이 아니라, 가능한 구현 방식일 뿐입니다.
|
||||
|
||||
### 10.2 사람군을 너무 넓게 쓰기
|
||||
### 10.2 사용자군을 너무 넓게 쓰기
|
||||
|
||||
"모든 직장인", "모든 학생", "모든 창업자"는 보통 너무 넓습니다. 넓을수록 실제 장면을 보기 어려워집니다.
|
||||
"모든 직장인", "모든 학생", "모든 창업자"는 보통 너무 광범위합니다. 넓을수록 실제 시나리오를 보기 어렵습니다.
|
||||
|
||||
### 10.3 사용자가 말하는 것만 듣고, 실제 행동은 보지 않기
|
||||
### 10.3 사용자의 말만 듣고 행동은 보지 않기
|
||||
|
||||
사용자는 자신이 원하는 것을 설명할 수 있지만, 진짜 우선순위는 지금 어떻게 문제를 임시로 해결하고 있는지에 숨어 있는 경우가 많습니다.
|
||||
사용자는 자신이 원하는 것을 설명할 수 있지만, 그의 진짜 우선순위는 종종 현재 어떻게 문제를 대충 해결하는지에 숨어 있습니다.
|
||||
|
||||
### 10.4 처음부터 완전한 플랫폼을 만들려고 하기
|
||||
|
||||
JTBD를 올바르게 여는 방식은 보통 "모든 것을 해결하는 큰 플랫폼을 만들겠다"가 아닙니다. 먼저 한 장면에서 가장 중요한 한 단계를 겨냥하고, 그것을 매우 매끄럽게 만드는 것입니다.
|
||||
JTBD의 올바른 사용법은 보통 "모든 것을 해결하는 대플랫폼을 만들겠다"가 아니라, 먼저 한 시나리오에서 가장 핵심적인 단계 하나를 정조준하여, 그것을 아주 편하게 만드는 것입니다.
|
||||
|
||||
## 11. 정리
|
||||
## 11. 요약
|
||||
|
||||
Jobs to Be Done의 가장 가치 있는 점은 새로운 용어를 하나 주는 것이 아니라, 관찰 관점을 바꿔 준다는 것입니다. **제품 기능만 바라보지 말고, 사용자가 어떤 일을 다음 단계로 밀고 싶어 하는지 바라보세요.**
|
||||
Jobs to Be Done의 가장 가치 있는 부분은 새로운 용어를 주는 것이 아니라, 관찰 관점을 바꿔주는 것입니다: **제품 기능만 바라보지 말고, 사용자가 무엇을 다음 단계로 밀고 나가고 싶은지 바라보세요.**
|
||||
|
||||
다음 질문을 반복해 묻기 시작하면:
|
||||
다음 질문들을 스스로에게 반복해서 물어보기 시작하면:
|
||||
|
||||
- 사용자는 어떤 장면에서 이 제품을 고용하는가
|
||||
- 정확히 어디에서 막혔는가
|
||||
- 지금은 어떤 방식으로 버티고 있는가
|
||||
- 일이 해결되면 상태가 어떻게 변하는가
|
||||
- 사용자가 어떤 시나리오에서 이 제품을 고용하는지
|
||||
- 정확히 어디에 막혀 있는지
|
||||
- 지금 어떤 방법으로 버티고 있는지
|
||||
- 일이 해결되면, 상태가 어떻게 변하는지
|
||||
|
||||
원래 흐릿했던 많은 아이디어가 갑자기 선명해지고, 원래 화려해 보였던 많은 기능이 갑자기 그다지 중요하지 않게 됩니다.
|
||||
원래 모호했던 아이디어가 갑자기 명확해지고, 원래 화려했던 기능도 갑자기 그다지 중요하지 않게 보이는 것을 발견할 것입니다.
|
||||
|
||||
제품을 만들 때, 특히 AI 제품을 만들 때 가장 위험한 것은 처음부터 능력 시연에 빠지는 것입니다. JTBD는 당신의 주의를 진짜 중요한 곳으로 되돌립니다. **사용자가 왜 당신을 필요로 하는가, 그리고 당신은 정확히 어떤 진전을 완성하도록 돕는가.**
|
||||
제품을 만드는 것, 특히 AI 제품을 만드는 데 있어 가장 두려운 것은 처음부터 능력 전시에 빠지는 것입니다. JTBD는 여러분의 주의를 정말로 중요한 곳으로 되돌려 줍니다: **사용자가 왜 당신이 필요한지, 그리고 당신이 정확히 어떤 진전을 도와주고 있는지.**
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## [12. AI로 JTBD를 실천하는 방법](#top-jtbd)
|
||||
## [12. AI를 활용해 JTBD를 실천하는 방법](#top-jtbd)
|
||||
|
||||
JTBD는 AI가 발명한 것이 아니지만, AI는 이 방법 안에서 리서치 조수, 정리 조수, 대조 조수 역할을 하기에 매우 적합합니다. 핵심은 **AI가 사용자를 상상해 대신 결론 내리게 하지 말고, 정리와 확장을 돕게 하는 것**입니다.
|
||||
JTBD는 AI가 발명한 것이 아니지만, AI는 이 방법에서 연구 조수, 정리 조수, 비교 조수로 활용하기에 매우 적합합니다. 핵심은: **AI가 정리와 확장을 돕게 하고, AI가 사용자를 대신해 추측하게 하지 않는 것입니다.**
|
||||
|
||||
다음처럼 사용할 수 있습니다.
|
||||
다음과 같이 활용할 수 있습니다:
|
||||
|
||||
### 12.1 AI에게 흐릿한 아이디어를 JTBD 가설로 바꾸게 하기
|
||||
### 12.1 AI로 모호한 아이디어를 JTBD 가설로 재작성
|
||||
|
||||
머릿속에 "대학생이 인턴십을 찾도록 돕는 도구를 만들고 싶다"처럼 흐릿한 설명만 있다면, 먼저 AI에게 여러 가능한 job으로 나눠 보게 할 수 있습니다.
|
||||
머릿속에 "대학생의 인턴십 찾기를 돕는 도구" 같은 모호한 설명만 있을 때, 먼저 AI에게 이것을 여러 가능한 job으로 분해하도록 요청할 수 있습니다:
|
||||
|
||||
```text
|
||||
지금 흐릿한 제품 아이디어가 있어: [아이디어]
|
||||
기능 목록을 바로 주지 말고, Jobs to Be Done 방식으로 분석해 줘.
|
||||
1. 어떤 구체적인 장면에 대응할 수 있는가
|
||||
2. 각 장면에서 사용자가 진짜 완료하고 싶은 진전은 무엇인가
|
||||
3. 현재 대체 방안은 무엇일 수 있는가
|
||||
4. 어떤 job이 MVP로 먼저 만들기 가장 적합한가
|
||||
마지막에는 각 job을 명확한 JTBD 문장으로 써 줘.
|
||||
모호한 제품 아이디어가 있습니다: [아이디어]
|
||||
기능 목록을 바로 주지 말고, Jobs to Be Done 방식으로 분석해 주세요:
|
||||
1. 어떤 구체적인 시나리오에 해당할 수 있는지
|
||||
2. 각 시나리오에서 사용자가 정말로 완수하고 싶은 진전이 무엇인지
|
||||
3. 현재 대체 솔루션은 무엇일 수 있는지
|
||||
4. 어떤 job을 먼저 MVP로 만드는 것이 가장 적합한지
|
||||
마지막으로 각 job을 명확한 JTBD 문장으로 작성해 주세요.
|
||||
```
|
||||
|
||||
아주 초보적인 입력도 괜찮습니다.
|
||||
입력을 아주 초보적으로 쓸 수도 있습니다:
|
||||
|
||||
```text
|
||||
대학생이 인턴십을 찾는 것을 돕는 무언가를 만들고 싶어.
|
||||
나도 아직 구체적으로 뭘 만들지 잘 모르겠어. 사용자가 정확히 어떤 일을 완료하고 싶은지 같이 생각해 줘.
|
||||
대학생이 인턴십을 찾는 것을 돕는 도구를 만들고 싶어요.
|
||||
구체적으로 무엇을 하는지 아직 잘 모르겠어요. 사용자가 진짜로 무엇을 완수하고 싶은지 생각해 주세요.
|
||||
```
|
||||
|
||||
AI가 주는 유용한 출력은 이렇게 생겼을 수 있습니다.
|
||||
AI의 유용한 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
가능한 JTBD 방향:
|
||||
|
||||
1. 처음 인턴십 지원을 준비할 때, 먼저 무엇을 준비해야 하는지 빠르게 알고 싶다.
|
||||
그래야 정보가 혼란스러워 계속 지원을 미루지 않을 수 있다.
|
||||
1. 처음으로 인턴십에 지원할 때, 먼저 어떤 자료를 준비해야 하는지 빠르게 알고 싶어,
|
||||
정보가 혼란스러워서 계속 지원을 미루지 않았으면 좋겠어.
|
||||
|
||||
2. 어떤 인턴십 공고를 봤을 때, 내가 지원할 가치가 있는지 빠르게 판단하고 싶다.
|
||||
그래야 맞지 않는 공고에 너무 많은 시간을 낭비하지 않을 수 있다.
|
||||
2. 인턴십 공고를 볼 때, 내가 지원할 가치가 있는지 빠르게 판단하고 싶어,
|
||||
적합하지 않은 공고에 너무 많은 시간을 낭비하지 않았으면 좋겠어.
|
||||
|
||||
3. 지원을 시작할 때, 기존 이력서를 직무에 더 맞는 버전으로 바꾸고 싶다.
|
||||
그래야 더 빨리 지원을 완료하고 통과율을 높일 수 있다.
|
||||
3. 지원을 시작할 때, 기존 이력서를 공고에 더 맞는 버전으로 빠르게 수정하고 싶어,
|
||||
더 빨리 지원을 완료하고 합격률을 높이고 싶어.
|
||||
```
|
||||
|
||||
이 출력의 가치는 매우 넓었던 생각 하나를 실제 장면에 가까운 여러 방향으로 나눈다는 데 있습니다.
|
||||
이런 출력의 가치는, 원래 한 문장으로 매우 광범위했던 아이디어를 몇 가지 더 실제 시나리오에 가까운 방향으로 분해해 준다는 것입니다.
|
||||
|
||||
### 12.2 AI에게 인터뷰 원문을 정리하게 하기
|
||||
### 12.2 AI로 인터뷰 원래 말 정리
|
||||
|
||||
사용자 인터뷰를 몇 번 했다면, 인터뷰 기록을 AI에게 주고 반복해서 등장하는 장면, 트리거, 대체 방안, 성공 기준을 추출하게 할 수 있습니다.
|
||||
사용자 인터뷰를 몇 번 이미 했다면, 인터뷰 기록을 AI에게 전달하여 반복적으로 등장하는 시나리오, 트리거, 대체 솔루션, 성공 기준을 추출하도록 할 수 있습니다.
|
||||
|
||||
```text
|
||||
아래는 사용자 5명의 인터뷰 원문이야.
|
||||
먼저 해결책을 주지 말고, JTBD 프레임워크에 따라 정리해 줘.
|
||||
1. 사용자는 어떤 장면에 있는가
|
||||
2. 사용자가 행동하게 된 트리거는 무엇인가
|
||||
3. 사용자가 진짜 완료하고 싶은 진전은 무엇인가
|
||||
4. 현재 대체 방안은 무엇인가
|
||||
5. 사용자가 가장 중요하게 여기는 성공 기준은 무엇인가
|
||||
6. 여러 사용자에게 반복해서 나타난 정보는 무엇인가
|
||||
마지막에는 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.
|
||||
다음은 5명의 사용자 인터뷰 원래 말입니다.
|
||||
먼저 솔루션을 제시하지 말고, JTBD 프레임워크로 정리해 주세요:
|
||||
1. 사용자가 어떤 시나리오에 있는지
|
||||
2. 행동을 촉발한 이벤트가 무엇인지
|
||||
3. 정말로 완수하고 싶은 진전이 무엇인지
|
||||
4. 현재 대체 솔루션이 무엇인지
|
||||
5. 가장 중요하게 생각하는 성공 기준이 무엇인지
|
||||
6. 어떤 정보가 여러 사용자에게서 반복적으로 등장하는지
|
||||
마지막으로 우선적으로 검증할 가치가 있는 JTBD 가설 3개로 정리해 주세요.
|
||||
```
|
||||
|
||||
아주 간단한 초보자 입력도 이렇게 쓸 수 있습니다.
|
||||
아주 간단한 초보자 입력도 가능합니다:
|
||||
|
||||
```text
|
||||
3명에게 물어봤는데, 대략 이렇게 말했어.
|
||||
3명에게 물어봤어요. 대략 이렇게 말했어요:
|
||||
|
||||
1. 인턴십에 지원할 때마다 이력서를 다시 고쳐야 해서 너무 귀찮다.
|
||||
2. 사실 가장 두려운 건 내가 잘 썼는지 모르겠다는 것이다.
|
||||
3. 지금은 선배에게 먼저 봐 달라고 하는데, 매번 부탁하기가 미안하다.
|
||||
1. 인턴십에 지원할 때마다 이력서를 다시 수정해야 해서 정말 번거로워.
|
||||
2. 사실 제일 무서운 건 내가 제대로 썼는지 모르는 거야.
|
||||
3. 지금은 선배나 조카에게 봐달라고 부탁하는데, 매번 부탁하기가 미안해.
|
||||
|
||||
그들이 진짜 완료하고 싶은 일이 무엇인지 정리해 줘.
|
||||
정리해 줘. 그들이 진짜로 완수하고 싶은 일이 뭔지.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
정리 결과:
|
||||
|
||||
- 공통 장면: 인턴십 지원 준비 전, 이력서를 처리해야 함
|
||||
- 공통 어려움: "충분히 좋은" 상태까지 수정했는지 판단하지 못함
|
||||
- 현재 대체 방안: 선배에게 봐 달라고 부탁하거나 직접 반복 수정
|
||||
- 공통 시나리오: 인턴십 지원 전, 이력서를 처리해야 함
|
||||
- 공통 어려움: "충분히 좋게" 수정하는 방법을 모름
|
||||
- 현재 대체 솔루션: 선배나 조카에게 검토 부탁, 스스로 반복 수정
|
||||
- 가능한 JTBD:
|
||||
인턴십 지원을 준비할 때, 이력서가 이미 지원 가능한 수준인지 더 빨리 판단하고 싶다.
|
||||
그래야 "조금만 더 고쳐 보자"에 계속 막혀 지원을 미루지 않을 수 있다.
|
||||
인턴십에 지원할 준비를 할 때, 이력서가 이미 지원 가능한 수준에 도달했는지 더 빨리 판단하고 싶어,
|
||||
"좀 더 수정해야지"에 계속 갇혀 지원을 못 하는 상황을 피하고 싶어.
|
||||
```
|
||||
|
||||
이 출력은 유용합니다. 흩어진 원문 속에서 더 "수요"에 가까운 것을 뽑아 주기 때문입니다.
|
||||
이런 출력은 매우 유용합니다. 왜냐하면 산발적인 원래 말에서 "니즈"에 더 가까운 것을 추출해 주기 때문입니다.
|
||||
|
||||
### 12.3 AI에게 가벼운 웹 조사를 한 번 맡기기
|
||||
### 12.3 AI로 가벼운 온라인 조사 대행
|
||||
|
||||
대규모 인터뷰를 시작하기 전, AI에게 아주 가벼운 외부 정보 스캔을 맡길 수 있습니다. 예를 들면 다음입니다.
|
||||
대규모 인터뷰를 시작하기 전에, AI에게 아주 가벼운 외부 정보 스캔을 먼저 맡길 수 있습니다. 예를 들어:
|
||||
|
||||
- 공개 포럼이나 커뮤니티에서 사람들이 이 문제를 어떻게 불평하는가
|
||||
- 시장에 이미 있는 제품들은 주로 어느 층의 문제를 해결하는가
|
||||
- 사용자가 가장 흔히 쓰는 대체 방안은 무엇인가
|
||||
- 흔한 평가에서 사람들이 가장 만족하고 불만족하는 지점은 무엇인가
|
||||
- 공개 포럼이나 커뮤니티에서, 사람들이 이 문제를 어떻게 불만을 제기하는지
|
||||
- 시장에 이미 있는 제품이 주로 어떤 레이어의 문제를 해결하는지
|
||||
- 사용자의 가장 흔한 대체 솔루션이 무엇인지
|
||||
- 흔한 평가에서, 사람들이 가장 만족하는 점과 가장 불만족스러운 점이 무엇인지
|
||||
|
||||
이 조사는 실제 사용자 인터뷰를 대체할 수 없지만, Discover 단계의 워밍업으로 매우 적합하며 먼저 문제 지도를 만드는 데 도움을 줍니다.
|
||||
이런 조사는 실제 사용자 인터뷰를 대체할 수 없지만, Discover 단계의 준비 운동으로 매우 적합하여, 먼저 문제 지도를 구축하는 데 도움이 됩니다.
|
||||
|
||||
간단한 입력 예시는 다음입니다.
|
||||
간단한 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
조사해 줘.
|
||||
"대학생이 이력서를 고치고 인턴십에 지원할 때 가장 흔히 겪는 고통은 무엇인가?"
|
||||
공개 포럼, 경험 글, 취업 커뮤니티에서 사람들이 직접 말한 내용을 우선 봐 줘.
|
||||
가장 흔한 문제 5개로 정리해 줘.
|
||||
조사해 주세요:
|
||||
"대학생이 이력서를 수정하고 인턴십에 지원할 때 가장 흔한 페인포인트는 무엇인가요?"
|
||||
공개 포럼, 경험 글, 구직 커뮤니티에서 사람들이 직접 한 말을 우선으로 봐 주세요.
|
||||
가장 흔한 문제 5가지로 정리해 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
흔한 고통 정리:
|
||||
흔한 페인포인트 정리:
|
||||
|
||||
1. 이력서에 무엇을 써야 할지 모르고 경험이 너무 적다.
|
||||
2. 직무마다 어떻게 다르게 수정해야 할지 모른다.
|
||||
3. 여러 번 고쳤지만 충분히 좋은지 계속 확신하지 못한다.
|
||||
4. 믿을 만한 사람에게 봐 달라고 하기 어렵다.
|
||||
5. 지원 절차가 복잡해 쉽게 미룬다.
|
||||
1. 이력서에 뭘 써야 할지 모름, 경험이 너무 적음
|
||||
2. 다른 직무에 맞게 어떻게 수정해야 할지 모름
|
||||
3. 여러 버전을 수정했지만, 여전히 충분히 좋은지 확신이 안 됨
|
||||
4. 신뢰할 수 있는 사람에게 검토를 부탁할 수 없음
|
||||
5. 지원 프로세스가 복잡해서, 미루기 쉬움
|
||||
```
|
||||
|
||||
이런 출력은 최종 결론으로 삼을 수는 없지만, 어떤 문제를 먼저 인터뷰할지 결정하는 데 적합합니다.
|
||||
이런 출력은 최종 결론으로 사용할 수 없지만, 어떤 문제를 우선적으로 인터뷰할지 결정하는 데 먼저 도움이 됩니다.
|
||||
|
||||
### 12.4 AI에게 "반대편" 역할을 맡기기
|
||||
### 12.4 AI를 "반대편 역할"로 활용
|
||||
|
||||
많은 경우 우리는 자기 아이디어에 감정적으로 너무 붙어 있습니다. AI에게 일부러 비판하는 사람 역할을 맡겨 문제를 더 명확하게 말하도록 압박할 수 있습니다.
|
||||
많은 경우, 우리는 자신의 아이디어에 너무 감정적으로 빠집니다. AI에게 특히 비판적인 역할을 맡겨, 문제를 더 명확하게 말하도록 강제할 수 있습니다:
|
||||
|
||||
```text
|
||||
매우 엄격한 제품 리서치 컨설턴트 역할을 해 줘.
|
||||
아래는 내 JTBD 가설이야: [가설]
|
||||
다음 관점에서 비판해 줘.
|
||||
1. 이 장면이 너무 넓은가
|
||||
2. 이 job이 진짜 진전이 아니라 기능으로 쓰였는가
|
||||
3. 대체 방안이 너무 약한가
|
||||
4. 성공 기준이 충분히 명확하지 않은가
|
||||
5. 이 가설에서 가장 먼저 검증해야 할 위험은 무엇인가
|
||||
매우 엄격한 제품 연구 컨설턴트 역할을 해 주세요.
|
||||
다음은 내 JTBD 가설입니다: [가설]
|
||||
다음 관점에서 비판해 주세요:
|
||||
1. 이 시나리오가 너무 넓은지
|
||||
2. 이 job이 진정한 진전이 아니라 기능으로 작성되었는지
|
||||
3. 대체 솔루션이 너무 약한지
|
||||
4. 성공 기준이 충분히 명확하지 않은지
|
||||
5. 이 가설에서 가장 검증이 필요한 위험이 무엇인지
|
||||
```
|
||||
|
||||
이렇게 하면 당신이 수요를 보고 있는지, 아니면 좋아하는 솔루션만 보고 있는지 더 빨리 발견할 수 있습니다.
|
||||
이렇게 하면 자신이 니즈를 보고 있는지, 아니면 자신이 좋아하는 솔루션만 보고 있는지 더 빨리 발견할 수 있습니다.
|
||||
|
||||
## 📚 Assignments
|
||||
## 📚 과제
|
||||
|
||||
위 내용을 바탕으로 다음 과제를 완료하세요.
|
||||
위 내용을 바탕으로 다음 과제를 완료해 주세요:
|
||||
|
||||
1. 최근 만들고 싶은 제품 아이디어 하나를 고르고, JTBD 공식 한 문장으로 명확하게 쓰세요.
|
||||
2. 이 아이디어에 5개 요소를 보충하세요: 장면, 트리거, 진전, 대체 방안, 성공 기준.
|
||||
3. 잠재 사용자 3명을 찾아 최소 한 번은 "최근에 이 문제를 만난 것은 언제였나요?"라고 물어보세요.
|
||||
4. 인터뷰 원문을 AI에게 주고 검증 우선순위가 높은 JTBD 가설 3개로 정리하세요.
|
||||
1. 최근에 만들고 싶은 제품 아이디어를 하나 골라, JTBD 공식 한 문장으로 명확하게 작성하세요
|
||||
2. 이 아이디어에 대해 5가지 요소를 보완하세요: 시나리오, 트리거, 진전, 대체 솔루션, 성공 기준
|
||||
3. 잠재 사용자 3명을 찾아, 적어도 한 번은 "최근에 이 문제를 만난 것이 언제였나요"라고 물어보세요
|
||||
4. 인터뷰 원래 말을 AI에게 전달하여, 우선적으로 검증할 가치가 있는 JTBD 가설 3개로 정리하세요
|
||||
|
||||
## 더 읽어 보기
|
||||
## 더 읽어볼 만한 자료
|
||||
|
||||
- [Christensen Institute: Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/)
|
||||
- [Harvard Business School Online: What Is Jobs to Be Done?](https://online.hbs.edu/blog/post/jobs-to-be-done)
|
||||
- [Intercom: Jobs-to-be-Done: A framework for customer needs](https://www.intercom.com/blog/jobs-to-be-done-framework/)
|
||||
- [Mural: Jobs to Be Done framework guide](https://www.mural.co/blog/jobs-to-be-done-framework)
|
||||
|
||||
|
||||
@@ -11,198 +11,198 @@ const duration = '약 <strong>1.5시간</strong>'
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## 본 장 안내
|
||||
## 이 장의 가이드
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['사용자 인터뷰', '수요 검증', '사용자 리서치', '제품 조사']"
|
||||
coreOutput="진짜 정보를 더 잘 끌어내는 인터뷰 질문 묶음 1개"
|
||||
expectedOutput="사용자의 예의상 격려를 검증으로 착각하지 않고, 실제 행동으로 방향을 판단할 수 있게 됨"
|
||||
:tags="['사용자 인터뷰', '수요 검증', '사용자 조사', '제품 조사']"
|
||||
coreOutput="실제 정보를 더 잘 끌어낼 수 있는 인터뷰 질문 세트 1개"
|
||||
expectedOutput="사용자의 예의상 응원을 검증으로 받아들이지 않고, 실제 행동으로 방향을 판단하게 됩니다"
|
||||
>
|
||||
|
||||
많은 사람이 처음 제품 조사를 할 때 가장 중요한 것이 "사람을 찾아 이야기해 보는 것"이라고 생각합니다. 그래서 친구, 동료, 심지어 가족에게 묻습니다.
|
||||
많은 사람이 처음 제품 조사를 할 때, 가장 중요한 것이 "누군가와 이야기하는 것"이라고 생각합니다. 그래서 친구, 동료, 심지어 가족에게 물어봅니다:
|
||||
|
||||
- 내 아이디어 어때?
|
||||
- 이런 제품이 있으면 쓸 것 같아?
|
||||
- 이 기능 괜찮아 보이지 않아?
|
||||
- 내 이 아이디어 어때?
|
||||
- 이런 제품이 있다면, 쓸 것 같아?
|
||||
- 이 기능 꽤 괜찮지 않아?
|
||||
|
||||
상대도 보통 매우 힘이 되는 피드백을 줍니다.
|
||||
상대방도 보통 매우 고무적인 피드백을 줍니다:
|
||||
|
||||
- 괜찮은데?
|
||||
- 유용해 보인다
|
||||
- 한번 해 봐도 좋을 것 같아
|
||||
- 꽤 좋은데
|
||||
- 쓸모 있어 보여
|
||||
- 한번 해 보면 좋을 것 같아
|
||||
|
||||
문제는 이런 답변이 대개 판단에 도움이 되지 않는다는 점입니다. 그것들은 예의, 응원, 또는 그 자리에서 당신의 흥을 깨고 싶지 않은 자연스러운 반응에 더 가깝습니다. 당신은 "시장 검증"을 얻었다고 생각하지만, 사실은 의사결정에 쓰기 어려운 위로만 잔뜩 모은 것일 수 있습니다.
|
||||
문제는, 이런 대답이 보통 판단에 도움이 되지 않는다는 것입니다. 그것들은 예의, 지지, 또는 당장 기분을 상하게 하고 싶지 않은 자연스러운 반응에 더 가깝습니다. 자신이 "시장 검증"을 얻었다고 생각하지만, 사실은 판단에 사용하기 어려운 위안을 모았을 뿐입니다.
|
||||
|
||||
The Mom Test 방법은 바로 이 문제를 해결하기 위해 만들어졌습니다. 이 방법은 우리에게 이렇게 상기시킵니다. **사용자가 일부러 당신을 속이는 것이 아니라, 당신의 질문 방식이 상대를 듣기 좋지만 쓸모없는 답으로 자연스럽게 이끈다**는 것입니다.
|
||||
The Mom Test 방법론은 바로 이 문제를 해결하기 위해 만들어졌습니다. 이것은 우리에게 상기시킵니다: **사용자가 일부러 거짓말을 하는 것이 아니라, 질문하는 방식 자체가 상대를 듣기 좋지만 쓸모없는 대답으로 자연스럽게 유도하고 있는 것입니다.**
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 최소 SOP
|
||||
**목적**: 읽고 나면 사용자와 어떻게 이야기해야 "듣기 좋다"만 듣지 않고, 방향 판단에 도움이 되는 정보를 실제로 물어낼 수 있는지 더 명확해집니다.
|
||||
**목적**: 이 글을 읽은 후, 사용자와 어떻게 대화해야 "꽤 좋아 보인다"만 듣지 않고, 정말로 방향을 판단하는 데 도움이 되는 정보를 끌어낼 수 있는지 더 명확히 알게 됩니다.
|
||||
|
||||
**행동 항목**: 원래 물어보려던 질문 5개를 바꾸고, 우선 "최근 한 번은 언제였나요", "그때 어떻게 처리했나요"를 묻습니다.
|
||||
**실행 항목**: 원래 물어보려고 했던 5개의 질문을 바꾸고, "최근에 언제 일어났는지", "그때 어떻게 처리했는지"를 우선으로 물어보세요.
|
||||
|
||||
**결과**: 무엇이 의견이고, 무엇이 판단을 뒷받침하는 증거인지 더 쉽게 구분할 수 있습니다.
|
||||
**결과**: 어떤 것이 의견이고, 어떤 것이 판단을 뒷받침할 수 있는 진짜 증거인지 더 쉽게 구분할 수 있게 됩니다.
|
||||
|
||||
**키워드 이동**: [The Mom Test란 무엇인가](#mom-what) · [세 가지 핵심 원칙](#mom-principles) · [AI는 어떻게 도와줄 수 있나](#mom-ai)
|
||||
**키워드 바로가기**: [The Mom Test란](#mom-what) · [세 가지 핵심 원칙](#mom-principles) · [AI가 도와주는 방법](#mom-ai)
|
||||
:::
|
||||
|
||||
## 다음 내용을 배우게 됩니다
|
||||
## 배울 내용
|
||||
|
||||
1. The Mom Test가 정확히 어떤 문제를 해결하는지, 왜 많은 "사용자 조사"가 실제 정보를 조사하지 못하는지
|
||||
2. 이 방법의 핵심 원칙: 의견은 적게 묻고 행동을 더 묻기, 가정보다는 사실을 더 묻기
|
||||
3. 거짓 양성 피드백을 쉽게 얻는 질문을 더 가치 있는 인터뷰 질문으로 바꾸는 법
|
||||
4. The Mom Test를 JTBD, 수요 검증, MVP 판단과 연결해 사용하는 법
|
||||
1. The Mom Test가 정확히 무엇을 해결하는지, 왜 많은 "사용자 조사"가 사실 실제 정보를 조사하지 못했는지
|
||||
2. 이 방법의 가장 핵심적인 몇 가지 원칙: 의견은 적게 묻고, 행동은 많이 묻기; 가정은 적게 묻고, 사실은 많이 묻기
|
||||
3. 가양성 피드백을 얻기 쉬운 질문을 어떻게 더 가치 있는 인터뷰 질문으로 바꾸는지
|
||||
4. The Mom Test를 JTBD, 수요 검증, MVP 판단과 어떻게 연결해서 사용하는지
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## [1. The Mom Test란 정확히 무엇인가](#top-mom)
|
||||
## [1. The Mom Test란 무엇인가](#top-mom)
|
||||
|
||||
The Mom Test는 Rob Fitzpatrick의 동명 책에서 나온 방법입니다. 이름은 농담처럼 들리지만 핵심을 아주 정확히 찌릅니다.
|
||||
The Mom Test는 Rob Fitzpatrick의 동명의 책에서 유래했습니다. 이름은 농담처럼 들리지만, 핵심은 매우 정확합니다:
|
||||
|
||||
**당신의 엄마조차도 "이건 별로인 아이디어야"라고 직접 말하기는 어렵습니다.**
|
||||
**당신의 엄마조차도 "이건 형편없는 아이디어야"라고 직접 말하기 어렵습니다.**
|
||||
|
||||
그 이유는 엄마가 정직하지 않아서가 아닙니다.
|
||||
그 이유는 그녀가 정직하지 않아서가 아니라:
|
||||
|
||||
- 당신을 상처 입히고 싶지 않습니다.
|
||||
- 무의식적으로 당신을 격려합니다.
|
||||
- 당신의 표현 방식에 맞춰 쉽게 대답합니다.
|
||||
- 당신을 상처 주고 싶지 않아서
|
||||
- 무의식적으로 당신을 응원하게 되어서
|
||||
- 당신의 표현 방식에 따라 대답하기 쉬워서
|
||||
|
||||
사실 엄마뿐 아니라 친구, 동료, 예전 동창, 심지어 많은 낯선 사람도 당신의 제품 아이디어를 마주하면 비슷한 "긍정 피드백"을 주는 경우가 많습니다. 이것은 수요가 진짜 있다는 뜻이 아니라, 질문을 듣기 좋은 답이 나오기 쉬운 형태로 했다는 뜻입니다.
|
||||
사실 엄마뿐만 아니라, 친구, 동료, 예전 동학, 심지어 많은 낯선 사람도 당신의 제품 아이디어 앞에서 비슷한 "긍정적 피드백"을 줍니다. 이것이 수요가 정말로 존재한다는 것을 의미하지는 않으며, 단지 당신이 질문을 누구나 당신의 대답에 맞춰주기 쉬운 형태로 만들었다는 것을 의미할 뿐입니다.
|
||||
|
||||
그래서 The Mom Test의 핵심은 "엄마에게 묻지 마라"가 아닙니다.
|
||||
그래서 The Mom Test의 핵심은 결코 "엄마에게 묻지 마라"가 아니라:
|
||||
|
||||
**누구라도 당신에게 맞장구치게 만드는 형태로 질문하지 말라는 것입니다.**
|
||||
**누구에게나 당신의 대답에 맞춰주게 만드는 방식으로 질문하지 마라.**
|
||||
|
||||
이 방법이 진짜로 가르치려는 것은 대화를 통해 실제 수요에 더 가까운 정보를 얻는 법이지, 스스로 기분 좋아지는 댓글을 잔뜩 모으는 법이 아닙니다.
|
||||
이 방법이 정말로 가르치고 싶은 것은, 대화를 통해 실제 수요에 더 가까운 정보를 얻는 방법이며, 자신을 기분 좋게 하는 댓글을 모으는 것이 아닙니다.
|
||||
|
||||
## 2. 해결하는 핵심 문제는 무엇인가
|
||||
## 2. 해결하려는 핵심 문제
|
||||
|
||||
The Mom Test가 주로 해결하는 것은 매우 흔한 인지 착각입니다.
|
||||
The Mom Test가 주로 해결하는 것은 매우 흔한 인지적 착각입니다:
|
||||
|
||||
**예의상 긍정 피드백을 실제 수요로 착각하는 것**입니다.
|
||||
**예의상의 긍정적 피드백을 실제 수요로 착각하는 것.**
|
||||
|
||||
예를 들어 이렇게 묻는다고 해 봅시다.
|
||||
예를 들어 물어본다면:
|
||||
|
||||
- 이 App 아이디어 어때요?
|
||||
- AI가 이력서를 써 주는 도구를 만들면 쓸 것 같아요?
|
||||
- 이 기능은 가치 있어 보이나요?
|
||||
- 이 앱 아이디어 어때요?
|
||||
- AI가 이력서 써주는 도구를 만들면, 쓸 건가요?
|
||||
- 이 기능 가치 있지 않나요?
|
||||
|
||||
이 질문들의 공통점은 다음입니다.
|
||||
이런 질문들의 공통점은:
|
||||
|
||||
- 모두 "의견"을 묻는다.
|
||||
- 모두 약간의 암시를 담고 있다.
|
||||
- 모두 아직 일어나지 않은 미래를 이야기한다.
|
||||
- 모두 "의견"을 묻고 있음
|
||||
- 모두 약간의 암시를 담고 있음
|
||||
- 모두 아직 일어나지 않은 미래에 대해 이야기하고 있음
|
||||
|
||||
사람이 "의견"과 "미래 가정"에 답할 때는 보통 안정적이지 않습니다. 많은 사람은 자신의 흥미, 실행력, 미래 구매 의사를 과대평가합니다.
|
||||
"의견"과 "미래 가정"에 대한 대답은 보통 불안정합니다. 많은 사람이 자신의 흥미, 실행력, 미래의 구매 의향을 과대평가합니다.
|
||||
|
||||
그래서 The Mom Test는 이렇게 알려 줍니다.
|
||||
그래서 The Mom Test는 상기시킵니다:
|
||||
|
||||
- 다른 사람이 내 아이디어를 어떻게 평가하는지 너무 믿지 마세요.
|
||||
- 다른 사람이 미래 행동을 어떻게 예측하는지 너무 믿지 마세요.
|
||||
- 가능한 한 이미 일어난 사용자의 실제 행동으로 돌아가세요.
|
||||
- 다른 사람이 당신의 아이디어에 대한 평가를 너무 믿지 마세요
|
||||
- 다른 사람의 미래 행동 예측을 너무 믿지 마세요
|
||||
- 사용자가 이미 일으킨 실제 행동으로 최대한 되돌아가세요
|
||||
|
||||
"쓸 것 같나요?"보다 "지난번에 이 일을 어떻게 처리했나요?"가 대개 진실에 더 가깝기 때문입니다.
|
||||
"쓸 건가요?"보다 "저번에 이 일 어떻게 처리했어요?"가 보통 진실에 더 가깝기 때문입니다.
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## [3. 세 가지 핵심 원칙](#top-mom)
|
||||
|
||||
가장 중요한 부분만 먼저 기억하고 싶다면 아래 세 가지 원칙을 기억하세요.
|
||||
가장 중요한 부분만 먼저 기억하고 싶다면, 다음 세 가지 원칙을 먼저 기억하세요.
|
||||
|
||||
### 3.1 내 아이디어는 적게 말하고, 사용자의 과거 실제 경험을 더 이야기하게 하기
|
||||
### 3.1 아이디어를 적게 이야기하고, 사용자의 과거 실제 경험을 많이 이야기하기
|
||||
|
||||
많은 무효 인터뷰는 시작하자마자 자기 솔루션을 설명하고, 자신이 얼마나 신났는지 말하고, 어떤 제품을 만들 준비인지 이야기합니다. 문제는 당신이 너무 많이 말하는 순간, 상대가 "맞춰 주기", "격려하기" 모드로 바뀌기 쉽다는 점입니다.
|
||||
많은 비효율적 인터뷰가 처음부터 자신의 솔루션을 설명하고, 자신이 얼마나 흥분했는지, 어떤 제품을 만들려고 하는지 이야기합니다. 문제는, 너무 많이 이야기하면 상대가 쉽게 "협조하기", "응원하기" 상태로 전환된다는 것입니다.
|
||||
|
||||
반대로 더 좋은 방식은 상대의 경험에 초점을 두는 것입니다.
|
||||
반면, 더 나은 방법은 상대방의 경험에 초점을 맞추는 것입니다:
|
||||
|
||||
- 최근에 이 문제를 만난 것은 언제였나요?
|
||||
- 최근에 이 문제를 만난 것이 언제였나요?
|
||||
- 그때 무엇을 하고 있었나요?
|
||||
- 결국 어떻게 처리했나요?
|
||||
- 마지막에 어떻게 처리했나요?
|
||||
- 어느 단계가 가장 번거로웠나요?
|
||||
|
||||
이런 질문은 대화를 상상 속 선호가 아니라 현실로 더 자연스럽게 되돌립니다.
|
||||
이런 질문이 대화를 자연스럽게 현실로 되돌리고, 상상 속의 선호에 머물지 않게 한다는 것을 발견할 것입니다.
|
||||
|
||||
### 3.2 추상적 의견은 적게 묻고, 구체적 사실을 더 묻기
|
||||
### 3.2 추상적 의견은 적게 묻고, 구체적 사실은 많이 묻기
|
||||
|
||||
"이 기능 괜찮은 것 같아요", "듣기에는 좋아요", "조금 쓸모 있어 보이네요" 같은 표현은 너무 추상적이라 제품 의사결정에 쓰기 어렵습니다.
|
||||
"이 기능 꽤 좋은 것 같아", "괜찮아 보여", "좀 쓸모 있을 것 같아" 같은 표현은 모두 너무 추상적이어서, 제품 의사결정을 지도하기 어렵습니다.
|
||||
|
||||
더 가치 있는 정보는 보통 이런 모습입니다.
|
||||
더 가치 있는 정보는 보통 이렇게 생겼습니다:
|
||||
|
||||
- 지난주에 이 일 때문에 2시간을 썼어요.
|
||||
- 지금은 Excel과 WeChat으로 버티고 있어요.
|
||||
- 지난달 이미 비슷한 도구에 돈을 낸 적이 있어요.
|
||||
- 제가 가장 두려운 건 느린 것이 아니라 잘못하는 거예요.
|
||||
- 저번 주에 이 일 때문에 2시간을 낭비했어요
|
||||
- 지금 Excel과 위챗으로 버티고 있어요
|
||||
- 지난달에 비슷한 도구에 이미 돈을 썼어요
|
||||
- 제일 무서운 건 틀리는 거지, 느린 게 아니에요
|
||||
|
||||
이런 정보가 문제 강도, 빈도, 지불 가능성을 판단하는 데 진짜 도움이 됩니다.
|
||||
이것이 바로 문제의 강도, 빈도, 결제 가능성을 판단하는 데 정말로 도움이 되는 정보입니다.
|
||||
|
||||
### 3.3 사용자가 원하는 솔루션을 적게 묻고, 지금 어떻게 해결하는지 더 보기
|
||||
### 3.3 사용자가 어떤 솔루션을 원하는지 적게 묻고, 지금 어떻게 문제를 해결하는지 많이 보기
|
||||
|
||||
사용자는 자신의 어려움을 설명하는 데는 능숙하지만, 해결책을 설계하는 데 항상 능숙하지는 않습니다.
|
||||
사용자는 자신의 고충을 설명하는 데 능숙하지만, 솔루션을 설계하는 데는 반드시 능숙하지는 않습니다.
|
||||
|
||||
이렇게 묻는다면:
|
||||
물어본다면:
|
||||
|
||||
- AI가 자동으로 이걸 해 주면 좋겠어요?
|
||||
- 지능형 기능을 넣으면 도움이 될까요?
|
||||
- AI가 이걸 자동으로 해주면 어떨까요?
|
||||
- 스마트 기능을 추가하면 도움이 될까요?
|
||||
|
||||
대개 얻는 것은 어떤 솔루션에 대한 흐릿한 태도일 뿐, 수요 자체가 아닙니다.
|
||||
얻는 것은 보통 어떤 솔루션에 대한 모호한 태도일 뿐, 수요 자체는 아닙니다.
|
||||
|
||||
더 좋은 질문은 다음입니다.
|
||||
더 나은 질문은:
|
||||
|
||||
- 지금 이 문제를 어떤 방법으로 처리하나요?
|
||||
- 왜 그 방법을 선택했나요?
|
||||
- 그 방법은 어디가 충분하지 않나요?
|
||||
- 지금 이 문제를 어떤 방법으로 처리하시나요?
|
||||
- 왜 이 방식을 선택했나요?
|
||||
- 어디가 충분히 좋지 않나요?
|
||||
|
||||
기존 대체 방안을 명확히 보는 것은 "무엇을 원하세요?"라고 직접 묻는 것보다 훨씬 중요합니다.
|
||||
기존 대체 솔루션을 파악하는 것이 "무엇을 원하시나요"를 직접 묻는 것보다 보통 더 중요합니다.
|
||||
|
||||
## 4. 왜 사람들은 늘 듣기 좋지만 쓸모없는 답을 줄까
|
||||
## 4. 왜 사람들은 항상 듣기 좋지만 쓸모없는 대답을 줄까
|
||||
|
||||
이 점을 이해하면 인터뷰에서 오판이 훨씬 줄어듭니다.
|
||||
이것을 이해하면, 인터뷰에서 오해가 많이 줄어듭니다.
|
||||
|
||||
### 4.1 사람은 무의식적으로 예의를 지킨다
|
||||
### 4.1 사람은 무의식적으로 예의를 지킴
|
||||
|
||||
특히 대화 상대와 관계가 있을 때, 상대는 직접 이렇게 말하기 어렵습니다.
|
||||
특히 대화 상대와 관계가 있을 때, 직접 말하기 어렵습니다:
|
||||
|
||||
- 이 방향은 별로인 것 같아요.
|
||||
- 저는 절대 안 쓸 것 같아요.
|
||||
- 이 문제는 제게 그렇게 중요하지 않아요.
|
||||
- 이 방향은 별로인 것 같아요
|
||||
- 저 절대 안 써요
|
||||
- 이 문제는 저한테 그렇게 중요하지 않아요
|
||||
|
||||
대신 "괜찮은데", "기회가 있으면 해 봐도 좋겠다"라고 말할 가능성이 큽니다.
|
||||
대신 "꽤 좋은데", "기회가 되면 한번 해 봐요"라고 말할 가능성이 높습니다.
|
||||
|
||||
### 4.2 사람은 미래의 자신을 과대평가한다
|
||||
### 4.2 사람은 미래의 자신을 과대평가함
|
||||
|
||||
많은 사람은 자신이 미래에 진심으로 이렇게 될 것이라 믿습니다.
|
||||
많은 사람이 진심으로 미래에 자신이 이렇게 할 것이라고 믿습니다:
|
||||
|
||||
- 더 자율적일 것이다.
|
||||
- 더 열심히 배울 것이다.
|
||||
- 더 기꺼이 돈을 낼 것이다.
|
||||
- 새 도구를 더 기꺼이 시도할 것이다.
|
||||
- 더 자제할 것
|
||||
- 더 열심히 공부할 것
|
||||
- 더 기꺼이 결제할 것
|
||||
- 더 기꺼이 새로운 도구를 시도할 것
|
||||
|
||||
그래서 "있으면 아마 쓸 것 같아요"는 종종 미래에 정말 쓴다는 뜻이 아닙니다.
|
||||
그래서 "있으면 쓸 것 같아요"라는 말은, 종종 미래에 정말로 쓴다는 것과 같지 않습니다.
|
||||
|
||||
### 4.3 질문 방식 자체가 답을 유도한다
|
||||
### 4.3 질문 방식 자체가 대답을 유도함
|
||||
|
||||
이렇게 물을 때:
|
||||
물어본다면:
|
||||
|
||||
- 내 아이디어 괜찮지 않아?
|
||||
- 이 기능이 당신에게 도움이 되지 않을까?
|
||||
- 내 이 아이디어 꽤 좋지 않아?
|
||||
- 이 기능 당신에게 도움이 많이 되지 않아?
|
||||
|
||||
사실 질문 안에 이미 "정답"을 몰래 넣은 것입니다.
|
||||
사실 이미 "정답"을 몰래 질문에 넣은 것입니다.
|
||||
|
||||
그래서 The Mom Test는 특히 강조합니다. **인터뷰를 인정을 구하는 자리로 만들지 마세요.**
|
||||
이것이 The Mom Test가 특히 강조하는 이유입니다: **인터뷰를 인정을 찾는 과정으로 만들지 마세요.**
|
||||
|
||||
## 5. 직접 비교: 어떤 질문은 망하기 쉽고, 어떤 질문은 더 가치 있는가
|
||||
## 5. 직접 비교: 어떤 질문이 망가지기 쉽고, 어떤 질문이 더 가치 있는지
|
||||
|
||||
아래 비교는 거의 모든 초보자가 바로 써먹을 수 있습니다.
|
||||
아래 비교는 거의 모든 초보자가 사용하는 것입니다.
|
||||
|
||||
| 망하기 쉬운 질문 | 더 가치 있는 질문 |
|
||||
| 망가지기 쉬운 질문 | 더 가치 있는 질문 |
|
||||
| --- | --- |
|
||||
| 내 아이디어 어때요? | 최근에 이 문제를 만난 것은 언제였나요? |
|
||||
| 이런 제품이 있으면 쓸 건가요? | 지금은 이 일을 어떻게 처리하고 있나요? |
|
||||
| 이 기능에 돈을 낼 의향이 있나요? | 지난번 이 문제 때문에 돈을 쓴 적이 있나요? 무엇에 썼나요? |
|
||||
| 이 기능이 중요하다고 생각하나요? | 이 흐름에서 가장 짜증 나고, 느리고, 불안한 단계는 무엇인가요? |
|
||||
| AI가 자동으로 도와주면 좋겠나요? | 지금 더 편한 해결책을 아직 찾지 못한 이유는 무엇인가요? |
|
||||
| 내 이 아이디어 어때요? | 최근에 이 문제를 만난 것이 언제였나요? |
|
||||
| 이 제품이 있으면 쓸 건가요? | 지금 이 일을 어떻게 처리하고 계세요? |
|
||||
| 이 기능에 결제할 의향이 있나요? | 저번에 이 문제 때문에 돈을 써본 적이 있나요? 무엇에 썼나요? |
|
||||
| 이 기능이 중요하다고 생각하시나요? | 이 과정에서 가장 번거롭고, 가장 느리고, 가장 불안한 단계는 어디인가요? |
|
||||
| AI가 자동으로 해주면 어떨까요? | 지금 왜 더 편한 해결책을 아직 못 찾았나요? |
|
||||
|
||||
이 표에서 가장 중요한 것은 구체적인 문장이 아니라 그 뒤의 방향입니다.
|
||||
이 표에서 가장 중요한 것은 구체적인 문장이 아니라, 배후의 방향입니다:
|
||||
|
||||
- 의견에서 사실로
|
||||
- 미래에서 과거로
|
||||
@@ -210,381 +210,380 @@ The Mom Test가 주로 해결하는 것은 매우 흔한 인지 착각입니다.
|
||||
|
||||
## 6. 제로 베이스도 바로 사용할 수 있는 인터뷰 리듬
|
||||
|
||||
지금 바로 사람을 찾아 이야기하고 싶다면 아래 순서를 그대로 따라도 됩니다.
|
||||
지금 당장 누군가와 이야기하러 가고 싶다면, 다음 순서대로 진행하세요.
|
||||
|
||||
### 6.1 시작: 내가 배우는 중이지 팔려고 온 것이 아니라고 설명하기
|
||||
### 6.1 시작: 판매가 아니라 학습하고 있다고 설명
|
||||
|
||||
예를 들면:
|
||||
예를 들어:
|
||||
|
||||
> 요즘 사람들이 이 문제를 어떻게 처리하는지 조사하고 있어요. 먼저 실제 상황을 이해하려는 것이지, 뭔가를 팔러 온 것은 아닙니다.
|
||||
> 요즘 다들 이런 문제를 어떻게 처리하는지 연구하고 있어요. 실제 상황을 먼저 파악하고 싶어서, 뭔가 팔러 온 건 아니에요.
|
||||
|
||||
이 표현은 상대가 "긍정 피드백을 줘야 한다"는 심리적 부담을 내려놓기 쉽게 합니다.
|
||||
이런 표현은 상대가 "긍정적인 피드백을 줘야 해"라는 심리적 부담을 더 쉽게 내려놓게 합니다.
|
||||
|
||||
### 6.2 최근의 실제 경험부터 묻기
|
||||
### 6.2 최근 실제 경험에서 시작
|
||||
|
||||
아래 질문으로 시작할 수 있습니다.
|
||||
이런 질문으로 시작할 수 있습니다:
|
||||
|
||||
- 최근에 이 문제를 만난 것은 언제였나요?
|
||||
- 그때 정확히 무슨 일이 있었나요?
|
||||
- 처음에는 어떻게 처리하려 했나요?
|
||||
- 최근에 이 문제를 만난 것이 언제였나요?
|
||||
- 그때 무슨 일이 있었나요?
|
||||
- 첫 반응은 어떻게 처리했나요?
|
||||
|
||||
대화가 구체적인 사건으로 들어가면 정보 품질은 보통 뚜렷하게 올라갑니다.
|
||||
대화가 구체적인 사건으로 들어가면, 정보의 질이 보통 눈에 띄게 향상됩니다.
|
||||
|
||||
### 6.3 행동, 비용, 대체 방안을 계속 캐묻기
|
||||
### 6.3 행동, 비용, 대체 솔루션을 계속 추적
|
||||
|
||||
이어서 묻습니다.
|
||||
계속 물어보세요:
|
||||
|
||||
- 지금은 어떤 방법으로 해결하나요?
|
||||
- 그 방법에서 가장 불편한 점은 무엇인가요?
|
||||
- 이 일 때문에 시간, 돈, 에너지를 얼마나 썼나요?
|
||||
- 다른 방법도 시도해 봤나요? 왜 계속 쓰지 않았나요?
|
||||
- 지금 어떤 방법으로 해결하고 계세요?
|
||||
- 이 방법에서 가장 불편한 점은 무엇인가요?
|
||||
- 이 일에 시간, 돈, 또는 에너지를 얼마나 썼나요?
|
||||
- 다른 방법도 시도해 보셨나요? 왜 계속 사용하지 않았나요?
|
||||
|
||||
### 6.4 마지막에 고통감과 우선순위 판단하기
|
||||
### 6.4 마지막에 고통과 우선순위 판단
|
||||
|
||||
"아픈가요?"라고 직접 묻지 않아도 됩니다. 세부 정보에서 판단할 수 있습니다.
|
||||
"아픈지 아닌지"를 직접 물어볼 필요 없이, 세부 사항에서 판단할 수 있습니다:
|
||||
|
||||
- 자주 만나는 문제인가
|
||||
- 이미 적극적으로 보완하고 있는가
|
||||
- 이미 비용을 지불할 의향을 보였는가
|
||||
- 말할 때 뚜렷한 감정이 실려 있는가
|
||||
- 자주 겪는 일인지
|
||||
- 이미 스스로 해결책을 찾고 있는지
|
||||
- 이미 비용을 지불할 의향이 있는지
|
||||
- 이야기할 때 뚜렷한 감정이 담겨 있는지
|
||||
|
||||
이것들이 "이게 당신의 고통점인가요?"라는 한 문장보다 훨씬 유용합니다.
|
||||
이 모든 것이 "이게 당신의 페인포인트인가요?" 한마디보다 더 유용합니다.
|
||||
|
||||
## 7. 더 완전한 예시
|
||||
|
||||
"AI가 대학생 이력서 수정을 돕는" 제품을 만들고 싶다고 가정해 봅시다.
|
||||
"AI로 대학생의 이력서를 수정하는" 제품을 만들고 싶다고 가정해 봅시다.
|
||||
|
||||
### 잘못된 질문 방식
|
||||
### 잘못된 질문
|
||||
|
||||
동급생에게 이렇게 묻습니다.
|
||||
학우에게 물어봅니다:
|
||||
|
||||
> AI 이력서 최적화 도구를 만들고 싶은데, 어때?
|
||||
> 직무에 따라 이력서를 자동으로 고쳐 준다면 쓸 것 같아?
|
||||
> AI 이력서 최적화 도구를 만들고 싶은데, 어때요?
|
||||
> 공고에 맞게 이력서를 자동으로 수정해 준다면, 쓸 건가요?
|
||||
|
||||
이때 상대는 이렇게 말할 가능성이 큽니다.
|
||||
이때 상대는 아마 이렇게 말할 것입니다:
|
||||
|
||||
- 괜찮아 보여
|
||||
- 유용할 것 같아
|
||||
- 무료면 한번 써 볼게
|
||||
- 꽤 좋은 것 같아
|
||||
- 쓸모 있을 것 같아
|
||||
> 무료면 써 볼게
|
||||
|
||||
이 답변으로는 수요가 얼마나 강한지 거의 판단할 수 없습니다.
|
||||
이런 대답은 수요가 얼마나 강한지 판단하는 데 거의 도움이 되지 않습니다.
|
||||
|
||||
### 더 좋은 질문 방식
|
||||
### 더 나은 질문
|
||||
|
||||
이렇게 바꿔 물을 수 있습니다.
|
||||
이렇게 바꿀 수 있습니다:
|
||||
|
||||
> 최근에 이력서를 고친 것은 언제였나요?
|
||||
> 그때 왜 고쳐야 했나요?
|
||||
> 어떻게 고쳤나요?
|
||||
> 어느 단계가 가장 막혔나요?
|
||||
> 다른 사람에게 봐 달라고 한 적이 있나요?
|
||||
> 이력서 때문에 돈을 쓰거나 많은 시간을 쓴 적이 있나요?
|
||||
> 최근에 이력서 수정한 게 언제였어?
|
||||
> 그때 왜 수정했어?
|
||||
> 어떻게 수정했어?
|
||||
> 어느 단계가 가장 막혔어?
|
||||
> 다른 사람에게 검토를 부탁해 본 적 있어?
|
||||
> 예전에 이력서 때문에 돈을 쓰거나 많은 시간을 쓴 적 있어?
|
||||
|
||||
이 질문을 통해 다음 정보를 얻을 수 있습니다.
|
||||
이런 질문을 통해 얻을 수 있는 정보는:
|
||||
|
||||
- 많은 사람은 못 쓰는 것이 아니라 직무별로 어떻게 고쳐야 할지 모른다.
|
||||
- 가장 아픈 것은 레이아웃이 아니라 "어떤 경험을 써야 할지 모르겠다"이다.
|
||||
- 그들이 미루는 것은 게으름 때문이 아니라 매번 이력서 수정이 매우 소모적이기 때문이다.
|
||||
- 그들은 이미 선배 조언, 템플릿 사이트, AI 도구, 친구에게 부탁하기로 겨우 해결하고 있다.
|
||||
- 많은 사람이 작성 방법을 모르는 것이 아니라, 다른 직무에 맞게 재작성하는 방법을 모른다는 것
|
||||
- 가장 아픈 것이 레이아웃이 아니라, "어떤 경험이 쓸 만한지 모르는 것"이라는 것
|
||||
- 그들이 미루는 것이 게을러서가 아니라, 매번 이력서를 수정하는 것이 너무 소모적이기 때문이라는 것
|
||||
- 이미 선배 조언, 템플릿 웹사이트, AI 도구, 친구 검토로 간신히 해결하고 있다는 것
|
||||
|
||||
이제 실제 문제에 훨씬 가까워졌습니다.
|
||||
이때, 진짜 문제에 훨씬 더 가까워집니다.
|
||||
|
||||
## 8. The Mom Test와 JTBD는 어떻게 함께 쓰는가
|
||||
## 8. The Mom Test와 JTBD를 어떻게 함께 사용할까
|
||||
|
||||
JTBD가 "사용자가 어떤 진전을 이루고 싶어 하는지"를 보게 해 준다면, The Mom Test는 이렇게 가르쳐 주는 것에 가깝습니다.
|
||||
JTBD가 "사용자가 어떤 진전을 완수하고 싶은지"를 명확히 보게 해준다면, The Mom Test는 다음을 가르치는 것에 더 가깝습니다:
|
||||
|
||||
**인터뷰를 통해 이 job이 정말 존재하는지 확인하는 방법**입니다.
|
||||
**인터뷰를 통해 이 job이 정말로 존재하는지 확인하는 방법.**
|
||||
|
||||
둘은 완전히 이어서 쓸 수 있습니다.
|
||||
두 가지를 연결해서 사용할 수 있습니다:
|
||||
|
||||
1. 먼저 JTBD로 하나의 job을 가정한다.
|
||||
2. The Mom Test 방식으로 사용자에게 최근의 실제 경험을 묻는다.
|
||||
3. 이 job이 정말 자주 발생하고, 실제이며, 우선 만들 가치가 있는지 본다.
|
||||
1. 먼저 JTBD로 job 하나를 가설로 세움
|
||||
2. The Mom Test 방식으로 사용자에게 최근 실제 경험을 물어봄
|
||||
3. 이 job이 정말로 빈도가 높고, 실제이며, 우선적으로 할 가치가 있는지 확인
|
||||
|
||||
예를 들어 JTBD 가설이 다음과 같다고 합시다.
|
||||
예를 들어 JTBD 가설이 다음과 같다면:
|
||||
|
||||
> 인턴십에 지원하려고 할 때, 나는 예전 이력서를 빠르게 직무에 맞는 버전으로 바꾸고 싶다. 그래야 가능한 한 빨리 지원을 완료할 수 있다.
|
||||
> 인턴십에 지원할 준비를 할 때, 기존 이력서를 공고에 맞는 버전으로 빠르게 수정하고 싶고, 최대한 빨리 지원을 완료하고 싶어.
|
||||
|
||||
그러면 The Mom Test 스타일 질문으로 검증할 수 있습니다.
|
||||
The Mom Test 스타일의 질문으로 검증할 수 있습니다:
|
||||
|
||||
- 최근에 지원한 것은 언제였나요?
|
||||
- 그때 이력서는 어떻게 고쳤나요?
|
||||
- 어느 문단이 가장 쓰기 어려웠나요?
|
||||
- 다 고친 뒤 충분히 좋은지 어떻게 판단했나요?
|
||||
- 최근에 지원한 게 언제였어?
|
||||
- 그때 이력서를 어떻게 수정했어?
|
||||
- 어느 부분이 가장 쓰기 어려웠어?
|
||||
- 수정한 후에 충분히 좋은지 어떻게 판단했어?
|
||||
|
||||
이렇게 방법이 연결됩니다.
|
||||
이렇게 하면 방법이 연결됩니다:
|
||||
|
||||
- JTBD는 수요 가설을 정의하게 도와줍니다.
|
||||
- The Mom Test는 인터뷰로 가설을 검증하게 도와줍니다.
|
||||
- JTBD가 수요 가설을 정의하는 데 도움을 줌
|
||||
- The Mom Test가 인터뷰를 통해 가설을 검증하는 데 도움을 줌
|
||||
|
||||
## 9. 초보자가 사용자 인터뷰에서 가장 흔히 하는 오해
|
||||
## 9. 초보자가 사용자 인터뷰를 할 때 가장 흔한 오해
|
||||
|
||||
### 9.1 인터뷰를 제품 설명회로 만들기
|
||||
### 9.1 인터뷰를 제품 소개회로 만듦
|
||||
|
||||
자신의 생각을 너무 많이 말하면 상대는 진짜 상황을 말하기보다 당신에게 맞춰 주기 쉽습니다.
|
||||
자신의 아이디어를 너무 많이 이야기하면, 상대가 실제 상황을 알려주는 대신 당신에게 협조하기 시작합니다.
|
||||
|
||||
### 9.2 인터뷰 대상이 전부 지인
|
||||
### 9.2 인터뷰 대상이 모두 아는 사람
|
||||
|
||||
지인과 이야기하면 안 되는 것은 아니지만, 지인은 당신을 격려하기 더 쉽습니다. 당신을 지지하는 사람만 찾지 말고, 실제 사용자에 더 가까운 사람을 섞어야 합니다.
|
||||
아는 사람과 대화하는 것이 나쁜 것은 아니지만, 아는 사람이 당신을 응원하기 더 쉽습니다. 최소한 지인 외에 실제 사용자에 더 가까운 사람들을 섞어야 하며, 자신을 지지하는 사람만 찾아서는 안 됩니다.
|
||||
|
||||
### 9.3 너무 일찍 기능을 추궁하기
|
||||
### 9.3 너무 일찍 기능을 추적하며 물어봄
|
||||
|
||||
문제를 아직 명확히 하지 못했는데 버튼, 인터페이스, 기능 세부사항을 묻기 시작하면 보통 너무 일찍 해결책으로 들어가는 것입니다.
|
||||
문제를 아직 파악하지 못한 상태에서 버튼, 인터페이스, 기능 세부 사항을 추적하면, 보통 너무 일찍 솔루션 단계에 진입한 것입니다.
|
||||
|
||||
### 9.4 "쓸 것 같다" 한마디를 검증 결과로 여기기
|
||||
### 9.4 "쓸게요" 한마디를 검증 결과로 받아들임
|
||||
|
||||
인터뷰는 방향 판단을 도울 뿐, 검증이 완료됐다는 뜻은 아닙니다. 진짜 검증은 결국 사용자가 시간, 전환 비용, 시험 사용 행동, 심지어 지불처럼 실제 비용을 낼 의향이 있는지 봐야 합니다.
|
||||
인터뷰는 방향을 판단하는 데 도움을 줄 수 있지만, 검증이 완료된 것과 같지 않습니다. 진짜 검증은 결국 사용자가 실제 비용(시간, 전환 비용, 체험 행동, 심지어 결제)을 지불할 의향이 있는지에 달려 있습니다.
|
||||
|
||||
### 9.5 인터뷰 후 정리하지 않기
|
||||
### 9.5 인터뷰 후 정리하지 않음
|
||||
|
||||
이야기하고 그냥 두면 정보는 금방 흐릿한 인상으로 변합니다. 가능한 한 빨리 정리하는 것이 좋습니다.
|
||||
대화가 끝나면 정보가 빠르게 모호한 인상으로 변합니다. 최대한 빨리 정리하는 것이 좋습니다:
|
||||
|
||||
- 자주 나타나는 문제
|
||||
- 사용자 원문 속 감정 단어
|
||||
- 현재 대체 방안
|
||||
- 빈도가 높은 문제
|
||||
- 사용자가 한 말 속의 감정 단어
|
||||
- 현재 대체 솔루션
|
||||
- 이미 지불한 비용
|
||||
- 자신의 새로운 판단
|
||||
|
||||
## 10. 바로 복사해 쓸 수 있는 질문 목록
|
||||
## 10. 바로 복사해서 사용할 수 있는 질문 목록
|
||||
|
||||
빨리 시작하고 싶다면 충분히 범용적인 질문 묶음이 여기 있습니다.
|
||||
빠르게 시작하고 싶다면, 여기에 충분히 범용적인 질문 세트가 있습니다.
|
||||
|
||||
### 시작 질문
|
||||
|
||||
- 최근에 이 문제를 만난 것은 언제였나요?
|
||||
- 최근에 이 문제를 만난 것이 언제였나요?
|
||||
- 그때 구체적으로 무슨 일이 있었나요?
|
||||
|
||||
### 행동 질문
|
||||
|
||||
- 그때 어떻게 처리했나요?
|
||||
- 왜 그 방법을 선택했나요?
|
||||
- 왜 이 방식을 선택했나요?
|
||||
|
||||
### 비용 질문
|
||||
|
||||
- 이 일은 보통 시간이나 에너지를 얼마나 쓰게 하나요?
|
||||
- 이 문제를 해결하려고 돈을 쓴 적이 있나요?
|
||||
- 이 일에 보통 시간이나 에너지를 얼마나 쓰나요?
|
||||
- 해결하기 위해 돈을 써본 적이 있나요?
|
||||
|
||||
### 대체 방안 질문
|
||||
### 대체 솔루션 질문
|
||||
|
||||
- 다른 도구나 방법을 시도해 본 적이 있나요?
|
||||
- 왜 결국 계속 쓰지 않았나요?
|
||||
- 다른 도구나 방법을 시도해 보셨나요?
|
||||
- 왜 계속 사용하지 않았나요?
|
||||
|
||||
### 마무리 질문
|
||||
|
||||
- 앞으로 같은 문제를 다시 만난다면, 가장 이상적인 해결 방식은 어떤 모습이어야 할까요?
|
||||
- 앞으로 같은 문제를 다시 만나면, 가장 이상적인 해결 방식은 어떤 것일까요?
|
||||
|
||||
주의하세요. 이 마무리 질문은 물어봐도 되지만, 가장 뒤에 두는 것이 좋습니다. 앞에서는 바람이 아니라 사실을 얻는 것이 더 중요하기 때문입니다.
|
||||
주의: 이 마무리 질문은 물어볼 수 있지만, 뒤에 두는 것이 좋습니다. 왜냐하면 앞에서는 사실을 먼저 얻어야 하고, 소원은 나중에 얻어도 되기 때문입니다.
|
||||
|
||||
## 11. 정리
|
||||
## 11. 요약
|
||||
|
||||
The Mom Test의 가장 중요한 기여는 "대화를 더 잘하는" 기술을 주는 것이 아니라, 더 맑은 판단 방식을 세워 주는 것입니다.
|
||||
The Mom Test의 가장 중요한 기여는 "더 잘 채팅하는" 기술을 주는 것이 아니라, 더 명확한 판단 방식을 구축하도록 돕는 것입니다:
|
||||
|
||||
- 다른 사람이 내 아이디어를 칭찬하는 말을 너무 빨리 믿지 마세요.
|
||||
- "있으면 쓸 것 같아요"를 실제 수요로 여기지 마세요.
|
||||
- 인터뷰가 인정을 구하는 자리가 되게 하지 마세요.
|
||||
- 다른 사람이 당신의 아이디어를 칭찬하는 것을 너무 빨리 믿지 마세요
|
||||
- "있으면 쓸게요"를 실제 수요로 받아들이지 마세요
|
||||
- 인터뷰를 인정을 찾는 과정으로 만들지 마세요
|
||||
|
||||
진짜 가치 있는 인터뷰는 가능한 한 다음으로 돌아가야 합니다.
|
||||
진짜 가치 있는 인터뷰는, 최대한 다음 것들로 되돌아가야 합니다:
|
||||
|
||||
- 사용자의 최근 실제 경험
|
||||
- 지금은 어떻게 처리하고 있는가
|
||||
- 이미 어떤 비용을 치렀는가
|
||||
- 어디에서 분명히 불편함을 느끼는가
|
||||
- 지금 어떻게 처리하는지
|
||||
- 이미 어떤 비용을 지불했는지
|
||||
- 어느 부분에서 분명히 불편해하는지
|
||||
|
||||
이렇게 묻기 시작하면 얻는 정보가 때로는 그렇게 듣기 좋지 않을 수 있지만, 보통 훨씬 더 유용합니다.
|
||||
제품을 만들 때는 **쓸모 있는 진실이 듣기 좋은 격려보다 언제나 더 중요합니다.**
|
||||
이런 식으로 물어보기 시작하면, 얻는 정보가 때때로 듣기에 그리 좋지 않을 수 있지만, 보통 더 유용합니다.
|
||||
제품을 만들 때, **유용한 진실은 항상 듣기 좋은 응원보다 더 중요합니다.**
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## [12. AI로 사용자 인터뷰를 돕는 방법](#top-mom)
|
||||
## [12. AI를 활용해 사용자 인터뷰 하는 방법](#top-mom)
|
||||
|
||||
The Mom Test는 본질적으로 "진짜 사람과 이야기하는" 방법이므로 AI가 실제 인터뷰를 대체할 수는 없습니다. 하지만 AI는 인터뷰 전, 중, 후에 보조 역할을 하기에 매우 적합하며, 특히 초보자의 진입 장벽을 낮추는 데 좋습니다.
|
||||
The Mom Test는 본질적으로 "실제 사람과 대화하는" 방법이므로, AI가 실제 인터뷰를 대체할 수는 없습니다. 하지만 AI는 인터뷰 전, 중, 후에 보조 역할을 하기에 매우 적합하며, 특히 초보자의 진입 장벽을 낮추는 데 도움이 됩니다.
|
||||
|
||||
### 12.1 AI에게 "망하기 쉬운 질문"을 고쳐 쓰게 하기
|
||||
### 12.1 AI로 "망가지기 쉬운" 질문을 재작성
|
||||
|
||||
많은 사람이 "내 아이디어 어때요"라고 물어보면 안 된다는 것을 알지만, 막상 입을 열면 다시 그런 문장으로 돌아갑니다. 준비한 질문을 AI에게 주고 고쳐 쓰게 할 수 있습니다.
|
||||
"내 이 아이디어 어때요?"라고 물으면 안 된다는 것을 알면서도, 입을 열면 여전히 이런 문장으로 돌아가는 사람이 많습니다. 준비한 질문을 먼저 AI에게 전달하여 재작성하도록 할 수 있습니다:
|
||||
|
||||
```text
|
||||
아래는 사용자 인터뷰에서 묻고 싶은 질문들이야.
|
||||
다음은 사용자 인터뷰를 준비하면서 물어보려는 질문입니다:
|
||||
[질문 붙여넣기]
|
||||
|
||||
The Mom Test 원칙으로 고쳐 써 줘.
|
||||
1. 의견형 질문 삭제
|
||||
2. 미래 가정 질문 삭제
|
||||
3. 가능한 한 과거 실제 행동, 기존 대체 방안, 이미 지불한 비용을 중심으로 바꾸기
|
||||
4. 마지막에 바로 인터뷰할 수 있는 질문 8~10개 목록으로 정리
|
||||
The Mom Test의 원칙으로 재작성해 주세요:
|
||||
1. 의견형 질문은 삭제
|
||||
2. 미래 가정 질문은 삭제
|
||||
3. 과거 실제 행동, 기존 대체 솔루션, 이미 지불한 비용을 중심으로 한 질문으로 수정
|
||||
4. 마지막으로 바로 인터뷰에 사용할 수 있는 8~10개의 질문 목록으로 정리
|
||||
```
|
||||
|
||||
아주 초보적인 입력도 괜찮습니다.
|
||||
아주 초보적인 입력도 가능합니다:
|
||||
|
||||
```text
|
||||
사용자에게 이렇게 묻고 싶어.
|
||||
사용자에게 물어보고 싶은데:
|
||||
1. AI 이력서 수정 도구를 만들면 어때요?
|
||||
2. 쓸 것 같나요?
|
||||
3. 돈을 낼 의향이 있나요?
|
||||
2. 쓸 건가요?
|
||||
3. 결제할 의향이 있나요?
|
||||
|
||||
더 좋은 질문으로 바꿔 줘.
|
||||
더 나은 질문으로 바꿔 주세요.
|
||||
```
|
||||
|
||||
AI가 주는 유용한 출력은 이런 모습일 수 있습니다.
|
||||
AI의 유용한 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
고친 질문:
|
||||
재작성된 질문:
|
||||
|
||||
1. 최근에 이력서를 고친 것은 언제였나요?
|
||||
2. 그때 왜 고쳐야 했나요?
|
||||
3. 어떻게 고쳤나요?
|
||||
1. 최근에 이력서를 수정한 게 언제였나요?
|
||||
2. 그때 왜 수정했나요?
|
||||
3. 어떻게 수정했나요?
|
||||
4. 어느 단계가 가장 시간이 많이 걸렸나요?
|
||||
5. 다른 사람에게 봐 달라고 한 적이 있나요?
|
||||
6. 이전에 이력서 수정에 돈을 쓰거나 많은 시간을 쓴 적이 있나요?
|
||||
5. 다른 사람에게 검토를 부탁해 본 적이 있나요?
|
||||
6. 예전에 이력서 수정 때문에 돈을 쓰거나 많은 시간을 쓴 적이 있나요?
|
||||
```
|
||||
|
||||
이 출력은 매우 도움이 됩니다. 원래 "의견을 묻는" 질문을 바로 "실제 행동을 묻는" 질문으로 바꿔 주기 때문입니다.
|
||||
이런 출력은 매우 도움이 됩니다. 왜냐하면 "의견을 묻는" 질문을 "실제 행동을 묻는" 질문으로 직접 바꿔주기 때문입니다.
|
||||
|
||||
### 12.2 AI에게 대상별 인터뷰 개요를 만들게 하기
|
||||
### 12.2 AI로 다른 대상을 위한 인터뷰 가이드라인 생성
|
||||
|
||||
같은 방향이라도 사람군이 다르면 인터뷰의 중점은 달라집니다. 예를 들어 학생, HR, 프리랜서는 관심사가 완전히 다릅니다. AI에게 서로 다른 대상별로 개요를 만들게 할 수 있습니다.
|
||||
같은 방향이라도, 다른 사용자군에게는 인터뷰 초점이 다릅니다. 예를 들어 학생, HR, 프리랜서의 관심사는 완전히 다릅니다. AI에게 다른 대상별로 각각 한 버전의 가이드라인을 작성하도록 할 수 있습니다:
|
||||
|
||||
- 초보 사용자 대상: 최근 한 번의 실제 경험을 중점적으로 이해
|
||||
- 헤비 사용자 대상: 대체 방안과 고통감을 중점적으로 이해
|
||||
- 유료 사용자 대상: 이미 비용을 지불했는지 중점적으로 이해
|
||||
- 초보 사용자에게는 최근 실제 경험에 초점
|
||||
- 헤비 사용자에게는 대체 솔루션과 고통에 초점
|
||||
- 유료 사용자에게는 이미 비용을 지불했는지에 초점
|
||||
|
||||
이렇게 하면 실제 대화할 때 리듬이 생기고, 모든 사람에게 똑같은 질문만 던지지 않게 됩니다.
|
||||
이렇게 하면 실제 대화에서 리듬감이 더 좋아지며, 모든 사람에게 같은 질문을 반복하지 않게 됩니다.
|
||||
|
||||
예를 들어 이렇게 바로 입력할 수 있습니다.
|
||||
예를 들어 이렇게 입력할 수 있습니다:
|
||||
|
||||
```text
|
||||
두 유형의 사람과 이야기하려고 해.
|
||||
1. 처음 인턴십을 찾는 대학생
|
||||
2. 이미 다른 사람의 이력서를 많이 봐 준 선배
|
||||
두 가지 유형의 사람과 대화할 거예요:
|
||||
1. 처음으로 인턴십을 찾는 대학생
|
||||
2. 다른 사람의 이력서를 많이 검토해 본 선배
|
||||
|
||||
각각 인터뷰 개요를 만들어 줘. 각 개요는 질문 6개로 해 줘.
|
||||
각각 6개의 인터뷰 가이드라인을 작성해 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
대학생 대상:
|
||||
1. 최근에 인턴십에 지원한 것은 언제였나요?
|
||||
2. 그때 가장 막힌 단계는 무엇이었나요?
|
||||
3. 본인의 이력서가 지원 가능한지 어떻게 판단했나요?
|
||||
1. 최근에 인턴십에 지원한 게 언제였나요?
|
||||
2. 그때 가장 막혔던 단계는 어디였나요?
|
||||
3. 이력서가 제출 가능한지 어떻게 알았나요?
|
||||
...
|
||||
|
||||
선배 대상:
|
||||
1. 최근에 다른 사람의 이력서를 봐 준 것은 언제였나요?
|
||||
2. 가장 자주 보이는 명확한 문제는 무엇인가요?
|
||||
3. 후배들이 가장 쉽게 막히는 단계는 무엇인가요?
|
||||
1. 최근에 다른 사람의 이력서를 검토해 준 게 언제였나요?
|
||||
2. 가장 자주 보이는 명백한 문제는 무엇인가요?
|
||||
3. 후배들이 가장 많이 막히는 단계는 어디인가요?
|
||||
...
|
||||
```
|
||||
|
||||
이렇게 하면 스스로 처음부터 질문을 만들 필요가 없어 인터뷰 준비가 훨씬 쉬워집니다.
|
||||
이렇게 하면 제로에서 직접 질문을 구성할 필요 없이, 인터뷰 준비가 훨씬 수월해집니다.
|
||||
|
||||
### 12.3 AI에게 인터뷰 기록을 정리하게 하기
|
||||
### 12.3 AI로 인터뷰 기록 정리
|
||||
|
||||
인터뷰를 마친 뒤 가장 흔한 문제는 "정보가 없다"가 아니라 "정보가 너무 흩어져 있다"입니다. AI는 조각난 대화를 구조화된 메모로 정리하는 데 매우 적합합니다.
|
||||
인터뷰가 끝난 후, 가장 흔히 발생하는 문제는 "정보가 없는 것"이 아니라 "정보가 너무 흩어져 있는 것"입니다. AI는 파편화된 대화를 구조화된 노트로 정리하는 데 매우 적합합니다:
|
||||
|
||||
```text
|
||||
아래는 사용자 3명과의 인터뷰 기록이야.
|
||||
The Mom Test 관점으로 정리해 줘.
|
||||
1. 어떤 내용이 사실이고, 어떤 내용이 의견인가
|
||||
2. 사용자의 최근 실제 행동은 무엇인가
|
||||
3. 현재 대체 방안은 무엇인가
|
||||
4. 사용자가 이미 지불한 시간, 돈, 에너지 비용은 무엇인가
|
||||
5. 반복해서 언급된 문제는 무엇인가
|
||||
6. 듣기에는 긍정적이지만 증거가 부족한 말은 무엇인가
|
||||
다음은 3명의 사용자와의 인터뷰 기록입니다.
|
||||
The Mom Test 관점으로 정리해 주세요:
|
||||
1. 어떤 내용이 사실이고, 어떤 것이 의견인지
|
||||
2. 사용자의 최근 실제 행동은 무엇인지
|
||||
3. 현재 대체 솔루션은 무엇인지
|
||||
4. 사용자가 이미 지불한 시간, 돈, 에너지 비용은 무엇인지
|
||||
5. 어떤 문제가 반복적으로 언급되었는지
|
||||
6. 어떤 말이 긍정적으로 들리지만 증거가 부족한지
|
||||
```
|
||||
|
||||
이 단계는 특히 가치가 있습니다. "듣기에는 좋다"와 "판단을 뒷받침할 수 있다"를 분리해 주기 때문입니다.
|
||||
이 단계는 특히 가치가 있습니다. 왜냐하면 "꽤 좋아 보이는" 내용과 "정말로 판단을 뒷받침할 수 있는" 내용을 분리하는 데 도움이 되기 때문입니다.
|
||||
|
||||
간단한 입력은 이렇게 쓸 수 있습니다.
|
||||
간단한 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
한 사용자와 이야기한 기록이야.
|
||||
한 사용자와 대화한 기록입니다:
|
||||
|
||||
- 도구가 있으면 한번 써 볼 것 같다고 했다.
|
||||
- 지난주 이력서를 고치느라 저녁 시간을 전부 썼다.
|
||||
- 지금은 주로 친구에게 봐 달라고 한다.
|
||||
- 가장 어려운 것은 어느 정도까지 고치면 지원해도 되는지 모른다는 점이라고 했다.
|
||||
- 도구가 있으면 한번 써 볼 것 같다고 했어요
|
||||
- 지난주에 이력서 수정하느라 하루 종일 걸렸다고 했어요
|
||||
- 지금은 주로 친구에게 검토를 부탁한다고 했어요
|
||||
- 제일 어려운 건 어디까지 수정해야 제출할 수 있는지 모르는 거라고 했어요
|
||||
|
||||
어떤 것이 의견이고 어떤 것이 사실인지 나눠 줘.
|
||||
의견과 사실을 나눠 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
의견:
|
||||
- 도구가 있으면 한번 써 볼 것 같다고 했다.
|
||||
- 도구가 있으면 한번 써 볼 것 같다
|
||||
|
||||
사실:
|
||||
- 지난주 이력서를 고치느라 저녁 시간을 전부 썼다.
|
||||
- 현재 대체 방안은 친구에게 봐 달라고 하는 것이다.
|
||||
- 가장 어려운 점은 언제 "지원 가능"한 상태인지 모른다는 것이다.
|
||||
- 지난주에 이력서 수정에 하루 종일 걸림
|
||||
- 현재 대체 솔루션은 친구에게 검토 부탁
|
||||
- 가장 어려운 점은 언제 "제출 가능"한지 모르는 것
|
||||
|
||||
수요 판단에 쓸 수 있는 핵심:
|
||||
- 이 문제는 최근에 실제로 발생했다.
|
||||
- 사용자는 명확한 시간 비용을 이미 투입했다.
|
||||
- 현재 방안은 다른 사람에게 의존하며 안정적이지 않다.
|
||||
수요 판단에 활용할 수 있는 핵심:
|
||||
- 이 문제는 최근에 실제로 발생함
|
||||
- 사용자가 이미 상당한 시간 비용을 지불함
|
||||
- 현재 솔루션은 타인에게 의존하여 불안정함
|
||||
```
|
||||
|
||||
이 출력은 초보자에게 어떤 말이 판단에 쓸 수 있고, 어떤 말은 그냥 들어 두는 정도인지 매우 직관적으로 알려 줍니다.
|
||||
이런 출력은 초보자에게 직관적으로 알려 줍니다: 어떤 말은 판단에 사용할 수 있고, 어떤 말은 그저 들어두면 되는지.
|
||||
|
||||
### 12.4 AI에게 먼저 가벼운 웹 검색을 시키기
|
||||
### 12.4 AI로 먼저 가벼운 온라인 검색 대행
|
||||
|
||||
아직 인터뷰를 시작하지 않았다면, AI에게 아주 가벼운 외부 조사를 맡길 수 있습니다.
|
||||
아직 인터뷰를 시작하지 않았다면, AI에게 먼저 가벼운 외부 조사를 맡길 수 있습니다. 예를 들어:
|
||||
|
||||
- 공개 커뮤니티에서 사람들이 최근 이 문제를 어떻게 불평하는지
|
||||
- 기존 도구에서 가장 많이 불평받는 부분은 무엇인지
|
||||
- 사용자가 유사한 문제에 이미 돈을 쓴 적이 있는지
|
||||
- 시장에 어떤 대체 방안이 이미 존재하는지
|
||||
- 공개 커뮤니티에서, 사람들이 최근에 이 문제를 어떻게 불만 제기하는지
|
||||
- 기존 도구에서 가장 많이 불만이 나오는 것이 무엇인지
|
||||
- 사용자가 비슷한 문제에 이미 돈을 지불했는지
|
||||
- 시장에 어떤 대체 솔루션이 이미 존재하는지
|
||||
|
||||
이 정보는 실제 사람 인터뷰를 대체할 수 없지만, 더 빨리 상태에 들어가고 문제를 어디서부터 파고들지 알게 해 줍니다.
|
||||
이런 정보는 실제 인터뷰를 대체할 수 없지만, 더 빨리 상태에 진입하여 어디서 질문을 시작해야 할지 알 수 있게 해줍니다.
|
||||
|
||||
간단한 입력 예시는 다음입니다.
|
||||
간단한 입력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
조사해 줘.
|
||||
"대학생이 이력서를 고칠 때 가장 자주 불평하는 것은 무엇인가"
|
||||
가장 흔한 불평 5개를 쉬운 말로 정리해 줘.
|
||||
조사해 주세요:
|
||||
"대학생이 이력서를 수정할 때 가장 많이 불만을 제기하는 것"
|
||||
가장 흔한 불만 5가지를 아주 일상적인 말로 정리해 주세요.
|
||||
```
|
||||
|
||||
AI는 이렇게 출력할 수 있습니다.
|
||||
AI의 출력은 다음과 같을 수 있습니다:
|
||||
|
||||
```text
|
||||
흔한 불평:
|
||||
흔한 불만:
|
||||
|
||||
1. 이력서에 정확히 무엇을 써야 할지 모른다.
|
||||
2. 직무 하나에 지원할 때마다 바꿔야 해서 너무 힘들다.
|
||||
3. 여러 번 고쳤지만 좋은지 계속 확신이 없다.
|
||||
4. 믿을 만한 피드백을 줄 사람이 없다.
|
||||
5. 아직 준비가 안 된 것 같아 계속 미루게 된다.
|
||||
1. 이력서에 뭘 써야 할지 모름
|
||||
2. 공고마다 수정해야 해서 너무 힘듦
|
||||
3. 여러 버전을 수정했는데 여전히 충분히 좋은지 모르겠음
|
||||
4. 신뢰할 수 있는 피드백을 줄 사람이 없음
|
||||
5. 항상 준비가 안 된 것 같아서 계속 미룸
|
||||
```
|
||||
|
||||
이 결과의 가치는 인터뷰 진입점을 더 쉽게 찾게 해 준다는 데 있습니다.
|
||||
이런 결과의 가치는, 인터뷰 진입점을 더 쉽게 찾을 수 있게 해준다는 것입니다.
|
||||
|
||||
### 12.5 AI에게 "인터뷰 회고 코치" 역할을 맡기기
|
||||
### 12.5 AI를 "인터뷰 복기 코치"로 활용
|
||||
|
||||
방금 끝낸 인터뷰 기록을 AI에게 던져 비판하게 할 수도 있습니다.
|
||||
방금 끝난 인터뷰 기록을 AI에게 전달하여, 비판을 맡길 수도 있습니다:
|
||||
|
||||
```text
|
||||
아래는 내 사용자 인터뷰 기록이야.
|
||||
The Mom Test 관점으로 회고해 줘.
|
||||
1. 내 질문 중 어떤 것이 인정을 구하는 것처럼 들렸나
|
||||
2. 어떤 질문이 명확하게 유도적이었나
|
||||
3. 원래 사실을 더 캐물어야 했던 부분은 어디인가
|
||||
4. 다시 한다면 이 대화를 어떻게 더 좋게 물어볼 수 있는가
|
||||
다음은 제 사용자 인터뷰 기록입니다.
|
||||
The Mom Test 관점에서 복기해 주세요:
|
||||
1. 어떤 질문이 인정을 찾는 것에 너무 가까웠는지
|
||||
2. 어떤 질문에 명백한 유도가 있었는지
|
||||
3. 어디서 사실을 계속 추적할 수 있었는지
|
||||
4. 다시 한번 한다면, 이 대화를 어떻게 더 잘 물어볼 수 있는지
|
||||
```
|
||||
|
||||
초보자에게 특히 도움이 됩니다. "내가 증거를 모으고 있는지, 격려를 모으고 있는지"에 대한 감각을 더 빨리 만들 수 있기 때문입니다.
|
||||
이것은 초보자에게 특히 도움이 됩니다. 왜냐하면 "내가 증거를 수집하고 있는지, 아니면 응원을 수집하고 있는지"에 대한 감각을 더 빨리 구축할 수 있기 때문입니다.
|
||||
|
||||
## 📚 Assignments
|
||||
## 📚 과제
|
||||
|
||||
위 내용을 바탕으로 다음 과제를 완료하세요.
|
||||
위 내용을 바탕으로 다음 과제를 완성해 주세요:
|
||||
|
||||
1. 최근 만들고 싶은 제품 방향 하나를 고르고, 원래 물어봤을 "망하기 쉬운" 질문 5개를 먼저 쓰세요.
|
||||
2. 이 5개 질문을 The Mom Test 스타일에 더 맞는 질문으로 고쳐 쓰세요.
|
||||
3. 잠재 사용자 3명을 찾아 최소 한 번은 "최근에 이 문제를 만난 것은 언제였나요?"라고 물어보세요.
|
||||
4. 인터뷰 후 네 가지 정보를 정리하세요: 실제 행동, 대체 방안, 이미 지불한 비용, 반복해서 나타나는 어려움.
|
||||
1. 최근에 만들고 싶은 제품 방향을 하나 골라, 원래 물어볼 "망가지기 쉬운" 질문 5개를 먼저 작성하세요
|
||||
2. 이 5개의 질문을 The Mom Test 스타일에 더 부합하는 질문으로 재작성하세요
|
||||
3. 잠재 사용자 3명을 찾아, 적어도 한 번은 "최근에 이 문제를 만난 것이 언제였나요"라고 물어보세요
|
||||
4. 인터뷰가 끝난 후 4가지 정보를 정리하세요: 실제 행동, 대체 솔루션, 이미 지불한 비용, 반복적으로 등장한 어려움
|
||||
|
||||
## 더 읽어 보기
|
||||
## 더 읽어볼 만한 자료
|
||||
|
||||
- [The Mom Test 공식 웹사이트](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
|
||||
|
||||
@@ -13,75 +13,74 @@ const relatedArticles =
|
||||
|
||||
# 초급 5: 완성 프로젝트 실전
|
||||
|
||||
## 본 장 안내
|
||||
## 장의 가이드
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['제품 사고', 'Mock Data', '상호작용 완성', 'LocalStorage']" coreOutput="기능이 완비된 AI 제품 프로토타입 1개" expectedOutput="완전한 흐름과 실제 같은 데이터를 포함한 Web 애플리케이션">
|
||||
<ChapterIntroduction :duration="duration" :tags="['제품 사고', 'Mock Data', '인터랙션 완성', 'LocalStorage']" coreOutput="기능이 완비된 AI 제품 프로토타입 1개" expectedOutput="완전한 흐름과 실제 데이터를 포함한 웹 애플리케이션">
|
||||
|
||||
지난 장에서는 AI 기능을 연결했고, Demo가 실행되기 시작했습니다. 하지만 진짜 "제품"과는 아직 <strong>거리가 멉니다</strong>. 페이지를 새로고침하면 <strong>데이터가 사라지고</strong>, 오류가 나면 <strong>흰 화면</strong>이 되며, 목록에는 "테스트 데이터 1, 테스트 데이터 2"만 있고, 사용자가 잘못 클릭해도 <strong>되돌릴 방법이 없습니다</strong>...
|
||||
이전 장에서 AI 능력을 연동하고 Demo가 돌아가게 만들었지만, 진정한 "제품"이라고 하기에는 아직 <strong>멀었습니다</strong>. 페이지를 새로고침하면 <strong>데이터가 사라지고</strong>, 오류가 나면 <strong>화면이 하얗게 변하며</strong>, 목록에는 "테스트 데이터 1, 테스트 데이터 2"만 있고, 사용자가 잘못 눌러도 <strong>되돌릴 수 없습니다</strong>...
|
||||
|
||||
이번 장에서는 이런 <strong>구멍을 모두 메웁니다</strong>. 우리는 <strong>제품의 완전한 흐름을 보완하고</strong>, AI로 <strong>실감 나는 비즈니스 데이터</strong>를 만들어 가짜 데이터를 대체하며, <strong>오류 처리와 사용자 피드백</strong>을 추가하고, 마지막에는 <strong>남에게 보여 줄 수 있을 만큼 그럴듯한</strong> 완성형 프로토타입으로 다듬습니다.
|
||||
이번 장에서는 이런 <strong>문제들을 모두 해결</strong>합니다. <strong>제품의 완전한 흐름을 보완</strong>하고, AI로 <strong>실감 나는 비즈니스 데이터</strong>를 생성해 가짜 데이터를 대체하며, <strong>오류 처리와 사용자 피드백</strong>을 추가합니다. 마지막으로 <strong>자랑할 수 있고, 남에게 보여 줄 수 있는</strong> 완성된 프로토타입을 다듬습니다.
|
||||
|
||||
이 장은 초급 단계의 <strong>마지막 장</strong>입니다. 이 단계를 마치면 "프로그래밍을 전혀 못함"에서 "<strong>AI 제품 프로토타입을 독립적으로 만들 수 있음</strong>"으로 바뀌는 전환을 완료하게 됩니다.
|
||||
이것은 초급 단계의 <strong>마지막 장</strong>입니다. 이 단계를 마치면 "프로그래밍을 전혀 모르는 상태"에서 "<strong>독립적으로 AI 제품 프로토타입을 만들 수 있는</strong>" 것으로 변신하게 됩니다.
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 폐쇄 루프로' },
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 루프까지' },
|
||||
{ title: '영혼 주입', description: '실제 비즈니스 데이터 시뮬레이션' },
|
||||
{ title: '피드백 반복', description: '실제 피드백 기반 경험 보완' },
|
||||
{ title: '최종 과제', description: '당신의 졸업 작품' }
|
||||
{ title: '최종 대과제', description: '당신의 졸업 작품' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. "Happy Path" 거부하기: 핵심 흐름 완성
|
||||
## 1. "Happy Path" 거부: 핵심 흐름 완성
|
||||
|
||||
많은 초보자는 프로토타입을 만들 때 "Happy Path", 즉 가장 이상적인 경로만 만듭니다. 사용자가 클릭한다 -> API 응답이 성공한다 -> 결과를 보여 준다.
|
||||
하지만 현실 세계에서는 일이 그렇게 순조롭지만은 않습니다. 당신의 프로토타입이 진짜 제품처럼 보이게 하려면 다음과 같은 "보이지 않는" 고리를 고려해야 합니다.
|
||||
많은 초보자가 프로토타입을 만들 때 "Happy Path"(가장 이상적인 경로)만 만드는 경우가 많습니다. 사용자가 클릭 -> API가 성공적으로 응답 -> 결과 표시. 하지만 현실에서는 항상 그렇게 순조롭지 않습니다. 프로토타입이 진짜 제품처럼 보이려면 다음과 같은 "보이지 않는" 링크들을 고려해야 합니다.
|
||||
|
||||
### 1.1 "기다림"과 "피드백" 추가하기
|
||||
### 1.1 "대기"와 "피드백" 추가
|
||||
|
||||
사용자가 "문구 생성"을 클릭하면 AI는 대개 응답까지 몇 초가 필요합니다. 이때 인터페이스가 아무 반응도 보이지 않으면 사용자는 프로그램이 고장 났다고 생각합니다.
|
||||
**AI IDE에게 Loading 상태를 추가해 달라고 해야 합니다.**
|
||||
사용자가 "카피 생성"을 클릭하면 AI가 응답하는 데 보통 몇 초가 걸립니다. 화면에 아무런 변화가 없으면 사용자는 프로그램이 고장 났다고 생각합니다.
|
||||
**AI IDE에 Loading 상태를 추가하도록 요청하세요:**
|
||||
|
||||
> 프롬프트 예시:
|
||||
> "생성 버튼을 클릭하면 버튼을 '생성 중...'으로 바꾸고 클릭할 수 없게 해 주세요. 동시에 오른쪽 영역에는 로딩 애니메이션을 표시해 주세요. API 결과가 반환된 뒤에 다시 정상 상태로 되돌려 주세요."
|
||||
> "생성 버튼을 클릭하면 버튼을 '생성 중...'으로 바꾸고 클릭할 수 없게 만들어 주세요. 동시에 오른쪽 영역에 로딩 애니메이션을 표시해 주세요. API가 결과를 반환하면 다시 정상 상태로 돌아와야 합니다."
|
||||
|
||||
### 1.2 "실패"와 "예외" 처리하기
|
||||
### 1.2 "실패"와 "예외" 처리
|
||||
|
||||
API Key가 만료될 수도 있고, 네트워크가 끊길 수도 있습니다.
|
||||
**AI IDE에게 오류 처리를 도와달라고 해야 합니다.**
|
||||
**AI IDE에 오류 처리를 요청하세요:**
|
||||
|
||||
> 프롬프트 예시:
|
||||
> "API 요청이 실패하면 콘솔에만 오류를 내지 말고, 페이지 상단에 빨간색 알림 상자(Toast)를 띄워 사용자에게 '생성에 실패했습니다. 잠시 후 다시 시도해 주세요'라고 알려 주세요. 그리고 사용자가 생성 버튼을 다시 클릭할 수 있게 해 주세요."
|
||||
> "API 요청이 실패하면 콘솔에 오류를 바로 띄우지 말고, 페이지 상단에 빨간색 알림 상자(Toast)를 표시해서 사용자에게 '생성 실패, 잠시 후 다시 시도해 주세요'라고 알려주세요. 그리고 사용자가 생성 버튼을 다시 클릭할 수 있도록 해주세요."
|
||||
|
||||
### 1.3 대화 기록 영속화
|
||||
### 1.3 대화 기록 지속화
|
||||
|
||||
AI와 상호작용하는 과정에서는 대화 내용을 저장해 사용자가 기록을 다시 보고 이전 대화를 이어 갈 수 있어야 합니다. 현재 단계에서는 데이터베이스를 도입하지 않고, 다음과 같은 가벼운 방안을 선택할 수 있습니다.
|
||||
AI와 상호작용하는 과정에서 대화 내용을 저장해 사용자가 이전 기록을 되돌아보고 이전 대화를 이어갈 수 있도록 해야 합니다. 현재 단계에서는 데이터베이스를 도입하지 않고 다음과 같은 가벼운 방식을 선택할 수 있습니다:
|
||||
|
||||
**저장 방안 선택:**
|
||||
**저장 방식 선택:**
|
||||
|
||||
| 방안 | 적합한 상황 | 특징 |
|
||||
| 방식 | 적용 시나리오 | 특징 |
|
||||
| ---------------- | -------------------------------- | ------------------------------------ |
|
||||
| **LocalStorage** | 순수 프론트엔드 프로젝트, 사용자 데이터가 브라우저에 저장됨 | 구현이 간단하고 새로고침해도 사라지지 않지만, 기기 간 동기화는 불가 |
|
||||
| **JSON 파일** | 로컬 프로토타입, 데이터를 파일 형태로 저장 | 구조가 명확하고 디버깅이 쉬우며 수동 편집 가능 |
|
||||
| **TXT 파일** | 가장 단순한 방안, 텍스트 내용을 빠르게 기록 | 형식이 자유롭고 호환성이 좋음 |
|
||||
| **LocalStorage** | 순수 프론트엔드 프로젝트, 사용자 데이터를 브라우저에 저장 | 구현이 간단하고, 새로고침해도 사라지지 않지만, 기기 간 동기화 불가 |
|
||||
| **JSON 파일** | 로컬 프로토타입, 데이터를 파일 형태로 저장 | 구조가 명확하고 디버깅이 쉬우며, 수동 편집 가능 |
|
||||
| **TXT 파일** | 가장 간단한 방식, 빠르게 텍스트 내용 기록 | 형식이 자유롭고 호환성이 좋음 |
|
||||
|
||||
**대화 내용 예시:**
|
||||
저장되는 대화 기록은 보통 다음 내용을 포함합니다.
|
||||
저장된 대화 기록은 일반적으로 다음 내용을 포함합니다:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"role": "user",
|
||||
"content": "블루투스 이어폰의 Douyin 판매 문구를 만들어 줘",
|
||||
"content": "블루투스 이어폰의 틱톡 라이브 커머스 카피를 생성해 줘",
|
||||
"timestamp": "2026-01-20 10:30:00"
|
||||
},
|
||||
{
|
||||
"role": "assistant",
|
||||
"content": "【블루투스 이어폰 추천 문구】\n\n🎧 지연은 이제 그만, 몰입형 음악 감상 경험\n\n여러분! 이 블루투스 이어폰 진짜 대박이에요👇\n\n✅ 40dB 액티브 노이즈 캔슬링, 순식간에 음악 세계로\n✅ 30시간 초장시간 배터리, 일주일 출퇴근 충전 걱정 없음\n✅ 통화 품질은 마치 대면 대화처럼 선명, 지하철 소음 속에서도 편하게\n✅ 세미 인이어 디자인, 오래 착용해도 아프거나 답답하지 않음\n\n💰 기간 한정 할인, 아래 링크로 바로 구매하세요!",
|
||||
"content": "[블루투스 이어폰 추천 카피]\n\n🎧 지연과 작별, 몰입형 청취 경험\n\n여러분! 이 블루투스 이어폰 진짜 대박이에요👇\n\n✅ 40dB 능동 노이즈 캔슬링, 순식간에 음악의 세계로\n✅ 30시간 초장시간 배터리, 일주일 출퇴근 충전 불필요\n✅ 통화 품질이 대면 수준, 지하철 소음 속에서도 대화 가능\n✅ 반삽입형 디자인, 오래 착용해도 아프지 않고 답답하지 않음\n\n💰 한정 할인, 아래 링크를 클릭해 구매하세요!",
|
||||
"timestamp": "2026-01-20 10:30:05"
|
||||
}
|
||||
]
|
||||
@@ -89,57 +88,57 @@ AI와 상호작용하는 과정에서는 대화 내용을 저장해 사용자가
|
||||
|
||||
**구현 프롬프트:**
|
||||
|
||||
> "대화 기록 저장 기능을 구현해 주세요. 사용자와 AI의 대화 기록을 JSON 파일로 저장하거나 LocalStorage를 사용하도록 지원해 주세요. 페이지에 들어올 때마다 기존 대화 기록을 자동으로 불러오고, 단일 대화 기록을 조회하고 삭제할 수 있게 해 주세요."
|
||||
> "대화 기록 저장 기능을 구현해 주세요. 사용자와 AI의 대화 기록을 JSON 파일로 저장(또는 LocalStorage 사용)하는 것을 지원합니다. 페이지에 들어올 때마다 자동으로 이전 대화를 불러오고, 개별 대화 기록을 보고 삭제할 수 있도록 해주세요."
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 폐쇄 루프로' },
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 루프까지' },
|
||||
{ title: '영혼 주입', description: '실제 비즈니스 데이터 시뮬레이션' },
|
||||
{ title: '피드백 반복', description: '실제 피드백 기반 경험 보완' },
|
||||
{ title: '최종 과제', description: '당신의 졸업 작품' }
|
||||
{ title: '최종 대과제', description: '당신의 졸업 작품' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. 영혼 주입하기: 실제 같은 데이터(Mock Data) 시뮬레이션
|
||||
## 2. 영혼 주입: 실제 데이터 시뮬레이션 (Mock Data)
|
||||
|
||||
텅 빈 페이지는 사람을 설득할 수 없습니다. "이커머스 소재 워크벤치"를 보여 주는데 기록이 텅 비어 있거나 "test / test / test" 한 줄만 있다고 상상해 보세요.
|
||||
가장 좋은 시연 효과를 만들려면 실제처럼 보이는 데이터를 "위조"해야 합니다. 그래야 프로토타입이 이미 반년 정도 운영된 진짜 제품처럼 보입니다.
|
||||
텅 빈 페이지는 사람을 감동시킬 수 없습니다. "이커머스 소재 작업대"를 남에게 보여주려는데 기록이 텅 비어 있거나, "test / test / test" 한 줄만 있다고 상상해 보세요.
|
||||
데모 효과를 최적화하려면 사실적인 데이터를 "위조"하여 프로토타입이 반 년간 운영된 진짜 제품처럼 보이게 만들어야 합니다.
|
||||
|
||||
### 2.1 AI에게 데이터 구조 설계를 맡기기
|
||||
### 2.1 AI에게 데이터 구조 설계 맡기
|
||||
|
||||
우리가 각 필드의 이름을 하나하나 생각할 필요는 없습니다. 예를 들어 `name`이라고 할지 `title`이라고 할지 고민하는 일은 AI에게 맡길 수 있습니다.
|
||||
각 필드 이름을 `name`으로 할지 `title`로 할지 직접 고민할 필요가 없습니다. 이 일은 완전히 AI에게 맡기면 됩니다.
|
||||
|
||||
당신은 AI에게 **비즈니스 장면**만 알려 주면 됩니다.
|
||||
AI에게 **비즈니스 시나리오**만 알려주면 됩니다:
|
||||
|
||||
> **프롬프트 예시:**
|
||||
> "나는 **Douyin 이커머스 소재 워크벤치** 프로토타입을 만들고 있어.
|
||||
> '상품 작업'을 설명하기 위한 JSON 데이터 구조를 설계해 줘.
|
||||
> 이 작업에는 상품의 기본 정보(이름, 카테고리), 입력 소재(이미지 링크), 그리고 AI가 생성한 결과(제목, 문구, 포스터 이미지)가 포함되어야 해.
|
||||
> JSON 예시를 바로 줘."
|
||||
> "저는 **틱톡 이커머스 소재 작업대** 프로토타입을 만들고 있습니다.
|
||||
> '상품 작업'을 설명하는 JSON 데이터 구조를 설계해 주세요.
|
||||
> 이 작업에는 다음이 포함되어야 합니다: 상품 기본 정보(이름, 카테고리), 입력 소재(이미지 링크), 그리고 AI 생성 결과(제목, 카피, 포스터 이미지).
|
||||
> JSON 예시를 바로 보여 주세요."
|
||||
|
||||
AI는 당신의 설명에 따라 `productName`, `generatedContent` 같은 필드를 자동으로 구상해 줍니다.
|
||||
AI는 설명에 따라 `productName`, `generatedContent` 같은 필드를 자동으로 구성해 줍니다.
|
||||
|
||||
### 2.2 AI에게 "실감 나는" 데이터를 대량 생산하게 하기
|
||||
### 2.2 AI에게 "사실적인" 데이터 대량 생산 맡기
|
||||
|
||||
데이터 구조가 생겼다면 다음 단계는 AI에게 "빈칸을 채워" 실제처럼 보이는 데이터를 한 묶음 만들게 하는 것입니다.
|
||||
데이터 구조가 준비되면 다음 단계는 AI에게 "빈칸을 채워" 사실적인 데이터를 대량 생성하는 것입니다.
|
||||
|
||||
**프롬프트 팁:**
|
||||
AI에게 "데이터 만들어 줘"라고만 말하면 안 됩니다. 인턴에게 업무를 맡기듯 **비즈니스 배경**과 **내용 요구사항**을 알려 줘야 합니다.
|
||||
AI에게 "데이터를 생성해 줘"라고만 하면 안 됩니다. 인턴에게 업무를 지시하듯 **비즈니스 배경**과 **콘텐츠 요구사항**을 알려주어야 합니다:
|
||||
|
||||
- **비즈니스 배경**: 우리는 "Douyin 이커머스"를 하므로 상품 제목은 눈길을 끌어야 합니다. 예: "날씬해 보이는 필수템", "학생 필수 구매". 문구는 구어체여야 합니다.
|
||||
- **이미지 요구사항**: 프로토타입을 예쁘게 보이게 하려면 이미지는 흑백 플레이스홀더가 아니라 랜덤 컬러 풍경이나 실제 물건 이미지가 좋습니다.
|
||||
- **비즈니스 배경**: AI에게 우리가 "틱톡 이커머스"를 한다고 알려주면, 상품 제목은 눈에 띄어야 하고(예: "날씬해 보이는 아이템", "학생 필수템"), 카피는 구어체여야 합니다.
|
||||
- **이미지 요구사항**: 프로토타입을 보기 좋게 만들려면 흑백 플레이스홀더가 아닌 무작위 컬러 풍경이나 실물 사진을 사용하는 것이 좋습니다.
|
||||
|
||||
> **프롬프트 예시:**
|
||||
> "방금 설계한 구조를 바탕으로 실감 나는 Mock Data 10개를 만들어 줘.
|
||||
> (비고: 반드시 JSON 형식일 필요는 없어. 프론트엔드를 작성 중이라면 JavaScript 배열로 바로 생성하게 해도 되고, Python을 쓴다면 List로 생성하게 해도 돼.)
|
||||
> "방금 설계한 구조를 기반으로 10개의 사실적인 Mock Data를 생성해 주세요.
|
||||
> (참고: 반드시 JSON 형식일 필요는 없습니다. 프론트엔드를 작성 중이라면 JavaScript 배열로, Python을 사용 중이라면 List로 생성할 수 있습니다.)
|
||||
>
|
||||
> **비즈니스 장면 요구사항**:
|
||||
> **비즈니스 시나리오 요구사항**:
|
||||
>
|
||||
> 1. 종합 잡화점이라고 가정하고, 상품은 '여성복', '디지털', '뷰티' 세 카테고리를 포함해.
|
||||
> 2. **생성된 제목과 문구는 매우 'Douyin 스타일'이어야 해**: 예를 들어 제목에는 Emoji(🔥, ✨)를 포함하고, 문구는 '대박', '직접 써 보니 좋음' 같은 말투를 사용해.
|
||||
> 3. **이미지 필드**: 모두 `https://picsum.photos/seed/{random_id}/300/400` 형식을 사용해서 각 이미지가 서로 다르게 보이도록 해."
|
||||
> 1. 종합 잡화점이라고 가정하고, 상품은 '여성의류', '디지털', '뷰티' 세 가지 카테고리를 포함합니다.
|
||||
> 2. **생성된 제목과 카피는 '틱톡 스타일'이어야 합니다**: 예를 들어 제목에 Emoji(🔥, ✨)를 포함하고, 카피에는 '대박', '직접 써봤는데 좋아요' 같은 말투를 사용합니다.
|
||||
> 3. **이미지 필드**: `https://picsum.photos/seed/{random_id}/300/400` 형식을 통일해서 사용해 주세요. 각 이미지가 서로 다르게 해주세요."
|
||||
|
||||
**생성된 Mock Data 예시:**
|
||||
|
||||
@@ -147,17 +146,17 @@ AI에게 "데이터 만들어 줘"라고만 말하면 안 됩니다. 인턴에
|
||||
export const mockProductTasks = [
|
||||
{
|
||||
id: 'task_001',
|
||||
name: '여름 프렌치 빈티지 플라워 원피스',
|
||||
name: '여름 프렌치 레트로 꽃무늬 원피스',
|
||||
status: 'completed',
|
||||
input: {
|
||||
category: '여성복',
|
||||
features: ['허리 라인', '날씬해 보임', '분위기'],
|
||||
category: '여성의류',
|
||||
features: ['허리 조임', '날씬해 보임', '분위기'],
|
||||
originalImage: 'https://picsum.photos/seed/dress_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '✨누가 입어도 예쁨! 이 프렌치 플라워 원피스 진짜 대박🔥',
|
||||
generatedTitle: '✨누가 입어도 예쁘다! 이 프렌치 꽃무늬 원피스 진짜 대박🔥',
|
||||
generatedCopy:
|
||||
'여러분! 이 원피스 진짜 날씬해 보여요! 허리 라인이 정말 좋아서 입자마자 실루엣이 살아나요. 원단도 통기성이 좋아 여름에 입어도 전혀 답답하지 않아요. 데이트와 쇼핑에 강력 추천!👗',
|
||||
'여러분! 이 원피스 진짜 날씬해 보여요! 허리 조임 디자인이 대박이고, 입으면 바로 허리 라인이 보여요. 원단이 통기성이 좋아서 여름에 입어도 전혀 답답하지 않아요. 데이트나 쇼핑할 때 최고!👗',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/dress_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-20T10:00:00Z'
|
||||
@@ -172,9 +171,9 @@ export const mockProductTasks = [
|
||||
originalImage: 'https://picsum.photos/seed/tech_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '🎧 드디어 찾았다! 이 이어폰 노이즈 캔슬링 너무 강력하잖아!🔇',
|
||||
generatedTitle: '🎧 드디어 찾았다! 이 이어폰 노이즈 캔슬링 너무 강력해!🔇',
|
||||
generatedCopy:
|
||||
'착용하는 순간 세상이 조용해져요. 음질도 뛰어나서 노래를 들으면 현장에 있는 것 같아요. 배터리도 정말 오래가서 한 번 충전하면 일주일 사용 가능! 학생 필수템!',
|
||||
'이걸 끼면 세상이 순식간에 조용해져요. 음질도 최고, 노래를 듣는 것 같은 현장감. 배터리도 엄청나서 한 번 충전으로 일주일 사용! 학생 필수템!',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/tech_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-21T14:30:00Z'
|
||||
@@ -183,85 +182,85 @@ export const mockProductTasks = [
|
||||
]
|
||||
```
|
||||
|
||||
### 2.3 (고급) LocalStorage로 "가짜 CRUD" 구현하기
|
||||
### 2.3 (심화) LocalStorage로 "가짜 추가/삭제/수정" 구현
|
||||
|
||||
방금 만든 "Mock Data"가 단지 보기만 하는 것이 아니라 삭제, 수정도 가능하고, 새로 생성한 작업이 페이지 새로고침 후에도 남아 있기를 원한다면 `LocalStorage`를 결합할 수 있습니다.
|
||||
방금 생성한 "시뮬레이션 데이터"를 볼 수만 있게 하지 않고, 삭제하고 수정할 수 있게 만들고 싶다면, 심지어 새로 생성한 작업이 페이지 새로고침 후에도 남아 있게 하려면 `LocalStorage`를 결합하면 됩니다.
|
||||
|
||||
> **프롬프트 예시:**
|
||||
> "데이터 저장 기능을 구현해 줘.
|
||||
> "데이터 저장 기능을 구현해 주세요.
|
||||
>
|
||||
> 1. 우선 `localStorage`에서 데이터를 읽어 와.
|
||||
> 2. `localStorage`가 비어 있으면 방금 생성한 Mock Data로 초기화하고, 그것들을 `localStorage`에 저장해.
|
||||
> 3. 동시에 `addProductTask`와 `deleteProductTask` 함수를 작성해 줘. 매번 작업할 때마다 `localStorage`도 동기화해야 해."
|
||||
> 1. `localStorage`에서 데이터를 먼저 읽어옵니다.
|
||||
> 2. `localStorage`가 비어 있으면 방금 생성한 Mock 데이터로 초기화하고, 이를 `localStorage`에 저장합니다.
|
||||
> 3. 동시에 `addProductTask`와 `deleteProductTask` 함수를 작성해 주세요. 매번 작업 시 `localStorage`를 동기화하여 업데이트합니다."
|
||||
|
||||
이 단계를 거치면 프로토타입은 "기억"을 가지게 되고, 사용자 경험은 거의 진짜 제품과 다르지 않게 됩니다.
|
||||
이 단계를 거치면 프로토타입에 "기억"이 생기고, 사용자 경험이 실제 제품과 거의 다르지 않게 됩니다.
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 폐쇄 루프로' },
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 루프까지' },
|
||||
{ title: '영혼 주입', description: '실제 비즈니스 데이터 시뮬레이션' },
|
||||
{ title: '피드백 반복', description: '실제 피드백 기반 경험 보완' },
|
||||
{ title: '최종 과제', description: '당신의 졸업 작품' }
|
||||
{ title: '최종 대과제', description: '당신의 졸업 작품' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 3. 피드백 수집과 빠른 반복 개선
|
||||
|
||||
문을 닫고 혼자 만들면 좋은 제품은 나오지 않습니다. 이제 당신의 프로토타입은 "핵심 기능" + "완전한 흐름" + "시연 데이터"를 갖췄습니다. 다른 사람에게 보여 줄 때가 되었습니다.
|
||||
방구석에서 만든 제품은 좋은 제품이 될 수 없습니다. 이제 프로토타입이 "핵심 기능" + "완전한 흐름" + "데모 데이터"를 갖추었으니, 남에게 보여줄 때입니다.
|
||||
|
||||
### 3.1 누구에게 테스트하게 할까? 어떻게 테스트할까?
|
||||
### 3.1 누구에게 테스트를 맡길까? 어떻게 테스트할까?
|
||||
|
||||
- **친구/동료 찾기**: 기술을 알 필요는 없습니다. 그냥 직접 사용해 보게 하면 됩니다.
|
||||
- **유도하지 말고 관찰하기**: "여기를 클릭하세요"라고 말하지 말고, 그들이 어디를 클릭하는지 봅니다. 버튼을 찾지 못한다면 설계에 문제가 있다는 뜻입니다.
|
||||
- **"Wizard of Oz"(오즈의 마법사 방법)**: AI가 아직 제대로 연결되지 않았다면, 백그라운드나 데이터베이스에서 사람이 직접 데이터를 수정해 AI 반환을 흉내 내고, 먼저 사용자가 이 기능을 필요로 하는지 검증할 수 있습니다.
|
||||
- **친구/동료에게 맡기기**: 기술을 이해할 필요 없이, 한번 사용해 보게만 하세요.
|
||||
- **안내하지 말고 관찰하기**: "여기를 클릭해"라고 말하지 말고, 그들이 어디를 클릭하는지 보세요. 버튼을 찾지 못한다면 디자인에 문제가 있는 것입니다.
|
||||
- **"Wizard of Oz" 방식**: AI가 아직 연동되지 않았다면, 수동으로 백엔드(또는 데이터베이스)에서 데이터를 수정해 AI의 응답을 시뮬레이션하여, 사용자가 이 기능을 필요로 하는지 먼저 검증할 수 있습니다.
|
||||
|
||||
### 3.2 Bug와 불평을 마주하기
|
||||
### 3.2 버그와 불평에 대처하기
|
||||
|
||||
- **스타일 깨짐**: 화면 크기가 다르면 레이아웃이 깨질 수 있습니다.
|
||||
- **Action**: 스크린샷을 AI IDE에게 보내기 -> "이 화면 너비에서 깨졌어. 고쳐 줘."
|
||||
- **조작이 불편함**: "이 흐름이 너무 번거로워요."
|
||||
- **Action**: 제안을 AI IDE에게 말하기 -> "사용자가 먼저 업로드하고 다시 생성하는 흐름이 너무 느리다고 해. 한 번에 생성하도록 바꿀 수 있을까?"
|
||||
- **새 요구사항**: "이 기능이 있으면 좋겠어요."
|
||||
- **Action**: 핵심인지 평가합니다. 핵심이라면 AI에게 빠르게 간소화 버전을 구현하게 합니다.
|
||||
- **스타일 깨짐**: 다른 화면 크기에서 레이아웃이 깨질 수 있습니다.
|
||||
- **Action**: 스크린샷을 찍어 AI IDE에 보내기 -> "이 화면 너비에서 레이아웃이 깨졌어요. 수정해 주세요."
|
||||
- **조작이 불편함**: "이 흐름이 너무 복잡해요".
|
||||
- **Action**: AI IDE에 의견 전달 -> "사용자가 먼저 업로드하고 생성하는 게 너무 느리다고 해요. 원클릭 생성으로 바꿀 수 있나요?"
|
||||
- **새로운 요구사항**: "이런 기능이 있었으면 좋겠어요".
|
||||
- **Action**: 핵심 기능인지 평가하고, 핵심이라면 AI에게 간소화 버전을 빠르게 구현하게 합니다.
|
||||
|
||||
**기억하세요. 이 단계에서 AI는 최고의 수정 조수입니다. 당신은 문제를 발견하기만 하면 되고, 코드 수정은 AI에게 맡기면 됩니다.**
|
||||
**기억하세요: 이 단계에서 AI는 최고의 수정 도우미입니다. 여러분은 문제를 발견하는 것만 담당하고, 코드 수정은 AI에게 맡기세요.**
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 폐쇄 루프로' },
|
||||
{ title: '흐름 완성', description: '단일 기능에서 완전한 루프까지' },
|
||||
{ title: '영혼 주입', description: '실제 비즈니스 데이터 시뮬레이션' },
|
||||
{ title: '피드백 반복', description: '실제 피드백 기반 경험 보완' },
|
||||
{ title: '최종 과제', description: '당신의 졸업 작품' }
|
||||
{ title: '최종 대과제', description: '당신의 졸업 작품' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 4. 🎓 단계 대과제: 당신의 "졸업 작품" 완성하기
|
||||
## 4. 🎓 단계 대과제: "졸업 작품" 완성
|
||||
|
||||
축하합니다! 당신은 이미 "요구사항"에서 "프로토타입", 그리고 "AI 통합"까지 전 과정을 걸어왔습니다. 이제 최종 결과물을 보여 줄 시간입니다.
|
||||
축하합니다! "요구사항"에서 "프로토타입"을 거쳐 "AI 통합"까지의 전 과정을 마쳤습니다. 이제 최종 성과를 보여줄 시간입니다.
|
||||
|
||||
**이번 대과제는 더 이상 "이커머스 소재 워크벤치"에만 제한되지 않습니다**. 자신의 관심사나 산업 배경을 결합해 세상에 하나뿐인 AI 제품 프로토타입을 만들어야 합니다.
|
||||
**이번 대과제는 "이커머스 소재 작업대"에 국한되지 않습니다.** 자신의 관심사나 산업 배경을 결합해 독창적인 AI 제품 프로토타입을 만들어야 합니다.
|
||||
|
||||
### 주제 선정과 요구사항
|
||||
|
||||
**[산업 다분류 시나리오 방향 참고](../appendix-industry-scenarios/index.md)** 중 가장 가까운 장면을 하나 선택하거나, 자신의 생각에 따라 완전히 새로운 장면을 구상해야 합니다.
|
||||
**[산업 다분류 시나리오 방향 참고](../appendix-industry-scenarios/index.md)**에서 가장 가까운 시나리오를 선택하거나, 자신의 아이디어로 완전히 새로운 시나리오를 구상할 수 있습니다.
|
||||
|
||||
**프로젝트는 앞의 몇 장에서 배운 모든 내용을 종합적으로 활용해야 합니다.**
|
||||
**프로젝트는 이전 수업에서 배운 모든 내용을 종합적으로 활용해야 합니다:**
|
||||
|
||||
1. **프로토타입 구축**: 프론트엔드 기술을 사용해 아름답고 사용하기 쉬운 인터페이스를 만듭니다.
|
||||
2. **요구사항 제어**: 크고 완전한 것을 추구하지 말고, 핵심 기능의 논리적 폐쇄 루프를 추구합니다.
|
||||
3. **API 접목**: 실제 AI 모델(LLM/VLM 등)을 연결해 애플리케이션에 진짜 지능을 부여합니다.
|
||||
4. **가지고 놀 수 있는 애플리케이션 구현**: 단순한 정적 페이지가 아니라 데이터 흐름과 상호작용 피드백이 있는 동적 애플리케이션이어야 합니다.
|
||||
1. **프로토타입 구축**: 프론트엔드 기술을 사용해 보기 좋고 사용하기 쉬운 인터페이스를 구축합니다.
|
||||
2. **요구사항 관리**: 크고 완벽한 것을 추구하기보다 핵심 기능 논리가 루프를 이루도록 합니다.
|
||||
3. **API 연동**: 실제 AI 모델(LLM/VLM 등)을 연동하여 애플리케이션에 진정한 지능을 부여합니다.
|
||||
4. **실행 가능한 애플리케이션 구현**: 정적인 페이지가 아닌, 데이터 흐름과 인터랙션 피드백이 있는 동적 애플리케이션을 만듭니다.
|
||||
|
||||
### 과제 산출물
|
||||
|
||||
최종적으로 다음 두 가지를 제출해야 합니다.
|
||||
최종적으로 다음 두 가지를 제출해야 합니다:
|
||||
|
||||
1. **완성된 프로토타입 애플리케이션**: 온라인 배포 또는 로컬 실행이 가능하고, 완전한 사용 흐름을 갖춰야 합니다.
|
||||
2. **30초 시연 영상**: 애플리케이션의 사용 장면을 간단히 소개하고 핵심 기능의 실제 조작을 보여 주는 영상을 녹화합니다.
|
||||
1. **완성된 프로토타입 애플리케이션**: 배포되어 온라인에서 접속 가능하거나, 로컬에서 실행 가능해야 하며, 완전한 사용 흐름을 갖추어야 합니다.
|
||||
2. **30초 데모 영상**: 애플리케이션 시나리오를 간단히 소개하고, 핵심 기능의 실제 조작을 시연하는 영상을 녹화합니다.
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
@@ -269,34 +268,33 @@ export const mockProductTasks = [
|
||||
</template>
|
||||
|
||||
<p>
|
||||
이것은 Stage 1의 마지막 전투입니다. 아래 체크리스트에 따라 작품을 확인하세요.
|
||||
이것은 Stage 1의 마지막 전투입니다. 다음 체크리스트에 따라 작품을 점검해 주세요:
|
||||
</p>
|
||||
|
||||
<div style="font-weight: bold; margin-bottom: 10px;">핵심 기능 자가 점검</div>
|
||||
<div style="font-weight: bold; margin-bottom: 10px;">핵심 기능 자체 점검</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>장면 명확성</strong>: 구체적인 산업 또는 애플리케이션 장면을 선택했다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>논리 폐쇄 루프</strong>: 핵심 흐름이 실행되며, Happy Path만 있는 것이 아니다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>AI 구동</strong>: 사전 설정 응답이 아니라 실제 대형 모델 API를 호출했다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>완전한 경험</strong>: Loading, 오류 처리, Mock Data를 포함한다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>시나리오 명확</strong>: 구체적인 산업 또는 애플리케이션 시나리오를 선택함</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>논리 루프</strong>: 핵심 흐름이 실행 가능하며, Happy Path에만 국한되지 않음</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>AI 구동</strong>: 실제로 대형 모델 API를 호출하며, 미리 설정된 응답이 아님</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>경험 완성</strong>: Loading, 오류 처리 및 Mock Data 포함</label></li>
|
||||
</ul>
|
||||
|
||||
<div style="font-weight: bold; margin: 20px 0 10px;">제출물 준비</div>
|
||||
<div style="font-weight: bold; margin: 20px 0 10px;">산출물 준비</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>프로토타입 애플리케이션</strong>: 코드가 완성되었고 실행 가능하다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>시연 영상</strong>: 약 30초, 핵심 하이라이트를 명확히 보여 준다</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>프로토타입 애플리케이션</strong>: 코드가 완성되었고 실행 가능함</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>데모 영상</strong>: 약 30초 분량, 핵심 하이라이트를 명확히 보여 줌</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 다음 단계
|
||||
|
||||
대과제를 완료했다면, 당신은 이미 "AI 애플리케이션 프로토타입을 독립적으로 개발하는" 능력을 갖춘 것입니다.
|
||||
다음 Stage 2에서는 더 복잡한 풀스택 개발을 깊이 다루며, 이 프로토타입을 실제로 배포 가능하고, 데이터베이스와 사용자 시스템을 갖춘 상업 수준의 애플리케이션으로 바꾸는 법을 배웁니다.
|
||||
대과제를 완료하면 "독립적으로 AI 애플리케이션 프로토타입을 개발하는" 능력을 갖추게 됩니다.
|
||||
다음 Stage 2에서는 더 복잡한 풀스택 개발을 심화 학습하고, 이 프로토타입을 실제로 온라인에 공개할 수 있고, 데이터베이스와 사용자 시스템을 갖춘 상업급 애플리케이션으로 만드는 법을 배우게 됩니다.
|
||||
|
||||
다음 단계에서 만나요!
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="계속 고급 단계로"
|
||||
description="Stage 1 완료를 축하합니다. 아래 장들은 엔지니어링 개발로 들어가는 데 도움을 줍니다."
|
||||
title="계속해서 실력 키우기"
|
||||
description="Stage 1을 완료한 것을 축하합니다. 다음 장들이 엔지니어링 개발로 진입하는 데 도움이 됩니다."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
|
||||
|
||||
@@ -1245,3 +1245,7 @@ API Key는 **아주 긴 “고급 비밀번호 + 신분증 번호”**로 이해
|
||||
- 그다음 “무엇에 비유할 수 있는가”를 한 문장으로 쓰기
|
||||
- 마지막으로 아주 간단한 예 하나 주기
|
||||
이렇게 하면 당신의 “개인 용어집”이 점점 길어지고 실용적이 되어, 컴퓨터와 더 잘 소통할 수 있게 됩니다.
|
||||
---
|
||||
title: 'Beginner 2: AI Coding Tools'
|
||||
description: 'Move from web AI coding to local development: understand IDE vs AI IDE, build a snake game with Trae, and learn practical AI collaboration tips.'
|
||||
---
|
||||
|
||||
@@ -11,40 +11,43 @@ const relatedArticles = relatedArticlesMap['ko-kr/stage-1/learning-map'] ?? []
|
||||
|
||||
# 아이디어에서 AI 제품까지
|
||||
|
||||
예전에는 소프트웨어를 만들기 위한 문턱이 높았습니다. 프로그래밍을 알아야 했고, 알고리즘도 알아야 했고, 몇 년의 프로젝트 경험도 필요했습니다.
|
||||
지금은 다릅니다. 아이디어만 있다면 AI가 코드를 작성하도록 도와줄 수 있습니다.
|
||||
::: info 특별 감사
|
||||
**칭화대학교 선전 국제대학원** 학생 여러분의 본 과정 테스트, 피드백, 지원에 특별히 감사드립니다! 여러분의 의견과 기여가 이 과정을 더 나은 곳으로 만들었습니다. [👉 전체 기여자 목록 보기](https://github.com/datawhalechina/easy-vibe#-contributing--contributors)
|
||||
:::
|
||||
|
||||
이것은 거대한 변화입니다. **프로그래밍 언어가 자연어로 변하고 있습니다**.
|
||||
예전에는 소프트웨어를 만드는 진입 장벽이 매우 높았습니다: 프로그래밍을 알아야 하고, 알고리즘을 이해해야 하며, 몇 년의 프로젝트 경험도 필요했습니다.
|
||||
지금은 다릅니다. 아이디어만 있으면 AI가 코드를 작성해 줍니다.
|
||||
|
||||
대형 언어 모델(LLM)의 등장은 개발을 더 이상 "기술 고수만의 전유물"이 아니라, 누구나 시작할 수 있는 도구로 바꾸었습니다. 예전에는 가장 어려운 것이 "코드를 어떻게 쓰는가"였다면, 지금 가장 어려운 것은 "**무엇을 만들 것인가**"입니다.
|
||||
이것은 거대한 변화입니다: **프로그래밍 언어가 자연어로 변하고 있습니다.**
|
||||
|
||||
> **Vibe Coding이란 무엇인가요?**
|
||||
> 간단히 말하면 "말로 하는 프로그래밍"입니다. Vibe Coding은 직접 코드를 쓰는 대신 AI와 대화하는 방식에 의존해 프로그래밍 프로젝트를 완성하는 것을 뜻합니다.
|
||||
대형 언어 모델(LLM)의 등장으로, 개발은 더 이상 "기술 고수의 전유물"이 아니라 모든 사람이 사용할 수 있는 도구가 되었습니다. 예전에 가장 어려웠던 것은 "코드를 어떻게 쓸까"였고, 지금 가장 어려운 것은 "**무엇을 만들까**"입니다.
|
||||
|
||||
물론 AI가 코드를 쓰게 하는 것은 첫걸음일 뿐입니다. 정말 사용할 수 있는 제품을 만들려면 다음과 같은 문제도 만나게 됩니다.
|
||||
> **Vibe Coding이란?**
|
||||
> 간단히 말해, "말로 프로그래밍하는 것"입니다. Vibe Coding은 코드를 직접 작성하는 대신, AI와 대화하는 것만으로 프로그래밍 프로젝트를 완수하는 방식을 의미합니다.
|
||||
|
||||
- AI가 깨끗하고 유지보수 가능한 코드를 쓰게 하려면 어떻게 해야 할까?
|
||||
- 흩어진 코드 조각을 실행 가능한 애플리케이션으로 어떻게 조립할까?
|
||||
- 애플리케이션을 실제로 배포하고 사람들이 쓰게 하려면 어떻게 해야 할까?
|
||||
- 텍스트 생성, 이미지 인식 같은 AI 기능을 내 제품에 어떻게 넣을까?
|
||||
물론, AI가 코드를 작성하는 것은 첫 번째 단계일 뿐입니다. 정말로 사용 가능한 제품을 만들려면, 다음과 같은 문제도 만나게 됩니다:
|
||||
- AI가 어떻게 깔끔하고 유지보수 가능한 코드를 작성하게 할 것인가?
|
||||
- 산발적인 코드를 어떻게 실행 가능한 애플리케이션으로 조립할 것인가?
|
||||
- 애플리케이션을 어떻게 실제로 온라인에 공개하고, 사람들이 사용하게 할 것인가?
|
||||
- 텍스트 생성, 이미지 인식 같은 AI 능력을 어떻게 제품에 넣을 것인가?
|
||||
|
||||
이 질문들은 이 강의 안에서 답을 찾게 됩니다.
|
||||
이런 질문에 대한 답을 이 과정에서 찾을 수 있습니다.
|
||||
|
||||
학생이든, 교사든, 의사든, 노동자든, 기술을 전혀 모르는 평범한 사람이든 상관없습니다. 몇 년씩 프로그래밍을 먼저 배울 필요 없이, 2주면 실행되고 시연할 수 있는 제품 프로토타입을 만들 수 있습니다.
|
||||
학생이든, 교사든, 의사든, 노동자든, 기술을 전혀 모르는 일반인이든 상관없습니다 -- 몇 년 동안 프로그래밍을 먼저 배울 필요 없이, 2주면 실행 가능하고 시연할 수 있는 제품 프로토타입을 만들 수 있습니다.
|
||||
|
||||
| 당신의 정체성 | 이 강의가 도와줄 수 있는 것 |
|
||||
| 당신의 신분 | 이 과정이 도와줄 수 있는 것 |
|
||||
|---------|-------------|
|
||||
| 학생 | 과제, 대회, 창업 프로젝트를 직접 만들고 더 이상 남에게 부탁하지 않기 |
|
||||
| 직장인 | 반복 업무를 자동화하고, 효율을 높이며, 부업까지 개발하기 |
|
||||
| 제품 관리자 / 디자이너 | 아이디어가 종이에 머물지 않고, 상사나 고객에게 보여 줄 Demo를 빠르게 만들기 |
|
||||
| 창업자 / 중소기업 운영자 | 저비용으로 아이디어를 검증하고, 수만 위안을 들여 외주를 맡기지 않아도 MVP 만들기 |
|
||||
| 교사 / 교육 종사자 | 교육 도구, 수업 자료, 자동 문제 출제를 만들어 교육 효율 높이기 |
|
||||
| 의사 / 변호사 / 전문직 | 전문 업무 흐름을 자동화하고 자신만의 효율 도구 만들기 |
|
||||
| 누구나 | AI로 생활과 업무의 구체적인 문제를 해결하고, 불가능해 보였던 일을 가능하게 만들기 |
|
||||
| 학생 | 과제, 대회, 창업, 직접 프로젝트를 만들어 더 이상 다른 사람에게 부탁하지 않음 |
|
||||
| 직장인 | 반복 업무를 자동화하고, 효율을 높이며, 부업까지 개발 |
|
||||
| 제품 관리자 / 디자이너 | 아이디어가 더 이상 종이 위에만 머물지 않고, 빠르게 Demo를 만들어 상사/고객에게 보여줌 |
|
||||
| 창업자 / 중소기업주 | 저비용으로 아이디어를 검증하고, 수만 원을 들여 외주를 맡기지 않고도 MVP를 만듦 |
|
||||
| 교사 / 교육 종사자 | 교육 도구, 강의 자료, 자동 출제를 만들어 교육 효율을 높임 |
|
||||
| 의사 / 변호사 / 전문 직업인 | 전문 프로세스를 자동화하고, 자신만의 효율 도구를 구축 |
|
||||
| 누구나 | AI로 생활/업무의 구체적인 문제를 해결하고, 불가능을 가능하게 만듦 |
|
||||
|
||||
AI 시대에는 실행력과 아이디어가 언제나 기술보다 더 중요합니다.
|
||||
AI 시대에는 실행력과 아이디어가 항상 기술보다 더 중요합니다.
|
||||
|
||||
## 성장 경로: "AI를 쓸 줄 아는 사람"에서 "AI 제품을 만들 줄 아는 사람"으로
|
||||
## 성장 경로: "AI를 사용할 줄 아는 것"에서 "AI 제품을 만들 줄 아는 것"까지
|
||||
|
||||
<div class="stage-intro">
|
||||
<div class="stage-card">
|
||||
@@ -52,9 +55,9 @@ AI 시대에는 실행력과 아이디어가 언제나 기술보다 더 중요
|
||||
<h3>초보자 입문</h3>
|
||||
<p class="stage-role">AI 프로그래밍 체험</p>
|
||||
<div class="stage-tags">
|
||||
<span>스네이크 미니게임</span>
|
||||
<span>스네이크 미니 게임</span>
|
||||
<span>제로 베이스 시작</span>
|
||||
<span>Vibecoding 첫 경험</span>
|
||||
<span>Vibecoding 첫 체험</span>
|
||||
<span>몇 분 만에 생성</span>
|
||||
</div>
|
||||
</div>
|
||||
@@ -68,30 +71,30 @@ AI 시대에는 실행력과 아이디어가 언제나 기술보다 더 중요
|
||||
<div class="stage-tags">
|
||||
<span>AI IDE (Cursor/Claude)</span>
|
||||
<span>요구사항 분해 & 프로토타입</span>
|
||||
<span>AI 기능 접목</span>
|
||||
<span>완성 Demo 개발</span>
|
||||
<span>AI 능력 연동</span>
|
||||
<span>완전한 Demo 개발</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">💻</div>
|
||||
<h3>2단계</h3>
|
||||
<p class="stage-role">초중급 개발자 / 독립 개발자</p>
|
||||
<p class="stage-role">초중급 개발 / 인디 개발자</p>
|
||||
<div class="stage-tags">
|
||||
<span>Figma에서 코드로</span>
|
||||
<span>Supabase 데이터베이스</span>
|
||||
<span>Stripe 결제 통합</span>
|
||||
<span>Dify 지식베이스</span>
|
||||
<span>Stripe 결제 연동</span>
|
||||
<span>Dify 지식 베이스</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🚀</div>
|
||||
<h3>3단계</h3>
|
||||
<p class="stage-role">고급 개발자 / 아키텍트</p>
|
||||
<p class="stage-role">고급 개발 / 아키텍트</p>
|
||||
<div class="stage-tags">
|
||||
<span>Web/미니프로그램/멀티 플랫폼</span>
|
||||
<span>Web/미니프로그램/멀티플랫폼</span>
|
||||
<span>MCP 고급 도구</span>
|
||||
<span>RAG & LangGraph</span>
|
||||
<span>시니어 엔지니어 사고방식</span>
|
||||
<span>고급 엔지니어 사고</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -172,103 +175,101 @@ AI 시대에는 실행력과 아이디어가 언제나 기술보다 더 중요
|
||||
}
|
||||
</style>
|
||||
|
||||
이 완성된 학습 경로를 통해 당신은 다음을 얻게 됩니다.
|
||||
이 완전한 학습 경로를 통해, 다음을 얻게 됩니다:
|
||||
|
||||
- **Vibe Coding 개발 능력:** Vibecoding 사고방식과 AI 코딩 도구를 능숙하게 사용해 개발 효율을 몇 배로 높입니다. 더 이상 문법을 억지로 외우는 것이 아니라, AI가 고품질 코드를 생성하도록 이끄는 방법을 배웁니다.
|
||||
- **풀스택 개발 역량:** UI 디자인에서 프론트엔드 구현까지, 데이터베이스 설계에서 API 개발까지, 로컬 개발에서 클라우드 배포까지 현대 Web 애플리케이션의 전체 기술 스택을 익힙니다.
|
||||
- **AI 기능 통합:** 다양한 멀티모달 AI API를 호출하는 법을 배우고, 텍스트, 이미지, 음성 등 AI 기능을 애플리케이션에 매끄럽게 통합하며, RAG 같은 기술로 지능형 제품을 구축합니다.
|
||||
- **제품 사고와 운영 능력:** 사용자 조사에서 요구사항 분해까지, MVP 설계에서 제품 반복 개선까지, 결제 통합에서 사용자 관리까지, 완전한 제품 개발과 운영의 폐쇄 루프를 형성합니다.
|
||||
- **Vibe Coding 개발 능력:** vibecoding 사고와 AI 코딩 도구를 능숙하게 사용하여, 개발 효율을 몇 배로 높입니다. 더 이상 문법을 외울 필요 없이, AI가 고품질 코드를 생성하도록 안내하는 방법을 배웁니다.
|
||||
- **풀스택 개발 기술:** UI 설계에서 프론트엔드 구현, 데이터베이스 설계에서 API 개발, 로컬 개발에서 클라우드 배포까지, 현대 웹 애플리케이션의 완전한 기술 스택을 마스터합니다.
|
||||
- **AI 능력 통합:** 다양한 멀티모달 AI API를 호출하는 방법을 배우고, 텍스트, 이미지, 음성 등 AI 능력을 애플리케이션에 원활하게 통합하며, RAG 등의 기술을 통해 지능형 제품을 구축합니다.
|
||||
- **제품 사고와 운영 능력:** 사용자 조사에서 요구사항 분해, MVP 설계에서 제품 반복, 결제 연동에서 사용자 관리까지, 완전한 제품 개발과 운영 루프를 형성합니다.
|
||||
|
||||
# 다 배우고 나면 무엇을 할 수 있나요?
|
||||
# 배우고 나면 무엇을 할 수 있을까?
|
||||
|
||||
## 1단계: 나의 첫 제품 프로토타입 만들기
|
||||
## 1단계: 첫 번째 제품 프로토타입 만들기
|
||||
|
||||
이 단계는 프로그래밍 기초가 전혀 없거나, 조금은 알지만 자신감이 부족한 사람에게 적합합니다. 이론 지식을 잔뜩 먼저 배울 필요 없이, 바로 따라 만들면서 AI 도구로 코드를 작성하는 법을 배웁니다.
|
||||
이 단계는 프로그래밍 기반이 전혀 없거나, 조금은 알지만 자신감이 부족한 분들에게 적합합니다. 많은 이론 지식을 먼저 배울 필요 없이, 바로 따라 하면서 AI 도구로 코드를 작성하는 법을 배웁니다.
|
||||
|
||||
**배우고 나면 할 수 있는 것**:
|
||||
**배우고 나면 할 수 있는 것:**
|
||||
- AI 프로그래밍 도구로 독립적으로 웹 애플리케이션 하나를 완성
|
||||
- 제품 아이디어를 클릭 가능하고 상호작용 가능한 프로토타입으로 만들기
|
||||
- 프로토타입에 AI 기능 추가(예: 텍스트에서 이미지 생성, 스마트 대화)
|
||||
- 오류를 만났을 때 어떻게 파악하고 해결하는지 알기
|
||||
|
||||
- AI 프로그래밍 도구로 웹 애플리케이션 하나를 독립적으로 완성하기
|
||||
- 제품 아이디어를 클릭 가능하고 상호작용 가능한 프로토타입으로 바꾸기
|
||||
- 프로토타입에 AI 기능 추가하기. 예: 텍스트로 이미지 만들기, 지능형 대화
|
||||
- 오류가 났을 때 어떻게 확인하고 해결해야 하는지 알기
|
||||
간단히 말해, "실행 가능하고, 남에게 시연할 수 있는" 것을 만들 수 있게 됩니다.
|
||||
|
||||
간단히 말하면, "실행되고, 다른 사람에게 시연할 수 있는" 무언가를 만들 수 있게 됩니다.
|
||||
먼저 미니 게임을 통해 AI 프로그래밍을 체험하고, AI 프로그래밍 도구로 코드를 작성하고 오류를 수정하는 법을 배울 수 있습니다. 그다음 간단한 페이지부터 시작해 점차 상호작용이 가능한 다중 페이지 애플리케이션을 만들고, 텍스트에서 이미지 생성, 스마트 대화 같은 AI 기능을 추가합니다. 마지막으로 완전한 프로젝트를 독립적으로 완성하여, 여러분의 크리에이티비티가 실제로 실현될 가능성을 갖게 됩니다.
|
||||
|
||||
먼저 미니게임으로 AI 프로그래밍을 체감하고, AI 프로그래밍 도구가 코드를 작성하고 오류를 고치도록 도와주는 법을 배웁니다. 이어서 간단한 페이지에서 시작해 점차 상호작용 가능한 다중 페이지 애플리케이션을 만들고, 텍스트-이미지 생성, 지능형 대화 같은 AI 기능을 더합니다. 마지막에는 독립적으로 완성 프로젝트를 끝내며, 당신의 아이디어가 실제로 구현될 가능성을 갖게 됩니다.
|
||||
|
||||
# 왜 프로젝트 기반으로 훈련해야 할까요?
|
||||
# 왜 프로젝트 기반 훈련을 사용할까?
|
||||
|
||||
> **현실 세계의 도전**
|
||||
>
|
||||
> 이유는 사실 간단합니다. 대부분의 학습자가 현재 상태로 바로 직장에 들어가면, 실제 프로젝트와 상사/고객의 "사회적 혹독함" 앞에서 한 걸음도 나아가기 어려울 가능성이 큽니다. 현실 세계에서 더 흔한 장면은 이렇습니다.
|
||||
> 이유는 사실 간단합니다: 대부분의 학생이 현재 상태로 직장에 바로 들어가면, 실제 프로젝트와 상사/고객의 "사회적 수술" 아래서 한 걸음도 나아가기 어려울 가능성이 높습니다. 현실 세계에서 더 흔한 시나리오는:
|
||||
|
||||
> 지도교수 / 상사: 우리는 xxx를 만들려고 해. 목표는 yyy 효과를 내는 거야.
|
||||
> 당신의 멘토/상사: 우리는 xxx를 만들어야 하고, 목표는 yyy 효과를 달성하는 것입니다.
|
||||
>
|
||||
> 문서? 준비된 프레임워크? 상세한 요구사항 설명? 많은 경우 존재하지 않습니다.
|
||||
> 문서? 기존 프레임워크? 상세한 요구사항 설명? 많은 경우 존재하지 않습니다.
|
||||
|
||||
실제 업무 속 많은 과제는 본질적으로 높은 불확실성 속에서 한 번도 본 적 없는 문제를 해결하는 일입니다. 요구사항은 모호하고, 경계는 계속 변하며, 누구도 정답을 알려 주지 않습니다. 스스로 자료를 찾고, 실험하고, 프로토타입을 만들고, 계속 반복 개선한 끝에 "실행되고, 사용할 수 있고, 배포 가능한" 해결책을 내놓아야 합니다.
|
||||
실제 업무의 많은 과제는 본질적으로 고도로 불확실한 환경에서 한 번도 본 적 없는 문제를 해결하는 것입니다: 요구사항은 모호하고, 경계는 변하며, 아무도 정답을 알려주지 않습니다. 스스로 자료를 찾고, 실험을 하고, 프로토타입을 만들고, 끊임없이 반복하여, 마지막에 "실행 가능하고, 사용 가능하고, 온라인에 공개할 수 있는" 솔루션을 제시해야 합니다.
|
||||
|
||||
이 강의가 하려는 일은 비교적 안전한 환경에서 미리 한 번 "모의 사회적 혹독함"을 겪게 하는 것입니다.
|
||||
이 과정이 하고 싶은 것은, 비교적 안전한 환경에서, 미리 한 번 "모의 사회적 수술"을 경험하게 하는 것입니다:
|
||||
|
||||
- 어느 정도 난이도가 있어 보이는 프로젝트 과제를 통해 문제를 분해하고, 방안을 설계하고, 스스로 자료를 찾는 연습을 강제합니다.
|
||||
- 지나치게 "따라 하기만 하면 되는" 스캐폴딩과 코드가 아니라, 중대형 코드베이스를 읽고 이해하고 고치는 법을 배우게 합니다.
|
||||
- 아이디어에서 배포까지 이어지는 완전한 폐쇄 루프를 통해 실제 제품이 0에서 1로 만들어지는 전체 과정을 경험하게 합니다.
|
||||
- 겉보기에 약간 난이도가 있는 프로젝트 과제를 통해, 문제 분해, 솔루션 설계, 스스로 자료 찾기를 연습하게 함
|
||||
- 그다지 "쉬운" 스캐폴딩과 코드를 통해, 중대형 코드베이스를 읽고, 이해하고, 수정하는 법을 배움
|
||||
- 아이디어에서 온라인 공개까지의 완전한 루프를 통해, 실제 제품이 0에서 1이 되는 완전한 과정을 경험
|
||||
|
||||
단기적으로는 이런 훈련이 꽤 고통스러울 수 있습니다. 하지만 장기적으로는 구직과 커리어 성장에서 경쟁력을 크게 높여 줍니다. 더 큰 일을 감당할 수 있고, 불확실한 환경에서 돌파구를 찾을 수 있으며, AI를 "Demo를 가지고 노는 단계"에 머물게 하지 않고 실제 제품으로 구현할 능력을 갖추게 됩니다.
|
||||
단기적으로, 이런 훈련은 확실히 꽤 고역입니다; 하지만 장기적으로, 취업과 직업 발전에서 경쟁력을 크게 높여줍니다: 더 많은 일을 감당하고, 불확실한 환경에서 돌파구를 더 잘 찾으며, AI를 실제로 구현되는 제품으로 만드는 능력도 더 갖게 되어, "Demo만 가지고 놀기" 단계에 머물지 않게 됩니다.
|
||||
|
||||
# 질문의 기술: AI 시대의 필수 역량
|
||||
# 질문의 기술: AI 시대의 필수 스킬
|
||||
|
||||
AI 시대에는 질문도 일종의 "기본기"입니다. 같은 코드, 같은 오류라도 **어떻게 질문하느냐가 AI가 어떤 답을 줄 수 있는지를 거의 결정합니다**. 두루뭉술한 설명으로 끝날지, 아니면 단계별로 실행 가능한 수정 방법을 줄지가 달라집니다.
|
||||
AI 시대에는 질문하는 것도 하나의 "기본기"입니다. 같은 코드, 같은 오류에 대해, **어떻게 질문하느냐가 AI가 어떤 답을 줄 수 있는지를 거의 결정합니다**: 막연한 이야기인지, 아니면 단계별로 실행 가능한 수정 방법인지.
|
||||
|
||||
**좋은 습관을 들이세요**: "AI에게 질문하기"를 일상적인 개발 흐름의 일부로 생각하세요. 이해가 안 되거나 막히는 문제가 생기면 바로 질문합니다.
|
||||
**좋은 습관 들이기**: "AI에게 질문하기"를 일상 개발 프로세스의 일부로 만드세요: 모르거나 막힌 문제를 만나면 바로 물어보세요.
|
||||
|
||||
## 왜 이것이 필수 역량인가요?
|
||||
## 왜 이것이 필수 스킬인가?
|
||||
|
||||
- **현실에는 완전한 문서가 드뭅니다**: 더 자주 마주하는 것은 불명확한 요구사항, 반쯤 만들어진 코드, 흩어진 오류 정보입니다.
|
||||
- **AI는 당신 곁의 멘토이자 동료입니다**: 질문을 잘하는 사람은 AI를 "고품질 페어 프로그래밍 파트너"로 만들 수 있습니다.
|
||||
- **능력의 상한은 소통이 결정합니다**: 핵심 정보를 더 잘 제공하고, 출력 형식을 더 잘 제한할수록 답변은 더 쓸모 있어집니다.
|
||||
- **현실에는 거의 완전한 문서가 없음**: 더 많은 경우, 직면하는 것은 불명확한 요구사항, 반쯤 완성된 코드, 산발적인 오류 정보
|
||||
- **AI는 당신의 휴대용 멘토 + 동료**: 질문을 잘하는 사람은 그것을 "고품질 짝 프로그래밍"으로 만들 수 있음
|
||||
- **능력의 상한은 소통에 의해 결정됨**: 핵심 정보를 더 많이 제공하고, 출력 형식을 더 잘 제약할수록, 답이 더 사용 가능해짐
|
||||
|
||||
**흔한 오해**: "왜 오류가 나나요?"라고 한마디만 물으면 대부분 추측만 잔뜩 받게 됩니다. 맥락을 채워 넣어야 실행 가능한 방안을 얻습니다.
|
||||
**흔한 오해**: "왜 오류가 나?"라고 한마디만 물으면 보통 추측만 잔뜩 얻게 됩니다. 컨텍스트를 보완해야 실행 가능한 솔루션을 얻을 수 있습니다.
|
||||
|
||||
## 정보를 AI에게 "먹이는" 방법: 스크린샷 vs 복사/붙여넣기
|
||||
## AI에게 정보를 어떻게 "먹이는가": 스크린샷 vs 복사 붙여넣기
|
||||
|
||||
두 방식 모두 가능하지만 용도가 다릅니다.
|
||||
두 방식 모두 가능하지만, 용도가 다릅니다:
|
||||
|
||||
| 방식 | 적합한 상황 | 핵심 요구사항 |
|
||||
| 방식 | 적용 시나리오 | 핵심 요구사항 |
|
||||
| ------------ | ----------------------------------------- | ----------------------------------------- |
|
||||
| **복사/붙여넣기** | 오류 스택, 로그, 코드, 설정, API 응답 | 가능한 한 완전하게. 핵심 키워드 한 줄만 자르지 않기 |
|
||||
| **스크린샷** | UI 레이아웃 문제, 상호작용 이상, 도구 화면에서 버튼을 찾기 어려운 경우 | 전체 화면 캡처 + 중요 영역 표시. 가능하면 짧은 설명 한 문장 추가 |
|
||||
| **복사 붙여넣기** | 오류 스택, 로그, 코드, 설정, API 반환 | 가능한 한 완전하게, 키워드 한 줄만 자르지 마세요 |
|
||||
| **스크린샷** | UI 레이아웃 문제, 인터랙션 이상, 도구 인터페이스에서 버튼을 찾을 수 없음 | 전체 화면 캡처 + 핵심 영역 표시, 글로 된 설명 한 문장을 함께 제공하는 것이 좋음 |
|
||||
|
||||
::: danger ⚠️ 중요한 전제
|
||||
**모든 AI가 이미지 입력을 지원하는 것은 아닙니다.** 스크린샷으로 소통하려면 AI가 멀티모달 능력, 즉 이미지를 이해하고 분석할 수 있는 능력을 갖춰야 합니다. 현재 이미지 입력을 지원하는 AI에는 Claude(Anthropic), GPT-4V/GPT-4o(OpenAI), Gemini(Google), 그리고 일부 중국산 대형 모델인 Tongyi Qianwen, Wenxin Yiyan 등이 있습니다.
|
||||
**모든 AI가 이미지 입력을 지원하는 것은 아닙니다.** 스크린샷으로 소통하려면 AI가 멀티모달 능력(즉, 이미지를 이해하고 분석할 수 있는 능력)을 갖추어야 합니다. 현재 이미지 입력을 지원하는 AI에는 Claude(Anthropic), GPT-4V/GPT-4o(OpenAI), Gemini(Google), 그리고 일부 국산 대형 모델인 퉁이치엔원, 원신이연 등이 있습니다.
|
||||
|
||||
**사용 중인 AI가 이미지 입력을 지원하지 않는다면** 스크린샷은 인식되지 않습니다. 이때는 복사/붙여넣기로 텍스트를 전달하세요.
|
||||
**사용 중인 AI가 이미지 입력을 지원하지 않는다면**, 스크린샷이 인식되지 않으므로, 이때는 복사 붙여넣기 텍스트 방식으로 소통하세요.
|
||||
:::
|
||||
|
||||
## AI가 "잘 설명하게" 만드는 프롬프트 기법
|
||||
## AI가 "잘 설명해 주도록" 만드는 프롬프트 기술
|
||||
|
||||
정답만 필요한 것이 아니라 답을 "배우고" 싶다면, 아래와 같은 지시를 쓰면 설명 품질이 크게 올라갑니다.
|
||||
답만 원하는 것이 아니라, 답을 "배우고" 싶다면. 다음과 비슷한 지시어를 사용하면 설명 품질을 크게 높일 수 있습니다:
|
||||
|
||||
> **학습형 질문 예시**
|
||||
>
|
||||
> - "먼저 이 개념을 5문장으로 명확하게 설명한 뒤, 제가 제대로 이해했는지 확인할 질문을 몇 개 해 주세요."
|
||||
> - "이 오류 메시지를 자세히 설명해 주세요. 왜 오류가 나는지 이해가 안 됩니다."
|
||||
> - "먼저 5문장으로 이 개념을 명확히 설명한 다음, 몇 가지 질문을 통해 제가 제대로 이해했는지 확인해 주세요."
|
||||
> - "이 오류 메시지를 자세히 설명해 주세요. 왜 오류가 나는지 이해가 안 돼요."
|
||||
|
||||
# 오래 버텼는데도 해결이 안 됩니다. 포기하고 싶어요
|
||||
# 오래 참아도 안 풀려요, 포기하고 싶어요
|
||||
|
||||
어쩌면 버티는 방법이 맞지 않았을 수 있습니다. 혼자 어둠 속에서 억지로 버티지 말고, 작성자와 조교들에게 이야기해 보세요. 이미 시도한 방법, 만난 구체적인 막힘, 현재의 심리 상태를 솔직하게 말해 주세요. 많은 경우 방향을 조금만 조정하거나 핵심 지식 하나만 보충해도 계속 앞으로 나아갈 수 있습니다.
|
||||
아마도 당신이 고집하는 방법이 맞지 않을 수 있습니다. 혼자 어둠 속에서 버티지 말고, 작가와 조교들과 이야기해 보세요: 이미 시도한 방법, 만난 구체적인 막힌 점, 그리고 현재 심리 상태를 솔직하게 말하세요. 많은 경우, 방향을 조금만 조정하고, 핵심 지식을 하나만 보완하면, 다시 앞으로 나아갈 수 있습니다.
|
||||
|
||||
# 튜토리얼 설계가 합리적이지 않은 것 같아요
|
||||
# 튜토리얼의 일부 설계가 불합리하다고 생각해요
|
||||
|
||||
언제든 작성자에게 연락하거나 issue를 제출하거나, 그룹/수업에서 직접 피드백해 주세요. 우리는 여러분과 함께 이 튜토리얼을 점점 더 좋게 다듬고 싶습니다. 어디가 명확하지 않은지, 어디의 경험이 좋지 않은지, 어디에서 헛수고를 하게 되었는지 솔직하게 지적해 주세요. 더 실제적이고 구체적인 피드백일수록 뒤에 오는 학습자가 덜 헤매도록 도와줍니다.
|
||||
언제든지 작가에게 연락하거나, 이슈를 제출하거나, 그룹/수업에서 직접 피드백해 주세요. 우리는 여러분과 함께 이 튜토리얼을 점점 더 좋게 만들어 가고 싶습니다: 어디가 불명확한지, 어디서 경험이 좋지 않았는지, 어디서 헛되이 시간을 보냈는지, 모두 솔직하게 지적해 주세요. 더 진실하고, 더 구체적인 피드백일수록, 나중에 오시는 분들이 불필요하게 겪는 어려움을 줄이는 데 더 도움이 됩니다.
|
||||
|
||||
# Reference
|
||||
|
||||
- [난징대학교 컴퓨터과학기술학과 컴퓨터 시스템 기초 과정 실험](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
|
||||
- [난징대학교 컴퓨터과학기술학과 컴퓨터시스템기초 과정 실험](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="다음에 무엇을 배울 수 있나요"
|
||||
description="'AI를 쓸 줄 아는 단계'에서 '제품을 만들 줄 아는 단계'로 계속 앞으로 나아갑니다."
|
||||
title="다음에 무엇을 배울 수 있을까"
|
||||
description="AI를 사용할 줄 아는 것에서 제품을 만들 줄 아는 것까지의 경로를 따라 계속 나아가세요."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user