리눅스 서버에서 CPU나 메모리 사용률이 높은 프로세스를 확인하다 보면 특정 PID가 눈에 들어올 때가 있습니다.
top또는:
ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head예를 들어 이런 식입니다.
PID PPID USER CMD %CPU %MEM
1234 1 appuser java -jar app.jar 98.7 10.8
2345 1 mysql /usr/sbin/mysqld 35.2 7.6
3456 1 nginx nginx: worker process 5.0 1.2여기서 초보 운영자가 가장 조심해야 할 부분이 있습니다.
PID만 보고 바로 kill 하면 안 됩니다.
PID는 단순히 프로세스 번호입니다.
중요한 건 그 PID가 어떤 서비스인지, 어떤 계정으로 실행 중인지, 죽였을 때 서비스 영향이 있는지를 확인하는 것입니다.
이번 글에서는 리눅스 서버에서 특정 PID가 어떤 서비스인지 확인하는 기본 순서를 초보 운영자 눈높이로 정리해보겠습니다.
PID는 프로세스 번호일 뿐입니다
PID는 Process ID의 줄임말입니다.
리눅스에서 실행 중인 프로세스마다 붙는 번호입니다.
예를 들어 1234라는 PID가 있다고 해서 그 자체만으로는 어떤 서비스인지 알 수 없습니다.
PID 1234이 숫자만 보고 알 수 있는 건 “현재 실행 중인 어떤 프로세스의 번호” 정도입니다.
그래서 PID를 찾았다면 다음 질문으로 넘어가야 합니다.
이 PID는 어떤 명령으로 실행됐는가?
어떤 계정이 실행했는가?
어느 경로에서 실행 중인가?
systemd 서비스와 연결되어 있는가?
죽이면 어떤 영향이 있는가?이걸 확인하지 않고 바로 kill 하면 운영 장애로 이어질 수 있습니다.
먼저 ps -fp로 PID 상세 확인
가장 먼저 볼 명령어는 ps -fp입니다.
ps -fp 1234예시 결과입니다.
UID PID PPID C STIME TTY TIME CMD
appuser 1234 1 85 10:20 ? 00:12:33 java -jar /app/service/app.jar여기서 볼 것은 아래입니다.
UID = 실행 계정
PID = 현재 프로세스 ID
PPID = 부모 프로세스 ID
CMD = 실행 명령특히 CMD가 중요합니다.
단순히 java라고만 보면 헷갈릴 수 있지만, 전체 명령을 보면 어떤 jar를 실행 중인지 알 수 있습니다.
java -jar /app/service/app.jar이 정도만 봐도 “이건 app 서비스 관련 Java 프로세스구나” 정도는 추정할 수 있습니다.
ps로 전체 명령이 잘리지 않게 보기
가끔 ps -fp 결과에서 명령어가 너무 길어서 잘려 보일 때가 있습니다.
그럴 때는 아래처럼 볼 수 있습니다.
ps -p 1234 -o pid,ppid,user,lstart,etime,cmd예시입니다.
PID PPID USER STARTED ELAPSED CMD
1234 1 appuser Mon Jun 23 10:20:10 2026 01:15:22 java -jar /app/service/app.jar --spring.profiles.active=prod여기서는 시작 시간과 실행 후 경과 시간도 같이 볼 수 있습니다.
lstart = 프로세스 시작 시간
etime = 실행 후 지난 시간
cmd = 실행 명령이 정보는 “언제부터 CPU가 높았는지”, “배포 이후 생긴 문제인지”를 볼 때 도움이 됩니다.
pwdx로 실행 위치 확인
PID가 어느 디렉터리에서 실행 중인지 확인하려면 pwdx를 사용할 수 있습니다.
pwdx 1234예시입니다.
1234: /app/service이 결과를 보면 해당 프로세스가 /app/service 경로에서 실행 중이라는 것을 알 수 있습니다.
운영 서버에서는 경로만 봐도 어떤 서비스인지 힌트를 얻을 때가 많습니다.
예를 들어:
/app/service
/opt/tomcat
/usr/local/nginx
/data/batch
/home/appuser/deploy이런 경로는 서비스나 배치 작업을 구분하는 데 도움이 됩니다.
/proc/PID/exe로 실행 파일 확인
리눅스에서는 /proc 아래에서 프로세스 정보를 확인할 수 있습니다.
실행 파일 경로를 보려면 아래 명령어를 사용합니다.
readlink -f /proc/1234/exe예시입니다.
/usr/bin/java이 경우 실행 파일은 Java입니다.
다만 Java처럼 공통 실행 파일을 사용하는 경우에는 이것만으로 서비스 이름을 알기는 어렵습니다.
그래서 exe 정보와 함께 cmdline, cwd도 같이 보면 좋습니다.
/proc/PID/cwd로 현재 작업 디렉터리 확인
현재 작업 디렉터리는 아래처럼 볼 수 있습니다.
readlink -f /proc/1234/cwd예시입니다.
/app/service이건 pwdx와 비슷한 정보를 보여줍니다.
운영 중에는 pwdx가 안 되는 환경도 있을 수 있으니 /proc 경로를 알아두면 좋습니다.
/proc/PID/cmdline으로 실행 명령 확인
실행 명령을 더 직접적으로 보려면 아래처럼 확인할 수 있습니다.
tr '\0' ' ' < /proc/1234/cmdline예시입니다.
java -jar /app/service/app.jar --spring.profiles.active=prodcmdline은 null 문자로 구분되어 있어 그냥 cat으로 보면 붙어서 보일 수 있습니다.
그래서 tr '\0' ' '를 붙여서 공백으로 바꿔 보는 방식이 편합니다.
이 명령어는 긴 실행 옵션을 확인할 때 도움이 됩니다.
systemd 서비스와 연결되어 있는지 확인
운영 서버에서는 프로세스가 systemd 서비스로 관리되는 경우가 많습니다.
PID가 어떤 systemd 서비스와 연결되어 있는지 확인하려면 아래 명령어를 사용할 수 있습니다.
systemctl status 1234환경에 따라 PID 기준으로 서비스 정보를 보여줄 수 있습니다.
또는 프로세스 정보를 보고 서비스 이름을 추정한 뒤 status를 확인합니다.
systemctl status nginxsystemctl status app.service서비스 목록에서 찾아볼 수도 있습니다.
systemctl list-units --type=service | grep app만약 systemd 서비스라면 바로 kill하기보다 systemctl status로 상태와 로그를 같이 확인하는 게 좋습니다.
systemctl status app.service --no-pager부모 프로세스 PPID도 확인하기
ps 결과에서 PPID도 중요합니다.
ps -fp 1234예시:
UID PID PPID C STIME TTY TIME CMD
appuser 1234 1000 85 10:20 ? 00:12:33 java -jar /app/service/app.jar여기서 PPID가 1000이면 부모 프로세스도 확인할 수 있습니다.
ps -fp 1000부모 프로세스를 보면 이 프로세스가 어떤 방식으로 실행됐는지 알 수 있습니다.
예를 들어:
systemd에서 실행됨
쉘 스크립트에서 실행됨
배치 스케줄러에서 실행됨
수동으로 실행됨
컨테이너 런타임에서 실행됨이 차이는 조치 판단에 중요합니다.
프로세스 트리로 보면 더 편하다
부모와 자식 관계를 한눈에 보려면 pstree를 사용할 수 있습니다.
pstree -p 1234또는 전체에서 특정 PID를 찾아볼 수 있습니다.
pstree -ap | grep 1234예시입니다.
systemd(1)─┬─java(1234)─┬─{java}(1235)
│ ├─{java}(1236)
│ └─{java}(1237)Java나 nginx, DB처럼 여러 자식 프로세스나 스레드가 있는 서비스는 트리로 보면 구조를 이해하기 쉽습니다.
다만 pstree가 설치되어 있지 않은 환경도 있을 수 있습니다.
열린 파일이나 포트도 확인하기
PID가 어떤 포트를 열고 있는지 확인하면 서비스 구분에 도움이 됩니다.
ss -lntp | grep 1234예시입니다.
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=1234,fd=55))이 결과를 보면 PID 1234가 8080 포트를 열고 있다는 것을 알 수 있습니다.
웹 서비스나 API 서버라면 포트 정보가 중요한 단서가 됩니다.
열린 파일을 보려면 lsof를 사용할 수도 있습니다.
lsof -p 1234 | head다만 운영 서버에서는 lsof가 설치되어 있지 않을 수 있고, 결과가 많을 수 있습니다.
컨테이너 환경이면 PID가 더 헷갈릴 수 있다
Docker나 Kubernetes 환경에서는 호스트에서 보이는 PID와 컨테이너 내부에서 보이는 PID가 다를 수 있습니다.
예를 들어 호스트에서 보면 PID가 1234인데, 컨테이너 안에서는 PID 1일 수 있습니다.
Docker 환경이라면 아래처럼 확인할 수 있습니다.
docker psdocker top 컨테이너IDKubernetes 환경이라면 보통 Pod 기준으로 확인합니다.
kubectl get pod -A -o widekubectl logs 파드명 -n 네임스페이스이 글은 리눅스 서버 기본 기준으로 정리하지만, 컨테이너 환경에서는 PID만 보고 판단하면 더 위험할 수 있습니다.
PID만 보고 kill 하면 안 되는 이유
PID를 확인하다 보면 빨리 조치하고 싶어서 이런 명령을 떠올릴 수 있습니다.
kill -9 1234하지만 kill -9는 강제 종료입니다.
서비스가 정상 종료할 시간을 주지 않고 바로 죽이기 때문에 아래 문제가 생길 수 있습니다.
사용자 요청이 끊김
파일 쓰기 중단
데이터 정합성 문제
자동 재기동 실패
이중화되지 않은 서비스 중단
장애 원인 로그 소실특히 DB, 애플리케이션 서버, 메시지 큐, 배치 작업은 더 조심해야 합니다.
PID를 찾았다고 조치가 끝난 게 아닙니다.
PID가 어떤 서비스인지 확인하고, 영향도를 판단한 뒤 조치해야 합니다.
운영 서버에서 확인하는 순서
특정 PID가 눈에 들어왔을 때 저는 보통 아래 순서로 봅니다.
1. ps -fp로 PID 상세 확인
2. 실행 계정 확인
3. 실행 명령과 경로 확인
4. pwdx 또는 /proc으로 작업 디렉터리 확인
5. PPID로 부모 프로세스 확인
6. systemctl status로 서비스 여부 확인
7. ss로 열린 포트 확인
8. 로그와 영향도 확인
9. 조치 여부 판단명령어로 정리하면 아래와 같습니다.
ps -fp 1234ps -p 1234 -o pid,ppid,user,lstart,etime,cmdpwdx 1234readlink -f /proc/1234/exereadlink -f /proc/1234/cwdtr '\0' ' ' < /proc/1234/cmdliness -lntp | grep 1234이 정도를 확인하면 단순한 PID 번호가 아니라, 어떤 서비스와 연결된 프로세스인지 훨씬 명확해집니다.
실무 보고 예시
PID를 확인 중이라면 이렇게 보고할 수 있습니다.
CPU 사용률이 높은 PID를 확인했으며, 해당 PID의 실행 명령과 서비스 연관성을 확인 중입니다.
서비스 영향도 확인 후 조치 여부를 판단하겠습니다.특정 서비스로 확인됐다면:
확인 결과 PID 1234는 app 서비스 프로세스로 확인되었습니다.
현재 서비스 응답 상태와 로그를 함께 확인하고 있으며, 필요 시 절차에 따라 조치하겠습니다.작업성 프로세스라면:
해당 PID는 로그 압축 작업으로 확인됩니다.
작업 중단 시 영향 여부를 확인 후 조치 여부를 판단하겠습니다.PID만 확인됐고 아직 서비스가 불명확하다면:
PID 기준 CPU 사용률 상승은 확인되었으나, 서비스 연관성은 추가 확인 중입니다.
실행 경로, 부모 프로세스, 열린 포트 기준으로 원인 범위를 좁히겠습니다.이렇게 쓰면 “PID 죽이겠습니다”보다 훨씬 안전한 보고가 됩니다.
정리
리눅스 서버에서 특정 PID를 찾았다고 바로 조치하면 안 됩니다.
PID는 단순한 번호이고, 중요한 것은 이 PID가 어떤 서비스인지 확인하는 것입니다.
기본 확인 명령어는 아래입니다.
ps -fp PIDpwdx PIDreadlink -f /proc/PID/exetr '\0' ' ' < /proc/PID/cmdliness -lntp | grep PID초보 운영자라면 이 문장만 기억해도 좋습니다.
PID만 보고 kill 하지 말고, 어떤 서비스인지 먼저 확인한다.프로세스 조치도 결국 확인 → 판단 → 조치 순서가 중요합니다.
4. 관련 글 연결 문구
CPU 사용률이 높은 PID를 찾았다면, 그다음은 해당 PID가 어떤 서비스인지 확인해야 합니다.
아래 글도 함께 보면 흐름이 자연스럽습니다.
- 리눅스 서버 CPU 사용률 높은 프로세스 확인하는 법
- 리눅스 서버 CPU 100%일 때 바로 kill 하면 안 되는 이유
- 리눅스 서버가 느려졌을 때 바로 재기동하기 전 기본 점검 순서
- 리눅스 서버 CPU는 낮은데 느릴 때 top에서 wa 값 확인하는 법
5. 다음 글 예고 문구
다음 글에서는 서버가 느리다는 상황을 보고할 때 CPU, 메모리, 디스크, 프로세스 상태를 어떻게 짧고 정확하게 정리하면 좋은지 다뤄보겠습니다.
'리눅스' 카테고리의 다른 글
| 리눅스 서버 웹사이트 접속 안 될 때, 방화벽부터 보지 말고 curl로 내부부터 확인하는 법 (0) | 2026.06.25 |
|---|---|
| 리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법 (0) | 2026.06.24 |
| 리눅스 서버 CPU 100% 알림 떴을 때, 재기동 전 범인(PID)부터 찾는 법 (0) | 2026.06.22 |
| 리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법 (0) | 2026.06.21 |
| 리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서 (0) | 2026.06.20 |