--- title: '빠른 수정' description: 빠른 수정과 임시 변경을 수행하는 방법 sidebar: order: 6 --- 전체 BMad Method가 필요하지 않은 버그 수정, 리팩터링, 작은 목표 변경에는 **빠른 개발**을 사용하세요. ## 사용 시점 - 원인이 명확하고 알려진 버그 수정 - 몇 개 파일 안에 제한된 작은 리팩터링(이름 변경, 추출, 구조 변경) - 작은 기능 조정이나 설정 변경 - 의존성 업데이트 :::note[필수 조건] - BMad Method 설치(`npx bmad-method install`) - AI 기반 IDE(Claude Code, Cursor 또는 유사 도구) ::: ## 단계 ### 1. 새 채팅 시작 AI IDE에서 **새 채팅 세션**을 엽니다. 이전 워크플로 세션을 재사용하면 컨텍스트 충돌이 생길 수 있습니다. ### 2. 의도 전달 빠른 개발은 호출 전, 호출과 함께, 또는 호출 후에 자유 형식 의도를 받을 수 있습니다. 예를 들면 다음과 같습니다. ```text run quick-dev - 빈 비밀번호를 허용하는 로그인 검증 버그를 수정해 줘. ``` ```text run quick-dev - https://github.com/org/repo/issues/42 를 수정해 줘 ``` ```text run quick-dev - _bmad-output/implementation-artifacts/my-intent.md의 의도를 구현해 줘 ``` ```text 문제는 인증 미들웨어에 있는 것 같아요. 토큰 만료를 확인하지 않습니다. 확인해 보니 src/auth/middleware.ts 47번째 줄에서 exp 확인을 완전히 건너뜁니다. run quick-dev ``` ```text run quick-dev > 무엇을 하고 싶나요? UserService가 콜백 대신 async/await를 사용하도록 리팩터링해 줘. ``` 일반 텍스트, 파일 경로, GitHub 이슈 URL, 버그 트래커 링크 등 LLM이 구체적 의도로 해석할 수 있는 것이면 됩니다. ### 3. 질문에 답하고 승인 빠른 개발은 구현 전에 명확화 질문을 하거나 짧은 사양을 제시해 승인을 요청할 수 있습니다. 질문에 답하고 계획이 만족스러우면 승인하세요. ### 4. 리뷰하고 푸시 빠른 개발이 변경을 구현하고, 자체 리뷰하고, 문제를 패치하고, 로컬에 커밋합니다. 완료되면 영향을 받은 파일을 에디터에서 엽니다. - diff를 훑어 변경이 의도와 맞는지 확인합니다 - 이상한 점이 있으면 에이전트에게 수정할 내용을 말하세요. 같은 세션에서 반복할 수 있습니다 만족하면 커밋을 푸시하세요. 빠른 개발이 푸시와 PR 생성을 제안합니다. :::caution[문제가 생기면] 푸시한 변경이 예상치 못한 문제를 일으키면 `git revert HEAD`로 마지막 커밋을 깔끔하게 되돌리세요. 그런 다음 새 채팅을 시작하고 빠른 개발을 다시 실행해 다른 접근을 시도합니다. ::: ## 얻는 결과 - 수정 또는 리팩터링이 적용된 소스 파일 - 테스트 스위트가 있다면 통과하는 테스트 - Conventional Commit 형식의 푸시 준비 완료 커밋 ## 보류 작업 빠른 개발은 각 실행을 하나의 목표에 집중하게 합니다. 요청에 여러 독립 목표가 있거나 리뷰에서 변경과 무관한 기존 문제가 드러나면, 모든 것을 한 번에 처리하지 않고 구현 산출물 디렉터리의 `deferred-work.md` 파일에 따로 보류합니다. 실행 후 이 파일을 확인하세요. 나중에 다시 볼 작업 백로그입니다. 각 보류 항목은 이후 새 빠른 개발 실행에 넣을 수 있습니다. ## 정식 계획으로 업그레이드할 때 다음과 같다면 전체 BMad Method 사용을 고려하세요. - 변경이 여러 시스템에 영향을 주거나 많은 파일의 조율된 업데이트가 필요합니다 - 범위를 확신하지 못해 먼저 요구사항 발견이 필요합니다 - 팀을 위해 문서나 아키텍처 결정을 기록해야 합니다 빠른 개발이 BMad Method와 어떻게 맞물리는지는 [빠른 개발](../explanation/quick-dev.md)을 참고하세요.