왜 7일인가

많은 사람이 "언젠가 만들고 싶은 서비스"를 갖고 있습니다. 그런데 그 '언젠가'는 대개 오지 않습니다. 이유는 단순합니다. 시작점이 막연하기 때문입니다.

바이브 코딩의 본질은 코드를 많이 아는 것이 아니라, 의도를 빠르게 구현하고 검증하는 반복에 있습니다. 그래서 이 강의에서는 7일짜리 짧은 실행 루프를 제안합니다. 완성품을 만드는 과정이 아니라, 시장에 던져볼 수 있는 **작동하는 최소 제품(MVP)**을 만드는 과정입니다.

Day 1 — 문제를 한 문장으로 고정하기

먼저 "무엇을 만들지"가 아니라 "누가 무엇 때문에 불편한지"를 한 문장으로 정의합니다.

• 나쁜 정의: "AI 기반 혁신 플랫폼"
• 좋은 정의: "소상공인이 매일 반복하는 재고 확인 메시지를 자동으로 요약해주는 웹앱"

문장이 구체적일수록, 이후의 화면·기능·데이터 구조가 모두 선명해집니다.

제품의 실패는 개발 단계가 아니라 문제 정의 단계에서 이미 시작되는 경우가 많습니다.

Day 2 — 입력과 출력 설계하기

사용자가 넣는 값(Input)과 얻는 값(Output)을 표처럼 적습니다.

• Input: 상품명, 현재 수량, 입고일
• Output: 부족 재고 알림, 주간 리포트, 추천 발주량

이 작업을 먼저 끝내면, 디자인이 흔들리지 않습니다. UI는 결국 데이터의 형태를 시각적으로 번역한 결과물이기 때문입니다.

Day 3 — V0/Bolt로 화면 초안 만들기

이 날의 목표는 아름다운 화면이 아닙니다. 동작하는 화면입니다.

• 폼 입력이 되는가?
• 버튼이 눌리는가?
• 결과 영역이 보이는가?

처음부터 디테일에 집착하면 일정이 무너집니다. 구조가 먼저고 스타일은 나중입니다.

Day 4 — Cursor로 로직 연결하기

이제 화면에 행동을 붙입니다. 핵심은 한 번에 크게 시키지 않는 것입니다.

• "재고 입력 폼 submit 로직만 먼저 구현해줘"
• "유효성 검사만 추가해줘"
• "리포트 API 연결만 해줘"

작은 단위로 지시하고 바로 검증하면, 오류를 빨리 잡고 맥락 손실을 줄일 수 있습니다.

Day 5 — 실제 데이터로 테스트하기

샘플 데이터 대신, 실제 업무 데이터를 넣어봅니다. 이 단계에서 진짜 문제가 드러납니다.

• 날짜 형식 충돌
• 공백/특수문자 처리
• 비정상 입력 예외

이 날의 목적은 "잘되는지 확인"이 아니라 어디서 망가지는지 찾는 것입니다.

Day 6 — 사용 흐름 단순화하기

기능을 추가하는 날이 아닙니다. 덜어내는 날입니다.

• 처음 보는 사람도 30초 안에 이해하는가?
• 설명 없이 다음 행동을 고를 수 있는가?
• 불필요한 클릭이 있는가?

좋은 서비스는 기능이 많은 제품이 아니라, 망설임이 적은 제품입니다.

Day 7 — 배포 후 피드백 루프 열기

작게 배포하고 최소 3명에게 직접 사용하게 합니다.

체크 포인트:

• 어디서 멈췄는지
• 어떤 문구가 헷갈렸는지
• 어떤 기능을 기대했는지

피드백의 핵심은 "좋아요"가 아닙니다. 망설이는 순간의 위치입니다. 그 지점이 다음 개선의 시작점입니다.

실전 운영 원칙 3가지

1) 완성보다 검증

완성도 100점보다 검증 속도 10배가 더 중요합니다.

2) 기능보다 흐름

사용자가 자연스럽게 다음 행동으로 이동하는지 먼저 봅니다.

3) 의지보다 시스템

"열심히"보다 "반복 가능한 운영 구조"가 오래 갑니다.

마무리

코딩을 모르는데 시작해도 되냐는 질문을 자주 받습니다. 제 대답은 늘 같습니다.

"모르기 때문에 더 빨리 시작해야 합니다."

학습은 기다리는 동안 쌓이지 않습니다. 실행한 뒤에만 남습니다.

오늘 할 일은 거창하지 않아도 됩니다. 문제를 한 문장으로 쓰고, 첫 화면 하나를 띄우세요.

그 순간부터 당신은 소비자가 아니라 제작자가 됩니다.