첫 프롬프트는 앱의 설계도입니다
앱 빌더형 도구를 처음 열면 가장 먼저 마주치는 것이 커다란 입력창입니다. Lovable이든 Replit Agent든 Bolt.new든, 도구 이름은 달라도 시작은 비슷합니다. "무엇을 만들까요?"라고 묻는 빈칸이 있고, 우리는 그 앞에서 잠시 멈춥니다.
막상 쓰려고 하면 이런 생각이 듭니다.
"독서 기록 앱 만들어줘."
"할 일 관리 앱 만들어줘."
"예약 문의 앱 하나 만들어줘."
틀린 요청은 아닙니다. 하지만 이렇게만 쓰면 AI는 너무 많은 부분을 스스로 추측해야 합니다. 누가 쓰는 앱인지, 어떤 정보가 필요한지, 화면은 몇 개면 되는지, 디자인은 차분해야 하는지 귀여워야 하는지, 저장은 꼭 필요한지 알 수 없습니다.
AI가 추측을 많이 할수록 결과물은 내 머릿속 앱과 멀어집니다. 반대로 내가 처음부터 필요한 정보를 차분히 알려주면, AI는 훨씬 안정적으로 첫 버전을 만들어냅니다.
첫 프롬프트는 명령문이 아니라 설계도입니다. 개발자처럼 전문 문서를 쓸 필요는 없습니다. 다만 "누가, 왜, 무엇을, 어떤 모습으로, 어디까지 만들지"를 알려주는 작은 기획서처럼 써야 합니다.
이 장에서는 앱 빌더형 도구에 처음 입력할 프롬프트의 기본 구조를 익힙니다. 코딩 문법은 나오지 않습니다. 대신 AI가 이해하기 쉬운 말의 순서를 배웁니다.
한 줄 요청이 자주 실패하는 이유
초보자가 처음 앱 빌더형 도구를 사용할 때 가장 흔히 하는 실수는 너무 짧게 요청하는 것입니다.
예를 들어 이렇게 입력했다고 해봅시다.
독서 기록 앱 만들어줘.AI는 앱을 만들기 시작할 수 있습니다. 제목 입력칸, 저자 입력칸, 목록 정도는 만들어줄지도 모릅니다. 하지만 다음과 같은 문제가 생기기 쉽습니다.
어떤 사람에게는 독서 기록 앱이 "읽은 책을 저장하는 앱"입니다. 어떤 사람에게는 "독후감을 길게 쓰는 앱"입니다. 또 어떤 사람에게는 "올해 읽은 책 수를 통계로 보는 앱"일 수 있습니다. 강사용이라면 학생들의 독서 기록을 모아야 할 수도 있고, 개인용이라면 로그인 없이 내 브라우저에만 저장해도 충분할 수 있습니다.
"독서 기록 앱"이라는 말 안에는 너무 많은 가능성이 들어 있습니다. AI는 그 가능성 중 하나를 골라야 합니다. 그런데 AI가 고른 방향이 내가 원하는 방향과 다르면, 첫 결과물을 보고 실망하게 됩니다.
이 문제는 AI가 부족해서라기보다 요청이 부족해서 생깁니다. 식당에서 "맛있는 거 주세요"라고 말하면 주방장은 음식을 만들 수는 있지만, 내가 매운 음식을 못 먹는지, 고기를 피하는지, 빨리 먹고 나가야 하는지 알 수 없습니다. 앱 생성 프롬프트도 마찬가지입니다.
좋은 첫 프롬프트는 AI에게 메뉴판을 넘기는 것이 아니라, 주문서를 정확히 써주는 일에 가깝습니다.
첫 문장에는 세 가지를 담습니다
첫 프롬프트의 첫 문장은 생각보다 중요합니다. AI에게 "이 앱의 방향"을 알려주는 출발점이기 때문입니다. 첫 문장에는 최소한 세 가지가 들어가면 좋습니다.
나는 누구인지, 무엇을 만들고 싶은지, 왜 필요한지입니다.
예를 들어 "나는 독서 모임을 운영하는 사람이고, 모임원들의 읽은 책과 한 줄 후기를 모아보는 간단한 웹앱을 만들고 싶습니다. 매번 카카오톡으로 흩어지는 기록을 한곳에 정리하기 위해 필요합니다."라고 쓰면 AI는 앱의 맥락을 이해합니다.
여기서 "나는 누구인지"는 거창한 자기소개가 아닙니다. 직업, 역할, 상황 중 앱과 관련 있는 것만 쓰면 됩니다. 직장인인지, 강사인지, 소상공인인지, 부모인지, 블로거인지 정도면 충분합니다.
"무엇을 만들고 싶은지"는 앱의 종류입니다. 독서 기록 앱, 예약 문의 앱, 회의록 정리 앱, 운동 루틴 기록 앱처럼 한 문장으로 말합니다.
"왜 필요한지"는 문제입니다. 기록이 흩어진다, 반복해서 같은 질문을 받는다, 수기로 정리하느라 시간이 오래 걸린다, 가족 일정이 자주 겹친다처럼 실제 불편함을 적습니다.
다음 세 문장을 비교해보겠습니다.
회의록 앱 만들어줘.나는 작은 팀에서 회의를 자주 진행하는 직장인입니다. 회의 내용을 매번 문서로 정리하는 데 시간이 오래 걸려서, 회의 제목과 날짜, 참석자, 주요 결정사항, 할 일을 기록하는 간단한 회의록 정리 웹앱을 만들고 싶습니다.두 번째 문장이 훨씬 좋습니다. AI가 "회의록 앱"을 막연하게 상상하지 않고, "작은 팀에서 쓰는 기록용 웹앱"으로 이해할 수 있기 때문입니다.
또 다른 예를 보겠습니다.
나는 필라테스 개인 수업을 운영하는 강사입니다. 회원들이 예약 문의를 보낼 때 필요한 정보를 빠뜨리는 경우가 많아서, 이름, 연락처, 희망 날짜, 희망 시간, 문의 내용을 한 번에 받는 예약 문의 웹앱을 만들고 싶습니다.이 문장에는 사용자의 역할, 만들 앱, 필요한 이유가 모두 들어 있습니다. 이렇게 시작하면 AI는 처음부터 엉뚱한 쇼핑몰이나 복잡한 예약 시스템을 만들 가능성이 줄어듭니다.
첫 앱 생성 프롬프트의 기본 뼈대
첫 프롬프트는 길게 써도 됩니다. 오히려 처음에는 짧은 요청보다 구조화된 긴 요청이 좋습니다. 단, 아무 말이나 길게 쓰는 것이 아니라 항목을 나눠야 합니다.
가장 기본이 되는 구조는 다음과 같습니다.
나는 [나의 역할/상황]입니다.
[만들고 싶은 앱]을 만들고 싶습니다.
이 앱의 목적은 [해결하고 싶은 문제]입니다.
사용 대상:
- [누가 사용할지]
필요한 핵심 기능:
1. [기능 1]
2. [기능 2]
3. [기능 3]
화면 구성:
1. [첫 화면]
2. [입력/작성 화면]
3. [목록/결과 화면]
디자인 분위기:
- [원하는 느낌]
처음 버전에서 제외할 기능:
- [이번에는 만들지 않을 기능]
먼저 MVP로 작고 단순하게 만들어주세요.여기서 MVP는 정식 제품이 아니라 첫 작동 버전입니다. 식당으로 비유하면 정식 매장을 열기 전 팝업스토어에 가깝습니다. 모든 메뉴를 갖춘 완벽한 매장이 아니라, 사람들이 실제로 와서 핵심 메뉴를 먹어볼 수 있는 작은 공간입니다.
앱도 마찬가지입니다. 첫 버전에서는 "이 앱이 정말 필요한가?", "기본 흐름이 작동하는가?", "사용자가 입력하고 결과를 볼 수 있는가?"를 확인하는 것이 중요합니다.
처음부터 로그인, 관리자 권한, 결제, 알림, 통계, 외부 API 연동까지 모두 넣으려고 하면 앱은 복잡해집니다. AI가 만들 수 있는 경우도 있지만, 초보자가 검토하기 어려워집니다. 작동은 하는 것처럼 보이지만 어디서 문제가 생겼는지 알기 힘들어집니다.
그래서 첫 프롬프트의 마지막에는 반드시 이렇게 적는 습관을 들이면 좋습니다.
처음부터 완성형 서비스로 만들지 말고, 핵심 기능만 작동하는 MVP로 만들어주세요.이 한 문장은 AI에게 "욕심내지 말고 작게 시작하자"는 신호를 줍니다.
사용 대상을 쓰면 앱이 선명해집니다
많은 사람이 "사용 대상"을 빼고 프롬프트를 씁니다. 하지만 사용 대상은 앱의 모양과 기능을 크게 바꿉니다.
같은 할 일 관리 앱이라도 사용 대상에 따라 전혀 달라집니다. 직장인 개인용 할 일 관리 앱이라면 마감일, 중요도, 완료 여부가 중요합니다. 초등학생 자녀와 함께 쓰는 할 일 앱이라면 글자 크기, 색상, 칭찬 문구가 중요할 수 있습니다. 스터디 모임 운영자용이라면 담당자, 과제 제출 여부, 미제출자 확인 기능이 필요할 수 있습니다.
다음처럼 사용 대상을 분명히 적어보세요.
사용 대상은 혼자 일정을 관리하는 직장인입니다. 여러 사람이 함께 쓰는 협업 도구가 아니라, 개인이 오늘 할 일과 이번 주 할 일을 정리하는 용도입니다.사용 대상은 독서 모임을 운영하는 운영자와 모임원입니다. 모임원은 책 제목과 한 줄 후기를 남기고, 운영자는 전체 목록을 확인하는 용도입니다.사용 대상은 작은 공방을 운영하는 사장님입니다. 고객이 예약 문의를 남기고, 사장님이 문의 목록을 확인하는 간단한 용도입니다.이렇게 쓰면 AI가 앱의 말투, 화면 구성, 기능 범위를 더 잘 맞춥니다. 초보자용 앱에서는 "누가 쓰는지"가 곧 "얼마나 단순해야 하는지"를 알려주는 단서가 됩니다.
핵심 기능은 세 개에서 다섯 개면 충분합니다
첫 앱 생성 프롬프트에서 기능을 너무 많이 넣으면 실패 확률이 올라갑니다. 처음에는 핵심 기능을 세 개에서 다섯 개 정도로 제한하는 것이 좋습니다.
기능은 가능하면 동사로 씁니다. "책 제목"이라고만 쓰는 것보다 "책 제목을 입력할 수 있다"라고 쓰는 편이 좋습니다. "목록"이라고만 쓰는 것보다 "입력한 책을 목록으로 볼 수 있다"라고 쓰는 편이 좋습니다.
예를 들어 독서 기록 앱의 핵심 기능은 이렇게 쓸 수 있습니다.
필요한 핵심 기능:
1. 책 제목, 저자, 읽은 날짜, 한 줄 메모를 입력할 수 있다.
2. 입력한 독서 기록을 카드 형태의 목록으로 볼 수 있다.
3. 책 제목이나 메모 키워드로 기록을 검색할 수 있다.
4. 잘못 입력한 기록을 수정하거나 삭제할 수 있다.할 일 관리 앱이라면 이렇게 쓸 수 있습니다.
필요한 핵심 기능:
1. 할 일 제목, 마감일, 중요도를 입력할 수 있다.
2. 할 일을 미완료와 완료로 구분해서 볼 수 있다.
3. 완료 버튼을 누르면 완료 목록으로 이동한다.
4. 필요 없는 할 일을 삭제할 수 있다.예약 문의 앱이라면 이렇게 쓸 수 있습니다.
필요한 핵심 기능:
1. 고객이 이름, 연락처, 희망 날짜, 희망 시간, 문의 내용을 입력할 수 있다.
2. 제출된 문의를 관리자용 목록에서 확인할 수 있다.
3. 문의 상태를 신규, 확인 중, 답변 완료로 바꿀 수 있다.
4. 개인정보 안내 문구를 입력 화면 아래에 표시한다.기능을 쓸 때 주의할 점이 있습니다. "좋게 만들어줘", "편하게 만들어줘", "깔끔하게 해줘" 같은 말은 방향은 주지만 기능은 아닙니다. 기능은 사용자가 실제로 할 수 있는 행동이어야 합니다.
좋은 기능 문장은 "사용자가 무엇을 입력한다", "무엇을 본다", "무엇을 수정한다", "무엇을 삭제한다", "무엇을 검색한다"처럼 확인 가능한 말로 끝납니다.
화면 구성을 쓰면 AI가 덜 헤맵니다
초보자는 화면 구성을 어렵게 생각합니다. 하지만 전문적인 와이어프레임을 그릴 필요는 없습니다. 와이어프레임은 화면의 대략적인 배치를 나타내는 밑그림입니다. 종이에 "위에는 제목, 가운데는 입력칸, 아래에는 목록"이라고 그리는 정도도 와이어프레임입니다.
앱 빌더형 도구에게는 화면 구성을 말로 설명하면 됩니다.
가장 단순한 앱은 보통 세 가지 영역으로 나눌 수 있습니다. 첫째, 앱의 목적을 알려주는 상단 영역입니다. 둘째, 사용자가 정보를 입력하는 영역입니다. 셋째, 입력한 결과를 확인하는 목록 또는 결과 영역입니다.
예를 들어 AI 프롬프트 보관함 앱이라면 이렇게 쓸 수 있습니다.
화면 구성:
1. 상단에는 앱 제목과 짧은 설명을 보여준다.
2. 왼쪽 또는 위쪽에는 프롬프트를 입력하는 폼을 둔다.
3. 오른쪽 또는 아래쪽에는 저장된 프롬프트 목록을 카드 형태로 보여준다.
4. 각 카드에는 제목, 카테고리, 프롬프트 내용 일부, 복사 버튼을 보여준다.강의 후기 수집 앱은 이렇게 쓸 수 있습니다.
화면 구성:
1. 첫 화면에는 강의명과 후기를 남겨달라는 안내 문구를 보여준다.
2. 후기 입력 영역에는 이름 또는 닉네임, 만족도, 좋았던 점, 개선할 점 입력칸을 둔다.
3. 제출 후에는 감사 메시지를 보여준다.
4. 관리자 확인용으로 제출된 후기 목록을 아래쪽에 보여준다.운동 루틴 기록 앱은 이렇게 쓸 수 있습니다.
화면 구성:
1. 상단에는 오늘의 운동 기록을 추가하는 입력 영역을 둔다.
2. 가운데에는 이번 주 운동 기록 목록을 보여준다.
3. 하단에는 총 운동 횟수와 총 운동 시간을 간단한 통계로 보여준다.화면 구성을 적으면 AI가 "무엇을 어디에 보여줄지" 결정하기 쉬워집니다. 결과적으로 첫 화면이 덜 산만해지고, 내가 원하는 앱에 가까워집니다.
디자인 분위기는 추상어보다 장면으로 말합니다
"예쁘게 만들어줘"는 많은 사람이 쓰는 요청입니다. 하지만 AI에게는 조금 막연합니다. 예쁜 디자인은 사람마다 다릅니다. 어떤 사람에게는 화려한 그라데이션이 예쁘고, 어떤 사람에게는 흰 배경에 여백이 많은 화면이 예쁩니다.
디자인 분위기를 말할 때는 추상적인 칭찬보다 장면을 떠올리게 쓰는 것이 좋습니다.
예를 들어 "깔끔하게"라고만 쓰기보다 이렇게 씁니다.
디자인 분위기:
- 흰 배경과 연한 회색 테두리를 사용한 깔끔한 업무용 SaaS 느낌으로 만들어주세요.
- 버튼은 너무 화려하지 않게 파란색 계열로 통일해주세요.
- 처음 사용하는 사람도 어디를 눌러야 하는지 바로 알 수 있게 여백을 충분히 주세요.SaaS는 인터넷으로 사용하는 업무용 소프트웨어를 말합니다. 예를 들어 협업 도구, 고객 관리 도구, 프로젝트 관리 도구처럼 웹브라우저에서 로그인해 쓰는 서비스가 여기에 해당합니다. 초보자 입장에서는 "업무용 웹서비스 느낌" 정도로 이해하면 충분합니다.
다른 분위기도 프롬프트로 바꿔보겠습니다.
디자인 분위기:
- 독서 다이어리처럼 차분하고 따뜻한 느낌으로 만들어주세요.
- 배경은 아이보리 계열, 카드에는 연한 베이지색을 사용해주세요.
- 글을 읽기 편하도록 글자 크기와 줄 간격을 넉넉하게 해주세요.디자인 분위기:
- 공공기관 신청서처럼 신뢰감 있고 단정한 느낌으로 만들어주세요.
- 장식은 줄이고, 입력 항목의 라벨과 안내 문구가 잘 보이게 해주세요.
- 모바일에서도 글자가 작아지지 않게 해주세요.디자인 분위기:
- 운동 기록 앱답게 활기차고 단순한 느낌으로 만들어주세요.
- 초록색 또는 파란색 포인트 컬러를 사용해주세요.
- 오늘의 운동을 빠르게 입력할 수 있도록 버튼을 크게 만들어주세요.디자인은 취향의 영역처럼 보이지만, 사실 사용성에도 큰 영향을 줍니다. 특히 초보자가 만든 앱은 "멋있음"보다 "사용자가 헷갈리지 않음"이 더 중요합니다.
제외할 기능을 적어야 앱이 작아집니다
첫 프롬프트에서 가장 자주 빠지는 항목이 "제외할 기능"입니다. 많은 사람이 만들고 싶은 기능만 적습니다. 하지만 AI에게는 만들지 말아야 할 것도 알려줘야 합니다.
왜냐하면 AI는 종종 친절함이 과합니다. 독서 기록 앱을 만들어달라고 했더니 로그인, 독서 목표, 차트, 추천 도서, 소셜 공유, 관리자 페이지까지 넣으려고 할 수 있습니다. 예약 문의 앱을 요청했더니 결제, 회원가입, 자동 문자 발송, 캘린더 연동까지 제안할 수도 있습니다.
나중에는 좋은 기능일 수 있습니다. 하지만 첫 앱에서는 부담입니다. 초보자에게 중요한 것은 기능이 많은 앱이 아니라 검토할 수 있는 앱입니다.
제외할 기능은 이렇게 씁니다.
처음 버전에서 제외할 기능:
- 로그인과 회원가입은 넣지 마세요.
- 결제 기능은 넣지 마세요.
- 문자 발송이나 이메일 자동 발송은 넣지 마세요.
- 외부 캘린더 연동은 넣지 마세요.
- 관리자 권한 구분은 나중에 추가하겠습니다.독서 기록 앱이라면 이렇게 쓸 수 있습니다.
처음 버전에서 제외할 기능:
- 도서 검색 API 연동은 하지 마세요.
- 다른 사용자와 공유하는 기능은 넣지 마세요.
- 로그인은 만들지 마세요.
- 추천 알고리즘은 만들지 마세요.회의록 정리 앱이라면 이렇게 쓸 수 있습니다.
처음 버전에서 제외할 기능:
- 음성 녹음과 자동 받아쓰기는 제외하세요.
- 외부 AI 요약 API 연결은 제외하세요.
- 회사 계정 로그인이나 권한 관리는 넣지 마세요.
- 먼저 직접 입력한 회의 내용을 정리하고 저장하는 기능만 만들어주세요.이렇게 제외할 기능을 적으면 AI가 과하게 만들 가능성이 줄어듭니다. 이것은 초보자가 앱의 난이도를 통제하는 가장 쉬운 방법입니다.
MVP로 만들어달라는 문장은 꼭 넣습니다
앱 빌더형 도구는 생각보다 많은 것을 빠르게 만들어줍니다. 그래서 오히려 초보자는 욕심을 내기 쉽습니다. "이왕 만드는 김에 로그인도 넣고, 통계도 넣고, 알림도 넣고, AI 요약도 넣고, 결제도 붙이면 좋지 않을까?"라는 생각이 듭니다.
하지만 첫 앱에서 가장 중요한 질문은 "멋진가?"가 아닙니다. "작동하는가?"입니다.
MVP로 만들어달라는 문장은 AI에게 범위를 줄여달라는 요청입니다. 처음부터 서비스 운영용으로 만들지 말고, 핵심 흐름을 확인할 수 있는 작은 버전을 만들라는 뜻입니다.
다음 문장을 첫 프롬프트 마지막에 붙여보세요.
먼저 MVP로 만들어주세요. 핵심 기능이 작동하는 단순한 첫 버전이면 충분합니다. 나중에 제가 테스트한 뒤 기능을 하나씩 추가하겠습니다.조금 더 강하게 제한하고 싶다면 이렇게 쓸 수 있습니다.
이번 단계에서는 기능을 많이 넣지 말고, 입력 → 저장 → 목록 확인 흐름이 잘 작동하는지에 집중해주세요. 복잡한 기능은 제안만 하고 실제 구현은 하지 마세요.AI 기능이 포함된 앱을 만들고 싶을 때도 처음부터 연결하지 않는 편이 좋을 때가 많습니다.
AI 요약 기능은 나중에 추가할 예정입니다. 처음 버전에서는 사용자가 직접 내용을 입력하고, 저장된 내용을 목록으로 확인하는 기능까지만 만들어주세요.이 문장들은 앱의 난이도를 낮춰줍니다. 바이브 코딩에서 중요한 능력은 AI에게 무조건 많이 시키는 능력이 아닙니다. 지금 만들 것과 나중에 만들 것을 구분하는 능력입니다.
바로 복사해서 쓰는 첫 앱 생성 프롬프트
이제 기본 구조를 실제 프롬프트로 묶어보겠습니다. 아래 템플릿은 어떤 앱에도 바꿔 쓸 수 있습니다.
나는 [나의 역할/상황]입니다.
[만들고 싶은 앱 이름]이라는 간단한 웹앱을 만들고 싶습니다.
이 앱의 목적은 [현재 겪는 불편함]을 줄이고, [사용자가 얻을 결과]를 쉽게 확인하는 것입니다.
사용 대상:
- [주 사용자]
- 이 사용자는 코딩이나 복잡한 도구에 익숙하지 않으므로 화면은 단순해야 합니다.
필요한 핵심 기능:
1. [사용자가 입력할 정보]를 입력할 수 있다.
2. 입력한 내용을 저장하고 목록으로 볼 수 있다.
3. 목록에서 필요한 항목을 검색하거나 확인할 수 있다.
4. 잘못 입력한 항목을 수정하거나 삭제할 수 있다.
화면 구성:
1. 상단에는 앱 제목과 짧은 설명을 보여준다.
2. 입력 영역에는 필요한 입력칸과 저장 버튼을 둔다.
3. 목록 영역에는 저장된 항목을 카드 또는 표 형태로 보여준다.
4. 빈 목록일 때는 사용 방법을 알려주는 안내 문구를 보여준다.
디자인 분위기:
- [원하는 디자인 느낌]으로 만들어주세요.
- 모바일에서도 사용하기 편하게 반응형으로 만들어주세요.
- 버튼과 입력칸은 초보자도 알아보기 쉽게 크게 보여주세요.
처음 버전에서 제외할 기능:
- 로그인과 회원가입은 넣지 마세요.
- 결제 기능은 넣지 마세요.
- 외부 API 연동은 하지 마세요.
- 복잡한 관리자 권한 관리는 넣지 마세요.
먼저 MVP로 작고 단순하게 만들어주세요.
핵심 흐름인 입력 → 저장 → 목록 확인이 잘 작동하는 것에 집중해주세요.반응형은 화면 크기에 따라 앱의 모양이 자연스럽게 바뀌는 것을 말합니다. 스마트폰에서는 세로로 보기 좋게, 노트북에서는 넓은 화면을 활용해 보이게 만드는 방식입니다. 초보자는 "모바일에서도 깨지지 않게 해주세요"라고 이해하면 됩니다.
예제 1: 가족 일정 공유 앱 첫 프롬프트
가족 일정 공유 앱은 생활 속 불편함을 해결하는 좋은 예제입니다. 단, 첫 버전부터 가족별 로그인, 알림, 캘린더 동기화까지 넣으면 어려워집니다. 먼저 가족 일정을 입력하고 목록으로 보는 정도면 충분합니다.
나는 가족 일정을 자주 조율해야 하는 부모입니다.
가족 일정 공유 앱이라는 간단한 웹앱을 만들고 싶습니다.
이 앱의 목적은 가족들의 병원 예약, 학원 일정, 가족 행사, 준비물을 한곳에 정리해서 일정이 겹치거나 빠지는 일을 줄이는 것입니다.
사용 대상:
- 부모와 가족 구성원입니다.
- 복잡한 기능보다 한눈에 보기 쉬운 일정 목록이 중요합니다.
필요한 핵심 기능:
1. 일정 제목, 날짜, 시간, 담당 가족, 준비물을 입력할 수 있다.
2. 입력한 일정을 날짜순 목록으로 볼 수 있다.
3. 담당 가족별로 일정을 필터링할 수 있다.
4. 잘못 입력한 일정을 수정하거나 삭제할 수 있다.
화면 구성:
1. 상단에는 앱 제목과 이번 주 일정 개수를 보여준다.
2. 입력 영역에는 일정 제목, 날짜, 시간, 담당 가족, 준비물 입력칸을 둔다.
3. 목록 영역에는 날짜순으로 정렬된 일정 카드를 보여준다.
4. 각 카드에는 담당 가족 이름과 준비물이 잘 보이게 표시한다.
디자인 분위기:
- 가족이 함께 쓰는 따뜻하고 밝은 느낌으로 만들어주세요.
- 모바일에서 주로 볼 예정이므로 모바일 우선 디자인으로 만들어주세요.
- 버튼과 글자는 크게, 색상은 부드러운 파스텔 계열로 해주세요.
처음 버전에서 제외할 기능:
- 로그인과 가족별 계정은 넣지 마세요.
- 카카오톡 알림이나 문자 알림은 넣지 마세요.
- 구글 캘린더 연동은 넣지 마세요.
- 반복 일정 기능은 나중에 추가하겠습니다.
먼저 MVP로 작고 단순하게 만들어주세요.
입력 → 저장 → 날짜순 목록 확인 흐름이 잘 작동하는 것에 집중해주세요.이 프롬프트는 가족 앱이지만 개인정보를 많이 요구하지 않습니다. 주소, 주민등록번호, 학교명 같은 민감한 정보는 처음 버전에 넣지 않는 편이 안전합니다.
예제 2: 강의 후기 수집 앱 첫 프롬프트
강사나 교육 담당자는 후기를 자주 모읍니다. 그런데 메신저, 설문 링크, 이메일에 흩어진 후기를 정리하는 일이 번거롭습니다. 이때 강의 후기 수집 앱은 첫 실습으로 좋습니다.
나는 소규모 강의를 운영하는 강사입니다.
강의 후기 수집 앱이라는 간단한 웹앱을 만들고 싶습니다.
이 앱의 목적은 수강생이 강의 후기를 쉽게 남기고, 나는 제출된 후기를 한곳에서 확인하는 것입니다.
사용 대상:
- 후기를 남기는 수강생
- 후기를 확인하는 강사
- 수강생은 복잡한 회원가입 없이 바로 후기를 남길 수 있어야 합니다.
필요한 핵심 기능:
1. 수강생이 이름 또는 닉네임, 만족도, 좋았던 점, 개선할 점을 입력할 수 있다.
2. 제출 버튼을 누르면 감사 메시지가 표시된다.
3. 제출된 후기를 목록으로 볼 수 있다.
4. 만족도별로 후기를 필터링할 수 있다.
5. 잘못 제출된 후기를 삭제할 수 있다.
화면 구성:
1. 첫 화면 상단에는 강의명과 후기 작성 안내 문구를 보여준다.
2. 가운데에는 후기 입력 폼을 둔다.
3. 제출 후에는 "후기를 남겨주셔서 감사합니다"라는 메시지를 보여준다.
4. 아래쪽에는 강사용 후기 목록 영역을 둔다.
디자인 분위기:
- 프리미엄 강의 페이지처럼 단정하고 신뢰감 있는 느낌으로 만들어주세요.
- 흰 배경에 짙은 남색 포인트 컬러를 사용해주세요.
- 입력칸은 넓고, 모바일에서도 작성하기 편하게 만들어주세요.
처음 버전에서 제외할 기능:
- 로그인은 넣지 마세요.
- 이메일 자동 발송은 넣지 마세요.
- 수강생 개인정보를 많이 받지 마세요.
- 결제 기능이나 수강 신청 기능은 넣지 마세요.
먼저 MVP로 만들어주세요.
후기 입력 → 제출 → 목록 확인 흐름이 잘 작동하는 단순한 첫 버전이면 충분합니다.이 프롬프트에서 중요한 점은 "수강생 개인정보를 많이 받지 마세요"라고 적은 부분입니다. 앱을 만들 때 필요한 정보만 받는 습관은 매우 중요합니다. 특히 외부 사람이 입력하는 앱이라면 더 조심해야 합니다.
예제 3: 블로그 글감 저장소 앱 첫 프롬프트
크리에이터나 블로거는 아이디어를 자주 잊어버립니다. 생각은 떠올랐는데 막상 글을 쓰려고 하면 어디에 적어두었는지 모를 때가 많습니다. 이때 블로그 글감 저장소 앱은 작고 실용적인 첫 앱이 될 수 있습니다.
나는 블로그를 운영하는 사람입니다.
블로그 글감 저장소 앱이라는 개인용 웹앱을 만들고 싶습니다.
이 앱의 목적은 떠오른 글감, 제목 후보, 참고 메모를 빠르게 저장하고 나중에 다시 찾아보는 것입니다.
사용 대상:
- 블로그 글감을 관리하는 개인 사용자입니다.
- 혼자 쓰는 앱이므로 협업 기능은 필요 없습니다.
필요한 핵심 기능:
1. 글감 제목, 카테고리, 핵심 메모, 작성 상태를 입력할 수 있다.
2. 저장된 글감을 카드 목록으로 볼 수 있다.
3. 카테고리와 작성 상태로 필터링할 수 있다.
4. 글감 키워드로 검색할 수 있다.
5. 글감 내용을 수정하거나 삭제할 수 있다.
화면 구성:
1. 상단에는 앱 제목과 저장된 글감 개수를 보여준다.
2. 입력 영역에는 제목, 카테고리, 메모, 작성 상태 입력칸을 둔다.
3. 목록 영역에는 글감 카드를 보여준다.
4. 카드에는 제목, 카테고리, 상태, 메모 일부를 보여준다.
디자인 분위기:
- 메모장과 콘텐츠 기획 보드가 섞인 느낌으로 만들어주세요.
- 너무 화려하지 않고, 오래 봐도 피로하지 않은 색을 사용해주세요.
- 노트북과 모바일에서 모두 편하게 사용할 수 있게 반응형으로 만들어주세요.
처음 버전에서 제외할 기능:
- AI 글쓰기 기능은 넣지 마세요.
- 블로그 자동 발행 기능은 넣지 마세요.
- 이미지 업로드는 넣지 마세요.
- 로그인은 만들지 마세요.
먼저 MVP로 만들어주세요.
글감 입력 → 저장 → 검색과 필터 → 수정과 삭제가 되는 단순한 버전이면 충분합니다.여기서도 "AI 글쓰기 기능"을 제외했습니다. 나중에는 좋은 확장 기능이 될 수 있습니다. 하지만 첫 버전에서는 아이디어를 저장하고 찾는 흐름이 먼저입니다.
좋은 첫 프롬프트를 만드는 순서
처음부터 완성된 문장을 쓰려고 하면 어렵습니다. 다음 순서로 메모하듯 채워보세요.
내가 누구인지 한 문장으로 쓴다.
만들 앱의 이름을 임시로 정한다.
이 앱이 해결할 불편함을 한 문장으로 쓴다.
사용할 사람을 정한다.
핵심 기능을 세 개에서 다섯 개로 줄인다.
화면 구성을 상단, 입력 영역, 목록 영역으로 나눈다.
원하는 디자인 분위기를 생활 장면으로 설명한다.
이번 버전에서 제외할 기능을 적는다.
마지막에 MVP로 만들어달라고 쓴다.
이 순서는 앱 기획서 한 장을 프롬프트로 바꾸는 과정이기도 합니다. 앞 장들에서 정리한 불편함, 사용자, 핵심 기능이 있다면 그대로 가져오면 됩니다.
프롬프트를 잘 쓰는 사람은 문장을 멋있게 쓰는 사람이 아닙니다. AI가 헷갈리지 않게 필요한 정보를 빠뜨리지 않는 사람입니다.
첫 프롬프트 작성 체크리스트
앱 빌더형 도구에 붙여넣기 전에 아래 항목을 확인해보세요.
나는 누구인지 썼는가?
무엇을 만들고 싶은지 썼는가?
왜 이 앱이 필요한지 썼는가?
누가 사용할 앱인지 썼는가?
필요한 기능을 번호로 정리했는가?
기능을 사용자의 행동 중심으로 썼는가?
화면 구성을 설명했는가?
디자인 분위기를 구체적으로 적었는가?
처음 버전에서 제외할 기능을 적었는가?
MVP로 만들어달라고 요청했는가?
로그인, 결제, 외부 연동처럼 어려운 기능을 첫 버전에 넣지 않았는가?
모바일에서 사용할 필요가 있다면 반응형 또는 모바일 우선 디자인을 요청했는가?
이 체크리스트를 매번 모두 외울 필요는 없습니다. 처음에는 이 장의 템플릿을 복사해 빈칸을 채우면 됩니다. 몇 번 반복하면 자연스럽게 익숙해집니다.
흔한 실수와 고치는 방법
첫 번째 실수는 "좋은 앱 만들어줘"처럼 결과만 요청하는 것입니다. AI에게 좋은 앱의 기준을 알려주지 않으면 AI는 일반적인 기준으로 만듭니다. 이때는 사용 대상, 목적, 핵심 기능을 다시 적어야 합니다.
고치는 프롬프트는 이렇게 쓸 수 있습니다.
방금 만든 앱의 방향을 다시 잡고 싶습니다.
이 앱은 일반 사용자용이 아니라 [구체적인 사용자]가 쓰는 앱입니다.
목적은 [구체적인 문제]를 해결하는 것입니다.
기능을 줄여서 [핵심 기능 3개] 중심의 MVP로 다시 구성해주세요.두 번째 실수는 처음부터 기능을 너무 많이 넣는 것입니다. 기능이 많으면 화면도 복잡해지고, 오류가 났을 때 원인을 찾기 어렵습니다. 이때는 MVP로 줄여달라고 요청해야 합니다.
현재 기능이 너무 많아 초보자가 테스트하기 어렵습니다.
첫 버전에서는 다음 기능만 남겨주세요.
1. [핵심 기능 1]
2. [핵심 기능 2]
3. [핵심 기능 3]
나머지 기능은 화면에서 제거하거나 "나중에 추가할 기능"으로만 정리해주세요.세 번째 실수는 제외할 기능을 쓰지 않는 것입니다. AI가 친절하게 복잡한 기능을 넣어버리면, 초보자는 그 기능이 꼭 필요한 줄 알고 끌려가게 됩니다. 이때는 명확히 빼달라고 말하면 됩니다.
이번 MVP에서는 로그인, 결제, 외부 API 연동, 알림 기능을 제외해주세요.
현재 앱에서 이 기능들과 관련된 화면이나 버튼이 있다면 제거하고, 입력과 목록 확인 중심으로 단순화해주세요.네 번째 실수는 디자인 요청이 너무 막연한 것입니다. "예쁘게" 대신 어떤 사용자가 어떤 상황에서 보는지 설명해야 합니다.
디자인을 다시 정리해주세요.
이 앱은 [사용 상황]에서 쓰는 앱입니다.
[원하는 분위기] 느낌으로 바꾸고, 버튼과 입력칸을 더 크게 만들어주세요.
모바일 화면에서 먼저 보기 좋게 구성해주세요.다섯 번째 실수는 AI가 만든 결과물을 한 번 보고 포기하는 것입니다. 바이브 코딩은 한 번에 완벽한 앱을 얻는 방식이 아닙니다. 대화하며 고쳐나가는 방식입니다. 첫 프롬프트는 시작점이고, 이후 기능 추가 프롬프트, 디자인 수정 프롬프트, 오류 수정 프롬프트로 이어집니다.
실습 미션: 내 앱의 첫 생성 프롬프트 쓰기
이제 직접 하나를 써볼 차례입니다. 아직 만들 앱을 정하지 못했다면 너무 고민하지 않아도 됩니다. 다음 중 하나를 골라도 충분합니다.
개인용 할 일 관리 앱
가족 일정 공유 앱
블로그 글감 저장소 앱
운동 루틴 기록 앱
예약 문의 앱
강의 후기 수집 앱
먼저 아래 빈칸을 채워보세요.
나는 [ ]입니다.
[ ] 앱을 만들고 싶습니다.
이 앱의 목적은 [ ]입니다.
사용 대상:
- [ ]
필요한 핵심 기능:
1. [ ]
2. [ ]
3. [ ]
화면 구성:
1. [ ]
2. [ ]
3. [ ]
디자인 분위기:
- [ ]
처음 버전에서 제외할 기능:
- [ ]
- [ ]
- [ ]
먼저 MVP로 작고 단순하게 만들어주세요.
핵심 흐름이 잘 작동하는지 확인할 수 있는 첫 버전이면 충분합니다.다 채웠다면 바로 앱 빌더형 도구에 붙여넣어도 됩니다. 단, 결과물이 마음에 들지 않아도 실패가 아닙니다. 첫 결과물은 대화의 시작입니다. 화면을 보고 "좋은 점", "다른 점", "빼고 싶은 점", "추가하고 싶은 점"을 다시 말하면 됩니다.
한 장 요약
첫 앱 생성 프롬프트는 앱의 설계도입니다. "앱 만들어줘"라고만 쓰면 AI는 너무 많은 것을 추측해야 합니다. 좋은 첫 프롬프트는 내가 누구인지, 무엇을 만들고 싶은지, 왜 필요한지로 시작합니다.
그다음 사용 대상, 핵심 기능, 화면 구성, 디자인 분위기를 번호로 정리하면 AI가 앱의 방향을 더 정확히 이해합니다. 특히 핵심 기능은 세 개에서 다섯 개 정도로 제한하는 것이 좋습니다. 기능은 "입력한다", "저장한다", "목록으로 본다", "수정한다", "삭제한다", "검색한다"처럼 사용자의 행동으로 쓰면 좋습니다.
처음 버전에서 제외할 기능도 반드시 적어야 합니다. 로그인, 결제, 외부 API 연동, 알림, 복잡한 권한 관리는 나중 단계로 미루는 편이 안전합니다. 유명하고 멋진 기능을 많이 넣는 것보다, 내가 직접 테스트하고 이해할 수 있는 작은 앱을 만드는 것이 먼저입니다.
마지막으로 "먼저 MVP로 만들어주세요"라는 문장을 꼭 넣으세요. 바이브 코딩은 AI에게 한 번에 완벽한 앱을 요구하는 기술이 아닙니다. 내가 원하는 것을 AI가 이해하도록 설명하고, 작게 만든 뒤, 대화하며 고쳐나가는 기술입니다.
다음 장에서는 첫 앱이 만들어진 뒤 필요한 기능을 하나씩 추가하는 프롬프트를 배웁니다. 첫 설계도가 준비되었다면, 이제는 벽돌을 하나씩 더 올릴 차례입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.