"말로 앱을 만든다"는 말이 수상하게 들릴 때
바이브 코딩이라는 말을 처음 들으면 조금 이상하게 느껴질 수 있습니다. "코딩을 몰라도 앱을 만든다니, 그게 정말 가능한가?" 하는 생각이 먼저 들죠. 더 솔직히 말하면, 조금 과장된 광고처럼 들리기도 합니다.
그 의심은 아주 건강합니다. 바이브 코딩은 마법이 아닙니다. 머릿속에 떠오른 앱을 AI가 그대로 읽어내는 기술도 아닙니다. 대신 우리가 평소에 쓰는 말로 "무엇을 만들고 싶은지" 설명하면, AI가 그 설명을 바탕으로 첫 번째 결과물을 만들어주고, 우리는 그 결과를 보며 다시 고쳐나가는 방식입니다.
예를 들어 이런 식입니다.
나는 독서 모임을 운영하는 사람입니다.
회원들이 읽은 책과 한 줄 감상을 기록할 수 있는 간단한 웹앱을 만들고 싶습니다.
사용자는 책 제목, 저자, 읽은 날짜, 별점, 한 줄 감상을 입력할 수 있어야 합니다.
목록 화면에서는 기록한 책들이 카드 형태로 보이면 좋겠습니다.
처음 버전에서는 로그인, 댓글, 이미지 업로드는 제외하고 MVP로 만들어주세요.이 문장은 프로그래밍 코드가 아닙니다. 하지만 AI 앱 빌더에게는 앱을 만들기 위한 중요한 설계 설명이 됩니다. 여기에는 누가 쓰는지, 무엇을 기록하는지, 어떤 화면이 필요한지, 무엇을 빼야 하는지가 들어 있습니다.
바이브 코딩의 핵심은 바로 여기에 있습니다. 코딩 문법을 직접 입력하는 대신, 앱의 목적과 구조를 말로 설명하고, AI가 만든 결과물을 보며 방향을 잡아가는 것입니다.
바이브 코딩은 '느낌대로 대충 만들기'가 아닙니다
'바이브'라는 단어 때문에 오해가 생기기도 합니다. 마치 분위기만 말하면 알아서 멋진 앱이 완성될 것처럼 들리죠. 하지만 실제로는 반대에 가깝습니다. 좋은 결과를 얻으려면 내 머릿속의 vague한, 그러니까 흐릿한 생각을 AI가 이해할 수 있을 만큼 구체적으로 풀어줘야 합니다.
"예약 앱 만들어줘"라고 말하면 AI는 많은 것을 추측해야 합니다. 미용실 예약인지, 상담 예약인지, 강의 신청인지 알 수 없습니다. 예약 날짜만 필요한지, 시간대도 필요한지, 연락처를 받아야 하는지도 모릅니다. 관리자만 보는 화면이 필요한지, 고객도 예약 현황을 봐야 하는지도 알기 어렵습니다.
반면 이렇게 말하면 훨씬 나아집니다.
동네 공방을 운영하는 사람을 위한 예약 문의 웹앱을 만들어주세요.
고객은 이름, 연락처, 원하는 날짜, 원하는 시간대, 문의 내용을 입력할 수 있어야 합니다.
관리자는 접수된 예약 문의 목록을 확인하고 상태를 '확인 전', '연락 완료', '취소'로 바꿀 수 있으면 좋겠습니다.
처음 버전에서는 온라인 결제와 회원가입은 제외해주세요.
모바일에서 보기 편한 디자인으로 MVP를 만들어주세요.두 요청의 차이는 코딩 지식이 아닙니다. 설명의 선명도입니다.
바이브 코딩은 코딩을 안 배워도 된다는 뜻이 아닙니다. 정확히 말하면, 처음부터 프로그래밍 문법을 외우지 않아도 작은 앱을 만들어볼 수 있다는 뜻에 가깝습니다. 대신 다른 능력이 필요합니다. 내가 원하는 것을 정리하고, AI가 이해할 수 있는 말로 전달하고, 결과를 보고 다시 요청하는 능력입니다.
이 책에서 계속 강조할 문장이 있습니다.
바이브 코딩은 코딩을 안 배워도 된다는 뜻이 아니라, 내가 원하는 것을 AI가 이해하게 설명하는 기술입니다.
AI 앱 제작은 보통 이렇게 흘러갑니다
처음부터 완벽한 앱이 한 번에 나오기를 기대하면 금방 실망할 수 있습니다. 바이브 코딩은 한 번의 주문으로 끝나는 작업이 아니라, 대화하며 다듬는 작업입니다. 식당에서 음식을 주문하는 장면을 떠올려보면 쉽습니다.
"맛있는 거 주세요"라고 하면 주방은 난감합니다. 손님이 매운 음식을 좋아하는지, 고기를 먹는지, 알레르기가 있는지 알 수 없기 때문입니다. 하지만 "맵지 않고, 채소가 들어가고, 밥과 함께 먹을 수 있는 따뜻한 메뉴를 추천해주세요"라고 말하면 훨씬 정확한 결과가 나옵니다.
AI에게 앱을 부탁하는 과정도 비슷합니다. 보통 다음 흐름으로 진행됩니다.
만들고 싶은 앱을 자연어로 설명합니다.
AI가 첫 번째 버전을 생성합니다.
미리보기 화면에서 실제로 눌러보고 확인합니다.
이상한 점, 빠진 점, 불편한 점을 수정 요청합니다.
다시 결과를 확인하고 필요한 만큼 반복합니다.
여기서 중요한 단계는 3번과 4번입니다. 많은 초보자가 "AI가 만들어줬으니 끝났다"고 생각하지만, 실제로는 그때부터가 시작입니다. 버튼을 눌러보고, 입력값이 저장되는지 확인하고, 모바일 화면에서 깨지지 않는지 살펴봐야 합니다.
예를 들어 할 일 관리 앱을 만들었다고 해봅시다. 첫 화면은 그럴듯하게 나왔습니다. 입력창도 있고, 추가 버튼도 있습니다. 그런데 막상 할 일을 입력하고 버튼을 누르니 목록에 추가되지 않습니다. 이때 "망했다"고 생각할 필요는 없습니다. 바이브 코딩에서는 이런 상황이 매우 흔합니다. 이제 이렇게 말하면 됩니다.
현재 할 일 입력창에 내용을 입력하고 '추가' 버튼을 눌러도 목록에 새 항목이 나타나지 않습니다.
입력값이 비어 있지 않을 때만 할 일이 추가되도록 수정해주세요.
추가 후에는 입력창이 비워지고, 새 항목이 목록 맨 위에 보이게 해주세요.이 요청은 불만이 아니라 진단입니다. 무엇이 안 되는지, 어떤 결과를 원하는지 구체적으로 말하고 있습니다. 바이브 코딩에서 수정 요청은 실패의 증거가 아니라 제작 과정의 일부입니다.
프롬프트, 생성, 미리보기, 수정 요청
바이브 코딩을 이해하려면 몇 가지 단어만 먼저 알아두면 됩니다. 여기서는 깊게 들어가지 않고, 첫 여행을 위한 지도 정도로만 익히겠습니다.
프롬프트는 AI에게 보내는 요청문입니다. "이런 앱을 만들어줘", "이 버튼이 작동하지 않으니 고쳐줘", "디자인을 더 차분하게 바꿔줘"처럼 AI에게 방향을 알려주는 문장입니다. 프롬프트는 식당의 주문서와 비슷합니다. 주문서가 구체적일수록 원하는 음식이 나올 가능성이 높습니다.
생성은 AI가 프롬프트를 바탕으로 앱의 첫 결과물을 만드는 단계입니다. 화면, 버튼, 입력창, 목록 같은 요소가 만들어질 수 있습니다. 도구에 따라 데이터 저장이나 배포까지 이어지기도 합니다.
미리보기는 만들어진 앱을 실제 사용자처럼 확인하는 단계입니다. 여기서 우리는 개발자가 아니라 사용자 입장에서 봐야 합니다. 버튼이 보이는지, 글자가 자연스러운지, 입력이 되는지, 내가 원한 흐름과 맞는지 확인합니다.
수정 요청은 결과를 보고 다시 AI에게 고쳐달라고 말하는 단계입니다. "더 예쁘게 해줘"보다 "카드 간격을 넓히고, 제목 글자를 더 크게 하고, 저장 버튼을 화면 아래에 고정해줘"가 좋습니다.
이 네 단어만 알아도 바이브 코딩의 기본 흐름은 잡힙니다.
프롬프트 작성 → 앱 생성 → 미리보기 → 수정 요청 → 재검토이 반복 루프가 바이브 코딩의 중심입니다. 한 번에 완벽한 앱을 얻는 것이 목표가 아닙니다. 작은 첫 버전을 만들고, 눈으로 확인하고, 말로 고쳐나가는 것이 목표입니다.
코딩을 모르는 사람이 맡아야 할 역할
여기서 이런 질문이 생길 수 있습니다.
"AI가 코드를 만들어준다면, 나는 뭘 해야 하나요?"
좋은 질문입니다. 바이브 코딩에서 사람의 역할은 사라지지 않습니다. 오히려 더 중요해집니다. 다만 역할이 달라집니다. 직접 벽돌을 쌓는 사람이 아니라, 어떤 집을 지을지 설명하고, 지어진 집이 생활에 맞는지 확인하는 사람에 가까워집니다.
비개발자인 당신이 맡아야 할 역할은 크게 네 가지입니다.
이 앱이 누구를 위한 것인지 정하기
가장 중요한 기능이 무엇인지 고르기
결과물을 직접 눌러보고 이상한 점 찾기
AI에게 다음 수정 방향을 구체적으로 말하기
예를 들어 강의 후기 수집 앱을 만든다고 해봅시다. 개발 지식이 없어도 당신은 이런 판단을 할 수 있습니다.
"수강생이 너무 많은 항목을 입력하면 귀찮아할 것 같아."
"별점보다 한 줄 후기가 더 중요해."
"강의명을 매번 쓰게 하지 말고, 내가 미리 정한 강의 중에서 선택하게 하고 싶어."
이런 판단은 코드가 아니라 사용자를 이해하는 감각에서 나옵니다. 그리고 작은 업무용 앱을 만들 때는 이 감각이 매우 중요합니다.
바이브 코딩은 개발자가 되는 길과도 다릅니다. 개발자는 코드 구조, 성능, 보안, 테스트, 배포, 유지보수까지 깊게 다룹니다. 반면 이 책의 독자가 처음 목표로 삼을 것은 내 업무나 일상에 필요한 작은 웹앱을 직접 만들어보는 경험입니다.
예를 들면 이런 것들입니다.
회의에서 나온 할 일을 정리하는 간단한 업무 추적 앱
학부모 상담 일정을 모아보는 예약 문의 앱
블로그 글감을 주제별로 저장하는 아이디어 보관함
이런 앱은 세상을 바꾸는 거대한 서비스가 아니어도 괜찮습니다. 중요한 것은 내가 반복해서 겪던 불편을 작은 도구로 바꿔보는 경험입니다.
유명한 도구가 항상 쉬운 도구는 아닙니다
바이브 코딩을 검색하다 보면 여러 도구 이름이 한꺼번에 등장합니다. Lovable, Replit Agent, Bolt.new, v0, Google AI Studio, Claude Code, Codex, Cursor 같은 이름들이죠. 처음 보는 사람에게는 전부 비슷해 보입니다. 모두 AI와 관련 있고, 모두 앱이나 코드를 만든다고 말하니까요.
하지만 초보자 입장에서는 반드시 구분해야 합니다. 모든 AI 개발 도구가 같은 출발점에 서 있지 않기 때문입니다.
먼저 초보용 앱 빌더형 도구가 있습니다. Lovable, Replit Agent, Bolt.new 같은 도구가 여기에 가깝습니다. 자연어로 원하는 앱을 설명하면 화면과 기능을 포함한 첫 버전을 만들어주는 흐름이 비교적 단순합니다. 처음 성공 경험을 만들기에 좋습니다.
다음으로 중간 단계 도구가 있습니다. v0, Google AI Studio Build mode, Softr 같은 도구는 화면을 빠르게 만들거나, AI 기능을 붙이거나, 업무용 앱을 구성하는 데 유용합니다. 다만 어느 정도 웹앱의 구조를 이해하면 더 잘 쓸 수 있습니다.
마지막으로 개발자형 코딩 에이전트나 IDE가 있습니다. Claude Code, ChatGPT Codex, Cursor, Windsurf, Gemini Code Assist 같은 도구가 여기에 들어갑니다. 이들은 코드베이스, 터미널, GitHub, 테스트, 디버깅 같은 개발자 업무 흐름에 더 가깝습니다. 매우 강력하지만, 완전 초보자의 첫 도구로는 부담스러울 수 있습니다.
여기서 꼭 기억해야 할 문장이 있습니다.
유명한 도구가 초보자에게 쉬운 도구는 아닙니다.
처음에는 앱 빌더형 도구로 작은 성공을 경험하는 편이 좋습니다. "내가 말한 대로 화면이 생겼다", "버튼을 눌렀더니 기록이 추가됐다", "링크를 보내 다른 사람이 열어봤다" 같은 경험이 쌓여야 다음 단계로 갈 힘이 생깁니다.
첫 앱은 작을수록 좋습니다
처음 바이브 코딩을 할 때 가장 흔한 실수는 너무 많은 것을 한 번에 요구하는 것입니다.
"회원가입이 되고, 결제가 되고, 관리자 페이지가 있고, 통계 대시보드가 있고, 카카오 알림도 보내고, AI 추천도 해주는 앱을 만들어줘."
이런 요청은 멋져 보이지만 초보자에게는 위험합니다. AI가 어느 정도 결과물을 만들어낼 수는 있어도, 내가 그것을 검토하고 고칠 수 있어야 합니다. 기능이 많아질수록 어디서 문제가 생겼는지 찾기 어려워집니다.
첫 앱은 작을수록 좋습니다. 독서 기록 앱이라면 처음에는 책 제목, 저자, 한 줄 감상만 입력해도 충분합니다. 운동 루틴 기록 앱이라면 날짜, 운동 이름, 세트 수 정도만 있어도 됩니다. 예약 문의 앱이라면 이름, 연락처, 원하는 날짜, 문의 내용만 받아도 첫 버전으로는 충분합니다.
처음부터 정식 매장을 열 필요는 없습니다. MVP, 즉 최소 기능 제품으로 시작하면 됩니다. MVP는 정식 매장을 열기 전에 작게 운영해보는 팝업스토어와 비슷합니다. 메뉴가 많지 않아도 손님이 원하는지 확인할 수 있고, 반응을 보며 고칠 수 있습니다.
바이브 코딩에서 첫 앱의 목표는 완성도가 아닙니다. 작동 경험입니다.
"내가 설명했다."
"AI가 만들었다."
"내가 눌러봤다."
"이상한 점을 말로 고쳤다."
이 네 단계를 한 번 경험하면, 앱 제작은 막연한 세계가 아니라 반복 가능한 과정으로 바뀝니다.
실제로 AI에게 어떻게 말하면 좋을까
처음 프롬프트를 쓸 때는 빈 화면이 가장 어렵습니다. 무엇부터 말해야 할지 모르기 때문입니다. 이럴 때는 다음 구조를 그대로 따라 쓰면 됩니다.
나는 [나의 상황/역할]입니다.
[사용자]를 위한 [앱 종류]를 만들고 싶습니다.
이 앱의 목적은 [해결하고 싶은 문제]입니다.
필요한 기능은 다음과 같습니다.
1. [기능 1]
2. [기능 2]
3. [기능 3]
화면은 다음처럼 구성해주세요.
1. [첫 화면]
2. [입력/작성 화면]
3. [목록/결과 화면]
디자인은 [원하는 분위기]로 해주세요.
처음 버전에서는 [제외할 기능]은 빼주세요.
초보자가 확인하기 쉬운 MVP로 만들어주세요.이 구조를 사용해 회의록 정리 앱을 요청하면 이렇게 됩니다.
나는 작은 팀에서 프로젝트 관리를 맡고 있는 직장인입니다.
팀 회의 내용을 정리하고 후속 할 일을 관리하는 회의록 정리 웹앱을 만들고 싶습니다.
이 앱의 목적은 회의 후에 누가 무엇을 해야 하는지 잊지 않도록 정리하는 것입니다.
필요한 기능은 다음과 같습니다.
1. 회의 제목, 날짜, 참석자, 회의 내용을 입력하는 기능
2. 결정 사항과 할 일을 따로 기록하는 기능
3. 할 일마다 담당자와 마감일을 적는 기능
4. 회의록 목록을 날짜순으로 보여주는 기능
화면은 다음처럼 구성해주세요.
1. 회의록 목록 화면
2. 새 회의록 작성 화면
3. 회의록 상세 보기 화면
디자인은 회사에서 쓰기 좋은 깔끔한 업무용 SaaS 느낌으로 해주세요.
처음 버전에서는 로그인, 파일 첨부, 이메일 발송 기능은 제외해주세요.
초보자가 확인하기 쉬운 MVP로 만들어주세요.여기서 SaaS는 인터넷으로 사용하는 업무용 소프트웨어를 뜻합니다. 어렵게 생각할 필요는 없습니다. 회사에서 쓰는 깔끔한 웹서비스 느낌이라고 이해하면 됩니다.
가족 일정 공유 앱이라면 이렇게 바꿀 수 있습니다.
나는 가족 일정을 자주 놓치는 부모입니다.
가족 구성원이 함께 볼 수 있는 간단한 가족 일정 공유 웹앱을 만들고 싶습니다.
이 앱의 목적은 병원 예약, 학교 행사, 가족 모임 같은 일정을 한곳에서 확인하는 것입니다.
필요한 기능은 다음과 같습니다.
1. 일정 제목, 날짜, 시간, 장소, 메모를 입력하는 기능
2. 가족 구성원 이름을 선택하는 기능
3. 다가오는 일정을 날짜순으로 보여주는 기능
4. 지난 일정과 예정 일정을 구분해서 보여주는 기능
화면은 다음처럼 구성해주세요.
1. 이번 주 일정 요약 화면
2. 새 일정 추가 화면
3. 전체 일정 목록 화면
디자인은 따뜻하고 보기 쉬운 가족용 앱 느낌으로 해주세요.
처음 버전에서는 로그인, 알림, 캘린더 연동은 제외해주세요.
모바일에서 보기 편한 MVP로 만들어주세요.프롬프트는 글을 잘 쓰는 대회가 아닙니다. 문장이 조금 투박해도 괜찮습니다. 중요한 것은 필요한 정보를 빠뜨리지 않는 것입니다.
미리보기에서 무엇을 확인해야 할까
AI가 첫 앱을 만들어주면 우리는 신기해서 화면만 훑어보고 넘어가기 쉽습니다. 하지만 바이브 코딩의 실력은 미리보기에서 자랍니다. 내가 만든 앱을 실제 사용자처럼 눌러보는 시간이 중요합니다.
독서 기록 앱을 예로 들어보겠습니다. 미리보기에서는 적어도 세 가지를 확인해야 합니다. 첫째, 책 정보를 입력했을 때 목록에 잘 추가되는지 봅니다. 둘째, 입력한 글자가 사라지지 않고 제대로 표시되는지 봅니다. 셋째, 스마트폰 화면에서도 버튼과 글자가 잘 보이는지 봅니다.
예약 문의 앱이라면 확인할 것이 조금 달라집니다. 고객이 이름과 연락처를 입력하지 않아도 제출되는지, 날짜 입력이 불편하지 않은지, 관리자가 문의 상태를 구분할 수 있는지 봐야 합니다.
강의 후기 수집 앱이라면 또 다릅니다. 수강생이 너무 많은 정보를 입력해야 하지 않는지, 별점 선택이 쉬운지, 후기를 제출한 뒤 "제출되었습니다" 같은 안내 문구가 보이는지 확인해야 합니다.
즉, 미리보기는 단순히 예쁜지 보는 단계가 아닙니다. 사용자가 실제로 목적을 달성할 수 있는지 확인하는 단계입니다.
이때 사용할 수 있는 점검 프롬프트도 있습니다.
지금 만든 앱을 초보 사용자 입장에서 점검해주세요.
사용자가 헷갈릴 만한 부분, 빠진 안내 문구, 작동하지 않을 가능성이 있는 기능을 찾아주세요.
그리고 지금 단계에서 꼭 고쳐야 할 것과 나중에 고쳐도 되는 것을 나눠서 알려주세요.이 프롬프트는 AI에게 앱을 다시 검토하게 만드는 요청입니다. 물론 AI의 점검도 완벽하지 않습니다. 하지만 내가 놓친 부분을 발견하는 데 도움이 됩니다.
흔한 실수와 고치는 방법
바이브 코딩 초보자가 자주 겪는 실수는 거의 비슷합니다. 실수 자체는 문제가 아닙니다. 중요한 것은 고치는 방법을 아는 것입니다.
첫 번째 실수는 너무 짧게 요청하는 것입니다. "할 일 앱 만들어줘"라고 하면 AI는 대부분의 내용을 추측해서 만듭니다. 이럴 때는 사용자, 목적, 필요한 기능, 제외할 기능을 추가해야 합니다.
방금 요청이 너무 간단했습니다. 다시 구체화하겠습니다.
이 앱은 개인 업무를 정리하는 직장인을 위한 할 일 관리 앱입니다.
할 일 제목, 마감일, 우선순위, 완료 여부를 관리할 수 있게 해주세요.
처음 버전에서는 로그인과 팀 공유 기능은 제외해주세요.두 번째 실수는 한 번에 너무 많은 기능을 넣는 것입니다. 기능이 많으면 멋져 보이지만, 첫 버전에서는 오히려 확인하기 어렵습니다. 이럴 때는 MVP로 줄여달라고 요청하면 됩니다.
현재 기능이 너무 많아 초보자가 확인하기 어렵습니다.
첫 번째 MVP 버전으로 줄여주세요.
가장 중요한 기능 3개만 남기고, 결제, 알림, 로그인, 통계, 관리자 권한 기능은 제외해주세요.세 번째 실수는 "예쁘게 해줘"처럼 모호하게 디자인을 요청하는 것입니다. 예쁨의 기준은 사람마다 다릅니다. 분위기, 사용자, 참고 느낌을 함께 말해야 합니다.
디자인을 더 구체적으로 수정해주세요.
전체 분위기는 다이어리 앱처럼 따뜻하고 차분하게 해주세요.
배경은 연한 크림색, 카드는 흰색, 버튼은 부드러운 초록색 계열로 해주세요.
모바일에서 한 손으로 입력하기 편하게 버튼과 입력창을 크게 만들어주세요.네 번째 실수는 오류 상황을 감정적으로만 설명하는 것입니다. "안 돼요", "이상해요"라고만 하면 AI도 원인을 찾기 어렵습니다. 어떤 행동을 했고, 어떤 결과가 나왔고, 원래는 어떻게 되어야 하는지를 말해야 합니다.
오류를 수정해주세요.
제가 한 행동: 제목 입력창에 '회의 준비'라고 입력하고 추가 버튼을 눌렀습니다.
현재 결과: 입력창은 비워지지만 목록에 할 일이 추가되지 않습니다.
원하는 결과: 추가 버튼을 누르면 새 할 일이 목록 맨 위에 나타나야 합니다.
관련 기능을 점검하고 수정해주세요.이렇게 말하면 AI가 문제를 훨씬 정확하게 이해합니다.
개발자가 되는 길과 만드는 사람이 되는 길
이 책은 당신에게 개발자가 되라고 말하지 않습니다. 물론 바이브 코딩을 하다 보면 개발에 흥미가 생길 수 있습니다. 나중에는 프론트엔드, 백엔드, 데이터베이스, API 같은 개념을 더 깊게 배우고 싶어질 수도 있습니다. 그것도 좋은 일입니다.
하지만 처음 목표는 다릅니다. 우리는 먼저 만드는 사람의 감각을 되찾으려 합니다. 여기서 만드는 사람이란 거창한 창업가만 뜻하지 않습니다. 자기 업무에서 반복되는 불편을 그냥 참지 않고, 작은 도구로 바꿔보는 사람입니다.
엑셀로 매번 복사해 붙이던 내용을 입력 폼으로 바꾸는 사람.
강의 후기를 카카오톡으로 흩어져 받지 않고 한곳에 모으는 사람.
가족 일정을 머릿속으로 기억하지 않고 함께 볼 수 있는 화면으로 만드는 사람.
이런 작은 변화가 바이브 코딩의 출발점입니다.
개발자는 건물을 구조적으로 설계하고 안전하게 시공하는 전문가에 가깝습니다. 반면 초보 바이브 코더는 내가 필요한 작은 공간을 어떻게 쓰고 싶은지 설명하는 사람에 가깝습니다. 둘은 경쟁 관계가 아닙니다. 오히려 나중에 개발자와 협업할 때도 "무엇을 원하는지 설명하는 능력"은 큰 도움이 됩니다.
이번 장의 실습 미션
이번 장에서는 아직 특정 도구를 열지 않아도 됩니다. 대신 만들고 싶은 앱을 말로 설명하는 연습을 해보겠습니다. 아래 질문에 답해보세요. 답이 완벽하지 않아도 괜찮습니다.
내가 반복해서 귀찮다고 느끼는 일은 무엇인가?
그 일을 하는 사람은 나 혼자인가, 다른 사람도 함께 쓰는가?
입력해야 하는 정보는 무엇인가?
결과로 보고 싶은 정보는 무엇인가?
첫 버전에서 빼도 되는 기능은 무엇인가?
이 질문을 바탕으로 아래 템플릿을 채워보세요.
나는 [상황/역할]입니다.
[누구]를 위한 [어떤 앱]을 만들고 싶습니다.
이 앱은 [반복되는 불편함]을 해결하기 위한 것입니다.
사용자가 입력해야 하는 정보는 다음과 같습니다.
1. [입력 정보 1]
2. [입력 정보 2]
3. [입력 정보 3]
결과 화면에서는 [보여주고 싶은 정보]가 보여야 합니다.
처음 버전에서는 [제외할 기능]은 빼주세요.
작고 단순한 MVP로 만들어주세요.예를 들어 직장인이라면 이렇게 쓸 수 있습니다.
나는 여러 프로젝트를 동시에 관리하는 직장인입니다.
나를 위한 업무 요청 정리 앱을 만들고 싶습니다.
이 앱은 메신저와 이메일로 흩어진 요청을 한곳에 모아 잊지 않게 하는 도구입니다.
사용자가 입력해야 하는 정보는 다음과 같습니다.
1. 요청 제목
2. 요청한 사람
3. 마감일
4. 진행 상태
결과 화면에서는 마감일이 가까운 요청부터 보여야 합니다.
처음 버전에서는 로그인, 알림, 팀원 초대 기능은 빼주세요.
작고 단순한 MVP로 만들어주세요.강사라면 이렇게 바꿀 수 있습니다.
나는 오프라인 강의를 운영하는 강사입니다.
수강생 후기를 모으는 강의 후기 수집 앱을 만들고 싶습니다.
이 앱은 강의가 끝난 뒤 흩어지는 후기를 한곳에 모으기 위한 도구입니다.
사용자가 입력해야 하는 정보는 다음과 같습니다.
1. 이름 또는 닉네임
2. 수강한 강의명
3. 별점
4. 한 줄 후기
5. 좋았던 점과 개선할 점
결과 화면에서는 후기 목록과 평균 별점이 보여야 합니다.
처음 버전에서는 로그인, 이미지 업로드, 자동 문자 발송 기능은 빼주세요.
작고 단순한 MVP로 만들어주세요.소상공인이라면 이렇게 시작할 수 있습니다.
나는 동네 네일숍을 운영하는 소상공인입니다.
고객의 예약 문의를 정리하는 예약 문의 앱을 만들고 싶습니다.
이 앱은 전화와 DM으로 흩어지는 예약 요청을 한곳에서 확인하기 위한 도구입니다.
사용자가 입력해야 하는 정보는 다음과 같습니다.
1. 고객 이름
2. 연락처
3. 원하는 날짜
4. 원하는 시간대
5. 요청 사항
결과 화면에서는 예약 문의가 최신순으로 보이고, 상태를 확인 전/연락 완료/취소로 바꿀 수 있어야 합니다.
처음 버전에서는 온라인 결제, 회원가입, 자동 알림 기능은 빼주세요.
작고 단순한 MVP로 만들어주세요.이 정도만 작성해도 첫 앱을 만들기 위한 재료는 충분합니다.
한 장 요약
바이브 코딩은 말로 앱을 만드는 새로운 제작 방식입니다. 하지만 마법은 아닙니다. 자연어로 앱의 목적, 사용자, 기능, 화면을 설명하면 AI가 첫 버전을 만들어주고, 우리는 미리보기에서 결과를 확인한 뒤 수정 요청을 하며 다듬어갑니다.
가장 중요한 흐름은 다음과 같습니다.
프롬프트로 원하는 앱을 설명한다.
AI가 만든 첫 버전을 미리보기로 확인한다.
이상한 점과 빠진 점을 구체적으로 수정 요청한다.
완벽한 앱보다 작은 MVP로 작동 경험을 먼저 만든다.
바이브 코딩은 코딩을 몰라도 된다는 약속이 아닙니다. 내가 원하는 것을 AI가 이해할 수 있도록 설명하는 기술입니다. 개발자가 되는 길과 내 업무용 도구를 만드는 길은 다릅니다. 처음에는 Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구로 작은 성공 경험을 만드는 것이 좋습니다.
다음 장에서는 노코드, 로우코드, AI 코딩, 바이브 코딩이 어떻게 다른지 차근차근 구분해보겠습니다. 이름은 비슷하지만, 각각의 출발점과 쓰임새는 다릅니다. 이 차이를 이해하면 내가 어떤 도구로 시작해야 할지도 훨씬 선명해집니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.