바이브 코딩의 기준을 만들다

"AI한테 '이거 만들어줘' 하면 뚝딱 나온다. 문제는 — 뚝딱 나온 걸 일주일 뒤의 내가 못 알아본다는 것이었다."

요즘 나는 코드를 '치지' 않는다. 말로 한다. "박수 두 번 치면 깨어나는 자비스 만들어줘", "손가락으로 입자를 휘젓는 화면 만들어줘" — 그러면 AI가 만들어준다. 이른바 바이브 코딩(vibe coding). 감으로, 흐름으로, 대화로 만든다. 신세계였다. 하루에 만들던 게 한 시간이 됐다.

그런데 한 달쯤 신나게 만들고 나니, 이상한 일이 벌어졌다.

"이거 내가 만든 거 맞나?"

분명 내 손(정확히는 내 말)으로 만든 건데, 며칠 지나니 왜 이렇게 짰는지, 뭘 하려던 건지 기억이 안 났다. 파일은 늘어나는데 어디에 뭐가 있는지 모르겠고, 멀쩡하던 기능이 새 기능 추가하다 깨졌다. 분명 빨라졌는데, 어느 순간부터 고치는 시간이 만드는 시간보다 길어졌다.

이유는 분명했다. "무엇을 만들지"도, "어떻게 만들었는지"도 어디에도 안 적혀 있었다. 머릿속에만 있었고, 머릿속은 사흘이면 지워졌다. 속도를 얻고 기록을 잃은 것이다.

그래서 정했다. 바이브 코딩에도 기준이 있어야 한다. 자유롭게 만들되, 세 개의 뼈대는 반드시 거치기로.

바이브 코딩의 기준 — 3단계

거창한 방법론이 아니다. 딱 세 단계다. 만들기 전에 두 번 생각하고(①②), 만든 뒤 한 번 남긴다(③).

① PRD — "무엇을, 왜"

PRD는 거창한 문서가 아니라 '시작하기 전 합의문'이다. 코드 한 줄 짜기 전에 이걸 먼저 적는다.

• 목적/배경 — 왜 만드나? 어떤 불편을 없애나?
• 사용자/상황 — 누가, 언제, 어디서 쓰나?
• 핵심 기능 — 꼭 되어야 하는 것 (우선순위 순)
• 범위 — ✅ 이번에 할 것 / ❌ 안 할 것. 이게 제일 중요하다. 안 할 것을 못 정하면 끝없이 커진다.
• 성공 기준 — 뭐가 되면 "완성"인가

한 장이면 충분하다. 이 한 장이 "만들다 보니 산으로 가는" 사고를 막는다.

② 설계도 — "어떻게"

무엇을 정했으면, 이제 어떻게 생겼는지를 그린다. 머릿속 그림을 밖으로 꺼내는 단계다.

• 구조 — 파일·모듈을 어떻게 나눌지
• 데이터 흐름 — 입력 → 처리 → 출력 (화살표로)
• 화면 배치 — 위/가운데/아래에 뭐가 오나
• 도식 — 말로 열 줄 쓸 걸 그림 한 장으로. (이 글 위의 도표처럼)
• 엣지케이스 — 실패하면? 입력이 비면? 미리 정해둔다

설계는 완벽할 필요 없다. "이렇게 갈게요"가 한눈에 보이면 충분하다. 그림이 있으면 AI도 훨씬 정확하게 만든다.

③ 문서화 — "남기기"

가장 자주 건너뛰는, 그러나 가장 중요한 단계. 만든 직후에 미래의 나에게 편지를 쓴다.

• 가이드북 — 실행법·조작법·핵심 구현. 그리고 버전(v1, v2…)을 박는다
• 저장 — 메모앱/위키에, 관련 글과 링크로 엮어서
• 백업 — 크게 고치기 전엔 날짜 붙인 스냅샷. "되돌릴 수 있다"는 안심
• 공유 후보 — 남들에게도 쓸모 있으면 블로그로 (지금 이 글처럼)

문서화를 하고 나니 신기한 일이 벌어졌다. 다음에 같은 걸 만들 때 0에서 시작하지 않게 됐다. v1이 v2의 출발선이 됐다.

작은 일은 가볍게, 큰 일은 충실히

오해는 말자. 버튼 색 하나 바꾸는 데 PRD를 쓰자는 게 아니다. 작은 일은 가볍게, 큰 일은 3단계를 충실히. 핵심은 규칙의 무게가 아니라 습관이다 — 만들기 전에 한 번 생각하고, 만든 뒤 꼭 남긴다.

마무리

바이브 코딩의 진짜 힘은 '빨리 만드는 것'이 아니었다. 빨리 만든 걸 잃지 않는 것이었다. 속도는 AI가 준다. 방향과 기록은 내가 잡는다. 그 둘이 만나야 비로소 쌓인다.

감으로 만들되, 기준 위에서. 그게 내가 정한 바이브 코딩의 기준이다.

---

나만의 AI 비서로 이것저것 만들어가는 과정을 공개합니다. 구독하면 다음 편도 받아보실 수 있어요.