바이브코딩 입문 4편: 아이디어를 기능 목록으로 쪼개는 법
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받을 수 있습니다.
바이브코딩을 처음 해보면 제일 먼저 막히는 지점이 있다. 코드를 몰라서가 아니라, 만들고 싶은 것을 너무 크게 말해서 그렇다.
예를 들어 “영상 제작을 편하게 해주는 서비스를 만들고 싶다”라고 말하면 AI코딩 도구도 꽤 그럴듯한 답을 준다. 그런데 바로 앱을 만들기 시작하면 금방 흐름이 꼬인다. 화면은 생겼는데 버튼이 무엇을 해야 하는지 애매하고, 저장은 되는지 안 되는지 모르겠고, 어느 순간 내가 뭘 만들고 있었는지도 헷갈린다.
그래서 이번 편은 코딩 자체보다 앞단 이야기다. 아이디어를 도구가 알아들을 수 있는 기능 목록으로 쪼개는 방법이다. 이걸 해두면 안티그래비티든 커서든 v0든 어떤 도구를 쓰더라도 대화가 훨씬 덜 흔들린다.
먼저 만들 것은 서비스가 아니라 한 장짜리 사용 흐름이다
처음부터 “완성된 서비스”를 상상하면 일이 커진다. 대신 사용자가 들어와서 나갈 때까지 딱 한 번의 흐름만 적어보는 편이 좋다.
예를 들어 영상 제작자를 위한 작은 도구를 만든다고 해보자. 처음 버전은 이 정도면 충분하다.
- 사용자가 프로젝트 이름을 입력한다.
- 촬영 전 체크리스트를 만든다.
- 필요한 컷을 장면별로 정리한다.
- 촬영이 끝난 컷은 완료 표시를 한다.
- 전체 진행률을 한눈에 본다.
이 정도만 있어도 이미 앱의 뼈대가 나온다. 중요한 건 “멋진 플랫폼”이 아니라 “오늘 내가 실제로 눌러볼 수 있는 흐름”을 잡는 것이다.
내가 Prepro Studio 같은 작업을 생각할 때도 출발점은 거창한 제작 관리 시스템이 아니었다. 혼자 영상 만들 때 매번 머릿속에 흩어지는 준비물, 컷, 체크리스트를 한곳에 모으고 싶었다. 이 정도로 작게 잡아야 AI코딩 도구에도 정확히 일을 시킬 수 있다.
기능은 명사보다 동사로 적는 게 잘 먹힌다
초보자가 자주 하는 실수는 기능을 명사로만 적는 것이다.
“대시보드”, “프로젝트”, “체크리스트”, “캘린더”처럼 적으면 있어 보이긴 한다. 그런데 도구 입장에서는 정확히 뭘 구현해야 하는지 모호하다.
조금 더 좋은 방식은 동사로 적는 것이다.
- 프로젝트를 새로 만든다.
- 장면을 추가한다.
- 컷마다 필요한 소품을 적는다.
- 촬영 완료 여부를 체크한다.
- 오늘 해야 할 컷만 따로 본다.
이렇게 쓰면 화면 구조도 자연스럽게 따라온다. “프로젝트를 새로 만든다”가 있으면 입력창과 저장 버튼이 필요하고, “오늘 해야 할 컷만 본다”가 있으면 필터나 탭이 필요하다. AI코딩 도구에 맡길 때도 훨씬 명확하다.
AI코딩 도구에 바로 던질 수 있는 프롬프트 형태
기능 목록을 만들었다면 다음은 AI코딩 도구에 줄 문장으로 바꾸면 된다. 너무 예쁘게 쓸 필요 없다. 대신 조건이 구체적이어야 한다.
아래처럼 말하면 된다.
영상 제작 준비를 돕는 작은 웹앱을 만들고 싶어. 첫 버전은 프로젝트 이름을 만들고, 장면별 컷 리스트를 추가하고, 각 컷에 필요한 준비물과 촬영 완료 여부를 체크하는 기능만 있으면 돼. 첫 화면에서 오늘 촬영할 컷과 전체 진행률이 보이게 해줘. 디자인은 복잡하지 않게, 혼자 쓰는 작업 도구처럼 만들어줘.
이 정도면 도구가 바로 화면을 만들기 시작할 수 있다. 여기서 더 중요한 건 한 번에 완성하려고 하지 않는 것이다. 첫 결과물이 나오면 “이 버튼은 너무 크다”, “체크리스트가 아래로 밀린다”, “모바일에서 컷 목록이 너무 답답하다”처럼 하나씩 고치면 된다.
처음부터 완벽한 프롬프트를 쓰는 사람은 거의 없다. 실제 작업은 첫 답변을 받고 나서 다듬는 쪽에 가깝다.
막힐 때는 기능을 더 줄이는 게 빠르다
바이브코딩을 하다 보면 어느 순간 도구가 엉뚱한 걸 만들기 시작한다. 그럴 때는 설명을 더 길게 붙이는 것보다 기능을 줄이는 편이 낫다.
예를 들어 처음부터 로그인, 결제, 공유, 이미지 업로드, 자동 저장을 다 넣으려고 하면 초보 단계에서는 관리하기 어렵다. 우선은 로컬에서 혼자 쓰는 버전으로 잡아도 된다.
첫 버전 기준은 이렇게 생각하면 편하다.
- 로그인은 나중에 붙인다.
- 결제는 당연히 나중이다.
- 공유 기능도 처음엔 빼도 된다.
- 데이터 저장은 브라우저 안에만 저장해도 된다.
- 화면은 2개보다 1개가 낫다.
이렇게 줄이면 결과물이 허술해지는 게 아니라, 오히려 완성 가능성이 올라간다. 일단 눌러지는 도구가 생기면 그 다음 개선은 훨씬 쉽다.
내가 만든 것을 소개하고 싶다면 기록부터 남긴다
바이브코딩으로 뭔가를 만들기 시작했다면, 결과물만 보여주기보다 과정도 같이 적어두는 게 좋다. 나중에 블로그 글로 풀기도 좋고, 같은 문제를 겪는 사람에게 도움이 된다.
기록은 복잡할 필요 없다.
- 처음 만들고 싶었던 이유
- 첫 번째로 만든 기능
- 막혔던 부분
- AI코딩 도구에 다시 요청한 문장
- 다음에 고치고 싶은 것
이 다섯 가지만 적어도 충분하다. 특히 “AI코딩 도구에 다시 요청한 문장”은 남겨두는 편이 좋다. 나중에 비슷한 앱을 만들 때 그대로 재사용할 수 있다.
Prepro Studio 같은 프로젝트도 결국 이런 식으로 쌓인다. 처음부터 거대한 제품처럼 접근하기보다, 내가 실제로 겪는 불편을 하나씩 도구로 바꾸는 식이다. 이게 일반인이 바이브코딩을 써먹기 가장 현실적인 방향이라고 본다.
따라 해볼 순서
오늘 바로 해보고 싶다면 순서는 이렇다.
1. 만들고 싶은 도구를 한 문장으로 적는다.
2. 사용자가 처음 누르는 행동부터 마지막 행동까지 적는다.
3. 기능을 동사로 5개만 적는다.
4. 로그인, 결제, 공유처럼 큰 기능은 일단 뺀다.
5. AI코딩 도구에 “첫 버전만 만들어줘”라고 요청한다.
6. 나온 결과를 보고 한 번에 하나씩 수정한다.
이 순서대로 하면 적어도 시작은 된다. 코딩 지식보다 중요한 건 “무엇을 만들지 작은 단위로 말하는 능력”이다.
궁금할 수 있는 점
Q. 처음부터 예쁜 디자인을 요청해도 될까?
가능은 하다. 다만 초반에는 예쁜 화면보다 눌렀을 때 일이 되는지가 먼저다. 기능이 잡힌 뒤 디자인을 고치는 편이 덜 피곤하다.
Q. 기능 목록은 몇 개가 적당할까?
처음에는 5개 안팎이 좋다. 10개가 넘어가면 도구도 방향을 놓치기 쉽고, 내가 검수하기도 어려워진다.
Q. 내가 개발자가 아니어도 이런 식으로 계속 만들 수 있을까?
가능하다. 대신 “도구가 알아서 다 해주겠지”보다는 내가 원하는 흐름을 계속 설명해주는 역할은 해야 한다. 바이브코딩에서 사람의 역할은 코드를 직접 치는 것보다 방향을 잡고 검수하는 쪽에 가깝다.
3줄 요약
- 바이브코딩은 큰 아이디어를 바로 앱으로 만들기보다 작은 사용 흐름으로 쪼갤 때 잘 된다.
- 기능은 “대시보드” 같은 명사보다 “컷을 추가한다”처럼 동사로 적는 편이 좋다.
- 처음엔 로그인, 결제, 공유를 빼고 혼자 눌러볼 수 있는 첫 버전부터 만드는 게 현실적이다.