docs: reuse zh-cn images for Korean stage 1
|
Before Width: | Height: | Size: 623 KiB |
|
Before Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 107 KiB |
|
Before Width: | Height: | Size: 379 KiB |
|
Before Width: | Height: | Size: 373 KiB |
|
Before Width: | Height: | Size: 656 KiB |
|
Before Width: | Height: | Size: 318 KiB |
|
Before Width: | Height: | Size: 41 KiB |
|
Before Width: | Height: | Size: 283 KiB |
|
Before Width: | Height: | Size: 119 KiB |
|
Before Width: | Height: | Size: 127 KiB |
|
Before Width: | Height: | Size: 108 KiB |
|
Before Width: | Height: | Size: 223 KiB |
|
Before Width: | Height: | Size: 385 KiB |
|
Before Width: | Height: | Size: 299 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 268 KiB |
|
Before Width: | Height: | Size: 167 KiB |
|
Before Width: | Height: | Size: 640 KiB |
|
Before Width: | Height: | Size: 13 MiB |
|
Before Width: | Height: | Size: 2.9 MiB |
|
Before Width: | Height: | Size: 514 KiB |
|
Before Width: | Height: | Size: 148 KiB |
|
Before Width: | Height: | Size: 5.3 MiB |
|
Before Width: | Height: | Size: 529 KiB |
|
Before Width: | Height: | Size: 313 KiB |
|
Before Width: | Height: | Size: 407 KiB |
|
Before Width: | Height: | Size: 587 KiB |
|
Before Width: | Height: | Size: 234 KiB |
|
Before Width: | Height: | Size: 651 KiB |
|
Before Width: | Height: | Size: 3.3 MiB |
|
Before Width: | Height: | Size: 3.1 MiB |
|
Before Width: | Height: | Size: 124 KiB |
|
Before Width: | Height: | Size: 238 KiB |
|
Before Width: | Height: | Size: 183 KiB |
|
Before Width: | Height: | Size: 442 KiB |
|
Before Width: | Height: | Size: 540 KiB |
|
Before Width: | Height: | Size: 4.1 MiB |
|
Before Width: | Height: | Size: 2.6 MiB |
|
Before Width: | Height: | Size: 3.7 MiB |
|
Before Width: | Height: | Size: 2.3 MiB |
|
Before Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 57 KiB |
|
Before Width: | Height: | Size: 602 KiB |
|
Before Width: | Height: | Size: 658 KiB |
|
Before Width: | Height: | Size: 333 KiB |
|
Before Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 236 KiB |
|
Before Width: | Height: | Size: 336 KiB |
|
Before Width: | Height: | Size: 880 KiB |
|
Before Width: | Height: | Size: 201 KiB |
|
Before Width: | Height: | Size: 388 KiB |
|
Before Width: | Height: | Size: 556 KiB |
|
Before Width: | Height: | Size: 478 KiB |
|
Before Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 114 KiB |
|
Before Width: | Height: | Size: 402 KiB |
@@ -129,7 +129,7 @@ AI가 등장한 뒤, 일반인에게 처음으로 완전히 새로운 가능성
|
||||
이런 “대화가 곧 프로그래밍”인 방식은 프로그래밍을 “코드 작성”에서 “요구사항 설명”으로 바꿉니다. 당신은 하위 기술 세부 사항을 신경 쓸 필요가 없고, AI에게 원하는 것을 명확히 알려 주기만 하면 됩니다. 그러면 AI가 아이디어를 실행 가능한 프로그램으로 바꿔 줍니다. 이것이 AI 시대 프로그래밍의 새로운 패러다임, 즉 **Vibe Coding(분위기식 코딩)** 입니다.
|
||||
:::
|
||||
|
||||

|
||||

|
||||
|
||||
간단한 요구사항을 입력한 뒤 **풀스택 개발** 버튼을 클릭하면, 웹페이지가 생성되는 전체 과정을 실시간으로 볼 수 있습니다. 보통 커피 한 잔을 내릴 시간 정도면 웹페이지가 자동으로 완성됩니다!
|
||||
|
||||
@@ -142,17 +142,17 @@ AI가 등장한 뒤, 일반인에게 처음으로 완전히 새로운 가능성
|
||||
5. 인터페이스는 간결하고 보기 좋아야 합니다.
|
||||
```
|
||||
|
||||

|
||||

|
||||
|
||||
생성이 끝나면 오른쪽에 탐색 가능한 웹 인터페이스가 나타납니다. 페이지 내용을 위아래로 스크롤해 보거나, 페이지 상단의 🧭 버튼을 클릭해 전체 화면 모드로 전환해 결과를 확인할 수 있습니다.
|
||||
|
||||
> 상단 버튼의 역할은 왼쪽부터 차례대로 다음과 같습니다. 화살표 버튼은 사이드 대화 기록 영역을 펼치고, 연필 버튼은 새 대화를 만들며, 순환 화살표 버튼은 페이지를 새로고침하고, 나침반 버튼은 전체 화면 모드로 전환합니다. Download 버튼은 프로젝트 다운로드, <> 버튼은 코드 보기 전환, Publish 버튼은 프로젝트 게시에 사용됩니다.
|
||||
|
||||

|
||||

|
||||
|
||||
이 웹페이지의 소스 코드를 보고 싶다면 오른쪽 위의 코드 아이콘을 클릭해 전체 코드를 확인할 수 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
::: tip 🌐 더 많은 AI 프로그래밍 도구 탐색하기
|
||||
|
||||
@@ -238,12 +238,12 @@ z.ai 외에도 아래의 훌륭한 AI 프로그래밍 플랫폼을 시도해 볼
|
||||
|
||||
> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘. 다음을 지원해야 해.
|
||||
>
|
||||
> 1. 서로 다른 단어를 먹을 수 있고, 그 단어들은 상자 안에 수집되어야 해.
|
||||
> 
|
||||
> 
|
||||
|
||||
> **💡 예시 프롬프트:** 스네이크 게임을 만들어줘. 다음을 지원해야 해.
|
||||
>
|
||||
@@ -251,13 +251,13 @@ z.ai 외에도 아래의 훌륭한 AI 프로그래밍 플랫폼을 시도해 볼
|
||||
> 2. 뱀이 단어 8개를 먹으면, llm이 이 단어들을 바탕으로 시를 만들어야 하고, 필요에 따라 이 시를 다시 섞을 수 있어야 해.
|
||||
> 3. 시가 완성되면, 다음 단계에서 이 시를 바탕으로 이미지를 자동으로 만들어야 해.
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
개발 과정에서는 기대만큼 좋지 않은 문제를 만날 수 있습니다. 예를 들어 버튼을 클릭해도 아무 반응이 없거나, 기능을 사용할 때 오류가 나거나, 기능이 예상대로 작동하지 않거나, 프론트엔드 페이지가 기대한 디자인과 맞지 않을 수 있습니다.
|
||||
|
||||
이런 상황에서는 모델에게 더 질문하여 예상치 못한 문제를 수정하도록 도와야 합니다.
|
||||
|
||||

|
||||

|
||||
|
||||
### 3.2 게임에 새 기능 추가하기
|
||||
|
||||
@@ -310,13 +310,13 @@ z.ai 외에도 아래의 훌륭한 AI 프로그래밍 플랫폼을 시도해 볼
|
||||
|
||||
z.ai의 답변은 다음과 같을 것입니다.
|
||||
|
||||

|
||||

|
||||
|
||||
이 프롬프트를 사용해 풀스택 개발 모드에서 프로젝트를 다시 생성할 수 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
@@ -649,7 +649,7 @@ HTML, CSS, JavaScript 같은 프론트엔드 기초 지식을 더 깊이 이해
|
||||
|
||||
> 💡 Vibe Coding이란 무엇인가요? 컴퓨터 과학자 [Andrej Karpathy](https://karpathy.ai/)(OpenAI 공동 창립자 중 한 명이자 Tesla 전 AI 책임자)는 2025년 2월 **vibe coding**이라는 용어를 제안했습니다. 이 개념은 LLM에 의존하는 코딩 방법을 가리키며, **프로그래머가 코드를 직접 작성하는 대신 자연어 설명을 제공하여 작동 가능한 코드를 생성할 수 있게 합니다.**
|
||||
|
||||

|
||||

|
||||
|
||||
문자 그대로 보면 Vibe Coding은 “말로 개발하는 방식”으로 이해할 수 있습니다. 핵심 변화는 다음과 같습니다. 더 이상 코드를 한 줄씩 직접 쓰고, 문법을 찾고, Bug를 고칠 필요가 없습니다. 원하는 것을 자연어로 바로 설명합니다. 예를 들면 다음과 같습니다.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 549 KiB |
|
Before Width: | Height: | Size: 961 KiB |
|
Before Width: | Height: | Size: 498 KiB |
|
Before Width: | Height: | Size: 292 KiB |
|
Before Width: | Height: | Size: 876 KiB |
|
Before Width: | Height: | Size: 762 KiB |
|
Before Width: | Height: | Size: 221 KiB |
|
Before Width: | Height: | Size: 914 KiB |
|
Before Width: | Height: | Size: 948 KiB |
|
Before Width: | Height: | Size: 1.0 MiB |
|
Before Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 825 KiB |
|
Before Width: | Height: | Size: 388 KiB |
|
Before Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 1.0 MiB |
|
Before Width: | Height: | Size: 129 KiB |
|
Before Width: | Height: | Size: 586 KiB |
|
Before Width: | Height: | Size: 333 KiB |
|
Before Width: | Height: | Size: 942 KiB |
|
Before Width: | Height: | Size: 431 KiB |
@@ -71,7 +71,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
넷째, **현 상태보다 더 나은 방법이나 도구를 제시해야 합니다**. 사용자는 원래 이 일을 어떻게 하고 있었나요. 머리로 기억했나요, 종이와 펜으로 적었나요, Excel을 썼나요, 스크린샷을 저장했나요, 아니면 여러 앱 사이를 오가며 처리했나요. 당신이 제공하는 것이 분명히 더 수월하고, 더 안정적이고, 더 즐거운 방식이라면, 그 아이디어는 비로소 가치가 생기기 시작합니다.
|
||||
|
||||

|
||||

|
||||
|
||||
위와 같은 사고가 잘 정리되지 않아도 괜찮습니다. 지금은 인공지능의 시대입니다. 위 내용을 하나의 완성된 프롬프트로 정리하고, 당신의 생각, 목표 사용자, 사용 장면을 함께 적어 대형 모델에게 보완과 정제를 맡길 수 있습니다. 모델을 언제든 온라인으로 대기하는 제품 공동창업자처럼 여기고, 반복해서 대화하고, 되묻고, 수정하면 흐릿한 개념을 구체화할 수 있습니다.
|
||||
|
||||
@@ -91,7 +91,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
가짜 요구의 전형적인 상황은 정반대입니다. 당신이 먼저 꺼내지 않으면 대부분의 사람은 그것이 문제라는 사실을 의식하지 못하고, 반드시 해결해야 한다고 느끼지도 않습니다. 당신이 묘사하는 사용 장면은 사용자의 일상생활보다 당신의 상상 속에 더 많이 존재합니다. 그들은 소개를 듣고 나서도 이것이 좋고 재미있다고 느낄 뿐, 돈을 내지 않고, 심지어 돌아서면 잊어버립니다. 이런 아이디어는 이야기를 쓰는 데는 괜찮을 수 있지만 제품을 만드는 데는 매우 위험합니다.
|
||||
|
||||

|
||||

|
||||
|
||||
그래서 **자기만족을 피하는 첫 번째 방어선은 사용자 요구를 이해하는 것**입니다. 시작할 때부터 당신은 겉보기에는 단순하지만 매우 중요한 질문에 답하도록 스스로를 몰아붙여야 합니다. 나 자신 말고, 누가 이 일 때문에 진지하게 골머리를 앓고 있는가. 포럼, 커뮤니티, 댓글 영역을 볼 수도 있고, 주변에서 사용자가 될 가능성이 있는 몇 사람에게 직접 물어볼 수도 있습니다. "나는 매번 이 일 때문에 발목이 잡힌다"거나 "지금 방식은 정말 너무 번거롭다"와 같은 실제 감정이 담긴 불평을 듣기 어렵다면, 그 아이디어는 실제 요구와 아직 거리가 있다는 뜻입니다.
|
||||
|
||||
@@ -117,7 +117,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
아래 네 가지 출처를 진지하게 실행한다면, 그 안에서 시작할 수 있는 방향을 쉽게 캐낼 수 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
### 자신의 삶을 사랑하기
|
||||
|
||||
@@ -127,7 +127,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
고양이 사진을 찍는 일을 생각해 봅시다. 많은 사람이 이런 일을 겪습니다. 자신은 휴대폰을 들고 있는데 고양이는 도무지 렌즈를 보지 않습니다. 고개를 숙여 발을 핥거나 다른 구석만 바라봅니다. 그렇다면 휴대폰이나 태블릿 화면에 자동으로 움직이는 빨간 점, 깃털, 작은 벌레 애니메이션이 나타나 고양이의 시선을 끌어 주는 작은 도구를 만들 수는 없을까요? 촬영 버튼을 누르면 그것이 자동으로 전면 카메라 근처를 한 바퀴 돌며 고양이의 시선을 렌즈 방향으로 "속여" 오고, 동시에 연속 촬영을 해서 그중 선명하고 예쁜 한 장을 골라 줍니다. 한 걸음 더 생각하면, 이 앱은 고양이마다 어떤 색, 어떤 이동 경로에 가장 흥미를 보이는지도 기록하고, 다음에는 그 고양이만의 전용 낚시 모드를 자동으로 사용해 성공률을 높일 수 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
당신이 화장이나 스킨케어 과정을 즐긴다면, 집 화장대 위의 모든 제품 뒤에는 많은 시행착오와 의사결정이 숨어 있습니다. 매번 메이크업 사진을 휴대폰 앨범에 찍어 두는 데 이미 익숙할 수 있습니다. 하지만 나중에 돌아볼 때마다 그날 어떤 립스틱과 어떤 아이섀도 팔레트를 썼는지 하나하나 떠올려야 합니다. 그렇다면 이런 정보를 체계적으로 기록해서 나만의 메이크업 도감을 만들 수 있지 않을까요? 더 나아가 앱이 어떤 메이크업을 어떤 상황에서 가장 많이 사용했는지, 어떤 조합이 사진에서 가장 잘 나왔는지 통계로 보여 줄 수도 있습니다. 그러면 매번 화장을 고를 때 처음부터 다시 생각하지 않아도 됩니다.
|
||||
|
||||
@@ -230,7 +230,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
"**괜찮아, 이건 나중에 기회가 되면 만들면 되지...**"
|
||||
|
||||

|
||||

|
||||
|
||||
생각만 하지 마세요. 바로 지금입니다. 이 장에서 하려는 일은, 아이디어를 만들 수 있는 버전으로 분해하는 방법을 배우도록 돕는 것입니다. 무에서 유를 만드는 일은 천재성에 의존하지 않고, 반복해서 연습할 수 있는 구체적인 동작들에 의존한다는 것을 보게 됩니다. **발산, 수렴, 분해, 세분화, 참고, 질문**입니다. 이 순서대로 하면 팀이 없어도, 시간이 많지 않아도, 하나의 아이디어를 흐름이 돌아가는 앱 데모로 바꿀 수 있습니다.
|
||||
|
||||
@@ -244,9 +244,9 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
더블 다이아몬드 모델은 영국 디자인 카운슬이 제시한 혁신과 디자인 프로세스 프레임워크입니다. 전체 과정을 연속된 두 개의 마름모, 즉 "더블 다이아몬드"에 비유합니다. 첫 번째 다이아몬드는 "문제 발견"에서 "명확한 문제 정의"로 가는 과정으로, 먼저 넓게 발산하고 충분히 조사하며 사용자를 이해한 뒤, 진짜 해결해야 할 핵심 문제로 수렴하는 것을 강조합니다. 두 번째 다이아몬드는 "솔루션 발전"에서 "최종 솔루션 전달"로 가는 과정으로, 가능한 해결 생각을 과감히 발산하고 탐색하며 프로토타입을 반복한 뒤, 다시 수렴하고 선별하고 다듬어 가장 적합하고 구현 가능한 방안을 만드는 과정입니다. 더블 다이아몬드 모델은 문제와 솔루션 두 단계 모두에서 "발산-수렴"을 거쳐야 함을 강조합니다. 처음부터 솔루션으로 뛰어드는 것을 피함으로써 혁신의 품질과 성공률을 높이는 것입니다.
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
### 첫 번째 다이아몬드: 문제 이해, 단일 지점에서 전체 모습으로 발산하고 수렴하기
|
||||
|
||||
@@ -282,7 +282,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
여기서 필요한 능력은 **분해하고 세분화하여 추상을 구체로 바꾸는 능력**입니다. 크고 넓은 목표를 바로 손댈 수 있는 최소 실행 항목까지 조금씩 쪼개고 세부화하는 것입니다. 이 능력은 제품을 만들 때뿐 아니라 생활에서도 매우 중요합니다.
|
||||
|
||||

|
||||

|
||||
|
||||
### 생활 예시에서 시작하기: 햄버거가 먹고 싶다는 말은 도대체 무엇을 뜻하는가
|
||||
|
||||
@@ -316,7 +316,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
"효율"이라는 말도 따로 쪼개 볼 가치가 있습니다. **효율은 도대체 무엇을 뜻할까요? 단순히 속도인가요, 아니면 속도뿐 아니라 품질, 오류율, 이해 난이도까지 포함하나요?** 예를 들어 20페이지 문서를 30분에 읽던 것을 5분에 핵심만 훑게 만드는 것은 속도입니다. 사용자가 요약에서 잘못된 논리나 데이터 모순을 빠르게 발견하게 하는 것은 품질입니다. 원래 전문 용어에 익숙하지 않은 사람도 설명과 표시를 통해 보고서를 이해하도록 돕는 것은 인지 문턱을 낮추는 일입니다. 스스로에게 아주 직접적으로 물을 수 있습니다. 이 앱이 매우 성공했다면 사용자에게 가장 큰 변화는 무엇인가. "문서에 쓰는 시간이 절반으로 줄었다"인가, 아니면 "문서 관련 일을 할 때 마음이 덜 지쳤다"인가. 이 문장에 명확히 답하면 기능 우선순위의 근거가 생깁니다.
|
||||
|
||||

|
||||

|
||||
|
||||
#### 두 번째 층의 분해와 세분화
|
||||
|
||||
@@ -373,7 +373,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
이런 설명은 더 이상 공허한 구호가 아니라, 곧바로 프롬프트가 되거나 AI가 plan으로 실행할 수 있는 지시 묶음이 됩니다. 예를 들어 이 문장을 개발 능력을 가진 AI에게 던져 개발 방안을 생성하게 하거나, 직접 최소 사용 가능 버전의 웹 앱을 만들게 할 수 있습니다. 디자이너에게 주어 구체적인 인터페이스 프로토타입을 그리게 할 수도 있고, 엔지니어 동료에게 보내 구현 비용과 기술 방안을 빠르게 평가하게 할 수도 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
여기까지 하면 두 가지 현실적인 변화를 보게 됩니다. 첫째, 더 이상 "효율을 높이는 앱을 만들겠다"는 문장에 눌리지 않고, 즉시 손댈 수 있는 단계를 갖게 됩니다. 둘째, 다른 사람과의 소통 비용이 급격히 낮아집니다. 충분히 구체적으로 쪼갠 초기 방안을 내놓을 수 있기 때문입니다.
|
||||
|
||||
@@ -390,7 +390,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
전체 앱을 먼저 세 종류의 페이지로 나눌 수 있습니다. 입구 페이지, 작업 페이지, 결과 페이지입니다.
|
||||
|
||||

|
||||

|
||||
|
||||
### 입구 페이지: 사용자는 어디에서 들어오고, 첫눈에 무엇을 보는가
|
||||
|
||||
@@ -439,9 +439,9 @@ const duration = '약 <strong>6시간</strong>'
|
||||
- 결과를 보여 줄 때 가장 중요한 정보가 가장 눈에 띄는 곳에 놓여 있는가. 부차 정보는 어떻게 접어 두었는가.
|
||||
- 새 사용자가 처음 들어올 때 다음에 어떻게 쓰는지 알려 주는 짧은 안내 흐름이 있는가.
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
다음과 같은 웹페이지 스크린샷 수집 사이트를 참고할 수 있습니다.
|
||||
|
||||
@@ -518,7 +518,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
좋은 앱의 가장 직접적인 특징은, 어떤 장면에서 사람이 실제로 조금이라도 이익을 얻도록 한다는 것입니다. 이 이익은 거창할 필요도 없고, 어려운 말로 포장할 필요도 없습니다. 하지만 당신이 분명히 말할 수 있을 정도로 구체적이어야 합니다. **그것이 도대체 사용자가 무엇을 덜 하게 했는지, 얼마나 시간을 덜 쓰게 했는지, 또는 어떤 일을 덜 실수하게 만들었는지** 말입니다.
|
||||
|
||||

|
||||

|
||||
|
||||
예를 들어 간단한 회의록 도구가 있다고 합시다. 녹음을 업로드하거나 회의 중 직접 녹음하기만 하면, 회의가 끝난 뒤 구조화된 회의록을 자동으로 생성하고, 할 일, 담당자, 마감일을 목록으로 정리해 준다면, 사용자가 절약하는 것은 단순한 타자 시간이 아닙니다. 기록, 정리, 선별, 형식화 출력까지 전체 과정의 정신적 에너지입니다. 이 도구가 회의 한 번마다 한 사람에게 대략 20분을 절약해 준다고 매우 명확히 말할 수 있습니다. 팀 전체가 매주 이런 회의를 10번 한다면 총 절약 시간은 상당합니다.
|
||||
|
||||
@@ -530,7 +530,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
또 하나 과소평가되기 쉽지만 매우 중요한 특징은 **좋은 앱은 대개 많은 설명이 필요 없다는 것**입니다. 사용자가 처음 열었을 때 직감만으로 어디서 시작해야 할지, 무엇을 누르면 무슨 일이 생기는지 대략 알 수 있습니다. 가장 큰 버튼은 보통 가장 핵심적인 일을 하며, 가장 중요한 입구는 진짜 중요한 위치에 놓여 있습니다. 메뉴 세 번째 층에 숨어 있지 않습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
방금 당신의 앱을 다운로드한 새 사용자를 상상해 보세요. 그는 줄을 서 있거나, 차 안에 있거나, 카페에서 무심코 열었을 수 있습니다. 그때 네트워크 신호가 꼭 좋지는 않고, 긴 설명서를 읽을 인내심도 없습니다. 그가 견딜 수 있는 혼란의 시간은 대개 몇 초뿐입니다. 이 몇 초 안에 어떤 명확한 안내도 보이지 않고, 다음에 무엇을 해야 할지 모르면, 바로 닫아 버리고 다시 돌아오지 않을 가능성이 큽니다.
|
||||
|
||||
@@ -560,7 +560,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
## 3.2 요구 통찰: **매슬로의 욕구 단계 이론**
|
||||
|
||||

|
||||

|
||||
|
||||
앱을 만들기 전에 많은 사람은 곧장 기능 차원으로 뛰어듭니다. 이쪽에 무엇을 더 만들 수 있을까, 저쪽에 버튼을 하나 더 넣을까. 그러나 앱이 살아남을 수 있는지를 진짜로 결정하는 것은, 당신이 사람의 어느 층위의 욕구를 얼마나 정확히 밟았는가입니다.
|
||||
|
||||
@@ -643,7 +643,7 @@ const duration = '약 <strong>6시간</strong>'
|
||||
|
||||
C 사이드 앱은 개인 사용자를 향하며, 각자의 일상생활 안에 박혀 있습니다. 흔한 유형에는 콘텐츠형, 도구형, 엔터테인먼트형, 소셜형, 학습형 등이 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
콘텐츠형 앱은 뉴스 읽기, 짧은 영상 플랫폼, 팟캐스트 도구 같은 것입니다. 핵심 작업은 보통 제한된 시간 안에 방대한 정보에서 사용자가 관심 있는 내용을 걸러 내게 하는 것입니다. 동시에 계속 새로운 것이 있어 사용자가 돌아오게 해야 합니다.
|
||||
|
||||
@@ -669,7 +669,7 @@ C 사이드의 진짜 요구를 판단하는 간단한 방법은, 사용자가
|
||||
|
||||
B 사이드 앱은 기업, 팀, 기관 또는 어떤 부서를 향합니다. 흔한 유형에는 ERP(자원 관리 시스템), CRM(고객 관계 관리), 협업 오피스 도구, 각종 SaaS 도구, 업계 내부 관리 시스템 등이 있습니다.
|
||||
|
||||

|
||||

|
||||
|
||||
이런 앱이 C 사이드와 가장 다른 점은 여러 역할의 요구를 동시에 만족시켜야 한다는 것입니다. 사용자는 현장 직원일 수 있지만, 의사결정자는 관리자나 대표일 수 있습니다. 데이터의 소유자는 조직 자체일 수 있고, 승인 흐름은 여러 부서를 포함할 수 있습니다. 당신은 사용자가 쓰기 좋다고 느끼게 해야 할 뿐 아니라, **의사결정자가 투자 대비 수익을 보게 해야 하며**, 전체 조직이 위험과 규정 준수 측면에서 안전하다고 느끼게 해야 합니다.
|
||||
|
||||
@@ -770,7 +770,7 @@ AI가 없어도 앱이 성립하고, 명확한 향상 지점도 찾았다면,
|
||||
|
||||
더 명확한 사고 방식은 AI를 몇 가지 다른 부품으로 보는 것입니다. **AI는 두뇌가 될 수도 있고, 눈이 될 수도 있고, 손이 될 수도 있습니다**. 제품 목표에 따라 AI가 그중 어떤 부분을 담당하는지 결정해야 합니다. 가능하다면 처음에는 한두 가지 역할만 골라 잘 만드는 것이 좋습니다. 한꺼번에 모두 집어넣지 마세요.
|
||||
|
||||

|
||||

|
||||
|
||||
**AI가 두뇌 역할을 할 때는 주로 문자 내용을 이해하고 생성하거나, 복잡한 정보 사이에서 추론을 담당합니다.** 예를 들어 회의록 도우미를 만든다면, 긴 녹음에서 진짜 핵심 토론 지점을 잡아낼 수 있어야 합니다. 단순히 시간 순서대로 나열하는 것이 아닙니다. 학습 앱을 만든다면, 사용자의 답을 바탕으로 그가 개념을 이해하지 못한 것인지, 아니면 단지 부주의하게 단계를 잘못 쓴 것인지 판단하고 서로 다른 피드백을 제공할 수 있어야 합니다. 이런 장면에서 AI의 가치는 사용자가 한 말을 읽고, 사용자가 제공한 자료를 이해한 뒤, 구조와 논리를 가진 출력을 생성할 수 있다는 데 있습니다. 당신이 해야 할 일은 사용자의 문제를 분명히 묻고, 컨텍스트를 충분히 정확하게 먹여 이 두뇌가 판단할 만큼 충분한 정보를 갖게 하는 것입니다.
|
||||
|
||||
@@ -839,7 +839,7 @@ AI가 없어도 앱이 성립하고, 명확한 향상 지점도 찾았다면,
|
||||
|
||||
먼저 서로 다른 장면이 AI에 요구하는 것이 다르다는 점을 이해해야 합니다. 앞의 workflow와 context 예시가 보여 준 것처럼, 흐름과 정보가 모두 확실할 때 AI는 사실 발휘할 공간이 별로 없고 전통 자동화로 충분합니다. 흐름은 확실하지만 정보가 불확실할 때 AI의 가치는 이해와 보완에 있습니다. 흐름이 불확실할 때에야 AI는 계획과 탐색을 해야 합니다. 이 분해 방식의 본질은 불확실성의 출처와 정도를 식별하는 것입니다. AI의 핵심 능력은 불확실성 속에서 패턴과 연관을 찾는 것입니다. 이 사고 방식은 Agent에만 적용되는 것이 아닙니다. 이미지 인식, 콘텐츠 생성, 추천 시스템 등 여러 영역에서도 똑같이 중요합니다. 예를 들어 AI 누끼 도구를 만든다면, 입력은 확실합니다(이미지 한 장). 하지만 가장자리 인식의 정확성, 복잡한 배경 처리 능력이 바로 불확실성이 있는 곳입니다.
|
||||
|
||||

|
||||

|
||||
|
||||
하지만 AI는 불확실성을 해결하는 동시에 새로운 불확실성도 도입합니다. 출력은 확률적이며, 잘못 이해하고, 추론이 치우치고, 환각을 만들 수 있습니다. 서로 다른 장면과 서로 다른 사용자는 이런 불확실성을 견디는 정도가 완전히 다릅니다. 그래서 다음 질문도 해야 합니다.
|
||||
|
||||
@@ -1096,4 +1096,4 @@ AI가 없어도 앱이 성립하고, 명확한 향상 지점도 찾았다면,
|
||||
|
||||
**_결말은 그곳에 이르기까지의 어떤 순간보다도 더 중요하지 않습니다._**
|
||||
|
||||

|
||||

|
||||
|
||||
|
Before Width: | Height: | Size: 28 KiB |
|
Before Width: | Height: | Size: 117 KiB |
|
Before Width: | Height: | Size: 2.8 MiB |
|
Before Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 61 KiB |
|
Before Width: | Height: | Size: 231 KiB |
|
Before Width: | Height: | Size: 736 KiB |
|
Before Width: | Height: | Size: 77 KiB |
|
Before Width: | Height: | Size: 166 KiB |
|
Before Width: | Height: | Size: 117 KiB |
|
Before Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 94 KiB |
|
Before Width: | Height: | Size: 94 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 438 KiB |