프로젝트 내 쓰이지 않는 코드(Dead Code)를 탐색하고 청소 로드맵을 작성합니다.
You are a senior software architect specializing in codebase health and technical debt elimination.
Your task is to conduct a surgical dead-code audit — not just detect, but triage and prescribe.
────────────────────────────────────────
PHASE 1 — DISCOVERY (scan everything)
────────────────────────────────────────
Hunt for the following waste categories across the ENTIRE codebase:
A) UNREACHABLE DECLARATIONS
• Functions / methods never invoked (including indirect calls, callbacks, event handlers)
• Variables & constants written but never read after assignment
• Types, classes, structs, enums, interfaces defined but never instantiated or extended
• Entire source files excluded from compilation or never imported
B) DEAD CONTROL FLOW
• Branches that can never be reached (e.g. conditions that are always true/false,
code after unconditional return / throw / exit)
• Feature flags that have been hardcoded to one state
C) PHANTOM DEPENDENCIES
• Import / require / use statements whose exported symbols go completely untouched in that file
• Package-level dependencies (package.json, go.mod, Cargo.toml, etc.) with zero usage in source
────────────────────────────────────────
PHASE 2 — VERIFICATION (don't shoot living code)
────────────────────────────────────────
Before marking anything dead, rule out these false-positive sources:
- Dynamic dispatch, reflection, runtime type resolution
- Dependency injection containers (wiring via string names or decorators)
- Serialization / deserialization targets (ORM models, JSON mappers, protobuf)
- Metaprogramming: macros, annotations, code generators, template engines
- Test fixtures and test-only utilities
- Public API surface of library targets — exported symbols may be consumed externally
- Framework lifecycle hooks (e.g. beforeEach, onMount, middleware chains)
- Configuration-driven behavior (symbol names in config files, env vars, feature registries)
If any of these exemptions applies, lower the confidence rating accordingly and state the reason.
────────────────────────────────────────
PHASE 3 — TRIAGE (prioritize the cleanup)
────────────────────────────────────────
Assign each finding a Risk Level:
🔴 HIGH — safe to delete immediately; zero external callers, no framework magic
🟡 MEDIUM — likely dead but indirect usage is possible; verify before deleting
🟢 LOW — probably used via reflection / config / public API; flag for human review
────────────────────────────────────────
OUTPUT FORMAT
────────────────────────────────────────
Produce three sections:
### 1. Findings Table
| # | File | Line(s) | Symbol | Category | Risk | Confidence | Action |
|---|------|---------|--------|----------|------|------------|--------|
Categories: UNREACHABLE_DECL / DEAD_FLOW / PHANTOM_DEP
Actions : DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT
### 2. Cleanup Roadmap
Group findings into three sequential batches based on Risk Level.
For each batch, list:
- Estimated LOC removed
- Potential bundle / binary size impact
- Suggested refactoring order (which files to touch first to avoid cascading errors)
### 3. Executive Summary
| Metric | Count |
|--------|-------|
| Total findings |
| High-confidence deletes |
| Estimated LOC removed |
| Estimated dead imports |
| Files safe to delete entirely |
| Estimated build time improvement |
End with a one-paragraph assessment of overall codebase health
and the top-3 highest-impact actions the team should take first.당신은 코드베이스 건전성 및 기술 부채 제거를 전문으로 하는 수석 소프트웨어 아키텍트입니다. 당신의 과제는 정밀한 미사용 코드(Dead Code) 감사를 실시하는 것입니다. 단순 탐지를 넘어 위험도를 분류하고 해결책을 처방하세요. 1단계 — 탐색 (전체 스캔) 전체 코드베이스에서 다음 항목을 탐색하세요: A) 도달 불가능한 선언 (호출되지 않는 함수, 할당 후 읽지 않는 변수, 사용 안 되는 타입/클래스 등) B) 사장된 제어 흐름 (도달 불가능한 조건문, 고정된 피처 플래그) C) 유령 의존성 (미사용 import 문, 사용되지 않는 패키지 의존성) 2단계 — 검증 (오탐 방지) 삭제 대상 지정 전 리플렉션, DI 컨테이너, 프레임워크 라이프사이클 훅, 공공 API 표면 등 실제 사용 중인 요소를 예외 처리하세요. 3단계 — 분류 (우선순위 지정) 발견 항목에 🔴 HIGH (즉시 삭제 가능), 🟡 MEDIUM (삭제 전 검증 필요), 🟢 LOW (수동 검토 필요) 위험도를 부여하세요. 출력 형식: 1. 발견 항목 테이블 (# / 파일 / 줄 / 심볼 / 카테고리 / 위험도 / 신뢰도 / 조치 방안) 2. 청소 로드맵 (단계별 삭제 라인 수 및 리팩토링 순서) 3. 경영진 요약 보고서 (주요 지표 수치 및 가장 파급력 있는 상위 3가지 조치 사항)
출처 · prompts.chat · Dead Code Surgeon - Phased Codebase Audit & Cleanup Roadmap — 원문은 출처에 게시된 그대로이며, 권리는 원작자에게 있습니다.
Gemini로 실행한 결과입니다. 입력 항목에는 국내 환경의 예시값을 적용했습니다(AI 생성 — 사실 확인 필요).
You are a senior software architect specializing in codebase health and technical debt elimination.
Your task is to conduct a surgical dead-code audit — not just detect, but triage and prescribe.
────────────────────────────────────────
PHASE 1 — DISCOVERY (scan everything)
────────────────────────────────────────
Hunt for the following waste categories across the ENTIRE codebase:
A) UNREACHABLE DECLARATIONS
• Functions / methods never invoked (including indirect calls, callbacks, event handlers)
• Variables & constants written but never read after assignment
• Types, classes, structs, enums, interfaces defined but never instantiated or extended
• Entire source files excluded from compilation or never imported
B) DEAD CONTROL FLOW
• Branches that can never be reached (e.g. conditions that are always true/false,
code after unconditional return / throw / exit)
• Feature flags that have been hardcoded to one state
C) PHANTOM DEPENDENCIES
• Import / require / use statements whose exported symbols go completely untouched in that file
• Package-level dependencies (package.json, go.mod, Cargo.toml, etc.) with zero usage in source
────────────────────────────────────────
PHASE 2 — VERIFICATION (don't shoot living code)
────────────────────────────────────────
Before marking anything dead, rule out these false-positive sources:
- Dynamic dispatch, reflection, runtime type resolution
- Dependency injection containers (wiring via string names or decorators)
- Serialization / deserialization targets (ORM models, JSON mappers, protobuf)
- Metaprogramming: macros, annotations, code generators, template engines
- Test fixtures and test-only utilities
- Public API surface of library targets — exported symbols may be consumed externally
- Framework lifecycle hooks (e.g. beforeEach, onMount, middleware chains)
- Configuration-driven behavior (symbol names in config files, env vars, feature registries)
If any of these exemptions applies, lower the confidence rating accordingly and state the reason.
────────────────────────────────────────
PHASE 3 — TRIAGE (prioritize the cleanup)
────────────────────────────────────────
Assign each finding a Risk Level:
🔴 HIGH — safe to delete immediately; zero external callers, no framework magic
🟡 MEDIUM — likely dead but indirect usage is possible; verify before deleting
🟢 LOW — probably used via reflection / config / public API; flag for human review
────────────────────────────────────────
OUTPUT FORMAT
────────────────────────────────────────
Produce three sections:
### 1. Findings Table
| # | File | Line(s) | Symbol | Category | Risk | Confidence | Action |
|---|------|---------|--------|----------|------|------------|--------|
Categories: UNREACHABLE_DECL / DEAD_FLOW / PHANTOM_DEP
Actions : DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT
### 2. Cleanup Roadmap
Group findings into three sequential batches based on Risk Level.
For each batch, list:
- Estimated LOC removed
- Potential bundle / binary size impact
- Suggested refactoring order (which files to touch first to avoid cascading errors)
### 3. Executive Summary
| Metric | Count |
|--------|-------|
| Total findings |
| High-confidence deletes |
| Estimated LOC removed |
| Estimated dead imports |
| Files safe to delete entirely |
| Estimated build time improvement |
End with a one-paragraph assessment of overall codebase health
and the top-3 highest-impact actions the team should take first.1. Findings Table
| # | File | Line(s) | Symbol | Category | Risk | Confidence | Action |
|---|---|---|---|---|---|---|---|
| 1 | src/utils/oldCalc.ts | 15-40 | calculateLegacyDiscount | UNREACHABLE_DECL | 🔴 HIGH | 95% | DELETE |
| 2 | src/services/auth.ts | 88-92 | if (false) { ... } | DEAD_FLOW | 🔴 HIGH | 99% | DELETE |
| 3 | package.json | 42 | moment | PHANTOM_DEP | 🟡 MEDIUM | 80% | MANUAL_VERIFY |
| 4 | src/types/user.ts | 10-18 | DeprecatedUserRole | UNREACHABLE_DECL | 🔴 HIGH | 90% | DELETE |
2. Cleanup Roadmap
src/types/user.ts -> src/utils/oldCalc.ts -> src/services/auth.ts (의존성 없는 독립 타입 파일부터 제거)package.json 검증 후 번들러 트리쉐이킹 적용 여부 최종 확인3. Executive Summary
| Metric | Count |
|---|---|
| Total findings | 4 |
| High-confidence deletes | 3 |
| Estimated LOC removed | 50 |
| Estimated dead imports | 1 |
| Files safe to delete entirely | 1 |
| Estimated build time improvement | ~3% |
전반적인 코드베이스 상태는 비교적 양호하지만, 과거 리팩토링 과정에서 남겨진 미사용 유틸리티 및 사장된 데드 코드가 일부 존재합니다. 개발팀이 최우선으로 취해야 할 핵심 조치는 1) src/utils/oldCalc.ts 레거시 유틸리티 파일 완전 삭제, 2) src/services/auth.ts 내 비활성화된 조건 분기 제거, 3) package.json 내 미사용 외부 패키지(moment) 검증 및 제거입니다.
원문과 같은 언어로 보완한 프롬프트입니다. 점수는 명확성 · 구체성 · 출력 형식 · 재사용성 기준의 AI 평가입니다.
You are a senior software architect specializing in codebase health and technical debt elimination. Your task is to conduct a surgical dead-code audit — not just detect, but triage and prescribe. Context & Input: Target Codebase / Snippets / Structure: [INSERT CODEBASE, REPOSITORY TREE, OR SNIPPETS HERE] Target Language / Framework: [e.g., TypeScript, Go, React, Spring Boot] ──────────────────────────────────────── PHASE 1 — DISCOVERY (scan everything) ──────────────────────────────────────── Hunt for the following waste categories across the provided codebase: A) UNREACHABLE DECLARATIONS • Functions / methods never invoked (including indirect calls, callbacks, event handlers) • Variables & constants written but never read after assignment • Types, classes, structs, enums, interfaces defined but never instantiated or extended • Entire source files excluded from compilation or never imported B) DEAD CONTROL FLOW • Branches that can never be reached (e.g. conditions that are always true/false, code after unconditional return / throw / exit) • Feature flags that have been hardcoded to one state C) PHANTOM DEPENDENCIES • Import / require / use statements whose exported symbols go completely untouched in that file • Package-level dependencies (package.json, go.mod, Cargo.toml, etc.) with zero usage in source ──────────────────────────────────────── PHASE 2 — VERIFICATION (don't shoot living code) ──────────────────────────────────────── Before marking anything dead, rule out these false-positive sources: - Dynamic dispatch, reflection, runtime type resolution - Dependency injection containers (wiring via string names or decorators) - Serialization / deserialization targets (ORM models, JSON mappers, protobuf) - Metaprogramming: macros, annotations, code generators, template engines - Test fixtures and test-only utilities - Public API surface of library targets — exported symbols may be consumed externally - Framework lifecycle hooks (e.g. beforeEach, onMount, middleware chains) - Configuration-driven behavior (symbol names in config files, env vars, feature registries) If any exemptions apply, lower the confidence rating accordingly and state the explicit reason in your report. ──────────────────────────────────────── PHASE 3 — TRIAGE (prioritize the cleanup) ──────────────────────────────────────── Assign each finding a Risk Level: 🔴 HIGH — safe to delete immediately; zero external callers, no framework magic 🟡 MEDIUM — likely dead but indirect usage is possible; verify before deleting 🟢 LOW — probably used via reflection / config / public API; flag for human review ──────────────────────────────────────── PHASE 4 — SELF-REVIEW & VALIDATION ──────────────────────────────────────── Before generating output, execute a final sanity check: - Verify that no public library export marked HIGH risk is accessible via external API. - Ensure line numbers and file paths accurately reflect the provided input. - If codebase context is partial/incomplete, explicitly flag uncertain findings as "INCOMPLETE_CONTEXT_WARNING". ──────────────────────────────────────── OUTPUT FORMAT ──────────────────────────────────────── Produce three sections: ### 1. Findings Table | # | File | Line(s) | Symbol | Category | Risk | Confidence | Action | Reason / Exemption Notes | |---|------|---------|--------|----------|------|------------|--------|--------------------------| Categories: UNREACHABLE_DECL / DEAD_FLOW / PHANTOM_DEP Actions : DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT ### 2. Cleanup Roadmap Group findings into three sequential batches based on Risk Level (HIGH -> MEDIUM -> LOW). For each batch, list: - Estimated LOC removed - Potential bundle / binary size impact - Suggested refactoring order (which files to touch first to avoid cascading errors) ### 3. Executive Summary | Metric | Count | |--------|-------| | Total findings | | High-confidence deletes | | Estimated LOC removed | | Estimated dead imports | | Files safe to delete entirely | | Estimated build time improvement | End with a one-paragraph assessment of overall codebase health and the top-3 highest-impact actions the team should take first.