불편함을 기능으로 바꾸는 질문법

불편함은 아직 앱이 아닙니다

"강의 후기를 받는 게 너무 번거로워요."

"예약 문의가 카카오톡, 문자, 인스타그램 DM으로 흩어져서 정신이 없어요."

"운동을 하긴 하는데 지난주에 뭘 했는지 기억이 안 나요."

이런 말들은 모두 좋은 앱 아이디어의 씨앗입니다. 하지만 씨앗만으로는 앱이 만들어지지 않습니다. AI 앱 빌더에게 "강의 후기 수집 앱 만들어줘"라고 말하면 뭔가 만들어주긴 하겠지만, 내가 상상한 것과 다른 결과물이 나올 가능성이 큽니다. 왜냐하면 AI는 아직 사용자가 무엇을 입력해야 하는지, 앱이 무엇을 저장해야 하는지, 화면에 무엇을 보여줘야 하는지 모르기 때문입니다.

앱 기획은 멋진 이름을 짓는 일이 아닙니다. 화려한 로고를 상상하는 일도 아닙니다. 가장 먼저 해야 할 일은 사용자의 행동을 문장으로 정리하는 것입니다.

예를 들어 "운동 기록 앱"이라는 이름보다 더 중요한 문장은 이것입니다.

"사용자는 오늘 한 운동 이름, 세트 수, 반복 횟수, 느낀 점을 입력하고, 앱은 날짜별 운동 기록을 목록으로 보여준다."

이 한 문장에는 앱의 뼈대가 들어 있습니다. 누가 쓰는지, 무엇을 입력하는지, 무엇이 저장되는지, 무엇을 다시 확인하는지가 보입니다. 바이브 코딩에서 좋은 프롬프트는 바로 이런 문장에서 시작됩니다.

이번 장에서는 막연한 불편함을 앱의 기능과 화면으로 바꾸는 질문법을 익힙니다. 코딩 문법은 몰라도 괜찮습니다. 대신 "사용자는 무엇을 하고, 앱은 무엇을 보여주는가?"를 차분히 말할 수 있어야 합니다.

첫 번째 질문: 누가, 언제, 무엇 때문에 불편한가

불편함을 앱으로 바꾸려면 먼저 상황을 좁혀야 합니다. 많은 초보자가 여기서 너무 크게 시작합니다.

"사람들이 시간을 잘 관리하게 해주는 앱을 만들고 싶어요."

좋은 방향이지만 너무 넓습니다. 학생도 시간을 관리하고, 직장인도 시간을 관리하고, 프리랜서도 시간을 관리합니다. 아침 루틴을 관리하고 싶은 사람도 있고, 회의 일정을 관리하고 싶은 사람도 있고, 운동 시간을 지키고 싶은 사람도 있습니다. AI에게 이렇게 넓은 요청을 하면 앱도 애매해집니다.

먼저 다음 문장으로 바꿔보세요.

"누가, 언제, 무엇 때문에 불편한가?"

예를 들어 봅시다.

직장인은 회의가 끝난 뒤 결정 사항을 정리하지 못해서 불편합니다. 강사는 강의가 끝난 뒤 후기를 한곳에 모으지 못해서 불편합니다. 작은 공방 운영자는 예약 문의가 여러 채널로 흩어져서 불편합니다. 운동을 시작한 사람은 지난 운동 기록을 기억하지 못해서 불편합니다.

이렇게 쓰면 앱의 방향이 훨씬 선명해집니다.

여기서 중요한 점은 "모든 사람을 위한 앱"을 만들려고 하지 않는 것입니다. 첫 앱은 특정한 한 사람, 특정한 한 상황, 특정한 한 문제를 향해야 합니다. 유명한 도구가 초보자에게 쉬운 도구는 아니듯이, 큰 아이디어가 초보자에게 좋은 아이디어도 아닙니다. 처음에는 작고 분명한 문제를 고르는 것이 좋습니다.

두 번째 질문: 사용자는 무엇을 입력하는가

앱은 보통 사용자가 무언가를 입력하면서 시작됩니다. 입력은 앱에게 건네는 재료입니다. 식당으로 비유하면 손님이 주문서에 적는 내용과 비슷합니다. 주문서가 "맛있는 거 주세요"라고만 되어 있으면 주방은 난감합니다. 하지만 "김치찌개 1개, 덜 맵게, 공깃밥 추가"라고 쓰여 있으면 훨씬 정확히 움직일 수 있습니다.

AI에게 앱을 부탁할 때도 마찬가지입니다. "기록 앱 만들어줘"보다 "사용자가 제목, 날짜, 메모, 만족도를 입력할 수 있게 해줘"라고 말해야 합니다.

입력값은 사용자가 직접 적거나 선택하는 정보입니다. 예를 들어 독서 기록 앱에서는 책 제목, 저자, 읽은 날짜, 별점, 한 줄 감상이 입력값이 될 수 있습니다. 예약 문의 앱에서는 이름, 연락처, 희망 날짜, 희망 시간, 문의 내용이 입력값이 됩니다. 운동 기록 앱에서는 운동 날짜, 운동 종류, 세트 수, 반복 횟수, 무게, 컨디션이 입력값이 될 수 있습니다.

처음부터 입력값을 너무 많이 넣을 필요는 없습니다. 입력칸이 많아질수록 사용자는 귀찮아지고, 앱도 복잡해집니다. 첫 버전에서는 정말 필요한 정보만 남기는 것이 좋습니다.

예를 들어 운동 기록 앱의 첫 버전이라면 운동 부위, 운동 기구, 칼로리, 사진, 루틴 추천, 친구 공유까지 넣지 않아도 됩니다. 처음에는 "날짜, 운동 이름, 세트 수, 메모" 정도면 충분합니다. 첫 앱은 완성도보다 작동 경험이 중요합니다.

세 번째 질문: 앱은 무엇을 저장하는가

사용자가 입력한 정보가 앱 안에 남아 있어야 한다면, 그것은 저장값입니다. 저장값은 장부나 엑셀 파일에 남겨두는 기록과 비슷합니다. 손님이 주문한 내용을 주방에서 한 번 보고 버리는 것이 아니라, 나중에 정산하거나 다시 확인할 수 있도록 적어두는 것입니다.

초보자는 입력값과 저장값을 거의 같은 것으로 생각해도 괜찮습니다. 다만 차이를 알아두면 AI에게 더 정확히 말할 수 있습니다.

예를 들어 강의 후기 수집 앱에서 사용자는 이름, 강의명, 만족도, 좋았던 점, 개선할 점을 입력합니다. 이 정보는 저장되어야 합니다. 그래야 강사가 나중에 후기 목록을 보고, 만족도 평균을 확인하고, 좋은 후기를 복사해서 홍보 문구로 활용할 수 있습니다.

반대로 저장하지 않아도 되는 정보도 있습니다. 예를 들어 검색창에 잠깐 입력한 검색어는 꼭 영구 저장할 필요가 없습니다. 필터에서 선택한 "별점 4점 이상" 같은 조건도 보통은 저장하지 않아도 됩니다. 앱을 만들 때 모든 것을 저장하려고 하면 구조가 복잡해집니다.

AI에게는 이렇게 말하면 좋습니다.

사용자가 입력한 후기 정보는 저장되어야 합니다. 저장할 항목은 이름, 강의명, 만족도 점수, 좋았던 점, 개선할 점, 제출 날짜입니다. 검색어와 필터 조건은 저장하지 않아도 됩니다.

이 정도만 말해도 AI는 앱의 구조를 훨씬 잘 이해합니다.

네 번째 질문: 앱은 무엇을 보여주는가

앱은 입력받고 저장하는 데서 끝나지 않습니다. 사용자가 다시 볼 수 있어야 합니다. 이때 앱이 보여주는 정보가 출력값입니다. 출력값은 사용자가 앱을 열었을 때 화면에서 확인하는 결과입니다.

출력값을 정할 때는 "사용자가 이 앱을 다시 여는 이유가 무엇인가?"라고 물어보면 됩니다.

강의 후기 수집 앱을 다시 여는 이유는 후기를 확인하기 위해서입니다. 그러면 앱은 후기 목록, 만족도 평균, 최신 후기, 개선 요청이 많은 항목을 보여주면 좋습니다. 예약 문의 앱을 다시 여는 이유는 예약 요청을 확인하고 처리하기 위해서입니다. 그러면 앱은 문의자 이름, 희망 날짜, 상태, 연락처, 문의 내용을 보여줘야 합니다. 운동 기록 앱을 다시 여는 이유는 내가 꾸준히 운동했는지 확인하기 위해서입니다. 그러면 앱은 날짜별 기록, 운동 종류, 총 세트 수, 최근 기록을 보여주면 됩니다.

여기서 욕심을 내면 대시보드, 그래프, 알림, AI 분석, PDF 다운로드까지 떠오를 수 있습니다. 하지만 첫 화면은 단순해야 합니다. 초보자에게 좋은 첫 화면은 "입력하는 곳"과 "목록으로 보는 곳"이 함께 있는 화면입니다.

예를 들어 첫 버전은 이렇게 요청할 수 있습니다.

첫 화면은 위쪽에 새 기록을 입력하는 폼을 두고, 아래쪽에 저장된 기록 목록을 보여주세요. 목록에는 최신 기록이 위에 오게 해주세요. 각 기록에는 날짜, 제목, 메모가 보이면 됩니다.

이 프롬프트는 짧지만 강합니다. 화면 구조, 입력 위치, 출력 위치, 정렬 방식까지 들어 있기 때문입니다.

입력값, 저장값, 출력값을 구분하는 연습

입력값, 저장값, 출력값이라는 말이 조금 딱딱하게 느껴질 수 있습니다. 쉽게 말하면 이렇습니다.

입력값은 사용자가 앱에 적는 것입니다. 저장값은 앱이 기억해두는 것입니다. 출력값은 앱이 다시 보여주는 것입니다.

이 세 가지를 구분하면 앱 기획이 훨씬 쉬워집니다. AI에게도 "이 앱은 대충 이런 느낌"이 아니라 "이 앱은 이런 정보를 받고, 이런 정보를 저장하고, 이런 식으로 보여준다"고 설명할 수 있습니다.

다음 예시를 보겠습니다.

이 표를 만드는 순간 아이디어는 훨씬 구체적인 앱이 됩니다. 아직 디자인도 없고 코드도 없지만, 앱의 핵심 구조가 보이기 시작합니다.

바이브 코딩은 코딩을 안 배워도 된다는 뜻이 아닙니다. 내가 원하는 것을 AI가 이해하게 설명하는 기술입니다. 입력값, 저장값, 출력값을 구분하는 일은 그 설명의 기초입니다.

불편함 문장을 기능 문장으로 바꾸기

이제 실제로 바꿔보겠습니다. 핵심은 불평을 기능 언어로 번역하는 것입니다. "불편하다"는 감정이고, "입력한다, 저장한다, 보여준다, 수정한다, 삭제한다"는 기능입니다.

먼저 강의 후기 수집 상황입니다.

불편함 문장은 이렇습니다.

"강의가 끝난 뒤 후기를 구글폼, 카톡, 문자로 따로 받아서 정리하기 힘들다."

이 문장을 기능 문장으로 바꾸면 이렇게 됩니다.

"수강생은 강의명, 만족도, 좋았던 점, 개선할 점을 입력한다. 앱은 제출된 후기를 저장하고, 강사는 후기 목록과 만족도 평균을 확인한다."

조금 더 앱 빌더에게 친절하게 바꾸면 이렇게 됩니다.

강의 후기 수집 앱을 만들고 싶습니다. 수강생은 이름, 강의명, 만족도 점수, 좋았던 점, 개선할 점을 입력합니다. 앱은 제출된 후기를 저장하고, 관리자 화면에서 후기 목록과 만족도 평균을 보여줍니다. 첫 버전에서는 로그인 없이 링크를 받은 사람이 후기를 제출할 수 있게 해주세요. 결제, 문자 발송, 복잡한 회원 관리는 제외해주세요.

이번에는 예약 문의 상황입니다.

불편함 문장은 이렇습니다.

"예약 문의가 여러 채널로 들어와서 누가 언제 예약하고 싶어 하는지 놓칠 때가 있다."

기능 문장은 이렇게 바꿀 수 있습니다.

"고객은 이름, 연락처, 희망 날짜, 희망 시간, 문의 내용을 입력한다. 앱은 예약 문의를 저장하고, 운영자는 문의 목록에서 상태를 확인하고 처리 완료로 바꾼다."

프롬프트로 쓰면 이렇게 됩니다.

작은 공방에서 사용할 예약 문의 앱을 만들고 싶습니다. 고객은 이름, 연락처, 희망 날짜, 희망 시간, 인원 수, 문의 내용을 입력합니다. 운영자는 문의 목록을 보고 각 문의의 상태를 '새 문의', '확인 중', '예약 확정', '취소'로 바꿀 수 있어야 합니다. 첫 화면에는 예약 문의 입력 폼이 있고, 관리자용 영역에는 문의 목록이 보이게 해주세요. 첫 버전에서는 온라인 결제와 자동 문자 발송은 제외해주세요.

이번에는 운동 기록 상황입니다.

불편함 문장은 이렇습니다.

"운동을 하긴 하는데 지난번에 몇 세트를 했는지 기억이 안 난다."

기능 문장은 이렇게 바뀝니다.

"사용자는 운동 날짜, 운동 이름, 세트 수, 반복 횟수, 메모를 입력한다. 앱은 운동 기록을 저장하고, 사용자는 날짜별 기록과 최근 운동 내역을 확인한다."

프롬프트로 쓰면 이렇게 됩니다.

개인용 운동 기록 앱을 만들고 싶습니다. 사용자는 날짜, 운동 이름, 세트 수, 반복 횟수, 무게, 메모를 입력할 수 있습니다. 앱은 기록을 저장하고 최신 운동 기록을 위에서부터 목록으로 보여줍니다. 운동 이름으로 검색할 수 있게 해주세요. 첫 버전에서는 친구 공유, 식단 관리, 칼로리 계산, 웨어러블 기기 연동은 제외해주세요.

세 예시의 공통점을 보세요. 멋진 표현보다 중요한 것은 사용자의 행동입니다. 누가 입력하고, 무엇이 저장되고, 어떤 화면에서 다시 보는지가 들어 있습니다.

기능은 동사로 써야 선명해집니다

앱 기획을 할 때 명사만 적으면 모호해집니다.

"후기, 예약, 운동, 통계, 알림"

이렇게 적으면 무엇을 하겠다는 것인지 불분명합니다. AI도 추측해야 합니다. 대신 동사로 바꾸면 선명해집니다.

"후기를 작성한다, 예약 문의를 제출한다, 운동 기록을 저장한다, 통계를 확인한다, 알림을 받는다."

기능은 되도록 동사로 쓰세요. 앱 안에서 사용자가 할 수 있는 행동이 바로 기능입니다.

예를 들어 "검색"이라고만 쓰지 말고 "키워드로 저장된 기록을 검색한다"라고 쓰는 편이 좋습니다. "삭제"라고만 쓰지 말고 "잘못 입력한 기록을 삭제한다"라고 쓰면 더 좋습니다. "관리자"라고만 쓰지 말고 "관리자가 문의 상태를 변경한다"라고 쓰면 AI가 화면을 더 잘 구성합니다.

기능 문장을 쓸 때 자주 쓰는 동사는 다음과 같습니다.

• 입력한다, 저장한다, 수정한다, 삭제한다

• 검색한다, 필터링한다, 정렬한다, 복사한다

• 확인한다, 제출한다, 선택한다, 상태를 바꾼다

• 목록으로 본다, 카드로 본다, 날짜별로 본다, 요약해서 본다

이 동사들만 잘 사용해도 앱 설명이 훨씬 좋아집니다.

너무 큰 아이디어를 첫 화면 하나로 줄이기

아이디어가 커지는 것은 자연스러운 일입니다. 예약 문의 앱을 생각하다 보면 결제도 붙이고 싶고, 알림도 넣고 싶고, 고객 관리도 하고 싶고, 리뷰 관리도 하고 싶어집니다. 운동 기록 앱을 생각하다 보면 AI 코치, 식단 분석, 체중 변화 그래프, 친구 랭킹까지 떠오릅니다.

하지만 첫 앱에서 모든 것을 넣으려고 하면 대부분 중간에 지칩니다. AI가 만들어준 결과물도 복잡해지고, 내가 무엇이 잘못됐는지 검토하기 어려워집니다.

이럴 때는 "첫 화면 하나"로 줄여야 합니다.

첫 화면 하나로 줄인다는 것은 사용자가 앱에 들어왔을 때 가장 먼저 해야 할 행동 하나만 남긴다는 뜻입니다. 강의 후기 수집 앱이라면 첫 화면은 후기 제출 폼이면 충분합니다. 예약 문의 앱이라면 첫 화면은 예약 문의 폼이면 충분합니다. 운동 기록 앱이라면 첫 화면은 오늘 운동 기록 입력과 최근 기록 목록이면 충분합니다.

다음 질문을 해보세요.

"이 앱에서 사용자가 가장 먼저 해야 하는 행동은 무엇인가?"

답이 "기록하기"라면 첫 화면은 기록 입력 화면입니다. 답이 "문의하기"라면 첫 화면은 문의 폼입니다. 답이 "목록 확인하기"라면 첫 화면은 목록 화면입니다.

첫 화면을 정하면 나머지는 나중 단계로 미룰 수 있습니다. 로그인, 결제, 알림, 관리자 권한, 그래프, AI 분석은 모두 훌륭한 기능일 수 있지만, 첫 버전에서 꼭 필요한 것은 아닐 수 있습니다.

다음 프롬프트를 사용하면 큰 아이디어를 줄이는 데 도움이 됩니다.

아래 앱 아이디어를 초보자가 만들 수 있는 첫 버전으로 줄여주세요.

앱 아이디어: [여기에 아이디어 입력]
사용자: [누가 쓰는지 입력]
해결하고 싶은 문제: [불편함 입력]

요청사항:
1. 첫 화면에서 사용자가 해야 할 행동 1개를 정해주세요.
2. 첫 버전에 꼭 필요한 기능 3개만 남겨주세요.
3. 나중 버전으로 미룰 기능을 따로 정리해주세요.
4. 입력값, 저장값, 출력값을 표로 정리해주세요.
5. 앱 빌더형 도구에 넣을 수 있는 첫 프롬프트로 바꿔주세요.

이 프롬프트는 Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구를 쓰기 전에 ChatGPT나 Claude 같은 대화형 AI에게 먼저 물어봐도 좋습니다. 바로 만들기 전에 생각을 정리하는 용도로 쓰는 것입니다.

예시 1: 강의 후기 수집 앱으로 줄이기

강사라면 강의 후기를 잘 모으고 싶습니다. 하지만 처음부터 너무 많은 기능을 넣기 쉽습니다. 수강생 관리, 강의별 통계, 후기 이미지 생성, 자동 이메일 발송, 재수강 추천까지 넣고 싶어집니다.

첫 버전에서는 이렇게 줄여봅니다.

사용자는 수강생입니다. 문제는 강의 후기를 한곳에 모으기 어렵다는 것입니다. 가장 중요한 행동은 후기를 제출하는 것입니다. 그러면 첫 화면은 후기 입력 폼이어야 합니다.

처음 버전에 필요한 기능은 후기 작성, 후기 저장, 후기 목록 확인 정도입니다. 만족도 평균을 보여주는 기능은 있어도 좋지만, 없어도 첫 버전은 작동합니다. 자동 문자 발송이나 로그인은 나중으로 미루는 편이 안전합니다.

앱 생성 프롬프트는 이렇게 쓸 수 있습니다.

저는 강의를 운영하는 강사입니다. 강의가 끝난 뒤 수강생 후기를 한곳에 모으는 간단한 웹앱을 만들고 싶습니다.

앱의 목적은 수강생이 쉽게 후기를 제출하고, 제가 제출된 후기를 목록으로 확인하는 것입니다.

필요한 기능은 다음과 같습니다.
1. 수강생이 이름, 강의명, 만족도 점수, 좋았던 점, 개선할 점을 입력한다.
2. 제출된 후기는 저장된다.
3. 관리자는 제출된 후기를 최신순 목록으로 확인한다.
4. 만족도 점수의 평균을 간단히 보여준다.

화면 구성은 첫 화면 상단에 후기 입력 폼, 하단에 제출된 후기 목록이 보이게 해주세요. 디자인은 깔끔한 강의 자료 느낌으로, 한국어 문구를 자연스럽게 써주세요.

첫 버전에서는 로그인, 이메일 발송, 문자 발송, 결제 기능은 제외해주세요. MVP로 작게 만들어주세요.

여기서 MVP는 정식 매장을 열기 전 팝업스토어와 같습니다. 모든 인테리어와 직원을 갖춘 큰 매장이 아니라, 사람들이 정말 관심을 보이는지 확인하는 작은 실험 공간입니다.

예시 2: 예약 문의 앱으로 줄이기

소상공인에게 예약 문의는 매우 현실적인 문제입니다. 네이버 톡톡, 문자, 전화, 인스타그램 DM으로 문의가 들어오면 어느 순간 놓치는 문의가 생깁니다. 하지만 첫 앱에서 모든 예약 시스템을 만들 필요는 없습니다.

처음에는 "예약 확정 시스템"이 아니라 "예약 문의를 한곳에 모으는 앱"으로 생각하는 것이 좋습니다. 결제, 자동 알림, 캘린더 연동은 나중 단계입니다.

첫 화면의 행동은 고객이 예약 문의를 남기는 것입니다. 운영자는 나중에 목록을 보고 상태만 바꾸면 됩니다.

저는 1인 공방을 운영합니다. 고객의 예약 문의를 한곳에 모으는 간단한 웹앱을 만들고 싶습니다.

앱의 목적은 고객이 예약 희망 정보를 남기고, 운영자가 문의 상태를 확인하는 것입니다.

필요한 기능은 다음과 같습니다.
1. 고객이 이름, 연락처, 희망 날짜, 희망 시간, 인원 수, 문의 내용을 입력한다.
2. 제출된 예약 문의는 저장된다.
3. 운영자는 문의 목록을 최신순으로 확인한다.
4. 운영자는 각 문의의 상태를 '새 문의', '확인 중', '예약 확정', '취소' 중 하나로 바꿀 수 있다.

화면 구성은 고객용 예약 문의 폼과 운영자용 문의 목록 영역으로 나눠주세요. 디자인은 따뜻하고 깔끔한 소규모 공방 느낌이면 좋겠습니다.

첫 버전에서는 온라인 결제, 자동 문자 발송, 로그인, 외부 캘린더 연동은 제외해주세요. 우선 MVP로 작동하는 문의 접수 앱을 만들어주세요.

이 프롬프트에서 중요한 부분은 "예약 앱"이라고만 하지 않고 "예약 문의 앱"이라고 한 점입니다. 예약을 완전히 확정하고 결제까지 처리하는 앱은 난이도가 올라갑니다. 반면 문의를 수집하고 상태를 바꾸는 앱은 초보자가 앱 빌더형 도구로 시도해볼 만합니다.

예시 3: 운동 기록 앱으로 줄이기

운동 기록 앱도 욕심내기 쉬운 주제입니다. 운동 추천, 식단 분석, 체중 변화, 사진 기록, AI 코치, 친구 경쟁 기능까지 떠오릅니다. 하지만 초보자의 첫 앱으로는 "오늘 한 운동을 저장하고 다시 보는 앱"이면 충분합니다.

사용자는 운동을 시작한 개인입니다. 문제는 이전 운동 기록을 기억하지 못한다는 것입니다. 첫 화면의 행동은 오늘 한 운동을 기록하는 것입니다.

저는 운동을 막 시작한 사람입니다. 오늘 한 운동을 기록하고 지난 기록을 확인하는 개인용 웹앱을 만들고 싶습니다.

앱의 목적은 운동 기록을 잊지 않고 쌓아가는 것입니다.

필요한 기능은 다음과 같습니다.
1. 사용자가 날짜, 운동 이름, 세트 수, 반복 횟수, 무게, 메모를 입력한다.
2. 입력한 운동 기록은 저장된다.
3. 저장된 기록은 최신순으로 목록에 표시된다.
4. 운동 이름으로 기록을 검색할 수 있다.

화면 구성은 상단에 운동 기록 입력 폼, 하단에 최근 운동 기록 목록을 배치해주세요. 모바일에서 헬스장에서 바로 입력하기 쉽게 큰 버튼과 간단한 입력창을 사용해주세요.

첫 버전에서는 회원가입, 친구 공유, 식단 관리, 칼로리 계산, AI 운동 추천은 제외해주세요. MVP로 작게 만들어주세요.

이 정도면 첫 앱으로 충분합니다. 나중에 기록이 쌓이면 주간 통계, 운동별 최고 무게, 월간 운동 횟수 같은 기능을 추가할 수 있습니다. 하지만 처음부터 넣지 않아도 됩니다.

화면은 방의 배치도처럼 생각하세요

화면 구성을 어렵게 생각하지 않아도 됩니다. 앱 화면은 방의 배치도와 비슷합니다. 침대가 어디에 있고, 책상이 어디에 있고, 창문이 어디에 있는지 대략 정하는 것입니다. 처음부터 인테리어 잡지처럼 완벽할 필요는 없습니다.

초보자가 가장 많이 쓰는 화면 구조는 단순합니다. 위에는 입력 폼, 아래에는 목록. 왼쪽에는 필터, 오른쪽에는 결과. 상단에는 요약 카드, 하단에는 상세 목록. 이 정도만 알아도 많은 앱을 설명할 수 있습니다.

예를 들어 회의록 정리 앱이라면 상단에는 회의 제목과 메모 입력창이 있고, 하단에는 저장된 회의록 목록이 있을 수 있습니다. 블로그 글감 저장소 앱이라면 왼쪽에는 카테고리 필터가 있고, 오른쪽에는 글감 카드 목록이 있을 수 있습니다. 가족 일정 공유 앱이라면 상단에는 이번 주 일정 요약이 있고, 하단에는 날짜별 일정 목록이 있을 수 있습니다.

AI에게 화면을 요청할 때는 "예쁘게 해줘"보다 "어디에 무엇을 배치할지"를 말하는 편이 좋습니다.

화면 상단에는 이번 달 요약 정보를 카드 3개로 보여주세요. 그 아래에는 새 기록을 입력하는 폼을 배치하고, 가장 아래에는 저장된 기록 목록을 최신순으로 보여주세요. 모바일에서는 카드가 한 줄에 하나씩 보이게 해주세요.

이렇게 말하면 디자인 요청이 아니라 구조 요청이 됩니다. 구조가 잡히면 디자인은 나중에 다듬을 수 있습니다.

바로 써먹는 변환 공식

불편함을 기능으로 바꿀 때는 아래 공식을 사용해보세요.

[사용자]는 [상황]에서 [불편함]을 겪는다.
그래서 이 앱은 [사용자]가 [입력값]을 입력할 수 있게 한다.
앱은 [저장값]을 저장하고,
사용자에게 [출력값]을 [화면 방식]으로 보여준다.
첫 버전에서는 [제외할 기능]을 넣지 않는다.

예를 들어 블로그 글감 저장소 앱이라면 이렇게 됩니다.

블로거는 아이디어가 떠올랐을 때 메모를 흩어져서 저장하는 불편함을 겪는다.
그래서 이 앱은 블로거가 글감 제목, 키워드, 메모, 카테고리를 입력할 수 있게 한다.
앱은 글감 정보를 저장하고,
사용자에게 카테고리별 글감 목록과 검색 결과를 카드 형태로 보여준다.
첫 버전에서는 AI 글쓰기, 이미지 생성, 자동 발행 기능을 넣지 않는다.

이 문장만 있어도 앱 생성 프롬프트의 절반은 완성된 셈입니다.

실습: 내 불편함 하나를 앱 문장으로 바꾸기

이제 직접 해볼 차례입니다. 아래 질문에 답해보세요. 답은 짧아도 괜찮습니다. 중요한 것은 머릿속에 둥둥 떠다니던 불편함을 문장으로 꺼내는 것입니다.

1. 이 앱은 누가 쓰나요?

2. 그 사람은 언제 불편함을 느끼나요?

3. 무엇이 흩어져 있거나 반복되거나 귀찮나요?

4. 사용자는 앱에 무엇을 입력해야 하나요?

5. 앱은 무엇을 저장해야 하나요?

6. 사용자는 나중에 무엇을 다시 보고 싶어 하나요?

7. 첫 화면에서 가장 먼저 해야 할 행동은 무엇인가요?

8. 첫 버전에서 빼도 되는 기능은 무엇인가요?

답을 적었다면 아래 템플릿에 넣어보세요.

저는 [나의 역할]입니다. [사용자]를 위한 [앱 종류]를 만들고 싶습니다.

이 앱의 목적은 [해결하고 싶은 불편함]을 줄이는 것입니다.

사용자는 [입력값 1], [입력값 2], [입력값 3]을 입력합니다.
앱은 이 정보를 저장하고, [출력값]을 [목록/카드/달력/표] 형태로 보여줍니다.

첫 화면에는 [가장 중요한 행동]을 할 수 있는 영역을 먼저 보여주세요.
필요한 기능은 다음과 같습니다.
1. [기능 1]
2. [기능 2]
3. [기능 3]

디자인은 [원하는 분위기]로 해주세요.
첫 버전에서는 [제외할 기능]은 넣지 말아주세요.
MVP로 작게 만들어주세요.

이 템플릿은 앞으로 여러 실습에서 계속 사용할 수 있습니다. 독서 기록 앱, 할 일 관리 앱, 강의 후기 수집 앱, 예약 문의 앱, 운동 루틴 기록 앱 모두 이 구조로 시작할 수 있습니다.

흔한 실수 1: 감정만 말하고 행동을 말하지 않는다

초보자가 자주 하는 요청은 이런 식입니다.

업무가 너무 정신없어서 정리해주는 앱을 만들어줘.

사람끼리는 어느 정도 공감할 수 있지만, 앱을 만들기에는 정보가 부족합니다. 무엇을 정리해야 하는지, 사용자가 무엇을 입력하는지, 결과를 어떻게 보여줘야 하는지 알 수 없습니다.

이럴 때는 행동을 추가해야 합니다.

업무 요청을 정리하는 앱을 만들고 싶습니다. 사용자는 요청 제목, 요청자, 마감일, 우선순위, 진행 상태를 입력합니다. 앱은 업무 요청을 저장하고, 마감일이 가까운 순서로 목록을 보여줍니다. 상태는 '대기', '진행 중', '완료'로 바꿀 수 있게 해주세요.

불편한 감정은 출발점입니다. 하지만 AI가 앱을 만들 수 있게 하려면 행동으로 바꿔야 합니다.

흔한 실수 2: 첫 버전부터 모든 기능을 넣는다

또 다른 실수는 처음부터 너무 많은 기능을 요구하는 것입니다.

예약 앱을 만들어줘. 로그인, 결제, 문자 알림, 캘린더 연동, 고객 관리, 리뷰 관리, 쿠폰 발급, 관리자 통계까지 다 넣어줘.

이런 요청은 초보자에게 위험합니다. AI가 어느 정도 만들어줄 수는 있지만, 오류가 생겼을 때 어디서 문제가 생겼는지 알기 어렵습니다. 결제, 로그인, 권한 관리, 외부 연동은 난이도가 높은 편입니다. 작동하는 것과 서비스로 운영 가능한 것은 다릅니다.

처음에는 이렇게 줄이는 편이 좋습니다.

첫 버전에서는 고객이 예약 문의를 남기고, 운영자가 문의 목록을 확인하는 기능까지만 만들어주세요. 로그인, 결제, 문자 알림, 캘린더 연동은 나중 버전으로 미뤄주세요.

AI에게 한 번에 완벽한 앱을 요구하지 마세요. 대화하며 고쳐나가는 것이 바이브 코딩의 기본 방식입니다.

흔한 실수 3: 화면을 설명하지 않는다

기능만 적고 화면을 설명하지 않으면 결과물이 어색해질 수 있습니다.

운동 기록을 저장하고 목록을 보여주는 앱을 만들어줘.

이 요청도 나쁘지는 않지만, 화면 배치가 빠져 있습니다. 조금만 더 설명하면 결과가 좋아집니다.

화면 상단에는 오늘 운동을 입력하는 폼을 배치하고, 하단에는 최근 운동 기록 목록을 보여주세요. 각 기록은 카드 형태로 표시하고, 날짜, 운동 이름, 세트 수, 메모가 보이게 해주세요. 모바일에서 한 손으로 입력하기 쉽게 버튼을 크게 만들어주세요.

화면 설명은 디자이너만 하는 일이 아닙니다. 비개발자도 "위에 무엇이 있고, 아래에 무엇이 있으면 좋겠다" 정도는 충분히 말할 수 있습니다. 그 정도면 AI에게 큰 도움이 됩니다.

고치는 방법: AI에게 먼저 질문하게 하기

내가 무엇을 빠뜨렸는지 모르겠다면, AI에게 바로 만들라고 하지 말고 질문부터 하게 만들면 됩니다. 이 방법은 매우 유용합니다.

아래 앱 아이디어를 바로 만들지 말고, 먼저 부족한 정보를 질문해주세요.

앱 아이디어: [여기에 아이디어 입력]

질문은 다음 기준으로 해주세요.
1. 사용자가 누구인지
2. 사용자가 입력해야 할 정보가 무엇인지
3. 앱이 저장해야 할 정보가 무엇인지
4. 화면에 보여줘야 할 정보가 무엇인지
5. 첫 버전에서 제외할 기능이 무엇인지
6. 개인정보나 보안상 조심해야 할 점이 있는지

질문은 초보자가 답하기 쉽게 쉬운 말로 해주세요.

이 프롬프트를 쓰면 AI가 기획 코치처럼 질문을 던져줍니다. 질문에 답하다 보면 내 아이디어도 자연스럽게 정리됩니다. 바이브 코딩에서 중요한 능력은 모든 것을 처음부터 완벽하게 아는 것이 아닙니다. 모르는 것을 질문으로 바꾸고, 답하면서 점점 선명하게 만드는 능력입니다.

이번 장의 체크리스트

불편함을 기능으로 바꾸기 전에 아래 항목을 확인해보세요.

• 이 앱을 쓸 사람을 한 문장으로 말할 수 있는가?

• 사용자가 겪는 불편함을 구체적인 상황으로 설명할 수 있는가?

• 사용자가 입력할 정보를 3~6개 정도로 정리했는가?

• 앱이 저장해야 할 정보와 저장하지 않아도 되는 정보를 구분했는가?

• 사용자가 다시 보고 싶은 결과를 정했는가?

• 첫 화면에서 가장 중요한 행동 하나를 골랐는가?

• 첫 버전에서 제외할 기능을 정했는가?

• 기능을 "입력한다, 저장한다, 보여준다, 수정한다"처럼 동사로 썼는가?

• 로그인, 결제, 알림, 외부 연동처럼 어려운 기능을 무리하게 넣지 않았는가?

• 앱 빌더에게 넣을 수 있는 첫 프롬프트 문장으로 바꿨는가?

한 장 요약

불편함은 앱 아이디어의 출발점이지만, 그 자체로는 아직 앱이 아닙니다. 앱으로 만들려면 사용자의 행동을 문장으로 바꿔야 합니다. 핵심 질문은 간단합니다. 사용자는 무엇을 입력하고, 앱은 무엇을 저장하고, 다시 무엇을 보여주는가?

입력값은 사용자가 적는 정보입니다. 저장값은 앱이 기억해두는 정보입니다. 출력값은 사용자가 화면에서 다시 확인하는 정보입니다. 이 세 가지를 구분하면 AI에게 훨씬 정확하게 요청할 수 있습니다.

강의 후기 수집 앱은 후기를 입력하고 목록과 평균을 보는 앱으로 줄일 수 있습니다. 예약 문의 앱은 결제 시스템이 아니라 문의를 한곳에 모으고 상태를 바꾸는 앱으로 시작할 수 있습니다. 운동 기록 앱은 AI 코치가 아니라 오늘 한 운동을 저장하고 최근 기록을 보는 앱으로 충분합니다.

첫 앱은 작을수록 좋습니다. 큰 아이디어를 첫 화면 하나로 줄이세요. 첫 화면에서 사용자가 해야 할 행동 하나를 정하세요. 그리고 나머지는 나중으로 미루세요.

바이브 코딩은 AI에게 "멋진 앱 만들어줘"라고 맡기는 일이 아닙니다. 내가 원하는 것을 AI가 이해할 수 있게 설명하는 일입니다. 그 설명은 불편함을 기능 문장으로 바꾸는 순간부터 시작됩니다.