점검 프롬프트와 MVP 줄이기 프롬프트

기능을 더 넣기 전에, 잠깐 멈춰야 할 때

앱을 하나 만들고 나면 이상한 욕심이 생깁니다. 처음에는 "독서 기록만 되면 좋겠다"고 시작했는데, 어느새 검색, 통계, 달력, 태그, 로그인, 공유, 추천, 알림까지 떠오릅니다. 할 일 관리 앱도 마찬가지입니다. 처음에는 할 일을 적고 완료 표시만 하면 충분했는데, 만들다 보면 우선순위, 마감일, 프로젝트, 반복 일정, 팀 공유, 알림, 칸반 보드까지 넣고 싶어집니다.

이 마음은 아주 자연스럽습니다. 내가 만든 앱이 조금씩 그럴듯해지면 "이왕이면 이것도"라는 생각이 따라옵니다. 하지만 첫 앱에서는 바로 이 순간이 위험합니다. 기능이 많아질수록 앱이 좋아지는 것이 아니라, 오히려 사용자가 어디를 눌러야 할지 모르는 앱이 될 수 있기 때문입니다.

좋은 앱은 기능이 많은 앱이 아닙니다. 좋은 앱은 사용자가 헷갈리지 않고 자기 일을 끝낼 수 있는 앱입니다.

바이브 코딩에서는 AI가 기능을 빠르게 붙여주기 때문에 더 조심해야 합니다. 버튼 하나 추가하는 일이 너무 쉬워 보이고, 화면 하나 더 만드는 일도 몇 문장으로 가능해 보입니다. 하지만 만들기 쉬운 것과 쓰기 쉬운 것은 다릅니다. 초보자가 가장 먼저 배워야 할 감각은 "무엇을 더 넣을까?"가 아니라 "무엇을 빼야 할까?"입니다.

이번 장에서는 만든 앱을 배포하거나 공유하기 전에 AI에게 점검을 맡기는 방법을 배웁니다. 앱의 문제점, 초보자 사용성, 모바일 화면, 개인정보 위험 요소를 확인하고, 필요하면 기능을 과감히 줄여 MVP, 즉 첫 작동 버전으로 다시 정리하는 프롬프트를 다룹니다.

점검 프롬프트는 앱의 건강검진이다

앱을 만든 뒤 바로 공유하고 싶을 수 있습니다. 하지만 병원에서 건강검진을 받듯이, 앱도 한 번쯤 점검을 받아야 합니다. 여기서 말하는 점검은 개발자처럼 코드를 한 줄씩 분석하는 일이 아닙니다. 초보자 입장에서는 다음 질문에 답하는 것만으로도 충분히 큰 도움이 됩니다.

이 앱을 처음 보는 사람이 무엇을 해야 하는지 바로 알 수 있는가? 모바일 화면에서도 버튼이 잘 보이는가? 입력 항목이 너무 많지는 않은가? 개인정보를 불필요하게 받고 있지는 않은가? 삭제 버튼을 실수로 눌렀을 때 되돌릴 방법이 있는가?

AI에게 점검을 요청할 때는 막연히 "검토해줘"라고만 말하면 결과도 막연합니다. AI는 친절한 말투로 "전반적으로 좋아 보입니다"라고 답할 수도 있습니다. 우리가 필요한 것은 칭찬이 아니라 개선점입니다. 그래서 점검 프롬프트에는 관점이 들어가야 합니다.

예를 들어 같은 앱이라도 직장인이 업무 중에 쓰는 앱인지, 강사가 수강생 후기를 받는 앱인지, 가족끼리 일정을 공유하는 앱인지에 따라 점검 기준이 달라집니다. 예약 문의 앱이라면 개인정보와 관리자 확인 흐름이 중요하고, 블로그 글감 저장소 앱이라면 검색과 분류가 더 중요합니다. 운동 루틴 기록 앱이라면 모바일 입력 편의성이 중요합니다.

점검 프롬프트는 앱을 비난하기 위한 도구가 아닙니다. 내가 미처 보지 못한 구멍을 찾는 도구입니다.

첫 번째 점검: 이 앱의 문제점을 찾아달라고 요청하기

가장 기본적인 점검은 "이 앱의 문제점을 찾아줘"입니다. 다만 여기서도 중요한 것은 사용자의 입장에서 봐달라고 요청하는 것입니다. 개발자 관점의 점검은 너무 어렵게 흘러갈 수 있습니다. 초보자의 첫 앱에서는 화면 흐름, 기능 중복, 입력 항목, 안내 문구, 버튼 이름 같은 요소가 더 중요합니다.

다음 프롬프트는 어떤 앱에도 거의 그대로 사용할 수 있습니다.

내가 만든 앱을 출시 전 점검해줘.

앱 설명:
- 앱 이름: [앱 이름]
- 사용 대상: [예: 독서 기록을 남기고 싶은 개인 사용자]
- 앱의 목적: [예: 읽은 책과 감상을 간단히 기록하는 것]
- 주요 기능: [현재 들어간 기능을 번호로 작성]

점검 관점:
1. 처음 보는 사용자가 사용법을 바로 이해할 수 있는지
2. 화면이나 버튼이 너무 많아 헷갈리지 않는지
3. 입력 항목이 과하게 많지 않은지
4. 중복되거나 없어도 되는 기능이 있는지
5. 첫 버전 MVP에 꼭 필요하지 않은 기능이 있는지

결과는 다음 형식으로 정리해줘.
- 가장 큰 문제 3가지
- 바로 고치면 좋은 부분 5가지
- 첫 버전에서 빼도 되는 기능
- 사용자에게 더 친절하게 바꿀 문구
- 수정 우선순위

코드를 바로 고치기 전에 먼저 진단만 해줘.

마지막 문장인 "코드를 바로 고치기 전에 먼저 진단만 해줘"가 중요합니다. 이전 장에서 배운 것처럼 AI가 질문 없이 바로 고쳐버리면, 의도하지 않은 부분까지 바뀔 수 있습니다. 점검 단계에서는 고치기보다 보는 것이 먼저입니다.

예를 들어 독서 기록 앱을 점검하면 AI는 "별점, 태그, 독서 상태, 완독일, 메모, 인용문, 표지 이미지까지 모두 입력하게 되어 있어 첫 사용자에게 부담스럽다"고 말할 수 있습니다. 이때 우리는 모든 제안을 다 받아들일 필요는 없습니다. 다만 "아, 첫 화면에서 입력칸이 너무 많구나"라는 사실을 알게 됩니다.

할 일 관리 앱이라면 "추가 버튼과 저장 버튼이 둘 다 있어서 사용자가 무엇을 눌러야 할지 헷갈릴 수 있다"는 점검이 나올 수 있습니다. 강의 후기 수집 앱이라면 "이름, 전화번호, 이메일을 모두 받는 것은 후기 수집 목적에 비해 과하다"는 피드백이 나올 수 있습니다.

이런 점검은 초보자에게 특히 유용합니다. 만든 사람은 자기 앱을 이미 알고 있기 때문에 불편함을 잘 못 봅니다. 하지만 처음 보는 사람은 작은 문구 하나에도 막힙니다. AI를 잠깐 '처음 보는 사용자' 역할로 세워두면, 내가 놓친 부분이 보이기 시작합니다.

두 번째 점검: 초보자 사용성 확인하기

초보자 사용성은 말 그대로 처음 쓰는 사람이 어렵지 않게 쓸 수 있는지를 보는 기준입니다. 여기서 초보자는 코딩 초보자가 아니라 앱 사용자 초보자입니다. 앱을 만든 나는 버튼의 의미를 알지만, 사용자는 모릅니다. 나는 "상태값"이라는 말이 익숙해졌을 수 있지만, 사용자는 "진행 중인지 완료인지 선택하세요"라는 말이 더 편합니다.

사용성은 식당으로 비유하면 동선입니다. 음식이 맛있어도 입구가 어디인지 모르고, 주문 방법이 복잡하고, 결제 위치가 헷갈리면 손님은 피곤해집니다. 앱도 마찬가지입니다. 기능이 좋아도 첫 화면에서 무엇을 해야 하는지 보이지 않으면 사용자는 나갑니다.

초보자 사용성 점검 프롬프트는 이렇게 쓸 수 있습니다.

이 앱을 처음 사용하는 사람의 입장에서 사용성 점검을 해줘.

앱 설명:
[앱의 목적과 현재 기능을 간단히 설명]

사용자는 개발 지식이 없고, 이 앱을 처음 봅니다.
다음 기준으로 확인해줘.

1. 첫 화면에서 무엇을 해야 하는지 바로 알 수 있는가?
2. 버튼 이름이 이해하기 쉬운가?
3. 입력창 안내 문구가 충분한가?
4. 사용자가 실수하기 쉬운 지점은 어디인가?
5. 삭제, 저장, 제출 같은 중요한 행동이 명확한가?
6. 빈 화면일 때 무엇을 해야 하는지 안내가 있는가?
7. 완료 후 다음 행동을 알려주는가?

답변은 다음 형식으로 줘.
- 사용자가 헷갈릴 가능성이 높은 부분
- 더 쉬운 버튼 이름 제안
- 더 쉬운 안내 문구 제안
- 화면 흐름 개선 제안
- 초보자용으로 꼭 고쳐야 할 3가지

아직 코드는 수정하지 말고, 먼저 제안만 해줘.

이 프롬프트는 특히 수집형 앱에 좋습니다. 강의 후기 수집 앱, 예약 문의 앱, 문의 접수 앱처럼 다른 사람에게 링크를 보내서 입력하게 하는 앱은 사용자가 설명을 듣지 못한 상태에서 앱을 열 가능성이 큽니다. 그래서 첫 화면의 안내 문구가 중요합니다.

예를 들어 "제출"이라는 버튼보다 "후기 보내기"가 더 친절할 수 있습니다. "저장"보다 "내 기록에 추가하기"가 더 명확할 수 있습니다. "삭제" 버튼 옆에는 "정말 삭제할까요?" 같은 확인 단계가 필요할 수 있습니다.

빈 화면 안내도 중요합니다. 처음 앱을 열었을 때 목록이 비어 있으면 사용자는 오류라고 생각할 수 있습니다. 이럴 때 "아직 등록된 기록이 없습니다. 위 입력창에서 첫 기록을 추가해보세요."라는 문구 하나만 있어도 앱이 훨씬 친절해집니다.

세 번째 점검: 모바일에서 쓸 수 있는지 확인하기

초보자가 만든 첫 앱은 대부분 컴퓨터 화면에서 확인합니다. 그런데 실제 사용자는 휴대폰으로 열 가능성이 큽니다. 특히 운동 루틴 기록 앱, 가족 일정 공유 앱, 예약 문의 앱, 강의 후기 수집 앱은 모바일 사용 비중이 높습니다. 지하철에서 보고, 강의실에서 입력하고, 매장 앞에서 문의하고, 운동 직후에 기록하기 때문입니다.

반응형이라는 용어가 있습니다. 반응형은 화면 크기에 맞춰 앱의 배치가 자연스럽게 바뀌는 것을 말합니다. 식당 테이블 배치를 떠올리면 쉽습니다. 넓은 홀에서는 큰 테이블을 펼쳐도 되지만, 작은 방에서는 테이블을 접거나 배치를 바꿔야 합니다. 앱도 컴퓨터 화면에서는 가로로 넓게 보여도, 휴대폰에서는 세로로 보기 편하게 바뀌어야 합니다.

모바일 점검은 다음 프롬프트로 요청할 수 있습니다.

이 앱을 모바일 화면 기준으로 점검해줘.

앱 설명:
[앱 이름, 사용 대상, 주요 기능]

사용자는 주로 스마트폰으로 앱을 사용할 예정입니다.
다음 기준으로 문제점을 찾아줘.

1. 버튼이 손가락으로 누르기에 충분히 큰가?
2. 입력창이 너무 많아 스크롤이 길어지지 않는가?
3. 중요한 버튼이 화면 아래쪽에서 잘 보이는가?
4. 카드, 표, 목록이 작은 화면에서 깨지지 않는가?
5. 글자 크기가 너무 작지 않은가?
6. 한 줄에 너무 많은 정보가 들어가 있지 않은가?
7. 모바일에서는 숨기거나 줄여도 되는 정보가 있는가?

결과는 다음처럼 정리해줘.
- 모바일에서 가장 불편할 부분
- 줄여야 할 입력 항목
- 버튼과 글자 크기 개선 제안
- 목록 화면 개선 제안
- 모바일 우선 디자인으로 바꾸는 수정 프롬프트

코드를 바로 수정하지 말고 먼저 점검 결과를 알려줘.

모바일 앱에서 흔한 문제는 표입니다. 컴퓨터 화면에서는 이름, 날짜, 상태, 메모, 수정 버튼, 삭제 버튼을 한 줄에 보여줘도 괜찮습니다. 하지만 휴대폰에서는 가로폭이 좁아서 표가 깨지거나 글자가 지나치게 작아집니다. 이럴 때는 표보다 카드 형식이 좋습니다. 카드 형식은 하나의 기록을 작은 종이 카드처럼 세로로 보여주는 방식입니다.

예를 들어 예약 문의 앱의 목록 화면을 생각해보겠습니다. 컴퓨터에서는 "이름 / 연락처 / 희망 날짜 / 문의 내용 / 상태"를 표로 보여줄 수 있습니다. 모바일에서는 각 문의를 카드로 보여주고, 카드 안에 이름, 날짜, 상태만 먼저 보이게 한 뒤, 자세한 내용은 펼쳐보기로 처리하는 편이 낫습니다.

운동 루틴 기록 앱도 마찬가지입니다. 모바일에서 운동 직후 기록하려면 입력이 짧아야 합니다. 운동명, 세트 수, 반복 횟수, 무게, 메모, 운동 부위, 난이도, 컨디션을 모두 입력하게 하면 금방 귀찮아집니다. 첫 버전에서는 운동명, 세트 수, 메모 정도만 있어도 충분할 수 있습니다.

네 번째 점검: 개인정보 위험 요소 확인하기

바이브 코딩을 할 때 가장 조심해야 할 부분 중 하나가 개인정보입니다. 앱이 그럴듯하게 작동한다고 해서 아무 정보나 받아도 되는 것은 아닙니다. 이름, 전화번호, 이메일, 주소, 생년월일, 건강 정보, 결제 정보, 학생 정보, 고객 상담 내용은 모두 조심해서 다뤄야 합니다.

특히 초보자가 만든 앱에서는 "정말 이 정보를 받아야 하나?"를 먼저 물어야 합니다. 예약 문의 앱이라면 연락처가 필요할 수 있습니다. 하지만 강의 후기 수집 앱에서 전화번호까지 받을 필요는 없을 수 있습니다. 독서 기록 앱이 개인용이라면 로그인이나 실명 입력이 없어도 됩니다. 운동 루틴 기록 앱에서 질병 정보나 민감한 건강 정보를 받기 시작하면 난이도가 크게 올라갑니다.

개인정보 점검 프롬프트는 다음처럼 씁니다.

이 앱의 개인정보 위험 요소를 점검해줘.

앱 설명:
- 앱 이름: [앱 이름]
- 사용 대상: [누가 쓰는지]
- 입력받는 정보: [예: 이름, 이메일, 전화번호, 메모, 사진 등]
- 저장되는 정보: [저장되는 데이터]
- 공유 방식: [개인 사용 / 링크 공유 / 외부 사용자 입력]

다음 기준으로 점검해줘.
1. 꼭 필요하지 않은 개인정보가 있는가?
2. 민감한 정보가 포함될 가능성이 있는가?
3. 사용자가 입력한 정보가 다른 사람에게 보일 위험이 있는가?
4. 관리자만 봐야 하는 정보가 공개 화면에 보일 가능성이 있는가?
5. 테스트 데이터나 예시 개인정보가 남아 있지 않은가?
6. API 키나 비밀번호 같은 비밀 정보가 화면이나 코드에 노출될 위험이 있는가?
7. 첫 MVP에서 개인정보 수집을 줄이는 방법은 무엇인가?

답변은 다음 형식으로 줘.
- 위험도 높음 / 보통 / 낮음으로 구분
- 반드시 제거하거나 줄일 정보
- 사용자에게 안내해야 할 문구
- MVP에서 안전하게 바꾸는 방법
- 배포 전 확인할 사항

법률 자문처럼 단정하지 말고, 초보자가 조심해야 할 실무 관점으로 설명해줘.

여기서 중요한 표현은 "법률 자문처럼 단정하지 말고"입니다. AI에게 법률 전문가의 최종 판단을 맡기면 안 됩니다. 다만 초보자가 놓칠 만한 위험 요소를 찾는 데는 도움이 됩니다.

예를 들어 강의 후기 수집 앱에서 이름, 소속, 전화번호, 이메일, 수강 만족도, 자유 의견을 모두 받고 있다면 AI는 "후기 분석 목적이라면 전화번호는 불필요할 수 있다"고 제안할 수 있습니다. 예약 문의 앱에서는 연락처가 필요하더라도, 공개 목록에 연락처가 그대로 보이면 위험하다고 알려줄 수 있습니다.

API 키와 환경변수도 조심해야 합니다. API 키는 외부 서비스를 사용할 때 필요한 비밀 열쇠 같은 것입니다. 환경변수는 그 비밀 열쇠를 코드 밖 안전한 금고에 넣어두는 방식입니다. 이 내용은 뒤에서 더 자세히 다루겠지만, 지금은 한 가지만 기억하면 됩니다. 비밀번호, API 키, 관리자용 링크처럼 남에게 보이면 안 되는 정보는 화면에 나오면 안 됩니다.

MVP 줄이기는 포기가 아니라 완성 전략이다

MVP는 Minimum Viable Product의 줄임말입니다. 이 책에서는 "첫 작동 버전"이라고 이해하면 충분합니다. 식당으로 비유하면 정식 매장을 열기 전 팝업스토어입니다. 모든 메뉴와 인테리어를 갖추기 전에, 사람들이 정말 이 음식을 필요로 하는지 작게 확인하는 단계입니다.

많은 초보자가 MVP 줄이기를 실패로 생각합니다. "기능을 줄이면 앱이 초라해지는 것 아닌가요?"라고 걱정합니다. 하지만 실제로는 반대입니다. 기능을 줄여야 첫 앱이 완성됩니다. 기능이 많아서 끝나지 않는 앱보다, 기능이 적어도 누군가 바로 쓸 수 있는 앱이 훨씬 낫습니다.

MVP 줄이기의 핵심 질문은 하나입니다.

"이 앱이 딱 한 가지 일만 잘한다면, 그것은 무엇인가?"

독서 기록 앱이라면 책과 감상을 남기는 일입니다. 할 일 관리 앱이라면 오늘 할 일을 적고 완료 표시하는 일입니다. 강의 후기 수집 앱이라면 수강생의 의견을 모으는 일입니다. 예약 문의 앱이라면 문의 내용을 받고 확인하는 일입니다. AI 프롬프트 보관함 앱이라면 자주 쓰는 프롬프트를 저장하고 다시 찾는 일입니다.

이 한 가지 일을 방해하는 기능은 첫 버전에서 빼도 됩니다. 삭제하는 것이 아니라 나중으로 미루는 것입니다.

기능을 줄여달라고 요청하는 프롬프트

AI에게 MVP 줄이기를 요청할 때는 현재 기능을 모두 알려준 뒤, 반드시 "첫 사용자에게 필요한 최소 기능만 남겨달라"고 말해야 합니다. AI는 기본적으로 더 많은 기능을 제안하는 경향이 있습니다. 그래서 이번에는 반대로 "줄이는 역할"을 맡겨야 합니다.

내 앱을 MVP 기준으로 다시 줄여줘.

앱 설명:
- 앱 이름: [앱 이름]
- 사용 대상: [누가 쓰는지]
- 핵심 목적: [이 앱이 해결하려는 가장 중요한 문제]
- 현재 기능:
  1. [기능 1]
  2. [기능 2]
  3. [기능 3]
  4. [기능 4]
  5. [기능 5]

요청:
첫 버전은 너무 복잡하지 않게 만들고 싶어.
사용자가 핵심 목적을 달성하는 데 꼭 필요한 기능만 남겨줘.

다음 형식으로 정리해줘.
1. 반드시 남길 기능
2. 첫 버전에서 빼도 되는 기능
3. 나중에 추가하면 좋은 기능
4. 화면에서 제거하거나 합칠 수 있는 부분
5. 입력 항목 중 줄일 수 있는 것
6. MVP 버전의 화면 구성
7. MVP로 줄인 뒤 다시 만들기 위한 프롬프트

중요:
기능을 많이 추천하지 말고, 과감히 줄이는 방향으로 판단해줘.

이 프롬프트를 쓰면 AI는 기능을 세 묶음으로 나눠줄 수 있습니다. 반드시 남길 기능, 나중에 추가할 기능, 아예 제거해도 되는 기능입니다. 이 구분이 중요합니다. 초보자는 모든 기능을 같은 무게로 느끼기 쉽습니다. 하지만 실제로는 앱을 앱답게 만드는 핵심 기능과, 있으면 좋은 장식 기능이 다릅니다.

예를 들어 블로그 글감 저장소 앱의 현재 기능이 글감 등록, 카테고리, 태그, 검색, 즐겨찾기, 작성 상태, 마감일, 통계, 랜덤 추천까지 있다고 해보겠습니다. 첫 MVP에서는 글감 등록, 목록 보기, 검색 정도면 충분할 수 있습니다. 태그와 즐겨찾기는 나중에 추가해도 됩니다. 통계와 랜덤 추천은 더 나중이어도 됩니다.

가족 일정 공유 앱도 마찬가지입니다. 가족 구성원별 색상, 반복 일정, 알림, 달력 보기, 메모, 준비물, 위치, 사진 첨부까지 넣으려고 하면 첫 버전이 복잡해집니다. MVP에서는 일정 제목, 날짜, 담당자, 메모 정도만 남겨도 가족끼리 쓰기 시작할 수 있습니다.

불필요한 화면을 줄이는 기준

앱이 복잡해지는 가장 흔한 이유는 화면이 많아지는 것입니다. 홈 화면, 등록 화면, 목록 화면, 상세 화면, 수정 화면, 설정 화면, 통계 화면, 관리자 화면이 생기다 보면 사용자는 길을 잃습니다. 첫 앱에서는 화면 수를 줄이는 것이 좋습니다.

화면을 줄일 때는 "이 화면이 독립적으로 꼭 필요한가?"를 물어보면 됩니다. 단순한 입력은 별도 화면으로 빼지 않고 목록 위나 옆에 넣을 수 있습니다. 간단한 수정은 상세 화면을 만들지 않고 카드 안에서 처리할 수 있습니다. 통계 화면은 첫 버전에서는 요약 숫자 한 줄로 대체할 수 있습니다.

AI에게 화면 축소를 요청할 때는 이렇게 말해보세요.

현재 앱의 화면 구성이 너무 복잡한지 점검하고 줄여줘.

현재 화면:
1. [홈 화면]
2. [등록 화면]
3. [목록 화면]
4. [상세 화면]
5. [수정 화면]
6. [통계 화면]
7. [설정 화면]

앱의 핵심 목적:
[예: 사용자가 운동 기록을 빠르게 남기고 최근 기록을 확인하는 것]

요청:
첫 MVP에서는 화면 수를 최소화하고 싶어.
다음 기준으로 정리해줘.

- 합칠 수 있는 화면
- 첫 버전에서 없애도 되는 화면
- 한 화면 안에서 처리해도 되는 기능
- 사용자가 가장 먼저 봐야 하는 화면
- 모바일에서 더 단순한 흐름

최종적으로 MVP 화면 구성을 2~3개 이내로 제안해줘.

처음 앱을 만들 때는 2~3개 화면이면 충분한 경우가 많습니다. 개인 기록 앱이라면 "입력과 목록을 함께 보여주는 메인 화면" 하나로도 시작할 수 있습니다. 수집형 앱이라면 "사용자 입력 화면"과 "관리자 확인 화면" 두 개면 됩니다. 랜딩페이지형 앱이라면 "소개 영역, 기능 설명, 문의 버튼"이 한 화면 안에 있어도 됩니다.

화면이 줄어들면 앱이 단순해집니다. 앱이 단순해지면 오류도 줄어듭니다. 오류가 줄어들면 내가 검토하기 쉬워집니다. 이것이 초보자에게 특히 중요한 이유입니다.

중복 버튼과 헷갈리는 버튼 정리하기

버튼은 사용자의 행동을 이끄는 표지판입니다. 표지판이 너무 많으면 길을 찾기 어렵습니다. 특히 "등록", "추가", "저장", "제출"처럼 비슷한 버튼이 한 화면에 같이 있으면 사용자는 헷갈립니다.

예를 들어 강의 후기 앱에서 입력창 아래에 "저장" 버튼이 있고, 화면 아래에 또 "제출" 버튼이 있다면 사용자는 둘 중 무엇을 눌러야 할지 모릅니다. 예약 문의 앱에서 "확인", "접수", "저장", "완료"가 모두 있으면 관리자도 헷갈립니다.

버튼을 정리할 때는 버튼 이름을 사용자의 행동 언어로 바꾸는 것이 좋습니다. "저장"보다 "기록 추가하기", "제출"보다 "후기 보내기", "삭제"보다 "이 기록 삭제하기"가 더 명확할 수 있습니다.

다음 프롬프트를 사용하면 버튼을 정리할 수 있습니다.

이 앱의 버튼 이름과 버튼 개수를 점검해줘.

앱 설명:
[앱의 목적과 사용 대상]

현재 버튼 목록:
- [버튼 1]
- [버튼 2]
- [버튼 3]
- [버튼 4]
- [버튼 5]

점검 기준:
1. 같은 의미의 버튼이 중복되어 있는가?
2. 버튼 이름이 사용자의 행동을 명확히 설명하는가?
3. 위험한 버튼, 예를 들어 삭제 버튼은 충분히 조심스럽게 보이는가?
4. 주요 버튼과 보조 버튼이 구분되는가?
5. 모바일에서 버튼이 너무 많아 보이지 않는가?

다음 형식으로 답해줘.
- 유지할 버튼
- 이름을 바꿀 버튼
- 합칠 수 있는 버튼
- 제거해도 되는 버튼
- 더 쉬운 버튼 문구 제안
- 삭제나 초기화처럼 위험한 버튼의 안전장치 제안

위험한 버튼에는 안전장치가 필요합니다. "전체 삭제" 버튼은 첫 MVP에서는 아예 빼는 편이 좋습니다. 꼭 필요하다면 확인창을 넣어야 합니다. 예를 들어 "정말 모든 기록을 삭제할까요? 이 작업은 되돌릴 수 없습니다."라는 문구가 필요합니다.

초보자의 첫 앱에서는 버튼이 적을수록 좋습니다. 사용자가 자주 누르는 버튼 하나를 분명하게 보여주고, 덜 중요한 버튼은 작게 두거나 나중으로 미루는 편이 낫습니다.

복잡한 입력 항목을 줄이는 기준

입력 항목은 앱의 문턱입니다. 사용자는 입력칸이 많으면 시작하기 전에 지칩니다. 특히 스마트폰에서는 입력이 더 귀찮습니다. 그래서 첫 버전에서는 꼭 필요한 정보만 받아야 합니다.

입력 항목을 줄일 때는 세 가지 질문이 도움이 됩니다.

• 이 정보가 없으면 앱의 핵심 기능이 작동하지 않는가?

• 사용자가 이 정보를 매번 입력해야 하는가?

• 나중에 필요할 수도 있다는 이유만으로 지금 받고 있지는 않은가?

예를 들어 독서 기록 앱에서 책 제목과 한 줄 감상은 핵심입니다. 저자, 출판사, ISBN, 구입처, 페이지 수, 독서 시작일, 완독일, 인용문, 태그는 있으면 좋지만 첫 버전에는 부담이 될 수 있습니다.

예약 문의 앱에서 이름, 연락처, 희망 날짜, 문의 내용은 필요할 수 있습니다. 하지만 주소, 성별, 나이, 상세 직업, 유입 경로까지 처음부터 받을 필요는 없을 수 있습니다. 운동 루틴 기록 앱에서 운동명과 세트 수는 중요하지만, 매번 운동 장소와 기분 점수와 날씨까지 입력하게 하면 오래 쓰기 어렵습니다.

입력 항목 점검 프롬프트는 다음과 같습니다.

이 앱의 입력 항목을 MVP 기준으로 줄여줘.

앱 목적:
[앱이 해결하려는 핵심 문제]

현재 입력 항목:
1. [항목 1]
2. [항목 2]
3. [항목 3]
4. [항목 4]
5. [항목 5]
6. [항목 6]

요청:
사용자가 부담 없이 입력할 수 있도록 첫 버전의 입력 항목을 최소화하고 싶어.

다음 기준으로 분류해줘.
- 반드시 필요한 항목
- 있으면 좋지만 첫 버전에서는 뺄 항목
- 개인정보 위험 때문에 조심해야 할 항목
- 선택 입력으로 바꿀 항목
- 자동으로 처리하거나 기본값으로 둘 항목

마지막에 MVP 입력 폼 구성을 다시 제안해줘.

입력 항목을 줄이면 앱이 빈약해지는 것이 아니라 시작하기 쉬워집니다. 많은 사람이 쓰는 앱은 대개 첫 행동이 간단합니다. 메모 앱은 일단 쓰면 됩니다. 할 일 앱은 할 일을 적으면 됩니다. 기록 앱은 기록 하나를 남기면 됩니다. 첫 앱도 이 단순함을 목표로 삼아야 합니다.

배포 전 체크리스트와 AI 점검을 함께 쓰는 흐름

이제 점검 프롬프트를 배웠으니, 실제로 어떤 순서로 쓰면 좋을지 정리해보겠습니다. 앱을 만든 뒤 배포하거나 다른 사람에게 링크를 보내기 전에는 다음 흐름을 추천합니다.

먼저 내가 직접 앱을 한 번 써봅니다. 새 기록을 추가하고, 목록에서 확인하고, 수정하거나 삭제해봅니다. 모바일 화면으로도 열어봅니다. 그다음 AI에게 문제점 점검을 요청합니다. 이후 초보자 사용성, 모바일 사용성, 개인정보 위험 요소를 차례로 확인합니다. 마지막으로 MVP 줄이기 프롬프트를 사용해 첫 버전에서 과한 기능을 덜어냅니다.

배포 전에는 다음 항목을 꼭 확인하세요.

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

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

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

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

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

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

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

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

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

이 체크리스트는 사람의 눈으로 먼저 보는 것이 좋습니다. 그런 다음 같은 항목을 AI에게도 점검하게 하면 더 안전합니다.

아래 배포 전 체크리스트를 기준으로 내 앱을 점검해줘.

앱 설명:
[앱 이름, 사용 대상, 핵심 기능]

체크리스트:
1. 버튼이 모두 작동하는가?
2. 모바일 화면에서 깨지지 않는가?
3. 한국어 문구가 자연스러운가?
4. 입력한 데이터가 정상적으로 보이는가?
5. 삭제 기능에 실수 방지가 있는가?
6. 개인정보를 과하게 수집하지 않는가?
7. 실제 API 키나 비밀 정보가 화면에 노출되지 않는가?
8. 공유 링크가 제대로 열리는가?
9. 다른 사람이 봐도 사용법을 이해할 수 있는가?

각 항목에 대해 다음 형식으로 답해줘.
- 점검 결과
- 위험도: 높음 / 보통 / 낮음
- 수정 제안
- 초보자가 이해할 수 있는 이유

바로 수정하지 말고, 먼저 점검표 형태로 정리해줘.

이 프롬프트는 배포 직전에 특히 유용합니다. 앱 빌더형 도구에서 만든 결과물을 바로 공유할 수 있다면 더더욱 필요합니다. "공유하기 쉬움"은 장점이지만, "준비 안 된 상태로 공유하기 쉬움"이라는 뜻도 됩니다. 링크를 보내기 전에 한 번 더 보는 습관이 중요합니다.

점검 결과를 수정 요청으로 바꾸는 법

AI가 점검 결과를 주면 다음 단계는 수정 요청입니다. 여기서도 한 번에 전부 고치라고 하면 위험합니다. 점검 결과가 10개 나왔더라도 우선순위를 정해야 합니다. 초보자는 보통 "전부 반영해줘"라고 말하고 싶어집니다. 하지만 그렇게 하면 화면이 갑자기 크게 바뀌거나, 잘 되던 기능이 깨질 수 있습니다.

수정 요청은 작게 나누는 것이 좋습니다. 먼저 버튼 이름과 안내 문구처럼 안전한 부분을 고칩니다. 다음으로 입력 항목을 줄입니다. 그다음 화면 구조를 정리합니다. 마지막으로 기능 제거처럼 영향이 큰 작업을 합니다.

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

방금 점검 결과 중에서 우선순위가 높은 것부터 단계별로 수정하고 싶어.

요청:
1. 먼저 사용자 혼란을 줄이는 수정만 해줘.
2. 기능 구조를 크게 바꾸지 말고, 버튼 이름과 안내 문구, 빈 화면 문구를 먼저 개선해줘.
3. 수정 후 어떤 부분이 바뀌었는지 목록으로 설명해줘.
4. 기존 데이터 추가, 목록 보기, 삭제 기능은 유지해줘.

이번 단계에서는 화면 개편이나 기능 삭제는 하지 마.

이렇게 단계별로 요청하면 변경 범위를 통제할 수 있습니다. 바이브 코딩에서 "변경 범위"는 매우 중요합니다. AI에게 작은 방 하나만 정리해달라고 해야 하는데, 집 전체 인테리어를 바꿔버리면 곤란합니다.

입력 항목을 줄일 때는 다음처럼 요청할 수 있습니다.

이번에는 입력 폼을 MVP 기준으로 줄여줘.

유지할 항목:
- [항목 1]
- [항목 2]
- [항목 3]

제거할 항목:
- [항목 4]
- [항목 5]

요청:
1. 제거하는 항목과 관련된 화면 요소를 없애줘.
2. 목록 카드에서도 제거된 항목이 보이지 않게 해줘.
3. 기존 핵심 기능인 추가, 목록 보기, 삭제는 유지해줘.
4. 사용자가 입력을 완료하면 확인 메시지를 보여줘.
5. 모바일에서 입력 폼이 너무 길어지지 않게 정리해줘.

수정 후 변경 사항을 간단히 설명해줘.

화면을 줄일 때는 조금 더 조심해야 합니다.

현재 화면 구성을 MVP에 맞게 단순화해줘.

목표:
사용자가 앱을 열자마자 [핵심 행동]을 할 수 있게 만들고 싶어.

수정 방향:
1. [등록 화면]과 [목록 화면]을 하나의 메인 화면으로 합쳐줘.
2. [통계 화면]은 첫 버전에서 제거해줘.
3. [설정 화면]은 없애고 필요한 기본값은 자동으로 적용해줘.
4. 모바일에서 위에서 아래로 자연스럽게 사용할 수 있게 배치해줘.
5. 기존 데이터 저장 방식은 가능하면 유지해줘.

주의:
새로운 기능을 추가하지 말고, 화면을 줄이는 데 집중해줘.

수정 요청에서 가장 중요한 문장은 "새로운 기능을 추가하지 말고"입니다. 우리는 지금 더하는 단계가 아니라 덜어내는 단계에 있습니다.

세 가지 앱으로 보는 MVP 줄이기 예시

이제 실제 예시로 살펴보겠습니다. 첫 번째는 독서 기록 앱입니다. 초기에 책 제목, 저자, 완독일, 별점, 감상, 인용문, 태그, 표지 이미지, 독서 상태, 검색, 통계까지 넣었다고 해보겠습니다. 보기에는 풍성하지만 첫 입력이 부담스러울 수 있습니다. MVP에서는 책 제목, 감상, 별점 정도만 남기고 시작할 수 있습니다. 검색은 기록이 많아진 뒤 추가해도 됩니다. 표지 이미지는 멋지지만 첫 버전에는 없어도 됩니다.

두 번째는 예약 문의 앱입니다. 이름, 연락처, 희망 날짜, 희망 시간, 서비스 종류, 인원, 문의 내용, 방문 경로, 예산, 주소까지 받는다면 사용자는 중간에 포기할 수 있습니다. MVP에서는 이름, 연락처, 희망 날짜, 문의 내용만 남기는 편이 낫습니다. 서비스 종류가 꼭 필요하다면 선택 항목으로 두면 됩니다. 주소나 예산은 상담 후 받아도 됩니다.

세 번째는 AI 프롬프트 보관함 앱입니다. 프롬프트 제목, 본문, 카테고리, 태그, 즐겨찾기, 사용 횟수, 마지막 사용일, 평가 점수, 공유 여부, 복사 버튼, 검색, 필터가 모두 있다면 꽤 복잡합니다. 하지만 첫 버전의 핵심은 "자주 쓰는 프롬프트를 저장하고 복사하는 것"입니다. 제목, 본문, 카테고리, 복사 버튼 정도면 시작할 수 있습니다. 사용 횟수나 평가 점수는 나중에 추가해도 늦지 않습니다.

이 세 예시의 공통점은 분명합니다. 첫 앱은 사용자가 첫 기록을 남기는 데 집중해야 합니다. 첫 기록을 남기기 전에 너무 많은 결정을 요구하면 안 됩니다.

흔한 실수: 점검을 받았는데 더 복잡해지는 경우

점검 프롬프트를 쓰다 보면 뜻밖의 일이 생깁니다. AI가 개선점을 많이 알려줬고, 그것을 모두 반영했더니 앱이 더 복잡해지는 경우입니다. 예를 들어 "사용자 안내가 부족하다"는 피드백을 보고 안내 문구를 너무 많이 넣으면 화면이 설명서처럼 변합니다. "필터가 있으면 좋다"는 제안을 반영했더니 검색창, 카테고리 필터, 날짜 필터, 상태 필터가 모두 생길 수 있습니다.

이럴 때는 다시 원칙으로 돌아가야 합니다. 첫 버전의 목적은 모든 사용자를 만족시키는 것이 아닙니다. 가장 중요한 사용자가 가장 중요한 일을 끝내게 하는 것입니다.

점검 결과를 받았을 때는 다음 기준으로 나누세요.

• 지금 꼭 고칠 것

• 다음 버전에서 고칠 것

• 좋은 의견이지만 이번에는 하지 않을 것

AI에게도 이렇게 정리해달라고 할 수 있습니다.

방금 제안한 개선 사항이 너무 많아 보여.
첫 MVP 기준으로 다시 우선순위를 정리해줘.

다음 세 그룹으로 나눠줘.
1. 지금 꼭 고칠 것: 사용자가 핵심 기능을 쓰는 데 방해되는 문제
2. 다음 버전에서 고칠 것: 있으면 좋지만 당장 없어도 되는 개선
3. 이번에는 하지 않을 것: 첫 버전을 복잡하게 만들 가능성이 큰 기능

판단 기준:
- 사용자가 헷갈리지 않는가?
- 핵심 기능 작동에 필요한가?
- 개인정보나 보안 위험과 관련 있는가?
- 모바일 사용에 큰 영향을 주는가?

기능을 늘리는 방향보다 줄이는 방향으로 판단해줘.

이 프롬프트는 매우 중요합니다. AI의 제안은 참고 자료일 뿐, 최종 결정은 앱을 만드는 사람이 해야 합니다. 바이브 코딩은 AI에게 끌려가는 일이 아니라, AI와 대화하면서 내가 원하는 방향을 분명히 하는 일입니다.

실습 미션: 내 앱을 30분 안에 가볍게 만들기

이번 장의 실습은 새 앱을 만드는 것이 아닙니다. 이미 만든 앱 하나를 가볍게 다듬는 것입니다. 독서 기록 앱, 할 일 관리 앱, 강의 후기 수집 앱, 예약 문의 앱, 운동 루틴 기록 앱, 블로그 글감 저장소 앱, AI 프롬프트 보관함 앱 중 하나를 골라도 좋습니다. 아직 만든 앱이 없다면 예전에 작성한 앱 기획서로 해도 됩니다.

먼저 현재 앱의 목적을 한 문장으로 씁니다. 예를 들어 "이 앱은 내가 읽은 책과 감상을 간단히 남기기 위한 앱이다"처럼 적습니다. 다음으로 현재 들어간 기능을 모두 적습니다. 그런 뒤 이 장의 MVP 줄이기 프롬프트를 넣어봅니다. AI가 줄여준 결과를 보고, 첫 버전에서 뺄 기능을 세 개 이상 골라보세요.

마지막으로 배포 전 체크리스트 프롬프트를 실행합니다. 점검 결과 중 위험도가 높은 항목 하나, 사용성을 높이는 항목 하나, 모바일 관련 항목 하나를 골라 수정 요청을 해봅니다. 단, 한 번에 모두 고치지 말고 하나씩 요청하세요.

실습에 바로 쓸 수 있는 통합 프롬프트를 제공합니다.

내가 만든 앱을 첫 배포 전 MVP 기준으로 점검하고 줄여줘.

앱 이름:
[앱 이름]

사용 대상:
[누가 쓰는 앱인지]

앱의 핵심 목적 한 문장:
[이 앱이 해결하는 가장 중요한 문제]

현재 기능:
1. [기능 1]
2. [기능 2]
3. [기능 3]
4. [기능 4]
5. [기능 5]

현재 화면:
1. [화면 1]
2. [화면 2]
3. [화면 3]

입력받는 정보:
- [정보 1]
- [정보 2]
- [정보 3]

점검 요청:
1. 초보자가 사용하기 어려운 부분을 찾아줘.
2. 모바일에서 불편할 부분을 찾아줘.
3. 개인정보 위험 요소를 찾아줘.
4. 첫 MVP에서 빼도 되는 기능을 골라줘.
5. 불필요한 화면, 중복 버튼, 복잡한 입력 항목을 줄여줘.
6. 배포 전에 꼭 고칠 것만 우선순위로 정리해줘.

답변 형식:
- 핵심 진단 요약
- 지금 꼭 고칠 것 3가지
- 첫 버전에서 뺄 기능
- 줄인 MVP 화면 구성
- 줄인 MVP 입력 항목
- 수정 요청 프롬프트 초안

중요:
새 기능을 추천하기보다, 첫 버전을 단순하고 안전하게 만드는 데 집중해줘.

이 실습을 마치면 앱이 조금 덜 화려해질 수 있습니다. 하지만 더 쓸 만해질 가능성이 큽니다. 첫 앱의 목표는 박수를 받는 것이 아니라, 누군가 실제로 한 번 써볼 수 있게 만드는 것입니다.

한 장 요약

이번 장에서는 만든 앱을 바로 공유하기 전에 AI를 활용해 점검하고, 필요하면 MVP 기준으로 기능을 줄이는 방법을 배웠습니다. 중요한 점은 점검 프롬프트가 칭찬을 받기 위한 도구가 아니라 문제를 찾기 위한 도구라는 것입니다.

앱을 점검할 때는 문제점, 초보자 사용성, 모바일 사용성, 개인정보 위험 요소를 나누어 보는 것이 좋습니다. "검토해줘"라고 막연히 말하기보다 어떤 기준으로 봐야 하는지 알려줘야 더 쓸모 있는 답을 얻을 수 있습니다.

MVP 줄이기는 포기가 아닙니다. 첫 버전을 완성하기 위한 전략입니다. 불필요한 화면, 중복 버튼, 복잡한 입력 항목을 줄이면 앱은 더 단순해지고, 사용자는 덜 헷갈립니다. 초보자의 첫 앱에서는 기능의 양보다 사용자의 첫 행동이 훨씬 중요합니다.

마지막으로 배포 전 체크리스트와 AI 점검 프롬프트를 함께 사용하세요. 사람의 눈으로 한 번 보고, AI에게 한 번 더 확인하게 만드는 흐름이 안전합니다. 바이브 코딩은 빠르게 만드는 기술이지만, 좋은 앱은 빠르게 만든 뒤 차분히 덜어내는 과정에서 완성됩니다.