DAY 06: 프로세스 감시자

소개

주니어 시스템 관리자님, 환영합니다! "LabEx"의 바쁜 월요일 아침, 긴급 경보가 발생했습니다. 메인 애플리케이션 서버가 급격히 느려져 모든 사용자에게 영향을 주고 있습니다. 선임 관리자들이 긴급 회의로 자리를 비운 사이, 여러분이 직접 문제를 조사하고 시스템을 안정화해야 합니다.

지금이 바로 여러분의 실력을 증명할 기회입니다. 서버의 명령줄 인터페이스에 접속하여 실행 중인 프로세스를 점검하고 문제를 진단하세요. 리소스를 과도하게 점유하는 원인을 찾아 제거하고, 필수 서비스가 정상적으로 운영되도록 조치해야 합니다. 이 챌린지를 마칠 때쯤이면, 시스템 관리자의 핵심 역량인 '압박 속에서의 실시간 리눅스 환경 관리 능력'을 갖추게 될 것입니다.

실행 중인 시스템 프로세스 나열하기

프로세스 감시자로서의 첫 번째 임무는 현재 서버에서 무엇이 실행되고 있는지 전체적인 그림을 파악하는 것입니다. 활성화된 모든 프로세스의 정적인 스냅샷을 확인하면 조사를 시작하고 이상 징후를 식별하는 데 도움이 됩니다.

과제

• 단일 명령어를 사용하여 시스템에서 실행 중인 모든 프로세스의 상세 목록을 생성하세요.

요구 사항

• 현재 사용자뿐만 아니라 모든 사용자의 프로세스를 표시해야 합니다.
• 출력 형식은 프로세스 소유자, CPU/메모리 사용량, 실행 시 사용된 전체 명령어 등 상세 정보를 포함하는 사용자 중심 형식이어야 합니다.

예시

명령어를 실행하면 다음과 유사한 출력이 나타나야 합니다.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 169848  9064 ?        Ss   08:30   0:02 /sbin/init
labex     1234  0.0  0.0   2324   564 pts/0    S+   08:35   0:00 bash /home/labex/project/resource_hog.sh
labex     1235  0.0  0.0   2324   564 ?        S    08:35   0:00 bash /home/labex/project/critical_service.sh
...

출력 결과에는 사용자, 프로세스 ID, CPU 사용률, 메모리 사용률 및 각 프로세스를 시작한 명령어가 열 형태로 표시됩니다.

힌트

• 이 작업에 가장 흔히 사용되는 명령어는 ps입니다.
• 모든 (a) 사용자의 프로세스를 사용자 (u) 친화적인 형식으로 보여주고, 터미널에 연결되지 않은 **프로세스 (x)**까지 포함하는 ps 옵션이 무엇인지 생각해보세요.

프로세스 리소스 사용량 모니터링

ps를 통한 정적 목록 확인은 좋은 시작이었지만, 서버의 부하는 매초 변하고 있습니다. 어떤 프로세스가 실제로 속도 저하를 일으키고 있는지 확인하려면 실시간으로 변하는 동적인 뷰가 필요합니다. 이제 더 강력한 모니터링 도구를 꺼낼 차례입니다.

과제

• 시스템 프로세스와 리소스 사용량을 실시간으로 모니터링할 수 있는 대화형 명령줄 유틸리티를 실행하세요.
• CPU 를 가장 많이 소모하고 있는 스크립트의 이름을 확인하세요.

요구 사항

• 지속적으로 업데이트되는 실시간 시스템 프로세스 뷰를 제공하는 도구를 사용해야 합니다.
• 해당 도구는 기본적으로 CPU 사용량에 따라 프로세스를 정렬해야 합니다.
• 리소스를 가장 많이 사용하는 대상을 확인한 후, 도구를 종료하고 다음 단계로 진행하세요.

예시

모니터링 도구를 실행하면 다음과 같이 자동으로 업데이트되는 대화형 화면이 나타납니다.

top - 09:15:30 up  1:45,  1 user,  load average: 1.50, 1.20, 0.85
Tasks: 105 total,   2 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.0 us,  5.0 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   2048.0 total,    850.4 free,    950.2 used,    247.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used,      0.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 labex     20   0   12884   1564   1320 R  95.0   0.1   2:15.30 bash /home/labex/project/resource_hog.sh
 1235 labex     20   0   12884   1564   1320 S   0.0   0.1   0:00.00 bash /home/labex/project/critical_service.sh
    1 root      20   0  169848   9064   6868 S   0.0   0.4   0:02.15 systemd
...

화면 상단에는 시스템 통계가 표시되고, 아래에는 CPU 사용량 순으로 정렬된 프로세스 목록이 나타나며, 가장 높은 CPU 점유율을 가진 프로세스가 맨 위에 위치합니다.

힌트

• 이 유명한 명령어는 리눅스 세계의 "작업 관리자"라고 불리기도 합니다.
• 대화형 도구에서 빠져나오려면 q 키를 누르면 됩니다.

주요 프로세스 식별하기

문제의 원인인 resource_hog.sh를 찾았습니다. 하지만 유능한 시스템 관리자는 무턱대고 프로세스를 종료하지 않습니다. 여러분은 critical_service.sh도 실행 중인 것을 확인했습니다. 리소스 점유 프로세스에 조치를 취하기 전에, 시스템에서 실행 중인 주요 프로세스들을 정확히 식별하고 이해해야 합니다.

과제

• critical_service.sh 스크립트의 프로세스 ID(PID) 를 찾으세요.
• 해당 핵심 서비스가 정상적으로 실행 중인지 확인하세요.

요구 사항

• pgrep 명령어를 사용하여 critical_service.sh를 실행 중인 프로세스의 PID 를 찾아야 합니다.
• 명령어는 실행 중인 프로세스를 성공적으로 찾아 PID 를 표시해야 합니다.

예시

pgrep으로 PID 를 찾으면 다음과 같은 출력이 나타납니다.

1235

이 숫자 (이 예시에서는 1235) 가 핵심 서비스 프로세스의 PID 입니다.

다음 명령어를 사용하여 프로세스 상세 정보를 확인할 수 있습니다.

ps -p 1235 -o pid,ppid,cmd

출력 결과는 다음과 유사해야 합니다.

PID PPID CMD
1235 1 /bin/bash /home/labex/project/critical_service.sh

힌트

• pgrep은 프로세스 이름을 기반으로 PID 를 찾을 수 있습니다.
• 전체 명령줄 인수를 대상으로 검색하려면 pgrep -f 옵션을 사용하세요.

오작동하는 프로세스 종료하기

이제 주요 프로세스들을 파악했으니, 서버를 느리게 만들고 있는 resource_hog.sh를 처리할 차례입니다. 정상적인 운영 상태로 복구하기 위해 이 프로세스를 종료해야 합니다.

과제

• resource_hog.sh 프로세스를 종료하세요.

요구 사항

• PID 를 먼저 찾을 필요 없이, 이름을 기반으로 프로세스를 종료할 수 있는 명령어를 사용해야 합니다.
• pkill 명령어를 사용하여 resource_hog.sh 스크립트를 중지하세요.

예시

프로세스가 종료되었는지 확인하기 위해 종료 후 프로세스 목록을 점검할 수 있습니다. 종료 전에는 다음과 같이 보일 수 있습니다.

labex 1234 95.0 0.0 2324 564 pts/0 R+ 09:15 5:00 bash /home/labex/project/resource_hog.sh

성공적으로 종료된 후 동일한 확인 명령어를 실행하면 일치하는 프로세스가 나타나지 않아야 합니다 (grep 명령어 자체만 표시됨).

labex 2345 0.0 0.0 2324 564 pts/0 S+ 09:20 0:00 grep resource_hog

힌트

• pkill 명령어는 이름을 기반으로 프로세스에 종료 신호를 보냅니다.
• 명령 실행 후, ps aux | grep resource_hog를 사용하여 프로세스가 더 이상 실행 중이지 않은지 확인하세요.

백그라운드 프로세스 시작 및 관리

서버가 다시 안정되었습니다! 훌륭합니다. 잠시 쉬려던 찰나, 개발자로부터 메시지가 왔습니다. 서버에서 오래 걸리는 스크립트인 data_processor.sh를 실행해 달라고 합니다. 이 스크립트 하나 때문에 터미널 세션을 몇 시간 동안 열어둘 수는 없습니다. 로그아웃한 후에도 스크립트가 계속 실행되도록 백그라운드에서 실행해야 합니다.

과제

• data_processor.sh 스크립트를 백그라운드에서 실행하고, 터미널을 닫아도 중단되지 않도록 (Hangup 면제) 설정하세요.

요구 사항

• 반드시 ~/project 디렉토리에서 작업해야 합니다.
• nohup 명령어를 사용하여 스크립트를 실행하세요.
• & 연산자를 사용하여 프로세스를 백그라운드로 보내세요.
• 스크립트의 모든 출력 (표준 출력 및 표준 에러) 을 processor.log라는 파일로 리다이렉션하세요.

예시

백그라운드에서 스크립트를 성공적으로 시작하면 다음과 유사한 출력이 나타납니다.

[1] 3456
nohup: ignoring input and appending output to 'processor.log'

[1] 3456은 작업 번호와 프로세스 ID 를 나타냅니다. 로그 파일을 확인하여 스크립트가 실행 중인지 확인할 수 있습니다.

cat processor.log

다음과 같은 내용이 보일 수 있습니다.

Starting data processing at Mon Sep 11 10:30:00 UTC 2025

또한 프로세스가 여전히 활성 상태인지 확인할 수 있습니다.

ps aux | grep data_processor

백그라운드 프로세스가 활성화되어 있는 것을 확인할 수 있을 것입니다.

힌트

• nohup 명령어는 "no hang up"의 약자입니다.
• 명령어 끝에 붙는 & 기호는 쉘에 해당 명령을 백그라운드 작업으로 실행하도록 지시합니다.
• 표준 출력은 >로, 표준 에러는 2>&1로 리다이렉션할 수 있습니다.

요약

축하합니다, 관리자님! 심각한 서버 성능 문제를 성공적으로 해결하고 리눅스 프로세스 관리 능력을 입증하셨습니다. 서버는 안정화되었고, 핵심 서비스는 우선적으로 보호받고 있으며, 장시간 실행되는 작업은 백그라운드에서 원활하게 돌아가고 있습니다.

이번 챌린지를 통해 여러분은 다음 능력을 증명했습니다.

• ps를 사용하여 실행 중인 모든 프로세스 나열 및 점검.
• top을 사용하여 시스템 리소스 실시간 모니터링.
• pgrep을 사용하여 중요한 프로세스 식별.
• pkill을 사용하여 오작동하는 프로세스를 깔끔하게 종료.
• nohup과 &를 사용하여 로그아웃 후에도 유지되는 백그라운드 작업 실행 및 관리.

이러한 기술은 시스템 관리, 데브옵스 (DevOps) 또는 백엔드 개발 분야에서 필수적인 고부가가치 역량입니다. 잠재적인 위기 상황을 여러분의 전문성을 발휘할 기회로 멋지게 바꾸어 놓으셨습니다. 수고하셨습니다!