Part 1.2 - 문제 정의: 6W로 내 아이디어 구체화하기

"할 일 관리 앱 만들어줘"

이렇게 시작하시는 분들 정말 많습니다. 근데 이게 왜 문제인지 아세요?

세상에 할 일 관리 앱이 몇 개나 있을까요? Todoist, Things, TickTick, Notion... 셀 수도 없이 많습니다. 그냥 "할 일 관리 앱"이라고 하면 AI는 이 중 아무거나 비슷하게 만들어줄 거에요

근데 여러분이 진짜 원하는 건 뭔가요?

혹시 기존 앱들이 마음에 안 들어서 직접 만들려는 거 아닌가요? 그렇다면 뭐가 마음에 안 들었는지, 어떻게 다르게 만들고 싶은지를 먼저 정리해야 합니다

오늘은 AI한테 코드를 요청하기 전에 꼭 해야 할 것, 바로 "문제 정의"에 대해 얘기해보겠습니다. 바이브코딩 연재물인데, 오늘은 살짝 기획쪽에 치우친 내용입니다. 제 지인 중 기획자분과 얘기하면서 어떻게 하면 비개발자분들, 처음 바이브코딩을 하는 분들에게 프로덕트를 잘 만드는 방법을 전달할 수 있을까? 로 나온 결론입니다. 모든 걸 다 적용할 필요는 없지만, 본인이 생각하기에 중요하다고 생각되는 걸 우선적으로 적용해보세요. 분명히 결과물이 달라질거라고 생각합니다

왜 문제 정의가 먼저인가요?

바이브코딩 실패의 대부분은 기술 문제가 아닙니다. "뭘 만들지 명확하지 않아서" 실패합니다

어떤 분이 "우리 팀 업무 관리 도구를 만들고 싶어요"라고 프롬프팅하셨어요. AI가 열심히 만들어줬어요. 근데 2주쯤 지나니까 이런 말씀을 하시더라고요.

"음... 이거 말고 채팅 기능도 있으면 좋겠는데요." "아, 모바일에서도 되면 좋겠어요." "파일 공유도 되면 안 되나요?" "캘린더 연동은요?"

결국 3개월이 지났는데도 완성을 못 하셨어요. 계속 새로운 게 추가되니까요.

처음에 "우리 팀이 정확히 뭘 필요로 하는지"를 제대로 정리했으면 이런 일이 없었을 거예요.

6W 질문법

그래서 저는 6W 질문법을 추천해요. 이거 거창한 게 아니에요. 그냥 여섯 가지 질문에 답하면서 아이디어를 구체화하는 방식입니다.

1. What (무엇을)

"정확히 무엇을 만들 건가요?"

이 질문이 제일 중요합니다. 바이브코딩 자체를 배우기 위해서 바이브코딩을 하는게 아니잖아요? 우리는 우리의 아이디어를 구현하기 위해서 프로덕트를 만들거고, 그럴려면 우리가 만드려는 프로덕트, 즉, '목적'을 정확히 하고 가야 합니다.

❌ "할 일 관리 앱" ❌ "쇼핑몰" ❌ "커뮤니티 사이트"

위는 목적이 아닙니다. 그냥 '목적'의 '성격'에 가깝습니다

✅ "마감일 기준으로 할 일을 자동 정렬해주는 앱" ✅ "수제 비누만 파는 소규모 쇼핑몰" ✅ "우리 동네 반려견 산책 친구를 찾는 커뮤니티"

차이가 느껴지시죠?

구체화하는 팁:

기존에 있는 앱/서비스랑 뭐가 다른지 써보세요
딱 한 문장으로 설명할 수 있어야 해요
"~하는 사람들을 위한 ~앱" 형식으로 써보세요

예시: "마감일을 자주 놓치는 프리랜서를 위한, 오늘 할 일만 딱 보여주는 초간단 투두 앱"

2. Why (왜)

"왜 이걸 만들어야 하나요?"

이 질문에 대한 답이 명확해야 합니다. 그냥 "재밌을 것 같아서"로는 부족해요. 이게 왜 중요하냐면, 결국 이게 에러가 터져도 계속 해결할 수 있게 하는 땔감이 됩니다. 동기죠. 강할 수록 좋습니다.

나한테 물어볼 것들:

기존 서비스들의 뭐가 불만인가요?
이게 없으면 뭐가 불편한가요?
다른 사람들도 같은 문제를 겪고 있나요?

실제 예시:

한 분이 식단 관리 앱을 만들고 싶다고 하셨어요. 왜냐고 물었더니:

"다이어트 앱들이 너무 복잡해요. 칼로리 계산하고, 영양소 분석하고... 저는 그냥 오늘 뭘 먹었는지 사진으로 기록만 하고 싶은데, 그런 단순한 앱이 없더라고요."

이거 좋은 "Why"예요. 문제가 명확하잖아요. "기존 앱들이 너무 복잡해서, 단순히 사진으로만 기록하는 앱이 필요하다."

Why가 명확하면 나중에 기능 추가할 때 기준이 생깁니다. "이 기능이 원래 목적에 맞나?" 하고 스스로 체크할 수 있죠.

3. Who (누구를 위해)

"누가 이걸 쓸 건가요?"

"모든 사람"은 답이 아닙니다. 모든 사람을 위한 제품은 아무도 위한 제품이 아닙니다

구체적으로 생각해보세요:

나이대는?
직업은?
어떤 상황에 있는 사람?
기술 수준은? (앱 잘 쓰는 사람? 어려워하는 사람?)

예시:

❌ "직장인들"

✅ "매일 야근하느라 운동할 시간이 없는 30대 IT 회사원. 점심시간에 10분이라도 스트레칭하고 싶은데, 뭘 해야 할지 모르는 사람."

이렇게 구체적으로 정하면 좋은 점이 있습니다

디자인할 때도 기준이 생기고, 기능 추가할 때도 "이 사람한테 정말 필요한가?" 물어볼 수 있어요.

4. When (언제)

"언제까지 만들 건가요?"

그리고 더 중요한 건, "언제 어떤 기능까지 만들 건가요?"

바이브코딩의 함정이 뭔지 기억나시죠? 처음엔 빠르다가 나중에 느려집니다. 그래서 시간 계획이 필요해요. 이미 시장은 포화상태일거고, 누가 먼저 출시하냐의 싸움일 수도 있습니다. 적정한 시간과 적정한 기능을 고려하세요.

현실적으로 계획 세우기:

1주차: 핵심 기능 하나만

예: "할 일 추가하고 완료 체크하는 것만"

2주차: 필수 기능 추가

예: "마감일 설정하고 정렬하는 것"

3주차: 있으면 좋은 기능

예: "카테고리 분류"

4주차: 다듬기 + 배포

예: "디자인 개선 + 실제로 올리기"

이렇게 해두면 좋아요. 2주 지났는데 아직 1주차 기능도 못 끝냈다? 그럼 계획을 줄여야 해요. 욕심 부리면 안 돼요.

핵심: 모든 기능을 다 넣으려고 하지 마세요. "이것만 되면 일단 쓸 수 있다"는 최소 기능(MVP)을 먼저 정하세요.

5. Where (어디서)

"어디서 쓸 건가요?"

이건 기술적인 결정에 영향을 줘요.

생각해볼 것들:

웹? 모바일 앱? 둘 다?
컴퓨터에서? 핸드폰에서?
혼자 쓸 건가요? 여러 사람이?
인터넷 없어도 돼야 하나요?

왜 이게 중요하냐면:

처음부터 "웹이랑 앱 둘 다"라고 하면 난이도가 확 올라가요. 비개발자가 처음 만드는 거라면 웹부터 시작하는 걸 강력 추천해요. 아니, 솔직히 웹도 필요 없다면 하지 마세요. 필요한 '그것'을 하세요.

그리고 "핸드폰에서 주로 쓸 건데 웹으로 만들어도 되나요?" 네, 됩니다. 반응형 웹으로 만들면 핸드폰에서도 잘 보여요. 진짜 앱처럼 다운받는 건 나중에 고민해도 돼요.

추천 순서:

웹 (반응형으로 핸드폰에서도 보이게)
잘 되면 그때 앱 고민

6. How (어떻게)

"어떻게 작동하나요?"

이건 사용자 입장에서 시나리오를 써보는 거예요.

예시: 식단 기록 앱

1. 앱을 열면 오늘 날짜가 보인다
2. "+" 버튼을 누르면 카메라가 켜진다
3. 음식 사진을 찍는다
4. "아침/점심/저녁" 중에 고른다
5. 저장 버튼을 누르면 오늘 기록에 추가된다
6. 메인 화면에서 오늘 먹은 것들을 사진으로 볼 수 있다
7. 날짜를 바꾸면 다른 날 기록도 볼 수 있다

이렇게 써보면 좋은 점이 뭐냐면, AI한테 요청할 때 이걸 그대로 주면 됩니다

"이 시나리오대로 작동하는 앱 만들어줘"

AI가 훨씬 정확하게 만들어줍니다. 뭔가 빠진 게 있다면 오히려 역질문을 날릴거에요.

실제로 정리해보기

자, 이제 6W를 다 배웠으니까 실제로 적용 해볼까요?

예시: 독서 기록 앱

질문	답
What	읽은 책에서 인상 깊은 문장을 기록하고, 나중에 랜덤으로 다시 보여주는 앱
Why	책 읽고 밑줄 그어도 다시 안 보게 됨. 가끔 예전에 읽은 좋은 문장을 다시 보고 싶음
Who	한 달에 책 2-3권 읽는 30대. 메모 앱에 적어두는데 찾기 어려움
When	2주 안에 MVP. 1주차: 문장 저장/목록 보기. 2주차: 랜덤 문장 보기
Where	웹 (핸드폰으로 주로 사용, 반응형)
How	1) 책 제목 입력 2) 문장 입력 3) 저장 4) 메인에서 랜덤 문장 보기 5) 전체 목록도 볼 수 있음

이 정도만 정리해도 AI한테 훨씬 명확하게 요청할 수 있어요.

PRD 간단 버전

회사에서는 이런 걸 PRD(Product Requirements Document)라고 불러요. 제품 요구사항 문서죠. 거창하게 들리지만, 우리는 간단하게만 해도 충분해요. PRD에 너무 큰 힘을 쓰지마세요. (PRD가 커질 수록, 이걸 LLM한테 넘겼을 때, 한번에 처리해야 하는 양 또한 늘어납니다. 버그가 터지면 어디서 터졌는지 찾기 힘들어요.)

위에서 정리한 6W를 이렇게 문서로 만들어보세요:

# 프로젝트: 책 속 문장 저장소

## 한 줄 설명
읽은 책에서 좋았던 문장을 저장하고, 랜덤으로 다시 보여주는 웹앱

## 왜 만드나요?
- 책 읽고 밑줄 그어도 다시 안 보게 됨
- 가끔 예전에 읽은 좋은 문장이 생각나는데 못 찾음
- 기존 메모앱은 책 기록용으로 불편함

## 누가 쓰나요?
- 한 달에 책 2-3권 읽는 사람
- 메모 습관은 있는데 정리가 안 되는 사람

## 핵심 기능 (MVP)
1. 책 제목 + 문장 저장하기
2. 저장한 문장 목록 보기
3. 랜덤으로 문장 하나 보여주기

## 나중에 추가할 기능
- 책별로 분류해서 보기
- 문장에 태그 달기
- 검색 기능

## 기술 스택
- 프론트: React
- 백엔드: Supabase
- 배포: Vercel

## 일정
- 1주차: 저장/목록 보기
- 2주차: 랜덤 보기 + 배포

이거 한 장이면 충분합니다

흔한 실수들

6W 정리할 때 자주 하는 실수들 알려드릴게요.

1. 기능을 너무 많이 넣음

"MVP에 로그인, 소셜 공유, 통계, 알림, 다크모드 다 넣을래요"

안 돼요. MVP는 "이것만 되면 쓸 수 있다"예요. 3개 이하로 줄이세요.

2. Who를 너무 넓게 잡음

"20대~50대 남녀 모두요"

이건 Who를 안 정한 거랑 같아요. 딱 한 명을 상상하세요.

3. Why가 약함

"그냥 만들어보고 싶어서요"

그러면 중간에 포기할 확률이 높아요. 진짜 필요한 이유를 찾으세요. 본인이 직접 쓸 거면 더 좋아요.

4. When 계획이 없음

"되는 대로요"

그러면 영원히 안 끝나요. 2주든 4주든 기한을 정하세요.

마무리

오늘 배운 6W, 처음엔 귀찮아 보일 수 있습니다. "그냥 빨리 만들면 안 돼?" 싶죠.

근데 이거 한 번 정리하고 시작하면, 나중에 시간을 엄청 아낍니다. 첫 단추를 잘 끼우는겁니다.

다음 글에서는 개발할 때 꼭 알아야 할 기본 용어들을 정리해드릴게요. 프론트엔드, 백엔드, API... 이런 말들 들어봤는데 정확히 뭔지 모르시죠? 비개발자 눈높이에서 쉽게 설명해드릴게요.