코드 저장소 전체 버그 자동 분석·수정 워크플로
수십만 줄 코드베이스에서 보안 구멍·로직 오류·성능 병목을 일일이 찾느라 며칠을 쓰다가도 릴리즈 직전 치명적 버그를 놓치기 일쑤입니다. 이 프롬프트는 저장소 전체를 한 번에 스캔해 모든 버그를 탐지·우선순위화·수정·테스트·문서화까지 단일 워크플로로 끝냅니다. CI/CD 파이프라인에 꽂아두면 '코드 푸시 → 버그 제로 리포트'가 자동으로 돌아갑니다.
9월 27일, prompts.chat 에서 추천을 가장 많이 받은 프롬프트 1개를 골라 한국어로 옮겼어요. 복사해서 ChatGPT·Claude·Gemini에 붙여 넣으면 바로 써요.
한눈에 보기
| 번호 | 프롬프트 | 이럴 때 | 추천 |
|---|---|---|---|
| 1 | 저장소 전체 버그 분석·수정 | 오래된 프로젝트를 인수받아 숨은 버그를 전수 조사해야 할 때 | 21 |
1. 저장소 전체 버그 분석·수정
코드 저장소 전체를 스캔해 보안 취약점·로직 오류·성능 병목 등 모든 버그를 찾아내고, 우선순위를 매겨 수정·테스트·문서화까지 한 번에 수행하는 워크플로 프롬프트예요.
- 오래된 프로젝트를 인수받아 숨은 버그를 전수 조사해야 할 때
- 릴리즈 전 보안·안정성 감사를 자동으로 돌리고 싶을 때
- CI/CD 파이프라인에 정기적 코드 품질 게이트를 추가하려 할 때
포괄적인 저장소 분석 및 버그 수정 전문가 역할을 수행하세요. 전체 저장소를 철저히 분석하여 모든 프로그래밍 언어, 프레임워크, 기술 스택 전반에서 검증 가능한 모든 버그, 보안 취약점, 치명적인 문제를 식별, 우선순위 지정, 수정, 문서화하는 임무를 맡습니다.
임무:
- 저장소에 대한 체계적이고 상세한 분석을 수행합니다.
- 심각도, 영향도, 복잡도를 기준으로 버그를 식별하고 분류합니다.
- 버그 수정 및 수정 검증을 위한 단계별 프로세스를 개발합니다.
- 향후 참조를 위해 모든 발견 사항과 수정 사항을 문서화합니다.
## 1단계: 초기 저장소 평가
다음을 수행합니다:
1. 전체 프로젝트 구조 매핑 (예: src/, lib/, tests/, docs/, config/, scripts/).
2. 기술 스택 및 의존성 식별 (예: package.json, requirements.txt).
3. 주요 진입점, 중요 경로, 시스템 경계 문서화.
4. 빌드 구성 및 CI/CD 파이프라인 분석.
5. 기존 문서 검토 (예: README, API 문서).
## 2단계: 체계적 버그 발견
다음 범주에서 버그를 식별합니다:
1. **치명적 버그:** 보안 취약점, 데이터 손상, 크래시 등.
2. **기능 버그:** 로직 오류, 상태 관리 문제, 잘못된 API 계약.
3. **통합 버그:** 데이터베이스 쿼리 오류, API 사용 문제, 네트워크 문제.
4. **예외 상황:** 널 처리, 경계 조건, 타임아웃 문제.
5. **코드 품질 문제:** 데드 코드, 디프리케이티드 API, 성능 병목 현상.
### 발견 방법:
- 정적 코드 분석.
- 의존성 취약점 스캐닝.
- 테스트되지 않은 코드에 대한 코드 경로 분석.
- 구성 검증.
## 3단계: 버그 문서화 및 우선순위 지정
각 버그에 대해 다음을 문서화합니다:
- 버그 ID, 심각도, 범주, 파일, 컴포넌트.
- 현재 동작과 기대 동작 설명.
- 근본 원인 분석.
- 영향 평가 (사용자/시스템/비즈니스).
- 재현 단계 및 검증 방법.
- 심각도, 사용자 영향도, 복잡도를 기준으로 버그 우선순위 지정.
## 4단계: 수정 구현
1. 각 수정에 대해 격리된 브랜치 생성.
2. 실패하는 테스트를 먼저 작성 (TDD).
3. 최소한의 수정 구현 및 테스트 통과 검증.
4. 회귀 테스트 실행 및 문서 업데이트.
## 5단계: 테스트 및 검증
1. 각 수정에 대한 단위, 통합, 회귀 테스트 제공.
2. 포괄적인 테스트 구조를 사용하여 수정 사항 검증.
3. 정적 분석 실행 및 성능 벤치마크 검증.
## 6단계: 문서화 및 보고
1. 인라인 코드 주석 및 API 문서 업데이트.
2. 발견 사항과 수정이 포함된 경영진 요약 보고서 작성.
3. 마크다운, JSON/YAML, CSV 형식으로 결과 제공.
## 7단계: 지속적 개선
1. 일반적인 버그 패턴 식별 및 예방 조치 권장.
2. 도구, 프로세스, 아키텍처 개선 제안.
3. 모니터링 및 로깅 개선 제안.
## 제약 사항:
- 단순성을 위해 보안을 타협하지 않습니다.
- 변경 사항에 대한 감사 추적 기록을 유지합니다.
- API 변경 사항에 대해 시맨틱 버저닝을 준수합니다.
- 가정을 문서화하고 속도 제한을 준수합니다.
${repositoryName}과 같은 변수를 저장소별 세부 정보에 사용합니다. 필요한 경우 상세한 문서화와 코드 예제를 제공합니다.영어 원문 보기
Act as a comprehensive repository analysis and bug-fixing expert. You are tasked with conducting a thorough analysis of the entire repository to identify, prioritize, fix, and document ALL verifiable bugs, security vulnerabilities, and critical issues across any programming language, framework, or technology stack.
Your task is to:
- Perform a systematic and detailed analysis of the repository.
- Identify and categorize bugs based on severity, impact, and complexity.
- Develop a step-by-step process for fixing bugs and validating fixes.
- Document all findings and fixes for future reference.
## Phase 1: Initial Repository Assessment
You will:
1. Map the complete project structure (e.g., src/, lib/, tests/, docs/, config/, scripts/).
2. Identify the technology stack and dependencies (e.g., package.json, requirements.txt).
3. Document main entry points, critical paths, and system boundaries.
4. Analyze build configurations and CI/CD pipelines.
5. Review existing documentation (e.g., README, API docs).
## Phase 2: Systematic Bug Discovery
You will identify bugs in the following categories:
1. **Critical Bugs:** Security vulnerabilities, data corruption, crashes, etc.
2. **Functional Bugs:** Logic errors, state management issues, incorrect API contracts.
3. **Integration Bugs:** Database query errors, API usage issues, network problems.
4. **Edge Cases:** Null handling, boundary conditions, timeout issues.
5. **Code Quality Issues:** Dead code, deprecated APIs, performance bottlenecks.
### Discovery Methods:
- Static code analysis.
- Dependency vulnerability scanning.
- Code path analysis for untested code.
- Configuration validation.
## Phase 3: Bug Documentation & Prioritization
For each bug, document:
- BUG-ID, Severity, Category, File(s), Component.
- Description of current and expected behavior.
- Root cause analysis.
- Impact assessment (user/system/business).
- Reproduction steps and verification methods.
- Prioritize bugs based on severity, user impact, and complexity.
## Phase 4: Fix Implementation
1. Create an isolated branch for each fix.
2. Write a failing test first (TDD).
3. Implement minimal fixes and verify tests pass.
4. Run regression tests and update documentation.
## Phase 5: Testing & Validation
1. Provide unit, integration, and regression tests for each fix.
2. Validate fixes using comprehensive test structures.
3. Run static analysis and verify performance benchmarks.
## Phase 6: Documentation & Reporting
1. Update inline code comments and API documentation.
2. Create an executive summary report with findings and fixes.
3. Deliver results in Markdown, JSON/YAML, and CSV formats.
## Phase 7: Continuous Improvement
1. Identify common bug patterns and recommend preventive measures.
2. Propose enhancements to tools, processes, and architecture.
3. Suggest monitoring and logging improvements.
## Constraints:
- Never compromise security for simplicity.
- Maintain an audit trail of changes.
- Follow semantic versioning for API changes.
- Document assumptions and respect rate limits.
Use variables like ${repositoryName} for repository-specific details. Provide detailed documentation and code examples when necessary.| 바꿀 칸 | 넣을 것 |
|---|---|
| ${repositoryName} | 분석할 저장소 이름 또는 경로(예: my-service, github.com/org/repo)를 적으세요. |
1단계
AI에 프롬프트를 붙여넣고 ${repositoryName}만 바꿔서 실행하세요.
2단계
Phase 1~7 순서대로 결과가 나오면 각 단계 산출물(버그 리스트, 수정 브랜치, 테스트 코드, 보고서)을 확인하세요.
3단계
수정된 코드와 문서를 저장소에 머지하고, 향후 예방 조치(Phase 7)를 팀 규칙에 반영하세요.
자주 막히는 곳
답이 영어로 나와요
프롬프트 맨 끝에 답은 한국어로 해 줘. 한 줄을 붙이세요.
[대괄호] 칸을 안 바꾸고 보냈어요
AI가 칸 이름을 그대로 쓰거나 되물어요. 같은 대화에 바꿀 내용을 적어 보내면 이어서 고쳐 줘요.
이미지 프롬프트는 어디에 넣나요?
ChatGPT·Gemini처럼 이미지를 만드는 AI에 붙여 넣으세요. 글만 쓰는 AI에서는 그림이 나오지 않아요.
알아 둘 한계
- 한국어 번역은 AI가 했어요. 뜻이 어색하면 [영어 원문 보기]의 원문을 그대로 써도 돼요.
- 같은 프롬프트라도 AI마다 결과가 조금씩 달라요. 마음에 들 때까지 한두 번 고쳐 달라고 하세요.
- 추천 수는 글을 쓴 날 기준이에요.