https://www.youtube.com/watch?v=BX4T-jv8JQU

description: |-

1. 이건 꼭 알아야 한다^1

[? 질문] AI에게 “기획서(설계 문서)”를 제대로 만들어 주면, Flutter 앱을 원샷 프롬프트만으로도 실제로 뚝딱 개발할 수 있는가^2
[= 답] 일정 수준의 **정교한 기획 산출물(특히 프롬프트 디자인)**이 갖춰져 있으면, Claude Code 같은 에이전트형 도구가 마일스톤 기반으로 코드를 생성·수정·테스트하며 실제 앱을 상당 부분 “원샷에 가깝게” 구현할 수 있음을 실험으로 보여준다(다만 극단적인 방식이며 항상 정답은 아님).^58

[? 질문] 기획(아이디어) 단계에서 Claude와 GPT 중 누가 더 실무적으로 유용한가^3
[= 답] 둘 다 제안은 가능하지만, 영상의 실험에서는 Claude가 더 빠르고 핵심을 찌르는 답을 주고, 특히 기획 산출물(문서)과 프롬프트 디자인 명세를 더 “바로 개발에 쓸 수 있는 형태”로 작성했다고 평가한다. GPT는 장황하거나 단계가 추상적으로 정리되는 경향이 있어 “복사-붙여넣기 개발”에는 아쉬움이 있었다고 말한다.^16

[? 질문] “툴/모델” 경쟁에서 중요한 승부처는 무엇인가—Cursor냐 Claude Code냐, GPT-5냐 Opus냐가 핵심인가^52
[= 답] 발표자는 툴 자체보다 **아이디어(실사용 문제 해결)**와 집요하게 결과물을 뽑아내는 태도, 그리고 이를 가능하게 하는 기획서+프롬프트 디자인이 더 중요하다고 강조한다. 다만 실험 결과로는 “원샷 프롬프트” 관점에서 Claude Code 쪽이 더 강자로 보였고, Cursor(+GPT-5)는 공유 인텐트 수신 등에서 논리적 오류가 남아 “원샷 성공률”이 떨어졌다고 결론 낸다.^52

2. 큰 그림^4

이 콘텐츠는 “반짝이는 아이디어를 가장 빠르게 앱으로 만드는 방법”을 주제로, 기획 → 설계 문서화 → 프롬프트 디자인 → AI 코딩 도구로 Flutter 앱 구현까지의 전 과정을 실험처럼 따라간다.^5 발표자는 Gmail에서 선택한 텍스트를 공유로 받아 거절/승낙/보류 답장을 LLM이 작성해 주는 MVP 앱을 만들며, Claude와 GPT의 기획 능력 및 Cursor와 Claude Code의 개발 실행력을 비교한다.^6

• 작은 문제에서 출발하는 기획이 가장 강력한 앱 아이디어를 만든다: 거창한 목표보다 “오늘 겪은 불편함” 같은 현실적인 문제에 집중하라고 말한다.^7
• AI 활용의 핵심은 **문서 산출물 4종(PRD/TRD/유저 플로우/프롬프트 디자인)**이며, 그중에서도 개발을 실제로 굴리는 건 프롬프트 디자인이라고 강조한다.^28
• “원샷 프롬프트”로도 가능성을 보였지만, 에러·환경·논리 버그는 필연적이므로 인간의 검토·지시·디버깅 루프가 중요하다고 반복해서 말한다.^60

3. 하나씩 살펴보기^1

3.1 오프닝: 코딩보다 먼저 ‘기획’부터 시작한다^1

발표자는 자신을 “AI 코딩 연구소 바이브랩스”라고 소개하며, 사람들의 아이디어가 “가장 빠르게 세상에 나올 수 있도록” 바이브랩스 사용법을 공유·연구한다고 말한다.^1 오늘은 함께 Flutter로 근사한 앱 하나를 만들어보는 실습을 진행한다고 선언한다.^2

이어서 코딩 시작 전에 가장 먼저 해야 할 일을 질문 형태로 던진다.^2
[? 코딩을 시작하기 전에 가장 먼저 해야 될 일은 무엇일까요]
[= 바로 기획이다] 라고 답하며, 모든 위대한 앱/서비스는 “왜 만드는가”라는 질문에서 출발한다고 설명한다.^2

기획의 목표는 “나의 불편함 혹은 여러분의 문제 해결”이며, 방향성은 아주 작은 문제에서 시작된다고 강조한다.^4 “세상을 바꾸겠다”는 거대한 목표보다, 오늘 겪은 구체적 불편함이나 “친구가 매일 겪는 사소한 고민”에 집중해야 한다고 말한다.^4 그리고 이런 작은 문제의 해결책이 오히려 많은 사람의 공감을 얻을 때가 있다고 덧붙인다.^4

[!IMPORTANT] 기획 관점의 기준(영상이 제시하는 출발점)

• “거창함”이 아니라 구체적·현실적 불편을 잡아야 한다.^4
• MVP는 “가볍게”, 필수 기능만으로 시작한다는 철학이 뒤에서 반복된다.^12

3.2 MVP 아이디어 설정: Gmail 텍스트를 받아 LLM이 답장을 써주는 앱^5

본격 코딩 전에 “어떤 앱을 만들지”를 기획해야 한다고 전환한다.^5 발표자가 처음 구상한 앱은 다음과 같이 설명된다.

• “메일을 전송해 주는 아주 간단한 앱”^6
• (초기 구상) Gmail에서 특정 이메일의 텍스트를 가져오고, 이메일을 가져오면 LLM API를 호출해 이메일 답장을 자동 작성^6
• 스스로 “아주 간단하죠?”라고 말하며 MVP 관점의 단순함을 강조^6

이 단계에서 발표자는 “기획을 위해” Claude와 GPT 두 모델을 경쟁시키겠다고 선언한다.^5 “어느 친구가 훨씬 기획을 잘할지”를 실제 프롬프트로 확인하겠다는 방식이다.^5

3.3 1차 비교: Claude Sonnet 4 vs GPT-5—답변 속도와 ‘기술적 과잉’의 문제^7

발표자는 같은 프롬프트를 Claude(“Sonnet 4”)와 GPT(“5”)에 보낸다.^7 Claude가 먼저 답변을 마치고 GPT는 추론 중이라 시간이 더 걸린다고 관찰한다.^7

Claude 답변 검토에서 “Gmail 가져오기를 위해 Gmail API 사용” 같은 제안, Flutter 개발에 필요한 패키지 제안이 있었다고 요약해 읽어준다.^7 이어 GPT 답변도 “Claude와 거의 유사”하지만, “기술적으로 조금 더 깊게 접근”해 제안한다고 평가한다.^8

여기서 발표자는 중요한 기준을 제시한다. 지금은 “아이디어 브레인스토밍” 과정이므로 지나치게 기술적으로 접근하는 것은 좋지 않다고 말한다.^8 즉, 기술 설계의 디테일이 많다고 무조건 좋은 기획이 아니라는 관점을 깔고 간다.^8

3.4 아이디어를 MVP로 ‘경량화’: Gmail API 대신 ‘공유(Share)로 텍스트 전달’^9

발표자는 아이디어를 더 발전시키겠다며, MVP는 가볍게 가야 한다고 전제한다.^9 Google Cloud Console로 접근해 Gmail API를 쓰는 건 “덩치가 너무 크다”고 말하며, 필수 기능만 만들고 “심플하게 접근하자”고 프롬프트를 수정한다.^9

또한 “답장 쓰는 게 너무 어려워서 LLM API를 쓰고 싶다”는 페인포인트를 분명히 하고,^9 핵심 전환을 제안한다:

• 이메일 내용을 “자동으로 가져오는 게 아니라”
• 사용자가 텍스트를 선택하고
• 공유 기능을 통해 다른 앱(우리 앱)으로 보내는 방식이면 MVP가 가볍다^10
• 이런 기능을 구현할 수 있냐고 Claude와 GPT에 질문한다.^10

이 구간에서 발표자는 AI의 답변 태도에 대한 경고도 덧붙인다. AI들은 사용자의 발언에 대해 “좋건 나쁘건 무조건 좋다”는 식으로 긍정하는 편이라, 답변을 무조건 신뢰하면 안 된다고 말한다.^11 따라서 아이디어를 비판적으로 바라보는 시선이 필요하다는 주장이다.^11

3.5 기능 범위 줄이기 실험: ‘거절 메일만’ 넣어도 쓸까? (AI에게 비판 요청)^12

MVP를 더 줄여 “지나치게 다양한 기능” 대신 핵심 기능에 치중하자며, 발표자는 “거절 기능만 넣으면 어떨까”를 제안한다.^12 하지만 아이디어의 객관적 검증이 필요하니, Claude에게 다음과 같이 요청한다:

• “네가 객관적으로 판단해 봐”
• “거절 기능만 있으면 네가 사용자라면 쓸지”
• “비판적 시각으로 검토해 달라”^12

GPT 답변을 보며 발표자는 GPT가 “장황하게” 말하는 경향이 있고, Claude는 “필요한 부분만 딱딱 집어서 명확”한 편이라고 비교한다.^13 장황하면 사용자가 전체를 검토해야 하므로 판단이 쉽지 않다는 불만도 함께 제기한다.^13

Claude의 답변은 “솔직히 말하면 애매하다”는 식으로 시작했다고 소개한다.^14 발표자가 “객관적으로”를 요구했기 때문에, Claude가 “거절 메일을 과연 쓸 것인가”에 대해 부정적 시선을 밝혔고, 다만 강력한 페인포인트 해결 가능성은 있다고 말한 것으로 전달된다.^14

3.6 확장 제안: ‘거절/승낙/보류’ 3가지 답장 세트로 MVP를 재구성^15

발표자는 “거절 기능 하나만”은 심심하니, 승락(감사)과 보류까지 세 가지 형태로 답장해 주는 앱이 어떻겠냐고 다시 묻는다.^15

Claude 쪽 답변에서 한계/리스크가 제시됐다고 소개한다:

• 거절은 매일 오는 게 아니라 “빈도수 문제”가 있다^15
• 앱스토어에 이메일 작성 앱이 많다^15
• 거절만 특이하지만 주제가 좁아 다운로드 확장에 한계가 있다^15

GPT도 “거절만은 제한적이지만 승낙/감사/보류까지 있으면 일상 답변 대부분을 커버”할 수 있다고 말했고, “3세트가 재사용성 높고 시장성 있는 MVP”라고 설명했다고 전달된다.^16

이후 Claude 답변도 도착했으며, “거절만”보다 “승낙과 보류가 함께”가 훨씬 좋은 아이디어이고 “일상적인 대부분을 커버”한다고 말한 것으로 소개된다.^17 발표자는 Claude가 “핵심만 딱 집어서 정확하게” 답했다고 다시 평가한다.^17

3.7 앱 정체성 정리: ‘AI가 어려운 문장을 대신 써준다’ + 브랜딩 톤^18

발표자는 다음 프롬프트로 앱의 정체성을 더 구체화한다:

• 거절이 메인, 승낙(감사)과 보류는 서브가 되면 좋겠다^18
• 세 가지 정체성을 동시에 담아 달라^18
• 이메일 글쓰기도 글쓰기 장르인데 어렵다 → AI가 대신 작성하는 컨셉이 앱 정체성이다^18

Claude는 “핵심 가치는 어려운 문장을 대신 써 주는 앱”이라고 정리해줬고, 브랜딩 아이디어로 “정중한 답장 매너”, “부드러운 거절 느낌” 같은 톤을 제안했다고 한다.^19 GPT도 세 가지 정체성(거절/승낙/보류)에 충실히 답변하고 한 줄 아이디어와 브랜딩 키워드를 제안했다고 말한다.^19

발표자는 이어서 앱 이름 후보(브랜드 네이밍) 제안도 요청한다.^20

3.8 16문항 템플릿으로 기획 정리: “AI가 쓴 답을 인간이 최종 검토해야 한다”^21

목표가 정리됐으니 “논의한 내용을 바탕으로 질문지”에 맞춰 아이디어를 다시 정리하라고 Claude/GPT에 요청한다.^21 이때 “코딩 기획서 템플릿”에 총 16가지 질문이 있으며, 이를 복사해 붙여넣고 각 문항에 답하라고 시킨다.^21

발표자는 이 결과를 “검토해 보라”고 하면서, AI가 제안한 내용을 인간 입장에서 검토해야 한다고 강하게 말한다.^22 이유는 두 가지다:

• 위에서 논의한 내용을 AI가 “빠뜨릴 수도” 있다^22
• 내가 미처 생각 못한 아이디어가 “불연듯 튀어나올 수도” 있다^22

따라서 최종적으로 “여러분들의 아이디어를 검토하는 단계”를 반드시 가져야 하며, 수정할 부분이 있으면 노션 페이지로 옮겨 수정해도 된다고 안내한다.^22

[!TIP] AI 기획 결과를 다룰 때의 작업 루프(영상이 권하는 방식)

1. AI에게 16문항 등 구조화된 질문으로 기획을 뽑는다.^21
2. 인간이 “빠짐/왜곡/추가 아이디어”를 검토한다.^22
3. 필요하면 노션 등에서 수정·보강한다.^22

3.9 개발 전 필수 문서 4종: PRD/TRD/유저 플로우/프롬프트 디자인^23

발표자는 개발 시작 전에 “기획서를 작성해야” 한다고 하며, 기획서가 네 가지 종류라고 정리한다.^23

1. PRD: 제품 요구 사항 정리 문서^23
2. TRD: 기술적 제약 사항 정의 문서^24
3. 유저 플로우: 사용자의 행동 흐름을 예측/정리하는 문서^24
4. 프롬프트 디자인: 개발 단계에서 AI에게 기능 구현을 요청할 “프롬프트 명세”^25

특히 프롬프트 디자인을 이렇게 설명한다:

• 개발해야 될 앱의 “전체 기능”을 프롬프트 하나에 녹여낸다^25
• 1단계/2단계… 단계별로 개발해야 할 “구체적 개발 내용”을 정리한다^25
• 결과적으로 “프롬프트 디자인 명세서”에 개발 내용을 단계적으로 정리하는 것^25

발표자는 이후 작업으로, 노션에 제공된 “프롬프트 전체”를 복사하고, Claude가 16문항에 답한 내용을 “노션 폼 응답 붙여 넣기” 항목에 넣어 다시 실행하는 과정을 설명한다.^26 GPT도 동일하게 진행해 두 모델이 “설계 문서 네 가지”를 산출하도록 만든다.^27

3.10 산출물 생성 비교: Claude는 ‘바로 쓸 수 있는 프롬프트 디자인’, GPT는 ‘요약 느낌’^28

두 모델은 아티팩트 형식으로 PRD/TRD/유저 플로우/프롬프트 디자인을 작성한다.^28 발표자는 왼쪽 UI에서 각 문서를 클릭해 작성 진행 상황을 확인할 수 있다고 말하며, Claude가 더 빠르게 PRD→TRD→유저 플로우로 진행한다고 관찰한다.^28

여기서 발표자는 네 가지 중 가장 중요한 문서는 프롬프트 디자인이라고 단언한다.^30 이유는 실제로 Claude Code 같은 툴로 개발할 때 “프롬프트로 개발 내용을 요청”해야 하고,^30 많은 사용자가 개발 방향성을 명확히 못 잡기 때문에, AI가 미리 “개발 일정/단계/구체 구현”을 제안해주면 프롬프트를 정확히 보내고 구현하기가 쉬워진다는 논리다.^30 그래서 발표자는 “마지막에 반드시 프롬프트를 꼭 디자인해 달라”고 요청한다고 말한다.^32

또한 경험상 Claude가 개발도 잘하지만 **기술 문서 작성(기획서)**도 훨씬 잘한다고 믿는다고 밝힌다.^33

GPT의 프롬프트 디자인을 보고는 “골조 구축”, “공유 인텐트 수신 파싱” 등은 있지만 “명확하게 뭘 해라”가 부족하고, “단순 정리/요약 느낌”이라 실제 개발엔 모자라다고 평가한다.^34 반면 Claude는 단계별로 구현해야 될 프롬프트를 다 만들어줘서 “복사해서 붙여넣기만 하면 개발 진행”이 가능하다고 말한다.^35 Claude 쪽은 총 5단계를 제안했다고 한다.^35

이 판단으로 발표자는 “채치는 퇴출”이라고 말하며(기획 산출물 관점에서), Claude가 제안한 기획서 양식으로 개발을 진행하겠다고 결정한다.^36

3.11 문서 다운로드 및 프로젝트 준비: DOCS 폴더에 4종 문서 넣기^37

발표자는 Claude가 만든 네 가지 문서를 로컬 PC로 다운로드한다:

• 문서 UI에서 아래 화살표 → 마크다운 다운로드^37
• PRD, TRD, 유저 플로우, 프롬프트 디자인 모두 다운로드^37

이후 Flutter 개발 단계로 넘어가며, 개발 도구로 Cursor AI와 Claude Code 두 가지를 대상으로 “동일한 기획서” 기반 코딩을 진행하겠다고 한다.^38 이를 위해 폴더를 두 개 만든다(맥 기준):

• Claude Code 폴더
• Cursor 폴더^38

각 폴더에서 flutter create로 프로젝트를 생성하는데, 프로젝트 이름은 “무조건 소문자”여야 한다고 안내한다.^39

이어서 Cursor를 실행하기 위해 터미널에서 cursor .를 실행하는 방식도 보여준다.^40 왼쪽은 Claude Code(익스텐션으로), 오른쪽은 Cursor라는 구도를 만들었다고 설명한다.^40

또한 Cursor 내에서 Claude Code를 쓸 수 있다고 소개하며, 익스텐션 메뉴에서 Claude Code 확장을 설치하면 Cursor 안에서 Claude Code를 실행할 수 있다고 안내한다.^41

두 프로젝트 모두 최상단에 DOCS 폴더를 만들고, 다운로드한 네 가지 산출물을 드래그해 넣는다.^42 이때 발표자는 다시 한 번 “가장 중요한 문서는 프롬프트 디자인”이라고 강조하며, 단계별 개발 프롬프트가 있으니 쭉 읽고 불필요한 내용이 있으면 삭제/수정하라고 말한다.^43

3.12 Claude Code 실행 & Cursor 모델 선택: 원샷 개발을 위한 셋업^44

Cursor에서 “Run Claude Code” 아이콘을 클릭해 Claude Code를 시작하고, Yes proceed로 프롬프트 전달 준비를 마친다고 안내한다.^44 처음 설치자는 계정 인증 등이 필요하며, 터미널 설치 후 Cursor 확장 설치가 선행돼야 한다고 말한다.^45

한편 Cursor 쪽은 먼저 에이전트를 선택하고, 오토 모드를 해제해 모델을 직접 고른다.^46 “서로 경쟁” 그림을 위해 Cursor에서는 “일반적인 GPT-5 모델”을 선택했다고 한다.^46

3.13 ‘원샷 개발 프롬프트’의 개념과 구성: 문서 읽고, 생각하고, 마일스톤대로 개발하라^47

개발 시작 전에 발표자는 “원샷 개발 프롬프트”를 보여주며 이것이 첫 번째 프롬프트라고 설명한다.^47 특징은 다음처럼 설명된다:

• 업로드한 네 개 설계 문서를 “깊이 읽고 생각하고 분석”한 뒤 개발을 진행하도록 하는 가이드 문서^47
• 프롬프트 디자인에 정의된 1~5단계 마일스톤을 “정확하게 구현”하라는 지시^48
• 개발을 “전략적으로/순차적으로” 수행하라는 방향 제시^48

프롬프트 내부 요소로는:

• 페르소나/역할 부여를 분명히 설정^49
• 앱 이름과 네 가지 기획서를 읽으라는 지시^49
• 바이브 코딩 개념을 설명하며 “바로 코딩하지 말고 생각하면서 시니어 개발자답게 구성/계획/진행”^50
• 기능 구현 후 단위 테스트로 검증, 주요 로직이 정확해야 다음 시나리오로 넘어가라^51
• 테스트/빌드 오류 발생 시 원인 분석을 잘하라^51

이 프롬프트를 복사해 Claude Code와 Cursor에 각각 입력해 개발을 시작한다.^52

[!IMPORTANT] 영상이 정의하는 “바이브 코딩”식 원샷 접근의 요지

• 설계 문서를 먼저 읽고 “생각→계획→구현” 순서로 가라.^50
• 마일스톤을 순차 실행하고, 테스트로 스스로 검증하라.^51

3.14 개발 진행 관찰: 양쪽 모두 분석→구현, 작업 스타일 차이(멈춤/다음 스텝)^53

프롬프트 입력 후 양쪽 모두 설계 문서를 읽고, 개발 착수 전 “분석 작업”을 수행한다고 말한다.^53 Claude Code는 파일 검색/읽기 권한을 요구해 Yes를 클릭해 허용했다고 한다.^53

Cursor는 구현해야 될 내용을 “투두 리스트”로 만들어 점진적으로 진행하는 모습이 보인다고 관찰한다.^54 Claude Code는 분석을 끝내고 마일스톤 1(프로젝트 초기 설정/기본 구조 구축)을 시작한다.^55 Cursor도 분석 후 소스 파일 생성 및 Android manifest XML 수정에 착수했다고 한다.^55

발표자는 Claude가 “현재 수행 작업 외에 다음에 수행할 작업”도 미리 보여주기도 한다고 언급한다.^56 또한 Cursor는 중간중간 멈추며 “다음 스텝을 진행할 건지”를 묻는다고 말하고, 그때는 간단히 “다음”이라고 입력하면 진행된다고 설명한다.^57

3.15 ‘툴 논쟁’에 대한 관점: 툴보다 아이디어와 집요함, 그리고 비용 현실^58

진행 중 발표자는 “커서가 좋냐, 클로드 코드가 좋냐, GPT-5 출시 후 코덱스가 좋냐” 같은 논쟁이 많다고 언급한다.^58 그러나 자신은 툴이 중요하지 않은 것 같다고 말한다.^58 커서로도 원하는 기능 개발이 가능하고, Claude Code나 Codex도 가능하다고 인정한다.^58

여기서 강조하는 핵심은:

• 중요한 건 아이디어(사람들이 쓸 만한 아이디어)다^59
• 사람들이 쓸 서비스를 어떻게 만들어낼지가 중요하다^59
• “원하는 기능이 나올 때까지” AI와 씨름하며 결과물을 만들어내는 태도가 중요^59
• 모델마다 비용 차이가 있고 Claude Sonnet/Opus가 비싸다는 현실도 언급^60

또한 바이브 코딩에 뛰어드는 사람은 많지만 끝까지 남는 사람은 소수라는 관찰을 하며, 누구나 시작할 수 있지만 마지막까지 살아남는 사람은 극소수일 것이라고 말한다.^60 기술이 좋아져도 인간이 쓰지 않으면 소용없다는 관점도 덧붙인다.^61

마지막으로 현재 방식(원샷 프롬프트 하나로 마일스톤 1,2 포함 개발을 “완벽하게 맡겨 놓고 진행”)은 “극단적”일 수 있다고 스스로 평가한다.^62 프롬프트 디자인에 마일스톤이 정리되어 있으니 “단계를 하나씩 프롬프트로 접근”하는 방식도 나쁘지 않다고 말해, 원샷만이 정답이 아님을 인정한다.^63

3.16 진행 속도와 단계: Cursor는 빨리 3단계로, Claude는 1단계 진행 중 ‘점프’도 발생^64

Cursor는 2단계를 끝내고 3단계 개발을 진행하겠다고 말하며, 단계가 끝날 때 Keep를 클릭하면 현재까지 소스를 저장한다고 안내한다.^64 발표자는 “다음” 입력으로 3단계로 넘어간다.^65

Claude는 여전히 1단계를 진행 중이라고 말하지만, 관찰 결과 마일스톤 2 구현 과정에서 2단계 내용까지 스스로 판단해 일부 구현했는지 “2는 거의 다 구현했으니 바로 3으로 넘어가겠다”는 식으로 보여줬다고 설명한다.^66

발표자는 이 실험 자체를 “많이들 비교하고 궁금해하는” 질문(Claude Code vs Cursor, GPT-5 vs Opus/Sonnet) 때문에, 두 모델이 경쟁하는 그림을 만들어 승자를 검증하고 싶어서 진행했다고 말한다.^67 본인도 실제 누가 기능을 정확히 구현할지 궁금하다고 한다.^67

3.17 마일스톤 후반: Claude는 도움말/스플래시까지, Cursor는 테스트 실패 회고 후 재시도^68

Claude Code는 마일스톤 4도 완료했고, 마지막으로 도움말 화면과 스플래시 스크린을 작성하겠다고 공지했다고 한다.^68 Cursor는 내부 테스트를 했는데 실패했고, 실패 과정을 회고하고 다시 테스트를 진행하겠다고 보여줬다고 한다.^68

Cursor는 1~10번까지 관련 기능 구현과 실행 방법 안내를 제공했다고 하며, 발표자는 그 방법대로 실행하면 된다고 말한다.^68 다만 Cursor는 아직 개발이 끝나지 않고 계속 진행 중이라고 언급한다.^68

3.18 보안/환경 설정 이슈: LLM API 키 저장—.env 파일 생성 요구와 수정^69

앱의 중요한 요구사항 중 하나가 “LLM API 호출”이므로 API 키 보관 기능이 필요하다고 말한다.^69 Cursor가 “API 키 보안 저장”을 구현했다고 했지만, 실제 키를 어디에 저장할지 안내가 없었다고 지적한다.^69

발표자는 보통 이런 키는 .env 파일에 저장한다고 말하며, 파일을 만들고 키를 저장해 LLM API 호출 시 사용하도록 하라고 Claude Code에 프롬프트를 전달한다.^69 Claude Code가 .env 파일을 생성하고, Flutter에서 .env 접근 라이브러리를 설치한 뒤 키 사용 기능을 수정했다고 설명한다.^70

.env에 API 키를 설정하는 방법은 “키를 입력만 하면 된다”고 말하며, OpenAI나 Claude 사이트에서 키 발급을 받으면 된다고 안내한다.^71 보통 선결제로 5~10달러 정도 결제 후 키 발급을 받는다고 말한다.^71 그리고 키는 외부 노출하면 안 되고, 한 번 발급받은 키는 다시 열람할 수 없으니 안전한 곳에 저장해두라고 강조한다.^71

또한 디폴트 API 프로바이더가 Claude나 OpenAI로 되어 있으니, 본인은 OpenAI로 수정했다고 말한다.^72 이후 “키 설정 완료, 마지막으로 앱 빌드 테스트 진행하고 문제 있으면 수정하라”는 최종 프롬프트를 Claude Code에 전달한다.^73

이 구간에서 에러는 필연적으로 발생하니 당황하지 말고, 에러 메시지를 그대로 AI에 전달해 해결하면 대부분 해결책을 제시한다고 조언한다.^74 다만 “무조건 AI에게 해결해 달라”보다, 인간이 먼저 왜 발생했는지 고민하고 접근하는 게 더 중요하다는 생각을 말한다.^75

[!WARNING] API 키 운영에 대한 영상의 주의점

• 키는 노출 금지, 재열람이 안 되니 발급 즉시 안전 저장.^71
• “AI가 구현했다”는 말만 믿지 말고, 실제 저장 위치/사용 경로를 확인해야 한다(발표자의 Cursor 관찰에서 나온 문제의식).^69

3.19 앱 사용 시나리오(정상 동작 목표) 명확화: Gmail → 텍스트 선택 → 공유 → 답장 타입 선택 → LLM 생성 → 복사 → Gmail 붙여넣기^76

발표자는 앱 테스트 시나리오(정상 플로우)를 단계적으로 설명한다.^76

1. Gmail을 열고 특정 이메일을 연다^76
2. 이메일에서 텍스트를 선택한다^76
3. 복사가 아니라 공유 버튼을 눌러 “우리 앱”을 실행한다^76
4. 앱에서 답장 유형을 선택한다: 거절/승락/보류 중 하나^76
5. 선택 완료 → LLM 호출 → AI가 자동 답장 생성^76
6. 복사 버튼 클릭 → Gmail로 돌아가 답장하면 끝^76

이 흐름대로 정확히 작동하는지 확인하겠다고 말하며 테스트 단계로 넘어간다.^77

3.20 Claude Code 빌드/디버깅: Cursor의 Run & Debug로 Flutter 디버그 환경 구성, 에러 복사→AI에 전달^78

발표자는 현재 Claude Code로 코딩했지만, Claude Code 익스텐션이 Cursor 안에서 돌아가므로 Cursor의 UI로 디버그한다고 설명한다.^78 Cursor에서:

• 왼쪽 탐색기, 그리고 Run and Debug 메뉴로 이동^78
• Run and Debug 버튼 클릭 → 환경 선택^78
• Flutter이므로 Dart & Flutter 선택^78
• launch.json 설정이 생성됨^79
• 디버그 실행 버튼이 안 보이면 다른 창 갔다가 다시 Run and Debug로 오면 나타난다고 팁 제공^79
• Start Debugging을 누르면 디버깅 시작^79

시작하자 에러가 발생했고, “길고 긴 에러와의 싸움”이 시작됐다고 표현한다.^80 에러는 보통 빨간 메시지이므로, 우클릭해 복사한 뒤 Claude Code 채팅 창에 붙여 넣으면 상황을 인식해 수정해 준다고 말한다.^80

예시로 CocoaPods가 설치되어 있지 않아 실행 불가 메시지가 나와 설치를 진행하는 장면이 나오며, 권한 요청을 수락했다고 한다.^81 또한 크롬 브라우저로 실행하지 말고 안드로이드 에뮬레이터로 디버그하도록 변경했다고 말한다.^81

안드로이드 에뮬레이터를 우선하는 이유로, 실제 디바이스 연결 전 에뮬레이터로 먼저 진행하는 게 우선순위라고 설명한다.^82 에뮬레이터가 실행 중이지 않으면 찾고 실행하며, Pixel 9 Pro 에뮬레이터를 실행해 디버그를 진행했다고 말한다.^83

시간이 걸린 끝에 앱이 실행됐고, 중간 이슈 해결 때문에 시간이 소요됐지만 최종적으로 앱이 시작됐다고 한다.^84

3.21 Claude Code 결과 검증: 공유 인텐트로 텍스트 수신 → 답장 타입 선택 → LLM 답장 생성 성공^85

앱이 실행되면 주요 기능 안내와 사용 방법 안내가 나온다고 말한다.^85 이후 Gmail로 넘어가 이메일을 선택하고 텍스트를 선택한 뒤, 공유 메뉴에서 앱(“정중한 답장”)을 선택한다.^86

그 결과:

• Gmail에서 선택한 이메일 텍스트가 앱으로 “그대로 넘어왔다”^86
• 앱에서 답장 유형(정중한 거절/감사한 승락/신중한 보류) 중 승락을 선택^87
• LLM API 호출에 시간이 조금 걸리지만 답장을 생성해 줌^87
• 생성된 답장이 “의도를 정확하게 반영”한 것 같다고 평가^87
• 복사 버튼으로 Gmail에 돌아가 답장하면 된다고 말한다.^87

발표자는 직접 작성했다면 오래 걸렸을 답장을, 바쁜 삶에서 30분 이상 쓰기 어렵기 때문에 AI 도움으로 앱을 만들어 해결했다고 말한다.^88 이메일 작성 앱은 많지만 “세 가지 기능만 수행”하는 앱을 Claude Code로 만들었다고 정리한다.^88

구현 시간은 “대략 30분 정도” 걸린 것 같고, 원하는 기능을 수행했으며, 공유 기능으로 Gmail 텍스트를 앱으로 넘기고 LLM API 호출로 답장을 작성하는 프로세스를 정확히 구현했다고 결론 내린다.^89

3.22 Cursor(+GPT-5) 결과 검증: 빌드/실행은 성공했지만 ‘공유 인텐트 수신’ 논리 오류 발생^90

다음으로 발표자는 Cursor 쪽으로 돌아가 앱을 종료하고, API 키 설정 후 디버그로 앱 작동 여부를 확인하겠다고 한다.^90 에뮬레이터에서 디버그 모드 실행을 요청하고, Cursor에서도 Run and Debug → Dart & Flutter 선택으로 실행을 시도한다.^91

실행 중 에러가 발생해 메시지 전체를 복사해 Cursor에게 보낸다고 말한다.^92 우여곡절 끝에 Cursor도 개발을 끝냈고, 자바 관련 문제로 시행착오가 있었지만 기능 구현을 했다고 정리한다.^93

앱이 실행된 뒤 Claude 때처럼 Gmail에서 텍스트 선택→공유→앱으로 전송을 해보지만, “작동을 잘 하지 않는 느낌”이 들고 반복 시도에도 정상 작동하지 않는다고 말한다.^94

발표자는 상황을 명확히 진단한다:

• 안드로이드의 “share intent”로 Gmail 텍스트를 앱으로 보냈다^95
• 보냈지만 앱이 “수신을 하지 못하고 있는 상황”^95
• 문법적 에러가 아니라 논리적 에러가 발생한 것이고, Cursor에서 수정해야 한다^96
• 공유 인텐트는 기본적이고 중요한 기능인데 GPT-5 모델이 이를 “정확히 구현하지 못했다”는 평가^97

물론 문제를 설명하고 수정 요청을 하면 고칠 수는 있겠지만, “원샷 프롬프트로 목표 서비스를 제대로 구현” 관점에서는 Cursor가 실망스럽다고 말한다.^98

그래서 발표자는 (단일 실험으로 단정은 어렵지만) 앱 개발 관점에서 Cursor는 아직 부족한 면이 있고, 원샷 프롬프트는 아직 힘든 것 같다고 말한다.^99 전체 코드베이스 맥락을 충분히 이해하지 못하고 세부 기능을 면밀히 구현하지 못한 실망이 있으며, 얼마나 더 많은 개입이 필요할지의 문제도 있다고 덧붙인다.^100

3.23 결론 및 ‘바이브 코딩’의 핵심 정리: 기획 산출물 → AI 이해 → 결과물, 그리고 인간 개입의 정도^101

영상 마무리에서 발표자는 “아직까지 코딩에 있어서는 Claude Code가 훨씬 강자”라고 느꼈다고 말한다.^101 다만 다음에는 Codex CLI로 같은 프로젝트를 다시 해보겠다고 예고한다.^101

오늘 영상의 핵심 흐름을 발표자 스스로 정리한다:

• 기획된 아이디어를 “체계적으로 기획서로 정리”하는 관점에서 진행했다^102
• 네 가지 산출물 중 특히 프롬프트 디자인에 더 신경 썼다^102
• 정교한 프롬프트 디자인 문서대로 AI가 지시를 정확히 구현하는지에 초점을 두었다^103
• “앱 만들어줘” 한 문장으로 원하는 결과 얻기는 쉽지 않다^104
• 하지만 기획 문서가 완벽하다면 더 빠르고 정확히 구현할 수 있지 않을까 하는 바람에서 실험했다^104
• 이것이 자신이 연구하는 바이브 코딩의 핵심이라고 말한다.^105

그는 “아이디어를 현실로 만드는 길”은 기획을 깊게 하고 산출물을 면밀히 작성한 뒤, 그 산출물을 AI에게 이해시키고 AI가 결과물을 만들어내는 과정이라고 정의한다.^106 인간의 개입/조언 투입 정도에 따라 결과물은 달라지지만, “원샷 프롬프트로 이런 간단한 앱은 충분히 만들어낼 수 있다”는 가능성을 보여주고 싶었다고 말한다.^107

마지막으로 앞으로도 AI로 창작 과정을 돕는 효율적 방법을 공유하겠다고 하고, 구독/좋아요/알림/댓글을 요청하며 영상이 끝난다.^108

4. 핵심 통찰[^109]

1. [h “작은 불편”에서 출발한 기획이 MVP의 성공 확률을 높인다] 거창한 비전보다 “구체적 문제”를 잡아야 기능 범위를 빠르게 줄이고 구현 가능한 형태로 만들 수 있다는 논리가 전개된다.^4

   • 실행: 지금 겪는 반복적 불편을 1개 적고, “MVP에서 꼭 필요한 동작”만 남겨 3~5단계로 재구성한다.^9

2. [h AI 기획의 관건은 ‘답을 받는 것’이 아니라 ‘검토 루프’다] AI가 빠뜨리거나 새 아이디어를 내놓을 수 있으니, 인간이 최종 검토/수정을 반드시 해야 한다는 점이 반복된다.^22

   • 실행: AI 결과를 받은 뒤 “누락된 요구사항/원치 않는 기능/톤&브랜드”를 체크리스트로 검토한다.^22

3. [c 프롬프트 디자인은 ‘코딩 지시서’이며, 산출물 4종 중 실제 개발 실행력을 좌우한다] PRD/TRD/유저 플로우도 중요하지만, 실제 에이전트 툴에서 개발을 굴리는 문서는 프롬프트 디자인이라고 강조한다.^30

   • 실행: 마일스톤(1~5)별로 “생성해야 할 파일/수정해야 할 설정/테스트 방법/완료 조건”이 포함된 프롬프트를 문서로 만든다.^25

4. [h 원샷 프롬프트는 가능하지만 ‘극단적 방식’이며, 단계형 프롬프트도 유효하다] 발표자는 자신이 원샷으로 맡기는 방식이 극단적이라며, 마일스톤을 하나씩 프롬프트로 접근하는 방식도 나쁘지 않다고 말한다.^62

   • 실행: 초반에는 단계별 프롬프트로 안정화하고, 반복 가능한 프로젝트에서만 원샷을 실험한다.^63

5. [h AI 코딩에서 에러는 필연—에러 메시지 복사→AI에 전달 + 인간의 원인 이해가 동시에 중요] “길고 긴 에러와의 싸움”을 전제로, 메시지를 그대로 전달하면 AI가 수정하지만, 인간도 왜 발생했는지 고민하는 태도가 중요하다고 말한다.^80

   • 실행: 에러 메시지를 그대로 붙여 넣되, “재현 조건/기대한 동작/실제 동작”을 같이 적는다.^75

6. [h ‘원샷 성공’의 핵심 평가지표는 문법 오류보다 ‘논리/흐름’ 오류다] Cursor 결과는 앱이 실행되었지만 공유 인텐트 수신이 안 되는 논리 오류로 실패 판정을 받는다.^95

   • 실행: 유저 플로우의 각 연결 지점(예: 공유 인텐트 수신)을 “필수 통과 테스트”로 정의하고, 첫 실행 때 그 지점부터 검증한다.^76

7. [m 툴 논쟁보다 중요한 것은 아이디어와 집요함, 그리고 비용·지속성 현실이다] 툴은 수단이며, 사람들이 쓸 서비스를 끝까지 만들어내는 태도가 중요하고, 모델 비용도 고려해야 한다는 현실론을 제시한다.^59

5. 헷갈리는 용어 정리[^110]

MVP: 가장 작은 기능 집합으로 빠르게 검증하는 제품 접근. 발표자는 “가볍게 접근, 필수 기능만”을 반복해서 강조한다.^9
PRD: 제품 요구 사항 문서.^23
TRD: 기술적 제약 사항(Technical Requirements/Restrictions)을 정의하는 문서.^24
유저 플로우(User Flow): 사용자의 행동 흐름을 예측하고 정리한 문서.^24
프롬프트 디자인: 개발 단계별(마일스톤별)로 AI에게 어떤 구현을 시킬지 “프롬프트 명세”로 정리한 문서.^25
원샷 개발 프롬프트: 개발 시작 시 AI에게 주는 첫 프롬프트로, 설계 문서들을 읽고 마일스톤대로 전략적으로 구현·테스트하라는 가이드 역할을 한다.^47
Share Intent(공유 인텐트): 안드로이드에서 다른 앱의 “공유”로 넘어온 텍스트/데이터를 수신하는 메커니즘. 이 앱의 핵심 입력 경로로 등장한다.^95
.env 파일: API 키 같은 민감 정보를 코드 밖에서 관리하기 위한 환경 변수 파일로, 발표자가 키 저장 위치로 제시한다.^69

---

참고(콘텐츠 정보)[^111]

• 제목: AI에게 기획서를 줬더니 앱 하나를 뚝딱? Flutter 앱 자동 개발^1
• 채널: 바이브랩스^1
• 길이: 41분 4초^1
• 링크: https://www.youtube.com/watch?v=BX4T-jv8JQU^1
• 키워드: AI 코딩, Flutter, Cursor AI, Claude, 바이브 코딩 등(사용자 제공 메타)^1

[^109]: 영상 전반의 반복 주장(기획/프롬프트/검토/실험 결론) 종합: @[00:19], @[09:21], @[11:14], @[38:20], @[40:21] [^110]: 용어 정의에 근거가 되는 구간: @[09:01], @[09:21], @[18:28], @[26:21], @[37:30] [^111]: 사용자 제공 메타 + 영상 오프닝 정보: @[00:00] 및 본문 상단 입력 정보