POOOLING FOREST
"도대체 이 프로세스는 누가 띄운 거야?" 리눅스 탐정 witr를 소개합니다 - 리눅스 프로세스의 실행 원인을 명확하게 추적해주는 오픈소스 도구 'witr'를 소개합니다. PID, 포트,
Engineering & Tech

"도대체 이 프로세스는 누가 띄운 거야?" 리눅스 탐정 witr를 소개합니다

리눅스 프로세스의 실행 원인을 명확하게 추적해주는 오픈소스 도구 'witr'를 소개합니다. PID, 포트, 이름을 기반으로 프로세스의 계보와 문맥을 한눈에 파악하세요.

김테크

8년차 개발자

안녕하세요. 풀링포레스트 백엔드 개발자 김테크입니다.

서버를 운영하다 보면 정말 등골이 서늘해지는 순간들이 있습니다. 장애 알림을 받고 급하게 터미널에 접속했는데, 듣도 보도 못한 포트가 열려 있거나 분명 죽였어야 할 프로세스가 좀비처럼 되살아나 리소스를 잡아먹고 있는 상황이죠. 습관처럼 ps aux | grep nodenetstat -tulpn, lsof 같은 명령어를 타다닥 치지만, 화면에 뜨는 건 무미건조한 PID 숫자와 알 수 없는 실행 옵션들뿐입니다.

"이거... 도대체 누가, 어디서, 왜 실행시킨 거지?"

솔직히 말해, 복잡하게 얽힌 MSA 환경이나 오래된 레거시 서버에서 이런 '유령 프로세스'의 근원을 찾는 건 베테랑 개발자에게도 고역입니다. PID를 따서 부모 프로세스(PPID)를 찾고, 그 부모가 systemd인지 Docker인지, 아니면 누군가 쉘에서 실수로 백그라운드로 돌린 건지 역추적하는 과정은 시간도 오래 걸리고 실수하기도 쉽습니다.

최근에 이런 막막함을 한 방에 해결해 줄 재미있는 도구를 발견해서 공유해 드리려고 합니다. 바로 witr라는 오픈소스 도구입니다. 이름부터 직관적입니다. "Why Is This Running?"의 약자거든요.

기존의 top이나 ps가 "무엇이 실행 중인가"라는 '상태'를 보여준다면, witr는 "왜 실행 중인가"라는 '인과관계'를 설명해 줍니다. 제가 이 도구를 써보고 가장 감탄했던 점은 프로세스의 계보를 사람이 읽기 쉬운 내러티브 형태로 보여준다는 것입니다.

예를 들어, 5000번 포트를 누가 쓰고 있는지 궁금할 때 보통 lsof -i :5000을 치고 나오는 PID를 다시 추적해야 했죠? witr --port 5000을 입력하면 이런 식의 결과가 나옵니다.

Why It Exists : systemd (pid 1) → docker (pid 450) → node (pid 14233)

단순히 프로세스 정보만 보여주는 게 아니라, "이 프로세스는 systemd가 관리하는 docker 데몬에 의해 실행되었습니다"라고 문맥을 짚어줍니다. 심지어 현재 실행 중인 디렉터리(Working Dir)와, 만약 그 디렉터리가 Git 저장소라면 현재 어떤 브랜치(Git Repo)에 있는지까지 알려줍니다. 배포 스크립트가 꼬여서 옛날 브랜치 코드가 몰래 돌아가고 있을 때, 이걸로 잡으면 정말 속이 시원합니다.

제가 겪었던 실제 사례를 하나 말씀드리면, 운영 서버에서 메모리 누수가 의심되는 Node.js 프로세스가 하나 있었습니다. ps로 봤을 때는 그냥 평범한 앱 인스턴스처럼 보였는데, witr로 찍어보니 Source : interactive shell이라고 뜨더군요. 알고 보니 며칠 전 동료 개발자가 디버깅하려고 터미널에서 직접 띄워놓고 끄는 걸 깜빡한 프로세스였습니다. 만약 이 도구가 없었다면 배포 파이프라인이나 PM2 설정을 뒤지느라 아까운 시간을 허비했을 겁니다.

사용법도 굉장히 직관적입니다. PID를 직접 넣어도 되고, 프로세스 이름(예: witr nginx)이나 포트 번호로 조회할 수도 있습니다. 설치도 별도의 복잡한 설정 없이 바이너리만 있으면 바로 동작합니다. 서버에 부담을 주지 않는 읽기 전용(Read-only) 도구라서 운영 환경에서 돌려보는 것도 크게 부담스럽지 않습니다.

물론 witr가 만능은 아닙니다. 모니터링 도구도 아니고, 문제를 자동으로 고쳐주지도 않습니다. 하지만 복잡한 리눅스 프로세스 트리 속에서 길을 잃었을 때, 나침반처럼 "여기가 시작점이야"라고 알려주는 역할은 톡톡히 해냅니다. 특히 컨테이너, 수동 실행, 서비스 데몬이 뒤섞인 복잡한 개발 서버를 정리할 때 이만한 도구가 없습니다.

개발자의 시간은 소중합니다. 쉘 명령어 조합하느라 뇌 리소스를 낭비하지 마시고, 이런 똑똑한 도구의 도움을 받아보세요. 여러분의 퇴근 시간이 조금이라도 빨라지길 바라며, 오늘도 터미널 앞에서 고군분투하는 모든 분을 응원합니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.