종단프로젝트 · 예비창업자 아이디어 검증·고객 피드백 보드

1개끝까지 성장시킬 서비스

10단계2장부터 11장까지

약 14시간전체 권장 실습 시간

Lv.6최종 하네스 목표

대표 서비스

아이디어 검증·고객 피드백·MVP 운영 보드

해결할 문제 · 사업 가설, 고객 인터뷰, 기능 요청과 실험 결과가 문서·메신저·스프레드시트에 흩어져 무엇을 검증했고 다음에 무엇을 만들지 판단하기 어렵다.

최종 사용자 · 아이디어를 실제 서비스로 검증하려는 예비창업자·비개발자 창업자·초기 창업팀과 가상 잠재고객.

최종 모습 · 문제·고객 가설 등록 → 인터뷰·피드백·실험 관리 → 검증·보류·기각 상태 추적 → 주간 학습 보고·MVP 개선 자동화 → 검증·통제 → GitHub 보관 → Vercel 공개 → 비용·보안 운영까지 이어지는 실제 서비스.

범위 원칙 · 2~10장에서는 가상 고객·가상 인터뷰와 공개 가능한 예시 데이터만 사용합니다. 실제 고객의 이름·연락처·계약정보·결제정보와 영업비밀은 저장하지 않습니다. 11장의 비용·보안·법적 책임 점검 전에는 실제 사업 운영에 적용하지 않습니다.

MVP 검증 안전 원칙

가상 데이터 우선 · 실습에서는 잠재고객A, 가설01처럼 식별 불가능한 가상 데이터만 사용하며 실제 고객정보와 영업비밀을 입력하지 않습니다.

사업 판단은 사람이 · AI가 만든 시장 요약·우선순위·통계를 그대로 확정하지 않고 창업자가 근거, 표본 한계, 사업 맥락을 최종 확인합니다.

시장 성공 자동판정 금지 · AI가 제품 성공·투자 가치·출시 여부를 자동으로 결정하지 않으며, 검증되지 않은 수요와 매출을 사실처럼 표시하지 않습니다.

하나의 서비스이전 장 결과물을 버리지 않고 다음 장의 입력으로 사용합니다.

하나의 기록PROJECT-JOURNAL.md에 결정·실패·검증 증거를 누적합니다.

하나의 리듬모든 장에서 말하기 → 확인하기 → 통제하기를 반복합니다.

한눈에 보는 성장 경로

장별 누적 실습

2장

시제품

사업 가설·고객 피드백 관리의 불편을 화면으로 바꾼다

45~60분 · 펼치기⌄

Claude 웹 아티팩트로 핵심 화면과 사용 흐름을 먼저 시험합니다.

책을 옆에 펴둘 곳

2.2 아티팩트 — 앱 및 웹사이트
2.3 프롬프트 5가지 원칙
2.4 말하기·확인하기·통제하기
2.6 웹의 파일 접근·저장 한계

이번 장의 누적 미션

문제 가설, 고객군, 실험 마감일, 검증 상태를 등록한다.
전체·고객군별·실험 임박·미검증 필터를 만든다.
공동창업자 또는 지인 1명에게 3분 사용성 시험을 받는다.
빠진 기능보다 먼저 핵심 흐름을 검증한다.

사람이 직접 확인할 합격선

가설→실험→학습→판단 흐름이 이해된다.
빈 가설과 잘못된 실험 마감일이 거부된다.
375px 화면에서 카드와 입력창이 겹치지 않는다.
영구 저장이 되지 않는 한계를 설명할 수 있다.

이번 장이 끝나면 남길 증거

시제품 화면 2장
사용성 의견 3개
수정 전·후 차이 1건
PROJECT-JOURNAL.md의 2장 기록

실행 프롬프트 예시

예비창업자·초기 창업팀용 아이디어 검증·고객 피드백·MVP 운영 보드의 웹 아티팩트 시제품을 만들어줘. 사용자: 예비창업자·초기 창업팀과 가상 잠재고객 핵심 기능: 문제 가설·고객군·실험 마감일 등록, 검증 상태(가설/실험/검증/기각) 변경, 마감 임박 표시, 고객군별 필터 제약: 실제 고객의 이름·연락처·계약·결제정보와 영업비밀은 입력받지 않기, 375px 반응형 ★ 완성 조건: - 새 가설이나 피드백을 등록하면 즉시 목록에 나타날 것 - 상태와 고객군 필터가 동작할 것 - 빈 가설과 잘못된 실험 마감일은 거부할 것 - 모바일에서 내용이 잘리지 않을 것 먼저 구현 계획과 확인 방법을 설명하고, 내 승인을 받은 뒤 만들어줘.

다음 장으로 넘길 것 · 핵심 화면, 합격선, 사용성 의견, 남은 문제 → 3장 준비

3장

준비

11장까지 사용할 하나의 작업장을 만든다

20~30분 · 펼치기⌄

프로젝트 폴더와 실행 환경을 만들고 장별 기록 체계를 시작합니다.

책을 옆에 펴둘 곳

3.1 터미널의 역할
3.2 핵심 명령어 5가지
3.3 uv 설치
3.4 시작 전 체크리스트

이번 장의 누적 미션

startup-mvp-board 전용 폴더를 만든다.
uv와 Claude Code 실행 상태를 확인한다.
PROJECT-JOURNAL.md를 만든다.
2장 시제품의 요구사항과 피드백을 옮긴다.

사람이 직접 확인할 합격선

현재 위치가 프로젝트 폴더임을 확인한다.
uv --version 결과가 보인다.
빈 전용 폴더에서 시작한다.
오류가 나면 메시지를 삭제하지 않고 기록한다.

남길 증거

터미널 현재 경로
uv 버전 결과
폴더 목록
PROJECT-JOURNAL.md 첫 기록

$ cd ~/Documents $ mkdir startup-mvp-board $ cd startup-mvp-board $ uv --version $ claude

다음 장으로 넘길 것 · 전용 폴더, 환경 확인 결과, 시제품 요구사항과 MVP 검증 안전 원칙 → 4장 로컬 앱

4장

로컬 앱

시제품을 내 컴퓨터의 최소 제품으로 옮긴다

70~90분 · 펼치기⌄

CLAUDE.md를 프로젝트 헌법으로 삼아 실제 파일로 작동하는 앱을 만듭니다.

책을 옆에 펴둘 곳

4.1 Claude 웹과 Claude Code의 차이
4.3 첫 실행과 폴더 작업
4.4 CLAUDE.md
4.5 체크리스트와 증거 요구
4.6 슬래시 명령어와 파일 지정

이번 장의 누적 미션

기능·금지사항·합격선을 CLAUDE.md에 적는다.
가설·실험·피드백 등록, 상태 변경, 고객군별 필터를 구현한다.
우선 localStorage에 가상 데이터를 저장한다.
가상 가설·실험·피드백 5건을 준비한다.

사람이 직접 확인할 합격선

새로고침 후에도 데이터가 남는다.
상태·고객군·실험일 필터가 모두 동작한다.
입력 오류가 사용자에게 설명된다.
AI의 완료 보고와 별개로 직접 시험했다.

남길 증거

CLAUDE.md
정상 동작 화면 2장
실패→수정→재검증 1건
실행 방법

먼저 CLAUDE.md를 만들어줘. 프로젝트는 '아이디어 검증·고객 피드백·MVP 운영 보드'야. 실습에서는 실제 고객정보·계약정보·영업비밀을 사용하지 않을 거야. 핵심 기능: 문제 가설과 고객군 등록, 실험 마감일과 검증 상태 변경, 우선순위, 고객군별 필터, localStorage 저장. 규칙: 실제 고객의 이름·연락처·계약·결제정보와 영업비밀 저장 금지, 삭제 전 확인, 기존 기능 보존, 모바일 확인. 작업 전에 계획과 변경 파일을 말하고 승인을 기다려. 완료 후에는 CLAUDE.md의 합격선별 시험 결과와 증거를 보고해줘.

다음 장으로 넘길 것 · 로컬 앱, CLAUDE.md, 샘플 데이터, 시험 결과 → 5장 자동화

5장

자동화

주간 고객 학습과 MVP 검증 보고를 자동화한다

80~100분 · 펼치기⌄

같은 서비스의 데이터를 문서 자동화와 반복 명령으로 확장합니다.

책을 옆에 펴둘 곳

5.1 HWPX 보고서 자동 생성
5.2 엑셀 처리와 PDF 리포트
5.3 Skill.md 기반 분석
5.5 커스텀 명령어
5.6 MCP 외부 연결 원리

이번 장의 누적 미션

가상 고객 인터뷰 메모 3개를 정해진 형식으로 정리한다.
가설·피드백 데이터를 CSV로 내보낸다.
검증·보류·기각 가설과 고객군별 피드백 현황을 주간보고로 만든다.
/weekly-report 반복 명령을 정의한다.

사람이 직접 확인할 합격선

원본 건수와 보고서 집계 건수가 일치한다.
지연 기준이 문서에 명시된다.
빈 폴더·잘못된 파일은 안전하게 중단된다.
원본 파일을 덮어쓰지 않는다.

남길 증거

샘플 CSV
주간 고객 학습·MVP 검증 보고 결과물
집계 대조표
커스텀 명령 파일

현재 앱의 가상 가설·피드백 데이터를 CSV로 내보내고, 이를 읽어 주간 운영 보고서를 만드는 안전한 자동화를 설계해줘. 보고서 항목: 전체/완료/진행/지연 건수, 완료율, 다음 주 우선순위, 확인이 필요한 항목. 규칙: 원본 덮어쓰기 금지, 실제 고객정보·계약·결제정보 열 금지, 건수 대조, 오류 시 중단. 반복 실행할 수 있도록 /weekly-report 명령으로 만들고 사용법과 검증 결과를 남겨줘.

다음 장으로 넘길 것 · 앱+자동화+오류 사례를 하나의 시스템으로 묶어 → 6장 위험 설계

6장

위험 설계

MVP 서비스에 필요한 다섯 고삐를 설계한다

45~60분 · 펼치기⌄

기능을 더 만들기 전에 발생 가능한 실패와 대응 원칙을 정합니다.

책을 옆에 펴둘 곳

6.1 AI 오작동 5가지 유형
6.2 하네스의 개념과 역할
6.3 규칙·울타리·검증·안전벨트·모니터링
6.4 하네스 성숙도

이번 장의 누적 미션

허위 피드백, 반복 등록, 잘못된 가설·집계, 삭제 사고, 장애를 정의한다.
각 위험을 다섯 고삐에 매핑한다.
자동 처리와 사람 승인 경계를 정한다.
현재 성숙도를 자가 진단한다.

사람이 직접 확인할 합격선

위험마다 예방·탐지·복구 방법이 있다.
가설 확정·기능 우선순위 변경·전체 삭제·실제 출시 결정은 창업자 승인 대상으로 표시된다.
통계와 AI 추천이 시장성·투자 가치·출시 결정의 단독 근거가 아님을 명시한다.
다음 장 구현 순위가 정해졌다.

남길 증거

위험 등록부
다섯 고삐 설계표
사람 승인 목록
성숙도 자가 진단

현재 아이디어 검증·고객 피드백·MVP 운영 보드의 위험 등록부를 만들어줘. 위험 예시: 허위 피드백, 반복 등록, 가설 상태 오류, 실험 일정 오류, 잘못된 집계, 전체 삭제, 서비스 중단, 실제 고객정보 입력. 각 위험에 대해 발생 조건, 영향, 규칙/울타리/검증/안전벨트/모니터링 중 적용할 고삐, 사람이 승인할 지점을 정리해줘. 코드는 아직 바꾸지 말고 설계안을 먼저 보여줘.

다음 장으로 넘길 것 · 위험 등록부와 구현 우선순위 → 7장 서비스 고삐

7장

서비스 고삐

창업팀과 잠재고객이 안심하고 쓸 수 있는 통제 장치를 붙인다

100~120분 · 펼치기⌄

6장의 설계를 실제 입력 규칙, 제한, 테스트, 복구, 현황판으로 구현합니다.

책을 옆에 펴둘 곳

7.2 규칙 적용
7.3 도배 방지 울타리
7.4 검증 적용
7.5 안전벨트와 복구
7.6 이용 현황 모니터링

이번 장의 누적 미션

금지 입력과 필수 입력 규칙을 적용한다.
짧은 시간의 반복 등록을 제한한다.
실험 마감일·미검증 건수 계산 테스트를 만든다.
오류 시 마지막 정상 데이터로 복구한다.
가설·검증·미검증·오류 현황을 표시한다.

사람이 직접 확인할 합격선

정상 입력은 통과하고 위험 입력은 막힌다.
경계값 테스트가 반복 가능하다.
장애 후 데이터 또는 기능이 복구된다.
현황 수치가 실제 샘플 데이터와 일치한다.

남길 증거

정상·차단 사례
테스트 결과
복구 전·후 화면
모니터링 화면

6장의 위험 등록부를 기준으로 다섯 고삐를 순서대로 적용해줘. 1) 규칙: 고객 개인정보와 허위 입력 차단 2) 울타리: 반복 등록과 입력 길이 제한 3) 검증: 마감일·처리율·필터 테스트 4) 안전벨트: 오류 시 안전한 메시지와 마지막 정상 상태 복구 5) 모니터링: 가설·검증·미검증·오류 건수 한 번에 전부 바꾸지 말고 고삐 하나씩 구현→시험→내 승인을 받아 다음으로 진행해줘.

다음 장으로 넘길 것 · 통제된 앱과 반복 가능한 시험 → 8장 AI 고삐

8장

AI 고삐

만드는 AI와 안전을 검사하는 AI를 분리한다

80~100분 · 펼치기⌄

서비스뿐 아니라 서비스를 수정하는 AI의 작업 과정에도 통제 장치를 적용합니다.

책을 옆에 펴둘 곳

8.2 서브에이전트 — 제작과 검사 분리
8.3 MCP의 실제 데이터 연결 원리
8.4 Hooks — 차단과 기록
8.5 Plugins — 고삐 세트 재사용

이번 장의 누적 미션

builder와 reviewer 역할을 분리한다.
reviewer가 합격선을 독립 확인하게 한다.
고객 개인정보·영업비밀·대량 삭제·위험 명령을 훅으로 막는다.
검증 규칙을 재사용 가능한 프로젝트 스킬로 정리한다.

사람이 직접 확인할 합격선

제작자의 자기 보고만으로 완료 처리하지 않는다.
reviewer가 결함을 1건 이상 찾아 재수정을 요청한다.
위험 작업은 실행 전에 차단되거나 승인 요청된다.
작업과 검사 기록이 남는다.

남길 증거

역할 정의 파일
검사 보고서
차단 로그
수정→재검사 결과

이 프로젝트의 변경 작업을 두 역할로 분리해줘. - builder: 승인된 기능만 구현 - reviewer: CLAUDE.md, 고객 개인정보·영업비밀 금지, 모바일, 기존 기능 회귀, 테스트 통과 여부를 독립 검사 민감정보 파일, 대량 삭제, 검증 생략을 막는 Hook도 제안해줘. builder의 완료 보고를 reviewer가 그대로 믿지 말고 실제 파일과 시험 결과로 판정하게 해줘.

다음 장으로 넘길 것 · 제작·검사 체계와 차단 로그 → 9장 GitHub

9장

GitHub

서비스를 금고에 넣고 되돌리기를 시험한다

60~80분 · 펼치기⌄

현재 프로젝트 전체를 버전으로 보관하고 안전한 수정·복구 흐름을 익힙니다.

책을 옆에 펴둘 곳

9.1 Git과 GitHub의 역할
9.2 계정과 저장소 준비
9.3 첫 업로드 전 검문
9.4 세이브 포인트와 되돌리기
9.5 자동화

이번 장의 누적 미션

비밀정보와 불필요한 파일을 업로드에서 제외한다.
의미 있는 첫 버전을 커밋·푸시한다.
작은 UI 변경을 별도 세이브 포인트로 남긴다.
의도적으로 변경한 뒤 이전 버전으로 되돌린다.

사람이 직접 확인할 합격선

GitHub에서 파일과 커밋 기록이 보인다.
API 키·고객 개인정보·영업비밀·로컬 환경 파일이 없다.
복구 후 핵심 기능이 다시 동작한다.
README에 실행·시험 방법이 있다.

남길 증거

저장소 URL
검문 결과
커밋 2개 이상
복구 전·후 커밋 ID

GitHub 첫 업로드를 준비해줘. 먼저 비밀정보·고객 개인정보·영업비밀·불필요한 생성 파일을 검사하고 .gitignore와 README 초안을 보여줘. 내 승인 전에는 push하지 마. 승인 후 현재 정상 버전을 커밋하고, 작은 화면 변경을 별도 커밋한 다음 되돌리기 실습 절차를 안내해줘. 각 단계의 확인 명령과 복구 증거를 PROJECT-JOURNAL.md에 남겨줘.

다음 장으로 넘길 것 · 검문된 저장소와 복구 가능한 정상 버전 → 10장 배포

10장

배포

같은 MVP를 가상 잠재고객이 접속할 수 있게 공개한다

80~100분 · 펼치기⌄

GitHub의 정상 버전을 Vercel에 연결하고 운영 환경에서 고삐가 작동하는지 확인합니다.

책을 옆에 펴둘 곳

10.1 Vercel을 쓰는 이유
10.2 GitHub 연결
10.3 배포 환경과 데이터 구조
10.5 배포 후 다섯 고삐 재점검
10.6 수정→푸시→자동 배포

이번 장의 누적 미션

Vercel과 GitHub 저장소를 연결한다.
환경변수와 데이터 저장 방식을 구분한다.
실제 고객정보·영업비밀·검증되지 않은 홍보문구가 없음을 확인한 뒤 배포 URL을 다른 기기에서 시험한다.
작은 수정이 자동 배포되는 흐름을 확인한다.

사람이 직접 확인할 합격선

새 브라우저·모바일에서 접속된다.
비밀정보가 화면·저장소·로그에 노출되지 않는다.
다섯 고삐의 핵심 시험이 배포 환경에서도 통과한다.
장애 시 이전 정상 배포로 롤백할 수 있다.

남길 증거

배포 URL
모바일 화면
배포 환경 시험표
자동 배포·롤백 기록

GitHub의 정상 버전을 Vercel에 배포하기 위한 계획을 세워줘. 먼저 로컬 저장(localStorage)과 여러 사용자가 공유하는 서버 저장의 차이를 설명하고, 현재 구현에서 가능한 범위를 명확히 표시해줘. 환경변수와 비밀정보 검문, 배포 후 다섯 고삐 재시험, 모바일 외부 접속, 자동 배포와 롤백 순서까지 체크리스트로 제시해줘. 실제 배포는 내 승인을 받은 뒤 진행해줘.

다음 장으로 넘길 것 · 공개 URL, 배포 시험표, 롤백 지점 → 11장 운영

11장

운영

아이디어 제안자에서 책임지는 서비스 운영자로 졸업한다

60~80분 · 펼치기⌄

비용·보안·개인정보·AI 안내·장애 대응을 점검하고 지속 운영 여부를 결정합니다.

책을 옆에 펴둘 곳

11.1 비용 울타리
11.2 보안 미니멀
11.3 졸업 실험의 운영 관점
11.4 하네스 성숙도 최종 진단
11.5 다음 단계 로드맵

이번 장의 누적 미션

무료 한도·비용 알림·중단 기준을 정한다.
비밀정보·고객 개인정보·지식재산·공개 범위를 재점검한다.
AI 기능이 있다면 참고용 안내, 시장 수치와 제품 약속은 창업자 확인 우선 원칙을 표시한다.
장애·오류·문의 대응과 종료 절차를 적는다.
Lv.6 자가 진단과 다음 버전 계획을 작성한다.

최종 합격선

비용 상한과 확인 주기가 정해졌다.
실제 고객정보를 저장하지 않으며 가상 데이터 삭제 방법이 있다.
운영 책임자 연락·장애 대응·롤백 절차가 있다.
가상 잠재고객 역할 2명 이상의 최종 사용성 시험을 통과했다.

최종 제출물

배포 URL과 GitHub URL
README·운영 체크리스트
PROJECT-JOURNAL.md
2장↔11장 비교 화면
3분 시연 영상 또는 발표 자료

이 서비스를 실제 베타 운영에 적용할 수 있는지 최종 점검해줘. 점검 범위: 비용 상한과 알림, 비밀정보, 고객 개인정보 최소화, AI 검증 결과 안내, 데이터 삭제, 로그 보관, 장애 대응, 롤백, 창업자 승인, 고객 문의 창구, 서비스 종료. 각 항목을 '통과/보완 필요/운영 전 필수'로 판정하고 증거 위치를 적어줘. 자동 판정하지 말고 사람이 최종 승인해야 할 항목을 별도로 모아줘. 마지막으로 하네스 성숙도 Lv.6 자가 진단과 다음 버전 로드맵을 작성해줘.

졸업 · 2장의 아이디어가 11장의 운영 가능한 서비스로 성장했습니다. 기능의 수보다 검증 증거와 통제 구조가 최종 성과입니다.

최종 제출 패키지

① 작동하는 서비스Vercel URL, GitHub 저장소, 실행 가능한 정상 버전

② 과정의 증거장별 PROJECT-JOURNAL, 실패·수정·재검증 기록

③ 운영의 증거비용·보안·개인정보·장애·롤백 체크리스트

④ 창업 검증 성찰말하기·확인하기·통제하기가 어떻게 달라졌는지 1쪽

⑤ MVP 운영 원칙AI 요약·통계·우선순위를 시장성·투자·출시 결정의 단독 근거로 사용하지 않기

⑥ 시연문제→핵심 흐름→고삐→배포→운영을 3분 안에 설명하기