바이브코딩 MVP SOP v0.1
0. 운영 표준 체계 내 역할
| 항목 | 내용 |
|---|---|
| 계층 | L4 도메인 SOP |
| 상위 기준 | jyp-labs-operating-system-v0.1, jyp-labs-operating-standards-map-v0.1 |
| 책임 | 아이디어를 검증 가능한 MVP와 제품화 판단으로 전환 |
| 연결되는 하위 산출물 | MVP plan.md, agent task breakdown, 품질 게이트 |
| 충돌 시 원칙 | 이 문서는 해당 도메인의 세부 기준을 관리하고, 공통 운영 구조·승인 경계는 상위 운영체계를 따른다. |
핵심 메시지: 바이브코딩의 차별점은 데모 속도가 아니라, MVP를 제품 수준으로 검증하는 SOP에 있다.
1. 목적
이 SOP는 아이디어를 빠르게 데모로 만드는 것에서 멈추지 않고, 아이디어 → plan.md → agent build → 품질 게이트 → MVP 검증 → 운영 전환까지 이어지는 JYP Labs 표준 절차다.
목표는 세 가지다.
- 바이브코딩을 “감으로 만드는 개발”이 아니라 검증 가능한 업무 루프로 만든다.
- Codex/Claude/Hermes 같은 에이전트를 안전하게 활용한다.
- 데모와 제품 사이의 품질·보안·운영 격차를 체크리스트로 관리한다.
2. 사용 조건
사용한다
- 대표님이 “이 아이디어 MVP로 만들어줘”라고 요청할 때
- 강의/컨설팅에서 바이브코딩 실습을 설계할 때
- 내부 자동화 또는 웹/앱 프로토타입을 빠르게 검증할 때
- agentic engineering 방식으로 plan → build → verify 루프를 돌릴 때
사용하지 않는다
- 문제 정의 없이 “그냥 만들어보자” 수준인 경우
- 고객 데이터, 결제, 외부 발송, 계정 권한이 필요한데 승인되지 않은 경우
- MVP가 아니라 장기 운영 제품 개발 범위인 경우
3. 표준 루프
아이디어 정의
→ 사용자/문제/성공 기준 작성
→ plan.md 생성
→ Codex/Claude/Hermes 작업 분해
→ MVP 구현
→ 품질 게이트
→ 사용자 시나리오 테스트
→ 배포/보류/폐기 결정
→ 회고와 SOP 갱신4. 입력 템플릿
## MVP 요청 입력
- 아이디어:
- 대상 사용자:
- 해결할 문제:
- 반드시 되는 기능:
- 하지 않을 기능:
- 사용 데이터:
- 민감 정보 여부:
- 원하는 산출물:
- 기한:
- 배포 필요 여부:5. plan.md 표준 목차
# <MVP 이름> Plan
## 1. 문제 정의
- 사용자:
- 문제:
- 현재 대안:
- 성공 기준:
## 2. 범위
### Must
- ...
### Should
- ...
### Won't
- ...
## 3. 사용자 흐름
1. ...
2. ...
3. ...
## 4. 기술/도구
- 프론트엔드:
- 백엔드:
- 데이터:
- 인증:
- 배포:
## 5. 작업 분해
| ID | 작업 | 실행자 | 검증 |
|---|---|---|---|
## 6. 품질 게이트
- [ ] ...
## 7. 승인 경계
- 자동 가능:
- 승인 필요:6. 작업 분해 기준
| 작업 유형 | 기본 실행자 | 검증 |
|---|---|---|
| 문제/범위 정리 | Sophie | 대표님 요구와 일치하는지 확인 |
| plan.md 작성 | Sophie 또는 Codex | Must/Should/Won’t 분리 |
| 코드 구현 | Codex/Claude Code | git diff, 테스트, 실행 로그 |
| 문서 작성 | Sophie | OMW 저장, fields/lint 확인 |
| UI 확인 | Browser/사람 | 주요 사용자 흐름 캡처 또는 로그 |
| 배포 | 사람 승인 후 | URL/헬스체크/롤백 기준 |
7. 품질 게이트 v0.1
| 게이트 | 체크 항목 | 통과 기준 |
|---|---|---|
| 문제 정의 | 누구의 어떤 문제를 해결하는가? | 한 문장으로 설명 가능 |
| MVP 범위 | 1~2일 안에 검증 가능한 최소 기능인가? | Must 3개 이하 권장 |
| 데이터/보안 | 민감 정보, 인증, 저장 위치, 외부 전송 위험이 정의됐는가? | 위험 항목과 승인 경계 명시 |
| 실행 검증 | 실제 실행, 테스트, 브라우저 확인, 로그 확인을 했는가? | 도구 출력 또는 캡처 존재 |
| 사용자 흐름 | 처음부터 끝까지 사용자가 목적을 달성할 수 있는가? | E2E 시나리오 1개 이상 통과 |
| 운영 전환 | 배포·모니터링·오류 대응·백업 계획이 있는가? | 운영 필요 시 최소 계획 존재 |
| 중단 기준 | 더 만들지 말아야 할 조건이 정의됐는가? | 폐기/보류 기준 존재 |
8. MVP 판정 기준
| 판정 | 기준 | 다음 액션 |
|---|---|---|
| proceed | 핵심 사용자 흐름이 작동하고 품질 게이트 통과 | 다음 기능 또는 베타 테스트 |
| iterate | 가능성은 있으나 핵심 흐름/품질 일부 미흡 | 한 번에 하나씩 개선 루프 |
| hold | 문제/사용자/가치가 불명확 | 리서치 또는 사용자 인터뷰 |
| discard | 반복 가치가 낮거나 위험이 크다 | 실패 로그 기록 |
9. 실패 로그
failed_at: YYYY-MM-DD
mvp_name: <name>
change_attempted: <무엇을 바꿨는가>
expected_gain: <기대 효과>
actual_result: <결과>
quality_gate_failed:
- <게이트>
reason: <원인>
decision: discard | iterate | hold10. 강의 후보
제목
바이브코딩: 데모에서 제품으로
핵심 메시지
- 바이브코딩은 진입 장벽을 낮추지만 품질 기준을 없애지 않는다.
- 빠른 데모보다 중요한 것은 문제 정의, 품질 게이트, 사용자 흐름 검증이다.
- AI 에이전트는 코드를 대신 쓰지만, 사람은 성공 기준과 승인 경계를 설계해야 한다.
5장 강의 구조
- 바이브코딩의 장점과 오해
- 데모와 제품의 차이
- MVP plan.md 작성법
- agent build와 품질 게이트
- 운영 전환과 실패 로그
실습
- 같은 아이디어를 “즉흥 프롬프트”와 “MVP SOP”로 각각 진행해 결과 비교
- Must/Should/Won’t 범위 줄이기
- 품질 게이트로 데모를 제품 후보로 평가하기
11. 자동화 후보
후보명
vibe-coding-mvp-sop
Trigger
- “이 아이디어 MVP로 만들어줘”
- “바이브코딩 SOP로 진행해”
- “plan.md 작성해”
- “데모에서 제품으로 만들려면?”
Input
- 아이디어
- 사용자/문제
- 제약 조건
- 원하는 산출물
- 민감 정보/배포 여부
Output
- MVP plan.md
- 작업 분해표
- 품질 게이트 체크리스트
- 실행/검증 로그 템플릿
- proceed/iterate/hold/discard 판정
Approval boundary
승인 전 금지:
- 실제 배포
- 도메인 연결
- 결제/광고 집행
- 고객 데이터 사용
- 외부 메일/메시지 발송
- production DB 변경
12. 실행 체크리스트
- 문제와 사용자가 명확하다.
- Must 기능이 3개 이하로 좁혀졌다.
- 하지 않을 기능이 적혀 있다.
- plan.md가 먼저 작성됐다.
- 작업별 실행자와 검증 방법이 정해졌다.
- 품질 게이트가 있다.
- 실제 실행 또는 dry-run 로그가 있다.
- 배포/외부 연동은 승인 후 진행한다.
- 실패 로그 또는 회고가 남는다.
13. 샘플 적용 및 v0.2 개정 후보
- 대표님이 선택하는 MVP 아이디어 1개에 이 SOP를 샘플 적용한다.
- Hermes skill
vibe-coding-mvp-sop초안을 작성할지 결정한다. - 강의 모듈
바이브코딩: 데모에서 제품으로의 슬라이드 목차를 작성한다.