바이브 코딩 실전 4화: 만들고 싶은 기능부터 적으면 실패합니다

지난 편에서는 AI 코딩 에이전트를 고르는 기준을 살펴봤습니다.

이제 도구도 어느 정도 정했습니다.

AI도 준비됐습니다.

드디어 만들고 싶은 앱의 기능을 적어볼 차례입니다.

그런데 여기서 조금 이상한 이야기를 하나 해보겠습니다.

처음에는 기능을 많이 적으면 안 됩니다.

보통 앱 기획이라고 하면 이런 식으로 시작하기 쉽습니다.

그리고 생각나는 대로 적습니다.

회원가입로그인사진 업로드검색태그카테고리댓글좋아요알림공유다크모드백업통계AI 추천친구 기능관리자 페이지...

잠깐.

우리는 아직 첫 화면도 만들지 않았습니다. 😅

그런데 머릿속 앱은 벌써 시리즈 B 투자를 받은 스타트업이 되어 있습니다.

바이브 코딩에서는 특히 이런 일이 자주 생깁니다.

왜냐하면 기능을 추가하는 비용이 너무 싸게 느껴지기 때문입니다.

AI에게 한마디만 하면 되니까요.

문제는 요청은 한 문장이지만, 실제 제품에서는 그 기능이 혼자 오지 않는다는 것입니다.

1. 기능 하나는 혼자 오지 않는다

예를 들어 MyLog 앱에 사진 첨부 기능을 넣는다고 해보겠습니다.

겉으로 보면 단순합니다.

하지만 실제로는 뒤에 작은 친구들이 줄줄이 따라옵니다.

사진 선택 기능

카메라 권한

사진 저장 위치

파일 업로드

업로드 실패 처리

파일 크기 제한

이미지 압축

삭제 처리

네트워크 오류

사진 접근 권한 안내

개인정보 관련 검토

갑자기 일이 불어납니다.

사진 하나가 들어왔을 뿐인데 프로젝트 안에서는 작은 이삿짐 트럭이 들어온 셈입니다. 📦

이게 제품 개발에서 기능을 조심해서 추가해야 하는 이유입니다.

2. 첫 앱의 목표부터 다시 정하자

이번 연재에서 만들 첫 앱은 MyLog입니다.

MyLog의 아이디어는 아주 단순합니다.

여기서 가장 먼저 해야 하는 질문은

"어떤 기능을 넣을까?"

가 아닙니다.

이 질문부터 해야 합니다.

MyLog라면 답은 꽤 단순합니다.

기록을 작성할 수 있어야 하고,

저장할 수 있어야 하고,

저장한 기록을 다시 볼 수 있어야 합니다.

끝입니다.

조금 허전한가요?

좋습니다.

MVP는 처음에 조금 허전한 것이 정상입니다.

3. MVP는 작은 제품이 아니라 작은 검증이다

MVP는 Minimum Viable Product의 약자입니다.

보통 한국어로는 최소 기능 제품 정도로 번역합니다.

이 말을 들으면 많은 사람이 이렇게 생각합니다.

틀린 말은 아닙니다.

하지만 저는 이번 연재에서 조금 다르게 접근하려고 합니다.

MVP의 핵심은

"최소한의 기능을 가진 제품"

이라기보다

"가장 작은 비용으로 가장 중요한 가정을 확인하는 것"

에 가깝습니다.

MyLog의 첫 번째 가정은 이것입니다.

그걸 확인하는 데 알림 기능이 필요할까요?

아닙니다.

친구 추가는?

필요 없습니다.

AI 요약 기능은?

멋있지만 지금은 필요 없습니다.

이 단계에서 그것들은 기능이 아니라 소음에 가깝습니다.

4. 기능을 세 종류로 나눠보자

비개발자가 앱의 범위를 줄일 때 가장 쉬운 방법이 있습니다.

기능을 세 바구니로 나누는 것입니다.

이 기능이 없으면 앱의 핵심 목적 자체가 성립하지 않습니다.

MyLog에서는

기록 작성

기록 저장

기록 목록 보기

기록 상세 보기

정도입니다.

이 네 가지는 MVP에 남깁니다.

없어도 앱은 사용할 수 있지만 있으면 훨씬 편해집니다.

예를 들면

검색

태그

카테고리

정렬

즐겨찾기

다크모드

정도입니다.

좋습니다.

다 하고 싶습니다.

하지만 지금은 보류합니다.

여기부터는 아이디어 창고입니다.

AI 요약

감정 분석

친구와 공유

위치 기반 기록

사진 자동 정리

통계

캘린더

백업

푸시 알림

여기에 넣습니다.

삭제하지는 않습니다.

그냥 지금 만들지 않을 뿐입니다.

이 구분이 중요합니다.

기능을 버린다고 생각하면 아깝습니다.

하지만 백로그에 넣는다고 생각하면 마음이 한결 편해집니다.

5. MyLog 첫 버전을 진짜 작게 만들어보자

그러면 MyLog의 첫 번째 버전을 이렇게 정의해보겠습니다.

사용자는 새 기록을 작성할 수 있다.

작성한 기록은 저장된다.

저장한 기록은 목록에서 볼 수 있다.

목록의 기록을 누르면 내용을 다시 볼 수 있다.

딱 여기까지입니다.

기능으로 쓰면 이렇게 됩니다.

MyLog MVP

1. 기록 목록 보기
2. 새 기록 작성하기
3. 기록 저장하기
4. 기록 상세 보기

정말 작습니다.

하지만 중요한 것은

이 네 가지가 처음부터 끝까지 끊기지 않고 동작하는가

입니다.

6. 로그인은 왜 빼나요?

여기서 아마 이런 질문이 나올 수 있습니다.

나중에는 필요할 수 있습니다.

하지만 첫 MVP에서는 없어도 됩니다.

우리는 처음에는 기록을 스마트폰 내부에 저장할 수 있습니다.

그러면

회원가입 서버도 필요 없고,

로그인도 필요 없고,

비밀번호 처리도 필요 없고,

사용자별 권한 처리도 필요 없습니다.

이렇게 되면 처음 앱을 완성하는 데 필요한 작업이 크게 줄어듭니다.

그리고 더 중요한 장점이 하나 있습니다.

문제가 발생했을 때 원인을 찾기 쉬워집니다.

처음부터 로그인, DB, 서버, 클라우드까지 붙이면 문제가 어디서 발생했는지 구분하기 어려워집니다.

반면 작은 앱은 구조도 작습니다.

작은 구조는 비개발자에게 최고의 디버깅 선생님입니다.

7. 처음부터 '최종 버전'을 만들려고 하지 말자

바이브 코딩에서 자주 보는 프롬프트가 있습니다.

개인 기록 앱을 만들어줘.

회원가입과 로그인 기능이 있고
사진을 첨부할 수 있으며
카테고리와 태그를 지원하고
검색과 필터 기능이 있으며
데이터는 Supabase에 저장하고
다크모드와 알림을 지원하고
예쁜 UI로 만들어줘.

AI 입장에서는 꽤 많은 요구사항입니다.

겉으로는 멋진 결과가 나올 수도 있습니다.

문제는 우리가 그 결과물을 이해하기 어렵다는 것입니다.

파일은 여러 개 생기고,

패키지도 많이 추가되고,

DB 구조도 만들어지고,

인증도 들어가고,

상태 관리도 들어갑니다.

그리고 어느 날 작은 수정 하나를 요청합니다.

그러자 엉뚱한 곳이 망가집니다.

왜?

처음부터 구조가 너무 커서 우리가 전체를 이해하지 못했기 때문입니다.

바이브 코딩은 AI가 빠르기 때문에 작게 만드는 것이 더 중요합니다.

빠르게 만들 수 있으니까 기능을 늘리는 것이 아니라,

빠르게 만들 수 있으니까 작게 만들고 확인하고 다음 단계로 넘어가는 것이 좋습니다.

8. 화면도 먼저 줄여보자

기능만 줄이는 것이 아닙니다.

화면 수도 줄일 수 있습니다.

MyLog MVP는 세 화면이면 충분합니다.

[기록 목록]

↓

[기록 작성]

↓

[기록 상세]

설정 화면?

아직 없습니다.

프로필?

없습니다.

로그인?

없습니다.

온보딩 화면?

없습니다.

심지어 처음에는 검색창도 없습니다.

지금 중요한 것은

기록을 작성하고 다시 읽을 수 있는 흐름

하나입니다.

9. 사용자의 한 문장으로 범위를 정하는 방법

제가 추천하는 방법이 하나 있습니다.

앱의 첫 번째 사용 경험을 한 문장으로 설명해보는 것입니다.

MyLog라면 이렇게 말할 수 있습니다.

이 한 문장에 포함되지 않는 기능은 일단 MVP에서 제외하는 것입니다.

예를 들어

"친구에게 공유한다."

없습니다.

"알림을 받는다."

없습니다.

"AI가 요약해준다."

없습니다.

아주 냉정합니다. ✂️

하지만 이 방법을 사용하면 범위가 놀랄 정도로 빨리 정리됩니다.

10. 좋은 MVP는 데모가 아니라 흐름이 완성되어야 한다

여기서 또 하나 조심해야 할 점이 있습니다.

기능을 줄인다고 해서 가짜 앱을 만들자는 것은 아닙니다.

예를 들어 저장 버튼을 눌렀더니 화면에

라고만 뜨고 실제 데이터는 저장되지 않는다면 그것은 MVP라기보다 화면 데모에 가깝습니다.

우리의 MyLog MVP는 작지만 실제로 동작해야 합니다.

작성
↓
저장
↓
앱 종료
↓
다시 실행
↓
기록이 그대로 존재

여기까지 확인할 겁니다.

기능 개수는 적지만 한 기능의 시작과 끝은 제대로 만들겠습니다.

이게 앞으로 우리가 계속 유지할 원칙입니다.

넓게 만들지 말고 깊게 완성한다.

11. AI에게도 한 번에 하나씩 시키자

범위를 줄였다고 해서 AI에게 네 가지 기능을 한꺼번에 시킬 필요도 없습니다.

조금 더 잘게 나눕니다.

예를 들어 이런 순서로 진행할 수 있습니다.

1단계

기록 목록 화면만 만들어줘.
아직 저장 기능은 만들지 마.

화면을 확인합니다.

그다음

2단계

새 기록 작성 화면을 추가해줘.
제목과 내용을 입력할 수 있게 해줘.

다시 확인합니다.

그다음

3단계

작성한 기록을 로컬에 저장하도록 만들어줘.

그리고

4단계

저장된 기록을 목록에서 누르면
상세 내용을 볼 수 있게 해줘.

이런 식입니다.

각 단계가 작기 때문에 문제가 생겨도 어디에서 문제가 생겼는지 추적하기 쉽습니다.

12. AI에게 '하지 말 것'도 알려줘야 한다

비개발자가 자주 놓치는 부분입니다.

AI에게 요구사항만 알려주는 것보다

이번 단계에서 하지 않을 것

도 명시하면 결과가 좋아집니다.

예를 들어

이번 단계에서는 기록 앱의 MVP만 만든다.

구현할 기능
- 기록 목록
- 기록 작성
- 기록 저장
- 기록 상세 보기

이번 단계에서 구현하지 않을 기능
- 로그인
- 회원가입
- 클라우드 동기화
- 사진 첨부
- 검색
- 태그
- 알림
- AI 기능

이렇게 적습니다.

AI는 친절해서 가끔 우리가 부탁하지 않은 것도 넣어줍니다.

문제는 그 친절이 프로젝트에서는 기능성 과잉 서비스가 될 수 있다는 점입니다.

"예쁘게 해줘"라고 했더니 애니메이션 라이브러리 세 개가 들어오는 날도 생깁니다. 🎁

그래서 범위를 제한하는 문장도 중요합니다.

13. 기능 우선순위를 정할 때 물어볼 네 가지 질문

앞으로 새로운 기능을 추가하고 싶어질 때마다 이 네 가지를 물어보겠습니다.

YES라면 MVP 후보입니다.

"나중에 있으면 멋질 것 같다"면 뒤로 보냅니다.

예를 들어 사진 기능 때문에 Storage, 권한, 업로드 처리가 추가된다면 생각보다 큰 기능입니다.

YES라면 꽤 높은 확률로 빼도 됩니다.

첫 번째 앱의 가장 중요한 목표는 기능 수가 아닙니다.

완성 경험입니다.

14. 비개발자에게 '완성 경험'이 중요한 이유

처음 바이브 코딩을 시작한 사람이 가장 많이 만나는 프로젝트는 아마 이런 모습일 겁니다.

my-awesome-app

my-awesome-app-v2

my-awesome-app-final

my-awesome-app-final-real

my-awesome-app-final-real-2

폴더만 늘어납니다. 😇

기능은 많지만 어디까지 되는지 잘 모릅니다.

결국 새 프로젝트를 시작합니다.

이 패턴을 끊어야 합니다.

작더라도

기획하고,

만들고,

테스트하고,

실제 스마트폰에서 실행하고,

배포까지 해보는 경험

한 번이 훨씬 중요합니다.

그래야 두 번째 앱부터 속도가 붙습니다.

15. MyLog의 버전 로드맵을 만들어보자

기능을 버린 것은 아닙니다.

순서를 만든 것입니다.

예를 들면 이렇게 발전시킬 수 있습니다.

MyLog v0.1

기록 작성
기록 저장
목록
상세 보기

그다음

MyLog v0.2

수정
삭제
검색

그리고

MyLog v0.3

회원가입
로그인
클라우드 저장

그다음에는

MyLog v0.4

사진 첨부
태그
카테고리

그리고 필요하다면

MyLog v1.0

스토어 출시

이렇게 제품은 한 번에 완성되는 것이 아니라 조금씩 자랍니다.

처음부터 성인 앱을 낳으려고 하지 말고 새싹부터 키우는 편이 낫습니다. 🌱

16. 오늘의 삽질 방지 팁 🛠️

AI에게 새로운 기능을 요청하기 전에 한 줄만 추가해보세요.

그리고 큰 기능이라면 바로 코딩시키지 말고

라고 요청해보세요.

바이브 코딩에서는 코드 작성 속도보다

변경 범위를 통제하는 능력

이 점점 중요해집니다.

AI는 5분 만에 20개 파일을 수정할 수 있습니다.

우리에게 필요한 능력은 그 5분을 더 빠르게 만드는 것이 아니라,

정말 20개 파일을 수정해야 하는지 먼저 판단하는 것입니다.

17. 오늘 MyLog에서 결정한 것

이제 첫 번째 앱의 범위를 확정해보겠습니다.

기록 목록

기록 작성

로컬 저장

기록 상세 보기

로그인

회원가입

클라우드

사진 첨부

검색

태그

알림

공유

AI 기능

통계

친구 기능

다크모드

삭제된 것이 많아 보입니다.

하지만 덕분에 우리가 실제로 완성할 가능성은 훨씬 높아졌습니다.

18. 기능을 적기 전에 버릴 기능부터 정하자

바이브 코딩이 쉬워질수록 기능을 추가하는 유혹은 더 커질 겁니다.

AI에게 한 줄만 말하면 무엇이든 만들어줄 것처럼 보이기 때문입니다.

하지만 제품 개발에서 중요한 질문은 여전히 같습니다.

보다

입니다.

첫 앱에서는 완벽한 앱을 목표로 하지 않겠습니다.

대신

작지만 끝까지 완성할 수 있는 앱

을 만들겠습니다.

그리고 MVP가 실제로 동작하면 그다음 기능을 하나씩 추가하겠습니다.

그게 결국 가장 빠른 길입니다.

조금 아이러니하지만,

바이브 코딩에서 속도를 높이는 가장 좋은 방법 중 하나는

기능을 덜 만드는 것입니다.

이제 무엇을 만들지 정했습니다.

다음 단계는 AI에게

라고 말하는 것이 아닙니다.

AI가 엉뚱한 방향으로 가지 않도록 요구사항을 문서로 정리하는 작업을 해보겠습니다.

다음 편에서는 MyLog의 실제 개발에 사용할 작은 PRD를 만들어봅니다.

[바이브 코딩 실전 #05] AI가 딴 길로 새지 않는 PRD 만들기 | 요구사항과 완료 조건 작성법

여기서부터는 우리가 만든 기획 문서가 이후 AI와 대화할 때 계속 기준점으로 사용됩니다.

AI에게 코드를 잘 쓰게 만드는 첫 번째 방법은 의외로 코딩 프롬프트가 아닙니다.

무엇을 만들어야 하는지 애매하지 않게 적는 것입니다.

#바이브코딩 #VibeCoding #AI코딩 #비개발자앱개발 #MVP #MVP개발 #앱기획 #서비스기획 #PRD #AI에이전트 #비개발자개발 #앱개발 #기능정의 #프로덕트개발 #MyLog #바이브코딩실전