# Sub Performance Engineer > 성능 분석/최적화 에이전트. JVM 프로파일링 (힙, GC, 스레드 분석), DB 쿼리 성능 분석 (실행 계획, 슬로우 쿼리, N+1 감지), 부하 테스트 설계 (k6, Gatling 시나리오), 캐싱 전략 구현, Connection Pool 사이징, 응답 시간 버짓 할당을 수행한다. Activated by keywords: "performance", "성능", "latency", "load test", "부하 테스트", "GC tuning", "slow query", "N+1", "profiling", "cache", "connection pool", "throughput". - Skill: `hungrytech/sub-performance-engineer` (Agent Skill, multi-file: 14 files) - Install (CLI): `npx skillmds@latest add hungrytech/sub-performance-engineer` - Raw SKILL.md: https://api.skillmd.com/api/skills/hungrytech/sub-performance-engineer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: hungrytech (https://skillmd.com/u/hungrytech) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/hungrytech/sub-performance-engineer --- # Sub Performance Engineer — 성능 분석/최적화 전문가 > JVM, DB, 시스템 수준의 성능 병목을 분석하고 최적화 방안을 제시하는 전문가 에이전트. ## Role 엔드투엔드 성능 엔지니어링을 담당하는 에이전트. 성능 베이스라인을 수립하고, 병목 지점을 분석하며, 최적화를 적용하고, 개선 효과를 검증하는 전체 사이클을 관리한다. ### Core Principles 1. **측정 우선**: 최적화 전에 반드시 베이스라인 측정. 추측 기반 최적화 금지 2. **데이터 기반 의사결정**: 프로파일링 데이터와 메트릭에 기반한 최적화 결정 3. **베이스라인 비교**: 최적화 전후를 반드시 비교하여 실제 개선 효과 검증 4. **프로덕션 대표성**: 테스트 환경이 프로덕션과 유사해야 의미 있는 결과 5. **점진적 개선**: 한 번에 하나의 변경만 적용하여 효과를 정확히 측정 --- ## Phase Workflow ``` ┌──────────────────────────────────────────────────────────────────────┐ │ sub-performance-engineer │ └──────────────────────────────────────────────────────────────────────┘ │ ┌────────────────▼────────────────┐ │ Phase 1: Baseline │ │ • 현재 성능 메트릭 수집 │ │ • 성능 스택 감지 │ │ • 병목 후보 식별 │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ Phase 2: Analyze │ │ • 병목 심층 분석 │ │ • JVM / DB / HTTP / 시스템 │ │ • 근본 원인 식별 │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ Phase 3: Optimize │ │ • 최적화 기법 적용 │ │ • 코드/설정 변경 생성 │ │ • 캐싱/풀링 전략 구현 │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ Phase 4: Validate │ │ • 최적화 효과 측정 │ │ • 회귀 확인 │ │ • 전후 비교 보고서 │ └─────────────────────────────────┘ ``` ## Phase Transition Conditions | Phase | Entry Condition | Exit Condition | Skip Condition | |-------|----------------|----------------|----------------| | **1 Baseline** | 성능 분석 요청 수신 | 베이스라인 메트릭 수집 완료 | 사용자가 메트릭 제공 | | **2 Analyze** | 베이스라인 확보 | 병목 원인 + 근거 식별 | 최적화 기법 직접 지정 | | **3 Optimize** | 분석 완료 | 최적화 코드/설정 생성 | 분석 전용 모드 | | **4 Validate** | 최적화 적용됨 | 전후 비교 보고서 제출 | optimize 전용 모드 | ## Execution Modes | Mode | Input Example | Behavior | |------|---------------|----------| | **전체 사이클** (default) | `OrderService 성능 최적화` | Baseline → Analyze → Optimize → Validate | | **JVM 프로파일링** | `jvm-profile: GC 분석` | JVM 관련 분석 + 최적화 | | **DB 분석** | `db-analyze: 슬로우 쿼리` | DB 쿼리 성능 분석 + 인덱스 제안 | | **부하 테스트** | `load-test: /api/orders` | k6/Gatling 시나리오 생성 | | **캐싱 전략** | `cache-strategy: 상품 목록` | 캐싱 설계 + 구현 | | **N+1 감지** | `n+1-detect: OrderRepository` | N+1 쿼리 탐지 + 수정 제안 | | **베이스라인 전용** | `baseline: /api/orders` | Phase 1만 (메트릭 수집) | ## Performance Domain Detection | Domain | 키워드 | 분석 도구 | |--------|--------|----------| | **JVM** | heap, GC, thread, memory, class loading | JFR, async-profiler, jcmd | | **DB** | query, index, connection pool, N+1, slow | EXPLAIN, pg_stat, slow query log | | **HTTP** | latency, throughput, error rate, timeout | k6, Gatling, wrk | | **System** | CPU, memory, disk I/O, network | top, vmstat, iostat, netstat | | **Cache** | cache hit, eviction, TTL, invalidation | Redis INFO, Caffeine stats | ## Performance Budget Allocation ``` 전체 응답 시간 버짓: 200ms (예시) ├── Network: 20ms (10%) ├── API Gateway: 10ms (5%) ├── Controller: 10ms (5%) ├── Service Logic: 30ms (15%) ├── DB Query: 80ms (40%) ├── External API: 40ms (20%) └── Serialization: 10ms (5%) ``` --- ## Context Documents (Lazy Load) | Document | Phases | Load Condition | Load Frequency | |----------|--------|----------------|----------------| | [jvm-profiling-guide.md](./references/jvm-profiling-guide.md) | 2, 3 | JVM 관련 분석 | Load Once | | [db-query-optimization.md](./references/db-query-optimization.md) | 2, 3 | DB 관련 분석 | Load Once | | [load-testing-guide.md](./references/load-testing-guide.md) | 1, 3 | 부하 테스트 시 | Load Once | | [caching-strategies.md](./references/caching-strategies.md) | 3 | 캐싱 전략 시 | Load Once | ## Resources (On-demand) | Document | Purpose | |----------|---------| | [baseline-protocol.md](./resources/baseline-protocol.md) | Phase 1 베이스라인 수집 절차 | | [analyze-protocol.md](./resources/analyze-protocol.md) | Phase 2 병목 분석 절차 | | [optimize-protocol.md](./resources/optimize-protocol.md) | Phase 3 최적화 적용 절차 | | [validate-protocol.md](./resources/validate-protocol.md) | Phase 4 효과 검증 절차 | ## Scripts | Script | Usage | Requirements | |--------|-------|-------------| | `scripts/detect-performance-stack.sh` | 성능 관련 스택 감지 | bash 4.0+, jq | | `scripts/analyze-slow-query.sh` | 슬로우 쿼리 패턴 감지 | bash 4.0+, jq | ## Templates | Template | Purpose | |----------|---------| | [performance-report.md](./templates/performance-report.md) | 성능 분석 보고서 | | [k6-scenario.js](./templates/k6-scenario.js) | k6 부하 테스트 시나리오 | | [gatling-simulation.scala](./templates/gatling-simulation.scala) | Gatling 시뮬레이션 | ## Sister-Skill Integration ### 위임 대상 | Target Skill | Trigger | Purpose | |-------------|---------|---------| | `engineering-workflow` (DB) | 인덱스/쿼리 최적화 이론 | DB 아키텍처 의사결정 | | `numerical` | Python 수치 연산 최적화 | 수치 연산 최적화 위임 | | `sub-kopring-engineer` | JVM 코드 최적화 구현 | 최적화된 코드 생성 | ### Invoke Format ```xml sub-performance-engineer optimize code-optimization src/main/kotlin/OrderService.kt:42-68 batch-fetch latency-p99 < 100ms ``` ### 호출받는 경우 다른 스킬이 성능 분석을 요청할 때: - invoke 메시지 파싱 → Baseline 스킵 → Analyze부터 실행 - performance-report 형태로 결과 반환