서버 갑자기 CPU 폭주할 때, 로그 어디부터 봐야 할까요?

---

요즘 저희 서비스가 갑자기 트래픽이 몰렸는지, 아니면 뭔가 이상한 게 터진 건지 모르겠어요.
개발팀에서 갑자기 CPU 점유율이 쭉 치솟는 현상을 발견해서요.
로그를 뒤져보긴 했는데, 너무 방대하고 어디부터 손대야 할지 감이 안 와요.
이런 상황일 때, 제일 먼저 체크해봐야 할 로그 파일이나 지표가 있을까요?
혹시 '이거부터 봐야 해!' 하는 치트키 같은 게 있을지 궁금해서요 ㅎㅎ

와, CPU 폭주 현상 겪으셨군요.
정말 당황스러울 때죠.
저도 몇 번 겪어봐서 공감합니다.
로그가 너무 방대하면 뭘 봐야 할지 막막할 때가 제일 힘들더라고요.
'치트키' 같은 게 있으면 좋겠지만, 사실 상황에 따라 봐야 할 게 조금 다르긴 합니다.
근데 제가 여러 번 겪어본 경험을 바탕으로, '이런 상황일 때, 보통 이 순서로 체크한다'는 가이드라인을 좀 정리해 드릴게요.
혹시 지금 바로 상황 파악이 필요하신 거니까, 이론만 나열하기보다는 실질적인 체크리스트 위주로 말씀드릴게요.
일단, CPU 폭주 원인을 잡는 건 '증상(CPU 폭주)'을 보는 것부터 시작해서 '원인(무엇이 이 폭주를 일으켰는지)'을 좁혀나가는 과정이 중요해요.
그러니까 로그만 보기 전에, '어떤 레벨의 지표'부터 볼지부터 정하는 게 좋습니다.
--- ### 1단계: '지금' 무슨 일이 일어나고 있는지 파악하기 (모니터링/지표 중심) 로그를 뒤지기 전에, '무엇이' 자원을 많이 쓰는지 1차적으로 파악하는 게 제일 빠르고 정확합니다.
이건 로그라기보다는 시스템 모니터링 지표를 보는 단계예요.
1.
Top/Htop 같은 프로세스 뷰어 확인 (가장 먼저!) * 뭘 봐야 하나요? CPU를 가장 많이 점유하고 있는 프로세스 ID (PID)와 프로세스 이름이 가장 중요합니다.

• 팁: 만약 여러 프로세스가 돌아가고 있다면, 폭주 시점에 가장 높은 %를 찍는 녀석이 범인일 확률이 90% 이상이에요.
• 주의할 점: 가끔 웹 서버 프로세스(예: Nginx/Apache 워커 프로세스)가 여러 개 돌아가는데, 그중 특정 몇 개만 폭주하는 경우도 있습니다.
  이 경우, '어떤 종류의 요청을 처리하는 프로세스'가 문제인지 파악하는 게 다음 단계예요.
  2.
  네트워크 I/O 확인 (네트워크 문제일 경우) * 혹시: CPU가 폭주했는데, netstat이나 ss 같은 걸로 봤을 때 외부 통신(Outbound/Inbound) 자체가 비정상적으로 폭증하는지 확인해 보세요.
• 의미: 만약 요청 자체가 아니라, 데이터를 주고받는 트래픽 자체가 갑자기 늘어난 거라면, 단순히 CPU 부하가 아니라 네트워크 대역폭 문제나 DDoS 같은 공격일 수도 있거든요.
• 체크 포인트: 특정 IP 대역이나 특정 포트로 트래픽이 몰리는지 확인하는 게 좋아요.
  3.
  메모리 상태 확인 (Memory Leak 가능성) * CPU 폭주와 메모리 누수는 종종 같이 오거나, 메모리 부족(OOM)으로 인해 시스템이 스왑(Swap)을 많이 쓰면서 CPU를 비정상적으로 점유할 수도 있어요.
• free -h 같은 걸로 메모리 사용량을 확인하고, Swap 사용량이 갑자기 늘어난 게 없는지 꼭 확인해 보세요.
• 만약 메모리 관련 문제가 있다면, 애플리케이션 레벨의 메모리 누수(Memory Leak)일 가능성이 높습니다.
  --- ### 2단계: '무엇'을 처리하느라 폭주했는지 추적하기 (로그 분석 중심) 1단계에서 특정 프로세스(예: java, python, php-fpm 등)가 범인으로 지목되었다면, 이제 그 프로세스가 '무슨 요청을 처리하다가' 폭주했는지 로그를 역추적해야 합니다.
  여기서 말씀드린 로그들은 서비스 구조에 따라 다르겠지만, 일반적으로 다음 순서로 체크하는 게 효율적입니다.
  1.
  웹 서버 로그 (Nginx/Apache Access Log) * 목적: '어떤 요청이 들어왔는가?'를 파악합니다.
• 찾아야 할 것: * 폭주 시점의 트래픽 패턴: 갑자기 특정 URL로만 요청이 몰렸나요?
  (예: /api/v1/search 같은 특정 API) * 요청 속도 (Request Rate): 요청 자체가 평소 대비 비정상적으로 많은지 확인합니다.
• HTTP 상태 코드: 5xx 에러가 폭주 시점부터 증가했는지 확인해 보세요.
  500 에러가 많다는 건 백엔드에서 처리하다가 에러를 내고 자원을 낭비하고 있다는 뜻일 수 있습니다.
  2.
  애플리케이션 로그 (백엔드 로직 로그) * 목적: 웹 서버를 통과한 요청이 실제로 어떤 로직을 거치다가 느려지거나 멈췄는지 확인합니다.
• 어디를 봐야 할까요? * 에러 로그 (Error Log): 가장 먼저 봐야 합니다.
  스택 트레이스(Stack Trace)가 찍혀있다면, 어떤 함수 호출에서 예외가 발생했는지를 통해 문제의 원인 코드를 좁힐 수 있습니다.
• 워닝 로그 (Warning Log): 에러는 아니지만, 특정 조건에서 반복적으로 경고가 뜨는 부분이 있다면, 그게 반복 호출되면서 자원을 소모하고 있을 수 있습니다.
• 로그 레벨 조정의 중요성: 만약 DEBUG 레벨로 로그를 찍어 놓는 습관이 있다면, 이게 제일 큰 함정일 수 있습니다. 디버깅 목적으로 남긴 로그가 실시간으로 엄청나게 많이 쌓이면서 I/O 부하와 CPU 부하를 동시에 일으킬 수 있거든요.
  폭주 상황에서는 로그 레벨을 일시적으로 INFO나 WARN으로 올려서 분석하는 것도 방법입니다.
  3.
  데이터베이스 로그 (DB Slow Query Log) * 만약 백엔드에서 DB를 많이 호출한다면, DB가 원인일 확률이 매우 높습니다. * 무엇을 봐야 하나요? * Slow Query Log: 이 로그는 **'너무 오래 걸려서 실행된 쿼리'**를 기록해 줍니다.
  이게 제일 강력한 힌트예요.
• 분석 방법: 폭주 시점의 Slow Query를 가져와서, 그 쿼리가 인덱스(Index)를 제대로 쓰고 있는지, 아니면 **전체 테이블 스캔(Full Table Scan)**을 하고 있는지를 확인해야 합니다.
  전체 테이블 스캔은 데이터가 많아질수록 성능 저하의 주범입니다.
  --- ### 실전 가이드: 단계별 사고 흐름 정리 (요약 및 최종 점검) 제가 만약 현장에 투입된다면, 이 순서로 생각하고 로그를 훑어볼 겁니다.
  Step 1: (지표) CPU 점유율이 가장 높은 프로세스 확인 $\rightarrow$ (가설 설정) > 예: java 프로세스가 99% 점유 중이다. Step 2: (로그) 웹 서버 로그 확인 $\rightarrow$ (요청 패턴 분석) > 예: java가 처리하는 요청 중, /api/v1/report 엔드포인트로만 요청이 폭증하고 있다. Step 3: (로그) 애플리케이션 로그 확인 $\rightarrow$ (코드 문제 추적) > 예: 해당 엔드포인트의 로그를 보니, 특정 로직에서 외부 API를 호출하고 있는데, 이 API가 타임아웃 되기 직전에 반복적으로 재시도(Retry) 로직을 돌리는 패턴이 보인다. Step 4: (로그/지표) DB 쿼리 확인 $\rightarrow$ (근본 원인 파악) > 예: 재시도 로직이 결국 DB의 복잡한 리포팅 쿼리를 계속 재실행하게 만들고, 이 쿼리가 인덱스 없이 테이블 전체를 읽어버린다. 결론: 이 경우, CPU 폭주의 원인은 '특정 API 요청 증가' $\rightarrow$ '취약한 비즈니스 로직(무한 재시도 등)' $\rightarrow$ **'최적화되지 않은 DB 쿼리'**의 조합입니다.
  --- ### ️ 초보자가 흔히 하는 실수 및 주의점 1.
  로그만 보고 '원인'을 단정하는 실수: 로그는 '무슨 일이 일어났는지'를 기록한 증거물일 뿐입니다.
  로그에 특정 에러가 찍혔다고 해서, 그 에러가 CPU 폭주의 직접적인 원인이라고 단정하기는 어렵습니다.
  때로는 에러 처리를 하느라 자원이 낭비되는 것일 수도 있고, 아니면 에러가 난 것과는 무관하게 트래픽 자체가 너무 많아서 부하가 걸리는 경우도 많아요.
  항상 '지표(CPU, Memory) $\rightarrow$ 로그(패턴) $\rightarrow$ 코드(로직)' 순서로 거슬러 올라가면서 확인하는 습관을 들이는 게 중요합니다.
  2.
  로드 밸런서(L4/L7)의 로그를 무시하는 실수: 만약 서비스 앞에 로드 밸런서가 있다면, 로드 밸런서 레벨에서 이미 트래픽이 왜 몰렸는지(어떤 헬스 체크가 실패했는지, 아니면 특정 세션으로만 트래픽이 쏠리는지)에 대한 로그가 남아있을 수 있습니다.
  애플리케이션 로그만 보면 전체 그림을 놓칠 수 있어요.
  3.
  너무 많은 로그를 한 번에 보는 실수 (가장 흔함): 로그 뷰어에서 날짜/시간 필터를 잘 사용하세요.
  폭주가 시작된 **특정 시간대(예: 14:30:00 ~ 14:35:00 사이)**로 범위를 극도로 좁히는 것이 생명입니다.
  시간 순서대로 처음부터 끝까지 다 보는 건 불가능에 가깝습니다.
  이거 너무 길게 설명드렸는데, 핵심은 '모니터링 지표(Top/Htop)로 범인 프로세스 잡기' $\rightarrow$ '웹 로그로 요청 패턴 잡기' $\rightarrow$ '에러/DB 로그로 근본 원인 찾기' 이 세 단계의 흐름을 꼭 기억해 주시면, 다음 폭주 때는 훨씬 체계적으로 대처하실 수 있을 거예요.
  일단 위 체크리스트대로 점검해보시고, 만약 특정 로그 파일이나 지표를 보시고 '이거 봐도 이상한가요?' 싶은 부분이 생기면 다시 질문 주세요.
  제가 아는 선에서 최대한 같이 고민해 보겠습니다.
  화이팅입니다!