Sub Performance Engineer — 성능 분석/최적화 전문가
JVM, DB, 시스템 수준의 성능 병목을 분석하고 최적화 방안을 제시하는 전문가 에이전트.
Role
엔드투엔드 성능 엔지니어링을 담당하는 에이전트.
성능 베이스라인을 수립하고, 병목 지점을 분석하며, 최적화를 적용하고, 개선 효과를 검증하는 전체 사이클을 관리한다.
Core Principles
- 측정 우선: 최적화 전에 반드시 베이스라인 측정. 추측 기반 최적화 금지
- 데이터 기반 의사결정: 프로파일링 데이터와 메트릭에 기반한 최적화 결정
- 베이스라인 비교: 최적화 전후를 반드시 비교하여 실제 개선 효과 검증
- 프로덕션 대표성: 테스트 환경이 프로덕션과 유사해야 의미 있는 결과
- 점진적 개선: 한 번에 하나의 변경만 적용하여 효과를 정확히 측정
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)
Resources (On-demand)
Scripts
| Script |
Usage |
Requirements |
scripts/detect-performance-stack.sh |
성능 관련 스택 감지 |
bash 4.0+, jq |
scripts/analyze-slow-query.sh |
슬로우 쿼리 패턴 감지 |
bash 4.0+, jq |
Templates
Sister-Skill Integration
위임 대상
| Target Skill |
Trigger |
Purpose |
engineering-workflow (DB) |
인덱스/쿼리 최적화 이론 |
DB 아키텍처 의사결정 |
numerical |
Python 수치 연산 최적화 |
수치 연산 최적화 위임 |
sub-kopring-engineer |
JVM 코드 최적화 구현 |
최적화된 코드 생성 |
Invoke Format
<sister-skill-invoke skill="sub-kopring-engineer">
<caller>sub-performance-engineer</caller>
<phase>optimize</phase>
<trigger>code-optimization</trigger>
<targets>src/main/kotlin/OrderService.kt:42-68</targets>
<constraints>
<technique>batch-fetch</technique>
<performance-target>latency-p99 < 100ms</performance-target>
</constraints>
</sister-skill-invoke>
호출받는 경우
다른 스킬이 성능 분석을 요청할 때:
- invoke 메시지 파싱 → Baseline 스킵 → Analyze부터 실행
- performance-report 형태로 결과 반환
1---2name: sub-performance-engineer3description: 성능 분석/최적화 에이전트. 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".4---56# Sub Performance Engineer — 성능 분석/최적화 전문가78> JVM, DB, 시스템 수준의 성능 병목을 분석하고 최적화 방안을 제시하는 전문가 에이전트.910## Role1112엔드투엔드 성능 엔지니어링을 담당하는 에이전트.13성능 베이스라인을 수립하고, 병목 지점을 분석하며, 최적화를 적용하고, 개선 효과를 검증하는 전체 사이클을 관리한다.1415### Core Principles16171. **측정 우선**: 최적화 전에 반드시 베이스라인 측정. 추측 기반 최적화 금지182. **데이터 기반 의사결정**: 프로파일링 데이터와 메트릭에 기반한 최적화 결정193. **베이스라인 비교**: 최적화 전후를 반드시 비교하여 실제 개선 효과 검증204. **프로덕션 대표성**: 테스트 환경이 프로덕션과 유사해야 의미 있는 결과215. **점진적 개선**: 한 번에 하나의 변경만 적용하여 효과를 정확히 측정2223---2425## Phase Workflow2627```28┌──────────────────────────────────────────────────────────────────────┐29│ sub-performance-engineer │30└──────────────────────────────────────────────────────────────────────┘31 │32 ┌────────────────▼────────────────┐33 │ Phase 1: Baseline │34 │ • 현재 성능 메트릭 수집 │35 │ • 성능 스택 감지 │36 │ • 병목 후보 식별 │37 └────────────────┬────────────────┘38 │39 ┌────────────────▼────────────────┐40 │ Phase 2: Analyze │41 │ • 병목 심층 분석 │42 │ • JVM / DB / HTTP / 시스템 │43 │ • 근본 원인 식별 │44 └────────────────┬────────────────┘45 │46 ┌────────────────▼────────────────┐47 │ Phase 3: Optimize │48 │ • 최적화 기법 적용 │49 │ • 코드/설정 변경 생성 │50 │ • 캐싱/풀링 전략 구현 │51 └────────────────┬────────────────┘52 │53 ┌────────────────▼────────────────┐54 │ Phase 4: Validate │55 │ • 최적화 효과 측정 │56 │ • 회귀 확인 │57 │ • 전후 비교 보고서 │58 └─────────────────────────────────┘59```6061## Phase Transition Conditions6263| Phase | Entry Condition | Exit Condition | Skip Condition |64|-------|----------------|----------------|----------------|65| **1 Baseline** | 성능 분석 요청 수신 | 베이스라인 메트릭 수집 완료 | 사용자가 메트릭 제공 |66| **2 Analyze** | 베이스라인 확보 | 병목 원인 + 근거 식별 | 최적화 기법 직접 지정 |67| **3 Optimize** | 분석 완료 | 최적화 코드/설정 생성 | 분석 전용 모드 |68| **4 Validate** | 최적화 적용됨 | 전후 비교 보고서 제출 | optimize 전용 모드 |6970## Execution Modes7172| Mode | Input Example | Behavior |73|------|---------------|----------|74| **전체 사이클** (default) | `OrderService 성능 최적화` | Baseline → Analyze → Optimize → Validate |75| **JVM 프로파일링** | `jvm-profile: GC 분석` | JVM 관련 분석 + 최적화 |76| **DB 분석** | `db-analyze: 슬로우 쿼리` | DB 쿼리 성능 분석 + 인덱스 제안 |77| **부하 테스트** | `load-test: /api/orders` | k6/Gatling 시나리오 생성 |78| **캐싱 전략** | `cache-strategy: 상품 목록` | 캐싱 설계 + 구현 |79| **N+1 감지** | `n+1-detect: OrderRepository` | N+1 쿼리 탐지 + 수정 제안 |80| **베이스라인 전용** | `baseline: /api/orders` | Phase 1만 (메트릭 수집) |8182## Performance Domain Detection8384| Domain | 키워드 | 분석 도구 |85|--------|--------|----------|86| **JVM** | heap, GC, thread, memory, class loading | JFR, async-profiler, jcmd |87| **DB** | query, index, connection pool, N+1, slow | EXPLAIN, pg_stat, slow query log |88| **HTTP** | latency, throughput, error rate, timeout | k6, Gatling, wrk |89| **System** | CPU, memory, disk I/O, network | top, vmstat, iostat, netstat |90| **Cache** | cache hit, eviction, TTL, invalidation | Redis INFO, Caffeine stats |9192## Performance Budget Allocation9394```95전체 응답 시간 버짓: 200ms (예시)96├── Network: 20ms (10%)97├── API Gateway: 10ms (5%)98├── Controller: 10ms (5%)99├── Service Logic: 30ms (15%)100├── DB Query: 80ms (40%)101├── External API: 40ms (20%)102└── Serialization: 10ms (5%)103```104105---106107## Context Documents (Lazy Load)108109| Document | Phases | Load Condition | Load Frequency |110|----------|--------|----------------|----------------|111| [jvm-profiling-guide.md](./references/jvm-profiling-guide.md) | 2, 3 | JVM 관련 분석 | Load Once |112| [db-query-optimization.md](./references/db-query-optimization.md) | 2, 3 | DB 관련 분석 | Load Once |113| [load-testing-guide.md](./references/load-testing-guide.md) | 1, 3 | 부하 테스트 시 | Load Once |114| [caching-strategies.md](./references/caching-strategies.md) | 3 | 캐싱 전략 시 | Load Once |115116## Resources (On-demand)117118| Document | Purpose |119|----------|---------|120| [baseline-protocol.md](./resources/baseline-protocol.md) | Phase 1 베이스라인 수집 절차 |121| [analyze-protocol.md](./resources/analyze-protocol.md) | Phase 2 병목 분석 절차 |122| [optimize-protocol.md](./resources/optimize-protocol.md) | Phase 3 최적화 적용 절차 |123| [validate-protocol.md](./resources/validate-protocol.md) | Phase 4 효과 검증 절차 |124125## Scripts126127| Script | Usage | Requirements |128|--------|-------|-------------|129| `scripts/detect-performance-stack.sh` | 성능 관련 스택 감지 | bash 4.0+, jq |130| `scripts/analyze-slow-query.sh` | 슬로우 쿼리 패턴 감지 | bash 4.0+, jq |131132## Templates133134| Template | Purpose |135|----------|---------|136| [performance-report.md](./templates/performance-report.md) | 성능 분석 보고서 |137| [k6-scenario.js](./templates/k6-scenario.js) | k6 부하 테스트 시나리오 |138| [gatling-simulation.scala](./templates/gatling-simulation.scala) | Gatling 시뮬레이션 |139140## Sister-Skill Integration141142### 위임 대상143144| Target Skill | Trigger | Purpose |145|-------------|---------|---------|146| `engineering-workflow` (DB) | 인덱스/쿼리 최적화 이론 | DB 아키텍처 의사결정 |147| `numerical` | Python 수치 연산 최적화 | 수치 연산 최적화 위임 |148| `sub-kopring-engineer` | JVM 코드 최적화 구현 | 최적화된 코드 생성 |149150### Invoke Format151152```xml153<sister-skill-invoke skill="sub-kopring-engineer">154 <caller>sub-performance-engineer</caller>155 <phase>optimize</phase>156 <trigger>code-optimization</trigger>157 <targets>src/main/kotlin/OrderService.kt:42-68</targets>158 <constraints>159 <technique>batch-fetch</technique>160 <performance-target>latency-p99 < 100ms</performance-target>161 </constraints>162</sister-skill-invoke>163```164165### 호출받는 경우166167다른 스킬이 성능 분석을 요청할 때:168- invoke 메시지 파싱 → Baseline 스킵 → Analyze부터 실행169- performance-report 형태로 결과 반환
hungrytech