안녕하세요. 15년 차 백엔드 개발자이자, 여러분과 같은 길을 걸으며 수많은 밤을 지새웠던 선배 개발자입니다. 오늘은 개발자라면 누구나 한 번쯤 겪게 되는 등골 오싹한 순간, 바로 '서버가 느려졌을 때'의 대처법에 대해 이야기해 보려 합니다. 단순히 명령어를 치는 것을 넘어, 리눅스 서버의 청진기라고 할 수 있는 top 명령어를 해부학 수준으로 뜯어보고, 병목 구간을 정확히 타격하는 방법을 공유하겠습니다.
혹시 지금 이 글을 읽고 계신 분들 중, 갑자기 치솟는 트래픽 때문에 서버 응답 속도가 3초, 5초, 심지어 타임아웃까지 가는 상황을 겪고 계신 분이 있나요? 아니면 클라우드 비용은 계속 나가는데 도대체 자원이 어디서 새는지 몰라 답답하신가요? 통계에 따르면 웹사이트 로딩이 3초를 넘어가면 사용자의 40%가 이탈한다고 합니다. 즉, 서버 성능은 곧 매출입니다. 저도 주니어 시절, 터미널 앞에서 깜빡이는 커서만 바라보며 식은 땀을 흘리던 시절이 있었습니다. 그때 저를 구원해 준 것이 바로 top 명령어였습니다. 화려한 GUI 도구들도 많지만, 가장 기본적이면서도 강력한 이 도구를 마스터하는 순간 여러분은 서버의 '진짜 주인'이 될 수 있습니다.
1. 왜 하필 지금 'top' 명령어인가요? (도구의 재발견)
많은 개발자들이 top 명령어를 단순히 '현재 CPU 사용량 확인용' 정도로만 알고 있습니다. 하지만 이는 마치 최신형 스마트폰을 사서 전화 기능만 쓰는 것과 같습니다. 실전에서 top은 서버의 종합 검진 센터와 같습니다. CPU, 메모리, 스왑(Swap), I/O 대기(Wait), 좀비 프로세스, 심지어 로드 밸런싱의 치우침까지 모든 정보를 실시간으로 보여주기 때문입니다.
모니터링 도구의 홍수 속에서 살아남은 이유
요즘은 Datadog, New Relic, Prometheus 같은 훌륭한 모니터링 도구들이 즐비합니다. 그럼에도 불구하고 왜 우리는 검은 화면의 텍스트 도구를 배워야 할까요? 정답은 '접근성'과 '실시간성'에 있습니다. 서버에 심각한 장애가 발생해서 SSH로 겨우 접속했을 때, 무거운 에이전트 기반의 GUI 도구는 아예 데이터를 전송하지 못하거나 대시보드가 열리지 않는 경우가 많습니다.
반면 top은 모든 리눅스 배포판에 기본적으로 설치되어 있습니다. 별도의 설치 과정 없이, 어떤 서버에 들어가든 즉시 실행할 수 있죠. 제 경험상, AWS EC2 인스턴스가 먹통이 되기 직전, 마지막 1초의 순간에 원인을 파악하게 해 준 것은 화려한 대시보드가 아니라 바로 터미널 창의 top이었습니다. 또한, top은 커널이 제공하는 /proc 파일 시스템의 데이터를 가장 날것(Raw) 그대로 보여줍니다. 가공되지 않은 데이터를 볼 줄 알아야, 왜곡 없는 정확한 진단이 가능합니다.
Before & After: top을 제대로 알기 전과 후
제 신입 시절 이야기를 잠깐 해보겠습니다. 당시 운영하던 쇼핑몰 사이트가 이벤트만 하면 느려지는 현상이 있었습니다. 저는 단순히 "서버가 부족한가 보다"라고 생각해서, 회사 법인 카드로 더 비싼 고성능 서버를 증설했습니다. 결과는 참담했습니다.
Before (무지했던 시절):
- 서버가 느려지면 무조건 CPU 코어 수와 메모리를 2배로 늘렸습니다. (스케일 업)
- 월 서버 비용이 200만 원에서 400만 원으로 뛰었지만, 응답 속도는 고작 0.5초 빨라졌습니다.
- 팀장님께 "트래픽이 많아서 어쩔 수 없습니다"라고 변명하기 바빴고, 야근은 일상이었습니다.
After (top 마스터 후):
- top의
%wa(I/O Wait) 수치를 통해 병목 구간이 CPU 연산이 아니라, 특정 프로세스의 과도한 로그 기록으로 인한 디스크 I/O 대기 때문임을 발견했습니다.
- 로그 레벨을 조정하고 DB 인덱스를 최적화한 결과, 기존 서버 사양의 절반(다운사이징)으로도 트래픽을 여유롭게 감당하게 되었습니다.
- 서버 비용을 월 150만 원 절감했고, 이 성과로 연말 고과에서 S등급을 받았습니다.
2. Load Average: 서버의 피로도를 측정하는 핵심 지표
터미널에 top을 입력하면 가장 윗줄 우측에 load average라는 숫자가 세 개 나옵니다. 많은 분들이 이 숫자를 대충 보고 넘기지만, 사실 이곳에 서버 상태의 80%가 담겨 있습니다. 이 숫자를 해석하지 못하면 서버 증설 타이밍을 영원히 놓치게 됩니다.
숫자 세 개의 비밀: 1분, 5분, 15분
이 세 숫자는 각각 최근 1분, 5분, 15분 동안의 평균 시스템 부하를 나타냅니다. 왜 세 개나 보여줄까요? 바로 추세(Trend)를 파악하기 위함입니다. 단편적인 숫자보다 흐름이 중요합니다.
- 사례 1:
load average: 1.5, 0.5, 0.1 -> 15분 전에는 0.1로 평화로웠지만, 최근 1분 사이 1.5로 급격히 부하가 늘어났습니다. 장애가 '시작'되고 있다는 강력한 신호입니다. 즉시 로그를 확인해야 합니다.
- 사례 2:
load average: 0.5, 1.5, 3.0 -> 아까는 힘들었지만 지금은 상황이 진정되고 있다는 뜻입니다. 일시적인 배치 작업이 끝났을 가능성이 큽니다.
CPU 코어 수와의 상관관계 (매우 중요!)
"Load Average가 5면 높은 건가요?"라는 질문을 종종 받습니다. 정답은 "CPU 코어 수에 따라 다릅니다"입니다. 이 개념을 잡지 못하면 엉뚱한 보고를 하게 됩니다.
- 싱글 코어(1 Core)일 때: Load 1.0은 100% 부하입니다. Load 5.0은 시스템이 비명을 지르고 있는 상태입니다. 4개의 작업이 대기 중이라는 뜻이니까요.
- 쿼드 코어(4 Cores)일 때: Load 1.0은 25% 부하에 불과합니다. 아주 여유롭죠. Load 4.0이 되어야 비로소 100%를 다 쓰는 것입니다.
실제 사례를 하나 들자면, 32코어짜리 고성능 DB 서버를 운영할 때였습니다. 모니터링 알람이 울려서 보니 Load Average가 20까지 치솟아 있었습니다. 신입 개발자가 "큰일 났습니다! 부하가 20입니다!"라고 소리쳤죠. 하지만 저는 침착하게 "괜찮아, 우리 코어 32개잖아. 아직 60% 정도밖에 안 쓰고 있어."라고 안심시켰습니다. 숫자의 절대값이 아니라, 내 시스템의 수용 능력(Capacity) 대비 비율을 보는 것이 핵심입니다.
댓글
댓글 쓰기