코드 저장소 전체 버그 자동 분석·수정 워크플로 프롬프트
수만 줄 코드베이스에서 보안 구멍과 로직 오류를 일일이 찾느라 며칠을 쓰느라 배포가 자꾸 미뤄집니다. 이 프롬프트는 저장소 전체를 한 번에 스캔해 버그 유형별로 우선순위를 매기고, 수정·테스트·문서화까지 파이프라인으로 엮어 줍니다. CI/CD에 붙여 넣으면 푸시할 때마다 자동으로 검수·패치·리포트가 돌아갑니다.
9월 27일, prompts.chat 에서 추천을 가장 많이 받은 프롬프트 1개를 골라 한국어로 옮겼어요. 복사해서 ChatGPT·Claude·Gemini에 붙여 넣으면 바로 써요.
한눈에 보기
| 번호 | 프롬프트 | 이럴 때 | 추천 |
|---|---|---|---|
| 1 | 저장소 전체 버그 분석·수정 | 새로 맡은 프로젝트에서 숨은 버그와 취약점을 한눈에 파악하고 싶을 때 | 21 |
1. 저장소 전체 버그 분석·수정
코드 저장소 전체를 스캔해 보안·로직·연동 버그를 찾아내고, 우선순위대로 고친 뒤 테스트와 문서까지 자동으로 정리해 주는 워크플로 프롬프트예요.
- 새로 맡은 프로젝트에서 숨은 버그와 취약점을 한눈에 파악하고 싶을 때
- 릴리스 전 회귀 테스트와 보안 점검을 체계적으로 돌리고 싶을 때
- 레거시 코드베이스를 리팩토링하기 전 현황을 문서화해야 할 때
전체 저장소 분석 및 버그 수정 전문가 역할을 수행한다. 모든 프로그래밍 언어, 프레임워크, 기술 스택에 걸쳐 검증 가능한 모든 버그, 보안 취약점, 치명적인 문제를 식별, 우선순위 지정, 수정, 문서화하기 위해 전체 저장소를 철저히 분석하는 임무를 맡는다.
수행 과제는 다음과 같다:
- 저장소에 대한 체계적이고 상세한 분석 수행.
- 심각도, 영향도, 복잡성을 기준으로 버그 식별 및 분류.
- 버그 수정 및 검증을 위한 단계별 프로세스 개발.
- 향후 참조를 위해 모든 발견 사항 및 수정 사항 문서화.
## 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, ../legacy-app)를 적으세요. |
1단계
AI 채팅창에 프롬프트를 붙여넣고 ${repositoryName}만 자기 저장소명으로 바꿉니다.
2단계
AI가 1~7단계(구조 파악 → 버그 탐색 → 문서화 → 수정 → 테스트 → 보고서 → 개선안)를 순서대로 수행하도록 지켜보며, 중간 산출물(버그 리스트, 테스트 코드, 보고서)을 파일로 저장하라고 지시하세요.
3단계
생성된 브랜치·테스트·문서를 실제 리포지토리에 적용해 PR을 올리고, CI 통과 뒤 머지합니다.
자주 막히는 곳
답이 영어로 나와요
프롬프트 맨 끝에 답은 한국어로 해 줘. 한 줄을 붙이세요.
[대괄호] 칸을 안 바꾸고 보냈어요
AI가 칸 이름을 그대로 쓰거나 되물어요. 같은 대화에 바꿀 내용을 적어 보내면 이어서 고쳐 줘요.
이미지 프롬프트는 어디에 넣나요?
ChatGPT·Gemini처럼 이미지를 만드는 AI에 붙여 넣으세요. 글만 쓰는 AI에서는 그림이 나오지 않아요.
알아 둘 한계
- 한국어 번역은 AI가 했어요. 뜻이 어색하면 [영어 원문 보기]의 원문을 그대로 써도 돼요.
- 같은 프롬프트라도 AI마다 결과가 조금씩 달라요. 마음에 들 때까지 한두 번 고쳐 달라고 하세요.
- 추천 수는 글을 쓴 날 기준이에요.