평균 응답시간만 보고 최적화를 끝내지 않기

평균은 모든 요청을 하나의 숫자로 압축합니다. 대부분이 빠르고 일부가 아주 느린 서비스에서는 그 일부의 경험이 평균 뒤에 숨어 버립니다.

1. 평균과 p95를 함께 읽기

p95는 요청의 약 95%가 그 값 이하에서 끝났다는 뜻입니다. 가장 느린 요청도, “평균보다 95% 빠르다”는 뜻도 아닙니다. 표본 수가 작으면 p95 자체가 불안정합니다.

NEMO의 작성자 제공 결과는 평균 98.91ms → 10.91ms, p95 114.20ms → 15.19ms입니다. 두 지표가 함께 개선되었지만, 이 숫자만으로 최대 부하나 사용자 수를 추정할 수는 없습니다.

2. 비교 전에 고정할 조건

측정 대상의 코드 변경 외에 조건이 달라지면 무엇이 효과를 냈는지 모르게 됩니다. 최소한 아래 정보를 함께 남깁니다.

항목	기록할 내용
실행 환경	JVM·DB 버전, CPU·메모리, 네트워크
데이터	행 수, 관계 분포, 조회 조건
부하	동시 요청 수, 요청 패턴, 지속 시간
준비	워밍업, 캐시, 커넥션 풀 상태
결과	표본 수, 평균, p95, 오류율, SQL 수
근거	테스트 코드 커밋, 실행 명령, 원본 보고서

3. 쿼리 수와 응답시간을 연결하기

N+1 조회를 줄이면 DB 왕복 비용이 줄 수 있습니다. 그러나 큰 조인이 만들어 낸 행 수가 급증하면 메모리와 전송 비용이 늘 수 있습니다.

그래서 “SQL이 줄었다”와 “같은 부하에서 더 빨라졌다”를 각각 확인해야 합니다. 실험에서는 한 번에 한 요인을 바꾸고, 원래 조건으로 되돌려도 차이가 유지되는지 확인합니다.

4. 다음 실험이 가능한 기록

이 사이트의 측정 데이터에는 환경, 방법, 날짜, 출처 URL을 추가할 수 있습니다. 지금 비어 있는 칸을 채우는 것이 새로운 멋진 숫자를 추가하는 것보다 먼저입니다.

운영 관측 지표를 연결할 때는 원본 모니터링 서버를 공개하지 않고, 인증된 서버 측 경로에서 필요한 집계만 가져오도록 확장할 수 있습니다. 현재 버전에는 운영 데이터 연결이나 가짜 실시간 지표가 없습니다.