AI에게 질문하게 만드는 프롬프트

오류가 났을 때 우리는 보통 이렇게 말하고 싶어집니다.

"이거 고쳐줘."

마음은 충분히 이해됩니다. 버튼은 안 눌리고, 저장은 안 되고, 화면은 깨져 있고, AI 앱 빌더는 방금 전까지는 잘 만들 것처럼 보였는데 갑자기 엉뚱한 방향으로 수정합니다. 이럴 때 답답한 마음에 "알아서 고쳐줘"라고 말하면, AI는 정말로 '알아서' 고치려고 합니다. 문제는 그 '알아서'가 내가 원하는 방향과 다를 수 있다는 점입니다.

바이브 코딩에서 중요한 습관은 AI에게 명령만 내리는 것이 아닙니다. 좋은 협업은 질문과 확인에서 시작됩니다. 특히 요구사항이 불명확할수록, AI가 바로 만들지 않고 먼저 물어보게 해야 합니다.

이 장에서는 AI에게 "추측하지 말고 질문해줘"라고 요청하는 방법을 배웁니다. 기능 우선순위, 사용자 유형, 데이터 저장 방식, 보안, 모바일, 배포처럼 초보자가 놓치기 쉬운 항목을 AI가 먼저 확인하게 만드는 프롬프트를 익혀보겠습니다.

AI는 빈칸을 보면 채우려고 한다

AI 앱 빌더는 친절합니다. 우리가 대충 말해도 무언가를 만들어줍니다. "예약 문의 앱 만들어줘"라고만 말해도 입력 폼과 목록 화면을 만들어낼 수 있습니다. "독서 기록 앱 예쁘게 바꿔줘"라고 말해도 색상과 카드 디자인을 바꿔줍니다.

그런데 이 친절함이 때로는 문제가 됩니다. AI는 모르는 부분을 그대로 멈춰두기보다, 그럴듯한 기본값으로 채우려는 경향이 있습니다. 사용자가 누구인지 모르면 일반 사용자를 가정하고, 저장 방식을 말하지 않으면 브라우저 안에만 저장하거나 임시 데이터로 처리하고, 로그인 여부를 말하지 않으면 로그인 없이 만드는 식입니다.

식당에 비유해보겠습니다. 손님이 "적당히 매운 걸로 주세요"라고 하면 주방장은 자신의 기준으로 맵기를 정합니다. 어떤 사람에게는 딱 좋지만, 어떤 사람에게는 너무 맵거나 싱거울 수 있습니다. 그래서 좋은 직원은 먼저 묻습니다.

"고추장 베이스가 좋으세요, 고춧가루 베이스가 좋으세요?"

"매운맛은 신라면 정도면 괜찮으세요?"

"아이도 같이 먹나요?"

AI에게도 같은 태도가 필요합니다. 우리가 원하는 것은 '눈치껏 아무거나 만들어주는 AI'가 아니라, '부족한 정보를 먼저 확인하는 AI'입니다.

이 장에서 알아둘 용어

이번 장에서는 새로운 개발 문법을 배우지 않습니다. 대신 AI와 대화할 때 자주 나오는 판단 기준을 정리해두면 좋습니다.

요구사항은 앱에 꼭 들어가야 하는 조건입니다. 예를 들어 "강의 후기를 이름 없이 제출할 수 있어야 한다", "관리자는 후기 목록을 볼 수 있어야 한다", "모바일에서 작성하기 쉬워야 한다" 같은 문장이 요구사항입니다. 쉽게 말해 앱을 주문할 때 적는 주문서입니다.

우선순위는 먼저 만들 것과 나중에 만들 것을 정하는 순서입니다. 모든 기능을 한 번에 넣으면 앱이 복잡해지고 오류도 늘어납니다. 그래서 "이번 버전에서는 입력, 저장, 목록 보기만 만들고 검색과 통계는 나중에 추가한다"처럼 정해야 합니다.

데이터 저장 방식은 사용자가 입력한 내용을 어디에 보관할지에 관한 결정입니다. 브라우저 안에만 저장할 수도 있고, 데이터베이스에 저장할 수도 있습니다. 데이터베이스는 장부나 엑셀 파일처럼 정보를 쌓아두는 곳입니다. 개인 연습용 앱이라면 로컬 저장으로 충분할 때도 있지만, 여러 사람이 함께 쓰는 앱이라면 클라우드 저장이나 데이터베이스가 필요할 수 있습니다.

보안 점검은 앱이 민감한 정보를 과하게 모으거나, API 키 같은 비밀값을 화면에 드러내지 않는지 확인하는 일입니다. API 키는 외부 서비스에 접속하기 위한 비밀번호 같은 값입니다. 초보 단계에서는 특히 개인정보, 로그인, 권한 관리, 결제 기능을 조심해야 합니다.

"바로 만들지 말고 먼저 질문해줘"라는 한 문장

AI에게 질문하게 만드는 가장 중요한 문장은 의외로 간단합니다.

내 요청에 부족한 정보가 있으면 바로 만들지 말고, 먼저 확인 질문을 해줘.
추측해서 결정하지 말고, 선택지가 있다면 장단점을 함께 설명한 뒤 나에게 고르게 해줘.

이 문장을 첫 프롬프트 맨 아래에 붙이면 AI의 태도가 달라집니다. 물론 모든 AI가 항상 완벽하게 따르는 것은 아닙니다. 그래도 이 문장이 있으면 AI가 무리하게 추측하는 비율을 줄일 수 있습니다.

예를 들어 이렇게 쓸 수 있습니다.

나는 개인용 독서 기록 웹앱을 만들고 싶어.
책 제목, 저자, 읽은 날짜, 한 줄 감상을 입력하고 목록으로 볼 수 있으면 돼.
처음 버전은 MVP로 작게 만들어줘.

단, 내 요청에 부족한 정보가 있으면 바로 만들지 말고 먼저 확인 질문을 해줘.
특히 저장 방식, 모바일 사용 여부, 삭제 기능의 필요 여부는 네가 먼저 물어봐줘.
추측해서 기능을 넣지 말고, 내가 답한 뒤에 만들어줘.

이 프롬프트의 핵심은 "만들어줘"보다 "물어봐줘"입니다. 바이브 코딩은 AI에게 일을 던져놓는 방식이 아닙니다. 내가 원하는 것을 AI가 이해하도록 함께 맞춰가는 방식입니다.

AI가 확인해야 할 세 가지 큰 질문

초보자가 앱을 만들 때 가장 자주 빠뜨리는 질문이 있습니다. 바로 누가 쓰는지, 무엇이 가장 중요한지, 어디에 저장할지입니다. 이 세 가지가 불명확하면 앱은 그럴듯해 보여도 실제로 쓰기 어려워집니다.

첫째, 사용자 유형입니다. 같은 예약 문의 앱이라도 미용실 사장님이 쓰는 앱과 1인 상담사가 쓰는 앱은 다릅니다. 미용실은 날짜, 시간, 시술 종류가 중요하고, 상담사는 문의 내용과 연락 가능 시간이 중요할 수 있습니다.

둘째, 기능 우선순위입니다. 할 일 관리 앱에 달력, 알림, 반복 일정, 팀 공유, 파일 첨부까지 넣고 싶을 수 있습니다. 하지만 첫 버전에서는 할 일 추가, 완료 체크, 삭제 정도면 충분합니다. 우선순위가 없으면 AI는 기능을 많이 넣는 쪽으로 흐르기 쉽습니다.

셋째, 데이터 저장 방식입니다. 입력한 내용이 새로고침 후 사라져도 되는 연습용 앱인지, 여러 사람이 제출한 내용을 계속 보관해야 하는 운영용 앱인지에 따라 구조가 달라집니다. 강의 후기 수집 앱이나 예약 문의 앱처럼 다른 사람의 입력을 받는 앱은 저장 방식을 더 신중히 물어봐야 합니다.

아래 프롬프트는 이 세 가지를 AI가 먼저 확인하도록 만드는 기본형입니다.

아래 앱을 만들기 전에 먼저 나에게 질문해줘.

앱 아이디어: [만들고 싶은 앱 이름]
대략적인 목적: [앱을 만드는 이유]

바로 코드를 만들거나 화면을 구성하지 말고, 다음 항목을 확인하는 질문을 먼저 해줘.
1. 이 앱을 주로 누가 쓰는지
2. 첫 버전에 꼭 필요한 기능 3개가 무엇인지
3. 나중으로 미뤄도 되는 기능이 무엇인지
4. 입력한 데이터를 어디에 저장해야 하는지
5. 모바일에서 주로 쓸 앱인지
6. 개인정보나 민감한 정보를 다루는지
7. 배포해서 다른 사람에게 공유할 계획이 있는지

질문은 한 번에 너무 많이 하지 말고, 초보자가 답하기 쉽게 선택지와 예시를 함께 제시해줘.

이 프롬프트를 쓰면 AI는 앱 제작자가 아니라 기획 코치처럼 움직이기 시작합니다. 처음부터 화면을 만들기보다, 앱의 방향을 정리하는 대화가 먼저 열립니다.

예시 1: 예약 문의 앱에서 먼저 물어보게 하기

예약 문의 앱은 초보자가 만들기 좋은 주제입니다. 하지만 동시에 조심할 점도 있습니다. 이름, 연락처, 날짜, 시간, 문의 내용처럼 개인정보가 들어갈 수 있기 때문입니다.

만약 이렇게만 요청하면 어떨까요?

필라테스 예약 문의 앱 만들어줘.

AI는 아마 예약 폼을 만들어줄 것입니다. 이름, 전화번호, 날짜, 시간, 요청사항을 넣을 수도 있습니다. 하지만 중요한 질문이 빠져 있습니다. 실제 예약 확정까지 앱에서 처리할 것인지, 단순 문의만 받을 것인지, 관리자가 어떻게 확인할 것인지, 개인정보 안내 문구가 필요한지 같은 내용입니다.

더 좋은 프롬프트는 다음과 같습니다.

필라테스 스튜디오에서 사용할 예약 문의 웹앱을 만들고 싶어.
아직 실제 결제나 예약 확정 기능은 넣지 않고, 첫 버전은 문의 접수용 MVP로 만들고 싶어.

바로 만들지 말고 먼저 질문해줘.
특히 아래 항목을 확인해줘.
1. 고객이 입력해야 할 정보가 무엇인지
2. 연락처를 받을 때 개인정보 안내 문구가 필요한지
3. 예약 확정 기능은 제외해도 되는지
4. 관리자가 문의 목록을 어디에서 확인할지
5. 모바일에서 고객이 작성하기 쉽게 하려면 어떤 화면 구성이 좋은지

내가 답하기 쉽도록 선택지를 제시해줘.
예를 들어 저장 방식은 '브라우저 임시 저장', '관리자 화면에 목록 표시', '나중에 데이터베이스 연결'처럼 단계별로 설명해줘.

이렇게 말하면 AI가 예약 시스템을 과하게 만들 가능성이 줄어듭니다. 첫 버전이 문의 접수용인지, 실제 예약 관리용인지 먼저 나누기 때문입니다.

예시 2: 회의록 정리 앱에서 우선순위 확인하기

회의록 정리 앱은 직장인에게 매력적인 주제입니다. 회의 내용을 붙여넣으면 핵심 안건, 결정사항, 할 일을 정리해주는 앱을 떠올릴 수 있습니다. 하지만 여기에는 AI 기능, 데이터 저장, 회사 정보 보안 문제가 얽힐 수 있습니다.

처음부터 "회의록 자동 정리 앱 만들어줘"라고 하면 AI가 멋진 화면을 만들 수는 있습니다. 그러나 실제 업무에서 쓰려면 이런 질문이 필요합니다.

회의록 정리 앱을 만들고 싶어.
회의 내용을 붙여넣으면 핵심 안건, 결정사항, 담당자별 할 일을 정리해주는 앱이야.

바로 구현하지 말고 먼저 나에게 확인 질문을 해줘.
특히 다음을 확인해줘.
1. 회의 내용이 앱 안에 저장되어야 하는지, 아니면 정리 결과만 보여주고 저장하지 않아도 되는지
2. 회사 내부 정보나 개인정보가 포함될 수 있는지
3. AI 요약 기능을 실제 API로 연결할지, 아니면 첫 버전에서는 예시 화면과 수동 입력 흐름만 만들지
4. 결과를 복사할 수 있는 버튼이 필요한지
5. 모바일보다 PC에서 주로 쓸 것인지

초보자가 이해할 수 있게 각 선택지의 장단점을 간단히 설명해줘.
내 답변을 받은 뒤 MVP 범위로 다시 정리해줘.

여기서 중요한 문장은 "첫 버전에서는 예시 화면과 수동 입력 흐름만 만들지"입니다. AI 요약 기능은 매력적이지만, API 키와 비용, 보안, 정확도 문제가 생길 수 있습니다. 처음에는 화면과 흐름부터 만든 뒤, 나중에 AI 기능을 붙이는 편이 안전합니다.

예시 3: 가족 일정 공유 앱에서 사용자와 권한 확인하기

가족 일정 공유 앱도 좋아 보입니다. 부모, 자녀, 배우자가 서로 일정을 확인하고 메모를 남길 수 있으면 편리합니다. 하지만 여기에는 로그인, 권한 관리, 가족 구성원 초대 같은 어려운 기능이 숨어 있습니다.

초보 단계에서는 실제 가족 계정 시스템을 만들기보다, 먼저 간단한 일정표 MVP로 시작하는 것이 좋습니다. 이때 AI에게 이렇게 질문하게 만들 수 있습니다.

가족 일정 공유 앱을 만들고 싶어.
가족 구성원이 병원 예약, 학교 행사, 여행 일정, 장보기 메모를 함께 확인하는 앱이야.

바로 만들지 말고 먼저 질문해줘.
특히 아래 내용을 확인해줘.
1. 첫 버전에서 로그인 없이 하나의 공유 일정표로 시작해도 되는지
2. 가족 구성원별 색상 표시가 필요한지
3. 일정에 포함할 정보는 제목, 날짜, 시간, 담당자, 메모 중 무엇인지
4. 삭제나 수정은 누구나 할 수 있게 할지, 관리자만 하게 할지
5. 실제 공유 링크로 배포할 계획이 있는지
6. 자녀 이름, 학교, 병원 정보처럼 민감한 정보가 들어갈 수 있는지

내가 초보자라는 전제로, 어려운 기능과 쉬운 기능을 구분해서 설명해줘.
로그인, 권한 관리, 알림 기능은 첫 버전에서 제외하는 방향도 제안해줘.

이 프롬프트는 AI에게 중요한 신호를 줍니다. "나는 가족 일정 앱을 원하지만, 로그인과 권한 관리까지 당장 만들고 싶은 것은 아니다"라는 신호입니다. 유명한 도구가 초보자에게 쉬운 도구는 아니듯, 멋진 기능이 첫 앱에 좋은 기능인 것도 아닙니다.

질문을 잘하게 만드는 프롬프트 공식

AI에게 질문하게 만드는 프롬프트는 다음 순서로 쓰면 좋습니다.

1. 만들고 싶은 앱을 한두 문장으로 설명합니다.

2. 아직 확정하지 않은 부분이 있다고 말합니다.

3. 바로 만들지 말고 먼저 질문하라고 요청합니다.

4. 반드시 확인해야 할 항목을 지정합니다.

5. 선택지와 장단점을 함께 달라고 요청합니다.

6. 답변을 받은 뒤 MVP로 정리해달라고 요청합니다.

이 구조를 하나의 템플릿으로 만들면 다음과 같습니다.

나는 [사용자/상황]을 위한 [앱 이름]을 만들고 싶어.
이 앱의 목적은 [해결하고 싶은 문제]야.

아직 요구사항이 완전히 정리되지 않았으니, 바로 만들지 말고 먼저 나에게 질문해줘.
추측해서 기능을 넣지 말고, 선택지가 필요한 부분은 장단점을 설명한 뒤 내가 고르게 해줘.

특히 아래 항목을 확인해줘.
1. 주 사용자는 누구인지
2. 첫 버전에 꼭 필요한 기능 3개는 무엇인지
3. 처음 버전에서 제외할 기능은 무엇인지
4. 사용자가 입력해야 하는 정보는 무엇인지
5. 결과로 보여줘야 하는 정보는 무엇인지
6. 데이터 저장 방식은 어떻게 할지
7. 모바일에서 주로 사용할지 PC에서 주로 사용할지
8. 개인정보나 민감한 정보가 포함되는지
9. 배포해서 다른 사람에게 공유할지

질문은 초보자가 답하기 쉽게 해줘.
각 질문마다 예시 답변을 함께 제시해줘.
내가 답하면 그 내용을 바탕으로 MVP 기획서와 첫 생성 프롬프트를 만들어줘.

이 템플릿은 Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구를 사용할 때 특히 유용합니다. v0처럼 화면을 먼저 만드는 도구에서도 사용할 수 있고, Google AI Studio Build mode처럼 AI 기능을 붙이는 단계에서도 도움이 됩니다. 다만 Claude Code, Codex, Cursor 같은 개발자형 도구에서는 코드베이스, 파일 구조, 테스트 방식 같은 질문이 추가될 수 있습니다. 완전 초보자라면 처음부터 개발자형 도구로 들어가기보다 앱 빌더형 도구에서 이 질문 습관을 먼저 익히는 편이 좋습니다.

기능 우선순위를 AI가 묻게 만들기

초보자는 기능을 많이 넣을수록 좋은 앱이 된다고 생각하기 쉽습니다. 하지만 첫 앱에서는 반대입니다. 기능이 많아질수록 AI가 실수할 지점도 많아집니다. 그래서 기능 추가 전에 AI가 우선순위를 묻게 해야 합니다.

다음 프롬프트를 사용해보세요.

내가 말한 기능을 모두 한 번에 만들지 말고, 먼저 우선순위를 정리해줘.

앱 이름: [앱 이름]
넣고 싶은 기능:
- [기능 1]
- [기능 2]
- [기능 3]
- [기능 4]
- [기능 5]

너는 먼저 아래 기준으로 기능을 분류해줘.
1. 첫 MVP에 꼭 필요한 기능
2. 있으면 좋지만 나중에 추가해도 되는 기능
3. 초보자에게는 아직 어려울 수 있는 기능
4. 개인정보, 보안, 비용 문제가 생길 수 있는 기능

분류한 뒤 나에게 확인 질문을 해줘.
내가 승인하기 전에는 구현하지 마.

예를 들어 운동 루틴 기록 앱에 "운동 기록 저장, 주간 통계, 사진 업로드, 친구 공유, 유료 코칭 결제"를 넣고 싶다고 해봅시다. AI가 먼저 분류하게 하면 운동 기록 저장과 주간 통계는 MVP 후보가 되고, 사진 업로드와 친구 공유는 나중 기능, 유료 결제는 아직 어려운 기능으로 나눌 수 있습니다.

이렇게 하면 앱이 더 작아지는 것이 아니라 더 선명해집니다. 첫 앱은 완성도보다 작동 경험이 중요합니다.

데이터 저장 방식을 AI가 묻게 만들기

데이터 저장은 초보자가 가장 자주 놓치는 부분입니다. 화면에서는 입력한 내용이 보이는데, 새로고침하면 사라질 수 있습니다. 내 컴퓨터에서는 보이는데 다른 사람에게 공유하면 보이지 않을 수도 있습니다. 이것은 앱이 망가진 것이 아니라, 저장 방식을 정하지 않았기 때문에 생기는 일일 수 있습니다.

AI에게 이렇게 요청해보세요.

이 앱을 만들기 전에 데이터 저장 방식을 먼저 확인해줘.

앱 설명: [앱 설명]
사용자가 입력하는 정보: [입력 정보]
이 앱을 사용할 사람: [나 혼자 / 팀원 몇 명 / 불특정 다수]

다음 저장 방식 중 어떤 것이 적절한지 질문과 함께 설명해줘.
1. 저장 없이 화면에서만 테스트
2. 브라우저 로컬 저장
3. 간단한 데이터베이스 저장
4. 로그인 후 사용자별 저장

각 방식의 장단점을 초보자도 이해할 수 있게 설명해줘.
특히 새로고침, 다른 기기 사용, 여러 사람 공유, 개인정보 측면에서 무엇이 달라지는지 알려줘.
내가 선택하기 전에는 구현하지 마.

로컬 저장은 내 브라우저 안에 적는 작은 메모장과 비슷합니다. 간단하고 빠르지만, 다른 기기에서는 보이지 않을 수 있습니다. 데이터베이스 저장은 공동 장부에 적는 것과 비슷합니다. 여러 사람이 함께 보기 좋지만 설정과 보안이 더 중요해집니다.

초보 단계에서는 저장 방식을 무조건 어렵게 갈 필요가 없습니다. 개인용 독서 기록 앱이나 프롬프트 보관함 앱은 로컬 저장으로 시작해도 됩니다. 반면 강의 후기 수집 앱, 예약 문의 앱, 가족 일정 공유 앱처럼 다른 사람이 입력하거나 함께 봐야 하는 앱은 저장 방식을 더 신중히 정해야 합니다.

보안, 모바일, 배포를 AI가 점검하게 하기

초보자는 기능이 작동하면 앱이 끝났다고 느끼기 쉽습니다. 하지만 누군가에게 공유하기 전에는 최소한 세 가지를 확인해야 합니다. 보안, 모바일, 배포입니다.

보안은 겁먹으라는 뜻이 아닙니다. 이름, 전화번호, 이메일, 주소, 건강 정보, 자녀 정보처럼 조심해야 할 정보를 과하게 받지 않는지 확인하자는 뜻입니다. 모바일은 실제 사용자가 휴대폰으로 접속했을 때 입력창과 버튼이 불편하지 않은지 보는 일입니다. 배포는 가게 문을 여는 것과 같습니다. 내 컴퓨터 안에서만 보이는 앱이 아니라, 다른 사람이 링크로 들어올 수 있게 하는 과정입니다.

다음 프롬프트를 앱 완성 직전에 붙여보세요.

이 앱을 배포하거나 다른 사람에게 공유하기 전에 점검해줘.
바로 수정하지 말고 먼저 문제 가능성을 목록으로 알려줘.

점검 항목:
1. 개인정보를 과하게 수집하고 있지 않은지
2. 전화번호, 이메일, 이름 같은 정보가 필요 이상으로 노출되지 않는지
3. API 키나 비밀값이 화면이나 코드에 드러나지 않는지
4. 모바일 화면에서 버튼, 입력창, 목록이 사용하기 쉬운지
5. 삭제 버튼에 실수 방지 확인 절차가 있는지
6. 사용자가 앱의 목적과 사용법을 첫 화면에서 이해할 수 있는지
7. 공유 링크로 접속했을 때 의도한 화면이 보이는지
8. 무료 플랜이나 배포 환경의 제한 때문에 문제가 생길 수 있는지

각 항목에 대해 '괜찮음 / 확인 필요 / 수정 권장'으로 나눠서 알려줘.
수정 권장 항목은 초보자가 이해할 수 있는 말로 이유를 설명해줘.

이 프롬프트는 앱의 품질을 높이는 데 매우 효과적입니다. 특히 예약 문의 앱, 강의 후기 수집 앱, 가족 일정 공유 앱처럼 다른 사람이 입력하는 앱에서는 거의 필수로 사용하는 습관을 들이는 것이 좋습니다.

AI에게 질문을 너무 많이 시키면 생기는 문제

여기서 한 가지 현실적인 주의가 필요합니다. AI에게 질문하게 만드는 것은 좋지만, 처음부터 질문을 30개씩 받으면 오히려 지칩니다. 초보자는 질문 폭탄을 맞으면 앱을 만들기도 전에 포기하게 됩니다.

그래서 질문에도 순서가 필요합니다. 처음에는 가장 중요한 질문 5개 정도면 충분합니다. 앱의 목적, 사용자, 핵심 기능, 저장 방식, 공유 여부만 확인해도 첫 MVP 방향은 잡힙니다. 그다음 디자인, 통계, 알림, 로그인 같은 세부 기능은 나중에 대화하면서 정하면 됩니다.

다음처럼 질문 개수를 제한할 수 있습니다.

먼저 가장 중요한 질문 5개만 해줘.
내가 답하면 그다음 단계에서 추가 질문을 해줘.
처음부터 모든 세부사항을 묻지 말고, MVP를 정하는 데 꼭 필요한 질문만 골라줘.

이 문장은 매우 유용합니다. AI가 지나치게 꼼꼼한 기획자처럼 변하는 것을 막아줍니다. 바이브 코딩은 한 번에 완벽한 문서를 쓰는 일이 아니라, 만들고 확인하고 고쳐나가는 과정입니다.

질문과 확인으로 이어가는 대화 예시

아래는 AI와 실제로 대화하는 흐름의 예입니다. 앱 주제는 블로그 글감 저장소입니다.

나: 블로그 글감 저장소 앱을 만들고 싶어. 바로 만들지 말고 먼저 가장 중요한 질문 5개만 해줘.

AI가 이렇게 물어볼 수 있습니다.

AI: 좋습니다. 먼저 아래 5가지만 확인할게요.
1. 이 앱은 본인만 쓰나요, 여러 명이 함께 쓰나요?
2. 글감에 어떤 정보를 저장하고 싶나요? 예: 제목, 카테고리, 메모, 참고 링크, 상태
3. 저장한 글감을 검색하거나 필터링해야 하나요?
4. 새로고침 후에도 데이터가 남아야 하나요?
5. 모바일에서 주로 사용할 예정인가요?

사용자는 이렇게 답할 수 있습니다.

나: 나 혼자 쓸 앱이야. 제목, 카테고리, 메모, 참고 링크, 작성 상태를 저장하고 싶어.
검색은 필요하고, 필터는 나중에 추가해도 돼. 새로고침 후에도 데이터가 남았으면 좋겠어.
모바일에서도 자주 쓸 것 같아.

이제 AI에게 다음 단계를 요청합니다.

내 답변을 바탕으로 첫 MVP 범위를 정리해줘.
꼭 필요한 기능과 나중에 추가할 기능을 나눠줘.
그다음 앱 빌더에 넣을 첫 생성 프롬프트를 만들어줘.

이 흐름은 단순하지만 강력합니다. 처음부터 긴 프롬프트를 완벽하게 쓰지 못해도 괜찮습니다. AI가 질문하게 만들고, 내가 답하고, 다시 정리하게 하면 됩니다.

초보자가 자주 하는 실수

AI에게 질문하게 만드는 단계에서도 흔한 실수가 있습니다.

첫 번째 실수는 "질문해줘"라고만 말하고 무엇을 질문해야 하는지 지정하지 않는 것입니다. 그러면 AI가 너무 일반적인 질문을 하거나, 반대로 중요하지 않은 세부사항을 물어볼 수 있습니다. "사용자, 핵심 기능, 저장 방식, 모바일, 개인정보를 먼저 확인해줘"처럼 질문 범위를 지정하는 편이 좋습니다.

두 번째 실수는 AI의 질문에 너무 길게 답하려고 하는 것입니다. 답변은 짧아도 됩니다. "나 혼자 쓸 앱", "모바일 중심", "로그인 제외", "로컬 저장으로 시작"처럼 간단히 답해도 충분합니다.

세 번째 실수는 AI가 제안한 기능을 모두 받아들이는 것입니다. AI는 친절하게 많은 기능을 제안할 수 있습니다. 하지만 첫 앱에서는 줄이는 능력이 더 중요합니다. "이번 버전에서는 제외해줘"라는 말을 자주 써도 괜찮습니다.

네 번째 실수는 보안과 개인정보 질문을 건너뛰는 것입니다. 이름과 연락처를 받는 순간 앱은 단순한 장난감에서 조금 더 조심해야 하는 도구가 됩니다. 초보자일수록 "이 앱이 개인정보를 다루는지 먼저 확인해줘"라고 말하는 습관이 필요합니다.

고치는 방법: AI를 기획 파트너로 세우기

AI가 자꾸 추측해서 만들거나, 원하지 않는 기능을 넣거나, 너무 복잡하게 확장한다면 다음 프롬프트로 대화를 다시 정리해보세요.

지금 방향이 조금 복잡해진 것 같아.
바로 구현하지 말고, 현재 앱 요구사항을 다시 정리해줘.

다음 형식으로 나눠줘.
1. 내가 확정한 요구사항
2. 아직 확인이 필요한 요구사항
3. 첫 MVP에 넣을 기능
4. 이번 버전에서 제외할 기능
5. 보안이나 개인정보 측면에서 조심할 점
6. 다음에 나에게 물어봐야 할 질문 3개

정리만 하고, 내가 승인하기 전에는 수정하지 마.

이 프롬프트는 대화가 꼬였을 때 특히 좋습니다. AI가 만든 결과물이 마음에 들지 않을 때 무작정 되돌리기보다, 먼저 생각을 정리하게 만드는 방식입니다.

또 하나의 유용한 문장은 이것입니다.

내가 초보자라는 전제로 설명해줘.
어려운 개발 용어를 쓰면 바로 옆에 쉬운 비유를 붙여줘.

이 문장을 넣으면 AI가 갑자기 데이터베이스 스키마, 인증 플로우, 서버리스 함수 같은 말을 늘어놓는 상황을 줄일 수 있습니다. 물론 이런 개념은 나중에 필요할 수 있습니다. 하지만 처음부터 전부 알 필요는 없습니다. 지금 필요한 것은 작은 앱을 만들고, 작동을 확인하고, 조금씩 고쳐나가는 감각입니다.

바로 써먹는 질문 유도 프롬프트 모음

아래 프롬프트들은 그대로 복사해서 사용할 수 있습니다. 대괄호 안만 자신의 상황에 맞게 바꾸면 됩니다.

첫 제작 전 질문 유도

나는 [누구]를 위한 [앱 이름]을 만들고 싶어.
목적은 [해결하고 싶은 문제]야.

바로 만들지 말고 먼저 질문해줘.
요구사항이 불명확한 부분은 추측하지 말고 나에게 확인해줘.
특히 사용자, 핵심 기능, 저장 방식, 모바일 사용 여부, 개인정보 여부를 먼저 확인해줘.
질문은 초보자가 답하기 쉽게 선택지와 예시를 포함해줘.

기능 추가 전 질문 유도

이 앱에 [추가하고 싶은 기능]을 넣고 싶어.
바로 추가하지 말고 먼저 확인 질문을 해줘.

다음 항목을 검토해줘.
1. 이 기능이 첫 MVP에 꼭 필요한지
2. 기존 기능과 충돌할 가능성이 있는지
3. 데이터 저장 방식이 바뀌어야 하는지
4. 모바일 화면이 복잡해지지 않는지
5. 보안이나 개인정보 문제가 생기지 않는지

검토 후 '지금 추가 추천 / 나중에 추가 추천 / 추가 비추천' 중 하나로 의견을 줘.

디자인 변경 전 질문 유도

이 앱의 디자인을 [원하는 분위기]로 바꾸고 싶어.
바로 수정하지 말고 먼저 질문해줘.

확인할 내용:
1. 주 사용자가 누구인지
2. 모바일 우선인지 PC 우선인지
3. 더 중요하게 보여야 할 정보가 무엇인지
4. 버튼과 입력창은 얼마나 크게 보여야 하는지
5. 색상 분위기는 차분한지, 밝은지, 전문적인지

내 답변을 받은 뒤 디자인 수정 방향을 3가지로 제안해줘.

오류 수정 전 질문 유도

앱에서 문제가 생겼어.
바로 고치려고 하지 말고, 먼저 원인을 파악하기 위한 질문을 해줘.

문제 상황:
[어떤 화면에서]
[무엇을 클릭하거나 입력했을 때]
[어떤 결과가 나왔는지]
[원래 기대한 결과는 무엇인지]

너는 먼저 추가로 필요한 정보를 질문해줘.
그다음 가능한 원인을 2~3개로 나눠 설명하고, 가장 안전한 수정 순서를 제안해줘.
내가 승인하기 전에는 코드를 바꾸지 마.

배포 전 점검 질문 유도

이 앱을 다른 사람에게 공유하기 전에 점검하고 싶어.
바로 수정하지 말고 먼저 확인 질문을 해줘.

특히 아래를 확인해줘.
1. 누구에게 공유할 앱인지
2. 개인정보를 입력받는지
3. 모바일에서 주로 사용할지
4. 로그인 없이 공개해도 되는지
5. 데이터가 저장되는 위치를 알고 있는지
6. 무료 플랜 제한 때문에 문제가 생길 수 있는지

내 답변을 바탕으로 배포 전 체크리스트를 만들어줘.

AI가 너무 앞서갈 때 멈추는 프롬프트

잠깐 멈춰줘.
지금은 구현하지 말고 질문과 정리만 해줘.
내가 확정하지 않은 기능을 추측해서 추가하지 마.

현재까지의 내용을 바탕으로
1. 확정된 것
2. 미정인 것
3. 질문이 필요한 것
4. 이번 버전에서 제외할 것
을 정리해줘.

실습 미션: 내 앱에 질문 목록 붙이기

이번 장의 실습은 앱을 새로 만드는 것이 아닙니다. 이미 만들었거나 만들고 싶은 앱 하나를 골라, AI가 먼저 물어보게 만드는 질문 유도 프롬프트를 작성해보는 것입니다.

먼저 앱 하나를 고르세요. 독서 기록 앱, 할 일 관리 앱, 강의 후기 수집 앱, 예약 문의 앱, 운동 루틴 기록 앱, 블로그 글감 저장소 앱, AI 프롬프트 보관함 앱 중 하나면 충분합니다.

그다음 아래 형식으로 적어보세요.

내가 만들 앱: [앱 이름]
이 앱을 쓰는 사람: [사용자]
앱의 목적: [해결할 문제]
아직 확실하지 않은 것: [예: 저장 방식, 모바일 사용 여부, 삭제 기능]

바로 만들지 말고 먼저 질문해줘.
특히 내가 아직 확실하지 않은 부분을 추측하지 말고 확인해줘.
질문은 가장 중요한 것 5개만 해줘.
내가 답하면 첫 MVP 범위와 생성 프롬프트를 만들어줘.

가능하다면 같은 앱으로 두 번 실험해보세요. 한 번은 "그냥 만들어줘"라고 요청하고, 다른 한 번은 "먼저 질문해줘"라고 요청합니다. 결과를 비교하면 차이가 분명히 보일 것입니다. 질문을 먼저 받은 쪽이 대체로 기능 범위가 선명하고, 나중에 수정하기도 쉽습니다.

한 장 요약

AI는 빈칸을 보면 그럴듯하게 채우려고 합니다. 그래서 바이브 코딩에서는 AI가 추측하기 전에 질문하게 만드는 습관이 중요합니다.

좋은 AI 협업은 명령이 아니라 질문과 확인으로 시작됩니다. "바로 만들지 말고 먼저 질문해줘", "추측하지 말고 선택지와 장단점을 알려줘", "내가 승인하기 전에는 구현하지 마" 같은 문장은 앱의 방향을 지키는 안전장치입니다.

특히 초보자는 사용자 유형, 기능 우선순위, 데이터 저장 방식, 개인정보, 모바일, 배포 여부를 AI가 먼저 확인하게 해야 합니다. 이 과정을 거치면 앱은 더 작아질 수 있지만, 오히려 더 쓸모 있어집니다.

바이브 코딩은 한 번에 완벽한 앱을 만드는 기술이 아닙니다. 내가 원하는 것을 설명하고, AI가 질문하고, 내가 답하고, 다시 정리하고, 조금씩 고쳐나가는 대화의 기술입니다. 다음 장에서는 이 흐름을 이어서, AI에게 앱의 문제점을 점검하게 하고 MVP 범위를 더 작게 줄이는 프롬프트를 다룹니다.