바이브코딩을 처음 하시는 분들로부터 저한테 오는 질문들이 있습니다:
"스터디장님, 저 Claude한테 '쇼핑몰 앱 만들어줘' 했는데 이상한 게 나왔어요."
"AI가 중간에 자꾸 길을 잃어버려요."
"계속 물어봐야 하는데 뭘 물어봐야 할지 모르겠어요."
여러분도 비슷한 경험 있으시죠?
오늘은 제가 실제로 3일 만에 만든 웹서비스 사례를 통해, AI에게 제대로 된 "주문서"를 만드는 방법을 알려드리려고 합니다.
문제의 시작: "외국인한테 서울 여행 추천해주는 퀴즈 만들까?"
몇 달 전, 제게 이런 아이디어가 떠올랐습니다.
"외국인 관광객에게 재미있는 퀴즈로 맞춤형 서울 여행 코스를 추천해주면 어떨까?"
처음엔 저도 AI한테 바로 물어봤습니다. "여행 추천 퀴즈 웹사이트 만들어줘"라고요.
결과는? 완전히 쓸모없는 코드 덩어리였습니다. 질문이 뭔지 정해지지 않았고, 어떤 타입으로 나눌지 모호했고, 디자인은 생각조차 안 했고, 다국어 지원은 엄두도 못 냈죠.
왜 이렇게 됐을까요?
깨달음: AI는 "신"이 아니라 "똑똑한 '신'입사원"
제가 깨달은 핵심은 이겁니다.
AI는 여러분의 머릿속을 읽을 수 없습니다. AI에게 "대충 이거 만들어줘"라고 하는 건, 회사 신입사원한테 아무 설명 없이 "그냥... 알아서 좀 해봐"라고 하는 것과 같습니다.
그럼 어떻게 해야 할까요? 답은 "문서화"입니다.
하지만 걱정 마세요. 100페이지 기획서를 쓰라는 게 아닙니다. 5단계로 나눠서, AI와 함께 조금씩 구체화하면 됩니다.
5단계 문서화 프로세스
전체 과정은 이렇게 흘러갑니다:
1단계 - 기획 문서 (반나절~1일)
"왜 만들까? 누가 쓸까?" - 방향성을 잡습니다.
2단계 - 콘텐츠 문서 (반나절~1일)
"무엇을 담을까?" - 실제 들어갈 내용을 만듭니다.
3단계 - PRD (수시간)
"어떤 제품을 만들까?" - 제품의 범위와 요구사항을 정의합니다.
4단계 - 프로젝트 플랜 (수시간)
"어떻게 만들까?" - 구체적인 기술 스펙과 실행 계획을 세웁니다.
5단계 - 디자인 가이드 (수시간)
"어떤 모습일까?" - 시각적 규칙을 정합니다.
개발 시작 (1-2일)
Claude Code로 실제 개발을 시작합니다.
실제로 저는 이 과정을 통해 총 3일 만에 완성했습니다. 기획과 문서화에 1일, Ruby on Rails 개발에 2일이 걸렸습니다.
자, 이제 각 단계를 자세히 살펴볼까요?
1단계: 기획 문서 - "왜"를 정의하기
소요 시간: 반나절~1일
도구: Claude Web (채팅으로 아이디어 확장)
역할: 프로젝트의 방향성과 존재 이유를 명확히 합 니다.
이 단계에서는 이런 질문들에 답해야 합니다:
- 왜 이걸 만드는가?
- 누가 사용할까?
- 어떤 가치를 제공할까?
- 돈은 어떻게 벌 수 있을까?
- 비슷한 게 이미 있진 않나?
Claude Web과 대화하며 구체화하기
처음 제 머릿속에는 그냥 "외국인한테 여행 추천하는 거"라는 막연한 생각만 있었습니다.
그래서 Claude에게 이렇게 물어봤죠:
```
나는 외국인 관광객을 위한 여행 추천 서비스를 만들려고 해.
퀴즈 형식으로 하려고 하는데, 여러 관점에서 분석해줄래?
- 비즈니스 관점
- 사용자 관점
- 기술 관점
- 콘텐츠 관점
```Claude와 한 시간쯤 대화하고 나니, 이런 구체적인 그림이 나왔습니다:
목표
- B2C: 외국인 관광객에게 맞춤형 여행 코스 제공
- B2B: 수집한 데이터를 관광업체에 판매
- 마케팅: SNS 공유로 바이럴 효과 유도
타겟 사용자
- 연령: 20-35세
- 특성: 개별 여행자(FIT)
- 행동: SNS 활동 활발, 맞춤형 추천 선호
핵심 가치
- 10개 질문으로 5분 안에 완료
- 7가지 여행자 타입 분류
- 실제 서울 장소 3-5곳 추천
- 6개 언어 지원
보이시죠? 막연했던 아이디어가 이렇게 구체적으로 변합니다.
이 문서는 나중에: 개발 중 방향을 잃을 때 돌아와서 "우리가 왜 이걸 만들고 있지?"를 확인하는 나침반이 됩니다.
2단계: 콘텐츠 문서 - "무엇"을 채울까
소요 시간: 반나절~1일
도구: Claude Web (콘텐츠 초안 생성)
역할: 실제 서비스에 들어갈 모든 내용을 준비합니다.
이제 실제로 들어갈 내용을 만들어야 합니다. "여행 관련 질문 좀 만들고..."라는 막연한 생각에서, 실제 10개 질문과 7가지 여행자 타입을 구체적으로 만드는 단계죠.
질문 구조 설계
저는 3단계 깔때기 방식으로 질문을 구성했습니다.
1단계: 기본 성향 파악 (3-4문)
여행 스타일, 예산, 동행 유형을 파악합니다. 예를 들어 "서울 첫날, 어디로 가시겠어요?"라고 물으면서 경복궁(전통), 성수동(힙), 맛집(음식), 한강(휴식) 중 하나를 고르게 합니다.
2단계: 구체적 취향 탐색 (4-5문)
이동 수단 선호도, SNS 활동성, 선호 시간대를 물어봅니다. "이동할 때 어떤 방식 을 선호하세요?"라고 물으면서 대중교통, 택시, 걷기, 자전거 중 선택하게 합니다.
3단계: 특수 관심사 (2-3문)
K-문화 관심도, 로컬 경험 선호도, 새로운 것 대 익숙한 것 같은 심화 질문을 합니다.
7가지 여행자 타입 정의
각 타입마다 이름, 특징, 추천 장소, 실용적인 팁을 만들었습니다.
역사 탐험가
- 특징: 전통 문화와 역사에 관심
- 추천 장소: 경복궁, 북촌 한옥마을, 창덕궁
- 팁: 영어 가이드 투어 추천
힙스터 헌터
- 특징: 트렌디한 카페와 거리 선호
- 추천 장소: 성수동, 연남동, 이태원
- 팁: 인스타그램 감성 스팟 리스트 제공
미식가
- 특징: 현지 음식 탐방이 목적
- 추천 장소: 망원시장, 광장시장, 통인시장
- 팁: 채식/할랄 옵션 정보 포함
이런 식으로 7개를 모두 만들었죠.
스코어링 로직 설계
가장 중요한 부분입니다. 10개 질문의 답변으로 어떻게 7개 타입 중 하나를 고를까요?
저는 가중치 방식을 사용했습니다. 각 질문의 각 선택지마다 7개 타입에 점수를 부여하는 거죠. 예를 들어 질문 1번에서 경복궁을 선택하면 역사탐험가에 3점, 사진수집가에 1점을 주는 식입니다. 성수동을 선택하면 힙스터헌터에 3점, 사진수집가에 2점을 줍니다.
이렇게 10개 질문이 끝났을 때 각 타입별 점수를 합산해서 가장 높은 타입을 결과로 보여주는 방식입니다.
이 문서는 나중에: questions-data.json과 scoring-logic.json 파일로 변환해서 Claude Code에게 제공합니다. 실제 개발할 때 이 데이터를 그대로 사용하는 거죠.
3단계: PRD - 제품 요구사항 정의
소요 시간: 수시간
도구: Claude Web (요구사항 정리)
역할: 무엇을 만들 것인지, 제품의 범위와 한계를 명확히 합니다.
PRD는 Product Requirements Document의 약자입니다. "어떤 제품을 만들 것인가"를 정의하는 문서죠. 구체적인 구현 방법이 아니라 제품이 해야 할 것과 하지 말아야 할 것을 정리합니다.
### 제품 비전과 목표
제품 비전 한 줄: 외국인 관광객이 5분 안에 자신에게 맞는 서울 여행 스타일을 발견하고, 실제 방문할 장소를 추천받는 퀴즈 서비스
주요 목표
- 사용자가 재미있게 끝까지 완료할 수 있어야 함
- 결과에 만족해서 SNS에 공유하고 싶어야 함
- 수집된 데이터가 실제 마케팅에 활용 가능해야 함
### 핵심 기능 목록 (상세 스펙 X)
필수 기능 (MVP)
- 다국어 지원 (6개 언어)
- 10단계 퀴즈 플로우
- 7가지 타입 결과 제공
- 맞춤 추천 장소 제공
- SNS 공유 기능
제외 기능 (v1에서는 만들지 않음)
- 회원가입/로그인
- 결과 저장
- 장소 예약 연동
- 실시간 채팅
사용자 스토리
스토리 1: 도쿄에서 온 25세 여성 관광객이 서울에 처음 왔습니다. 호텔에서 휴식을 취하다가 스마트폰으로 이 퀴즈를 발견합니다. 일본어로 10개 질문에 답하고, 자신이 "힙스터 헌터" 타입이라는 걸 알게 됩니 다. 추천받은 성수동, 연남동, 이태원을 방문 계획에 추가합니다.
스토리 2: 방콕에서 온 30세 남성 여행자가 친구의 인스타그램 스토리에서 이 퀴즈 링크를 봅니다. 태국어로 퀴즈를 완료하고, 자신이 "미식가" 타입이라는 결과를 받습니다. 추천받은 시장 리스트를 저장하고, 본인도 결과를 인스타그램에 공유합니다.
성공 지표
참여 지표
- 퀴즈 시작률: 70% (방문자 중 시작한 비율)
- 완료율: 80% (시작한 사람 중 끝까지 한 비율)
바이럴 지표
- 공유 클릭률: 30%
- 공유 후 유입률: 20%
데이터 품질
- 국적별 고른 분포
- 타입별 고른 분포 (특정 타입으로 쏠림 없음)
제약사항
기술적 제약
- 모바일 우선 설계
- 로딩 시간 3초 이내
- 오프라인에서는 동작 불가
비즈니스 제약
- 개인정보 수집 최소화 (GDPR 준수)
- 무료 서비스로 운영
- 광고 없음
이 문서는 나중에: 개발 중 "이 기능 추가하면 어때?"라는 유혹이 올 때, "PRD에 없으니까 v2에 하자"라고 판단하는 기준이 됩니다.
4단계: 프로젝트 플랜 - 구체적인 실행 계획
소요 시간: 수시간
도구: Claude Web (기술 스택과 일정 조정)
역할: 어떻게 만들 것인지, 구체적인 기술 스펙과 순서를 정합니다.
이제 "어떻게 만들까?"를 구체적으로 계획합니다. PRD는 "무엇을"이었다면, 프로젝트 플랜은 "어떻게"