성능 회귀를 계측하고 병목을 찾는 CLI 프롬프트

언제 사용하나

기능은 정상이지만 응답 시간, throughput, CPU, memory, query 수가 악화됐을 때 추측 대신 측정으로 병목을 찾기 위해 사용한다.

준비할 정보

• {{REGRESSION}}: 악화된 지표와 기준값
• {{WORKLOAD}}: 재현 가능한 요청·데이터·실행 명령
• {{GOOD_REF}} / {{BAD_REF}}: 정상과 회귀 버전
• {{TOOLS}}: 사용 가능한 benchmark·profiler·APM

복사해서 쓰는 CLI agent 프롬프트

{{REGRESSION}}을 재현하고 병목을 계층적으로 조사해줘.
workload: {{WORKLOAD}}
정상/회귀 기준: {{GOOD_REF}} / {{BAD_REF}}
가능한 도구: {{TOOLS}}

1. 현재 작업트리와 실행 환경을 확인하고, 입력·warm-up·반복 횟수·병렬성을 고정한 benchmark를 먼저 작성해.
2. 수정 전 baseline의 중앙값과 p95/p99, CPU, memory, I/O, network, DB query 수를 기록해.
3. application -> runtime/GC -> DB -> network -> disk 순으로 계층을 나누고 가설별 profiler·trace 방법을 선택해.
4. profiler overhead가 결과를 왜곡할 수 있으므로 계측 유무를 비교해.
5. {{GOOD_REF}}..{{BAD_REF}} 변경을 지표 악화와 연결하되 상관관계만으로 원인을 확정하지 마.
6. 한 번에 하나의 변수만 바꿔 재측정하고 결과와 명령을 보존해.
7. 수정은 기준 버전과 같은 workload로 비교하고 기능 회귀 테스트도 실행해.

결과: 'benchmark 조건 / baseline / 계층별 증거 / 핵심 병목 / 변경 전후 표 / 재현 명령 / 남은 불확실성'

승인이 필요한 작업

운영의 load test, 트래픽 증가, profiler 부착, DB EXPLAIN ANALYZE, cache 초기화는 성능과 비용에 영향을 줄 수 있으므로 먼저 영향과 중단 방법을 보고한다.

검수 방법

최소 5회 이상 반복해 분포를 비교하고, 지표 개선과 사용자 체감 경로가 연결되는지 확인한다. 단일 실행의 빠른 결과만으로 성공을 판정하지 않는다.

실패 판정과 복구

비교 환경의 CPU quota, 데이터 크기, cache 상태가 다르면 결과를 회귀 근거로 사용하지 않는다. 수정 후 기능 테스트가 실패하거나 중앙값은 좋아졌지만 p99가 악화되면 변경을 성공으로 판정하지 않는다. 변경 commit을 되돌린 후 같은 benchmark로 baseline이 복구되는지 확인한다.