문제 발견 → 원인 좁히기 → 기술 선택 근거 → 결과 수치로 닫는 결
팀 프로젝트에서 특정 API 응답이 간헐적으로 5초 이상 지연되는 문제가 발생했는데, 재현 조건을 잡기가 어려웠습니다. 로컬에서는 정상이고 배포 환경에서만 나타났습니다.
저는 먼저 재현 조건을 좁히기 위해 요청 패턴과 서버 리소스 로그를 시간대별로 대조했습니다. 분석 결과 동시 요청이 10건 이상 몰릴 때만 지연이 발생하고, DB 커넥션 대기 시간이 급증하는 것을 확인했습니다. 커넥션 풀 설정이 기본값으로 고정돼 있었던 게 원인이었습니다.
해결책으로 HikariCP 풀 사이즈를 트래픽 패턴에 맞게 조정하고, 자주 조회되는 데이터에 Redis 캐싱을 추가했습니다. 캐싱 대상은 변경 빈도가 낮고 조회가 잦은 마스터 데이터로 한정했고, TTL은 10분으로 설정했습니다.
배포 후 동시 20건 부하 테스트에서 평균 응답 시간이 4.8초 → 0.6초로 줄었습니다. 이 경험에서 간헐적 버그는 재현 조건을 먼저 데이터로 좁혀야 원인이 보인다는 것을 배웠습니다. 지금도 성능 이슈가 생기면 직관보다 로그와 메트릭부터 보는 편입니다.