현업 개발자의 바이브코딩 문서 관리법 — 라이브노트

단계 명세만 11개였던 개인 PT 앱 MoFit의 문서를 "코드로 알 수 없는 것만 남긴다"는 기준으로 걷어냈어요. 다시 불어나지 않게 스킬과 커밋 훅, 빨라진 테스트 게이트까지 걸었고요.

이 노트를 읽고 나면 할 수 있는 것

1. 내 프로젝트 문서를 남김·지움·고침으로 판정하게 하는 프롬프트를 그대로 넣어 보기
2. 문서로 적으려던 규칙 중 린터·테스트로 옮길 것을 골라내기
3. 세션이 끝날 때마다 "문서에 무엇을 넣고 뺄지" 브리핑받는 스킬과, 문서가 다시 불어나지 않게 막는 훅 만들기

다시보기: https://youtu.be/8LLLy3dn3fg · 3시간 16분, 채팅 질문 답변은 2시간 43분부터

목차

• 이해도부터 끌어올리기 ▶ 0:03:21
• 남는 문서는 두 종류뿐이에요 ▶ 0:11:04
• 규칙은 문서 말고 린터로 ▶ 0:24:33
• 기획 점검은 파악부터 시키기 ▶ 0:34:19
• 세션이 끝날 때마다 session-docs ▶ 0:46:10
• 문서가 다시 불어나지 않게 하는 장치 ▶ 2:06:59
• 테스트 게이트의 속도 ▶ 2:00:00
• Q&A ▶ 2:43:23
• 오늘 해볼 것 ▶ 3:05:01

이해도부터 끌어올리기 ▶ 0:03:21

MoFit은 제가 PT를 받으면서 트레이너분과 운동 중량을 같이 보려고 만들고 있는 앱이에요. 라이브 때만 손대다 보니 구조를 많이 까먹은 상태였어요. 그래서 문서를 손보기 전에 코드베이스 이해도부터 다시 올렸어요. ▶ 0:03:39

에포트(effort, 모델이 생각에 쓰는 양) 기준은 단순해요. 잘 모를 때는 높이고, 이해가 쌓이면 내려요. ▶ 0:04:20

이날 일은 새 설계가 아니라 문서 정리라서 Cursor의 Grok으로 옮겼어요. 제가 보는 난이도 기준은 고려할 컨텍스트가 얼마나 많은가예요. ▶ 0:06:55

이 프로젝트에 대해서 파악해봐. mermaid 문법도 적절히 사용해

30초 만에 구조가 나왔어요. 여기서 보이는 게 하나 있어요. 이렇게 대강만 시켜도 빨리 나오는 정보는 문서에 담길 필요가 없는 거예요. ▶ 0:08:16

에포트를 높이면 똑똑해진다고 생각하기 쉬운데, 방향을 이 정도로 주면 높을 필요가 없어요. ▶ 2:25:43 저는 medium을 제일 좋아하고 low도 많이 쓰고, extra high는 거의 안 써요. ▶ 2:25:02