diff --git a/docs/ko-kr/stage-1/ai-capabilities-through-games/index.md b/docs/ko-kr/stage-1/ai-capabilities-through-games/index.md
index a16306c..0987388 100644
--- a/docs/ko-kr/stage-1/ai-capabilities-through-games/index.md
+++ b/docs/ko-kr/stage-1/ai-capabilities-through-games/index.md
@@ -1,133 +1,764 @@
----
-title: 'AI 시대, 말할 수 있으면 코딩할 수 있다'
-description: '작은 게임 예제를 통해 AI 코딩과 Vibe Coding의 기본 감각을 익히는 한국어 튜토리얼입니다.'
----
+# 초급 1: AI 시대에는 말할 수 있으면 프로그래밍할 수 있다
-# AI 시대, 말할 수 있으면 코딩할 수 있다
+이것은 **프로젝트 기반 학습** 튜토리얼입니다. 단계별로 따라 하며 결과를 재현해 보기를 권장합니다.
+실수하거나 내용을 수정하는 것을 걱정하지 마세요. 우리는 언제나 당신이 해낼 수 있다고 믿습니다. 반드시 기억하세요.
-처음부터 큰 제품을 만들려고 하면 어렵습니다. Stage 1의 첫 실습은 작고 분명한 예제에서 시작합니다. 예를 들어 "스네이크 게임을 만들어 줘"라고 말하고, AI가 만든 결과를 실행해 보며 수정하는 식입니다.
+
+
+ 완벽보다 완성이 더 중요합니다 🐣
+
+
-이 장의 목표는 코딩 문법을 외우는 것이 아닙니다. **AI와 함께 만드는 흐름**을 익히는 것입니다.
+
-AI는 다음 작업을 잘 도와줍니다.
+## 이 장의 가이드
-- 간단한 웹 페이지나 게임 생성
-- HTML, CSS, JavaScript 코드 작성
-- 오류 메시지 해석
-- 기능 추가와 UI 수정
-- 코드를 더 읽기 쉽게 정리
-- 초보자에게 코드 설명
+
-하지만 AI에게 모든 판단을 맡기면 결과가 흔들립니다. 사람이 해야 하는 일은 다음입니다.
+만약 당신이 프로그래밍을 전혀 할 줄 모르거나, 아주 조금만 알고 있다면, 이 장은 바로 당신을 위해 준비된 것입니다. 우리는 가장 기초적인 부분부터 시작합니다. 대화하는 방식으로 AI가 코드를 작성하게 하고, 문법을 외우지 않아도 되고, 환경을 설정하지 않아도 되며, 웹페이지에서 바로 실행할 수 있습니다.
-- 무엇을 만들지 정한다.
-- 결과가 원하는 방향인지 판단한다.
-- 너무 큰 요구를 작은 단계로 쪼갠다.
-- 이상한 결과가 나오면 구체적으로 피드백한다.
+당신은 직접 처음으로 실행 가능한 프로그램을 만들게 됩니다. “단어를 먹고, 시를 쓰고, 그림을 그리는” 스네이크 게임입니다. 이 실습을 통해 AI 프로그래밍이 어떤 느낌인지 체험하게 됩니다. AI가 당신을 대신해 생각하는 것이 아니라, 당신이 생각을 말로 꺼내고 AI가 그것을 구현해 주는 방식입니다.
-## 2. 첫 프롬프트 예시
+모든 창조는 0에서 1로 시작합니다. 모든 자신감과 전문성을 당신에게 전달할 수 있어 기쁩니다. 당신에게는 실행력 is all you need입니다.
-작은 게임을 만들 때는 이렇게 말할 수 있습니다.
+
-```text
-브라우저에서 바로 실행할 수 있는 스네이크 게임을 만들어 줘.
-HTML, CSS, JavaScript를 한 파일에 넣어도 괜찮아.
-방향키로 조작하고, 점수를 보여 주고, 게임 오버 후 다시 시작할 수 있게 해 줘.
-초보자가 읽기 쉽게 코드에 중요한 부분만 짧게 주석을 달아 줘.
+
+
+
+
+
+
+## 1. 일반인의 곤경과 기회
+
+많은 사람의 머릿속에는 제품 아이디어가 잔뜩 있습니다. 자신을 위한 가계부 작은 도구, 아이의 성장을 기록하는 웹페이지, 심지어 미니게임까지 있습니다. 하지만 코드를 써야 하고 프로그래머를 찾아야 한다고 생각하는 순간 바로 포기하게 됩니다.
+
+AI가 등장한 뒤, 일반인에게 처음으로 완전히 새로운 가능성이 열렸습니다. 코드를 쓸 줄 몰라도 됩니다. AI에게 원하는 것을 분명히 말하는 법만 배우면 됩니다. GitHub Copilot의 [데이터](https://www.wearetenet.com/blog/github-copilot-usage-data-statistics)에 따르면 1,500만 명이 넘는 개발자가 AI 보조 프로그래밍을 사용하고 있으며, 평균적으로 코드의 46%가 AI로 생성됩니다! Java 프로젝트에서는 이 비율이 61%에 도달할 수 있습니다.
+
+
+
+
+ 🚀
+ 효율과 도입률의 도약
+
+
+
+
+
+
+
55%
+
속도 향상
+
+
+
+
+
2.4 일
+
작업 소요 시간(기존 9.6일)
+
+
+
+
+
81%
+
첫날 설치율
+
+
+
+
+
96%
+
제안 채택률
+
+
+
+
+
+ 정말 흥미로운 것은 효율의 도약입니다. 개발자가 작업을 완료하는 속도가 55% 향상되었습니다. 원래 코드를 제출하는 데 9.6일이 필요했다면, 이제는 2.4일이면 처리할 수 있습니다. 이렇게 눈에 보이는 효율 향상은 AI가 더 이상 “선택 가능한 도구”가 아니라 개발 흐름에서 없어서는 안 될 프로그래밍 어시스턴트가 되고 있음을 보여 줍니다. 도입률 데이터도 이를 뒷받침합니다. 접근 권한을 얻은 당일에 개발자의 81%가 바로 설치를 완료하고 사용을 시작했으며, 그중 96%는 당일에 AI가 제공한 코드 제안을 채택하기 시작했습니다. 다시 말해 개발자들은 거의 즉시 AI를 일상적인 코딩 작업에 통합했습니다.
+
+
+
+일반인에게 이 흐름은 더 큰 의미가 있습니다. 전문 프로그래머도 AI에 크게 의존해 코드를 쓴다면, **프로그래밍을 모르는 우리도 왜 AI와 직접 대화해서 자기 아이디어를 구현할 수 없을까요?**
+
+이 수업의 목표는 당신이 새로운 능력을 익히도록 돕는 것입니다. 자연어 대화만으로 애플리케이션을 만들 수 있는 능력입니다. AI와 컴퓨터의 언어로 소통하는 법, 머릿속 아이디어를 실제로 사용할 수 있는 제품으로 바꾸도록 AI를 활용하는 법을 배웁니다.
+
+
+
+
+
+
+
+## 2. AI는 어느 정도까지 도와줄 수 있을까
+
+이 절에서는 한 가지 문제만 다룹니다. 당신이 코드를 전혀 쓸 줄 모른다면, 지금의 AI가 어느 정도까지 도와줄 수 있을까요?
+
+대략적으로 말하면, 현재 대형 모델의 능력은 **간단한 내부용 작은 도구**, **데이터 시각화 대시보드**, 그리고 일부 **가벼운 미니게임** 개발을 감당할 수 있는 수준이라고 이해하면 됩니다. 이런 능력은 **자기 사용 도구**를 만들거나 **제품 관리자 관점에서 요구사항을 검증**하는 데에는 기본적으로 충분합니다. 다만 버튼 한 번으로 바로 **상업용 성숙 제품**을 생성하려면, 보통 여전히 사람이 **프로세스 설계**와 **세부 다듬기**를 계속 최적화해야 합니다.
+
+이제 스네이크를 예로 들어, AI 프로그래밍이 현재 구체적으로 어디까지 가능한지 살펴보겠습니다.
+
+### 2.1 60초 만에 스네이크 게임 만들기
+
+먼저 수업에서 사용하는 실험 웹페이지 [z.ai](https://chat.z.ai/)를 여세요. `z.ai`는 Zhipu AI(중국의 선도적인 대형 언어 모델 회사 중 하나)가 개발한 AI 플랫폼이며, 핵심 능력은 Zhipu가 자체 연구 개발한 GLM 계열 대형 모델이 제공합니다. 이 플랫폼은 슬라이드 생성, 포스터 디자인, 풀스택 개발 등 여러 AI 기능을 통합합니다. 이 튜토리얼에서는 그중 풀스택 개발 모듈의 사용을 중점적으로 소개합니다.
+
+::: details 💡 “웹페이지에서 바로 프로그래밍”하는 새 방식이란?
+
+과거에는 웹 애플리케이션을 개발하려면 다음이 필요했습니다.
+- Python, Node.js 같은 프로그래밍 환경 설치
+- 코드 편집기 설정
+- HTML/CSS/JavaScript 같은 언어 학습
+- 각종 의존성과 오류 처리
+
+하지만 지금은 AI 프로그래밍 플랫폼의 도움으로 다음만 하면 됩니다.
+- 브라우저를 열고 웹페이지에 접속
+- 자연어로 원하는 기능을 설명
+- AI가 자동으로 코드를 생성하고 결과를 실시간으로 미리보기
+
+이런 “대화가 곧 프로그래밍”인 방식은 프로그래밍을 “코드 작성”에서 “요구사항 설명”으로 바꿉니다. 당신은 하위 기술 세부 사항을 신경 쓸 필요가 없고, AI에게 원하는 것을 명확히 알려 주기만 하면 됩니다. 그러면 AI가 아이디어를 실행 가능한 프로그램으로 바꿔 줍니다. 이것이 AI 시대 프로그래밍의 새로운 패러다임, 즉 **Vibe Coding(분위기식 코딩)** 입니다.
+:::
+
+
+
+간단한 요구사항을 입력한 뒤 **풀스택 개발** 버튼을 클릭하면, 웹페이지가 생성되는 전체 과정을 실시간으로 볼 수 있습니다. 보통 커피 한 잔을 내릴 시간 정도면 웹페이지가 자동으로 완성됩니다!
+
+```
+스네이크 게임을 만들어 주세요:
+1. 방향키로 뱀의 이동을 제어합니다.
+2. 먹이를 먹으면 뱀이 길어지고 점수가 증가합니다.
+3. 벽이나 자신의 몸에 부딪히면 게임이 끝납니다.
+4. 시작 버튼과 다시 시작 버튼이 있어야 합니다.
+5. 인터페이스는 간결하고 보기 좋아야 합니다.
```
-좋은 프롬프트는 길다고 좋은 것이 아닙니다. 다음 네 가지가 들어가면 충분합니다.
+
-- 실행 환경: 브라우저, Node.js, 모바일 등
-- 핵심 기능: 조작, 점수, 저장, 검색 등
-- 제약 조건: 한 파일, 외부 라이브러리 금지, 반응형 등
-- 원하는 품질: 초보자용, 깔끔한 UI, 주석 포함 등
+생성이 끝나면 오른쪽에 탐색 가능한 웹 인터페이스가 나타납니다. 페이지 내용을 위아래로 스크롤해 보거나, 페이지 상단의 🧭 버튼을 클릭해 전체 화면 모드로 전환해 결과를 확인할 수 있습니다.
-## 3. 결과를 바로 믿지 말고 실행하기
+> 상단 버튼의 역할은 왼쪽부터 차례대로 다음과 같습니다. 화살표 버튼은 사이드 대화 기록 영역을 펼치고, 연필 버튼은 새 대화를 만들며, 순환 화살표 버튼은 페이지를 새로고침하고, 나침반 버튼은 전체 화면 모드로 전환합니다. Download 버튼은 프로젝트 다운로드, <> 버튼은 코드 보기 전환, Publish 버튼은 프로젝트 게시에 사용됩니다.
-AI가 코드를 주면 반드시 실행해 봐야 합니다. 실행 과정에서 자주 만나는 문제는 다음과 같습니다.
+
-| 현상 | 원인 | 대응 |
-| --- | --- | --- |
-| 화면이 비어 있음 | HTML 연결 문제, JS 오류 | 브라우저 콘솔 오류를 AI에게 붙여 넣기 |
-| 버튼이 동작하지 않음 | 이벤트 연결 누락 | "이 버튼이 클릭되지 않는다"고 구체적으로 말하기 |
-| 디자인이 어색함 | 요구사항이 추상적임 | 원하는 레이아웃, 색, 간격을 더 구체화 |
-| 기능이 일부 빠짐 | 프롬프트가 너무 넓음 | 기능을 하나씩 추가 요청 |
+이 웹페이지의 소스 코드를 보고 싶다면 오른쪽 위의 코드 아이콘을 클릭해 전체 코드를 확인할 수 있습니다.
-## 4. 수정 요청은 작게 한다
+
-초보자가 가장 많이 하는 실수는 한 번에 너무 많은 수정을 요청하는 것입니다.
+::: tip 🌐 더 많은 AI 프로그래밍 도구 탐색하기
-좋은 수정 요청은 작습니다.
+z.ai 외에도 아래의 훌륭한 AI 프로그래밍 플랫폼을 시도해 볼 것을 추천합니다.
-```text
-게임 오버 화면에 현재 점수와 최고 점수를 보여 줘.
-다른 코드는 최대한 유지하고, 필요한 부분만 수정해 줘.
+| 도구 | 주소 | 특징 |
+|------|------|------|
+| **Google AI Studio**(추천) | [aistudio.google.com/apps](https://aistudio.google.com/apps) | Google 공식 제품이며 Gemini 모델을 지원하고 빠른 프로토타입 개발에 적합합니다 |
+| **Figma Make** | [figma.com/make](https://www.figma.com/make) | 디자인 도구와 깊게 통합되어 디자이너가 상호작용 프로토타입을 빠르게 구현하기에 적합합니다 |
+| **Coze** | [coze.com](https://www.coze.cn) | ByteDance가 출시한 AI Bot 개발 플랫폼이며, 노코드 시각적 구축 능력을 제공합니다. Doubao, Kimi 등 중국산 대형 모델과 깊게 통합되어 있고, 플러그인 마켓, 예약 작업, 여러 채널 배포(Feishu, WeChat 등)를 지원하므로 C-end 사용자를 위한 대화형 애플리케이션이나 기업 내부 지능형 어시스턴트를 빠르게 만들기에 적합합니다 |
+| **v0.dev** | [v0.dev](https://v0.dev) | Vercel이 만든 AI UI 생성 도구로, 설명을 입력하면 실행 가능한 React 컴포넌트 코드를 생성합니다 |
+| **Bolt.new** | [bolt.new](https://bolt.new) | StackBlitz가 출시한 AI 풀스택 개발 플랫폼으로, 완전한 Web 애플리케이션을 바로 생성하고 배포할 수 있습니다 |
+| **Lovable** | [lovable.dev](https://lovable.dev) | 고품질 React 애플리케이션 생성에 집중하며 GitHub 통합과 원클릭 배포를 지원합니다 |
+| **Replit Agent** | [replit.com](https://replit.com) | AI 프로그래밍 어시스턴트를 통합한 온라인 IDE이며, 여러 언어와 실시간 협업을 지원합니다 |
+
+웹 프로그래밍 도구에 대한 더 자세한 비교와 사용 튜토리얼을 알고 싶다면 확장 읽기인 [7가지 주요 Vibe Coding 온라인 플랫폼 실제 비교](../../stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md)를 참고하세요.
+:::
+
+### 2.2 대화식 프로그래밍은 무엇을 할 수 있고 무엇을 할 수 없을까
+
+이 절은 하나의 구체적인 문제에 집중합니다. 대화식 AI에만 의존하고 코드를 전혀 쓰지 않을 때, 그것이 일을 어디까지 밀고 갈 수 있을까요?
+경험적으로 비교적 안정적인 결론은 이렇습니다. AI는 “작지만 완전한” 것을 완성하도록 도울 수 있습니다. 하지만 “어느 정도까지 하면 충분한가”는 여전히 당신이 각 단계의 세부 절차를 직접 결정해야 합니다.
+
+#### “작고 명확한” 애플리케이션에 더 강하다
+
+앞의 스네이크 예시에서 이미 전형적인 패턴을 보았습니다.
+인터페이스와 상호작용을 분명히 말할 수 있다면, AI는 보통 몇 번의 대화 안에 열 수 있고, 클릭할 수 있고, 플레이할 수 있는 완전한 웹페이지를 조립할 수 있습니다.
+
+이런 작업에는 보통 몇 가지 공통 특징이 있습니다.
+
+- 범위가 명확함: 한 페이지 웹페이지, 간단한 내부 도구, 작은 플레이 방식
+- 결과가 보임: 브라우저에서 예상대로 동작하는지 즉시 검증할 수 있음
+- 오류 수정이 직접적임: 문제를 발견한 뒤 후속 대화에서 구체적인 현상을 지적하고 수정을 요청할 수 있음. 오류를 복사해 그대로 붙여 넣거나, 스크린샷을 붙여 넣어 AI가 수정하게 할 수 있음
+
+이 경계 안에서 대화식 AI는 실행력이 꽤 괜찮은 “보조 개발자”로 볼 수 있습니다. 매 라운드마다 자연어로 요구사항을 세분화하고 수정하기만 하면, 빠르게 사용할 수 있는 프로토타입을 얻을 수 있습니다.
+
+**AI가 독립적으로 작은 프로젝트를 완성할 성공률:**
+
+
+#### 대형 프로젝트에는 “프로세스 관점”이 필요하다
+
+작고 명확한 범위를 벗어나면, 몇 번의 대화만으로 AI가 복잡한 시스템을 처음부터 끝까지 완성해 주길 기대하는 것은 곧 한계에 부딪힙니다. 대형 프로젝트는 보통 백엔드를 연결하고, 데이터베이스를 붙이고, 서드파티 서비스를 통합해야 하며, 권한, 보안, 동시성, 다수의 비즈니스 규칙도 얽힙니다. 목표는 한 페이지 웹페이지가 아니라 기존 비즈니스와 깊게 연결된 전체 시스템을 납품하는 것입니다.
+
+이 경우 더 합리적인 방법은 모든 요구사항을 한꺼번에 AI에게 던지는 것이 아니라, 먼저 명확한 전체 프로세스를 정리하는 것입니다. 핵심 단계가 무엇인지, 각 단계의 입력과 출력 및 상태 변화가 무엇인지, 어떤 지점이 성능과 보안에 가장 민감한지를 파악합니다. 그런 다음 이 흐름도를 바탕으로 상대적으로 독립적인 부분을 분해해 대화식 AI에게 인터페이스, 모듈, 스크립트, 테스트를 생성하게 합니다.
+
+현재 능력으로 보면 AI는 작은 단계 하나하나를 가속하는 데 더 강합니다. 어떻게 단계를 나누고 어떻게 연결할지는 당신(또는 당신의 팀)이 결정해야 하며, 최종 아키텍처 설계, 시스템 통합, 운영 유지도 책임져야 합니다.
+
+#### 쓸 수 있는 것과 사용할 만한 것의 차이
+
+겉으로 보면 AI는 무엇이든 쓸 수 있을 것 같습니다. 하지만 이것들이 실제로 쓸 수 있는지, 어느 정도까지 쓸 수 있는지, 우리는 어떻게 구분해야 할까요?
+
+참고할 만한 경험칙은 다음과 같습니다.
+
+::: warning ⚠️ 적합한 상황 가이드
+
+- **프로토타입 / Demo / 내부 자사용 도구**: 첫 번째 버전을 AI에게 맡기고, 이후 직접 세부 사항을 반복 개선하기에 매우 적합합니다.
+- **실제 사용자를 대상으로 하는 대형 제품**: 보통 엔지니어가 아키텍처, 추상화, 성능, 유지보수에 장기적으로 투입되어야 합니다.
+- **강한 보안 / 강한 규정 준수 시스템(예: 결제, 리스크 관리, 의료 등)**: 현재 단계에서는 “생성한 뒤 바로 배포”해서는 안 되며, 엄격한 검토와 테스트 절차를 반드시 도입해야 합니다.
+ :::
+
+현재 당신은 AI를 효율적인 Demo 및 자사용 도구 파트너로 비교적 안심하고 볼 수 있습니다.
+더 많이 테스트하고, 더 많이 반복하며, “여기가 틀렸어. 고치고 이유를 설명해 줘”라고 몇 번 더 묻는다면, 프로토타입과 내부 도구 수준에서는 전체 품질이 대체로 충분하고 실천 가치도 있습니다.
+
+
+
+
+
+
+
+## 3. 실습: 당신의 첫 번째 AI 네이티브 애플리케이션
+
+다시 실습 부분으로 돌아갑시다. 앞부분에서 우리는 AI로 플레이 가능한 스네이크 프로토타입을 빠르게 만들었고, AI가 무엇을 할 수 있고 무엇을 할 수 없는지도 대략 알게 되었습니다. 이제 가장 기초적인 **vibe coding** 기술을 사용해 **현대판** AI 스네이크 게임을 만드는 법을 배웁니다. 뱀이 콩이 아니라 문자와 단어를 먹게 만들 것입니다. 마지막에는 게임이 먹은 문자와 단어를 바탕으로 시를 하나 생성하고 그림도 하나 그리게 합니다.
+이 실제 사례를 통해 새로운 프로그래밍 방식의 핵심 이념을 이해할 수 있습니다. 자연어로 요구사항을 명확하게 표현하는 법입니다.
+
+### 3.1 AI 네이티브 스네이크
+
+처음에는 가장 간단한 방식으로 대형 모델과 대화할 수 있습니다. 이렇게 하면 제품 프로토타입을 빠르게 얻을 수 있습니다. 채팅창에 바로 다음을 입력해 볼 수 있습니다.
+
+> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘
+>
+> 
+
+> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘. 다음을 지원해야 해.
+>
+> 1. 서로 다른 단어를 먹을 수 있고, 그 단어들은 상자 안에 수집되어야 해.
+> 
+
+> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘. 다음을 지원해야 해.
+>
+> 1. 서로 다른 단어를 먹을 수 있고, 그 단어들은 상자 안에 수집되어야 해.
+> 2. 뱀이 단어 8개를 먹으면, llm이 이 단어들을 바탕으로 시를 만들어야 하고, 필요에 따라 이 시를 다시 섞을 수 있어야 해.
+> 3. 시가 완성되면, 다음 단계에서 이 시를 바탕으로 이미지를 자동으로 만들어야 해.
+>
+> 
+
+개발 과정에서는 기대만큼 좋지 않은 문제를 만날 수 있습니다. 예를 들어 버튼을 클릭해도 아무 반응이 없거나, 기능을 사용할 때 오류가 나거나, 기능이 예상대로 작동하지 않거나, 프론트엔드 페이지가 기대한 디자인과 맞지 않을 수 있습니다.
+
+이런 상황에서는 모델에게 더 질문하여 예상치 못한 문제를 수정하도록 도와야 합니다.
+
+
+
+### 3.2 게임에 새 기능 추가하기
+
+기본 기능을 완성한 뒤에는 프로그램에 새로운 재미를 추가해 볼 수 있습니다! 뱀이 단어나 문자를 먹는 과정이 조금 지루하다고 느껴진다면, 뱀이 서로 다른 색상의 단어를 먹고 그에 따라 뱀의 색도 바뀌게 할 수 있습니다.
+
+“먹는” 과정에 특수 효과를 추가할 수도 있고, 특수 효과를 발동하는 마법 단어를 도입할 수도 있습니다. 예를 들어 뱀의 속도나 크기를 증가시키는 단어입니다. 또 다른 아이디어는 뱀이 단어를 8개 먹을 때까지 기다리는 대신, 단어를 하나 먹을 때마다 모델이 시와 그림을 생성하게 하는 것입니다.
+
+이것들이 어렵게 느껴진다면 언어 모델에게 직접 도움을 요청할 수 있습니다! 모델은 창의적인 제안을 제공해 게임을 더 흥미롭게 만들 수 있습니다. 한번 시도해 보세요!
+
+```
+1. "단어로 세계 잠금 해제" 메커니즘
+뱀이 단어 하나를 먹을 때마다 LLM이 해당 단어를 시적으로 연상합니다. 예: “나무” → “숲”, “초록 그늘”. 이미지 모델은 즉시 그 단어를 위한 작은 예술품을 생성합니다. 이 이미지들은 점차 하나의 독특한, 플레이어가 만든 파노라마로 조립되므로, 플레이어는 매번 플레이할 때 “그림을 그리고 시를 쓰는” 셈입니다.
+
+2. "시 퍼즐" 플레이 방식
+뱀이 먹는 각 단어는 LLM이 짧은 시구를 생성하게 하고, 이미지 모델은 삽화를 생성합니다. 이 시구와 이미지는 퍼즐처럼 결합되어 라운드가 끝날 때 AI와 협업한 시와 그림을 형성합니다.
+
+3. "마법 단어" & "스토리 분기"
+특수한 “마법 단어”(예: “바람”, “밤”, “꿈”)는 LLM이 시를 생성하게 할 뿐 아니라 장면의 정서나 주제를 바꿉니다. 생성 이미지의 스타일을 밤, 폭풍우, 꿈같은 분위기로 전환합니다.
+분기 스토리: LLM은 시작 시 하나의 주제나 수수께끼를 제공합니다. 예: “가을의 기억”. 플레이어의 단어 선택은 이야기와 시의 진화에 직접 영향을 미치며, 이미지 모델은 배경과 시각 효과를 실시간으로 업데이트합니다.
+
+4. "실시간 상호작용 생성"
+각 단어 이후 LLM은 한 줄의 대화나 묘사를 생성합니다. 게임 속 NPC가 플레이어에게 “말”하거나, 환경이 그에 따라 바뀔 수 있습니다.
+이미지 모델 덕분에 뱀의 외형이나 게임 속 장애물도 먹은 단어에 따라 시각적으로 달라질 수 있습니다.
+
+5. "창작 & 공유"
+플레이어는 세션이 끝날 때 AI가 창작한 시와 이미지를 저장하고 공유하여, 자신만의 독특한 “AI 협업” 결과물을 자랑할 수 있습니다.
+“가장 아름다운 시+예술”, “가장 창의적인 단어 조합” 같은 순위표를 통해 재플레이와 창의성을 장려합니다.
+
+6. "문장별 스네이크" 도전
+역방향 모드: LLM이 시 한 줄이나 수수께끼를 주면, 플레이어는 뱀을 이끌어 순서대로 단어를 먹게 하여 문장을 재구성해야 합니다. 잘못된 단어를 먹으면 이미지 생성 모델이 재미있거나 예술적인 결과를 발동합니다.
+
+7. "테마 스테이지" & "스타일 선택"
+게임 시작 시 플레이어는 하나의 테마를 선택합니다. 예: “동화”, “SF”, “당시”. LLM과 이미지 모델은 단어 선택, 시 스타일, 시각 효과를 모두 조정해 테마와 맞추므로 매번 새롭게 느껴집니다.
+
+8. "현장 공동 창작"
+특수 단어를 먹었을 때 LLM은 플레이어에게 문구를 입력하거나 스타일을 선택하라고 요청할 수 있습니다. 그런 다음 AI가 이에 맞는 시구와 삽화를 생성하여 진정한 인간-AI 공동 창작이 되게 합니다.
+
+9. "AI 이스터에그 & 업적"
+어떤 단어 조합은 LLM이 특수 주제나 내부 농담으로 인식합니다. 예: “달”, “계수나무꽃”, “강가”. 그러면 희귀한 시구와 삽화가 발동되어 탐색을 보상합니다.
+
+10. "성장하는 이야기"
+뱀이 성장함에 따라 LLM은 연속적인 이야기시를 생성하고, 이미지 모델은 매끄러운 긴 두루마리나 파노라마를 만듭니다. 그래서 플레이어는 동시에 “쓰기, 그리기, 플레이하기”를 하게 됩니다.
```
-나쁜 수정 요청은 모호합니다.
+또한 LLM에게 프로젝트 수준의 프롬프트를 직접 생성해 달라고 요청할 수도 있습니다. 지난 절에서는 스네이크 게임의 프롬프트만 우리가 직접 작성했습니다. 이제 대형 모델에게 전체 프레임워크와 구현 경로가 포함된 프롬프트를 생성하게 해 봅시다. z.ai로 바로 생성할 수 있습니다.
-```text
-더 좋게 만들어 줘.
+더 좋은 프롬프트를 작성하는 법을 배우고 싶다면 [프롬프트 엔지니어링 부록](/ko-kr/appendix/8-artificial-intelligence/prompt-engineering)을 확인하세요.
+
+> AI가 웹 스네이크 게임을 생성하게 하고 싶습니다. 더 완성도 높은 프롬프트가 필요합니다. 생성 결과가 더 인상적이고 재미있어야 합니다. 이에 맞는 프롬프트를 생성해 주세요. 현재 목표는 다음과 같습니다. 서로 다른 단어를 먹으면 시를 생성하는 기능이 있는 스네이크 게임을 만들고, 이미지 생성 모듈도 포함해야 합니다.
+
+z.ai의 답변은 다음과 같을 것입니다.
+
+
+
+이 프롬프트를 사용해 풀스택 개발 모드에서 프로젝트를 다시 생성할 수 있습니다.
+
+
+
+
+
+
+
+
+
+
+
+### 3.3 다른 미니게임 만들어 보기
+
+스네이크(게임) 외에도 상상력을 마음껏 펼칠 수 있습니다.
+
+우리가 만들고 싶은 무엇이든 만들어 보세요. 심지어 모든 것을 망쳐 보는 시도도 해 보세요! 그리고 처음부터 다시 시작하면 됩니다!
+
+```
+1. AI 아트 갤러리 플랫폼
+ 설명: AI 생성 예술 작품을 전시하는 온라인 갤러리. 사용자는 AI 예술 작품을 업로드하고 공유하고 댓글을 달 수 있습니다.
+ 기능: 사용자 계정 시스템, 예술 작품 업로드와 전시, 평점 시스템, 카테고리 탐색, AI 생성 도구 통합.
+ 기술 포인트: React/Vue 프론트엔드, Node.js 백엔드, MongoDB 데이터베이스, AI API 통합.
+
+2. 레트로 게임 아카이브
+ 설명: 고전 게임에 경의를 표하는 웹사이트. 게임 역사, 플레이 가이드, 온라인으로 플레이 가능한 레트로 게임을 포함합니다.
+ 기능: 게임 데이터베이스, 타임라인 전시, 온라인 에뮬레이터, 사용자 댓글, 게임 컬렉션 기능.
+ 기술 포인트: 반응형 디자인, WebGL/Canvas 게임 구현, RESTful API, 사용자 인증 시스템.
+
+3. 지속 가능한 생활 추적기
+ 설명: 친환경 팁과 커뮤니티 챌린지를 통해 사용자가 탄소 발자국을 추적하고 줄이도록 돕는 웹사이트.
+ 기능: 개인 탄소 발자국 계산기, 목표 설정, 진행 상황 추적, 커뮤니티 챌린지, 친환경 지식 베이스.
+ 기술 포인트: 데이터 시각화, 모바일 최적화, 소셜 기능, 푸시 알림.
+
+4. 가상 주방 어시스턴트
+ 설명: AI 기반 요리 안내 플랫폼. 개인화된 레시피 추천과 단계별 조리 설명을 제공합니다.
+ 기능: 레시피 데이터베이스, 식재료 인식, 개인화 추천, 조리 타이머, 영양 분석.
+ 기술 포인트: 이미지 인식 API, 머신러닝 추천 시스템, 음성 제어, 실시간 영상 안내.
+
+5. 언더그라운드 음악 발견 플랫폼
+ 설명: 독립 및 신진 아티스트에 집중한 음악 스트리밍 플랫폼. 독특한 발견 경험을 제공합니다.
+ 기능: 음악 스트리밍, 아티스트 프로필, 개인화 추천, 플레이리스트 생성, 커뮤니티 댓글.
+ 기술 포인트: 오디오 스트림 처리, 추천 알고리즘, 소셜 기능, 음악 시각화.
+
+6. 미니멀 작업 관리 시스템
+ 설명: 명상적인 미학을 가진 작업 관리 도구. 단순하고 효율적인 작업 정리에 집중합니다.
+ 기능: 작업 생성과 분류, 우선순위 설정, 진행 상황 추적, 팀 협업, 데이터 분석.
+ 기술 포인트: 미니멀 UI 디자인, 드래그 앤 드롭 기능, 실시간 동기화, 크로스 플랫폼 호환성.
+
+7. SF 글쓰기 공방
+ 설명: SF 작가를 위한 창작 도구와 영감을 제공하는 플랫폼. 세계관 구축 보조와 캐릭터 개발 도구를 포함합니다.
+ 기능: 이야기 구조 도구, 캐릭터 프로필, 세계관 구축 템플릿, 글쓰기 통계, 커뮤니티 피드백.
+ 기술 포인트: 리치 텍스트 에디터, 데이터 시각화, 협업 편집, AI 보조 창작.
+
+8. 개인 지식 그래프
+ 설명: 사용자가 개인 지식 네트워크를 구축하고, 다양한 생각과 정보를 시각화하고 연결하도록 돕는 도구.
+ 기능: 노드 생성과 연결, 태그 시스템, 검색 기능, 가져오기/내보내기 도구, 시각화 차트.
+ 기술 포인트: 그래프 데이터베이스, 데이터 시각화 알고리즘, Markdown 지원, 여러 기기 동기화.
+
+9. 가상 식물원
+ 설명: 상호작용형 식물 백과사전. 사용자는 식물 세계를 탐색하고 가상 정원을 만들 수 있습니다.
+ 기능: 식물 데이터베이스, 3D 식물 모델, 성장 시뮬레이션, 원예 가이드, 커뮤니티 전시.
+ 기술 포인트: 3D 렌더링, 계절 변화 시뮬레이션, AR 통합, 식물 인식 API.
+
+10. 프로그래밍 챌린지 아레나
+ 설명: 프로그래머를 위한 온라인 경기 플랫폼. 다양한 난이도의 프로그래밍 챌린지를 제공합니다.
+ 기능: 챌린지 문제, 코드 에디터, 자동 평가, 순위표, 학습 경로.
+ 기술 포인트: 코드 샌드박스 환경, 실시간 평가 시스템, 알고리즘 시각화, 소셜 학습 기능.
```
-AI는 "더 좋게"의 기준을 모릅니다. 초보자일수록 원하는 변화를 눈에 보이는 단위로 말하는 것이 중요합니다.
+그리고... 게임을 좋아한다면, 함께 게임을 만들어 봅시다!
-## 5. AI 코딩에서 중요한 습관
+```
+1. 3D 오픈월드 RPG
+ 설명: 광활한 오픈월드, 퀘스트, 캐릭터 성장이 있는 판타지 RPG.
+ 기능: 낮밤 순환, 동적 날씨, 스킬 트리, 멀티플레이 협동, 제작 시스템.
+ 기술 포인트: 3D 렌더링을 위한 Three.js 또는 Babylon.js, 서버 측 게임 로직, 캐릭터 커스터마이징, 저장 시스템.
-### 5.1 한 번에 하나씩 바꾸기
+2. 1인칭 슈팅(FPS) 아레나
+ 설명: 다양한 게임 모드와 맵이 있는 빠른 템포의 멀티플레이 FPS.
+ 기능: 팀 데스매치, 깃발 뺏기, 무기 커스터마이징, 랭크전.
+ 기술 포인트: 3D 그래픽을 위한 WebGL/Three.js, 멀티플레이 네트워크 코드, 명중 판정, 음성 채팅.
-기능을 하나 추가하고 실행합니다. 디자인을 하나 바꾸고 확인합니다. 그래야 문제가 생겼을 때 원인을 찾기 쉽습니다.
+3. AI 체스와 멀티플레이 게임
+ 설명: AI 상대와 온라인 대전 기능을 가진 완전한 체스 플랫폼.
+ 기능: AI 난이도 단계, 엔드게임 챌린지, 토너먼트 모드, 리플레이 분석.
+ 기술 포인트: 체스 로직 라이브러리, 실시간 대전을 위한 WebSocket, ELO 랭킹 시스템, 부정행위 방지.
-### 5.2 오류 메시지를 그대로 보여 주기
+4. 마작 온라인 멀티플레이 게임
+ 설명: 온라인 멀티플레이와 점수 계산 기능이 있는 전통 마작 게임.
+ 기능: 여러 규칙 세트, 비공개 방, 랭킹 시스템, 리플레이 기능.
+ 기술 포인트: 패 매칭 로직, 실시간 멀티플레이, 로비 시스템, 점수 추적.
-오류 메시지는 AI에게 가장 좋은 단서입니다. "안 돼요"보다 "콘솔에 이런 오류가 나와요"가 훨씬 효과적입니다.
+5. 턴제 전략 게임
+ 설명: 격자 전투와 유닛 관리가 있는 전술 전략 게임.
+ 기능: 캠페인 모드, 스커미시, 유닛 업그레이드, 전장의 안개, 멀티플레이 대전.
+ 기술 포인트: 격자 이동 시스템, AI 의사결정, 턴 동기화, 저장/불러오기 시스템.
-```text
-아래 오류가 나면서 게임이 시작되지 않아.
-원인을 설명하고 수정 코드를 제안해 줘.
+6. 타임 트라이얼 레이싱 게임
+ 설명: 시간 기록과 트랙 기록에 집중한 3D 레이싱 게임.
+ 기능: 여러 트랙, 자동차 커스터마이징, 고스트 리플레이, 순위표.
+ 기술 포인트: 3D 자동차 물리, 트랙 에디터, 리플레이 시스템, 온라인 순위표.
-[여기에 오류 메시지 붙여넣기]
+7. 카드 대전 게임(덱 빌딩)
+ 설명: 플레이어가 덱을 구성하고 상대와 싸우는 전략 카드 게임.
+ 기능: 카드 수집, 덱 구성, 랭크전, 시즌 이벤트.
+ 기술 포인트: 카드 게임 로직, 매칭 시스템, AI 상대, 카드 애니메이션.
+
+8. 배틀로얄(탑다운 2D)
+ 설명: 축소되는 게임 구역과 전리품 메커니즘이 있는 탑다운 2D 배틀로얄 게임.
+ 기능: 솔로 및 스쿼드 모드, 다양한 무기, 게임 내 이벤트, 순위표.
+ 기술 포인트: 실시간 멀티플레이, 구역 축소 로직, 전리품 생성 시스템, 매칭.
+
+9. 공포 생존 게임(1인칭)
+ 설명: 자원 관리와 탈출 메커니즘이 있는 1인칭 공포 게임.
+ 기능: 분위기 있는 환경, 퍼즐, 적 AI, 다중 결말.
+ 기술 포인트: 동적 조명, 사운드 디자인, 적 경로 탐색, 저장 시스템.
+
+10. 음악 리듬 게임(3D)
+ 설명: 플레이어가 음악 박자에 맞춰 노트를 치는 3D 리듬 게임.
+ 기능: 여러 난이도 단계, 트랙 에디터, 사용자 지정 곡 지원, 순위표.
+ 기술 포인트: 오디오 분석, 비트 동기화, 3D 노트 트랙, 입력 타이밍 판정.
```
-### 5.3 코드 전체를 이해하려 하지 않아도 된다
+## 📚 과제
-처음에는 전체 코드를 완벽히 이해하지 않아도 됩니다. 대신 다음 정도를 구분하면 됩니다.
+
+
+
🎯 이 장의 과제: 첫 번째 AI 네이티브 미니게임 묶음 완성하기
+
-- 화면 구조를 담당하는 HTML
-- 디자인을 담당하는 CSS
-- 동작을 담당하는 JavaScript
+
+ 이 절에서 당신은 “대화로 스네이크 생성하기”부터 “AI 네이티브 미니게임 설계 사고 이해하기”까지의 전체 흐름을 단계별로 경험했습니다. 아래 과제는 이러한 이해를 진짜 자신의 능력으로 바꾸도록 돕습니다.
+
-## 6. 작은 게임에서 제품으로 넘어가기
+
+
+ AI 네이티브 스네이크 게임 완전히 재현하기
+
+
최소한 다음을 구현하세요. 뱀이 움직일 수 있고, “먹이”를 먹으면 길이와 점수가 변하며, 벽이나 자기 몸에 부딪히면 종료되어야 합니다.
+
재현 과정에서 오류 현상 + 오류 정보 + 핵심 코드 조각을 한 번에 AI에게 던지고, “초보자 모드”로 수정해 달라고 요청하는 연습을 하세요.
+
+
+
+ (선택) 직접 AI 네이티브 미니게임 또는 Demo 1개 만들기
+
+
문자, 이미지, 음악, 리듬 등을 중심으로 한 어떤 가벼운 플레이 방식도 가능합니다. 예: “단어를 먹고 시 쓰기”, “리듬 클릭”, “생성형 러닝 게임” 등.
+
중요한 것은 화면이 얼마나 화려한지가 아니라, AI가 여기서 구체적으로 어떤 도움을 주었는지, 그리고 어떤 “사람이 직접 하기 어렵거나 번거로운” 부분을 해결했는지 분명히 말할 수 있는 것입니다.
+
+
+
-게임 예제의 목적은 게임 개발자가 되는 것이 아닙니다. 이 과정에서 다음 감각을 얻는 것이 중요합니다.
+
+ 이것이 전체 튜토리얼입니다! 모든 내용을 완료하고 자신만의 스네이크 게임을 만들려면 4시간이 필요할 수 있습니다. 서두르지 마세요. 탐색하고, 실험하고, 이 과정을 즐기세요. 진행 중 이해하기 어려운 개념을 만나면 아래 부록의 관련 부분을 바로 확인하는 것을 추천합니다.
+
+
-- 자연어 요구사항이 코드로 바뀌는 과정
-- 실행 결과를 보고 피드백하는 과정
-- 오류를 발견하고 수정하는 과정
-- 기능을 단계적으로 확장하는 과정
+## 부록
-이 네 가지는 나중에 업무 도구, AI 챗봇, 이미지 생성 앱, 예약 시스템을 만들 때도 그대로 쓰입니다.
+
+
부록 내비게이션
+
+ 여기에는 이 장과 관련된 몇 가지 기초 개념을 정리했습니다. 학습 과정에서 “프론트엔드가 무엇인가”, “Vibe Coding이 정확히 무엇을 뜻하는가” 같은 문제를 만나면 언제든 여기로 돌아와 확인할 수 있습니다.
+
+ 작은 팁: Ctrl/⌘+F로 키워드를 검색하거나, 이해되지 않는 단락을 AI에게 복사해 주고 “완전 초보자도 이해할 수 있는 방식”으로 다시 설명해 달라고 요청할 수 있습니다.
+
+
-## 과제
+## [부록 1: 프론트엔드 개발 지식이 필요한가요?](#appendix-nav)
-다음 중 하나를 골라 AI에게 만들어 달라고 요청해 보세요.
+::: tip 💡 한 문장 요약
+코드를 쓸 줄 몰라도 됩니다. 하지만 기본 개념을 이해하면 AI에게 요구사항을 더 잘 설명할 수 있습니다.
+:::
-1. 스네이크 게임
-2. 타자 연습 게임
-3. 간단한 할 일 목록 앱
-4. 랜덤 점심 메뉴 추천기
-5. 퀴즈 게임
+
+
+
+
+
+ 👁️
+ 프론트엔드
+ 보임
+
+
+
+ 사용자가 볼 수 있고, 클릭할 수 있는 모든 내용
+
+
웹페이지 제목, 텍스트, 이미지
+
버튼, 입력창, 드롭다운 메뉴
+
게임 화면, 애니메이션 효과
+
+
+
+
+
+
+
+
+ ⚙️
+ 백엔드
+ 보이지 않음
+
+
+
+ 서버에서 실행되는 데이터 처리
+
+
사용자 점수 저장
+
로그인 계정 검증
+
스테이지 콘텐츠 배정
+
+
+
+
+
-완성 후에는 다음 세 가지를 추가로 요청해 보세요.
+### 프론트엔드 3종 세트
-- 화면을 더 보기 좋게 다듬기
-- 모바일에서도 잘 보이게 만들기
-- 오류나 빈 상태를 처리하기
+브라우저는 세 가지 “코드”를 통해 페이지를 구성합니다.
-## 다음으로
+
+
+
+
+
-[AI IDE 도구 익히기](/ko-kr/stage-1/introduction-to-ai-ide/)에서 로컬 프로젝트를 열고 AI와 함께 개발하는 기본 흐름을 익힙니다.
+### 코드는 어떻게 페이지가 될까?
+웹페이지를 열면 브라우저는 세 가지 코드를 순서대로 처리합니다.
+
+**1. HTML - 페이지 구조 정의**
+브라우저는 먼저 HTML을 해석하여 페이지 위에 어떤 요소(제목, 문단, 이미지, 버튼 등)가 있는지, 그리고 그들의 계층 관계가 어떤지 이해합니다.
+
+**2. CSS - 스타일 적용**
+그다음 브라우저는 CSS 규칙에 따라 이 요소들에 스타일을 추가합니다. 색상, 크기, 위치, 간격 등을 적용해 페이지를 보기 좋게 만듭니다.
+
+**3. JavaScript - 상호작용 추가**
+마지막으로 JavaScript 코드를 실행해 페이지를 “움직이게” 합니다. 클릭 응답, 폼 제출, 애니메이션 재생 등을 처리합니다.
+
+**4. 페이지 표시**
+세 가지가 함께 작동한 결과가 최종적으로 보이는 웹페이지입니다.
+
+### 현대 프론트엔드 프레임워크: HTML에서 React/Vue까지
+
+앞서 소개한 HTML, CSS, JavaScript는 프론트엔드 개발의 “3종 세트”이며, 모든 웹페이지의 기초입니다. 하지만 페이지가 복잡해지면 이 3종 세트만으로 직접 개발할 때 어려움이 생깁니다. 코드 유지보수가 어렵고, 반복 작업이 많으며, 데이터 동기화가 번거롭습니다.
+
+**현대 프론트엔드 프레임워크**(예: React, Vue, Angular)는 HTML/CSS/JS 위에 구축되어 개발을 더 효율적으로 만듭니다.
+
+**1. HTML/CSS/JS(기초 단계)**
+페이지 요소를 직접 조작하며 간단한 페이지에 적합합니다. 하지만 코드량이 많아지면 모든 로직이 뒤섞여 유지보수가 어려워집니다.
+
+**2. jQuery(과도기 단계)**
+DOM 조작을 단순화해 코드를 더 간결하게 만들었습니다. 하지만 여전히 페이지 상태를 수동으로 관리해야 하며, 데이터가 변할 때 직접 해당 요소를 찾아 업데이트해야 합니다.
+
+**3. React/Vue(현대 단계)**
+컴포넌트화와 상태 주도 설계를 채택합니다.
+- **컴포넌트화**: 페이지를 독립적이고 재사용 가능한 모듈로 나눕니다. 예: 버튼, 카드, 내비게이션 바.
+- **상태 주도**: 데이터가 변하면 프레임워크가 해당 인터페이스를 자동으로 업데이트합니다. 수동 조작이 필요 없습니다.
+
+::: tip 💡 간단한 이해
+- **HTML/CSS/JS** = 기초 재료(벽돌, 시멘트, 철근)
+- **React/Vue** = 건축 프레임워크(집을 짓기 위한 규범과 도구 제공)
+
+AI 보조 프로그래밍 시대에는 프레임워크의 모든 세부 사항을 깊게 익힐 필요는 없습니다. 기본 개념만 이해하면 자연어 설명을 통해 AI가 코드를 생성하게 할 수 있습니다.
+:::
+
+### Vibe Coding에서는
+
+**핵심 요점: 코드를 쓸 필요는 없고, 설명할 줄 알면 됩니다.**
+
+프론트엔드 개념을 이해한 뒤에는 AI에게 이렇게 요구사항을 설명할 수 있습니다.
+
+> "React로 순위표 페이지를 만들어줘. 오른쪽에는 점수 목록을 표시하고, 어떤 행을 클릭하면 아래에 플레이어 상세 정보를 보여 줘. 스타일은 간결하고 모던하게 해줘."
+
+HTML, CSS, JavaScript 같은 프론트엔드 기초 지식을 더 깊이 이해하고 싶다면 [Web 기초 부록](/ko-kr/appendix/3-browser-and-frontend/javascript-deep-dive)을 확인하세요. 프론트엔드 기술의 발전 역사를 알고 싶다면 [프론트엔드 진화사 부록](/ko-kr/appendix/3-browser-and-frontend/frontend-frameworks)을 확인하세요.
+
+## [부록 2: Vibe Coding은 대체 무엇인가](#appendix-nav)
+
+> 💡 Vibe Coding이란 무엇인가요? 컴퓨터 과학자 [Andrej Karpathy](https://karpathy.ai/)(OpenAI 공동 창립자 중 한 명이자 Tesla 전 AI 책임자)는 2025년 2월 **vibe coding**이라는 용어를 제안했습니다. 이 개념은 LLM에 의존하는 코딩 방법을 가리키며, **프로그래머가 코드를 직접 작성하는 대신 자연어 설명을 제공하여 작동 가능한 코드를 생성할 수 있게 합니다.**
+
+
+
+문자 그대로 보면 Vibe Coding은 “말로 개발하는 방식”으로 이해할 수 있습니다. 핵심 변화는 다음과 같습니다. 더 이상 코드를 한 줄씩 직접 쓰고, 문법을 찾고, Bug를 고칠 필요가 없습니다. 원하는 것을 자연어로 바로 설명합니다. 예를 들면 다음과 같습니다.
+
+“휴대폰 번호 입력창과 인증번호 입력창이 있는 로그인 페이지가 필요해.”
+“로그인에 성공하면 홈으로 이동하고, 오른쪽 위에 사용자 이름을 보여 줘.”
+“키보드 방향키로 조작할 수 있는 간단한 스네이크 미니게임을 만들어줘.”
+대형 언어 모델(LLM)은 이런 설명을 실제로 실행 가능한 코드로 자동 번역하고, 대응되는 페이지, 로직, 데이터 구조를 생성합니다. 결과를 확인한 뒤에는 자연어로 수정 의견을 제시합니다. 예를 들어 “버튼을 더 크게 해줘”, “배경을 어두운 색으로 바꿔줘”, “점수 기록을 저장하고 순위표에 보여 줘”라고 말하면 AI가 요구에 따라 계속 구현을 조정합니다.
+
+이런 방식에서는 먼저 프로그래밍 언어를 배운 뒤 코드를 쓰는 것이 아닙니다. 주요 에너지는 무엇을 만들지 명확히 말하고, 결과를 본 뒤 “어디가 맞지 않는지” 판단하고, 다시 새 수정사항을 제시하는 데 쓰입니다. AI는 이러한 상위 수준의 생각을 구체적인 구현으로 옮겨, 기계적이고 반복적인 코딩 작업을 크게 줄입니다.
+
+vibe coding에 대한 더 자세한 내용은 여기에서 볼 수 있습니다: [https://www.ibm.com/think/topics/vibe-coding](https://www.ibm.com/think/topics/vibe-coding)
+
+Karpathy의 공유 내용을 더 보려면 여기에서 확인할 수 있습니다: [https://karpathy.bearblog.dev/blog/](https://karpathy.bearblog.dev/blog/)
+
+### Vibe Coding 고수인 척하는 법
+
+실제로 진짜 vibe coding 과정에서는 복잡한 프롬프트를 많이 쓰지 않는 경우가 많습니다. 시작할 때 전체 프로그램을 위해 구체적이고 적당히 복잡한 프롬프트를 제공할 필요는 있을 수 있습니다. 하지만 그 이후의 각 단계에서는 아마 아래와 같은 유형의 프롬프트만 필요할 것입니다.
+
+```
+"코드에 bug가 있어. 고쳐줘."
+"부분 코드 말고, 수정된 전체 코드를 줘."
+"네 코드가 아직 문제가 있어."
+"다시 수정하고 수정된 전체 코드를 줘."
+"방금 전에는 실행됐는데 왜 지금은 안 돼?"
+"내 뜻을 이해하지 못했어? 원래 코드를 바꾸지 마."
+"디버그 기능을 추가하지 마."
+"내가 시키지 않은 일을 하지 마."
+"내가 구현하라고 한 기능은 어디 있어?"
+"내 말 못 알아들어?"
+"나는 함수 하나만 원해."
+"내가 이전 코드 참고하라고 말했잖아."
+"불필요한 주석을 추가하지 마."
+"내 원본 코드의 기본 로직을 수정하지 마."
+"코드를 수정해 줘."
+"내 코드를 바탕으로 수정해..."
+"내 변수명 바꾸지 마!!!"
+"원래 함수명 바꾸지 마!"
+"내 변수 함부로 건드리지 마."
+"추가 기능 넣지 마."
+"프레임워크만 생성하지 말고 완전한 코드를 생성해."
+```
+
+조금 과장처럼 들릴 수 있지만, 실제로 이것들은 우리가 일상 업무에서 사용할 수 있는 프롬프트입니다. 대형 언어 모델의 **컨텍스트 길이 제한** 때문에, 또는 때로는 **지시 따르기 능력**이 그렇게 강하지 않기 때문에, 모델은 대화 앞부분에서 논의한 내용을 잊어버릴 수 있습니다. vibe coding에서는 긴 컨텍스트 모델을 선호하고, 지시 따르기 능력이 강한 모델을 사용하려 합니다. 두 능력의 순위나 지표를 통해 좋은 모델인지 판단할 수 있습니다.
+
+또는 학습 데이터셋의 스타일 때문에 대형 모델은 그 학습 데이터의 스타일로 답하려는 경향이 있습니다. 예를 들어 어떤 사람은 말투가 매우 진지하고, 어떤 사람은 수식을 많이 붙이며, 어떤 대형 모델은 코드에 많은 주석이나 불필요한 모듈을 추가하는 것을 좋아합니다.
+
+## [부록 3: 모델 컨텍스트](#appendix-nav)
+
+모델 컨텍스트는 AI의 단기 기억으로 이해할 수 있습니다. 현재 한 번의 대화 또는 한 번의 작업에서 모델이 “볼 수 있고” “기억할 수 있는” 모든 텍스트 내용을 뜻합니다. 여기에는 당신이 앞서 입력한 질문, 시스템이 제공한 설명, 관련 자료 등이 포함됩니다.
+
+바로 이 컨텍스트가 있기 때문에 AI는 당신이 앞의 내용을 이어서 질문하고 있다는 것을 이해할 수 있고, 여러 차례 이어지는 자연스러운 대화를 할 수 있습니다. 컨텍스트가 없다면 당신의 모든 문장은 모델에게 완전히 새로운 질문처럼 보입니다. 이전에 무엇을 말했는지 알 수 없으므로 대화를 이어 갈 수도 없습니다.
+
+각 모델에는 자신만의 유효 컨텍스트 길이(context window)가 있습니다. 이 길이는 보통 token(대략 “글자와 단어 조각”의 단위로 이해할 수 있음)으로 측정합니다. 현재 주요 모델은 대부분 32k-128k token 사이입니다. 컨텍스트가 길수록 모델이 한 번에 “읽을” 수 있는 내용이 많아집니다. 예를 들어:
+
+- 긴 논문이나 보고서를 한 번에 읽기
+- 같은 대화에서 여러 자료와 여러 사례를 인용하기
+- 앞선 몇 차례의 복잡한 논의 결론을 모델이 기억하게 하기
+
+입력 내용이 모델의 컨텍스트 제한에 가까워지거나 초과하면, 종종 몇 가지 흔한 현상이 나타납니다.
+
+- 모델이 앞쪽 긴 텍스트의 세부 사항이나 핵심 정보를 잊기 시작함
+- 대화가 뒤로 갈수록 화제가 처음 목표에서 점점 벗어남
+- 같은 자료에 대한 서로 다른 질의응답 사이에서 인용 내용이 일치하지 않음
+
+이 현상은 모델이 갑자기 “멍청해진” 것이 아니라, 컨텍스트 용량이 꽉 찼거나 거의 찼을 때 생기는 자연스러운 결과입니다.
+
+실제 사용에서는 컨텍스트가 가능한 한 길기를 바라지만, 동시에 다음도 인식해야 합니다.
+
+- 컨텍스트가 길수록 사용하는 연산 자원이 늘어납니다.
+- 대응되는 호출 비용도 함께 증가합니다.
+
+따라서 AI 애플리케이션을 설계할 때는 모델이 충분히 많이 보게 하는 것과 비용을 통제하고 효율을 높이는 것 사이에서 균형을 잡아야 합니다. 예를 들면 다음과 같습니다.
+
+- 오래 보존해야 할 정보는 요약한 뒤 모델에게 전달합니다.
+- 더 이상 필요하지 않은 세부 정보를 매번 원문 그대로 컨텍스트에 반복해서 넣지 않습니다.
+- 외부 지식 베이스 같은 방식을 사용해 “장기 기억”을 시스템에 맡기고, 모델 컨텍스트 안에 억지로 밀어 넣지 않습니다.
+
+## [부록 4: 지시 따르기 능력](#appendix-nav)
+
+지시 따르기 능력이란 모델이 당신의 지시를 이해한 뒤, 요구사항에 따라 정확하고 완전하게 실행할 수 있는지를 뜻합니다. 여기에는 질문에 답하는 것뿐 아니라, 지정한 형식, 스타일, 단계에 따라 작업을 완료하는 것도 포함됩니다.
+
+예를 들어 아래는 모두 모델에게 명확한 요구를 담은 지시입니다.
+
+- 이 글을 세 가지 요점으로 요약하세요.
+- 정중하고 예의 있는 어조로 답장 이메일을 작성하세요.
+- 이 단어를 영어로 번역하고 각각 예문을 하나씩 만드세요.
+- 글에서 작성자, 시간, 주요 사건을 추출하세요.
+
+지시 따르기 능력이 강한 모델은 보통 다음 특징을 가집니다.
+
+- 요구한 수량에 맞춰 내용을 출력합니다.
+ 예를 들어 세 가지 요점으로 요약하라고 하면 다섯 개를 주지 않습니다.
+- 지정된 요소를 모두 포함합니다.
+ 예를 들어 작성자, 시간, 사건을 추출하라고 하면 그중 어떤 것도 빠뜨리지 않습니다.
+- 지정한 형식과 어조를 지킵니다.
+ 예를 들어 공식적인 어조를 요구하면 지나치게 구어체인 답변을 출력하지 않습니다.
+- 불필요한 추가 확장을 하지 않습니다.
+ 예를 들어 번역과 예문만 요구했는데 관련 없는 긴 설명을 추가하지 않습니다.
+
+실제 응용에서 강한 지시 따르기 능력은 매우 중요합니다. 이유는 다음과 같습니다.
+
+- 안정성 향상: 같은 지시를 다른 시간에 여러 번 실행해도 출력 구조와 행동 패턴이 더 일관되고, 임의로 벗어나기 어렵습니다.
+- 재현성 향상: 어떤 프롬프트를 제품이나 프로세스에 설정했을 때, 모델이 대략 어떻게 응답할지 예측할 수 있어 테스트와 반복 개선이 쉬워집니다.
+- 시스템 통합 편의성: 모델 출력이 기대 형식에 맞으면 백엔드 프로그램, 워크플로, 기타 도구와 자동으로 연결하기 더 쉽습니다.
+
+따라서 대형 언어 모델을 선택하고 평가할 때는 그것이 똑똑한지, 지식 범위가 넓은지뿐만 아니라 지시 따르기 능력에도 특별히 주목해야 합니다. 산업용 애플리케이션에서는 안정적이고 정확하게 지시를 실행할 수 있는지가, 가끔 한 번 놀라운 답변을 하는 것보다 더 중요할 때가 많습니다.
+
+
diff --git a/docs/ko-kr/stage-1/appendix-a-product-thinking/index.md b/docs/ko-kr/stage-1/appendix-a-product-thinking/index.md
index bf8fffc..94185ba 100644
--- a/docs/ko-kr/stage-1/appendix-a-product-thinking/index.md
+++ b/docs/ko-kr/stage-1/appendix-a-product-thinking/index.md
@@ -1,145 +1,1099 @@
---
title: '제품 사고와 솔루션 설계'
-description: 'AI로 프로토타입을 만들기 전에 문제, 사용자, 솔루션을 정리하는 제품 사고 기초를 설명합니다.'
+description: 'AI 도구를 만들 줄 아는 단계에서 벗어나, 감각 있는 AI 애플리케이션을 생각하고 판단하고 다듬을 줄 아는 단계로 넘어가는 법을 배우며, 제품 사고의 핵심 관념과 실천 방법을 익힙니다.'
---
+
+
# 제품 사고와 솔루션 설계
-AI가 코드를 빠르게 만들어 줄수록 제품 사고는 더 중요해집니다. 구현이 쉬워졌다는 것은 잘못된 방향도 더 빨리 만들 수 있다는 뜻입니다.
+## 이 장의 안내
-이 부록은 "무엇을 만들지"를 더 정확히 정하기 위한 기본 틀입니다.
+
-## 1. 제품은 기능이 아니라 문제 해결이다
+앞선 장에서 당신은 이미 z.ai와 로컬 AI IDE에서 여러 작은 도구를 만드는 법을 배웠고, Trae로 환경 설정, 의존성 설치 같은 엔지니어링 문제를 처리해 보면서, 아이디어를 브라우저에서 로컬 프로젝트로 옮길 수 있는 능력을 갖추었습니다.
-초보자는 보통 기능에서 출발합니다.
+이제부터는 관심의 초점을 "만들 수 있는가"에서 "도대체 무엇을 만들어야 만들 가치가 있는가"로 옮깁니다.
-```text
-로그인, 게시판, AI 챗봇, 결제, 관리자 페이지가 있는 앱
-```
+이번 수업에서는 다음 내용을 체계적으로 다룹니다.
+- "아이디어"란 무엇이고, 무엇이 "좋은 아이디어"인가
+- 어떤 제품 방향이 투자할 가치가 있는지 어떻게 판단하는가
+- 반복 가능한 프로세스로 흐릿한 영감을 명확한 애플리케이션 방안으로 어떻게 바꾸는가
-하지만 사용자는 기능 목록을 사지 않습니다. 사용자는 자신의 문제를 더 빠르고 편하게 해결하고 싶어 합니다.
+핵심 목표: 도구를 만들 줄 아는 단계에서, 실제로 누군가 사용하고 실질적 가치를 만들어 내는 AI 애플리케이션을 만들 수 있는 단계로 올라가는 것입니다.
-제품 사고는 다음 질문에서 시작합니다.
+
-- 누가 문제를 겪고 있는가?
-- 언제 그 문제가 발생하는가?
-- 지금은 어떻게 해결하고 있는가?
-- 기존 방식의 불편은 무엇인가?
-- 내 솔루션이 줄여 주는 시간, 비용, 스트레스는 무엇인가?
+
+
+
+
+
-## 2. 문제 문장 만들기
+## 당신은 다음 내용을 배우게 됩니다
-좋은 문제 문장은 구체적입니다.
+전체적으로 말하면, 당신은 애플리케이션을 만드는 기본 지식을 배우게 됩니다. 아이디어는 어디에서 오는가 -> 아이디어는 어떻게 앱이 되는가 -> 앱은 어떻게 쓸 수 있는 상태에서 쓰기 좋은 상태가 되는가 -> 앱은 AI를 어떻게 쓰는가 -> 완성 후 사용자는 어떻게 찾는가.
-```text
-[사용자]는 [상황]에서 [목표]를 달성하려 하지만,
-[현재 방식] 때문에 [불편]을 겪는다.
-```
+1. 내가 앱을 만들려면, 어디에서 온 아이디어가 믿을 만한가?
+2. 아이디어가 생겼다면, 어떻게 만들 수 있는 앱으로 쪼갤 수 있는가?
+3. 만든 뒤에는, 어떻게 판단하고 다듬어 "좋은 앱"으로 만들 수 있는가?
+4. 어느 단계에서, 어떤 방식으로 AI를 합리적으로 사용해 가치를 키울 수 있는가?
+5. 앱이 생겼다면, 어떻게 0에서 첫 번째 진짜 사용자를 찾을 수 있는가?
-예시:
+# 1. 내가 앱을 만들려면, 어디에서 온 아이디어가 믿을 만한가
-```text
-소규모 쇼핑몰 운영자는 새 상품을 등록할 때 매번 상세페이지 문구를 직접 써야 하지만,
-마케팅 문구 작성 경험이 부족해 업로드 시간이 길어지고 상품의 장점이 잘 드러나지 않는다.
-```
+많은 사람은 앱을 만든다고 하면 가장 먼저 이렇게 생각합니다. 먼저 충분히 기억에 남는 창의적인 아이디어를 떠올려야 한다. 그래서 매일 랭킹을 보고, 기사를 읽고, 여러 인기 제품을 연구하고, 다른 사람의 성공 사례를 바라보며, 언젠가 자신에게도 아주 남다른 아이디어가 찾아오기를 기대합니다.
-## 3. 솔루션 문장 만들기
+하지만 실제 상황은 다릅니다. 많은 사람은 사실 애초에 별다른 생각이 없고, 단지 아이디어가 없어서 불안해합니다. 또 어떤 사람은 시작부터 스스로에게 아주 높은 문턱을 세웁니다. 충분히 재미있지 않으면 시작하지 않고, 평범하면 곧 실패라고 생각합니다. 그러나 실제로 조금 앞으로 걸어가 보면, 오래 가고 안정적으로 가는 앱 대부분은 어느 깊은 밤에 머리를 쥐어짜서 나온 것이 아니라, 하나하나의 구체적인 생활 장면 속에서, 실제 문제를 둘러싸고 조금씩 자라난 것임을 알게 됩니다.
-솔루션은 문제 문장을 뒤집어서 만듭니다.
+그래서 이 장에서 해결하려는 것은 출발점의 문제입니다. **어떻게 해야 아이디어를 가질 수 있을까? 이 아이디어는 도대체 믿을 만한가? 앞으로 시간과 에너지를 투입해 진짜 앱으로 만들 가치가 있는가?**
-```text
-[사용자]가 [입력]을 넣으면,
-[시스템]이 [처리]해서
-[결과]를 제공한다.
-```
+## 1.1 아이디어란 무엇인가
-예시:
+가장 기초적이지만 자주 무시되는 질문에서 시작해 봅시다. 도대체 무엇을 아이디어라고 부를 수 있을까요.
-```text
-쇼핑몰 운영자가 상품명, 특징, 타깃 고객을 입력하면,
-AI가 여러 톤의 상품 상세 문구와 SNS 홍보 문구를 생성한다.
-```
+일상 대화에서 사람들이 말하는 아이디어는 대개 아주 주관적인 흥분감입니다. 길에서 어떤 영상을 보고 순간적으로 이 방향은 정말 멋지다고 느낀 뒤, 나도 비슷한 것을 만들 수 있겠다고 생각할 수 있습니다. 또는 모임에서 어떤 제품이 쓰기 불편하다고 함께 불평하다가, 이런 걸 자동으로 다 처리해 주는 무언가가 있으면 좋겠다고 무심코 말할 수도 있습니다. 이때 당신에게 희미한 생각이 생긴 것은 맞지만, 그것이 실제로 만들 수 있는 물건이 되기까지는 아직 거리가 꽤 멉니다.
-## 4. MVP 범위 정하기
+여기서는 먼저 조금 더 엄밀한 기준을 세워 보겠습니다. 어떤 생각이 적어도 아래 몇 가지를 만족할 때, 우리는 그것을 아이디어라고 부르겠습니다.
-첫 버전에서 중요한 것은 "작지만 완결된 흐름"입니다.
+첫째, **명확한 한 종류의 사용자를 향해야 합니다**. 모두를 위한 것이라고 막연히 말하는 것이 아니라, 주로 누가 쓰는지 분명히 말할 수 있어야 합니다. 대학생인지, 사회 초년생인지, 아이를 키우는 부모인지, 독립 개발자인지, 이커머스 판매자인지, 소상공인 대표인지 말입니다. 서로 다른 사람은 같은 일에서도 완전히 다른 지점에 신경을 씁니다. 사람군을 정하지 못했다면, 이후의 모든 판단은 허공에 뜨게 됩니다.
-MVP에 넣을 것:
+둘째, **구체적인 장면에 뿌리내려야 합니다**. 이 앱은 사용자가 언제 쓰는 것인가요. 아침 출근길 지하철 안에서 쓰는지, 업무 중간에 쓰는지, 잠들기 전에 쓰는지, 주말에 자료를 정리할 때 쓰는지 말입니다. 노트나 작업 관리처럼 추상적으로 보이는 도구도 자세히 관찰해 보면, 실제로 자주 사용되는 부분은 반드시 어떤 장면과 아주 강하게 묶여 있습니다.
-- 사용자가 입력하는 핵심 정보
-- 결과를 생성하거나 보여 주는 핵심 화면
-- 결과를 복사하거나 저장하는 최소 행동
-- 실패/빈 상태 처리
+셋째, **사용자가 분명한 작업을 완료하도록 도와야 합니다**. 작업이 꼭 거창할 필요는 없지만, 말로 설명할 수 있어야 합니다. 예를 들어 하루의 할 일을 정리하기, 긴 글을 몇 개의 핵심 요점으로 압축하기, 회의에 대해 구조가 분명한 회의록을 생성하기, 또는 한 도시에서 주말 나들이를 위한 실행 가능한 코스를 만들기 같은 것입니다. 작업을 구체적으로 말할수록, 뒤에서 기능을 설계하고 가치를 평가하기가 쉬워집니다.
-MVP에서 빼도 되는 것:
+넷째, **현 상태보다 더 나은 방법이나 도구를 제시해야 합니다**. 사용자는 원래 이 일을 어떻게 하고 있었나요. 머리로 기억했나요, 종이와 펜으로 적었나요, Excel을 썼나요, 스크린샷을 저장했나요, 아니면 여러 앱 사이를 오가며 처리했나요. 당신이 제공하는 것이 분명히 더 수월하고, 더 안정적이고, 더 즐거운 방식이라면, 그 아이디어는 비로소 가치가 생기기 시작합니다.
-- 로그인
-- 권한 관리
-- 결제
-- 복잡한 관리자 페이지
-- 모든 플랫폼 지원
-- 과한 디자인 옵션
+
-## 5. 기능 우선순위
+위와 같은 사고가 잘 정리되지 않아도 괜찮습니다. 지금은 인공지능의 시대입니다. 위 내용을 하나의 완성된 프롬프트로 정리하고, 당신의 생각, 목표 사용자, 사용 장면을 함께 적어 대형 모델에게 보완과 정제를 맡길 수 있습니다. 모델을 언제든 온라인으로 대기하는 제품 공동창업자처럼 여기고, 반복해서 대화하고, 되묻고, 수정하면 흐릿한 개념을 구체화할 수 있습니다.
-기능을 세 가지로 나눕니다.
+## 1.2 아이디어와 사용자 요구: 자기만족을 피하는 첫 번째 방어선
-| 구분 | 의미 |
-| --- | --- |
-| Must | 이 기능이 없으면 제품 가치가 성립하지 않음 |
-| Should | 있으면 사용성이 좋아지지만 첫 버전에서 없어도 됨 |
-| Later | 검증 후 추가해도 되는 기능 |
+많은 사람이 처음 앱을 만들 때 가장 쉽게 빠지는 함정은 자기만족입니다. 이른바 자기만족이란, 자신이 떠올린 창의적 아이디어에 너무 흥분한 나머지 이것이 세상을 뒤흔들 방향이라고 생각하지만, 막상 보통 사용자에게 설명하면 상대의 반응은 매우 차분하거나 심지어 어찌할 바를 모르는 상태가 되는 것입니다. 상대는 예의상 고개를 끄덕이며 꽤 괜찮아 보인다고 말할 뿐입니다. 그러나 제품을 출시한 뒤에는 다운로드도 하지 않고, 오래 사용하지도 않습니다.
-예시:
+이런 상황을 피하려면 아이디어와 사용자 요구를 분리해서 보아야 합니다.
-| 기능 | 우선순위 |
-| --- | --- |
-| 상품 정보 입력 | Must |
-| 문구 생성 | Must |
-| 결과 복사 | Must |
-| 히스토리 저장 | Should |
-| 팀 공유 | Later |
-| 결제 | Later |
+먼저 **사용자 요구**가 무엇인지 이야기해 봅시다. 비교적 간단한 문장으로 요약하면 이렇습니다. 어떤 구체적인 장면에서, **사용자가 어떤 목표를 달성하기 위해 낮추고 싶어 하는 여러 비용, 또는 늘리고 싶어 하는 여러 가치**입니다. 여기서 비용은 돈만 뜻하지 않습니다. 시간, 에너지, 인지 부담, 실수 위험, 심지어 사회적 압박까지 포함합니다. 예를 들어 막 입사한 사회 초년생은 첫 발표에서 덜 긴장하기 위해 템플릿 한 세트에 돈을 낼 수 있습니다. 아이를 키우는 부모는 매일 30분만이라도 자기 시간이 보장된다면 조금 더 비용을 지불할 수 있습니다.
-## 6. 좋은 요구사항의 형태
+이 점을 이해하고 나면, **단순히 멋져 보이는 것만으로는 요구가 성립하지 않는다**는 사실을 알게 됩니다. 많은 창의적 아이디어는 확실히 새롭고 신기합니다. 그러나 사용자가 어떤 구체적 목표를 이루는 데 더 수월하고, 더 안심되고, 더 자신감 있게 만들지 못한다면, 진짜로 지속 가능한 앱을 떠받치기 어렵습니다.
-AI에게 전달하기 좋은 요구사항은 다음처럼 씁니다.
+아이디어와 요구 사이에는 자주 무시되는 간극이 있습니다. **아이디어가 나타내는 것은 데이터가 뒷받침한 사실이 아니라 당신의 주관적 판단**입니다. 당신이 무엇을 재미있어 하는지, 무엇을 흥미롭게 느끼는지, 무엇이 앞서 보인다고 생각하는지입니다. 요구는 사용자가 실제로 무엇을 겪고 있으며, 어떤 일 때문에 고민하는지를 뜻합니다. 당신은 자동으로 시를 생성하는 기능이 아주 멋지다고 생각할 수 있습니다. 하지만 대부분의 사용자에게는 매일 반복 정리 작업에서 10분을 덜 쓰게 해 주는 도구가 더 매력적일 수 있습니다. 물론 당신이 스티브 잡스처럼 아주 뛰어난 디자인 미감과 설득력을 갖추어 사람들이 "자동 시 생성 기능"도 매우 멋지다고 느끼고 자발적으로 따르게 만들 수 있다면 예외입니다. 다만 이는 어느 정도 어렵습니다.
-```text
-목표:
-대상 사용자:
-핵심 사용 흐름:
-첫 화면:
-결과 화면:
-필수 기능:
-제외할 기능:
-디자인 톤:
-확인 기준:
-```
+어떤 생각을 판단할 때 간단한 구분 방법이 있습니다. 그것이 **진짜 요구에 가까운지, 가짜 요구에 가까운지**를 보는 것입니다. 진짜 요구의 뚜렷한 특징은, 지금 당신의 앱이 없어도 사용자가 이미 그 문제를 해결하려고 능동적으로 방법을 찾고 있다는 점입니다. 기존 방법이 서툴고 번거롭더라도, 사용자는 여전히 시간과 에너지, 심지어 돈을 들여 그 구멍을 메우려 합니다. 예를 들어 어떤 사람은 반복 노동을 조금 줄이기 위해 직접 방안을 쓰거나 스크립트를 작성합니다. 이런 장면에서 당신이 더 친절하고 더 보편적인 해결책을 제공할 수 있다면, 제품이 설 자리가 생길 가능성이 큽니다.
-이 형식으로 정리하면 AI IDE가 훨씬 안정적으로 결과를 만듭니다.
+가짜 요구의 전형적인 상황은 정반대입니다. 당신이 먼저 꺼내지 않으면 대부분의 사람은 그것이 문제라는 사실을 의식하지 못하고, 반드시 해결해야 한다고 느끼지도 않습니다. 당신이 묘사하는 사용 장면은 사용자의 일상생활보다 당신의 상상 속에 더 많이 존재합니다. 그들은 소개를 듣고 나서도 이것이 좋고 재미있다고 느낄 뿐, 돈을 내지 않고, 심지어 돌아서면 잊어버립니다. 이런 아이디어는 이야기를 쓰는 데는 괜찮을 수 있지만 제품을 만드는 데는 매우 위험합니다.
-## 7. 솔루션 검증 질문
+
-만들기 전에 다음 질문에 답해 보세요.
+그래서 **자기만족을 피하는 첫 번째 방어선은 사용자 요구를 이해하는 것**입니다. 시작할 때부터 당신은 겉보기에는 단순하지만 매우 중요한 질문에 답하도록 스스로를 몰아붙여야 합니다. 나 자신 말고, 누가 이 일 때문에 진지하게 골머리를 앓고 있는가. 포럼, 커뮤니티, 댓글 영역을 볼 수도 있고, 주변에서 사용자가 될 가능성이 있는 몇 사람에게 직접 물어볼 수도 있습니다. "나는 매번 이 일 때문에 발목이 잡힌다"거나 "지금 방식은 정말 너무 번거롭다"와 같은 실제 감정이 담긴 불평을 듣기 어렵다면, 그 아이디어는 실제 요구와 아직 거리가 있다는 뜻입니다.
-- 이 문제가 실제로 반복해서 발생하는가?
-- 사용자가 지금 돈이나 시간을 쓰고 있는가?
-- 내 솔루션이 기존 방식보다 명확히 쉬운가?
-- 첫 버전을 하루나 이틀 안에 만들 수 있는가?
-- 주변 사람에게 바로 보여 주고 반응을 받을 수 있는가?
+## 1.3 좋은 아이디어는 왜 좋은 아이디어인가
-## 과제
+모든 아이디어가 같은 운명을 갖는 것은 아닙니다. 어떤 아이디어는 며칠만 들여 거칠지만 흐름이 돌아가는 버전을 만들어도, 자연스럽게 소수의 진짜 사용자를 끌어들입니다. 그들은 남아 있고, 인내심 있게 의견을 줍니다. 반면 어떤 아이디어는 기능을 필사적으로 쌓고, 광고에 돈을 쓰고, 여러 플랫폼에서 많은 홍보를 하더라도, 결국 외부 힘으로 잠깐 데이터를 쌓을 뿐 얼마 지나지 않아 조용해집니다.
-내 아이디어를 아래 형식으로 정리하세요.
+그 뒤의 가장 본질적인 차이는 아이디어 자체가 어떤 핵심 문제 지점을 밟고 있는가입니다.
-```text
-문제 문장:
-솔루션 문장:
-대상 사용자:
-Must 기능 3개:
-첫 화면 구성:
-결과 화면 구성:
-첫 번째 사용자 검증 질문 5개:
-```
+**좋은 아이디어는 자연스럽게 성장을 맞이할 수 있습니다**. 매우 조악한 형태로 나타나더라도, 심지어 간단한 버튼 몇 개만 있더라도, 사용자가 당장 겪는 구체적인 작은 불편을 해결할 수만 있다면 일정 수준의 자연 성장을 얻을 수 있습니다. 예를 들어 음성을 빠르게 문자로 바꿔 주는 작은 도구는 처음에는 웹페이지 하나와 간단한 버튼 몇 개뿐일 수 있습니다. 하지만 인식 품질이 충분히 좋고 기능 전환이 아주 자연스럽다면, 많은 사람이 주변 친구에게 링크를 보내고 싶어 합니다. 그야말로 시간을 절약해 주기 때문입니다.
+**나쁜 아이디어는 대개 처음부터 외부 힘에 의존해야 할 운명입니다**. 겉모습이 아주 좋고 내부가 매우 고급스러워 보이더라도, 계속 밀어붙이고, 계속 외치고, 계속 설명해야 합니다. 그리고 사람을 끌어오는 행동이 조금만 느려지면 사용 데이터는 곧장 떨어집니다. 자원을 쏟고, 협업을 끌어오고, 이벤트를 열어도 언제나 물살을 거슬러 올라가는 느낌이 듭니다. 문제는 실행이 부족한 것이 아니라, 그 지점 자체가 충분히 실제적인 고통을 맞히지 못했다는 데 있습니다.
+
+물론 위 상황이 절대적인 것은 아닙니다. 예를 들어 초기 시장에서는 사용자가 가치를 뒤늦게 인식하는 지연성이 있을 수 있고, 경쟁 제품이 있는 경우에는 외관, 조작 난이도, 브랜드 특성 등을 고려해야 합니다. 하지만 이는 더 깊은 내용이므로 지금은 잠시 다루지 않습니다.
+
+따라서 어떤 아이디어에 계속 투자할지 논의할 때 진짜로 보아야 할 것은 창의성 자체가 얼마나 화려한지가 아닙니다. 그것이 문제에서 솔루션으로 이어지는 경로를 자연스럽게 자라나게 할 수 있는가입니다. 우리는 아이디어를 통해 자신이 얼마나 창의적인지 남에게 증명하려는 것이 아닙니다. 가치 있는 출발점을 찾고, 그 길을 따라 작은 도구를 진짜 쓰기 좋은 앱으로 천천히 다듬기 위해 아이디어를 다룹니다.
+
+선택은 노력보다 중요합니다.
+
+## 1.4 좋은 아이디어는 어디에서 오는가: 네 가지 출처와 구체적 예시
+
+많은 사람이 아이디어를 떠올린다고 하면, 책상 앞에 혼자 앉아 천장을 보며 언젠가 영감이 갑자기 떨어지기를 기다리는 장면을 떠올립니다. 하지만 현실의 좋은 아이디어는 대부분 그렇게 오지 않습니다. 그것들은 생활 속 작은 관찰, 커뮤니티에서 반복되는 질문, 인터넷에 쌓이는 불평, 그리고 이미 존재하는 제품 속에서 조금씩 걸러져 나옵니다.
+
+아래 네 가지 출처를 진지하게 실행한다면, 그 안에서 시작할 수 있는 방향을 쉽게 캐낼 수 있습니다.
+
+
+
+### 자신의 삶을 사랑하기
+
+아주 소박하지만 효과적인 원칙이 있습니다. **당신이 삶에 더 깊이 참여할수록 문제를 더 쉽게 발견하고, 무엇이 해결할 가치가 있는 문제인지 판단하는 능력도 더 커집니다**. 여기서 참여감이란, 화면 너머로 다른 사람이 사는 모습을 보는 것이 아니라, 직접 경험하고, 시도하고, 시행착오를 겪는 것입니다. 자신의 취미와 관심사를 진지하게 대할수록, 그것은 아이디어가 자라나는 비옥한 토양이 될 가능성이 커집니다.
+
+예를 들어 당신이 고양이를 아주 좋아한다면, 고양이와 함께 사는 당신의 하루는 "고양이 키우기 팁" 영상 100개를 보는 것보다 더 많은 정보를 줍니다. 고양이가 어디에서 물건을 가장 잘 넘어뜨리는지 알게 되고, 매일 어느 시간에 가장 뛰어다니는지, 어떤 상황에서 스트레스를 가장 잘 받는지 기억하게 됩니다. 모래를 치우고, 털을 정리하고, 발톱을 깎고, 병원에 가는 세부 사항도 직접 겪게 됩니다. **조금이라도 매끄럽지 않았던 모든 경험은 사실 잠재적인 제품 단서입니다**.
+
+고양이 사진을 찍는 일을 생각해 봅시다. 많은 사람이 이런 일을 겪습니다. 자신은 휴대폰을 들고 있는데 고양이는 도무지 렌즈를 보지 않습니다. 고개를 숙여 발을 핥거나 다른 구석만 바라봅니다. 그렇다면 휴대폰이나 태블릿 화면에 자동으로 움직이는 빨간 점, 깃털, 작은 벌레 애니메이션이 나타나 고양이의 시선을 끌어 주는 작은 도구를 만들 수는 없을까요? 촬영 버튼을 누르면 그것이 자동으로 전면 카메라 근처를 한 바퀴 돌며 고양이의 시선을 렌즈 방향으로 "속여" 오고, 동시에 연속 촬영을 해서 그중 선명하고 예쁜 한 장을 골라 줍니다. 한 걸음 더 생각하면, 이 앱은 고양이마다 어떤 색, 어떤 이동 경로에 가장 흥미를 보이는지도 기록하고, 다음에는 그 고양이만의 전용 낚시 모드를 자동으로 사용해 성공률을 높일 수 있습니다.
+
+
+
+당신이 화장이나 스킨케어 과정을 즐긴다면, 집 화장대 위의 모든 제품 뒤에는 많은 시행착오와 의사결정이 숨어 있습니다. 매번 메이크업 사진을 휴대폰 앨범에 찍어 두는 데 이미 익숙할 수 있습니다. 하지만 나중에 돌아볼 때마다 그날 어떤 립스틱과 어떤 아이섀도 팔레트를 썼는지 하나하나 떠올려야 합니다. 그렇다면 이런 정보를 체계적으로 기록해서 나만의 메이크업 도감을 만들 수 있지 않을까요? 더 나아가 앱이 어떤 메이크업을 어떤 상황에서 가장 많이 사용했는지, 어떤 조합이 사진에서 가장 잘 나왔는지 통계로 보여 줄 수도 있습니다. 그러면 매번 화장을 고를 때 처음부터 다시 생각하지 않아도 됩니다.
+
+더 구체적으로 말하면, 많은 사람에게는 이런 장면이 있습니다. 아침에 시간이 급한데 앨범을 열어 "지난번에 성공했던 출근 메이크업"을 찾고 싶습니다. 그런데 한참을 넘겨도 그때 정확히 어떤 제품을 썼는지 기억나지 않습니다. 그렇다면 사진을 찍은 뒤 휴대폰에 대고 "오늘은 면접 메이크업, 01호 오렌지 브라운 아이섀도 팔레트와 말린 장미색 립스틱을 썼어"라고 말하기만 하면, 앱이 자동으로 인식해 사진과 연결된 "메이크업 레시피"를 생성해 주는 작은 기능을 만들 수 있지 않을까요? 다음에는 "면접", "오렌지 브라운 아이섀도", "말린 장미색"만 검색하면 관련 메이크업을 한 번에 볼 수 있고, 심지어 "오늘은 출근에 어울리고 5분 안에 끝낼 수 있는 것만 보기" 같은 추천 목록도 자동으로 생성할 수 있습니다. 매일 아침 절약되는 그 몇 분이 사실은 아주 구체적인 "해결된 문제"입니다.
+
+당신이 시티 워크나 여러 형태의 느린 여행을 좋아한다면, 이미 여러 도구를 조합해 자신의 경험을 만들고 있을 수 있습니다. 지도 앱으로 경로를 기록하고, 메모 앱에 가고 싶은 카페를 적고, 앨범에는 길에서 찍은 사진과 감상이 흩어져 있습니다. 그렇다면 경로, 방문 지점, 사진, 글을 시간선과 이야기가 있는 걷기 기록으로 함께 엮어 주는 앱이 있을 수 있지 않을까요? 더 나아가 당신의 경로를 친구에게 한 번에 공유해, 같은 도시에서 그들도 다른 버전을 걸어 볼 수 있게 할 수도 있습니다.
+
+더 일상적인 작은 세부 사항을 파고들 수도 있습니다. 많은 사람은 시티 워크를 할 때 "지금 이 모퉁이가 정말 예쁘다고 느꼈는데, 집에 돌아가면 지도에서 그 지점을 전혀 찾을 수 없다"는 좌절감을 겪습니다. 그렇다면 아주 가벼운 기능을 만들 수 있지 않을까요? 느낌 있는 길모퉁이에 도착했을 때 이어폰 버튼을 길게 누르고 "표시해 줘, 여기는 데이트 산책에 아주 어울리는 길이야"라고 한마디만 하면, 앱이 현재 위치에 음성 메모가 붙은 마커를 즉시 찍고, 시간, 날씨, 소음 수준을 자동으로 기록합니다. 이후 당신이나 친구가 이 도시의 지도를 열면 "길에서 직접 검증된 분위기 지점"을 볼 수 있습니다. 어디가 혼자 멍때리기 좋은지, 어디가 야경 보기 좋은지, 어디가 친구와 걸으며 이야기하기 좋은지 알 수 있습니다. 원래라면 "지나가면 잊히는" 작은 길모퉁이들이 이렇게 조금씩 질감 있는 도시 경험 데이터베이스로 자랍니다.
+
+이 예시들이 설명하려는 것은 사실 하나뿐입니다. **당신은 자신의 삶을 사랑해야 하며, 삶은 최고의 아이디어 출처입니다**. 매일 만나는 곤란함, 임시로 떠올린 우회 방법, 조금 귀찮지만 계속 참고 있던 지점들은, 당신이 조금 더 들여다보고 작은 도구로 바꿀 수 없을지 한 번 더 묻기만 한다면 모두 미래 제품의 초기 형태가 될 수 있습니다.
+
+### 당신이 가진 사람 자산에서 캐내기
+
+사람 자산이란 쉽게 말해 당신이 이미 도달할 수 있는 사람들의 집단입니다. 당신의 독자일 수도 있고, 운영하는 커뮤니티일 수도 있고, 당신이 속한 회사의 내부 동료 그룹일 수도 있으며, 오랫동안 참여해 온 어떤 취미 커뮤니티일 수도 있습니다. 어떤 경로든 **일정한 사람들의 일상 대화, 불만, 기대를 안정적으로 들을 수 있다면**, 당신은 완전히 0에서 시작하는 사람보다 훨씬 큰 이점을 갖고 있습니다.
+
+흔한 예를 들어 봅시다. 당신이 디자이너 커뮤니티 운영자라면, 매일 그룹 안에서 보는 내용은 사실 매우 귀중한 요구 풀입니다. 누군가는 클라이언트가 계속 수정 요청을 반복한다고 불평하고, 누군가는 특정 소재 사이트의 과금 방식이 불만이라고 말하고, 누군가는 서로 다른 사이즈 규격 사이를 오가며 조정하는 데 시간이 너무 낭비된다고 느낍니다. 모든 불평 뒤에는 잠재적인 제품 단서가 숨어 있습니다. 예를 들어 한 세트의 디자인을 여러 주요 플랫폼의 사이즈 비율로 한 번에 생성해 주는 간단한 사이즈 맞춤 도구를 만들 수 있습니다. 또는 자주 쓰는 컴포넌트를 저장하고 재사용할 수 있는 작은 도구를 만들어, 디자이너가 반복 노동을 더 적은 시간으로 끝내도록 도울 수 있습니다.
+
+당신이 속한 곳이 시험 준비 커뮤니티라면, 그룹 안에는 장기적으로 비슷한 화제가 가득할 수 있습니다. 오늘 컨디션이 안 좋다, 계획이 또 밀렸다, 어떤 자료를 봐야 더 효율적인가, 어떻게 해야 출석 체크를 계속할 수 있는가 같은 이야기입니다. 당신은 허공에서 상상할 필요가 없습니다. 일정 기간 관찰하고, 사람들이 반복해서 말하는 몇 가지 공통 난제를 정리하기만 하면, 학습 앱의 초기 기능 방향을 대략 그릴 수 있습니다. 예를 들어 더 합리적인 목표 분해, 더 인간적인 체크인 피드백, 더 실제적인 진도 시각화 같은 것입니다.
+
+이런 장면에서 처음부터 모두를 대상으로 하는 크고 완전한 제품을 만들려 할 필요는 없습니다. 당신이 인정해야 할 것은 하나입니다. 지금 손에 쥔 이 작은 사람 집단이 최고의 출발점입니다. 그들을 깊이 이해할수록, 그들의 실제 생활 속에서 말로 표현되는 고민과 말로 표현되지 않는 작은 불편을 더 잘 알수록, 진짜로 사용되는 물건을 만들 기회가 커집니다.
+
+### 공개된 공간에서 요구 캐내기
+
+아직 자신의 커뮤니티나 독자 집단이 전혀 없어도 걱정할 필요는 없습니다. 인터넷에서는 매일 수많은 사람이 여러 플랫폼에서 자신의 어려움과 불만을 큰 소리로 말하고 있습니다. 공개된 공간의 이런 목소리 자체가 거대한 보물창고입니다. 다만 대부분의 사람이 진지하게 들으려 하지 않았을 뿐입니다.
+
+당신은 관심 있는 업계와 관련된 플랫폼 몇 곳을 정하고, 감정이 담긴 키워드를 정기적으로 검색할 수 있습니다. 예를 들어 **너무 귀찮다, 추천 있나요, 어떻게 해결하지, 정말 번거롭다, 더 좋은 방법 없나요** 같은 표현입니다. 그리고 글과 댓글을 끈기 있게 읽으면서 두 종류의 정보에 특히 주목합니다.
+
+한 종류는 어떤 문제가 오랫동안 반복해서 언급되는 경우입니다. 예를 들어 구직 게시판에서는 일정 기간마다 이력서를 어떻게 써야 하는지, 자기소개를 어떻게 준비해야 하는지, 면접 결과를 어떻게 후속 확인해야 하는지 묻는 사람이 나타납니다. 육아 부모 집단에서는 이유식 조합, 생활 리듬 조정, 부모와 아이의 소통 같은 곤란함이 반복해서 등장합니다. 소상공인 교류 커뮤니티에서는 재고 관리, 현금 흐름, 직원 근무표를 언제나 걱정할 수 있습니다. 이런 장기적으로 존재하는 반복 문제는 한 업계가 반복해서 드러내는 시스템적 고통입니다.
+
+다른 한 종류는 어떤 장면에서 사용자가 매우 서툰 방식으로 억지로 버티고 있는 경우입니다. 예를 들어 어떤 사람은 모든 할 일을 종이에 쓰고 다시 사진을 찍어 클라우드에 올립니다. 어떤 사람은 한 형식의 내용을 다른 형식으로 바꾸기 위해 여러 앱 사이를 오가며 복사하고 붙여넣습니다. 어떤 사람은 서로 다른 채널의 데이터를 직접 하나의 표로 모읍니다. 이런 지점은 마음을 기울여 관찰하면 프로세스화하고 도구화할 수 있는 작은 절개면을 많이 발견하게 됩니다.
+
+공개된 공간에서 요구를 캐내는 것은 사실 한 가지 능력을 훈련하는 일입니다. 자신을 방관자에서 포착자로 바꾸는 능력입니다. 이런 키워드를 습관적으로 검색하고, 사례를 습관적으로 기록하면, 당신의 머릿속에는 현실 문제에 대한 민감도가 천천히 쌓입니다. 이 민감도는 이후 제품 설계 과정에서 여러 번 당신을 도와줄 것입니다.
+
+### 거인의 어깨 위에 서기
+
+또 자주 무시되는 아이디어 출처는 기존 제품과 프로젝트입니다. 이 세상에는 이미 너무 많은 뛰어난 사람이 우리 대신 여러 탐색의 길을 걸어 보았습니다. 매번 백지에서 시작할 필요는 없습니다. 다른 사람이 이미 절반쯤 해 놓은 곳에 서서 한 걸음 더 나아가면 됩니다.
+
+**해커톤 행사, 제품 혁신 대회, 창업 데모 데이** 같은 자리에는 대개 흥미로운 작은 작품이 많이 등장합니다. 그것들은 대부분 두 가지 특징이 있습니다. 시간이 부족하고, 자원이 제한되어 있습니다. 이는 지금 당신이 만들려는 작은 앱과 꽤 비슷합니다. 그래서 수상작을 볼 때는 두 가지 질문을 더 던져 볼 수 있습니다. 이 물건이 더 좁은 세분화 사용자만 서비스한다면 더 쉽게 구현될까. 기능을 절반, 심지어 3분의 2까지 잘라 내고 가장 핵심적인 한 고리만 남기면 오히려 더 명확해질까.
+
+마찬가지로 **제품 랭킹, 오픈소스 프로젝트, 도구 모음 사이트**에 나열된 도구들도 모두 사고의 출발점이 될 수 있습니다. 관심 있는 것을 몇 개 고른 뒤 하나씩 분해해 볼 수 있습니다. 누구의 어떤 일을 해결하는가, 지금 형태에는 어떤 뚜렷한 빈틈이 있는가, 다른 장면이나 다른 나라로 옮기면 어떤 차이가 생기는가. 당신은 표절하려는 것이 아니라, 이런 분해 연습을 통해 문제와 솔루션 사이의 관계를 이해하는 감각을 훈련하는 것입니다.
+
+오프라인 세계도 마찬가지입니다. 병원 접수 대기, 식당 대기, 행정기관에서 같은 정보를 여러 번 적는 일, 종이 양식에 같은 내용을 반복해서 쓰는 일을 겪을 때마다 의식적으로 멈춰서 스스로에게 물을 수 있습니다. 여기에 **시스템화, 디지털화, 자동화할 여지**가 있는가. 지저분하고 반복적이며 비효율적으로 보이는 장면들은 본질적으로 미래의 어떤 도구가 자라날 토양입니다.
+
+이 네 경로에서 장기적으로 소재를 캐내다 보면, 아이디어는 머릿속에 갑자기 나타나는 기적이 아니라, 당신이 생활, 타인, 정보 세계와 장기간 상호작용한 뒤 자연스럽게 자라나는 부산물임을 알게 됩니다.
+
+## 1.5 좋은 아이디어를 한 문장으로 요약하는 법: 적을수록 많아지는 기술
+
+아이디어가 대략 어디에서 오는지 알았다면, 다음으로 중요한 연습은 **그것을 한 문장으로 명확하게 말해 보는 것**입니다. 이 연습은 간단해 보이지만 실제로는 꽤 잔혹합니다. 왜냐하면 당신에게 한 가지 사실을 마주하게 하기 때문입니다. **당신의 아이디어는 정말로 명확한 핵심을 붙잡고 있는가.**
+
+사람이 다른 사람을 기억하는 이유는 상대가 모든 면을 갖추었기 때문이 아닌 경우가 많습니다. 오히려 어떤 뚜렷한 특징 때문인 경우가 많습니다. 항상 특정한 모자를 쓰거나, 말투가 매우 안정적이거나, 토론할 때마다 결정적인 한마디를 던지는 것일 수 있습니다. 제품도 마찬가지입니다. **상대가 열몇 가지 기능을 억지로 기억하게 하는 것보다, 소박하지만 분명한 인상을 갖게 하는 편이 낫습니다.**
+
+이 한 문장을 쓸 때 흔한 오해는 지나치게 넓게 쓰는 것입니다. 예를 들어 "이것은 사용자의 영어 실력을 높여 주는 앱입니다"라고 말할 수 있습니다. 얼핏 틀리지는 않습니다. 하지만 더 깊이 물어보면, 이 문장은 거의 아무것도 말하지 않습니다. 누구를 돕는가. 완전 초보 학생인가, 이미 직장에 다니는 사람인가. 어떤 방식으로 돕는가. 단어 암기인가, 듣기 훈련인가, 말하기 교정인가, 글쓰기 첨삭인가. 얼마나 시간을 들여야 하고, 얼마나 큰 변화가 생기는가. 모든 핵심 정보가 희석되어 버렸습니다.
+
+조금 더 나은 표현은 훨씬 구체적입니다. 예를 들어 "매일 출퇴근 시간 10분을 활용해 한 달에 핵심 단어 100개를 외우게 하는 단어 암기 앱"이라고 할 수 있습니다. 여기에는 적어도 세 가지가 설명되어 있습니다. 사용 비용이 통제 가능합니다. 매일 10분이면 됩니다. 기대 결과가 보입니다. 한 달에 새 단어 100개입니다. 장면이 명확합니다. 주로 출퇴근이지 다른 자투리 시간이 아닙니다. 사용자는 이런 설명을 들으면 자신에게 쓸모가 있는지 머릿속에서 빠르게 판단할 수 있습니다.
+
+이 한 문장을 쓰는 과정은 사실 세 질문에 답하도록 자신을 반복해서 몰아붙이는 과정입니다. **당신은 도대체 누구를 돕는가, 그들이 어떤 장면에서 당신을 떠올리기를 바라는가, 당신은 어느 정도 시간 안에 어떤 결과를 달성하도록 돕고 싶은가.** 화려한 수사를 조금 희생하더라도 이 정보들을 하나로 붙일 수 있을 때, 당신의 아이디어는 비로소 이해되고 전파될 수 있는 것이 됩니다.
+
+이 훈련을 거꾸로 자신에게 적용할 수도 있습니다. 앞으로 3년에 대해 한 문장 설명을 써 보세요. 예를 들어, 3년 뒤에는 내가 주로 어떤 사람을 위해 어떤 문제를 해결하고 있으며, 어떤 눈에 보이는 성과를 냈는지 한두 문장으로 설명할 수 있기를 바란다고 쓸 수 있습니다. 이런 훈련은 선택을 할 때 더 분명해지게 합니다. 어떤 일은 반드시 붙잡아야 하고, 어떤 일은 적절히 내려놓아도 되는지 알게 합니다. 버리는 법을 배우는 것은 더하는 법을 배우는 것보다 어렵지만 올바른 일입니다.
+
+이런 표현을 어디에서 배워야 할지 모르겠다면 간단합니다. 매일 사용자의 주의를 얻기 위해 문구를 다듬는 콘텐츠를 보세요. **앱 마켓의 한 문장 소개, 게임과 도구 제품이 공식 홈페이지 첫 화면에 내거는 메인 제목, 여러 랜딩 페이지의 핵심 문구**를 참고할 수 있습니다. 그것들을 베껴 적고, 구조로 분해하고, AI를 바탕으로 자신의 아이디어에 맞는 새로운 문안을 써 보면 됩니다.
+
+## 1.6 AI로 사고를 확장하고 차별점 찾기
+
+예전에는 아이디어를 생각할 때 대부분 사람이 직접 천천히 궁리하는 수밖에 없었습니다. 이제는 AI가 있으므로 언제든 부를 수 있는 브레인스토밍 파트너가 하나 더 생긴 셈입니다. 잘 사용하면 사고의 공간을 크게 넓힐 수 있습니다.
+
+어떤 방향에서 막혀 머릿속 생각이 몇 가지 사이에서만 맴돈다고 느낄 때는, 지금 가진 아이디어를 가능한 한 명확하게 AI에게 설명하고 몇 가지 일을 부탁해 보세요. 예를 들어 **같은 핵심 작업을 바탕으로 서로 다른 사용자 집단 20가지를 나열해 달라**고 하거나, 학생, 프리랜서, 아이를 키우는 부모, 소상공인 같은 여러 관점에서 이 아이디어의 가능한 사용 방식을 다시 설명해 달라고 할 수 있습니다. 또는 제품 매니저, 운영, 마케팅, 기술 역할에 서서 각각 무엇을 신경 쓰는지 제안해 달라고 할 수도 있습니다.
+
+그러면 원래는 능동적으로 떠올리지 않았을 사용 장면이 이 단계에서 많이 던져지는 것을 보게 됩니다. 당신의 임무는 그 제안을 단순히 받아들이는 것이 아니라, 확장된 공간 안에서 **당신이 가장 잘 이해하고 자원 우위가 있는 작은 조각을 골라내는 것**입니다. 예를 들어 AI가 많은 업계를 나열했지만, 당신은 교육과 콘텐츠 창작 장면에 특히 감이 있다고 발견할 수 있습니다. 그러면 이 두 방향을 우선해서 더 아래로 분해할 수 있습니다.
+
+이 과정에는 또 중요한 원칙이 있습니다. **흔한 아이디어가 반드시 무효한 아이디어인 것은 아닙니다**. 많은 초보자는 겉보기에 흔한 방향을 모두 피해야 한다고 생각합니다. 누군가 이미 한 것은 기회가 없다고 느끼기 때문입니다. 하지만 실제 세계는 그렇게 단순하지 않습니다. 단어 암기, 할 일 목록, 가계부, 습관 체크인처럼 흔해 보이는 방향이 계속 만들어지는 이유는 그 뒤의 문제가 실제로 널리 존재하기 때문입니다. 이런 경우 경쟁의 핵심은 완전히 새로운 거대 창의성이 있는지가 아니라, **누가 어떤 작은 사람 집단을 더 잘 이해하고, 누가 세부를 그들의 생활에 더 가깝게 만들 수 있는가**입니다.
+
+초보자가 가장 쉽게 떠올리는 아이디어를 먼저 한 묶음 나열할 수 있습니다. 단어 암기 도구, 매일 체크인 앱, 독서 노트 도우미, 이력서 생성기, 습관 형성 도구 같은 것들입니다. 그런 다음 각각에 대해 AI와 한 차례 분해를 해 보고, 세 질문에 집중하세요. 내가 디자이너, 변호사, 초보 엄마, 대학원생처럼 아주 구체적인 사람 집단만 서비스한다면 이 아이디어는 어떻게 달라질까. 출퇴근길, 점심시간 10분, 잠들기 전 30분처럼 고정된 장면만 겨냥한다면 기능과 표현을 더 집중시킬 수 있을까. **결과 표현을 극단적으로 잘 만든다면, 예를 들어 더 공유하기 쉽고, 더 인쇄하기 쉽고, 다른 시스템으로 더 가져가기 쉽다면, 그것만으로 차이가 될 수 있을까.**
+
+여기서 AI의 가치는 당신 대신 결정하는 데 있지 않습니다. 원래 아주 좁았던 길을 더 완전한 지도로 바꾸도록 돕는 데 있습니다. 어떤 영역은 이미 다른 사람이 깊이 파고들었고, 어떤 구석은 아직 비교적 비어 있는지 더 빨리 볼 수 있습니다. 그리고 결국 어느 길을 걸을지는 언제나 오래된 질문으로 돌아갑니다. 어떤 곳이 당신이 진심으로 신경 쓰고, 충분히 깊이 이해하고, 장기적으로 투자할 의지가 있는 곳인가.
+
+이 모든 것의 마지막에서, 다시 한 번 그 최저선을 강조해야 합니다. 아이디어와 창의성에 관한 어떤 논의든 최종적으로는 사용자 요구로 돌아가야 합니다. AI로 사고를 보조하고 변형을 더 빨리 생성할 수는 있습니다. 하지만 브레인스토밍을 몇 차례 했든, 최종 판단 기준은 변하지 않습니다. 이 생각이 어떤 사람 집단의 실제 고통에 정말 응답하는가. 그들이 이미 반복해서 해결하려 하는 문제에서 한 걸음 앞으로 나아가게 하는가.
+
+## 소결
+
+당신은 몇 가지 간단한 차원으로 아이디어가 충분히 명확한지 검토하는 법을 배워야 합니다. 내가 멋지다고 느끼는 것과 사용자가 정말 필요로 하는 것의 차이를 구분해야 합니다. 좋은 아이디어가 좋은 이유는 처음부터 어떤 고통 지점을 밟고 있기 때문임을 알아야 합니다. 자신의 생활, 사람 자산, 공개 정보, 기존 제품에서 지속적으로 단서를 캐내는 법을 배워야 합니다. 아이디어를 한 문장으로 말하는 연습도 해야 합니다. 또한 AI를 판단을 대신하는 도구가 아니라 사고를 확장하는 파트너로 삼는 법을 배워야 합니다.
+
+손안에 이런 아이디어가 1개에서 3개 정도 있고, 각각이 **누구를 위한 것인지, 어떤 장면에서 쓰이는지, 대략 어떤 결과를 가져올지 한 문장으로 설명할 수 있다면**, 이제 새 아이디어를 더 떠올리려는 충동을 멈추고 다음 단계로 주의를 옮길 수 있습니다. 그중 하나를 어떻게 실제로 만들 수 있고, 실제 사용자가 쓸 수 있는 앱으로 분해할 것인가입니다.
+
+이 아이디어가 조금 별로라면 어떻게 할까요? 괜찮습니다. 처음에 별로인 것이 오히려 정상입니다. **완성은 언제나 완벽보다 중요합니다**. 먼저 시작해야 결말도 생깁니다.
+
+## 📚 Assignments
+
+위 내용을 바탕으로 다음 과제를 완료하세요.
+
+1. 자신의 관심사와 결합해 AI를 사용하여 몇 가지 앱 "아이디어"를 생성합니다.
+2. AI가 자신의 생각을 바탕으로 이것이 진짜 요구인지 가짜 요구인지 평가하고, 사용자 요구 통찰과 제안을 제시하게 합니다.
+3. 네 가지 출처 중 하나 또는 두 개를 골라 "아이디어"를 얻거나, AI가 몇 가지 앱 "아이디어"를 생성하게 합니다.
+4. 위의 모든 아이디어 중 가장 마음에 드는 세 가지를 고르고, 정보량이 풍부한 한 문장으로 그 아이디어를 요약해 봅니다.
+
+# 2. 아이디어가 생겼다면, 어떻게 만들 수 있는 앱으로 쪼갤 수 있는가
+
+앞 장에서 해결한 것은 출발점의 문제였습니다. 도대체 어떤 아이디어가 진지하게 다룰 만한가.
+
+진짜 도전은 여기서부터 시작됩니다. 많은 사람이 바로 이 단계에서 넘어집니다. 머릿속에는 완성된 것처럼 보이는 청사진이 있지만, 막상 손을 대면 너무 복잡해서 어디서부터 시작해야 할지 모릅니다. 기능이 너무 많고, 페이지가 너무 많고, 기술도 무서워 보입니다. 그래서 계속 미루다가 결국 **자기 위안** 한마디가 됩니다.
+
+"**괜찮아, 이건 나중에 기회가 되면 만들면 되지...**"
+
+
+
+생각만 하지 마세요. 바로 지금입니다. 이 장에서 하려는 일은, 아이디어를 만들 수 있는 버전으로 분해하는 방법을 배우도록 돕는 것입니다. 무에서 유를 만드는 일은 천재성에 의존하지 않고, 반복해서 연습할 수 있는 구체적인 동작들에 의존한다는 것을 보게 됩니다. **발산, 수렴, 분해, 세분화, 참고, 질문**입니다. 이 순서대로 하면 팀이 없어도, 시간이 많지 않아도, 하나의 아이디어를 흐름이 돌아가는 앱 데모로 바꿀 수 있습니다.
+
+## 2.1 생각에서 솔루션으로: 더블 다이아몬드 모델로 발산에서 수렴까지
+
+페이지를 그리고 아이디어를 내는 법을 배우고 나면 곧 또 다른 흔한 문제를 만나게 됩니다. 생각이 점점 많아지는 문제입니다. 화이트보드에 가능한 장면과 기능을 여러 개 적고, 종이에는 서로 다른 페이지 버전이 가득합니다. 보기에 성취감은 있지만, 실제로 만들려고 하면 오히려 더 손대기 어렵습니다. 모든 것이 중요해 보이고, 모두 시도해 볼 가치가 있어 보이기 때문입니다.
+
+이때 매우 고전적이지만 이해하기 쉬운 사고 프레임워크가 필요합니다. 더블 다이아몬드 모델입니다. 이 모델의 뜻은 사실 소박합니다. 인생의 많은 단계에서 먼저 발산하고, 다시 수렴해야 한다는 것입니다. 처음부터 모든 일을 한 번에 끝내려 하면 안 됩니다.
+
+### 더블 다이아몬드 모델이란 무엇인가
+
+더블 다이아몬드 모델은 영국 디자인 카운슬이 제시한 혁신과 디자인 프로세스 프레임워크입니다. 전체 과정을 연속된 두 개의 마름모, 즉 "더블 다이아몬드"에 비유합니다. 첫 번째 다이아몬드는 "문제 발견"에서 "명확한 문제 정의"로 가는 과정으로, 먼저 넓게 발산하고 충분히 조사하며 사용자를 이해한 뒤, 진짜 해결해야 할 핵심 문제로 수렴하는 것을 강조합니다. 두 번째 다이아몬드는 "솔루션 발전"에서 "최종 솔루션 전달"로 가는 과정으로, 가능한 해결 생각을 과감히 발산하고 탐색하며 프로토타입을 반복한 뒤, 다시 수렴하고 선별하고 다듬어 가장 적합하고 구현 가능한 방안을 만드는 과정입니다. 더블 다이아몬드 모델은 문제와 솔루션 두 단계 모두에서 "발산-수렴"을 거쳐야 함을 강조합니다. 처음부터 솔루션으로 뛰어드는 것을 피함으로써 혁신의 품질과 성공률을 높이는 것입니다.
+
+
+
+
+
+### 첫 번째 다이아몬드: 문제 이해, 단일 지점에서 전체 모습으로 발산하고 수렴하기
+
+**더블 다이아몬드 모델에서 첫 번째 다이아몬드는 문제 자체에 관한 것입니다**. 당신은 먼저 흐릿한 인식에서 출발해 관련된 더 많은 상황과 가능성을 발산하고, 다시 한 번 수렴하여 진짜 해결할 가치가 있는 문제 지점을 찾습니다.
+
+당신의 앱에 대응하면 다음 몇 가지 일입니다.
+
+**발산 단계에서는 사용자의 가능한 사용 장면을 최대한 많이 나열합니다.** 사용자가 마주칠 수 있는 저항, 기대하는 결과도 함께 나열합니다. 서둘러 판단하지 않고, 머릿속의 관련 내용을 모두 펼쳐 놓습니다. 예를 들어 문서 처리 앱이라면, 사용자가 출퇴근 중에 쓰는지, 회의 전에 쓰는지, 보고서를 쓰기 전에 쓰는지, 회고를 할 때 쓰는지 나열할 수 있습니다. 그들이 두려워하는 것이 요약이 부정확한 것인지, 형식이 흐트러지는 것인지, 핵심을 놓치는 것인지 나열할 수 있습니다. 그들이 바라는 것이 글이 무엇을 말하는지 더 빨리 파악하는 것인지, 자신과 관련된 부분을 더 빨리 찾는 것인지도 적을 수 있습니다.
+
+**수렴 단계에서는 가장 흔하고 가장 아픈 상황 한두 가지를 고르도록 자신을 압박해야 합니다**. 예를 들어 많은 장면 중에서 가장 많이 언급되는 것이 긴 업무 문서를 받았을 때 이 문서가 도대체 무엇을 말하는지, 주요 결론이 무엇인지 먼저 알고 싶다는 점이라고 발견했다고 합시다. 그렇다면 첫 버전의 앱 목표를 모든 문서 처리 관련 문제를 동시에 해결하는 것이 아니라, 사용자가 5분 안에 긴 글의 핵심 의미를 이해하도록 돕는 것으로 정할 수 있습니다.
+
+첫 번째 다이아몬드가 끝날 때는 시작할 때보다 더 분명해야 합니다. **당신이 진짜 해결하려는 문제가 무엇인지, 그것이 주변의 다른 문제에 비해 왜 우선순위가 높은지** 말입니다.
+
+### 두 번째 다이아몬드: 솔루션 설계, 거친 생각에서 실행 가능한 방안으로
+
+**더블 다이아몬드의 두 번째 부분은 솔루션의 탄생에 관한 것입니다**. 해결해야 할 문제가 무엇인지 대략 알았으니, 다음에는 그 문제를 해결할 방법을 최대한 많이 생각하고, 그중 첫 번째 버전에 가장 적합한 것을 골라야 합니다.
+
+여기서 발산 단계는 계속 아이디어를 추가한다는 뜻입니다. 여러 기능, 더 세부적인 장면, 가능한 다양한 활용 방식을 브레인스토밍할 수 있습니다. 긴 글 요약을 예로 들면, 서로 다른 요약 세분화 정도, 다른 결과 표현 방식, 음성 읽기 지원 여부, 사용자가 핵심을 표시할 수 있는지, 여러 스타일의 요약 버전을 제공할지 등을 생각할 수 있습니다. 이 단계에서는 즉시 결정할 필요가 없습니다. 가능한 것을 최대한 나열할 뿐입니다.
+
+수렴 단계에서는 간단하지만 매우 실용적인 평가 도구를 꺼내야 합니다. 사용자 가치 × 실행 가능성 × 시간 비용입니다. 각 아이디어에 대해 이 세 차원에서 대략적인 점수를 줄 수 있습니다. 예를 들어 1점에서 5점까지 매기고, 종합 점수가 높고 시간 비용이 통제 가능한 생각을 우선적으로 MVP, 즉 최소 실행 가능 버전의 구성 요소로 선택합니다.
+
+예를 들어 음성 읽기 기능은 사용자 가치는 괜찮을 수 있지만, 기술과 프론트엔드를 통합하는 시간 비용이 높습니다. 반면 간단한 텍스트 요약과 요점 추출은 사용자 가치가 뚜렷하고, 실행 가능성도 높으며, 시간 비용도 더 낮습니다. 그렇다면 첫 버전에 반드시 넣을 기능으로 더 적합합니다.
+
+이 과정에서 끊임없이 자신에게 상기해야 할 것이 있습니다. **첫 번째 버전의 목표는 완벽한 앱을 만드는 것이 아니라, 실제로 존재하고 누군가 진짜 사용할 수 있는 버전을 만드는 것**입니다. 모든 것을 포괄할 필요는 없습니다. 하나의 구체적인 작업에서 충분히 그럴듯하게 작동하면 됩니다.
+
+두 번째 다이아몬드에 간단한 시간 경계를 줄 수도 있습니다. 예를 들어 한 달 안에 사용 가능한 버전을 내야 한다면, 발산한 모든 아이디어 중 한 달이나 몇 달을 넘어야 구현될 기능은 일단 나중에 다시 볼 목록에 잠시 넣어둘 수 있습니다. 이렇게 하면 하고 싶은 것이 너무 많아서 시작부터 붙잡히지 않습니다.
+
+더블 다이아몬드 모델로 생각을 정리하는 데 익숙해지면, 원래 엉켜 있던 많은 상황이 훨씬 산뜻해집니다. 어떤 단계에서는 가능한 한 많이 생각해야 하고, 어떤 단계에서는 과감히 일부 가능성을 잘라내야 하는지 알게 됩니다. 더 이상 한 번에 모든 문제를 해결하겠다고 기대하지 않고, 발산과 수렴 사이를 오가며 전환하는 법을 배우게 됩니다.
+
+## 2.2 실행 가능한 단계 얻기: 추상에서 구체로 내려오는 법
+
+아이디어를 발산하고 난 뒤, 생각을 얻는 것은 매우 쉽습니다. 하지만 실행 가능한 단계를 얻는 것은 매우 어렵습니다. 효율을 높이는 도구를 만들겠다, 창작자를 돕는 앱을 만들겠다고 말하는 것은 모두 거창하게 들립니다. 실제로 손을 움직이려 하면 추상은 거의 도움이 되지 않습니다. 매일 마주하는 것은 아주 구체적인 문제들입니다. **첫 번째 버전은 도대체 어느 작은 조각을 만들어야 하는가, 어떤 페이지가 필요한가**, 회원가입과 로그인을 지원해야 하는가, 결제를 붙여야 하는가.
+
+여기서 필요한 능력은 **분해하고 세분화하여 추상을 구체로 바꾸는 능력**입니다. 크고 넓은 목표를 바로 손댈 수 있는 최소 실행 항목까지 조금씩 쪼개고 세부화하는 것입니다. 이 능력은 제품을 만들 때뿐 아니라 생활에서도 매우 중요합니다.
+
+
+
+### 생활 예시에서 시작하기: 햄버거가 먹고 싶다는 말은 도대체 무엇을 뜻하는가
+
+앱 이야기는 잠시 내려놓고, 생활 속 아주 간단한 예시로 돌아가 봅시다. 햄버거가 먹고 싶다. 얼핏 이 문장은 전혀 복잡하지 않습니다. 하지만 진지하게 쪼개 보면 그 안에 많은 구체적인 분기가 숨어 있음을 알게 됩니다.
+
+먼저 **동기와 마음속 핵심 요구**입니다. 당신은 정말 햄버거가 먹고 싶은가요? 맛이 당기는 것뿐인가요, 한 끼를 빠르게 해결하고 싶은가요, 친구와 잠깐 만나고 싶은가요, 아니면 예쁜 사진을 봤기 때문인가요. 별 상관없어 보이지만 이는 이후 선택에 직접 영향을 줍니다. 친구와 만나기 위해서라면 환경과 경험에 대한 요구가 있을 가능성이 큽니다. 단지 시간이 부족하다면 맛보다 빠름이 더 중요할 수 있습니다.
+
+다음은 **행동의 범위**입니다. 어떤 종류의 햄버거를 먹고 싶은가요? 몇 시에 먹고 싶은가요? 햄버거 자체만 원하는가요, 아니면 음료, 감자튀김, 디저트가 있는 세트를 원하는가요. 조금 뒤에 일이 있어 너무 배부르게 먹고 싶지 않다면 선택이 달라질 수 있습니다. 더 나아가 내일 아침까지 함께 해결할지, 예를 들어 간단한 햄버거 하나를 더 사 갈지 스스로 물을 수도 있습니다.
+
+그다음은 **이 일을 어떻게 실현할 것인가**입니다. 햄버거는 반드시 매장에 가서 먹어야 하나요, 배달로 받아도 되나요, 아니면 집에서 직접 만들어 볼 의향이 있나요. 각각의 선택 뒤에는 완전히 다른 행동 경로가 있습니다. 매장에 간다는 선택은 위치를 찾고, 시간을 확인하고, 이동 경로를 잡는다는 뜻입니다. 배달을 선택하면 플랫폼을 보고, 가격과 시간을 비교해야 합니다. 직접 만든다면 재료와 도구를 준비하고 레시피를 찾아야 합니다.
+
+이 모든 것을 분명히 쪼개고 나면, 원래 흐릿했던 "햄버거가 먹고 싶다"는 문장은 구체적인 행동 단계의 묶음으로 변합니다. 예를 들어 배달 앱을 열고, 전에 먹어 봐서 괜찮았던 가게를 검색하고, 세트를 고르고, 음료를 빼고 햄버거와 감자튀김만 선택하고, 소스를 빼 달라는 요청사항을 적고, 마지막으로 주문합니다. 이 행동들은 모두 매우 작지만 즉시 실행할 수 있습니다. 또한 AI 프로그래밍으로도 절차화된 실행 가능한 plan을 만들어 조작할 수 있습니다.
+
+**분해하고 세분화하는 의미가 바로 여기에 있습니다. 크고 추상적으로 들리는 바람에서, 구체적으로 실행할 수 있는 목록으로 이동하도록 돕습니다.**
+
+### 앱 예시: 문서 처리 효율을 높이는 일은 어디에서 시작하는가
+
+좀 더 복잡하고 단계가 겹겹이 있는 예시를 보겠습니다. 당신에게 "문서 처리 효율을 높이는 앱을 만들고 싶다"는 꽤 그럴듯한 바람이 있다고 합시다. 방향은 맞지만 이 반 문장에 멈춰 있으면 거의 손댈 수 없습니다. 첫 단계에서 어떤 페이지를 그려야 할지 모르고, 첫 버전이 어느 정도까지 해야 하는지도 모르며, 다른 사람에게 자신의 생각을 어떻게 설명해야 할지도 모릅니다.
+
+이때 방금의 분해와 세분화 방식을 빌려 한 걸음씩 구체화할 수 있습니다. 시간 관계상 여기서는 두 단계 분해 방법만 시연합니다.
+
+#### 첫 번째 층의 분해와 세분화
+
+**먼저 "문서"가 무엇인지 정의해야 합니다**. 문서 자체는 매우 넓은 개념입니다. 표, Word 보고서, PDF 파일일 수도 있고, 코드 주석을 기록한 Markdown 텍스트, TXT 노트일 수도 있으며, 스캔해서 만든 이미지형 문서, 도표와 수식이 들어간 학술 논문일 수도 있습니다. 문서 유형에 따라 구현 차이가 있고, 이후 설계할 "처리" 기능은 문서의 구체적 유형과 맞아야 하므로 문서 정의를 세분화할 수밖에 없습니다. 이미지형 문서라면 먼저 OCR 문자 인식 기능을 넣어야 할 수 있습니다. 표 형식 문서라면 핵심 요구는 단순한 글 축약이 아니라 데이터 추출과 분석일 가능성이 더 큽니다.
+
+**다음으로 "처리"가 무엇인지도 정의해야 합니다. 무엇으로 처리되어야 처리한 것인가요?** 처리 방식은 또 무엇인가요? 어떤 사람이 말하는 처리는 50페이지 보고서를 5페이지짜리 읽기 쉬운 개요로 줄이는 것입니다. 어떤 사람이 말하는 처리는 뒤죽박죽인 Word, PDF, Markdown 형식을 하나의 표준 템플릿으로 통일하는 것입니다. 또 어떤 사람은 번역, 개작, 윤문에 관심이 있습니다. 겨우 읽을 만한 초안을 외부에 공개할 수 있는 정식 버전으로 바꾸는 일입니다. 이 단계에서는 스스로에게 직접 물을 수 있습니다. 내가 말하는 "처리"는 도대체 "더 빨리 읽는 것"인가, "더 잘 고치는 것"인가, 아니면 "다른 사람에게 더 편하게 전달하는 것"인가. 다른 답은 뒤에서 그릴 입구 페이지와 작업 페이지를 완전히 다르게 결정합니다.
+
+**"앱"도 마찬가지로 정의해야 합니다. 무엇을 앱이라고 부를 것인가요?** 자기 혼자 쓰는 작은 도구인가요, 아니면 앞으로 여러 사용자가 쓰기를 바라는 것인가요? 웹 프로그램인가요, 모바일 앱인가요, 아니면 기존 시스템 안에 박힌 작은 기능인가요? 컴퓨터에서 혼자 쓰려는 것이라면 조악한 웹페이지나 명령줄 스크립트로 만드는 비용이 훨씬 낮습니다. 팀 동료와 함께 쓰려면 계정 체계, 권한, 협업 입구를 고려해야 할 수 있습니다. 이것들은 기술 선택처럼 들리지만, 분해 단계에서 당신은 아주 소박한 한 문장에 답하면 됩니다. 나는 어떤 기기, 어떤 장면에서 이것을 사용할 계획인가.
+
+이제 **이 문장 자체, "문서 처리 효율을 높인다"로 돌아옵니다**. 몇 가지 핵심어를 더 분명히 쪼개야 합니다. 예를 들어 **"무엇으로 높이는가"**입니다. 반드시 AI를 써야 하나요? 아니면 꼭 그렇지는 않은가요? 어떤 효율 향상은 규칙, 템플릿, 단축키만으로도 충분히 해결할 수 있습니다. 예를 들어 고정 형식의 보고서 표지를 한 번에 생성하거나 표준 면책 문구를 한 번에 삽입하는 일입니다. 이런 요구는 모델이 전혀 필요 없을 수 있습니다. 반대로 대량의 비정형 긴 텍스트를 마주하고 이해, 요약, 개작을 해야 한다면 AI는 매우 자연스러운 고리가 될 수 있습니다.
+
+"효율"이라는 말도 따로 쪼개 볼 가치가 있습니다. **효율은 도대체 무엇을 뜻할까요? 단순히 속도인가요, 아니면 속도뿐 아니라 품질, 오류율, 이해 난이도까지 포함하나요?** 예를 들어 20페이지 문서를 30분에 읽던 것을 5분에 핵심만 훑게 만드는 것은 속도입니다. 사용자가 요약에서 잘못된 논리나 데이터 모순을 빠르게 발견하게 하는 것은 품질입니다. 원래 전문 용어에 익숙하지 않은 사람도 설명과 표시를 통해 보고서를 이해하도록 돕는 것은 인지 문턱을 낮추는 일입니다. 스스로에게 아주 직접적으로 물을 수 있습니다. 이 앱이 매우 성공했다면 사용자에게 가장 큰 변화는 무엇인가. "문서에 쓰는 시간이 절반으로 줄었다"인가, 아니면 "문서 관련 일을 할 때 마음이 덜 지쳤다"인가. 이 문장에 명확히 답하면 기능 우선순위의 근거가 생깁니다.
+
+
+
+#### 두 번째 층의 분해와 세분화
+
+위는 첫 번째 층의 분해입니다. 이 단계에서 우리가 얻을 수 있는 초기 분해와 세분화 결과가 "AI로 PDF 문서를 문자로 바꾸는 속도와 품질을 높이는 웹 프로그램을 만들고 싶다"라고 가정해 봅시다. 이 문장은 처음의 "문서 처리 효율을 높인다"보다 훨씬 구체적입니다. 문서 유형(PDF), 처리 방식(문자로 변환), 개선 방향(속도와 품질), 기술 경로(AI), 그리고 담는 형태(웹 프로그램)를 명확히 했습니다. 요구 표현의 관점에서 보면, 추상적인 바람에서 비교적 명확한 기능 구상으로 수축되었습니다.
+
+하지만 주의해야 할 점은 이런 설명도 여전히 "중간 목표"일 뿐, 진짜 실행 가능한 제품 방안이라고 부르기에는 부족하다는 것입니다. 이유는 **그 안의 많은 핵심 정보가 여전히 뭉뚱그려져 있기 때문입니다. 예를 들어 "어떤 AI를 쓸 것인가", "어느 정도까지 향상할 것인가", "어떤 사용 장면에 맞출 것인가", "어떤 사용자를 향할 것인가" 같은 것들입니다**. 따라서 우리는 계속 아래로 분해하여, 이 문장을 더 세밀한 설계 결정과 기술 방안의 묶음으로 바꿀 수 있고, 그렇게 해야 합니다.
+
+먼저 "AI"를 보겠습니다. 여기서 "AI"는 도대체 문자인식만 담당하는 가벼운 OCR 모델을 뜻하나요, 아니면 이후의 교정, 레이아웃 재정리, 내용 재배치, 구조 이해까지 하도록 대형 언어 모델이나 멀티모달 모델을 도입해야 하나요? 선택이 다르면 세 차원에서 완전히 다른 결과가 생깁니다.
+
+- 비용 소모: 연산 비용, 호출 비용, 추론 지연 등이 포함되며, 일회성 투자가 중심인지 지속 지출이 중심인지 달라집니다.
+- 개발 난이도: 기존 OCR 인터페이스를 단순 통합하면 되는지, 복잡한 프롬프트, 컨텍스트 관리, 심지어 자체 학습과 평가 체계를 설계해야 하는지 달라집니다.
+- 제품 형태와 출시 전략: "텍스트를 빠르게 추출하는 작은 도구"인지, 아니면 목차 구조, 표, 제목 계층을 복원할 수 있어 깊이 읽기와 내용 재사용에 적합한 "문서 지능 처리 플랫폼"인지 달라집니다.
+
+다음은 **"PDF 문서"의 추가 분해입니다. 당신은 도대체 어떤 종류의 PDF를 지원할 것인가요?** 범위를 "문자 위주이며 복사 가능한 순수 텍스트 PDF"로 한정한다면, 처음부터 스캔본, 복잡한 도표, 수식 조판을 처리할 필요가 없고, 극단적인 다단 구성이나 화려한 편집 문서까지 책임질 필요도 없습니다. 반대로 "어떤 PDF든 던지면 된다"를 원한다면, 시작부터 이미지형 PDF의 OCR 인식, 레이아웃 재구성, 이미지와 텍스트 혼합, 표 추출 같은 고난도 문제 묶음을 동시에 해결해야 한다는 뜻입니다. 프로젝트 복잡도는 몇 배로 커집니다.
+
+이 층에서는 의식적으로 한 번 "좁히기"를 하고, 그 선택을 명확히 적어 둘 수 있습니다. 예를 들어 현재 버전은 주로 "구조가 비교적 명확하고 문자 위주의 PDF 보고서와 설명 문서"를 서비스하며, 스캔본이나 무거운 이미지-텍스트 혼합 문서의 효과는 보장하지 않는다고 쓸 수 있습니다. 이렇게 하면 이후 "속도"와 "품질"에 관한 모든 목표에 비교적 통제 가능하고 설명 가능한 전제 조건이 생깁니다. 제품 설명과 사용자 기대 관리에서도 경계를 분명히 말하기 쉬워집니다.
+
+다음은 "고품질로 문자로 변환"입니다. 여기서 "품질"은 적어도 세 가지 논의 가능하고 절충 가능한 차원으로 나눌 수 있습니다.
+
+1. **인식이 대체로 정확한가**: 오탈자, 구두점, 특수기호의 인식 정확도는 어떤지, 전체 문단이 깨지는 일이 있는지.
+2. **문단과 제목 구조가 유지되는가**: 원문의 장절 계층, 문단 구분, 목록 구조, 인용 블록 등이 순수 텍스트로 변환된 뒤 가능한 한 복원되는지.
+3. **2차 편집과 재사용이 편한가**: 생성된 텍스트가 충분히 깔끔한지, 형식이 정돈되어 있는지, 사용자가 이후 Word, Notion, 코드 편집기로 복사할 때 대규모 수작업 정리가 필요한지.
+
+**자신이 가장 중요하게 보는 두세 가지를 먼저 골라 "품질"의 주공 방향으로 삼을 수 있습니다**. 예를 들어 "문단 구조가 명확함"과 "제목 계층이 기본적으로 유지됨"을 우선 보장하고, 오탈자는 "사용자가 몇 분 안에 빠르게 직접 고칠 수 있는 정도"까지만 요구할 수 있습니다. 이렇게 하면 "고품질"은 더 이상 공허한 형용사가 아니며, 작성하고 측정할 수 있는 제품 기준으로 바뀝니다. 가끔 인식 오류가 있는 것은 허용되지만, 문서를 조각조각 나누어 문단을 혼란스럽게 만들거나, 사용자가 구조를 정리하는 데 수동 복사보다 더 힘들게 만드는 것은 안 됩니다.
+
+다음은 "속도"입니다. 목표에 "속도와 품질을 높인다"고 썼다면, "빠르다"는 말은 **사용자가 체감할 수 있는 어떤 규모**로 구체화되어야 합니다. "느낌상 빠르다"에 머물러서는 안 됩니다. 여기에는 중요한 절충이 숨어 있습니다.
+
+- 초장문 문서(수십 페이지, 수백 페이지)를 지원하고, 사용자가 오래 기다려도 되기를 바라는가?
+- 아니면 중단편 문서만 대상으로 하되, 페이지 수를 제한하는 전제에서 "몇 초에서 십여 초 안에 결과를 받는" 경험을 만들 것인가?
+
+전형적인 사용 장면이 회의 전에 10여 페이지짜리 보고서, 방안, 연구 요약을 빠르게 편집 가능한 텍스트로 바꾸어 표시, 수정, 발췌하려는 것이라면, 더 자연스러운 선택은 다음과 같습니다.
+
+- 단일 문서에 합리적인 페이지 상한을 둡니다. 예를 들어 "20페이지 이하의 텍스트형 PDF"입니다.
+- 동시에 대략적인 처리 시간 지표를 제시합니다. 예를 들어 "보통 약 10초 안에 처리가 완료됩니다"입니다.
+
+이 두 가지가 명확히 적히면 뒤의 기술 방안(병렬 처리가 필요한지, 비동기 큐를 둘지), 인터페이스 문구(페이지에 표시할 예상 시간, 시간 초과 안내), 사용자 기대 관리는 모두 "중단편 문서 + 빠른 반환"이라는 핵심 경험을 중심으로 최적화할 수 있습니다.
+
+**마지막은 "웹 프로그램" 자체입니다. 이 항목은 겉보기에는 단지 담는 형태의 선택 같지만, 실제로는 마찬가지로 적당히 범위를 좁혀야 합니다.** 너무 이른 시점에 무거운 제품 형태로 말려들지 않기 위해서입니다. 먼저 중요한 질문 하나를 스스로에게 물어볼 수 있습니다.
+
+- 이것은 "나 자신과 작은 내부 범위에서 사용하는 임시 도구"에 더 가까운가?
+- 아니면 처음부터 "진짜 사용자들이 장기적으로 쓰는 온라인 서비스"로 계획하는가?
+
+전자에 더 가깝다면 많은 복잡도를 과감히 잘라낼 수 있습니다. 완전한 계정 체계와 권한 관리를 만들 필요가 없고, 첫 버전부터 작업 기록, 프로젝트 관리, 팀 협업 같은 기능을 구현할 필요도 없습니다. 대신 아주 단순한 흐름 하나에 집중합니다.
+**웹페이지 열기 -> PDF 업로드 -> 처리 대기 -> 편집 가능한 텍스트 표시 -> 한 번에 복사하거나 다운로드**.
+반대로 목표가 정식으로 외부에 안정적인 서비스를 제공하는 것이라면, 이후 버전에서 동시 처리 능력, 큐 스케줄링, 사용자 할당량, 예외 복구, 로그와 모니터링, 보안과 권한 관리를 점진적으로 고려해야 합니다. 하지만 지금 이 분해 단계에서는 먼저 "브라우저 기반의 작은 도구, 로그인 없이 사용 가능"으로 정의하고, 모든 상호작용을 가장 단순하고 핵심적인 한 경로에 집중해도 됩니다.
+
+"AI", "PDF 문서", "고품질 문자 변환", "속도 요구", "웹 프로그램"이라는 **키워드 뒤의 선택을 더 구체적인 문장으로 명확히 표현**하면, 처음의 "AI로 PDF 문서를 문자로 바꾸는 속도와 품질을 높이는 웹 프로그램을 만들고 싶다"는 문장을 더 명확하고 실행 가능한 설명으로 조일 수 있습니다. 예를 들면 다음과 같습니다.
+
+> 사용자에게 브라우저 기반의 작은 도구를 제공한다. 구조가 비교적 명확하고 문자 위주의 PDF 보고서를 우선 지원하며, 적합한 파싱 흐름과 가벼운 AI 정리를 통해 약 10초 안에 문단 구조가 명확하고 제목 계층이 기본적으로 유지되며 인식 오류율이 허용 가능한 편집 가능 텍스트를 출력한다. 로그인 없이 사용할 수 있다.
+
+이 시점이 되면 추상 목표에서 실제 구현 가능한 방안으로 넘어가는 중요한 도약을 이미 완료한 것입니다. 조금 더 줄이면 한 문장 설명을 얻을 수 있습니다.
+
+> 사용자에게 웹 도구를 제공해, 20페이지 이하의 텍스트형 PDF를 업로드하면 약 10초 안에 문단 구조가 명확하고 제목 계층이 유지된 편집 가능 텍스트를 얻고, 한 번에 복사하거나 `.txt`로 다운로드할 수 있게 한다.
+
+이런 설명은 더 이상 공허한 구호가 아니라, 곧바로 프롬프트가 되거나 AI가 plan으로 실행할 수 있는 지시 묶음이 됩니다. 예를 들어 이 문장을 개발 능력을 가진 AI에게 던져 개발 방안을 생성하게 하거나, 직접 최소 사용 가능 버전의 웹 앱을 만들게 할 수 있습니다. 디자이너에게 주어 구체적인 인터페이스 프로토타입을 그리게 할 수도 있고, 엔지니어 동료에게 보내 구현 비용과 기술 방안을 빠르게 평가하게 할 수도 있습니다.
+
+
+
+여기까지 하면 두 가지 현실적인 변화를 보게 됩니다. 첫째, 더 이상 "효율을 높이는 앱을 만들겠다"는 문장에 눌리지 않고, 즉시 손댈 수 있는 단계를 갖게 됩니다. 둘째, 다른 사람과의 소통 비용이 급격히 낮아집니다. 충분히 구체적으로 쪼갠 초기 방안을 내놓을 수 있기 때문입니다.
+
+추상에서 구체로 내려온다는 것은, 사실 "문서 처리 효율을 높이는 앱을 만들고 싶다" 같은 큰 바람을 누구나, 심지어 어떤 AI도 즉시 이해하고 실행을 시작할 수 있는 작업 목록으로 쪼개는 것입니다. 이 방식을 통하면 해결하기 어려운 문제는 없습니다. 모든 문제는 원자화되면 결국 두 가지 선택만 남습니다. 원자화할 수 있으면 실행할 수 있습니다.
+
+1. 내가 이 하위 문제를 해결하고 실행한다.
+2. AI 또는 다른 전문가가 이 하위 문제를 실행하고 해결한다.
+
+## 2.3 화이트보드에서 앱 구상하기: 먼저 첫 앱을 그려 보기
+
+많은 사람이 앱 만들기를 시작한다고 생각하면 머릿속에 가장 먼저 코드, 백엔드, 데이터베이스, 인터페이스, 프레임워크가 떠오릅니다. 이상한 일이 아닙니다. 우리는 오랫동안 앱을 만든다는 것은 무엇보다 기술 문제라는 관념을 주입받았기 때문입니다. 하지만 시작부터 모든 주의를 기술에 눌러 놓으면 가장 중요한 것을 쉽게 놓칩니다. **사용자가 당신의 앱에서 도대체 무엇을 하려는가**입니다.
+
+이 점에서 가장 단순하지만 자주 무시되는 방법이 있습니다. 먼저 그리는 것입니다. 전문 소프트웨어가 필요하지 않습니다. 화이트보드, 빈 종이, 메모장 모두 가능합니다. 중요한 것은 사용자가 들어와서 나갈 때까지의 전체 경로를 몇 장의 간단한 페이지 스케치로 먼저 그려 보는 것입니다. 편집기를 열어 코드를 쓰러 곧장 달려가면 안 됩니다.
+
+전체 앱을 먼저 세 종류의 페이지로 나눌 수 있습니다. 입구 페이지, 작업 페이지, 결과 페이지입니다.
+
+
+
+### 입구 페이지: 사용자는 어디에서 들어오고, 첫눈에 무엇을 보는가
+
+입구 페이지는 사용자와 당신의 앱이 처음 마주치는 곳입니다. 많은 사람은 입구를 설계할 때 범용 홈페이지 하나만 생각합니다. 그 위에 기능 버튼, 모듈 입구, 광고 위치를 가득 쌓아야만 물건이 충분히 많고 대단해 보인다고 여깁니다. 하지만 그 페이지를 종이에 그리고 벽에 붙인 뒤, 처음 온 사람이라고 가정해 보면 아주 현실적인 문제를 깨닫게 됩니다. **나는 도대체 어디를 먼저 눌러야 하는가.**
+
+입구 페이지를 그릴 때는 스스로를 가이드라고 생각해 볼 수 있습니다. 아주 구체적인 질문 몇 가지를 던지세요. 사용자는 어떤 방식으로 들어오는가. 공유 링크를 클릭해서 들어오는가, 앱 마켓에서 검색해서 들어오는가, 웹페이지에서 QR 코드를 스캔하는가. 출처가 다르면 사용자의 기대도 완전히 다릅니다. 예를 들어 친구가 보낸 링크로 들어온 사용자는 당신의 앱이 무엇을 할 수 있는지 대략 알고 있습니다. 이때 입구 페이지는 더 직접적으로 핵심 기능을 바로 써 보게 할 수 있습니다. 반면 앱 마켓에서 검색해 발견한 사용자는 당신에 대해 아무것도 모를 수 있습니다. 이때는 **입구 페이지가 한 문장으로 당신이 무엇을 하는지 먼저 이해시키거나, 보기만 해도 쓸 줄 알게 만들어야 합니다**.
+
+그릴 때는 간단히 처리할 수 있습니다. 종이에 휴대폰 화면 테두리를 그리고, 맨 위에 이 페이지의 제목을 씁니다. 가운데에는 주요 영역을 그립니다. 이 페이지에서 사용자에게 무엇을 알려 주고 싶은지, 여기서 어떤 선택을 하기를 바라는지 분명히 표시합니다. 예를 들어 큰 시작 버튼을 누르게 할 것인지, 짧은 예시 결과를 먼저 보게 할 것인지, 가장 간단한 기본 정보를 입력하게 할 것인지 말입니다.
+
+시작 페이지가 단순하고 구체적일수록, 막 도착한 사용자가 길을 잃지 않고 빠르게 익숙해질 기회가 커집니다.
+
+### 작업 페이지: 사용자는 무엇을 입력하고, 누르고, 선택해야 하는가
+
+사용자가 앞으로 나아가기로 했다면, 다음 단계는 작업 페이지입니다. 즉 전체 앱의 작업 공간입니다. 여기서 사용자는 실제로 당신과 상호작용합니다. 또한 가장 많은 사람이 과하게 복잡하게 설계하는 곳이기도 합니다.
+
+작업 페이지를 그릴 때 효과적인 연습이 하나 있습니다. **사용자가 한 가지 일만 할 수 있게 허용하는 것**입니다. 종이에 그 일을 가장 단순한 표현으로 씁니다. 예를 들어 텍스트 제출하기, 음성으로 생각 하나 기록하기, 템플릿 선택하기, 매개변수 하나 설정하기 같은 것입니다. 그런 다음 그 일만 중심으로 최대한 적게 만들어 봅니다. 필요한 입력과 버튼이 최소 몇 개인지 보는 것입니다.
+
+긴 글 자동 요약 앱을 예로 들면, 거칠지만 흐름이 돌아가는 작업 페이지는 몇 가지 요소만 있으면 됩니다. 텍스트를 붙여넣을 수 있는 입력 상자, 요약 길이를 고르는 옵션, 요약 생성 버튼입니다. 글자 크기, 색상, 아이콘 같은 시각적 세부는 먼저 생각하지 않아도 됩니다. 초점을 몇 가지 질문에 둡니다. **사용자가 이 페이지에 들어오자마자 무엇을 해야 하는지 아는가, 무엇을 준비해야 하는가, 중간에 다음 단계가 무엇인지 모르게 될 가능성은 없는가.**
+
+종이 위에서 작업 페이지를 구상하는 장점은 매우 낮은 비용으로 여러 버전을 시도할 수 있다는 것입니다. 모든 입력이 한 페이지에 있는 버전을 먼저 그리고, 다시 두 단계의 작은 마법사로 나눈 버전을 그린 뒤, 머릿속에서 몇 번 실행해 볼 수 있습니다. 어떤 버전이 덜 막히는가. 이미 작성된 코드에서 흐름을 고치는 것에 비하면, 종이에서 조정하는 비용은 거의 없습니다.
+
+### 결과 페이지: 사용자는 무엇을 얻었고, 어떻게 보여 줄 것인가
+
+많은 앱은 결과 단계에서 매우 대충 처리합니다. 개발자는 결과가 한 단락의 글, 한 장의 그림, 한 줄의 데이터일 뿐이니 보여 주면 된다고 생각하는 경우가 많습니다. 하지만 사용자에게는 반대인 경우가 많습니다. 사용자가 앞 단계에서 입력하고, 기다리고, 시도할 의향을 보인 근본 이유는 결과 페이지에서 충분히 명확하고 유용한 것을 보기를 기대하기 때문입니다.
+
+결과 페이지를 그릴 때는 이런 관점에서 생각할 수 있습니다. **사용자가 가장 신경 쓰는 핵심 정보는 무엇이며, 그것은 가장 눈에 띄는 위치에 놓여야 합니다**. 어떤 결과를 내보내고, 저장하고, 공유해야 하나요. 그 입구는 어디에 있나요. 결과에 간단한 설명을 붙여 사용자가 그것이 무엇을 의미하는지 알게 할 필요가 있나요.
+
+마찬가지로 긴 글 요약을 예로 들면, 비교적 친절한 결과 페이지 설계는 이렇습니다. 맨 위에는 몇 줄의 간결한 요점으로 핵심 결론을 나열하고, 그 아래에는 더 자세한 요약을 둡니다. 맨 아래에는 원문 링크를 남깁니다. 옆에는 눈에 띄는 버튼 두 개를 둡니다. 하나는 요점 복사, 하나는 문서로 내보내기입니다. 종이에 이런 영역의 배치를 그려 보고, 각 버튼이 담당할 동작을 표시할 수 있습니다.
+
+입구 페이지, 작업 페이지, 결과 페이지를 모두 그린 뒤에는 화살표로 연결해 **사용자가 처음 들어와 한 단계씩 끝까지 가는 과정**을 그립니다. 이 과정은 원래 의식하지 못했던 많은 문제를 드러냅니다. 예를 들어 사용자가 결과 페이지에서 세부 사항 하나를 수정하고 싶다면 어떻게 작업 페이지로 돌아갈 수 있는가. 또는 작업 페이지에서 사용자가 잠시 계속할지 확신이 없다면, 명확한 나가기나 임시 저장 방식이 있는가.
+
+이 절 전체의 핵심은 한 문장입니다. 먼저 사용자 조작 과정을 그리고, 그다음 기술 구현을 생각하세요. 코드를 전혀 쓸 줄 몰라도, **간단한 스케치 몇 장으로 아이디어를 눈에 보이는 앱 초기 형태로 바꿀 수 있습니다**. 이 단계가 명확할수록, 뒤에서 직접 구현하든 다른 사람과 협업하든 훨씬 수월해집니다.
+
+## 2.4 다른 앱 참고하기: 똑똑하게 숙제 베끼기
+
+많은 사람이 첫 앱을 만들 때 심리적 부담을 느낍니다. 페이지 구조, 상호작용 방식, 시각적 배치를 모두 0에서 시작해 완전히 독창적으로 만들어야 하는 것처럼 느낍니다. 그래야 진짜 제품을 만드는 것 같다고 생각합니다. 현실은, 이 원칙을 고집하면 중요하지 않은 곳에서 엄청난 에너지를 소모하게 됩니다.
+
+앱 설계에는 **똑똑하게 숙제 베끼기**라는 더 효율적이고 성숙한 태도가 있습니다. 단순 모방이 아니라, 이미 검증된 좋은 해법을 선택적으로 빌려 오고, 당신의 에너지는 가장 당신만의 가치가 필요한 곳에 남겨 두는 것입니다.
+
+인터넷에는 앱 인터페이스 스크린샷을 모아 둔 사이트가 많고, 앱 마켓의 상세 페이지도 많이 있습니다. 이런 곳은 그 자체로 거대한 참고 도감입니다. 당신은 자신의 방향과 가까운 앱 몇 개, 예를 들어 같은 종류의 도구나 같은 사람군의 제품을 골라 샘플을 연구하듯 한 페이지씩 볼 수 있습니다.
+
+중점적으로 관찰할 것은 색상이 얼마나 예쁜지가 아니라, 몇 가지 핵심 영역을 어떻게 처리했는가입니다.
+
+- 내비게이션 바는 어떻게 설계했는가. 아래쪽인가 위쪽인가. 고정된 핵심 입구 몇 개인가, 아니면 주요 버튼 하나뿐인가.
+- 폼은 어떻게 조직했는가. 한 페이지에서 한 번에 다 입력하는가, 아니면 여러 작은 단계로 나누는가.
+- 결과를 보여 줄 때 가장 중요한 정보가 가장 눈에 띄는 곳에 놓여 있는가. 부차 정보는 어떻게 접어 두었는가.
+- 새 사용자가 처음 들어올 때 다음에 어떻게 쓰는지 알려 주는 짧은 안내 흐름이 있는가.
+
+
+
+
+
+다음과 같은 웹페이지 스크린샷 수집 사이트를 참고할 수 있습니다.
+
+- [https://www.uisources.com/](https://www.uisources.com/)
+- [https://screenlane.com/](https://screenlane.com/)
+- [https://pagecollective.com/](https://pagecollective.com/)
+- [https://patttterns.net/](https://patttterns.net/)
+- [https://mobbin.com/](https://mobbin.com/)
+- [https://refero.design/](https://refero.design/)
+- [https://scrnshts.club/](https://scrnshts.club/)
+- [https://godly.website](https://godly.website/)
+
+다른 앱을 직접 참고하는 것 외에도, 해커톤(제한된 시간 안에 고강도로 팀 협업 개발을 진행해 짧은 시간에 제품 프로토타입이나 솔루션을 완성하는 활동) 수상작이나 공개 데모 사이트 같은 여러 대회에서 영감을 얻을 수 있습니다. 본질적으로 이것들은 실천자들이 아주 짧은 시간 안에 제출한 해결책입니다. 거칠지만, 제한된 시간 안에 아이디어에서 실행 가능한 제품까지 압축된 과정을 어떻게 완성하는지 보여 줍니다. 그들의 작품을 참고해 최소 제품 프로토타입이 무엇인지 생각할 수 있습니다. 다만 해커톤은 어디까지나 짧은 시간의 대회이므로, 창의성이 실용성보다 앞설 수 있고, 수상작이 반드시 장기 제품으로 참고하고 개발하기에 적합한 것은 아닙니다. 실제 상황에 따라 판단해야 합니다.
+
+그 밖에 이른바 도구형 사이트도 참고할 수 있습니다. 도구형 사이트는 날씨 조회 사이트, 다국어 번역 사이트, 포켓몬 도감 수집 사이트, 게임 공략 사이트, 인기 차량 순위 사이트, AI 도구 사이트 같은 것으로 이해하면 됩니다. 이런 도구 사이트는 기능이 매우 단순하지만, 어쩌면 어떤 사람의 요구를 만족시키는 아주 좋은 "앱"일 수 있습니다. 아이디어는 복잡함이 아니라 유용함에 있습니다. 서로 다른 앱을 참고하면 무엇이 시장 요구인지 정말로 알 수 있습니다.
+
+## 2.5 모든 것이 준비될 때까지 기다렸다가 사용자 요구를 조사하지 말기
+
+많은 사람이 말로는 사용자 주도 제품을 만들겠다고 하지만, 실제로는 먼저 문을 닫고 자신이 생각하는 완성 버전을 만든 뒤에야 용기를 내어 다른 사람에게 보여 주는 데 익숙합니다. **겉으로는 더 체면이 있어 보일 수 있습니다. 적어도 다른 사람 앞에서 반제품을 드러내지는 않으니까요. 하지만 제품 관점에서 보면 이는 매우 위험한 습관입니다.**
+
+이유는 간단합니다. 사용자를 늦게 만날수록, 앞에서 세부에 투입한 것이 많아지고, 방향이 틀렸을 때 손실이 커집니다. 중요하지 않은 기능에 이미 많은 코드를 썼을 수 있고, 많은 사람이 신경 쓰지 않는 세부를 위해 많은 그림을 설계했을 수 있습니다. 그리고 나중에야 사용자가 진짜 막히는 곳은 당신이 가장 많은 시간을 쓴 부분이 전혀 아니라는 사실을 발견할 수 있습니다.
+
+이 상황을 피하려면 스스로에게 늘 상기할 수 있는 간단하지만 효과적인 원칙이 있습니다. 그리면서 묻고, **만들면서 묻고, 다 만든 뒤에 묻지 마세요**.
+
+### 그리면서 묻기: 종이 단계에서 피드백 수집을 시작하기
+
+화이트보드나 종이에 입구 페이지, 작업 페이지, 결과 페이지를 막 그렸을 때도 이미 사용자와 대화할 기반이 있습니다. 이 단계에서 목표 사용자가 될 가능성이 있는 두세 명을 찾아 보여 주고, 첫 반응을 들을 수 있습니다.
+
+복잡한 인터뷰를 할 필요는 없습니다. 몇 가지 세부만 관찰하면 됩니다. 그들이 입구 페이지를 보고 당신이 기대한 말을 자연스럽게 하는가. 예를 들어 "이건 긴 글 요약을 하는 것 같네요" 같은 말입니다. 작업 페이지에서 당신이 예상한 순서대로 자연스럽게 진행하는가. 예를 들어 먼저 글을 붙여넣고, 그다음 요약 길이를 선택하는가. 결과 페이지에서는 당신이 보기를 바라는 부분에 한눈에 끌리는가, 아니면 중요하지 않은 구석에 얽매이는가.
+
+이런 관찰은 첫 줄의 코드를 쓰기 전부터 가장 뚜렷한 설계 문제를 드러내 줍니다. 이 피드백을 바탕으로 종이 위 프로토타입을 한 번 고치고, 다시 아래로 진행할 수 있습니다. 전체 앱을 이미 다 만든 뒤에 구조를 크게 바꾸는 것보다 훨씬 낫습니다.
+
+### 만들면서 묻기: 반제품 단계에서 사람을 불러 사용해 보게 하기
+
+기본 흐름이 돌아가는 반제품 버전이 생겼다면, 혼자 묵혀 둘 이유는 더더욱 없습니다. 화면이 거칠어도, 많은 기능이 아직 없어도, **당신이 정의한 최소 작업을 완료할 수만 있다면, 이미 진짜 사용자를 초대해 사용해 보게 할 조건을 갖춘 것**입니다.
+
+먼저 주변 사람부터 시작할 수 있습니다. 또한 앞 장에서 말한 사람 자산이나 공개 공간에서 접촉한 사용자 중 새 도구를 시도할 의향이 비교적 큰 사람을 고를 수도 있습니다. 그들에게 링크를 보내고, 지금 할 수 있는 일을 간단히 설명한 뒤, 당신이 너무 많이 설명하지 않는 상태에서 입구부터 결과까지 걸어가 보게 하세요.
+
+**이 과정에서 당신이 해야 할 일은 변명하는 것이 아니라 관찰하는 것입니다**. 그들은 어디에서 망설이는가, 어떤 단계에서 멈추는가, 어떤 버튼을 오래 보고도 감히 누르지 못하는가. 사후에 몇 가지 구체적인 질문을 할 수도 있습니다. 어떤 단계가 가장 힘들었나요. 어떤 결과가 가장 만족스러웠나요. 있을 줄 알았는데 결국 보지 못한 것은 무엇인가요.
+
+반제품 단계에서 이런 일을 하는 데에는 큰 장점이 있습니다. 아직 어떤 방안에도 지나치게 감정적으로 의존하지 않았기 때문에, 보기에는 멋지지만 사용자가 전혀 신경 쓰지 않는 기능을 잘라내기 더 쉽습니다. 또한 눈에 띄지 않지만 실제 사용에서 자주 나타나는 작은 세부를 최적화하는 데 시간을 쓰려는 마음도 더 커집니다.
+
+### 거칠게 드러나는 것을 두려워하지 않기
+
+많은 사람이 초기에 다른 사람에게 보여 주기 싫어하는 이유는 자신의 거친 상태가 드러나는 것이 두렵기 때문입니다. 프로답지 않아 보일까 걱정합니다. 하지만 오히려 반대입니다. 정말 성숙한 제품 담당자는 초기 버전에 대해 이런 부끄러움을 거의 갖지 않습니다. 문제는 일찍 드러낼수록 비용이 가장 낮다는 것을 알기 때문입니다.
+
+이 일을 바라보는 관점을 마음속에서 바꿔 볼 수 있습니다. 당신은 미완성품을 전시하는 것이 아니라, 상대를 함께 다듬는 과정에 초대하는 것입니다. 이것이 매우 초기 버전이고, 당신이 원하는 것이 칭찬이 아니라 가능한 한 직접적인 사용감이라고 미리 분명히 말하면, 대부분의 사람은 도움을 줄 의향이 있습니다. 특히 당신이 해결하려는 문제로 실제로 곤란을 겪고 있는 사람일수록 그렇습니다.
+
+여기까지 당신은 화이트보드와 종이로 추상적인 아이디어를 구체적인 사용자 경로로 바꾸는 법을 배웠습니다. 분해를 통해 크고 넓은 바람을 내일 바로 시작할 수 있는 최소 실행 항목으로 쪼개는 법을 알게 되었습니다. 또한 욕심내서 모든 생각을 첫 버전에 한꺼번에 넣지 말고, 더블 다이아몬드 모델로 발산과 수렴 사이를 오가며 먼저 할 가치가 가장 큰 MVP를 고르는 법도 알게 되었습니다. 기존 앱을 똑똑하게 참고하고, 내비게이션, 폼, 결과 표현 같은 기본 구조에서 다른 사람의 어깨 위에 서는 법을 배웠습니다. 더 중요한 것은, 모든 것이 준비될 때까지 기다렸다가 사용자를 찾는 것이 아니라, 데모 단계부터 그들을 들여보내고, 그들의 사용감을 통해 함께 방향을 수정해야 한다는 것을 알게 된 것입니다.
+
+이 도구와 단계를 통해, 당신은 이미 하나의 아이디어를 초기 사용 가능한 앱으로 쪼갤 능력을 갖추었습니다. 하지만 쓸 수 있는 앱과 진짜 쓰기 좋은 앱 사이에는 아직 한 겹의 장막이 있다는 것도 알게 될 것입니다.
+
+다음으로는 따로 이야기해 보겠습니다. 어떤 앱이 좋은 앱이라고 할 수 있는가. 첫 사용 가능 버전을 얻은 뒤, 다음 단계에서 어떻게 앱을 더 멀리 가게 만들 수 있는가.
+
+## 📚 Assignments
+
+위 내용을 바탕으로 다음 과제를 완료하세요.
+
+1. 어떤 대형 언어 모델이든 사용해, 이전 아이디어에 대해 AI가 더블 다이아몬드 모델을 참고하여 발산 결과를 제시하게 합니다. 당신은 그 발산 결과를 바탕으로 실행 가능한 솔루션 하나를 골라야 합니다.
+2. 이전에 떠올린 아이디어를 바탕으로, 분해와 세분화 방법을 사용해 더 구체적인 실행 가능 내용을 얻습니다. 예: "사용자에게 웹 도구를 제공해, 20페이지 이하의 순수 텍스트 PDF를 업로드하면 10초 안에 문단 구조가 명확하고 제목 계층이 유지된 편집 가능 텍스트를 얻고, 한 번에 복사하거나 `.txt`로 다운로드할 수 있게 한다."
+3. 세분화한 아이디어를 바탕으로 화이트보드에 앱을 그려 봅니다. 앱은 두 부분에 주목해야 합니다. 하나는 UI를 어떻게 설계할지, 다른 하나는 어떤 기능이 있어야 하며 각 기능이 어디에 있는지입니다.
+
+# 3. 만든 뒤에는, 어떻게 판단하고 다듬어 좋은 앱으로 만들 수 있는가
+
+마침내 첫 버전을 만들어 실제 세계에 내놓고 사람들이 사용하게 하면, 완전히 다른 단계에 들어갑니다. 앞서의 모든 논의는 아직 생각과 설계 차원에 머물러 있었지만, 이제 제품은 처음으로 진짜 사용 장면의 검증을 받습니다. 사용자가 잘못 누르는 곳, 망설이는 곳, 멈춰 움직이지 않는 곳을 보게 되고, 어떤 단계에서는 의외로 아주 매끄럽게 지나가거나, 어떤 구석에 뜻밖에 몇 초 더 머무는 것도 보게 됩니다. 이런 세부는 머릿속의 온갖 제품 상상보다 훨씬 정직합니다.
+
+이 장에서 해결하려는 핵심 문제는 이것입니다. 앱이 이미 만들어졌고, 심지어 초기 사용자가 어느 정도 사용하고 있을 때, 그것이 좋은 앱에서 얼마나 떨어져 있는지 어떻게 판단하고, 실제 사용 과정에서 얻은 정보를 어떻게 활용해 한 걸음씩 잘 다듬을 것인가.
+
+## 3.1 좋은 앱이란 무엇인가: 4가지 핵심 특징
+
+앱이 좋은지 판단할 때는 당신 자신이 얼마나 좋아하는지만 보아서는 안 되고, 다운로드 수나 하루 이틀의 사용 횟수만 보아도 안 됩니다. 더 아래에 있고 더 안정적인 특징을 갖추었는지를 보아야 합니다. 간단히 말하면 다음 몇 가지 특징을 참고할 수 있습니다.
+
+### 좋은 앱은 구체적 가치를 가져온다
+
+좋은 앱의 가장 직접적인 특징은, 어떤 장면에서 사람이 실제로 조금이라도 이익을 얻도록 한다는 것입니다. 이 이익은 거창할 필요도 없고, 어려운 말로 포장할 필요도 없습니다. 하지만 당신이 분명히 말할 수 있을 정도로 구체적이어야 합니다. **그것이 도대체 사용자가 무엇을 덜 하게 했는지, 얼마나 시간을 덜 쓰게 했는지, 또는 어떤 일을 덜 실수하게 만들었는지** 말입니다.
+
+
+
+예를 들어 간단한 회의록 도구가 있다고 합시다. 녹음을 업로드하거나 회의 중 직접 녹음하기만 하면, 회의가 끝난 뒤 구조화된 회의록을 자동으로 생성하고, 할 일, 담당자, 마감일을 목록으로 정리해 준다면, 사용자가 절약하는 것은 단순한 타자 시간이 아닙니다. 기록, 정리, 선별, 형식화 출력까지 전체 과정의 정신적 에너지입니다. 이 도구가 회의 한 번마다 한 사람에게 대략 20분을 절약해 준다고 매우 명확히 말할 수 있습니다. 팀 전체가 매주 이런 회의를 10번 한다면 총 절약 시간은 상당합니다.
+
+또 예를 들어 별것 아닌 것처럼 보이는 이미지 압축 도구가 있습니다. 육안으로 거의 차이를 볼 수 없는 전제에서 이미지 묶음의 용량을 원래의 3분의 1로 줄이고, 동시에 한 번에 내보내기, 폴더 구조 유지, 이름 규칙 통일까지 보장한다면, 그것이 가져오는 가치는 단지 하드디스크 공간 절약만이 아닙니다. 더 빠른 전송, 더 매끄러운 업로드, 다른 시스템과 연결할 때 더 적은 오류도 포함됩니다. 이런 평범해 보이는 구체적 가치는 "효율 향상"이라는 모호한 말보다 훨씬 믿을 만한 경우가 많습니다.
+
+따라서 자신의 앱이 가치 있다고 말할 때는, 가치를 한두 가지 구체적 장면으로 쪼개고, 평범한 사람이 이해할 수 있는 말로 설명하는 것이 가장 좋습니다. 당신의 앱은 사용자가 원래 얼마나 오래 걸리고, 얼마나 많은 수작업을 해야 하며, 얼마나 큰 위험을 감수해야 했던 일을 더 수월하게 만듭니까.
+
+### 사용자가 쉽게 시작하고, 거의 설명서를 보지 않아도 이해한다
+
+또 하나 과소평가되기 쉽지만 매우 중요한 특징은 **좋은 앱은 대개 많은 설명이 필요 없다는 것**입니다. 사용자가 처음 열었을 때 직감만으로 어디서 시작해야 할지, 무엇을 누르면 무슨 일이 생기는지 대략 알 수 있습니다. 가장 큰 버튼은 보통 가장 핵심적인 일을 하며, 가장 중요한 입구는 진짜 중요한 위치에 놓여 있습니다. 메뉴 세 번째 층에 숨어 있지 않습니다.
+
+
+
+방금 당신의 앱을 다운로드한 새 사용자를 상상해 보세요. 그는 줄을 서 있거나, 차 안에 있거나, 카페에서 무심코 열었을 수 있습니다. 그때 네트워크 신호가 꼭 좋지는 않고, 긴 설명서를 읽을 인내심도 없습니다. 그가 견딜 수 있는 혼란의 시간은 대개 몇 초뿐입니다. 이 몇 초 안에 어떤 명확한 안내도 보이지 않고, 다음에 무엇을 해야 할지 모르면, 바로 닫아 버리고 다시 돌아오지 않을 가능성이 큽니다.
+
+그래서 자신이 제품 로직이 매우 매끄럽다고 느낄 때는, 당신의 앱을 전혀 본 적 없는 사람을 찾아 아무 말도 하지 않고 0에서부터 만져 보게 하는 것이 좋습니다. 당신은 그가 어디에서 멈추는지, 어디에서 망설이는지, 언제 "이게 뭐지"라는 표정을 짓는지만 관찰합니다. 사용자가 들어오자마자 온갖 시작 팝업, 복잡한 옵션, 계정 연결에 막힌다면, 당신이 제공하려는 진짜 가치를 진지하게 경험하기 어렵습니다.
+
+**시작하기 쉬움은 본질적으로 제품이 사용자 비용을 존중하는 방식입니다**. 당신은 한 가지 사실을 인정하고 있습니다. 아무도 당신의 앱을 연구하는 데 시간을 써야 할 의무가 없습니다.
+
+### 자주 쓰거나 중요한 장면에서 자연스럽게 당신을 떠올린다
+
+좋은 앱은 대개 안정적인 사용 리듬이 있습니다. 자주 쓰이거나, 중요할 때 쓰입니다. **고빈도란 매일 여러 번 여는 메시지 앱처럼 사용자의 일상에 녹아든다는 뜻**입니다. 매일 출퇴근에 쓰는 이동 도구, 매일 기록하는 습관 체크 앱이 그렇습니다. 중요하다는 것은 매일 쓰지는 않더라도 어떤 장면을 만나면 사용자가 가장 먼저 당신을 떠올린다는 뜻입니다. 예를 들어 세금 신고 도구, 인테리어 예산 계산기, 면접 질문 관리 도구, 비자 서류 체크리스트 도우미 같은 것입니다.
+
+스스로에게 몇 가지 질문을 할 수 있습니다. 사용자는 진짜로 언제, 어떤 상황에서 당신의 앱을 쓰게 되는가. 당신의 앱을 놓치면 정말 불편함을 느끼는가. 같은 장면에서 지금은 어떤 방식으로 살아가고 있는가. 대체 수단이 있고, 그것이 번거롭더라도 이미 익숙하다면, 당신이 해야 할 일은 기능을 맞추는 것뿐 아니라 이쪽으로 옮겨 오는 것이 정말 더 가치 있다고 느끼게 하는 것입니다.
+
+흔한 오해는 사용 빈도와 앱의 좋고 나쁨을 직접 묶는 것입니다. 사실 꼭 그렇지는 않습니다. 연말 보고서를 만들거나, 어떤 증명서를 처리하거나, 큰 금액을 이체하는 일은 그 자체로 빈도가 높지 않습니다. 하지만 한 번 발생하면 사용자에게는 그 순간 가장 중요한 일 중 하나입니다. **당신의 앱이 이런 중요한 장면을 안정적이고 빠르며 마음이 놓이게 처리할 수 있다면, 그것 역시 좋은 앱이라고 할 수 있습니다.**
+
+**정말 경계해야 할 것은, 사용자가 당신을 자주 쓰지도 않고, 어떤 중요한 순간에도 능동적으로 떠올리지 않는 경우**입니다. 심지어 당신의 앱이 휴대폰에서 사라져도 몇 달 뒤 저장공간을 정리하다가 예전에 이런 걸 설치했었다고 흐릿하게 떠올릴 뿐입니다. 이런 상황은 대개 당신의 앱이 어떤 실제 장면과도 깊이 묶이지 않았고, 기능 차원에서 존재감이 약한 것들을 쌓아 놓았을 뿐임을 뜻합니다.
+
+### 이타심
+
+많은 사람이 처음 제품을 만들 때 마음속으로 여러 가지를 동시에 계산합니다. 만들고 나서 어떻게 과금할지, 어떻게 가격을 올릴지, 어떻게 사용자가 조금 더 쓰면 돈을 내게 할지, 어떻게 데이터를 묶어 사용자가 떠나지 못하게 할지 같은 것들입니다. 비즈니스 계산 자체는 문제가 없습니다. 하지만 시작부터 사고가 온통 여기에만 둘러싸이면, 한눈에 경계심을 일으키는 앱을 만들기 쉽습니다. 처음부터 온갖 권한을 요구하고, 곳곳에 교묘한 과금 지점을 두고, 기능 설계가 사용자가 매끄럽게 작업을 끝내도록 돕기보다 어떤 유료 버튼으로 유도하려는 것처럼 보입니다.
+
+그에 비해 진짜 좋은 앱에는 대개 소박한 이타심이 있습니다. 어떻게 살아남을지 분명히 생각하고, 합리적인 과금 방식도 설정하지만, 경로와 경험을 설계할 때 우선순위는 언제나 **사용자가 이 일을 더 쉽게, 더 순조롭게 완료하도록 하는 방법**에 놓여 있습니다. 몇 단계를 더 넣어 추가 장벽을 만드는 방법이 아닙니다. 이런 앱은 많은 곳에서 사용자에게 더 친절한 방식을 사용합니다. 핵심 단계에서 명확한 안내를 주고, 내보내기와 이전에 과도한 장벽을 만들지 않으며, 과금 전에 적어도 일부 실질적 가치를 경험하게 합니다.
+
+이런 이타심은 자주 작은 설계 세부에서 드러납니다. 예를 들어 폼 항목이 더 많은 정보를 얻기 위해 작업과 무관한 데이터를 잔뜩 요구하지 않습니다. 튜토리얼의 순서는 기능 모듈 자체가 아니라 사용자가 달성하려는 목표를 중심으로 설계됩니다. 사용자는 이 앱이 나를 짜내야 할 대상으로 보는 것이 아니라, 내가 한 가지 일을 해내도록 진지하게 돕고 있다고 느낍니다.
+
+또 한 가지 중요한 점이 있습니다. **좋은 앱이 반드시 큰 앱일 필요는 없습니다. 작아도 됩니다. 한 종류의 사람, 한 장면, 한 작업만 서비스해도 됩니다**. 다만 그 작은 조각 안에서 충분히 잘해 내면 됩니다. 예를 들어 디자이너가 출력소가 요구하는 형식으로 시안을 내보내도록 돕는 전용 도구나, 프리랜서가 개인 프로젝트 사례를 정리하도록 돕는 전용 도구는 범위가 크지 않지만 그 안의 가치는 전혀 작지 않습니다.
+
+## 3.2 요구 통찰: **매슬로의 욕구 단계 이론**
+
+
+
+앱을 만들기 전에 많은 사람은 곧장 기능 차원으로 뛰어듭니다. 이쪽에 무엇을 더 만들 수 있을까, 저쪽에 버튼을 하나 더 넣을까. 그러나 앱이 살아남을 수 있는지를 진짜로 결정하는 것은, 당신이 사람의 어느 층위의 욕구를 얼마나 정확히 밟았는가입니다.
+
+매슬로의 욕구 단계 이론이 이렇게 많은 분야에서 반복해서 언급되는 이유는, 그것이 엄밀해서가 아니라 충분히 쓰기 좋은 관찰 프레임워크를 제공하기 때문입니다. 이를 엄격한 심리학 결론으로 볼 필요는 없습니다. 간단한 틀로만 보면 됩니다. 사용자의 여러 동기를 비교적 명확한 몇 층위에 걸어 두고, 당신의 앱이 도대체 어떤 종류의 욕구를 만족시키는지 판단하기 쉽게 도와줍니다. 더 많은 욕구를 만족시킬수록 더 좋은 앱이 됩니다.
+
+매슬로의 욕구 단계 이론은 보통 다섯 층으로 나뉩니다. 아래에서 위로 생리적 욕구, 안전 욕구, 소속과 사랑, 존중 욕구, 자아실현입니다.
+
+### 생리와 생존 관련 욕구
+
+이 층은 가장 기초적이며, 먹기, 자기, 생존 상태 자체와 직접 관련됩니다. 인터넷 제품과는 조금 멀어 보이지만, 사실 적지 않은 앱이 이 층에서 작동합니다.
+
+예를 들어 배달, 장보기, 심부름, 숙소 예약, 택시 호출 같은 대표적인 생활과 이동 서비스는 본질적으로 사용자가 더 낮은 시간 비용으로 먹기, 외출, 휴식 같은 가장 기본 문제를 해결하도록 돕습니다. 또 운동 기록, 수면 모니터링, 식단 체크인은 겉으로는 건강 관리에 더 가까워 보이지만, 많은 사람에게는 통제 불능이 되지 않는 신체 상태를 유지하려는 시도입니다. 이것도 생리와 생존 층의 확장으로 볼 수 있습니다.
+
+당신의 앱이 이 층에서 힘을 쓴다면 한 가지 특징이 있습니다. **사용자는 안정성, 신뢰성, 예측 가능성에 특히 민감합니다**. 배달이 오지 않거나, 택시가 계속 잡히지 않거나, 숙소 예약 정보가 틀리는 일은 매우 강한 감정 반응을 일으킵니다. 이런 문제는 생활의 기본 리듬을 직접 끊어 버리기 때문입니다.
+
+### 안전감과 확실성의 욕구
+
+안전 욕구에는 물리적 안전뿐 아니라 경제, 정보, 심리적 안전감도 포함됩니다.
+
+많은 도구형 앱은 사실 주로 이 안전 층에서 작동합니다. 예를 들어 가계부, 자산 관리, 보험 도우미, 계약서 템플릿 도구, 비밀번호 관리자, 백업 도구, 개인정보 보호 도구, 클라우드 동기화, 데이터 복구 같은 것들입니다. 이런 앱의 핵심 약속은 대개 실수 확률을 낮춰 주고, 문제가 생겼을 때 대안을 갖게 해 주며, 적어도 마음이 놓이게 해 준다는 것입니다.
+
+전형적인 종류 중 하나는 잃어버림, 잊어버림, 실수를 막는 여러 작은 도구입니다. 일정 알림, 약 복용 알림, 중요 문서 만료 알림, 핵심 시점의 메모 같은 것들입니다. 이런 앱은 매일 몇 번만 알려 주더라도, 한두 번 결정적인 순간에 당신을 구해 주면 곧장 반드시 남겨 두어야 할 도구로 분류됩니다.
+
+이런 제품을 설계할 때는 한 문장을 더 물어볼 수 있습니다. **당신은 도대체 사용자의 어떤 위험을 낮추는가. 돈의 위험인가, 시간의 위험인가, 관계의 위험인가**, 아니면 규정 준수와 법률의 위험인가. 당신 자신도 말하지 못한다면 사용자가 당신을 진짜로 신뢰하기 어렵습니다.
+
+### 소속감, 연결, 보인다는 느낌
+
+그 위층은 소속과 사랑의 욕구입니다. 간단히 말하면 나는 혼자이고 싶지 않으며, 어떤 사람들과 연결되어 있고 싶다는 것입니다. 이 층은 소셜 앱, 커뮤니티 앱, 관심사 그룹 앱의 본거지입니다.
+
+친구 피드, 그룹 채팅, 관심 포럼, 동호회 커뮤니티, 온라인 독서 모임, 게임 속 길드, 심지어 초보 부모 모임, 유학생 상호 지원, 업계 내부 익명 불평 플랫폼처럼 특정 정체성을 중심으로 한 도구는 본질적으로 어떤 소속감을 제공합니다. 나와 비슷한 사람들이 있고, 우리는 비슷한 주제를 보고, 비슷한 어려움을 불평하고, 비슷한 경험을 나눕니다.
+
+어떤 도구는 겉으로 기능형 앱이지만, 실제로 사용자를 붙잡는 것은 이 층의 욕구인 경우가 많습니다. 예를 들어 가계부 앱에서 사람들이 자신의 저축 진도를 공유하거나, 러닝 앱의 순위와 체크인 모임, 학습 앱의 상호 감독 그룹이 그렇습니다. 이런 부가적인 소셜 모듈은 사실 사용자가 당신의 앱을 자신의 어떤 집단 정체성과 묶게 만드는 역할을 합니다.
+
+당신의 앱이 이 층에 서려고 한다면, 내용만으로는 부족합니다. 생각해야 할 것은 **사용자가 왜 여기를 자기 사람들의 공간이라고 느끼는가, 이곳에 흔적을 남기고 다른 사람과 가볍지만 진짜 상호작용을 하려 하는가**입니다. 그렇지 않으면 당신이 만든 것은 단방향 방송 도구일 뿐입니다.
+
+### 존중, 자기 가치, 성취감
+
+그 위층은 존중과 자존 욕구입니다. 사람은 받아들여지고 싶어 할 뿐 아니라, 어느 단계에서는 이곳에서 나는 괜찮은 사람인가, 내가 보이고 인정받는가, 내가 해낸 일을 누군가 아는가를 신경 쓰기 시작합니다.
+
+많은 체크인, 배지, 순위표, 칭호, 성취 시스템은 사실 이 층에서 작동합니다. 학습 앱에서 몇 시간의 수업을 완료하면 칭호를 주고, 운동 앱에서 목표를 달성하면 인증서를 주며, 창작 플랫폼은 작가에게 서로 다른 등급의 신분 표시를 열어 주고, 커뮤니티에서는 좋은 콘텐츠 작성자에게 뚜렷한 강조 표시를 줍니다.
+
+여기서 쉽게 생기는 오해는 배지, 포인트, 칭호를 잔뜩 붙이면 사용자를 자극할 수 있다고 생각하는 것입니다. 사용자가 원하는 것은 과장된 장식이 아니라, 자신의 실제 노력이 기록되고 진지하게 다루어지는 것입니다. 당신이 설계한 성취 시스템이 사용자의 실제 투입과 전혀 연결되어 있지 않다면, 예를 들어 몇 번만 아무렇게나 누르면 고급 칭호를 받을 수 있다면, 그 동기는 곧 효력을 잃고 심지어 싸구려처럼 느껴질 수 있습니다.
+
+그래서 이 층에서 핵심은 동기부여 시스템이 있는지 여부가 아닙니다. **당신의 앱이 사용자에게 축적 가능한 무대를 제공하는가, 사용자가 초보자에서 숙련자로 변하는 모습을 분명히 볼 수 있게 하는가**, 그리고 중요한 지점에서 이 단계는 기록할 가치가 있다는 의식을 주는가입니다.
+
+### 자아실현과 자기 초월
+
+피라미드의 가장 위층은 내가 어떤 사람이 되고 싶은가, 그리고 내 일부를 어떻게 기여하고 싶은가를 향합니다. 추상적으로 들리지만 구체적인 장면으로 내려오면 매우 실제적인 표현이 있습니다.
+
+예를 들어 창작 도구가 있습니다. 글쓰기, 그림, 음악 제작, 영상 편집, 프로그래밍 프로젝트 관리는 겉으로는 기술 능력을 제공하지만, 그 뒤에는 자신만의 무언가를 만들고 싶다는 사용자의 갈망을 받칩니다. 또 장기 학습 플랫폼, 커리어 계획 도구, 습관 형성 도구도 단일 기술만 서비스하는 것이 아니라 더 장기적인 자기 성장 목표를 서비스합니다.
+
+또 다른 종류는 다른 사람을 더 좋게 만들고 싶은 요구입니다. 많은 사람이 지식 공유 플랫폼, 질의응답 커뮤니티, 공익 앱, 협업 창작 도구를 사용하는 이유는 단지 포인트나 트래픽을 얻기 위해서가 아닙니다. 다른 사람을 돕고, 어떤 프로젝트를 앞으로 밀어내는 과정에서 내가 의미 있는 일을 하고 있다는 느낌을 얻기 때문입니다. 이것도 자아실현의 일부입니다.
+
+당신의 앱이 진짜로 이 층을 건드릴 때는 대개 매우 강한 점성이 생깁니다. 화면이 가장 예쁘지 않아도, 기능이 가장 완전하지 않아도 사용자는 이곳에 머뭅니다. **그것이 내가 어떤 사람인지, 내가 어떤 일을 하고 있는지와 더 깊은 연결을 맺기 때문**입니다.
+
+매슬로 피라미드를 제품 시각의 하나로 삼는 장점은 두 가지 흔한 편향을 피하게 해 준다는 점입니다.
+
+**첫 번째 편향은 잘못된 한 층위만 계속 바라보는 것입니다**. 예를 들어 사용자가 파일을 안전하게 저장하도록 돕는 도구를 만든다면 본질적으로 안전 층에 서 있습니다. 그런데 당신이 소셜 제품을 무작정 따라 하며 화면에 좋아요, 댓글, 순위표를 잔뜩 쌓는다면, 소셜 제품의 사용자 마음도 얻지 못하고, 그저 안전한 저장 도구를 원하는 사람에게는 본업을 하지 않는 것처럼 보입니다.
+
+**두 번째 편향은 층위 사이의 선후 관계를 무시하는 것입니다**. 사람이 가장 기본적인 안정적 사용 경험조차 보장받지 못할 때, 당신의 앱에서 진지하게 자아실현을 추구하기는 어렵습니다. 예를 들어 앱이 자주 멈추고 데이터가 가끔 사라진다면, 아무리 많은 배지와 성장 곡선을 주어도 사용자는 진심으로 몰입하지 않습니다. 반대로 기초 층위가 단단하게 만들어져 있고, 그 위에 더 높은 층위의 가치를 점진적으로 더한다면, 사용자는 당신과 함께 더 쉽게 위로 올라갑니다.
+
+실제 설계에서는 이렇게 자가 점검할 수 있습니다.
+
+- 먼저 묻습니다. 내 앱이 가장 주로, 가장 핵심적으로 만족시키는 욕구 층은 어디인가. 하나만 고를 수 있습니다.
+- 다음으로 묻습니다. 이 핵심 층 위에서, 억지로 개념을 붙이는 것이 아니라 자연스럽게 한 층 위로 확장할 기회가 있는가.
+- 마지막으로 봅니다. 목표 층보다 아래의 층들에서 명백한 단점이 있거나, 심지어 사용자의 발목을 잡고 있지는 않은가.
+
+이 질문들에 명확히 답할 수 있다면, 사용자가 진짜로 원하는 것이 무엇인지에 대한 이해는 더 이상 "그들이 아마 좋아할 것 같다"는 흐릿한 수준에 머물지 않습니다. 이는 더 좋은 앱을 만드는 데 도움이 됩니다.
+
+## 3.3 사용자 유형별 분류: C 사이드 앱과 B 사이드 앱의 차이
+
+앱을 만들고 나면 곧 또 하나 중요한 사실을 발견하게 됩니다. 일반 개인 사용자를 상대하는 것과 기업이나 기관 사용자를 상대하는 것은 완전히 다른 게임 규칙입니다. 둘 다 사용자라고 부르지만, 신경 쓰는 중점은 완전히 다릅니다.
+
+- C 사이드(Consumer End): "소비자 쪽"을 뜻하며, 핵심은 일반 개인 사용자입니다.
+ 예를 들어 우리가 일상적으로 쓰는 WeChat, Douyin, Meituan 배달 같은 앱의 사용자는 하나하나의 독립된 개인입니다. 이런 개인에게 서비스를 제공하는 장면이 C 사이드 비즈니스입니다.
+- B 사이드(Business End): "기업 쪽"을 뜻하며, 핵심은 기업, 기관, 조직 사용자입니다.
+ 예를 들어 회사에서 쓰는 DingTalk(기업 협업 도구), 재무 소프트웨어(예: Yonyou, Kingdee), 소매 매장의 POS 시스템 같은 제품의 사용자는 기업 직원, 팀, 전체 기관입니다. 기업의 경영, 관리, 생산 등을 서비스하는 장면이 B 사이드 비즈니스입니다.
+
+### C 사이드 앱: 보통 사람의 생활, 감정, 습관을 향한다
+
+C 사이드 앱은 개인 사용자를 향하며, 각자의 일상생활 안에 박혀 있습니다. 흔한 유형에는 콘텐츠형, 도구형, 엔터테인먼트형, 소셜형, 학습형 등이 있습니다.
+
+
+
+콘텐츠형 앱은 뉴스 읽기, 짧은 영상 플랫폼, 팟캐스트 도구 같은 것입니다. 핵심 작업은 보통 제한된 시간 안에 방대한 정보에서 사용자가 관심 있는 내용을 걸러 내게 하는 것입니다. 동시에 계속 새로운 것이 있어 사용자가 돌아오게 해야 합니다.
+
+도구형 앱은 가계부, 할 일 목록, 파일 관리, 캘린더 일정 같은 것입니다. 이들은 대개 어떤 구체적 작업에서 원래 방식보다 더 손쉬운 해결책을 제공합니다. 사용자가 일상적으로 쓰는 기초 인프라 중 하나입니다.
+
+엔터테인먼트형 앱에는 게임, 가벼운 상호작용, 재미있는 작은 도구가 포함됩니다. 이들이 사용자에게 제공하는 것은 감정적 이완과 즐거움입니다. 좋고 나쁨을 판단하는 기준은 사용자가 계속 시간을 쓰고 싶어 하는가에 더 가깝습니다.
+
+소셜형 앱은 사람 사이의 연결과 상호작용을 중심으로 하며, 학습형 앱은 단어 암기, 문제 풀이, 독서 체크인, 수업 관리처럼 어떤 능력 향상을 중심으로 합니다.
+
+이 앱들은 종류가 다르지만 몇 가지 공통 관심사가 있습니다.
+
+**첫째, 사용자 성장입니다.** 즉 더 많은 사람이 처음으로 당신의 앱을 시도하게 하는 방법입니다. 여기에는 채널, 전파 문구, 사용자 인센티브가 관련됩니다. 하지만 전제는 언제나 같습니다. 먼저 충분히 명확한 사용 장면이 있어야 합니다. 그렇지 않으면 아무리 뛰어난 성장 수단도 단기적인 호기심만 가져올 수 있습니다.
+
+**둘째, 리텐션과 재방문입니다.** 누군가 왔다는 것이 아니라, 그가 남고 돌아오려 하는가입니다. 콘텐츠형 앱이 사용자가 관심 있어 하는 콘텐츠를 지속적으로 생산하지 못하면 곧 대체됩니다. 도구형 앱이 핵심 몇 번의 사용에서 사용자가 진짜로 작업을 완료하도록 돕지 못하면 장기 사용 습관도 만들기 어렵습니다. 1일차, 7일차, 30일차 리텐션을 관찰해, 도대체 얼마나 많은 사람이 당신을 생활 리듬 안에 넣었는지 판단할 수 있습니다.
+
+**셋째, 전환과 결제입니다.** 사용자가 결제하려는 이유는 보통 당신이 무료 버전을 아주 형편없게 만들었기 때문이 아닙니다. 이미 당신에게서 일부 가치를 얻은 뒤, 유료 기능이 더 높은 수준의 편의를 가져온다는 것을 보았기 때문입니다. 예를 들어 더 높은 사용 한도, 더 강한 협업 능력, 더 전문적인 템플릿, 더 안정적인 성능이 그렇습니다.
+
+**넷째, 공유 전파성입니다.** 많은 C 사이드 제품이 빠르게 퍼지는 이유는 사용 과정에 자연스럽게 공유 속성이 있기 때문입니다. 예를 들어 이미지, 영상, 텍스트를 생성할 때, 사용자는 자신의 목표를 완료하기 위해 결과를 다른 사람에게 보내야 합니다. 이 과정에서 브랜드 노출을 자연스럽고 거슬리지 않게 만들 수만 있다면 일부 입소문 전파를 얻을 수 있습니다.
+
+C 사이드의 진짜 요구를 판단하는 간단한 방법은, 사용자가 그것을 중심으로 자기만의 작은 습관을 만들려 하는지 보는 것입니다. 매일 열어 보고 싶어 하는지, 자신의 생활 리듬과 묶으려 하는지, 중요한 순간의 기록에 그것을 참여시키려 하는지입니다. 반대로 사용자가 행사나 광고 때문에 한 번 들어와 쓰고 바로 떠나며 거의 돌아오지 않는다면, 당신이 해결한 것은 장기 요구가 아니라 일시적인 호기심일 가능성이 큽니다.
+
+### B 사이드 앱: 조직의 효율, 비용, 위험 통제를 향한다
+
+B 사이드 앱은 기업, 팀, 기관 또는 어떤 부서를 향합니다. 흔한 유형에는 ERP(자원 관리 시스템), CRM(고객 관계 관리), 협업 오피스 도구, 각종 SaaS 도구, 업계 내부 관리 시스템 등이 있습니다.
+
+
+
+이런 앱이 C 사이드와 가장 다른 점은 여러 역할의 요구를 동시에 만족시켜야 한다는 것입니다. 사용자는 현장 직원일 수 있지만, 의사결정자는 관리자나 대표일 수 있습니다. 데이터의 소유자는 조직 자체일 수 있고, 승인 흐름은 여러 부서를 포함할 수 있습니다. 당신은 사용자가 쓰기 좋다고 느끼게 해야 할 뿐 아니라, **의사결정자가 투자 대비 수익을 보게 해야 하며**, 전체 조직이 위험과 규정 준수 측면에서 안전하다고 느끼게 해야 합니다.
+
+B 사이드 앱에는 특히 핵심적인 관심사가 몇 가지 있습니다.
+
+**첫째, 효율 향상입니다.** 이는 한 사람의 시간이 줄어드는 것만 뜻하지 않습니다. 전체 프로세스 시간이 줄고, 협업 비용이 낮아지며, 커뮤니케이션 단계가 줄어드는 것을 뜻합니다. 예를 들어 주문 하나가 생성에서 출고까지 원래 다섯 개 시스템을 거쳤는데, 이제 하나의 통합 입구로 전체 흐름이 이어진다면, 이런 향상은 기업에게 매우 구체적인 가치입니다.
+
+**둘째, 비용 절감입니다.** 인건비, 교육 비용, 시스템 유지 비용 등이 포함됩니다. 어떤 시스템이 보기에는 기능이 매우 강력하지만, 간신히 돌아가게 하려면 많은 교육과 유지 자원을 투입해야 한다면, 많은 중소기업에는 비용 대비 효용이 낮아 보일 수 있습니다. 오히려 겉보기에는 더 가볍지만 빠르게 시작하고 빠르게 수익을 볼 수 있는 SaaS 도구가 현실 세계에서 더 쉽게 살아남습니다.
+
+**셋째, 위험 통제와 규정 준수 보장입니다.** 많은 B 사이드 장면에서는 금융, 의료, 제조, 공공 행정 같은 업계처럼 규정 준수와 추적 가능성에 높은 요구가 있습니다. 좋은 B 사이드 앱은 종종 사용상의 자유도를 조금 희생해 더 명확한 권한 관리, 더 엄격한 로그 기록, 더 분명한 승인 사슬을 얻습니다. 개인 사용자에게는 마음대로 할 수 있는 공간이 조금 줄어드는 것처럼 보일 수 있지만, 조직 전체에는 오히려 가치가 됩니다.
+
+**넷째, 권한 관리와 책임 경계입니다.** 누가 무엇을 볼 수 있는가, 누가 무엇을 고칠 수 있는가, 누가 어떤 결과에 책임을 지는가. 이런 문제는 B 사이드 시스템 설계의 핵심입니다. 여기서 잘못하면 이후 감사, 분쟁, 책임 추적에 큰 문제가 생깁니다. 따라서 B 사이드 앱이 좋은 앱인지 판단할 때는 화면이 보기 좋은지만 볼 수 없습니다. 권한 모델이 엄격한지, 이해하고 유지하기 쉬운지도 보아야 합니다.
+
+업계에서 앱으로 이어지는 사고는 이렇게 할 수 있습니다. **교육훈련, 이커머스, 제조, 금융, 의료처럼 어느 정도 이해가 있는 업계를 하나 고르고**, 그 업계의 일상 운영에서 어떤 프로세스가 특히 사람의 손에 의존하는지, 어떤 정보가 자주 여러 시스템이나 여러 개인 채팅에 흩어지는지, 어떤 단계의 오류율이 특히 높지만 즉시 발견하기 어려운지 쪼개서 봅니다. 이런 지점을 둘러싸면 매우 집중된 작은 도구를 설계할 수 있는 경우가 많습니다.
+
+예를 들어 교육훈련 업계에서 아주 구체적인 앱 절개면은 수업 시간표와 강의실 이용률 최적화 도구를 만드는 것입니다. 전체 학사 시스템을 대체할 필요는 없습니다. 교무 담당자가 강사, 강의실, 수업 시간을 더 쉽게 배치하고, 충돌을 자동으로 피하며, 최적 조합을 제시하고, 모두가 이해할 수 있는 시간표를 내보내게 하는 데 집중하면 됩니다. 이것만으로도 반복 커뮤니케이션과 수정 시간을 많이 줄일 수 있습니다.
+
+이커머스 업계에서 흔한 요구는 다채널 주문 관리입니다. 판매자는 여러 플랫폼에 동시에 매장을 갖고 있을 수 있고, 주문 정보는 곳곳에 흩어져 있습니다. 여러 플랫폼의 주문을 한데 모아 애프터서비스와 물류 정보를 통합 처리하는 작은 도구를 제공할 수 있다면, 그들이 매일 반복 조작하는 큰 고통 하나를 이미 해결한 것입니다.
+
+제조업에서는 여전히 많은 기업이 생산 진도 추적을 위해 종이 기록이나 Excel에 의존합니다. 간단한 작업지시 추적 도구에서 시작해, 현장 관리자가 하루 종일 사람에게 묻고 전화하는 대신 각 공정의 상태를 더 직관적으로 볼 수 있게 할 수 있습니다.
+
+금융이나 의료 업계에서 당신의 진입점은 반드시 프론트 업무일 필요는 없습니다. 규정 준수 검사 보조 도구, 문서 템플릿 생성, 승인 자료 체크리스트 관리가 될 수 있습니다. 어떤 프로세스에서 어떤 직무의 어떤 작업을 더 통제 가능하게 만드는지 말할 수만 있다면, 이미 시도해 볼 만한 방향입니다.
+
+위 업계의 앱에는 대개 성숙한 회사의 제품이 홍보 중인 경우가 많습니다. 이는 오히려 당신에게 좋은 참고 경로를 제공합니다. 인터넷에서 "대응 업계 + 핵심 요구 + 제품" 키워드(예: "교육훈련 업계 교무 시간표 시스템", "이커머스 다채널 주문 관리 도구")를 능동적으로 검색할 수 있습니다. 구체적인 제품 홈페이지와 기능 소개뿐 아니라 사용자 평가, 업계 사례, 심지어 제품 데모 영상까지 볼 수 있습니다. 이런 정보는 성숙한 제품이 같은 종류의 문제를 어떻게 해결하는지 직관적으로 이해하게 하며, 0에서 더듬어 가는 시행착오 비용을 줄여 줍니다.
+
+## 3.4 사용자 데이터로 다듬기: 내가 좋다고 느끼는 것에서 사용자가 좋다고 느끼는 것으로
+
+앱을 만든 뒤 가장 쉽게 생기는 착각이 있습니다. 자신이 쓰면 쓸수록 편하고, 어디든 합리적이라고 느끼니 사용자도 그럴 것이라고 생각하는 것입니다. 실제로는 자신이 쓴 제품일수록 다른 사람의 문제를 보지 못하기 쉽습니다. 앱을 자기 만족스러운 작품에서 진짜 좋은 앱으로 자라게 하려면, 실제 사용자 피드백을 해결 과정 안으로 끌어들일 줄 알아야 합니다.
+
+### 간단한 피드백 메커니즘을 설계해 사용자가 말할 출구를 만들기
+
+처음부터 복잡한 고객센터 시스템과 데이터 플랫폼을 만들 필요는 없습니다. 아주 간단한 방식부터 시작할 수 있습니다.
+
+**그룹 채팅은 가장 직접적인 방식입니다.** 이미 작은 범위의 사용자 그룹이 있다면, 평소 사용 과정의 문제와 생각을 그룹에 보내 달라고 초대할 수 있습니다. 당신이 해야 할 일은 진지하게 답하고, 기록하고, 정기적으로 정리하는 것입니다. 그룹 안에서 변명하거나 방어하는 것이 아닙니다. 이 작은 집단 안에 솔직히 말할 수 있는 분위기를 만들수록, 뒤에서 수집하는 피드백은 더 가치 있어집니다.
+
+설문은 **한 번에 비교적 많은 구조화 정보를 수집해야 할 때** 적합합니다. 예를 들어 버전 하나를 반복한 뒤, 몇 가지 구체적인 기능에 대해 모두가 어떻게 느끼는지 알고 싶을 때입니다. 작성률을 높이고 싶다면 설문은 너무 길지 않는 것이 좋고, 질문은 최대한 구체적이어야 합니다. 예를 들어 이 기간에 가장 자주 사용한 기능은 무엇인가, 어느 단계에서 가장 많이 막혔는가를 묻습니다. 앱에 대한 전반적인 느낌은 어떠냐고 막연히 묻는 것보다 낫습니다.
+
+사용 후 팝업도 흔히 쓰는 방식입니다. 예를 들어 사용자가 작업 하나를 완료한 뒤, 매우 짧은 점수와 제안 입력 상자로 이번 경험이 순조로웠는지 묻는 것입니다. 때로는 간단한 숫자 점수 하나만으로도 특정 흐름에 뚜렷한 문제가 있는지 판단하는 데 충분합니다.
+
+일대일 인터뷰는 비용이 높지만, 보상도 자주 더 큽니다. **서로 다른 유형의 사용자 몇 명을 골라 20분에서 40분 정도 약속을 잡고**, 평소 사용 습관을 자세히 이야기해 보세요. 그들이 조작하면서 무엇을 보고, 무엇을 느꼈는지 말하게 합니다. 어떤 창업자는 사용자 제안을 듣기 위해 매일 10회가 넘는 미팅을 잡고 사용자와 대화했다고 합니다. 시간을 들여 사용자 요구를 이해하는 것은 언제나 나쁜 일이 아닙니다.
+
+### 뒤섞인 피드백에서 세 종류의 정보를 뽑아내기
+
+사용자 피드백은 보통 뒤섞여 있어 한눈에 보기 어렵습니다. 그것들을 세 종류로 나누어 볼 수 있습니다. **버그, 경험 문제, 신규 요구**입니다.
+
+**버그는 원래 어떤 동작이 일어난다고 말했지만 어떤 상황에서는 전혀 일어나지 않거나, 잘못된 동작이 일어나는 것**입니다. 예를 들어 업로드 실패, 강제 종료, 버튼 무응답, 결과가 명백히 틀림 같은 것들입니다. 이런 문제에 대해 해야 할 일은 최대한 빨리 재현하고, 수정하고, 수정 후 영향을 받은 사용자들에게 능동적으로 알려 그 문제를 진지하게 다루고 있음을 알리는 것입니다.
+
+**경험 문제는 흐름 길이, 조작 위치, 문구 표현에서 가장 매끄러운 경로를 고르지 못한 것입니다.** 예를 들어 사용자가 어떤 버튼에서 계속 망설이며, 눌렀을 때 되돌릴 수 없는 결과가 생기는지 모릅니다. 어떤 기능이 중요하지만 눈에 띄지 않는 구석에 놓여 있습니다. 일부 기본 설정이 대부분 사람의 습관과 반대라 매번 한 단계 더 조정해야 합니다. 이런 피드백은 데이터와 관찰을 결합해 판단해야 하며, 바꿀지, 어느 정도까지 바꿀지 결정해야 합니다.
+
+**신규 요구는 사용자가 원래 당신이 생각하지 못했던 기능과 장면을 제안하기 시작하는 것입니다.** 어떤 신규 요구는 진지하게 고려할 가치가 있습니다. 예를 들어 여러 내보내기 형식, 팀 협업 능력, 다른 자주 쓰는 도구와의 연동 같은 것입니다. 하지만 사용자가 무엇을 제안하든 다 따라 해야 하는 것은 아닙니다. 진짜 해야 할 일은 이 신규 요구 뒤에 공통 문제가 있는지, 당신이 원래 서비스하려던 사람 집단과 핵심 작업에 일치하는지 구분하는 것입니다. 그렇지 않으면 흩어진 요구에 여러 방향으로 끌려 다니다가, 결국 무엇이든 하려 하지만 아무것도 제대로 하지 못하는 제품이 되기 쉽습니다.
+
+습관 하나를 만들 수 있습니다. 모든 피드백에 라벨을 붙이고 그것이 버그인지, 경험 문제인지, 신규 요구인지 표시합니다. 정기적으로 이 라벨들을 모아 어느 종류의 문제가 어떤 기능이나 흐름에 집중되어 있는지 봅니다. 그러면 더 이상 수동적으로 땜질만 하는 것이 아니라, 고빈도 문제를 중심으로 의식적으로 반복 개선할 수 있습니다.
+
+### 세 가지 간단한 지표로 계속 투자할지 판단하기
+
+자원이 제한된 상황에서는 이 앱에 장기적으로 계속 투자할 가치가 있는지 판단하기 위해 간단하지만 효과적인 지표도 필요합니다.
+
+**첫 번째는 리텐션입니다.** 리텐션은 어느 하루에 몇 명이 열었는지를 보는 것이 아니라, **일정 기간 동안 얼마나 많은 사용자가 계속 사용하고 있는지**를 보는 것입니다. 거칠게라도 통계낼 수 있습니다. 예를 들어 다운로드 후 일주일 안에 적어도 한 번 사용한 사람이 얼마나 되는지, 한 달 안에 다시 돌아온 사람이 얼마나 되는지입니다. 대부분의 사용자가 한두 번 쓰고 다시 돌아오지 않는다면, 앱이 초기에 충분한 가치를 보여 주지 못했거나 사용 문턱이 너무 높다는 뜻입니다.
+
+**두 번째는 재방문 빈도입니다.** 당신의 앱을 삭제하지 않은 사람들은 도대체 얼마나 자주 돌아오는가. 매일 쓸 수 있는 도구와 분기마다 한 번 떠올리는 앱은 제품 포지셔닝이 다르며, 서로 다른 잣대로 측정해야 합니다. 하지만 어느 쪽이든 합리적인 사용 리듬 기대치를 제시할 수 있어야 하며, 실제 데이터와 비교해 큰 차이가 있는지 보아야 합니다. 빈도가 기대보다 높다면 가치가 예상보다 클 수 있습니다. 빈도가 기대보다 훨씬 낮다면 장면을 정확히 잡지 못했거나, 사용 경험의 어떤 부분이 사용자를 피곤하게 만드는지 돌아봐야 합니다.
+
+**세 번째는 추천 의향입니다.** 누군가 당신의 앱을 다른 사람에게 능동적으로 추천하려 하는가. 이 일은 몇 가지 방식으로 관찰할 수 있습니다. 예를 들어 사용자가 특히 순조로운 작업 하나를 완료한 뒤 자연스러운 공유 입구를 제공하고, 실제로 얼마나 많은 사람이 사용하는지 봅니다. 그룹 안에서 누군가 자발적으로 당신의 제품을 추천하는지 봅니다. 또는 작은 규모의 사용자 인터뷰에서, 주변 사람이 비슷한 문제를 만난다면 이 도구를 추천하겠는지 물어봅니다. 추천 의향은 보통 단순 만족도 점수보다 문제를 더 잘 설명합니다. 추천은 개인 신용을 걸고 하는 행동이기 때문입니다. 사용자는 당신이 정말 큰 도움을 주었다고 느낄 때만 자신의 친구에게 앱을 소개하려 합니다.
+
+이 세 지표를 앞서 말한 사용자 피드백과 함께 보면, 앱이 현재 어떤 상태에 있는지 대략 판단할 수 있습니다. 기능이 아직 완전하지 않아도 특정 장면에서 반복해서 사용하며 남아 있는 사람들이 있다면, 그런 앱은 계속 투자하고 다듬을 가치가 있습니다. 반대로 많은 버그를 고치고 새 기능도 꽤 쌓았는데 리텐션과 재방문이 계속 올라가지 않고, 능동적으로 추천하는 사람도 거의 없다면, 범위를 줄이고 처음의 핵심 장면으로 돌아가야 하는지, 심지어 방향을 바꿔야 하는지 차분히 생각해야 합니다.
+
+# 4. 어느 단계에서, 어떤 방식으로 AI를 합리적으로 사용해 가치를 키울 수 있는가?
+
+앱을 진지하게 만들기 시작하면 곧 보편적인 유혹을 만나게 됩니다. AI를 조금 더 넣을 수 없을까. 이 유혹이 강한 이유는 매일 온갖 홍보를 보기 때문입니다. AI가 어느 업계를 강화한다, AI가 어느 프로세스를 완전히 재구성한다, AI가 모든 것을 한 번에 처리해 준다는 식입니다. 시간이 지나면 원래 소박했던 문제를 과장된 구호로 바꾸고, 기술 스택에 모델 호출을 쌓아 계정 비용이 점점 새어 나가는 모습을 보기 쉽습니다.
+
+이 튜토리얼이 AI 네이티브 앱을 개발하는 법을 가르친다는 점에서 이 주제를 말하는 것은 자기 밥그릇을 스스로 깨는 것처럼 보일 수도 있습니다. 하지만 작은 앱이나 이제 막 시작한 제품에서 **가장 위험한 것은 AI를 쓰지 않는 것이 아니라, AI를 위한 AI를 하는 것**입니다. 당신은 먼저 단순하지만 믿을 만한 도구를 만들 수 있는데, 여러 새로운 능력에 끌려 똑똑해 보이는 기능을 계속 추가하고, 결국 원래 구현 가능했던 방향을 비싸고 복잡하게 만들며, 뚜렷한 가치 상승도 얻지 못할 수 있습니다. 이 장의 핵심 문제는 명확히 설명하는 것입니다. 어떤 단계에서, 어떤 고리에, 어떤 방식으로 AI가 진짜로 앱의 가치를 키울 수 있는가.
+
+## 4.1 AI를 위한 AI를 하지 말기
+
+자신이 어느새 AI를 위한 AI를 하고 있는지 판단하는 실용적인 방법이 있습니다. 어떤 AI 기능을 넣을지 고민할 때마다, 먼저 자신에게 두 질문을 진지하게 답하도록 강제하는 것입니다.
+
+**첫 번째 질문은: AI가 없어도 이 앱은 성립하는가**입니다. 즉 모든 AI 능력을 잠시 지워 버렸을 때, 당신이 하는 이 일이 그 자체로 가치 있는 일인지, 사용자가 현실 요구를 가지고 있는지, 매일, 매주, 매월 이 일에 실제 시간을 들일 의향이 있는지 보는 것입니다.
+
+이 말은 지금의 흐름과 조금 반대로 들릴 수 있습니다. 거의 모든 제품 소개가 AI를 매우 눈에 띄는 위치에 놓고, AI가 없으면 현대적인 도구가 아닌 것처럼 보이기 때문입니다. 하지만 AI가 없을 때 당신의 앱이 완전히 서지 못한다면, 많은 경우 그것은 기술이 충분히 앞서 있지 않다는 뜻이 아닙니다. 더 깊은 문제를 뜻합니다. 당신이 붙잡은 요구가 애초에 별로 아프지도 가렵지도 않거나, 심지어 실제로 존재하지 않을 수 있다는 것입니다.
+
+사람들이 할 일을 정리하도록 돕는 도구를 만든다고 상상해 봅시다. 당신의 주요 차별점이 할 일 목록에 모델이 생성한 몇 가지 안내를 붙이는 것이라면, 예를 들어 자동 제목 생성, 자동 분류, 설명 자동 보완 같은 것이라면 어떨까요. 하지만 사용자가 원래 할 일을 적을 때 제목을 붙이는 것이 전혀 고통스럽지 않고, 그저 빨리 일을 적고 싶어 할 뿐이라면, 이런 똑똑한 능력이 아무리 화려해도 지속적인 가치를 만들기 어렵습니다. 반대로 한 걸음 물러나, AI가 없을 때 이 앱의 가장 소박한 가치는 무엇인지 분명히 물어보면 더 단단한 방향을 발견할 수 있습니다. 여러 채널에 흩어진 작업을 하나로 모아 주고, 매일 실제로 끝낼 수 있는 일이 얼마나 되는지 보게 하며, 일정이 끝나기 전에 위험을 보게 해서 덜어내고 선택하도록 돕는 것입니다. 이런 기본 능력을 단단히 만드는 것이, 처음부터 할 일에 온갖 지능형 태그를 붙이는 것보다 훨씬 중요할 때가 많습니다.
+
+**두 번째 질문은: AI를 사용한 뒤 구체적으로 무엇이 향상되었는가**입니다. 여기서는 효율 향상, 경험 재구성, 지능 업그레이드 같은 넓은 요약은 받아들이지 않습니다. 사용자 자신도 분명히 체감할 수 있는 한두 가지 차원으로 내려와야 합니다.
+
+스스로 이렇게 캐물을 수 있습니다.
+
+- 작업 완료 속도가 뚜렷하게 올라갔는가. 예를 들어 원래는 한 페이지 문안을 처음부터 직접 써야 했는데, 이제는 5분 동안 검토하고 고치기만 하면 되는가.
+- 결과 품질이 분명히 올라갔는가. 예를 들어 사용자가 같은 시간 안에 더 구조적이고, 더 전문적이며, 목표 독자에게 더 맞는 내용을 만들 수 있는가.
+- 사용 과정이 더 매끄럽거나 더 가벼워졌는가. 예를 들어 매우 지루한 폼 흐름을 더 대화 같은 문답으로 바꾸었는가.
+- 실제 비용이 줄었는가. 예를 들어 외주 횟수, 인공 고객지원 시간, 교육 주기, 의사결정 시간을 줄였는가.
+
+머릿속의 답이 아직 **느낌상** 더 편할 것 같다거나, 더 멋져 보인다는 수준에 머문다면, 십중팔구 그 AI 기능은 아직 가장 중요한 작용점을 찾지 못했다는 뜻입니다.
+
+이 두 질문에는 사실 분명한 순서가 있습니다. 먼저 AI가 없어도 이 앱이 말이 되는지 보장하고, 그 기초 위에서 AI를 더했을 때 구체적으로 무엇이 좋은지 묻는 것입니다.
+
+## 4.2 AI가 어떤 역할을 맡는지 생각하기
+
+AI가 없어도 앱이 성립하고, 명확한 향상 지점도 찾았다면, 다음 단계에서는 더 구체적으로 생각해야 합니다. **당신의 앱에서 AI는 도대체 무엇을 하는가**입니다. 많은 제품은 이 단계에서 실수합니다. AI를 구체적인 분업을 가진 역할이 아니라 추상적인 에너지처럼 다루기 때문입니다. 결과적으로 기능은 많이 쌓이지만 각 부분의 작용은 흐릿하고, 사용자는 곳곳에 지능이 묻어 있는 것 같다고 느낄 뿐 어디가 진짜로 AI 없이는 안 되는지 말하지 못합니다.
+
+더 명확한 사고 방식은 AI를 몇 가지 다른 부품으로 보는 것입니다. **AI는 두뇌가 될 수도 있고, 눈이 될 수도 있고, 손이 될 수도 있습니다**. 제품 목표에 따라 AI가 그중 어떤 부분을 담당하는지 결정해야 합니다. 가능하다면 처음에는 한두 가지 역할만 골라 잘 만드는 것이 좋습니다. 한꺼번에 모두 집어넣지 마세요.
+
+
+
+**AI가 두뇌 역할을 할 때는 주로 문자 내용을 이해하고 생성하거나, 복잡한 정보 사이에서 추론을 담당합니다.** 예를 들어 회의록 도우미를 만든다면, 긴 녹음에서 진짜 핵심 토론 지점을 잡아낼 수 있어야 합니다. 단순히 시간 순서대로 나열하는 것이 아닙니다. 학습 앱을 만든다면, 사용자의 답을 바탕으로 그가 개념을 이해하지 못한 것인지, 아니면 단지 부주의하게 단계를 잘못 쓴 것인지 판단하고 서로 다른 피드백을 제공할 수 있어야 합니다. 이런 장면에서 AI의 가치는 사용자가 한 말을 읽고, 사용자가 제공한 자료를 이해한 뒤, 구조와 논리를 가진 출력을 생성할 수 있다는 데 있습니다. 당신이 해야 할 일은 사용자의 문제를 분명히 묻고, 컨텍스트를 충분히 정확하게 먹여 이 두뇌가 판단할 만큼 충분한 정보를 갖게 하는 것입니다.
+
+**AI가 눈 역할을 할 때는 이미지, 영상 같은 비텍스트 내용을 처리하는 데 초점이 있습니다.** 이런 것들을 기계가 이해할 수 있는 설명으로 바꾸고, 다시 그 설명을 바탕으로 더 행동하는 것입니다. 예를 들어 종이 문서를 정리하는 도구는 사진 촬영 인식을 통해 영수증, 계약서, 포장 설명서 더미를 검색 가능한 글자로 바꿀 수 있습니다. 그림 학습 앱은 사용자가 그린 스케치를 이해하고 구도와 선의 문제를 지적할 수 있습니다. 홈 정리 제안 도구는 사용자가 올린 사진을 통해 현재 방의 배치와 물건 분포를 식별하고, 실행 가능한 간단한 개선 방안을 줄 수 있습니다. 여기서 AI의 핵심은 분석할 줄 아는 눈처럼 작동해, 앱이 더 이상 키보드로 입력한 글자만 처리하는 것이 아니라 사용자의 생활 속 실제 사물 세계에 닿기 시작하게 한다는 점입니다.
+
+**AI가 손 역할을 할 때는, 단지 제안이나 문자 결과를 내는 것이 아니라 구체적인 일련의 동작을 실행하기 시작한다는 뜻**입니다. 예를 들어 어떤 자동화 플랫폼은 여러 단계를 하나의 워크플로로 엮게 합니다. 이메일에서 첨부파일을 읽고, 내용을 요점으로 요약하고, 그룹에 보내고, 원문을 클라우드 드라이브에 저장하고, 마지막으로 작업 관리 도구에 후속 작업을 자동 생성하는 것입니다. 여기서 AI의 역할은 복잡한 흐름에서 컨텍스트에 따라 다음에 무엇을 해야 할지 동적으로 결정하도록 돕는 것입니다. 예를 들어 어떤 이메일이 불만인지 식별하고, 어떤 폼이 완전히 작성되었는지 판단한 뒤, 그에 따라 서로 다른 후속 동작을 트리거합니다.
+
+위의 단순한 설명 외에도 실제 앱에서 AI가 맡는 역할은 더 구체적이고 다양할 때가 많습니다. 예를 들면 다음과 같습니다.
+
+텍스트 처리에서는 번역, 요약, 질의응답, 이어 쓰기, 감정 분석을 할 수 있습니다. 예를 들어 고객지원 시스템에서 사용자 문의를 자동 분류하거나, 법률 문서 도우미에서 계약 조항을 추출하거나, 교육 앱에서 작문을 첨삭하는 것입니다.
+
+- 기술 기반은 주로 딥러닝의 **대형 언어 모델(LLM)**입니다. 방대한 말뭉치에서 언어 규칙과 세계 지식을 학습해, 긴 글과 여러 차례 대화의 컨텍스트를 "이해"할 수 있고, 일관되고 스타일이 맞는 내용을 "작성"할 수도 있습니다.
+- "이해" 측면에서 LLM은 사용자 의도를 식별하고, 핵심 정보를 추출하며, 감정 경향을 판단할 수 있습니다. "생성" 측면에서는 자동 요약 작성, 질문 답변, 이어 쓰기와 개작, 다국어 번역에 사용되어, 사람이 읽고 요약하고 작성해야 했던 많은 일을 자동화하거나 반자동화합니다.
+- **온라인 고객지원 봇**을 예로 들면, 시스템은 먼저 사용자의 한 문장을 바탕으로 문의, 불만, 애프터서비스 중 어디에 속하는지 대략 판단하고, 말 속에서 주문 번호, 시간, 상품명 같은 핵심 정보를 식별합니다. 그다음 LLM이 컨텍스트와 기업 지식베이스를 결합해 자연스럽고 완전한 답변을 생성합니다. 이는 인력 부담을 줄이고, 피크 시간에도 안정적인 서비스 품질을 유지하게 합니다.
+
+이미지 처리에서는 인식, 분류, 생성, 복원, 향상을 할 수 있습니다. 예를 들어 의료 영상에서 병변 위치를 표시하거나, 이커머스 플랫폼에서 자동으로 배경을 제거하고 바꾸거나, 디자인 도구에서 텍스트 설명에 따라 그림을 생성하는 것입니다.
+
+- 이미지 이해는 보통 **합성곱 신경망(CNN)** 같은 시각 딥러닝 모델에 의존합니다. 방대한 이미지에서 가장자리, 질감, 구조 같은 특징을 학습해, 객체 탐지, 이미지 분할, 세밀한 분류(예: 서로 다른 병변, 서로 다른 상품 종류 구분)에 사용합니다.
+- 이미지 생성과 복원은 **확산 모델, GAN 같은 생성 모델**에 의존합니다. 텍스트 설명이나 참고 이미지를 바탕으로 완전히 새로운 이미지를 만들고, 흐릿하거나 결손되었거나 저해상도인 이미지를 복원하고 초해상도로 향상할 수 있습니다.
+- 많은 시스템은 LLM도 함께 결합합니다. 먼저 자연어로 사용자의 텍스트 설명을 이해하고, 다시 시각 모델에 적합한 "프롬프트", 스타일 태그, 구도 제약을 자동 생성합니다. 이를 통해 "당신이 원하는 것을 알아듣는 것"에서 "당신이 원하는 것을 그리는 것"까지 구현합니다.
+- 이커머스 플랫폼의 **"스마트 대표 이미지 생성"**을 예로 들면, 시스템은 먼저 탐지와 분할 모델로 상품을 원본 이미지에서 정교하게 잘라 냅니다. 그런 다음 LLM이 판매자가 입력한 문구(예: "미니멀 북유럽풍 거실 장면, 부드러운 자연광")를 해석해 구체적인 장면, 색조, 스타일 매개변수로 바꿉니다. 마지막으로 확산 모델이 어울리는 배경과 빛 효과를 생성하고, 구도가 좋지 않거나 스타일이 맞지 않는 결과를 자동으로 걸러, 바로 상품 등록에 사용할 수 있는 대표 이미지를 출력합니다.
+
+오디오와 비디오 처리에서는 오디오와 영상의 생성, 전사, 노이즈 제거, 편집, 자막 제작을 할 수 있습니다. 예를 들어 팟캐스트 도구에서 오프닝과 엔딩 내레이션을 자동 생성하고, 영상 플랫폼에서 스크립트에 따라 해설 영상을 자동 합성하며, 회의 소프트웨어에서 대화를 실시간 전사하고 번역해 다국어 자막과 녹화 다시보기를 생성하는 것입니다.
+
+- "이해" 측면에서 시스템은 **음성 인식 모델**로 음성을 글자로 바꾸고, 동시에 화자, 언어, 말 속도, 대략적인 감정을 분석합니다. 시각 모델로는 영상 화면 속 장면, 인물, 핵심 물체를 이해합니다.
+- "생성" 측면에서는 LLM을 핵심으로 삼아 스크립트, 회의 내용, 사용자 지시를 이해하고, 분해하고, 고쳐 씁니다. 그다음 **음성 합성(TTS)**을 구동해 자연스러운 음성 해설을 생성하고, 영상 생성과 편집 모델을 구동해 화면을 자동 합성하거나 편집하고, 배경을 교체하고, 컷과 자막을 삽입합니다. 오디오 측의 생성 모델은 배경음악과 환경음을 자동 생성할 수도 있으며, 딥러닝 기반 노이즈 제거와 음질 향상을 결합해 전체 청감을 높입니다.
+- **"텍스트로 짧은 영상 생성"** 제품을 예로 들면, 사용자는 한 단락의 문안만 입력하면 됩니다. 시스템은 먼저 LLM으로 글을 자연스러운 여러 단락과 화면으로 나누고, 구어 해설문과 간단한 스토리보드 설명을 생성합니다. 그런 다음 TTS 모델이 더빙을 합성하고, 영상 템플릿과 생성 모델이 스토리보드에 따라 화면을 선택하거나 생성하며, 시간축에서 자막과 음성을 자동으로 맞춥니다. 마지막으로 바로 게시할 수 있는 짧은 영상을 한 번에 내보냅니다.
+
+음성 상호작용에서는 인식, 합성, 감정 감지, 대화 관리를 할 수 있습니다. 예를 들어 스마트 스피커에서 사용자 지시를 이해하고, 음성 내비게이션에서 경로를 읽어 주며, 언어 학습 앱에서 발음을 교정하는 것입니다.
+
+- 프론트엔드는 딥러닝 **음성 인식 모델**로 사용자의 음성을 글자로 바꾸고, 억양, 음량, 말 속도 같은 특징을 추출해 감정과 상태 판단에 단서를 제공합니다.
+- 백엔드는 **음성 합성(TTS)**으로 이 문자 답변을 자연스럽고 매끄러운 음성 출력으로 바꿉니다. 감정 인식 모델은 사용자의 현재 말 방식에 따라 답변의 어조와 속도를 조정해 상호작용이 실제 대화에 더 가깝게 느껴지도록 합니다.
+- **스마트 스피커**를 예로 들면, 사용자가 "오늘 좀 피곤해, 편안한 음악 좀 틀어 줘"라고 말할 때, 시스템은 먼저 음성 인식으로 글자로 바꾸고, 다시 LLM이 이전 재생 기록을 결합해 사용자가 선호하는 "편안한" 스타일을 이해하여 더 부드러운 재생 목록을 자동으로 고릅니다. 감정 인식이 사용자가 피곤한 상태라고 판단하면, TTS는 답변을 합성할 때 말 속도를 낮추고 억양을 부드럽게 하여, 전체 교류 과정이 "알아듣는" 동시에 "듣기 편한" 느낌이 되도록 합니다.
+
+위 내용은 AI가 몇 가지 주요 방향에서 어떻게 적용되고 어떤 기술을 쓰는지 간단히 소개한 것일 뿐입니다. 실제 비즈니스 장면에 들어가면, 여러 최신 AI API를 도입해 서로 다른 작업에서 더 전면적인 테스트를 해야 하는 경우가 많습니다. 또한 현재 AI의 능력이 도대체 얼마나 강한지, 어떤 문제를 해결할 수 있는지, 어떤 상황에서 쉽게 틀리는지, 그 경계가 어디인지 점차 파악해야 합니다. 이를 인식해야만 기능과 흐름을 합리적으로 설계할 수 있고, 능력을 잘못 판단해 위험을 묻어 두지 않을 수 있습니다.
+
+다음으로는 이 점을 중심으로 다음 절에서 더 체계적으로 논의합니다. AI의 능력과 경계를 어떻게 이해할 것인지, 실제 제품을 만들 때 무엇을 고려해야 하는지입니다.
+
+## 4.3 AI 능력과 경계에 익숙해지기
+
+실제로 AI를 앱에 넣기 시작하면 곧 한 가지 현실을 발견하게 됩니다. 홍보에서 말하는 만능성과 구체적인 기능에서 만나는 제약 사이에는 때때로 상당한 차이가 있습니다. 과도하게 약속했다가 결과가 빗나가는 일을 피하려면, **현재 AI 능력의 몇 가지 주요 방향에 대한 기본 인식을 갖고, 각자의 경계가 어디인지 분명히 해야 합니다. 많은 테스트를 통해 나쁜 사례를 얻고 반성하며, 사용 중 AI가 매우 높은 확률로 실수할 상황을 피해야 합니다. 또는 오류에 경고 설명을 붙여야 합니다.**
+
+현재 모델은 많은 장면에서 여전히 지어내는 문제가 있습니다. 특히 자유롭게 발휘하게 하거나 충분히 믿을 만한 참고 자료를 주지 않을 때 그렇습니다. 때로는 매우 자신감 있어 보이지만 완전히 틀린 답을 내고, 존재하지 않는 파일, 데이터, 경험을 만들어 내기도 합니다. 따라서 결과가 엄중한 후과와 관련된 장면, 예를 들어 재무 보고서, 법률 문서, 의료 조언에서는 설계 안에 반드시 사람이 교정하거나 여러 겹으로 검사하는 단계를 넣어야 합니다. 모델의 출력을 자동 실행 가능한 지시로 직접 취급하면 안 됩니다.
+
+동시에 개인정보와 데이터 보안도 반드시 직시해야 합니다. 어떤 데이터를 모델에 직접 보낼 수 있고, 어떤 데이터는 익명화해야 하며, 어떤 데이터는 아예 제3자 시스템에 나타나면 안 되는지 매우 분명히 알아야 합니다. 사용자가 업로드한 계약서, 진료 기록, 개인 신원 정보 같은 민감한 내용에 대해서는 인터페이스와 약관에서 처리 방식을 명확히 설명해야 합니다. 가능하다면 이런 장면을 위해 더 안전하고 통제 가능한 모델 배포 방식을 따로 선택해야 합니다.
+
+더 구체적으로, 지능형 에이전트 Agent와 관련된 예시를 빌려 AI 능력의 경계를 진짜로 이해한다는 것이 무엇인지 설명해 보겠습니다. 주의할 점은, 여기서 Agent를 처음부터 구현하는 법을 가르치려는 것이 아니며, 지금 어떤 특정 아키텍처를 좇으라고 말하는 것도 아닙니다. 이 예시를 통해 한 가지 사고 방식을 보려는 것입니다. 똑같이 Agent를 논의하더라도, 어떤 사람은 그것을 새 용어로만 여기고, 어떤 사람은 이 주제를 빌려 작업을 아주 분명히 쪼개고 경계를 아주 분명히 그릴 수 있습니다.
+
+오랫동안 현장에서 AI 앱을 만들어 온 저자 Barret Li Jing은 Agent를 잘 만드는 법과 AI를 활용해야 하는지에 관해 제가 매우 동의하는 요약을 제시한 적이 있습니다. 그것은 성숙한 이해 방식을 잘 보여 줍니다. 먼저 문제를 쪼개고, 그다음 AI가 쓰일 자리를 이야기하는 것입니다.
+
+> Agent에는 두 가지 변수가 있습니다. 하나는 작업의 방향을 제어하는 workflow, 즉 워크플로이고, 다른 하나는 내용 생성을 제어하는 context, 즉 컨텍스트입니다.
+>
+> 1) workflow와 context의 확실성이 모두 높다면, 이런 작업은 자동화되기 쉽습니다. 전통적인 RPA와 비슷합니다. 예를 들어 청구서 처리, 폼 작성 작업을 처리할 때 AI는 더 많이 접착제 역할을 하며, 발휘 공간은 비교적 제한적입니다.
+>
+> 2) workflow는 확실하지만 context는 불확실하다면, 즉 흐름은 고정되어 있지만 입력이 다양하다면, Agent가 의미와 이해 측면에서 보완해야 합니다. 예를 들어 고객지원 질의응답, 계약 분석은 외부 검색, 지식 그래프 같은 도구로 정보의 빈틈을 메워 추론 결과가 기대에 더 부합하게 해야 합니다.
+>
+> 3) workflow는 불확실하지만 context는 확실하다면, 즉 입력은 분명하지만 갈 수 있는 길이 다양하다면, Agent가 스스로 경로를 계획해야 합니다. 예를 들어 시장 분석 보고서 생성, 개인화 추천 등이 있습니다. 대부분의 End-to-End RL Agent는 이런 작업을 잘합니다. 학습 단계에서 많은 경로 계획과 문제 풀이 사고를 익혔기 때문입니다.
+>
+> 4) workflow와 context가 모두 불확실할 때는 가장 복잡한 장면입니다. 추론도 해야 하고 탐색도 해야 합니다. 혁신 방안 설계, 부서 간 정보 수집 같은 것이 여기에 해당하며, 이런 것은 더 일반형 Agent에 가깝습니다. 실행 효과는 어떤 도구를 얼마나 풍부하게 붙여 주었는지에 달려 있고, 특히 프로그래밍 능력을 최대한 열어 주어야 합니다. 예를 들어 GitHub에서 저장소를 찾아 클론하고 코드를 수정해 문제를 해결하는 법을 배우게 하여, 사람처럼 일하게 하는 것입니다.
+>
+> 그래서 Agent를 잘 만들려면 먼저 장면을 명확히 해야 합니다. 본질적으로 자동화는 "확실성" 문제를 해결하고, 지능화는 "불확실성" 문제를 해결합니다.
+
+이 분해 방식의 가치는 "Agent를 만들겠다" 같은 흐릿한 개념을 구체적으로 판단할 수 있는 문제로 바꾸는 데 있습니다. 당신이 마주한 작업에서 확실성과 불확실성은 각각 어디에 있는가. 흐름과 정보가 모두 확실할 때는 전통적인 프로그램이면 충분합니다. 불확실성이 나타날 때만 AI의 의미 이해, 패턴 인식, 추론 계획 능력이 쓰일 자리가 생깁니다. 하지만 동시에 불확실성이 높을수록 AI가 도입하는 새로운 위험도 커집니다. 양쪽이 모두 불확실한 장면에서는 AI의 모든 단계가 빗나갈 수 있고, 그것이 어떤 선택을 할지 미리 알기 어렵습니다. 많은 팀이 두 번째 사분면(workflow 확실, context 불확실)에서 시작하는 이유도 여기에 있습니다. AI의 이해 능력을 발휘하면서도 고정된 흐름으로 위험을 통제 가능한 범위 안에 둘 수 있기 때문입니다.
+
+이 절의 처음 문제로 돌아가 봅시다. AI 능력의 경계를 진짜로 이해한다는 것은 무엇인가.
+
+먼저 서로 다른 장면이 AI에 요구하는 것이 다르다는 점을 이해해야 합니다. 앞의 workflow와 context 예시가 보여 준 것처럼, 흐름과 정보가 모두 확실할 때 AI는 사실 발휘할 공간이 별로 없고 전통 자동화로 충분합니다. 흐름은 확실하지만 정보가 불확실할 때 AI의 가치는 이해와 보완에 있습니다. 흐름이 불확실할 때에야 AI는 계획과 탐색을 해야 합니다. 이 분해 방식의 본질은 불확실성의 출처와 정도를 식별하는 것입니다. AI의 핵심 능력은 불확실성 속에서 패턴과 연관을 찾는 것입니다. 이 사고 방식은 Agent에만 적용되는 것이 아닙니다. 이미지 인식, 콘텐츠 생성, 추천 시스템 등 여러 영역에서도 똑같이 중요합니다. 예를 들어 AI 누끼 도구를 만든다면, 입력은 확실합니다(이미지 한 장). 하지만 가장자리 인식의 정확성, 복잡한 배경 처리 능력이 바로 불확실성이 있는 곳입니다.
+
+
+
+하지만 AI는 불확실성을 해결하는 동시에 새로운 불확실성도 도입합니다. 출력은 확률적이며, 잘못 이해하고, 추론이 치우치고, 환각을 만들 수 있습니다. 서로 다른 장면과 서로 다른 사용자는 이런 불확실성을 견디는 정도가 완전히 다릅니다. 그래서 다음 질문도 해야 합니다.
+
+**AI가 도입하는 새로운 불확실성을 사용자와 시스템이 감당할 수 있는가?** 예를 들어 고객지원 장면에서 AI가 사용자 의도를 잘못 이해하더라도 사용자는 곧바로 고칠 수 있습니다. 이런 불확실성은 통제 가능합니다. 하지만 자동 재무 승인이라면 AI의 오판 한 번이 심각한 결과를 일으킬 수 있고, 이런 불확실성은 받아들일 수 없습니다. 또 이미지 생성이 사용자 프로필 사진을 예쁘게 꾸미는 것이라면 결과가 마음에 들지 않을 때 다시 생성하면 되므로 시행착오 비용이 낮습니다. 하지만 건축 설계자에게 시공 도면을 생성하는 것이라면 작은 세부 오류 하나도 공사 사고를 일으킬 수 있습니다.
+
+**AI의 정확률이 이 장면의 합격선을 넘을 수 있는가? 그리고 이 합격선은 사용자가 그것을 무엇에 쓰는지에 달려 있습니다.** 똑같은 이미지 인식이라도, 사용자의 앨범을 정리하고 얼굴별로 사진을 분류하는 일이라면 정확률 80%도 받아들일 수 있습니다. 몇 장은 직접 조정하면 됩니다. 하지만 보안 감시 장면에서는 의심 인원 20%를 놓치는 것이 심각한 안전 위험입니다. 텍스트 생성도 마찬가지입니다. 소셜 미디어 문안을 돕는 것이라면 60점짜리 창의성으로 충분하고 사용자가 직접 다듬을 수 있습니다. 하지만 법률 계약 조항을 생성한다면 95점도 부족합니다. 단어 하나가 부적절해도 법적 분쟁을 일으킬 수 있기 때문입니다. 사용자와 용도에 따라 오류율에 대한 민감도는 완전히 다르므로, 당신이 서비스하는 장면의 허용 오차가 얼마나 되는지 분명히 알아야 합니다.
+
+**AI가 틀렸을 때 보완할 방법이 있는가?** workflow가 확실한 장면에서는 핵심 지점에 사람의 검토를 설정해 AI의 불확실성을 국소적으로 통제할 수 있습니다. 하지만 workflow도 불확실한 장면에서는 AI의 모든 단계가 빗나갈 수 있고, 언제 개입해야 하는지 판단하기 어렵습니다. 이때 비용과 위험은 급격히 올라갑니다. 예를 들어 이미지 복원 장면에서 AI가 오래된 사진을 충분히 사실적으로 복원하지 못하면 사용자는 한눈에 알아보고 채택하지 않을 수 있습니다. 하지만 의학 영상 보조 진단 장면에서 AI가 이상 위치를 잘못 표시하면 의사가 발견하기 어려울 수 있고, 결과는 훨씬 심각합니다.
+
+**AI의 성능을 측정하고 최적화할 방법이 있는가?** 작업 자체에 명확한 정답 기준이 없다면 AI가 잘했는지 어떻게 알 수 있을까요? 사용자 피드백이 늦게 온다면 어떻게 빠르게 반복할 수 있을까요? 측정조차 할 수 없을 때, AI의 불확실성은 블랙박스가 됩니다. 예를 들어 추천 시스템은 클릭률, 체류 시간 같은 지표로 효과를 빠르게 평가할 수 있습니다. 하지만 창의적인 광고 문안을 생성하는 일이라면 무엇이 "좋은지" 자체가 주관적이며, 광고를 집행한 뒤에야 전환율을 알 수 있을 수 있습니다. 반복 주기는 길어집니다.
+
+진짜 성숙한 판단은 "여기에 불확실성이 있으니 AI를 쓸 수 있다"가 아니라, "여기의 불확실성은 AI가 처리할 수 있고, AI가 가져오는 새로운 불확실성도 내가 관리할 수 있다"입니다. "이 기능 지점에서 AI가 어느 정도까지 도울 수 있는가, 투자할 가치가 있는가, 어떻게 투자하는 것이 비용 대비 효율이 가장 높은가." 이런 판단력을 형성해야 이후 기능을 설계하고 방안을 평가할 때 훨씬 덜 돌아가게 됩니다.
+
+# 5. 앱이 생겼다면, 어떻게 0에서 첫 번째 진짜 사용자를 찾을 수 있는가
+
+어렵게 앱 하나를 만들고 나면, 다음 난제는 첫 번째 진짜 사용자가 어떻게 나타나게 할 것인가입니다.
+
+많은 팀은 이 단계에서 착각을 합니다. 물건이 이미 만들어졌으니 이제 홍보만 하면 된다고 생각합니다. 홍보하고, 광고를 사고, 노출을 찾으면, 더 많은 사람이 보기만 해도 자연스럽게 돌아갈 것처럼 여깁니다. 하지만 시작부터 대규모 노출을 급하게 추구하면 전형적인 함정에 빠지기 쉽습니다. 귀중한 시간과 예산을 태우고, 데이터상으로는 누군가 왔다 간 것처럼 보이지만, 이 앱을 지속적으로 사용하려는 사람이 실제로 있는지는 검증하지 못하는 것입니다.
+
+이 단계에서 가장 중요한 일은 사실 하나뿐입니다. **가능한 한 작은 대가로, 실제로 이 앱을 쓰고 싶어 하는 사람이 있고, 사용 후 다시 돌아오려 한다는 것을 증명하는 것**입니다. 성장과 제품의 맥락에서 이 단계를 보통 "콜드 스타트"라고 부릅니다.
+
+콜드 스타트란 거의 모든 것이 0인 상황에서 완전히 새로운 제품을 실제로 굴러가게 만드는 단계입니다. 이때 당신에게는 사용자 기반도 없고, 입소문도 없고, 검색량과 브랜드 인지도도 없으며, 모든 지표가 거의 0에 머물러 있습니다. 이런 차갑고 조용한 환경에서 첫 번째로 진짜 사용하려는 사람들을 나타나게 하고, 그들을 둘러싸고 최초의 사용 폐쇄고리를 만들어야 합니다.
+
+이는 이미 사용자와 데이터가 있는 제품에서 최적화를 하는 것과 완전히 다른 종류의 일입니다. 간단히 보면 다음 네 단계로 추진할 수 있습니다.
+
+1. 먼저 성장은 0-1과 1-N으로 나눌 수 있음을 알고, 현재 자신이 무엇만 이해하면 되는지 안다.
+2. 진짜로 찾아야 할 대상이 누구인지 분명히 하고, 최종 사용자만 바라보지 않는다.
+3. 대상이 분명한 전제에서, 자신에게 맞는 콜드 스타트 경로 한두 가지를 고른다.
+4. 자원이 제한된 현실에서 선택하고, 힘을 가장 중요한 작은 조각에 모은다.
+
+## 5.1 먼저 두 단계를 구분하기: 0-1과 1-N
+
+사용자를 어떻게 찾을지 본격적으로 이야기하기 전에, 먼저 한 가지를 분명히 해야 합니다. **성장은 단계가 나뉩니다**. 성장과 관련된 모든 일을 한데 섞어 보면, 지금 어디에 힘을 써야 하는지 알 수 없습니다. 가장 간단하고 실용적인 구분 방식은 성장을 두 단계로 나누는 것입니다. 0-1과 1-N입니다.
+
+### 0-1: 아무도 쓰지 않는 상황에서 어떻게 콜드 스타트할 것인가
+
+이른바 0-1은 완전히 사용자가 없는 상태에서, 실제로 사용하려는 소수의 사용자가 나타나는 과정입니다. 콜드 스타트의 "콜드"는 처음에는 거의 모든 지표가 0이라는 데 있습니다. 다운로드도 없고, 검색량도 없고, 입소문도 없습니다. 당신의 앱은 이 세상에 존재하지 않는 것과 다름없습니다.
+
+이때 자연 유입과 운을 기대할 수 없습니다. 능동적으로 움직여 최초의 기반을 세워야 합니다. 구체적으로는 반드시 완료해야 할 일이 몇 가지 있습니다.
+
+**진짜로 사용하려는 작은 종자 사용자 집단을 찾습니다.** 지인 관계에서 아무나 모아 숫자를 채우는 것이 아닙니다. 이 사람들은 당신이 해결하려는 문제에 실제 요구가 있어야 합니다. 인정이나 호기심 때문에 한 번 눌러 보고 떠나는 사람이 아니어야 합니다.
+
+**초기의 사용 경험과 공급을 준비합니다.** 사용자가 들어와서 빈 화면만 보지 않게 해야 합니다. 기능이 아직 완전하지 않아도, 적어도 한 번의 핵심 조작을 완료하고 이 앱의 가치를 느낄 수 있어야 합니다.
+
+**제품이 무엇을 하고 어떤 문제를 해결하는지 간단한 말로 설명합니다.** 브랜드 보증이 없는 상황에서 사용자가 당신에게 주는 인내심은 몇 초뿐입니다. 가장 짧은 시간 안에 "이것이 나에게 어떤 쓸모가 있는가"를 이해시켜야 합니다.
+
+**첫 번째 도달 채널을 찾습니다.** 이 정보를 잠재 사용자에게 전달해야 합니다. 작은 커뮤니티일 수도 있고, 포럼 하나일 수도 있고, 친구 피드일 수도 있습니다. 핵심은 규모가 얼마나 큰지가 아니라, 진짜 필요한 사람에게 정확히 도달할 수 있는가입니다.
+
+0-1 단계에서 진짜로 고려해야 할 것은, 첫 번째 실제 요구가 있는 사람들을 들여오고, 그들이 들어와 사용하고 피드백하는 폐쇄고리를 한 번 완성하게 하는 것입니다. 이 폐쇄고리가 돌아갈 수만 있다면, 이 앱은 공중누각이 아니라 실제로 누군가 필요로 하고 쓰고 싶어 하는 것임을 증명한 것입니다.
+
+### 1-N: 이미 쓰려는 사람이 있는 기초 위에서 어떻게 규모화할 것인가
+
+반복해서 사용하려는 사용자를 천천히 쌓고 나면, 문제는 비로소 수십 명, 수백 명에서 수천 명, 수만 명, 심지어 그 이상으로 어떻게 넓힐 것인가로 바뀝니다. 이 구간이 전통적인 의미에서 사람들이 말하는 성장, 확장, 규모화입니다.
+
+1-N 단계에서는 메커니즘, 조직, 상업화, 브랜드, 팀 등 더 복잡한 전체 문제 묶음을 신경 쓰기 시작해야 합니다. 예를 들면 다음과 같습니다.
+
+**상대적으로 안정적인 사용자 획득 채널을 찾았는가.** 예산이나 시간을 얼마나 투입하면 대략 얼마나 새로운 사용자가 오는지 알고 있는가. 이때 필요한 것은 더 이상 운이 아니라 반복 가능하고 예측 가능한 성장 경로입니다.
+
+**서비스 메커니즘을 구축하기 시작했는가.** 예를 들어 고객지원, 운영 이벤트, 사용자 교육 같은 것입니다. 사용자가 많아지면 초기처럼 일대일로 모든 사람에게 손잡고 사용법을 가르칠 수 없습니다. 표준화된 서비스 체계를 세워야 합니다.
+
+**이 제품을 어떻게 돈 벌게 할 것인가.** 구독인지, 단건 결제인지, 부가 서비스인지 또는 다른 방식인지입니다. 비즈니스 모델을 처음부터 명확히 해야 하는 것은 아니지만, 1-N 단계에 들어가면 이 제품을 지속 가능하게 운영하는 방법을 진지하게 고려해야 합니다.
+
+**사용자에게 어떤 브랜드 인상을 남기고 싶은가.** 초기에는 작은 범위에서 전파했을 수 있지만, 사용자 규모가 커지면 더 많은 사람이 당신을 기억하고 신뢰하며, 자발적으로 다른 사람에게 추천하게 만드는 방법을 생각해야 합니다.
+
+**팀에 아직 어떤 능력이 부족하고, 어떤 고리는 누군가 장기적으로 지켜봐야 하는가.** 완전히 외주화할 수 없는 부분입니다. 한 사람이나 작은 팀은 0-1을 버틸 수 있지만, 1-N은 대개 더 많은 역할의 협력이 필요합니다.
+
+이 질문들은 모두 중요하지만, 0-1 단계에서부터 급하게 이것들을 고민하면 대개 공회전에 빠집니다. 이 제품을 정말 누군가 쓰고 싶어 하는지, 남아 있으려 하는지 아직 모르는 상황에서 비즈니스 모델과 브랜드 전략을 말하면, 진짜 중요한 일에서 주의가 멀어질 뿐입니다.
+
+### 왜 먼저 0-1에 집중해야 하는가?
+
+개인 개발자와 작은 팀에게 1-N보다 **진짜로 가장 신경 써야 할 것은 0-1**입니다. 이유는 간단합니다. 첫 번째 진짜 사용자도 찾지 못한다면, 이후의 모든 규모화, 상업화, 브랜드 구축 논의는 공허한 말입니다.
+
+0-1 단계는 전체 제품 생명주기에서 가장 취약하면서도 가장 중요한 순간입니다. 이 단계는 이 제품의 가치를 증명할 수 있는지, 최초의 신뢰를 세울 수 있는지, 이후 성장의 토대를 놓을 수 있는지를 결정합니다. 0-1을 실제로 통과했을 때만 1-N 문제를 고려할 자격이 생깁니다.
+
+이제 0-1 단계에 더 집중해, "도대체 누구를 찾아야 하는가"라는 문제를 분명히 말하고, 그다음 구체적인 콜드 스타트 경로를 이야기하겠습니다.
+
+## 5.2 콜드 스타트 대상: 종자 사용자, 공급자, 트래픽 제공자, 채널 제공자
+
+서로 다른 유형의 앱은 대개 몇 가지 핵심 대상을 피하기 어렵습니다. 종자 사용자, 공급자, 트래픽 제공자, 채널 제공자입니다.
+
+### 첫 번째 종류: 종자 사용자
+
+**종자 사용자는 당신이 가장 먼저 도달하는 사용자 집단입니다.** 전형적인 특징은 숫자가 많지 않지만 목표 프로필과 매우 잘 맞는다는 것입니다. 그들에게서 얻어야 할 것은 단순한 가입과 사용 데이터가 아니라, 일차적인 방향과 경험 피드백입니다.
+
+- 개인 도구형 제품을 향한다면, 종자 사용자는 어떤 문제에 장기적으로 고통을 겪는 사람들일 수 있습니다. 예를 들어 긴 글을 자주 써서 정리가 필요한 콘텐츠 창작자, 발표 자료를 자주 준비하는 직장인, 매일 많은 자료를 다루는 학생입니다.
+- 교육 앱이라면, 종자 사용자는 같은 시험을 준비 중인 소수의 수험생이거나 특정 학년대의 학부모일 수 있습니다.
+
+콜드 스타트 때는 먼저 명확한 종자 사용자 목표를 세울 수 있습니다. 예를 들어 협조할 의향이 있는 사용자 20명에서 50명을 먼저 찾고, 1-2주 동안 사용하면서 대화하는 것입니다. 핵심은 숫자가 아니라, 고밀도 교류를 통해 제품 로직을 분명히 갈아내는 것입니다.
+
+### 두 번째 종류: 공급자
+
+**일부 양면 또는 다면 플랫폼형 제품에서는** 사용자 쪽만 있어서는 충분하지 않습니다. 충분한 공급자가 없다면 사용자가 들어와도 쓸 수 있는 것을 찾지 못해 곧 떠납니다.
+
+**공급자는 콘텐츠 창작자, 강의 교사, 서비스 제공자, 판매자, 기사, 집주인** 등이 될 수 있으며, 이들이 플랫폼의 풍부함과 매력을 결정합니다.
+
+- 디자이너를 위한 소재 플랫폼을 만든다면, 먼저 일부 디자이너가 작품을 올리도록 설득해야 합니다. 작은 규모로 일부 무료 소재만 열더라도 그렇습니다. 그렇지 않으면 사용자가 들어와 몇 장의 예시 이미지만 보고 끈끈함을 형성하기 어렵습니다.
+- 온라인 예약 도구를 만든다면, 사용 의향이 있는 몇몇 상점이나 기관을 미리 연결해 두지 않으면, 일반 사용자가 들어와도 실제로 예약할 대상을 찾지 못합니다.
+
+콜드 스타트 때는 자신이 먼저 사용자 쪽을 해결하는지, 공급 쪽을 먼저 해결하는지, 아니면 양쪽을 동시에 밀어붙이는지 매우 분명히 알아야 합니다. 많은 플랫폼은 초기 단계에서 이런 선택과 균형을 겪었습니다. 이것이 정면으로 마주해야 할 구조적 문제임을 인식하기만 해도, 최종 사용자만 더 많이 끌어오려는 사람보다 이미 한 걸음 앞서 있습니다.
+
+### 세 번째 종류: 트래픽 제공자
+
+트래픽 제공자는 **짧은 시간 안에 일정 규모의 사용자 주의를 당신에게 향하게 할 수 있는 사람이나 기관**입니다. 인플루언서, 버티컬 계정, 미디어, 커뮤니티 운영자일 수도 있고, 많은 사용자를 가진 도구 플랫폼일 수도 있습니다.
+
+- 직장 도구형 제품이라면, 몇몇 커리어 발전 블로거를 설득해 콘텐츠 안에서 자연스럽게 당신의 앱을 소개하게 할 수 있습니다. 그러면 짧은 시간 안에 직장 효율 도구에 민감한 사람들을 얻을 기회가 생깁니다.
+- Xiaohongshu 창작자를 위한 주제 선정 도우미라면, 몇몇 중간 규모 블로거와 협업해 실제 사례 속에서 사용 과정을 보여 주게 할 수 있습니다. 그러면 이 창작자 집단은 자연스럽게 당신의 잠재 종자 사용자가 됩니다.
+
+콜드 스타트 단계에서 가장 큰 트래픽 제공자를 급하게 찾을 필요는 없습니다. 심지어 바로 상위권과 협업을 이야기할 필요도 없습니다. 많은 경우 규모는 중간이지만 목표 사용자와 고도로 겹치는 작은 트래픽 제공자가, 오히려 당신과 함께 맞춤형 시도를 해 볼 의향이 더 큽니다. 당신이 해야 할 일은 이런 사람이나 기관을 찾고, 당신이 무엇을 하려는지, 그들에게 어떤 이익을 가져다줄 수 있는지 상대가 이해할 수 있는 명확한 협업 제안을 내는 것입니다.
+
+### 네 번째 종류: 채널 제공자
+
+채널 제공자는 **특정 장면에서 목표 사용자에게 안정적으로 도달하도록 도와줄 수 있는 조직이나 입구**입니다. 트래픽 제공자와의 차이는, 트래픽 제공자는 일회성 주의 유입에 더 가깝고, 채널 제공자는 장기적이고 구조화된 연결 방식에 더 가깝다는 점입니다.
+
+- 학교, 교육기관, 기업, 업계 협회, 소프트웨어 서비스 제공자는 모두 대표적인 채널 제공자입니다.
+ 당신의 앱이 어떤 기관의 효율 향상, 비용 절감, 서비스 품질 향상에 실질적으로 도움이 된다면, 그들은 자신의 체계 안의 많은 사용자에게 당신의 제품을 소개할 동기가 있습니다.
+
+콜드 스타트 단계에서 대형 채널을 한 번에 따내겠다는 망상을 할 필요는 없습니다. 작은 범위의 파일럿에서 시작할 수 있습니다. 예를 들어 한두 개 반, 작은 회사 하나, 지역 커뮤니티 하나와 협업해 내부에서 일정 기간 먼저 사용하게 하고, 피드백에 따라 규모를 키울지 결정합니다.
+
+콜드 스타트 대상을 나누어 보면 직접적인 장점이 있습니다. 모든 에너지를 최종 사용자 신규 유입에 쏟고, 제품 구조 안의 다른 핵심 고리를 무시하는 일을 피할 수 있습니다. 자신의 제품 형태에 따라 간단한 역할 그림을 그리고, 각 종류의 대상이 누구인지, 현재 얼마나 있는지, 단기 목표가 각각 무엇인지 적어 보세요. 이 대상 그림이 분명해진 뒤, 구체적인 콜드 스타트 경로를 이야기할 수 있습니다.
+
+## 5.3 콜드 스타트 방법: 서로 다른 대상을 겨냥한 세 가지 주요 경로
+
+찾아야 할 사람이 누구인지 알았다면, 다음 문제는 어떤 경로로 그들을 찾아가고 서비스할 것인가입니다.
+
+실제로는 특정 경로 하나에 얽매일 필요가 없습니다. 자신의 자원 상태와 제품 특성에 따라 선택하면 됩니다. 대부분의 경우 그중 하나를 주된 흐름으로 삼고, 다른 한두 가지를 보조로 사용하게 됩니다.
+
+### 경로 1: 종자 사용자로 돌파하고, 먼저 사적 네트워크를 잘 활용하기
+
+이 경로는 주로 종자 사용자와 일부 공급자를 겨냥합니다.
+
+막 시작한 개인 개발자, 작은 팀, 심지어 스타트업 대부분에게 가장 현실적이고 비용이 낮으며 리듬을 잡기 쉬운 방법은 보통 자신이 이미 가진 사적 네트워크에서 출발하는 것입니다.
+
+사적 네트워크란 복잡한 운영 개념이 아니라, 당신이 이미 능동적으로 도달할 수 있는 사람들입니다. 예를 들어 친구 피드, 참여 중인 업계 커뮤니티, 발언권이 있는 관심사 그룹, 한동안 운영해 온 뉴스레터나 블로그 독자 등이 있습니다.
+
+이 경로에는 대략 세 가지 핵심 행동이 있습니다.
+
+1. **소수의 정밀한 사용자를 능동적으로 초대해 경험하게 하기**
+ 핵심은 숫자가 아니라 목표 프로필과의 일치도입니다. 사회 초년생의 이력서 작성을 돕는 도구를 만들고 있다면, 졸업한 지 1-2년 된 친구, 인턴십을 준비하는 후배를 우선 찾아야 합니다. 이미 10년 일한 지인이 아닙니다.
+ 초대할 때는 세 가지를 가능한 한 분명히 말합니다.
+ 1. 이것은 어떤 사람을 위해 어떤 문제를 해결하는 앱인가.
+ 2. 상대가 대략 얼마나 시간을 들여 써 보기를 바라는가.
+ 3. 그들이 제공한 피드백을 당신이 어떻게 다룰 것인가.
+2. **의식적으로 피드백을 수집하고 빠르게 최적화하기**
+ 종자 사용자의 가치는 숫자를 채우는 데 있지 않고, 제품의 사각지대를 보게 하는 데 있습니다. 일대일 대화, 작은 설문 등을 통해 어떤 장면에서 그것을 떠올리는지, 사용할 때 어디에서 막히는지, 어느 부분이 가장 유용하거나 전혀 쓸모없는지 분명히 물을 수 있습니다.
+3. **종자 사용자가 첫 콘텐츠나 사례를 만들어 내게 하기**
+ 실제 사용 흔적이 곧 콘텐츠입니다. 평가, 비교 스크린샷, 사용 이야기는 모두 이후 외부에 소개할 때의 소재가 될 수 있습니다.
+
+이 과정에서 시작부터 대규모 확산을 추구하고 싶은 충동을 특히 절제해야 합니다. 이 수십 명도 제대로 서비스하지 못했다면, 더 큰 노출로 더 많은 사람을 같은 구덩이에 밀어 넣는 것은 본질적으로 문제를 확대하는 것이지 해결하는 것이 아닙니다.
+
+### 경로 2: 콘텐츠나 혜택으로 움직이게 하고, 충분히 분명한 첫 이유를 주기
+
+이 경로는 종자 사용자와 트래픽 제공자를 함께 겨냥하는 경우가 많으며, 경쟁이 치열한 분야에서 특히 흔합니다.
+
+사용자에게 대체 선택지가 많을 때, "새로 나왔으니 한번 써 보세요"라는 말만으로는 감동시키기 어렵습니다. 상대가 첫걸음을 내딛도록 더 분명하고 더 매력적인 이유를 주어야 합니다.
+
+흔한 두 가지 진입 방식은 다음과 같습니다.
+
+1. **실질적인 혜택을 직접 미끼로 사용하기**
+ 1. 새로 출시한 강의 플랫폼은 초기에 품질 좋은 무료 강의 몇 개를 열거나, 한정 할인 자리를 제공할 수 있습니다.
+ 2. 이커머스 앱은 보조금 쿠폰, 저가 공동구매, 할인권 같은 방식으로 새 사용자가 먼저 한 번 와도 손해 보지 않는다고 느끼게 합니다.
+2. **버티컬 콘텐츠로 지속적으로 끌어들이기**
+ Douyin, Xiaohongshu, 공개 계정, 팟캐스트 같은 플랫폼에서 목표 사용자가 신경 쓰는 어떤 버티컬 주제를 중심으로, 직장 노하우, 프로그래밍 팁, 감정 관리, 요리 튜토리얼, 학습 방법 같은 가치 있는 콘텐츠를 안정적으로 내보냅니다.
+ 콘텐츠로 끌어온 첫 사람들은 반드시 곧바로 앱 사용자로 전환되지는 않습니다. 하지만 적어도 당신에게 기본 신뢰가 생겼기 때문에, 적절한 시점에 도구나 앱을 던졌을 때 더 진지하게 볼 가능성이 큽니다.
+
+콘텐츠 주도 경로를 택한다면, 이는 비교적 천천히 달아오르지만 장기 보상이 있는 길임을 받아들여야 합니다. 에너지를 계속 투입해 콘텐츠를 단단히 만들어야 하며, 시작부터 조회 수와 읽은 수에 끌려 다니지 않도록 해야 합니다. **콜드 스타트에 진짜 도움이 되는 것은 콘텐츠 안에서 공감을 찾은 작은 집단이지, 짧은 시간에 몰려왔다가 곧 흩어지는 트래픽이 아닙니다.** 혜택이든 콘텐츠 유입이든, 마지막에는 같은 문장으로 돌아갑니다. 반드시 사람을 당신의 앱 안으로 매끄럽게 이끌어, 완전한 경험 한 번을 완료하게 해야 합니다.
+
+### 경로 3: 큰 플랫폼의 힘을 빌려 기존 생태 안에서 돌파구 찾기
+
+이 경로는 주로 공급자, 트래픽 제공자, 채널 제공자를 겨냥합니다.
+
+많은 영역에서 새 앱이 완전히 스스로 생태계를 만들려면 비용이 매우 높습니다. 하지만 자신을 큰 플랫폼 위의 새 상점, 새 계정, 새 플러그인으로 먼저 여길 수 있다면, 콜드 스타트 난이도는 훨씬 낮아집니다.
+
+- 이커머스 영역에서는 새 상점이 Taobao, Pinduoduo, JD 같은 플랫폼에 입점하면 적어도 결제, 물류, 평가 시스템을 0에서 만들 필요가 없습니다. 콜드 스타트 때 자주 쓰는 방식에는 인플루언서 판매, 플랫폼 내부 홍보와 이벤트 자리, 라이브 커머스 등이 있습니다.
+- 도구형, 콘텐츠형 앱은 성숙한 플랫폼용 플러그인이나 작은 도구를 개발해, 서비스를 오픈 플랫폼의 기능 마켓에 올릴 수 있습니다. 그러면 이미 명확한 요구가 있는 사용자가 더 쉽게 당신을 찾습니다.
+
+이 길의 뒤에 있는 논리는 **큰 플랫폼이 이미 특정 장면에 사용자를 모아 두었다는 사실을 인정하고, 당신은 그 장면 안에서 당신의 제품과 맞는 작은 구석을 찾는다는 것**입니다. 힘을 빌린다고 해서 독립성을 포기하는 것은 아닙니다. 콜드 스타트 단계에서 더 현실적인 방식으로 국면을 여는 것입니다.
+
+## 5.4 자원이 제한될 때의 선택: 0-1 단계에서는 가장 중요한 작은 조각만 하기
+
+자신이 아직 0-1 단계에 있음을 확인하고, 서비스할 대상도 분명히 했으며, 콜드 스타트 경로도 대략 골랐는데, 자원이 턱없이 부족하다는 사실을 발견할 수 있습니다.
+
+여기서 자원은 돈만 뜻하지 않습니다. 시간, 에너지, 인력, 주의력, 인맥, 채널도 포함합니다. 콜드 스타트 때 처음부터 "여러 길을 함께 시도하자"고 하면 결과는 대개 이렇습니다. 매일 바쁘고, 한 일은 적지 않지만, 어느 경로도 깊게 걸어가지 못합니다. 결국 설득력 있는 결과도 얻지 못하고, 사용자를 제대로 이해하지도 못합니다.
+
+이 단계에서는 의식적으로 수축해야 합니다. 목표는 "많이 하는 것"이 아니라 "가장 중요한 작은 조각을 단단히 하는 것"입니다. 세 관점에서 자신의 행동 방식을 재구성할 수 있습니다.
+
+### 목표에서 구체적 작업으로
+
+많은 사람이 콜드 스타트 때 세우는 목표는 "먼저 시장 반응을 보자", "먼저 사용자를 키우자", "먼저 한 번 사람들을 불러 써 보게 하자"입니다. 이런 말은 너무 넓어서 매일 하는 일이 정말 목표에 가까워지고 있는지 판단하기 어렵습니다.
+
+더 실무적인 방법은 목표를 하나의 구체적인 작은 일로 조이는 것입니다. 예를 들어 앞으로 4주 동안 목표 프로필에 맞는 진짜 사용자 20명이 자신의 실제 장면에서 당신의 앱을 여러 번 완전히 사용하게 하고, 그들에게서 충분히 구체적인 피드백을 얻는 것입니다.
+
+**이른바 "세분화 사람군"은 "이런 도구를 쓸 수도 있는 아무 사람"이 아니라, 어떤 라벨을 가리키며 구체적으로 설명할 수 있는 사람들의 집단입니다.** 예를 들어 업무 보고서를 생성해 주는 도구를 만든다면, 목표는 막연한 "직장인"이 아니라 "인터넷 업계 운영 직무 1-3년 차"일 수 있습니다. 이 사람들은 몇 가지 공통점이 있습니다. 매달 실제로 보고해야 하고, 시간이 제한적이며, 내용이 조금 더 전문적으로 보이기를 바랍니다. 그들의 문제는 구체적이고 지속적입니다.
+
+**"완전한 사용 작업"도 모호해서는 안 됩니다**. 이 보고서 도구를 예로 들면, 한 번의 완전한 작업은 다음과 같을 수 있습니다. 사용자가 최근 일주일의 운영 데이터와 소재를 정리해 도구에 넣고, 초안을 생성한 뒤, 추천 구조와 요점에 따라 두세 차례 수정하고, 마지막으로 PPT나 문서로 내보내 실제 부서 회의에서 발표합니다. 사용자가 아무렇게나 몇 번 눌러 보고 대략 어떻게 생겼는지만 본 뒤 닫고 다시 열지 않는 것은 완전한 사용으로 볼 수 없습니다.
+
+구체적 피드백은 충분히 세밀하게 물어야 합니다. 예를 들어 다음과 같습니다.
+
+- 데이터를 가져올 때 이해가 안 되거나, 입구를 찾지 못하거나, 늘 잘못 누르는 단계가 있었는가.
+- 생성된 구조가 그 사용자의 회사 보고 습관과 맞는가. 예를 들어 그에게 필요한 "배경-목표-과정-결과" 형식이 있는가.
+- 어떤 페이지를 실제로 가져다 쓰고, 어떤 페이지는 매번 삭제하는가.
+- 사용 후 한 번의 보고서를 준비하는 시간이 3시간에서 1시간으로 줄었다고 뚜렷하게 느끼는가, 아니면 "조금 편해진 것 같지만 말로 설명하기는 어렵다"고 느끼는가.
+
+### 무엇이든 한 번씩 다 해 보려 하지 않기
+
+"작은 목표"를 정했다면, 다음 문제는 이 20명의 사용자를 어떻게 찾고, 그들이 실제 장면을 끝까지 걸어가게 할 것인가입니다.
+
+콜드 스타트 방법은 많습니다. 글 쓰기, 커뮤니티 만들기, 광고 집행, 인플루언서 찾기, 기관 찾기, 플랫폼에 올리기. 하지만 자원이 제한된 전제에서 당신에게 필요한 것은 방법이 몇 가지인지 아는 것이 아니라, **지금의 당신에게 어떤 방식이 가장 자연스럽고, 가장 지속하기 쉬운가**입니다.
+
+평소 긴 글 쓰기에 익숙하고, 당신의 글을 진지하게 끝까지 읽는 사람이 어느 정도 있다면, 콘텐츠에서 먼저 출발할 수 있습니다. 예를 들어 아주 구체적인 실전 기록을 씁니다. 이 도구로 실제 월간 보고서를 어떻게 준비했는지, 원본 데이터를 받는 것에서 시작해 구조를 구상하고, 초안을 생성하고, 세부를 수정하고, 실제 회의실에서 발표하는 과정까지 말입니다. 중간에 비교 스크린샷을 몇 장 넣어 도구 사용 전후의 시간, 효과, 조리 측면의 차이를 보여 줄 수 있습니다. 글 마지막에는 차가운 다운로드 링크만 두지 말고 분명히 말합니다. 당신도 운영 보고를 하는 사람이고, 나와 함께 이 도구를 다듬어 볼 의향이 있다면 저에게 연락하거나 간단한 양식을 작성해 달라. 제가 20명을 골라 일대일로 따라가 보겠다.
+
+운영 교류 그룹, 동문 직장 그룹처럼 안정적인 커뮤니티 몇 개를 갖고 있다면, 이런 "사적 네트워크"에서 시작하는 것이 더 적합합니다. 그룹에 솔직하게 말할 수 있습니다. 업무 보고서 생성을 돕는 도구를 만들고 있는데 이제 막 쓸 수 있는 정도이고 아직 거칠다. 실제로 보고 요구가 있는 사람들을 찾아 함께 써 보며 매끄럽게 만들고 싶다. 자원한 사람들 중 직무와 업무 내용을 기준으로 가장 잘 맞는 사람들을 골라 별도 작은 그룹을 만들고, 그 안에서 사용해 보고, 스크린샷을 올리고, 불평과 의견을 말하게 하며, 당신은 매일 시간을 들여 따라갑니다.
+
+어떤 버티컬 업계에 인맥이 있다면, 예를 들어 교육기관 교사 몇 명과 관계가 좋거나 중소기업의 사업 책임자를 안다면, 파일럿을 한 반이나 작은 팀 안에서 할 수 있습니다. 구체적인 방법은 명확한 시범 사용 방안을 제시하는 것입니다. 예를 들어 앞으로 한 달 동안 이 팀의 모든 주간 보고서를 당신의 도구로 생성해 보게 하고, 당신은 실시간 지원과 조정을 제공합니다. 그 대가로 그들은 매주 10분짜리 짧은 회의를 열어 가장 잘 된 부분과 가장 불편한 부분을 알려 줍니다.
+
+### 가장 핵심적인 부분만 다듬기
+
+작은 목표가 있고, 주된 경로도 정했다면, 다음에 해야 할 일은 스스로에게 이 작은 조각만 하도록 제한을 거는 것입니다.
+
+많은 팀의 콜드 스타트 단계 공통 특징은 불안입니다. 불안해지면 밖에서 새로운 행동을 찾기 쉽습니다. 짧은 영상 계정을 만들고 사용 튜토리얼 몇 개를 찍어야 하나, 작은 예산을 들여 광고를 한번 해 봐야 하나, 몇몇 미디어에 연락해 기사 하나라도 써 줄 수 있는지 봐야 하나. **각각은 문제 없어 보이지만, 합치면 매일 방향을 바꾸고 어느 길에도 깊이 들어가지 못하는 결과가 됩니다.**
+
+**아주 구체적인 단계 제약을 스스로 정할 수 있습니다. 예를 들어 앞으로 4주 동안 두 가지 일에만 집중합니다**. 첫째, 그 20명의 사용자를 중심으로 그들이 실제 장면에서 쓰는 경험을 반복해서 최적화하여, "간신히 쓸 수 있음"에서 "대체로 손에 익음"으로 바꿉니다. 둘째, 당신이 고른 주된 경로를 따라 소수의 새 사용자를 계속 찾고, 그들의 행동과 피드백을 기록해 앞선 사람들과 어떤 공통점과 차이가 있는지 봅니다.
+
+이 4주 동안 어떤 새로운 생각이나 새로운 기회를 만나든 먼저 자신에게 한 문장을 묻습니다. 이 일이 이 기간 안에 그 20명의 사용자가 더 잘 쓰도록 뚜렷하게 밀어 주는가, 또는 다음 비슷한 사용자를 더 분명히 찾게 해 주는가.
+
+이 방법의 뒤에는 콜드 스타트의 본질을 인정하는 태도가 있습니다. 손에 쥔 정보가 매우 제한되어 있어 많은 방향에서 동시에 좋은 판단을 할 수 없다는 것입니다. 열 곳에서 조금씩 하는 것보다, 하나의 구체적인 장면과 하나의 구체적인 사람 집단 안에서 반복 검증 가능한 개선을 만드는 편이 낫습니다. 예를 들어 이 운영 신입 집단에서 도구가 실제로 보고서 준비 시간을 줄였고, 그들이 요점을 더 쉽게 말하게 했다는 것을 분명히 볼 수 있습니다.
+
+당신은 **사용자 찾기 -> 사용 유도 -> 피드백 수집 -> 경험 개선 -> 사용자가 계속 쓰고 싶어 함**이라는 폐쇄고리를 통과해야 합니다. 그래야 이후 어떤 사용자를 찾아야 하는지, 어떤 말로 그들과 소통해야 하는지, 어느 단계에서 가장 문제가 생기기 쉬운지, 어떤 조정으로 그들을 다시 데려올 수 있는지 알 수 있습니다. 이 길이 매끄러워진 뒤에야 새 채널을 하나 추가하거나 새로운 협업을 시도하는 것이 의미 있습니다.
+
+# 정리
+
+가장 처음의 질문으로 돌아가 봅시다. 앱을 만들려면, 이 일은 도대체 어디에서 시작해야 믿을 만한 시작이 될까요.
+
+이 글의 모든 내용은 사실 하나의 주선을 둘러싸고 펼쳐집니다. **먼저 아이디어가 무엇인지 분명히 하고, 그것과 사용자 요구 사이의 관계를 본 뒤, 한 걸음씩 그것을 만들 수 있고, 사용될 수 있고, 다듬어질 수 있고, AI로 키울 수 있으며, 사용자를 찾을 수 있는 하나의 전체 사용 경로로 쪼개는 것**입니다.
+
+먼저 첫 장에서 우리는 아이디어 자체에서 출발했습니다. 하나의 아이디어는 더 이상 머릿속의 "느낌상 멋지다"는 말이 아니라, 반드시 명확한 한 종류의 사용자를 향하고, **어떤 구체적 장면에 뿌리내리며, 그들이 구체적 작업 하나를 완료하도록 돕고, 현 상태보다 더 나은 방법을 제시해야 합니다**. 당신은 **놀이 방식, 사용자 경로, 어떤 일을 하는가, 어떤 문제를 해결하는가**라는 네 차원에서 자신의 생각을 살피는 법을 배웠고, 아이디어와 사용자 요구 사이에 쉽게 무시되는 간극이 있음을 의식하기 시작했습니다. 자기만족의 충동을 누르고 진짜 요구와 가짜 요구를 구분하기 시작했으며, 좋은 아이디어와 나쁜 아이디어는 처음부터 운명에서 차이가 있다는 점을 인정했습니다. 그런 다음 수동적으로 영감을 기다리지 않고, 자신이 사랑하는 생활, 사람 자산, 공개 공간, 기존 제품에서 능동적으로 단서를 캐내는 법을 배웠습니다. 더 아래로는, 한 문장으로 아이디어의 본질을 요약하는 훈련을 하고, AI로 브레인스토밍하며, 흔한 방향 안에서 자신만의 사람군과 장면 차별화를 찾았습니다.
+
+이어 두 번째 장에서는 더 이상 생각에 머물지 않고 **손을 움직이는 법을 배우기 시작했습니다**. **발산과 수렴** 사이를 오가며, 더블 다이아몬드 방식으로 먼저 아이디어를 펼친 뒤, 사용자 가치, 실행 가능성, 시간 비용에 따라 **진짜 실행 가능한 길로 조이는 법**을 배웠습니다. **추상에서 구체로 내려오는 법**을 연습해, "효율을 높이는 앱을 만들고 싶다" 같은 흐릿한 바람을 층층이 최소 실행 항목으로 쪼개고, 각 단계가 오늘 손댈 수 있는 작업이 될 때까지 내렸습니다. 화이트보드나 종이를 들고 먼저 그리고 나서 만들며, 앱을 입구 페이지, 작업 페이지, 결과 페이지로 나누고, 사용자가 들어와 결과를 얻기까지의 전체 경로를 그렸습니다. 또한 더 이상 다른 사람을 참고하는 일을 단순한 숙제 베끼기로 여기지 않고, **다른 앱의 내비게이션, 폼, 결과 표시, 안내 흐름을 의식적으로 분석하고 기존 경험을 빌리는 법**을 배웠습니다. 동시에 제품을 완전히 다 만든 뒤에야 사용자에게 묻지 않고, 프로토타입과 반제품 단계에서부터 의식적으로 그리면서 묻고 만들면서 물으며, 진짜 사용자가 가능한 한 빨리 설계에 들어오게 했습니다.
+
+세 번째 장에서는 무엇이 단지 쓸 수 있는 것이고, 무엇이 쓰기 좋은 것인지 구분하기 위한 자신만의 판단 기준을 천천히 세웠습니다. **이 앱이 괜찮다고 모호하게 말하지 않고, 사용자의 시간을 절약했는지, 오류율을 낮췄는지, 커뮤니케이션 비용을 줄였는지, 인지 부담을 덜었는지 구체적으로 보기 시작했습니다**. **좋은 앱은 설명서 없이도 거의 시작할 수 있어야 한다**는 것을 알았고, 중요한 장면에서 자연스럽게 떠올라야 하며, 좋은 앱 뒤에는 진짜 이타심이 있다는 것도 이해했습니다. 실제 문제와 사용자 고통을 한계 비용의 차원까지 쪼개어, 그 뒤에서 소비되는 것이 시간인지, 돈인지, 마음의 힘인지, 위험인지 구분하기 시작했습니다. 동시에 **C 사이드와 B 사이드의 차이**를 처음 이해했습니다. 전자는 감정 가치와 전파를 더 신경 쓰고, 후자는 효율, 비용, 위험, 규정 준수를 더 신경 씁니다. 더 이상 자신이 좋다고 느끼는 것만 믿지 않고, 간단한 피드백 메커니즘을 만들고, 리텐션, 재방문, 추천이라는 세 지표로 이것을 계속 투자할 가치가 있는지 판단하며, 반복되는 사용자 피드백으로 앱을 내가 좋다고 느끼는 것에서 사용자가 좋다고 느끼는 것으로 다듬었습니다.
+
+네 번째 장에서는 시각을 순수 제품에서 AI 능력으로 확장했습니다. 먼저 **AI를 위한 AI를 하고 싶은 충동을 눌렀고**, 자신에게 두 가지를 진지하게 물었습니다. AI가 없어도 이 앱은 성립하는가. AI를 쓰면 구체적으로 무엇이 향상되는가. 텍스트, 이미지, 영상, 자동화에서 AI의 기본 능력과 경계를 익히고, 어디를 모델에 맡길 수 있고 어디에는 반드시 사람의 검토가 필요한지 알았습니다. 단지 기능 구현 차원에 머무르지 않고, 더 본질적인 지표를 바라보았습니다. 작업 완료 시간이 줄었는가, 결과 품질이 더 좋아졌는가, 사용 빈도가 올라갔는가, 사용자가 AI 기능에 따로 돈을 낼 의향이 있는가.
+
+마지막 다섯 번째 장은 모든 것을 현실 문제로 다시 끌고 왔습니다. 이미 꽤 괜찮고, 심지어 AI까지 들어간 앱이 있더라도 사용자가 없다면 그 가치는 여전히 0입니다. 먼저 **0-1과 1-N을 구분하는 법을 배웠고, 규모화, 브랜드, 조직에 관한 모든 거대한 문제를 잠시 내려놓고, 한 가지 일에 집중했습니다. 먼저 20명의 진짜 사용자가 쓰게 만들고**, 사용 후 다시 돌아오게 하는 것입니다. 더 이상 맹목적으로 그물을 넓게 던지지 않고, 세 가지 주요 흐름을 따라 콜드 스타트했습니다. 주변 커뮤니티, 동료, 친구를 활용해 종자 사용자를 천천히 쌓고, 콘텐츠와 제한된 혜택으로 첫 번째 시도 의향이 있는 사람들을 끌어오며, 기존 플랫폼과 채널의 힘을 빌려 이미 트래픽이 있는 곳에 자신의 입구를 만들었습니다. 또한 대상에 따라 콜드 스타트 전략을 쪼개기 시작했습니다. 종자 사용자, 공급자, 트래픽 제공자, 채널 제공자를 구분하고, 각자 다른 방식으로 뚫었습니다. 자원이 제한될 때는 더 이상 무엇이든 한 번씩 해 보려 하지 않고, 자신이 가장 잘하고 손에 쥔 것 중 가장 쉽게 시작할 수 있는 길을 보고, 그 길 하나를 깊고 철저하게 걸었습니다. 채널 열 개의 반제품을 한꺼번에 펼치지 않았습니다.
+
+이 내용을 합쳐 보면, 전체 방법은 신비롭지 않습니다. **믿을 만한 아이디어에서 출발하고, 그것이 실제 요구에 뿌리내렸는지 확인합니다. 그리고 그리기, 쓰기, 쪼개기로 그것을 최소 실행 가능 앱으로 수렴시키고, 진짜 사용자와 명확한 지표로 조금씩 좋은 앱으로 다듬습니다. 핵심 지점에 AI를 합리적으로 도입해 가치를 키우고, 마지막으로 제한된 자원 아래에서 적합한 콜드 스타트 방식으로 기꺼이 돈을 낼 첫 사용자들을 찾습니다**.
+
+다음 단계에서 당신이 해야 할 일은 지나친 환상을 버리고, 그중 하나를 착실히 골라 만들어 세상에 내놓는 것입니다. 실제 세계 안으로 들어가 검증을 받게 하세요. **아이디어, 방법론, AI, 성장에 관한 모든 논의는 결국 구체적인 한 사람, 구체적인 한 장면, 구체적인 한 작업 위에 떨어져야 합니다.**
+
+그렇기 때문에 처음에 아주 거칠어도 괜찮습니다. 기능이 부족하고, 흐름이 뻣뻣하고, 화면이 투박해도 괜찮습니다. 한참 밀어붙였는데 아무도 반응하지 않고, 등록이나 결제를 원하는 사람이 없어도 여전히 괜찮습니다. 이것들은 모두 과정의 상태일 뿐 최종 결론이 아닙니다. 그것들은 다음에 어떻게 수정할 수 있는지를 알려 줄 뿐입니다. 진짜 중요한 것은 진전이 있어야 한다는 점입니다. 과정 속에서 끊임없이 회고하고, 정리하고, 한계를 높이고, 기꺼이 조언해 줄 더 많은 사람을 알아가야 합니다.
+
+이 단계에서 필자는 과정을 즐기기만 하면 된다고 생각합니다. 유명한 전자 이야기 게임 "To the Moon"이 말한 것처럼요.
+
+**_"The ending isn't any more important than any of the moments leading to it."_**
+
+**_결말은 그곳에 이르기까지의 어떤 순간보다도 더 중요하지 않습니다._**
+
+
diff --git a/docs/ko-kr/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md b/docs/ko-kr/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md
index 5f86b7c..dc4b332 100644
--- a/docs/ko-kr/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md
+++ b/docs/ko-kr/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md
@@ -1,74 +1,356 @@
----
-title: 'AI 코딩 도구로 스네이크 게임 만들기'
-description: 'AI 코딩 도구를 사용해 작은 게임을 만들며 Vibe Coding 흐름을 익히는 한국어 실습입니다.'
+# 7가지 AI 코딩 도구 비교
+
+## 이 장의 가이드
+
+수많은 AI 코딩 도구 중에서 어떤 도구가 가장 나에게 잘 맞을까요? 이 장에서는 하나의 통일된 실습 과제인 “스네이크 + AI 시 쓰기” 게임 개발을 통해 Lovable, Replit, Z.ai 등 7가지 주요 Web Vibe Coding 플랫폼을 깊이 있게 가로로 비교합니다. 초보자 친화성, 코드 제어 가능성, 배포 편의성 등 여러 관점에서 비교하여, 가장 강력한 개발 보조 도구를 빠르게 고를 수 있도록 돕습니다.
+
---
-# AI 코딩 도구로 스네이크 게임 만들기
+# 1. Vibe Coding으로 스네이크 게임 만들기: 전체 실습 튜토리얼
-이 실습의 목적은 게임 개발이 아니라 AI 코딩 도구의 기본 흐름을 익히는 것입니다.
+이 글은 새로운 소프트웨어 개발 실천 방식인 “Vibe Coding(분위기식 코딩)”을 소개합니다. Vibe Coding은 인공지능을 활용해 애플리케이션 구축 과정을 가속합니다.
-## 1. 목표
+이제 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 도구를 전체 워크플로에 통합하는 방법을 배웁니다.
-- 방향키 조작
-- 먹이 생성
-- 점수 표시
-- 벽이나 자기 몸에 부딪히면 게임 오버
-- 다시 시작 버튼
+## 1. 들어가며
-## 2. 첫 요청
+이전 수업에서는 계속 z.ai의 풀스택 개발 모델을 사용해 프로그래밍 과제를 완성해 왔습니다.
-```text
-브라우저에서 실행되는 스네이크 게임을 만들어 줘.
-HTML, CSS, JavaScript를 사용하고, 초보자가 실행하기 쉽게 구성해 줘.
+하지만 우리는 생각해 본 적이 있을까요? 그 핵심은 사실 “AI Agent”입니다. 일반적인 채팅형 AI와는 다르고, 훨씬 더 지능적입니다. 단지 당신과 대화만 하는 것이 아니라 생각할 수 있고(당신이 작업을 주면 먼저 계획을 세웁니다), 주도적으로 행동할 수도 있기 때문입니다. 예를 들어 웹 검색 호출, 컴퓨터 명령 실행, 웹페이지 열기 같은 도구를 사용할 수 있습니다. 뒤에서 더 자세히 소개하겠습니다.
-필수 기능:
-- 방향키로 조작
-- 점수 표시
-- 게임 오버 화면
-- 다시 시작 버튼
-- 보기 좋은 간단한 디자인
-```
+## 1. Vibe Coding이란 무엇인가?
-## 3. 실행하기
+Vibe Coding은 AI를 활용해 애플리케이션 개발 흐름을 가속하는 새로운 소프트웨어 개발 방식입니다. 전통적인 프로그래밍의 대체물이 아니라, 더 “대화식”인 프로그래밍 모델에 가깝습니다. 이 개념은 AI 연구자 Andrej Karpathy가 제시했습니다. 이 워크플로에서 개발자는 더 이상 코드를 한 줄씩 직접 작성하는 데 중심을 두지 않고, 주로 AI Agent를 이끌어 애플리케이션을 생성하고, 최적화하고, 디버깅합니다.
-AI가 단일 HTML 파일을 만들었다면 파일을 브라우저로 열어 확인합니다. Vite 프로젝트로 만들었다면 다음 명령을 사용합니다.
+Vibe Coding의 핵심 생각은 **“코드 중심(code-first)”** 에서 **“의도 중심(intent-first)”** 으로 전환하는 것입니다. 더 이상 첫 번째 코드 줄부터 구상할 필요가 없습니다. 자연어로 원하는 결과를 설명하면 됩니다.
-```bash
-npm install
-npm run dev
-```
+전형적인 Vibe Coding 워크플로는 끊임없이 반복되는 순환입니다.
-## 4. 개선 요청
+- **목표 설명:** 먼저 한 문장이나 한 단락으로 구현하고 싶은 기능을 설명합니다. 예: “Python 백엔드가 있고 시를 생성할 수 있는 간단한 스네이크 게임을 만들어줘.”
+- **AI가 코드 생성:** AI Agent가 요구사항을 해석하고, 기본 구조, 프론트엔드 페이지, 백엔드 로직을 포함한 첫 번째 코드 버전을 생성합니다.
+- **실행하고 관찰:** 생성된 코드를 실행해 예상대로 동작하는지 확인하고, 동시에 버그나 부족한 점을 찾습니다.
+- **피드백하고 반복:** 오류가 있거나 결과가 마음에 들지 않으면 대화에서 계속 지시합니다. 예: “뱀이 너무 느리게 움직여. 속도를 더 빠르게 해줘”, 또는 “지금 `.env` 파일의 API Key가 제대로 읽히지 않아. 백엔드 코드를 고쳐줘.”
+- **위 단계를 반복:** “설명 → 생성 → 실행 → 피드백” 순환을 계속 반복해 애플리케이션이 만족스러운 상태에 도달할 때까지 개선합니다.
-한 번에 많이 바꾸지 말고 작은 요청을 순서대로 합니다.
+### Vibe Coding의 주요 장점
-```text
-게임 시작 전 대기 화면을 추가해 줘.
-스페이스바를 누르면 시작하게 해 줘.
-```
+- **진입 장벽 감소:** 프로그래밍 경험이 부족한 디자이너, 창업자, 학생 등도 자연어를 통해 애플리케이션 개발에 참여할 수 있습니다.
+- **빠른 프로토타입:** 아이디어에서 최소 기능 제품(MVP)까지 걸리는 시간이 크게 줄어듭니다.
+- **효율 향상:** 템플릿 코드처럼 반복적이고 기계적인 코딩 작업을 자동으로 처리하여, 개발자가 아키텍처 설계와 문제 추상화에 더 집중할 수 있게 합니다.
+- **실험에 유리:** 먼저 빠르게 만들어 보고 계속 개선하는 방식을 장려하므로, 새로운 아이디어와 기능을 시도하기가 더 쉽습니다.
-```text
-모바일에서도 플레이할 수 있게 화면 아래에 방향 버튼 4개를 추가해 줘.
-```
+## 2. Vibe Coding 온라인 플랫폼(Web-based)이란 무엇인가?
-```text
-최고 점수를 localStorage에 저장해 줘.
-```
+이번 실제 테스트에서 평가한 도구는 **Web-based(온라인 플랫폼)** 과 **IDE(로컬 개발 환경)** 두 종류로 나뉩니다.
-## 5. 배운 점
+둘 다 핵심은 AI가 코드를 작성하도록 돕는 것이지만, 사용 경험과 적합한 상황에는 큰 차이가 있습니다.
-이 실습에서 익혀야 할 것은 다음입니다.
+### Vibe Coding 온라인 플랫폼(Web-based)
-- 자연어 요구사항을 코드로 바꾸기
-- 실행 결과를 보고 피드백하기
-- 오류 메시지를 AI에게 전달하기
-- 기능을 작은 단위로 추가하기
+**대표 도구:** Lovable, Replit, Z.ai, v0
-## 다음으로
+이는 “짐만 들고 들어가면 되는” 호텔식 아파트와 비슷합니다.
-비슷한 방식으로 타자 게임, 퀴즈 게임, 할 일 목록 앱을 만들어 보세요.
+- **환경 설정 불필요:** Python 환경이 무엇인지, Node.js 버전이 무엇인지 신경 쓸 필요가 없고, 의존성 설치도 신경 쓰지 않아도 됩니다. 브라우저를 열고 주소를 입력하면 바로 코딩을 시작할 수 있습니다.
+- **원클릭 미리보기와 배포:** 코드가 생성되면 플랫폼은 보통 오른쪽 창에 실행 결과를 자동으로 보여줍니다. 완성되면 버튼 하나로 링크를 생성해 친구에게 공유할 수 있습니다.
+- **적합한 상황:**
+ - **아이디어 빠른 검증(MVP):** 머릿속에 아이디어가 있고, 30분 정도 써서 만들 수 있는지 보고 싶을 때.
+ - **초보자 입문:** 복잡한 환경 오류에 막혀 포기하고 싶지 않고, AI 코딩의 재미를 경험하고 싶을 때.
+ - **가벼운 애플리케이션:** 간단한 도구 웹페이지, 미니게임, 개인 소개 페이지를 만들 때.
+### AI IDE(로컬 개발 환경)
+
+**대표 도구:** Cursor, Trae, VS Code + AI 플러그인
+
+이는 “고급 인테리어가 된” 자가 주택과 비슷합니다.
+
+- **강력한 로컬 능력:** 당신의 컴퓨터에서 실행되며, 모든 로컬 파일에 직접 접근하고 컴퓨터의 연산 자원을 활용할 수 있습니다.
+- **전문 워크플로와 매끄러운 연결:** 대형 프로젝트에 적합하며, 다양한 플러그인을 자유롭게 설치하고, 로컬 데이터베이스에 연결하고, 복잡한 디버깅을 수행할 수 있습니다.
+- **적합한 상황:**
+ - **전문 프로젝트 개발:** 장기 유지보수가 필요하고 구조가 복잡한 상업 프로젝트.
+ - **깊은 맞춤화:** 코드 세부 사항을 극도로 제어해야 하거나 Git, Docker 같은 기존 로컬 워크플로와 깊게 결합해야 할 때.
+ - **데이터 프라이버시:** 코드가 완전히 로컬에 있으므로 일부 기업의 보안 규정에 더 잘 맞습니다.
+
+**정리하면:** AI 코딩을 막 시작했거나 작은 것을 빠르게 만들어 보고 싶다면 **온라인 플랫폼**이 훌륭한 출발점입니다. 전문 개발자이거나 프로젝트가 점점 복잡해진다면 **로컬 IDE**가 더 높은 상한을 제공합니다.
+
+---
+
+## 3. 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의 큰 특징 중 하나는 외부 도구를 호출할 수 있다는 점입니다. 더 이상 “텍스트 생성”에만 갇혀 있지 않습니다. 예를 들어 웹을 탐색하고, 코드를 실행하고, 데이터베이스를 조회하고, 이메일을 보낼 수 있습니다. 즉 “도구를 조율하는” 두뇌입니다.
+
+다음과 같이 비유해 이해할 수 있습니다.
+
+- **전통적인 프로그램**은 계산기와 같습니다. 숫자와 연산자를 입력하면, 버튼을 눌렀을 때만 계산을 수행합니다.
+- **AI 어시스턴트**는 인간 비서와 같습니다. “근처 식당을 찾아줘”라고 하면 검색 결과를 주고 선택지를 나열하지만, 최종 결정은 여전히 당신이 합니다.
+- **AI Agent**는 자동화된 연구팀에 더 가깝습니다. 당신은 “일본 여행 일정을 계획해줘” 같은 상위 목표만 주면 됩니다. 그러면 Agent는 작업을 분해하고, 인터넷에서 자료를 찾고, 항공권과 호텔을 예약하고(API를 통해), 일정을 정리한 뒤 최종 결과를 전달합니다. 전체 과정에서 세부 사항에 대한 당신의 개입은 거의 필요하지 않습니다.
+
+---
+
+# 2. 프롬프트 작성에 대하여
+
+## 1. 프롬프트를 한 번에 다 쓰는 것이 좋을까, 여러 단계로 나누는 것이 좋을까?
+
+많은 사람은 “완전한 풀스택 애플리케이션을 만들어줘”라는 내용을 하나의 프롬프트 안에 한 번에 다 설명하고 싶어 합니다. 실제로 현재 도구들은 이미 충분히 강력해서, 한 번에 꽤 괜찮아 보이는 결과를 내놓을 가능성도 있습니다. 하지만 전체 경험과 성공률을 보면, 작업을 작은 단계로 나누고 단계별로 반복하는 편이 대체로 더 좋습니다. “더 이상 고쳐지지 않는” 막다른 길에 빠질 가능성도 줄어듭니다.
+
+> **작은 팁:** “한 번에 완성”을 기대하기보다, 큰 목표를 실행 가능한 작은 할 일(To-do)들로 나누는 편이 좋습니다.
+> 예를 들어 “build me a Snake game”이라고 바로 말하지 말고, 다음처럼 나누세요.
+> “1. 먼저 스네이크 게임의 프론트엔드를 만들어줘”,
+> “2. 그다음 점수를 기록하는 백엔드를 구현해줘”,
+> “3. 마지막으로 프론트엔드와 백엔드를 연결해줘”.
+> 이렇게 하면 AI가 요구사항을 더 정확히 이해하고 더 신뢰할 수 있는 출력을 낼 수 있습니다.
+
+## 2. 명확할수록 좋다
+
+- Vibe Coding에서 당신이 쓰는 프롬프트는 당신이 쓰는 코드만큼 중요합니다. 프롬프트가 명확하고 구체적일수록 결과는 당신이 마음속으로 생각한 것에 더 가까워집니다.
+- 처음부터 목표와 제약 조건을 명확히 말하면 이후 반복 수정 횟수를 줄일 수 있습니다. 이는 시간을 아낄 뿐 아니라 사용량과 비용도 절약합니다.
+
+---
+
+# 3. 도구 개요(Vibe Coding / UIUX 도구)
+
+## 1. AI Agent 플랫폼
+
+| **Name** | **Platform** |
+| ------------------------------------------ | ------------ |
+| **[Lovable](https://lovable.dev/)** | Web-based |
+| **[Cursor](https://cursor.com/cn/agents)** | PC |
+| **[Z.ai](https://chat.z.ai/)** | Web-based |
+| **[Replit](https://replit.com/~)** | Web-based |
+| **[Minimax](https://agent.minimaxi.com/)** | Web-based |
+| **[Trae](https://www.trae.ai/)** | PC |
+| **[V0](https://v0.app/)** | Web-based |
+
+## 2. AI UIUX 플랫폼
+
+| **Name** | **Platform** |
+| ------------------------------------- | -------------------- |
+| **[Mastergo](https://mastergo.com/)** | Web-based |
+| **[FIgma](https://www.figma.com/)** | Web-based, PC Plugin |
+
+---
+
+# 4. 실습 튜토리얼(Vibe Coding + UI 결합)
+
+1. Vibe Coding을 진행하려는 플랫폼의 채팅창에 원하는 프로그램 설명을 입력합니다.
+ 예시:
+
+ > 프론트엔드와 백엔드가 있는 간단한 스네이크(Snake) 웹 애플리케이션을 만들어 주세요.
+ >
+ > 1. 프론트엔드
+ >
+ > - 페이지 1: 게임 페이지
+ > - 키보드로 뱀의 이동을 제어합니다.
+ > - 뱀이 먹는 것은 음식이 아니라 영어 단어입니다.
+ > - 페이지 사이드바에 수집한 단어와 개수를 표시합니다.
+ > - 게임이 끝난 뒤에도 수집한 단어는 그대로 남아 있고, 새 게임에서도 이어집니다.
+ > - 페이지 2: 시 쓰기 페이지(Make Poem)
+ > - 게임 페이지와 같은 단어 목록을 표시합니다. 데이터는 동일해야 합니다.
+ > - 현재 수집한 단어를 백엔드로 보내 시를 생성하는 버튼을 제공합니다.
+ > - 시가 생성된 뒤, 사용된 단어를 목록에서 제거하거나 개수를 줄입니다.
+ >
+ > * Game과 Make Poem 두 페이지 사이를 전환할 수 있도록 간단한 내비게이션을 추가합니다.
+ > * 수집된 단어가 두 페이지 모두에서 보이도록 보장합니다.
+ >
+ > 2. 백엔드
+ >
+ > - 수집한 단어를 받아 시를 반환하는 백엔드 API를 제공합니다.
+ > - 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이 추적하지 않게 해야 합니다.
+ - 이렇게 하면 프로젝트는 여전히 로컬에서 이 키들을 정상적으로 사용할 수 있지만, 저장소에는 유출되지 않습니다.
+
+3. 생성 결과를 확인한 뒤 오류가 있거나 수정할 부분이 있으면 채팅창에 바로 수정 요청을 입력할 수 있습니다.
+4. 페이지 디자인이 마음에 들지 않으면 Figma나 Mastergo에서 인터페이스를 다시 디자인한 뒤, 디자인 의도를 Agent에게 피드백할 수도 있습니다.
+
+- **예시**
+
+> _Word-Snake_ 라는 이름의 **두 페이지 Web 애플리케이션**을 설계해 주세요.
+>
+> - **Game 페이지:**
+> - 뱀은 키보드로 이동을 제어합니다.
+> - 뱀이 먹는 것은 일반 음식이 아니라 영어 단어입니다.
+> - 오른쪽 패널에 수집한 단어와 수량을 표시합니다.
+> - 게임 종료 후에도 단어 재고는 초기화되지 않고, 다음 라운드에서 계속 사용됩니다.
+> - **Make Poem 페이지:**
+> - 같은 공유 단어 재고를 표시합니다.
+> - 사용자가 일부 단어를 선택하고 **Generate Poem** 버튼을 클릭합니다.
+> - 이 단어들을 백엔드로 보내 DeepSeek API가 시를 생성하게 합니다.
+> - 시가 생성된 뒤, 사용된 단어를 재고에서 삭제하거나 줄입니다.
+> - **내비게이션:** 간단한 Tab 또는 상단 메뉴로 두 페이지 사이를 전환합니다.
+> - **공유 상태:** 수집된 단어가 두 페이지에서 항상 동기화되어 보이도록 보장합니다.
+
+- **결과 예시**
+
+
+
+---
+
+# 5. AI Agent 플랫폼 비교(간단한 프로젝트에 가장 좋은 조합을 고르는 법)
+
+서로 다른 Vibe Coding 플랫폼은 각기 다른 특징과 워크플로를 가지고 있습니다. 우리는 같은 “DeepSeek API가 포함된 스네이크 게임” 요구사항을 여러 플랫폼에서 실제로 테스트하고, 초보자의 관점에서 장단점을 평가했습니다. 아래는 요약입니다.
+
+## 1. 비교 기준
+
+1. **목표(Goal)**
+ DeepSeek API를 연결한 스네이크(Snake) 웹 애플리케이션을 구축합니다.
+
+2. **게임 세부 사항(Game Details)**
+ 1. 게임은 DeepSeek LLM API를 통해 시를 생성합니다.
+ 2. 뱀이 먹는 것은 영어 단어이며, 수집한 단어는 게임 종료 후에도 유지되고 새 게임에서도 계속 사용됩니다. 같은 단어를 여러 번 수집할 수 있으며 각각 개수가 계산됩니다.
+ 3. 시를 하나 생성한 뒤, 사용된 단어는 재고에서 제거됩니다.
+
+3. **필수 기능(Must-Haves)**
+ 1. 스네이크 게임을 포함한 실행 가능한 프론트엔드 페이지. 키보드 제어와 Canvas 렌더링을 포함합니다.
+ 2. 단어 수집 메커니즘. 단어가 보드에 나타나고, 뱀이 단어를 먹으면 사이드바 목록이 업데이트됩니다.
+ 3. 여러 게임 라운드 사이에서도 단어 재고를 지속적으로 유지합니다.
+ 4. DeepSeek API를 사용하는 백엔드. API Key가 없으면 먼저 가짜 시를 반환해도 됩니다.
+ 5. “시 생성” 버튼. 클릭하면 백엔드를 호출하고, 시를 표시하며, 사용 상황에 따라 단어 재고를 업데이트합니다.
+ 6. API Key를 위한 `.env` 지원과 `.gitignore`를 통한 키 유출 방지.
+
+4. **있으면 좋은 기능(Nice-to-Haves)**
+ 1. 사용자가 시 생성에 사용할 단어를 선택할 수 있습니다.
+ 2. 사용자 경험이 친절합니다. 예를 들어 사이드바에 단어 목록을 명확히 보여 주고, 시 표시 영역의 레이아웃이 합리적이어야 합니다.
+ 3. 초보자를 위해 코드에 주석을 추가하여 핵심 로직을 설명합니다.
+
+## 2. 코딩 출력 비교
+
+### 1. Lovable(Web-based)
+
+- **플랫폼 유형:** Web
+- **주요 특징과 워크플로:** Lovable은 통합과 협업 측면에서 잘 만들어져 있습니다. Supabase 데이터베이스 연결 같은 초기화 작업을 자동으로 처리하여 프로젝트 구축 과정이 매우 매끄럽습니다. 프로젝트 요구사항만 설명하면 Agent가 각종 서비스를 연결하고 기본 구조를 만들어 줍니다.
+- **적합한 사용자:** Vibe Coding을 처음 시도하는 초보자에게 Lovable은 매우 친절한 선택입니다. 여러 서비스를 함께 연결하는 복잡도를 단순화해 주므로 환경 설정이 아니라 프롬프트와 반복 개선에 집중할 수 있습니다. 높은 자동화 덕분에 실행 가능한 프로토타입을 빠르게 얻을 수 있습니다.
+- **프롬프트 과정:**
+ 
+- **스네이크 게임 결과:**
+
+
+
+- **가격:** 비교적 비싼 편이지만, 학교 이메일이 있으면 학생 인증을 통해 반값으로 사용할 수 있습니다.
+ 
+
+### 2. Cursor(IDE)
+
+- **플랫폼 유형:** 데스크톱 애플리케이션(PC)
+- **주요 특징과 워크플로:** Cursor는 AI 기능이 통합된 전용 IDE이며 Windows, macOS, Linux를 지원합니다. 코드 생성, 지능형 재작성, 코드베이스 질의 같은 기능을 개발 환경 안에 직접 넣었습니다. Web 도구와 비교하면 전통적인 로컬 개발 경험에 더 가깝습니다. 로컬 환경이기 때문에 컴퓨터마다 설정이 다르고, 때때로 환경 관련 문제가 발생할 수 있습니다. 장점은 프로젝트가 내 컴퓨터에 있으므로 추가로 다운로드하거나 실행 환경을 설정할 필요가 적고, Cursor가 많은 번거로운 단계를 처리해 준다는 점입니다.
+- **적합한 사용자:** 어느 정도 프로그래밍 기초가 있는 사용자에게 Cursor는 매우 강력하고 익숙한 환경입니다. 그러나 완전 초보자에게는 프로젝트 구조, 의존성 관리, 파일 구성 같은 개념을 스스로 이해해야 하므로 학습 곡선이 더 가파를 수 있습니다. 전통적인 코딩 흐름에 AI 어시스턴트를 추가하고 싶은 개발자에게 더 적합합니다.
+- **프롬프트 과정:**
+ 
+- **스네이크 게임 결과:**
+
+
+
+- **가격:**
+ 
+
+### 3. Z.ai(Web-based)
+
+- **플랫폼 유형:** Web
+- **주요 특징과 워크플로:** Z.ai의 사용 방식은 비교적 직접적이지만, 뚜렷한 어려움이 하나 있습니다. **생성된 코드를 수동으로 복사해 붙여 넣어야 한다**는 점입니다. 플랫폼 자체에 실시간 미리보기 창이 부족하여 코드 실행 결과를 즉시 보기 어렵습니다.
+- **적합한 사용자:** 이 플랫폼은 비교적 “직접 손을 대는” 사용 방식을 요구합니다. 자동화가 부족하다는 것은 코드와 직접 마주해야 한다는 뜻이고, AI 출력 내용을 깊이 이해하고 싶은 사람에게는 오히려 훈련이 될 수 있습니다. 하지만 잦은 복사 붙여넣기는 효율 문제와 실수 위험을 가져옵니다. 원클릭 경험을 원하는 사람보다는 “AI가 원시적으로 출력한 코드”를 보고 싶은 학생에게 더 적합합니다.
+- **프롬프트 과정:**
+ 
+- **스네이크 게임 결과:**
+
+
+
+- **가격:**
+ 
+
+### 4. Replit(Web-based)
+
+- **플랫폼 유형:** Web
+- **주요 특징과 워크플로:** Replit은 통합 온라인 개발 및 배포 환경입니다. 브라우저 안에서 코드를 작성하고, 프로그램을 실행하고, 온라인 접속 주소를 생성할 수 있습니다. 코딩을 시작하기 전에 명확한 실행 계획을 제시합니다. 또한 시각적 편집기도 제공하므로 미리보기 창에서 UI를 직접 수정할 수 있고, 소스 코드는 자동으로 동기화되어 업데이트됩니다. 이를 통해 AI 출력이 기대와 맞는지 수시로 확인할 수 있어 왕복 수정 횟수를 크게 줄일 수 있습니다.
+
+ 
+
+- **적합한 사용자:** Replit은 초보자에게 매우 친절합니다. 코딩부터 배포까지의 전체 폐쇄 루프를 단순화하여 서버나 호스팅 서비스를 직접 따로 설정할 필요가 없습니다. 협업 기능도 강력해 학생들이 함께 프로젝트를 하거나 다른 사람에게 원격으로 코드 확인을 부탁하기에도 적합합니다.
+- **프롬프트 과정:** 구축 과정에서 AI가 처음부터 요구사항을 완전히 이해한 것은 아니었고, 중간에 약 3번의 반복을 거친 뒤에야 최종 출력이 이상적인 결과에 도달했습니다.
+ 
+- **스네이크 게임 결과:**
+
+
+
+- **가격:**
+ 
+
+### 5. Minimax(Web-based)
+
+- **플랫폼 유형:** Web
+- **주요 특징과 워크플로:** Minimax는 작업을 수행할 때 보통 시간이 꽤 걸립니다. 그 흐름은 대체로 AI가 자동으로 오류를 발견하고 수정하는 과정을 포함하므로 전체 과정이 느리거나 다소 번거롭게 느껴질 수 있습니다. 이 프로젝트를 예로 들면, Agent는 보통 먼저 상세 계획을 생성한 뒤 백엔드, 데이터베이스, 프론트엔드 로직을 단계적으로 구축합니다.
+- **적합한 사용자:** 자동으로 테스트를 실행하고 오류를 수정하기 때문에 시간과 Token 소비가 모두 큰 편입니다. 하지만 AI가 문제를 찾고 해결하는 과정을 분명히 볼 수 있으므로 학습 관점에서는 가치가 있습니다.
+- **프롬프트 과정:**
+
+
+
+- **스네이크 게임 결과:**
+
+
+
+- **가격:** 무료 버전은 복잡한 프로젝트에서 처음부터 끝까지 순조롭게 실행되지 않을 가능성이 높으므로, 프로젝트를 완전히 구축하려면 유료 업그레이드를 더 추천합니다.
+ 
+
+### 6. Trae(IDE)
+
+- **플랫폼 유형:** 데스크톱 애플리케이션(PC)
+- **주요 특징과 워크플로:** 데스크톱 애플리케이션인 Trae는 Web 도구와 비교했을 때 보통 성능과 응답 속도에서 더 유리합니다. 하지만 다운로드와 설치가 필요하므로 일부 사용자에게는 입문 장벽이 조금 높을 수 있습니다. 마찬가지로 로컬 환경이기 때문에 컴퓨터 설정과 의존성 환경의 차이에서 일정한 불확실성이 생깁니다. 장점은 Trae가 로컬에서 프로젝트 생성과 실행 설정을 도와주며, 사용자가 자신의 컴퓨터에서 바로 개발하고 디버깅할 수 있다는 점입니다.
+- **적합한 사용자:** 장기적으로 Vibe Coding 프로젝트를 진행할 계획이 있고, 전용 데스크톱 도구를 사용하고 싶은 사용자에게 더 적합합니다. “가끔 한 번 해보는” 정도를 원하는 학생에게는 가장 가벼운 선택이 아닐 수 있습니다.
+- **프롬프트 과정:**
+ 
+- **스네이크 게임 결과:**
+
+
+
+- **가격:** 가격은 비교적 친근한 편이며, 무료 버전만으로도 품질이 괜찮은 작은 프로젝트를 완성하기에 충분합니다.
+ 
+
+### 7. V0(Web-based)
+
+- **플랫폼 유형:** Web
+- **주요 특징과 워크플로:** V0는 Vercel이 제공하는 React UI 컴포넌트 생성에 집중한 도구입니다. 고품질의 프로덕션 사용 가능한 인터페이스를 생성하는 데 뛰어납니다. 하지만 실제 사용 중에는 “코드 보기 화면을 찾기 어렵다”, “API Key를 어디에 설정해야 하는지 명확히 설명하지 않는다” 같은 문제가 나타납니다.
+- **적합한 사용자:** V0는 프론트엔드와 UI/UX 디자인에 집중하는 학생이나 디자이너에게 매우 적합합니다. 하지만 완전한 풀스택 솔루션은 아니므로 백엔드 로직과 API 통합을 구현하려면 여전히 다른 플랫폼을 사용해야 합니다. 따라서 목표가 “한 번에 완전한 애플리케이션 구축”이라면 최우선 선택은 아닐 수 있습니다.
+- **프롬프트 과정:**
+ 
+
+ 
+
+- **스네이크 게임 결과:**
+ 
+- **가격:** 무료 사용자는 대략 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 생성에 집중하며, 백엔드와 전체 애플리케이션 구축은 다른 플랫폼과 함께 진행해야 합니다. |
diff --git a/docs/ko-kr/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents.md b/docs/ko-kr/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents.md
index 087d7c4..9eac603 100644
--- a/docs/ko-kr/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents.md
+++ b/docs/ko-kr/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents.md
@@ -1,91 +1,344 @@
----
-title: '디자인 Agent와 코딩 Agent로 웹사이트 만들기'
-description: '디자인 도구와 코딩 AI를 함께 사용해 작은 웹사이트를 만드는 흐름을 설명합니다.'
+# 디자인 Agent와 코딩 Agent로 웹사이트 설계하기
+
+## 이 장의 가이드
+
+이 장에서는 디자인과 개발이 AI를 통해 어떻게 완벽하게 협업할 수 있는지 보여 줍니다. 당신은 제품 관리자의 역할을 맡아 “디자인 Agent”에게 로고 디자인, 색상 구성, 페이지 레이아웃을 지휘하고, 이어서 “코딩 Agent”와 협업해 시각 디자인을 실행 가능한 코드로 바꿉니다. 창의적인 구상부터 웹사이트 공개까지, 전 과정에서 AI가 개발을 지원하는 흐름을 경험하고 한 사람이 하나의 팀이 되는 방식을 체험합니다.
+
---
-# 디자인 Agent와 코딩 Agent로 웹사이트 만들기
+# 1. 입문 가이드
-웹사이트를 만들 때는 디자인과 구현을 나누어 생각하면 편합니다.
+## 1. 튜토리얼 소개
-- 디자인 Agent: 로고, 레이아웃, 색상, 화면 구조를 잡는다.
-- 코딩 Agent: HTML/CSS/JS 또는 프레임워크 코드로 구현한다.
+AI 디자인 Agent와 코딩 Agent를 사용해 처음부터 완전한 웹사이트를 만들어 봅시다.
-## 1. 웹사이트 목표 정하기
+- **디자인 Agent**: 로고, 웹페이지 레이아웃, 색상 구성, 기타 시각 요소를 만드는 역할을 합니다.
+- **코딩 Agent**: 프롬프트에서 제시한 요구사항과 레이아웃에 따라 HTML/CSS/JS 같은 실제 코드를 작성하고 실행 가능한 웹사이트를 구축합니다.
-먼저 어떤 사이트인지 한 문장으로 정합니다.
+## 2. 디자인 Agent와 코딩 Agent
-```text
-개인 포트폴리오 사이트
-작은 카페 소개 사이트
-AI 도구 랜딩 페이지
-동아리 모집 페이지
+- **디자인 Agent**: 당신이 제공한 프롬프트에 따라 이미지, 페이지 모델, 디자인 스타일을 생성하는 AI입니다.
+- Mastergo
+- Lovart
+- Figma MCP
+- **코딩 Agent**: 프롬프트에서 요청한 기능과 레이아웃에 따라 실제 코드(HTML/CSS/JS 등)를 작성하는 AI입니다.
+- Z.AI
+- Trae
+- Cursor
+- Lovable
+
+---
+
+# 2. 디자인 Agent로 로고 만들기
+
+## 1. 로고를 디자인할 때 고려해야 할 핵심 요소
+
+로고는 웹사이트의 첫인상을 결정하는 핵심 요소 중 하나입니다. AI 디자인 Agent로부터 만족스러운 결과를 얻으려면, 프롬프트에서 원하는 로고 유형을 명확하게 설명해야 합니다.
+
+1. **브랜드 이름 / 텍스트**
+
+- 로고 안에 반드시 나타나야 하는 글자입니다. 예: 웹사이트 제목, 브랜드 이름 등.
+
+2. **스타일(정서 / 분위기)**
+
+- 로고가 전달하기를 원하는 전체적인 느낌이나 분위기입니다.
+- _예시: 미니멀, 귀여움, 간결함, 모던, 레트로, 미래감 등._
+
+3. **색상 구성**(선택)
+
+- 로고의 색상이 전체 웹사이트의 전반적인 톤과 어울리게 하는 것이 좋습니다.
+- 구체적인 16진수 색상 코드나 대략적인 색조(차가운 색, 따뜻한 색 등)를 지정할 수 있습니다.
+- _예시: **`#171721`**(검정), **`#FF7130`**(오렌지)._
+
+4. **형태(모양 / 구조)**
+
+- 로고에 특정한 모양이나 구도가 필요한지 명확히 합니다.
+- _예시: 원형 안에 텍스트 배치, 아이콘 + 텍스트 조합, 아이콘 중심 로고 등._
+
+5. **아이콘 / 상징 요소**(선택)
+
+- 로고 안에 나타나기를 원하는 그래픽이나 상징입니다.
+- _예시: 책 아이콘, 번개 기호, AI와 관련된 그래픽, 추상 기하 도형 등._
+
+## 2. 로고 디자인 프롬프트 작성하기
+
+**예시 프롬프트**
+
+```
+"'My First Website'라는 브랜드 이름으로 미니멀 스타일의 로고를 디자인해 주세요.
+검정색(#171721)과 오렌지색(#FF7130)을 사용하고, 텍스트를 원형 안에 배치해 주세요."
```
-## 2. 디자인 요청
-
-```text
-작은 독립 카페의 랜딩 페이지 디자인을 제안해 줘.
-
-포함할 섹션:
-- 첫 화면 hero
-- 대표 메뉴
-- 공간 분위기
-- 위치와 영업시간
-- 예약/문의 버튼
-
-분위기:
-따뜻하지만 너무 복고풍은 아니고, 사진이 잘 보이는 깔끔한 스타일
+```
+"'AIID'를 브랜드명으로 하는 로고를 디자인해 주세요.
+전체 스타일은 미래적이고 깔끔하며 간결해야 하고, 주색은 파란색과 흰색입니다.
+AI를 상징하는 추상 그래픽과 텍스트를 결합하고, 투명 배경 PNG로 내보내 주세요."
```
-## 3. 사이트 구조 정리
+## 3. Agent에게 디자인 요청하기
-디자인 결과를 보고 실제 구현 섹션을 정리합니다.
+- 위 프롬프트 입력 → Agent가 생성한 여러 디자인 시안을 비교합니다.
-```text
-1. Hero
-2. 메뉴 소개
-3. 공간 사진
-4. 방문 정보
-5. 문의 CTA
+
+
+## 4. 최종 로고 확정하기
+
+- 초안 중 가장 마음에 드는 버전을 선택해 다운로드합니다.
+
+---
+
+# 3. 웹사이트 구조 계획하기
+
+## 1. 기본 섹션 이해하기
+
+웹사이트를 실제로 만들기 전에 어떤 메뉴(섹션)를 포함할지 미리 계획하는 것은 매우 중요합니다. 메뉴 설계는 방문자에게 무엇을 보여 주고 싶은지, 그리고 방문자가 어떤 행동을 하길 원하는지에 따라 달라집니다.
+일반적으로 웹사이트는 보통 **Home / About / Contact** 같은 기본 섹션으로 구성됩니다.
+
+## 2. 먼저 구조 스케치 직접 그리기(선택)
+
+웹사이트의 목표에 따라 간단한 메뉴 구조를 대략 작성해 볼 수 있습니다.
+
+### 기본 메뉴
+
+1. **Home**
+ 1. 방문자가 웹사이트에 들어온 뒤 처음 보게 되는 메인 페이지입니다.
+ 2. 보통 로고, 메인 비주얼 영역, 짧은 표어나 소개 문장을 포함합니다.
+2. **About**
+ 1. 당신이 누구인지, 또는 프로젝트 / 서비스의 목적을 소개합니다.
+ 2. 개인 포트폴리오: 자기소개 + 짧은 이력.
+ 3. 서비스형 웹사이트: 비전, 목표, 핵심 기능.
+3. **Contact**
+ 1. 이메일, 전화번호, 소셜미디어 링크 같은 연락 방법입니다.
+ 2. 간단한 문의 양식을 추가할 수도 있습니다.
+
+### 선택 메뉴
+
+4. **Services / Projects**
+ 1. 제공하는 서비스 또는 프로젝트 / 포트폴리오를 보여 줍니다.
+ 2. 보통 목록이나 카드 형태로 표시합니다.
+
+5. **Gallery**
+ 1. 이미지, 사진, 디자인 작업물을 보여 주는 데 사용합니다.
+
+6. **Blog / News**
+ 1. 글, 소식, 로그를 게시하는 데 사용합니다.
+
+7. **FAQ**
+ 1. 방문자가 자주 묻는 질문과 답변을 정리합니다.
+
+## 3. 색상 구성 선택하기(선택)
+
+이미 로고가 있거나 특정 색상 조합을 사용해 웹사이트를 디자인하고 싶다면, 프롬프트에 사용할 색상 코드를 직접 써도 됩니다.
+
+**예시:** `#171721, #872B97, #FF7130, #FF3C68`
+
+아직 색상 구성이 떠오르지 않는다면, 색상 조합 사이트나 검색 키워드를 통해 영감을 얻을 수도 있습니다.
+
+- **색상 조합 참고 사이트**
+ - https://colorhunt.co/
+ - https://coolors.co/
+
+
+
+- **Google에서 키워드로 색상 조합 검색하기**
+
+
+
+## 4. 웹사이트 디자인 프롬프트 작성하기
+
+**예시 프롬프트**
+
+```
+"Home, About, Contact 세 개 섹션으로 구성된 단일 페이지 웹사이트를 디자인해 주세요.
+색상 #171721, #FF7130, #FF3C68을 사용해 주세요.
+전체 스타일은 모던하고 간결해야 합니다."
```
-## 4. 코딩 Agent에 구현 요청
+---
-```text
-아래 사이트 구조를 기준으로 반응형 랜딩 페이지를 만들어 줘.
-HTML, CSS, JavaScript만 사용해도 돼.
+# 4. 디자인 Agent로 웹사이트 디자인하기
-요구사항:
-- 모바일에서도 자연스럽게 보이기
-- 첫 화면에서 브랜드와 CTA가 분명하게 보이기
-- 메뉴 카드는 3개
-- 위치 정보와 영업시간 포함
-- 과한 애니메이션은 넣지 않기
+## 1. 프롬프트 입력 → 디자인 시안 생성
+
+- 프롬프트에 계획한 구조와 선택한 색상 구성을 작성합니다.
+
+**Mastergo 프롬프트 예시**
+
+
+
+## 2. 디자인 시안 검토하고 수정 의견 제시하기
+
+자신의 필요에 따라 Agent에게 피드백을 줄 수 있습니다. 예:
+
+- “너무 화려해요. 전체 스타일을 더 간결하게 바꿔 주세요.”
+- “다른 글꼴로 바꿔 주세요.”
+- “색상 조합을 조정해 주세요.”
+- “여기 이 블록을 삭제해 주세요.”
+
+
+
+## 3. 최종 디자인 확정하기
+
+디자인 시안을 여러 차례 수정해 만족한 뒤에는, 이 디자인을 코드로 변환하여 코딩 Agent가 이해하고 이어서 작업할 수 있게 합니다.
+
+디자인을 코드로 바꾸는 방식은 플랫폼마다 다르지만, 보통 디자인 플랫폼 안에서 특정 플러그인을 설치하고 사용하는 방식으로 진행합니다.
+
+**Mastergo 예시**
+
+1. [Mastergo 플러그인 웹사이트](https://mastergo.com/community/plugin)를 열고 **seal**을 검색합니다.
+
+
+
+2. 디자인 페이지로 돌아가 **사각형 아이콘(플러그인)** 을 클릭합니다.
+
+
+
+3. 코드로 변환하고 싶은 디자인 영역을 선택하고 **Generate** 버튼을 클릭해 코드를 생성합니다.
+
+
+
+---
+
+# 5. 코딩 Agent로 웹사이트 만들기
+
+## 1. HTML/CSS/JS의 기본 개념 이해하기
+
+웹사이트는 본질적으로 세 가지 언어로 구성됩니다.
+
+- **HTML(HyperText Markup Language)** → 구조(뼈대)
+- **CSS(Cascading Style Sheets)** → 스타일(외관)
+- **JavaScript(JS)** → 기능(상호작용)
+
+이 세 가지가 함께 작동하여 우리가 보는 완전한 웹페이지를 구성합니다.
+
+1. **🏗️ HTML(구조)**
+
+- 페이지에서 “무엇을 보여 줄지” 정의합니다.
+- 텍스트, 이미지, 버튼, 링크 같은 요소를 배치하는 데 사용합니다.
+- 건축물의 **벽체와 프레임**과 비슷합니다.
+
+**예시**
+
+```html
+
Hello!
+
This is my first website.
+Contact
```
-## 5. 디자인과 코드 맞추기
+2. **🎨 CSS(스타일)**
-처음 결과는 대개 완벽하지 않습니다. 다음처럼 구체적으로 수정합니다.
+- “내용을 어떻게 보여 줄지” 결정합니다.
+- 글자 크기, 색상, 간격, 배경, 버튼 모양 등을 제어합니다.
+- HTML에 “옷”과 시각 스타일을 입혀 줍니다.
-```text
-첫 화면이 너무 마케팅 배너처럼 보여.
-카페 사진을 더 크게 쓰고, 텍스트는 왼쪽 아래에 자연스럽게 배치해 줘.
+**예시**
+
+```css
+h1 {
+ color: #FF7130; /* 글자 색상 */
+ font-size: 36px; /* 글자 크기 */
+ text-align: center; /* 가운데 정렬 */
+}
+
+body {
+ background-color: #171721; /* 배경 색상 */
+ color: white; /* 기본 글자 색상 */
+}
```
-```text
-모바일에서 메뉴 카드 텍스트가 좁아 보여.
-카드는 한 줄에 하나씩 나오게 하고 간격을 늘려 줘.
+3. **⚙️ JavaScript(JS)(기능)**
+
+- 웹페이지가 사용자와 상호작용할 수 있게 합니다.
+- 버튼 클릭, 메뉴 펼치기, 이미지 캐러셀, 폼 제출 같은 동적 효과를 구현할 수 있습니다.
+- HTML/CSS가 정적인 뼈대와 외관이라면, JS는 웹페이지를 “살아 움직이게” 하는 **두뇌**입니다.
+
+**예시**
+
+```javascript
+function showAlert() {
+ alert("The button has been clicked!");
+}
```
-## 6. 마무리 체크리스트
+```html
+
+```
-- 첫 화면에서 무엇을 소개하는 사이트인지 분명하다.
-- 주요 CTA가 보인다.
-- 모바일에서 레이아웃이 깨지지 않는다.
-- 이미지가 너무 어둡거나 흐리지 않다.
-- 텍스트가 카드나 버튼 밖으로 넘치지 않는다.
+## 2. 코딩 Agent가 코드를 생성하게 하기
-## 과제
+**예시 프롬프트**
-내가 만들고 싶은 웹사이트 주제를 하나 정하고, 디자인 요청과 코딩 요청을 각각 작성해 보세요.
+```
+"Home, About, Contact 섹션을 포함한 단일 페이지 웹사이트의 HTML과 CSS를 작성해 주세요.
+색상 #171721, #FF7130, #FF3C68을 사용해 주세요.
+배경은 검정색, 글자는 흰색으로 해 주세요."
+```
+
+
+## 3. 웹사이트 실행하기
+
+초안 코드가 생성되면 Agent는 보통 프로젝트를 자동으로 시작하고, 생성된 웹사이트 페이지를 보여 줍니다.
+
+Agent를 다시 시작했거나 웹사이트 화면이 나타나지 않는다면, 다음과 비슷한 프롬프트를 입력할 수 있습니다.
+
+```
+"Please activate the project"
+```
+
+Agent가 프로젝트를 다시 시작하고 미리보기 페이지를 열어 현재 효과를 확인하기 쉽게 합니다.
+
+## 4. 간단히 수정하기
+
+자연어로 초안을 계속 미세 조정할 수 있습니다. 예:
+
+- “버튼을 조금 더 크게 만들어 주세요.”
+- “글꼴을 조금 더 굵게 해 주세요.”
+
+
+
+## 5. 웹사이트 문구 내용 수정하기
+
+Agent가 생성한 첫 번째 웹사이트에는 보통 자동으로 생성된 자리표시자 텍스트가 포함됩니다. 실제 상황에 더 가깝게 만들려면, 미리 실제 내용을 준비한 다음 Agent에게 교체를 부탁할 수 있습니다.
+
+**적용 예시**: AIID 웹사이트의 About 페이지 업데이트
+
+1. 먼저 About 페이지에 보여 주고 싶은 내용을 작성합니다. Agent가 이해하기 쉽도록 Markdown 형식으로 저장할 수 있습니다.
+
+
+
+2. 그런 다음 대화에서 Agent에게 해당 파일의 내용을 지정한 페이지에 적용하라고 말합니다.
+
+
+
+3. 내용이 적용된 업데이트 버전을 확인합니다.
+
+
+
+## 6. 이미지 삽입하기
+
+특정 이미지(예: 로고, 배경 이미지 등)를 추가하고 싶다면, 먼저 이미지를 프로젝트 폴더에 업로드한 뒤 프롬프트에서 이 이미지를 페이지의 어느 위치에 사용할지 설명할 수 있습니다.
+
+- **예시:**
+
+
+
+- **결과:**
+
+
+
+---
+
+# 6. 디자인과 코드 통합하기
+
+## 1. 디자인 파일과 웹사이트 코드 통합하기(선택)
+
+디자인 Agent에서 코드 파일을 다운로드했다면, 해당 파일들을 현재 프로젝트 디렉터리로 옮긴 다음 코딩 Agent에게 이 디자인 코드와 기존 프로젝트를 합쳐 달라고 요청할 수 있습니다.
+
+- **예시:**
+
+
+
+- **결과:**
+
+
diff --git a/docs/ko-kr/stage-1/appendix-b-common-errors/index.md b/docs/ko-kr/stage-1/appendix-b-common-errors/index.md
index dd25f0b..47127a0 100644
--- a/docs/ko-kr/stage-1/appendix-b-common-errors/index.md
+++ b/docs/ko-kr/stage-1/appendix-b-common-errors/index.md
@@ -1,120 +1,334 @@
---
-title: '오류가 났을 때 대처법'
-description: 'AI IDE로 작업하다가 오류를 만났을 때 원인을 좁히고 AI에게 효과적으로 도움을 요청하는 방법입니다.'
+title: '코드를 쓰다가 오류를 만나면 어떻게 해야 할까 - 스크린샷으로 AI에게 묻는 실전 가이드'
+description: '개발 중 발생하는 다양한 오류를 해결하기 위해 AI에게 효율적으로 질문하는 법을 배웁니다. 스크린샷, 설명, 문제 위치 파악의 표준 흐름을 익혀 AI를 디버깅 조수로 만듭니다.'
---
-# 오류가 났을 때 대처법
+
-AI 코딩을 하다 보면 오류는 반드시 납니다. 오류가 난다는 것은 실패가 아니라, 수정할 단서가 생겼다는 뜻입니다.
+# 코드를 쓰다가 오류를 만나면 어떻게 해야 할까
-## 1. 먼저 어디서 오류가 났는지 구분하기
+## 본 장 안내
-| 위치 | 예시 |
-| --- | --- |
-| 설치 오류 | `npm install` 실패 |
-| 실행 오류 | `npm run dev` 실패 |
-| 빌드 오류 | `npm run build` 실패 |
-| 브라우저 오류 | 화면이 비거나 콘솔 에러 |
-| 기능 오류 | 버튼 클릭, 입력, 결과 표시가 안 됨 |
-| API 오류 | 401, 403, 429, 500 등 |
+
-오류 위치를 구분하면 AI에게 더 정확히 물어볼 수 있습니다.
+AI 시대에는 오류를 조사하는 방식이 이미 바뀌었습니다.
-## 2. 오류 메시지를 그대로 복사하기
+모든 오류 유형을 외울 필요도 없고, 디버깅 전문가가 될 필요도 없으며, 심지어 오류가 무슨 뜻인지 이해하지 못해도 됩니다.
-가장 좋은 프롬프트:
+딱 한 가지, AI에게 어떻게 물어볼지만 배우면 됩니다.
-```text
-아래 오류가 발생했어.
-원인을 초보자도 이해할 수 있게 설명하고,
-가장 작은 수정으로 해결해 줘.
+이 장은 간단한 단계에서 고급 단계로 이어지는 조사 흐름을 알려 줍니다.
-실행한 명령:
-npm run dev
+1. 1단계: 바로 묻기: 현상 설명 + 스크린샷, 한 문장 질문
+2. 2단계: 정보 보충: 해결되지 않으면 F12를 열어 핵심 정보 보충
-오류 메시지:
-[여기에 전체 오류 붙여넣기]
+이 흐름을 익히면 오류의 90%를 스스로 해결할 수 있습니다.
+
+
+
+::: info 설명
+이 장의 모든 방법은 Cursor/Trae/Claude 같은 AI IDE의 실제 사용 경험에 기반하며, 일상 개발에 바로 적용할 수 있습니다.
+:::
+
+
+
+
+
+
+
+## 1. 핵심 마음가짐: 스크린샷으로 AI에게 묻기
+
+::: warning 이 장이 왜 중요한가요?
+
+많은 초보자가 오류를 만났을 때 가장 먼저 보이는 반응은 다음과 같습니다.
+
+- 당황해서 코드를 아무렇게나 고치기 시작한다.
+- "xxx 오류 해결 방법"을 검색하는 데 30분을 쓴다.
+- 오류가 무슨 뜻인지 스스로 이해하려고 한다.
+- 혼자 밤늦게까지 debug한다.
+
+이것들은 모두 시간을 낭비하는 방식입니다.
+
+AI 시대에 디버깅은 매우 단순한 일이 되었습니다.
+
+```
+오류를 본다 → 스크린샷을 찍는다 → AI에게 묻는다 → AI가 말한 대로 한다
```
-## 3. 최근 변경을 알려 주기
+오류를 이해할 필요도, 디버깅을 할 줄 알 필요도, 심지어 문제가 어디 있는지 알 필요도 없습니다.
-오류는 대개 방금 바꾼 부분에서 생깁니다.
+어떻게 물어볼지만 배우면 됩니다.
-```text
-오류가 나기 직전에 ProductCard 컴포넌트와 App.vue를 수정했어.
-이 두 파일을 중심으로 원인을 찾아 줘.
+:::
+
+### 1.1 가장 간단한 질문 방식
+
+복잡한 템플릿이 필요 없습니다. 두 방식 중 하나를 고르면 됩니다.
+
+**방식 1: 현상 설명**
+
+형식: 방금 무엇을 했고, 지금 무엇이 나타났는지
+
+```
+방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 비어 있어요. 어떻게 해야 하나요?
```
-## 4. 한 번에 하나씩 고치기
+**방식 2: 스크린샷**
-오류가 여러 개 보이면 가장 위쪽 오류부터 해결합니다. 아래쪽 오류는 위쪽 오류 때문에 연쇄적으로 생긴 것일 수 있습니다.
+현재 페이지나 오류 정보를 바로 캡처합니다.
-AI에게는 이렇게 요청합니다.
+```
+[스크린샷]
-```text
-오류가 여러 개 나오는데, 가장 먼저 고쳐야 할 오류 하나만 골라서 설명해 줘.
-그 오류를 고친 뒤 다시 실행해 볼게.
+이 오류는 어떻게 해결하나요?
```
-## 5. 자주 보는 오류
+**가장 좋은 방식: 설명 + 스크린샷**
-### 5.1 모듈을 찾을 수 없음
+```
+방금 로그인 페이지 코드를 수정했는데, 지금 페이지가 하얗게 비어 있어요.
-의존성이 설치되지 않았거나 import 경로가 틀린 경우입니다.
+[스크린샷]
-대응:
-
-- `npm install` 실행
-- 파일 경로 확인
-- 대소문자 확인
-
-### 5.2 환경변수 오류
-
-API Key가 없거나 이름이 틀린 경우입니다.
-
-대응:
-
-- `.env` 파일 확인
-- 변수 이름 확인
-- 서버 재시작
-
-### 5.3 빈 화면
-
-JavaScript 오류로 앱이 렌더링되지 않는 경우가 많습니다.
-
-대응:
-
-- 브라우저 개발자 도구 Console 확인
-- 첫 번째 오류 복사
-- AI에게 오류와 관련 파일을 함께 보여 주기
-
-### 5.4 API 인증 실패
-
-401 또는 403은 보통 키, 권한, 요청 형식 문제입니다.
-
-대응:
-
-- API Key가 맞는지 확인
-- 결제/권한 활성화 확인
-- 공식 문서의 예시 요청과 비교
-
-## 6. 되돌리는 것도 실력이다
-
-수정이 너무 꼬이면 되돌리는 편이 빠릅니다. Git을 쓰고 있다면 변경 전 커밋을 만들어 두는 습관이 좋습니다.
-
-AI에게도 이렇게 말할 수 있습니다.
-
-```text
-방금 수정 이후 문제가 생겼어.
-변경된 파일을 기준으로 어떤 부분이 위험한지 설명하고,
-가능하면 이전 구조를 유지하면서 최소 수정해 줘.
+어떻게 해야 하나요?
```
-## 체크리스트
+**기억하세요: 맥락을 분명히 설명하고 스크린샷을 더하면, AI가 더 빨리 문제를 해결해 줄 수 있습니다.**
-- 실행한 명령을 기록했다.
-- 오류 메시지를 전체 복사했다.
-- 최근 변경 파일을 확인했다.
-- 첫 번째 오류부터 봤다.
-- AI에게 "최소 수정"을 요청했다.
+### 1.2 문제를 어떻게 명확히 말할까
+
+많은 초보자가 질문해야 한다는 것은 알지만 어떻게 말해야 할지 모릅니다. 사실 세 가지만 분명히 말하면 됩니다.
+
+**1. 방금 무엇을 했는가**
+
+```
+방금 저장 버튼을 클릭했어요.
+방금 로그인 페이지 코드를 수정했어요.
+방금 페이지를 새로고침했어요.
+```
+
+**2. 지금 무엇을 보았는가**
+
+```
+지금 페이지가 비어 있어요.
+지금 버튼을 눌러도 반응이 없어요.
+지금 오류 메시지가 표시돼요.
+```
+
+**3. 어떤 효과를 원했는가**
+
+```
+데이터가 성공적으로 저장되게 하고 싶어요.
+페이지가 정상적으로 표시되게 하고 싶어요.
+버튼을 누르면 알림이 뜨게 하고 싶어요.
+```
+
+**완전한 예시:**
+
+```
+방금 저장 버튼을 클릭했는데, 지금 페이지에 "저장 실패" 오류가 표시돼요.
+
+[스크린샷]
+
+폼 데이터가 데이터베이스에 성공적으로 저장되게 하고 싶은데, 어떻게 해야 하나요?
+```
+
+**핵심 원칙:**
+
+- 전문 용어를 쓰지 말고 일상어로 설명합니다.
+- 시간 순서대로 말합니다. 먼저 무엇을 했고, 그다음 무엇이 일어났는지.
+- 기대한 결과를 말해 AI가 당신이 원하는 바를 알게 합니다.
+
+## 2. 1단계: 현상을 바로 설명하며 질문하기
+
+문제를 만났을 때 급하게 F12를 열지 마세요. 먼저 현상을 직접 설명하고, 현재 화면을 캡처해 AI에게 던져 보세요.
+
+많은 경우 AI는 스크린샷만 보고도 바로 해결 방안을 줄 수 있습니다.
+
+### 2.1 흔한 현상은 어떻게 설명할까
+
+::: tip 바로 설명하면 됩니다
+
+**페이지가 하얗게 비어 있음**
+
+```
+페이지를 열면 비어 있어요. 어떻게 해야 하나요?
+
+[스크린샷]
+```
+
+**버튼을 클릭해도 반응이 없음**
+
+```
+이 버튼을 클릭해도 반응이 없어요. 한번 봐 주세요.
+
+[스크린샷]
+```
+
+**데이터가 저장되지 않음**
+
+```
+저장을 눌렀는데 데이터가 저장되지 않아요. 어떻게 해야 하나요?
+
+[스크린샷]
+```
+
+**스타일 표시가 이상함**
+
+```
+이 버튼 위치가 어긋났어요. 어떻게 조정하나요?
+
+[스크린샷]
+```
+
+**인터페이스 오류**
+
+```
+인터페이스 호출에서 오류가 났어요. 봐 주세요.
+
+[스크린샷]
+```
+
+:::
+
+### 2.2 AI가 바로 해결했다면
+
+축하합니다. 문제가 해결되었습니다. AI가 말한 대로 수정하면 됩니다.
+
+### 2.3 AI가 "더 많은 정보가 필요하다"고 말한다면
+
+그때 F12를 열어 핵심 정보를 보충하면 됩니다. 아래를 계속 보세요.
+
+## 3. 2단계: 핵심 정보 보충하기
+
+AI가 더 많은 정보가 필요하다고 말할 때는 문제 유형에 따라 F12를 열고 해당 내용을 캡처합니다.
+
+### 3.1 언제 정보를 보충해야 할까
+
+AI가 이렇게 답할 수 있습니다.
+
+- "Console을 열어 오류가 있는지 확인해 주세요."
+- "Network 패널을 캡처해 주세요."
+- "구체적인 오류 정보가 필요합니다."
+
+이때 아래 안내에 따라 스크린샷을 보충합니다.
+
+### 3.2 Console 정보 보충하기(페이지 빈 화면/오류)
+
+::: tip 작업 단계
+
+**1단계: F12를 눌러 개발자 도구 열기**
+
+Mac에서는 `Cmd+Option+I`를 누르거나, 페이지에서 우클릭 후 "검사"를 선택합니다.
+
+**2단계: Console 탭으로 전환**
+
+**3단계: 빨간색 오류 정보를 캡처**
+
+**4단계: AI에게 보내기**
+
+```
+Console 오류는 다음과 같습니다.
+
+[스크린샷]
+```
+
+:::
+
+### 3.3 Network 정보 보충하기(데이터 문제/API 오류)
+
+::: tip 작업 단계
+
+**1단계: F12를 눌러 개발자 도구 열기**
+
+**2단계: Network 탭으로 전환**
+
+**3단계: 작업을 다시 한 번 수행**(저장 클릭/페이지 새로고침)
+
+**4단계: 해당 요청을 찾아 캡처**
+
+- URL과 상태 코드 보기
+- Payload(전송한 파라미터) 보기
+- Response(반환 결과) 보기
+
+**5단계: AI에게 보내기**
+
+```
+Network 정보는 다음과 같습니다.
+
+요청: [스크린샷1]
+파라미터: [스크린샷2]
+반환: [스크린샷3]
+```
+
+:::
+
+### 3.4 Elements 정보 보충하기(스타일 문제)
+
+::: tip 작업 단계
+
+**1단계: 요소 우클릭 → "검사"**
+
+개발자 도구가 해당 요소로 자동 이동합니다.
+
+**2단계: Styles 패널 캡처**
+
+**3단계: AI에게 보내기**
+
+```
+요소 스타일은 다음과 같습니다.
+
+[스크린샷]
+```
+
+:::
+
+## 4. 3단계: 해결될 때까지 반복하기
+
+### 4.1 비효율적인 방식
+
+이런 방식은 시간을 낭비합니다.
+
+오류를 보자마자 당황해서 코드를 마구 고치기
+오류 해결책을 검색하는 데 30분 쓰기
+모든 오류의 뜻을 스스로 이해하려 하기
+혼자 밤늦게까지 debug하기
+
+### 4.2 효율적인 방식
+
+이 흐름을 따르세요.
+
+먼저 현상 설명과 스크린샷으로 바로 질문하기
+AI가 더 많은 정보가 필요하다고 말할 때만 F12를 열어 보충하기
+제안에 따라 코드 수정하기
+수정 후 테스트하고, 문제가 남아 있으면 계속 캡처해 질문하기
+
+## 5. 정리: 전체 흐름
+
+```
+문제 발생
+ ↓
+현상 설명 + 스크린샷
+ ↓
+AI에게 던지기: "어떻게 해야 하나요?"
+ ↓
+AI가 바로 해결?
+ ↓ 예
+AI가 말한 대로 하기
+ ↓
+해결됐는지 테스트
+ ↓
+ ↓ 아니오 / AI가 더 많은 정보 필요
+F12를 열어 핵심 정보 보충
+ ↓
+다시 AI에게 보내기
+ ↓
+해결될 때까지 반복
+```
diff --git a/docs/ko-kr/stage-1/appendix-c-consumer-scenarios/index.md b/docs/ko-kr/stage-1/appendix-c-consumer-scenarios/index.md
index 42fb076..620813f 100644
--- a/docs/ko-kr/stage-1/appendix-c-consumer-scenarios/index.md
+++ b/docs/ko-kr/stage-1/appendix-c-consumer-scenarios/index.md
@@ -1,110 +1,642 @@
---
-title: '소비자용 AI 제품 시나리오 참고'
-description: 'C-end 소비자용 AI 제품 아이디어를 찾기 위한 한국어 시나리오 참고 목록입니다.'
+title: 'C 사이드 소비 장면 영감 참고'
+description: '이 문서는 LLM 대형 모델이 C 사이드 소비 장면에서 창의적으로 적용될 수 있는 방향을 정리합니다. 라이프스타일, 감정적 동행, 엔터테인먼트와 휴식, 개인 성장, 소셜 상호작용 등 영역의 영감 장면을 다루며, 일반 소비자를 향한 AI 앱 개발자에게 참고 자료를 제공합니다.'
---
-# 소비자용 AI 제품 시나리오 참고
+
+
+# C 사이드 소비 장면 영감 참고
+
+## 장 안내
+
+
+
+이 문서는 LLM 대형 모델이 C 사이드 소비 장면에서 창의적으로 적용될 수 있는 방향을 정리합니다. 효율과 고통 지점에 관심을 두는 B 사이드와 달리, C 사이드 제품은 느낌, 심리적 암시, 분위기 조성을 더 중시하며, 사용자가 사용 과정에서 감정적 공명과 좋은 경험을 얻도록 합니다.
+
+
+
+## 장면 분위기 빠른 선택
+
+
+
당신을 건드리는 장면 영감 찾기
+
+ 원하는 분위기와 지금의 느낌을 선택하면, 시스템이 관련 장면 방향을 추천합니다. 태그를 클릭하면 해당 절로 이동합니다.
+
+ 당신을 위한 {{ currentSelection.vibe }} × {{ currentSelection.feeling }} 장면 추천:
+
+
+
+ {{ topic.title }}
+
+
+
+ 다시 선택
+
+
+
+
+---
+
+## 1. 생활 방식
+
+> 💡 **핵심 관념**: 평범한 일상을 의식감 있게 만들고, 세부 속에서 아름다움을 창조합니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 아침 의식감 깨우기 도우미 | 날씨 API와 캘린더 데이터를 통합하고 LLM이 개인화된 아침 방안을 생성합니다. 스마트 스피커로 맞춤 음악을 재생하고 스마트 조명을 서서히 밝힙니다 |
+| 2 | 혼자 사는 생활 분위기 연출가 | 스마트홈 기기(조명, 스피커, 디퓨저)를 연결하고, LLM이 시간/기분에 따라 매개변수를 자동 조절합니다. 사용자 선호를 학습해 계속 최적화합니다 |
+| 3 | 주말 집콕 치유 계획 생성기 | 스트리밍 플랫폼 API와 연결해 영화 목록을 가져오고, 사용자 과거 선호를 결합해 영화+음식+공간 꾸미기의 조합 방안을 생성합니다 |
+| 4 | 잠들기 전 마음 위로 라디오 | TTS 음성 합성으로 부드러운 이야기를 만들고, 백색소음 혼합 알고리즘과 스마트 볼륨 페이드아웃을 적용합니다. 수면 데이터에 따라 내용을 조정합니다 |
+| 5 | 생활 미학 영감 포착기 | 이미지 인식으로 사용자 환경 사진을 분석하고 LLM이 미학 제안을 생성합니다. Pinterest/Xiaohongshu 스타일 콘텐츠를 추천합니다 |
+
+---
+
+## 2. 감정적 동행
+
+> 💡 **핵심 관념**: 무조건적인 수용과 동행으로 감정을 담아 주는 부드러운 그릇이 됩니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 깊은 밤의 마음 구멍 청취자 | 종단 간 암호화로 개인정보를 보장하고, LLM 감정 분석으로 감정을 이해하며, 장기 기억에 사용자 이야기를 저장하고 다회차 대화로 계속 동행합니다 |
+| 2 | 이별 치유 동행자 | 감정 단계 인식 알고리즘으로 단계별 지원을 제공합니다(털어놓기 단계 -> 쏟아내기 단계 -> 재건 단계). 심리학 지식베이스 RAG 검색을 사용합니다 |
+| 3 | 불안 완화 호흡 코치 | 생체 센서 데이터(심박/호흡)를 연결하고 불안 수준을 실시간으로 감지합니다. 음성으로 호흡 리듬과 점진적 근육 이완을 안내합니다 |
+| 4 | 자신감 재건 멘토 | 긍정심리학 대화 프레임워크로 사용자의 작은 성취를 기록하고 피드백합니다. 인지 재구성 기술로 부정적 자기 대화를 바꾸도록 돕습니다 |
+| 5 | 감정 일기 지능형 해석 | 감정 인식 NLP 모델과 시계열 분석으로 감정 패턴을 발견합니다. 감정 그래프를 시각화하고 예측성 감정 경고를 제공합니다 |
+
+---
+
+## 3. 엔터테인먼트와 휴식
+
+> 💡 **핵심 관념**: 몰입형 경험을 만들어 엔터테인먼트가 마음의 쉴 곳이 되게 합니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 몰입형 추리 게임 DM | LLM이 실시간으로 이야기 분기를 생성하고, 음성 합성으로 NPC를 연기하며, 플레이어 반응에 따라 난이도와 리듬을 동적으로 조정합니다. AR/VR 장면을 렌더링합니다 |
+| 2 | 오픈월드 게임의 영혼 있는 NPC | 장기 기억 데이터베이스에 플레이어 상호작용 기록을 저장하고, LLM이 개인화 대화를 생성합니다. 감정 컴퓨팅으로 NPC가 실제 감정 반응을 갖게 합니다 |
+| 3 | 개인화 팟캐스트 콘텐츠 생성 | 사용자 관심 그래프에 따라 전용 콘텐츠를 생성하고, TTS로 사용자가 좋아하는 목소리를 복제합니다. 실시간 상호작용으로 청취자 질문에 답합니다 |
+| 4 | 가상 콘서트 분위기 팀 | 가상 아바타 렌더링, 실시간 댓글 상호작용, 가상 응원봉/응원 도구를 제공합니다. 공간 음향 기술로 현장감을 만듭니다 |
+| 5 | 인터랙티브 소설 공동 창작 파트너 | LLM이 실시간으로 이야기를 생성하고, 사용자 선택이 이야기 방향에 영향을 줍니다. 다중 엔딩을 설계하고 인물 관계를 동적으로 발전시킵니다 |
+
+---
## 4. 개인 성장
-- 습관 형성 코치
-- 매일 작은 성취 기록
-- 공부 계획 생성
-- 독서 노트 질문 생성
-- 장기 목표를 작은 행동으로 나누기
+> 💡 **핵심 관념**: 성장은 고행이 아니라 재미있는 자기 발견의 여정입니다.
-## 5. 관계와 소통
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 개인 성장 목격자 | 타임라인 시각화로 성장 궤적을 보여 주고, 이정표를 자동 표시합니다. "과거의 나"와 "지금의 나"를 비교 이미지로 보여 줍니다 |
+| 2 | 습관 형성 게임화 코치 | 게임화 메커니즘(경험치, 레벨, 배지), 소셜 순위표, AI 코치 역할극(예: "모험 멘토")을 제공합니다 |
+| 3 | 기술 학습 메이트 매칭 | 관심사와 학습 목표 기반 매칭 알고리즘, 학습 그룹 커뮤니티, 서로 감독하는 체크인 메커니즘을 제공합니다 |
+| 4 | 매일의 작은 행복 발견자 | 이미지 인식으로 생활 속 아름다운 순간을 발견하고, 감사 일기 안내와 매주 좋은 순간 회고를 제공합니다 |
+| 5 | 인생 시뮬레이션 체험기 | 다중 분기 이야기로 서로 다른 선택의 결과를 시뮬레이션하고, 평행 인생을 비교합니다. 의사결정 결과를 시각화합니다 |
-- 대화 주제 추천
-- 메시지 톤 다듬기
-- 데이트 코스 아이디어
-- 가족에게 보낼 안부 문구
-- 갈등 완화 대화 초안
+---
-## 6. 창작
+## 5. 소셜 상호작용
-- 글쓰기 아이디어 도우미
-- 사진 구도 추천
-- 브랜딩 무드보드 설명 생성
-- 음악 분위기 설명
-- 손글씨/다이어리 문구 추천
+> 💡 **핵심 관념**: 소셜을 가볍고 자연스럽게 만들고, 편안한 연결 방식을 찾습니다.
-## 7. 여행
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 아이스브레이킹 대화 주제 생성기 | 장소와 참여자 기반의 지능형 주제 추천, 실시간 대화 분석을 통한 후속 주제 제안, 어색한 순간의 구원 힌트를 제공합니다 |
+| 2 | 친구 피드 문구 분위기 연출가 | 이미지 콘텐츠를 분석하고 LLM이 여러 스타일의 문구(문학적/유머러스/깊은 톤)를 생성합니다. 이모지와 레이아웃을 지능적으로 추천합니다 |
+| 3 | 데이트 분위기 기획자 | 양쪽 관심사를 바탕으로 데이트 방안을 생성하고, 식당/활동 추천과 대화 주제 제안을 제공합니다. 실시간 날씨와 교통 알림을 포함합니다 |
+| 4 | 원격 모임 분위기 담당 | 온라인 게임 라이브러리, 아이스브레이킹 활동 생성기, 주제 룰렛을 제공합니다. 가상 배경과 필터로 분위기를 강화합니다 |
+| 5 | 소셜 에너지 관리 도우미 | 소셜 활동 후 에너지 소모를 평가하고 회복 제안(혼자 하는 활동 추천)을 제공합니다. 소셜 캘린더를 지능적으로 계획합니다 |
-- 도시 산책 코스 추천
-- 혼자 여행 일정 짜기
-- 여행 감정 일기 생성
-- 목적지 분위기 미리보기
-- 여행 사진 촬영 아이디어
+---
-## 8. 건강과 생활 관리
+## 6. 창의적 표현
-- 운동 루틴 동기부여
-- 냉장고 재료 기반 식단 추천
-- 수면 환경 체크리스트
-- 자기 돌봄 리마인더
-- 스트레스 기록 요약
+> 💡 **핵심 관념**: 모든 사람에게는 창의력이 있고, 다만 깨워질 필요가 있습니다.
-## 9. 금융 습관
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 영감 고갈 응급 키트 | 분야 간 연상 알고리즘, 무작위 자극어 생성, 창의적 프롬프트 라이브러리, 마인드맵식 영감 발산 도구를 제공합니다 |
+| 2 | 개인 스타일 탐색 가이드 | 이미지 분석으로 사용자의 기존 스타일을 식별하고, 스타일 트렌드를 추천하며, 가상 착장/메이크업을 제공합니다. 스타일 진화 타임라인을 보여 줍니다 |
+| 3 | 다이어리와 일기 미학 컨설턴트 | 레이아웃 템플릿 추천, 색 조합 방안 생성, 장식 요소 제안을 제공합니다. 손글씨 인식과 콘텐츠 미화를 지원합니다 |
+| 4 | 사진 구도 분위기 가이드 | 장면 인식과 구도 제안, 필터 스타일 추천, 보정 매개변수 지능 조정을 제공합니다. 촬영 기술 학습 경로를 제시합니다 |
+| 5 | 음악 기분 매칭 전문가 | 음악 감정 분석 알고리즘, 사용자 기분 인식, 개인화 재생목록 생성을 제공합니다. 음악 이야기와 배경 소개도 제공합니다 |
-주의: 투자 판단을 대신하는 제품은 피해야 합니다. 초보자 프로젝트에서는 습관 기록과 교육 보조가 적합합니다.
+---
-- 소비 감정 기록
-- 저축 목표 시각화
-- 금융 용어 쉽게 설명
-- 지출 회고 질문 생성
+## 7. 여행 탐색
-## 10. 소비자 제품 설계 원칙
+> 💡 **핵심 관념**: 여행은 풍경을 보는 것뿐 아니라 서로 다른 생활 방식을 느끼는 일입니다.
-### 10.1 기능보다 감정
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 도시 산책 탐색 가이드 | 현지 고수 콘텐츠를 모으고, 덜 알려진 장소를 추천하며, AR 내비게이션 안내를 제공합니다. 실시간 번역과 음성 해설을 지원합니다 |
+| 2 | 여행 기분 일기 생성 | 사진을 자동 분류하고 선별하며, LLM이 아름다운 여행기를 생성하고 위치 표시 타임라인을 만듭니다. 여행 영상을 한 번에 생성합니다 |
+| 3 | 혼자 여행 동행 도우미 | 실시간 위치 공유와 안전 알림, 현지 긴급 연락처, AI 가이드 음성 동행을 제공합니다. 혼자 여행 커뮤니티 교류를 지원합니다 |
+| 4 | 목적지 분위기 미리보기 | VR/360도 파노라마 미리보기, 현지 소리와 향기 시뮬레이션, 문화 배경 소개를 제공합니다. 가상 "미리 살아보기" 경험을 제공합니다 |
+| 5 | 여행 사진 분위기 지도 | 골든아워 알림, 구도 보조선, 현지 특색 촬영 지점 추천을 제공합니다. 후보정 색감 스타일 제안을 제공합니다 |
-소비자 제품은 "무엇을 해 주는가"뿐 아니라 "어떤 기분을 주는가"가 중요합니다.
+---
-### 10.2 작게 자주 쓰게 만들기
+## 8. 몸과 마음의 건강
-처음부터 큰 플랫폼보다 하루 1분, 매주 1회처럼 반복 사용되는 작은 행동이 좋습니다.
+> 💡 **핵심 관념**: 건강은 목표가 아니라 부드러운 자기 돌봄의 방식입니다.
-### 10.3 사용자가 더 나은 자신을 느끼게 하기
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 운동 동기 깨우기 코치 | 사용자 상태에 따라 운동 유형을 지능적으로 추천하고, 5분짜리 미니 운동 옵션과 게임화 운동 챌린지를 제공합니다. 소셜 운동 체크인을 지원합니다 |
+| 2 | 건강 식단 영감 주방 | 냉장고 식재료를 인식하고, 개인화 레시피 추천과 영양 조합 분석을 제공합니다. 단계별 조리 안내를 지원합니다 |
+| 3 | 수면 품질 최적화 분위기 연출가 | 수면 모니터링 데이터를 분석하고, 잠들기 전 의식을 생성하며, 환경 최적화 제안(온도/습도/빛)을 제공합니다. 스마트 기상을 지원합니다 |
+| 4 | 몸 감각 안내자 | 바디 스캔 명상 안내, 신체 부위와 감정의 연결, 몸과 마음 연결 연습을 제공합니다. 생체 피드백을 시각화합니다 |
+| 5 | 자기 돌봄 알림 도우미 | 업무 강도를 모니터링하고, 정기 휴식 알림과 작은 돌봄 활동 제안(물 마시기/스트레칭/깊은 호흡)을 제공합니다. 자기 돌봄을 기록합니다 |
-좋은 소비자용 AI 제품은 사용자를 대신하지 않습니다. 사용자가 더 잘 선택하고 표현하고 정리하도록 돕습니다.
+---
-## 과제
+## 9. 지식 탐색
-소비자용 아이디어 하나를 골라 다음 형식으로 정리하세요.
+> 💡 **핵심 관념**: 학습은 끝없는 모험이고, 호기심은 최고의 선생님입니다.
-```text
-사용자:
-상황:
-느끼는 감정:
-지금의 대안:
-AI가 줄 수 있는 도움:
-첫 화면:
-결과 화면:
-```
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 지식 탐색 게임화 가이드 | 지식 지도를 시각화하고, 스테이지형 학습 경로와 성취 배지 시스템을 제공합니다. AI 멘토 역할극을 지원합니다 |
+| 2 | 언어 학습 상황 파트너 | LLM이 서로 다른 역할을 맡아 대화하고, 발음 교정과 문화 배경 소개를 제공합니다. 몰입형 상황 시뮬레이션을 지원합니다 |
+| 3 | 호기심 충족 도우미 | 위키백과/지식 그래프를 연결하고, 복잡한 개념을 쉽게 설명하며, 관련 지식을 추천합니다. 호기심 기록을 제공합니다 |
+| 4 | 독서 노트 영감 자극 | 책 내용을 분석하고, 관점 추출과 연결, 사고 각도 추천을 제공합니다. 독서 노트 템플릿과 미화를 지원합니다 |
+| 5 | 지식 공유 분위기 조성 | 지식 카드를 자동 생성하고, 공유 문구를 최적화하며, 시각적으로 미화합니다. 소셜 공유 데이터 피드백을 제공합니다 |
+---
+
+## 10. 관계 운영
+
+> 💡 **핵심 관념**: 좋은 관계는 정성껏 운영해야 하지만, 정성이 꼭 복잡할 필요는 없습니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 친밀한 관계 소통 코치 | 감정 표현 템플릿 생성, 비폭력 대화 기술 안내, 갈등 해소 말투를 제공합니다. 관계 건강도를 평가합니다 |
+| 2 | 가족 돌봄 알림 도우미 | 중요한 날짜(생일/기념일)를 알려 주고, 돌봄 표현 제안과 가족 활동 추천을 제공합니다. 가족 앨범을 생성합니다 |
+| 3 | 우정 유지 분위기 연출가 | 친구 상호작용 기록, 공통 주제 추천, 원격 모임 조직을 제공합니다. 우정 타임라인과 추억을 생성합니다 |
+| 4 | 고백과 서프라이즈 기획자 | 개인화된 서프라이즈 방안, 선물 추천, 로맨틱한 말투 제안을 제공합니다. 실행 일정표와 알림을 제공합니다 |
+| 5 | 갈등 완화 분위기 안내 | 감정 냉각 말투, 입장 바꿔 생각하기 안내, 화해 단계 제안을 제공합니다. 관계 회복을 추적합니다 |
+
+---
+
+## 11. 반려동물 동행
+
+> 💡 **핵심 관념**: 반려동물은 가족이고, 그들의 동행은 기록되고 소중히 여겨질 가치가 있습니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 반려동물 의인화 일기 | 반려동물 행동을 분석하고, 1인칭 일기를 생성하며, 사진을 자동으로 매칭합니다. 반려동물 "친구 피드"를 제공합니다 |
+| 2 | 반려동물 행동 해석가 | 반려동물 행동 영상을 분석하고, 건강 경고와 훈련 제안을 제공합니다. 품종 특성 지식베이스를 제공합니다 |
+| 3 | 반려동물 동행 시간 기획 | 반려동물 활동 추천, DIY 장난감 튜토리얼, 반려동물 친화 장소 추천을 제공합니다. 반려동물 소셜 매칭을 지원합니다 |
+| 4 | 반려동물 추억 이야기 생성 | 사진과 영상을 선별하고, 타임라인 이야기를 생성하며, 음악을 매칭합니다. 추억책/영상을 자동 생성합니다 |
+| 5 | 초보 반려인 안심 가이드 | 단계별 돌봄 가이드, 자주 묻는 질문 답변, 긴급 상황 처리를 제공합니다. 초보자 커뮤니티 지원을 제공합니다 |
+
+---
+
+## 12. 재무 건강
+
+> 💡 **핵심 관념**: 재무 자유가 목표가 아니라, 재무 건강이 핵심입니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 소비 감정 알아차림 도우미 | 소비 기록을 분석하고, 감정-소비 연관 분석과 충동 소비 경고를 제공합니다. 대체 만족 제안을 제공합니다 |
+| 2 | 저축 목표 시각화 동기부여 | 목표 진척도를 시각화하고, 꿈의 장면을 렌더링하며, 이정표를 축하합니다. 저축 습관 형성 게임을 제공합니다 |
+| 3 | 재테크 지식 쉽게 배우기 | 자투리 지식 푸시, 장면화 사례 교육, 인터랙티브 질의응답을 제공합니다. 지식 검사와 인증서를 제공합니다 |
+| 4 | 재무 불안 완화 코치 | 재무 상태 건강 평가, 스트레스 관리 기술, 작은 행동 계획을 제공합니다. 재무 심리 상담을 지원합니다 |
+| 5 | 소액 투자 체험 게임 | 가상 투자 시뮬레이션, 위험 교육, 투자 포트폴리오 게임을 제공합니다. 실제 소액 투자 안내를 제공합니다 |
+
+---
+
+## 13. 커리어 발전
+
+> 💡 **핵심 관념**: 커리어는 정해진 궤도가 아니라 탐색할 수 있는 들판입니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 커리어 방황 동행자 | 직업 관심사 평가, 역량 점검, 업계 정보 추천을 제공합니다. 커리어 멘토 대화를 지원합니다 |
+| 2 | 일의 성취감 깨우기 코치 | 업무 성과를 기록하고, 가치를 추출하며, 성취를 시각화합니다. 동료/고객의 긍정 피드백을 수집합니다 |
+| 3 | 직장 소셜 분위기 도우미 | 직장 대화 주제 추천, 네트워킹 기술, 업계 행사 추천을 제공합니다. LinkedIn 콘텐츠 최적화를 지원합니다 |
+| 4 | 사이드 프로젝트 영감 자극기 | 기술-관심사-시장 요구를 매칭하고, 부업 사례 라이브러리와 시작 가이드를 제공합니다. 부업 커뮤니티 교류를 지원합니다 |
+| 5 | 면접 전 자신감 충전소 | 모의 면접, 자주 나오는 질문 준비, 자신감 향상 기술을 제공합니다. 이미지 제안을 제공합니다 |
+
+---
+
+## 14. 집 공간
+
+> 💡 **핵심 관념**: 집은 단지 거주하는 곳이 아니라, 마음이 머무는 곳입니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 집 공간 분위기 디자이너 | 공간 사진을 분석하고, 스타일과 가구/장식을 추천합니다. AR 미리보기를 제공합니다 |
+| 2 | 사계절 집 꾸미기 변화 가이드 | 계절 테마 추천, 수납과 전시 제안, 명절 장식 방안을 제공합니다. 쇼핑 목록을 생성합니다 |
+| 3 | 작은 집 공간 마법 | 공간 최적화 알고리즘, 다기능 가구 추천, 수납 팁을 제공합니다. 시각적 확장 팁을 제공합니다 |
+| 4 | 집 생활 의식감 창조자 | 일상 의식(아침/저녁/주말)을 설계하고, 의식 실행 알림을 제공합니다. 의식 효과 피드백을 제공합니다 |
+| 5 | 정리와 비움 심리 동행 | 물건의 감정적 가치를 평가하고, 정리와 비움 단계를 안내하며, 심리적 지원을 제공합니다. 기부/재활용 채널을 추천합니다 |
+
+---
+
+## 15. 음식과 요리
+
+> 💡 **핵심 관념**: 음식은 사랑의 언어이고, 요리는 사랑을 표현하는 방식입니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 혼밥 치유 요리 | 냉장고 식재료를 인식하고 간단한 레시피를 추천하며 단계별 안내를 제공합니다. 혼밥 플레이팅 미학을 제안합니다 |
+| 2 | 명절 식탁 분위기 설계 | 명절 테마 메뉴, 식탁 배치 방안, 분위기 조성 팁을 제공합니다. 손님 경험을 최적화합니다 |
+| 3 | 요리 기분 매칭 전문가 | 기분-음식 연관 알고리즘, 감정 조절 레시피, 위로 음식 추천을 제공합니다. 요리 치유 안내를 제공합니다 |
+| 4 | 요리 초보 자신감 세우기 | 아주 간단한 레시피, 실패 수습 팁, 자신감 세우기 말투를 제공합니다. 점진적 난이도 향상을 지원합니다 |
+| 5 | 음식 사진 분위기 가이드 | 음식 플레이팅 제안, 자연광 활용, 촬영 각도 안내를 제공합니다. 필터와 후보정 제안을 제공합니다 |
+
+---
+
+## 16. 착장과 스타일
+
+> 💡 **핵심 관념**: 착장은 자기표현이고, 스타일은 내면의 외적 표현입니다.
+
+| 번호 | 앱 장면 이름 | 앱 장면 기능 |
+| :--: | ------------ | ------------ |
+| 1 | 오늘의 착장 무드보드 | 날씨/상황/기분을 종합해 추천하고, 가상 착장을 제공하며, 코디 영감을 제공합니다. 옷장 관리를 지원합니다 |
+| 2 | 캡슐 옷장 코디 전문가 | 옷장을 점검하고, 아이템 코디 조합과 한 옷 여러 번 입기 방안을 제공합니다. 쇼핑 제안(빈틈 채우기)을 제공합니다 |
+| 3 | 개인 스타일 탐색 여행 | 스타일 테스트, 참고 아이콘 추천, 스타일 진화 경로를 제공합니다. 자신감 구축을 돕습니다 |
+| 4 | 헌 옷 새롭게 입기 크리에이터 | 헌 옷 리폼 영감, 새로운 코디 방식, 액세서리 포인트 팁을 제공합니다. 지속 가능한 패션 관념을 제시합니다 |
+| 5 | 특별한 자리 스타일링 컨설턴트 | 자리별 드레스 코드 해석, 스타일링 방안 생성, 메이크업과 헤어 제안을 제공합니다. 전체 스타일링 조화를 돕습니다 |
+
+---
+
+## C 사이드 제품을 설계하는 핵심 마음가짐
+
+### 1. "기능"에서 "감정"으로
+
+B 사이드 제품은 "이 기능이 어떤 문제를 해결하는가"에 관심을 두고, C 사이드 제품은 "이 기능이 어떤 느낌을 가져오는가"에 관심을 둡니다.
+
+| B 사이드 사고 | C 사이드 사고 |
+|---------|---------|
+| 효율 향상 | 좋아하는 일을 할 시간을 아껴 줌 |
+| 비용 절감 | 돈 하나하나가 아깝지 않게 함 |
+| 고통 지점 해결 | 좋은 경험 창조 |
+| 기능 완비 | 느낌이 제대로 닿음 |
+
+### 2. 분위기를 만드는 세 층위
+
+**감각층**: 시각, 청각, 촉각의 설계
+- 따뜻한 색
+- 편안한 소리
+- 매끄러운 모션
+
+**감정층**: 감정의 공명과 안내
+- 사용자의 마음 이해하기
+- 감정적 지원 제공하기
+- 긍정적 감정 만들기
+
+**의미층**: 가치의 인정과 소속
+- 사용자가 이해받고 있다고 느끼게 하기
+- 소속감 만들기
+- 행동에 의미 부여하기
+
+### 3. 심리적 암시의 힘
+
+C 사이드 제품의 문구와 설계는 모두 심리적 암시를 전달합니다.
+
+- **긍정 암시**: "이미 충분히 잘하고 있어요", "천천히 해도 괜찮아요"
+- **소속 암시**: "많은 사람이 당신과 같아요", "당신은 혼자가 아니에요"
+- **성장 암시**: "모든 시도는 진전이에요", "당신은 더 좋아지고 있어요"
+
+### 4. 사용자가 더 나은 자신이 되게 하기
+
+최고의 C 사이드 제품은 사용자를 바꾸는 것이 아니라, 사용자가 되고 싶은 자신이 되도록 돕습니다.
+
+- "당신은 ...해야 한다"가 아니라 "당신은 ...할 수 있다"
+- "반드시 ...해야 한다"가 아니라 "원한다면 ..."
+- "아직 부족하다"가 아니라 "이미 ..."
+
+---
+
+> 🌟 **기억하세요**: C 사이드 사용자가 사는 것은 기능이 아니라 느낌이고, 도구가 아니라 동행이며, 서비스가 아니라 이해입니다.
diff --git a/docs/ko-kr/stage-1/appendix-double-diamond/index.md b/docs/ko-kr/stage-1/appendix-double-diamond/index.md
index 0041ba4..38e76d5 100644
--- a/docs/ko-kr/stage-1/appendix-double-diamond/index.md
+++ b/docs/ko-kr/stage-1/appendix-double-diamond/index.md
@@ -1,84 +1,545 @@
---
-title: 'Double Diamond: 올바른 문제를 찾고 제대로 해결하기'
-description: '제품 기획에서 자주 쓰는 Double Diamond 모델을 AI 프로토타입 작업에 적용하는 방법입니다.'
+title: 'Double Diamond: 올바른 일을 먼저 하고, 그 일을 제대로 하기'
+description: '제로 베이스 독자를 위한 Double Diamond 입문 글입니다. Discover, Define, Develop, Deliver 네 단계를 이해하고, 문제가 명확해지기 전에 서둘러 프로토타입을 만드는 일을 피합니다.'
---
-# Double Diamond: 올바른 문제를 찾고 제대로 해결하기
+
-Double Diamond는 제품 문제를 다룰 때 유용한 사고 모델입니다.
+# Double Diamond: 올바른 일을 먼저 하고, 그 일을 제대로 하기
-핵심은 두 번 넓히고 두 번 좁히는 것입니다.
+
-1. 문제를 넓게 탐색한다.
-2. 진짜 풀 문제를 좁힌다.
-3. 해결책을 넓게 탐색한다.
-4. 첫 구현안을 좁힌다.
+## 본 장 안내
-## 1. Discover: 문제 넓히기
+
-처음부터 솔루션을 정하지 않습니다. 사용자의 상황과 불편을 넓게 수집합니다.
+많은 사람이 처음 제품을 만들 때 가장 쉽게 빠지는 함정은 "노력이 부족하다"가 아니라 너무 빨리 해결책으로 들어가는 것입니다.
-질문 예시:
+머릿속에 방향이 하나 떠오르자마자 페이지를 어떻게 그릴지, 버튼을 어디에 둘지, AI를 붙일지, 로그인/회원가입을 만들지, 어떤 도구로 프로토타입을 그릴지 생각하기 시작합니다. 한참 바쁘게 움직인 뒤에야 가장 근본적인 문제가 전혀 정리되지 않았다는 것을 깨닫습니다. 사용자가 정말 이 고통을 가지고 있는가? 지금 이 문제를 해결할 가치가 있는가? 프로젝트를 밀고 있다고 생각하지만, 사실은 잘못된 방향으로 열심히 가속하고 있을 뿐입니다.
-- 언제 이 문제가 생기나요?
-- 지금은 어떻게 해결하나요?
-- 가장 귀찮은 부분은 어디인가요?
-- 이 문제 때문에 잃는 시간이나 비용은 무엇인가요?
-- 비슷한 문제가 또 있나요?
+Double Diamond 모델은 바로 이런 상황을 피하기 위해 쓰입니다.
-## 2. Define: 문제 좁히기
+가장 가치 있는 알림은 이것입니다. **"올바른 일을 하는 것"과 "그 일을 제대로 하는 것"은 완전히 다른 두 단계입니다.** 문제가 명확해지기도 전에 프로토타입으로 달려가면, 보통 잘못된 방향을 더 완전하게 만들 뿐입니다.
-수집한 내용을 바탕으로 첫 버전에서 풀 문제를 하나로 좁힙니다.
+
-좋은 문제 정의:
+::: info 최소 SOP
+**목적**: 읽고 나면 제품을 만들 때 언제 먼저 문제를 생각해야 하고, 언제부터 솔루션과 프로토타입을 생각해야 하는지 더 명확해집니다. 처음부터 잘못된 방향을 매우 성실하게 만드는 일을 피합니다.
+
+**행동 항목**: `Discover → Define → Develop → Deliver` 네 단계를 따라 내려가며, 각 단계에서는 현재 단계에서 해야 할 일만 합니다.
+
+**결과**: 더 명확한 문제 정의, 비교 가능한 몇 가지 솔루션, 검증 가능한 최소 버전을 얻게 됩니다.
+
+**키워드 이동**: [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란 정확히 무엇인가](#top-dd)
+
+Double Diamond는 영국 **Design Council**이 널리 알린 고전적인 디자인 프로세스 프레임워크입니다. 하나의 완전한 디자인과 혁신 과정을 연속된 두 개의 다이아몬드 모양으로 그립니다.
+
+"다이아몬드"인 이유는 각 다이아몬드가 서로 반대지만 모두 중요한 두 가지 동작을 포함하기 때문입니다.
+
+- **발산**: 먼저 시야를 열고 더 많은 가능성을 본다.
+- **수렴**: 다시 범위를 좁혀 판단하고 취사선택한다.
+
+전체 과정은 네 단계입니다.
+
+1. **Discover**: 사용자, 문제, 환경, 시장을 넓게 이해한다.
+2. **Define**: 많은 정보 속에서 진짜 해결할 가치가 있는 핵심 문제를 추출한다.
+3. **Develop**: 핵심 문제를 둘러싸고 여러 해결책을 발산한다.
+4. **Deliver**: 더 적합한 해결책을 선별하고, 프로토타입을 만들고, 테스트하고 전달한다.
+
+이 네 단계를 가장 기억하기 쉬운 한 문장으로 압축하면 이렇습니다.
+
+- **첫 번째 다이아몬드**: 정확히 어떤 문제를 해결해야 하는지 먼저 파악한다.
+- **두 번째 다이아몬드**: 그다음 어떤 방법으로 해결할지 결정한다.
+
+이것이 방금 말한 아주 정확한 문장입니다.
+
+- **첫 번째 다이아몬드: 올바른 일을 하기**
+- **두 번째 다이아몬드: 그 일을 제대로 하기**
+
+## 2. 왜 Double Diamond는 초보자에게 특히 적합한가
+
+초보자가 제품을 만들 때 가장 흔한 리듬은 보통 이렇습니다.
+
+- 아이디어가 떠오른다.
+- 이 방향이 멋지다고 느낀다.
+- 바로 프로토타입을 그리기 시작한다.
+- 만들다 보니 기능이 점점 많아진다.
+- 마지막에는 자신이 정확히 어떤 문제를 해결하는지 모르게 된다.
+
+Double Diamond의 가치는 프로세스를 복잡하게 만드는 데 있지 않습니다. **"문제 이해"와 "솔루션 설계"를 강제로 분리하게 하는 데** 있습니다.
+
+이 말은 평범하게 들리지만 실제로는 매우 중요합니다. 실패한 제품의 상당수는 실행이 성실하지 않아서가 아니라 다음 이유 때문입니다.
+
+- 문제를 잘못 골랐다.
+- 사용자를 오해했다.
+- 해결책을 너무 일찍 고정했다.
+- 방향 검증 없이 세부 다듬기에 많은 시간을 썼다.
+
+Double Diamond는 계속해서 이렇게 상기시킵니다.
+
+- 생각이 잘 이어진다고 해서 문제가 성립했다고 기본 가정하지 마세요.
+- 해결책을 만들 수 있다고 해서 그것이 만들 가치가 있다고 기본 가정하지 마세요.
+- 프로토타입이 완성되어 보인다고 해서 사용자가 정말 필요로 할 것이라고 기본 가정하지 마세요.
+
+
+## [3. 첫 번째 다이아몬드: 올바른 일을 하기](#top-dd)
+
+첫 번째 다이아몬드는 **문제 자체**에 집중하며, 해결책에 집중하지 않습니다.
+
+한 문장으로 이해하면 이렇습니다. **서둘러 만들지 말고, 정말 만들 가치가 있는지 먼저 파악하세요.**
+
+### 3.1 Discover: 먼저 문제 공간을 열기
+
+Discover 단계의 핵심 과제는 **넓게 조사하는 것**이지, 빠르게 결론을 내리는 것이 아닙니다.
+
+이 단계에서 보통 하는 일은 다음과 같습니다.
+
+- 사용자가 실제 장면에서 어떻게 행동하는지 보기
+- 잠재 사용자를 인터뷰해 최근 언제 문제를 만났는지 이해하기
+- 지금은 어떻게 임시로 해결하고 있는지 관찰하기
+- 경쟁 제품과 대체 방안이 어떻게 처리하는지 보기
+- 시장, 프로세스, 제약, 상하류 정보를 수집하기
+
+많은 사람이 Discover를 "자료를 좀 더 많이 보는 것"으로 오해합니다. 사실 더 중요한 것은 **사람과 장면을 이해하는 것**이지, 정보만 잔뜩 검색하는 것이 아닙니다.
+
+예를 들어 "AI가 회의록 정리를 도와주는 도구"를 만들고 싶다면, Discover 단계에서 더 집중해야 할 것은 다음입니다.
+
+- 사용자가 회의 후 정확히 어느 부분에서 가장 고통스러워하는지
+- 기록이 어려운지, 정리가 어려운지, 동기화가 어려운지
+- 지금은 직접 쓰는지, 인턴에게 시키는지, 녹음을 다시 듣는지, 아예 정리하지 않는지
+- 어떤 회의 장면에서 회의록이 가장 필요하고, 어떤 장면에서는 전혀 필요 없는지
+
+이 단계에서 가장 중요한 목표는 답을 내는 것이 아니라, **너무 일찍 자신이 이미 답을 알고 있다고 착각하지 않는 것**입니다.
+
+### 3.2 Define: 많은 정보 속에서 핵심 문제 추출하기
+
+Discover가 시야를 여는 것이라면, Define은 수렴을 시작하는 것입니다.
+
+Define 단계에서 해야 할 일은 모든 관찰을 그대로 보존하는 것이 아니라, 다음을 묻는 것입니다.
+
+- 진짜로 가장 우선 해결할 가치가 있는 문제는 무엇인가?
+- 어떤 문제가 가장 자주 나타나고, 가장 아프고, 가장 가치 있는가?
+- 첫 번째 버전은 정확히 어떤 장면 하나만 겨냥할 것인가?
+
+이 단계의 핵심은 넓은 주제를 명확한 문제 정의로 수렴하는 것입니다.
+
+처음에는 이렇게 말할 수 있습니다.
+
+> 회의 효율을 높이는 AI 도구를 만들고 싶다.
+
+Define 단계에 이르면 더 좋은 표현은 이렇게 바뀔 수 있습니다.
+
+> 우리는 먼저 프로젝트형 팀이 30~60분짜리 협업 회의가 끝난 뒤, 10분 안에 할 일, 담당자, 마감일이 포함된 회의록을 만들지 못하는 문제를 해결한다.
+
+이제 문제가 명확해지기 시작합니다.
+
+- 사용자는 누구인가
+- 장면은 무엇인가
+- 막히는 지점은 무엇인가
+- 성공 기준은 무엇인가
+
+Define의 본질은 **"문제가 많다"에서 "이번에는 어떤 문제 하나를 먼저 해결할 것인가"로 수렴하는 것**입니다.
+
+## 4. 두 번째 다이아몬드: 그 일을 제대로 하기
+
+첫 번째 다이아몬드를 완료한 뒤에야 진정으로 두 번째 다이아몬드에 들어가기에 적합합니다. 이때 해결하려는 것은 더 이상 모호한 방향이 아니라 수렴된 구체적인 문제이기 때문입니다.
+
+### 4.1 Develop: 핵심 문제를 중심으로 솔루션 발산하기
+
+Develop 단계의 핵심은 **같은 문제를 중심으로 여러 가능한 솔루션을 탐색하는 것**입니다.
+
+주의할 점은 여기서의 발산은 Discover 단계와 다릅니다.
+
+- Discover의 발산은 문제 공간을 탐색하는 것입니다.
+- Develop의 발산은 해결책 공간을 탐색하는 것입니다.
+
+회의록 예시를 계속 쓰면, Develop 단계에서는 다음을 생각할 수 있습니다.
+
+- 웹 도구를 만들 것인가, 회의 플러그인을 만들 것인가
+- 녹음 업로드 후 처리할 것인가, 실시간 기록할 것인가
+- 요약만 할 것인가, 할 일 추출에 집중할 것인가
+- 개인 효율을 강조할 것인가, 팀 동기화를 강조할 것인가
+- 사용자가 자유롭게 편집하게 할 것인가, 구조화된 템플릿을 바로 출력할 것인가
+
+이 단계는 브레인스토밍에 매우 적합하고, 팀과 함께 솔루션을 넓히기에도 좋습니다.
+
+하지만 전제가 있습니다. **모든 솔루션은 이미 정의된 같은 문제를 섬겨야 합니다.**
+문제가 명확히 정의되지 않았다면 Develop은 쉽게 다시 기능이 난무하는 상태가 됩니다.
+
+### 4.2 Deliver: 솔루션 선택, 프로토타입, 테스트, 전달
+
+Deliver 단계는 두 번째 다이아몬드 안의 수렴 단계입니다.
+
+이때 해야 할 일은 더 많이 상상하는 것이 아니라 판단을 시작하는 것입니다.
+
+- 어떤 솔루션이 현재 단계에 가장 적합한가
+- 어떤 버전이 가장 작지만 가장 유용한가
+- 어떤 기능은 반드시 먼저 해야 하고, 어떤 기능은 나중으로 미뤄도 되는가
+- 어떻게 프로토타입을 만들고, 테스트하고, 작은 범위에서 검증할 것인가
+
+많은 사람이 Deliver를 "출시"와 같다고 생각합니다. 사실 더 정확한 뜻은 **하나의 솔루션을 테스트 가능하고, 검증 가능하며, 반복 개선 가능한 것으로 바꾸는 것**입니다.
+
+그것은 다음일 수 있습니다.
+
+- 저충실도 흐름도 한 장
+- Figma 프로토타입
+- 실행 가능한 MVP
+- 소규모 사용자 테스트
+- 실제 피드백 이후의 반복 개선 버전
+
+Deliver의 핵심은 "완벽한 전달"이 아니라 **가능한 한 빨리 솔루션을 실제 환경에 넣어 검증하는 것**입니다.
+
+## 5. 가장 기억하기 쉬운 대조표
+
+네 단계를 자꾸 헷갈린다면 아래 버전을 그대로 기억하세요.
+
+| 단계 | 무엇을 하는가 | 키워드 | 흔한 산출물 |
+| --- | --- | --- | --- |
+| Discover | 문제 이해 | 조사, 관찰, 인터뷰, 정보 수집 | 사용자 인사이트, 장면 메모, 문제 목록 |
+| Define | 문제 정의 | 추출, 집중, 취사선택, 문제 다시 쓰기 | 문제 정의, 우선순위, MVP 진입점 |
+| Develop | 솔루션 탐색 | 브레인스토밍, 비교, 공동 창작, 프로토타입 구상 | 솔루션 목록, 흐름 스케치, 프로토타입 방향 |
+| Deliver | 솔루션 검증 | 프로토타입, 테스트, 반복 개선, 전달 | 프로토타입, 테스트 피드백, 최적화 버전 |
+
+더 압축하면 이렇습니다.
+
+- **Discover / Define**: "올바른 일을 하기"를 해결한다.
+- **Develop / Deliver**: "그 일을 제대로 하기"를 해결한다.
+
+## 6. Double Diamond의 가장 흔한 오해
+
+### 6.1 Discover도 하지 않고 바로 Deliver하기
+
+가장 흔한 경우입니다. 많은 사람이 아이디어가 생기자마자 프로토타입을 그리고, PRD를 쓰고, 모델을 붙이고, 페이지를 만듭니다.
+
+문제는 당신이 성실하지 않다는 것이 아니라, 해결할 가치가 있는 문제인지 아직 확인하지 않았을 수 있다는 점입니다.
+
+### 6.2 Discover는 오래 하지만 끝내 Define하지 않기
+
+또 다른 극단은 계속 조사하고, 계속 자료를 보고, 계속 인터뷰하지만 좀처럼 수렴하지 못하는 것입니다.
+
+Double Diamond는 무한 발산을 하라는 뜻이 아닙니다. 발산 후에는 반드시 판단과 취사선택으로 들어가야 한다고 알려 주는 것입니다.
+
+### 6.3 Define 이후 몰래 문제를 바꾸기
+
+많은 팀은 Develop 단계에서 어떤 솔루션이 더 쉽게 만들 수 있다는 이유로, 기존 솔루션에 맞도록 문제 정의를 거꾸로 수정합니다.
+
+이것은 위험합니다. 문제를 해결하는 것이 아니라 자신이 선호하는 솔루션을 정당화하고 있을 수 있기 때문입니다.
+
+### 6.4 Deliver를 "크고 완전한 출시"로 오해하기
+
+Deliver는 완전한 제품을 모두 만들어야 끝난다는 뜻이 아닙니다. 많은 경우 테스트 가능한 프로토타입 하나, 실제 사용자 테스트 한 번이면 이미 좋은 deliver입니다.
+
+## 7. AI 제품에서 Double Diamond는 어떻게 쓰나
+
+AI 제품은 특히 "능력 우선" 함정에 빠지기 쉽습니다. 모델 능력이 너무 매력적으로 보이기 때문입니다. 당신은 곧장 이런 생각을 하고 싶어질 수 있습니다.
+
+- 멀티모달을 붙일까
+- Agent를 만들까
+- 워크플로우를 넣을까
+- 음성, 이미지, 웹 검색을 연결할까
+
+하지만 Double Diamond는 먼저 이렇게 묻게 합니다.
+
+- 사용자는 정확히 어느 단계에서 정말 막혀 있는가
+- 이 막힘은 반드시 AI가 있어야 해결되는가
+- AI를 쓰지 않는다면 기존 방법은 정확히 어디가 가장 나쁜가
+- AI가 들어간 뒤 가장 핵심적인 진전은 무엇인가
+
+이것은 흔한 상황을 피하게 해 줍니다. **능력은 강한데 가치는 약한 상황**입니다.
+
+실용적인 순서는 다음과 같습니다.
+
+1. Discover 단계에서 사용자가 지금 어떻게 과제를 처리하는지 관찰한다.
+2. Define 단계에서 가장 아픈 장면 하나를 명확한 문제 정의 한 문장으로 쓴다.
+3. Develop 단계에서 어떤 AI 기능이 이 문제를 가장 잘 섬기는지 비교한다.
+4. Deliver 단계에서 최소 버전을 만들고 실제 사용자에게 테스트하게 한다.
+
+## 8. 바로 적용할 수 있는 Double Diamond 템플릿
+
+자기 제품을 만들고 있다면 이 순서대로 먼저 써 보세요.
+
+### Discover
+
+- 내가 관찰한 사용자는 누구인가?
+- 그들이 최근 이 문제를 만난 것은 언제인가?
+- 지금은 어떻게 해결하고 있는가?
+- 가장 짜증 나고, 느리고, 불안한 지점은 무엇인가?
+
+### Define
+
+- 이 문제들 중 가장 우선 해결할 가치가 있는 것은 무엇인가?
+- 어떤 장면이 가장 빈번하거나 가장 핵심적인가?
+- 첫 번째 버전은 누구만, 무엇만 섬길 것인가?
+- 성공적으로 해결되면 사용자의 상태는 어떻게 변하는가?
+
+### Develop
+
+- 이 문제에 대해 어떤 가능한 솔루션이 있는가?
+- 어떤 솔루션이 가장 가볍고, 빠르고, 검증하기 쉬운가?
+- 반드시 해야 할 것은 무엇이고, 나중으로 미룰 것은 무엇인가?
+
+### Deliver
+
+- 이 방향을 검증하기 위해 가장 작게 무엇을 전달할 수 있는가?
+- 흐름도인가, 프로토타입인가, MVP인가?
+- 누구에게 테스트해야 하는가?
+- 테스트 후 계속할지, 수정할지, 포기할지는 어떻게 판단할 것인가?
+
+## 9. 제로 베이스도 이해할 수 있는 예시
+
+"대학생의 취업 이력서 준비를 돕는 AI 도구"를 만들고 싶다고 가정해 봅시다.
+
+많은 사람은 처음부터 두 번째 다이아몬드로 들어가 이런 생각을 시작합니다.
+
+- 원클릭 미화를 넣을까
+- 지능형 문장 개선을 넣을까
+- JD 자동 매칭을 할까
+- 자기소개서를 생성할까
+
+하지만 Double Diamond를 따르면 더 좋은 과정은 이렇습니다.
+
+### 첫 번째 다이아몬드
+
+**Discover**
+
+- 취업 준비생에게 최근 이력서를 고친 것이 언제인지 묻는다.
+- 그들이 이전 이력서를 어떻게 새 버전으로 바꾸는지 본다.
+- 가장 어려운 것이 "쓸 줄 모름"인지, "고칠 줄 모름"인지, "좋은지 판단할 줄 모름"인지 이해한다.
+
+**Define**
+
+- 마지막에는 더 구체적인 문제로 수렴한다.
+- "대학생은 이력서를 만들 줄 모른다"가 아니다.
+- "처음 인턴십에 지원하는 학생은 기존 경험을 직무에 맞는 표현으로 바꾸기 어려워 지원을 미룬다"이다.
+
+### 두 번째 다이아몬드
+
+**Develop**
+
+- 몇 가지 솔루션을 생각한다. 템플릿 라이브러리, AI 문장 개선, 직무 대조, 이력서 점수화, 사례 참고.
+
+**Deliver**
+
+- 첫 버전은 "직무 설명에 따라 경험 bullet point를 바꿔 쓰기"만 만든다.
+- 학생 5명에게 써 보게 하고, 더 빨리 첫 버전의 이력서를 제출하게 되는지 본다.
+
+첫 번째 다이아몬드를 탄탄하게 하면 두 번째 다이아몬드가 훨씬 명확해진다는 것을 알 수 있습니다.
+
+## 10. 정리
+
+Double Diamond의 가장 강한 힘은 혼란스러운 덩어리를 네 개의 더 명확한 동작으로 나눠 준다는 데 있습니다.
+
+- 먼저 발산해 문제를 이해한다.
+- 다시 수렴해 문제를 정의한다.
+- 다시 발산해 솔루션을 탐색한다.
+- 마지막으로 수렴해 솔루션을 전달한다.
+
+이 모델은 당신을 느리게 만들기 위한 것이 아닙니다. **바빠 보이지만 사실 방향이 틀린 수많은 우회로를 줄이기 위한 것**입니다.
+
+특히 AI 시대에는 만드는 속도가 점점 빨라지기 때문에 Double Diamond가 오히려 더 중요해집니다. "만드는 것"이 점점 쉬워질수록 진짜 희소한 능력은 이렇게 바뀌기 때문입니다. **해결할 가치가 있는 문제를 풀고 있는가, 그리고 그것을 적합한 방식으로 풀고 있는가.**
+
+이 한 문장만 기억하면 됩니다.
+
+**올바른 일을 먼저 하고, 그 일을 제대로 하세요.**
+
+
+## [11. AI로 Double Diamond 흐름을 실행하는 방법](#top-dd)
+
+Double Diamond 자체는 AI 도구가 아니지만, AI는 네 단계에서 "가속기" 역할을 하기에 매우 적합합니다. 핵심은 AI가 대신 결정하게 하는 것이 아니라, 시야 확장, 정보 정리, 솔루션 비교, 검증 자료 생성을 돕게 하는 것입니다.
+
+### 11.1 Discover 단계에서 AI로 정보 밑작업 한 번 하기
+
+정식 인터뷰와 조사를 시작하기 전에 AI에게 가벼운 문제 스캔을 맡길 수 있습니다. 예를 들면 다음입니다.
+
+- 시장에서 흔한 대체 방안은 무엇인가
+- 사용자가 공개 커뮤니티에서 가장 자주 불평하는 것은 무엇인가
+- 이 문제는 어떤 장면과 사람군에서 자주 나타나는가
+- 기존 제품은 보통 무엇을 놓치고 있는가
+
+이 단계는 실제 조사를 대체할 수 없지만, 문제 지도를 빠르게 만드는 데 매우 적합합니다.
+
+아주 간단한 초보자 입력은 이렇게 쓸 수 있습니다.
```text
-온라인 강의를 준비하는 1인 강사는 매주 강의 내용을 퀴즈로 바꿔야 하지만,
-문항과 해설을 만드는 데 시간이 많이 걸린다.
+대학생 이력서 수정을 도와주는 도구를 만들고 싶어.
+기능을 생각해 주지 말고, 이 문제에서 사람들이 가장 자주 겪는 어려움이 무엇인지 먼저 봐 줘.
```
-나쁜 문제 정의:
+AI는 이렇게 출력할 수 있습니다.
```text
-교육을 혁신한다.
+초기 문제 지도:
+
+1. 어떤 경험을 써야 할지 모름
+2. 직무에 맞게 어떻게 수정해야 할지 모름
+3. 여러 번 고쳤는데도 충분히 좋은지 확신하지 못함
+4. 다른 사람에게 봐 달라고 해야 하지만 매번 부탁하기 불편함
+5. 확신이 없어서 계속 지원을 미룸
```
-## 3. Develop: 해결책 넓히기
+이 출력의 역할은 결론을 대신 내려 주는 것이 아니라, Discover에 더 빨리 들어가게 해 주는 것입니다.
-하나의 문제에 대해 여러 해결책을 생각합니다.
+### 11.2 Define 단계에서 AI에게 문제 정의 수렴을 돕게 하기
-- 퀴즈 자동 생성기
-- 강의 요약 도구
-- 수강생 질문 분류 도구
-- 복습 카드 생성기
-- 시험지 템플릿 생성기
-
-AI에게도 여러 안을 요청합니다.
+많은 사람이 자료를 한가득 모은 뒤 가장 어려워하는 것은 문제를 진짜 명확한 한 문장으로 줄이는 일입니다. 조사 메모를 AI에게 주고 몇 가지 후보 문제 정의로 압축하게 할 수 있습니다.
```text
-아래 문제를 해결할 수 있는 제품 아이디어를 10개 제안해 줘.
-각 아이디어는 첫 버전으로 만들 수 있을 만큼 작아야 해.
+아래는 Discover 단계에서 모은 사용자 피드백과 조사 메모야.
+[내용 붙여넣기]
+
+다음 세 가지를 도와줘.
+1. 가장 자주 나타나는 문제 패턴을 요약
+2. 문제 빈도, 고통감, 검증 가능성을 기준으로 우선 해결할 가치가 있는 문제 3개 정리
+3. 각 문제를 구체적인 문제 정의 한 문장으로 작성
```
-## 4. Deliver: 첫 구현안 좁히기
+이렇게 하면 "문제가 너무 많다"에 머무르지 않고 Define으로 들어가기 쉬워집니다.
-첫 구현은 가장 작고 검증 가능한 형태로 좁힙니다.
-
-선택 기준:
-
-- 하루나 이틀 안에 만들 수 있는가?
-- 입력과 출력이 명확한가?
-- 사용자가 결과를 바로 평가할 수 있는가?
-- AI 기능 하나로 가치가 만들어지는가?
-
-## 과제
-
-내 아이디어를 Double Diamond로 정리하세요.
+입력을 아주 간단하게 써도 됩니다.
```text
-Discover: 관찰한 문제 5개
-Define: 이번에 풀 문제 1개
-Develop: 가능한 솔루션 5개
-Deliver: 첫 프로토타입 범위 1개
+지금 모은 문제는 이거야.
+1. 다들 이력서에 무엇을 써야 할지 모름
+2. 다들 어떻게 고쳐야 할지 모름
+3. 다들 잘 고친 건지 확신하지 못해 지원을 망설임
+
+첫 버전에서 어떤 문제를 먼저 해결하는 게 가장 적합한지 봐 줘.
```
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+우선 해결을 추천하는 문제:
+
+"처음 인턴십에 지원하는 학생은 이력서가 이미 지원 가능한 수준인지 확신하지 못해 반복 수정하고 지원을 미룬다."
+
+이유:
+1. 문제가 더 구체적이다.
+2. 지연 행동을 설명할 수 있다.
+3. 작은 버전을 설계해 검증하기 쉽다.
+```
+
+이런 출력은 유용합니다. 흐릿한 문제들 속에서 MVP 출발점에 가까운 정의 하나를 수렴하게 해 주기 때문입니다.
+
+### 11.3 Develop 단계에서 AI로 여러 솔루션 발산하기
+
+많은 사람은 문제를 정의하자마자 머릿속에 처음 떠오른 솔루션만 바라봅니다. 이 단계에서 AI는 강제로 발산시키는 데 매우 적합합니다.
+
+```text
+핵심 문제를 이렇게 정의했어: [문제 정의]
+최종 답을 하나만 주지 말고, 아래 각도에서 2~3가지 해결 방향을 제안해 줘.
+1. 가장 가벼운 MVP
+2. 수요 검증에 가장 적합한 방안
+3. 경험 개선에 가장 적합한 방안
+4. AI에 의존하지 않는 방안
+5. AI에 의존하는 방안
+마지막에는 각 방안의 장점, 위험, 검증 비용을 비교해 줘.
+```
+
+이렇게 하면 너무 일찍 하나의 솔루션에 묶이지 않게 됩니다.
+
+간단한 입력은 이렇게 쓸 수 있습니다.
+
+```text
+현재 문제 정의는 이거야.
+"대학생은 이력서가 이미 지원 가능한지 확신하지 못해 계속 미루고 있다."
+
+서로 다른 해결책 4가지를 생각해 줘. 하나만 주지 마.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+방안 1: 이력서 지원 가능 체크리스트
+방안 2: 직무 설명에 맞춘 맞춤형 문장 개선
+방안 3: 사용자가 이력서를 업로드하면 위험 알림 제공
+방안 4: 우수 사례 대조를 제공해 사용자가 차이를 판단하도록 도움
+```
+
+이때부터 "솔루션 비교"로 들어가기 쉬워지고, 처음부터 AI 문장 개선 하나만 바라보지 않게 됩니다.
+
+### 11.4 Deliver 단계에서 AI로 프로토타입 문구와 테스트 자료 생성하기
+
+Deliver 단계에 들어가면 AI는 다음 작업을 빠르게 처리하는 데 매우 적합합니다.
+
+- 저충실도 프로토타입의 페이지 문구 생성
+- 사용자 테스트 스크립트 정리
+- 비교 가능한 여러 버전의 제목, 버튼, 설명문 생성
+- 테스트 후 피드백과 문제 목록 정리
+
+예를 들어 AI에게 20분 사용자 테스트 스크립트를 만들게 하거나, 사용자 5명의 피드백을 "계속 진행 / 방향 수정 / 중단" 판단 근거로 정리하게 할 수 있습니다.
+
+가장 작은 입력 예시는 다음입니다.
+
+```text
+아주 간단한 프로토타입을 만들었어.
+사용자가 이력서를 업로드하면, 시스템이 어떤 부분이 아직 지원하기에 적합하지 않은지 알려 줘.
+
+15분짜리 사용자 테스트 스크립트를 만들어 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+15분 테스트 스크립트:
+
+1. 먼저 사용자에게 최근 이력서 지원 경험을 설명하게 한다.
+2. 사용자가 독립적으로 이력서 업로드를 완료하게 한다.
+3. 피드백 결과를 이해하는지 관찰한다.
+4. 질문: 이 안내 중 어떤 것이 가장 도움이 되고, 어떤 것이 헷갈렸나요?
+5. 질문: 다음 지원 전에 다시 쓰고 싶나요?
+```
+
+이 출력은 실용적입니다. "프로토타입을 만들었다"에서 "다음에는 어떻게 테스트할까"로 넘어가게 해 주기 때문입니다.
+
+### 11.5 AI에게 "단계 문지기" 역할을 맡기기
+
+Double Diamond에서 가장 흔한 문제는 사람이 단계를 건너뛰는 것입니다. AI에게 직접 문지기 역할을 맡겨 현재 어느 단계에 있는지 알려 달라고 할 수 있습니다.
+
+```text
+제품 프로세스 코치 역할을 해 줘.
+아래는 현재 내 프로젝트 상태야: [설명]
+내가 지금 Discover, Define, Develop, Deliver 중 어디에 더 가까운지 판단해 줘.
+그리고 알려 줘.
+1. 내가 너무 일찍 다음 단계로 넘어갔는지
+2. 현재 단계에서 가장 보충해야 할 행동은 무엇인지
+3. 지금은 먼저 하지 말아야 할 일은 무엇인지
+```
+
+초보자에게 특히 유용합니다. "문제를 아직 명확히 생각하지 않았는데 프로토타입을 그리기 시작하는" 일이 매우 쉽게 일어나기 때문입니다.
+
+## 📚 Assignments
+
+위 내용을 바탕으로 다음 과제를 완료하세요.
+
+1. 최근 만들고 싶은 제품 아이디어 하나를 고르고, Discover, Define, Develop, Deliver 네 단계 초안을 작성하세요.
+2. Define 단계에서 문제를 구체적인 한 문장으로 강제로 줄이세요.
+3. Develop 단계에서 처음 떠오른 방법 하나만 바라보지 말고, 최소 3가지 다른 방안을 나열하세요.
+4. Deliver 단계에서 일주일 안에 전달 가능한 최소 검증 버전을 작성하세요.
+
+## 더 읽어 보기
+
+이 글은 주로 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/)
+
diff --git a/docs/ko-kr/stage-1/appendix-idea-sources/index.md b/docs/ko-kr/stage-1/appendix-idea-sources/index.md
index 2408ad1..52bd5a1 100644
--- a/docs/ko-kr/stage-1/appendix-idea-sources/index.md
+++ b/docs/ko-kr/stage-1/appendix-idea-sources/index.md
@@ -1,84 +1,302 @@
---
-title: '아이디어는 어디서 찾을까'
-description: '초보자가 AI 제품 아이디어를 찾을 때 참고하기 좋은 출처와 조사 방법을 설명합니다.'
+title: '아이디어는 어디서 찾을까: 초보자에게 가장 적합한 참고 출처 3가지'
+description: '제로 베이스 독자를 위한 제품 아이디어 입문 글입니다. 바로 idea를 훑기 좋은 사이트, 트렌드 출처, 실제 비즈니스 출처와 VC 목록을 정리해, 링크 속에서 더 구체적인 방향을 빠르게 찾도록 돕습니다.'
---
-# 아이디어는 어디서 찾을까
+
-아이디어가 떠오르지 않을 때는 머릿속에서 억지로 짜내기보다 이미 사람들이 돈과 시간을 쓰는 곳을 관찰하는 편이 좋습니다.
+# 아이디어는 어디서 찾을까: 초보자에게 가장 적합한 참고 출처 3가지
-## 1. 이미 존재하는 앱 보기
+
-앱스토어, Product Hunt, Chrome Web Store, Notion 템플릿 마켓, SaaS 갤러리 등을 보면 사람들이 이미 어떤 문제를 해결하려 하는지 알 수 있습니다.
+## 본 장 안내
-볼 때는 기능만 보지 말고 다음을 함께 봅니다.
+
-- 누가 쓰는 앱인가?
-- 어떤 상황에서 쓰는가?
-- 리뷰에서 반복되는 불만은 무엇인가?
-- 너무 복잡해서 더 작은 버전으로 만들 수 있는가?
-- AI를 넣으면 시간이 줄어드는 부분은 어디인가?
+많은 사람이 첫 단계에서 막힙니다. 완전히 영감이 없어서가 아니라, 많은 내용을 훑고 나서도 머릿속에 남는 것이 여전히 큰 단어뿐이기 때문입니다.
-## 2. 사람들이 돈을 쓰는 곳 보기
+- AI for education
+- AI for healthcare
+- AI for finance
+- AI agent for business
-다음은 좋은 단서입니다.
+이것들은 아직 아이디어가 아닙니다. 단지 "방향이 크다"는 것을 알려 줄 뿐, 다음을 알려 주지 않습니다.
-- 유료 템플릿
-- 외주 서비스
-- 강의
-- 컨설팅
-- 반복 업무 대행
+- 누가 쓰는지
+- 어떤 장면에서 쓰는지
+- 지금은 어떻게 임시로 해결하고 있는지
+- 어느 단계를 먼저 잘라 들어갈 가치가 있는지
-사람들이 돈을 쓴다는 것은 문제가 실제로 존재할 가능성이 높다는 뜻입니다.
+이 글은 공허한 방법론을 말하지 않습니다. 바로 쓰기 좋은 출처들을 정리해 드립니다.
-## 3. 사람들이 불평하는 곳 보기
+
-커뮤니티, 리뷰, 댓글, Q&A 사이트에서 반복되는 불평을 찾습니다.
+::: info 최소 SOP
+**목적**: 읽고 나면 아이디어가 없을 때 먼저 어디를 훑어야 하는지, 어떤 링크가 "구체적인 수요"를 보기에 적합한지, 어떤 링크가 "트렌드"를 보기에 적합한지, 어떤 링크가 "실제 비즈니스"를 보기에 적합한지 알게 됩니다.
-좋은 불평은 제품 아이디어의 씨앗입니다.
+**행동 항목**: 먼저 idea 목록을 한 바퀴 훑고, 그다음 돈을 버는 작은 제품을 한 바퀴 봅니다. 이어서 트렌드와 더 비즈니스에 가까운 출처를 보고, 마지막에 계속 조사하고 싶은 방향 1개를 남깁니다.
+
+**결과**: 큰 단어에 머무르지 않고, 더 구체적이고 계속 검증할 만한 방향 1개를 얻습니다.
+
+**키워드 이동**: [참고 앱 목록](#idea-apps) · [트렌드 출처](#idea-trends) · [더 비즈니스에 가까운 출처](#idea-business) · [VC / 액셀러레이터 출처](#idea-vc) · [최단 경로](#idea-path) · [AI는 어떻게 도와줄 수 있나](#idea-ai)
+:::
+
+## 다음 내용을 배우게 됩니다
+
+1. 어떤 웹사이트가 idea를 바로 훑기에 적합한지
+2. 어떤 웹사이트가 이미 돈을 버는 작은 제품을 보기에 적합한지
+3. 어떤 출처가 트렌드와 산업 변화를 보기에 적합한지
+4. 어떤 출처가 실제 비즈니스와 실제 지불에 더 가까운지
+5. 제로 베이스에 적합한 가장 짧은 사용 경로
+
+
+## [1. 참고 앱 목록: 먼저 다른 사람이 이미 무엇을 하고 있는지 보기](#top-idea-sources)
+
+이것은 초보자에게 가장 적합한 출발점입니다. 가장 구체적이기 때문입니다.
+
+### 1군: 열자마자 idea 목록이 나오고 바로 고를 수 있는 곳
+
+- [Reddit — r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
+ 이 subreddit의 핵심 용도는 실제 사용자가 직접 "누가 XX 하나 만들어 줬으면 좋겠다"를 올리는 것입니다. 각 게시물은 보통 구체적인 제품 수요 하나이고, 약간의 상황 설명도 포함합니다. 들어간 뒤 `Top -> Past Month` 또는 `Top -> Past Year`로 정렬하면 20분 만에 실제 수요를 한 묶음 훑을 수 있습니다.
+- [Reddit — r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
+ 위와 비슷하지만 소프트웨어/App 쪽에 더 가깝습니다. 게시물의 흔한 형식은 "XX를 할 수 있는 앱이 필요하다"이고, 입도가 더 작으며 작지만 아름다운 niche가 많습니다.
+- [Reddit — r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
+ 앞의 두 곳보다 더 완전합니다. 많은 게시물이 한 문장짜리 수요에 그치지 않고, 약간의 시장 분석, 비즈니스 모델, 왜 지금 할 만한지까지 포함합니다.
+- [Unvalidated Ideas](https://unvalidatedideas.com/)
+ 검증되지 않은 창업 idea를 매주 발행합니다. 흔한 필드는 타깃 사용자, 수익화 방식, 초기 검증 아이디어입니다. 형식이 통일되어 있어 빠르게 훑기 좋습니다.
+- [IdeasAI](https://ideasai.com/)
+ AI로 창업 idea를 생성하며 계속 넘겨 볼 수 있습니다. 품질은 불안정하지만, "아무 감이 없을 때" 영감을 자극하고 다시 세부 장면으로 파고들기에 좋습니다.
+
+### 2군: 다른 사람이 이미 하고 있는 돈 되는 작은 제품을 보고 idea를 역추적하기
+
+이런 플랫폼의 논리는 이렇습니다. 다른 사람이 이미 수요를 검증했고, 심지어 돈도 벌고 있습니다. 이것들을 보는 이유는 베끼기 위해서가 아니라, "어떤 작은 문제가 이미 유료로 해결되고 있는지" 보기 위해서입니다.
+
+- [Starter Story](https://www.starterstory.com/)
+ 실제 작은 비즈니스 사례를 많이 수록합니다. 보통 창업자 인터뷰, 매출 데이터, 시작 과정이 있습니다. 월수입 1만~10만 달러 수준의 작은 제품을 중점적으로 보세요. 보통 더 niche하고, 일반인이 이해할 수 있는 제품 규모에 더 가깝습니다.
+- [Indie Hackers — Products](https://www.indiehackers.com/products)
+ 독립 개발자가 제품을 보여 주는 곳입니다. 많은 제품이 수익과 성장을 공개합니다. 수익 순으로 정렬해 월수입 수천~수만 달러 제품들이 어떤 구체적 문제를 해결하는지 봅니다.
+- [MicroConf Blog](https://microconf.com/blog)
+ Micro SaaS 쪽에 가깝습니다. "충분히 작지만 누군가 돈을 낼 의향이 있는" 제품 진입점을 보기에 적합합니다.
+- [1000 Tools](https://1000.tools/)
+ AI 도구 모음 사이트입니다. 어떤 카테고리가 이미 만들어졌지만 완성도가 아쉬운지, 또는 국내/특정 수직 산업에서 아직 잘 커버되지 않은 방향이 무엇인지 보기에 좋습니다.
+- [Product Hunt](https://www.producthunt.com/)
+ 최근 반복해서 등장하는 제품 유형을 봅니다. 1위만 보지 말고, 어떤 카테고리가 계속 만들어지지만 아직 명확한 승자가 없는지에 집중하세요.
+- [BetaList](https://betalist.com/)
+ 초기 제품과 아직 방향을 시험 중인 팀을 보기에 적합합니다.
+
+### 제품을 볼 때는 제품 자체만 보지 말고, 낮은 평점과 "대행 서비스"도 보세요
+
+- [G2](https://www.g2.com/)
+ 사용법: 1점, 2점 리뷰를 봅니다. 낮은 평점에는 보통 "기존 제품의 어느 단계가 제대로 되지 않는지"가 숨어 있습니다.
+- [Capterra](https://www.capterra.com/)
+ 사용법: G2와 비슷합니다. SaaS 제품의 실제 불평을 보기에 적합합니다.
+- 타오바오 / Xianyu / [Fiverr](https://www.fiverr.com/) / [Upwork](https://www.upwork.com/) / Zhu Bajie
+ 사용법: "대행", "대신 정리", "대신 입력", "대신 녹취", "대신 변환" 같은 키워드를 검색합니다. 어떤 수작업 서비스가 잘 팔린다면, 그 뒤에는 대개 반복 가능하고 제품화 가능한 프로세스가 있습니다.
+
+판단 신호는 단순합니다.
+
+- 사용자가 기존 도구를 이미 불평하고 있다.
+- 사용자가 이미 돈을 내고 누군가에게 대행을 맡기고 있다.
+- 사용자가 이 프로세스에 많은 인력과 시간을 투입하고 있다.
+
+### 4군: 영상 보기. 누군가가 직접 idea를 분해해 준다
+
+포럼이나 순위를 훑는 것을 좋아하지 않고 "누군가 생각의 흐름을 대신 풀어 주면 좋겠다"면 영상과 팟캐스트도 적합합니다.
+
+- `Greg Isenberg startup ideas` 검색
+ 누군가가 구체적인 idea 2~3개를 직접 분해하고, 시장 규모, 경쟁 분석, 진입점을 함께 설명하는 콘텐츠를 보기에 좋습니다.
+- `My First Million podcast` 검색
+ 두 진행자가 자주 한 회 전체를 비즈니스 idea 브레인스토밍에 씁니다. 밀도가 높고 매우 구체적인 niche가 자주 나옵니다.
+- `YC startup ideas` 또는 `Michael Seibel startup ideas` 검색
+ 초보자에게 적합합니다. 내용이 직설적이고, 방향을 고르는 법을 바로 설명하는 경우가 많습니다.
+
+
+## [2. 트렌드 출처: 어떤 방향이 떠오르고 있는지 보기](#top-idea-sources)
+
+트렌드 사이트의 역할은 직접 아이디어를 주는 것이 아니라, 어떤 방향이 뜨거워지고 있는지, 계속 볼 가치가 있는지 판단하게 도와주는 것입니다.
+
+- [Exploding Topics](https://explodingtopics.com/)
+ 빠르게 성장하지만 아직 주류 시야에 완전히 들어오지 않은 주제와 제품 카테고리를 데이터로 추적합니다. "떠오르고 있지만 아직 지나치게 붐비지는 않은" 방향을 보기에 적합합니다.
+- [Google Trends](https://trends.google.com/)
+ 키워드를 검색해 지난 1년의 추세선을 보고, "관련 검색어"의 "급상승" 단어를 봅니다.
+- [Glimpse](https://meetglimpse.com/)
+ Google Trends와 비슷합니다.
+- 산업 연구 보고서 요약 페이지
+ 이미 방향이 있고, 이 방향이 산업 안에서 어떤 위치에 있는지 빠르게 보고 싶을 때 적합합니다.
+- McKinsey / BCG / Gartner의 트렌드 콘텐츠
+ 기업과 큰 산업 관점에 더 가깝습니다. B2B, 산업, 전통 업종에 적합합니다.
+- [State of AI Report](https://www.stateof.ai/)
+ 방향이 AI 기술 자체와 관련 있다면, 이런 연례 보고서가 큰 그림을 잡는 데 좋습니다.
+
+트렌드를 볼 때는 세 가지만 중점적으로 봅니다.
+
+- 이 단어가 지속적으로 뜨거워지고 있는가
+- 어떤 구체적 장면에 놓이는가
+- 누가 가장 먼저 시간, 전환 비용, 예산을 지불할 것인가
+
+
+## [3. 더 비즈니스에 가까운 출처: 누가 돈을 쓰고, 누가 불평하고, 누가 수작업 서비스를 파는지 보기](#top-idea-sources)
+
+"멋있어 보이는" 방향이 아니라 "실제 비즈니스에 더 가까운" 방향을 찾고 싶다면, 워크플로우에 더 가까운 출처를 봐야 합니다.
+
+### 누가 실제로 무엇에 돈을 쓰는지 보기
+
+- [중국정부조달망](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`
+- [V2EX](https://www.v2ex.com/)
+- Jike
+- Xiaohongshu
+
+검색할 때 "AI", "혁신"만 검색하지 마세요. 더 효과적인 검색어는 다음입니다.
+
+- 너무 번거롭다
+- 더 좋은 방법 없나요
+- 도구 추천 부탁
+- Excel로는 관리가 안 된다
+- I wish there was
+- is there a tool for
+- I hate
+
+### 누가 반복적인 수작업 서비스를 파는지 보기
+
+- [Fiverr](https://www.fiverr.com/)
+- [Upwork](https://www.upwork.com/)
+- Zhu Bajie
+- 타오바오
+- Xianyu
+
+다음 서비스가 잘 팔리는 것을 보면 계속 조사할 가치가 있습니다.
+
+- PDF 견적서를 Excel로 정리해 주기
+- 고객 자료를 대량 정리해 주기
+- 이력서/문구 수정, 녹취, 아카이빙 대행
+
+이런 서비스 뒤에는 보통 일회성 수요가 아니라 반복적으로 발생하는 워크플로우가 있습니다.
+
+### idea 목록만 보지 말고 전체 워크플로우를 보세요
+
+때로는 가장 직접적인 방법이 하나의 산업을 골라 프로세스를 한 번 훑고, 아직 WeChat, Excel, 종이와 펜, 전화에 의존하는 단계를 찾는 것입니다.
+
+- 무역: 공급업체 찾기, 문의, 가격 비교, 견적서 만들기, 고객에게 보내기, 회신 추적, 검품 준비, 선적 예약, 통관.
+ 볼 만한 진입점: 공급업체 견적을 고객용 견적서로 정리하기.
+- 치과: 접수, 촬영, 영상 판독, 치료 방안 소통, 후속 관리, 치료, 재진.
+ 볼 만한 진입점: 환자에게 치료 방안을 설명하고 계속 후속 관리하기.
+- 건설 현장: 순찰, 사진 촬영, 단체 채팅방 공유, 보고서 정리, 발주처 제출.
+ 볼 만한 진입점: 현장 사진에서 규정 준수 보고서까지.
+
+
+## [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/)
+ 사용법: 특정 방향을 깊게 파기에 적합합니다. 반드시 아이디어 목록은 아니지만 글의 품질이 보통 높습니다.
+
+이런 출처의 장점:
+
+- 앞으로 어떤 방향을 볼 만한지 알려 준다.
+- 어떤 트랙이 계속 추진될 가능성이 있는지 알려 준다.
+- 특정 트랙의 맥락에 빠르게 들어가게 해 준다.
+
+이런 출처의 한계:
+
+- 보통 투자자 관점이다.
+- 구체적으로 어떤 역할이 가장 아픈지 반드시 알려 주지는 않는다.
+- 어떤 프로세스 단계가 가장 막히는지 반드시 알려 주지는 않는다.
+- 오늘 누가 이미 이것에 돈을 쓰고 있는지 반드시 알려 주지는 않는다.
+
+따라서 더 좋은 사용법은 이 출처들로 방향을 찾고, 다시 참고 제품, 산업 포럼, 조달 정보, 실제 워크플로우로 돌아가 더 구체적인 진입점을 찾는 것입니다.
+
+
+## [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 같은 곳에서 이 방향의 오늘 가장 짜증 나는 지점이 어디인지, 아직 어디가 수작업에 의존하는지 봅니다.
+
+다 보고 나서 아래 문장을 명확히 말할 수 있으면 충분합니다.
+
+- 어떤 유형의 사람이, 어떤 장면에서, 어느 프로세스 단계에 막혀 있고, 지금은 주로 어떤 서툰 방법으로 버티고 있다.
+
+
+## [6. AI는 어떻게 도와줄 수 있나](#top-idea-sources)
+
+이 글의 중점은 AI가 아니지만, AI는 정리에 매우 적합합니다.
+
+가장 실용적인 사용법은 두 가지뿐입니다.
+
+- 훑어 본 링크, 게시물 제목, 사용자의 원문을 AI에게 붙여 넣고 "사람군 / 장면 / 고통점 / 대체 방안"으로 분류하게 합니다.
+- AI에게 흩어진 정보를 후보 방향 3개로 수렴하게 합니다. 계속 기능 50개로 발산하게 하지 마세요.
+
+바로 이렇게 물어볼 수 있습니다.
```text
-매번 직접 정리하기 귀찮다.
-어디서부터 시작해야 할지 모르겠다.
-예시는 많은데 내 상황에 맞게 바꾸기 어렵다.
-여러 도구를 왔다 갔다 해야 한다.
+최근에 이런 출처들을 봤어.
+1. [제목이나 원문 붙여넣기]
+2. [제목이나 원문 붙여넣기]
+3. [제목이나 원문 붙여넣기]
+
+기능 목록을 주지 마.
+딱 세 가지만 해 줘.
+1. 사람군과 장면별로 분류
+2. 반복해서 나타나는 번거로운 단계 찾기
+3. 더 구체적인 후보 방향 3개로 정리
```
-## 4. 반복 수작업 보기
+## 더 읽어 보기
-AI가 잘 도와주는 영역은 반복 수작업입니다.
-
-- 복사해서 붙여넣기
-- 형식 맞추기
-- 요약하기
-- 분류하기
-- 문장 다듬기
-- 초안 만들기
-
-반복 수작업을 찾으면 첫 제품 범위가 자연스럽게 작아집니다.
-
-## 5. AI에게 아이디어 조사를 시키기
-
-```text
-나는 AI IDE로 첫 프로토타입을 만들고 싶은 초보자야.
-대상은 [사용자군]이고, 관심 분야는 [분야]야.
-
-다음 기준으로 제품 아이디어 10개를 제안해 줘.
-- 하루나 이틀 안에 프로토타입 가능
-- AI 기능 하나만 사용
-- 입력과 출력이 명확함
-- 사용자가 직접 결과를 확인할 수 있음
-
-각 아이디어마다 대상 사용자, 문제, 첫 화면, 결과 화면을 적어 줘.
-```
-
-## 과제
-
-다음 세 곳에서 아이디어를 3개씩 찾아 보세요.
-
-1. 앱/웹 서비스 목록
-2. 사용자 리뷰나 커뮤니티 불평
-3. 돈을 받고 대신 해 주는 서비스
-
-그중 가장 작게 만들 수 있는 아이디어 하나를 골라 Stage 1 프로젝트로 사용합니다.
+- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
+- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
+- [NFX](https://www.nfx.com/)
+- [Reddit - r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
+- [Reddit - r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
+- [Reddit - r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
+- [Starter Story](https://www.starterstory.com/)
+- [Indie Hackers - Products](https://www.indiehackers.com/products)
+- [Product Hunt](https://www.producthunt.com/)
+- [BetaList](https://betalist.com/)
+- [IdeasAI](https://ideasai.com/)
+- [Unvalidated Ideas](https://unvalidatedideas.com/)
+- [Google Trends](https://trends.google.com/)
+- [Exploding Topics](https://explodingtopics.com/)
+- [G2](https://www.g2.com/)
+- [Capterra](https://www.capterra.com/)
diff --git a/docs/ko-kr/stage-1/appendix-industry-scenarios/index.md b/docs/ko-kr/stage-1/appendix-industry-scenarios/index.md
index 9a1ccb0..9112512 100644
--- a/docs/ko-kr/stage-1/appendix-industry-scenarios/index.md
+++ b/docs/ko-kr/stage-1/appendix-industry-scenarios/index.md
@@ -1,109 +1,765 @@
---
-title: 'AI 산업 적용 시나리오 참고'
-description: 'B2B와 업무 자동화 관점에서 AI 제품 아이디어를 찾는 참고 시나리오입니다.'
+title: 'B 사이드 산업 앱 장면 방향 참고'
+description: '이 문서는 LLM 대형 모델이 B 사이드 기업 장면에서 실제로 적용될 수 있는 앱을 정리합니다. 산업 제조, 지능형 고객지원, 교육, 지능형 프로그래밍, 의료, 네트워크 보안, 금융 관리, 기업 서비스 등 영역의 구체적인 적용 방향을 포함하며, 기업 고객을 향한 AI 앱 개발자에게 참고 자료를 제공합니다.'
---
-# AI 산업 적용 시나리오 참고
+
-- 수업 자료 요약
-- 퀴즈 생성
-- 학습 계획 추천
-- 학생 질문 분류
-- 개념 설명 난이도 조절
+# B 사이드 산업 앱 장면 방향 참고
-## 5. 인사/채용
+## 장 안내
-- 채용 공고 초안 작성
-- 이력서 요약
-- 면접 질문 생성
-- 온보딩 체크리스트
-- 교육 자료 정리
+
-## 6. 운영/관리
+이 문서는 LLM 대형 모델이 B 사이드 기업 장면에서 실제로 적용되는 앱을 정리합니다. 사용자 경험과 감정에 관심을 두는 C 사이드와 달리, B 사이드 제품은 실제 비즈니스 요구 해결, 효율 향상, 비용 절감을 더 중시합니다. 각 장면은 모두 실제로 구현 가능한 가능성을 갖추고 있으며, 요구 분석부터 기술 구현까지의 완전한 사고를 포함하므로, 기업 고객을 향한 AI 앱 개발자가 참고하기에 적합합니다.
-- 회의록에서 할 일 추출
-- 업무 보고서 초안 작성
-- 반복 체크리스트 생성
-- 매뉴얼 정리
-- 일정 충돌 요약
+
-## 7. 법무/계약 보조
+## 업계 방향 빠른 선택
-주의: 법률 판단을 대신하는 제품은 고위험입니다. Stage 1에서는 판단 자동화보다 문서 정리와 체크리스트 보조 수준이 적합합니다.
+
+
당신에게 맞는 앱 장면 찾기
+
+ 관심 방향과 달성하고 싶은 목적을 선택하면, 시스템이 관련 업계 장면을 추천합니다. 태그를 클릭하면 해당 절로 이동합니다.
+
+ 당신을 위해 앱 장면 {{ recommendationTopics.length }}개 추천
+
+ ({{ currentSelection.interest }} + {{ currentSelection.purpose }})
+
+
+
+
+
+
{{ scope.row.title }}
+
{{ scope.row.desc }}
+
+
+
+
+ {{ scope.row.industryName }}
+
+
+
+
+ 💡 표의 아무 행이나 클릭하면 해당 업계 절로 이동합니다.
+
+
+
+
+
+ 💡 관심 방향과 실현 목적을 선택하세요
+ 💡 관심 방향을 선택하세요
+ 💡 실현 목적을 선택하세요
+
+
+
+
+ 다시 선택
+
+
-- 계약서 요약
-- 조항 체크리스트
-- 계약 검토 요청사항 정리
-- 표준 문구 비교
+## 업계 빠른 소개
-## 8. 의료/헬스케어 보조
+### 주요 기술 선택
-주의: 진단이나 치료 판단은 피해야 합니다.
+AI 앱 개발에서 흔히 쓰는 기술 방향은 다음과 같습니다.
-가능한 범위:
+1. **LLM(대형 언어 모델)**: 대화, 텍스트 생성, 요약, 번역 같은 자연어 작업에 강하며, 지능형 고객지원, 콘텐츠 창작, 지식 질의응답 앱을 만들기에 적합합니다.
+2. **VLM(시각 언어 모델)**: 시각 이해와 언어 능력을 결합해 이미지 설명, 시각 질의응답, 멀티모달 콘텐츠 생성 등을 구현할 수 있으며, 의료 영상 분석, 산업 품질 검사, 창의 설계 같은 장면에 적합합니다.
+3. **GenAI(생성형 AI)**: 텍스트 생성, 이미지 생성(예: Stable Diffusion, DALL·E), 영상 생성 등 기술을 포함하며, 창의 콘텐츠를 빠르게 만들 수 있어 설계 보조, 마케팅 소재 제작, 교육훈련 등 영역에 적합합니다.
-- 운동 기록 정리
-- 식단 메모 요약
-- 병원 방문 전 질문 목록 작성
-- 건강 습관 리마인더
+### 선택 전략
-## 9. 좋은 업무용 아이디어의 조건
+학습자는 다음 차원에 따라 자신에게 맞는 앱 방향을 선택할 수 있습니다.
-업무용 아이디어는 다음 조건을 보면 좋습니다.
+1. **관심 지향**: 자신이 관심 있는 업계나 기술 방향을 우선 선택해 학습 동력을 유지합니다. 예:
+ - 창의 설계에 관심이 있다면 콘텐츠 생산, 산업 디자인 앱을 시도할 수 있습니다.
+ - 기술 도전에 관심이 있다면 네트워크 보안, 의료 방향의 앱을 시도할 수 있습니다.
+ - 사회적 가치에 관심이 있다면 스마트 행정, 교육 업계 앱을 시도할 수 있습니다.
-- 반복 빈도가 높다.
-- 결과 형식이 어느 정도 정해져 있다.
-- 사람이 최종 확인할 수 있다.
-- 실패해도 치명적이지 않다.
-- 시간 절약 효과를 설명할 수 있다.
+2. **업계 적합성**: 자신의 업계 배경이나 자원 우위를 결합해 장면을 선택합니다.
+ - 제조업 종사자: 산업 제조, 기업 서비스형 앱을 우선 고려할 수 있습니다.
+ - 교육 종사자: 교육 업계, 콘텐츠 생산형 앱에 우선 관심을 둘 수 있습니다.
+ - 의료 종사자: 의료 방향, 건강 관리형 앱을 탐색할 수 있습니다.
-## 과제
+3. **기술 난이도**: 자신의 기술 기초에 따라 적합한 복잡도를 선택합니다.
+ - 입문급: 지능형 고객지원, 콘텐츠 창작, 간단한 질의응답 시스템
+ - 발전급: 산업 품질 검사, 의료 영상 분석, 코드 지능형 도우미
+ - 전문급: 금융 리스크 관리, 네트워크 보안, 멀티모달 복합 앱
-관심 있는 업종 하나를 고르고 다음을 적어 보세요.
+## 1. 산업 제조업
-```text
-업종:
-반복 업무:
-현재 해결 방식:
-불편한 점:
-AI가 도와줄 수 있는 부분:
-첫 프로토타입 화면:
-```
+산업 제조업 장면은 주로 설계 보조, 생산 최적화, 지능형 운영 유지보수라는 세 방향을 중심으로 전개됩니다. 흔한 앱에는 AI 보조 제품 외관 설계, 자동화 도면 검토, 기술 문서 지능형 생성, 산업 설비 고장 진단 등이 있으며, 설계 효율을 크게 높이고 운영 유지 비용을 낮출 수 있습니다.
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 신에너지 버스 외관 AI 보조 설계 플랫폼 | 이미지 생성 모델 기반으로 외관 콘셉트 설계를 수행하고, LLM으로 설계 규범 검사와 아이디어 반복을 진행합니다. Three.js 3D 렌더링 서비스를 통합합니다 |
+| 2 | 지능형 도면 설계와 검토 도우미 | RAG 기술로 기업 설계 규범 지식베이스를 구축하고, DALL·E가 참고 이미지를 생성해 이해를 돕습니다. CAD API를 통합해 도면 자동 파싱을 구현합니다 |
+| 3 | 기술 문서 자동 생성과 관리 | LLM을 기반으로 제품 데이터베이스에서 제품 사양서와 조작 매뉴얼을 자동 생성하고, ChromaDB 벡터 저장소에 과거 문서를 저장해 지능형 검색을 지원합니다 |
+| 4 | 생산 설비 점검 보고서 자동 생성 도우미 | 점검 인력이 음성으로 설비 상태를 설명하면 LLM이 구조화된 점검 보고서를 생성합니다. 과거 고장 기록을 자동 연결합니다 |
+| 5 | 공장 지게차 지능형 dispatch와 경로 계획 시스템 | LLM이 주문 작업과 창고 위치를 해석하고 지도 API와 결합해 최적 dispatch 방안을 생성합니다 |
+| 6 | LLM 정보 검색 기반 데이터 웨어하우스 | Text-to-SQL 기술로 자연어를 데이터베이스 질의로 변환하고, Superset으로 질의 결과를 시각화합니다. Doris 또는 ClickHouse를 OLAP 엔진으로 사용합니다 |
+| 7 | 산업 설비 고장 진단 지식 질의응답 도우미 | 과거 고장 사례 기반 벡터 지식베이스를 구축하고, LLM이 고장 설명에 따라 진단 제안과 해결 방안을 제공합니다 |
+| 8 | 생산 품질 검사 보고서 지능형 생성과 결함 분류 | OCR로 품질 검사 사진 속 결함을 인식하고 LLM이 구조화된 품질 검사 보고서를 생성합니다. 결함 유형과 심각도를 자동 분류합니다 |
+| 9 | 재고 실사 지능형 도우미와 실사 보고서 생성 | 실사 데이터를 입력하면 LLM이 시스템 재고와 자동 비교하고 차이 보고서를 생성합니다. 이상 재고 경고를 제공합니다 |
+| 10 | 공정 프로세스 최적화 제안 지능형 질의응답 시스템 | 생산 공정 문서를 바탕으로 RAG 지식베이스를 구축하고, LLM이 생산 문제에 따라 최적화 제안을 제공합니다 |
+
+## 2. 지능형 고객지원
+
+지능형 고객지원 장면은 고객 서비스 효율 향상과 사용자 경험 최적화에 집중합니다. 대표 앱에는 다채널 고객지원 통합, 지능형 답변 생성, 고객 감정 분석, 티켓 자동 처리 등이 있으며, 기업이 7×24시간 고객 서비스를 구현하도록 돕습니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 다채널 지능형 고객지원 자동 답변과 티켓 생성 시스템 | WeChat, APP, 공식 웹사이트 등 다채널 메시지를 연결하고, LLM이 의도를 이해한 뒤 답변을 생성하고 티켓을 자동 생성합니다. LangChain으로 대화 흐름을 만들고 MySQL에 티켓 데이터를 저장합니다 |
+| 2 | 잠재 고객 발굴과 후속 제안 도우미 | LLM이 과거 고객지원 대화 기록을 분석해 구매 의향이 높은 고객 특징을 식별하고 점수를 매깁니다. 추천 시스템은 협업 필터링 알고리즘을 결합합니다 |
+| 3 | 기업 내부 지식 지능형 검색과 질의응답 매니저 | Confluence와 내부 문서를 바탕으로 벡터 지식베이스를 만들고, LLM이 RAG 기술과 결합해 답변을 생성합니다 |
+| 4 | 고객 만족도 조사와 서비스 개선 관리 시스템 | LLM이 고객지원 대화 내용을 자동 분석해 감정 분류와 만족도 점수를 수행합니다. BI 보고서로 분석 결과를 표시합니다 |
+| 5 | 고객지원 대화 지능형 요약과 티켓 생성 도구 | 고객지원 대화 종료 후 LLM이 대화 요약을 자동 생성하고 핵심 정보를 추출합니다. 티켓 필드를 자동 채웁니다 |
+| 6 | 고객지원 화법 컴플라이언스 자동 검사 도우미 | 고객지원 담당자가 입력한 답변 내용을 LLM이 실시간 검사해 화법 컴플라이언스와 민감어를 확인하고 수정 제안을 제공합니다 |
+| 7 | 고객지원 티켓 자동 요약과 분류 생성 도구 | LLM이 긴 대화 기록을 요약하고 자동 분류 태그를 생성합니다. Elasticsearch가 티켓 전문 검색을 지원합니다 |
+| 8 | 고객 감정 모니터링과 이상 경고 도구 | 음성 억양 특징과 문자 감정을 실시간 분석하고 LLM이 이상 감정을 식별해 경고를 트리거합니다. WebSocket으로 경고 메시지를 푸시합니다 |
+| 9 | 고객지원 베스트 화법 추천 지식베이스 시스템 | LLM이 우수 고객지원 대화 사례를 분석해 베스트 화법 템플릿을 정제합니다. 추천 시스템은 대화 컨텍스트에 따라 실시간으로 화법을 추천합니다 |
+| 10 | 지능형 아웃바운드 콜 대화 내용 분석과 품질 검사 도우미 | 아웃바운드 콜 녹음을 전사한 뒤, LLM이 대화 내용을 분석해 핵심 정보를 추출합니다. 품질 검사 보고서와 개선 제안을 자동 생성합니다 |
+
+## 3. 교육 업계
+
+교육 업계 장면은 개인화 교육과 스마트 교육 관리를 구현하는 데 힘씁니다. 핵심 앱에는 지능형 학습 경로 계획, 과제 자동 채점, 수업안 생성, 학습 상태 분석 등이 있으며, 교육 자원의 최적 배치와 맞춤형 교육을 추진합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 개인화 언어 학습 경로 계획과 지능형 학습 안내 시스템 | LLM이 학습자의 현재 수준을 평가하고 학습 목표에 따라 매일의 학습 작업을 계획합니다. 추천 알고리즘과 지식 그래프를 결합해 학습 자원을 추천합니다 |
+| 2 | 수업안 자동 작성과 교육 자료 추천 플랫폼 | LLM이 교과 과정 개요에 따라 수업안 프레임워크와 교수 설계를 생성합니다. 벡터 저장소에 우수 수업안과 수업 자료를 저장해 키워드 검색과 유사 추천을 지원합니다 |
+| 3 | 과제 자동 채점과 학습 상태 진단 분석 시스템 | LLM이 서술형 문제를 자동 채점하고 채점 제안을 생성하며, 지식 그래프가 학생의 취약 지식 포인트를 찾아냅니다 |
+| 4 | 인재 직무 역량 모델 구축과 학습 지도 | LLM이 직무 설명을 분석해 역량 요구를 추출하고 직무 역량 프로필을 구축합니다. 격차에 따라 개인화 학습 지도를 생성합니다 |
+| 5 | 학교 기반 교육과정 체계 구축과 수업 자료 제작 도구 | LLM이 학교 특성과 학생 요구를 분석해 학교 기반 교육과정 프레임워크를 생성합니다. PPT 생성 인터페이스를 통합해 수업 자료를 자동 제작합니다 |
+| 6 | 외국어 말하기 일대일 상황형 실전 연습 | LLM이 서로 다른 역할을 맡아 말하기 대화를 진행하고, ASR이 발음을 인식해 점수를 매깁니다. TTS가 표준 발음 시범을 생성합니다 |
+| 7 | 대학 입시 지원 빅데이터 추천과 진로 계획 지도 플랫폼 | LLM이 수험생 점수, 등수, 관심사 등을 분석하고 입학 데이터를 결합해 학교와 전공을 추천합니다 |
+| 8 | 어린이 코딩 코드 도우미 | LLM이 코드 로직을 설명하고 프로그래밍 지도를 제공하며, 블록 언어와 Python 전환을 지원합니다 |
+| 9 | 지식 포인트 마인드맵 자동 생성과 학습 경로 추천 도구 | 수업 주제를 입력하면 LLM이 지식 포인트 마인드맵을 자동 생성합니다. 학습 진도에 따라 다음 학습 내용을 추천합니다 |
+| 10 | 한국어와 영어 작문 자동 채점과 첨삭 엔진 | LLM이 주제 의식, 구조, 언어, 다양성 등 여러 차원에서 점수를 매기고 주석을 생성합니다. 우수 예시 글과 비교합니다 |
+
+## 4. 지능형 프로그래밍
+
+지능형 프로그래밍 장면은 개발 효율과 코드 품질을 높이는 것을 목표로 합니다. 대표 앱에는 지능형 코드 완성, 버그 자동 수정, 자동화 테스트 생성, 코드 변환 등이 있으며, 개발자가 반복적인 코딩 작업이 아니라 비즈니스 로직에 집중하게 합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 지능형 코드 완성과 버그 자동 수정 도우미 | CodeLlama로 코드 모델을 미세조정하고, IDE 플러그인이 실시간 코드 완성 제안을 제공합니다. LLM이 오류 스택을 분석해 버그를 자동 위치 지정하고 수정 코드를 생성합니다 |
+| 2 | 로우코드 앱 구축과 프로세스 자동화 플랫폼 | 사용자가 자연어로 요구를 설명하면 LLM이 로우코드 설정이나 코드 프레임워크로 변환합니다 |
+| 3 | 단위 테스트 케이스 생성 시스템 | AST가 소스 코드를 파싱해 함수 로직을 추출하고, LLM이 경계 조건과 예외 장면의 테스트 케이스를 생성합니다. Jest/Pytest를 통합해 테스트를 실행합니다 |
+| 4 | 코드 지능형 분석과 언어 마이그레이션 도구 | Tree-sitter 기반으로 코드 구조를 파싱하고, LLM이 코드 품질을 분석해 최적화 제안을 제공합니다. 규칙 엔진과 결합해 언어 변환을 구현합니다 |
+| 5 | 자연어를 SQL 문으로 자동 생성하는 도구 | LLM이 자연어 질의를 SQL로 변환하며, 복잡한 다중 테이블 조인과 집계 질의를 지원합니다 |
+| 6 | API 인터페이스 자동화 테스트와 문서 생성 플랫폼 | LLM이 코드 주석과 인터페이스 정의를 분석해 테스트 케이스와 API 문서를 자동 생성합니다. Postman 통합 테스트 실행을 지원합니다 |
+| 7 | UI 테스트 스크립트 지능형 녹화와 유지보수 도구 | 브라우저 플러그인이 사용자 조작 궤적을 녹화하고, LLM이 조작 의도를 분석해 테스트 스크립트를 생성합니다. AI가 실패한 locator를 수정합니다 |
+| 8 | 시스템 로그 분석과 장애 위치 지정 | ELK Stack이 로그 데이터를 수집하고, LLM이 이상 로그를 분석해 핵심 정보를 추출하며 근본 원인을 찾습니다. 수정 방안을 추천합니다 |
+| 9 | 프론트엔드 인터페이스(UI) 코드 자동 생성 도구 | 디자인 시안 이미지를 OCR로 인식해 레이아웃 구조를 파악하고, LLM이 반응형 CSS와 컴포넌트 코드를 생성합니다. TailwindCSS를 통합해 여러 스타일 프레임워크를 지원합니다 |
+| 10 | 데이터베이스 구조 지능형 설계와 모델링 도우미 | 비즈니스 요구 문서를 LLM에 입력하면 ER 다이어그램과 데이터 테이블 구조를 자동 생성합니다. MySQL/PostgreSQL 테이블 생성 스크립트 내보내기를 지원합니다 |
+
+## 5. 의료 방향
+
+의료 방향 장면은 진료 효율과 의료 서비스 품질을 높이는 데 힘씁니다. 흔한 앱에는 진료 기록 자동 생성, 의학 지식 질의응답, 영상 분석 보조, 신약 개발 지원 등이 있으며, 의료 업계의 지능화 전환을 추진합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 의학 검사 보고서 지능형 해석 도우미 | 검사 보고서 이미지를 업로드하면 OCR이 핵심 지표를 인식하고, LLM이 이상값을 해석해 쉬운 설명을 생성합니다 |
+| 2 | 지식 검색 기술 기반 건강 상담 전문가 | 의학 지식 그래프(ICD-10, 약품 설명서, 진료 지침)를 구축하고 RAG 검색으로 답변을 생성합니다 |
+| 3 | 임상 연구 데이터 의사결정 분석 플랫폼 | EMR 데이터와 검사 결과를 통합하고, LLM이 통계 분석 코드와 시각화 차트 생성을 보조합니다. 코호트 연구와 생존 분석을 지원합니다 |
+| 4 | 의학 시험 문제 지능형 생성과 오답 해설 시스템 | 교재 장과 지식 포인트를 입력하면 LLM이 연습 문제와 해설을 생성합니다. 오답을 자동 수집하고 취약점 분석을 생성합니다 |
+| 5 | 신약 개발 전 과정 지식 그래프 지능형 질의응답 전문가 | 약물-표적-질병 지식 그래프를 구축하고 LLM이 연구개발 관련 질문에 답합니다. 문헌 검색과 실험 방안 추천을 지원합니다 |
+| 6 | 의약품 설명서 지능형 질의응답 도우미 | 의약품 설명서 이미지를 업로드하거나 약명을 입력하면 LLM이 용법·용량, 이상 반응, 주의사항 등 질문에 답합니다 |
+| 7 | 질병 지식 대중화 글 생성 도우미 | 질병명과 독자를 입력하면 LLM이 쉽고 이해하기 쉬운 대중화 글을 생성합니다. 여러 버전(환자용/가족용)을 지원합니다 |
+| 8 | 의학 영상 보고서 자동 생성 도구 | 영상의학과 의사가 영상 특징을 설명하면 LLM이 구조화된 보고서를 자동 생성합니다. 흔한 검사 유형 템플릿을 지원합니다 |
+| 9 | 수술 기록 지능형 생성과 보관 도우미 | 수술 과정에서 핵심 단계를 음성으로 입력하면 LLM이 구조화된 수술 기록을 생성합니다. 수술 코드를 자동 연결합니다 |
+| 10 | 만성질환 관리 복약 알림 지능형 도우미 | 환자가 복약 목록을 입력하면 LLM이 개인화 복약 알림을 생성합니다. 복약 금기 검사와 인터랙티브 질의응답을 지원합니다 |
+
+## 6. 네트워크 보안
+
+네트워크 보안 장면은 보안 방어와 위험 통제에 집중합니다. 핵심 앱은 취약점 탐지, 위협 인텔리전스 분석, 피싱 메일 식별, 보안 사건 대응 등을 포함하며, 기업을 위해 전방위 지능형 보안 방어 체계를 구축합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 코드 보안 취약점 탐지와 수정 엔진 | 정적 코드 분석 도구(SAST)가 코드를 스캔하고, LLM이 취약점 원리를 분석해 수정 제안을 생성합니다. CI/CD 파이프라인을 통합합니다 |
+| 2 | AI 생성형 피싱 메일 지능형 식별과 차단 시스템 | LLM이 메일 내용, 발신자 특징, 링크 안전성을 분석해 AI가 생성한 피싱 메일을 식별합니다. 메일 게이트웨이와 연결해 실시간 차단합니다 |
+| 3 | 보안 운영 일일 보고서 자동 생성 도우미 | 보안 장비 로그를 모으고 LLM이 핵심 이벤트를 자동 추출해 일일 보고서를 생성합니다. 이상 이벤트를 highlight 표시합니다 |
+| 4 | 보안 지식베이스 지능형 질의응답 도우미 | 보안 문서와 CVE 라이브러리 기반 벡터 지식베이스를 구축하고, LLM이 보안 기술과 처치 제안 질문에 답합니다 |
+| 5 | 침투 테스트 보고서 지능형 생성 도우미 | 침투 테스트 완료 후 LLM이 취약점 설명에 따라 보고서를 자동 생성합니다. 취약점 수정 제안을 일괄 생성합니다 |
+| 6 | 악성 코드 방어와 개인정보 컴플라이언스 모니터링 | 샌드박스로 의심 파일 행동을 분석하고, LLM이 악성 특징을 식별해 시그니처를 생성합니다. 개인정보 식별 스캔을 수행합니다 |
+| 7 | 보안 설정 컴플라이언스 체크리스트 생성 도구 | 목표 시스템 유형을 입력하면 LLM이 보안 설정 체크리스트를 생성합니다. Multi-Level Protection 2.0, CIS 등 표준을 지원합니다 |
+| 8 | 위협 인텔리전스 지능형 조회와 분석 도우미 | 여러 출처의 위협 인텔리전스(오픈소스, 상용)를 연결하고, LLM이 정보를 해석해 기업 자산과 연관 짓습니다. 방어 전략을 추천합니다 |
+| 9 | 보안 사건 회고 보고서 생성 도우미 | 보안 사건 발생 후 LLM이 타임라인에 따라 회고 보고서를 자동 생성합니다. 근본 원인 분석과 개선 제안을 제공합니다 |
+| 10 | 글로벌 위협 인텔리전스 모니터링과 경고 센터 | 크롤러가 전 세계 보안 뉴스와 취약점 공개를 수집하고, LLM이 핵심 정보를 추출해 영향을 평가합니다. 메일/문자 경고 알림을 제공합니다 |
+
+## 7. 금융 관리와 보험 은행업
+
+금융 영역 장면은 위험 통제와 비즈니스 지능화를 중심으로 전개됩니다. 대표 앱에는 신용 리스크 평가, 자산관리 고문, 재무 보고서 생성, 자금세탁 방지 모니터링 등이 있으며, 금융기관의 운영 효율과 위험 통제 능력을 높입니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 신용 실사 보고서 지능형 생성 도우미 | 기업 기본 정보와 재무 데이터를 입력하면 LLM이 신용 실사 보고서를 자동 생성합니다. 위험 지점을 자동 표시합니다 |
+| 2 | 프라이빗 뱅킹 자산관리 지능형 고문 | LLM이 고객 위험 선호와 재무 목표를 분석하고 자산 배분 제안을 생성합니다. 자산관리 상품과 펀드 라이브러리를 연결합니다 |
+| 3 | IPO 투자설명서 지능형 생성과 컴플라이언스 검증 도우미 | 투자설명서 모듈형 템플릿에 LLM이 사업 설명과 위험 요인을 자동 채웁니다. 컴플라이언스 검증 규칙 엔진이 앞뒤 일관성을 검사합니다 |
+| 4 | 기업 재무 보고서 자동 생성과 경영 이상 경고 시스템 | 재무 시스템 데이터를 자동 수집하고 LLM이 재무 분석과 경영진 논의 부분을 생성합니다. 이상 지표 경고 규칙을 제공합니다 |
+| 5 | 재무 증빙 정보 추출과 질의응답 도우미 | 청구서 이미지를 업로드하면 OCR이 정보를 인식하고, LLM이 증빙 관련 질문에 답합니다. 부가가치세 청구서, 기차표 등을 지원합니다 |
+| 6 | 컴플라이언스 사례 지능형 검색과 질의응답 도우미 | 감독기관 처벌 사례를 바탕으로 지식베이스를 구축하고, LLM이 컴플라이언스 질문에 답하며 사례 참고를 제공합니다 |
+| 7 | 보험 설계사 지능형 화법 연습 | LLM이 서로 다른 유형의 고객을 연기해 모의 대화를 진행하고, 설계사 화법의 규정 준수와 설득력을 평가합니다. 녹음 전사 분석을 제공합니다 |
+| 8 | 보험 상품 조항 분석과 경쟁 상품 비교 플랫폼 | 조항을 구조화해 파싱하고 LLM이 장점 요약과 주의사항을 생성합니다 |
+| 9 | 고객 화법 감정 인식 서비스 | 음성 감정 인식과 화법 컴플라이언스 검사를 결합해 설계사에게 실시간 개선 제안을 피드백합니다 |
+| 10 | 보험금 청구 진행 상황 지능형 조회와 대화 도우미 | 사용자가 보험증권 번호나 접수 번호를 입력하면 LLM이 청구 진행 상황을 조회하고 청구 관련 질문에 답합니다 |
+
+## 8. 기업 서비스
+
+기업 서비스 장면은 조직 운영 효율과 관리 수준을 높이는 데 힘씁니다. 흔한 앱에는 고객 관계 관리, 영업 예측, 여론 모니터링, HR 지능형 관리 등이 있으며, 기업의 디지털 전환 업그레이드를 돕습니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 고객 유지 분석과 이탈 경고 플랫폼 | 행동 데이터 추적으로 사용자 조작을 수집하고, ML 모델이 이탈 확률을 예측하며, LLM이 유지 제안을 생성합니다 |
+| 2 | B2B 잠재 고객 도달과 마케팅 메일 플랫폼 | 기업 상공 데이터를 선별해 목표 고객을 찾고, LLM이 개인화 마케팅 콘텐츠를 생성합니다. 메일 대량 발송 플랫폼을 연결합니다 |
+| 3 | 영업 파이프라인 모니터링과 성과 예측 플랫폼 | CRM 데이터를 자동 수집하고 LLM이 영업 퍼널을 분석해 성과 달성을 예측합니다. 이상 경고를 관리자에게 푸시합니다 |
+| 4 | 브랜드 여론 모니터링과 위기 경고 레이더 | 전 웹 여론 데이터(소셜 미디어, 뉴스, 포럼)를 수집하고, LLM이 감정과 전파 추세를 분석합니다. 위기 경고를 푸시합니다 |
+| 5 | 직장 메일 지능형 작성과 커뮤니케이션 감정 관리 도우미 | 메일 컨텍스트를 이해하고 LLM이 전문적인 메일 초안을 생성합니다. 감정 분석으로 개선 제안을 피드백합니다 |
+| 6 | 이력서 지능형 파싱과 직무 매칭 시스템 | PDF 이력서를 파싱해 핵심 정보를 추출하고, LLM이 적합한 직무를 매칭하며 면접 제안을 생성합니다. ATS 시스템을 연결합니다 |
+| 7 | 기업 직원 온보딩 안내와 질의응답 도우미 | 온보딩 문서 지식베이스 RAG 검색을 통해 LLM이 신입 직원의 자주 묻는 질문에 답합니다 |
+| 8 | 직원 성과 피드백과 OKR 목표 관리 플랫폼 | OKR 시스템 데이터를 수집하고 LLM이 목표 완료 상황을 분석해 피드백 제안을 생성합니다. 360도 피드백을 수집합니다 |
+| 9 | 지능형 회의 기록과 할 일 관리 | 회의 녹음을 전사하고 LLM이 핵심 논의점과 할 일을 추출합니다. 작업 시스템에 할 일을 자동 생성합니다 |
+| 10 | 청구서 인식과 비용 정산 자동 처리 | OCR이 청구서 정보를 인식하고, 청구서 진위와 비용 정산 컴플라이언스를 자동 검증합니다. 재무 시스템을 연결합니다 |
+
+## 9. 콘텐츠 생산과 운영
+
+콘텐츠 생산과 운영 장면은 창의 생성과 트래픽 운영에 집중합니다. 핵심 앱에는 문안 창작, 짧은 영상 제작, 디지털 휴먼 라이브, SEO 최적화 등이 있으며, 기업의 콘텐츠 생산 효율과 마케팅 전환율을 높입니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 영상과 소설 콘텐츠 창작 보조 플랫폼 | LLM이 스토리 개요, 인물 설정, 대사 생성 등 창작 보조를 제공합니다. 마인드맵으로 이야기 구조를 시각화합니다 |
+| 2 | 기업 브랜드 스토리와 PR 기사 지능형 작성 도우미 | 브랜드 키워드와 제품 정보를 입력하면 LLM이 여러 스타일의 문안 버전을 생성합니다. A/B 테스트 인터페이스를 연결합니다 |
+| 3 | 가상 디지털 휴먼 라이브 상호작용과 송출 관리 시스템 | 디지털 휴먼 모델링 + TTS 음성 + LLM 대화로 시청자 댓글에 실시간 응답합니다. OBS 송출을 통합합니다 |
+| 4 | 짧은 영상 스크립트 생성과 지능형 편집 | LLM이 짧은 영상 스크립트와 콘티를 생성하고, Sora/Runway가 영상 클립을 생성합니다. 편집 도구가 자동으로 이어 붙입니다 |
+| 5 | 영업 대화 음성 전사와 화법 추천 | 전화 녹음 ASR 전사 후 LLM이 대화를 분석하고 베스트 화법을 추천합니다. CRM 시스템을 통합합니다 |
+| 6 | 마케팅 콘텐츠 지능형 생성과 디자인 시스템 | 제품 정보를 입력하면 LLM이 마케팅 문안과 판매 포인트를 추출합니다. Canva/Gaoding Design 템플릿을 통합합니다 |
+| 7 | 다중 플랫폼 광고 집행 ROI 실시간 모니터링과 전략 조정 시스템 | 광고 플랫폼 API를 연결해 데이터를 수집하고, LLM이 집행 효과를 분석해 최적화 제안을 생성합니다. 이상 경고를 푸시합니다 |
+| 8 | 검색엔진 키워드와 트래픽 분석 | Baidu Index, 5118 데이터를 수집하고, LLM이 키워드 추세와 경쟁도를 분석합니다. 콘텐츠 주제를 추천합니다 |
+| 9 | 경쟁사 광고 집행 분석 플랫폼 | 제3자 데이터 플랫폼 API로 경쟁사 광고를 수집하고, LLM이 집행 전략과 창의 특징을 분석합니다 |
+| 10 | 전 웹 핫이슈 주제 지능형 분석과 콘텐츠 추천 시스템 | Weibo 핫검색어, Douyin 인기 순위 데이터를 수집하고, LLM이 핫이슈 추세를 분석해 주제 각도를 추천합니다. 캘린더형 콘텐츠 일정을 제공합니다 |
+
+## 10. 스마트 행정 관리
+
+스마트 행정 장면은 정부 서비스 효율과 거버넌스 능력을 높이는 데 힘씁니다. 대표 앱에는 공공 민원 핫라인 지능형 안내, 정책 지능형 질의응답, 행정 승인 최적화, 도시 사건 관리 등이 있으며, 디지털 정부 구축을 추진합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 12345 공공 민원 핫라인 지능형 음성 안내와 자동 배정 시스템 | 시민 전화 음성을 인식하고, LLM이 요구를 이해해 해당 부서로 지능적으로 배정합니다. 티켓 시스템이 자동으로 흐름을 이어갑니다 |
+| 2 | 공공 서비스 센터 지능형 안내와 정책 질의응답 봇 | 공공 행정 지식베이스 RAG 검색으로 LLM이 업무 처리 흐름과 정책 질문에 답합니다. 번호표 시스템을 연결합니다 |
+| 3 | 기업 지원 정책 지능형 매칭과 정밀 푸시 플랫폼 | 정책을 구조화해 파싱하고 기업 프로필과 적용 가능한 정책을 자동 매칭합니다. 문자/메일 푸시 알림을 제공합니다 |
+| 4 | 행정 승인 자료 지능형 사전 검토와 컴플라이언스 검증 도우미 | 자료 OCR 인식과 핵심 정보 추출을 수행하고, LLM이 자료 완전성과 컴플라이언스를 검증합니다 |
+| 5 | 공공 안전 영상 감시 이상 행동 탐지 시스템 | 영상 스트림을 실시간 분석하고, CV 모델이 이상 행동(싸움, 넘어짐 등)을 탐지합니다. 경고를 푸시합니다 |
+| 6 | 도시 그리드 사건 지능형 식별과 dispatch 관리 플랫폼 | 도시 감지 데이터(IoT, 카메라)를 수집하고, LLM이 사건 유형을 식별해 배정합니다 |
+| 7 | 사회 여론 빅데이터 분석과 위험 경고 시스템 | 공공 민원 핫라인, 온라인 여론, 현장 방문 등 다중 출처 데이터를 융합 분석합니다. LLM이 위험 핫스팟을 식별합니다 |
+| 8 | 공공 기록 디지털화 인식과 지능형 보관 관리 플랫폼 | OCR이 기록 문자를 인식하고, LLM이 핵심 정보를 추출해 자동 분류합니다. 전문 검색을 지원합니다 |
+| 9 | 돌발 공공 사건 비상 지휘와 구조 자원 지능형 dispatch 플랫폼 | 사건 정보를 수집하고, LLM이 비상 대응 방안을 생성합니다. 자원 dispatch 최적화 알고리즘을 사용합니다 |
+| 10 | 대기 환경 오염 그리드 모니터링과 정밀 원인 추적 시스템 | 공기질 센서 데이터를 수집하고, CV 모델이 오염원을 식별합니다. LLM이 오염 추세를 분석하고 원인을 추적합니다 |
+
+## 11. 법무와 계약 관리
+
+법무 장면은 법률 서비스 효율 향상과 컴플라이언스 관리에 집중합니다. 흔한 앱에는 계약 검토, 사건 분석, 법규 모니터링, 법률 문서 생성 등이 있으며, 법률 종사자에게 지능형 도구 지원을 제공합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 계약 위험 구멍 원클릭 점검 Agent | 계약 텍스트를 구조화해 파싱하고, LLM이 위험 체크리스트와 대조해 잠재 문제를 식별합니다. 고위험 조항을 표시합니다 |
+| 2 | 기업 계약 전 생명주기 컴플라이언스 검토와 수정 제안 플랫폼 | 계약 조항을 법규 라이브러리와 비교하고, LLM이 컴플라이언스 검토 보고서를 생성합니다. 수정 제안을 추적합니다 |
+| 3 | 유사 사건 승소율 AI 지능형 평가 고문 | 사건 특징을 추출하고 유사 판례를 검색해 매칭합니다. LLM이 승소에 영향을 주는 요인을 분석합니다 |
+| 4 | 법규 변경 실시간 모니터링과 업무 영향 분석 레이더 | 법규 데이터베이스를 실시간 업데이트하고, LLM이 변경 내용을 해석해 업무 영향을 평가합니다. 경고를 푸시합니다 |
+| 5 | 변호사 내용증명 AIGC 자동 초안 도구 | 사실 진술을 입력하면 LLM이 표준 변호사 서한 템플릿을 생성합니다. 요소 검사와 컴플라이언스 검증을 제공합니다 |
+| 6 | 재판 녹음 실시간 전사와 쟁점 자동 추출 기록기 | 법정 녹음을 ASR로 전사하고, LLM이 쟁점과 핵심 논점을 추출합니다. 타임스탬프를 표시합니다 |
+| 7 | 전 웹 지식재산권 침해 단서 자동 모니터링과 블록체인 증거 보전 시스템 | 이커머스 플랫폼, 소셜 미디어 침해를 모니터링합니다. 침해 증거를 자동 수집하고 보전합니다 |
+| 8 | LLM 기반 IPO 투자설명서 핵심 데이터 일관성 검토와 위험 경고 Agent | 투자설명서 여러 장의 데이터를 비교하고, LLM이 불일치와 데이터 이상을 식별합니다. 위험을 표시합니다 |
+| 9 | 복잡한 법률 조항을 쉬운 말로 바꾸는 설명 플러그인 | 선택한 법률 조문에 대해 LLM이 쉽고 이해하기 쉬운 설명을 생성합니다 |
+| 10 | 사건 증거 사슬 지능형 정리와 시각화 표시 시스템 | 증거 자료를 업로드하면 LLM이 증거 관계와 타임라인을 분석합니다 |
+
+## 12. 여행과 이동 서비스
+
+여행과 이동 장면은 여행 경험과 서비스 편의성을 높이는 데 힘씁니다. 핵심 앱에는 지능형 일정 계획, 가격 예측, 가상 안내, 번역 서비스 등이 있으며, 여행을 더 쉽고 즐겁게 만듭니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | AIGC 기반 게으른 여행 일정 생성기 | 사용자 선호(일수, 예산, 관심사)를 입력하면 LLM이 매일의 일정을 생성합니다. 관광지 API로 운영 시간과 티켓 정보를 가져옵니다 |
+| 2 | 전 웹 항공권 호텔 가격 추세 예측과 저가 자동 잠금 봇 | OTA 가격 데이터를 수집하고 ML 모델이 가격 추세를 예측합니다. 가격 모니터링 알림을 제공합니다 |
+| 3 | 항공편 취소 후 여러 항공사 일정 재구성과 비상 방안 추천 고문 | 항공편 상태를 모니터링하고, LLM이 대체 일정 방안을 분석합니다. 여러 항공사 가격 비교를 제공합니다 |
+| 4 | 비자 자료 지능형 사전 검토와 자동 양식 작성 보조 시스템 | 자료 사진을 업로드하면 OCR이 정보 완전성을 검사합니다. 양식을 자동으로 채웁니다 |
+| 5 | 해외여행 실시간 음성 번역과 메뉴 시각 번역 매니저 | 오프라인 음성 번역 모델과 메뉴 이미지 OCR 인식 및 번역을 제공합니다 |
+| 6 | 빅데이터 실제 평가 기반 호텔 위험 회피 가이드 분석기 | 호텔 리뷰 데이터를 수집하고 LLM이 긍정·부정 평가 키워드를 추출합니다 |
+| 7 | 목적지 몰입형 VR 미리보기와 가상 객실 선택 상호작용 플랫폼 | 360도 파노라마 이미지를 수집하고 VR 기술로 몰입형 미리보기를 구현합니다. 객실 가상 투어를 제공합니다 |
+| 8 | 여행 발자취 자동 여행기와 소셜 문안 생성 도우미 | 사진의 시간과 장소 정보를 추출하고, LLM이 여행기 문안을 생성합니다. 템플릿 레이아웃을 생성합니다 |
+| 9 | 기업 출장 청구서 자동 수집과 컴플라이언스 정산 관리 플랫폼 | 출장 플랫폼 API를 연결하고 청구서 정보를 자동 수집합니다. 컴플라이언스 검증을 수행합니다 |
+| 10 | 관광지 혼잡 실시간 예측과 분산 관람 경로 계획 내비게이션 | 관광지 방문객 데이터를 수집하고 ML 모델이 혼잡 시간대를 예측합니다. 분산 관람을 추천합니다 |
+
+## 13. 감정적 동행
+
+감정적 동행 장면은 정신 건강과 감정적 위로에 집중합니다. 대표 앱에는 가상 파트너, 감정 상담, 인지 훈련, 심리 상담 등이 있으며, 사용자에게 상시 동행과 지원을 제공합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | LLM 대형 모델 기반 24시간 깊은 동행 가상 파트너 | 기억 시스템이 대화 기록을 저장하고, LLM이 개인화 답변을 생성합니다. 감정 지원 모듈을 제공합니다 |
+| 2 | 멀티모달 감정 인식과 심리 상담 AI 고문 | 음성 억양 분석 + 문자 감정 인식으로 LLM이 상담 제안을 생성합니다. 위기 개입 경고를 제공합니다 |
+| 3 | 알츠하이머 노인 AI 인지 훈련과 기억 깨우기 디지털 휴먼 | 인지 게임(기억, 계산, 언어) 훈련을 제공하고, 오래된 사진/노래가 기억 회상을 트리거합니다 |
+| 4 | 사회불안인을 위한 AIGC 모의 소셜 연습 코치 | 가상 소셜 장면을 시뮬레이션하고, LLM이 서로 다른 역할을 맡습니다. 소셜 기술 제안을 제공합니다 |
+| 5 | 생성형 AI 어린이 잠자리 이야기 맞춤 생성기 | 보호자가 주제와 선호를 입력하면 LLM이 맞춤 이야기를 생성합니다. 배경음악 생성을 제공합니다 |
+| 6 | 고인의 디지털 생명 복원과 LLM 시공간 대화 시스템 | 생전 자료(음성, 문자)로 개인화 모델을 학습하고, 기억 대화를 생성합니다 |
+| 7 | MBTI 데이터 기반 AI 성격 거울과 공감형 챗봇 | MBTI 테스트 결과를 입력하면 LLM이 성격 분석과 공감 답변을 생성합니다. 성격 매칭 추천을 제공합니다 |
+| 8 | 상시 기분 모니터링과 AI 긍정 감정 격려 도우미 | 일상 기분 상태를 기록하고, LLM이 추세를 분석해 격려 콘텐츠를 생성합니다. 긍정 알림을 푸시합니다 |
+| 9 | 개인정보 보호 등급 청소년 AI 고민 털어놓기 공간 | 익명 털어놓기 입구를 제공하고 LLM이 경청과 제안을 제공합니다. 민감어 경고를 제공합니다 |
+| 10 | 자율 진화 능력을 갖춘 AI 가상 반려동물 키우기 시스템 | 반려동물 성격 모델을 학습하고, 대화 상호작용으로 성장·진화합니다. 가상 꾸미기 시스템을 제공합니다 |
+
+## 14. 휴식과 엔터테인먼트
+
+휴식과 엔터테인먼트 장면은 풍부한 디지털 엔터테인먼트 경험을 제공하는 데 힘씁니다. 흔한 앱에는 게임 NPC 지능형 의사결정, 추리 게임 보조, 콘텐츠 창작, 오디오·비디오 처리 등이 있으며, 사용자의 다양한 엔터테인먼트 요구를 만족시킵니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | LLM 구동 오픈월드 게임 NPC 자율 의사결정 엔진 | NPC 행동 트리에 LLM 의사결정을 융합하고, 대화 시스템이 개인화 상호작용을 생성합니다. 행동 엔진을 사용합니다 |
+| 2 | 몰입형 추리 게임 AIGC 이야기 추론과 DM 진행 보조 도구 | 플레이어 선택이 이야기 분기를 트리거하고, LLM이 추리 로직을 생성합니다. 단서 카드를 자동 생성합니다 |
+| 3 | 인터랙티브 소설 결말 생성식 수정기 | 독자 선택이 이야기 방향에 영향을 주고, LLM이 여러 결말 분기를 생성합니다 |
+| 4 | 2D 캐릭터 3D 모델링 AIGC 자동 생성 워크벤치 | 설명 텍스트로 캐릭터 스케치를 생성하고, 3D 모델링 도구가 자동 모델링합니다. 재질 텍스처를 렌더링합니다 |
+| 5 | e스포츠 전황 CV 시각 분석과 AI 지능형 해설자 | 게임 화면을 실시간 분석하고 핵심 순간을 식별합니다. LLM이 해설 문안을 생성합니다 |
+| 6 | 개인화 유머 콘텐츠 추천 알고리즘 엔진 | 사용자 관심 프로필을 만들고 유머 콘텐츠를 매칭해 추천합니다 |
+| 7 | AI 지능형 음정 보정과 KTV 보컬 미화 소프트웨어 | 오디오 노이즈 제거와 보컬 강화 처리를 수행합니다. AI 음정 보정 알고리즘을 사용합니다 |
+| 8 | 영상 드라마 캐릭터 전용 이야기 AI 추출과 편집 도구 | 영상 내용을 분석하고 캐릭터 관련 장면을 추출합니다. 자동 편집으로 생성합니다 |
+| 9 | 다중 역할 TTS 음성 합성 오디오북 자동 생성 시스템 | 텍스트 역할을 배분하고 개인화 음색을 생성합니다. 배경음악과 효과음을 추가합니다 |
+| 10 | 보드게임·카드게임 강화학습 대국 회고 코치 | 게임 국면을 분석하고 AI 상대가 모의 대국을 진행합니다. 회고 제안을 생성합니다 |
+
+## 15. 이커머스 서비스
+
+이커머스 서비스 장면은 운영 효율과 전환 향상에 집중합니다. 핵심 앱에는 상품 콘텐츠 생성, 라이브 커머스, 고객 서비스, 가격 분석 등이 있으며, 판매자가 지능형 운영을 구현하도록 돕습니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 고전환율 AIGC 상품 상세 페이지 대량 생산 도구 | 상품 정보를 입력하면 LLM이 판매 포인트 문안과 장면 설명을 생성합니다. 배경 이미지를 생성합니다 |
+| 2 | 의류 가상 모델 AI 지능형 착용과 전시 영상 생성 공장 | 의류 평면 이미지를 처리하고 가상 모델 착용 효과를 생성합니다. 여러 각도 전시 영상을 만듭니다 |
+| 3 | 크로스보더 이커머스 다국어 LLM 현지화 번역과 윤문 도우미 | 상품 설명을 여러 언어로 번역하고 문화에 맞게 다듬습니다. 여러 플랫폼 게시 인터페이스를 제공합니다 |
+| 4 | NLP 기반 고객 감정 분석과 지능형 답변 봇 | 문의 대화 감정을 분석하고, 위로 답변을 자동 생성합니다. 긍정·부정 리뷰를 분류합니다 |
+| 5 | 24시간 상시 AIGC 디지털 휴먼 라이브 커머스 시스템 | 디지털 휴먼 이미지 + 실시간 화법 생성으로 상품 정보를 실시간 호출합니다. 댓글 상호작용 답변을 제공합니다 |
+| 6 | 전 웹 동일 상품 AI 가격 비교와 추세 예측 플러그인 | 이커머스 플랫폼 가격을 크롤링하고 가격 비교 차트를 표시합니다. 가격 추세를 예측합니다 |
+| 7 | 구매자 후기 이미지 AI 지능형 선별과 짧은 영상 합성 플랫폼 | 구매자 후기 이미지 품질을 점수화하고 우수 콘텐츠를 자동 추천합니다. 짧은 영상 템플릿 합성을 제공합니다 |
+| 8 | LLM 기반 실시간 영업 대화 음성 분석과 베스트 화법 추천 | 통화 ASR 전사를 수행하고 실시간 화법 컴플라이언스 검사를 제공합니다. 화법을 추천합니다 |
+| 9 | 시장 유행 추세 AI 통찰과 히트 상품 예측 엔진 | 소셜 미디어와 이커머스 데이터를 수집·분석하고 LLM이 추세 핫이슈를 통찰합니다. 상품 선정 제안을 추천합니다 |
+| 10 | 사적 트래픽 사용자 프로필 AI 군집화와 정밀 운영 시스템 | 사용자 행동 데이터를 군집 분석하고 프로필 태그를 생성합니다. 자동화 마케팅을 트리거합니다 |
+
+## 16. 에너지
+
+에너지 장면은 에너지 업계의 지능형 관리와 녹색 전환을 구현하는 데 힘씁니다. 대표 앱에는 전력 사용 분석, 설비 검사, 탄소 배출 산정, dispatch 최적화 등이 있으며, 에너지 시스템의 효율적 운영을 추진합니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 가정 전력 사용 행동 AI 분석과 절전 전략 고문 | 스마트 전력계 데이터를 수집하고 전력 사용 패턴을 분석합니다. LLM이 절전 제안을 생성합니다 |
+| 2 | 태양광 모듈 결함 드론 CV 시각 식별 시스템 | 드론 점검 촬영과 열적외선 이미지 분석을 수행합니다. 결함 탐지 표시를 제공합니다 |
+| 3 | 전력 현물 거래 가격 AI 추세 예측과 자동 수익 전략 Agent | 전력 시장 데이터를 수집하고 가격 예측 모델을 사용합니다. 전략 생성과 거래 실행을 제공합니다 |
+| 4 | 에너지 저장 배터리 건강도 AI 비파괴 검사와 열폭주 위험 경고 시스템 | 배터리 운전 데이터를 모니터링하고 건강도 평가 모델을 사용합니다. 위험 경고를 푸시합니다 |
+| 5 | 기업 전 링크 탄소 배출 AI 자동 산정과 ESG 보고서 생성 도우미 | 에너지 소비 데이터를 수집하고 탄소 배출 계수를 계산합니다. ESG 보고서를 자동 생성합니다 |
+| 6 | 전력망 극단 기상 부하 AI 예측과 비상 dispatch 지휘 시스템 | 기상 데이터를 연결하고 부하 예측 모델을 사용합니다. dispatch 전략을 생성합니다 |
+| 7 | 주유소 위반 행동 AI 영상 식별과 경보 감시자 | 영상 감시를 분석하고 위반 행동(전화, 흡연 등)을 탐지합니다. 경고를 푸시합니다 |
+| 8 | 장거리 송유·가스관 누출 음파 AI 모니터링과 정밀 위치 지정 시스템 | 음파 센서 데이터를 수집하고 누출 탐지 모델을 사용합니다. 위치 지정 알고리즘으로 계산합니다 |
+| 9 | 가상 발전소 자원 집합과 AI 전력 거래 의사결정 시스템 | 분산 자원을 연결하고 집합 최적 dispatch를 수행합니다. 거래 전략을 실행합니다 |
+| 10 | 광산 인원 위치 AI 추적과 위험 구역 침입 경보 | UWB/블루투스 위치 지정으로 인원 궤적을 추적합니다. 위험 구역 전자 펜스를 제공합니다 |
+
+## 17. 오디오와 비디오
+
+오디오와 비디오 장면은 콘텐츠 생산과 미디어 처리에 집중합니다. 흔한 앱에는 영상 편집, 음성 합성, 자막 생성, 영상 복원 등이 있으며, 오디오·비디오 콘텐츠의 생산 효율과 품질을 높입니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | 장편 영상 하이라이트 AI 식별과 짧은 영상 자동 편집 도구 | 영상 내용을 분석하고 키프레임을 식별합니다. 하이라이트 장면을 자동 편집합니다 |
+| 2 | 영상 배경 소음 AI 지능형 분리와 음성 강화 도우미 | 오디오 분리 모델로 배경 소음을 제거합니다. 음성을 강화 처리합니다 |
+| 3 | 오래된 영상 4K 초해상 복원과 AI 지능형 색 입히기 워크벤치 | 영상 초해상도 모델로 오래된 화질을 복원합니다. AI가 자동으로 색을 입힙니다 |
+| 4 | 텍스트를 실제 사람 수준 TTS 더빙으로 바꾸는 감정 제어 시스템 | 다중 음색 TTS 모델과 감정 제어 생성을 제공합니다. 오디오 내보내기를 지원합니다 |
+| 5 | 영상 음성 ASR 자동 인식과 이중 언어 자막 생성 도구 | 음성 인식으로 자막을 생성하고 여러 언어로 번역합니다. 이중 언어 자막을 겹쳐 표시합니다 |
+| 6 | 영상 화면 불필요 객체 AI 지능형 지우기 엔진 | 영상 객체 추적, 객체 제거 복원, 프레임 간 일관성 처리를 수행합니다 |
+| 7 | 저작권 없는 배경음악 AIGC 자동 작곡기 | 음악 생성 모델을 사용하고 감정 스타일을 제어할 수 있습니다. 저작권 검사를 제공합니다 |
+| 8 | 특정 인물 음색 AI 클론과 변성 변환 소프트웨어 | 소량의 음성 샘플로 음색 모델을 학습합니다. 변성 처리를 제공합니다 |
+| 9 | 대본 원클릭 콘티 스크립트 변환과 AI 동적 프리비즈 영상 생성 플랫폼 | 대본을 파싱해 콘티를 생성하고, AI가 프리비즈 영상을 생성합니다 |
+| 10 | 회의 녹음 AI 지능형 전사와 핵심 할 일 추출 도우미 | 여러 사람 회의 음성을 분리 전사하고, LLM이 할 일을 추출합니다. 타임스탬프를 표시합니다 |
+
+## 18. AI 마케팅
+
+AI 마케팅 장면은 마케팅 효율과 창의 산출을 높이는 데 힘씁니다. 핵심 앱에는 문안 생성, 포스터 설계, 핫이슈 추적, 경쟁사 분석 등이 있으며, 기업이 정밀 마케팅과 브랜드 전파를 구현하도록 돕습니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | Xiaohongshu 히트 문안 AIGC 자동 작성 엔진 | 주제를 입력하면 LLM이 추천형 문안을 생성합니다. 이모지와 주제 태그를 최적화합니다 |
+| 2 | 마케팅 포스터 AI 지능형 레이아웃과 다중 사이즈 적응 도구 | 문안을 입력하면 포스터 템플릿을 지능적으로 매칭하고 여러 사이즈로 내보냅니다 |
+| 3 | 브랜드 LOGO 창의 AIGC 생성과 VI 체계 구축 플랫폼 | 브랜드 키워드를 입력하면 LOGO 아이디어를 생성합니다. VI 규범을 생성합니다 |
+| 4 | 전 웹 핫이슈 AI 추적과 트렌드 활용 마케팅 아이디어 생성 도우미 | 핫이슈 데이터를 수집하고 LLM이 마케팅 각도를 분석합니다. 창의 방안을 생성합니다 |
+| 5 | 광고 집행 ROI 실시간 모니터링과 AI 예산 입찰 매니저 | 광고 플랫폼 데이터를 연결하고 효과 분석 모델을 사용합니다. 입찰 전략을 최적화합니다 |
+| 6 | 경쟁사 마케팅 전략 심층 해석과 AI 주간 보고서 생성기 | 경쟁사 콘텐츠를 수집 분석하고 전략을 추출합니다. 주간 보고서를 자동 생성합니다 |
+| 7 | 검색엔진 키워드 AI 배치와 유입 글 대량 작성 | 키워드를 분석하고 글을 대량 생성합니다. SEO 최적화 제안을 제공합니다 |
+| 8 | 천인천면 개인화 마케팅 메일 AI 작성 전문가 | 사용자 프로필 데이터로 개인화 콘텐츠를 생성합니다. A/B 테스트를 지원합니다 |
+| 9 | 브랜드 평판 전 웹 모니터링과 여론 위기 AI 경고 레이더 | 전 웹 여론 데이터를 수집하고 감정을 분석합니다. 위기 경고를 푸시합니다 |
+| 10 | 짧은 영상 스크립트 아이디어 AIGC 생성과 콘티 지도 도우미 | 주제를 입력하면 스크립트와 콘티를 생성합니다. 촬영 제안을 안내합니다 |
+
+## 19. 데이터 지능
+
+데이터 지능 장면은 데이터 분석과 가치 발굴에 집중합니다. 대표 앱에는 자연어 질의, 시각화 생성, 데이터 거버넌스, 지식 그래프 구축 등이 있으며, 기업이 데이터 기반 의사결정 지원을 구현하도록 돕습니다.
+
+| 번호 | 앱 장면 이름 | 구현 참고 |
+| :--: | ------------ | -------- |
+| 1 | Text-to-SQL 기반 자연어 데이터 조회 엔진 | 자연어를 SQL 질의로 변환하고 결과를 시각화해 표시합니다 |
+| 2 | 대화형 BI: 한 문장으로 시각화 차트 생성 | 데이터 요구를 설명하면 차트를 자동 생성합니다. 여러 차트 유형 전환을 지원합니다 |
+| 3 | 스크린샷 원클릭 Excel 표 인식 도구 | 스크린샷 업로드 후 VLM이 표 구조와 데이터를 인식합니다. Excel 파일로 내보냅니다 |
+| 4 | 이미지와 스크린샷을 Excel 표로 바꾸는 AI 인식 도구 | 이미지 OCR이 표 구조를 인식하고 데이터를 Excel로 내보냅니다 |
+| 5 | 다중 출처 이기종 데이터 지식 그래프 자동 구축 | 여러 데이터 소스를 연결하고 엔티티와 관계를 추출합니다. 그래프 데이터베이스에 저장합니다 |
+| 6 | 데이터 보고서 지능형 해석과 추세 분석 도우미 | 데이터 보고서 이미지를 업로드하거나 데이터를 입력하면 VLM이 차트 내용을 해석하고 추세를 분석합니다 |
+| 7 | 데이터베이스 테이블 구조 지능형 해석과 질의 예시 생성 도우미 | 테이블명이나 필드 설명을 입력하면 LLM이 테이블 생성 설명과 예시 SQL 질의를 생성합니다 |
+| 8 | 기업 마스터 데이터 지능형 정렬과 AI 중복 제거 거버넌스 | 다중 출처 마스터 데이터를 매칭하고 중복 기록을 식별합니다. 병합 규칙 설정을 제공합니다 |
+| 9 | 데이터 요구 문서 지능형 테스트 케이스 변환 도구 | 데이터 요구 설명을 입력하면 LLM이 테스트 장면과 검증 케이스를 생성합니다 |
+| 10 | 데이터 지표 정의 지능형 질의응답 도우미 | 지표 정의 문서를 바탕으로 지식베이스를 구축하고, LLM이 지표 정의와 계산 로직 등 질문에 답합니다 |
diff --git a/docs/ko-kr/stage-1/appendix-jobs-to-be-done/index.md b/docs/ko-kr/stage-1/appendix-jobs-to-be-done/index.md
index 68d0d33..a618d82 100644
--- a/docs/ko-kr/stage-1/appendix-jobs-to-be-done/index.md
+++ b/docs/ko-kr/stage-1/appendix-jobs-to-be-done/index.md
@@ -1,93 +1,497 @@
---
-title: 'Jobs to Be Done으로 사용자가 진짜 하려는 일 찾기'
-description: 'JTBD 관점으로 AI 제품 아이디어와 사용자 요구를 정리하는 방법을 설명합니다.'
+title: 'Jobs to Be Done으로 사용자가 진짜 완료하고 싶은 일 찾기'
+description: '제로 베이스 독자를 위한 Jobs to Be Done 입문 글입니다. 사용자는 기능을 사는 것이 아니라 특정 장면에서 제품을 "고용"해 진전을 완성한다는 관점을 이해하고, JTBD로 제품 방향, 인터뷰 질문, AI 프롬프트를 분해하는 법을 배웁니다.'
---
-# Jobs to Be Done으로 사용자가 진짜 하려는 일 찾기
+
-Jobs to Be Done, 줄여서 JTBD는 사용자를 단순한 인구통계로 보지 않고 "어떤 상황에서 어떤 진전을 이루려는 사람"으로 보는 방법입니다.
+# Jobs to Be Done으로 사용자가 진짜 완료하고 싶은 일 찾기
-## 1. JTBD 기본 문장
+
+
+## 본 장 안내
+
+
+
+많은 사람이 처음 제품을 만들 때 가장 쉽게 하는 실수는 모든 주의를 "내가 어떤 기능을 만들 것인가"에 두는 것입니다. 다른 제품에 지능형 분류가 있으면 나도 넣고 싶고, 자동 요약이 있으면 나도 붙이고 싶고, 다른 사람이 Agent, 멀티모달, 워크플로우를 만들면 나도 빼면 안 될 것 같습니다.
+
+하지만 현실에서 사용자는 "이 기능 이름이 멋있어서" 제품을 쓰는 경우가 드뭅니다. 그들은 더 자주 어떤 구체적인 순간에 어떤 일을 앞으로 밀고 싶어 합니다. 그래서 일시적으로 도구, 서비스, 심지어 사람을 "고용"해 그 한 단계를 완성합니다.
+
+이것이 바로 **Jobs to Be Done(JTBD)** 방법이 우리에게 상기시키는 것입니다. **사용자는 기능 자체를 구매하는 것이 아니라, 자신이 어떤 진전을 완성하도록 도와주는 해결책을 고용합니다.**
+
+이 글은 가능한 한 쉬운 언어로 JTBD를 처음부터 이해하게 하고, AI 애플리케이션을 만들 때 바로 쓸 수 있는 분석 도구로 바꾸도록 안내합니다.
+
+
+
+::: info 최소 SOP
+**목적**: 읽고 나면 흐릿한 아이디어를, 기능 이름만 잔뜩 있는 상태가 아니라 실제 사용자 장면이 있는 수요 한 문장으로 수렴하는 법을 더 명확히 알게 됩니다.
+
+**행동 항목**: 흐릿한 아이디어 1문장을 쓰고, 잠재 사용자 3명에게 "최근 한 번은 어떻게 처리했는지"를 묻고, JTBD 문장 1개로 정리합니다.
+
+**결과**: 더 명확한 수요 가설을 얻고, 첫 버전에서 무엇을 먼저 해결해야 하는지 알게 됩니다.
+
+**키워드 이동**: [JTBD란 무엇인가](#jtbd-what) · [한 문장 공식](#jtbd-formula) · [AI는 어떻게 도와줄 수 있나](#jtbd-ai)
+:::
+
+## 다음 내용을 배우게 됩니다
+
+1. Jobs to Be Done이 무엇이고, 왜 "기능 브레인스토밍"보다 실제 수요에 더 가까운지
+2. "사용자가 원한다고 말한 기능"과 "사용자가 진짜 완료하고 싶은 일"을 구분하는 법
+3. 간단한 템플릿으로 흐릿한 아이디어를 장면, 트리거, 장애물, 성공 기준으로 분해하는 법
+4. JTBD를 AI 제품, 인터뷰 질문, 프롬프트 정리에 활용하는 법
+
+
+## [1. Jobs to Be Done이란 무엇인가](#top-jtbd)
+
+Jobs to Be Done은 보통 **JTBD**라고 줄여 부릅니다. 그 핵심 생각은 Clayton Christensen 팀이 널리 알린 고전적인 표현과 관련 있습니다. **사용자는 어떤 제품을 "고용"해 하나의 일을 완성한다**는 것입니다.
+
+여기서 말하는 "일"은 할 일 목록의 표면적 동작이 아니라, 사용자가 자신의 상태에서 일으키고 싶은 어떤 **진전**입니다. 예를 들면 다음과 같습니다.
+
+- "AI 회의록 도구가 필요하다"가 아니라, "회의 후 10분 안에 핵심, 할 일, 담당자를 정리해서 기억에 의존해 메모를 보충하지 않고 싶다"
+- "가계부 App이 필요하다"가 아니라, "돈이 정확히 어디로 갔는지 알고 싶어서 월말에 다시 불안해지고 싶지 않다"
+- "이력서 최적화기가 필요하다"가 아니라, "그럴듯한 이력서를 더 확신 있게 제출하고 싶고, 매번 지원할 때마다 내가 너무 못 쓴 건 아닌지 의심하고 싶지 않다"
+
+따라서 **JTBD가 주목하는 것은 제품이 어떻게 생겼는지가 아니라, 사용자가 왜 이 순간 그것을 필요로 하는가입니다.**
+
+그래서 겉으로는 서로 달라 보이는 제품도 실제로는 같은 job을 두고 경쟁할 수 있습니다. 사용자가 "출근길을 덜 지루하게 보내고 싶다"면 고용할 수 있는 대상은 숏폼 영상, 팟캐스트, 게임, 채팅, 심지어 잠깐 조는 것일 수 있습니다. 사용자가 "긴 PDF를 빠르게 이해하고 싶다"면 고용할 수 있는 대상은 AI 요약 도구, 인턴, 동료, 억지로 직접 읽기, 또는 일단 안 읽기일 수 있습니다.
+
+이 관점으로 문제를 보면 진짜 경쟁자는 대개 "당신과 비슷하게 생긴 다른 App"만이 아니라, **사용자가 현재 받아들일 수 있는 모든 대체 방안**이라는 것을 알게 됩니다.
+
+## 2. JTBD는 사용자 페르소나, 기능 목록과 무엇이 다른가
+
+많은 초보자는 수요 분석을 시작할 때 먼저 사용자 페르소나를 씁니다. 25세, 여성, 1선 도시, 직장인, 효율 도구를 좋아하고 새 제품을 시도할 의향이 있음. 이런 정보가 완전히 쓸모없다고 할 수는 없지만, 보통 **한 사람이 왜 이 순간 행동을 취하는지 설명하기에는 부족합니다.**
+
+JTBD는 아래 질문에 더 관심이 있습니다.
+
+- 그는 어떤 장면에서 해결책을 찾기로 결정했는가
+- 당시 정확히 무엇에 막혔는가
+- 무엇을 다음 단계로 밀고 싶었는가
+- 지금은 어떤 서툰 방법으로 버티고 있는가
+- 일이 잘 해결된다면 어떤 결과가 "가치 있었다"고 느끼게 하는가
+
+즉, **사용자 페르소나는 "이 사람이 대략 누구인가"에 가깝고, JTBD는 "이 사람이 지금 정확히 무엇을 완료하고 싶은가"에 가깝습니다.**
+
+마찬가지로 기능 목록도 사람을 쉽게 빗나가게 합니다. 사용자가 "Word로 내보내고 싶어요", "AI 문장 개선이 있으면 좋겠어요", "음성 입력이 필요해요"라고 말할 수 있습니다. 하지만 이것들은 모두 표면 표현입니다. JTBD는 계속 아래로 묻습니다.
+
+- 왜 지금 PDF가 아니라 Word 내보내기가 필요한가?
+- 문장을 고치고 싶은 이유는 문체가 나빠서인가, 아니면 대상에 맞게 바꿔야 해서인가?
+- 음성 입력이 필요한 이유는 타이핑이 귀찮아서인가, 아니면 자주 걸으면서, 운전하면서, 회의 직후에 바로 기록해야 해서인가?
+
+많은 경우 **기능은 job의 임시 번역일 뿐**입니다. 기능만 수집하면 "사용자가 말하는 것을 전부 쌓는" 제품이 되기 쉽습니다. 뒤에 있는 job을 볼 수 있어야 진짜로 쓰기 편하고 경쟁력 있는 솔루션을 만들 가능성이 커집니다.
+
+## 3. 제로 베이스도 이해할 수 있는 예시
+
+복잡한 AI 제품을 서둘러 생각하지 말고, 먼저 생활 속 예시에서 시작해 봅시다.
+
+어떤 사람이 아침에 나가기 전 늘 아침을 먹을 시간이 부족해서 지하철역 입구에서 샌드위치와 커피를 자주 산다고 가정해 봅시다. 표면적으로 그는 "아침 식사"를 구매합니다. 하지만 JTBD로 보면 그가 진짜 완료하고 싶은 일은 이럴 수 있습니다.
+
+- 바쁜 아침에 가장 머리를 덜 쓰는 방식으로 한 끼를 해결한다.
+- 회사에 도착하기 전에 배고파 불안해지지 않도록 한다.
+- 아침 식사 때문에 출근 리듬을 망치지 않는다.
+
+이때 사용자가 고용한 것은 "어떤 고정 브랜드의 샌드위치"가 아니라, 아침을 순조롭게 앞으로 밀어 주는 해결책입니다. 옆 편의점이 더 빠르고, 더 가깝고, 더 안정적이면 그는 원래 선택을 바로 바꿀 수 있습니다.
+
+이 논리를 AI 제품으로 옮기면 더 분명해집니다.
+
+예를 들어 "AI 회의록 도구"를 만들고 싶다고 합시다. 기능 층위에만 머물면 쉽게 이런 생각을 하게 됩니다.
+
+- 오디오 업로드를 지원할까
+- 화자 분리를 붙일까
+- Markdown 내보내기를 할까
+- 할 일을 자동 생성할까
+
+이것들은 모두 틀리지 않지만 충분하지 않습니다. JTBD로 한 층 더 물으면 사용자가 진짜 완료하고 싶은 것은 다음일 수 있습니다.
+
+- 회의 후 10분 안에 참석하지 못한 사람에게 논의 결과를 동기화하고 싶다.
+- 할 일, 담당자, 마감일을 깔끔하게 뽑아 팀이 기억에 의존해 협업하지 않게 하고 싶다.
+- 회의 내용을 반복 정리하는 시간을 줄이고, 에너지를 의사결정과 추진에 남기고 싶다.
+
+job이 명확해지면 많은 기능의 우선순위가 자동으로 떠오릅니다. 첫 버전에서 가장 중요한 것은 "12가지 내보내기 형식 지원"이 아니라 다음일 수 있습니다.
+
+- 회의록 구조가 충분히 명확해야 한다.
+- 할 일 추출이 안정적이어야 한다.
+- 공유 링크가 편리해야 한다.
+- 출력 결과를 팀에 바로 전달할 수 있을 만큼 믿을 수 있어야 한다.
+
+이것이 JTBD의 가치입니다. **"어떤 능력을 쌓을까"에서 "사용자가 어떤 진전을 이루도록 도울까"로 되돌려 줍니다.**
+
+## 4. 쓰기 좋은 JTBD 템플릿
+
+제로 베이스라면 JTBD를 너무 학술적으로 생각하지 않아도 됩니다. 가장 실용적인 5개 요소만 잡으면 충분합니다.
+
+### 4.1 장면
+
+사용자는 어떤 순간, 어떤 환경에서 이 제품을 떠올리는가?
+
+- 회의가 끝난 뒤인가
+- 상사가 갑자기 자료를 요구할 때인가
+- 밤에 이력서를 제출하려고 준비할 때인가
+- 월말에 돈이 또 부족하다는 것을 발견했을 때인가
+
+**장면이 없는 수요는 보통 아직 충분히 진짜가 아닙니다.**
+
+### 4.2 트리거
+
+무엇이 그를 즉시 해결책을 찾게 만들었는가?
+
+- 긴 문서에 눌려 어디서부터 봐야 할지 모른다.
+- 내일 제출해야 하는 자료가 있는데 오늘서야 형식이 엉망이라는 것을 발견했다.
+- 방금 리더에게 진행 상황을 추궁당했고, 자신이 정리를 제대로 해 두지 않았다는 것을 깨달았다.
+- 기록을 꾸준히 하고 싶지만 손글씨, 복사, 정리가 모두 너무 번거롭다.
+
+트리거에는 보통 감정이 함께 있습니다. 이 감정은 매우 중요합니다. 왜냐하면 사용자가 왜 바로 이 순간 행동하게 되는지를 결정하기 때문입니다.
+
+### 4.3 완료하고 싶은 진전
+
+그는 단지 "동작 하나"를 하고 싶은 것이 아니라, 자신을 어떤 새로운 상태로 밀어 넣고 싶은가?
+
+- 혼란에서 명확함으로
+- 불안에서 안심으로
+- 미룸에서 시작으로
+- 비효율에서 매끄러움으로
+- 설명하지 못함에서 바로 전달 가능함으로
+
+이 단계에서 "진전"이라는 단어가 매우 중요합니다. 많은 사람이 진짜로 사는 것은 도구가 아니라 **상태 변화**이기 때문입니다.
+
+### 4.4 현재 대체 방안
+
+당신의 제품이 없을 때 그는 지금 어떻게 하는가?
+
+- 수동 복사/붙여넣기
+- Excel이나 메모장으로 억지로 버티기
+- 동료에게 부탁하기
+- 미뤄 두기
+- 여러 도구 사이를 왔다 갔다 하기
+
+대체 방안이 누구인지가 곧 당신의 실제 경쟁 환경입니다.
+
+### 4.5 성공 기준
+
+어떤 상태가 되어야 일이 진짜 해결되었다고 볼 수 있는가?
+
+- 10분 안에 공유 가능한 결과를 얻는다.
+- 크게 다시 고치지 않아도 다른 사람에게 보낼 수 있다.
+- 누락, 오류, 잊어버림이 쉽게 생기지 않는다.
+- 처음 써도 다음에 무엇을 해야 하는지 안다.
+
+"사용자가 어떻게 가치 있다고 판단하는지"조차 말하지 못한다면, 이 방향은 아직 충분히 수렴되지 않았을 가능성이 큽니다.
+
+
+## [5. 바로 적용할 수 있는 한 문장 공식](#top-jtbd)
+
+제품 방향을 정리하고 싶을 때는 먼저 이 매우 실용적인 문장 형식을 사용할 수 있습니다.
+
+> __________ 할 때, 나는 __________ 하고 싶다. 그래야 __________ 할 수 있다.
+> 지금은 __________ 방식으로 겨우 이 일을 해내고 있다.
+
+예를 들면:
+
+> 정보량이 많은 프로젝트 회의가 끝났을 때, 나는 할 일, 담당자, 마감일이 포함된 회의록을 빠르게 얻고 싶다. 그래야 팀에 바로 동기화하고 실행을 추진할 수 있다.
+> 지금은 기억을 더듬고, 채팅 기록을 뒤지고, 손으로 정리하는 방식으로 겨우 이 일을 해내고 있다.
+
+또 다른 예:
+
+> 새로운 직무에 지원하려고 할 때, 나는 기존 경험을 해당 직무에 더 맞는 표현으로 빠르게 고치고 싶다. 그래야 더 확신 있게 그럴듯한 이력서를 제출할 수 있다.
+> 지금은 예전 이력서를 반복해서 복사하고, 문구를 손으로 고치고, 마지막에는 점점 더 확신이 없어지는 방식으로 버티고 있다.
+
+이 한 문장을 이 정도로 명확하게 쓸 수 있다면, 뒤의 페이지 설계, 프롬프트 설계, 기능 우선순위 판단이 훨씬 쉬워집니다.
+
+## 6. AI 제품을 만들 때 특히 봐야 할 job의 세 층
+
+많은 AI 제품은 기능 시연 때는 강력해 보이지만 실제 출시 후 사용자를 붙잡지 못합니다. 흔한 이유는 표면 동작만 해결하고 더 깊은 job을 해결하지 못했기 때문입니다.
+
+하나의 job을 대략 세 층으로 나누어 볼 수 있습니다.
+
+### 6.1 기능 층
+
+가장 표면적인 과제는 무엇인가?
+
+- 문서 요약
+- 문구 재작성
+- 할 일 추출
+- 이미지 생성
+
+사용자가 말로 가장 쉽게 말하는 층입니다.
+
+### 6.2 감정 층
+
+사용자는 어떤 불편한 감정을 줄이거나 어떤 느낌을 얻고 싶은가?
+
+- 덜 당황하고 싶다.
+- 덜 비전문적으로 보이고 싶다.
+- 매번 처음부터 시작하고 싶지 않다.
+- 더 통제감을 갖고 싶다.
+
+많은 지불 의향은 실제로 감정 층과 큰 관련이 있습니다.
+
+### 6.3 사회적 층
+
+사용자는 다른 사람 눈에 어떤 사람으로 보이고 싶은가?
+
+- 더 믿음직해 보이고 싶다.
+- 팀에서 더 조직적인 사람으로 보이고 싶다.
+- 고객 앞에서 더 전문적으로 보이고 싶다.
+- 소셜 플랫폼에서 더 잘 표현하는 사람으로 보이고 싶다.
+
+기능 층만 만들면 제품은 쉽게 대체됩니다. 감정 층과 사회적 층까지 이해하면 진짜 끈적한 가치를 찾기 쉬워집니다.
+
+## 7. JTBD로 제품 방향을 거꾸로 걸러내기
+
+이미 제품이 있는 것이 아니라 손에 3~5개의 아이디어가 있고 무엇을 해야 할지 모르겠다면, JTBD는 선별에 매우 적합합니다.
+
+각 아이디어를 두고 다음 5가지 질문을 해 보세요.
+
+1. 이 아이디어가 대응하는 장면이 충분히 구체적인가?
+2. 사용자는 지금 이미 어떤 서툰 방식으로 해결하고 있는가?
+3. 이 job의 고통감이 충분히 강하거나 충분히 자주 발생하는가?
+4. 내가 잘 만들면 사용자가 "상태가 좋아졌다"고 분명히 느낄까?
+5. 첫 버전은 이 job의 핵심 한 단계만 중심으로 작지만 유용하게 만들 수 있을까?
+
+어떤 방향을 끝까지 말해도 "느낌상 재미있다" 정도밖에 말하지 못하고 트리거, 대체 방안, 성공 기준을 말하지 못한다면, 그것은 아직 성숙한 방향이 아니라 흐릿한 영감일 가능성이 큽니다.
+
+## 8. 사용자 인터뷰에 바로 가져갈 수 있는 질문
+
+많은 사람이 조사를 시작하면 "어떤 기능을 원하세요?"라고 묻습니다. 이런 질문은 표면적인 답을 얻기 쉽습니다.
+
+JTBD에는 아래 질문들이 더 적합합니다.
+
+- 최근에 이 문제를 만난 것은 언제인가요?
+- 그때 무엇을 하고 있었고, 왜 막혔나요?
+- 결국 어떻게 해결했나요?
+- 이 과정에서 가장 짜증 나고, 느리고, 불안한 지점은 무엇이었나요?
+- 도구가 도와준다면 어떤 결과가 정말 유용하다고 느껴질까요?
+- 어떤 대체 방법을 써 봤나요? 왜 충분하지 않았나요?
+
+이런 질문 방식의 장점은 대화를 상상 속 취향이 아니라 실제 경험으로 되돌린다는 점입니다.
+
+## 9. AI로 JTBD 분해하기
+
+JTBD 자체는 AI가 발명한 것이 아니지만, AI는 JTBD를 정리하고 추출하는 데 매우 적합합니다.
+
+예를 들어 사용자 피드백 5~10개를 이미 모았다면, 그것을 모델에게 던져 아래 구조로 요약하게 할 수 있습니다.
```text
-[상황]에서 나는 [동기] 때문에 [원하는 진전]을 이루고 싶다.
+제품 리서치 조수 역할을 해 줘.
+사용자 원문을 줄 테니 먼저 기능 제안을 하지 말고,
+Jobs to Be Done 프레임워크에 따라 정리해 줘.
+
+1. 사용자는 어떤 장면에 있는가
+2. 사용자가 행동하게 된 트리거는 무엇인가
+3. 사용자가 진짜 완료하고 싶은 진전은 무엇인가
+4. 현재 대체 방안은 무엇인가
+5. 사용자가 가장 중요하게 보는 성공 기준은 무엇인가
+6. 이 피드백들에서 반복해서 등장하는 감정 단어는 무엇인가
+
+마지막으로 이 내용을 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.
```
-예시:
+이미 아이디어가 있다면 AI에게 1차 수렴을 도와달라고 할 수도 있습니다.
```text
-새 상품을 온라인몰에 올려야 할 때,
-나는 마케팅 문구 작성에 시간을 많이 쓰지 않고,
-상품의 장점을 잘 보여 주는 설명을 빠르게 만들고 싶다.
+[제품 아이디어]를 만들고 싶어.
+기능 목록을 바로 주지 말고, Jobs to Be Done 방법으로 분석해 줘.
+
+1. 이 제품이 섬길 수 있는 구체적인 장면은 무엇인가
+2. 각 장면에서 사용자가 완료하고 싶은 핵심 job은 무엇인가
+3. 기존 대체 방안은 무엇인가
+4. 어떤 job이 MVP 출발점으로 가장 적합한가, 왜 그런가
+5. 마지막으로 추천하는 job을 명확한 JTBD 문장 한 개로 작성해 줘
```
-## 2. 페르소나와의 차이
+이렇게 하면 처음부터 AI가 "기능 50개 브레인스토밍"으로 끌고 가지 않고, 먼저 방향을 명확하게 말하게 할 수 있습니다.
-페르소나는 "누구인가"에 집중합니다.
+## 10. 초보자가 가장 흔히 하는 4가지 오해
-JTBD는 "무엇을 해내려 하는가"에 집중합니다.
+### 10.1 job을 기능명으로 쓰기
-| 관점 | 질문 |
-| --- | --- |
-| 페르소나 | 이 사람은 누구인가? |
-| JTBD | 이 사람은 어떤 상황에서 어떤 진전을 원하나? |
+"AI 요약", "지능형 분류", "자동 생성"은 모두 job이 아닙니다. 그것들은 가능한 구현 방식일 뿐입니다.
-제품 아이디어를 만들 때는 둘 다 유용하지만, 초보자에게는 JTBD가 첫 기능을 좁히는 데 더 직접적입니다.
+### 10.2 사람군을 너무 넓게 쓰기
-## 3. 기능, 감정, 사회적 층위
+"모든 직장인", "모든 학생", "모든 창업자"는 보통 너무 넓습니다. 넓을수록 실제 장면을 보기 어려워집니다.
-하나의 Job에는 보통 세 층이 있습니다.
+### 10.3 사용자가 말하는 것만 듣고, 실제 행동은 보지 않기
-- 기능적 Job: 실제로 해내야 하는 일
-- 감정적 Job: 느끼고 싶은 감정
-- 사회적 Job: 다른 사람에게 보이고 싶은 모습
+사용자는 자신이 원하는 것을 설명할 수 있지만, 진짜 우선순위는 지금 어떻게 문제를 임시로 해결하고 있는지에 숨어 있는 경우가 많습니다.
-예시:
+### 10.4 처음부터 완전한 플랫폼을 만들려고 하기
-| 층위 | 내용 |
-| --- | --- |
-| 기능 | 상품 설명을 빨리 작성한다 |
-| 감정 | 막막함을 줄이고 자신감을 얻는다 |
-| 사회 | 전문적으로 운영하는 쇼핑몰처럼 보이고 싶다 |
+JTBD를 올바르게 여는 방식은 보통 "모든 것을 해결하는 큰 플랫폼을 만들겠다"가 아닙니다. 먼저 한 장면에서 가장 중요한 한 단계를 겨냥하고, 그것을 매우 매끄럽게 만드는 것입니다.
-## 4. 인터뷰 질문
+## 11. 정리
-JTBD를 찾을 때는 다음 질문이 좋습니다.
+Jobs to Be Done의 가장 가치 있는 점은 새로운 용어를 하나 주는 것이 아니라, 관찰 관점을 바꿔 준다는 것입니다. **제품 기능만 바라보지 말고, 사용자가 어떤 일을 다음 단계로 밀고 싶어 하는지 바라보세요.**
-- 마지막으로 이 문제를 겪은 때가 언제인가요?
-- 그때 무엇을 하려고 했나요?
-- 어떤 방법을 써 봤나요?
-- 가장 귀찮았던 단계는 무엇인가요?
-- 결과가 좋았다고 느끼는 기준은 무엇인가요?
-- 돈이나 시간을 써서 해결한 적이 있나요?
+다음 질문을 반복해 묻기 시작하면:
-## 5. AI와 함께 JTBD 정리하기
+- 사용자는 어떤 장면에서 이 제품을 고용하는가
+- 정확히 어디에서 막혔는가
+- 지금은 어떤 방식으로 버티고 있는가
+- 일이 해결되면 상태가 어떻게 변하는가
+
+원래 흐릿했던 많은 아이디어가 갑자기 선명해지고, 원래 화려해 보였던 많은 기능이 갑자기 그다지 중요하지 않게 됩니다.
+
+제품을 만들 때, 특히 AI 제품을 만들 때 가장 위험한 것은 처음부터 능력 시연에 빠지는 것입니다. JTBD는 당신의 주의를 진짜 중요한 곳으로 되돌립니다. **사용자가 왜 당신을 필요로 하는가, 그리고 당신은 정확히 어떤 진전을 완성하도록 돕는가.**
+
+
+## [12. AI로 JTBD를 실천하는 방법](#top-jtbd)
+
+JTBD는 AI가 발명한 것이 아니지만, AI는 이 방법 안에서 리서치 조수, 정리 조수, 대조 조수 역할을 하기에 매우 적합합니다. 핵심은 **AI가 사용자를 상상해 대신 결론 내리게 하지 말고, 정리와 확장을 돕게 하는 것**입니다.
+
+다음처럼 사용할 수 있습니다.
+
+### 12.1 AI에게 흐릿한 아이디어를 JTBD 가설로 바꾸게 하기
+
+머릿속에 "대학생이 인턴십을 찾도록 돕는 도구를 만들고 싶다"처럼 흐릿한 설명만 있다면, 먼저 AI에게 여러 가능한 job으로 나눠 보게 할 수 있습니다.
```text
-아래 사용자 메모를 JTBD 관점으로 정리해 줘.
-
-메모:
-[인터뷰나 관찰 내용]
-
-다음 형식으로 답해 줘.
-1. 상황
-2. 사용자가 원하는 진전
-3. 현재 대안
-4. 기능적 Job
-5. 감정적 Job
-6. 사회적 Job
-7. 첫 프로토타입 아이디어
+지금 흐릿한 제품 아이디어가 있어: [아이디어]
+기능 목록을 바로 주지 말고, Jobs to Be Done 방식으로 분석해 줘.
+1. 어떤 구체적인 장면에 대응할 수 있는가
+2. 각 장면에서 사용자가 진짜 완료하고 싶은 진전은 무엇인가
+3. 현재 대체 방안은 무엇일 수 있는가
+4. 어떤 job이 MVP로 먼저 만들기 가장 적합한가
+마지막에는 각 job을 명확한 JTBD 문장으로 써 줘.
```
-## 과제
-
-내 프로젝트 사용자를 한 명 정하고 다음을 채우세요.
+아주 초보적인 입력도 괜찮습니다.
```text
-상황:
-원하는 진전:
-현재 대안:
-성공 기준:
-첫 기능:
+대학생이 인턴십을 찾는 것을 돕는 무언가를 만들고 싶어.
+나도 아직 구체적으로 뭘 만들지 잘 모르겠어. 사용자가 정확히 어떤 일을 완료하고 싶은지 같이 생각해 줘.
```
+AI가 주는 유용한 출력은 이렇게 생겼을 수 있습니다.
+
+```text
+가능한 JTBD 방향:
+
+1. 처음 인턴십 지원을 준비할 때, 먼저 무엇을 준비해야 하는지 빠르게 알고 싶다.
+그래야 정보가 혼란스러워 계속 지원을 미루지 않을 수 있다.
+
+2. 어떤 인턴십 공고를 봤을 때, 내가 지원할 가치가 있는지 빠르게 판단하고 싶다.
+그래야 맞지 않는 공고에 너무 많은 시간을 낭비하지 않을 수 있다.
+
+3. 지원을 시작할 때, 기존 이력서를 직무에 더 맞는 버전으로 바꾸고 싶다.
+그래야 더 빨리 지원을 완료하고 통과율을 높일 수 있다.
+```
+
+이 출력의 가치는 매우 넓었던 생각 하나를 실제 장면에 가까운 여러 방향으로 나눈다는 데 있습니다.
+
+### 12.2 AI에게 인터뷰 원문을 정리하게 하기
+
+사용자 인터뷰를 몇 번 했다면, 인터뷰 기록을 AI에게 주고 반복해서 등장하는 장면, 트리거, 대체 방안, 성공 기준을 추출하게 할 수 있습니다.
+
+```text
+아래는 사용자 5명의 인터뷰 원문이야.
+먼저 해결책을 주지 말고, JTBD 프레임워크에 따라 정리해 줘.
+1. 사용자는 어떤 장면에 있는가
+2. 사용자가 행동하게 된 트리거는 무엇인가
+3. 사용자가 진짜 완료하고 싶은 진전은 무엇인가
+4. 현재 대체 방안은 무엇인가
+5. 사용자가 가장 중요하게 여기는 성공 기준은 무엇인가
+6. 여러 사용자에게 반복해서 나타난 정보는 무엇인가
+마지막에는 검증 우선순위가 높은 JTBD 가설 3개로 정리해 줘.
+```
+
+아주 간단한 초보자 입력도 이렇게 쓸 수 있습니다.
+
+```text
+3명에게 물어봤는데, 대략 이렇게 말했어.
+
+1. 인턴십에 지원할 때마다 이력서를 다시 고쳐야 해서 너무 귀찮다.
+2. 사실 가장 두려운 건 내가 잘 썼는지 모르겠다는 것이다.
+3. 지금은 선배에게 먼저 봐 달라고 하는데, 매번 부탁하기가 미안하다.
+
+그들이 진짜 완료하고 싶은 일이 무엇인지 정리해 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+정리 결과:
+
+- 공통 장면: 인턴십 지원 준비 전, 이력서를 처리해야 함
+- 공통 어려움: "충분히 좋은" 상태까지 수정했는지 판단하지 못함
+- 현재 대체 방안: 선배에게 봐 달라고 부탁하거나 직접 반복 수정
+- 가능한 JTBD:
+ 인턴십 지원을 준비할 때, 이력서가 이미 지원 가능한 수준인지 더 빨리 판단하고 싶다.
+ 그래야 "조금만 더 고쳐 보자"에 계속 막혀 지원을 미루지 않을 수 있다.
+```
+
+이 출력은 유용합니다. 흩어진 원문 속에서 더 "수요"에 가까운 것을 뽑아 주기 때문입니다.
+
+### 12.3 AI에게 가벼운 웹 조사를 한 번 맡기기
+
+대규모 인터뷰를 시작하기 전, AI에게 아주 가벼운 외부 정보 스캔을 맡길 수 있습니다. 예를 들면 다음입니다.
+
+- 공개 포럼이나 커뮤니티에서 사람들이 이 문제를 어떻게 불평하는가
+- 시장에 이미 있는 제품들은 주로 어느 층의 문제를 해결하는가
+- 사용자가 가장 흔히 쓰는 대체 방안은 무엇인가
+- 흔한 평가에서 사람들이 가장 만족하고 불만족하는 지점은 무엇인가
+
+이 조사는 실제 사용자 인터뷰를 대체할 수 없지만, Discover 단계의 워밍업으로 매우 적합하며 먼저 문제 지도를 만드는 데 도움을 줍니다.
+
+간단한 입력 예시는 다음입니다.
+
+```text
+조사해 줘.
+"대학생이 이력서를 고치고 인턴십에 지원할 때 가장 흔히 겪는 고통은 무엇인가?"
+공개 포럼, 경험 글, 취업 커뮤니티에서 사람들이 직접 말한 내용을 우선 봐 줘.
+가장 흔한 문제 5개로 정리해 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+흔한 고통 정리:
+
+1. 이력서에 무엇을 써야 할지 모르고 경험이 너무 적다.
+2. 직무마다 어떻게 다르게 수정해야 할지 모른다.
+3. 여러 번 고쳤지만 충분히 좋은지 계속 확신하지 못한다.
+4. 믿을 만한 사람에게 봐 달라고 하기 어렵다.
+5. 지원 절차가 복잡해 쉽게 미룬다.
+```
+
+이런 출력은 최종 결론으로 삼을 수는 없지만, 어떤 문제를 먼저 인터뷰할지 결정하는 데 적합합니다.
+
+### 12.4 AI에게 "반대편" 역할을 맡기기
+
+많은 경우 우리는 자기 아이디어에 감정적으로 너무 붙어 있습니다. AI에게 일부러 비판하는 사람 역할을 맡겨 문제를 더 명확하게 말하도록 압박할 수 있습니다.
+
+```text
+매우 엄격한 제품 리서치 컨설턴트 역할을 해 줘.
+아래는 내 JTBD 가설이야: [가설]
+다음 관점에서 비판해 줘.
+1. 이 장면이 너무 넓은가
+2. 이 job이 진짜 진전이 아니라 기능으로 쓰였는가
+3. 대체 방안이 너무 약한가
+4. 성공 기준이 충분히 명확하지 않은가
+5. 이 가설에서 가장 먼저 검증해야 할 위험은 무엇인가
+```
+
+이렇게 하면 당신이 수요를 보고 있는지, 아니면 좋아하는 솔루션만 보고 있는지 더 빨리 발견할 수 있습니다.
+
+## 📚 Assignments
+
+위 내용을 바탕으로 다음 과제를 완료하세요.
+
+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)
+
diff --git a/docs/ko-kr/stage-1/appendix-mom-test/index.md b/docs/ko-kr/stage-1/appendix-mom-test/index.md
index 77004e2..ec748dd 100644
--- a/docs/ko-kr/stage-1/appendix-mom-test/index.md
+++ b/docs/ko-kr/stage-1/appendix-mom-test/index.md
@@ -1,86 +1,590 @@
---
-title: 'The Mom Test: 수요를 검증하는 사용자 인터뷰'
-description: '칭찬이 아니라 실제 행동을 끌어내는 사용자 인터뷰 방법을 설명합니다.'
+title: 'The Mom Test: 사용자 인터뷰로 수요를 검증하는 방법'
+description: '제로 베이스 독자를 위한 The Mom Test 입문 글입니다. 예의상 긍정 피드백을 피하고, 실제 행동, 구체적 사실, 이미 존재하는 문제를 중심으로 사용자 인터뷰를 진행해 "듣기에는 좋다"를 더 신뢰할 수 있는 수요 판단으로 바꾸는 법을 배웁니다.'
---
-# The Mom Test: 수요를 검증하는 사용자 인터뷰
+
-The Mom Test는 사용자가 예의상 해 주는 칭찬에 속지 않기 위한 인터뷰 방법입니다. 이름의 뜻은 "엄마에게 물어봐도 거짓 칭찬이 나오지 않게 질문하라"는 의미에 가깝습니다.
+# The Mom Test: 사용자 인터뷰로 수요를 검증하는 방법
-## 1. 나쁜 질문
+
-다음 질문은 대답이 좋게 나와도 별 도움이 되지 않습니다.
+## 본 장 안내
-- 이 앱 있으면 쓸 것 같아요?
-- 제 아이디어 괜찮죠?
-- 얼마면 살 것 같아요?
-- 이런 기능 필요하죠?
+
-사람들은 상대를 실망시키지 않으려고 좋게 말할 수 있습니다.
+많은 사람이 처음 제품 조사를 할 때 가장 중요한 것이 "사람을 찾아 이야기해 보는 것"이라고 생각합니다. 그래서 친구, 동료, 심지어 가족에게 묻습니다.
-## 2. 좋은 질문
+- 내 아이디어 어때?
+- 이런 제품이 있으면 쓸 것 같아?
+- 이 기능 괜찮아 보이지 않아?
-좋은 질문은 과거의 실제 행동을 묻습니다.
+상대도 보통 매우 힘이 되는 피드백을 줍니다.
-- 마지막으로 이 문제를 겪은 때가 언제인가요?
-- 그때 어떻게 해결했나요?
-- 해결하는 데 얼마나 걸렸나요?
-- 돈을 내거나 다른 사람에게 부탁한 적이 있나요?
-- 지금 쓰는 방식에서 가장 불편한 점은 무엇인가요?
+- 괜찮은데?
+- 유용해 보인다
+- 한번 해 봐도 좋을 것 같아
-## 3. 아이디어를 먼저 설명하지 않기
+문제는 이런 답변이 대개 판단에 도움이 되지 않는다는 점입니다. 그것들은 예의, 응원, 또는 그 자리에서 당신의 흥을 깨고 싶지 않은 자연스러운 반응에 더 가깝습니다. 당신은 "시장 검증"을 얻었다고 생각하지만, 사실은 의사결정에 쓰기 어려운 위로만 잔뜩 모은 것일 수 있습니다.
-처음부터 내 솔루션을 보여 주면 사용자는 그 솔루션에 맞춰 대답합니다. 먼저 문제와 현재 행동을 들어야 합니다.
+The Mom Test 방법은 바로 이 문제를 해결하기 위해 만들어졌습니다. 이 방법은 우리에게 이렇게 상기시킵니다. **사용자가 일부러 당신을 속이는 것이 아니라, 당신의 질문 방식이 상대를 듣기 좋지만 쓸모없는 답으로 자연스럽게 이끈다**는 것입니다.
-추천 순서:
+
-1. 사용자의 최근 경험을 묻는다.
-2. 현재 해결 방식을 묻는다.
-3. 비용, 시간, 빈도를 묻는다.
-4. 불편한 단계를 묻는다.
-5. 마지막에 프로토타입을 보여 준다.
+::: info 최소 SOP
+**목적**: 읽고 나면 사용자와 어떻게 이야기해야 "듣기 좋다"만 듣지 않고, 방향 판단에 도움이 되는 정보를 실제로 물어낼 수 있는지 더 명확해집니다.
-## 4. 인터뷰 기록 템플릿
+**행동 항목**: 원래 물어보려던 질문 5개를 바꾸고, 우선 "최근 한 번은 언제였나요", "그때 어떻게 처리했나요"를 묻습니다.
+
+**결과**: 무엇이 의견이고, 무엇이 판단을 뒷받침하는 증거인지 더 쉽게 구분할 수 있습니다.
+
+**키워드 이동**: [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란 정확히 무엇인가](#top-mom)
+
+The Mom Test는 Rob Fitzpatrick의 동명 책에서 나온 방법입니다. 이름은 농담처럼 들리지만 핵심을 아주 정확히 찌릅니다.
+
+**당신의 엄마조차도 "이건 별로인 아이디어야"라고 직접 말하기는 어렵습니다.**
+
+그 이유는 엄마가 정직하지 않아서가 아닙니다.
+
+- 당신을 상처 입히고 싶지 않습니다.
+- 무의식적으로 당신을 격려합니다.
+- 당신의 표현 방식에 맞춰 쉽게 대답합니다.
+
+사실 엄마뿐 아니라 친구, 동료, 예전 동창, 심지어 많은 낯선 사람도 당신의 제품 아이디어를 마주하면 비슷한 "긍정 피드백"을 주는 경우가 많습니다. 이것은 수요가 진짜 있다는 뜻이 아니라, 질문을 듣기 좋은 답이 나오기 쉬운 형태로 했다는 뜻입니다.
+
+그래서 The Mom Test의 핵심은 "엄마에게 묻지 마라"가 아닙니다.
+
+**누구라도 당신에게 맞장구치게 만드는 형태로 질문하지 말라는 것입니다.**
+
+이 방법이 진짜로 가르치려는 것은 대화를 통해 실제 수요에 더 가까운 정보를 얻는 법이지, 스스로 기분 좋아지는 댓글을 잔뜩 모으는 법이 아닙니다.
+
+## 2. 해결하는 핵심 문제는 무엇인가
+
+The Mom Test가 주로 해결하는 것은 매우 흔한 인지 착각입니다.
+
+**예의상 긍정 피드백을 실제 수요로 착각하는 것**입니다.
+
+예를 들어 이렇게 묻는다고 해 봅시다.
+
+- 이 App 아이디어 어때요?
+- AI가 이력서를 써 주는 도구를 만들면 쓸 것 같아요?
+- 이 기능은 가치 있어 보이나요?
+
+이 질문들의 공통점은 다음입니다.
+
+- 모두 "의견"을 묻는다.
+- 모두 약간의 암시를 담고 있다.
+- 모두 아직 일어나지 않은 미래를 이야기한다.
+
+사람이 "의견"과 "미래 가정"에 답할 때는 보통 안정적이지 않습니다. 많은 사람은 자신의 흥미, 실행력, 미래 구매 의사를 과대평가합니다.
+
+그래서 The Mom Test는 이렇게 알려 줍니다.
+
+- 다른 사람이 내 아이디어를 어떻게 평가하는지 너무 믿지 마세요.
+- 다른 사람이 미래 행동을 어떻게 예측하는지 너무 믿지 마세요.
+- 가능한 한 이미 일어난 사용자의 실제 행동으로 돌아가세요.
+
+"쓸 것 같나요?"보다 "지난번에 이 일을 어떻게 처리했나요?"가 대개 진실에 더 가깝기 때문입니다.
+
+
+## [3. 세 가지 핵심 원칙](#top-mom)
+
+가장 중요한 부분만 먼저 기억하고 싶다면 아래 세 가지 원칙을 기억하세요.
+
+### 3.1 내 아이디어는 적게 말하고, 사용자의 과거 실제 경험을 더 이야기하게 하기
+
+많은 무효 인터뷰는 시작하자마자 자기 솔루션을 설명하고, 자신이 얼마나 신났는지 말하고, 어떤 제품을 만들 준비인지 이야기합니다. 문제는 당신이 너무 많이 말하는 순간, 상대가 "맞춰 주기", "격려하기" 모드로 바뀌기 쉽다는 점입니다.
+
+반대로 더 좋은 방식은 상대의 경험에 초점을 두는 것입니다.
+
+- 최근에 이 문제를 만난 것은 언제였나요?
+- 그때 무엇을 하고 있었나요?
+- 결국 어떻게 처리했나요?
+- 어느 단계가 가장 번거로웠나요?
+
+이런 질문은 대화를 상상 속 선호가 아니라 현실로 더 자연스럽게 되돌립니다.
+
+### 3.2 추상적 의견은 적게 묻고, 구체적 사실을 더 묻기
+
+"이 기능 괜찮은 것 같아요", "듣기에는 좋아요", "조금 쓸모 있어 보이네요" 같은 표현은 너무 추상적이라 제품 의사결정에 쓰기 어렵습니다.
+
+더 가치 있는 정보는 보통 이런 모습입니다.
+
+- 지난주에 이 일 때문에 2시간을 썼어요.
+- 지금은 Excel과 WeChat으로 버티고 있어요.
+- 지난달 이미 비슷한 도구에 돈을 낸 적이 있어요.
+- 제가 가장 두려운 건 느린 것이 아니라 잘못하는 거예요.
+
+이런 정보가 문제 강도, 빈도, 지불 가능성을 판단하는 데 진짜 도움이 됩니다.
+
+### 3.3 사용자가 원하는 솔루션을 적게 묻고, 지금 어떻게 해결하는지 더 보기
+
+사용자는 자신의 어려움을 설명하는 데는 능숙하지만, 해결책을 설계하는 데 항상 능숙하지는 않습니다.
+
+이렇게 묻는다면:
+
+- AI가 자동으로 이걸 해 주면 좋겠어요?
+- 지능형 기능을 넣으면 도움이 될까요?
+
+대개 얻는 것은 어떤 솔루션에 대한 흐릿한 태도일 뿐, 수요 자체가 아닙니다.
+
+더 좋은 질문은 다음입니다.
+
+- 지금 이 문제를 어떤 방법으로 처리하나요?
+- 왜 그 방법을 선택했나요?
+- 그 방법은 어디가 충분하지 않나요?
+
+기존 대체 방안을 명확히 보는 것은 "무엇을 원하세요?"라고 직접 묻는 것보다 훨씬 중요합니다.
+
+## 4. 왜 사람들은 늘 듣기 좋지만 쓸모없는 답을 줄까
+
+이 점을 이해하면 인터뷰에서 오판이 훨씬 줄어듭니다.
+
+### 4.1 사람은 무의식적으로 예의를 지킨다
+
+특히 대화 상대와 관계가 있을 때, 상대는 직접 이렇게 말하기 어렵습니다.
+
+- 이 방향은 별로인 것 같아요.
+- 저는 절대 안 쓸 것 같아요.
+- 이 문제는 제게 그렇게 중요하지 않아요.
+
+대신 "괜찮은데", "기회가 있으면 해 봐도 좋겠다"라고 말할 가능성이 큽니다.
+
+### 4.2 사람은 미래의 자신을 과대평가한다
+
+많은 사람은 자신이 미래에 진심으로 이렇게 될 것이라 믿습니다.
+
+- 더 자율적일 것이다.
+- 더 열심히 배울 것이다.
+- 더 기꺼이 돈을 낼 것이다.
+- 새 도구를 더 기꺼이 시도할 것이다.
+
+그래서 "있으면 아마 쓸 것 같아요"는 종종 미래에 정말 쓴다는 뜻이 아닙니다.
+
+### 4.3 질문 방식 자체가 답을 유도한다
+
+이렇게 물을 때:
+
+- 내 아이디어 괜찮지 않아?
+- 이 기능이 당신에게 도움이 되지 않을까?
+
+사실 질문 안에 이미 "정답"을 몰래 넣은 것입니다.
+
+그래서 The Mom Test는 특히 강조합니다. **인터뷰를 인정을 구하는 자리로 만들지 마세요.**
+
+## 5. 직접 비교: 어떤 질문은 망하기 쉽고, 어떤 질문은 더 가치 있는가
+
+아래 비교는 거의 모든 초보자가 바로 써먹을 수 있습니다.
+
+| 망하기 쉬운 질문 | 더 가치 있는 질문 |
+| --- | --- |
+| 내 아이디어 어때요? | 최근에 이 문제를 만난 것은 언제였나요? |
+| 이런 제품이 있으면 쓸 건가요? | 지금은 이 일을 어떻게 처리하고 있나요? |
+| 이 기능에 돈을 낼 의향이 있나요? | 지난번 이 문제 때문에 돈을 쓴 적이 있나요? 무엇에 썼나요? |
+| 이 기능이 중요하다고 생각하나요? | 이 흐름에서 가장 짜증 나고, 느리고, 불안한 단계는 무엇인가요? |
+| AI가 자동으로 도와주면 좋겠나요? | 지금 더 편한 해결책을 아직 찾지 못한 이유는 무엇인가요? |
+
+이 표에서 가장 중요한 것은 구체적인 문장이 아니라 그 뒤의 방향입니다.
+
+- 의견에서 사실로
+- 미래에서 과거로
+- 당신의 솔루션에서 사용자의 문제로
+
+## 6. 제로 베이스도 바로 사용할 수 있는 인터뷰 리듬
+
+지금 바로 사람을 찾아 이야기하고 싶다면 아래 순서를 그대로 따라도 됩니다.
+
+### 6.1 시작: 내가 배우는 중이지 팔려고 온 것이 아니라고 설명하기
+
+예를 들면:
+
+> 요즘 사람들이 이 문제를 어떻게 처리하는지 조사하고 있어요. 먼저 실제 상황을 이해하려는 것이지, 뭔가를 팔러 온 것은 아닙니다.
+
+이 표현은 상대가 "긍정 피드백을 줘야 한다"는 심리적 부담을 내려놓기 쉽게 합니다.
+
+### 6.2 최근의 실제 경험부터 묻기
+
+아래 질문으로 시작할 수 있습니다.
+
+- 최근에 이 문제를 만난 것은 언제였나요?
+- 그때 정확히 무슨 일이 있었나요?
+- 처음에는 어떻게 처리하려 했나요?
+
+대화가 구체적인 사건으로 들어가면 정보 품질은 보통 뚜렷하게 올라갑니다.
+
+### 6.3 행동, 비용, 대체 방안을 계속 캐묻기
+
+이어서 묻습니다.
+
+- 지금은 어떤 방법으로 해결하나요?
+- 그 방법에서 가장 불편한 점은 무엇인가요?
+- 이 일 때문에 시간, 돈, 에너지를 얼마나 썼나요?
+- 다른 방법도 시도해 봤나요? 왜 계속 쓰지 않았나요?
+
+### 6.4 마지막에 고통감과 우선순위 판단하기
+
+"아픈가요?"라고 직접 묻지 않아도 됩니다. 세부 정보에서 판단할 수 있습니다.
+
+- 자주 만나는 문제인가
+- 이미 적극적으로 보완하고 있는가
+- 이미 비용을 지불할 의향을 보였는가
+- 말할 때 뚜렷한 감정이 실려 있는가
+
+이것들이 "이게 당신의 고통점인가요?"라는 한 문장보다 훨씬 유용합니다.
+
+## 7. 더 완전한 예시
+
+"AI가 대학생 이력서 수정을 돕는" 제품을 만들고 싶다고 가정해 봅시다.
+
+### 잘못된 질문 방식
+
+동급생에게 이렇게 묻습니다.
+
+> AI 이력서 최적화 도구를 만들고 싶은데, 어때?
+> 직무에 따라 이력서를 자동으로 고쳐 준다면 쓸 것 같아?
+
+이때 상대는 이렇게 말할 가능성이 큽니다.
+
+- 괜찮아 보여
+- 유용할 것 같아
+- 무료면 한번 써 볼게
+
+이 답변으로는 수요가 얼마나 강한지 거의 판단할 수 없습니다.
+
+### 더 좋은 질문 방식
+
+이렇게 바꿔 물을 수 있습니다.
+
+> 최근에 이력서를 고친 것은 언제였나요?
+> 그때 왜 고쳐야 했나요?
+> 어떻게 고쳤나요?
+> 어느 단계가 가장 막혔나요?
+> 다른 사람에게 봐 달라고 한 적이 있나요?
+> 이력서 때문에 돈을 쓰거나 많은 시간을 쓴 적이 있나요?
+
+이 질문을 통해 다음 정보를 얻을 수 있습니다.
+
+- 많은 사람은 못 쓰는 것이 아니라 직무별로 어떻게 고쳐야 할지 모른다.
+- 가장 아픈 것은 레이아웃이 아니라 "어떤 경험을 써야 할지 모르겠다"이다.
+- 그들이 미루는 것은 게으름 때문이 아니라 매번 이력서 수정이 매우 소모적이기 때문이다.
+- 그들은 이미 선배 조언, 템플릿 사이트, AI 도구, 친구에게 부탁하기로 겨우 해결하고 있다.
+
+이제 실제 문제에 훨씬 가까워졌습니다.
+
+## 8. The Mom Test와 JTBD는 어떻게 함께 쓰는가
+
+JTBD가 "사용자가 어떤 진전을 이루고 싶어 하는지"를 보게 해 준다면, The Mom Test는 이렇게 가르쳐 주는 것에 가깝습니다.
+
+**인터뷰를 통해 이 job이 정말 존재하는지 확인하는 방법**입니다.
+
+둘은 완전히 이어서 쓸 수 있습니다.
+
+1. 먼저 JTBD로 하나의 job을 가정한다.
+2. The Mom Test 방식으로 사용자에게 최근의 실제 경험을 묻는다.
+3. 이 job이 정말 자주 발생하고, 실제이며, 우선 만들 가치가 있는지 본다.
+
+예를 들어 JTBD 가설이 다음과 같다고 합시다.
+
+> 인턴십에 지원하려고 할 때, 나는 예전 이력서를 빠르게 직무에 맞는 버전으로 바꾸고 싶다. 그래야 가능한 한 빨리 지원을 완료할 수 있다.
+
+그러면 The Mom Test 스타일 질문으로 검증할 수 있습니다.
+
+- 최근에 지원한 것은 언제였나요?
+- 그때 이력서는 어떻게 고쳤나요?
+- 어느 문단이 가장 쓰기 어려웠나요?
+- 다 고친 뒤 충분히 좋은지 어떻게 판단했나요?
+
+이렇게 방법이 연결됩니다.
+
+- JTBD는 수요 가설을 정의하게 도와줍니다.
+- The Mom Test는 인터뷰로 가설을 검증하게 도와줍니다.
+
+## 9. 초보자가 사용자 인터뷰에서 가장 흔히 하는 오해
+
+### 9.1 인터뷰를 제품 설명회로 만들기
+
+자신의 생각을 너무 많이 말하면 상대는 진짜 상황을 말하기보다 당신에게 맞춰 주기 쉽습니다.
+
+### 9.2 인터뷰 대상이 전부 지인
+
+지인과 이야기하면 안 되는 것은 아니지만, 지인은 당신을 격려하기 더 쉽습니다. 당신을 지지하는 사람만 찾지 말고, 실제 사용자에 더 가까운 사람을 섞어야 합니다.
+
+### 9.3 너무 일찍 기능을 추궁하기
+
+문제를 아직 명확히 하지 못했는데 버튼, 인터페이스, 기능 세부사항을 묻기 시작하면 보통 너무 일찍 해결책으로 들어가는 것입니다.
+
+### 9.4 "쓸 것 같다" 한마디를 검증 결과로 여기기
+
+인터뷰는 방향 판단을 도울 뿐, 검증이 완료됐다는 뜻은 아닙니다. 진짜 검증은 결국 사용자가 시간, 전환 비용, 시험 사용 행동, 심지어 지불처럼 실제 비용을 낼 의향이 있는지 봐야 합니다.
+
+### 9.5 인터뷰 후 정리하지 않기
+
+이야기하고 그냥 두면 정보는 금방 흐릿한 인상으로 변합니다. 가능한 한 빨리 정리하는 것이 좋습니다.
+
+- 자주 나타나는 문제
+- 사용자 원문 속 감정 단어
+- 현재 대체 방안
+- 이미 지불한 비용
+- 자신의 새로운 판단
+
+## 10. 바로 복사해 쓸 수 있는 질문 목록
+
+빨리 시작하고 싶다면 충분히 범용적인 질문 묶음이 여기 있습니다.
+
+### 시작 질문
+
+- 최근에 이 문제를 만난 것은 언제였나요?
+- 그때 구체적으로 무슨 일이 있었나요?
+
+### 행동 질문
+
+- 그때 어떻게 처리했나요?
+- 왜 그 방법을 선택했나요?
+
+### 비용 질문
+
+- 이 일은 보통 시간이나 에너지를 얼마나 쓰게 하나요?
+- 이 문제를 해결하려고 돈을 쓴 적이 있나요?
+
+### 대체 방안 질문
+
+- 다른 도구나 방법을 시도해 본 적이 있나요?
+- 왜 결국 계속 쓰지 않았나요?
+
+### 마무리 질문
+
+- 앞으로 같은 문제를 다시 만난다면, 가장 이상적인 해결 방식은 어떤 모습이어야 할까요?
+
+주의하세요. 이 마무리 질문은 물어봐도 되지만, 가장 뒤에 두는 것이 좋습니다. 앞에서는 바람이 아니라 사실을 얻는 것이 더 중요하기 때문입니다.
+
+## 11. 정리
+
+The Mom Test의 가장 중요한 기여는 "대화를 더 잘하는" 기술을 주는 것이 아니라, 더 맑은 판단 방식을 세워 주는 것입니다.
+
+- 다른 사람이 내 아이디어를 칭찬하는 말을 너무 빨리 믿지 마세요.
+- "있으면 쓸 것 같아요"를 실제 수요로 여기지 마세요.
+- 인터뷰가 인정을 구하는 자리가 되게 하지 마세요.
+
+진짜 가치 있는 인터뷰는 가능한 한 다음으로 돌아가야 합니다.
+
+- 사용자의 최근 실제 경험
+- 지금은 어떻게 처리하고 있는가
+- 이미 어떤 비용을 치렀는가
+- 어디에서 분명히 불편함을 느끼는가
+
+이렇게 묻기 시작하면 얻는 정보가 때로는 그렇게 듣기 좋지 않을 수 있지만, 보통 훨씬 더 유용합니다.
+제품을 만들 때는 **쓸모 있는 진실이 듣기 좋은 격려보다 언제나 더 중요합니다.**
+
+
+## [12. AI로 사용자 인터뷰를 돕는 방법](#top-mom)
+
+The Mom Test는 본질적으로 "진짜 사람과 이야기하는" 방법이므로 AI가 실제 인터뷰를 대체할 수는 없습니다. 하지만 AI는 인터뷰 전, 중, 후에 보조 역할을 하기에 매우 적합하며, 특히 초보자의 진입 장벽을 낮추는 데 좋습니다.
+
+### 12.1 AI에게 "망하기 쉬운 질문"을 고쳐 쓰게 하기
+
+많은 사람이 "내 아이디어 어때요"라고 물어보면 안 된다는 것을 알지만, 막상 입을 열면 다시 그런 문장으로 돌아갑니다. 준비한 질문을 AI에게 주고 고쳐 쓰게 할 수 있습니다.
```text
-인터뷰 대상:
-날짜:
-문제가 발생한 최근 상황:
-현재 해결 방식:
-사용한 도구:
-걸린 시간:
-가장 불편한 점:
-돈/시간을 쓴 증거:
-반복 빈도:
-인상 깊은 원문:
-프로토타입 반응:
-다음 개선점:
+아래는 사용자 인터뷰에서 묻고 싶은 질문들이야.
+[질문 붙여넣기]
+
+The Mom Test 원칙으로 고쳐 써 줘.
+1. 의견형 질문 삭제
+2. 미래 가정 질문 삭제
+3. 가능한 한 과거 실제 행동, 기존 대체 방안, 이미 지불한 비용을 중심으로 바꾸기
+4. 마지막에 바로 인터뷰할 수 있는 질문 8~10개 목록으로 정리
```
-## 5. AI에게 인터뷰 분석 맡기기
+아주 초보적인 입력도 괜찮습니다.
```text
-아래 인터뷰 메모를 분석해 줘.
-칭찬이나 의견보다 실제 행동 증거를 중심으로 정리해 줘.
+사용자에게 이렇게 묻고 싶어.
+1. AI 이력서 수정 도구를 만들면 어때요?
+2. 쓸 것 같나요?
+3. 돈을 낼 의향이 있나요?
-출력:
-1. 강한 수요 증거
-2. 약한 수요 또는 불확실한 부분
-3. 사용자가 실제로 겪는 문제
-4. 첫 프로토타입에서 검증해야 할 가설
-5. 다음 인터뷰 질문 5개
-
-메모:
-[인터뷰 메모]
+더 좋은 질문으로 바꿔 줘.
```
-## 과제
+AI가 주는 유용한 출력은 이런 모습일 수 있습니다.
-주변 사람 3명에게 내 아이디어를 설명하기 전에 다음 질문을 해 보세요.
+```text
+고친 질문:
-1. 마지막으로 이 문제를 겪은 때가 언제인가요?
-2. 그때 어떻게 해결했나요?
-3. 얼마나 자주 발생하나요?
-4. 가장 귀찮은 단계는 무엇인가요?
-5. 해결을 위해 돈이나 시간을 쓴 적이 있나요?
+1. 최근에 이력서를 고친 것은 언제였나요?
+2. 그때 왜 고쳐야 했나요?
+3. 어떻게 고쳤나요?
+4. 어느 단계가 가장 시간이 많이 걸렸나요?
+5. 다른 사람에게 봐 달라고 한 적이 있나요?
+6. 이전에 이력서 수정에 돈을 쓰거나 많은 시간을 쓴 적이 있나요?
+```
+
+이 출력은 매우 도움이 됩니다. 원래 "의견을 묻는" 질문을 바로 "실제 행동을 묻는" 질문으로 바꿔 주기 때문입니다.
+
+### 12.2 AI에게 대상별 인터뷰 개요를 만들게 하기
+
+같은 방향이라도 사람군이 다르면 인터뷰의 중점은 달라집니다. 예를 들어 학생, HR, 프리랜서는 관심사가 완전히 다릅니다. AI에게 서로 다른 대상별로 개요를 만들게 할 수 있습니다.
+
+- 초보 사용자 대상: 최근 한 번의 실제 경험을 중점적으로 이해
+- 헤비 사용자 대상: 대체 방안과 고통감을 중점적으로 이해
+- 유료 사용자 대상: 이미 비용을 지불했는지 중점적으로 이해
+
+이렇게 하면 실제 대화할 때 리듬이 생기고, 모든 사람에게 똑같은 질문만 던지지 않게 됩니다.
+
+예를 들어 이렇게 바로 입력할 수 있습니다.
+
+```text
+두 유형의 사람과 이야기하려고 해.
+1. 처음 인턴십을 찾는 대학생
+2. 이미 다른 사람의 이력서를 많이 봐 준 선배
+
+각각 인터뷰 개요를 만들어 줘. 각 개요는 질문 6개로 해 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+대학생 대상:
+1. 최근에 인턴십에 지원한 것은 언제였나요?
+2. 그때 가장 막힌 단계는 무엇이었나요?
+3. 본인의 이력서가 지원 가능한지 어떻게 판단했나요?
+...
+
+선배 대상:
+1. 최근에 다른 사람의 이력서를 봐 준 것은 언제였나요?
+2. 가장 자주 보이는 명확한 문제는 무엇인가요?
+3. 후배들이 가장 쉽게 막히는 단계는 무엇인가요?
+...
+```
+
+이렇게 하면 스스로 처음부터 질문을 만들 필요가 없어 인터뷰 준비가 훨씬 쉬워집니다.
+
+### 12.3 AI에게 인터뷰 기록을 정리하게 하기
+
+인터뷰를 마친 뒤 가장 흔한 문제는 "정보가 없다"가 아니라 "정보가 너무 흩어져 있다"입니다. AI는 조각난 대화를 구조화된 메모로 정리하는 데 매우 적합합니다.
+
+```text
+아래는 사용자 3명과의 인터뷰 기록이야.
+The Mom Test 관점으로 정리해 줘.
+1. 어떤 내용이 사실이고, 어떤 내용이 의견인가
+2. 사용자의 최근 실제 행동은 무엇인가
+3. 현재 대체 방안은 무엇인가
+4. 사용자가 이미 지불한 시간, 돈, 에너지 비용은 무엇인가
+5. 반복해서 언급된 문제는 무엇인가
+6. 듣기에는 긍정적이지만 증거가 부족한 말은 무엇인가
+```
+
+이 단계는 특히 가치가 있습니다. "듣기에는 좋다"와 "판단을 뒷받침할 수 있다"를 분리해 주기 때문입니다.
+
+간단한 입력은 이렇게 쓸 수 있습니다.
+
+```text
+한 사용자와 이야기한 기록이야.
+
+- 도구가 있으면 한번 써 볼 것 같다고 했다.
+- 지난주 이력서를 고치느라 저녁 시간을 전부 썼다.
+- 지금은 주로 친구에게 봐 달라고 한다.
+- 가장 어려운 것은 어느 정도까지 고치면 지원해도 되는지 모른다는 점이라고 했다.
+
+어떤 것이 의견이고 어떤 것이 사실인지 나눠 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+의견:
+- 도구가 있으면 한번 써 볼 것 같다고 했다.
+
+사실:
+- 지난주 이력서를 고치느라 저녁 시간을 전부 썼다.
+- 현재 대체 방안은 친구에게 봐 달라고 하는 것이다.
+- 가장 어려운 점은 언제 "지원 가능"한 상태인지 모른다는 것이다.
+
+수요 판단에 쓸 수 있는 핵심:
+- 이 문제는 최근에 실제로 발생했다.
+- 사용자는 명확한 시간 비용을 이미 투입했다.
+- 현재 방안은 다른 사람에게 의존하며 안정적이지 않다.
+```
+
+이 출력은 초보자에게 어떤 말이 판단에 쓸 수 있고, 어떤 말은 그냥 들어 두는 정도인지 매우 직관적으로 알려 줍니다.
+
+### 12.4 AI에게 먼저 가벼운 웹 검색을 시키기
+
+아직 인터뷰를 시작하지 않았다면, AI에게 아주 가벼운 외부 조사를 맡길 수 있습니다.
+
+- 공개 커뮤니티에서 사람들이 최근 이 문제를 어떻게 불평하는지
+- 기존 도구에서 가장 많이 불평받는 부분은 무엇인지
+- 사용자가 유사한 문제에 이미 돈을 쓴 적이 있는지
+- 시장에 어떤 대체 방안이 이미 존재하는지
+
+이 정보는 실제 사람 인터뷰를 대체할 수 없지만, 더 빨리 상태에 들어가고 문제를 어디서부터 파고들지 알게 해 줍니다.
+
+간단한 입력 예시는 다음입니다.
+
+```text
+조사해 줘.
+"대학생이 이력서를 고칠 때 가장 자주 불평하는 것은 무엇인가"
+가장 흔한 불평 5개를 쉬운 말로 정리해 줘.
+```
+
+AI는 이렇게 출력할 수 있습니다.
+
+```text
+흔한 불평:
+
+1. 이력서에 정확히 무엇을 써야 할지 모른다.
+2. 직무 하나에 지원할 때마다 바꿔야 해서 너무 힘들다.
+3. 여러 번 고쳤지만 좋은지 계속 확신이 없다.
+4. 믿을 만한 피드백을 줄 사람이 없다.
+5. 아직 준비가 안 된 것 같아 계속 미루게 된다.
+```
+
+이 결과의 가치는 인터뷰 진입점을 더 쉽게 찾게 해 준다는 데 있습니다.
+
+### 12.5 AI에게 "인터뷰 회고 코치" 역할을 맡기기
+
+방금 끝낸 인터뷰 기록을 AI에게 던져 비판하게 할 수도 있습니다.
+
+```text
+아래는 내 사용자 인터뷰 기록이야.
+The Mom Test 관점으로 회고해 줘.
+1. 내 질문 중 어떤 것이 인정을 구하는 것처럼 들렸나
+2. 어떤 질문이 명확하게 유도적이었나
+3. 원래 사실을 더 캐물어야 했던 부분은 어디인가
+4. 다시 한다면 이 대화를 어떻게 더 좋게 물어볼 수 있는가
+```
+
+초보자에게 특히 도움이 됩니다. "내가 증거를 모으고 있는지, 격려를 모으고 있는지"에 대한 감각을 더 빨리 만들 수 있기 때문입니다.
+
+## 📚 Assignments
+
+위 내용을 바탕으로 다음 과제를 완료하세요.
+
+1. 최근 만들고 싶은 제품 방향 하나를 고르고, 원래 물어봤을 "망하기 쉬운" 질문 5개를 먼저 쓰세요.
+2. 이 5개 질문을 The Mom Test 스타일에 더 맞는 질문으로 고쳐 쓰세요.
+3. 잠재 사용자 3명을 찾아 최소 한 번은 "최근에 이 문제를 만난 것은 언제였나요?"라고 물어보세요.
+4. 인터뷰 후 네 가지 정보를 정리하세요: 실제 행동, 대체 방안, 이미 지불한 비용, 반복해서 나타나는 어려움.
+
+## 더 읽어 보기
+
+- [The Mom Test 공식 웹사이트](https://momtestbook.com/)
+- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
diff --git a/docs/ko-kr/stage-1/building-prototype/index.md b/docs/ko-kr/stage-1/building-prototype/index.md
index eba99da..c16b5ef 100644
--- a/docs/ko-kr/stage-1/building-prototype/index.md
+++ b/docs/ko-kr/stage-1/building-prototype/index.md
@@ -1,154 +1,607 @@
---
-title: '프로토타입 만들기'
-description: '아이디어를 요구사항으로 정리하고 AI IDE로 단일 페이지 및 다중 페이지 프로토타입을 만드는 방법을 설명합니다.'
+title: '직접 프로토타입 만들기 - 비즈니스 분석부터 다중 페이지 제품 프로토타입 구현까지'
+description: '비즈니스 분석부터 다중 페이지 제품 프로토타입 구현까지의 전체 폐쇄 루프를 경험합니다. 비즈니스에 질문하고, 요구사항을 분해하고, AI IDE로 단일 페이지 및 다중 페이지 애플리케이션을 생성하며, 프로토타입을 개선하고 테스트하는 방법을 배웁니다.'
---
-# 프로토타입 만들기
+
-Stage 1에서는 백엔드나 복잡한 데이터베이스보다 먼저 **화면, 흐름, 핵심 가치**를 구현합니다.
+# 초급 3: 직접 프로토타입 만들기
-## 1. 코드를 쓰기 전에 요구사항 정리하기
+## 이 장의 가이드
-AI에게 바로 "앱 만들어 줘"라고 하면 결과가 흔들립니다. 먼저 다음을 정리합니다.
+
-| 항목 | 질문 |
-| --- | --- |
-| 사용자 | 누가 쓰는가? |
-| 상황 | 언제, 왜 쓰는가? |
-| 입력 | 사용자가 무엇을 넣는가? |
-| 처리 | 앱이 무엇을 계산/생성/정리하는가? |
-| 출력 | 사용자는 어떤 결과를 얻는가? |
-| 성공 기준 | 결과가 좋다고 판단하는 기준은 무엇인가? |
+지난 장에서는 좋은 아이디어를 찾는 법을 배웠습니다. 사용자 요구에서 출발해 누군가 기꺼이 비용을 지불할 방향을 찾는 법이었습니다. 하지만 방향을 찾는 것은 첫걸음일 뿐입니다. 제품 관리자를 진짜로 시험하는 것은 모호한 요구를 어떻게 사용할 수 있는 제품으로 바꾸느냐입니다.
-예시:
+이번 장에서 우리는 하나의 현실 문제를 해결합니다. 사장이 “AI로 상품을 이커머스 플랫폼에 게시하는 효율을 높여 봐”라는 한마디를 던졌을 때, 이것을 어떻게 사용 가능한 제품 프로토타입으로 바꿀 수 있을까요?
-```text
-사용자: 작은 쇼핑몰을 운영하는 사장
-상황: 새 상품을 올릴 때 상세페이지 문구가 필요함
-입력: 상품명, 특징, 가격대, 타깃 고객
-처리: 여러 톤의 상품 문구 생성
-출력: 제목, 핵심 문구, 상세 설명, SNS 홍보 문구
-성공 기준: 바로 수정해서 쓸 수 있는 문구가 나온다
+앞에서 만든 스네이크나 계산기와 달리, 실제 비즈니스에서는 기능을 허공에서 상상하면 안 됩니다.
+
+1. 문제점 명확히 하기: 운영 담당자와 이야기하며, 모호한 “효율 향상” 속에서 진짜 문제점을 파냅니다.
+2. 중요한 것부터 만들기: 많은 문제 중에서 먼저 가장 아픈 문제를 해결합니다. 한 번에 전부 만들려고 하지 않습니다.
+3. 빠르게 검증하기: AI IDE로 먼저 단일 페이지 프로토타입을 만들고, 잘 통하면 다중 페이지로 확장합니다.
+4. 쓸 수 있는 것을 만들기: 마지막에는 시연할 수 있고 조작할 수 있는 이커머스 소재 워크벤치를 전달합니다.
+
+우리는 장난감 만들기에서 애플리케이션 만들기로 전환하는 법을 배우고, 고객의 실제 요구에 공감하고 사고하는 법을 배우게 됩니다.
+
+
+
+::: info ℹ️ 설명
+이 글에는 일부 비즈니스 용어가 나올 수 있습니다. 이해가 되지 않는다면 AI에게 설명을 요청해도 됩니다.
+:::
+
+
+
+
+
+
+
+## 1. 코드를 쓰기 전에 요구사항 확정하기
+
+앞선 튜토리얼에서는 AI IDE를 사용해 스네이크와 여러 미니게임을 쉽게 생성했습니다. 하지만 이런 것들은 장난감 프로젝트라고 할 수 있을 뿐, 실제 업무와 생활에 적용되기는 어렵습니다. AI 능력이 진짜로 사람들에게 쓰이게 하려면 생활과 업무 장면을 결합해 vibe coding을 해야 합니다.
+
+지난 장에서는 누군가 기꺼이 비용을 지불할 좋은 아이디어를 찾는 법을 배웠습니다. 하지만 방향을 찾는 것은 시작일 뿐입니다. 실제로 제품을 만들다 보면 알게 됩니다. “무엇을 만들지” 아는 것과 “어떻게 만들지” 아는 것 사이에는 거대한 간극이 있습니다.
+
+이 간극이 바로 요구사항의 구체화입니다.
+
+예를 들어 수업이나 개인 프로젝트에서는 보통 가장 단순하게 실행 가능한 기능에서 출발해 제품과 애플리케이션을 만듭니다.
+
+- “칸반을 만들어서 작업을 나열해줘.”
+- “그림 그리는 도구를 만들어줘.”
+- “설문을 수집할 수 있는 소프트웨어를 만들어줘.”
+
+이것들은 대개 하나의 도구, 하나의 기능 모듈일 뿐이며, 명확한 비즈니스 문제라고 부르기도 어렵습니다. 더 중요한 것은 이런 생각들이 대부분 “내가 유용하다고 느끼는 것”이지, “사용자가 정말 필요로 하는 것”이 아니라는 점입니다.
+
+기업급 프로젝트나 창업 프로젝트에서 제품 관리자와 엔지니어는 보통 더 큰 비즈니스 명제에서 출발합니다. 예를 들어 다음과 같은 상황을 가정해 볼 수 있습니다.
+
+
+
🛍️ 비즈니스 상황:
+
+
당신은 한 매장의 이커머스 운영 제품 관리자입니다. 사장이 모호하지만 압박이 큰 과제를 줬습니다.
+
“요즘 공식 계정들에서 AI로 이미지도 만들고 문구도 만들던데, 보기엔 꽤 쉬워 보이더라. 네가 한번 해 봐. 우리가 Douyin 이커머스에 새 상품을 올릴 때 효율이 좀 높아지게 해줘.”
+
+
+
+이때 당신은 “사장님 또 꿈꾸시네!”라고 생각할 수 있습니다. 하지만 실제 업무에서는 이렇게 모호한 한마디로 의사결정이 내려지는 일이 매우 흔합니다. 심지어 일주일에 밀크티를 주문하는 횟수보다 많을 수도 있습니다. 따라서 괜찮은 직장인이 되기 위해서는, 더 나아가 새롭게 떠오르는 스타트업 CEO가 되기 위해서는, 자기만 쓰는 도구 만들기에서 진짜 제품 프로토타입 만들기로 전환하는 법을 반드시 배워야 합니다.
+
+AI IDE를 배웠으니, 곰곰이 생각하면 이 요구사항은 사실 아주 간단해 보입니다. AI에게 이 내용을 바탕으로 프롬프트를 하나 만들어 달라고 하고, Agent에게 던지면 끝나는 것 아닐까요?
+
+```
+제 요구사항 xxxx를 참고해서,
+이커머스 소재 워크벤치를 설계해 주세요.
+상품 설명, 이미지, 동영상 등 소재의 생성과 관리 기능을 포함해 주세요.
```
-## 2. 첫 버전 범위 정하기
+만약 신나서 이 요구사항을 바로 프로토타입으로 바꾼 다음 사장에게 보낸다면, 축하합니다. 이번 분기 보너스는 취소될 겁니다!
-첫 버전은 작아야 합니다.
+**왜 그럴까요? 이것이 우리가 해결해야 할 핵심 문제입니다.**
-좋은 첫 범위:
+이전에 AI IDE를 배울 때 만들었던 것은 스네이크나 계산기처럼 **자기가 쓰는 장난감 프로젝트**였습니다. 기능은 단순하고, 자신이 무엇을 원하는지 잘 알고 있으며, 만들어서 스스로 쓰면 됩니다. 하지만 **실제 비즈니스 장면은 완전히 다릅니다**.
-- 입력 폼 1개
-- 결과 카드 1개
-- 샘플 데이터 몇 개
-- 로딩/오류 상태
-- 다시 생성 버튼
+- **당신은 사용자가 아닙니다**: 사장이 원하는 것은 “효율 향상”이지만, 운영 담당자가 매일 구체적으로 어떻게 일하고 어디에서 막히는지 당신은 모릅니다.
+- **AI도 비즈니스를 모릅니다**: 모호한 요구를 AI에게 던지면 AI는 일반 지식에 기반해 추측할 뿐입니다. 결과물은 그럴듯해 보이지만 실제로는 전혀 쓸 수 없을 수 있습니다.
+- **좋은 아이디어가 좋은 제품은 아닙니다**: 당신은 “AI 생성 기능을 하나 넣으면 멋지다”고 생각할 수 있지만, 사용자는 전혀 필요로 하지 않거나 오히려 기존보다 더 번거롭다고 느낄 수 있습니다.
-나쁜 첫 범위:
+**그래서 우리는 “아이디어를 떠올리는 것에서 사용자를 이해하는 것”으로 나아가는 법을 반드시 배워야 합니다.** 당신의 창의성이 진짜로 다른 사람의 문제를 해결할 때, 질문하고 비즈니스를 깊이 이해할 때, 비로소 진정한 의미에서 가치 있는 일을 만들 수 있습니다. 좋은 아이디어는 때로 좋은 기술보다 더 중요합니다.
-- 로그인
-- 결제
-- 관리자
-- 팀 협업
-- 실시간 알림
-- 모바일 앱과 웹 동시 개발
+### 1.1 상상에서 현실로: 비즈니스에 질문하는 법 배우기
-처음에는 "보여 줄 수 있는 핵심 장면"만 만듭니다.
+::: info 💡 먼저 분명히 하기: 요구사항이란 무엇인가? 비즈니스란 무엇인가?
-## 3. AI IDE에 줄 첫 요청
+**요구사항**은 사용자가 진짜로 원하는 것입니다. 그들이 겪는 불편, 해결하고 싶은 문제입니다. 예를 들어 “사장이 상품 등록을 더 빠르게 하라고 한다”는 하나의 요구사항입니다.
-```text
-AI 문구 생성기 프로토타입을 만들고 싶어.
-아직 실제 API는 연결하지 말고, 프론트엔드 화면과 가짜 응답만 만들어 줘.
+**비즈니스**는 사용자가 매일 실제로 하는 일과 일하는 방식입니다. 예를 들어 이커머스 운영 담당자가 매일 하는 일은 상품 등록, 가격 수정, 이미지 제작, 데이터 확인 등입니다. 이것들이 모두 비즈니스입니다.
+
+**왜 비즈니스에 주목해야 할까요?**
+비즈니스를 이해하지 못하면 만든 도구가 “보기에는 좋지만 아무도 쓰지 않는” 것이 될 수 있기 때문입니다. 사용자가 매일 어떻게 일하고 어디에서 막히는지 진짜로 이해해야, 실제로 도움 되는 것을 만들 수 있습니다.
+
+:::
+
+가장 단순한 관점에서 출발한다면, 먼저 자신에게 몇 가지 질문을 던질 수 있습니다.
+
+- 사장이 말한 “**효율이 좀 높아지게**”는 구체적으로 무슨 뜻일까요? **더 빠르게** 만들고 싶은 걸까요? **비용을 덜 쓰고** 싶은 걸까요? 아니면 **더 많이 팔고** 싶은 걸까요?
+- 지금은 상품을 어떻게 등록하고 있을까요? **어디가 매끄럽지 않을까요?**
+- 매일 몇 개의 **신상품**을 처리해야 할까요? 상품마다 몇 장의 **이미지**와 몇 줄의 **문구**가 필요할까요?
+- 현재 업무에서 **어떤 일이 가장 번거롭고**, **가장 하기 싫은 일**일까요?
+
+하지만 이것들은 모두 추측에 기반한 질문입니다. 우리는 일선의 Douyin 이커머스 비즈니스 담당자에게 직접 “어떤 어려움이 있고, 무엇에 신경을 쓰고 있나요?”라고 물어야 합니다. 소통을 통해 더 정확한 답을 얻을 수 있습니다.
+
+::: info 📋 실제 비즈니스 인터뷰 결과
+
+이커머스 운영을 하는 사람들에게 물어보니, 다음과 같은 고민을 말했습니다.
+
+**1. 일이 너무 많고 너무 잡다함**
+- 한 사람이 여러 매장을 관리해야 하고, 매장마다 처리해야 할 상품이 많습니다.
+- 매일 바쁘게 돌아갑니다. **새 상품 등록**, **가격 수정**, **이미지 제작**, **데이터 확인**을 하다 보면 한 일이 끝나기도 전에 다른 일을 해야 합니다.
+
+**2. 콘텐츠 제작은 한 번에 끝나는 일이 아니라, 만들면서 테스트하는 일**
+- 먼저 **제조사에서 준 이미지**, **예전에 사용했던 소재**, 또는 **인터넷에서 찾은 참고 이미지**를 사용해 상품을 빠르게 **등록**해 봅니다.
+- 적은 비용으로 광고를 조금 돌려서 **구매가 발생하는지 확인**합니다.
+- **잘 팔리는 상품**에 대해서만 이미지와 상세 설명, 영상을 진지하게 제작합니다.
+
+:::
+
+비즈니스 담당자에게 질문을 끝낸 뒤 우리는 열정에 차오릅니다. 이제야말로 비즈니스에 완벽히 맞는 제품 프로토타입을 만들 수 있을 것 같습니다. 하지만 또 틀렸습니다. 우리가 “모든 요구를 한 번에 만족시키려고” 하면 제품은 매우 거대해지고, 수업 시간 안에 구현하기도 어렵습니다. 따라서 더 정리하고 좁혀서 진짜 핵심 문제점을 찾아야 합니다.
+
+### 1.2 발산에서 수렴으로: 비즈니스의 핵심 문제점과 기능 잠그기
+
+::: info 💡 왜 “수렴”해야 할까요? “문제점”이란 무엇일까요?
+
+**문제는 많은데, 무엇을 먼저 할까요?**
+
+사용자는 A도 번거롭고, B도 번거롭고, C도 번거롭다고 여러 문제를 말할 수 있습니다. 하지만 모든 문제를 한 번에 해결하려고 하면 결국 아무것도 잘 만들지 못할 수 있습니다. 그래서 **수렴**해야 합니다. 많은 문제 중에서 **가장 아프고, 가장 급하고, 가장 해결 가능한** 것을 골라 먼저 시작하는 것입니다.
+
+**문제점이란 무엇일까요?**
+사용자가 **가장 짜증나고, 가장 시간을 많이 쓰고, 가장 해결하고 싶어 하는** 구체적인 문제입니다. “내가 유용하다고 생각하는 것”이 아니라, 사용자가 **매일 불평하고, 할 때마다 고통스러워하는** 일입니다.
+
+:::
+
+위 인터뷰를 통해 운영 담당자가 겪는 문제는 많다는 것을 알게 되었습니다. 행사 때문에 업무 리듬이 끊기고, 여러 매장을 관리해야 하며, 등록 / 가격 수정 / 이미지 제작 / 데이터 확인 사이를 바쁘게 오갑니다.
+
+만약 “이 문제들을 전부 해결하겠다”고 하면, 결국 **크고 다 갖췄지만 쓰기 불편한** 도구를 만들게 됩니다.
+
+이 문제들을 분류해 보겠습니다. AI에게 도와달라고 해도 됩니다. 대략 세 종류가 있습니다.
+
+1. **리듬 문제**: 언제 상품을 올리고 언제 가격을 조정할 것인가.
+2. **효율 문제**: 여러 매장과 여러 상품을 어떻게 동시에 잘 관리할 것인가.
+3. **콘텐츠 문제**: 상품 이미지와 문구를 어떻게 빠르게 만들 것인가.
+
+우리 수업에 가장 적합하게 먼저 해결할 것은 **세 번째: 콘텐츠 제작 문제**입니다. 하지만 “콘텐츠를 빠르게 만들기”는 여전히 조금 추상적입니다. 비즈니스 담당자에게 구체적으로 어디에서 막히는지 다시 물어봅니다.
+
+::: info 📋 비즈니스 담당자가 말한 콘텐츠 제작의 가장 고통스러운 두 지점
+
+**고통 1: 이미지를 대량으로 만들고 문구를 쓰는 일이 너무 힘듦**
+- 소재가 여기저기 흩어져 있습니다. 클라우드 드라이브, WeChat 기록, 플랫폼 백오피스 등이라서 **찾기가 매우 힘듭니다**.
+- 한 번에 많은 상품을 올려야 해서 **하나하나 정성 들여 만들 시간이 없습니다**. 대충 조합할 수밖에 없습니다.
+- 요구 수준은 높지 않습니다. **볼 수 있고, 등록할 수 있으면 됩니다**. 아주 정교할 필요는 없습니다.
+
+**고통 2: 쓸 만한 방안을 저장해 두고 재사용할 수 없음**
+- 전에 잘 만들었던 제목과 레이아웃을 **다음에 쓰고 싶어도 찾을 수 없습니다**.
+- 방안이 채팅 기록이나 예전 상품 링크에 흩어져 있습니다.
+- 쓰고 싶을 때 **한참 뒤지고, 복사해 붙여 넣고, 한참 고쳐야 합니다**.
+- **즐겨찾기, 관리, 바로 적용**을 할 수 있는 도구가 없습니다.
+
+:::
+
+위 두 문제점을 바탕으로 우리는 간단한 작은 도구를 만들 것입니다. **운영 담당자가 이미지와 문구를 대량으로 만들 수 있게 돕고, 쓸 만한 방안을 저장해 다음에 바로 사용할 수 있게 하는 도구**입니다.
+
+이 도구는 두 가지만 합니다. AI에게 세부화를 도와달라고 할 수 있으며, 비즈니스 피드백에 따라 기능을 계속 줄이는 것을 기억하세요.
+
+::: info 기능 1: 이커머스 상품 이미지와 문구 대량 생성
+
+**무엇을 하는 기능인가요?**
+시스템에 상품 정보를 주면, 이커머스 플랫폼(Douyin, Taobao 등)에 등록할 때 사용할 수 있는 상품 이미지와 문구를 자동으로 생성합니다.
+
+**입력**
+| 유형 | 내용 |
+|------|------|
+| 상품 정보 | 이름, 카테고리, 브랜드, 소재, 크기, 색상 등 |
+| 상품 이미지 | 흰 배경 이미지 또는 간단한 장면 이미지 |
+| 참고 이미지 | 예전에 잘 팔렸던 상품 스크린샷 또는 참고 링크 |
+| 가져오기 방식 | Excel 일괄 가져오기 또는 페이지에서 직접 입력 |
+
+**출력(생성된 이커머스 소재)**
+- **상품 대표 이미지**: 문구형 판매 포인트가 들어간 제품 표시 이미지. 사용자가 스크롤하다가 처음 보는 이미지입니다.
+- **상품 제목**: 검색에서 찾힐 수 있는 키워드 조합입니다.
+- **판매 포인트 문구**: 구매자를 끌어들이는 1-2문장입니다.
+- 모두 **조금만 고치면 바로 등록할 수 있는** 완성본입니다.
+
+**효과**
+- 이전: 상품마다 처음부터 이미지를 만들고 문구를 써야 했습니다.
+- 현재: 상품 묶음을 시스템에 넣고, 생성된 초안을 고르고 조금 수정하면 됩니다.
+
+:::
+
+::: info 기능 2: 쓸 만한 방안을 템플릿으로 저장하기
+
+**입력**
+| 유형 | 내용 |
+|------|------|
+| 한 세트 전체 | 대표 이미지 + 제목 + 문구 |
+
+**출력**
+| 기능 | 설명 |
+|------|------|
+| 적용 | 다음에 새 상품을 만들 때 템플릿으로 자동 생성 |
+| 수정 | 제목과 문구를 직접 수정 |
+| 관리 | 이름을 붙이고 태그를 달아(예: “남성 가방 템플릿”, “대규모 프로모션 제목”) 찾기 쉽게 함 |
+
+**효과**
+1. 새 상품을 가져옵니다.
+2. 선택합니다. 시스템 기본 생성 또는 **내가 저장한 템플릿 사용**.
+3. 시스템이 템플릿 스타일을 자동으로 적용해 새로운 이미지와 문구를 출력합니다.
+
+:::
+
+---
+
+**방금 우리가 한 일을 돌아봅시다.**
+
+1. **먼저 질문하기**: 바로 만들기 시작하지 않고, 운영 담당자에게 “무엇이 가장 짜증나는가”를 먼저 물었습니다.
+2. **문제점 찾기**: 가장 고통스러운 점이 “이미지 만들고 문구 쓰기가 너무 힘듦”과 “쓸 만한 방안을 저장할 수 없음”임을 발견했습니다.
+3. **범위 수렴하기**: 크고 모든 것을 다 하는 플랫폼을 만들지 않고, “이미지와 문구 대량 생성 + 템플릿 저장” 두 기능만 만들기로 했습니다.
+
+**왜 이렇게 하는 것이 중요할까요?**
+
+많은 초보자가 제품을 만들 때 저지르는 오해는 기능이 많을수록 좋다고 생각하는 것입니다. 하지만 사용자가 진짜로 필요한 것은 **가장 아픈 문제를 해결하는 것**입니다. 많은 기능을 만들었지만 전부 쓰기 불편한 것보다, 한두 기능이라도 진짜로 도움 되는 것이 낫습니다.
+
+**제품과 비즈니스 사고의 핵심:**
+- “내가 보기에 사용자가 무엇을 필요로 할까”를 혼자 상상하지 않습니다.
+- 사용자에게 “매일 무엇을 하나요? 어디가 가장 고통스럽나요?”라고 묻습니다.
+- 많은 문제 중에서 **가장 아프고, 가장 해결 가능한 문제**로 **수렴**합니다.
+- 먼저 **최소 사용 가능** 버전을 만든 뒤 천천히 반복 개선합니다.
+
+이것이 코드를 쓰기 전에 분명히 생각해야 할 일입니다. 코드는 도구일 뿐이고, **사용자를 이해하고 문제를 정확히 찾는 것**이 첫걸음입니다.
+
+
+
+
+
+
+
+## 2. 10분 안에 프로토타입 만들기: AI IDE로 “핵심 플레이 방식” 구현하기
+
+::: info 💡 프로그래밍 Plan 제안
+현재 IDE가 충분히 똑똑하지 않다고 느끼거나 사용량을 금방 다 쓸 것 같다면 **프로그래밍 Plan**을 구매해도 됩니다. 미리 [이 글](../../stage-2/backend/modern-cli/)을 예습하여 Claude를 사용한 프로그래밍을 참고하세요.
+:::
+
+Thinking은 좋은 일이지만 over thinking은 좋지 않습니다. 과도한 반성을 여기서 멈추고, 단일 페이지부터 프로토타입을 만들어 보겠습니다.
+
+### 2.1 첫 번째 단계: 쉬운 말로 AI에게 원하는 것을 말하기
+
+처음부터 완벽한 프롬프트를 추구할 필요는 없습니다. 가장 자연스러운 표현에서 시작하세요. 동료에게 요구사항을 설명하듯 쉬운 말로 AI에게 무엇을 만들고 싶은지 말한 뒤, AI가 더 전문적인 표현으로 다듬도록 하면 됩니다.
+
+#### 2.1.1 말로 설명하는 것부터 시작하기(초보자에게 추천)
+
+먼저 자기 말로 아이디어를 설명합니다. 거칠어도 괜찮습니다.
+
+```
+이커머스 운영 담당자가 상품 대표 이미지와 문구를 자동으로 생성하도록 돕는 도구를 만들고 싶습니다.
+운영 담당자는 평소 이미지를 하나하나 만들고 문구를 직접 써야 해서 매우 번거롭습니다.
+제 생각은 이렇습니다. 상품 정보를 업로드하면 시스템이 초안을 한 묶음 자동으로 생성하고,
+운영 담당자는 쓸 만한 것을 골라 조금만 수정해서 사용할 수 있습니다.
+
+먼저 가장 단순한 버전부터 만들겠습니다. 한 페이지이고, 왼쪽에는 상품 정보를 입력하며,
+오른쪽에는 생성 결과를 보여 줍니다. 이미지를 업로드할 수 있고, 텍스트를 입력할 수 있으며,
+생성 후에는 대표 이미지 미리보기와 문구를 표시합니다.
+```
+
+다음으로 이 문장을 AI(ChatGPT, Claude 등)에게 보내고 확장해 달라고 합니다. AI는 보통 당신이 고려하지 못한 세부 사항을 보충해 주고, 생각을 더 명확하게 정리한 뒤, AI IDE에 보내기 좋은 프롬프트를 생성해 줍니다.
+
+AI에게 이렇게 말할 수 있습니다.
+
+```
+위 아이디어를 확장해서 명확한 비즈니스 로직 문서로 정리해 주세요.
+그리고 AI IDE(예: Cursor, Trae)에 보내기 좋은 프롬프트를 생성해 주세요.
+단일 페이지 애플리케이션의 프로토타입 코드를 생성하는 데 사용할 것입니다.
+```
+
+AI는 구조화된 요구사항과 대응되는 프롬프트를 반환할 것입니다. 직접 한 번 확인하고, 필요 없는 기능을 줄이고, 문제가 없다고 판단한 뒤 코드 생성에 사용하세요.
+
+이렇게 하는 장점은 말로 설명한 내용이 가장 진짜 생각이라는 점입니다. 다만 중요한 세부 사항이 빠질 수 있습니다. AI가 확장할 때 “일괄 업로드를 지원할까요?”처럼 생각하지 못한 질문을 던지며 더 검증하게 도와줄 수 있습니다. 피드백에 따라 실제적이지 않은 기능을 보존하거나 삭제하고, 반복 수정하면서 AI에게 줄 첫 번째 프롬프트를 확정할 수 있습니다.
+
+#### 2.1.2 확장 단계를 건너뛰기: 정리해 둔 비즈니스 문서를 AI에게 바로 던지기
+
+앞선 장에서 이미 비즈니스 로직 문서(예: 쉬운 말로 쓴 요구사항 설명)를 정리했다면, 아래 형식을 AI IDE에 바로 적용할 수 있습니다. AI에게 확장을 시키는 중간 단계를 생략하는 방식입니다. 요구사항이 이미 명확하고 바로 코드 작성에 들어가고 싶을 때 적합합니다.
+
+```
+아래 비즈니스 로직을 참고해 핵심 플레이 기능을 검증할 단일 페이지 애플리케이션을 구현해 주세요.
+
+비즈니스 로직 참고:
+1. 운영 담당자가 첫 번째 이미지/문구 초안을 대량 생성하도록 돕기:
+- **입력(소재 직접 업로드와 일괄 가져오기 지원):**
+ - 상품 기본 정보: 이름, 카테고리, 브랜드, 소재, 크기, 색상, 대상 사용자 등;
+ - 상품 이미지: 흰 배경 이미지 / 간단한 장면 이미지;
+ - 매번 생성할 때 과거 인기 상품 스크린샷이나 참고 링크를 추가로 업로드할 수 있도록 지원하고, 참고물이 있을 수 있게 함;
+ - Excel 일괄 가져오기 또는 페이지에서 온라인 입력 / 업로드를 지원함.
+ - 페이지에서 상품 소재를 소재 라이브러리에 저장할지 지정할 수 있게 하여 다음 사용을 편하게 함
+- **출력(바로 등록하거나 조금 고치면 등록할 수 있는 내용):**
+ - 각 상품마다 “볼 만하고, 기본 판매 포인트가 들어간” 대표 이미지 초안 한 장;
+ - “구조가 합리적이고, 핵심 키워드가 포함된” 제목 + 1-2문장의 판매 포인트 문구.
+- **기대하는 사용 방식 변화:**
+ 매번 상품 묶음마다 맨땅에서 시작하던 방식에서, 상품 묶음을 시스템에 넣고 시스템이 생성한 초안을 골라 미세 조정하는 방식으로 바뀜.
+
+먼저 첫 번째 기능을 만들고, 두 번째 기능(템플릿 라이브러리)은 나중에 추가합니다.
+```
+
+#### 2.1.3 프로그래머의 방식(심화): AI에게 “프롬프트의 프롬프트”를 작성하게 하기
+
+코드 생성 과정을 더 세밀하게 제어하고 싶다면, 먼저 AI(ChatGPT 등)에게 요구사항을 바탕으로 AI IDE 전용 프롬프트를 생성하게 할 수 있습니다.
+
+```
+아래 아이디어를 바탕으로 coding Agent에게 보낼 코드 작성용 프롬프트를 써 주세요.
+저는 이 프롬프트를 사용해 코드를 생성하려고 합니다.
+
+[여기에 비즈니스 로직 설명을 붙여 넣으세요]
요구사항:
-- 상품명, 특징, 타깃 고객을 입력하는 폼
-- 생성 버튼
-- 생성 결과 카드 3개
-- 로딩 상태
-- 오류 메시지 영역
-- 모바일에서도 보기 좋은 반응형 레이아웃
-
-먼저 어떤 파일을 만들거나 수정할지 계획을 말하고,
-그다음 코드를 작성해 줘.
+1. 프롬프트에 명확한 페이지 레이아웃 설명이 포함되어야 합니다.
+2. 데이터 구조와 상호작용 로직을 명확히 해야 합니다.
+3. 기술 스택(예: React + Tailwind)을 지정해야 합니다.
+4. 구현해야 할 핵심 기능 항목을 나열해야 합니다.
```
-## 4. 단일 페이지 프로토타입 만들기
+보통 AI는 아래와 비슷한 구조화된 프롬프트를 생성합니다.
+
-처음에는 한 화면이면 충분합니다.
+이 프롬프트를 조금 수정한 뒤 AI IDE에 보내 코드를 생성할 수 있습니다.
-화면 구성 예시:
+### 2.2 두 번째 단계: AI IDE가 직접 코드를 생성하게 하기
-1. 상단 제목과 짧은 설명
-2. 입력 폼
-3. 생성 버튼
-4. 결과 영역
-5. 예시 결과 또는 빈 상태
+#### 2.2.1 준비 작업: AI IDE의 기본 조작 이해하기
-단일 페이지를 먼저 만드는 이유는 명확합니다.
+AI IDE(Cursor, Trae, Windsurf 등)의 기본 사용 방식이 아직 익숙하지 않다면, 부록의 [IDE 기초 튜토리얼](/ko-kr/appendix/2-development-tools/ide-basics/)을 먼저 보고 다음을 이해하는 것이 좋습니다.
+- 새 프로젝트 만들기
+- AI Agent와 대화하기
+- AI의 코드 생성 과정 이해하기
-- 요구사항을 빠르게 확인할 수 있다.
-- 사용 흐름이 보인다.
-- 디자인과 문구를 쉽게 바꿀 수 있다.
-- 기능 추가 전 핵심 가치가 맞는지 검증할 수 있다.
+#### 2.2.2 코드 생성 시작하기
-## 5. 여러 화면으로 확장하기
+이제 초기 프롬프트를 얻었습니다. 첫 번째 프롬프트 스타일을 예로 들어 AI가 코드를 생성하도록 해 보겠습니다. 먼저 창과 해당 폴더를 만들고, 폴더를 엽니다. 원하는 폴더 위치에서 새 프로젝트를 초기화하면 됩니다.
+
+
-단일 페이지가 괜찮다면 다음 화면을 추가할 수 있습니다.
+사이드바에서 원하는 모델을 하나 선택합니다. gemini, gpt, glm, kimi, minimax 등을 추천합니다. 그런 다음 첫 번째 단계에서 얻은 프롬프트를 입력합니다.
+
-- 홈 화면: 서비스 소개와 시작 버튼
-- 생성 화면: 실제 입력과 결과
-- 히스토리 화면: 이전 결과 목록
-- 상세 화면: 결과 하나를 크게 보기
-- 설정 화면: 톤, 길이, 언어 같은 옵션
+생성을 클릭하면 익숙한 과정을 보게 됩니다. AI는 프롬프트에 따라 프로젝트의 디렉터리 구조, 필요한 파일, 각 파일의 초기 내용을 계획합니다.
-하지만 화면을 늘릴 때도 기준은 같습니다. 사용자가 실제로 필요한 흐름만 추가합니다.
+::: warning ⚠️ 특별 주의: AI가 멈춰서 확인을 기다릴 수 있습니다
+생성 과정에서 AI Agent는 자주 **멈춰서 당신의 입력이나 확인을 기다립니다**. 예를 들어:
+- 다음 단계로 계속할지 묻습니다.
+- 어떤 작업을 확인하려고 Enter를 누르라고 합니다.
+- 어떤 기술 세부 사항을 선택할지 묻습니다.
-## 6. 프로토타입을 진짜처럼 보이게 하기
+**AI가 움직이지 않는 것처럼 보이면 먼저 대화 화면을 확인해, 답변을 기다리고 있는지 보세요.** 많은 초보자는 AI가 생각 중이라고 착각하지만, 사실 이미 거기서 멈춰 당신을 기다리고 있습니다. 직접 답하거나 Enter를 누르면 AI가 계속 작업합니다.
+:::
-프로토타입 품질은 코드보다 화면의 설득력에서 많이 갈립니다.
+이때도 마찬가지로 Enter를 눌러 정보를 확인하는 것을 잊지 마세요. 그렇지 않으면 대기 상태에 빠질 수 있습니다. 일부 AI IDE는 이 문제에 빠지지 않을 수도 있습니다.
+
-다음 요소를 챙기세요.
+아래와 같은 장면을 만났다면, 이미 로컬에서 서비스가 시작되었다는 뜻입니다. 건너뛰기를 클릭해야 합니다. 그렇지 않으면 이 화면에 머무를 수 있습니다. 코드 생성이 끝났는데 아무것도 나타나지 않으면, 직접 “이 프로젝트를 시작해 줘”라고 말해야 합니다.
+
-- 실제 같은 샘플 데이터
-- 버튼 hover/disabled 상태
-- 로딩 중 문구
-- 빈 상태 안내
-- 오류 문구
-- 결과 복사 버튼
-- 모바일 레이아웃
+::: info 💡 상황 설명
+**상황 설명**: `npm create vite@latest`로 React + TypeScript 프로젝트(easy-vibe-web)를 만들었습니다. 생성이 끝나면 컴퓨터가 이 웹페이지를 자동으로 “실행”하여 즉시 결과를 볼 수 있게 합니다.
-AI에게 이렇게 요청할 수 있습니다.
+**로컬 서비스**: 컴퓨터가 임시로 웹페이지 표시 창을 열어 둔 것으로 이해할 수 있습니다. 자신의 컴퓨터에서만 실행되며 다른 사람은 접근할 수 없습니다.
-```text
-현재 프로토타입이 너무 데모처럼 보여.
-실제 SaaS 도구처럼 보이도록 UI를 다듬어 줘.
-단, 기능 범위는 늘리지 말고 레이아웃, 간격, 상태 표현, 샘플 데이터만 개선해 줘.
+**localhost(로컬 주소)**: `localhost`는 “이 컴퓨터 자신”이라는 뜻입니다. 브라우저에서 여기에 접속하는 것은 사실 내 컴퓨터에서 실행 중인 웹페이지에 접속하는 것입니다.
+
+**포트**: 포트는 번호로 이해할 수 있습니다. 같은 컴퓨터에서 실행 중인 서로 다른 웹페이지 서비스를 구분하는 데 쓰이며, 이 프로젝트에서는 5174를 사용합니다.
+
+**접속 링크 `http://localhost:5174/`**: 이 주소는 “내 컴퓨터에서 번호가 5174인 웹페이지에 접속한다”는 뜻입니다. 브라우저에서 열면 결과를 볼 수 있습니다.
+
+**이번 상황 설명**: 시스템은 원래 5173을 사용하려 했지만 해당 번호가 이미 사용 중이어서 자동으로 5174로 바꿨습니다. 정상적인 상황입니다.
+
+**조작 안내**: 브라우저 주소창에 `http://localhost:5174/`를 입력하고 Enter를 누르면 현재 프로젝트 페이지를 볼 수 있습니다.
+:::
+
+모두 확인한 뒤 Agent가 잠시 실행되기를 기다리면 아래와 같은 결과를 얻을 수 있습니다.
+
+
+초기 기능 화면은 생겼지만 프론트엔드 페이지가 너무 못생겼다는 것을 볼 수 있습니다. 이때 AI와 직접 대화하며 인터페이스 표시를 최적화할 수 있습니다.
+
+
+최적화 후에는 아래와 같은 더 보기 좋은 인터페이스를 얻을 수 있습니다.
+
+
+자신의 필요에 따라 웹페이지 기능을 수정할 수 있습니다. 스크린샷을 첨부하고 자유롭게 질문해도 됩니다. 예를 들어 “지금은 일괄 가져오기 기능이 필요 없으니 제거해 줘”, “왼쪽 입력 항목이 너무 많으니 xxxxx만 남겨 줘”라고 할 수 있습니다. 더 나아가 다른 성숙한 웹사이트를 참고할 수도 있습니다. 예를 들어 여기서는 Google의 어떤 디자인 제품을 직접 참고해 “참고”할 수 있습니다. 마음에 드는 성숙한 웹사이트의 스크린샷을 붙여 넣어도 됩니다.
+
+
+마지막으로 다음과 같은 결과를 얻을 수 있습니다.
+
+
+### 2.3 오류가 나면 어떻게 할까?
+
+실제 조작 과정에서 오류를 만나는 것은 필연적이며 정상적인 현상입니다. 이것이 당신이 뭔가 잘못했다는 뜻은 아닙니다. 오류를 이해할 필요는 없습니다. “보이는 상황”을 빠짐없이 AI에게 전달하면 됩니다.
+
+일반적인 처리 방식은 세 가지뿐입니다.
+
+- **방식 1: 페이지나 터미널에 오류가 표시됨**
+ 페이지가 빨갛게 변하거나, 흰 화면이 뜨거나, 터미널에 빨간 글자가 잔뜩 나타나면, 바로 스크린샷을 찍거나 전체 오류 정보를 복사해 AI에게 보내고 고쳐 달라고 합니다.
+
+- **방식 2: 기능은 틀렸지만 오류는 없음**
+ 예를 들어 버튼이 반응하지 않거나, 데이터가 표시되지 않거나, 스타일이 엉켰다면, 쉬운 말로 “지금 무슨 일이 일어났는지 + 원래 무엇을 원했는지”를 설명하고 필요하면 스크린샷을 추가합니다.
+
+- **방식 3: 문제가 있는지 확실하지 않음**
+ AI에게 바로 물어볼 수 있습니다. “이 기능에 명백한 문제가 있는지, 조정이 필요한지 확인해 줘.”
+
+#### 2.3.1 초보자가 자주 묻는 질문
+
+- **Q: 오류 정보가 어디 있는지 모르겠어요.**
+- A: 일반적으로 모든 “빨간 글자”를 보면 됩니다. 터미널, 콘솔, 페이지에서 빨간 안내 문구를 찾아 전체 선택 후 AI에게 복사해 보내면 됩니다.
+
+- **Q: AI가 고쳤는데도 같은 오류가 계속 나면 어떻게 하나요?**
+- A: 흔한 상황입니다. 최신 오류 정보를 계속 스크린샷으로 찍거나 복사해 보내고, 지난 수정 위에서 더 고치게 하세요.
+
+- **Q: AI의 수정 방안을 완전히 이해해야 하나요?**
+- A: 한 번에 전부 이해할 필요는 없습니다. 매번 한두 가지만 집중하면 됩니다. 시간이 지나면 영어 단어를 쌓듯 점점 더 많은 코드를 이해하게 됩니다.
+
+- **Q: 여러 번 고쳤는데도 문제가 해결되지 않으면 어떻게 하나요?**
+- A: 다음을 시도할 수 있습니다.
+ - IDE의 “버전 되돌리기” 기능을 사용합니다. Agent 대화 위치에서 되돌리기 버튼을 찾아 실행 가능한 버전으로 돌아간 뒤 다시 시작합니다.
+ - 모델을 바꾸거나 프롬프트를 조정하고, 현상과 오류 정보를 더 구체적으로 설명합니다.
+ - “현재 코드 + 오류 로그 + 기대 동작”을 묶어 한 번에 AI에게 보내고, 문제 부분을 전체적으로 재구성하게 합니다.
+
+## 3. 단일 페이지에서 다중 페이지 애플리케이션으로 확장하기
+
+
+
+
+
+
+
+핵심 플레이 방식의 로직이 기본적으로 생성된 뒤에는 나머지 부분의 내용을 생성할 수 있습니다. 예를 들어 지금 설정을 클릭하거나 일부 버튼을 눌러도 전혀 작동하지 않을 수 있습니다.
+
+AI에게 비즈니스 프롬프트 요구사항에 따라 검사하고 아직 생성되지 않은 부분을 만들게 할 수 있습니다. 또는 구현이 끝나지 않은 페이지를 AI에게 바로 보완하게 할 수도 있습니다. 특정 페이지를 지정해 AI에게 구현을 보완하게 해도 됩니다. 페이지가 클릭 가능하고 기능이 정상적으로 상호작용할 때까지 진행합니다.
+
+
+잠시 기다리면 프로그램이 이전 기반 위에 여러 페이지와 상호작용 기능을 보완한 것을 볼 수 있습니다.
+
+
+
+
+이제 관심 있는 각 기능과 버튼을 사람이 직접 클릭해 상호작용이 정상인지 확인하면 됩니다. 상호작용이 되지 않는 기능이 있다면 AI와 소통하여 고치게 합니다.
+
+## 4. 프로토타입을 “그럴듯하게” 만들기
+
+
+
+
+
+
+
+다중 페이지 구조가 생긴 뒤 마지막 단계는 프로토타입을 “실행은 됨”에서 “사용하기 편하고, 보기에도 전문적으로 보임”으로 바꾸는 것입니다. 이를 위해 전체 흐름(사용자 흐름)을 직접 한 번 경험하고, 실행되지 않는 부분은 AI에게 고치게 해야 합니다. 매번 새로고침한 뒤에도 처음부터 새 사용자를 흉내 내며 전체 흐름을 끝까지 진행하고 기대 결과를 얻을 수 있어야 합니다.
+
+처음 요구사항을 다시 봅시다.
+
+```
+1. 운영 담당자가 첫 번째 이미지/문구 초안을 대량 생성하도록 돕기:
+- **입력(소재 직접 업로드와 일괄 가져오기 지원):**
+ - 상품 기본 정보: 이름, 카테고리, 브랜드, 소재, 크기, 색상, 대상 사용자 등;
+ - 상품 이미지: 흰 배경 이미지 / 간단한 장면 이미지;
+ - 매번 생성할 때 과거 인기 상품 스크린샷이나 참고 링크를 추가로 업로드할 수 있도록 지원하고, 참고물이 있을 수 있게 함;
+ - Excel 일괄 가져오기 또는 페이지에서 온라인 입력 / 업로드를 지원함.
+ - 페이지에서 상품 소재를 소재 라이브러리에 저장할지 지정할 수 있게 하여 다음 사용을 편하게 함
+- **출력(바로 등록하거나 조금 고치면 등록할 수 있는 내용):**
+ - 각 상품마다 “볼 만하고, 기본 판매 포인트가 들어간” 대표 이미지 초안 한 장;
+ - “구조가 합리적이고, 핵심 키워드가 포함된” 제목 + 1-2문장의 판매 포인트 문구.
+- **기대하는 사용 방식 변화:**
+ 매번 상품 묶음마다 맨땅에서 시작하던 방식에서, 상품 묶음을 시스템에 넣고 시스템이 생성한 초안을 골라 미세 조정하는 방식으로 바뀜.
+
+2. 쓸 만한 출력을 재사용 가능한 템플릿 라이브러리로 축적하기:
+- **무엇을 즐겨찾기할 수 있나요?**
+ - 운영 담당자가 “쓸 만하다”고 느끼는 어떤 출력도 원클릭으로 저장할 수 있습니다.
+ - “대표 이미지 + 제목 + 판매 포인트”의 완전한 조합일 수 있습니다.
+ - 또는 그중 일부만 저장할 수도 있습니다. 예: 어떤 제목 구조, 어떤 판매 포인트 문구.
+- **저장한 뒤 무엇을 할 수 있나요?**
+ - **재사용:**
+ - 이 저장 항목을 사용해 새 상품 매개변수 묶음에 적용하고, 이미지/문구 초안을 다시 생성합니다.
+ - 또는 같은 상품에서 이 템플릿을 바탕으로 여러 버전을 생성해 A/B 테스트를 합니다.
+ - **편집:**
+ - 제목 문구 / 판매 포인트 문구를 직접 수정합니다.
+ - 이미지 편집을 지원한다면 대표 이미지의 텍스트, 스티커 같은 요소를 미세 조정할 수 있습니다.
+ - **관리:**
+ - 저장 항목에 이름과 태그를 붙입니다. 예: “남성 가방 대표 이미지 템플릿”, “대규모 프로모션 제목 구조”. 매장별 분류를 지원하여 이후 검색이 편하게 합니다.
+- **다음 신상품 등록 때 어떻게 사용하나요?**
+ - 새 상품을 가져온 뒤 운영 담당자는 선택할 수 있습니다.
+ - 시스템 기본 로직으로 생성하거나,
+ - “내가 저장한 특정 템플릿으로 생성”을 지정합니다.
+ - 시스템은 새 상품 데이터를 바탕으로 템플릿의 구조와 스타일을 자동 적용해 새로운 대표 이미지 + 제목 + 판매 포인트 초안을 출력합니다.
```
-## 7. 체크리스트
+테스트할 때마다 직접 새 데이터를 만들어야 한다면 시간이 많이 듭니다. 이때 우리는 보통 “테스트 데이터”라는 방식을 사용합니다. 아래 방식으로 AI와 소통해, 인터페이스에 테스트용 빠른 데이터 진입점을 만들게 할 수 있습니다. 그러면 기능이 정상적으로 끝까지 실행되는지 쉽게 테스트할 수 있습니다.
-프로토타입을 마친 뒤 아래를 확인합니다.
+```
+지금 이 사용자 사용 과정을 테스트해서 완전히 끝까지 진행되는지 확인해야 합니다. 아래 요구사항을 결합해 테스트 데이터 진입점을 만들어 주세요. 제가 클릭하면 전체 흐름이 정상인지 빠르게 테스트할 수 있어야 합니다.
+1. 운영 담당자가 첫 번째 이미지/문구 초안을 대량 생성하도록 돕기:
+- **입력(소재 직접 업로드와 일괄 가져오기 지원):**
+ - 상품 기본 정보: 이름, 카테고리, 브랜드, 소재, 크기, 색상, 대상 사용자 등;
+ - 상품 이미지: 흰 배경 이미지 / 간단한 장면 이미지;
+ - 매번 생성할 때 과거 인기 상품 스크린샷이나 참고 링크를 추가로 업로드할 수 있도록 지원하고, 참고물이 있을 수 있게 함;
+ - Excel 일괄 가져오기 또는 페이지에서 온라인 입력 / 업로드를 지원함.
+ - 페이지에서 상품 소재를 소재 라이브러리에 저장할지 지정할 수 있게 하여 다음 사용을 편하게 함
+- **출력(바로 등록하거나 조금 고치면 등록할 수 있는 내용):**
+ - 각 상품마다 “볼 만하고, 기본 판매 포인트가 들어간” 대표 이미지 초안 한 장;
+ - “구조가 합리적이고, 핵심 키워드가 포함된” 제목 + 1-2문장의 판매 포인트 문구.
+- **기대하는 사용 방식 변화:**
+ 매번 상품 묶음마다 맨땅에서 시작하던 방식에서, 상품 묶음을 시스템에 넣고 시스템이 생성한 초안을 골라 미세 조정하는 방식으로 바뀜.
+```
-- 첫 화면에서 무엇을 하는 도구인지 5초 안에 이해된다.
-- 입력해야 할 내용이 명확하다.
-- 버튼을 누르면 결과가 나온다.
-- 결과가 사용자의 문제와 연결된다.
-- 오류나 빈 상태가 방치되어 있지 않다.
-- 모바일에서도 주요 흐름이 깨지지 않는다.
+결과는 쉽게 얻을 수 있습니다. 데이터 하나가 너무 적다고 느껴지면, AI에게 테스트 케이스를 여러 개 생성하게 할 수 있습니다.
+
-## 과제
+클릭하면 결과를 얻습니다.
+
-자신의 아이디어를 하나 고르고 다음 산출물을 만드세요.
+이때 우리가 바로 얻는 것은 결과이지, “가상의 생성 과정”이 있는 것은 아닙니다. 실제 생성 과정을 모방하고 싶다면 AI와 직접 대화할 수 있습니다. “실제 생성 과정을 시뮬레이션해 주세요. 클릭한 뒤 일정 시간이 지난 후에 결과를 보여 주세요.”
+
-1. 요구사항 1페이지
-2. 단일 페이지 프로토타입
-3. 샘플 데이터 5개
-4. 결과 화면 1개
-5. 개선 요청 프롬프트 3개
+생성 기능을 끝까지 통과한 뒤에는 템플릿 라이브러리 기능이 정상인지 확인해야 합니다. 페이지의 생성 카드에서 알 수 있듯 템플릿 라이브러리 저장 기능은 구현되지 않았습니다. 이때 AI와 더 깊게 대화해야 합니다. “요구사항 [여기에 위 2번 내용을 붙여 넣기] 이 정상 동작하도록 확인해 주세요. 결과 하나를 클릭해 해당 템플릿을 저장할 수 있고, 열어 보면 생성 매개변수를 볼 수 있어야 합니다.”
-## 다음으로
+생성은 보통 한 번에 끝나지 않으며, 자주 스크린샷으로 수정해야 합니다.
+
-[AI 기능 통합하기](/ko-kr/stage-1/integrating-ai-capabilities/)에서 가짜 응답 대신 실제 AI API를 붙이는 방법을 배웁니다.
+마지막으로 기대한 결과를 얻습니다.
+
+요구 흐름을 직접 경험하는 것 외에도, AI에게 바로 요구사항 검사를 시킬 수 있습니다. 예를 들면 다음과 같습니다.
+
+- “처음 요구사항과 대조해 현재 애플리케이션이 모든 핵심 기능을 이미 포함했는지 확인해 주세요.”
+- “기능 목록을 만들어 어떤 것은 완료되었고, 어떤 것은 아직 구현되지 않았거나 경험이 부족한지 표시해 주세요.”
+
+AI는 보통 checklist를 출력합니다. 그 결과를 바탕으로 계속 개선할지 생각할 수 있습니다. 반복 수정 후에는 비교적 완성도 높은 프로토타입 결과를 얻을 수 있습니다.
+
+## 5. 📚 과제: 나만의 Douyin 이커머스 워크벤치 복제하기
+
+
+
+
🚀 도전 과제: 이커머스 소재 워크벤치 복제하기
+
+
+
+ 이번 수업의 프롬프트와 내용을 참고해 한 번의 완전한 폐쇄 루프를 완성하세요.
+
+
+
+
+ 완전한 폐쇄 루프 실습
+
+
비즈니스 정리 프롬프트 생성 → 단일 페이지 프로토타입 생성 → 다중 페이지 프로토타입 생성
+
+
+
+ 결과 공유
+
+
프로그램을 스크린샷으로 찍어 모두에게 공유하세요.
+
+
+
+ 생각해 볼 질문
+
+
다음 절 “대형 언어 모델(LLM)과 텍스트-이미지 생성 능력 연결”을 위한 공간을 남겨 두고 미리 생각해 보세요. 당신의 워크벤치 안에 “AI 문구 작성 / 이미지 생성 / 스크립트 생성” 같은 능력을 어떻게 넣을 수 있을까요?
+
+
+
+
+
+## 다음 단계
+
+다음 절에서는 이 콘텐츠 생산 워크벤치를 바탕으로 구체적인 AI 능력(텍스트-텍스트, 이미지-텍스트, 텍스트-이미지)을 연결합니다. 예를 들면 다음과 같습니다.
+
+- 특정 콘텐츠 작업에 대해 문구 초안과 여러 제목 후보를 자동 생성하기
+- 작업 설명에 따라 이미지 초안 자동 생성하기(텍스트-이미지)
+- 과거 콘텐츠 작업을 자동 분류하고 요약하여 다음 이벤트의 주제 계획을 돕기
+
+
diff --git a/docs/ko-kr/stage-1/complete-project-practice/index.md b/docs/ko-kr/stage-1/complete-project-practice/index.md
index 03a1d7b..d2c3b90 100644
--- a/docs/ko-kr/stage-1/complete-project-practice/index.md
+++ b/docs/ko-kr/stage-1/complete-project-practice/index.md
@@ -1,105 +1,302 @@
---
-title: '완성 프로젝트 실습'
-description: 'AI로 만든 프로토타입을 사용자에게 보여 줄 수 있는 데모 수준으로 다듬는 방법을 설명합니다.'
+title: '완성 프로젝트 실전 - Demo에서 제품급 프로토타입까지'
+description: 'Demo 단계를 벗어나 제품 흐름을 완성하고, 실감 나는 Mock Data를 구성하며, 피드백을 통해 빠르게 반복 개선해 최종적으로 보여 줄 수 있고 상호작용 가능한 완성형 AI 제품 프로토타입을 만드는 법을 배웁니다.'
---
-# 완성 프로젝트 실습
+
-## 1. 행복 경로만 만들지 않기
+# 초급 5: 완성 프로젝트 실전
-초보자 프로토타입은 보통 성공 흐름만 있습니다.
+## 본 장 안내
-```text
-입력 → 버튼 클릭 → 결과 표시
+
+
+지난 장에서는 AI 기능을 연결했고, Demo가 실행되기 시작했습니다. 하지만 진짜 "제품"과는 아직 거리가 멉니다. 페이지를 새로고침하면 데이터가 사라지고, 오류가 나면 흰 화면이 되며, 목록에는 "테스트 데이터 1, 테스트 데이터 2"만 있고, 사용자가 잘못 클릭해도 되돌릴 방법이 없습니다...
+
+이번 장에서는 이런 구멍을 모두 메웁니다. 우리는 제품의 완전한 흐름을 보완하고, AI로 실감 나는 비즈니스 데이터를 만들어 가짜 데이터를 대체하며, 오류 처리와 사용자 피드백을 추가하고, 마지막에는 남에게 보여 줄 수 있을 만큼 그럴듯한 완성형 프로토타입으로 다듬습니다.
+
+이 장은 초급 단계의 마지막 장입니다. 이 단계를 마치면 "프로그래밍을 전혀 못함"에서 "AI 제품 프로토타입을 독립적으로 만들 수 있음"으로 바뀌는 전환을 완료하게 됩니다.
+
+
+
+
+
+
+
+
+
+## 1. "Happy Path" 거부하기: 핵심 흐름 완성
+
+많은 초보자는 프로토타입을 만들 때 "Happy Path", 즉 가장 이상적인 경로만 만듭니다. 사용자가 클릭한다 -> API 응답이 성공한다 -> 결과를 보여 준다.
+하지만 현실 세계에서는 일이 그렇게 순조롭지만은 않습니다. 당신의 프로토타입이 진짜 제품처럼 보이게 하려면 다음과 같은 "보이지 않는" 고리를 고려해야 합니다.
+
+### 1.1 "기다림"과 "피드백" 추가하기
+
+사용자가 "문구 생성"을 클릭하면 AI는 대개 응답까지 몇 초가 필요합니다. 이때 인터페이스가 아무 반응도 보이지 않으면 사용자는 프로그램이 고장 났다고 생각합니다.
+**AI IDE에게 Loading 상태를 추가해 달라고 해야 합니다.**
+
+> 프롬프트 예시:
+> "생성 버튼을 클릭하면 버튼을 '생성 중...'으로 바꾸고 클릭할 수 없게 해 주세요. 동시에 오른쪽 영역에는 로딩 애니메이션을 표시해 주세요. API 결과가 반환된 뒤에 다시 정상 상태로 되돌려 주세요."
+
+### 1.2 "실패"와 "예외" 처리하기
+
+API Key가 만료될 수도 있고, 네트워크가 끊길 수도 있습니다.
+**AI IDE에게 오류 처리를 도와달라고 해야 합니다.**
+
+> 프롬프트 예시:
+> "API 요청이 실패하면 콘솔에만 오류를 내지 말고, 페이지 상단에 빨간색 알림 상자(Toast)를 띄워 사용자에게 '생성에 실패했습니다. 잠시 후 다시 시도해 주세요'라고 알려 주세요. 그리고 사용자가 생성 버튼을 다시 클릭할 수 있게 해 주세요."
+
+### 1.3 대화 기록 영속화
+
+AI와 상호작용하는 과정에서는 대화 내용을 저장해 사용자가 기록을 다시 보고 이전 대화를 이어 갈 수 있어야 합니다. 현재 단계에서는 데이터베이스를 도입하지 않고, 다음과 같은 가벼운 방안을 선택할 수 있습니다.
+
+**저장 방안 선택:**
+
+| 방안 | 적합한 상황 | 특징 |
+| ---------------- | -------------------------------- | ------------------------------------ |
+| **LocalStorage** | 순수 프론트엔드 프로젝트, 사용자 데이터가 브라우저에 저장됨 | 구현이 간단하고 새로고침해도 사라지지 않지만, 기기 간 동기화는 불가 |
+| **JSON 파일** | 로컬 프로토타입, 데이터를 파일 형태로 저장 | 구조가 명확하고 디버깅이 쉬우며 수동 편집 가능 |
+| **TXT 파일** | 가장 단순한 방안, 텍스트 내용을 빠르게 기록 | 형식이 자유롭고 호환성이 좋음 |
+
+**대화 내용 예시:**
+저장되는 대화 기록은 보통 다음 내용을 포함합니다.
+
+```json
+[
+ {
+ "role": "user",
+ "content": "블루투스 이어폰의 Douyin 판매 문구를 만들어 줘",
+ "timestamp": "2026-01-20 10:30:00"
+ },
+ {
+ "role": "assistant",
+ "content": "【블루투스 이어폰 추천 문구】\n\n🎧 지연은 이제 그만, 몰입형 음악 감상 경험\n\n여러분! 이 블루투스 이어폰 진짜 대박이에요👇\n\n✅ 40dB 액티브 노이즈 캔슬링, 순식간에 음악 세계로\n✅ 30시간 초장시간 배터리, 일주일 출퇴근 충전 걱정 없음\n✅ 통화 품질은 마치 대면 대화처럼 선명, 지하철 소음 속에서도 편하게\n✅ 세미 인이어 디자인, 오래 착용해도 아프거나 답답하지 않음\n\n💰 기간 한정 할인, 아래 링크로 바로 구매하세요!",
+ "timestamp": "2026-01-20 10:30:05"
+ }
+]
```
-하지만 실제 사용자는 빈 입력을 넣고, 네트워크가 실패하고, 결과가 마음에 들지 않을 수 있습니다. 최소한 다음 상태를 만들어야 합니다.
+**구현 프롬프트:**
-- 입력 전 안내
-- 입력값 검증
-- 로딩
-- 성공
-- 실패
-- 재시도
+> "대화 기록 저장 기능을 구현해 주세요. 사용자와 AI의 대화 기록을 JSON 파일로 저장하거나 LocalStorage를 사용하도록 지원해 주세요. 페이지에 들어올 때마다 기존 대화 기록을 자동으로 불러오고, 단일 대화 기록을 조회하고 삭제할 수 있게 해 주세요."
-## 2. 실제 같은 데이터 넣기
+
+
+
+
+
-빈 카드와 `test`, `hello`, `sample` 같은 데이터는 제품을 약하게 보이게 합니다. AI에게 도메인에 맞는 샘플 데이터를 만들어 달라고 요청하세요.
+## 2. 영혼 주입하기: 실제 같은 데이터(Mock Data) 시뮬레이션
-```text
-내 앱은 소상공인용 상품 문구 생성기야.
-실제처럼 보이는 샘플 상품 데이터 10개를 만들어 줘.
-각 데이터에는 상품명, 특징, 타깃 고객, 가격대, 원하는 톤을 포함해 줘.
+텅 빈 페이지는 사람을 설득할 수 없습니다. "이커머스 소재 워크벤치"를 보여 주는데 기록이 텅 비어 있거나 "test / test / test" 한 줄만 있다고 상상해 보세요.
+가장 좋은 시연 효과를 만들려면 실제처럼 보이는 데이터를 "위조"해야 합니다. 그래야 프로토타입이 이미 반년 정도 운영된 진짜 제품처럼 보입니다.
+
+### 2.1 AI에게 데이터 구조 설계를 맡기기
+
+우리가 각 필드의 이름을 하나하나 생각할 필요는 없습니다. 예를 들어 `name`이라고 할지 `title`이라고 할지 고민하는 일은 AI에게 맡길 수 있습니다.
+
+당신은 AI에게 **비즈니스 장면**만 알려 주면 됩니다.
+
+> **프롬프트 예시:**
+> "나는 **Douyin 이커머스 소재 워크벤치** 프로토타입을 만들고 있어.
+> '상품 작업'을 설명하기 위한 JSON 데이터 구조를 설계해 줘.
+> 이 작업에는 상품의 기본 정보(이름, 카테고리), 입력 소재(이미지 링크), 그리고 AI가 생성한 결과(제목, 문구, 포스터 이미지)가 포함되어야 해.
+> JSON 예시를 바로 줘."
+
+AI는 당신의 설명에 따라 `productName`, `generatedContent` 같은 필드를 자동으로 구상해 줍니다.
+
+### 2.2 AI에게 "실감 나는" 데이터를 대량 생산하게 하기
+
+데이터 구조가 생겼다면 다음 단계는 AI에게 "빈칸을 채워" 실제처럼 보이는 데이터를 한 묶음 만들게 하는 것입니다.
+
+**프롬프트 팁:**
+AI에게 "데이터 만들어 줘"라고만 말하면 안 됩니다. 인턴에게 업무를 맡기듯 **비즈니스 배경**과 **내용 요구사항**을 알려 줘야 합니다.
+
+- **비즈니스 배경**: 우리는 "Douyin 이커머스"를 하므로 상품 제목은 눈길을 끌어야 합니다. 예: "날씬해 보이는 필수템", "학생 필수 구매". 문구는 구어체여야 합니다.
+- **이미지 요구사항**: 프로토타입을 예쁘게 보이게 하려면 이미지는 흑백 플레이스홀더가 아니라 랜덤 컬러 풍경이나 실제 물건 이미지가 좋습니다.
+
+> **프롬프트 예시:**
+> "방금 설계한 구조를 바탕으로 실감 나는 Mock Data 10개를 만들어 줘.
+> (비고: 반드시 JSON 형식일 필요는 없어. 프론트엔드를 작성 중이라면 JavaScript 배열로 바로 생성하게 해도 되고, Python을 쓴다면 List로 생성하게 해도 돼.)
+>
+> **비즈니스 장면 요구사항**:
+>
+> 1. 종합 잡화점이라고 가정하고, 상품은 '여성복', '디지털', '뷰티' 세 카테고리를 포함해.
+> 2. **생성된 제목과 문구는 매우 'Douyin 스타일'이어야 해**: 예를 들어 제목에는 Emoji(🔥, ✨)를 포함하고, 문구는 '대박', '직접 써 보니 좋음' 같은 말투를 사용해.
+> 3. **이미지 필드**: 모두 `https://picsum.photos/seed/{random_id}/300/400` 형식을 사용해서 각 이미지가 서로 다르게 보이도록 해."
+
+**생성된 Mock Data 예시:**
+
+```javascript
+export const mockProductTasks = [
+ {
+ id: 'task_001',
+ name: '여름 프렌치 빈티지 플라워 원피스',
+ status: 'completed',
+ input: {
+ category: '여성복',
+ features: ['허리 라인', '날씬해 보임', '분위기'],
+ originalImage: 'https://picsum.photos/seed/dress_input/300/400'
+ },
+ output: {
+ generatedTitle: '✨누가 입어도 예쁨! 이 프렌치 플라워 원피스 진짜 대박🔥',
+ generatedCopy:
+ '여러분! 이 원피스 진짜 날씬해 보여요! 허리 라인이 정말 좋아서 입자마자 실루엣이 살아나요. 원단도 통기성이 좋아 여름에 입어도 전혀 답답하지 않아요. 데이트와 쇼핑에 강력 추천!👗',
+ generatedPosterImage: 'https://picsum.photos/seed/dress_output/300/400'
+ },
+ createdAt: '2026-01-20T10:00:00Z'
+ },
+ {
+ id: 'task_002',
+ name: '초강력 노이즈 캔슬링 블루투스 이어폰 Pro',
+ status: 'completed',
+ input: {
+ category: '디지털',
+ features: ['노이즈 캔슬링', '초장시간 배터리', '저지연'],
+ originalImage: 'https://picsum.photos/seed/tech_input/300/400'
+ },
+ output: {
+ generatedTitle: '🎧 드디어 찾았다! 이 이어폰 노이즈 캔슬링 너무 강력하잖아!🔇',
+ generatedCopy:
+ '착용하는 순간 세상이 조용해져요. 음질도 뛰어나서 노래를 들으면 현장에 있는 것 같아요. 배터리도 정말 오래가서 한 번 충전하면 일주일 사용 가능! 학생 필수템!',
+ generatedPosterImage: 'https://picsum.photos/seed/tech_output/300/400'
+ },
+ createdAt: '2026-01-21T14:30:00Z'
+ }
+ // ... 더 많은 데이터
+]
```
-샘플 데이터가 좋아지면 데모 설득력이 크게 올라갑니다.
+### 2.3 (고급) LocalStorage로 "가짜 CRUD" 구현하기
-## 3. 사용자 피드백 받기
+방금 만든 "Mock Data"가 단지 보기만 하는 것이 아니라 삭제, 수정도 가능하고, 새로 생성한 작업이 페이지 새로고침 후에도 남아 있기를 원한다면 `LocalStorage`를 결합할 수 있습니다.
-피드백은 "좋아 보여?"라고 묻지 않습니다. 실제 행동을 관찰합니다.
+> **프롬프트 예시:**
+> "데이터 저장 기능을 구현해 줘.
+>
+> 1. 우선 `localStorage`에서 데이터를 읽어 와.
+> 2. `localStorage`가 비어 있으면 방금 생성한 Mock Data로 초기화하고, 그것들을 `localStorage`에 저장해.
+> 3. 동시에 `addProductTask`와 `deleteProductTask` 함수를 작성해 줘. 매번 작업할 때마다 `localStorage`도 동기화해야 해."
-좋은 질문:
+이 단계를 거치면 프로토타입은 "기억"을 가지게 되고, 사용자 경험은 거의 진짜 제품과 다르지 않게 됩니다.
-- 이 화면에서 먼저 무엇을 눌러 보고 싶나요?
-- 어떤 정보를 입력해야 하는지 바로 알겠나요?
-- 나온 결과를 실제로 어디에 쓸 수 있을 것 같나요?
-- 헷갈리는 문구나 버튼이 있나요?
-- 이 기능이 없어도 되는 부분은 무엇인가요?
+
+
+
+
+
-좋지 않은 질문:
+## 3. 피드백 수집과 빠른 반복 개선
-- 이거 쓸 것 같나요?
-- 괜찮죠?
-- 예쁘죠?
+문을 닫고 혼자 만들면 좋은 제품은 나오지 않습니다. 이제 당신의 프로토타입은 "핵심 기능" + "완전한 흐름" + "시연 데이터"를 갖췄습니다. 다른 사람에게 보여 줄 때가 되었습니다.
-## 4. 피드백을 개선 작업으로 바꾸기
+### 3.1 누구에게 테스트하게 할까? 어떻게 테스트할까?
-피드백을 받으면 바로 큰 개편을 하지 말고 작은 수정 단위로 정리합니다.
+- **친구/동료 찾기**: 기술을 알 필요는 없습니다. 그냥 직접 사용해 보게 하면 됩니다.
+- **유도하지 말고 관찰하기**: "여기를 클릭하세요"라고 말하지 말고, 그들이 어디를 클릭하는지 봅니다. 버튼을 찾지 못한다면 설계에 문제가 있다는 뜻입니다.
+- **"Wizard of Oz"(오즈의 마법사 방법)**: AI가 아직 제대로 연결되지 않았다면, 백그라운드나 데이터베이스에서 사람이 직접 데이터를 수정해 AI 반환을 흉내 내고, 먼저 사용자가 이 기능을 필요로 하는지 검증할 수 있습니다.
-| 피드백 | 수정 작업 |
-| --- | --- |
-| 무엇을 입력해야 할지 모르겠다 | 입력 예시와 placeholder 추가 |
-| 결과가 너무 길다 | 결과 카드에 요약과 펼치기 추가 |
-| 버튼이 눈에 안 띈다 | 주요 CTA 스타일 개선 |
-| 실패했을 때 멈춘 줄 알았다 | 로딩/오류 상태 추가 |
+### 3.2 Bug와 불평을 마주하기
-AI IDE에는 이렇게 요청합니다.
+- **스타일 깨짐**: 화면 크기가 다르면 레이아웃이 깨질 수 있습니다.
+ - **Action**: 스크린샷을 AI IDE에게 보내기 -> "이 화면 너비에서 깨졌어. 고쳐 줘."
+- **조작이 불편함**: "이 흐름이 너무 번거로워요."
+ - **Action**: 제안을 AI IDE에게 말하기 -> "사용자가 먼저 업로드하고 다시 생성하는 흐름이 너무 느리다고 해. 한 번에 생성하도록 바꿀 수 있을까?"
+- **새 요구사항**: "이 기능이 있으면 좋겠어요."
+ - **Action**: 핵심인지 평가합니다. 핵심이라면 AI에게 빠르게 간소화 버전을 구현하게 합니다.
-```text
-사용자 피드백을 반영해 프로토타입을 개선하고 싶어.
-아래 피드백을 작은 수정 작업으로 나누고,
-가장 영향이 큰 것부터 순서대로 수정해 줘.
+**기억하세요. 이 단계에서 AI는 최고의 수정 조수입니다. 당신은 문제를 발견하기만 하면 되고, 코드 수정은 AI에게 맡기면 됩니다.**
-[피드백 목록]
-```
+
+
+
+
+
-## 5. 최종 제출물
+## 4. 🎓 단계 대과제: 당신의 "졸업 작품" 완성하기
-Stage 1을 마칠 때 다음이 있으면 충분합니다.
+축하합니다! 당신은 이미 "요구사항"에서 "프로토타입", 그리고 "AI 통합"까지 전 과정을 걸어왔습니다. 이제 최종 결과물을 보여 줄 시간입니다.
-1. 제품 아이디어 한 문장
-2. 대상 사용자와 사용 상황
-3. 핵심 화면 1~3개
-4. AI 기능 하나
-5. 실제 같은 샘플 데이터
-6. 로딩/오류/빈 상태
-7. 주변 사용자 피드백 3개 이상
-8. 개선 전후 정리
+**이번 대과제는 더 이상 "이커머스 소재 워크벤치"에만 제한되지 않습니다**. 자신의 관심사나 산업 배경을 결합해 세상에 하나뿐인 AI 제품 프로토타입을 만들어야 합니다.
-## 6. 마무리 체크리스트
+### 주제 선정과 요구사항
-- 앱을 처음 보는 사람이 목적을 이해할 수 있다.
-- 핵심 기능을 1분 안에 체험할 수 있다.
-- 결과물이 사용자의 문제와 연결된다.
-- 오류가 나도 화면이 무너지지 않는다.
-- 데모 링크나 로컬 실행 방법을 설명할 수 있다.
+**[산업 다분류 시나리오 방향 참고](../appendix-industry-scenarios/index.md)** 중 가장 가까운 장면을 하나 선택하거나, 자신의 생각에 따라 완전히 새로운 장면을 구상해야 합니다.
+
+**프로젝트는 앞의 몇 장에서 배운 모든 내용을 종합적으로 활용해야 합니다.**
+
+1. **프로토타입 구축**: 프론트엔드 기술을 사용해 아름답고 사용하기 쉬운 인터페이스를 만듭니다.
+2. **요구사항 제어**: 크고 완전한 것을 추구하지 말고, 핵심 기능의 논리적 폐쇄 루프를 추구합니다.
+3. **API 접목**: 실제 AI 모델(LLM/VLM 등)을 연결해 애플리케이션에 진짜 지능을 부여합니다.
+4. **가지고 놀 수 있는 애플리케이션 구현**: 단순한 정적 페이지가 아니라 데이터 흐름과 상호작용 피드백이 있는 동적 애플리케이션이어야 합니다.
+
+### 과제 산출물
+
+최종적으로 다음 두 가지를 제출해야 합니다.
+
+1. **완성된 프로토타입 애플리케이션**: 온라인 배포 또는 로컬 실행이 가능하고, 완전한 사용 흐름을 갖춰야 합니다.
+2. **30초 시연 영상**: 애플리케이션의 사용 장면을 간단히 소개하고 핵심 기능의 실제 조작을 보여 주는 영상을 녹화합니다.
+
+
+
+
🚀 최종 도전 체크리스트
+
+
+
+ 이것은 Stage 1의 마지막 전투입니다. 아래 체크리스트에 따라 작품을 확인하세요.
+
+
+
핵심 기능 자가 점검
+
+
+
+
+
+
+
+
제출물 준비
+
+
+
+
+
## 다음 단계
-Stage 1을 마쳤다면 두 가지 방향이 있습니다.
+대과제를 완료했다면, 당신은 이미 "AI 애플리케이션 프로토타입을 독립적으로 개발하는" 능력을 갖춘 것입니다.
+다음 Stage 2에서는 더 복잡한 풀스택 개발을 깊이 다루며, 이 프로토타입을 실제로 배포 가능하고, 데이터베이스와 사용자 시스템을 갖춘 상업 수준의 애플리케이션으로 바꾸는 법을 배웁니다.
-- 더 탄탄한 웹 제품을 만들고 싶다면 [Stage 2](/ko-kr/stage-2/)로 이동합니다.
-- 제품 기획과 검증을 더 연습하고 싶다면 [제품 사고 부록](/ko-kr/stage-1/appendix-a-product-thinking/)을 봅니다.
+다음 단계에서 만나요!
+
+
diff --git a/docs/ko-kr/stage-1/finding-great-idea/index.md b/docs/ko-kr/stage-1/finding-great-idea/index.md
index be1c89c..8374b28 100644
--- a/docs/ko-kr/stage-1/finding-great-idea/index.md
+++ b/docs/ko-kr/stage-1/finding-great-idea/index.md
@@ -1,164 +1,1085 @@
---
-title: '좋은 아이디어 찾기'
-description: 'AI 시대에 초보자가 만들기 좋은 제품 아이디어를 찾고 검증하는 방법을 설명합니다.'
+title: '좋은 아이디어 찾기 - 사용자 요구에서 누군가 비용을 지불하는 지점까지'
+description: '일상의 문제점에서 비즈니스 기회를 발견하는 법을 배우고, 요구사항 분석의 체계적인 방법론을 익혀 평범한 생각을 사용자가 기꺼이 비용을 지불할 제품 개념으로 다듬습니다.'
---
-# 좋은 아이디어 찾기
+
-AI가 코드를 대신 써 주는 시대에도 좋은 제품은 자동으로 나오지 않습니다. 오히려 구현 장벽이 낮아질수록 "무엇을 만들 것인가"가 더 중요해집니다.
+# 초급 2: 좋은 아이디어 찾기
-좋은 아이디어는 화려한 기술에서 시작하지 않습니다. 보통 특정 사람이 반복해서 겪는 불편에서 시작합니다.
+## 이 장의 가이드
-## 1. 좋은 아이디어의 조건
+
-초보자가 시작하기 좋은 아이디어는 다음 조건을 만족합니다.
+앞에서 우리는 AI IDE로 무언가를 만드는 법을 배웠습니다. 하지만 더 근본적인 문제가 하나 있습니다. 무엇을 만들 것인가?
-| 조건 | 설명 |
-| --- | --- |
-| 대상이 구체적이다 | "모든 사람"보다 "공모전 준비하는 대학생"이 낫습니다. |
-| 상황이 분명하다 | 언제, 어디서, 왜 쓰는지 말할 수 있어야 합니다. |
-| 현재 대안이 불편하다 | 엑셀, 메모장, 수작업, 여러 앱 조합처럼 불편한 대안이 있으면 좋습니다. |
-| 작게 만들 수 있다 | 첫 버전은 한두 개 핵심 기능으로 충분해야 합니다. |
-| 직접 검증할 수 있다 | 주변 사람에게 보여 주고 반응을 받을 수 있어야 합니다. |
+많은 사람은 시작하자마자 “AI 도구 하나 만들자”, “소셜 플랫폼 하나 하자”라고 생각하지만, 결과물은 아무도 쓰지 않습니다. 문제는 어디에 있을까요? 진짜 요구를 찾지 못했기 때문입니다.
-## 2. 아이디어를 찾는 질문
+더 냉혹한 현실도 있습니다. 많은 제품은 문제를 해결했는데도 사용자가 비용을 지불하려 하지 않습니다.
-다음 질문에서 출발해 보세요.
+이번 장에서는 샤오밍의 이야기를 통해, 만들 가치가 있는 제품 방향을 찾는 법을 배웁니다.
-- 내가 매주 반복해서 하는 귀찮은 일은 무엇인가?
-- 주변 사람이 자주 부탁하는 일은 무엇인가?
-- 엑셀이나 노션으로 억지로 관리하고 있는 일은 무엇인가?
-- 검색하고 복사하고 정리하는 데 시간이 많이 드는 일은 무엇인가?
-- 결과물을 만들 때 매번 비슷한 형식을 반복하는 일은 무엇인가?
+이 장을 마치면 당신은 좋은 아이디어를 찾는 완전한 방법론과 검증된 제품 개념 3개를 갖게 됩니다.
-AI 제품 아이디어는 "AI를 넣고 싶다"에서 시작하면 흔들리기 쉽습니다. 먼저 문제를 찾고, 그 문제를 줄이는 과정에서 AI가 필요한지 판단하는 편이 낫습니다.
+
-## 3. 아이디어를 좁히는 방법
-나쁜 예:
+
+
+
+
+
-```text
-AI 비서 앱을 만들고 싶다.
+## Step 1: 판단 기준 세우기 - 어떤 요구에 사용자가 비용을 지불할까
+
+::: warning 이 장은 왜 중요한가?
+
+누군가는 이상하게 느낄 수 있습니다. “이건 Vibe Coding을 가르치는 수업 아닌가? 왜 먼저 ‘요구 찾기’를 배워야 하지? 바로 코드 쓰면 안 되나?”
+
+맞습니다. 시중의 많은 프로그래밍 수업은 바로 프로젝트를 만들게 합니다. Todo List 만들기, 계산기 만들기, 개인 블로그 만들기... 이런 프로젝트는 문법과 도구에 익숙해지는 데 분명 도움 됩니다. 하지만 문제는 다음입니다.
+
+방향이 틀리면, 깊이 들어갈수록 더 많이 틀립니다.
+
+상상해 보세요.
+- 2주 동안 “일정 관리 시스템”을 만들었지만 시장에는 이미 더 좋은 것이 100개 있습니다.
+- “사진으로 칼로리 계산”을 만들었지만 사용자는 한 번 쓰고 삭제합니다.
+- “개인 가계부”를 만들었지만 당신 자신도 쓰기 귀찮아합니다.
+
+이런 프로젝트를 완성한 뒤 이력서에 쓸 수 있을까요? 아마 어렵습니다. 진짜 문제를 해결하지 않았고, 진짜 가치를 만들지 않았기 때문입니다.
+
+더 냉정하게 말하면, 어차피 시간을 들여 배울 거라면 왜 더 좋은 결과를 추구하지 않을까요?
+
+Vibe Coding이 우리에게 아이디어를 빠르게 제품으로 바꿀 수 있게 해 준다면, 우리는 더욱 만들 가치가 있는 아이디어를 찾는 법을 배워야 합니다. 실전에 가장 가까운 방식으로 훈련해야 합니다. “연습 프로젝트”를 만드는 것이 아니라 “누군가 기꺼이 사용할 제품”을 만드는 것입니다.
+
+그래서 우리는 먼저 “좋은 아이디어 찾기”를 배웁니다.
+
+---
+
+**필자는 개인적으로** 시간이 매우 소중하다고 생각합니다. **할 거면 가장 잘해야 합니다.** 그렇지 않다면 왜 놀러 가지 않을까요? 책임감으로서 필자도 최선을 다해 당신이 가장 잘할 수 있도록 지원하겠습니다.
+
+모든 사람이 당신이 잘할 수 있다고 믿지 않더라도, 필자는 흔들림 없이 당신이 가장 잘할 수 있기를 바랍니다. vibecoding으로 제품을 만들기로 했다면, 자신이 어디까지 갈 수 있는지 한번 시험해 봅시다!
+
+:::
+
+
+---
+
+## 시작: 독립 개발자 샤오밍의 이야기
+
+샤오밍은 프로그래머이고, 일한 지 3년이 되었습니다. 어느 날 문득 이런 생각이 떠올랐습니다. 피트니스 APP을 하나 만들어 보면 어떨까? 사용자가 운동 계획을 세우고 훈련 데이터를 기록하도록 돕는 앱입니다. 이 생각에 그는 매우 흥분했고, 드디어 만들 수 있는 프로젝트를 찾았다고 느꼈습니다.
+
+그다음 1년 동안 샤오밍은 거의 모든 여가 시간을 쏟아부었습니다. 그는 기능이 매우 완전한 APP을 만들었습니다. 수업 모듈, 출석 체크 시스템, 커뮤니티 기능, 데이터 분석까지 있어야 할 것은 다 있었습니다. 인터페이스도 꽤 보기 좋았습니다. 적어도 본인은 꽤 만족했습니다.
+
+출시 당일, 샤오밍은 큰 기대를 품었습니다. 홍보에도 적지 않은 돈을 썼고, 첫 달에 5만 명이 다운로드했습니다. 시작은 좋아 보였습니다. 그렇지 않나요?
+
+하지만 곧 문제가 나타났습니다. 사용자는 다운로드한 뒤 한 번 쓰고 삭제했고, 7일 유지율은 5%뿐이었습니다. 그는 몇 가지 유료 기능을 만들었지만, 거의 아무도 돈을 내려고 하지 않았습니다. 더 낙담스러운 것은 Keep, Bohe Health, FitTime 같은 성숙한 제품들이 기능도 더 많고 콘텐츠도 더 좋다는 점이었습니다. 사용자가 왜 그의 APP으로 옮겨와야 할까요?
+
+1년 뒤 샤오밍은 20만 위안을 손해 봤습니다.
+
+그는 컴퓨터 앞에 앉아 처참한 백오피스 데이터를 보며 마음속에 단 하나의 질문만 남았습니다. 내 APP은 꽤 잘 만들었는데, 왜 아무도 쓰지 않을까? 더구나 왜 아무도 비용을 지불하지 않을까?
+
+
+
+샤오밍의 실패는 기술이 부족해서도, 제품을 잘못 만들어서도 아닙니다. 솔직히 말해 그의 APP은 기능이 꽤 완전했고, 인터페이스도 꽤 보기 좋았습니다.
+
+**문제는 출발점에 있었습니다.**
+
+그는 가장 기본적인 질문을 한 번도 하지 않았습니다. 사용자가 정말 필요로 하는가?
+
+그는 피트니스 APP 시장이 크고 Keep의 기업가치가 수십억이라고 보고, 이것이 좋은 기회라고 생각했습니다. 하지만 몇 가지를 제대로 파악하지 못했습니다. 사용자는 왜 또 다른 피트니스 APP이 필요할까요? Keep과 비교해 내 차별점은 무엇일까요? 사용자는 이것에 비용을 지불할 의향이 있을까요?
+
+**방향이 틀리면, 깊이 들어갈수록 더 많이 틀립니다.** 그는 1년을 들여 틀린 방향을 점점 더 완성도 있게 만들었고, 결과적으로 성공에서 점점 더 멀어졌습니다.
+
+
+::: tip 이 장에서 우리가 할 일
+
+이번 장에서는 샤오밍의 실패를 함께 되짚어 봅니다. 문제가 정확히 어디에서 생겼는지 보고, 진짜로 누군가 비용을 지불할 제품 방향을 함께 찾습니다.
+
+우리는 세 단계로 진행합니다.
+
+**1막: 진짜 요구 찾기** - 먼저 어떤 요구에 사용자가 비용을 지불하는지 파악합니다.
+
+**2막: 좋은 아이디어 파내기** - 평범한 생각에서 가치 있는 비즈니스 기회를 발굴하는 법을 배웁니다.
+
+**3막: AI 대화로 다듬기** - AI를 사용해 생각을 실행 가능한 제품 방안으로 바꿉니다.
+
+:::
+
+---
+
+## 1막: 진짜 요구 찾기
+
+샤오밍은 매우 낙담했지만 포기하지 않았습니다. 그는 한 가지 문제를 되돌아보기 시작했습니다. 대체 어떤 요구에 사용자가 비용을 지불할까요?
+
+### 샤오밍의 혼란: 왜 사용자는 비용을 지불하지 않을까?
+
+그는 자신의 APP을 사용해 본 친구 몇 명을 찾아가 진짜 생각을 들어 보려고 했습니다.
+
+친구 A가 말했습니다. “네 APP은 꽤 잘 만들었어. 그런데 나는 이미 Keep을 쓰고 있는데 왜 바꿔야 해?”
+
+친구 B가 말했습니다. “매번 운동을 기록하라고 하는 게 너무 번거로워. 나는 기록하기 귀찮아.”
+
+친구 C는 더 직접적으로 말했습니다. “무료 기능으로 충분한데 왜 돈을 내야 해?”
+
+이 답변들은 샤오밍에게 문제가 어디에 있는지 갑자기 깨닫게 했습니다.
+
+**첫 번째 문제: 사용자가 바꾸지 않는 이유는 기존 방안이 이미 충분히 좋기 때문입니다.** Keep 같은 성숙한 제품은 기능이 이미 매우 완전하고, 사용자 습관도 형성되어 있으며, 이전 비용이 높습니다. 비슷한 제품 하나를 만든다고 해서 사용자가 왜 바꿔야 할까요?
+
+**두 번째 문제: 사용자는 습관을 바꾸려 하지 않습니다.** 운동을 기록하는 일은 사용자에게 너무 번거롭습니다. 어떤 제품이 사용자에게 3개 이상의 습관을 바꾸라고 요구하면 실패할 확률이 높습니다.
+
+**세 번째 문제: 무료 대체재가 너무 많습니다.** 기능이 너무 범용적이고 독특한 가치가 없으면, 사용자는 비용을 지불할 이유를 찾지 못합니다.
+
+### 진짜 요구란 무엇인가?
+
+샤오밍은 사용자가 기꺼이 비용을 지불하는 성공 제품들을 연구하기 시작했습니다. 그는 공통점을 하나 발견했습니다. 이런 제품들이 해결하는 것은 “내가 유용하다고 느끼는” 요구가 아니라, 사용자가 비용을 지불하고, 행동을 바꾸고, 불편을 감수할 의지가 있는 요구였습니다.
+
+다시 말해 **진짜 요구는 사용자가 발로 투표해 드러낸 것이지, 제품 관리자가 머리로 상상해 낸 것이 아닙니다.**
+
+### 사례: 사용자가 비용을 지불하게 하는 제품
+
+샤오밍은 성공 사례 몇 가지를 연구하며, 이들이 정확히 어떤 문제점을 붙잡았는지 알고 싶었습니다.
+
+#### Meicai: 작은 식당 사장이 잠을 잘 수 있게 하기
+
+겉으로 보면 Meicai가 하는 일은 간단합니다. 식당의 식재료 구매를 도와줍니다. 하지만 자세히 생각해 보면 식당 사장은 왜 이것을 사용할까요?
+
+작은 식당 사장은 매일 새벽 4시에 일어나 도매시장에 가야 합니다. 매우 힘들고, 자주 바가지를 쓰기도 합니다. Meicai가 하는 일은 단순한 “식재료 이커머스”가 아니라 전체 공급망을 재구성하여 작은 식당 사장이 잠을 잘 수 있게 하는 것입니다.
+
+문제점이 아플수록 지불 의향은 강해집니다. 절약되는 시간과 체력은 절약되는 식재료 값보다 더 가치 있습니다.
+
+#### 샤오홍슈: 선택 어려움 해결
+
+겉으로 보면 샤오홍슈는 “해외 쇼핑 경험 공유”입니다. 하지만 사용자는 왜 시간을 들여 그 안의 노트를 볼까요?
+
+상품이 너무 많을 때 사용자는 무엇이 살 만하고 무엇이 살 만하지 않은지 모릅니다. 자신을 대신해 선별해 주고, 시간을 아끼고, 함정을 피하게 도와줄 믿을 만한 사람이 필요합니다.
+
+샤오홍슈가 해결하는 것은 사실 두 가지 깊은 문제점입니다. 선택 어려움과 신뢰 결핍입니다. 사용자는 “시간 절약”과 “실패 회피”에 기꺼이 비용을 지불합니다. 이것이 샤오홍슈가 성장할 수 있었던 이유입니다.
+
+---
+
+이 사례들을 본 뒤 샤오밍은 중요한 발견을 했습니다.
+
+사용자가 비용을 지불하는 것은 결코 “기능”이 아니라 “두려움 해결”과 “불안 제거”입니다. Meicai는 작은 식당 사장이 새벽 구매의 고됨을 두려워하는 문제를 해결하고, 샤오홍슈는 사용자가 잘못 살까 봐 두려워하는 문제를 해결합니다.
+
+**두려움은 결제를 이끌고, 불안은 행동을 이끕니다.**
+
+### 요구의 세 층: 문제점, 만족점, 가려운 지점
+
+샤오밍은 더 연구하면서 사용자의 요구를 세 가지 유형으로 나눌 수 있다는 것을 발견했습니다.
+
+::: tip 문제점(Pain Point) - 두려움이 이끄는 것
+
+**본질:** 사용자가 지금 겪고 있으며 고통, 불안, 불편을 느끼게 하는 문제입니다. 해결하지 않으면 매우 괴롭고, 심지어 생존이나 안전을 위협할 수도 있습니다.
+
+**예시:**
+- 당뇨병 환자가 탄수화물을 얼마나 먹으면 혈당이 급상승하는지 모름(두려움: 건강 위협)
+- 작은 식당 사장이 새벽 4시에 일어나 도매시장에 감(두려움: 생존의 고됨)
+
+**핵심:** 사용자는 이것에 비용을 지불할 의향이 있습니다. 해결하지 않으면 “너무 아프기” 때문입니다.
+
+:::
+
+::: tip 만족점(Delight Point) - 즉시 만족
+
+**본질:** 사용자에게 어떤 요구가 있고, 그것이 즉시 충족되어 즉각적인 즐거움을 만드는 것입니다.
+
+**예시:**
+- 배달 음식이 30분 안에 도착함(배고픔의 즉시 만족)
+- 클릭 한 번으로 보기 좋은 PPT 생성(시간과 힘을 아끼는 만족감)
+
+**핵심:** 사용자를 “기분 좋게” 만드는 것은 유지율의 핵심이지만, 단독 결제 포인트로는 약합니다.
+:::
+
+::: tip 가려운 지점(Itch Point) - 가상의 자아
+
+**본질:** 사용자는 더 나아지고, 더 멋지고, 더 세련되고 싶어 하지만 필수는 아닙니다. 만족하면 기쁘지만, 만족하지 않아도 괜찮습니다.
+
+**예시:**
+- 매일 물을 얼마나 마셨는지 기록하기(상상 속의 자기관리 생활)
+- AI로 사진에 예술 필터 추가하기(상상 속의 예술적 취향)
+
+**핵심:** 사용자가 “가려운 지점”에 비용을 지불할 의향은 약합니다. 해결하지 않아도 괜찮기 때문입니다.
+
+:::
+
+올바른 우선순위는 어떻게 봐야 할까요? 좋은 제안은 다음입니다. 문제점 > 만족점 > 가려운 지점
+
+왜 그럴까요?
+
+1. **문제점은 생존 요구입니다:** 해결하지 않으면 죽거나 매우 괴롭습니다. 사용자는 비용을 지불할 수밖에 없습니다. “진통제”입니다.
+2. **만족점은 즉시 보상입니다:** 사용자를 기분 좋게 만들면 사용자는 다시 옵니다. “중독 장치”입니다.
+3. **가려운 지점은 욕망 충족입니다:** 있어도 되고 없어도 되며, 가장 먼저 잘려 나가기 쉽습니다. “비타민” 또는 “사치품”입니다.
+
+**핵심 통찰:** 많은 제품 관리자가 저지르는 실수는 가려운 지점 제품을 문제점 방식으로 팔려고 하는 것입니다.
+
+예: “물 마시는 기록은 더 건강해지게 합니다.” 물을 마시는 것은 확실히 건강하지만, 기록하지 않는다고 건강하지 않은 것은 아닙니다. 이것은 가려운 지점을 문제점으로 포장하는 것이며, 사용자는 납득하지 않습니다.
+
+### 진짜 요구를 검증하는 5단계 방법
+
+샤오밍은 생각했습니다. **그렇다면 내게 아이디어가 하나 있을 때, 이것이 투자할 가치가 있는지 어떻게 빠르게 판단할 수 있을까?**
+
+그는 제품 관리자가 자주 쓰는 5단계 판단법을 배웠습니다. 자세한 내용은 부록 A에 있습니다.
+
+1. **1단계: 실제 사용자와 직접 대화하고, 지금 어떻게 하고 있는지 이해하기**
+
+ 목표 사용자 10명을 찾습니다. “지금은 이 문제를 어떻게 해결하고 있나요?”라고 묻습니다. 사용자가 이미 어떤 방법을 쓰고 있다면 문제가 실제로 존재한다는 뜻입니다. 사용자가 해결할 필요가 없다고 말한다면 진짜 요구가 아닐 수 있습니다.
+
+2. **2단계: 사용자의 기존 대체 방안을 분석하고, 나의 장점 찾기**
+
+ 사용자는 지금 다른 제품, Excel, 기억력, 또는 참고 견디기를 사용하고 있을 수 있습니다. 이 방안들의 단점이 무엇인지 파악해야 합니다. 당신의 제품이 그것들보다 훨씬 좋아야 사용자가 바꿀 의향이 생깁니다.
+
+3. **3단계: 사용자가 제품에 돈을 낼 의향이 있는지 테스트하기**
+
+ 사전 판매나 예약금을 받습니다. 예약금을 낼 의향이 있는 사용자 비율을 집계합니다. 돈을 빨리 벌수록 요구가 더 맞다는 뜻입니다.
+ - 10% 초과: 요구가 진짜이며 투자할 가치가 있음
+ - 5%에서 10%: 요구는 존재하지만 다듬어야 함
+ - 5% 미만: 요구가 성립하지 않을 수 있음
+
+4. **4단계: 이 시장이 얼마나 크고 돈을 벌 수 있는지 추산하기**
+
+ 세 숫자를 계산합니다. 목표 사용자 총수 × 지불 의향 × 객단가. 곱한 뒤 시장 규모를 얻습니다. 시장이 너무 작으면 만들 가치가 없을 수 있습니다.
+
+5. **5단계: 제품에 어떤 해자가 있어 다른 사람이 베끼지 못하게 할 수 있는지 생각하기**
+
+ 기술 난이도, 네트워크 효과, 브랜드, 비용 우위 같은 장벽을 고려합니다. 이것들은 장기 경쟁력을 유지하는 데 도움을 줍니다.
+
+**이번 막 소결: 샤오밍의 수확**
+
+1. **진짜 요구의 기준**
+ - 가장 중요한 기준은 사용자가 비용을 지불할 의향이 있다는 것입니다.
+ - 사용자가 이를 위해 행동을 바꿀 의향이 있습니다.
+ - 해결 방안이 없으면 사용자가 큰 손실을 봅니다.
+
+2. **가짜 요구 피하기**
+ - 가려운 지점은 문제점이 아니며, 진짜 요구로 보면 안 됩니다.
+ - 시장이 너무 작으면 비즈니스 모델을 지탱하기 어렵습니다.
+ - 해결 방안이 문제보다 더 복잡하면 사용자는 포기합니다.
+
+3. **우선순위 정렬**
+ - 진짜 우선순위는 문제점 > 만족점 > 가려운 지점입니다.
+
+**이번 막 산출물**
+- 진짜 요구가 무엇인지 이해했습니다.
+- 요구의 세 층 분류인 문제점, 만족점, 가려운 지점을 익혔습니다.
+- 5단계 판단법으로 요구의 진위를 검증하는 법을 배웠습니다.
+
+---
+
+## 2막: 좋은 아이디어 파내기
+
+샤오밍은 이제 진짜 요구가 무엇인지 알게 되었지만, 여전히 어디에서 시작해야 할지 몰랐습니다. 허공에서 요구 하나를 상상해 낼 수는 없으니까요.
+
+그는 자신에게 가장 익숙한 것에서 시작하기로 했습니다. 주변 사람과 주변 일입니다.
+
+### 자신에서 출발하기: 샤오밍의 누나
+
+샤오밍은 누나를 떠올렸습니다. 누나는 막 아이를 낳았고, 늘 운동할 시간이 없다고 불평했습니다. 배에 붙은 살이 빠지지 않고, 전체적으로 매우 불안해했습니다.
+
+어느 날 샤오밍이 물었습니다. “지금 운동 문제는 어떻게 해결하고 있어?”
+
+누나는 한숨을 쉬며 말했습니다. “Keep 따라 하긴 하는데, 그 동작들이 산후 몸에 맞지 않아. 하고 나면 허리가 더 아파. 헬스장? 아이 봐줄 사람이 없어. 개인 트레이너? 한 수업에 300-500위안이라 너무 비싸. 혼자 대충 하자니 다칠까 봐 무서워.”
+
+샤오밍은 듣고 나서 이것이 찾고 있던 진짜 요구일지도 모른다고 느꼈습니다.
+
+누나의 어려움은 사실 매우 구체적입니다. 시간은 조각나 있고, 아기를 돌봐야 해서 운동할 온전한 시간이 없습니다. 몸에는 제한이 있습니다. 복직근 이개, 골반저근 이완 때문에 격한 운동을 할 수 없습니다. 심리적으로 매우 불안합니다. 몸매가 변했고, 남편이 싫어할까 걱정하며, 사회적으로 자신감이 떨어집니다. 정보도 너무 혼란스럽습니다. 온라인 정보가 너무 많아 어떤 운동이 산후에 맞는지 모릅니다. 또한 고립감도 있습니다. 자신의 처지를 이해해 주는 사람이 없고 동료 지원이 부족합니다.
+
+이것들은 모두 진짜 문제점입니다. “있으면 좋겠다” 수준의 가려운 지점이 아닙니다.
+
+---
+
+### 가로로 나누기: 서로 다른 사람군의 요구
+
+샤오밍은 “피트니스 APP”이라는 생각이 너무 넓다는 것을 깨달았습니다. 그는 모든 사람이 운동하도록 돕고 싶었지만, 문제는 모든 사람의 요구가 다르다는 점입니다.
+
+그는 “운동하고 싶은 사람”을 몇 가지 유형으로 가로로 나누었습니다. 자세한 방법은 부록 B에 있습니다.
+
+근육을 키우려는 사람은 단백질 섭취를 정확히 계산해야 하지만 직접 기록하기가 너무 번거롭습니다. 이들의 지불 의향은 높고 효율을 추구합니다. 당뇨병 환자는 탄수화물을 엄격히 통제해야 하지만 외식할 때 추산하기 어렵습니다. 이것은 필수 요구이며, 비용을 지불할 의향이 있고 재구매율도 높습니다. 산후 엄마는 몸매 회복을 원하지만 계산할 시간이 없고, 간단한 방안이 필요하며, 시간에 민감하고, 원스톱 서비스가 필요합니다. 배달 음식에 의존하는 사람은 매일 배달 음식을 먹으며 얼마나 많은 열량을 먹었는지 모릅니다. 고빈도 장면이지만 지불 의향은 중간입니다. 대학원 입시생은 효율적인 학습 도구가 필요하지만 무엇을 써야 할지 모릅니다. 필수 요구이지만 객단가는 낮습니다.
+
+샤오밍은 “산후 엄마”라는 사람군을 선택했습니다. 왜일까요?
+
+먼저 그는 사용자와 가까웠습니다. 누나가 산후 엄마였고, 이 집단의 문제점을 자연스럽게 이해했습니다. 둘째, 문제점이 매우 아픕니다. 산후 회복의 불안은 진짜이며, “있으면 좋다” 수준의 가려운 지점이 아닙니다. 셋째, 지불 의향이 강합니다. 엄마들은 몸매 회복을 위해 돈을 쓸 의향이 있습니다. 넷째, 경쟁이 상대적으로 치열하지 않습니다. 시장에는 산후 엄마를 전문적으로 겨냥한 제품이 많지 않습니다.
+
+::: tip 제품 관리자의 나누기 논리
+
+왜 사람군을 나누는 것이 이렇게 중요할까요?
+
+범용 도구는 이기기 어렵기 때문입니다. 대형 플랫폼은 이미 “범용” 시장을 차지했고, 기능에서 그것들을 넘어서기는 어렵습니다. 세분화된 사람군의 요구는 더 아픕니다. 산후 엄마의 운동 요구는 필수 요구이고, 일반 운동자는 “있어도 되는” 수준입니다. 작은 집단 하나를 잘 서비스하는 것이 모든 사람을 만족시키려는 것보다 입소문을 만들기 쉽습니다. 세분화된 사람군의 문제점은 더 구체적이고, 해결 방안에 비용을 지불할 의향도 더 강합니다.
+
+:::
+
+---
+
+### 세로로 깊게 파기: 완전한 사용자 장면
+
+사람군을 찾은 뒤 샤오밍은 “산후 운동”이라는 단일 기능에 머물지 않았습니다. 그는 사용자의 완전한 장면을 더 깊게 이해하고 싶었습니다. 자세한 방법은 부록 C에 있습니다.
+
+그는 누나의 하루 생활을 관찰했습니다.
+
+아침 6시, 아기가 막 잠들었고 누나는 30분의 여유가 있었습니다. 운동하고 싶었지만 아기를 깨울까 봐 걱정했고, 어떤 동작이 안전한지도 몰랐습니다.
+
+오전 10시, 누나는 아기를 안고 재우고 있었고 허리가 매우 아팠습니다. 몇 가지 회복 운동을 하고 싶었지만 손이 비어 있지 않았습니다.
+
+오후 3시, 아기가 자고 누나는 운동하고 싶었습니다. 하지만 몸이 너무 피곤했고, 아직 운동해도 되는지 몰랐습니다.
+
+밤 8시, 누나는 드디어 시간이 생겼지만 매우 불안했습니다. 거울 속의 자신을 보며 인생이 끝난 것 같다고 느끼고, 예전 사진을 넘겨 보며 몰래 울었습니다.
+
+샤오밍은 누나의 문제점이 “운동 수업이 없음”이 아니라 “산후 회복에 대한 두려움과 불안”이라는 것을 발견했습니다.
+
+---
+
+::: info 제품 관리자의 장면 사고
+
+많은 사람은 문제점이 기능 요구라고 생각하지만, 사실 그렇지 않습니다. 문제점은 장면 속의 감정과 지불 의향이 더해진 것입니다.
+
+산후 엄마가 거울 속 변한 몸매를 마주할 때, 진짜 문제점은 “어떻게 운동해야 하는지 모름”이 아닙니다. 두려움입니다. 몸이 잘 회복되지 않아 후유증이 남을까 걱정합니다. 불안입니다. 거울 속 자신을 보며 인생이 끝난 것처럼 느낍니다. 무력감입니다. 어디서부터 시작해야 할지 모르고 지도해 줄 사람도 없습니다. 고립감입니다. 다른 사람은 쉽게 출산하는 것 같은데 나만 이렇게 오래 회복해야 한다고 느낍니다.
+
+좋은 제품 설계는 기능뿐 아니라 감정을 해결해야 합니다. 감정 뒤에는 사용자의 지불 동기가 있습니다.
+
+:::
+
+---
+
+### 가치 재구성: “피트니스 APP”에서 “산후 엄마 회복 어시스턴트”로
+
+위 분석을 바탕으로 샤오밍은 이 제품을 다시 설계했습니다.
+
+::: tip 재구성된 제품 개념: “산후 엄마 회복 어시스턴트”
+
+**핵심 포지셔닝:** 단순한 피트니스 도구가 아니라 산후 엄마의 “전용 회복 코치 + 심리 지원자”
+
+**핵심 기능:**
+1. **조각 시간 훈련:**
+ - 매번 10-15분만 필요
+ - 아기가 잘 때도 운동 가능
+ - “아기를 안고도 할 수 있는” 동작 제공
+
+2. **산후 전용 수업:**
+ - 산후 단계별 분류(0-3개월, 3-6개월, 6개월 이상)
+ - 복직근 이개, 골반저근 회복을 겨냥한 전문 훈련
+ - 각 동작마다 “산후 주의사항” 안내
+
+3. **AI 동작 교정:**
+ - 휴대폰 카메라로 동작 인식
+ - “무릎이 너무 굽었어요”, “등을 곧게 펴세요” 같은 실시간 안내
+ - 잘못된 동작으로 몸을 다치는 것을 방지
+
+4. **심리 지원 커뮤니티:**
+ - 산후 엄마만 있는 비공개 커뮤니티
+ - 회복 과정을 공유하고 서로 격려
+ - 전문 심리 상담사가 입주
+
+5. **개인화 방안:**
+ - 출산 방식(자연분만/제왕절개), 몸 상태에 따라 맞춤화
+ - 수유기의 특수 요구 고려
+
+**비즈니스 모델:**
+- 기본 수업 무료
+- 고급 수업: 월 99위안(AI 동작 교정, 전용 방안 포함)
+- 1:1 개인 코칭: 월 299위안(온라인 지도)
+- 커뮤니티 회원: 연 199위안(심리 지원, 전문가 Q&A 포함)
+
+**경쟁 장벽:**
+- 전문성: 산후 회복 기관과 협력하고 의학적 근거를 갖춤
+- 커뮤니티 점착성: 산후 엄마의 감정 연결이 강함
+- 데이터 축적: 사용자 신체 데이터가 많을수록 방안이 더 정확해짐
+
+**시장 규모:**
+- 중국의 연간 신생아 약 1,000만 명
+- 산후 회복 시장 약 500억 위안
+- 목표: 산후 엄마의 1% 서비스 = 사용자 10만 명
+- ARPU(사용자당 평균 매출): 연 500위안
+- 잠재 매출: 연 5,000만 위안
+
+:::
+
+원래 idea와 재구성 후 개념을 비교해 봅니다.
+
+| 차원 | 원래 생각 | 재구성 후 |
+|------|---------|--------|
+| 목표 사용자 | 모든 운동 인구(크고 넓음) | 산후 엄마(정확함) |
+| 해결 문제점 | 훈련 기록(가려운 지점) | 산후 회복 불안(문제점) |
+| 경쟁 장벽 | 기술(복제 쉬움) | 전문성 + 커뮤니티 + 데이터 |
+| 지불 의향 | 낮음(무료 대체재 많음) | 높음(필수 요구 + 감정 가치) |
+| 확장 공간 | 제한적 | 임신기, 임신 준비기로 확장 가능 |
+
+**이것이 “하나의 기능”에서 “누군가 비용을 지불할 제품”으로 진화하는 과정입니다.**
+
+---
+
+### 더 많은 예시: 평범한 idea에서 좋은 아이디어까지
+
+샤오밍은 이 방법이 매우 유용하다고 느꼈습니다. 그는 같은 방법으로 몇 가지 다른 예시도 분석해 보며 이 방법이 일반적으로 통하는지 확인했습니다. 자세한 사례는 부록 D에 있습니다.
+
+#### 예시 1: “칼로리 측정”에서 “당뇨인이 안심하고 먹기”까지
+
+평범한 생각은 사진으로 음식 열량을 인식해 다이어트하는 사람이 식단을 통제하도록 돕는 것입니다. 하지만 문제는 이미 Bohe Health, MyFitnessPal 같은 성숙한 제품이 있다는 점입니다.
+
+샤오밍은 가로로 나눠 보다가 당뇨병 환자라는 사람군이 흥미롭다는 것을 발견했습니다. 이들은 탄수화물을 엄격히 통제해야 하지만 외식할 때 추산하기가 어렵습니다. 이들의 장면을 세로로 깊게 파 보면, 식사 전에는 이 음식을 먹어도 되는지 몰라 혈당이 급상승할까 걱정하고, 식사 중에는 “이미 탄수화물을 얼마나 먹었는지” 실시간으로 안내받아야 하며, 식사 후에는 혈당 변화를 기록해 식단과의 관계를 봐야 합니다.
+
+재구성된 제품은 “당뇨인이 안심하고 먹기”이고, 포지셔닝은 당뇨병 환자의 “식단 안전 어시스턴트”입니다.
+
+---
+
+#### 예시 2: “뉴스 어시스턴트”에서 “투자 리서치 정보관”까지
+
+평범한 생각은 여러 플랫폼의 뉴스를 모아 하나씩 열 필요를 없애는 것입니다. 하지만 Toutiao, Tencent News 등은 이미 잘하고 있습니다.
+
+샤오밍은 가로로 나눈 뒤 금융 애널리스트라는 사람군에게 특수 요구가 있음을 발견했습니다. 이들은 특정 산업 동향을 추적해야 하지만 정보가 너무 흩어져 있습니다. 이들의 장면을 세로로 깊게 파 보면, 아침에는 overnight 미국 주식 동향과 환율 변화를 보고, 오전에는 보유 회사의 공시와 산업 뉴스를 추적하며, 오후에는 잠재 투자 대상을 연구하기 위해 많은 산업 정보를 필요로 합니다.
+
+재구성된 제품은 “투자 리서치 정보관”이고, 포지셔닝은 금융 종사자의 “정보 레이더와 의사결정 어시스턴트”입니다.
+
+---
+
+#### 예시 3: “캠퍼스 중고 플랫폼”에서 “졸업 정리 어시스턴트”까지
+
+평범한 생각은 캠퍼스 중고 거래 플랫폼입니다. 하지만 Xianyu, Zhuanzhuan은 이미 잘하고 있습니다.
+
+샤오밍은 가로로 나눈 뒤 졸업생이라는 사람군에게 특수 요구가 있음을 발견했습니다. 물건이 너무 많아 하나씩 팔기 너무 번거롭습니다. 이들의 장면을 세로로 깊게 파 보면, 졸업 전 일주일 안에 학교를 떠나야 해서 천천히 팔 시간이 없고, 누가 내 물건을 필요로 하는지도 모르며, 가격 흥정, 전달, 수금이 너무 번거롭습니다.
+
+재구성된 제품은 “졸업 정리 어시스턴트”이고, 포지셔닝은 졸업생의 “퇴교 자산 매니저”입니다.
+
+---
+
+### 이번 막 소결: 샤오밍의 수확
+
+2막을 통해 샤오밍은 다음을 이해했습니다.
+
+**1. 자신에서 출발하기**
+- 당신 자신이 사용자라면, 그 집단의 문제점을 자연스럽게 이해합니다.
+- 취미는 가장 좋은 출발점이고, 열정은 가장 좋은 동력입니다.
+
+**2. 사람군을 가로로 나누기**
+- “모든 사람”을 서비스하려 하지 말고, “가장 아픈 사람군”을 찾습니다.
+- 더 세분화할수록 더 많은 기회가 있고, 사용자의 지불 의향도 더 강합니다.
+
+**3. 장면을 세로로 깊게 파기**
+- 사용자의 완전한 여정을 설명합니다. 사용 전, 사용 중, 사용 후.
+- 감정 접점을 찾습니다. 두려움, 불안, 무력감, 고립감...
+
+**4. 가치 재구성**
+- “기능”에서 “해결 방안”으로 업그레이드합니다.
+- “도구”에서 “어시스턴트 / 매니저 / 파트너”로 업그레이드합니다.
+
+---
+
+📦 **이번 막 산출물:**
+- 정확한 목표 사용자(산후 엄마)를 찾았습니다.
+- 사용자의 완전한 장면과 진짜 감정을 이해했습니다.
+- 제품 개념을 재구성했고, 명확한 차별화 포지셔닝을 갖게 되었습니다.
+
+---
+
+## 3막: AI 대화로 다듬기
+
+샤오밍은 이제 명확한 제품 방향을 갖게 되었습니다. 산후 엄마 회복 어시스턴트입니다. 하지만 여전히 구체적으로 어떻게 만들지, 어디서 시작할지, 기술 구현 난이도가 얼마나 될지 몰랐습니다.
+
+그는 AI를 사용해 제품 개념을 다듬고, 생각을 실행 가능한 계획으로 바꾸기로 했습니다.
+
+### 첫 번째 라운드: 원래 생각 던지기
+
+샤오밍은 자신의 생각을 AI에게 말했습니다. “산후 엄마 회복 어시스턴트 APP을 만들고 싶어. 산후 엄마가 몸매를 회복하도록 도와주는 앱이야. 그런데 기술 구현 난이도가 걱정돼. 특히 AI 동작 교정 기능은 혼자 할 수 있을까?”
+
+---
+
+### 두 번째 라운드: AI가 MVP 계획을 돕기
+
+AI가 답했습니다. “좋은 질문입니다! MVP(최소 기능 제품) 계획을 해 봅시다.”
+
+AI는 세 단계로 나누어 만들 것을 제안했습니다. 첫 번째 단계는 1-2개월이며 목표는 요구 검증입니다. APP을 만들지 말고 먼저 WeChat 미니프로그램을 만들고, 산후 전용 수업(영상)과 체크인 커뮤니티만 제공합니다. 동작 지도는 사람이 제공합니다. 사용자가 영상을 업로드하면 코치가 답변합니다. 목표는 산후 엄마가 비용을 지불할 의향이 있는지 검증하는 것입니다.
+
+두 번째 단계는 3-6개월입니다. 첫 단계가 성공적으로 검증되면 핵심 기능을 추가합니다. AI 동작 교정을 개발하며, Baidu 인체 인식 같은 기존 SDK를 사용할 수 있습니다. 개인화 방안을 추가하고 커뮤니티 기능을 최적화합니다.
+
+세 번째 단계는 6-12개월이며 규모화입니다. 독립 APP을 개발하고, 산후 회복 기관과 협력하며, 임신기와 임신 준비기로 확장합니다.
+
+기술 구현에 대해서 AI는 AI 동작 교정에 Baidu, Tencent의 API 같은 기존 AI 능력을 사용하라고 제안했습니다. 처음부터 개발할 필요가 없어서 비용을 낮출 수 있습니다. 초기에는 사람 + AI 혼합 모드를 사용하고, 점차 전환합니다.
+
+시작 비용 측면에서 미니프로그램 개발은 1-2만 위안(외주) 또는 AI IDE로 직접 만들 수 있습니다. 콘텐츠 제작은 산후 회복 코치와 협력하고, 홍보는 엄마 커뮤니티와 샤오홍슈에서 시작합니다.
+
+검증 지표는 첫 달 사용자 100명, 10% 유료 전환율입니다. 도달하면 요구가 진짜라는 뜻이므로 계속 투자합니다. 도달하지 못하면 방향을 즉시 조정합니다.
+
+---
+
+### 세 번째 라운드: 샤오밍이 걱정을 제기하기
+
+샤오밍은 생각한 뒤 다시 물었습니다. “콘텐츠 제작이 걱정돼. 산후 회복 수업은 전문 지도가 필요한데, 나는 의학 배경이 없어. 수업 품질을 어떻게 보장하지?”
+
+---
+
+### 네 번째 라운드: AI가 해결 방안을 제시하기
+
+AI가 답했습니다. “이것은 많은 기술형 창업자가 걱정하는 부분이지만 해결 방안이 있습니다.”
+
+방안 1은 전문가와 협력하는 것입니다. 산후 회복 코치나 병원 영양과 의사와 협력합니다. 당신은 기술과 제품을 제공하고, 그들은 전문 콘텐츠를 제공합니다. 수익 배분 방식을 사용할 수 있습니다.
+
+방안 2는 기존 고품질 콘텐츠를 통합하는 것입니다. 초기에는 YouTube나 Bilibili의 공개 산후 회복 영상 같은 것을 사용할 수 있습니다. 직접 콘텐츠 검토와 정리를 하고, 이후에 오리지널 콘텐츠를 제작합니다.
+
+방안 3은 사용자 생성 콘텐츠입니다. 경험 있는 엄마들이 자신의 회복 방법을 공유하도록 장려하고, 커뮤니티 투표 방식으로 고품질 콘텐츠를 선별하며, 점차 콘텐츠 생태계를 구축합니다.
+
+AI는 먼저 방안 1을 사용하라고 제안했습니다. 구체적인 조작은 다음입니다. 산후 회복 코치 2-3명을 찾아 협력 논의를 합니다. 당신은 제품을 개발하고, 그들은 수업을 제공합니다. 수익은 분배합니다. 당신이 70%, 그들이 30%를 가져갑니다. 이렇게 하면 콘텐츠 품질을 보장하면서 비용도 낮출 수 있습니다. 초기 수업 제작 비용은 0위안입니다. 수익 배분 방식을 쓰면 개발 시간과 홍보 비용만 투입하면 됩니다.
+
+**나의 제안: 먼저 방안 1 사용하기**
+
+구체적인 조작:
+1. 산후 회복 코치 2-3명을 찾기
+2. 협력 논의하기: 당신은 제품을 개발하고, 그들은 수업을 제공
+3. 수익 배분: 당신 70%, 코치 30%
+4. 이렇게 하면 콘텐츠 품질을 보장하면서 비용도 낮출 수 있음
+
+**초기 비용:**
+- 수업 제작: 0위안(수익 배분 방식 사용)
+- 당신은 개발 시간과 홍보 비용만 투입하면 됨
+
+:::
+
+---
+
+### 다섯 번째 라운드: 샤오밍이 홍보 문제를 묻기
+
+샤오밍에게는 마지막 걱정이 남았습니다. “홍보 비용이 높지 않을까? 산후 엄마라는 집단을 어떻게 찾지?”
+
+---
+
+### 여섯 번째 라운드: AI가 홍보 전략을 제공하기
+
+AI가 답했습니다. “산후 엄마라는 집단은 사실 찾기 매우 쉽고, 홍보 비용도 낮출 수 있습니다.”
+
+가장 추천하는 것은 샤오홍슈입니다. “산후 회복”, “복직근 이개” 같은 키워드를 검색해 관련 블로거를 찾고, 개인 메시지로 협력합니다. “1개월 무료 체험” 방식으로 홍보를 교환하면 비용은 거의 0입니다.
+
+그다음은 엄마 커뮤니티입니다. WeChat 그룹, QQ 그룹을 검색하고 “산후 회복 경험 공유”라는 명목으로 들어갑니다. 직접 광고하지 말고 실용적인 콘텐츠를 공유하며 신뢰를 점차 쌓습니다.
+
+또한 병원 산부인과와 협력해 무료 산후 회복 지도를 제공하고 병원에서 홍보 전단을 배포할 수 있습니다. 비용은 인쇄비 몇백 위안입니다. 또는 모자용품점과 협력해 홍보물을 배치하고, 모자용품 구매 시 체험 카드를 증정할 수 있습니다. 비용은 체험 카드 제작비입니다.
+
+검증 지표는 다음입니다. 첫 달 사용자 100명, 유료 사용자 10명(10% 전환율), 총 홍보 비용 1,000위안 미만, 고객 획득 비용 1인당 10위안 미만. 이 지표에 도달하면 요구가 진짜라는 뜻이며 계속 투자할 수 있습니다.
+
+---
+
+### 최종: 샤오밍에게 명확한 계획이 생기다
+
+6번의 대화 후 샤오밍은 마침내 명확한 계획을 갖게 되었습니다.
+
+첫 번째 단계는 1-2개월입니다. WeChat 미니프로그램을 만들고, 산후 회복 코치 2-3명과 협력합니다(수익 배분 방식). 산후 전용 수업(영상)과 체크인 커뮤니티만 제공하고, 동작 지도는 사람이 제공합니다. 목표는 사용자 100명과 10% 유료 전환율입니다.
+
+두 번째 단계는 3-6개월입니다. 첫 단계 검증이 성공하면 계속 투자합니다. AI 동작 교정 기능을 추가하고, 개인화 방안을 추가하며, 커뮤니티 기능을 최적화합니다.
+
+세 번째 단계는 6-12개월입니다. 독립 APP을 개발하고, 산후 회복 기관과 협력하며, 임신기와 임신 준비기로 확장합니다.
+
+시작 비용은 매우 낮습니다. 개발은 AI IDE로 직접 합니다(0위안). 콘텐츠는 코치와 수익을 나눕니다(초기 0위안). 홍보는 샤오홍슈와 엄마 커뮤니티를 사용합니다(1,000위안 미만). 총 비용은 1,000위안 미만입니다.
+
+---
+
+### AI 대화로 다듬는 5단계 방법
+
+이 사례를 통해 샤오밍은 AI와 대화하는 표준 흐름을 정리했습니다. 자세한 내용은 부록 E에 있습니다.
+
+**1단계: 원래 생각 던지기.** 초기 생각을 설명합니다. 거칠어도 괜찮습니다. 경쟁이 치열하다거나 차별화 방법을 모르겠다는 걱정도 AI에게 말합니다.
+
+**2단계: AI에게 MVP 계획을 도와달라고 하기.** 최소 기능 제품은 어떤 기능을 포함해야 할까요? 몇 단계로 나눌까요? 각 단계의 목표는 무엇일까요? 기술 구현 난이도는 높은가요?
+
+**3단계: 걱정 제기하기.** 기술 구현 난이도, 콘텐츠 제작 비용, 홍보 비용, 사용자 획득 난이도 등 걱정을 모두 AI에게 말합니다.
+
+**4단계: AI에게 해결 방안을 요청하기.** 당신의 걱정에 대해 AI가 구체적인 제안을 줍니다. 여러 방안을 비교하고 최적안을 선택합니다. 비용도 추산합니다.
+
+**5단계: 최종 계획 확인하기.** 명확한 실행 계획을 정리하고 검증 지표를 설정합니다. 도달하지 못하면 즉시 방향을 조정합니다.
+
+**프롬프트 템플릿:**
+```
+[제품 개념]을 만들고 싶습니다.
+하지만 [나의 걱정]이 걱정됩니다.
+다음을 도와주세요:
+1. MVP를 계획하기
+2. 구체적인 기술 구현 제안 제시하기
+3. 비용 추산하기
+4. 검증 지표 설정하기
```
-좋은 예:
+---
-```text
-대학생이 팀플 회의록을 붙여 넣으면,
-할 일 담당자와 마감일을 자동으로 정리해 주는 웹 앱을 만들고 싶다.
+### 이번 막 소결: 샤오밍의 수확
+
+3막을 통해 샤오밍은 세 가지를 이해했습니다.
+
+**첫째, AI 대화로 제품 개념을 다듬기.** 한 번의 대화로 완벽한 답을 기대하지 말고 여러 라운드로 반복합니다. 당신의 관찰, 경험, 주변 사람의 피드백을 AI에게 알려 줍니다. AI의 제안이 합리적이지 않다면 즉시 지적합니다. 마지막에는 반드시 구체적인 실행 계획으로 내려와야 합니다.
+
+**둘째, MVP의 핵심 원칙.** 최소화합니다. 가장 핵심 기능만 만듭니다. 검증 가능해야 합니다. 요구가 진짜인지 빠르게 검증할 수 있어야 합니다. 낮은 비용으로 검증합니다.
+
+**셋째, 검증 지표.** 유료 전환율이 10%보다 크면 요구가 진짜이며 투자할 가치가 있습니다. 유료 전환율이 5-10%이면 요구는 존재하지만 다듬어야 합니다. 유료 전환율이 5%보다 낮으면 요구가 성립하지 않으므로 즉시 조정해야 합니다.
+
+---
+
+📦 **이번 장 산출물:**
+- 명확한 MVP 계획이 생겼습니다.
+- 기술 구현 경로를 알게 되었습니다.
+- 검증 지표를 설정했습니다.
+
+---
+
+## 종장: 당신의 행동
+
+### 기억 공식
+
+**한 사람 한 일 한 진입점, 가로로 나누고 세로로 파서 문제점을 찾고, AI 대화로 개념을 다듬고, 5단계 검증 후 시작하라**
+
+**설명:**
+- **한 사람:** 당신 자신에서 출발합니다. 당신은 그 집단을 자연스럽게 이해합니다.
+- **한 일:** 하나의 구체적인 일에 집중합니다. 욕심내지 않습니다.
+- **한 진입점:** 진입점을 찾습니다. 더 세분화할수록 좋습니다.
+- **가로 나누기:** 사람군을 가로로 나누어 지불 의향이 가장 강한 사용자를 찾습니다.
+- **세로 파기:** 장면을 세로로 깊게 파서 사용자의 완전한 여정을 이해합니다.
+- **AI 대화:** AI 대화로 제품 개념을 다듬습니다.
+- **5단계 검증:** 5단계 판단법으로 요구의 진위를 검증합니다.
+
+---
+
+### 과후 연습
+
+일상생활의 작은 불편 하나를 선택하고, 이번 장의 방법으로 확장해 보세요.
+
+::: tip 연습 과제
+
+**1. 이 불편을 설명하기**(1문장)
+- 예: “사용자의 소비를 기록하는 가계부 APP을 만들고 싶다”
+
+**2. 가로 나누기: 서로 다른 요구를 가질 수 있는 사람군 3개 찾기**
+- 예: 소상공인, 유학생 부모, 프리랜서
+
+**3. 사람군 하나를 선택하고 세로로 깊게 파기: 그들의 완전한 장면과 진짜 감정 설명하기**
+- 예: 유학생 부모의 장면 - 아이가 해외에서 돈을 얼마나 쓰는지 알고 싶지만 아이가 말하지 않음
+
+**4. 제품 개념 재구성: “하나의 기능”에서 “하나의 해결 방안”으로 진화시키기**
+- 예: “유학 자금 매니저” - 단순 가계부가 아니라 부모가 아이의 해외 소비를 “마음속으로 파악”하게 해 주는 것
+
+**5. 검증 체크리스트로 아이디어 평가하기**(부록 F 참고)
+
+**분석을 커뮤니티에 공유하고 다른 학습자와 토론하세요!**
+
+:::
+
+---
+
+## 부록: SOP 방법론
+
+### 부록 A: 요구 분석의 5단계 판단법
+
+아이디어가 하나 있을 때, 이것이 투자할 가치가 있는지 어떻게 빠르게 판단할 수 있을까요?
+
+**1단계: 사용자 검증 - 목표 사용자 10명 찾기**
+
+**묻지 말아야 할 질문:** “내 제품을 사용할 건가요?”(거짓 양성률 90%)
+
+**물어야 할 질문:**
+1. “지금은 이 문제를 어떻게 해결하고 있나요?”(진짜 행동 이해)
+2. “최근 일주일 동안 이 문제가 몇 번이나 당신을 괴롭혔나요?”(빈도 이해)
+3. “이를 해결하기 위해 돈/시간을 얼마나 썼나요?”(지불 의향 이해)
+4. “해결 방안이 있지만 습관을 바꿔야 한다면, 의향이 있나요?”(변화 비용 이해)
+
+**판단 기준:**
+- 3명 이상의 사용자가 “매일 이 일 때문에 골치 아파요”라고 말하면 문제점일 수 있습니다.
+- 사용자가 “꽤 흥미롭지만 급하지는 않아요”라고 말하면 대부분 가려운 지점입니다.
+- 사용자가 “지금 XX로 해결하고 있는데 만족스럽지 않아요”라고 말하면 기회가 있습니다.
+
+**핵심 질문:** 사용자는 지금 어떤 방법으로 이 문제를 해결하고 있나요?
+
+| 대체 방안 유형 | 설명 | 기회 판단 |
+|------------|------|---------|
+| **대체 방안 없음** | 사용자가 조용히 참고 있음 | 큰 기회이지만 시장 교육 필요 |
+| **매우 둔한 방법 사용** | Excel, 수작업, 여러 사람 협업 | 좋은 기회. 사용자가 더 나은 방안을 갈망함 |
+| **여러 도구를 조합 사용** | A도구 + B도구 + C도구 | 좋은 기회. 통합에 가치가 있음 |
+| **성숙한 제품 사용** | 하지만 사용자가 만족하지 않음 | 기회가 있지만 차별화 필요 |
+| **성숙한 제품 사용** | 사용자가 매우 만족함 | 기회가 작음. 파괴적 혁신이 아니면 어려움 |
+
+::: tip “파괴적 혁신”이란 무엇인가?
+
+**간단한 정의:** 제품을 더 좋게 만드는 것이 아니라, 더 단순하거나 저렴한 방식으로 이전에 무시되던 사용자 집단을 서비스하는 것입니다.
+
+**예시:**
+- 전통 휴대폰 → 스마트폰(기능이 더 많은 것이 아니라 상호작용 방식이 완전히 다름)
+- 전통 택시 → Didi(차가 더 좋은 것이 아니라 언제 어디서나 차량 호출이 가능해짐)
+- 전통 서점 → 전자책(책이 더 많은 것이 아니라 휴대와 구매가 더 편해짐)
+
+**핵심:** 파괴적 혁신은 보통 “저가 시장” 또는 “새 사용자 집단”에서 시작해 점차 위쪽으로 잠식합니다.
+
+:::
+
+**사례:**
+- 당뇨병 환자가 지금 “경험 + 추측”으로 식단을 통제함(매우 둔한 방법) - 기회 큼
+- 일반 다이어터가 Bohe Health를 사용함(성숙한 제품, 만족도 중간) - 세분화 기회 있음
+- 학생이 WeChat 그룹으로 중고 거래를 함(여러 도구 조합) - 통합 기회 있음
+
+**가장 효과적인 방법: 사전 판매 또는 예약금**
+
+**조작 단계:**
+1. 간단한 랜딩 페이지를 만들어 제품 개념을 설명합니다.
+2. “사전 판매” 또는 “예약” 버튼을 놓습니다.
+3. 몇 명이 비용을 지불하려 하는지 봅니다. 1위안이어도 됩니다.
+
+**판단 기준:**
+- 예약금을 내는 사용자 > 10%: 요구가 진짜이며 만들 가치가 있음
+- 예약금을 내는 사용자 5-10%: 요구는 존재하지만 다듬어야 함
+- 예약금을 내는 사용자 < 5%: 요구가 성립하지 않거나 제품 개념에 문제가 있음
+
+**주의:** “살게요”라고 말하는 사람은 많습니다. 실제로 돈을 내는 사람만이 목표 사용자입니다.
+
+**간단 공식:**
+```
+잠재 시장 규모 = 목표 사용자 수 × 지불 의향 × 객단가
```
-좋은 아이디어 문장은 다음 요소를 포함합니다.
+**사례: 캠퍼스 중고 거래 플랫폼**
+- 목표 사용자: 전국 대학생 4,000만 명
+- 중고 거래 요구가 있는 사람: 50% = 2,000만 명
+- 플랫폼을 사용할 의향이 있는 사람: 10% = 200만 명
+- 연간 거래 빈도: 2회
+- 플랫폼 수수료: 5%
+- 평균 객단가: 100위안
+- 잠재 시장 규모 = 200만 × 2 × 100 × 5% = 연 2,000만 위안
-```text
-[누가] [어떤 상황에서] [무엇을 넣으면] [어떤 결과를 얻는다]
+**판단 기준:**
+- 시장 규모 > 10억 위안: 큰 트랙, 만들 가치 있음
+- 시장 규모 1-10억 위안: 중소 트랙, 만들 수 있지만 상한이 뚜렷함
+- 시장 규모 < 1억 위안: 니치 시장, 부업 또는 작지만 아름다운 제품에 적합
+
+**핵심 질문:** 제품이 성공하면 다른 사람이 베끼면 어떻게 할까요?
+
+**흔한 해자 유형:**
+
+| 해자 유형 | 설명 | 예시 |
+|-----------|------|------|
+| **네트워크 효과** | 사용자가 많을수록 제품 가치가 커짐 | WeChat, Didi |
+| **데이터 축적** | 데이터가 많을수록 알고리즘이 정확해짐 | Toutiao, Douyin |
+| **브랜드 인식** | 사용자 마음속 점유 | Coca-Cola, Nike |
+| **규모 효과** | 규모가 클수록 비용이 낮아짐 | JD Logistics, Amazon |
+| **기술 특허** | 핵심 기술 장벽 | Huawei, DJI |
+| **전환 비용** | 사용자 이전 비용이 높음 | 기업 소프트웨어, 운영체제 |
+
+**초기 프로젝트의 현실:**
+- 대부분 초기 프로젝트에는 뚜렷한 해자가 없습니다.
+- 하지만 괜찮습니다. 핵심은 빨리 달리는 것입니다.
+- 먼저 시장을 점유하고, 그다음 장벽을 세웁니다.
+
+---
+
+### 부록 B: 사람군을 가로로 나누는 방법
+
+“모든 XX 사용자”를 서비스하려 하지 말고, 특정 사람군 하나를 찾으세요. 그들의 요구가 더 아프고 더 구체적입니다.
+
+**1단계: 가능한 모든 세분 사람군 나열하기**
+
+제품 개념을 대상으로 가능한 모든 사람군을 나열합니다.
+
+**2단계: 각 사람군의 비즈니스 가치 평가하기**
+
+| 평가 차원 | 설명 |
+|---------|------|
+| 문제점 강도 | 이 사람군의 요구는 문제점인가, 가려운 지점인가? |
+| 지불 의향 | 해결 방안에 얼마를 낼 의향이 있는가? |
+| 시장 규모 | 이 사람군은 몇 명인가? |
+| 경쟁 정도 | 기존 해결 방안은 만족스러운가? |
+| 사람군에 대한 이해 | 당신은 이 사람군을 이해하는가? 접촉 채널이 있는가? |
+
+**3단계: 사람군 하나를 선택해 깊게 분석하기**
+
+다음 조건에 맞는 사람군을 선택합니다.
+- 문제점이 가장 아픔
+- 지불 의향이 가장 강함
+- 당신이 가장 잘 이해함
+- 경쟁이 상대적으로 치열하지 않음
+
+::: tip 나누기 예시
+
+**제품 개념:** 가계부 APP
+
+| 세분 사람군 | 문제점 | 지불 의향 | 시장 규모 | 경쟁 정도 |
+|---------|------|---------|---------|---------|
+| 일반 직장인 | 기록이 번거로움 | 낮음 | 큼 | 높음 |
+| 소상공인 | 개인/회사 지출이 섞임 | 높음 | 중간 | 중간 |
+| 프리랜서 | 수입이 불안정하고 현금흐름 예측 필요 | 높음 | 중간 | 중간 |
+| 유학생 부모 | 아이가 돈을 얼마나 쓰는지 알고 싶지만 아이가 말하지 않음 | 높음 | 작음 | 낮음 |
+
+**선택:** 유학생 부모(문제점이 가장 아프고, 지불 의향이 높으며, 경쟁이 상대적으로 낮음)
+
+:::
+
+---
+
+### 부록 C: 장면을 세로로 깊게 파는 방법
+
+사람군을 찾은 뒤 단일 기능에 머무르지 말고 사용자의 완전한 장면을 이해해야 합니다.
+
+**1단계: 사용자의 하루 설명하기**
+
+아침부터 밤까지, 사용자가 제품을 사용할 때의 완전한 장면을 설명합니다.
+
+**2단계: 각 장면의 문제점 분석하기**
+
+각 장면에서 사용자는 어떤 문제를 만났나요? 어떤 감정이 있나요?
+
+**3단계: 감정 접점 찾기**
+
+두려움, 불안, 무력감, 고립감, 분노, 후회...
+
+**4단계: 가치 재구성하기**
+
+장면과 감정을 바탕으로 제품 가치를 재구성합니다.
+
+::: tip 깊게 파기 예시
+
+**사람군:** 산후 엄마
+
+| 시간 | 장면 | 문제점 | 감정 |
+|------|------|------|------|
+| 아침 6시 | 아기가 막 잠들었고 30분 여유가 있음 | 어떤 동작이 안전한지 모름 | 두려움 |
+| 오전 10시 | 아기를 안고 재우며 허리가 매우 아픔 | 손이 비어 있지 않고 회복 운동을 하고 싶음 | 불안 |
+| 오후 3시 | 아기가 자고 운동하고 싶음 | 몸이 매우 피곤하고 아직 해도 되는지 모름 | 무력감 |
+| 밤 8시 | 드디어 시간이 생김 | 거울 속 자신을 보며 인생이 끝났다고 느낌 | 우울 |
+| 장기 | 이해해 주는 사람이 없음 | 나만 이렇게 고통스럽다고 느낌 | 고립감 |
+
+**가치 재구성:** “피트니스 도구”에서 “회복 코치 + 심리 지원자”로 업그레이드
+
+:::
+
+---
+
+### 부록 D: 평범한 idea에서 좋은 아이디어로 바뀌는 더 많은 예시
+
+#### 예시 1: “가계부 APP”에서 “유학 자금 매니저”까지
+
+**평범한 생각:** 자동 가계부 APP. 은행카드를 연결해 소비를 자동 분류합니다.
+
+**문제:** 시장에는 이미 Suishouji, Wacai, Alipay 청구서 등이 있습니다.
+
+**가로 나누기:**
+- 유학생 부모: 아이가 외국에서 돈을 얼마나 쓰고, 초과 지출하는지 알고 싶음
+
+**세로 깊게 파기:**
+- 문제점은 “가계부”가 아니라 “통제감을 잃은 느낌”입니다. 아이가 얼마를 쓰는지 모르고, 어디에 쓰는지도 모릅니다.
+- 장면: 매달 신용카드 청구서를 보지만 아이는 무엇에 썼는지 절대 먼저 말하지 않습니다.
+
+**재구성 후:** “유학 자금 매니저” - 단순 가계부가 아니라 부모가 아이의 해외 소비를 “마음속으로 파악”하게 하는 것
+
+**핵심 기능:**
+- 자녀 소비 실시간 동기화
+- 초과 지출 경고
+- 월별 소비 분석 보고서
+- 같은 유형 학생 소비 비교(“당신의 아이는 평균보다 20% 더 썼습니다”)
+
+---
+
+#### 예시 2: “뽀모도로 도구”에서 “원격근무 증명”까지
+
+**평범한 생각:** 사용자가 집중해 일하도록 돕는 뽀모도로 APP.
+
+**문제:** 휴대폰 기본 화면 사용 시간, Forest, Tomato ToDo 등이 있습니다.
+
+**가로 나누기:**
+- 원격근무자: 상사에게 “내가 정말 일하고 있다”는 것을 증명해야 함
+
+**세로 깊게 파기:**
+- 문제점은 “집중하지 못함”이 아니라 “신뢰 위기”입니다. 상사는 나를 볼 수 없는데 어떻게 내가 일하고 있다는 것을 증명할까요?
+- 장면: 매일 퇴근할 때 상사가 “오늘 일은 어땠나요?”라고 묻지만 증명할 방법이 없습니다.
+
+**재구성 후:** “원격근무 증명” - 원격근무자가 고용주와의 신뢰를 구축하도록 돕기
+
+**핵심 기능:**
+- 자동 근무 시간 추적
+- 생산성 보고서
+- 화면 활동 요약(프라이버시 보호 버전)
+- 매일 자동으로 “업무 보고서”를 생성해 상사에게 전송
+
+---
+
+#### 예시 3: “중고책 거래”에서 “그림책 도서관”까지
+
+**평범한 생각:** 중고책 거래 플랫폼.
+
+**문제:** Duozhuayu, Xianshu, Kongfz 같은 중고책 사이트가 있습니다.
+
+**가로 나누기:**
+- 엄마 집단: 아이가 그림책을 다 보면 방치되지만 새 책은 비쌈
+
+**세로 깊게 파기:**
+- 문제점은 “책이 비쌈”이 아니라 “그림책 생명주기가 짧음”입니다. 아이가 3살에 본 책을 4살에는 보지 않습니다.
+- 장면: 집에는 그림책이 가득 쌓였고, 아이는 더 이상 보지 않지만 버리기 아깝습니다.
+
+**재구성 후:** “집으로 오는 그림책 도서관” - 중고책 판매가 아니라 그림책의 “사용권 대여” 제공
+
+**핵심 기능:**
+- 그림책 구독제(매달 연령에 맞는 그림책 5권 배송, 다 읽으면 반납하고 새 책으로 교환)
+- 읽기 진행 추적
+- 연령별 추천
+- 소독 보장
+
+---
+
+### 부록 E: AI 대화로 제품 개념을 다듬는 5단계 방법
+
+여러 라운드의 AI 대화를 통해 평범한 idea를 점차 실행 가능한 정확한 제품 개념으로 다듬습니다.
+
+**조작:**
+- 초기 생각을 설명합니다. 거칠어도 괜찮습니다.
+- AI에게 당신의 걱정을 말합니다. 경쟁이 치열하다, 차별화 방법을 모르겠다 등.
+
+**프롬프트:**
+```
+[제품 개념]을 만들고 싶습니다.
+하지만 [문제/걱정]을 발견했습니다.
```
-예시:
+**조작:**
+- AI에게 최소 기능 제품 계획을 세우게 합니다.
+- 기술 구현 난이도와 비용을 논의합니다.
+- 검증 지표를 설정합니다.
-- 신입 마케터가 광고 문안을 입력하면, 여러 톤의 SNS 문구를 생성한다.
-- 교사가 단원명을 입력하면, 객관식 퀴즈 10개와 해설을 만든다.
-- 자취생이 냉장고 재료를 입력하면, 15분 안에 만들 수 있는 메뉴를 추천한다.
-
-## 4. 처음 만들기 좋은 유형
-
-### 4.1 생성형 도구
-
-입력값을 받아 글, 이미지 설명, 요약, 기획안, 이메일 등을 만들어 줍니다.
-
-예시:
-
-- 자기소개서 문장 다듬기
-- SNS 게시글 생성기
-- 수업 퀴즈 생성기
-- 상품 상세페이지 문구 생성기
-
-### 4.2 정리형 도구
-
-긴 텍스트나 흩어진 정보를 구조화합니다.
-
-예시:
-
-- 회의록에서 할 일 추출
-- 고객 리뷰 분류
-- 긴 문서 요약
-- 인터뷰 메모 정리
-
-### 4.3 추천형 도구
-
-사용자의 조건을 받아 후보를 추천합니다.
-
-예시:
-
-- 여행 코스 추천
-- 점심 메뉴 추천
-- 공부 계획 추천
-- 운동 루틴 추천
-
-### 4.4 변환형 도구
-
-한 형식의 내용을 다른 형식으로 바꿉니다.
-
-예시:
-
-- 블로그 글을 숏폼 대본으로 변환
-- 긴 설명을 발표 슬라이드 목차로 변환
-- 제품 요구사항을 개발 티켓으로 변환
-
-## 5. 피해야 할 첫 아이디어
-
-처음부터 다음 유형을 고르면 난이도가 급격히 올라갑니다.
-
-- 완전한 SNS
-- 결제와 정산이 필요한 마켓플레이스
-- 실시간 채팅 서비스
-- 대규모 추천 시스템
-- 의료, 법률, 금융 판단을 대신하는 서비스
-- 여러 권한과 복잡한 관리자 시스템이 필요한 서비스
-
-이런 아이디어도 나중에는 만들 수 있습니다. 하지만 첫 프로젝트에서는 "한 사람이 한 상황에서 얻는 하나의 가치"에 집중하는 편이 좋습니다.
-
-## 6. 10분 검증법
-
-아이디어를 고른 뒤 바로 만들지 말고 10분만 검증합니다.
-
-1. 대상 사용자를 한 문장으로 쓴다.
-2. 사용자가 지금 어떻게 해결하는지 적는다.
-3. 내 도구가 줄여 줄 시간을 추정한다.
-4. 첫 화면에 무엇을 입력해야 하는지 적는다.
-5. 결과 화면에 무엇이 나와야 하는지 적는다.
-6. 주변 사람 한 명에게 "이거 있으면 쓸 것 같아?"가 아니라 "지금 이 문제를 어떻게 해결해?"라고 묻는다.
-
-## 7. AI에게 아이디어 정리를 부탁하기
-
-다음 프롬프트를 사용할 수 있습니다.
-
-```text
-나는 초보자이고 AI IDE로 첫 제품 프로토타입을 만들고 싶어.
-아래 아이디어를 평가해 줘.
-
-아이디어:
-[여기에 아이디어 작성]
-
-다음 기준으로 답해 줘.
-1. 대상 사용자가 충분히 구체적인가
-2. 첫 버전에서 만들 핵심 기능 3개
-3. 너무 큰 범위라면 줄이는 방법
-4. 첫 화면과 결과 화면에 들어갈 내용
-5. 사용자에게 물어볼 검증 질문 5개
+**프롬프트:**
+```
+다음을 도와주세요:
+1. MVP 계획하기
+2. 구체적인 기술 구현 제안 제시하기
+3. 비용 추산하기
+4. 검증 지표 설정하기
```
-## 과제
+**조작:**
+- 기술 구현 난이도?
+- 콘텐츠 제작 비용?
+- 홍보 비용?
+- 사용자 획득 난이도?
-아이디어 3개를 적고, 각각을 다음 형식으로 바꿔 보세요.
-
-```text
-[사용자]가 [상황]에서 [입력]을 넣으면 [결과]를 얻는 도구
+**프롬프트:**
+```
+저는 다음이 걱정됩니다:
+1. [걱정1]
+2. [걱정2]
+3. [걱정3]
```
-그중 가장 작게 만들 수 있는 하나를 골라 다음 장으로 넘어갑니다.
+**조작:**
+- 당신의 걱정에 대해 구체적인 제안을 받습니다.
+- 여러 방안을 비교하고 최적안을 선택합니다.
+- 비용을 추산합니다.
-## 다음으로
+**프롬프트:**
+```
+제 걱정에 대해 구체적인 해결 방안을 제시해 주세요.
+```
-[프로토타입 만들기](/ko-kr/stage-1/building-prototype/)에서 아이디어를 실제 화면과 기능으로 바꾸는 과정을 배웁니다.
+**조작:**
+- 명확한 실행 계획을 정리합니다.
+- 검증 지표를 설정합니다.
+- 도달하지 못하면 즉시 방향을 조정합니다.
+**프롬프트:**
+```
+명확한 실행 계획을 정리해 주세요.
+```
+
+::: tip 핵심 기술
+
+- **여러 라운드 대화:** 한 번의 대화로 완벽한 답을 기대하지 말고 여러 번 반복합니다.
+- **정보 제공:** 당신의 관찰, 경험, 주변 사람의 피드백을 AI에게 알려 줍니다.
+- **AI에 의문 제기:** AI의 제안이 합리적이지 않다면 즉시 지적합니다.
+- **실행에 집중:** 마지막에는 반드시 구체적인 실행 계획으로 내려옵니다.
+
+:::
+
+---
+
+### 부록 F: 요구 검증 체크리스트
+
+시간을 들여 개발하기로 결정하기 전에, 아래 체크리스트로 아이디어를 검증하세요. 핵심 질문은: 사용자가 이것에 비용을 지불할까? 입니다.
+
+::: tip 요구 검증 체크리스트
+
+**1. 사용자 페르소나 명확도**
+- ☐ 목표 사용자를 한 문장으로 설명할 수 있는가?
+- ☐ 그들이 현재 쓰는 대체 방안이 무엇인지 말할 수 있는가?
+- ☐ 그들의 사용 장면의 구체적인 세부 사항을 설명할 수 있는가?
+- ☐ 이 사람군은 지불 능력이 있는가?
+
+**2. 문제점 강도 평가**
+- ☐ 사용자가 지금 이 문제를 해결하기 위해 어떤 대가를 치르는가? 시간/돈/에너지.
+- ☐ 이 문제를 해결하지 않으면 어떤 결과가 생기는가?
+- ☐ 사용자가 이미 해결 방안을 찾고 있는가?
+- ☐ 사용자가 이 문제를 해결하기 위해 얼마를 지불할 의향이 있는가?
+
+**3. 해결 방안 차별화**
+- ☐ 기존 방안과 비교해 당신의 장점은 무엇인가?
+- ☐ 이 장점이 사용자가 전환할 만큼 충분한가?
+- ☐ 대형 플랫폼이 당신의 기능을 베끼는 난이도는 높은가?
+- ☐ 당신의 차별화는 사용자 결제를 지탱할 만큼 충분한가?
+
+**4. 비즈니스 모델 가능성**
+- ☐ 사용자가 이것에 비용을 지불할 의향이 있는가? 얼마를 낼까? 반드시 실제 테스트해야 합니다.
+- ☐ 고객 획득 비용은 대략 얼마인가?
+- ☐ 사용자 생애 가치(LTV)가 고객 획득 비용(CAC)을 덮을 수 있는가?
+- ☐ 다른 수익화 방식이 있는가? 광고, 부가 서비스, B2B 등.
+
+**5. 빠른 검증 방안**
+- ☐ 최소 비용(1-2주)으로 테스트 가능한 프로토타입을 만들 수 있는가?
+- ☐ 목표 사용자 10명을 찾아 인터뷰할 수 있는가?
+- ☐ 핵심 가설을 검증할 실험을 설계할 수 있는가?
+- ☐ 사용자에게 예약금을 선불로 받아 지불 의향을 검증할 수 있는가?
+
+:::
+
+“이 제품을 사용할 건가요?” 같은 질문은 하지 마세요. 이런 질문은 모두 거짓 양성 답변을 얻습니다.
+
+이렇게 물어야 합니다:
+- “지금은 이 문제를 어떻게 해결하고 있나요?”(진짜 행동 이해)
+- “최근 일주일 동안 이 문제가 몇 번이나 당신을 괴롭혔나요?”(빈도 이해)
+- “해결 방안이 있지만 지금 습관을 바꿔야 한다면, 의향이 있나요?”(변화 비용 이해)
+- “XX위안을 받는다면 구매할 건가요?”(지불 의향 이해)
+
+**가장 좋은 검증:** 사용자에게 예약금을 선불로 받는 것입니다. 비용을 지불하겠다고 말하는 사람은 많지만, 실제로 돈을 내는 사람만이 목표 사용자입니다.
+
+**핵심 지표:**
+- 예약금을 낼 의향이 있는 사용자 비율 > 10%: 요구가 진짜이며 투자할 가치가 있음
+- 예약금을 낼 의향이 있는 사용자 비율 5-10%: 요구는 존재하지만 다듬어야 함
+- 예약금을 낼 의향이 있는 사용자 비율 < 5%: 요구가 성립하지 않거나 제품 개념에 문제가 있음
+
+---
+
+## 이 장의 소결
+
+이번 장에서는 샤오밍의 이야기를 통해 제품 관리자의 관점으로 제품 아이디어를 바라보는 법을 배웠습니다. 핵심은 항상 사용자가 이것에 비용을 지불할까? 입니다.
+
+::: info 핵심 요점
+
+**1. 진짜 요구의 세 가지 기준:**
+- 사용자가 비용을 지불할 의향이 있음. 가장 중요한 기준입니다.
+- 사용자가 행동을 바꿀 의향이 있음.
+- 해결 방안이 없을 때 사용자가 큰 손실을 봄.
+
+**2. 평범한 idea에서 누군가 비용을 지불할 제품으로 가는 길:**
+- 가로 나누기: 특정 사람군을 찾습니다. 더 세분화할수록 지불 의향이 강합니다.
+- 세로 깊게 파기: 완전한 장면을 이해하고, 기능뿐 아니라 감정을 해결합니다.
+- 가치 재구성: 도구에서 해결 방안으로 진화시켜 결제 이유를 만듭니다.
+
+**3. 가짜 요구의 함정 피하기:**
+- 가짜 문제점 해결하기(문제점이 아니라 가려운 지점)
+- 시장 규모가 너무 작아 비즈니스 모델을 지탱할 수 없음
+- 해결 방안이 문제보다 더 복잡함
+
+**4. 지불 의향 검증 방법:**
+- 목표 사용자 10명을 찾아 심층 인터뷰
+- 사용자에게 예약금을 선불로 받게 해 진짜 의향 검증
+- 예약금을 낼 의향이 있는 사용자 비율이 10%를 넘어야 투자할 가치가 있음
+
+**5. AI 대화로 제품 개념 다듬기:**
+- 여러 라운드로 반복하며 계속 최적화
+- 실행에 집중하고 실행 계획으로 내리기
+- 검증 지표를 설정하고 즉시 조정
+
+:::
+
+**기억하세요:** 좋은 제품 관리자는 허공에서 요구를 창조하는 사람이 아니라, 무시되고, 과소평가되고, 잘못 충족되고 있는 진짜 요구를 발견하고, 사용자가 기꺼이 비용을 지불할 방식을 찾는 사람입니다.
+
+다음 장에서는 검증된 아이디어를 가지고, AI IDE로 그것을 상호작용 가능한 제품 프로토타입으로 바꾸는 법을 배우기 시작합니다.
diff --git a/docs/ko-kr/stage-1/integrating-ai-capabilities/index.md b/docs/ko-kr/stage-1/integrating-ai-capabilities/index.md
index 4e93c41..79651b5 100644
--- a/docs/ko-kr/stage-1/integrating-ai-capabilities/index.md
+++ b/docs/ko-kr/stage-1/integrating-ai-capabilities/index.md
@@ -1,159 +1,808 @@
---
-title: 'AI 기능 통합하기'
-description: '프로토타입에 텍스트 생성, 이미지 생성, OCR, 음성 등 AI 기능을 붙이는 기본 흐름을 설명합니다.'
+title: '프로토타입에 AI 능력 추가하기 - 텍스트와 이미지 API 연결'
+description: '기존 Web 프로토타입에 실제 AI 능력을 연결합니다. API의 핵심 개념을 이해하고, API Key와 공식 예시를 찾는 법을 배우며, DeepSeek 텍스트 모델과 여러 이미지 생성 서비스(SiliconFlow Qwen-Image, Recraft, Seedream)를 실습으로 통합하고, 자주 쓰는 모델 선택 방법을 익힙니다.'
---
-# AI 기능 통합하기
+
-## 1. AI 기능은 어디에 넣어야 할까
+# 초급 4: 프로토타입에 AI 능력 주입하기
-AI 기능은 보통 다음 위치에 들어갑니다.
+## 장 가이드
-| 위치 | 예시 |
-| --- | --- |
-| 입력 보조 | 사용자의 짧은 메모를 정리된 프롬프트로 바꾸기 |
-| 생성 | 글, 이미지 설명, 코드, 계획, 메시지 생성 |
-| 요약 | 긴 문서, 회의록, 리뷰를 짧게 정리 |
-| 분류 | 문의, 감정, 우선순위, 카테고리 분류 |
-| 추출 | 텍스트에서 날짜, 담당자, 금액, 할 일 추출 |
-| 변환 | 블로그 글을 SNS 문구로 바꾸기 |
+
-처음에는 한 가지 기능만 붙이세요. 여러 AI 기능을 한꺼번에 붙이면 오류 원인을 찾기 어렵습니다.
+앞선 장에서 우리는 좋은 아이디어 찾기부터 제품 프로토타입 만들기까지의 전체 흐름을 완성했습니다. 하지만 지금의 프로토타입은 아직 “껍데기”에 가깝습니다. 버튼을 클릭해도 실제로 콘텐츠가 생성되지 않고, 페이지의 데이터도 모두 고정되어 있습니다.
-## 2. API 연결의 기본 구조
+첫 장에서 강조했던 것을 기억하나요? 우리가 만들려는 것은 “누군가 기꺼이 비용을 지불할 제품”이지, “그럴듯해 보이는 프로토타입”이 아닙니다. 진짜 가치는 제품이 실제 문제를 해결할 수 있는 데서 나오며, 그러려면 프로토타입이 진짜로 실행될 수 있어야 합니다.
-대부분의 AI API 연결은 비슷합니다.
+이번 장에서는 프로토타입을 “살아 움직이게” 만듭니다. 실제 AI 능력을 연결합니다. API Key를 받는 것부터 시작해 공식 문서를 읽고, AI IDE가 인터페이스를 코드에 통합하도록 돕게 합니다. DeepSeek 텍스트 모델을 예로 들어, 애플리케이션이 실제로 대형 모델을 호출해 콘텐츠를 생성하게 하는 방법을 배웁니다. 관심이 있다면 이미지 생성 연결도 선택 실습으로 할 수 있습니다.
-1. API Key를 발급받는다.
-2. 요청 URL을 확인한다.
-3. 요청 body 형식을 확인한다.
-4. 프론트엔드 또는 백엔드에서 요청을 보낸다.
-5. 응답을 화면에 표시한다.
-6. 오류, 로딩, 빈 응답을 처리한다.
+이 장을 마치면 당신의 프로토타입은 더 이상 정적인 데모가 아니라, 실제 AI 능력을 호출하고 실제 문제를 해결할 수 있는 애플리케이션이 됩니다.
-초보자에게는 먼저 백엔드 없이 실습하는 경우도 있지만, 실제 서비스에서는 API Key를 브라우저에 직접 노출하지 않는 편이 안전합니다.
+
-## 3. AI IDE에 API 연결을 요청하는 프롬프트
+
+
+
+
+
-```text
-현재 프로토타입에 텍스트 생성 API를 연결하고 싶어.
+# 1. API 기초 개념
-요구사항:
-- API Key는 .env 파일에서 읽게 해 줘.
-- 사용자가 입력한 내용을 프롬프트로 보내 줘.
-- 로딩 중에는 버튼을 비활성화해 줘.
-- 실패하면 사용자에게 이해하기 쉬운 오류 메시지를 보여 줘.
-- 응답이 비어 있으면 다시 시도 안내를 보여 줘.
+앞에서 말했듯 우리의 목표는 “AI 능력을 연결”하여 프로토타입이 더 이상 정적인 데모가 아니라 실제 AI 서비스를 호출할 수 있는 도구가 되게 하는 것입니다. 이를 실현하는 핵심은 API(애플리케이션 프로그래밍 인터페이스)를 이해하고 사용하는 데 있습니다.
-먼저 현재 프로젝트 구조를 확인하고,
-어떤 방식으로 API Key를 안전하게 다룰지 설명한 뒤 수정해 줘.
+API는 컴퓨터 분야의 중요한 추상 개념입니다. 간단히 이해하면, **상대가 요구한 형식에 맞춰 “질문을 보내면”, 상대도 같은 형식에 따라 “결과를 돌려주는” 것**입니다.
+
+- **당신이 보내는 내용**: 보통 “비밀키(API Key)”와 “무엇을 생성할지”를 포함합니다.
+- **상대가 돌려주는 내용**: 성공하면 결과를 주고, 실패하면 이유를 알려 줍니다. 예: “키가 틀림”, “잔액 부족”, “파라미터 오류”.
+
+구체적으로는 다음 핵심 요소를 익혀야 합니다.
+
+1. **API Key**: 당신의 “통행증”이자 “지갑 열쇠”입니다. 다른 사람이 이것을 얻으면 당신 대신 인터페이스를 호출하고 비용을 발생시킬 수 있습니다.
+2. **Endpoint(인터페이스 경로)**: API 요청의 구체적인 경로입니다. 서버에 어떤 기능에 접근할지 알려 줍니다. 완전한 요청 주소는 보통 “기본 URL + Endpoint 경로”로 구성됩니다. 예:
+ - 텍스트 생성: 기본 URL (`https://api.service.com`) + Endpoint (`/v1/chat/completions`) = 전체 URL `https://api.service.com/v1/chat/completions`
+ - 이미지 생성: 기본 URL (`https://api.service.com`) + Endpoint (`/v1/images/generations`) = 전체 URL `https://api.service.com/v1/images/generations`
+3. **호출/요청**: AI 서비스에 작업을 보내고 결과를 받는 과정입니다.
+4. **요청 내용**: AI에게 보내는 구체적인 내용입니다. 예를 들어 AI가 써야 할 글의 주제, 생성할 이미지 설명 등입니다.
+5. **응답 결과**: AI가 처리한 뒤 돌려주는 내용입니다. 예를 들어 생성된 글, 이미지 등입니다.
+6. **오류 처리**: 문제가 생겼을 때(API Key 오류, 요청 빈도 초과 등) 원인을 찾아 해결하는 방법을 아는 것입니다.
+
+::: info ℹ️ API란 무엇인가
+API에 대한 더 깊은 설명은 부록 [API 입문](/ko-kr/appendix/4-server-and-backend/api-intro)을 참고하세요.
+
+::: warning 🔐 **API 보안 주의사항**
+API Key는 AI 서비스 요청을 위한 “통행증”입니다. 신원 확인과 과금에 쓰이는 비밀번호 문자열입니다.
+
+API Key는 계정과 비용에 직접 연결되므로 반드시 주의해야 합니다.
+
+- 절대 **단체 채팅방에 공유하거나, 스크린샷을 인터넷에 올리거나**, 공개 포럼에 게시하지 마세요.
+- **코드에 하드코딩한 뒤** Git 저장소에 제출하지 마세요. 특히 공개 저장소는 더 위험합니다.
+- Key가 유출되었다고 의심되면 **즉시 새 Key로 교체**하세요.
+
+아래 내용에서는 연습을 위해 **API KEY를 AI IDE에 직접 붙여 넣어 조작**합니다. **정식 프로젝트에서는 이렇게 하면 안 됩니다!!** 우리는 연습이기 때문에 이렇게 할 수 있습니다. 더 익숙해지면 AI에게 설정 파일을 생성하게 하고, API KEY는 설정 파일에만 넣으면 됩니다.
+:::
+
+
+
+
+
+
+
+# 2. 텍스트 생성 API 연결하기: DeepSeek
+
+API에는 이런 기술 개념이 얽혀 있지만, 프로토타입 개발 단계에서 실제 조작은 아주 단순하고 효율적일 수 있습니다. 핵심 생각은 다음입니다.
+
+> **공식 예시를 찾고, API Key를 얻고, AI IDE에게 버튼에 연결하게 한다.**
+
+이 개념을 익히면 텍스트 모델을 연결하든 이미지 모델을 연결하든 본질적인 흐름은 같다는 것을 알게 됩니다. 사용자가 버튼을 클릭하면 프론트엔드가 입력을 정리해 요청을 보내고, 인터페이스가 결과를 반환하면 그 결과를 다시 페이지에 표시합니다. 이제 실제 조작으로 이것을 확인해 보겠습니다.
+
+`1.2 직접 프로토타입 만들기`에서 이미 상호작용 가능한 프로토타입을 만들었습니다. 이제 해야 할 일은 프로토타입 안의 “AI처럼 보이는 기능”을 진짜 사용할 수 있는 능력으로 바꾸는 것입니다. **사용자가 버튼을 클릭하면 프로토타입이 외부 AI 서비스에 요청을 보내고, 반환된 텍스트를 화면에 표시**하게 만듭니다.
+
+::: info ℹ️ 원리 확장
+원리 관련 내용을 더 알고 싶다면 부록 [대형 언어 모델(LLM) 입문](/ko-kr/appendix/8-artificial-intelligence/llm-principles)을 확인하세요.
+::: details 더 알아보기: DeepSeek이란 무엇인가?
+
+**항저우 DeepSeek 인공지능 기초기술 연구유한회사**(Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd.)는 DeepSeek이라는 상호로 운영되는 **대형 언어 모델(LLMs)을 개발하는 중국 인공지능(AI) 회사**입니다. DeepSeek은 저장성 항저우에 본사를 두고 있으며, 중국 헤지펀드 환팡퀀트(High-Flyer)가 소유하고 자금을 지원합니다. DeepSeek은 환팡퀀트 공동 창업자인 Liang Wenfeng이 2023년 7월 설립했으며, 그는 두 회사의 CEO도 겸하고 있습니다. 이 회사는 2025년 1월 동명의 챗봇과 DeepSeek-R1 모델을 출시했습니다.
+
+DeepSeek이 GPQA 벤치마크 순위에서 다른 최상위 모델과 어떻게 비교되는지 보겠습니다. 주목할 점은 DeepSeek은 오픈소스(누구나 인터넷에서 모델을 다운로드 가능) 모델이고, Grok, Google Gemini, ChatGPT 같은 일반적인 다른 모델은 폐쇄형이라는 점입니다. 볼 수 있듯 DeepSeek은 이미 상당 부분 1군 모델에 가까워졌습니다.
+
+
+
+GPQA는 “Graduate-Level Google-Proof Q&A Benchmark”의 약자로, 과학 질의응답 작업을 위한 대학원 수준의 벤치마크입니다. 자세한 소개는 다음과 같습니다.
+
+GPQA는 448개의 객관식 문제를 포함하며, 생물학, 물리학, 화학의 하위 분야를 다룹니다. 예: 양자역학, 유기화학, 분자생물학 등. 이 문제들은 박사 학위를 보유했거나 박사 과정 중인 61명의 전문가가 작성했고, 엄격한 검증 과정을 거쳤습니다.
+:::
+
+이 3단계를 따르면 대형 모델 생성 API를 빠르게 통합할 수 있습니다.
+
+1. **DeepSeek 플랫폼에서 API Key 만들기**
+2. **DeepSeek 문서에서 텍스트 생성 예시 찾기**. 보통 바로 복사할 수 있는 코드가 있습니다.
+3. **AI IDE를 열고 API Key + 공식 예시를 붙여 넣은 뒤**, 구현할 기능을 알려 줍니다.
+ > 이 대형 모델 API를 연결해서 이 애플리케이션의 문구 생성 작업을 지원해 줘.
+
+이제 시연을 진행합니다. 전체 흐름을 따라 직접 한 번 조작해 보세요. 먼저 [DeepSeek](https://platform.deepseek.com/usage) 계정을 등록하고 API Key를 만든 뒤, 검증을 위해 소액을 충전합니다.
+
+
+
+
+
+“API KEYS”를 클릭하고 화면 아래에서 “create new API key”를 찾습니다. 최종적으로 `sk-8573341c39fc44315aadc071c53rh7d2` 같은 API key를 얻게 됩니다.
+
+
+
+키를 얻으면 모델을 호출할 권한을 가진 것입니다.
+
+이때 [API](https://api-docs.deepseek.com/) 문서를 바로 읽을 수 있습니다. 보통 curl 또는 Python 호출 예시를 제공합니다.
+
+
+
+예시를 찾은 뒤, 문서의 모든 내용과 키를 AI IDE의 대화창에 복사해 넣고, 이전에 개발해 둔 프로토타입에 대형 언어 모델을 통합해 달라고 요청할 수 있습니다.
+
+
+
+참고 프롬프트는 다음과 같습니다.
+
+```
+이 호출 방법을 참고해 문구 생성 기능을 지원해 주세요. 상품 정보를 바탕으로 클릭하면 해당 Douyin 이커머스 문구를 여러 스타일로 생성할 수 있어야 합니다.
+
+아래 참고 자료:
+api key: sk-8573341c39aefa1efe
+api 요청 참고:
+curl \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
+ -d '{
+ "model": "deepseek-chat",
+ "messages": [
+ {"role": "system", "content": "You are a helpful assistant."},
+ {"role": "user", "content": "Hello!"}
+ ],
+ "stream": false
+ }'
```
-## 4. 로딩과 오류가 중요하다
+AI가 코드를 생성하는 데 약간의 시간이 지나면, 테스트할 수 있는 대응 문구 생성 버튼을 쉽게 얻을 수 있습니다. 입구를 찾을 수 없다면 AI IDE에게 어느 페이지에서 해당 페이지로 들어갈 수 있는지 알려 달라고 하면 됩니다. 정말 찾기 어렵다면 AI IDE에게 당신의 생각을 바탕으로 직접 리팩터링하고 개선하게 하여 최종 문구 생성 결과를 얻을 수 있습니다.
-AI API는 느릴 수 있고, 실패할 수 있습니다. 사용자는 기다리는 동안 무슨 일이 일어나는지 알아야 합니다.
+
-필수 상태:
+
-- 입력 전 빈 상태
-- 생성 중 로딩 상태
-- 성공 상태
-- 실패 상태
-- 재시도 가능 상태
+물론 여기서 이런 질문이 들 수 있습니다. 실제로 대형 모델을 호출한 것인지, 아니면 고정된 답변을 내장한 것인지 어떻게 알 수 있을까요? 사용자 지정 문구를 입력하고, 대형 모델이 당신이 즉시 지정한 사용자 정의 분석을 바탕으로 대응 문구를 생성하게 해 보면 됩니다.
-오류 메시지는 기술적으로 정확한 것보다 사용자가 다음 행동을 알 수 있어야 합니다.
+매번 결과가 다르고 논리적으로도 맞는다면, 이때 API가 정상적으로 호출되어 생성되고 있다고 안심해도 됩니다. [API 사용 관리 플랫폼](https://platform.deepseek.com/usage)에서 성공적으로 호출되었는지도 확인할 수 있습니다. 다만 표시되기까지 몇 분이 걸릴 수 있습니다.
-나쁜 문구:
+## 더 많은 텍스트 생성 모델 선택지
-```text
-500 Internal Server Error
+DeepSeek 외에도 다른 대형 언어 모델을 시도할 수 있습니다. 대부분의 모델이 **OpenAI 호환 인터페이스**를 제공하므로 전환은 매우 간단합니다. API Key, 기본 URL, 모델 이름만 바꾸면 됩니다.
+
+### MiniMax 통합
+
+::: details 더 알아보기: MiniMax란 무엇인가?
+
+**MiniMax**는 범용 인공지능 기술 연구 개발에 힘쓰는 중국 인공지능 회사입니다. MiniMax는 자체 연구 개발한 MiniMax-M2.7 대형 언어 모델 시리즈를 출시했으며, 여러 벤치마크 테스트에서 우수한 성능을 보이고 매우 높은 가성비를 가지고 있습니다.
+
+**MiniMax-M2.7 시리즈의 주요 특징:**
+
+- **초장문 컨텍스트**: 204,800 tokens 컨텍스트 창을 지원하여 긴 문서와 다중 턴 대화 처리에 적합합니다.
+- **높은 가성비**: 가격 경쟁력이 매우 높습니다.
+- **OpenAI 호환 인터페이스**: OpenAI SDK로 바로 호출할 수 있어 새로운 API 형식을 추가로 배울 필요가 없습니다.
+- **사용 가능한 두 모델**:
+ - `MiniMax-M2.7`: 플래그십 모델로 복잡한 작업에 적합합니다.
+ - `MiniMax-M2.7-highspeed`: 같은 성능을 유지하면서 더 빠른 고속 버전입니다.
+:::
+
+연결 방식은 DeepSeek과 동일하며, 세 단계만 필요합니다.
+
+1. [MiniMax 오픈 플랫폼](https://platform.minimax.io/)으로 가서 계정을 등록하고 API Key를 만듭니다.
+2. MiniMax 문서에서 호출 예시를 찾습니다.
+3. API Key + 예시를 AI IDE에 붙여 넣습니다.
+
+MiniMax는 OpenAI 호환 인터페이스를 제공하므로 아래 curl 예시와 당신의 API Key를 그대로 복사해 AI IDE에 보내 통합할 수 있습니다.
+
+```bash
+curl https://api.minimax.io/v1/chat/completions \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer ${MINIMAX_API_KEY}" \
+ -d '{
+ "model": "MiniMax-M2.7",
+ "messages": [
+ {"role": "system", "content": "You are a helpful assistant."},
+ {"role": "user", "content": "Hello!"}
+ ],
+ "stream": false
+ }'
```
-좋은 문구:
+::: tip ✅ 팁
+MiniMax의 API 형식은 DeepSeek과 거의 완전히 같습니다. 둘 다 OpenAI 호환 형식입니다. 따라서 이미 DeepSeek을 성공적으로 연결했다면, MiniMax로 전환할 때는 세 곳만 수정하면 됩니다.
+1. **기본 URL**: `https://api.minimax.io/v1`로 변경
+2. **API Key**: MiniMax의 API Key 사용
+3. **모델 이름**: `MiniMax-M2.7` 또는 `MiniMax-M2.7-highspeed`로 변경
-```text
-생성 중 문제가 발생했습니다. 잠시 후 다시 시도해 주세요.
-문제가 반복되면 입력 내용을 조금 줄여 보세요.
+자세한 내용은 [MiniMax OpenAI 호환 인터페이스 문서](https://platform.minimax.io/docs/api-reference/text-openai-api)를 참고하세요.
+:::
+
+# 3. 이미지-텍스트 API 연결하기: Qwen3 VL
+
+::: info ℹ️ 원리 확장
+원리 관련 내용을 더 알고 싶다면 부록 [비전 언어 모델(VLM) 입문](/ko-kr/appendix/8-artificial-intelligence/multimodal-models)을 확인하세요.
+
+::: details 더 알아보기: Qwen3 VL이란 무엇인가?
+
+**Qwen3 VL**은 Alibaba Cloud Tongyi Qianwen 팀이 출시한 멀티모달 비전 언어 모델 시리즈의 최신 버전입니다. VL은 “Vision-Language”, 즉 비전 언어 모델을 의미합니다. 이미지를 이해하고, 이미지에 대한 텍스트 설명을 생성하고, 이미지 관련 질문에 답하고, 이미지 정보를 추출하는 등의 작업을 할 수 있습니다.
+
+
+
+
+**Qwen3 VL의 주요 능력은 다음과 같습니다.**
+
+- **이미지 이해**: 이미지 속 물체, 장면, 인물, 문자 등을 인식할 수 있습니다.
+- **시각 질의응답**: 사용자 질문에 따라 이미지에 관한 질문에 정확히 답할 수 있습니다.
+- **이미지 설명**: 자세하거나 간결한 이미지 텍스트 설명을 생성합니다.
+- **다중 이미지 이해**: 여러 이미지를 동시에 처리하고 비교 분석할 수 있습니다.
+- **텍스트 추출**: 이미지에서 문자 내용을 추출합니다. OCR 능력입니다.
+
+**왜 Qwen3 VL을 선택할까요?**
+
+이전 세대 모델과 비교하면 Qwen3 VL은 이미지 이해 정확도에서 뚜렷하게 향상되었고, 더 길고 복잡한 이미지 분석 작업을 지원합니다. 중국어 이해 성능이 우수하고 API 호출 비용이 상대적으로 낮아 가성비가 높습니다. 또한 컨텍스트 창이 더 커서 더 복잡한 시각 추론 작업을 처리할 수 있습니다.
+
+**대표 적용 장면:**
+
+- 이커머스: 상품 이미지에서 제목, 설명, 판매 포인트 자동 생성
+- 콘텐츠 창작: 소재 이미지를 바탕으로 문구나 이미지 제안 자동 생성
+- 사무: 이미지 내용 추출, 보고서 자동 인식
+- 교육: 이미지 문제 자동 해석, 지식 포인트 추출
+
+:::
+
+앞부분에서 텍스트 생성 API를 연결하는 방법을 설명했습니다. 하지만 앞선 애플리케이션 장면에서는 문제가 하나 있습니다. 우리는 이미지를 업로드합니다. 대형 언어 모델만 사용하면 이미지 안의 내용을 제대로 이해하기 어렵고, 생성 결과가 달라질 가능성이 큽니다.
+
+우리는 이미지를 텍스트 설명으로 바꿔 줄 수 있는 모델이 필요합니다. 이때 필요한 것이 비전 언어 모델(VLM)입니다. 사례에서는 비전 언어 모델을 사용해 상품의 판매 포인트 설명을 생성하여 사용자 경험을 높입니다.
+
+편의를 위해 [클라우드 플랫폼 SiliconFlow](https://cloud.siliconflow.cn/me)가 제공하는 API 인터페이스를 사용해 이미지-텍스트 API를 연결합니다.
+
+::: details 더 알아보기: SiliconFlow란 무엇인가
+**SiliconFlow**는 중국 내에서 잘 알려진 AI 모델 집계 플랫폼으로, 여러 주요 대형 언어 모델과 비전 언어 모델의 API 인터페이스 서비스를 제공합니다.
+
+**플랫폼 특징:**
+
+- **다중 모델 지원**: DeepSeek, Qwen, Llama 계열 등 여러 주요 AI 모델과 오픈소스 모델을 통합합니다.
+- **기술 최적화**: 오픈소스 모델에 대한 추론 최적화를 수행하여 낮은 지연 시간과 높은 동시성의 API 서비스를 제공합니다.
+- **인터페이스 호환**: OpenAI 형식과 호환되는 API 인터페이스를 제공하여 기존 애플리케이션 통합이 쉽습니다.
+- **사용량 기반 과금**: 호출량에 따라 비용을 지불하는 방식을 지원합니다.
+
+SiliconFlow는 오픈소스 대형 모델 추론 서비스 측면에서 비교적 성숙했으며, 중국산 오픈소스 AI 모델을 사용할 때 자주 선택되는 플랫폼 중 하나입니다.
+:::
+
+SiliconFlow 플랫폼의 홈 화면에 들어가면 많은 모델을 선택할 수 있습니다. 왼쪽 위에서 필터를 찾아 펼친 뒤, 비전 태그를 선택하면 여러 이미지-텍스트 모델을 볼 수 있습니다. 예를 들어 Zhipu GLM-4.6V나 Qwen3-VL이 있습니다.
+
+
+
+테스트를 위해 아무 모델이나 선택할 수 있습니다. 여기서는 `Qwen/Qwen3-VL-8B-Instruct`를 예로 들겠습니다.
+
+
+
+[SiliconFlow 플랫폼](https://cloud.siliconflow.cn/me/account/ak)에 들어가 API 키에서 “새 API 키”를 클릭해 새로운 API Key를 만듭니다.
+
+아래 코드를 참고 코드로 사용할 수 있습니다. 생성한 API Key와 함께 AI IDE에 보내 기능을 통합하세요.
+
+::: details 이미지-텍스트 참고 코드
+
+```python
+from openai import OpenAI
+from typing import Dict, Any, List
+import base64
+import os
+SILICONFLOW_API_KEY: str = ""
+SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/"
+MODEL_NAME: str = "Qwen/Qwen3-VL-8B-Instruct"
+
+def encode_image(image_path: str) -> str:
+ with open(image_path, "rb") as image_file:
+ return base64.b64encode(image_file.read()).decode('utf-8')
+
+def get_vlm_completion(client: OpenAI, messages: List[Dict[str, Any]]) -> str:
+ response = client.chat.completions.create(
+ model=MODEL_NAME,
+ messages=messages,
+ max_tokens=512,
+ temperature=0.7,
+ top_p=0.7,
+ frequency_penalty=0.5,
+ stream=False,
+ n=1
+ )
+ return response.choices[0].message.content
+
+def caption_image(image_path: str) -> str:
+ base64_image = encode_image(image_path)
+ messages = [
+ {
+ "role": "user",
+ "content": [
+ {
+ "type": "text",
+ "text": "Please describe this image in detail."
+ },
+ {
+ "type": "image_url",
+ "image_url": {
+ "url": f"data:image/jpeg;base64,{base64_image}"
+ }
+ }
+ ]
+ }
+ ]
+
+ client = OpenAI(
+ api_key=SILICONFLOW_API_KEY,
+ base_url=SILICONFLOW_BASE_URL
+ )
+
+ return get_vlm_completion(client, messages)
+
+image_path = "images.jpg"
+caption = caption_image(image_path)
```
-## 5. 프롬프트 설계
+:::
-AI 기능의 품질은 모델만이 아니라 프롬프트에도 크게 좌우됩니다.
+이 장면에서는 AI IDE에게 업로드한 이미지를 바탕으로 이커머스 판매 포인트 텍스트와 키워드를 자동 생성하는 기능을 구현하게 해 봅니다. 아래와 같습니다.
-좋은 프롬프트에는 다음이 들어갑니다.
+```
+아래 이미지-텍스트 API를 바탕으로, 업로드한 이미지에서 이커머스 판매 포인트 텍스트와 키워드를 자동 생성하는 기능을 구현해 주세요.
-- 역할: 어떤 전문가처럼 답해야 하는가
-- 입력: 사용자가 넣은 내용
-- 출력 형식: 표, JSON, 목록, 문단 등
-- 제약: 길이, 톤, 금지 사항
-- 예시: 가능하면 좋은 출력 예시
-
-예시:
-
-```text
-너는 소상공인을 돕는 마케팅 카피라이터야.
-아래 상품 정보를 바탕으로 한국어 상품 홍보 문구를 만들어 줘.
-
-출력 형식:
-1. 짧은 제목 3개
-2. 상세 설명 1개
-3. SNS 홍보 문구 3개
-
-톤: 친근하지만 과장하지 않게
-상품 정보:
-{userInput}
+<여기서는 코드를 생략했습니다. 직접 키와 참고 코드를 붙여 넣어야 합니다.>
```
-## 6. 텍스트 생성 외의 AI 기능
+마지막으로 생성 결과를 얻습니다.
+
-### 6.1 이미지 생성
+
-사용자가 원하는 분위기, 대상, 스타일, 비율을 입력하면 이미지 생성 모델에 전달합니다. 제품에서는 생성된 이미지를 그대로 쓰기보다 여러 후보를 보여 주고 선택하게 하는 방식이 좋습니다.
+
+
+
+
+
-### 6.2 OCR / 이미지 이해
+# 4. 이미지 생성 API 연결하기: Seedream
-영수증, 문서, 화면 캡처에서 정보를 읽어 구조화할 수 있습니다. 단, 인식 오류를 사용자가 수정할 수 있는 UI가 필요합니다.
+앞부분에서는 주로 텍스트 관련 작업을 다뤘습니다. 이제 이미지 생성 기능을 연결해 보겠습니다. 텍스트 설명에서 이미지를 생성하거나 이미지를 수정하는 기능을 지원합니다.
-### 6.3 음성 인식
+::: info ℹ️ 원리 확장
+원리 관련 내용을 더 알고 싶다면 부록 [이미지 생성 입문](/ko-kr/appendix/8-artificial-intelligence/image-generation)을 확인하세요.
-회의록, 메모, 인터뷰 정리에 유용합니다. 녹음, 업로드, 변환, 편집 흐름을 함께 설계해야 합니다.
+::: details 더 알아보기: [Seedream](https://seed.bytedance.com/en/seedream4_5)이란 무엇인가?
-### 6.4 RAG
+
-내 문서나 지식베이스를 바탕으로 답하게 만드는 방식입니다. Stage 1에서는 개념만 이해하고, 본격 구현은 Stage 2 이후에 다룹니다.
+> 어쩌면 Nano Banana(Google 개발)를 이미 알고 있을 수 있지만, Seedream을 놓치지 않는 것이 좋습니다. Seedream 4.5는 ByteDance가 만든 차세대 이미지 창작 모델입니다. 이미지 생성과 이미지 편집 능력을 하나의 통합 아키텍처에 결합합니다. 이를 통해 지식 기반 생성, 복잡한 추론, 참조 일관성 같은 복잡한 멀티모달 작업을 유연하게 처리할 수 있습니다. 또한 추론 속도는 이전 제품보다 훨씬 빠르며, 최대 4K 해상도의 놀라운 고화질 이미지를 생성할 수 있습니다.
+>
+> 
+> 
-## 7. 보안 주의사항
+**주요 능력:**
-- API Key를 GitHub에 올리지 않는다.
-- `.env` 파일은 `.gitignore`에 넣는다.
-- 브라우저에 직접 노출되는 환경변수인지 확인한다.
-- 결제형 API라면 사용량 제한을 둔다.
-- 사용자 입력을 그대로 신뢰하지 않는다.
+- **텍스트-이미지**: 텍스트 설명으로 이미지를 생성하며, 다양한 스타일(실사, 카툰, 수묵화, 사이버펑크 등)을 지원합니다.
+- **스타일 전이**: 이미지를 지정한 예술 스타일로 변환합니다.
+- **이미지 변형**: 참고 이미지를 바탕으로 유사한 스타일의 새 이미지를 생성합니다.
+- **해상도 향상**: 이미지 선명도와 세부 사항을 강화합니다.
+- **이미지 편집**: 자연어 지시에 따라 기존 이미지를 편집하고 수정합니다.
-## 8. 완성 체크리스트
+**왜 Seedream을 선택할까요?**
-- API Key가 코드에 하드코딩되어 있지 않다.
-- 로딩 중 버튼이 중복 클릭되지 않는다.
-- 실패 시 오류 메시지가 보인다.
-- 응답 결과가 화면에 보기 좋게 표시된다.
-- 너무 긴 입력이나 빈 입력을 처리한다.
-- 사용자가 결과를 복사하거나 다시 생성할 수 있다.
+- **중국 내 네트워크 안정성**: 중국 내 접속 속도가 빠르고 지연 시간이 낮습니다.
+- **우수한 결과**: 이커머스와 소재 장면에서 안정적이고 신뢰할 만한 결과를 보입니다.
+- **중국어 최적화**: 중국어 프롬프트 이해가 더 정확해 중국 사용자를 위한 작업에 적합합니다.
+- **빠른 속도**: 생성 효율이 높고 응답 시간이 짧습니다.
+- **안정적인 품질**: 최대 4K 해상도의 고화질 이미지를 생성합니다.
-## 과제
+**대표 적용 장면:**
-이전 장에서 만든 프로토타입에 AI 기능 하나를 붙여 보세요.
+- 이커머스: 대표 이미지, 상세 페이지 이미지, 프로모션 포스터 생성
+- 소셜미디어: 아바타, 이모티콘, 첨부 이미지 생성
+- 디자인: 콘셉트 이미지, 소재 이미지, 배경 이미지 빠르게 제작
+- 마케팅: 광고 이미지, 이벤트 banner, 명절 포스터 제작
-추천 주제:
+**Qwen3 VL과의 조합:**
-- 상품 문구 생성
-- 회의록 요약
-- 여행 일정 추천
-- 공부 계획 생성
-- 리뷰 감정 분류
+이 두 API는 이어서 사용할 수 있습니다. 먼저 Qwen3 VL로 참고 이미지를 분석해 화면 내용을 이해하고, 그다음 Seedream이 분석된 참고 이미지의 프롬프트 내용을 바탕으로 새 이미지를 생성합니다.
+:::
-## 다음으로
+Douyin, Bilibili, YouTube에서 볼 수 있는 많은 “AI 포스터 / AI 대표 이미지 / AI 캐릭터 이미지”는 본질적으로 여기서 소개하는 기술을 사용합니다. 당신이 해야 할 일은 간단합니다. 사용자 입력을 한 문장으로 정리하고 이미지 API를 요청한 뒤, 반환된 이미지를 표시하면 됩니다. 이때 사용하는 모델을 이미지 생성 / 이미지 편집 모델이라고 합니다.
-[완성 프로젝트 실습](/ko-kr/stage-1/complete-project-practice/)에서 데모를 실제로 보여 줄 수 있는 수준으로 다듬습니다.
+이제 Seedream API를 프로젝트에 통합하는 방법을 단계별로 시연합니다. AI IDE의 도움을 받아 진행합니다.
+[홈페이지](https://www.volcengine.com/experience/ark?launch=seedream)에 접속한 뒤 로그인을 클릭합니다.
+
+
+
+로그인 후 페이지 오른쪽 위의 충전 옵션을 찾습니다.
+
+
+
+충전하려면 실명 인증이 필요합니다.
+
+
+
+인증이 성공하면 [1위안을 충전해 테스트](https://console.volcengine.com/finance/fund/recharge)할 수 있습니다.
+
+[초기 화면](https://www.volcengine.com/experience/ark?launch=seedream)으로 돌아가 API 접근을 클릭합니다.
+
+
+
+먼저 API key를 만들고, 선택 옵션을 클릭합니다.
+
+
+
+그러면 2단계로 이동합니다. 여기에서 호출할 서비스가 Seedream 4.5인지 확인하고, 제공된 호출 예시를 복사해야 합니다. 이 스크린샷은 촬영 시점이 조금 이르기 때문에 모델 버전이 여전히 4.0으로 표시되어 있습니다.
+
+
+
+API Key와 호출 예시가 준비되면, 그것들을 AI IDE에 바로 붙여 넣어 프론트엔드 상호작용 데모를 생성하거나 기존 프로토타입에 능력을 연결하게 할 수 있습니다. 이미지에서 텍스트-이미지를 선택할지, 여러 이미지로 단일 이미지를 생성할지 선택할 수 있다는 점에 주의하세요. 현재 요구에 맞춰 참고 코드를 선택해야 합니다.
+
+::: warning ⚠️ 중요 팁
+여기의 기본 예시는 비교적 복잡합니다. **“워터마크 추가”** 와 **“스트리밍 응답”** 을 비활성화하는 것을 기억하세요. 그래야 워터마크가 생성되지 않고 요청 실패도 줄일 수 있습니다.
+:::
+
+이후에 참고 이미지 생성 모드를 사용할 것이므로, 먼저 여러 이미지로 단일 이미지를 생성하는 기능으로 갑니다. 복사한 참고 코드는 다음과 같습니다.
+
+```
+curl -X POST https://ark.cn-beijing.volces.com/api/v3/images/generations \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer xxxxxxx" \
+ -d '{
+ "model": "doubao-seedream-4-5-251128",
+ "prompt": "이미지 1의 의상을 이미지 2의 의상으로 바꿔 주세요",
+ "image": ["https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_1.png", "https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_2.png"],
+ "sequential_image_generation": "disabled",
+ "response_format": "url",
+ "size": "2K",
+ "stream": false,
+ "watermark": true
+}'
+```
+
+이미지 참고 코드가 생겼다면 AI IDE에게 이커머스에서 자주 쓰는 이미지 작업 기능을 지원하게 합니다.
+
+```
+아래 API를 바탕으로 이 프로젝트에서 이커머스 업무의 일반적인 기능(예: 포스터 생성, Douyin 이커머스 첫 이미지 생성 등)을 구현해 주세요.
+
+<여기에 API KEY와 이미지 편집 코드를 붙여 넣으세요>
+```
+
+구현 결과는 다음과 같습니다.
+
+
+
+주의할 점은 이미지 생성에서는 이상한 문제를 자주 만날 수 있다는 것입니다. 따라서 AI IDE가 전체 오류 정보를 표시하도록 하는 것이 좋습니다. 그래야 복사해 붙여 넣고 수정하기 쉽습니다. 그렇지 않으면 왜 그런지 모른 채 “생성 실패”만 반복해서 보일 수 있습니다. 예를 들어 이렇게 말할 수 있습니다.
+
+```
+이미지 생성 실패라고만 표시하지 말고, 매번 전체 실패 원인을 표시해 주세요. 예: 이미지 불일치, 요청 오류, 타임아웃 등.
+```
+
+때로는 수정 후 업데이트가 웹페이지에 적용되지 않을 수 있습니다. 수정 뒤에도 웹페이지가 계속 오류를 내고 있다면(여러 번 반복된다면), AI IDE에게 직접 “이 프로젝트를 재시작해 주세요”라고 말해 보세요.
+
+이커머스 업무에서는 사용자가 업로드한 옷을 자동으로 사람에게 입혀 보게 하거나, 상품의 매력적인 판매 이미지와 포스터를 자동 생성하게 하고 싶을 수 있습니다. 여기서 우리가 시도한 프롬프트는 이커머스 포스터를 생성하게 하는 것입니다.
+
+
+
+상상하는 비즈니스 장면에 따라 텍스트-이미지 또는 이미지-이미지 API를 사용해 서로 다른 기능을 구현할 수 있습니다.
+
+## 더 많은 이미지 서비스 선택지
+
+아래에 다른 선택지를 제시합니다. 먼저 Qwen 이미지 생성 결과를 끝까지 실행해 본 뒤, 효과와 비용에 따라 아래 서비스를 대체 사용하기를 권장합니다. 실제 사용 감각에 따라 선택하세요.
+
+### Recraft 통합
+
+프로토타입이 “디자인 생산” 쪽에 더 가깝다면, 예를 들어 브랜드 스타일 일러스트, 마케팅 포스터, 벡터 스타일 소재를 생성해야 한다면 Recraft가 더 편할 때가 많습니다. 연결 방식은 이전 절과 완전히 같습니다. **Key를 얻고 + 공식 예시를 찾고 + AI IDE가 예시를 버튼/페이지에 적용하게 합니다.**
+
+::: details 더 알아보기: Recraft란 무엇인가?
+
+> Recraft는 디자이너, 일러스트레이터, 마케터를 위한 AI 도구입니다. 2022년 미국에서 설립되었고 본사는 런던에 있습니다. 이미지, 벡터 아트, 3D 그래픽 같은 시각 결과물을 생성하고 반복 개선하도록 돕습니다. 고품질 출력(어떤 텍스트 크기/길이든), 정확한 요소 배치, 브랜드 일관성 디자인 등의 장점이 있습니다. 200개 국가/지역의 300만 명 이상 사용자(오길비, Netflix 포함)가 신뢰하며, 3.5억 장 이상의 이미지를 만들었습니다. 이 팀은 Recraft를 필수 디자이너 도구로 만들고, 창작자가 AI 보조 워크플로를 통제할 수 있게 하는 것을 목표로 합니다.
+>
+> 
+> 
+
+먼저 여전히 [API 입구](https://www.recraft.ai/profile/api)를 찾아 API Key를 얻어야 합니다.
+
+여기는 무료 한도를 제공하지 않으므로 직접 1,000 크레딧을 충전해야 합니다. 이 웹사이트는 Alipay와 WeChat Pay를 지원하므로 1,000 크레딧을 쉽게 얻을 수 있습니다. 필요한 금액 이상 충전하지 않도록 주의하세요.
+
+
+
+그 뒤에도 같은 방법을 따릅니다. 공식 문서에서 해당 요청 예시를 찾습니다.
+
+-
+-
+-
+
+:::
+
+### Qwen Image / Qwen Image Edit 통합
+
+더 간단한 방식으로 이미지 생성 서비스를 연결하고 싶다면 Qwen Image(Tongyi Wanxiang)를 고려할 수 있습니다. 생각은 마찬가지입니다. 이것을 “이미지 생성 API”로 보고, 프로토타입 버튼에 연결하면 됩니다.
+
+::: details 더 알아보기: Qwen Image / Qwen Image Edit란 무엇인가?
+
+**Qwen Image**(Tongyi Wanxiang이라고도 함)는 Alibaba Cloud Tongyi 팀이 출시한 이미지 생성 모델 시리즈이며, 주로 두 가지 큰 모델을 포함합니다.
+
+**1. Qwen Image - 텍스트-이미지(Text-to-Image) 모델**
+
+텍스트 설명에 따라 완전히 새로운 이미지를 생성합니다. 프롬프트를 입력하면 모델이 의도를 이해하고 설명에 맞는 이미지를 생성합니다.
+
+
+
+**주요 능력:**
+
+- **텍스트-이미지**: 텍스트 설명으로 이미지를 생성하며, 다양한 스타일(실사, 카툰, 수묵화, 사이버펑크 등)을 지원합니다.
+- **스타일 전이**: 이미지를 지정한 예술 스타일로 변환합니다.
+- **이미지 변형**: 참고 이미지를 바탕으로 유사한 스타일의 새 이미지를 생성합니다.
+- **해상도 향상**: 이미지 선명도와 세부 사항을 강화합니다.
+
+**2. Qwen Image Edit - 이미지-이미지(Image-to-Image) 모델**
+
+기존 이미지 위에서 편집과 수정을 수행합니다. 자연어 지시를 통해 모델이 수정 의도를 이해하고 결과를 생성하게 합니다.
+
+**주요 능력:**
+
+- **부분 교체**: 이미지 속 어떤 물체나 인물을 교체합니다. 예: “배경을 바닷가로 바꿔줘”.
+- **요소 제거**: 이미지에서 필요 없는 요소를 제거합니다.
+- **스타일 변환**: 이미지에 필터나 예술 효과를 추가합니다.
+- **이미지 확장**: 이미지 경계를 확장하고 새 내용을 생성합니다.
+- **지능형 보정**: 자동 미화, 빛과 그림자 조정, 결함 복구.
+
+
+
+
+
+
+
+**왜 Qwen Image 시리즈를 선택할까요?**
+
+- **중국어 최적화**: 중국어 프롬프트 이해가 더 정확해 중국 사용자를 위한 작업에 적합합니다.
+- **낮은 비용**: 국제 경쟁 제품과 비교해 가격이 더 저렴합니다.
+- **빠른 속도**: 생성 효율이 높고 응답 시간이 짧습니다.
+- **안정적인 품질**: 이커머스와 소재 장면에서 안정적이고 신뢰할 만한 결과를 보입니다.
+- **다양한 스타일**: 여러 예술 스타일과 창의적 효과를 지원합니다.
+
+**대표 적용 장면:**
+
+- 이커머스: 대표 이미지, 상세 페이지 이미지, 프로모션 포스터 생성
+- 소셜미디어: 아바타, 이모티콘, 첨부 이미지 생성
+- 디자인: 콘셉트 이미지, 소재 이미지, 배경 이미지 빠르게 제작
+- 마케팅: 광고 이미지, 이벤트 banner, 명절 포스터 제작
+ :::
+
+[SiliconFlow](https://siliconflow.cn/) 공식 웹사이트를 확인합니다. 왼쪽에는 “Playground” 섹션이 있으며, API 호출 없이 여러 모델을 시험해 볼 수 있습니다. 웹페이지 상단에는 “Filters” 버튼이 있습니다. 클릭하면 오른쪽 모델 목록을 필터링할 수 있습니다.
+
+“Image”를 선택하면 현재 지원하는 모든 텍스트-이미지 모델만 보입니다. 이 경우 우리는 Qwen/Qwen-Image를 사용할 것입니다.
+
+
+
+모든 설정이 끝나면 해당 이미지 생성 API 문서를 참고해야 합니다. 공식 문서 페이지에서 “API Reference”라고 표시된 부분을 찾을 수 있습니다. 그것을 클릭한 뒤 [이미지 생성 API 섹션](https://docs.siliconflow.cn/cn/api-reference/images/images-generations)으로 이동해 관련 요청 예시를 찾습니다.
+
+아래 요청 예시와 API KEY를 함께 AI IDE에 보내면 이미지 생성 기능을 구현할 수 있습니다.
+
+```bash
+curl --request POST \
+ --url https://api.siliconflow.cn/v1/images/generations \
+ --header 'Authorization: Bearer ' \
+ --header 'Content-Type: application/json' \
+ --data '
+{
+ "model": "Qwen/Qwen-Image-Edit-2509",
+ "prompt": "an island near sea, with seagulls, moon shining over the sea, light house, boats int he background, fish flying over the sea"
+}
+'
+```
+
+여기의 모델은 Qwen/Qwen-Image 또는 Qwen/Qwen-Image-Edit-2509를 사용할 수 있습니다.
+
+::: details 이미지 편집 참고 코드
+
+아래 코드와 key를 함께 복사해 AI IDE에 보내세요.
+
+```python
+import requests
+import os
+from typing import Dict, Any, Optional
+
+SILICONFLOW_API_KEY: str = ""
+SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/images/generations"
+QWEN_IMAGE_EDIT_MODEL: str = "Qwen/Qwen-Image-Edit-2509"
+
+def generate_image_edit(
+ prompt: str,
+ image: Optional[str] = None,
+ image2: Optional[str] = None,
+ image3: Optional[str] = None,
+ negative_prompt: Optional[str] = None,
+ cfg: Optional[float] = 4.0,
+ seed: Optional[int] = None
+) -> Optional[Dict[str, Any]]:
+ payload: Dict[str, Any] = {
+ "model": QWEN_IMAGE_EDIT_MODEL,
+ "prompt": prompt,
+ }
+ if image:
+ payload["image"] = image
+ if image2:
+ payload["image2"] = image2
+ if image3:
+ payload["image3"] = image3
+ if negative_prompt:
+ payload["negative_prompt"] = negative_prompt
+ if cfg is not None:
+ payload["cfg"] = cfg
+ if seed is not None:
+ payload["seed"] = seed
+
+ headers: Dict[str, str] = {
+ "Authorization": f"Bearer {SILICONFLOW_API_KEY}",
+ "Content-Type": "application/json"
+ }
+
+ try:
+ response = requests.post(SILICONFLOW_BASE_URL, json=payload, headers=headers)
+ response.raise_for_status()
+ return response.json()
+ except requests.exceptions.RequestException as e:
+ print(f"Error generating image: {e}")
+ return None
+
+def save_image_from_url(image_url: str, output_path: str = "image.png") -> bool:
+ try:
+ response = requests.get(image_url)
+ response.raise_for_status()
+ os.makedirs(os.path.dirname(output_path) if os.path.dirname(output_path) else ".", exist_ok=True)
+ with open(output_path, "wb") as f:
+ f.write(response.content)
+ print(f"Image saved successfully to: {output_path}")
+ return True
+ except requests.exceptions.RequestException as e:
+ print(f"Error downloading image: {e}")
+ return False
+ except Exception as e:
+ print(f"Error saving image: {e}")
+ return False
+
+prompt: str = "하늘을 저녁으로 바꾸고, 달과 별이 보이는 몽환적인 스타일로 만들어 주세요"
+negative_prompt: str = "흐림, 저품질, 왜곡"
+image_url: str = "https://inews.gtimg.com/om_bt/Os3eJ8u3SgB3Kd-zrRRhgfR5hUvdwcVPKUTNO6O7sZfUwAA/641"
+image2_url: Optional[str] = None
+image3_url: Optional[str] = None
+
+cfg: float = 4.0
+seed: int = 12345
+output_path: str = "edited_image.png"
+
+print(f"Generating edited image with prompt: {prompt}")
+print(f"Input image: {image_url}")
+print(f"CFG: {cfg}, Seed: {seed}")
+print("-" * 50)
+
+result = generate_image_edit(
+ prompt=prompt,
+ image=image_url,
+ image2=image2_url,
+ image3=image3_url,
+ negative_prompt=negative_prompt,
+ cfg=cfg,
+ seed=seed
+)
+
+if result and "images" in result:
+ images = result["images"]
+ if images and len(images) > 0:
+ image_url_result = images[0]["url"]
+ print(f"Image edit generated successfully. URL: {image_url_result}")
+ success = save_image_from_url(image_url_result, output_path)
+ if success:
+ print(f"Image saved to: {output_path}")
+ else:
+ print("Failed to save image to local file")
+ else:
+ print("No images found in response")
+else:
+ print("Image generation failed")
+ if result:
+ print(f"Response: {result}")
+```
+
+:::
+
+# 부록: “현재 더 강한” AI 모델을 찾는 법
+
+텍스트 모델(흔히 “대형 언어 모델”이라고도 함)의 발전 속도는 매우 빠릅니다. 우리는 항상 우리가 사용하는 모델이 더 나은 성능을 보이는 모델 중 하나인지 확인해야 합니다. 아래 두 웹사이트를 통해 “지금 사람들이 많이 쓰고, 평가도 좋은 모델”을 편하게 볼 수 있습니다.
+
+일반적으로 이런 웹사이트는 **“모델 경기장”** 으로 이해할 수 있습니다. 두 모델의 출력을 나란히 놓고, 당신이 더 마음에 드는 쪽에 투표합니다. 표가 많은 모델은 보통 더 많은 사람이 “더 쓰기 좋다”고 느낀다는 뜻입니다.
+
+또한 이런 대형 모델 경기장에서 가끔 신비로운 익명 모델(“Unknown Model”)을 볼 수도 있습니다. 이는 보통 누군가 “내부 테스트 모델”을 몰래 넣어 블라인드 테스트를 하고 있다는 뜻입니다. 더 강한 능력을 미리 체험할 기회일 수도 있습니다.
+
+## LMArena
+
+웹사이트:
+
+LMArena는 “다수의 사람이 어떤 모델의 답변을 더 선호하는지” 판단하는 데 더 적합합니다. 투표가 많고 점수가 높을수록 보통 실제 사용 장면에서 더 안정적이라는 뜻입니다.
+
+간단한 사용법은 다음과 같습니다.
+
+1. 순위표(Leaderboard)를 바로 봅니다.
+2. 먼저 작업 방향을 하나 선택합니다. 예: 일반 대화 / 프로그래밍 / 비전.
+3. Top 3 안에서 사용할 수 있는 것을 고릅니다. 접근 가능하고, 가격을 감당할 수 있고, 지연 시간도 받아들일 수 있어야 합니다.
+
+
+
+## Artificial Analysis
+
+웹사이트:
+
+Artificial Analysis는 “효과 / 가격 / 속도”를 같은 표에서 비교하는 데 더 적합합니다. 모델 선택을 위한 매개변수 표로 볼 수 있습니다.
+
+자주 쓰는 방법은 다음과 같습니다.
+
+1. 관심 있는 모델 범주를 찾습니다. 텍스트 / 이미지 생성 등.
+2. 품질 지표(Quality) + 가격(Price) + 지연/처리량(Latency/Throughput)을 봅니다.
+3. 제품에 가장 잘 맞는 “종합 가성비” 모델을 선택합니다.
+
+::: tip ✅ 제안
+“어떤 모델이 더 강한가”를 감으로 논쟁하지 마세요. 더 믿을 만한 방법은 같은 입력 묶음으로 2-3개 모델을 동시에 테스트하고, 순위표와 가격을 함께 고려해 결정하는 것입니다.
+:::
+
+## 요약
+
+여러 AI 서비스를 연결할 때 API를 지나치게 복잡하게 생각할 필요는 없습니다. 다음 몇 가지 핵심 개념만 잡으면 대부분의 장면에 대응할 수 있습니다.
+
+**API의 본질은 통신 다리입니다.** 하는 일은 간단합니다. 당신의 요청을 보내고, 모델의 응답을 다시 가져옵니다. 뒤에서 무슨 일이 일어나는지 신경 쓸 필요는 없습니다. 요청 형식만 올바르게 구성하면 됩니다.
+
+**SDK는 API의 포장입니다.** API가 raw 인터페이스라면, SDK는 준비된 도구 상자입니다. 요청 서명, 오류 처리, 파라미터 검증 같은 번거로운 세부 사항을 대신 처리합니다. 일상 개발에서는 직접 API를 호출하기보다 SDK를 우선 선택하면 많은 번거로움을 줄일 수 있습니다.
+
+**문서를 읽을 때는 세 가지만 보면 충분합니다**. 서비스 주소(endpoint), 신원 증명(API key), 그리고 호출 파라미터를 어떻게 채우는지입니다. 이 세 가지를 명확히 하면 연결은 시간문제입니다.
+
+나머지 작업은 IDE와 현대적인 개발 도구가 도와줄 것입니다. 비즈니스 로직에 집중하고, 하위 호출은 성숙한 SDK와 도구 체인에 맡기세요.
+
+# 5. 📚 과제: 첫 번째 AI 능력 통합하기
+
+
+
+
🚀 도전 과제: AI 능력을 워크벤치에 통합하기
+
+
+
+ 이번 수업의 프롬프트와 내용을 참고해 한 번의 완전한 폐쇄 루프를 완성하세요.
+
+
+
+
+ 완전한 폐쇄 루프 실습
+
+
AI 서비스 하나 선택 및 연결(LLM / 텍스트-이미지 / 이미지-이미지) → 프론트엔드와 백엔드 상호작용 구현 → 프로토타입에 통합
+
+
+
+ 결과 공유
+
+
기능 페이지를 스크린샷으로 찍어 모두에게 공유하세요.
+
+
+
+ 생각해 볼 질문
+
+
다음 절 “전체 프로젝트 실습”을 위한 공간을 남겨 두고 미리 생각해 보세요. 이 AI 능력들을 어떻게 조합해서 어떤 재미있는 기능을 만들 계획인가요?
+
+
+
+
+
+## 다음 단계
+
+다음 절에서는 흩어진 AI 능력들을 연결하고, 실제 비즈니스 장면과 결합해 완전한 제품 하나를 만듭니다.
+
+- 콘텐츠 기획, 상품 등록, 데이터 분석 등의 단계를 하나의 완전한 비즈니스 흐름으로 연결하기
+- 이번 수업에서 배운 AI 능력(LLM 문구 생성, 텍스트-이미지, 이미지 편집 등)을 실제 비즈니스 지점에 삽입하기
+- 고립된 demo가 아니라 진짜 사용할 수 있는 “이커머스 AI 워크벤치” 구현하기
+
+
diff --git a/docs/ko-kr/stage-1/introduction-to-ai-ide/index.md b/docs/ko-kr/stage-1/introduction-to-ai-ide/index.md
index aeba8b2..1c9b7e6 100644
--- a/docs/ko-kr/stage-1/introduction-to-ai-ide/index.md
+++ b/docs/ko-kr/stage-1/introduction-to-ai-ide/index.md
@@ -1,159 +1,1247 @@
----
-title: 'AI IDE 도구 익히기'
-description: 'Cursor, Claude Code, Trae 같은 AI IDE의 역할과 기본 사용 흐름을 한국어로 설명합니다.'
----
-# AI IDE 도구 익히기
+# 초급 2: AI 프로그래밍 도구 배우기
-AI IDE는 단순한 코드 편집기가 아닙니다. 프로젝트 폴더를 읽고, 파일을 만들고, 명령을 실행하고, 오류를 해석하며, 개발 흐름 전체를 도와주는 작업 환경입니다.
+## 이 장의 가이드
-이 장에서는 특정 도구 하나만 외우기보다, 대부분의 AI IDE에서 공통으로 쓰이는 사고방식과 작업 흐름을 익힙니다.
+
-AI IDE는 보통 다음 능력을 가집니다.
+
-- 프로젝트 파일 구조 읽기
-- 새 파일 생성 및 기존 파일 수정
-- 코드 설명
-- 오류 메시지 분석
-- 터미널 명령 제안
-- 리팩터링
-- 테스트나 빌드 실패 원인 추적
+앞에서 우리는 z.ai에서 AI 프로그래밍을 경험했습니다. 하지만 웹 버전에는 많은 제한이 있습니다. 언제든 저장하기 어렵고, 파일 관리가 불편하며, 복잡한 프로젝트를 만들기도 어렵습니다. 이번 장은 개발 환경을 자신의 컴퓨터로 옮겨, 진짜로 독립적으로 무언가를 만들 수 있게 돕습니다.
-중요한 점은 AI IDE가 **현재 프로젝트의 맥락**을 읽을 수 있다는 것입니다. 일반 챗봇에게 코드 조각을 붙여 넣는 것보다 훨씬 편합니다.
+먼저 IDE와 AI IDE가 정확히 무엇이 다른지, 왜 후자가 효율을 몇 배로 높일 수 있는지 이해합니다. 그런 다음 손잡고 따라 하는 방식으로 Trae를 사용해 로컬에서 스네이크 게임을 만들며, 설치부터 실행까지의 전체 흐름을 밟아 봅니다. 마지막으로 AI와 대화하는 실용적인 팁도 공유하여 시행착오를 줄입니다.
-## 2. 기본 작업 흐름
+이 장을 마치면 프로그래머와 비슷한 개발 흐름을 익히게 됩니다.
-### 2.1 폴더 열기
+::: tip 💡 심화 팁
+프로그래밍 기초가 어느 정도 있고 더 강력한 도구를 미리 사용하고 싶다면, [현대 CLI Coding 도구](../../stage-2/backend/modern-cli/)를 참고해 명령줄 방식으로 개발해 볼 수 있습니다.
+:::
-먼저 프로젝트 폴더를 엽니다. AI에게는 "이 폴더 안의 파일들을 기준으로 작업해 달라"고 요청합니다.
+
-```text
-이 프로젝트 구조를 먼저 읽고, 어떤 파일이 진입점인지 설명해 줘.
-아직 코드는 수정하지 말고 구조만 파악해 줘.
+
+
+
+
+
+
+## 1. 코드를 쓰려면 어떤 환경과 도구가 필요할까
+
+### 1.1 사고 전환: 문제가 생기면 먼저 AI에게 묻기
+
+여러 환경과 도구를 소개하기 전에, 먼저 **사고 습관을 바꿔야 한다는 점**을 알려 드립니다.
+
+전통적인 프로그래밍 학습에서는 Python 설치, Conda 설정, npm 설치 실패 해결 같은 일을 해야 할 때 보통 검색 엔진을 열고 튜토리얼을 찾아 단계별로 따라 했습니다. 중간에 오류가 나면 다시 오류 메시지를 검색하고, 여러 번 시도해야 했습니다.
+
+틀렸습니다! ❌
+
+AI 시대, 특히 AI IDE를 사용할 때는 핵심 원칙 하나를 기억하세요. **어떤 작업이든 먼저 AI에게 물어볼 수 있고, 심지어 직접 해 달라고 할 수도 있습니다.**
+
+- **환경 설치 방법을 모르나요?** 사이드바에서 AI에게 바로 물어보세요. “Python을 쓰고 싶은데 Python이 설치되어 있는지 확인하고, 없으면 설치를 도와줘.”
+- **네트워크에서 막혔나요?** 의존성 패키지 설치 중 계속 돌기만 하거나 오류가 나면 오류를 AI에게 바로 던지세요. “다운로드가 실패했어. 네트워크 문제일까? 중국 내 미러 소스로 바꿔줄 수 있어?”
+- **명령어가 기억나지 않나요?** Git 명령이나 Conda 명령을 억지로 외울 필요가 없습니다. AI에게 바로 말하세요. “demo라는 이름의 새 가상 환경을 만들어줘.”
+
+### 1.2 왜 환경과 도구가 필요할까
+
+“코드 몇 줄을 시험 삼아 써 보기”에서 “장기 유지보수가 가능한 프로젝트 만들기”로 넘어가면, 환경과 도구에 대한 요구는 완전히 달라집니다.
+
+이론적으로는 시스템에 기본으로 들어 있는 메모장으로도 코드를 쓸 수 있습니다. 하지만 문제는 금방 나타납니다.
+
+- **코드가 전부 검은 글자**라서 키워드, 문자열, 주석이 섞여 구조를 한눈에 보기 어렵습니다.
+- **지능형 힌트가 없어서** 모든 단어를 끝까지 직접 쳐야 하고, 글자 하나만 틀려도 반복해서 확인해야 합니다.
+- **파일이 많아지면 엉망이 됩니다**. 십여 개 파일을 오가다 보면 고쳐야 할 줄이 어디인지 자주 잃어버립니다.
+- **오류가 나면 추측만 할 수 있습니다**. 프로그램이 멈췄는데 어디가 문제인지 몰라 한 줄씩 로그를 찍어 보며 시행착오를 해야 합니다.
+
+따라서 IDE(통합 개발 환경)가 필요합니다. IDE는 코드를 여러 색으로 표시하고, 입력할 때 자동 힌트를 주며, 파일을 프로젝트 단위로 정리하고, 오류를 한 단계씩 추적할 수 있게 해 개발을 더 효율적이고 덜 오류 나게 만듭니다.
+
+## 2. IDE란 무엇이고 왜 필요할까
+
+::: info 예습 팁
+IDE가 무엇인지, 각 인터페이스 요소가 어떤 역할을 하는지 아직 익숙하지 않다면 [IDE 소개](/ko-kr/appendix/2-development-tools/ide-basics)를 먼저 읽고 IDE의 기본 개념과 흔한 기능을 예습하는 것이 좋습니다.
+:::
+
+초기 프로그래밍 시대에는 간단한 텍스트 편집기와 언어 처리기만 있으면 충분했습니다. 하지만 프로젝트 복잡도가 증가하면서 개발자들은 파일을 효율적으로 관리하고, 문법 강조와 디버깅을 지원하는 도구를 절실히 필요로 하게 되었고, 그래서 통합 개발 환경(IDE)이 등장했습니다.
+
+IDE는 “코드를 편집하고, 관리하고, 실행하고, 디버깅”하기 위해 특화된 프로그램으로 이해할 수 있습니다. 초기 IDE의 외형은 매우 “원시적”이었고, 거의 전부 키보드로 조작했습니다.
+
+
+
+터미널 인터페이스(Terminal) 이미지 출처: https://en.wikipedia.org/wiki/File:Emacs-screenshot.png
+
+`Vim`처럼 유명하고 기능이 성숙한 “내장형 IDE”는 서버 원격 조작에 자주 쓰입니다.
+
+
+
+더 효율적으로 작업하려면 마우스 조작을 지원하는 현대 IDE가 필요합니다. 보통 다음을 포함합니다.
+
+- **소스 코드 편집기**: 문법 강조, 자동 완성.
+- **빌드와 실행 도구**: 내장 컴파일러 / 인터프리터.
+- **디버거**: 중단점 디버깅, 변수 확인.
+
+현대 IDE는 Git 같은 도구도 내장하는 경우가 많습니다. 가장 인기 있는 것은 Microsoft의 **[Visual Studio Code (VS Code)](https://code.visualstudio.com/)** 입니다. 가볍고 확장 가능합니다. JetBrains 제품군 같은 전문 IDE도 있지만, 초보자에게는 VS Code가 가장 친절합니다.
+
+
+
+VS Code의 핵심 철학은 “모든 것은 플러그인”입니다. 플러그인 메커니즘으로 여러 언어를 지원합니다. Python 플러그인을 설치하면 Python IDE가 되고, C++ 플러그인을 설치하면 C++ IDE가 됩니다. 플러그인을 설치하지 않으면 고급 텍스트 편집기일 뿐입니다.
+
+
+
+심지어 Markdown 문서를 편집하는 데도 사용할 수 있습니다.
+
+
+
+정리하면 IDE는 개발자가 코드를 효율적으로 쓰고 프로그램을 실행하도록 돕는 도구 묶음입니다.
+
+더 구체적인 설명은 [부록의 가상 IDE 시각화 IDE 원리 부분](/ko-kr/appendix/2-development-tools/ide-basics)을 확인하세요.
+
+## 3. AI IDE와 일반 IDE는 무엇이 다를까
+
+일반 IDE(예: 원본 VS Code)는 본질적으로 “도구 상자”입니다.
+프로젝트를 열고, 코드를 쓰고, 실행하고, 디버깅할 수 있으며, 플러그인도 설치할 수 있습니다. 하지만 전제는 당신이 무엇을 해야 하고 어떻게 해야 하는지 스스로 알아야 한다는 것입니다.
+
+- 오류가 나면 직접 안내를 읽고, 어느 줄에 문제가 있는지 찾아야 합니다.
+- 새 페이지나 새 인터페이스를 추가하려면 직접 대응 파일을 찾고 코드를 써야 합니다.
+- 환경 설정이나 패키징을 하려면 직접 문서를 찾아 단계별로 조작해야 합니다.
+
+하지만 AI IDE에서는 대형 언어 모델을 바로 사용해 코딩과 파일 수정을 도울 수 있습니다.
+
+- “로그인 페이지를 만들어줘”라고 직접 말하면, 기본 코드 구조를 먼저 생성합니다.
+- 오류 정보와 관련 코드를 던지면, 먼저 원인을 분석하고 수정 제안을 냅니다.
+- 당신이 확인하면 파일을 자동으로 새로 만들고, 코드를 일괄 수정하고, 여러 파일에 걸친 반복 작업을 처리합니다.
+
+예를 들어 코드 한 부분을 선택하고 “리팩터링해줘” 또는 “주석을 추가해줘”라고 할 수 있습니다. 사이드바에서 “이 프로젝트는 어떻게 설계되어 있나요?”라고 물을 수도 있습니다. `@파일명` 또는 `@전체 프로젝트`로 참고 범위를 지정하면, 한 문장으로 새 파일 생성, 코드 작성, 실행 같은 번거로운 작업을 자동 완료할 수 있습니다.
+
+최신 VS Code에는 이미 대형 언어 모델 어시스턴트가 내장되어 있습니다. 전체 코드 저장소, 특정 파일, 심지어 특정 함수에 대해 모델과 직접 대화할 수 있습니다. 이전에 Web에서 자동 코드 작성 도구를 사용했던 것처럼, 요구사항을 프롬프트 형태로 내장 코딩 Agent에게 보내면 필요한 기능 구현, 파일 생성, 코드 수정, 환경 설정 등을 자동으로 도와줍니다.
+
+VS Code를 다운로드해 설치한 뒤, 오른쪽 위의 사이드바 입구를 클릭해 AI 기능 영역을 열고 이러한 능력을 체험할 수 있습니다.
+
+
+
+다만 VS Code가 AI 능력이 가장 강한 IDE는 아닙니다. 대량의 AI 보조 코딩이 필요한 상황에서는 보통 “더 똑똑하고 효율이 높은” 도구를 쓰고 싶어 합니다. 좋은 AI IDE는 코드 작성과 Bug 수정 시간을 크게 줄여 줍니다. 아래에서는 현재 비교적 인기 있는 AI IDE 몇 가지를 소개합니다. 취향에 맞게 아무 AI IDE나 선택해 사용해도 됩니다.
+
+VS Code는 오픈소스이기 때문에(누구나 소스 코드를 다운로드하고 직접 컴파일 가능), 현재 시장의 대부분 AI IDE는 VS Code를 기반으로 2차 개발되어 있습니다. 그래서 “여러 IDE를 많이 배워야 한다”고 걱정할 필요는 없습니다. **VS Code의 기본 사용법만 익숙해지면** 이런 AI IDE로 이동할 때 다시 배울 필요가 크지 않습니다.
+
+일반적으로 서로 다른 AI IDE의 차이는 주로 네 가지에 집중됩니다. 가격, 사용할 수 있는 모델 종류(일부 고급 모델은 특정 지역에서 제한될 수 있음), Agent의 능력(코드 작성을 도울 때의 지능 수준과 실행 능력), 그리고 실행 속도와 성능입니다. 실제 테스트 결과에 따라 선택하면 됩니다. 자신에게 맞는 것이 가장 좋습니다.
+
+> 전형적인 AI IDE는 보통 다음 핵심 능력을 갖습니다.
+>
+> - 지능형 코드 생성과 완성: 전통 IDE에서는 보통 몇 글자를 입력해 변수명이나 함수명을 완성합니다. 현대 AI IDE에서는 몇 줄의 의사코드나 간단한 요구 설명을 쓰면 IDE가 전체 로직을 자동 완성하고, 지시에 따라 긴 코드나 전체 코드 블록을 바로 생성할 수 있습니다.
+> - 코드 이해와 질의응답: IDE는 특정 코드 조각, 특정 파일, 심지어 전체 프로젝트 디렉터리 구조에 관한 질문을 이해하고 답할 수 있습니다.
+> - 코드 리팩터링과 최적화: IDE는 당신의 의도에 따라 지정 코드 조각의 구현 로직을 다시 쓰거나 최적화할 수 있습니다.
+> - 테스트 자동 생성: IDE는 여러 함수와 모듈에 대한 테스트 코드를 자동 생성하여 필요한 테스트를 편하게 할 수 있습니다.
+> - Agent식 작업 실행: 지능형 Agent는 코드 생성, 패키징, 설치, 실행, 수정을 자동으로 수행할 수 있으며, 많은 작업에서 초급 소프트웨어 엔지니어의 일을 일부 대체할 수 있습니다.
+
+::: details Antigravity
+
+### [Antigravity](https://antigravity.google/)
+
+Antigravity는 Google이 2025년 11월 Gemini 3와 함께 발표한 새로운 AI IDE이며, “Agent-First”(지능형 에이전트 우선) 개발 방식을 채택합니다. 전통적인 AI 보조 코딩과 달리 Antigravity는 AI 에이전트를 “능동적 실행자”로 두어 편집기, 터미널, 브라우저 같은 도구를 직접 조작하고 더 많은 “실행”, “기획”, “검증” 작업을 맡게 합니다. 개발자는 상위 의도만 제시하면 에이전트가 작업을 자동 분해하고, 계획을 세우고, 코드를 실행하고, 테스트를 돌리고, 산출물을 생성합니다. Gemini 3 Pro, Claude Sonnet 4.5 등 여러 모델 전환을 지원하며, 현재 공개 프리뷰 형태로 제공되고 Windows, macOS, Linux 전 플랫폼을 지원합니다.
+:::
+
+::: details Trae
+
+### [Trae](https://www.trae.ai/)
+
+
+
+Trae는 ByteDance가 출시한 AI 프로그래밍 어시스턴트이며 100개 이상의 프로그래밍 언어를 지원하고 주요 IDE에 통합될 수 있습니다. 기능에는 자연어로 코드 생성, 자동 디버깅, 디자인 시안을 React/Vue 컴포넌트로 변환하기 등이 포함됩니다. 2025년 8월 업데이트 이후 Trae에는 지능형 의존성 가져오기, 이름 변경 제안, 작업 목록 관리 등의 기능이 추가되었습니다. SOLO 모드도 백엔드 코드 생성과 기술 아키텍처 문서 편집을 지원하기 시작했습니다.
+:::
+
+::: details Cursor
+
+### [Cursor](https://cursor.com/)
+
+Cursor는 Anysphere가 개발한 AI 코드 편집기이며 VS Code 기반으로 커스터마이즈되어, 대규모 코드 저장소와 다중 파일 협업 장면을 중점적으로 최적화했습니다. GPT-4o, Claude 3.7 등 모델을 지원합니다. 2025년에 출시된 Claude Max 모드는 수백만 줄 코드 수준의 프로젝트를 처리할 수 있습니다. Pro 버전은 요청 횟수 제한을 없애 복잡한 기업급 프로젝트에 매우 적합합니다.
+
+현재 Cursor는 “프론트엔드 인터페이스가 있는 AI IDE” 중 종합 경험이 가장 좋은 도구 중 하나라고 할 수 있습니다. 사용자 수가 많고 기능 반복 주기도 빠릅니다. 가장 큰 단점은 가격이 높다는 점입니다. Pro 버전은 월 약 20달러가 필요합니다.
+
+
+:::
+
+::: details Qoder
+
+### [Qoder](https://qoder.com/)
+
+Qoder는 Alibaba가 출시한 AI IDE이며 “투명한 협업”과 “강화된 컨텍스트 엔지니어링 능력”을 강조합니다. Action Flow를 통해 작업을 여러 단계로 분해하고 AI의 실행 과정을 실시간으로 추적할 수 있습니다. 또한 다중 모델 동적 라우팅과 작업 상태 머신 관리를 지원하므로, 중대형 프로젝트에서 아키텍처 거버넌스를 하거나 레거시 시스템을 “역공학” 분석하는 데 매우 적합합니다.
+
+
+:::
+
+::: details CodeBuddy
+
+### [CodeBuddy](https://www.codebuddy.com/)
+
+CodeBuddy는 Tencent Cloud가 출시한 AI 프로그래밍 도구이며 중국어 지시에 대한 지원과 기업급 규정 준수 능력을 강조합니다. 코드 완성, 일괄 코드 리뷰, 다중 모델 전환 등의 기능을 제공합니다. 그중 Craft 지능체는 다중 파일 코드 생성과 API 통합을 구현할 수 있습니다. 기업 버전은 사유화 배포를 지원하고 중국의 3급 등급보호 인증을 통과했으므로 금융, 의료 등 데이터 보안 요구가 높은 업종에 적합합니다.
+
+
+:::
+
+::: details VS Code + Cline
+
+### VS Code + [Cline](https://cline.bot/)
+
+Cline은 VS Code(Visual Studio Code)의 AI 프로그래밍 Agent 플러그인입니다. 서로 다른 API 엔드포인트를 설정해 사용하는 대형 모델을 유연하게 바꿀 수 있습니다. Cline은 멀티모달 입력, MCP 도구 확장, 비용 모니터링을 지원하며, 모든 작업은 사용자 확인 후 실행됩니다. 아이디어를 빠르게 검증하거나 기존 개발 흐름에 통합하는 데 매우 적합합니다. 기본 기능은 무료이고, 기업 버전은 사유 환경에서 모델 배포를 지원합니다.
+
+
+
+
+:::
+
+::: details Kiro
+
+### [Kiro](https://kiro.dev/)
+
+Kiro는 AWS(Amazon Web Services)가 출시한 AI 프로그래밍 IDE이며 Amazon Bedrock과 AWS 클라우드 서비스 생태계에 깊게 통합되어 있습니다. Claude, Nova 등 여러 대형 모델을 지원하고, AWS 클라우드 서비스와 긴밀히 통합해야 하는 개발 장면에 특히 적합합니다. Kiro는 지능형 코드 생성, 자동화 테스트, AWS 리소스(Lambda, S3, DynamoDB 등)와의 매끄러운 연결 능력을 제공하여 클라우드 네이티브 애플리케이션 개발에 독특한 장점을 가집니다.
+
+> **비고**: Anthropic Claude 관련 모델을 사용하고 싶다면 IDE로 Cursor, Kiro 또는 Antigravity를 사용해야 합니다. 이 IDE들은 Anthropic과 공식 협력하거나 깊게 통합되어 있어 더 안정적이고 완전한 Claude 모델 경험을 제공할 수 있습니다.
+:::
+
+
+
+
+
+
+
+## 4. 실습: AI IDE로 로컬에서 스네이크 게임 생성하기
+
+앞에서 말한 것은 주로 “개념”과 “차이”였습니다. 이 절에서는 한 번의 완전한 실습을 통해 추상 개념을 구체적인 조작으로 옮깁니다. **빈 폴더 새로 만들기 → AI IDE로 열기 → 사이드바 채팅에서 React로 스네이크 게임을 처음부터 만들게 하기.** 여기서는 위에서 소개한 Trae를 예로 들며, 먼저 Trae를 설치하고 간단히 이해해야 합니다.
+
+::: tip 💡 작은 팁: 웹에서 로컬로 매끄럽게 이어가기
+이전에 z.ai나 다른 웹 기반 AI 프로그래밍 플랫폼에서 프로젝트를 개발한 적이 있다면, 코드를 로컬로 다운로드한 뒤 AI IDE로 열어 계속 개발할 수 있습니다. 이렇게 하면 이전 성과를 보존하면서 로컬 IDE의 더 강한 AI 보조 능력도 누릴 수 있습니다.
+
+조작 단계는 간단합니다.
+1. z.ai 같은 플랫폼에서 다운로드 버튼을 클릭해 프로젝트를 로컬에 저장합니다.
+2. 압축을 푼 뒤 Trae/Cursor 같은 AI IDE로 해당 폴더를 엽니다.
+3. 사이드바에서 AI와 계속 대화하며 프로젝트를 반복 개선합니다.
+:::
+
+### 4.1 준비 작업: Trae 설치하고 이해하기
+
+#### 4.1.1 Trae란 무엇인가
+
+Trae의 전체 이름은 “The Real AI Engineer”로 이해할 수 있으며, ByteDance가 개발한 적응형 AI 통합 개발 환경(IDE)입니다. 인기 있는 VS Code 위에 구축되어 있습니다. 즉 이전에 VS Code에 이미 익숙하다면 Trae를 사용할 때 인터페이스 배치나 기본 조작 모두 매우 익숙하고 편안하게 느껴질 것입니다.
+
+Trae의 핵심 목표는 개발자의 “지능형 프로그래밍 파트너”가 되는 것입니다. AI 능력을 깊게 통합하여 대량의 반복 작업을 자동 처리하고, 더 직관적이고 효율적인 개발 경험을 제공합니다. 단순한 “코드 완성 도구”가 아니라, 프로젝트 생성, 코드 작성, 디버깅, 테스트, 배포까지 전체 개발 워크플로에서 도움을 주려 합니다.
+
+#### 4.1.2 Trae 설치하기
+
+Trae는 국제판과 중국판으로 나뉩니다. 국제판은 해외 네트워크에 접근할 수 있어야 하지만 GPT-5 같은 최신 해외 모델을 사용할 수 있습니다. 중국판은 주로 GLM, Qwen, Kimi 같은 중국 내 최신 대형 모델을 지원합니다.
+
+국제판 다운로드 주소: https://www.trae.ai/
+중국판 다운로드 주소: https://www.trae.cn/
+
+##### Trae 가격과 사용 방식
+
+::: info 💡 버전 선택 팁(입문자는 CN판 추천)
+- **완전 초보 입문에는 중국판(CN판, trae.cn) 다운로드를 강력히 추천합니다**. 현재 사용 경험이 더 좋고 기본 기능이 무료이며 해외 네트워크가 필요 없습니다.
+- GPT-5 같은 해외 모델을 사용해야 하고 네트워크 조건이 허용된다면 국제판을 선택할 수 있습니다.
+- 이미 서드파티 모델의 API Key가 있다면, 서드파티 모델 연결로 비용을 유연하게 제어할 수 있습니다.
+:::
+
+> 💡 **현재 OpenRouter 무료 모델로 테스트하는 것을 추천합니다**
+>
+> 튜토리얼 작성 시점(2026년 2월 12일) 기준, StepFun 모델은 아직 무료로 시험 사용할 수 있습니다. 구체적으로는 아래 4.2 절의 모델 연결 방식을 참고해 `stepfun/step-3.5-flash:free`를 연결하세요.
+
+Trae의 비용과 사용 방식에는 다음 선택지가 있습니다.
+
+- **중국판 CN판(강력 추천)**: 기본 사용은 무료이며, 현재 전체 사용 효과가 국제판보다 좋고 완전 초보 입문에 매우 적합합니다. 사용자가 많아 가끔 대기해야 할 수 있습니다.
+- **국제판**: 구독 가격은 월 약 3달러 정도이며 GPT-5 같은 해외 모델에 접근할 수 있지만 해외 네트워크 접근이 필요합니다.
+- **서드파티 모델 연결**: 이미 중국 내 대형 모델의 Token API(DeepSeek, Tongyi Qianwen, Kimi 등)가 있다면 Trae의 서드파티 모델 설정 기능으로 이러한 API를 연결해 사용할 수 있습니다. 주요 클라우드 서비스 업체(Alibaba Cloud, Tencent Cloud, Baidu Cloud 등)는 보통 Coding Plan 구독 플랜을 제공하며, 구매 후 더 저렴한 가격으로 대형 모델 API를 사용할 수 있습니다. 이렇게 하면 원하는 모델을 자유롭게 선택하면서 사용 비용도 제어할 수 있습니다.
+
+초보자는 중국 CN판 무료 버전부터 경험하는 것을 권장합니다. 다운로드 주소는 https://www.trae.cn/ 입니다. 현재 CN판 사용 효과가 더 좋고 완전히 무료입니다. 대기 문제가 있거나 더 안정적인 서비스가 필요하다면 서드파티 모델을 연결하고 해당 클라우드 업체의 Coding Plan을 구매하는 것을 고려할 수 있습니다.
+
+#### 4.1.3 Trae 인터페이스 소개
+
+인터페이스 형태로 보면 Trae는 우리가 일상적으로 사용하는 VS Code와 매우 비슷합니다. 왼쪽 리소스 관리자, 가운데 편집 영역, 오른쪽 확장 패널이라는 고전적인 3열 배치를 사용합니다.
+
+
+
+오른쪽 사이드바가 Copilot 상호작용 창이며, Agent 창으로 이해할 수도 있습니다. 보이지 않는다면 Trae 오른쪽 위의 사이드바 아이콘을 클릭해 열 수 있습니다.
+
+
+
+사이드바를 열면 `Builder` 옵션이 보입니다. 이것이 Agent 모드입니다. 간단히 이해하면 z.ai의 “로컬 버전”과 같으며, 내 컴퓨터 환경을 조작하고 실행 환경을 설치하고 웹페이지를 여는 일을 도와줄 수 있습니다.
+
+
+
+“Builder”를 클릭하면 “Chat” 모드와 “Builder with MCP” 모드가 보입니다.
+
+- **Chat 모드**: 주로 현재 폴더 안의 코드와 대화하거나 일반 채팅 모델처럼 사용하는 데 쓰입니다. 왼쪽 위의 “File” 메뉴로 폴더를 열 수 있으며, 이 폴더 안에서 편집 작업을 진행합니다. 이 경우 Builder가 만들거나 수정하는 파일은 모두 이 폴더 내부에서만 발생합니다.
+- **Builder with MCP 모드**: Agent에게 더 많은 사용 가능한 도구를 제공합니다. 예를 들어 언어 모델과 다른 소프트웨어를 연결하거나 날씨를 조회하는 등의 도구입니다. 간단히 말해 MCP는 언어 모델이 여러 외부 도구를 더 편하게 호출할 수 있게 해 줍니다.
+
+
+
+아래 영역에는 모델 선택 옵션도 보입니다. 클릭하면 현재 사용하는 대형 모델을 바꿀 수 있습니다. 중국판에서는 Kimi k2나 GLM 같은 중국 모델을 선택할 수 있습니다. 국제판 Trae를 사용한다면 ChatGPT나 Claude 같은 해외 모델도 선택할 수 있습니다. 다만 중국 내 대형 모델도 매우 빠르게 발전하고 있어 Kimi, Qwen, GLM 등은 많은 작업에서 Claude 3.5 또는 3.7에 가까운 실제 경험을 보여 주며, 일상 개발에는 충분합니다. 여기서는 국제판이나 중국판 중 하나를 반드시 사용하라고 강제하지 않습니다.
+
+**주의할 점은 Auto 모드(자동 모델 선택)를 추천하지 않는다는 것입니다. 국제판이라면 Gemini 또는 GPT 모델을 추천하고, 중국판이라면 Kimi k2, Minimax, GLM 같은 중국 모델을 시도해 보기를 추천합니다.** 모델마다 적합한 장면이 다르며, 누가 반드시 더 좋다는 식의 교조적인 답은 없습니다. 서로 다른 작업에서 어려움을 만나 해결되지 않을 때 모델을 바꿔 보고, 여러 번 테스트해 자신만의 최적 실험 결과를 얻을 수 있습니다.
+
+
+
+이상이 Trae에 대한 간단한 소개입니다. 이제 이전에 z.ai에서 했던 조작을 돌아보고, Trae에서 같은 일을 시도해 볼 수 있습니다.
+
+### 4.2 첫 번째 단계: 빈 폴더를 새로 만들고 AI IDE로 열기
+
+본격적으로 시작하기 전에 먼저 깨끗한 프로젝트 작업 디렉터리를 준비해야 합니다.
+이 절의 예시에서는 로컬에 `snake-game-react`라는 이름의 빈 폴더를 만들 수 있습니다.
+
+그다음 설치해 둔 AI IDE를 열고 시작 화면에서 폴더 열기 또는 Open Folder를 선택해 이 빈 폴더를 프로젝트 루트 디렉터리로 가져옵니다. 폴더를 IDE 창으로 직접 끌어다 놓아 열 수도 있습니다. 이때 왼쪽 리소스 관리자에는 아무 코드 파일도 나타나지 않습니다. 완전히 빈 프로젝트 상태에서 시작하고 있다는 뜻입니다.
+
+::: details 📚 선택: 클라우드 서비스 업체의 API 또는 Coding Plan 연결하기
+
+이 절에서는 더 안정적이고 더 자주 모델을 호출하기 위해 클라우드 서비스 업체의 API 또는 Coding Plan을 연결하는 방법을 소개합니다. 마지막에는 Trae에서 연결하는 스크린샷을 제공합니다.
+
+**Coding Plan이란 무엇인가**
+
+Coding Plan은 주요 클라우드 서비스 업체가 출시한 구독 플랜입니다. 구매 후 일정 기간 해당 업체의 대형 모델 API를 **무제한 또는 높은 빈도로** 사용할 수 있습니다. Token 단위 과금 방식과 비교하면 Coding Plan은 “월정액 패키지”에 더 가깝습니다. 고정 비용을 한 번 내면 매번 호출 비용을 걱정하지 않고 마음껏 사용할 수 있습니다.
+
+**왜 Coding Plan을 구매해야 할까**
+
+직접 API로 대형 모델을 호출할 수 있는데 왜 Coding Plan을 구매해야 하는지 궁금할 수 있습니다. 주요 이유는 다음입니다. **계속 사용할 수 있음**: Coding Plan의 핵심 장점은 언제든 자주 대형 모델을 호출할 수 있고, 많이 썼을 때 비용이 폭발할까 걱정하지 않아도 되며, 과금표를 자주 확인할 필요도 없다는 점입니다.
+
+**추천 중국 내 클라우드 서비스 Coding Plan**
+
+아래는 중국 내 주요 클라우드 서비스 업체가 제공하는 Coding Plan 추천 선택지입니다.
+
+- Zhipu AI(BigModel Plan): https://bigmodel.cn/glm-coding
+- Volcengine(ByteDance Cloud AI Plan): https://www.volcengine.com/activity/codingplan
+
+> 💡 **대형 모델 API를 바로 연결할 수도 있습니다**
+> Coding Plan 외에도 Add Model을 통해 각 대형 모델의 API를 직접 연결할 수 있습니다. 아래의 OpenRouter StepFun 무료 API 연결 방식을 참고해 API를 Trae에 연결해 사용할 수 있습니다. 테스트 결과 기본 프로그래밍 요구를 충족할 수 있습니다.
+> 충전이 필요하다면 먼저 10위안 정도만 충전해 얼마나 쓸 수 있는지 느껴 보기를 권장합니다. 예를 들어 DeepSeek 같은 가성비 좋은 모델이 있습니다.
+
+**Coding Plan 연결 방법**
+
+Coding Plan 연결 단계는 매우 간단하며 몇 분이면 완료할 수 있습니다.
+
+1. 선택한 클라우드 서비스 업체 공식 사이트에 방문합니다. 예: Zhipu AI https://bigmodel.cn/glm-coding , Volcengine https://www.volcengine.com/activity/codingplan
+2. 계정을 등록하고 로그인합니다.
+3. “가격” 또는 “Coding Plan” 페이지를 찾습니다.
+4. 자신에게 맞는 요금제를 선택하고 결제합니다.
+5. 결제 성공 후 API Key 또는 Plan ID를 받습니다.
+
+::: tip 🎯 사용자 지정 모델 추천
+
+Trae에서 사용자 지정 모델을 연결할 때는 **기본적으로 OpenRouter 방식을 추천합니다**. OpenRouter는 통합 API 인터페이스를 제공하여 여러 대형 언어 모델을 편리하게 연결할 수 있습니다.
+
+**2026년 2월 12일 기준, StepFun의 무료 API도 사용할 수 있습니다.**
+
+- **`stepfun/step-3.5-flash:free`**: StepFun이 제공하는 무료 모델이며 Trae에 직접 연결해 사용할 수 있습니다.
+
+**기타 무료 모델:**
+
+- **`openrouter/free`**: 무료 LLM API를 기본으로 사용하는 모델 옵션입니다. Trae의 Custom Model 연결에서 바로 사용할 수 있고, 모델 ID에 그대로 쓰면 됩니다. 비용 없이 AI 프로그래밍 기능을 경험할 수 있습니다.
+
+이 무료 선택지는 초보자가 경험하기에 매우 적합합니다. 실제 프로덕션 환경에 투입하기 전, 먼저 이런 무료 방식으로 AI IDE의 작업 흐름을 익힐 수 있습니다.
+
+**선택: 대형 모델 호출 API 연결하기(DeepSeek 예시)**
+
+1. DeepSeek 플랫폼 방문: https://platform.deepseek.com/usage
+2. 계정 등록 및 로그인
+3. 충전 페이지에서 10위안 Token 패키지 구매
+4. 충전 성공 후 API Keys 페이지에서 API Key 생성 및 복사
+5. Trae에서 **"Add Model"** 을 클릭하고 DeepSeek을 찾아 대응 모델을 선택한 뒤 API Key를 입력하면 사용할 수 있습니다.
+
+아래 인터페이스를 통해 성공적으로 추가할 수 있습니다. 모델 선택 옵션을 본 뒤 **반드시 맨 아래까지 스크롤**해야 합니다. 아래에 “사용자 지정 모델”이 있고, 클릭하면 모델 ID를 입력할 수 있습니다. 이때 위 추천 모델 ID인 `stepfun/step-3.5-flash:free` 등을 그대로 입력하면 됩니다. 동시에 아래의 Key 얻기를 클릭해 공식 사이트로 이동하고 해당 API Key를 받아 입력하면 정상 사용 가능합니다.
+
+
+
+
+:::
+
+### 4.3 두 번째 단계: 사이드바에서 채팅하며 AI가 React로 스네이크 게임을 설계하게 하기
+
+이제 AI 채팅 사이드바를 엽니다. 보통 `Ctrl+L`을 누르거나 오른쪽 채팅 아이콘을 클릭하면 됩니다. 그런 다음 채팅에 충분히 명확한 프롬프트를 입력합니다.
+
+> React 아키텍처로 스네이크 게임을 구현해 주세요. 키보드 제어, 먹이를 먹으면 길이가 늘고 점수가 올라가는 기능, 벽이나 자기 몸에 부딪히면 “게임 종료”를 표시하고 다시 시작을 지원하는 기능을 포함해야 합니다. 구현 후 이 프로젝트를 시작해 주세요. 설치되지 않은 프로그램 환경이 있다면 자동으로 설치해 주세요.
+
+이 과정에서 AI는 단순한 채팅 모델이 아니라 로컬 환경 조작을 도울 수 있다는 점을 인식해야 합니다. 파일을 만들고, 의존성을 설치하고, 실행 명령을 수행할 수 있습니다. 달성하려는 목표를 자연어로 설명하면 AI가 어떤 명령을 실행하고 코드를 어떻게 구성할지 결정합니다.
+
+실행 중 문제가 생기면 AI는 대화 안에 오류와 처리 방안을 표시합니다. 계속 대화로 조정하게 하면 되며, 모든 명령 세부 사항을 직접 외울 필요는 없습니다.
+
+::: warning ⚠️ 주의할 점
+아래 그림처럼 **가끔 AI Agent가 실행 중 멈출 수 있습니다. 이는 이름 입력, Enter 확인, 명령 실행 클릭처럼 당신의 입력을 기다리기 때문입니다.** 보통은 바로 Enter를 누르면 됩니다. 이 단계에서 무엇을 해야 할지 확실하지 않다면 현재 화면을 스크린샷으로 찍어 대형 모델에게 어떻게 조작해야 하는지 물어볼 수 있습니다.
+:::
+
+그림처럼 여기서는 Run을 클릭해 확인해야 합니다.
+
+
+그림처럼 여기서는 y만 입력하면 확인됩니다.
+
+
+
+
+그림처럼 여기서는 템플릿을 만들고 있지만 어떻게 조작해야 할지 모르겠습니다. 이 부분을 스크린샷으로 찍어 대형 모델에게 물어볼 수 있습니다.
+
+
+
+AI Agent가 실행 중 멈추는 또 다른 이유는 이때 “서비스”가 시작되었기 때문입니다. 우리의 스네이크 자체도 하나의 “서비스”입니다. 아래 명령의 URL을 보면 Agent가 로컬 컴퓨터 서비스를 실행했다는 뜻입니다. 해당 주소에 접속하면 스네이크를 볼 수 있습니다. 서비스는 계속 켜져 있어야 하므로 여기서 일시정지처럼 보입니다. 우리는 `Skip` 버튼만 클릭하면 됩니다.
+
+
+
+이 과정에서 용어나 이해하기 어려운 내용을 만나도 걱정하지 마세요. 부록의 “컴퓨터 용어 설명” 부분을 확인하거나, AI에게 직접 질문하거나, 바로 질문하면 됩니다!
+
+과정 중 기대와 다른 현상을 만나면, 예를 들어 스네이크가 벽에 부딪힌 뒤 게임이 끝나지 않거나 시작을 클릭해도 뱀이 움직이지 않는다면, 그 현상을 사이드바 Agent에게 설명하기만 하면 됩니다. 오류가 있으면 스크린샷을 찍거나 오류를 복사해 사이드바 Agent에게 보내세요. 여러 번 해도 해결되지 않으면 모델을 바꿔 시도해 보세요.
+
+잠시 기다리면 z.ai와 비슷한 결과를 얻을 수 있습니다.
+
+
+
+오른쪽 아래의 체크 표시를 클릭해 코드 변경을 확정할 수 있고, `Cancel` 버튼을 클릭해 변경을 취소할 수도 있습니다. 또는 “2 files need review” 위치를 클릭해 변경된 코드를 펼쳐 볼 수 있습니다.
+
+여기서 또 주의할 점은 코드 수정이 반드시 옳은 것은 아니라는 점입니다. 또한 모든 IDE의 Agent가 코드 되돌리기를 지원한다는 사실도 알아야 합니다. 예를 들어 여기서 실수로 잘못 수정했거나 이번 작업 결과가 만족스럽지 않다면, 수정이 끝난 뒤 입력창 부분으로 돌아가 Revert 버튼을 클릭해 수정 전 상태로 되돌릴 수 있습니다. 입력 문구를 바꾸어 다시 작업할 수 있습니다.
+
+
+
+### 4.4 세 번째 단계(선택): AI에게 코드 구현 세부 사항 묻기
+
+스네이크 게임이 정상적으로 실행되면, 프론트엔드나 React가 아직 익숙하지 않은 경우 같은 채팅 창에서 AI에게 최대한 구어체로 코드를 안내해 달라고 할 수 있습니다. 도구를 바꿀 필요도 없고, 일부러 문서를 뒤질 필요도 없습니다. 현재 프로젝트를 둘러싸고 계속 질문하면 됩니다.
+
+비교적 실용적인 방법은 AI에게 먼저 “게임이 어떻게 움직이는지” 전체를 설명하게 하고, 그다음 구체적인 세부 사항으로 나누는 것입니다. 예를 들어 바로 이렇게 물을 수 있습니다.
+
+> “위에서 아래로 한 번 설명해 줘. 이 스네이크 게임은 각 단계에서 어떻게 움직이는 거야? 전문 용어는 최대한 적게 써줘.”
+
+
+
+그다음 AI의 답변을 따라 핵심 지점을 계속 물어볼 수 있습니다. 예:
+
+> “화면에 보이는 뱀의 각 몸통 칸은 어떤 데이터 구조로 기억하는 거야? 비유로 설명해 줄 수 있어?”
+> “'일정 시간마다 한 번 움직이기'는 어떻게 제어하는 거야? 코드에서는 어느 부분이야?”
+> “뱀이 먹이를 먹었을 때 어떤 순서로 처리했어? 먹었다고 판단하는 로직은 어디야?”
+> “벽에 부딪히는 것과 자기 몸에 부딪히는 것은 각각 어느 코드에서 판단해?”
+
+어떤 파일(예: `SnakeGame.tsx`)을 봤지만 전혀 무엇을 하는지 모르겠다면, AI에게 기능별로 나눠 설명해 달라고 바로 요청할 수도 있습니다.
+
+> “`SnakeGame.tsx`를 기능별로 몇 덩어리로 나눠 설명해 줘. 각 덩어리가 대략 무엇을 담당하는지 쉬운 말로 알려줘.”
+
+이 대화에서 이해하지 못한 단어는 모두 추가 질문의 입구로 삼을 수 있습니다. 예:
+
+> “방금 말한 ‘상태’가 구체적으로 뭐야? 생활 속 예로 설명해 줄 수 있어?”
+> “여기서 말한 ‘타이머’는 주로 뭘 하는 거야? 이걸 빼면 무슨 일이 생겨?”
+
+이 방식에서 목표는 모든 개념을 한 번에 외우는 것이 아니라 먼저 세 가지를 파악하는 것입니다. 이 게임의 핵심 데이터가 무엇인지(뱀, 먹이, 점수, 게임 상태 등), 이 데이터가 언제 바뀌는지(이동, 먹이 먹기, 게임 종료 등), 그리고 각 변화가 어느 작은 코드 조각에 대응되는지입니다. 이 세 가지가 정리되면 이 코드의 주요 로직은 기본적으로 이해할 수 있습니다.
+
+### 4.5 네 번째 단계: AI에게 화면을 조금 더 보기 좋게 만들게 하기
+
+여기서 초보자에게 중요한 점을 먼저 알려 드립니다. AI에게 “이 화면을 예쁘게 만들어줘”라고 한 마디만 말하지 마세요. 이런 표현은 인간 디자이너에게도 너무 모호합니다. 모델에게는 더더욱 그렇습니다. “예쁘다”가 어떤 스타일인지, 어느 부분을 조정해야 하는지, 레이아웃 문제인지 색상 문제인지 AI는 이 한 문장에서 읽어낼 수 없습니다. AI가 진짜로 마음속 기대에 가까운 결과를 만들게 하려면, “예쁘게 하고 싶다”는 모호한 목표를 구체적이고 실행 가능한 작은 요구들의 묶음으로 나누는 법을 배워야 합니다.
+
+예를 들어 많은 사람은 처음에 이렇게 말합니다.
+
+> “이 화면을 좀 더 예쁘게 만들고 싶어.”
+
+예를 들어 먼저 전체 요구 묶음을 제시할 수 있습니다.
+
+> “게임 인터페이스 전체를 조금 미화해 주세요.
+>
+> - 게임 영역은 가운데 정렬하고, 왼쪽 위에 붙어 있지 않게 해 주세요.
+> - 배경색은 비교적 밝은 색으로 바꿔서 뱀과 먹이가 더 눈에 띄게 해 주세요.
+> - 점수를 크게 표시하고, 눈에 잘 띄는 위치에 놓아 주세요.
+> - 파란색을 주 색상으로 해서 전체 색상과 버튼을 미화해 주세요.”
+
+“게임 종료” 시 더 명확한 피드백을 원한다면 추가로 보충할 수 있습니다.
+
+> “게임이 끝나면 화면 중앙에 ‘게임 종료’를 표시하고, 아래에는 게임을 초기화할 수 있는 ‘다시 시작’ 버튼을 넣어 주세요.”
+
+AI는 설명에 따라 React 컴포넌트와 스타일을 직접 수정합니다. 저장 후 브라우저를 새로고침하면 새 인터페이스를 볼 수 있습니다. 결과가 상상과 아직 다르면 작은 단위로 계속 조정할 수 있습니다. 예:
+
+> “점수를 더 크게 하고 색도 더 눈에 띄게 해줘.”
+> “게임 영역을 조금 더 조밀하게 하고, 사방에 여백을 조금 남겨줘.”
+> “다시 시작 버튼은 파란색 둥근 모서리 스타일로 바꾸고, 안내 문구 아래 가운데에 놓아줘.”
+
+이 단계에서 어떤 수정이 오류를 일으켜도 직접 억지로 찾아볼 필요는 없습니다. 오류 정보를 채팅창에 복사하거나 “방금 인터페이스를 미화한 뒤 나타난 오류야” 같은 짧은 설명을 붙여, AI가 현재 프로젝트 맥락 안에서 위치를 찾고 고치게 하세요. 이렇게 “계속 대화하고, 계속 새로고침하는” 순환 속에서 실행 가능한 Demo를 점차 인터페이스가 명확하고 상호작용이 매끄러운 작은 완성품으로 다듬을 수 있습니다.
+
+### 4.6 (선택) z.ai 아키텍처를 참고해 스네이크 결과 수정하기
+
+vibe coding 초보자에게 가장 어려운 것은 오히려 무엇이 “베스트 프랙티스”인지, 어떤 아키텍처가 가장 적합한지 모른다는 점입니다. 컴퓨터 기초를 모르기 때문에 AI를 잘 이끌기 어렵습니다. 이 문제를 해결하는 방법은 “직접 참고”입니다. z.ai에서 코드를 볼 수 있다고 앞에서 말했던 것을 기억하나요? 사실 해당 README(프로젝트에서 기능과 기술 아키텍처를 소개하는 부분)에는 이미 최적 아키텍처 참고가 제시되어 있습니다.
+
+
+
+로컬 결과가 z.ai 결과와 최대한 비슷해지게 하고 싶다면, 이 README 전체 내용을 복사해 Trae 사이드바에 붙여 넣고, README의 아키텍처에 따라 로컬 코드를 수정하게 하면 됩니다.
+
+
+
+마지막으로 z.ai와 매우 비슷한 페이지 디자인 스타일을 얻을 수 있습니다.
+
+
+
+
+
+
+
+
+
+## 5. 인터페이스의 각 버튼은 무엇을 할까
+
+위 작업을 통해 최소 프로그램 생성 폐쇄 루프는 빠르게 통과했습니다. 하지만 IDE에 충분히 익숙하다고 말하기는 아직 어렵습니다. 앞으로 오래 함께할 이 도구를 제대로 익히기 위해, 이번 절에서는 IDE의 각 세부 부분을 깊이 설명합니다. 먼저 인터페이스부터 시작합니다. 서로 다른 AI IDE의 인터페이스는 약간 다르지만, 대부분 [VS Code의 레이아웃](https://code.visualstudio.com/docs/getstarted/getting-started)을 이어받았습니다.
+
+
+
+각 부분의 구체적인 역할은 다음과 같습니다.
+
+- **Title Bar(제목 표시줄)**: 파일명과 창 제어 버튼을 표시합니다.
+- **Activity Bar(활동 표시줄)**: 파일, 검색 등 기능 뷰를 전환합니다.
+- **Side Bar(사이드바)**: 파일 목록 같은 구체적인 내용을 표시합니다.
+- **Editor Groups(편집 영역)**: 코드를 작성하는 핵심 영역입니다.
+- **Breadcrumbs(경로 탐색)**: 파일 경로를 표시하고 이동을 지원합니다.
+- **Minimap(코드 미니맵)**: 코드를 빠르게 미리 보고 위치를 찾습니다.
+- **Panel(하단 패널)**: 터미널과 출력 창을 포함합니다.
+- **Status Bar(상태 표시줄)**: 현재 환경 상태를 표시합니다.
+
+더 구체적인 설명은 [부록의 가상 IDE 시각화 IDE 원리 부분](/ko-kr/appendix/2-development-tools/ide-basics)을 확인하세요.
+
+
+
+
+
+
+
+## 6. AI에게 어떻게 말해야 효과적일까
+
+AI 능력이 점점 강해지면서, 우리는 이미 “프로그래머에게 코드를 써 달라고 하는” 많은 일을 AI에게 맡길 수 있게 되었습니다.
+하지만 실제로 사용해 보면 알게 됩니다. 같은 AI를 쓰는데도 어떤 사람은 몇 마디만으로 실행 가능한 작은 프로젝트를 얻고, 어떤 사람은 한참 대화했는데 결과가 전혀 원하는 것이 아닙니다. 그 차이는 대개 “누가 더 똑똑한가”가 아니라, AI에게 말하는 방식이 충분히 구체적이고 단계적인가에 있습니다.
+이 절에서는 몇 가지 흔한 상황에서 출발해 완전 초보자에게 적합한 질문 방식을 소개하고, AI가 더 안정적으로 쓸 수 있는 결과를 내도록 돕습니다.
+
+### 6.1 요구사항을 분명히 말하기: “모호한 생각”에서 “구체적인 설명”으로
+
+많은 사람이 처음 AI를 사용할 때 아주 포괄적인 한 문장만 말하는 습관이 있습니다. 예:
+
+> “웹페이지 하나 만들어줘.”
+> “작은 프로그램 하나 써줘.”
+
+이런 경우 AI는 당신이 무엇을 원하는지 스스로 “상상”할 수밖에 없습니다. 그래서 겉보기에는 꽤 완성도 있어 보이는 것을 아무거나 줄 수 있지만, 실제로 만들고 싶은 것과는 많이 다를 때가 많습니다.
+AI가 당신의 뜻을 더 잘 이해하게 하려면 “머릿속 생각”을 나누어 몇 문장으로 단계별로 분명히 말해야 합니다.
+
+다음 몇 가지 측면을 보충할 수 있습니다.
+
+1. **이것을 어디에 쓰려는지 말하기**
+ 예를 들어 “개인 웹사이트”라고만 하지 말고 이렇게 말합니다.
+ - “채용 담당자에게 보내기 위한 한 페이지짜리 개인 소개 웹페이지를 만들고 싶어.”
+
+2. **대략 어떤 내용 블록이 필요한지 말하기**
+ 전문 용어를 쓰지 않아도 됩니다. 페이지에 무엇이 나타나길 원하는지만 설명하면 됩니다.
+ - “페이지는 세 부분이어야 해. 맨 위에는 이름과 한 줄 자기소개, 가운데에는 몇 가지 업무 경력, 맨 아래에는 이메일과 WeChat 번호를 넣어줘.”
+
+3. **자신의 수준과 제한을 말하기**
+ AI가 초보자가 받아들일 수 있는 방식으로 만들게 합니다.
+ - “나는 코드를 전혀 쓸 줄 몰라. 가장 간단한 방식만 사용해서, 내가 한 파일에 바로 복사하고 브라우저에서 열 수 있게 해줘.”
+
+4. **결과를 어떤 형태로 받고 싶은지 말하기**
+ 예:
+ - “`index.html`로 바로 저장하고 브라우저에서 열 수 있는 전체 코드를 주세요.”
+
+종합하면 AI에게 이렇게 말할 수 있습니다.
+
+> “나는 코드를 전혀 쓸 줄 몰라. 채용 담당자에게 보내기 위한 한 페이지짜리 개인 소개 웹페이지를 만들고 싶어.
+> 페이지에는 세 부분이 필요해. 위에는 이름과 한 줄 자기소개, 가운데에는 몇 가지 업무 경력, 아래에는 이메일과 WeChat 번호를 넣어줘.
+
+이 정보를 분명히 말하면 AI는 아무거나 “멋져 보이지만 쓸 수 없는 것”을 주는 대신, 당신의 실제 요구에 더 가까운 결과를 낼 수 있습니다.
+
+### 6.2 리듬 맞추기: 먼저 “실행되게” 하고, 그다음 조금씩 복잡하게 만들기
+
+완전 초보자에게 가장 흔한 함정은 처음부터 “매우 완전하고” “기능이 많은” 것을 만들려고 하는 것입니다.
+예:
+
+> “Taobao 같은 웹사이트를 만들어줘.”
+> “회원가입, 로그인, 주문이 가능한 시스템을 만들어줘.”
+
+결과는 대개 이렇습니다. AI가 큰 코드 덩어리를 주고, 복사해 넣으면 열리지 않거나 여기저기 오류가 납니다. 어디가 문제인지도 이해할 수 없어 결국 포기하게 됩니다.
+
+더 적합한 방법은 **능동적으로 리듬을 제어**하는 것입니다. AI가 한 번에 모든 것을 쏟아붓게 하지 말고, 당신을 따라 한 단계씩 진행하게 하세요. 아래 순서대로 요구할 수 있습니다.
+
+1. **첫 번째 단계: 먼저 “최소 예시”를 요청하기**
+ 한 가지만 확인합니다. 브라우저에서 무엇인가 보이는가.
+ 예:
+
+ > “먼저 가장 간단한 예시를 주세요. 브라우저에서 ‘여기는 내 홈페이지입니다’라는 한 줄만 보이면 됩니다.
+ > 그리고 파일명을 무엇으로 해야 하는지, 어떻게 저장하고 어떻게 여는지 단계별로 알려 주세요.”
+
+2. **두 번째 단계: 이 기반 위에 내용을 천천히 추가하기**
+ “그 한 줄이 실제로 보인다”는 것을 확인한 뒤 이렇게 말합니다.
+
+ > “방금 기반 위에 ‘업무 경력’ 영역을 추가해 주세요. 전체 코드를 다시 보내 주세요. 바뀐 부분만 보내지 마세요.”
+
+3. **세 번째 단계: 구조가 거의 잡힌 뒤 보기 좋게 만들기**
+ 예:
+ > “이제 페이지가 정상적으로 내용을 표시합니다. 다음으로 조금 미화해 주세요. 전체를 가운데 정렬하고, 제목은 조금 크게 하고, 편안한 글꼴을 사용해 주세요. 업데이트된 전체 코드를 주세요.”
+
+단계를 하나 추가할 때마다 먼저 한 번 실행하고 실제 변화가 있는지 확인한 뒤 AI에게 다음을 추가하게 하세요. 이렇게 하면 어떤 단계에서 문제가 생겨도 “직전 정상 버전”으로 빠르게 돌아갈 수 있고, 완전히 처음부터 다시 할 필요가 없습니다.
+
+### 6.3 스크린샷과 복사를 잘 활용하기: 말로 못 하겠으면 “화면을 AI에게 던지기”
+
+완전 초보자가 자주 겪는 어려움은 “코드를 못 고치는 것”보다 **문제를 어떻게 말해야 할지 모른다**는 데 있습니다.
+예:
+
+- 브라우저에 갑자기 영어 오류가 잔뜩 뜨는데 전혀 이해할 수 없습니다.
+- 웹페이지 레이아웃이 생각과 다르지만, 어떤 단어로 설명해야 할지 모릅니다.
+
+이럴 때 전문 용어를 억지로 짜낼 필요는 없습니다. 가장 간단한 방법은 **본 것을 그대로 AI에게 던지는 것**입니다.
+
+다음처럼 할 수 있습니다.
+
+1. **오류 문자 복사하기**
+ 빨간 오류 메시지를 보면 바로 복사한 뒤 이렇게 말합니다.
+
+ > “이것은 실행 후 나타난 전체 오류 정보입니다. 영어를 이해하지 못하겠습니다. 먼저 일반인이 이해할 수 있는 말로 대략 무슨 뜻인지 설명해 주세요.
+ > 그리고 지금 가장 간단히 어떻게 고치면 되는지 알려 주세요.”
+
+2. **AI에게 스크린샷 보여 주기**
+ “이 페이지가 그냥 이상해 보인다”고 느끼지만 설명을 못 하겠다면:
+ - 현재 페이지 스크린샷을 찍습니다.
+ - 사용 중인 전체 코드를 복사해 AI에게 보냅니다.
+ - 그리고 이렇게 설명합니다.
+ > "이것은 현재 페이지 모습이고, 이것은 현재 전체 코드입니다.
+ > 원래는 3열 레이아웃을 원했는데 지금은 1열이 되었습니다. 원인을 봐 주고, 수정된 전체 코드를 주세요."
+
+ ::: tip 💡 스크린샷 기능 보충 설명
+
+ 주의할 점은 **모든 AI 모델이 “이미지를 볼 수 있는” 것은 아니라는 점**입니다. 여기에는 서로 다른 두 개념이 관련됩니다.
+
+ - **순수 텍스트 대형 모델(LLM)**: 텍스트 입력만 처리할 수 있고 이미지 내용을 인식할 수 없습니다. 스크린샷을 보내면 처리를 거부하거나 이미지 안의 정보를 제대로 이해하지 못할 수 있습니다.
+
+ - **멀티모달 모델**: 텍스트, 이미지 등 여러 유형의 입력을 동시에 처리할 수 있습니다. 당신이 보낸 스크린샷을 “이해”하고, 이미지 내용을 바탕으로 제안을 줄 수 있습니다.
+
+ **흔한 모델 능력 참고**(Trae에서 선택 가능한 모델 기준):
+
+ | 모델 | 이미지 입력 지원 여부 |
+ |------|-----------------|
+ | Doubao-Seed 시리즈 | ✅ 지원 |
+ | GLM-4.7 / 4.6 | ❌ 미지원 |
+ | MiniMax-M2.7 / M2.5 | ❌ 미지원 |
+ | DeepSeek-V3.1 | ❌ 미지원 |
+ | Kimi-K2.5 | ✅ 지원 |
+ | Kimi-K2-0905 | ❌ 미지원 |
+ | Qwen-3-Coder | ❌ 미지원 |
+ | Gemini 시리즈 | ✅ 지원 |
+ | GPT 시리즈 | ✅ 지원 |
+
+ **사용 제안**: 스크린샷으로 AI에게 인터페이스 문제를 확인하게 하고 싶다면, 먼저 사용하는 모델이 이미지 입력을 지원하는지 확인하세요. 지원하지 않는다면 문자로 문제를 설명하거나 오류 정보를 복사해 붙여 넣으세요.
+
+ :::
+
+3. **마음에 드는 웹페이지를 만나 비슷하게 만들고 싶을 때**
+ “이 레이아웃을 뭐라고 부르지”라고 말할 필요가 없습니다. 바로:
+ - 스크린샷을 찍거나 그 페이지의 주요 제목과 문단을 복사합니다.
+ - 그리고 이렇게 말합니다.
+ > “이것과 구조가 비슷한 페이지를 만들고 싶습니다. 완전히 똑같을 필요는 없습니다.
+ > 간단한 코드로 비슷한 프레임을 하나 만들어 주세요. 그다음 글자는 제가 제 것으로 바꾸겠습니다.”
+
+간단히 말하면, 당신은 “본 것을 AI에게 옮겨 주고”, 가장 쉬운 말로 “이것이 어떻게 바뀌면 좋겠다”고 말하면 됩니다. 나머지 “코드로 번역하기, 용어 설명하기, 문제 찾기”는 AI에게 맡기면 됩니다.
+
+### 6.4 AI가 생성한 코드가 작동하지 않을 때: 공통 대응 방법
+
+실제 연습에서는 반드시 이런 상황을 만납니다.
+AI가 아주 성실하게 코드를 줬고, 당신도 정직하게 복사했지만 결과는 브라우저가 텅 비거나, AI가 말한 효과와 전혀 다릅니다.
+이것은 당신이 “배울 수 없다”는 뜻도 아니고, AI가 완전히 틀렸다는 뜻도 아닙니다. 다만 당신과 AI 사이에 몇 차례 “왕복 확인”이 더 필요하다는 뜻입니다.
+
+코드가 “작동하지 않을” 때는 아래 고정 절차에 따라 AI에게 말할 수 있습니다.
+
+1. **먼저 “무엇을 했고 + 지금 어떤 상태인지” 분명히 말하기**
+ “안 열려”, “안 돼”라고만 말하지 않습니다. 이렇게 설명할 수 있습니다.
+
+ > 열어 보니 페이지가 완전히 비어 있고, 네가 말한 환영 문구가 표시되지 않습니다.
+ > xxxx 페이지를 열었는데 방금 내가 말한 부분이 없습니다. 사용할 수 없습니다.
+
+2. **현재 전체 코드를 AI에게 보내기**
+ 많은 경우 문제는 한 줄을 덜 복사했거나, 이전 내용과 이번 내용이 섞였기 때문입니다.
+ 이렇게 말할 수 있습니다.
+
+ > “아래는 지금 이 파일 안의 전체 코드입니다.
+ > 어디가 빠졌는지, 잘못 썼는지, 순서가 틀렸는지 비교해 주세요.
+ > 수정된 전체 코드를 바로 주세요. 작은 일부만 보내지 마세요.”
+
+3. **오류 안내가 있으면 함께 제공하기**
+ 예를 들어 브라우저 오른쪽 위에 뜬 오류나 하단의 빨간 글자입니다. 다음을 할 수 있습니다.
+ - 오류 문자를 복사합니다.
+ - 또는 스크린샷을 찍습니다.
+ - 그리고 말합니다.
+ > “이것은 제가 본 오류 안내입니다. 전혀 이해하지 못하겠습니다. 먼저 쉬운 방식으로 대략 어떤 문제인지 설명하고, 지금 가장 먼저 고쳐야 할 몇 줄을 알려 주세요.”
+
+4. **상대에게 “초보자 모드”로 단계별 설명을 요구하기**
+ 자신의 상황을 분명히 말하고 중간 단계를 생략하지 말라고 할 수 있습니다.
+
+ > “저는 코드를 전혀 쓸 줄 모릅니다. 단계별로 알려 주세요.
+ > 1단계에서는 어느 줄을 고쳐야 하는지,
+ > 2단계에서는 어떻게 저장해야 하는지,
+ > 3단계에서는 어떻게 다시 열거나 페이지를 새로고침해야 하는지.
+ > 각 단계는 완전한 문장으로 써 주세요.”
+
+5. **마지막으로 “정상이라면 무엇을 봐야 하는지” 비교 기준을 말해 달라고 하기**
+ 예:
+ > 먼저 말해 주세요. 수정된 코드대로라면 정상적으로 웹페이지를 열었을 때 무엇이 보여야 하나요?
+
+이 절차에 따라 AI와 상호작용하면 대부분의 “코드가 작동하지 않는” 상황은 몇 차례 왕복 안에 해결할 수 있습니다.
+동시에 흔한 문제 유형에도 점점 익숙해져 다음에 비슷한 상황을 만나면 직접 해결할 수 있게 됩니다.
+
+## 7. 소결과 다음 단계
+
+이번 장에서 당신은 “웹페이지에서 AI가 생성한 스네이크를 플레이할 수 있음”에서 “로컬에서 AI IDE로 직접 미니게임을 만들 수 있음”으로 한 단계 업그레이드했습니다. 크게 세 가지를 이해했습니다. 코드를 쓸 때 왜 VS Code 같은 IDE가 필요한지, 그 위에 AI(Trae, Cursor 등)가 더해지면 IDE가 더 이상 도구 상자에 그치지 않고 자연어를 이해하고 파일 생성, 환경 설치, 코드 수정을 도와주는 “인턴 엔지니어”가 된다는 점, 그리고 IDE 인터페이스의 각 영역(왼쪽 파일, 하단 터미널, 가운데 편집 영역, 오른쪽 AI 패널)이 각각 무엇을 담당하는지입니다. 이제 사용할 때 막막함이 줄어듭니다.
+
+더 중요한 것은 이미 한 번의 완전한 흐름을 실제로 통과했다는 점입니다. 로컬에서 빈 폴더 만들기 → AI IDE로 열기 → 사이드바 대화에서 요구사항 설명하기 → AI가 프로젝트를 생성하고 개발 서버를 시작하게 하기 → 문제가 생기면 “현상 + 전체 코드 + 오류 스크린샷”을 함께 AI에게 던지고 “초보자 모드”로 단계별 수정 요청하기. 이 과정에서 더 효과적인 프롬프트를 쓰는 법도 연습했습니다. 목표, 내용 구조, 자신의 수준을 분명히 말하고, “먼저 실행되게” 한 다음 “더 보기 좋고 재미있게” 만드는 식으로 리듬을 제어하는 법입니다.
+
+다음 장에서는 초점을 “도구를 사용할 줄 아는 것”에서 “진짜 누군가 쓰고 싶어 하는 프로토타입 만들기”로 옮깁니다. 사용자 관점에서 규칙, 상호작용, 피드백을 설계하고, AI가 이러한 생각을 제품의 초기 형태로 구현하게 할 것입니다.
+
+## 8. 📚 과제: 로컬 AI IDE로 더 복잡한 게임 만들기
+
+
+
+
🚀 도전 과제: 나만의 게임 만들기
+
+
+
+ 이미 로컬 AI IDE로 스네이크를 만들어 보았습니다. 이제 조금 더 복잡한 미니게임에 도전하고, “요구사항 설명 →
+ 프로젝트 생성 → 로컬 실행 → 디버깅 반복”의 흐름을 완전히 한 번 더 밟아 보세요.
+
+
+
+
+ 스네이크보다 조금 더 복잡한 게임 하나 선택하기
+
+
“테트리스”, “두더지 잡기”, “지뢰 찾기”, “2048”, “비행기 슈팅” 같은 것이 가능합니다.
+
또는 직접 상상한 간단한 오리지널 게임도 됩니다.
+
+
+
+ 반드시 로컬 AI IDE로 전체 과정을 완성하기
+
+
빈 폴더를 새로 만들고 AI IDE로 엽니다.
+
사이드바 채팅에서 게임 요구사항을 분명히 설명합니다.
+
AI가 파일 생성, 프로젝트 구조 구축, 주요 로직 구현을 맡게 합니다.
+
로컬 개발 서버를 시작해 게임이 정상적으로 실행되는지 확인합니다.
+
+
+
+ 기본적인 “플레이 가능성”과 피드백 갖추기
+
+
최소한 시작, 진행 중, 종료 세 가지 상태를 포함해야 합니다.
+
플레이어에게 명확한 조작 방식(키보드 또는 마우스)이 있어야 합니다.
+
화면에 명확한 점수 또는 진행 피드백이 있어야 합니다.
+
+
+
+ 최소 2회 이상 반복 개선하기
+
+
첫 번째 라운드에서는 AI가 “플레이 가능한” 버전을 만들게 합니다.
+
두 번째 라운드 이후에는 스타일, 난이도, 상호작용 최적화 같은 구체적인 개선을 단계적으로 제시합니다.
+
+
+
+
+
+
+
+# 부록
+
+
+
부록 내비게이션
+
+ 여기는 “필요할 때 바로 찾아보는” 보충 자료입니다. 용어가 이해되지 않거나 인터페이스에서 입구를 찾지 못할 때 다시 돌아오세요.
+
+ 지원: Ctrl/⌘+F로 키워드 검색. 새 단어를 만나면 오류를 복사해 AI에게 “초보자 모드”로 설명하게 할 수 있습니다.
+
+
+
+# 부록 1: 흔한 컴퓨터 용어 빠른 조회표
+
+
+
🗺️ 용어 지도: 여기서 만나게 될 것들...
+
+
+ 🖥️ 도구 인터페이스
+ IDE / 터미널 / 패널
+
+
+ 🌐 네트워크 서비스
+ URL / 포트 / 로컬
+
+
+ ⚙️ 프론트엔드와 백엔드
+ API / JSON / 인터페이스
+
+
+ 📝 코드 기초
+ 변수 / 함수 / 컴포넌트
+
+
+
+
+ 🐞 디버깅과 오류 찾기
+ Bug / 중단점 / 로그
+
+
+ 📂 프로젝트 관리
+ Git / 저장소 / 커밋
+
+
+ 🤖 AI 도구
+ Agent / 모델 / Key
+
+
+ 🛠️ 브라우저
+ DevTools / 콘솔
+
+
+
+
+이 부분은 일부러 외울 필요가 없습니다. 먼저 머릿속에 대략적인 인상을 만드는 것이 더 중요합니다.
+
+## [1. “도구 인터페이스”와 관련된 단어](#appendix-1-map)
+
+### 1. IDE, 편집기, 터미널
+
+**IDE(통합 개발 환경)**
+IDE를 “프로그래머의 작업대”라고 상상할 수 있습니다.
+
+- 한쪽에는 글을 쓰는 책상(편집기)이 있고,
+- 한쪽에는 전원 콘센트와 버튼(실행, 디버깅)이 있으며,
+- 서랍에는 여러 작은 도구(검색, 버전 관리)가 들어 있습니다.
+ VS Code, Trae, Cursor는 모두 IDE이거나 IDE를 기반으로 수정한 도구입니다.
+
+**코드 편집기(Editor)**
+“고급 메모장”에 더 가깝고, 하는 일은 다음뿐입니다.
+
+- 타이핑해서 코드를 쓰게 합니다.
+- 색으로 서로 다른 내용을 구분합니다(문법 강조).
+- 자동 완성을 제공합니다.
+ IDE 안에서 코드를 쓰는 그 영역이 코드 편집기입니다.
+
+**터미널 / 명령줄(Terminal / 명령줄 창)**
+검은 배경에 흰 글자가 보이는 창입니다. 그 안에서 **명령어를 입력**해 컴퓨터가 일하게 합니다.
+
+- 예: `npm run dev`는 “개발 서버를 시작해 줘”라는 뜻입니다.
+- `python main.py`는 “이 Python 파일을 실행해 줘”라는 뜻입니다.
+ “컴퓨터에게 문자 명령을 하나씩 보내면, 컴퓨터가 문자로 실행 결과를 답한다”고 상상하면 됩니다.
+
+### 2. IDE 안의 몇 가지 흔한 영역
+
+**활동 표시줄(Activity Bar)**
+가장 왼쪽의 세로 아이콘 줄이며 “기능 탭”과 비슷합니다.
+
+- 파일 아이콘 클릭 → 왼쪽에 파일 목록 표시
+- 돋보기 아이콘 클릭 → 왼쪽이 검색으로 바뀜
+- Git 아이콘 클릭 → 왼쪽에 버전 관리 표시
+
+**사이드바(Side Bar)**
+활동 표시줄 오른쪽의 큰 영역이며 현재 모드의 내용을 표시합니다.
+
+- 파일 모드: 프로젝트의 파일과 폴더 표시
+- 검색 모드: 검색 결과 목록 표시
+- 소스 코드 관리 모드: 어떤 파일이 수정되었는지 표시
+
+**편집 영역(Editor)**
+가운데 가장 큰 영역이며, 파일을 열었을 때 실제 내용을 보고 수정하는 곳입니다.
+위쪽의 탭(Tab)은 “현재 어떤 파일들이 열려 있는지”를 나타냅니다.
+
+**하단 패널(Panel)**
+보통 가장 아래쪽에 있으며 흔히 다음이 있습니다.
+
+- Terminal(터미널): 명령어를 입력해 프로젝트 실행
+- Problems(문제): 오류가 난 파일과 줄 번호 나열
+- Output(출력): 일부 도구가 출력하는 실행 정보
+- Debug Console(디버그 콘솔): 디버깅 중 출력
+
+**상태 표시줄(Status Bar)**
+가장 아래의 얇은 줄입니다.
+
+- 현재 파일의 언어(JS, HTML, Python 등) 표시
+- 들여쓰기가 “공백 2개”인지 “공백 4개”인지 표시
+- 오류 여부와 현재 Git 브랜치 표시
+ “현재 편집 환경의 작은 건강검진표”로 이해할 수 있습니다.
+
+## [2. “웹페이지 / 네트워크 / 서비스”와 관련된 단어](#appendix-1-map)
+
+### 1. URL, http, 포트, 로컬 서비스
+
+**URL(웹 주소)**
+브라우저 주소창에 있는 문자열입니다. 예:
+
+- `https://www.trae.cn/`
+- `http://localhost:3000/`
+ 인터넷 세계의 어떤 방에 대한 “완전한 주소”와 같습니다.
+
+**HTTP / HTTPS**
+URL 앞에서 보이는 `http://` 또는 `https://`입니다.
+
+- HTTP: 일반 전송 방식
+- HTTPS: 한 겹의 암호화가 더 있어 더 안전함
+ 먼저 “웹 주소는 보통 `http` 또는 `https`로 시작한다”고 기억하면 됩니다.
+
+**포트(Port)**
+컴퓨터 한 대를 건물로 상상하면, 포트는 **각 방의 문패 번호**입니다.
+
+- `:3000`은 3000번 방을 뜻합니다.
+- 같은 컴퓨터에서 여러 서비스를 동시에 열 수 있고, 각각 하나의 포트를 차지합니다.
+ `http://localhost:3000`은 “내 컴퓨터에서 실행 중인 3000번 방의 서비스에 접속한다”는 뜻입니다.
+
+**로컬(Local / localhost)**
+당신 자신의 컴퓨터를 뜻합니다.
+
+- `localhost`는 “이 기계 자신”으로 이해할 수 있습니다.
+ `http://localhost:3000`에 접속하면, 사실 다른 사람의 서버가 아니라 내 컴퓨터에서 실행 중인 프로그램과 상호작용하는 것입니다.
+
+**서비스(Service / Server)**
+“서비스”는 **백그라운드에서 계속 실행되며 언제든 지시를 듣는** 프로그램입니다.
+
+- 웹페이지 서비스: 브라우저가 어떤 주소에 접속하면 웹페이지 내용을 돌려줍니다.
+- 게임 서비스: 대전, 저장, 순위표 등을 관리합니다.
+ 터미널에서 `npm run dev`로 프로젝트를 시작하는 것은 본질적으로 “로컬에서 웹페이지 서비스를 하나 연다”는 뜻입니다.
+
+## [3. “프론트엔드 / 백엔드 / 데이터”와 관련된 단어](#appendix-1-map)
+
+### 1. 프론트엔드, 백엔드
+
+**프론트엔드(Frontend)**
+사용자가 **볼 수 있고, 클릭할 수 있는** 부분입니다.
+
+- 웹페이지의 버튼, 텍스트, 이미지, 애니메이션
+- React / Vue로 만든 페이지
+ 인터페이스를 보여 주고 사용자 조작(클릭, 입력, 드래그 등)에 응답합니다.
+
+**백엔드(Backend)**
+사용자가 **볼 수 없는**, 서버에서 돌아가는 부분입니다.
+
+- 데이터 저장과 읽기(사용자 정보, 주문, 점수 등)
+- 비즈니스 규칙 실행(로그인 검증, 권한 판단)
+ 프론트엔드를 “매장과 직원”에 비유한다면, 백엔드는 “창고와 장부 시스템”에 비유할 수 있습니다.
+
+### 2. 인터페이스, 요청, 응답, JSON
+
+**인터페이스 / API**
+프론트엔드와 백엔드가 미리 약속해 둔 “질문하기 + 답변하기” 규칙입니다.
+
+- 프론트엔드: “이 주소와 이 형식으로 질문할게.”
+- 백엔드: “이 형식으로 결과를 돌려줄게.”
+
+**요청(Request)**
+프론트엔드가 백엔드로 보내는 한 번의 “질문”입니다.
+
+- 어디로 요청하는지(URL)
+- 어떤 방식인지(GET, POST 등)
+- 어떤 파라미터를 가져가는지(예: 사용자 ID)
+
+**응답(Response)**
+백엔드가 프론트엔드에 주는 “답변”입니다.
+
+- 상태 코드(200 성공, 404 찾을 수 없음, 500 서버 오류)
+- 실제 데이터(대부분 JSON)
+
+**JSON**
+**JavaScript 코드와 매우 비슷한 작성 방식**으로 데이터를 표현하는 형식입니다. 예:
+
+```json
+{
+ "name": "Alice",
+ "score": 120
+}
```
-### 2.2 작은 요구사항 전달
+“기계용 키-값 메모장”으로 이해할 수 있으며, 프론트엔드와 백엔드는 자주 이것으로 데이터를 교환합니다.
-처음부터 "앱 전체를 만들어 줘"라고 하지 말고 작은 단위로 요청합니다.
+## [4. “코드 작성 자체”와 관련된 단어](#appendix-1-map)
-```text
-메인 화면에 할 일 목록을 보여 주는 기본 UI를 만들어 줘.
-아직 저장 기능은 넣지 말고, 샘플 데이터 3개만 화면에 표시해 줘.
+### 1. 변수, 식별자, 상태
+
+**변수(Variable)**
+“어떤 데이터에 붙이는 이름표”입니다.
+
+- 예를 들어 점수를 `score`라고 기록합니다.
+- 이후 `score`라는 이름을 사용해 이 데이터를 읽고 쓸 수 있습니다.
+
+```js
+let score = 0
+score = score + 10
```
-### 2.3 실행하고 확인하기
+**식별자(Identifier)**
+“직접 붙인 여러 이름”의 총칭입니다.
-AI가 코드를 수정하면 직접 실행합니다.
+- 변수명: `score`
+- 함수명: `moveSnake`
+- 컴포넌트명: `SnakeGame`
+ “사진”, “업무”, “청구서”처럼 폴더에 이름을 붙여 코드 안에서 서로 다른 “것”을 구분하기 쉽게 하는 것과 같습니다.
-```bash
-npm install
-npm run dev
+**상태(State)**
+프로그램의 현재 “핵심 상황 기록”입니다.
+
+- 게임이 이미 끝났는지
+- 뱀이 지금 몇 번째 칸에 있는지
+- 현재 점수가 얼마인지
+ React에서는 일반적으로 이렇게 이해합니다. **상태가 바뀌면 인터페이스도 따라 업데이트되어야 한다**.
+
+### 2. 함수, 컴포넌트, 모듈
+
+**함수(Function)**
+“반복해서 할 수 있는 일”을 묶어 이름을 붙인 것입니다.
+
+```js
+function sayHello(name) {
+ console.log('Hello, ' + name)
+}
```
-화면이 정상인지, 콘솔 오류가 없는지, 버튼이 실제로 동작하는지 확인합니다.
+이후 `sayHello('Bob')`라고 쓰면 안의 몇 줄을 다시 실행하는 것과 같습니다.
-### 2.4 오류를 되돌려 주기
+**컴포넌트(Component)**
+프론트엔드에서 “반복해서 사용할 수 있는 작은 인터페이스 + 작은 로직”입니다.
-오류가 나면 추측하지 말고 메시지를 그대로 전달합니다.
+- 버튼 하나가 컴포넌트일 수 있습니다.
+- 상단 내비게이션 하나가 컴포넌트일 수 있습니다.
+- 전체 게임 영역도 컴포넌트일 수 있습니다.
+ 컴포넌트들은 조립할 수 있으며, 블록을 맞추는 것과 비슷합니다.
-```text
-브라우저 콘솔에 아래 오류가 나와.
-원인을 설명하고 최소 수정으로 고쳐 줘.
+**모듈(Module)**
+“관련 코드 한 묶음으로 이루어진 파일”입니다.
-[오류 메시지]
+- `snakeLogic.ts`에는 “뱀이 어떻게 움직이는지”와 관련된 코드를 둡니다.
+- `score.ts`에는 점수를 계산하는 코드를 둡니다.
+ 모듈끼리는 서로 “가져오기 / 내보내기”를 할 수 있으며, 서로 다른 서랍에 들어 있는 도구와 같습니다.
+
+### 3. 문법, 프로그래밍 언어, 프레임워크
+
+**문법(Syntax)**
+어떤 프로그래밍 언어의 “문법 규칙”과 “구두점 습관”입니다.
+
+- 문자열은 따옴표를 붙여야 합니다.
+- 각 문장 끝에 세미콜론을 써야 하는지 여부가 있습니다.
+- 코드 블록은 `{}`로 감싸야 합니다.
+ 문법을 잘못 쓰면 컴파일러 / 인터프리터가 바로 “문법 오류”를 냅니다.
+
+**프로그래밍 언어(Programming Language)**
+컴퓨터와 소통하는 규칙과 어휘 전체입니다. 예:
+
+- JavaScript, Python, Java, C++, Go...
+ 언어마다 적합한 일, 작성 방식, 도구 생태계가 다릅니다.
+
+**프레임워크(Framework)**
+다른 사람이 “뼈대를 미리 세워 둔” 큰 코드와 관습 묶음입니다.
+
+- 프론트엔드: React, Vue. 인터페이스 업데이트, 상태 관리 등을 도와줍니다.
+- 백엔드: Django, Spring Boot 등.
+ “이미 준비된 뼈대 위에 내용을 채우는 것”이므로 처음부터 모든 것을 만드는 것보다 훨씬 쉽습니다.
+
+## [5. “디버깅 / 오류 찾기”와 관련된 단어](#appendix-1-map)
+
+### 1. Bug, 오류 메시지, 로그 / console.log
+
+**Bug**
+프로그램의 동작이 생각과 다르면 bug입니다.
+
+- 원래 버튼이 나타나야 하는데 나타나지 않습니다.
+- 원래 10점이 올라야 하는데 훨씬 많이 올라갑니다.
+- 페이지를 열자마자 흰 화면입니다.
+
+**오류 메시지(Error Message)**
+프로그램이 멈춘 뒤 화면이나 터미널에 나타나는 “무서워 보이는” 영어 문구입니다.
+보기는 어렵지만 보통 다음을 알려 줍니다.
+
+- 대략 어디가 틀렸는지
+- 어떤 파일, 몇 번째 줄 근처를 확인해야 하는지
+ 그대로 복사해 AI에게 던지면 번역과 분석을 시킬 수 있습니다.
+
+**로그(Log)**
+프로그램이 실행되는 동안 스스로 “말하는 내용”입니다.
+가장 흔한 것은 프론트엔드의 다음 코드입니다.
+
+```js
+console.log('현재 점수', score)
```
-## 3. AI IDE에 좋은 지시를 주는 법
+핵심 단계에서 일부러 숫자나 정보를 보고해, 프로그램이 원하는 흐름대로 가는지 확인하는 방법으로 이해할 수 있습니다.
-좋은 지시는 다음 구조를 가집니다.
+> **console.log란 무엇인가요?**
+>
+> - `console`은 “디버깅용 작은 칠판”으로 이해할 수 있습니다.
+> - `.log`는 “작은 칠판에 한 줄 쓰기”입니다.
+> - 브라우저에서 F12를 눌러 개발자 도구의 Console 패널을 열면 이런 출력을 볼 수 있습니다.
-```text
-목표:
-현재 상태:
-원하는 변경:
-지키면 좋은 제약:
-수정 후 확인 방법:
-```
+### 2. 디버깅, 중단점, 한 단계 실행, 스냅샷
-예시:
+**디버깅(Debug / 디버그 프로그램)**
+프로그램에 문제가 생겼을 때 무작정 수정하는 것이 아니라:
-```text
-목표: 상품 카드 UI를 더 보기 좋게 만들고 싶어.
-현재 상태: 카드 안에 제목, 가격, 설명이 텍스트로만 보여.
-원하는 변경: 이미지 영역, 가격 강조, 구매 버튼을 추가해 줘.
-제약: 기존 데이터 구조는 바꾸지 말고 CSS 중심으로 수정해 줘.
-확인 방법: npm run dev에서 카드 3개가 한 줄로 보이면 돼.
-```
+- 프로그램을 어떤 줄에서 잠시 멈추게 하고(중단점),
+- 현재 각 변수의 값을 보고,
+- 한 단계씩 내려가며 “어디서부터 이상해지는지” 관찰하는 것입니다.
-## 4. 초보자가 꼭 알아야 할 파일들
+**중단점(Breakpoint)**
+중단점은 “이 줄에 일시정지 버튼을 꽂아 둔다”고 상상할 수 있습니다.
-프론트엔드 프로젝트에서 자주 만나는 파일은 다음과 같습니다.
+- 프로그램은 평소에는 계속 아래로 실행됩니다.
+- 중단점을 꽂은 줄에 도달하면 잠시 멈추고, 당신이 확인할 때까지 기다립니다.
-| 파일 | 역할 |
-| --- | --- |
-| `package.json` | 실행 명령과 의존성 목록 |
-| `src/main.js` 또는 `src/main.ts` | 앱 시작점 |
-| `src/App.vue`, `App.jsx` 등 | 주요 화면 컴포넌트 |
-| `index.html` | 브라우저가 처음 여는 HTML |
-| `README.md` | 프로젝트 설명 |
+**한 단계 실행(Step)**
+중단점에서 멈춘 뒤에는 다음을 선택할 수 있습니다.
-모르는 파일이 나오면 AI에게 이렇게 묻습니다.
+- 한 줄씩 아래로 실행(step over)
+- 어떤 함수 내부로 들어가 자세히 보기(step into)
+ 빠른 영상을 바로 보는 것이 아니라 춤 동작을 하나씩 분해해 보는 것과 같습니다.
-```text
-이 프로젝트에서 package.json, src/main.*, App.* 파일이 각각 어떤 역할을 하는지 초보자 기준으로 설명해 줘.
-```
+**스냅샷(Snapshot) - 단순한 이해**
+여기서 “스냅샷”은 다음처럼 이해할 수 있습니다.
-## 5. 안전하게 작업하는 습관
+> **어떤 시간점의 “현재 상태”를 사진으로 찍어 나중에 비교하기 편하게 하는 것.**
+> 실제 도구에서 “스냅샷”은 다음을 가리킬 수 있습니다.
-### 5.1 수정 전 계획을 요청하기
+- 한 번 커밋한 시점의 프로젝트 전체 상태
+- 디버깅 중 어떤 시간점의 메모리 / 변수 전체 상황
+ 먼저 이 비유만 기억해도 충분합니다. **스냅샷 ≈ 어느 순간 상태의 사진**.
-큰 변경 전에는 바로 수정하게 하지 말고 먼저 계획을 받습니다.
+## [6. “프로젝트 관리”와 관련된 단어](#appendix-1-map)
-```text
-바로 수정하지 말고, 어떤 파일을 어떻게 바꿀지 먼저 계획만 말해 줘.
-```
+### 1. 프로젝트, 작업공간, 폴더
-### 5.2 변경 범위를 제한하기
+**프로젝트(Project)**
+하나의 애플리케이션을 구현하기 위해 같은 폴더에 둔 것들입니다.
-```text
-이번에는 src/components/ProductCard.vue만 수정해 줘.
-다른 파일은 건드리지 마.
-```
+- 소스 코드 파일
+- 설정 파일
+- 소재(이미지, 오디오 등)
-### 5.3 실행 결과 기준을 주기
+**작업공간(Workspace)**
+VS Code / Trae가 “이번에 현재 어떤 것들을 열었는지”를 설명할 때 쓰는 개념입니다.
-```text
-수정 후 npm run build가 통과해야 하고, 모바일 폭에서도 버튼이 줄바꿈되어야 해.
-```
+- 폴더 하나 열기 → 간단한 작업공간
+- 때로는 여러 폴더를 하나의 다중 프로젝트 작업공간으로 합칠 수도 있습니다.
-## 6. AI IDE가 틀릴 때
+### 2. Git, 저장소, 커밋(Commit)
-AI IDE도 자주 틀립니다.
+**Git(버전 관리 도구)**
+프로젝트의 “타임머신”으로 이해할 수 있습니다.
-- 없는 파일을 있다고 가정한다.
-- 사용하지 않는 라이브러리를 임의로 추가한다.
-- 실행되지 않는 코드를 만든다.
-- 기존 스타일과 다른 방식으로 구현한다.
+- 매번 한 묶음의 내용을 수정한 뒤 “버전 단체 사진”을 찍을 수 있습니다.
+- 나중에 필요할 때 어떤 과거 상태로 돌아갈 수 있습니다.
-이럴 때는 "틀렸어"라고만 하지 말고, 실제 상태를 기준으로 다시 지시합니다.
+**저장소(Repository / Repo)**
+Git을 켠 뒤 “버전 기록”이 있는 프로젝트 폴더를 “저장소”라고 부릅니다.
-```text
-방금 말한 파일은 실제 프로젝트에 없어.
-현재 파일 목록을 다시 확인하고, 존재하는 파일 기준으로 수정 계획을 다시 세워 줘.
-```
+**커밋(Commit)**
+매번 “이 변경 묶음은 하나의 단계적 성과다”라고 느낄 때 다음을 할 수 있습니다.
-## 과제
+- 설명 한 줄 작성(예: `Add score panel`)
+- 현재 전체 수정을 하나의 버전으로 묶기
+- Git이 이 순간의 상태를 저장함
+ 이 동작을 “commit을 했다”고 합니다.
-아무 작은 프론트엔드 프로젝트나 열고 다음을 해 보세요.
+## [7. “AI 개발 도구”와 관련된 단어](#appendix-1-map)
-1. AI에게 프로젝트 구조 설명을 요청한다.
-2. 메인 화면에 작은 UI 변경을 요청한다.
-3. 실행 후 오류가 있으면 오류 메시지를 붙여 넣고 고친다.
-4. 변경된 파일이 무엇인지 설명해 달라고 한다.
+### 1. AI IDE, Agent, SOLO 모드
-## 다음으로
+**AI IDE**
+일반 IDE 위에 “사람 말을 이해하고 직접 손을 움직일 수 있는” AI가 한 층 더해진 것입니다.
-[좋은 아이디어 찾기](/ko-kr/stage-1/finding-great-idea/)에서 어떤 제품을 만들지 고르는 방법을 배웁니다.
+- “스네이크를 만들어줘”라고 하면 프로젝트 구성과 코드 작성을 도와줍니다.
+- 오류 스크린샷을 주면 먼저 설명하고 수정도 시도합니다.
+- 한 줄씩 완성하는 데 그치지 않고 여러 파일을 함께 수정할 수 있습니다.
+**Agent(지능체)**
+Agent는 **항상 대기 중인 AI 작은 엔지니어**로 상상할 수 있습니다.
+
+- 프로젝트 구조를 읽습니다.
+- 작업을 분해합니다. 먼저 의존성 설치, 그다음 코드 생성, 그다음 프로젝트 실행.
+- 실행 중 오류가 나면 오류 정보를 바탕으로 스스로 방안을 조정합니다.
+
+**SOLO 모드(Trae 예시)**
+의미는 다음과 같습니다.
+
+> 당신은 “목적지”만 분명히 말하면 됩니다.
+> Agent가 스스로 “경로”를 계획하고,
+> 로컬에서 단계별로 실행하며,
+> 중간의 핵심 지점에서만 계속할지 묻습니다.
+
+### 2. 모델, 비밀키(API Key)
+
+**모델(Model, 여기서는 대형 언어 모델을 뜻함)**
+이 단어는 “뒤에서 작동하는 거대한 AI 두뇌”로 간단히 이해할 수 있습니다.
+
+- GPT, Claude, Kimi, GLM 등이 있습니다.
+- 서로 다른 모델은 “중국어 이해”, “코드 작성”, “추론”에서 수준이 다릅니다.
+- AI IDE에서는 보통 드롭다운 메뉴에서 서로 다른 모델로 바꿔 사용할 수 있습니다.
+
+**비밀키 / API Key**
+API Key는 **아주 긴 “고급 비밀번호 + 신분증 번호”**로 이해할 수 있습니다.
+역할은 하나입니다.
+
+> 다른 사람의 서버에 “저는 어떤 사용자입니다. 당신들의 AI 서비스를 사용할 수 있게 허용하고, 비용을 제 계정에 기록해 주세요”라고 알리는 것.
+
+몇 가지 요점:
+
+- 이 문자열은 보통 긴 무작위 영문자와 숫자입니다.
+- 공개된 곳(저장소, 스크린샷, 단체 채팅)에 올리면 안 됩니다. 다른 사람이 얻으면 당신 계정을 도용할 수 있습니다.
+- 도구에 API Key를 입력하는 것은 “자물쇠에 열쇠를 꽂는 것”과 같습니다. 이후 도구가 대응 AI 서비스를 호출할 수 있습니다.
+
+## [8. “브라우저 / 개발자 도구”와 관련된 단어](#appendix-1-map)
+
+**Chrome(Google 브라우저)**
+현재 프론트엔드 개발에서 가장 자주 쓰는 브라우저 중 하나입니다.
+
+- 웹페이지를 빠르게 엽니다.
+- 비교적 강력한 “개발자 도구”를 내장해 문제 확인에 편리합니다.
+
+**새로고침(Refresh / Reload)**
+현재 웹페이지를 다시 불러옵니다.
+
+- 프론트엔드 코드를 수정한 뒤 자동 새로고침 도구가 없다면, 수동으로 새로고침해야 결과를 볼 수 있습니다.
+
+**개발자 도구(DevTools)**
+브라우저 안에서 개발자를 위해 제공되는 도구 패널 묶음입니다.
+
+- 웹페이지 구조 확인(Elements)
+- 스타일 확인(Styles)
+- 오류와 로그 확인(Console)
+- 네트워크 요청 확인(Network)
+ Chrome에서는 보통 `F12` 또는 `Ctrl+Shift+I`로 엽니다.
+
+**Console(콘솔)**
+개발자 도구 안의 탭 하나이며, 다음을 전문적으로 보여 줍니다.
+
+- 작성한 `console.log(...)` 출력
+- 실행 중 발생한 오류(빨간 글자)
+ 이것을 “프로그램의 채팅창”으로 볼 수 있습니다.
+- 프로그램이 할 말이 있으면 여기에 씁니다.
+- 디버깅할 때 가장 자주 보는 부분이 바로 이곳입니다.
+
+나중에 학습 과정에서 새로운 단어를 만나면, 이 스타일대로 AI에게 모든 내용을 보충하게 할 수 있습니다.
+
+- 먼저 “이것이 무엇을 하는가”를 한 문장으로 쓰기
+- 그다음 “무엇에 비유할 수 있는가”를 한 문장으로 쓰기
+- 마지막으로 아주 간단한 예 하나 주기
+ 이렇게 하면 당신의 “개인 용어집”이 점점 길어지고 실용적이 되어, 컴퓨터와 더 잘 소통할 수 있게 됩니다.
diff --git a/docs/ko-kr/stage-1/learning-map/index.md b/docs/ko-kr/stage-1/learning-map/index.md
index 4b9aa7f..1424d23 100644
--- a/docs/ko-kr/stage-1/learning-map/index.md
+++ b/docs/ko-kr/stage-1/learning-map/index.md
@@ -1,101 +1,274 @@
---
-title: '아이디어에서 AI 제품까지 - Easy-Vibe 학습 지도'
-description: 'AI 코딩을 처음 시작하는 사람을 위한 Stage 1 한국어 학습 지도입니다. AI IDE, 요구사항 정리, 프로토타입 제작, AI 기능 통합까지 이어지는 흐름을 설명합니다.'
+title: '아이디어에서 AI 제품까지 - Easy-Vibe 학습 로드맵'
+description: 'AI 프로그래밍을 배우기 위한 전체 로드맵: 제로 베이스에서 풀스택 개발까지. Vibe Coding, Claude Code, Cursor 같은 AI IDE 도구를 익히고, 제품 사고, 풀스택 개발, AI 기능 통합을 배웁니다.'
---
+
+
# 아이디어에서 AI 제품까지
-예전에는 소프트웨어를 만들려면 프로그래밍 언어, 알고리즘, 프로젝트 경험이 먼저 필요했습니다. 지금은 출발점이 조금 달라졌습니다. 만들고 싶은 것이 분명하다면, AI가 코드 작성과 구현 과정을 상당 부분 도와줄 수 있습니다.
+예전에는 소프트웨어를 만들기 위한 문턱이 높았습니다. 프로그래밍을 알아야 했고, 알고리즘도 알아야 했고, 몇 년의 프로젝트 경험도 필요했습니다.
+지금은 다릅니다. 아이디어만 있다면 AI가 코드를 작성하도록 도와줄 수 있습니다.
-이 변화의 핵심은 단순합니다. **프로그래밍 언어가 점점 자연어에 가까워지고 있습니다.**
+이것은 거대한 변화입니다. **프로그래밍 언어가 자연어로 변하고 있습니다**.
-대형 언어 모델의 등장으로 개발은 더 이상 전문가만의 영역이 아닙니다. 예전의 어려움이 "코드를 어떻게 쓰지?"였다면, 이제 더 중요한 질문은 "무엇을 만들고 싶은가?"입니다.
+대형 언어 모델(LLM)의 등장은 개발을 더 이상 "기술 고수만의 전유물"이 아니라, 누구나 시작할 수 있는 도구로 바꾸었습니다. 예전에는 가장 어려운 것이 "코드를 어떻게 쓰는가"였다면, 지금 가장 어려운 것은 "**무엇을 만들 것인가**"입니다.
-> **Vibe Coding이란?**
-> 코드 한 줄부터 직접 쓰기보다, AI와 대화하며 원하는 기능과 화면을 설명하고 결과물을 함께 만들어 가는 개발 방식입니다.
+> **Vibe Coding이란 무엇인가요?**
+> 간단히 말하면 "말로 하는 프로그래밍"입니다. Vibe Coding은 직접 코드를 쓰는 대신 AI와 대화하는 방식에 의존해 프로그래밍 프로젝트를 완성하는 것을 뜻합니다.
-물론 AI가 코드를 써 준다고 모든 문제가 끝나는 것은 아닙니다. 실제로 쓸 수 있는 제품을 만들려면 다음 질문에 답해야 합니다.
+물론 AI가 코드를 쓰게 하는 것은 첫걸음일 뿐입니다. 정말 사용할 수 있는 제품을 만들려면 다음과 같은 문제도 만나게 됩니다.
-- AI가 만든 코드를 어떻게 더 깔끔하고 유지보수 가능하게 만들까?
-- 흩어진 코드 조각을 어떻게 실행 가능한 앱으로 묶을까?
-- 앱을 어떻게 배포해서 다른 사람이 쓰게 할까?
-- 텍스트 생성, 이미지 인식, 음성 처리 같은 AI 기능을 어떻게 제품에 넣을까?
+- AI가 깨끗하고 유지보수 가능한 코드를 쓰게 하려면 어떻게 해야 할까?
+- 흩어진 코드 조각을 실행 가능한 애플리케이션으로 어떻게 조립할까?
+- 애플리케이션을 실제로 배포하고 사람들이 쓰게 하려면 어떻게 해야 할까?
+- 텍스트 생성, 이미지 인식 같은 AI 기능을 내 제품에 어떻게 넣을까?
-Stage 1에서는 이 중에서 **아이디어를 제품 프로토타입으로 만드는 첫 번째 구간**을 다룹니다.
+이 질문들은 이 강의 안에서 답을 찾게 됩니다.
-## 누가 보면 좋은가
+학생이든, 교사든, 의사든, 노동자든, 기술을 전혀 모르는 평범한 사람이든 상관없습니다. 몇 년씩 프로그래밍을 먼저 배울 필요 없이, 2주면 실행되고 시연할 수 있는 제품 프로토타입을 만들 수 있습니다.
-| 대상 | 얻을 수 있는 것 |
-| --- | --- |
-| 완전 초보자 | 코드를 몰라도 AI와 함께 첫 프로토타입을 만드는 경험 |
-| 학생 | 과제, 공모전, 창업 아이디어를 직접 데모로 구현하는 방법 |
-| 직장인 | 반복 업무를 자동화하거나 작은 내부 도구를 만드는 방법 |
-| PM / 디자이너 | 문서나 화면 설계에서 끝내지 않고 동작하는 데모까지 만드는 방법 |
-| 창업자 / 소상공인 | 외주 전에 아이디어를 저렴하게 검증하는 MVP 제작법 |
-| 교사 / 강사 | 수업 도구, 퀴즈, 학습 보조 앱을 빠르게 만드는 방법 |
+| 당신의 정체성 | 이 강의가 도와줄 수 있는 것 |
+|---------|-------------|
+| 학생 | 과제, 대회, 창업 프로젝트를 직접 만들고 더 이상 남에게 부탁하지 않기 |
+| 직장인 | 반복 업무를 자동화하고, 효율을 높이며, 부업까지 개발하기 |
+| 제품 관리자 / 디자이너 | 아이디어가 종이에 머물지 않고, 상사나 고객에게 보여 줄 Demo를 빠르게 만들기 |
+| 창업자 / 중소기업 운영자 | 저비용으로 아이디어를 검증하고, 수만 위안을 들여 외주를 맡기지 않아도 MVP 만들기 |
+| 교사 / 교육 종사자 | 교육 도구, 수업 자료, 자동 문제 출제를 만들어 교육 효율 높이기 |
+| 의사 / 변호사 / 전문직 | 전문 업무 흐름을 자동화하고 자신만의 효율 도구 만들기 |
+| 누구나 | AI로 생활과 업무의 구체적인 문제를 해결하고, 불가능해 보였던 일을 가능하게 만들기 |
-## 성장 경로
+AI 시대에는 실행력과 아이디어가 언제나 기술보다 더 중요합니다.
-### 0. AI 코딩 감각 익히기
+## 성장 경로: "AI를 쓸 줄 아는 사람"에서 "AI 제품을 만들 줄 아는 사람"으로
-먼저 작은 게임이나 단순한 웹 페이지를 만들어 보며 AI가 코드를 생성하고 수정하는 흐름을 경험합니다. 핵심은 "AI가 무엇을 잘하고, 어디서 사람이 방향을 잡아야 하는지"를 감각적으로 이해하는 것입니다.
+
+
+
🎮
+
초보자 입문
+
AI 프로그래밍 체험
+
+ 스네이크 미니게임
+ 제로 베이스 시작
+ Vibecoding 첫 경험
+ 몇 분 만에 생성
+
+
+
-### 1. AI IDE와 작업 방식 익히기
+
+
+
🛠️
+
1단계
+
제품 관리자 / 운영
+
+ AI IDE (Cursor/Claude)
+ 요구사항 분해 & 프로토타입
+ AI 기능 접목
+ 완성 Demo 개발
+
+
+
+
💻
+
2단계
+
초중급 개발자 / 독립 개발자
+
+ Figma에서 코드로
+ Supabase 데이터베이스
+ Stripe 결제 통합
+ Dify 지식베이스
+
+
+
+
🚀
+
3단계
+
고급 개발자 / 아키텍트
+
+ Web/미니프로그램/멀티 플랫폼
+ MCP 고급 도구
+ RAG & LangGraph
+ 시니어 엔지니어 사고방식
+
+
+
-Cursor, Claude Code, Trae 같은 AI IDE는 단순한 코드 편집기가 아니라, 프로젝트 폴더를 읽고 수정하며 명령을 실행할 수 있는 개발 파트너에 가깝습니다.
+
-### 4. AI 기능 통합하기
+이 완성된 학습 경로를 통해 당신은 다음을 얻게 됩니다.
-프로토타입이 만들어지면 텍스트 생성, 이미지 생성, OCR, 음성 인식 같은 AI 기능을 붙일 수 있습니다. 이때 중요한 것은 모델 자체보다 **사용자 흐름 안에서 AI가 어디에 들어가야 자연스러운지**입니다.
+- **Vibe Coding 개발 능력:** Vibecoding 사고방식과 AI 코딩 도구를 능숙하게 사용해 개발 효율을 몇 배로 높입니다. 더 이상 문법을 억지로 외우는 것이 아니라, AI가 고품질 코드를 생성하도록 이끄는 방법을 배웁니다.
+- **풀스택 개발 역량:** UI 디자인에서 프론트엔드 구현까지, 데이터베이스 설계에서 API 개발까지, 로컬 개발에서 클라우드 배포까지 현대 Web 애플리케이션의 전체 기술 스택을 익힙니다.
+- **AI 기능 통합:** 다양한 멀티모달 AI API를 호출하는 법을 배우고, 텍스트, 이미지, 음성 등 AI 기능을 애플리케이션에 매끄럽게 통합하며, RAG 같은 기술로 지능형 제품을 구축합니다.
+- **제품 사고와 운영 능력:** 사용자 조사에서 요구사항 분해까지, MVP 설계에서 제품 반복 개선까지, 결제 통합에서 사용자 관리까지, 완전한 제품 개발과 운영의 폐쇄 루프를 형성합니다.
-### 5. 완성도 있는 데모로 다듬기
+# 다 배우고 나면 무엇을 할 수 있나요?
-마지막에는 사용자가 직접 만져볼 수 있는 형태로 다듬습니다.
+## 1단계: 나의 첫 제품 프로토타입 만들기
-- 빈 화면, 로딩, 오류 상태를 처리한다.
-- 예시 데이터를 실제처럼 만든다.
-- 주요 흐름이 끊기지 않게 한다.
-- 주변 사람에게 보여 주고 피드백을 받는다.
+이 단계는 프로그래밍 기초가 전혀 없거나, 조금은 알지만 자신감이 부족한 사람에게 적합합니다. 이론 지식을 잔뜩 먼저 배울 필요 없이, 바로 따라 만들면서 AI 도구로 코드를 작성하는 법을 배웁니다.
-## 이 단계의 목표
+**배우고 나면 할 수 있는 것**:
-Stage 1을 끝내면 다음 능력을 갖추는 것이 목표입니다.
+- AI 프로그래밍 도구로 웹 애플리케이션 하나를 독립적으로 완성하기
+- 제품 아이디어를 클릭 가능하고 상호작용 가능한 프로토타입으로 바꾸기
+- 프로토타입에 AI 기능 추가하기. 예: 텍스트로 이미지 만들기, 지능형 대화
+- 오류가 났을 때 어떻게 확인하고 해결해야 하는지 알기
-- 만들고 싶은 아이디어를 AI가 이해할 수 있는 요구사항으로 바꾼다.
-- AI IDE로 정적 웹 프로토타입을 만든다.
-- 오류를 무서워하지 않고 AI와 함께 수정한다.
-- AI API를 제품 흐름에 붙이는 기본 감각을 익힌다.
-- 다른 사람에게 보여 줄 수 있는 작은 데모를 완성한다.
+간단히 말하면, "실행되고, 다른 사람에게 시연할 수 있는" 무언가를 만들 수 있게 됩니다.
-## 다음으로
+먼저 미니게임으로 AI 프로그래밍을 체감하고, AI 프로그래밍 도구가 코드를 작성하고 오류를 고치도록 도와주는 법을 배웁니다. 이어서 간단한 페이지에서 시작해 점차 상호작용 가능한 다중 페이지 애플리케이션을 만들고, 텍스트-이미지 생성, 지능형 대화 같은 AI 기능을 더합니다. 마지막에는 독립적으로 완성 프로젝트를 끝내며, 당신의 아이디어가 실제로 구현될 가능성을 갖게 됩니다.
-[AI 시대, 말할 수 있으면 코딩할 수 있다](/ko-kr/stage-1/ai-capabilities-through-games/)에서 작은 예제로 AI 코딩의 감각을 먼저 경험해 보세요.
+# 왜 프로젝트 기반으로 훈련해야 할까요?
+
+> **현실 세계의 도전**
+>
+> 이유는 사실 간단합니다. 대부분의 학습자가 현재 상태로 바로 직장에 들어가면, 실제 프로젝트와 상사/고객의 "사회적 혹독함" 앞에서 한 걸음도 나아가기 어려울 가능성이 큽니다. 현실 세계에서 더 흔한 장면은 이렇습니다.
+
+> 지도교수 / 상사: 우리는 xxx를 만들려고 해. 목표는 yyy 효과를 내는 거야.
+>
+> 문서? 준비된 프레임워크? 상세한 요구사항 설명? 많은 경우 존재하지 않습니다.
+
+실제 업무 속 많은 과제는 본질적으로 높은 불확실성 속에서 한 번도 본 적 없는 문제를 해결하는 일입니다. 요구사항은 모호하고, 경계는 계속 변하며, 누구도 정답을 알려 주지 않습니다. 스스로 자료를 찾고, 실험하고, 프로토타입을 만들고, 계속 반복 개선한 끝에 "실행되고, 사용할 수 있고, 배포 가능한" 해결책을 내놓아야 합니다.
+
+이 강의가 하려는 일은 비교적 안전한 환경에서 미리 한 번 "모의 사회적 혹독함"을 겪게 하는 것입니다.
+
+- 어느 정도 난이도가 있어 보이는 프로젝트 과제를 통해 문제를 분해하고, 방안을 설계하고, 스스로 자료를 찾는 연습을 강제합니다.
+- 지나치게 "따라 하기만 하면 되는" 스캐폴딩과 코드가 아니라, 중대형 코드베이스를 읽고 이해하고 고치는 법을 배우게 합니다.
+- 아이디어에서 배포까지 이어지는 완전한 폐쇄 루프를 통해 실제 제품이 0에서 1로 만들어지는 전체 과정을 경험하게 합니다.
+
+단기적으로는 이런 훈련이 꽤 고통스러울 수 있습니다. 하지만 장기적으로는 구직과 커리어 성장에서 경쟁력을 크게 높여 줍니다. 더 큰 일을 감당할 수 있고, 불확실한 환경에서 돌파구를 찾을 수 있으며, AI를 "Demo를 가지고 노는 단계"에 머물게 하지 않고 실제 제품으로 구현할 능력을 갖추게 됩니다.
+
+# 질문의 기술: AI 시대의 필수 역량
+
+AI 시대에는 질문도 일종의 "기본기"입니다. 같은 코드, 같은 오류라도 **어떻게 질문하느냐가 AI가 어떤 답을 줄 수 있는지를 거의 결정합니다**. 두루뭉술한 설명으로 끝날지, 아니면 단계별로 실행 가능한 수정 방법을 줄지가 달라집니다.
+
+**좋은 습관을 들이세요**: "AI에게 질문하기"를 일상적인 개발 흐름의 일부로 생각하세요. 이해가 안 되거나 막히는 문제가 생기면 바로 질문합니다.
+
+## 왜 이것이 필수 역량인가요?
+
+- **현실에는 완전한 문서가 드뭅니다**: 더 자주 마주하는 것은 불명확한 요구사항, 반쯤 만들어진 코드, 흩어진 오류 정보입니다.
+- **AI는 당신 곁의 멘토이자 동료입니다**: 질문을 잘하는 사람은 AI를 "고품질 페어 프로그래밍 파트너"로 만들 수 있습니다.
+- **능력의 상한은 소통이 결정합니다**: 핵심 정보를 더 잘 제공하고, 출력 형식을 더 잘 제한할수록 답변은 더 쓸모 있어집니다.
+
+**흔한 오해**: "왜 오류가 나나요?"라고 한마디만 물으면 대부분 추측만 잔뜩 받게 됩니다. 맥락을 채워 넣어야 실행 가능한 방안을 얻습니다.
+
+## 정보를 AI에게 "먹이는" 방법: 스크린샷 vs 복사/붙여넣기
+
+두 방식 모두 가능하지만 용도가 다릅니다.
+
+| 방식 | 적합한 상황 | 핵심 요구사항 |
+| ------------ | ----------------------------------------- | ----------------------------------------- |
+| **복사/붙여넣기** | 오류 스택, 로그, 코드, 설정, API 응답 | 가능한 한 완전하게. 핵심 키워드 한 줄만 자르지 않기 |
+| **스크린샷** | UI 레이아웃 문제, 상호작용 이상, 도구 화면에서 버튼을 찾기 어려운 경우 | 전체 화면 캡처 + 중요 영역 표시. 가능하면 짧은 설명 한 문장 추가 |
+
+::: danger ⚠️ 중요한 전제
+**모든 AI가 이미지 입력을 지원하는 것은 아닙니다.** 스크린샷으로 소통하려면 AI가 멀티모달 능력, 즉 이미지를 이해하고 분석할 수 있는 능력을 갖춰야 합니다. 현재 이미지 입력을 지원하는 AI에는 Claude(Anthropic), GPT-4V/GPT-4o(OpenAI), Gemini(Google), 그리고 일부 중국산 대형 모델인 Tongyi Qianwen, Wenxin Yiyan 등이 있습니다.
+
+**사용 중인 AI가 이미지 입력을 지원하지 않는다면** 스크린샷은 인식되지 않습니다. 이때는 복사/붙여넣기로 텍스트를 전달하세요.
+:::
+
+## AI가 "잘 설명하게" 만드는 프롬프트 기법
+
+정답만 필요한 것이 아니라 답을 "배우고" 싶다면, 아래와 같은 지시를 쓰면 설명 품질이 크게 올라갑니다.
+
+> **학습형 질문 예시**
+>
+> - "먼저 이 개념을 5문장으로 명확하게 설명한 뒤, 제가 제대로 이해했는지 확인할 질문을 몇 개 해 주세요."
+> - "이 오류 메시지를 자세히 설명해 주세요. 왜 오류가 나는지 이해가 안 됩니다."
+
+# 오래 버텼는데도 해결이 안 됩니다. 포기하고 싶어요
+
+어쩌면 버티는 방법이 맞지 않았을 수 있습니다. 혼자 어둠 속에서 억지로 버티지 말고, 작성자와 조교들에게 이야기해 보세요. 이미 시도한 방법, 만난 구체적인 막힘, 현재의 심리 상태를 솔직하게 말해 주세요. 많은 경우 방향을 조금만 조정하거나 핵심 지식 하나만 보충해도 계속 앞으로 나아갈 수 있습니다.
+
+# 튜토리얼 설계가 합리적이지 않은 것 같아요
+
+언제든 작성자에게 연락하거나 issue를 제출하거나, 그룹/수업에서 직접 피드백해 주세요. 우리는 여러분과 함께 이 튜토리얼을 점점 더 좋게 다듬고 싶습니다. 어디가 명확하지 않은지, 어디의 경험이 좋지 않은지, 어디에서 헛수고를 하게 되었는지 솔직하게 지적해 주세요. 더 실제적이고 구체적인 피드백일수록 뒤에 오는 학습자가 덜 헤매도록 도와줍니다.
+
+# Reference
+
+- [난징대학교 컴퓨터과학기술학과 컴퓨터 시스템 기초 과정 실험](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
+
+
diff --git a/docs/public/sitemap.xml b/docs/public/sitemap.xml
index f637073..5184642 100644
--- a/docs/public/sitemap.xml
+++ b/docs/public/sitemap.xml
@@ -772,7 +772,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/ai-capabilities-through-games/
- 2026-05-11T06:13:58.867Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -781,7 +781,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-a-product-thinking/
- 2026-05-11T06:16:35.347Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -790,7 +790,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial/
- 2026-05-11T06:16:35.851Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -799,7 +799,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents/
- 2026-05-11T06:16:35.910Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -808,7 +808,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-b-common-errors/
- 2026-05-11T06:16:35.795Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -817,7 +817,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-c-consumer-scenarios/
- 2026-05-11T06:16:35.467Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -826,7 +826,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-consumer-scenarios/
- 2026-05-11T06:16:35.528Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -835,7 +835,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-double-diamond/
- 2026-05-11T06:16:35.636Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -844,7 +844,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-idea-sources/
- 2026-05-11T06:16:35.583Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -853,7 +853,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-industry-scenarios/
- 2026-05-11T06:16:35.410Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -862,7 +862,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-jobs-to-be-done/
- 2026-05-11T06:16:35.691Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -871,7 +871,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/appendix-mom-test/
- 2026-05-11T06:16:35.741Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -880,7 +880,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/building-prototype/
- 2026-05-11T06:13:59.053Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -889,7 +889,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/complete-project-practice/
- 2026-05-11T06:13:59.156Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -898,7 +898,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/finding-great-idea/
- 2026-05-11T06:13:58.991Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -907,7 +907,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/integrating-ai-capabilities/
- 2026-05-11T06:13:59.107Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -916,7 +916,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/introduction-to-ai-ide/
- 2026-05-11T06:13:58.932Z
+ 2026-05-11T15:22:02+09:00weekly0.9
@@ -925,7 +925,7 @@
https://datawhalechina.github.io/easy-vibe/zh-cn/stage-1/learning-map/
- 2026-05-11T06:13:58.815Z
+ 2026-05-11T15:22:02+09:00weekly0.9