성능 모니터링 지표 기초: CPU, 메모리, 디스크, 네트워크 수치를 해석하는 방법

느린 화면을 만났을 때, 숫자를 어떻게 읽어야 하는가

페이지 로딩이 갑자기 늘어지고, 파일 저장이 지연되며, 원격 접속이 끊기는 날이 있다.

모니터링 화면에는 CPU, 메모리, 디스크, 네트워크 수치가 떠 있지만, 무엇이 원인인지 바로 연결되지 않는 경우가 많다.

성능 모니터링은 “수치가 높다/낮다”를 판단하는 일이 아니라, 병목이 생기는 경로를 좁혀 가는 작업이다.

• CPU와 메모리 수치가 의미하는 범위와 한계
• 디스크와 네트워크는 왜 “지연”으로 나타나는가
• 대표 지표를 비교해 첫 관찰 포인트 정하기
• YES/NO로 원인 후보를 좁히는 체크리스트
• 실제 느린 서비스 사례로 확인·해결 절차 따라가기

CPU와 메모리부터 읽되, “어느 수준의 수치인지”를 먼저 고정한다

CPU 지표: 사용률만 보면 놓치는 구간이 생긴다

정의: CPU 지표는 프로세서가 계산 작업, 커널 작업, 대기 상태를 얼마나 자주 겪는지 보여주는 수치다.

핵심 특징: 같은 80%라도 의미가 다르다. 전체 서버 기준인지, 특정 프로세스 기준인지, 순간치인지 평균치인지에 따라 해석이 갈린다.

• 범위: 시스템 전체 CPU 사용률과 프로세스별 CPU 사용률은 원인 추적 방향이 달라진다.
• 내부 동작 원리: CPU 시간은 대체로 사용자 영역(애플리케이션 계산)과 커널 영역(시스템 호출 처리)로 나뉘어 기록된다.
• 제약: 코어 수가 늘면 “100%”의 기준도 바뀐다. 8코어 장비에서 100%는 8개 코어가 동시에 가득 찬 상태를 뜻한다.
• 관측 창: 1초 순간치와 1분 평균치는 다른 사건을 말한다. 짧은 스파이크는 평균에서 사라질 수 있다.

주의점: CPU 사용률이 낮아도 느릴 수 있다. 애플리케이션이 디스크나 네트워크 응답을 기다리며 멈춰 있으면 CPU는 놀고 있는데 체감 속도는 떨어진다.

주의점: CPU 사용률이 높아도 반드시 과부하가 아니다. 배치 작업이나 인코딩처럼 CPU를 적극적으로 쓰는 작업이 의도된 것인지 구분해야 한다.

 

CPU·메모리·디스크·네트워크 병목이 체감 속도로 바뀌는 경로

 

메모리 지표: “남은 메모리”보다 “압박 신호”를 본다

정의: 메모리 지표는 프로세스가 사용하는 작업 공간과, 운영체제가 캐시/버퍼로 활용하는 영역, 스왑으로 밀어내는 상황을 보여준다.

핵심 특징: 단순히 “사용 중”으로 표시되는 메모리는 실제로는 캐시가 섞여 있을 수 있다. 캐시는 필요하면 회수될 수 있으나, 회수 속도보다 요구가 빠르면 지연이 생긴다.

• 내부 동작 원리: 운영체제는 디스크 I/O를 줄이기 위해 페이지 캐시를 활용한다. 자주 읽는 데이터를 메모리에 붙잡아 두는 방식이다.
• 범위: 시스템 메모리(전체)와 프로세스 메모리(RSS, Working Set 등)를 구분해야 한다. 특정 프로세스의 누수는 시스템 전체 수치만으로 숨겨질 수 있다.
• 제약: 메모리가 부족해지면 스왑 사용이 늘고, 스왑은 디스크를 건드리므로 지연이 급격히 증가한다.
• 정리 필요성: 로그, 캐시, 임시 파일이 늘면 간접적으로 메모리/디스크 압박이 커진다. 정리 정책이 없으면 수치가 서서히 나빠진다.

주의점: “여유 메모리 0”만 보고 장애로 결론 내리기 쉽다. 캐시가 많은 상태라면 즉시 문제가 아닐 수 있으나, 스왑 사용 증가와 함께 나타나면 위험 신호로 봐야 한다.

주의점: 가비지 컬렉션이 있는 런타임은 메모리를 넉넉히 잡았다가 한 번에 정리할 수 있다. 순간 메모리 급증이 정상 패턴인지 확인이 필요하다.

지표를 한 번에 보되, “무엇이 느린가”를 문장으로 바꿔서 비교한다

성능 문제는 보통 “응답 시간이 늘었다”로 시작한다. 응답 시간은 CPU 계산, 메모리 압박, 디스크 대기, 네트워크 지연이 합쳐진 결과다.

따라서 지표를 볼 때는 수치 자체보다, 그 수치가 어떤 종류의 지연을 만들 수 있는지로 연결하는 편이 빠르다.

자원	대표 지표	느려질 때 흔한 체감	주의할 오해
CPU	사용률, 사용자/커널 비중, 런큐(대기열)	전체가 무겁고 클릭마다 지연	사용률만 높다고 항상 문제는 아니다
메모리	사용량, 캐시, 스왑 사용, OOM 이벤트	간헐적 멈춤, 특정 시점에 급격히 느림	캐시를 “낭비”로 오해하기 쉽다
디스크	지연시간, IOPS, 처리량, 대기열, 사용률	저장/조회가 느리고, 전체가 끊기는 느낌	처리량만 보면 지연을 놓친다
네트워크	대역폭, 지연, 패킷 드롭, 재전송, 연결 수	외부 API 호출이 느림, 원격 접속 불안정	대역폭 여유가 있어도 지연은 발생한다

표 제목: CPU·메모리·디스크·네트워크 지표 한눈에 비교

어떤 상황이면 어디를 먼저 의심하는가: YES/NO 체크리스트

• 질문: 특정 기능만 느리고 다른 화면은 괜찮은가. YES: 해당 기능이 의존하는 DB/외부 API/파일 I/O부터 확인한다. NO: 시스템 전반 지표(CPU, 메모리 압박, 디스크 지연)를 넓게 본다.
• 질문: CPU 사용률이 높고, 동시에 응답이 전반적으로 무거운가. YES: 프로세스별 CPU 상위 작업과 스레드/쿼리 폭주를 의심한다. NO: 디스크/네트워크 대기나 락 경합 가능성을 본다.
• 질문: 스왑 사용이 증가하거나 메모리 회수로 멈춤이 느껴지는가. YES: 메모리 누수, 캐시 정책, 동시 처리량을 점검한다. NO: 메모리는 1차 원인에서 제외하고 다른 지표로 이동한다.
• 질문: 디스크 지연시간이 오르고 대기열이 길어지는가. YES: 로그 폭증, DB I/O, 백업/스캔 작업을 의심한다. NO: 디스크가 아니라 네트워크나 애플리케이션 로직으로 범위를 옮긴다.
• 질문: 네트워크 오류(재전송, 드롭, 연결 급증)가 관찰되는가. YES: 회선/장비/방화벽/외부 API 상태를 확인한다. NO: 애플리케이션 내부 병목 또는 DB 병목을 우선 본다.

실전 예시: “업무용 웹이 오후만 느려지는 문제”를 지표로 좁혀 가는 절차

문제: 오전에는 정상인데 오후 2시 이후 특정 웹 화면이 느려지고, 저장 버튼을 누르면 로딩이 길어지는 현상이 반복된다.

왜 발생: 사용자 증가로 동시 요청이 늘거나, 오후에만 실행되는 배치/백업이 CPU나 디스크를 점유하거나, 외부 연동 호출이 지연되면서 대기가 길어질 수 있다.

어떤 선택이 적합: 먼저 “느려지는 지점이 서버 내부인지, 네트워크/외부 연동인지”를 분리해야 한다. 그 다음 CPU·메모리·디스크·네트워크 중 어떤 경로가 지연을 만들었는지 지표로 좁힌다.

잘못 쓰면 어떤 문제: CPU만 보고 서버 증설로 결론 내리면, 실제 원인이 디스크 지연이나 외부 API 지연일 때 비용만 늘고 문제는 남는다. 메모리 사용량만 보고 즉시 재시작하면 일시적으로 좋아져 보이지만 원인 데이터가 사라져 재현이 어려워질 수 있다.

확인/해결: 사건 시간을 고정하고, 같은 시간대의 지표를 함께 모아 “동시에 변하는 값”을 찾는 방식이 재발 방지에 유리하다.

 

성능 문제를 10분 안에 분류하는 진단 플로우

 

따라할 수 있는 확인 방법: 화면 체감부터 시스템 지표까지 순서로 묶는다

1. 느려진 시각을 기록한다(예: 14:10~14:25). 같은 시간대 비교가 가능한 기준점이 된다.
2. 브라우저 개발자도구의 Network 탭에서 요청 시간을 본다. 대기(TTFB)가 긴지, 다운로드가 긴지로 “서버 처리 지연”과 “전송 지연”을 분리한다.
3. 서버(또는 PC)에서 작업 관리자/활동 모니터/htop 등으로 프로세스별 CPU 상위 항목을 확인한다. 특정 프로세스가 비정상적으로 치솟는지 본다.
4. 메모리에서 스왑 사용, 페이지 인/아웃 급증, OOM 흔적을 확인한다. 동시에 “갑자기 멈추는 체감”이 있었는지와 함께 본다.
5. 디스크는 처리량보다 지연시간과 대기열을 먼저 확인한다. 로그 폭증, DB 파일 I/O, 백업 작업이 같은 시간에 겹치는지 확인한다.
6. 네트워크는 대역폭뿐 아니라 오류 수치(재전송, 드롭, 연결 급증)를 확인한다. 외부 연동 호출이 있다면 호출 시간과 실패율을 함께 본다.
7. 같은 시간대에 가장 뚜렷하게 변한 지표 1개를 “1차 병목 후보”로 고정하고, 그 후보에 맞는 다음 조치를 정한다(예: 디스크 지연이면 로그/DB I/O 분리, 네트워크 지연이면 외부 연동 타임아웃·재시도 정책 점검).

자주 나오는 패턴 3가지로 빠르게 결론을 좁힌다

패턴 1: CPU 상승과 함께 전체가 무거워진다. 계산량 증가, 무한 루프, 과도한 동시 처리, 특정 쿼리 폭주가 후보가 된다.

패턴 2: CPU는 낮은데 멈춘 듯 느리다. 디스크 대기나 외부 호출 대기처럼 “기다리는 시간”이 길어졌을 가능성이 있다.

패턴 3: 메모리가 서서히 차고 어느 순간 급격히 느려진다. 누수, 캐시 정책 불일치, 스왑 사용 증가가 결합되는 경우가 많다.

결론

성능 지표는 높고 낮음을 판정하는 도구가 아니라, 병목 경로를 줄이는 지도다.

CPU·메모리부터 읽되, 디스크 지연과 네트워크 지연은 “대기 시간”으로 나타날 수 있음을 함께 본다.

사건 시간을 고정하고 같은 시간대 지표를 묶어 보면, 원인 후보가 빠르게 좁혀진다.

• 다음에 읽으면 좋은 연계 주제: 실행 로그와 지표를 같은 타임라인으로 맞추는 방법
• 다음에 읽으면 좋은 연계 주제: 지연시간(레이트턴시) 분포와 평균의 함정

FAQ

CPU 사용률이 20%인데도 서비스가 느릴 수 있는가

가능하다. 외부 API 응답 대기, 디스크 I/O 대기, 락 대기처럼 CPU가 할 일이 없어 쉬는 상황이면 사용률은 낮게 보이지만 체감은 느려질 수 있다.

메모리가 거의 꽉 찼다고 항상 문제인 것인가

항상 그렇지는 않다. 캐시가 크게 잡혀 “사용 중”으로 보일 수 있다. 다만 스왑 사용이 늘거나 멈춤이 동반되면 메모리 압박으로 보는 편이 낫다.

디스크는 처리량이 높을 때만 느려지는가

그렇지 않다. 처리량이 낮아도 지연시간이 높고 대기열이 길면 느릴 수 있다. 특히 작은 랜덤 I/O가 많거나, 로그/DB 작업이 겹치면 지연이 먼저 튈 수 있다.