바이브 코딩할 때 가이드라인으로 .md 파일 쓰시나요?
Do you use .md files as guardrails when vibe coding?
핵심 요약
AI 코딩 시 프로젝트 구조와 규칙을 정의한 .md 파일을 활용해 가이드라인으로 삼는 방식에 대한 논의.
- 프로젝트 가이드라인 — AI가 참조할 수 있도록 구조와 규칙을 .md 파일로 정리함.
- 토큰 절약 — 전체 코드를 읽게 하는 대신 요약된 문서로 AI의 컨텍스트를 관리함.
- 구현 계획 — 독립적인 .md 파일로 계획을 세워 에이전트 간 컨텍스트를 공유함.
- 버전 관리 — 깃(Git) 스테이징과 커밋을 통해 변경 사항을 추적하고 검토함.
우선 저는 전문 개발자가 아닙니다. 그러니 제 관찰 결과는 적당히 걸러 들으세요.
바이브 코딩을 할 때, 가이드라인으로 ".md" 파일을 만드시나요, 아니면 소스 코드 변경 사항을 추적하기 위해 주로 GitHub에 의존하시나요?
저는 이 둘이 서로 다른 것이라는 생각이 들기 시작했습니다.
GitHub는 코드의 변경 사항을 추적하는 데 아주 좋습니다.
하지만 ".md" 파일은 프로젝트가 왜 이런 식으로 구조화되었는지, AI가 건드리지 말아야 할 부분은 무엇인지, 어떤 규칙을 따라야 하는지, 그리고 이미 어떤 결정들이 내려졌는지를 설명해 줄 수 있습니다.
예를 들면 이렇습니다:
- "README.md" - 앱의 기능
- "ARCHITECTURE.md" - 시스템 설계 방식
- "PROJECT_RULES.md" - AI가 변경해서는 안 되는 것
- "API.md" - 예상되는 백엔드 동작
- "DATABASE.md" - 스키마 및 마이그레이션 규칙
- "PROMPT.md" - 특히 복잡한 프로젝트에서 코드를 생성하는 데 사용되는 실제 프롬프트
바이브 코딩을 하면서 이런 종류의 파일들을 실제로 유지 관리하는 사람이 얼마나 되는지 궁금합니다.
여러분은 ".md" 파일을 프로젝트 가이드라인으로 사용하시나요, 아니면 그냥 커밋, 브랜치, 풀 리퀘스트에 의존해서 상황을 통제하시나요?

