주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 2장 느려진 서비스, 어디부터 봐야 할까

서비스가 느려졌을 때 가장 흔한 실수는 “일단 코드 최적화부터 시작하는 것”이다.
실무에서는 먼저 병목이 어느 계층에 있는지부터 구분해야 한다.

기본 분류

성능 문제는 대체로 네 군데에서 시작한다.

1. 애플리케이션 CPU 사용량 증가
2. DB 지연
3. 외부 시스템 응답 지연
4. 네트워크 또는 인프라 계층 문제

같은 “응답 지연”이어도 원인은 완전히 다를 수 있다.

어디부터 봐야 하는가

책에서 중요한 포인트는 “증상 → 계층 → 지표” 순서다.

예를 들어:

• 응답 시간이 늘어남
• 에러율은 그대로
• DB connection 수가 급증

이 조합이면 애플리케이션 코드보다 느린 쿼리 혹은 락 대기를 먼저 의심하는 게 맞다.

반대로:

• 응답 시간이 늘어남
• CPU 사용률 급증
• GC 시간 증가

이 조합이면 JVM이나 애플리케이션 레벨 병목일 가능성이 높다.

성능 문제를 볼 때 확인할 것

1. 요청량 변화

• QPS가 갑자기 늘었는가
• 특정 API만 몰리는가
• 배치/이벤트 소비가 겹쳤는가

2. 자원 사용량

• CPU
• Memory
• GC
• Thread 수
• DB connection pool

3. 의존성 계층

• DB 응답 시간
• 캐시 hit ratio
• 외부 API latency
• 메시지 큐 적체 여부

4. 시스템 레벨

• 디스크 I/O
• 네트워크 대역폭
• 컨테이너 throttling
• 노드 리소스 압박

실무에서 중요한 기준

성능 분석은 “어디가 가장 느린가”보다 어디서 대기가 발생하는가를 보는 일에 가깝다.

• CPU bound인가
• I/O bound인가
• lock bound인가
• remote call bound인가

이 구분이 먼저 돼야 해결 방법도 정해진다.

주니어가 가져가야 할 체크리스트

• 문제를 코드 한 줄 수준으로 바로 내려가지 말 것
• 메트릭과 로그를 함께 볼 것
• 평균값보다 p95, p99 지연을 볼 것
• 장애 당시 배포/트래픽/배치 이벤트를 함께 볼 것
• 병목 지점을 하나씩 제거하며 재현 가능하게 분석할 것

정리

느려진 서비스는 무조건 “코드 최적화 문제”가 아니다.
애플리케이션, DB, 외부 연동, 인프라 중 어디가 병목인지 먼저 구분해야 한다.

실무에서 좋은 개발자는 문제를 빨리 푸는 사람보다,
문제를 잘 분류해서 잘못된 곳을 먼저 파지 않는 사람에 가깝다.