이모카
이모카
🐶 AI 찐친
🎖️ 마스터 파트너
🚀 SNS 챌린지 달성자

아이디어만 있으면 AI가 다 개발해주는 바이브코딩 전 문서 작성 워크플로우

바이브코딩을 처음 하시는 분들로부터 저한테 오는 질문들이 있습니다:

"스터디장님, 저 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.jsonscoring-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는 "무엇을"이었다면, 프로젝트 플랜은 "어떻게"입니다.

기술 스택 결정

프레임워크: Ruby on Rails 8

- 이유: 빠른 프로토타이핑, I18n 내장, 간편한 배포, Claude Code가 잘 이해함

데이터베이스: SQLite

- 이유: 간단한 설정, 별도 서버 불필요, MVP에 충분

프론트엔드: Tailwind CSS + Hotwire

- 이유: Rails와 잘 통합됨, 빠른 스타일링

컨테이너: Docker

- 이유: 일관된 개발/배포 환경

배포: Kamal + Digital Ocean

- 이유: 간단한 배포 프로세스, 비용 효율적, 컨테이너 기반

### 아키텍처 설계

모델 구조

- Question: 질문 데이터 (I18n으로 다국어 지원)

- Answer: 답변 선택지

- TravelerType: 7가지 타입 정보

- Result: 사용자 결과 저장 (선택 사항)

컨트롤러 구조

- QuizController: 퀴즈 플로우 전체 관리

- ResultsController: 결과 계산 및 표시

뷰 구조

- layouts/application: 전체 레이아웃

- quiz/landing: 시작 페이지

- quiz/language: 언어 선택

- quiz/question: 질문 페이지

- quiz/loading: 로딩 화면

- results/show: 결과 페이지

상세 기능 스펙

다국어 지원 구현

- Rails I18n 사용

- locale 파일 6개 생성

- 세션에 선택 언어 저장

- URL에 locale 파라미터 포함

스코어링 시스템 구현

- scoring-logic.json을 Ruby Hash로 로드

- 각 질문의 답변을 받을 때마다 세션에 저장

- 10번째 질문 완료 시 모든 점수 합산

- 가장 높은 점수의 타입을 결과로 선택

- 동점일 경우 첫 번째 타입 선택

SNS 공유 기능 구현

- Open Graph 메타 태그 설정

- 타입별 이미지 동적 생성 (또는 사전 제작)

- 공유 URL에 결과 타입 포함

- Facebook, Twitter, Instagram 공유 버튼

실제 3일 일정

Day 1: 기획+문서화 (6-8시간)

- 오전: Claude Web과 기획, 콘텐츠 작성

- 오후: PRD, 프로젝트 플랜, 디자인 가이드

- 저녁: 콘텐츠를 JSON으로 변환, 최종 검토

Day 2: 핵심 개발 (8-10시간)

- 오전: Rails 프로젝트 세팅, 모델 생성, I18n 설정

- 오후: 퀴즈 컨트롤러, 기본 뷰, 스코어링 로직

- 저녁: 결과 페이지, 공유 기능

Day 3: 마무리+배포 (6-8시간)

- 오전: Tailwind 적용, 디자인 가이드 반영

- 오후: 모바일 최적화, 전체 테스트

- 저녁: Docker 이미지 생성, Kamal 설정, Digital Ocean 배포

개발 순서 상세

Phase 1: 기본 구조 (2시간)

- Rails 프로젝트 생성

- 필요한 gem 설치

- 기본 모델 생성

- 마이그레이션 실행

Phase 2: I18n 설정 (1시간)

- 6개 언어 locale 파일 생성

- questions-data.json을 locale 파일로 변환

- 언어 전환 로직 구현

Phase 3: 퀴즈 플로우 (3시간)

- QuizController 생성

- 랜딩 페이지, 언어 선택 페이지

- 질문 페이지 (진행률 포함)

- 세션에 답변 저장 로직

Phase 4: 결과 계산 (2시간)

- scoring-logic.json 로드

- 점수 합산 메서드

- 최고 점수 타입 선택

- 결과 페이지 렌더링

Phase 5: 스타일링 (2시간)

- Tailwind 설정

- 디자인 가이드 기반 컴포넌트 스타일

- 반응형 처리

Phase 6: 배포 (1시간)

- Dockerfile 작성

- Kamal 설정 파일 생성

- Digital Ocean 서버 설정

- Kamal로 배포 실행

이 문서는 나중에: Claude Code에게 단계별로 작업을 지시할 때 정확히 이 순서대로 진행합니다. "Phase 1만 먼저 해줘" 이런 식으로요.


5단계: 디자인 가이드 - 일관성 있게 만들기

소요 시간: 수시간

도구: Claude Web (색상 조합 추천)

역할: 시각적 일관성을 위한 규칙을 정합니다.

이제 AI가 참고할 시각적 규칙을 정의합니다.

브랜드 아이덴티티

저는 "Modern Hanbok Meets Pop Culture"라는 컨셉을 잡았습니다. 한국 전통미와 현대적 팝 문화의 조화를 추구하는 거죠.

실제 적용에서는 색상은 전통 한복 색감에 비비드한 포인트를 더하고, 타이포그래피는 깔끔한 한글과 플레이풀한 영문을 조합하고, 일러스트는 손그림 느낌과 기하학 패턴을 섞었습니다.

### 컬러 시스템

메인 민트는 버튼과 강조, CTA에 사용해서 신선함과 활력을 전달합니다. 밝은 민트는 배경과 카드 배경에 사용해서 차분하고 청량한 느낌을 주고요. 골드는 프리미엄 요소와 뱃지에 사용해서 특별함을 표현합니다. 배경색은 전체 배경에 사용해서 깨끗하고 넓은 느낌을 만듭니다.

컴포넌트 패턴

Primary 버튼은 메인 민트 배경에 흰색 텍스트, 높이 56px, 12px 둥근 모서리로 만듭니다. Hover 시 10% 어둡게, 클릭 시 살짝 눌리는 효과, Disabled 시 50% 투명하게 처리합니다.

질문 카드는 흰색 배경에 테두리 없이, 부드러운 그림자와 24px 패딩, 16px 둥근 모서리로 만듭니다.

이렇게 자주 사용할 컴포넌트들의 스타일을 미리 정해두면, Claude Code가 일관되게 만들어줍니다.

이 문서는 나중에: Claude Code에게 "디자인 가이드에 따라 스타일을 적용해줘"라고 하면 이 문서를 참고해서 일관된 디자인을 만들어줍니다.


Claude Code로 개발 시작!

자, 이제 5단계 문서를 모두 완성했습니다. 드디어 실제 개발을 시작할 차례입니다.

### 준비물 확인

Claude Code를 실행하기 전에 다음 파일들을 준비합니다:

1. 기획문서.md - 방향성 확인용

2. 콘텐츠문서.md - 원본 콘텐츠 참고용

3. questions-data.json - 질문 데이터 (콘텐츠 문서에서 변환)

4. scoring-logic.json - 스코어링 로직 (콘텐츠 문서에서 변환)

5. PRD.md - 제품 범위 확인용

6. 프로젝트플랜.md - 구체적 구현 가이드

7. 디자인가이드.md - 스타일 규칙

Claude Code에게 작업 지시하는 법

나쁜 예시는 단순히 "여행 퀴즈 웹사이트 만들어줘"라고 하는 겁니다.

좋은 예시는 이렇게 구체적으로 요청하는 겁니다:

Ruby on Rails로 여행 퀴즈 앱을 만들려고 합니다.

아래 문서들을 모두 읽고 이해한 후 단계별로 진행하겠습니다.

[첨부 파일]

1. PRD.md - 제품 요구사항

2. 프로젝트플랜.md - 구체적 구현 계획

3. 디자인가이드.md - 스타일 규칙

4. questions-data.json - 질문 데이터

5. scoring-logic.json - 스코어링 로직

먼저 프로젝트플랜.md의 Phase 1만 진행해주세요:

- Rails 프로젝트 생성 (SQLite 사용)

- 필요한 gem 설치

- 기본 모델 생성

완료되면 다음 Phase로 진행하겠습니다.

단계별로 진행하기

Phase 1 완료 후: "좋아, 이제 Phase 2 (I18n 설정)를 진행해줘. questions-data.json을 locale 파일로 변환해서 config/locales/에 넣어줘."

Phase 2 완료 후: "완벽해. 이제 Phase 3 (퀴즈 플로우)를 만들어줘. QuizController를 생성하고 프로젝트플랜.md에 있는 뷰 구조대로 만들어줘."

Phase 3 완료 후: "잘 됐어. 이제 Phase 4 (결과 계산)를 해줘. scoring-logic.json을 사용해서 점수를 합산하고 최고 타입을 찾아줘."

Phase 4 완료 후: "거의 다 왔어! Phase 5 (스타일링)를 해줘. 디자인가이드.md를 참고해서 Tailwind 클래스를 적용해줘."

Phase 5 완료 후: "마지막이야! Phase 6 (배포)를 준비해줘. Dockerfile을 작성하고 Kamal 설정 파일을 만들어줘."

막혔을 때는?

실제로 제가 겪었던 상황입니다. 스코어링 로직이 예상대로 안 나왔어요. 그래서 Claude에게 이렇게 말했습니다:



Claude, scoring-logic.json을 다시 확인해줘.

각 질문의 가중치가 올바르게 적용되고 있는지

단계별로 디버깅 로그를 추가해서 보여줘.

프로젝트플랜.md의 "스코어링 시스템 구현" 섹션을 

다시 읽고 스펙대로 되어있는지 확인해줘.

Claude가 프로젝트 플랜을 다시 읽고, 디버깅 코드를 추가해주었고, 문제를 발견했습니다. 타입 변환 오류였죠. 즉시 수정해서 해결했습니다.

핵심은 어떤 문서를 참고하면 되는지 명확히 알려주는 겁니다. "이상해요"가 아니라 "프로젝트플랜.md의 어떤 섹션을 확인하고, 뭘 수정해달라"고 말하는 거죠.


실전 팁: 자주 하는 실수들

실수 1: "문서 쓸 시간에 코딩이나"

제 실제 경험입니다.

문서 없이 시작했을 때는 3일 개발하다가 방향을 잃어서 폐기하고 다시 4일 걸렸습니다. 총 7일이죠.

문서를 쓰고 시작했을 때는 1일 문서 작성, 2일 개발로 완성했습니다. 총 3일입니다.

하루 투자가 일주일을 절약합니다.

실수 2: "완벽하게 쓰고 시작해야지"

첫날 기획서만 3번 수정하고, 디자인 픽셀 하나하나 조정하다가 결국 시간만 낭비한 적이 있습니다.

올바른 방법은 80% 완성되면 개발을 시작하고, 개발하면서 문서를 계속 업데이트하는 겁니다. 문서는 "살아있는 것"이니까요.

실수 3: "Claude가 알아서 하겠지"

제가 "다음 단계 해줘"라고 하면 Claude는 "어떤 단계요? 구체적으로 말씀해주세요"라고 되묻습니다. 그럼 저는 멘붕에 빠지죠.

올바른 방법은 항상 "프로젝트플랜.md의 Phase X를 해줘"라고 명확히 지시하는 겁니다.

### 성공의 핵심: 문서 참조를 명확히

나쁜 지시는 "퀴즈 페이지 만들어줘"입니다.

좋은 지시는 이렇습니다:

프로젝트플랜.md의 Phase 3를 진행해줘.

뷰 구조는 "뷰 구조" 섹션을 참고하고,

디자인은 디자인가이드.md를 따라줘.

질문 데이터는 questions-data.json에서 가져와.

각 단계가 10-20분이면 충분합니다. 이렇게 하면 Claude도 명확히 이해하고, 여러분도 진행 상황을 파악하기 쉽습니다.


Q&A: 꼭 알아야 할 것들

Q1. 정말 3일만에 가능한가요?

네, 가능합니다. 단, 조건이 있습니다.

문서화를 철저히 하고, Rails처럼 빠른 프레임워크를 사용하고, Claude Code를 효과적으로 활용하고, 기능을 최소화(MVP)해야 합니다.

실제로 저는 Day 1에 6-8시간, Day 2에 8-10시간, Day 3에 6-8시간 정도 투자했습니다.

Q2. 문서 없이는 정말 안 되나요?

문서 없이도 "만들 수는" 있습니다. 하지만 AI가 방향을 자주 상실하고, 같은 질문을 반복하며, 완성도가 낮고, 디버깅이 어렵습니다.

문서가 있으면 AI가 정확히 이해하고, 일관된 결과물을 만들며, 유지보수가 용이하고, 확장이 가능합니다.

핵심은 문서가 AI를 위한 "GPS"라는 겁니다. GPS 없이 모르는 길을 찾아가는 것과 GPS를 켜고 가는 것의 차이죠.

Q3. PRD와 프로젝트 플랜의 차이가 뭔가요?

PRD는 "무엇을", 프로젝트 플랜은 "어떻게"입니다.

PRD는 제품이 해야 할 것과 하지 말아야 할 것을 정의합니다. "다국어 지원이 필요하다"까지만 적습니다.

프로젝트 플랜은 구체적인 구현 방법을 적습니다. "Rails I18n을 사용해서 6개 언어 locale 파일을 만들고, 세션에 저장한다"라고 적는 거죠.

Q4. Claude Web vs Claude Code, 언제 뭘 쓰나요?

명확한 역할 분담이 있습니다.

Claude Web은 기획 단계에서 사용합니다. 아이디어를 확장하고, 콘텐츠 초안을 생성하고, 전략을 논의하고, 5가지 문서를 작성합니다.

Claude Code는 개발 단계에서 사용합니다. 완성된 문서들을 참고해서 실제 코드를 작성하고, 파일을 생성하거나 수정하고, 디버깅하고, Git 커밋을 합니다.

정리하면 생각은 Web, 실행은 Code입니다.

---

체크리스트: 시작 전 확인사항

시작하기 전에 이것들을 확인하세요:

1단계 완료 확인

- [ ] 비즈니스 목표 1문장 정의

- [ ] 타겟 사용자 구체화

- [ ] Claude와 아이디어 확장 대화

- [ ] 기획문서.md 작성 완료

2단계 완료 확인

- [ ] 모든 질문 작성 (10개)

- [ ] 7가지 타입 정의

- [ ] 스코어링 로직 설계

- [ ] 콘텐츠문서.md 작성 완료

- [ ] questions-data.json 변환 완료

- [ ] scoring-logic.json 변환 완료

3단계 완료 확인

- [ ] 제품 비전 정의

- [ ] 핵심 기능 목록 작성

- [ ] 제외 기능 명시

- [ ] 사용자 스토리 작성

- [ ] 성공 지표 설정

- [ ] PRD.md 작성 완료

4단계 완료 확인

- [ ] 기술 스택 결정 (Rails + SQLite + Kamal)

- [ ] 아키텍처 설계

- [ ] 기능별 상세 스펙 작성

- [ ] 개발 순서 정리 (Phase 1~6)

- [ ] 현실적인 일정 수립

- [ ] 프로젝트플랜.md 작성 완료

5단계 완료 확인

- [ ] 브랜드 아이덴티티 정의

- [ ] 컬러 시스템 확립

- [ ] 컴포넌트 패턴 정리

- [ ] 디자인가이드.md 작성 완료

개발 시작 전 최종 확인

- [ ] Claude Code 설치 및 세팅

- [ ] 7개 문서 파일 모두 준비

- [ ] 첫 커밋 준비 완료


한국 웹사이트의 홈페이지

마무리: 오늘부터 시작하기

여러분은 이제 알게 되었습니다.

AI는 "딸깍"이 아니라 "여러분의 생각을 구현해주는 똑똑한 동료"입니다. 동료에게 일을 잘 시키려면 명확한 지시가 필요합니다. 그 지시서가 바로 개발 시 필요한 "문서"입니다.

오늘부터 할 수 있는 것

오늘

만들고 싶은 아이디어를 한 문장으로 적어보세요. "______를 위한 _______를 만들고 싶다"

내일

Claude Web과 대화하며 아이디어를 확장하고 기획 문서 초안을 작성하세요.

모레

콘텐츠를 구체화하고, PRD와 프로젝트 플랜, 디자인 가이드를 만드세요. 콘텐츠는 JSON으로 변환하는 것도 잊지 마세요.

3일차

Claude Code를 열고, 7개 문서를 첨부하고, "프로젝트플랜.md의 Phase 1부터 시작하자"라고 말하세요!

실제로 3일이면 충분합니다.

여러분도 할 수 있습니다. 오늘, 지금, 한 문장부터 시작해보세요.

3
2개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요