부록: 체크리스트 모음과 다음 단계

이 책을 여기까지 읽었다면 이제 당신에게 필요한 것은 더 많은 설명이 아닐지도 모릅니다. 오히려 필요한 것은 "무엇부터 확인하면 되는지"를 한눈에 볼 수 있는 작은 종이 한 장입니다.

바이브 코딩을 처음 시작할 때 가장 흔한 실수는 능력이 부족해서 생기지 않습니다. 대부분은 확인 순서가 없어서 생깁니다. 누가 쓸 앱인지 정하지 않은 채 기능을 넣고, 처음 버전에서 제외할 기능을 정하지 않은 채 AI에게 "좋게 만들어줘"라고 말하고, 배포 전에 버튼과 데이터 저장을 확인하지 않은 채 링크를 공유합니다.

체크리스트는 초보자가 AI와 협업할 때 실수를 줄여주는 안전장치입니다. 개발 지식을 모두 외우지 않아도 괜찮습니다. 다만 만들기 전, 프롬프트를 쓰기 전, 공유하기 전에는 잠시 멈춰서 질문해야 합니다.

"이 앱은 누구를 위한 것인가?"

"AI에게 충분히 구체적으로 설명했는가?"

"다른 사람이 써도 위험하지 않은가?"

이번 장은 책의 마지막 장이자, 당신이 실제로 첫 앱을 만들기 전에 다시 펼쳐볼 실행용 부록입니다.

체크리스트는 초보자의 안전벨트다

자동차를 처음 운전할 때 운전 실력이 뛰어나지 않아도 반드시 하는 일이 있습니다. 안전벨트를 매고, 사이드미러를 보고, 기어를 확인하고, 브레이크를 밟아봅니다. 이 동작들은 화려하지 않지만 사고를 줄여줍니다.

바이브 코딩에서도 마찬가지입니다. 좋은 도구를 쓰는 것보다 중요한 것은 확인 순서입니다. Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구를 쓰더라도 AI는 당신의 머릿속을 자동으로 읽지 못합니다. 당신이 사용자, 문제, 핵심 기능, 제외할 기능을 알려줘야 합니다.

유명한 도구가 초보자에게 쉬운 도구는 아닙니다. 처음에는 앱 빌더형 도구로 작은 성공 경험을 만드는 것이 중요합니다. 그리고 그 작은 성공 경험을 만드는 가장 현실적인 방법이 바로 체크리스트입니다.

체크리스트는 창의성을 막는 규칙이 아닙니다. 오히려 막연한 생각을 실제 앱으로 옮기게 해주는 발판입니다. 아이디어가 흐릿할수록 체크리스트는 더 강력합니다.

예를 들어 "가족 일정 앱을 만들고 싶다"는 생각은 아직 앱 기획이 아닙니다. 하지만 다음처럼 바꾸면 AI가 이해할 수 있는 요청이 됩니다.

"부모와 자녀가 함께 보는 가족 일정 공유 앱을 만들고 싶다. 일정 제목, 날짜, 담당자, 메모를 입력하고 목록에서 볼 수 있게 해줘. 처음 버전에서는 로그인, 알림, 캘린더 연동은 제외해줘."

이 정도만 되어도 AI가 만들 수 있는 그림이 훨씬 또렷해집니다.

앱 만들기 전 체크리스트

앱을 만들기 전에는 먼저 "무엇을 만들 것인가"보다 "왜 필요한가"를 확인해야 합니다. 좋은 앱 아이디어는 거창한 창업 아이템에서만 나오지 않습니다. 내 일상과 업무에서 반복되는 불편함이 가장 좋은 출발점입니다.

아래 체크리스트는 앱 빌더에 첫 요청을 넣기 전에 반드시 확인해야 할 질문입니다.

• 이 앱은 누가 쓰는가?

• 사용자는 어떤 문제를 겪는가?

• 가장 중요한 기능 1개는 무엇인가?

• 처음 버전에서 빼도 되는 기능은 무엇인가?

• 입력해야 하는 정보는 무엇인가?

• 결과로 보여줘야 하는 정보는 무엇인가?

• 모바일에서 주로 쓸 것인가?

• 공유용인가, 개인용인가?

• 로그인 기능이 꼭 필요한가?

• 개인정보를 다루는가?

이 질문에 모두 길게 답할 필요는 없습니다. 오히려 첫 앱에서는 짧게 답하는 편이 좋습니다. 중요한 것은 빈칸을 그대로 두지 않는 것입니다.

예를 들어 독서 기록 앱을 만든다면 이렇게 정리할 수 있습니다.

할 일 관리 앱이라면 답이 달라집니다. 핵심 기능은 "할 일을 추가하고 완료 표시하기"가 될 수 있습니다. 강의 후기 수집 앱이라면 "참여자가 후기를 제출하고 운영자가 목록으로 확인하기"가 핵심입니다. 예약 문의 앱이라면 "이름, 연락처, 희망 날짜, 문의 내용을 받아 관리자에게 보여주기"가 핵심입니다.

여기서 주의할 점이 있습니다. 연락처, 이메일, 주소, 나이, 건강 정보처럼 개인을 알아볼 수 있거나 민감할 수 있는 정보가 들어가면 난이도가 올라갑니다. 첫 앱에서는 가능하면 개인정보를 적게 다루는 주제로 시작하세요. "작동하는 것"과 "서비스로 운영 가능한 것"은 다릅니다.

앱 아이디어를 고르는 빠른 기준

책을 덮고 바로 앱을 만들고 싶다면 후보를 너무 많이 늘리지 않는 것이 좋습니다. 아이디어가 많아도 첫 앱은 하나만 만들 수 있습니다. 그래서 아래 세 가지 기준으로 후보를 줄여보세요.

• 내가 실제로 이번 주에 쓸 앱인가?

• 입력과 결과가 단순한가?

• 로그인 없이도 첫 버전을 만들 수 있는가?

이 기준으로 보면 독서 기록 앱, 운동 루틴 기록 앱, 블로그 글감 저장소 앱, AI 프롬프트 보관함 앱, 가족 일정 메모 앱은 좋은 첫 후보입니다. 반대로 결제 기능이 있는 예약 앱, 회원별 권한이 필요한 커뮤니티 앱, 의료 상담 앱, 금융 관리 앱, 법률 문서 자동 작성 앱은 첫 앱으로는 무겁습니다.

아직 어렵다는 말은 만들지 말라는 뜻이 아닙니다. 순서를 늦추자는 뜻입니다. 먼저 작은 앱으로 AI와 대화하며 만드는 감각을 익힌 뒤, 나중에 로그인, 데이터베이스, 권한 관리, 결제, 외부 API 같은 기능을 하나씩 붙이면 됩니다.

첫 프롬프트 작성 체크리스트

바이브 코딩은 코딩을 안 배워도 된다는 뜻이 아닙니다. 내가 원하는 것을 AI가 이해하게 설명하는 기술입니다. 그래서 첫 프롬프트는 앱의 운명을 꽤 많이 결정합니다.

AI에게 "독서 앱 만들어줘"라고 말하면 결과는 도구와 AI의 추측에 크게 의존합니다. 반면 "누가, 왜, 어떤 기능으로, 어떤 화면에서, 무엇은 제외하고, 어떤 분위기로" 만들지 알려주면 결과물이 훨씬 안정됩니다.

첫 프롬프트를 쓰기 전에는 아래 항목을 확인하세요.

• 나는 누구인지 썼는가?

• 무엇을 만들고 싶은지 썼는가?

• 누가 쓰는지 썼는가?

• 필요한 기능을 번호로 정리했는가?

• 화면 구성을 설명했는가?

• 디자인 분위기를 적었는가?

• 처음에는 제외할 기능을 적었는가?

• MVP로 만들어달라고 했는가?

초보자에게 가장 좋은 첫 프롬프트는 작은 기획서처럼 생긴 프롬프트입니다. 아래 템플릿을 복사해 당신의 앱에 맞게 바꿔보세요.

나는 코딩을 모르는 초보자입니다.
[앱 이름]이라는 작은 웹앱을 만들고 싶습니다.

앱의 목적은 [해결하고 싶은 문제]입니다.
사용자는 [누가 사용할지]입니다.

필요한 기능은 다음과 같습니다.
1. [입력 기능]
2. [목록 보기 기능]
3. [수정 또는 삭제 기능]
4. [검색, 필터, 통계 중 필요한 기능]

화면은 다음처럼 구성해주세요.
1. 상단: 앱 제목과 간단한 설명
2. 입력 영역: 사용자가 정보를 입력하는 폼
3. 목록 영역: 저장된 내용을 카드나 표로 보기
4. 요약 영역: 전체 개수나 간단한 통계 보기

디자인은 [원하는 분위기]로 해주세요.
모바일에서도 보기 편한 반응형 웹앱으로 만들어주세요.

처음 버전에서는 로그인, 결제, 외부 API 연동, 복잡한 관리자 권한은 제외해주세요.
먼저 MVP로 작동하는 버전을 만들어주세요.

여기서 MVP는 정식 매장 전 팝업스토어와 같습니다. 모든 메뉴를 갖춘 가게가 아니라, 손님이 정말 원하는지 확인하는 작은 임시 매장입니다. 첫 앱도 그래야 합니다. 기능이 많을수록 멋있어 보이지만, 초보자에게는 확인할 것이 너무 많아집니다.

예를 들어 회의록 정리 앱을 만들고 싶다면 처음부터 음성 인식, 자동 요약, 참석자별 할 일 추출, 이메일 발송, 캘린더 등록을 모두 넣지 마세요. 첫 버전은 회의 제목, 날짜, 참석자, 주요 논의, 결정 사항, 다음 할 일을 입력하고 목록으로 보는 정도면 충분합니다.

첫 프롬프트를 더 좋게 만드는 세 가지 문장

프롬프트에 아래 세 문장을 추가하면 결과물이 더 초보자 친화적으로 나올 가능성이 높습니다.

내가 결과물을 쉽게 이해할 수 있도록 화면 구조를 단순하게 만들어주세요.

기능을 한 번에 많이 넣지 말고, 먼저 작동하는 최소 버전을 만든 뒤 추가 기능을 제안해주세요.

만들기 전에 요구사항에서 애매한 부분이 있으면 먼저 질문해주세요.

특히 세 번째 문장은 중요합니다. AI가 애매한 부분을 마음대로 추측하면 나중에 고치기 어려운 방향으로 앱이 만들어질 수 있습니다. 바이브 코딩에서는 AI에게 답만 요구하지 말고, 질문도 하게 만들어야 합니다.

결과물이 나온 뒤 확인할 것

앱 빌더가 첫 결과물을 만들어주면 잠깐 기분이 좋아집니다. 화면이 생기고 버튼이 보이면 벌써 앱을 완성한 것처럼 느껴집니다. 하지만 이때 바로 공유 링크를 보내기보다 먼저 테스트 데이터를 넣어보세요.

테스트 데이터란 진짜 정보가 아니라 확인용으로 넣는 가짜 정보입니다. 예를 들어 예약 문의 앱이라면 이름에 "홍길동", 연락처에 "010-0000-0000", 문의 내용에 "테스트 문의입니다"라고 넣어봅니다. 가족 일정 앱이라면 "토요일 장보기", "엄마", "오후 3시"처럼 부담 없는 정보를 넣습니다.

확인해야 할 것은 세 가지입니다. 입력한 내용이 잘 저장되는지, 저장된 내용이 보기 좋게 표시되는지, 수정하거나 삭제할 때 이상한 일이 생기지 않는지입니다. 이 세 가지가 되면 첫 MVP로는 꽤 괜찮습니다.

결과물이 아쉽다면 이렇게 요청하세요.

현재 앱은 첫 버전으로는 괜찮지만, 초보 사용자가 쓰기에는 조금 복잡합니다.
화면을 더 단순하게 정리해주세요.

수정 기준은 다음과 같습니다.
1. 가장 중요한 입력 항목만 위에 배치해주세요.
2. 버튼 이름을 한국어로 자연스럽게 바꿔주세요.
3. 저장된 목록은 카드 형태로 보기 쉽게 보여주세요.
4. 불필요한 설명과 장식은 줄여주세요.
5. 기존 기능이 망가지지 않게 수정해주세요.

AI에게 수정 요청을 할 때는 "더 예쁘게"보다 "무엇을 어떻게" 바꿀지 말하는 편이 좋습니다. 디자인도 기능처럼 구체적으로 말해야 합니다.

기능 추가 전 체크리스트

첫 앱이 작동하기 시작하면 기능을 더 넣고 싶어집니다. 검색도 넣고 싶고, 필터도 넣고 싶고, 통계도 보고 싶고, 로그인도 붙이고 싶습니다. 이 욕심은 자연스럽습니다. 하지만 기능 추가는 언제나 앱을 복잡하게 만듭니다.

기능을 추가하기 전에는 아래 질문을 확인하세요.

• 이 기능은 핵심 문제 해결에 꼭 필요한가?

• 없어도 첫 사용에는 문제가 없는가?

• 사용자가 이 기능을 어디에서 찾을 수 있는가?

• 이 기능 때문에 입력해야 할 정보가 늘어나는가?

• 이 기능이 데이터 저장 방식에 영향을 주는가?

• 이 기능을 추가한 뒤 기존 기능을 다시 테스트할 수 있는가?

예를 들어 독서 기록 앱에 검색 기능을 추가하는 것은 비교적 쉽습니다. 저장된 책 제목과 메모에서 단어를 찾으면 되기 때문입니다. 하지만 사용자별 로그인 기능을 추가하는 것은 훨씬 어렵습니다. 인증, 권한, 데이터 분리, 보안이 함께 따라옵니다. 인증은 출입증 확인과 비슷합니다. 누가 들어와도 되는지 확인하고, 그 사람에게 맞는 정보만 보여줘야 합니다.

처음에는 검색, 필터, 정렬, 간단한 통계처럼 안전한 기능부터 추가하세요. 로그인, 결제, 외부 API 연동, 관리자 권한, 여러 사용자 데이터 분리는 나중 단계로 미루는 편이 좋습니다.

배포 전 체크리스트

배포는 가게 문을 열고 손님이 들어올 수 있게 하는 것과 같습니다. 내 컴퓨터나 앱 빌더 미리보기 화면에서만 보던 앱을 다른 사람도 접속할 수 있게 만드는 단계입니다.

배포 자체는 도구가 쉽게 도와줄 수 있습니다. 하지만 공개 링크를 공유한다는 것은 책임이 생긴다는 뜻이기도 합니다. 특히 개인정보를 받는 앱이라면 더 조심해야 합니다.

공유하기 전에는 아래 체크리스트를 확인하세요.

• 버튼이 모두 작동하는가?

• 모바일 화면에서 깨지지 않는가?

• 한국어 문구가 자연스러운가?

• 입력한 데이터가 정상적으로 보이는가?

• 삭제 기능에 실수 방지가 있는가?

• 개인정보를 과하게 수집하지 않는가?

• 실제 API 키가 화면에 노출되지 않는가?

• 공유 링크가 제대로 열리는가?

• 다른 사람이 봐도 사용법을 이해할 수 있는가?

여기서 API 키는 외부 서비스에 들어가기 위한 비밀 열쇠와 같습니다. 환경변수는 그 비밀 열쇠를 코드 안에 그대로 적지 않고 안전한 금고에 넣어두는 방식입니다. 금고 비밀번호를 가게 유리문에 붙여두면 안 되듯이, API 키를 화면이나 공개 코드에 노출하면 안 됩니다.

배포 전에 AI에게 아래처럼 점검을 요청할 수도 있습니다.

이 앱을 다른 사람에게 공유하기 전에 점검하고 싶습니다.
초보자 관점에서 위험하거나 불편한 부분을 찾아주세요.

특히 다음 항목을 확인해주세요.
1. 버튼이 모두 자연스럽게 작동하는지
2. 모바일 화면에서 사용하기 불편한 부분이 있는지
3. 한국어 문구가 어색하지 않은지
4. 개인정보를 과하게 수집하고 있지 않은지
5. API 키나 비밀값이 화면이나 코드에 노출될 위험이 있는지
6. 삭제 기능에 실수 방지 안내가 필요한지
7. 첫 사용자도 사용법을 이해할 수 있는지

문제점을 찾은 뒤, 수정 우선순위를 상/중/하로 나눠서 알려주세요.

이 프롬프트는 특히 마지막 공유 전에 유용합니다. AI가 만든 앱도 반드시 사람이 검토해야 합니다. AI는 그럴듯한 화면을 만들 수 있지만, 실제 사용자가 당황하는 지점까지 완벽하게 예측하지는 못합니다.

개인정보가 들어가는 앱의 추가 체크리스트

이름, 전화번호, 이메일, 주소, 생년월일, 사진, 건강 상태, 결제 정보처럼 개인과 관련된 정보가 들어가면 더 신중해야 합니다. 초보자의 첫 앱에서는 가능하면 이런 정보를 적게 받는 편이 좋습니다.

개인정보가 들어간다면 아래 질문을 추가로 확인하세요.

• 이 정보를 꼭 받아야 하는가?

• 덜 민감한 정보로 대체할 수 있는가?

• 사용자가 왜 이 정보를 입력해야 하는지 알 수 있는가?

• 입력한 정보를 누가 볼 수 있는가?

• 테스트 데이터와 실제 데이터를 구분했는가?

• 삭제 요청이 들어오면 지울 수 있는가?

• 관리자 화면이 아무에게나 열리지 않는가?

• 공개 링크로 다른 사람의 정보가 보이지 않는가?

예를 들어 강의 후기 수집 앱은 이름 없이도 운영할 수 있습니다. "익명 후기"로 만들면 개인정보 위험이 줄어듭니다. 예약 문의 앱은 연락처가 필요할 수 있지만, 주민등록번호나 자세한 주소까지 받을 필요는 거의 없습니다. 운동 기록 앱도 건강 상태나 질병 정보를 다루기 시작하면 민감해집니다.

개인정보는 적게 받을수록 안전합니다. 앱이 똑똑해 보이려고 많은 정보를 요구할 필요는 없습니다.

오류가 났을 때 확인할 순서

앱을 만들다 보면 오류가 납니다. 버튼이 눌리지 않거나, 입력값이 저장되지 않거나, 화면이 모바일에서 깨질 수 있습니다. 이것은 실패가 아니라 과정입니다. 버그는 주문한 메뉴와 다른 음식이 나오는 상황이고, 디버깅은 주문이 어디서 꼬였는지 확인하는 일입니다.

오류가 났을 때는 화내듯이 "안 돼요. 고쳐줘요"라고 말하기보다 상황을 차분히 설명해야 합니다.

아래 순서로 정리해보세요.

• 어떤 화면에서 문제가 생겼는가?

• 어떤 버튼이나 기능을 사용했는가?

• 어떤 값을 입력했는가?

• 기대한 결과는 무엇인가?

• 실제 결과는 무엇인가?

• 오류 메시지가 있다면 그대로 붙였는가?

• 최근에 추가하거나 수정한 기능은 무엇인가?

오류 수정 프롬프트는 이렇게 쓸 수 있습니다.

앱에서 오류가 발생했습니다.
아래 정보를 바탕으로 원인을 추측하고, 기존 기능이 망가지지 않게 수정해주세요.

문제가 생긴 화면: [예: 할 일 목록 화면]
사용한 기능: [예: 완료 버튼 클릭]
입력한 값: [예: 할 일 제목 "보고서 작성"]
기대한 결과: [예: 완료 상태로 바뀌고 목록에 남아 있어야 함]
실제 결과: [예: 버튼을 누르면 항목이 사라짐]
오류 메시지: [있으면 그대로 붙여넣기]
최근 변경 사항: [예: 필터 기능을 추가함]

수정 후에는 어떤 부분을 고쳤는지 초보자도 이해할 수 있게 설명해주세요.

중요한 것은 오류를 한 번에 모두 고치려 하지 않는 것입니다. 문제가 여러 개라면 하나씩 나눠서 요청하세요. 버튼 문제, 저장 문제, 모바일 화면 문제를 한 프롬프트에 모두 넣으면 AI가 엉뚱한 부분까지 건드릴 수 있습니다.

책을 덮은 뒤 만들 첫 앱 후보 3개 정하기

이제 읽기에서 만들기로 넘어갈 시간입니다. 그런데 바로 도구를 열기 전에 첫 앱 후보를 세 개만 적어보세요. 후보가 하나뿐이면 막혔을 때 포기하기 쉽고, 후보가 열 개면 고르느라 시작하지 못합니다. 세 개가 적당합니다.

아래 양식을 그대로 채워보세요.

잘 떠오르지 않는다면 아래 예시에서 골라도 됩니다.

처음 만들 앱은 되도록 "쉬움"에서 고르세요. 첫 앱의 목적은 자랑할 만한 완성작을 만드는 것이 아니라, 내가 AI에게 설명하고 결과물을 확인하고 다시 수정하는 경험을 얻는 것입니다.

첫 앱 후보를 고르는 프롬프트

아이디어가 여전히 애매하다면 AI에게 후보 고르기를 도와달라고 요청해도 됩니다.

나는 코딩을 모르는 초보자입니다.
바이브 코딩으로 첫 웹앱을 만들고 싶습니다.

아래는 내가 생각한 앱 후보입니다.
1. [후보 1]
2. [후보 2]
3. [후보 3]

각 후보를 다음 기준으로 평가해주세요.
1. 초보자가 만들기 쉬운지
2. 로그인 없이 MVP를 만들 수 있는지
3. 개인정보 위험이 낮은지
4. 핵심 기능이 단순한지
5. 1주 안에 테스트해볼 수 있는지

마지막에는 가장 먼저 만들 앱 1개를 추천하고, 그 이유를 쉽게 설명해주세요.

AI에게 아이디어를 맡긴다고 해서 생각을 포기하는 것은 아닙니다. AI는 조언자이고, 선택은 당신이 합니다. 내가 실제로 겪는 불편함을 가장 잘 아는 사람은 여전히 나 자신입니다.

다음 2주 실습 계획

책을 읽은 직후에는 의욕이 높습니다. 하지만 의욕만으로는 앱이 완성되지 않습니다. 그래서 2주짜리 작은 계획을 세워두는 것이 좋습니다. 하루 종일 붙잡고 있을 필요는 없습니다. 하루 30분에서 1시간이면 충분합니다.

1일 차: 후보 3개 적기

오늘은 만들지 않아도 됩니다. 내 업무와 일상에서 반복되는 불편함을 떠올리고 앱 후보를 세 개만 적으세요. 직장인이라면 회의록, 업무 요청, 보고 일정에서 찾을 수 있습니다. 강사라면 후기 수집, 과제 확인, 수강생 질문 정리에서 찾을 수 있습니다. 소상공인이라면 예약 문의, 재고 메모, 고객 요청 정리에서 찾을 수 있습니다.

2일 차: 첫 앱 하나 고르기

후보 세 개를 쉬움, 보통, 어려움으로 나눕니다. 로그인, 결제, 민감한 개인정보, 여러 사용자 권한이 필요한 앱은 뒤로 미루세요. 첫 앱은 입력, 저장, 목록 보기만으로 의미가 있는 것이 좋습니다.

3일 차: 앱 기획서 한 장 쓰기

사용자, 문제, 핵심 기능, 입력 정보, 결과 정보, 제외할 기능을 한 장으로 정리합니다. 길게 쓰지 않아도 됩니다. "나 혼자 쓰는 독서 기록 앱. 책 제목, 저자, 읽은 날짜, 메모를 저장하고 목록으로 본다. 로그인과 추천 기능은 제외한다." 이 정도면 시작할 수 있습니다.

4일 차: 첫 생성 프롬프트 작성하기

앞에서 제공한 첫 프롬프트 템플릿을 채웁니다. 기능은 번호로 쓰고, 화면 구성도 번호로 씁니다. 디자인 분위기는 "깔끔한 개인 기록 앱", "업무용 SaaS 느낌", "따뜻한 다이어리 느낌"처럼 구체적으로 적습니다.

5일 차: 앱 빌더형 도구로 첫 버전 만들기

Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구 중 하나를 골라 첫 프롬프트를 넣습니다. 도구를 고를 때 너무 오래 고민하지 마세요. 유명한 도구가 초보자에게 쉬운 도구는 아닙니다. 처음에는 화면, 기능, 배포 흐름을 단순하게 경험할 수 있는 도구가 좋습니다.

6일 차: 테스트 데이터 넣기

진짜 정보 대신 가짜 정보를 넣어봅니다. 입력, 저장, 목록 보기, 수정, 삭제가 되는지 확인합니다. 모바일 화면에서도 열어봅니다. 버튼 이름과 한국어 문구가 자연스러운지도 봅니다.

7일 차: 첫 수정 요청하기

아쉬운 점을 세 개만 골라 수정 요청을 합니다. 예를 들어 "입력창이 너무 많다", "목록이 한눈에 안 보인다", "모바일에서 버튼이 작다"처럼 구체적으로 말하세요. 한 번에 앱 전체를 뒤집는 요청은 피하는 것이 좋습니다.

8일 차: 기능 하나만 추가하기

검색, 필터, 정렬, 복사 버튼, 간단한 통계 중 하나만 추가합니다. 기능을 추가한 뒤 기존 기능이 망가지지 않았는지 다시 확인합니다. 기능 추가는 늘 테스트와 한 세트입니다.

9일 차: 디자인 다듬기

색상, 여백, 버튼 크기, 카드 형태, 모바일 화면을 다듬습니다. "예쁘게"보다 "모바일에서 입력하기 편하게", "목록을 카드 형태로", "중요한 버튼을 눈에 띄게"처럼 요청하세요.

10일 차: 오류와 불편함 기록하기

사용하면서 불편한 점을 적습니다. 앱이 느린지, 버튼이 헷갈리는지, 데이터가 사라지는지, 삭제가 너무 쉬운지 확인합니다. 오류가 있다면 재현 순서를 적어 AI에게 전달합니다.

11일 차: 배포 전 점검하기

배포 전 체크리스트를 적용합니다. 개인정보를 과하게 받고 있지 않은지, API 키가 노출되지 않았는지, 공유 링크가 열리는지 확인합니다. 개인용 앱이라면 굳이 공개할 필요는 없습니다. 공유는 선택입니다.

12일 차: 가까운 사람 1명에게 보여주기

친구, 동료, 가족 중 한 명에게 보여주고 사용해보게 합니다. 설명 없이도 쓸 수 있는지 보는 것이 좋습니다. 사용자가 어디서 멈추는지 관찰하세요. 말로는 "괜찮다"고 해도 실제 행동은 다를 수 있습니다.

13일 차: 피드백 반영하기

받은 피드백을 모두 반영하지 마세요. 먼저 세 가지로 나눕니다. 바로 고칠 작은 문제, 다음 버전에 넣을 개선, 지금은 미룰 큰 기능입니다. 초보자에게 중요한 능력은 기능을 많이 넣는 능력이 아니라, 지금 하지 않을 일을 정하는 능력입니다.

14일 차: 첫 앱 회고하기

마지막 날에는 앱을 더 만들기보다 배운 것을 정리하세요. 어떤 프롬프트가 잘 통했는지, 어떤 요청이 애매했는지, 어떤 기능이 생각보다 어려웠는지 적어봅니다. 이 기록이 두 번째 앱을 만들 때 가장 좋은 교재가 됩니다.

2주 계획을 한눈에 보기

이 계획은 꼭 완벽하게 지킬 필요는 없습니다. 중간에 하루를 쉬어도 괜찮습니다. 중요한 것은 "언젠가 만들어야지"를 "이번 주에는 여기까지 해보자"로 바꾸는 것입니다.

다음 단계: 두 번째 앱에서는 무엇을 해볼까

첫 앱을 만들고 나면 두 번째 앱에서는 조금 더 넓혀볼 수 있습니다. 하지만 여전히 무리할 필요는 없습니다. 두 번째 앱에서 도전하기 좋은 것은 다음 정도입니다.

• 검색, 필터, 정렬을 더 자연스럽게 붙이기

• 로컬 저장을 활용해 새로고침 후에도 데이터 남기기

• CSV 내보내기처럼 데이터를 밖으로 빼는 기능 추가하기

• 관리자용 목록 화면 만들기

• 모바일 화면을 더 편하게 다듬기

• Google AI Studio Build mode 같은 도구로 작은 AI 기능 실험하기

반면 로그인, 권한 관리, 결제, 대규모 데이터, 민감한 개인정보, 의료·법률·금융 판단 기능은 여전히 신중해야 합니다. 이런 기능은 개발자형 도구나 전문가 협업이 필요한 경우가 많습니다. Claude Code, ChatGPT Codex, Cursor, Windsurf 같은 개발자형 코딩 에이전트나 IDE는 이미 만든 앱을 확장하거나 코드베이스를 관리할 때 더 어울립니다. 완전 초보자의 첫 도구로는 어렵게 느껴질 수 있습니다.

순서를 기억하세요. 먼저 작은 앱을 만들고, 그다음 고치고, 그다음 공유하고, 그다음 확장합니다.

마지막으로 다시 확인할 세 문장

이 책에서 반복해서 말한 핵심은 단순합니다.

첫째, 바이브 코딩은 개발자가 되는 길이 아니라 만드는 사람의 감각을 되찾는 길입니다.

둘째, 첫 앱은 완성도보다 작동 경험이 중요합니다.

셋째, 좋은 프롬프트는 앱의 품질을 결정하지만, 한 번에 완벽한 프롬프트를 쓰려고 할 필요는 없습니다.

당신은 이제 코딩 문법을 줄줄 외우는 사람이 아닐 수 있습니다. 그래도 괜찮습니다. 이 책의 목표는 당신을 당장 개발자로 만드는 것이 아니었습니다. 목표는 당신이 일상과 업무에서 느끼는 작은 불편함을 앱이라는 형태로 바꿔보게 하는 것이었습니다.

이제 당신이 할 일은 간단합니다.

앱 후보 세 개를 적으세요.

그중 가장 쉬운 하나를 고르세요.

첫 프롬프트를 쓰세요.

그리고 앱 빌더형 도구에 넣어보세요.

결과물이 이상하게 나와도 괜찮습니다. 수정 요청을 하면 됩니다. 기능이 너무 많아져도 괜찮습니다. MVP로 줄이면 됩니다. 오류가 나도 괜찮습니다. 오류 상황을 설명하고 하나씩 고치면 됩니다.

첫 앱은 작아도 됩니다. 아니, 작을수록 좋습니다.

당신은 이제 코딩을 잘하는 사람은 아닐 수 있습니다. 하지만 내가 원하는 작은 앱을 AI에게 설명하고 만들어보는 첫걸음은 뗄 수 있습니다. 그 첫걸음이면 충분합니다. 만드는 감각은 거기서 다시 시작됩니다.

한 장 요약

체크리스트는 바이브 코딩 초보자의 안전장치입니다. 앱을 만들기 전에는 사용자, 문제, 핵심 기능, 제외할 기능, 입력 정보, 결과 정보를 확인해야 합니다. 첫 프롬프트를 쓸 때는 내가 누구인지, 무엇을 만들고 싶은지, 누가 쓰는지, 필요한 기능과 화면 구성을 번호로 정리해야 합니다. 배포 전에는 버튼 작동, 모바일 화면, 한국어 문구, 데이터 저장, 삭제 실수 방지, 개인정보 수집, API 키 노출 여부를 반드시 점검해야 합니다.

책을 덮은 뒤에는 첫 앱 후보 세 개를 적고, 가장 쉬운 하나를 골라 2주 동안 작게 만들어보세요. 처음부터 완벽한 앱을 만들 필요는 없습니다. 작동하는 작은 앱 하나가 다음 앱을 만드는 가장 좋은 출발점입니다.