3.9 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 빠른 수정 | 빠른 수정과 임시 변경을 수행하는 방법 |
|
전체 BMad Method가 필요하지 않은 버그 수정, 리팩터링, 작은 목표 변경에는 빠른 개발을 사용하세요.
사용 시점
- 원인이 명확하고 알려진 버그 수정
- 몇 개 파일 안에 제한된 작은 리팩터링(이름 변경, 추출, 구조 변경)
- 작은 기능 조정이나 설정 변경
- 의존성 업데이트
:::note[필수 조건]
- BMad Method 설치(
npx bmad-method install) - AI 기반 IDE(Claude Code, Cursor 또는 유사 도구) :::
단계
1. 새 채팅 시작
AI IDE에서 새 채팅 세션을 엽니다. 이전 워크플로 세션을 재사용하면 컨텍스트 충돌이 생길 수 있습니다.
2. 의도 전달
빠른 개발은 호출 전, 호출과 함께, 또는 호출 후에 자유 형식 의도를 받을 수 있습니다. 예를 들면 다음과 같습니다.
run quick-dev - 빈 비밀번호를 허용하는 로그인 검증 버그를 수정해 줘.
run quick-dev - https://github.com/org/repo/issues/42 를 수정해 줘
run quick-dev - _bmad-output/implementation-artifacts/my-intent.md의 의도를 구현해 줘
문제는 인증 미들웨어에 있는 것 같아요. 토큰 만료를 확인하지 않습니다.
확인해 보니 src/auth/middleware.ts 47번째 줄에서 exp 확인을 완전히 건너뜁니다.
run quick-dev
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와 어떻게 맞물리는지는 빠른 개발을 참고하세요.