4단계 흐름: 재진술, PRD, 확인, 코딩
소프트웨어 공학의 요구사항 확인 단계를 인간-AI 협업에 도입합니다. AI는 코드를 작성하기 전에 반드시 요구사항을 재진술하고, PRD를 작성하며, 명시적 승인을 받아야 합니다. 여기에 일괄 수정 중단점과 중복 감지 규칙을 더해 실행 전에 피해 범위를 통제합니다.
실제 요구사항 "보고서 내보내기 기능을 추가해줘"로 전체 흐름을 실행해봅니다. "다음 단계"를 클릭하고 4단계에 주목하세요: "승인"을 클릭하지 않으면 AI는 코드를 작성하지 않습니다.
"이해한 후 코딩해주세요"라는 말은 너무 모호합니다. AI는 스스로 "이미 이해했다"고 판단하고 바로 시작합니다. "PRD 작성, 승인 대기"와 같은 구체적인 동작을 명시해야 AI가 실제로 멈춥니다. 실제로 간단한 한 줄 수정은 AI가 스스로 PRD가 필요 없다고 판단합니다 — 이 흐름은 주로 다중 파일 변경과 신규 기능 개발, 즉 재작업 비용이 가장 높은 작업을 차단합니다.
규칙 원문: "3개 파일 초과 수정 시 반드시 수정 계획을 먼저 나열하고 사용자 확인 후 진행해야 합니다." 슬라이더를 드래그하여 이번에 수정할 파일 수를 바꾸고 중단점이 언제 트리거되는지 확인하세요.
어떤 파일을 변경할지
완전한 파일 목록입니다. 사람이 먼저 범위가 맞는지 확인하고, 그 다음 내용을 검토합니다. 목록 자체가 "왜 이 요구사항에 설정 파일이 포함되지?"와 같은 이상을 드러낼 수 있습니다.
각 파일에서 무엇을 변경할지
파일별로 변경 내용을 명확히 작성합니다. AI가 하나의 요구사항을 빌미로 관련 없는 리팩토링이나 정리를 "편의상" 하는 것을 방지합니다.
변경 간 의존 관계
어떤 것을 먼저 바꾸고, 어떤 것을 나중에 바꾸며, 누가 누구에 의존하는지 명시합니다. 연쇄적으로 파일을 수정한 후 접근 방식이 잘못됐다는 것을 발견하고 롤백 비용이 너무 높아지는 것을 방지합니다.
임계값은 프로젝트별로 조정할 수 있습니다. 3개 파일은 저자 프로젝트에서의 경험치이며, 신중한 프로젝트는 1로 낮추고, 빠른 프로토타입은 5까지 늘릴 수 있습니다.
문제: AI는 프로젝트에 이미 있는 구현을 모릅니다
AI의 컨텍스트는 현재 대화에만 국한됩니다 — 3개월 전 다른 대화에서 작성된 유틸리티 함수는 볼 수 없습니다. 제약 없이는 같은 formatDate가 네 번 작성되고, 매번 동작이 약간씩 달라집니다.
규칙: 먼저 검색, 그 다음 실행
- 기능 추가 전, 반드시 프로젝트에 유사한 구현이 있는지 먼저 검색해야 합니다
- 검색 범위: 관련 디렉토리의 함수명, 클래스명, 유틸리티 메서드
- 기존 구현을 발견했을 때 재사용 또는 확장을 우선합니다
중단점은 실행 전에 설정해야 합니다. 재진술과 PRD는 이해 오류를 차단하고, 수정 계획은 연쇄적 잘못된 변경을 차단하며, 중복 감지는 바퀴의 재발명을 차단합니다. 세 가지 관문 모두 사후 롤백보다 저렴합니다.
출처: rule-opensource.mdc 제2장 "요구사항 처리 및 개발 흐름"에 해당하며, 저장소 itshen/xs_vibe_rules.