witr 딥다이브
— "이거 왜 돌고 있지?"를 한 명령으로 역추적하는 프로세스 계보 추적기

1프로젝트 한 줄 요약

witr(Why Is This Running)는 시스템 위에서 뭔가가 돌고 있을 때 "그게 무엇인가"가 아니라 "그게 왜 거기 있는가"를 답한다. 대상은 네 가지 형태로 지정할 수 있다 — 프로세스 이름·PID, 네트워크 포트, 열린 파일, 컨테이너. witr는 그 대상을 우선 하나의 PID로 환원한 뒤, 그 PID의 부모의 부모의 부모…를 PID 1(init)까지 거슬러 올라가 "누가 이걸 낳았는지"의 족보를 만든다.

표준 출력은 이렇게 생겼다. 대상(node)이 무엇인지, 언제 시작됐는지, 그리고 Why It Exists 줄에 인과 사슬이 그대로 찍힌다.

Target      : node
Process     : node (pid 14233)
User        : pm2
Command     : node index.js
Started     : 2 days ago (Mon 2026-02-02 11:42:10 +05:30)

Why It Exists :
  systemd (pid 1) → pm2 (pid 5034) → node (pid 14233)

Source      : pm2
Working Dir : /opt/apps/expense-manager
Git Repo    : expense-manager (main)
Sockets     : 127.0.0.1:5001 (TCP | LISTENING)

설계 철학은 한 문장으로 요약된다 — "모든 것을 프로세스 질문으로 취급하라(treat everything as a process question)". 포트든 파일이든 컨테이너든 결국 PID로 환원되고, PID만 정해지면 나머지(계보·근원·경고)는 같은 파이프라인으로 처리된다. 이 단순한 환원이 witr의 코드 구조 전체를 지탱한다.

2왜 지금 주목받는가

witr가 8개월 만에 별 2만 개를 모은 건 대단한 신기술이라서가 아니다. "이 포트 누가 쓰지?", "이 좀비는 왜 안 죽지?" 같은, 개발자라면 매주 겪는 통증을 명령 한 줄로 끝내 주기 때문이다. 여기에 배포·마케팅 완성도가 붙어 폭발했다.

① 누구나 겪는 문제를 정면으로 푼다

"8080 포트가 이미 쓰이고 있습니다"라는 에러를 보고 lsof -i :8080 → PID 확인 → ps -ef | grep → 부모 추적… 하던 3~4단계를 witr --port 8080 한 줄로 대체한다. 정체불명의 프로세스, 되살아나는 서비스, 누가 잡고 있는지 모를 파일 락 — 전부 같은 방식으로 근원을 짚는다.

② 4개 OS 네이티브 + 8개 컨테이너 런타임

리눅스 전용 /proc 트릭에 머물지 않고 macOS·Windows·FreeBSD까지 각 OS의 네이티브 방식으로 지원한다. 컨테이너도 Docker 하나가 아니라 Podman·nerdctl·CRI(crictl)·Incus·LXC·LXD·FreeBSD jail까지 8종을 인식해, 컨테이너 안 프로세스의 계보를 호스트 관점에서 이어 준다.

③ 설치 없이 브라우저에서 체험

공식 사이트(pranshuparmar.github.io/witr)는 witr의 출력 계층을 JavaScript로 충실히 재구현한 인터랙티브 플레이그라운드다. 실제 바이너리가 찍을 바이트(ANSI 색 코드까지)를 그대로 브라우저에서 보여준다. "설치부터 하고 판단"이 아니라 "먼저 만져 보고 결정"하게 만드는 이 훅이 유입을 크게 키웠다.

④ 배포와 스크립트 친화성

Homebrew·apt·conda·AUR·winget·npm·nix·scoop·choco 등 20종이 넘는 패키지 매니저에 등재돼 있어 "어떻게 깔지" 고민이 없다. 게다가 종료 코드(exit code)가 의미를 갖는다 — 정상 0, 경고 1, 못 찾음 2, 권한 부족 3… 그래서 CI·헬스체크 스크립트에 그대로 물릴 수 있다.

3기술 스택 전체 지도

witr는 Go 100%다(go 1.25). 놀라운 점은 의존성이 겨우 9개라는 것 — 프로세스·네트워크·컨테이너를 들여다보는 핵심 로직은 gopsutil 같은 범용 라이브러리에 기대지 않고 전부 자체 구현했다. 외부 의존성은 "화면 그리기"와 "systemd 대화"에만 쓴다. 그래서 이 저장소는 시스템 프로그래밍을 날것으로 배우기에 대단히 좋은 교재가 된다.

CLI · TUI 계층 (Charm 생태계)

시스템 대화 계층

빌드 · 배포 도구

크로스컴파일과 패키징은 GoReleaser가 맡는다(4 OS × 2 아키텍처, .deb/.rpm/.apk 생성, SHA256 체크섬). Nix flake로 재현 가능한 빌드를 제공하고, golangci-lint로 정적 분석, //go:generate로 man 페이지·마크다운 문서를 소스에서 자동 생성한다. CGO_ENABLED=0 정적 링크라 실행에 별도 런타임이 필요 없다.

4아키텍처 심화 분석

witr의 데이터 흐름은 네 정거장을 지난다. 사용자가 준 대상(이름·포트·파일·컨테이너)을 ①PID로 해석하고, 그 PID를 ②계보(ancestry)로 역추적하고, 계보를 훑어 ③근원(source)을 판별한 뒤, ④출력 렌더러가 표준/짧게/트리/JSON 중 하나로 찍는다.

핵심 알고리즘 ① — 계보 역추적 (internal/proc/ancestry.go)

witr의 심장이다. 대상 PID에서 시작해 부모 PID(PPID)를 따라 위로 걸어 올라가며 사슬을 쌓고, 순환을 막으려 방문한 PID를 seen 맵에 기록한다. PID 1이나 PPID 0에 닿으면 멈추고, 마지막에 사슬을 뒤집어 "뿌리(init)가 맨 앞"에 오게 만든다.

func ResolveAncestry(pid int) ([]model.Process, error) {
    var chain []model.Process
    seen := make(map[int]bool)
    current := pid
    for current > 0 {
        if seen[current] { break }        // 순환 방지
        seen[current] = true
        p, err := ReadProcess(current)     // OS별 구현 (리눅스: /proc 파싱)
        if err != nil { break }
        chain = append(chain, p)
        if p.PPID == 0 || p.PID == 1 { break }
        current = p.PPID
    }
    // 뿌리가 앞에 오도록 뒤집기
    for i, j := 0, len(chain)-1; i < j; i, j = i+1, j-1 {
        chain[i], chain[j] = chain[j], chain[i]
    }
    return chain, nil
}

핵심 알고리즘 ② — 한 프로세스 읽기 (process_linux.go)

리눅스에서 한 PID의 모든 정보를 /proc/<pid>/ 아래 파일에서 직접 읽는다. 읽는 중 프로세스가 사라지는 경합(TOCTOU)을 의식해 stat을 먼저 잡는다. 주요 소스는 아래와 같다.

핵심 알고리즘 ③ — "왜"의 정체 판별 (internal/source/detect.go)

역추적한 계보를 받아 우선순위 순서로 검사해 단 하나의 근원을 고른다. 검사 순서가 곧 정책이다 — 컨테이너가 가장 강한 맥락이고, 그 다음이 원격 접속, 셸, 서비스 매니저 순이다.

func Detect(ancestry []model.Process) model.Source {
    if s := detectContainer(ancestry); s != nil { return *s }  // 1. 컨테이너
    if s := detectSSH(ancestry);       s != nil { return *s }  // 2. SSH 세션
    if s := detectShell(ancestry);     s != nil { return *s }  // 3. 대화형 셸/유저툴
    if s := detectSystemd(ancestry);   s != nil { return *s }  // 4. systemd
    if s := detectLaunchd(ancestry);   s != nil { return *s }  // 5. launchd(macOS)
    if s := detectBsdRc(ancestry);     s != nil { return *s }  // 6. rc.d(FreeBSD)
    if s := detectSupervisor(ancestry);s != nil { return *s }  // 7. pm2/supervisord
    if s := detectCron(ancestry);      s != nil { return *s }  // 8. cron
    if s := detectWindowsService(ancestry); s != nil { return *s } // 9. Win 서비스
    if s := detectInit(ancestry);      s != nil { return *s }  // 10. PID1 총괄
    return model.Source{Type: model.SourceUnknown}
}

각 판별기는 계보에서 단서를 캔다. detectSSH는 사슬에 sshd가 있고 환경변수 SSH_CLIENT가 있으면 원격 IP·TTY를 뽑아 "SSH session from 1.2.3.4"로 만든다. detectSystemd는 cgroup에서 유닛명을 공짜로 얻은 뒤 D-Bus로 재시작 횟수·타이머 스케줄까지 보강한다(예전엔 systemctl show를 매번 fork했는데 단일 D-Bus 연결로 대체해 성능을 개선한 흔적이 코드에 남아 있다).

핵심 알고리즘 ④ — 포트에서 PID 찾기 (net_linux.go)

포트→PID는 두 단계다. 먼저 /proc/net/tcp를 파싱해 해당 포트와 일치하는 소켓의 inode를 모으고(포트는 4자리 16진수로 인코딩돼 있다), 그다음 /proc/*/fd/* 심볼릭 링크를 전부 훑어 socket:[inode]를 가진 PID를 찾는다.

targetHex := fmt.Sprintf("%04X", port)   // 포트를 4자리 대문자 16진수로
// /proc/net/tcp 한 줄:  fields[1]="로컬IP:PORT"(hex), fields[3]=상태, fields[9]=inode
if state == "0A" /* TCP_LISTEN */ && localParts[1] == targetHex {
    inodes[fields[9]] = true              // 이 포트를 LISTEN 중인 소켓 inode 수집
}
// 이후 /proc/<pid>/fd 의 각 심링크를 readlink → "socket:[inode]" 대조 → PID 확정

이 소켓 테이블은 2초 TTL 캐시로 감싸 계보를 훑는 동안 반복 파싱을 피한다. IPv6는 /proc/net/tcp6가 리틀엔디언 워드로 저장하므로 바이트 재배열이 필요하고, :: 리스너가 IPv4까지 받는 듀얼스택 상황도 합성해 보여준다.

크로스플랫폼 전략 — 같은 인터페이스, OS별 4벌 구현

이 저장소의 가장 큰 학습 포인트다. ReadProcess·ResolvePort 같은 동일한 함수를 Go 빌드 태그(//go:build linux 등)로 OS별 파일에 각각 구현했다. internal/proc/ 한 폴더 안에 process_linux.go·process_darwin.go·process_windows.go·process_freebsd.go 네 벌이 공존한다.

특히 Windows는 PowerShell·WMI를 피하고(hang·느린 시작 회피) golang.org/x/sys/windows로 순수 Win32 API를 직접 호출한다. 지원하지 않는 OS에서는 unsupported.go가 안내 메시지를 찍고 종료한다.

CLI 대 TUI — 하나의 바이너리, 두 얼굴

app.go가 모드를 가른다. 대상 인자가 있으면 cobra 기반 CLI 1회 실행(결과를 찍고 의미 있는 종료 코드 반환), 인자가 없거나 -i면 Bubble Tea TUI가 뜬다. TUI는 Processes/Ports/Containers/Locks 네 탭을 table 위젯으로 보여주고, 3초에서 시작해 부하에 따라 간격을 늘리는 적응형 자동 새로고침, 마우스·정렬·검색, 그리고 유닉스에서는 프로세스에 시그널을 보내는 액션(KILL/TERM/STOP/CONT/renice)까지 지원한다.

5디렉토리 구조 해부

internal/과 pkg/의 구분이 핵심이다. Go는 internal/ 아래 코드를 외부 모듈이 import하지 못하도록 언어 차원에서 막는다. witr는 앱의 구현 전부를 internal/에 숨기고, 재사용할 가치가 있는 순수 데이터 타입만 pkg/model/에 공개했다. "이건 우리 앱 내부 사정, 이건 남들이 써도 되는 계약"을 폴더로 못 박은 셈이다. 실제 코드량이 가장 많은 곳은 internal/proc/ — OS별 4벌 구현이 몰려 있는 이 도구의 심장이다.

6학습 포인트

witr는 "터미널 도구를 어떻게 만드는가"의 모범 답안이자, 리눅스가 프로세스·네트워크를 어떻게 노출하는지 배우는 실물 교재다. 배울 것을 계층별로 정리하면 이렇다.

① /proc 파일시스템으로 OS 들여다보기

리눅스는 커널 내부 상태를 /proc라는 가짜 파일시스템으로 노출한다. witr가 읽는 /proc/<pid>/stat·cmdline·cgroup·fd와 /proc/net/tcp는 ps·ss·lsof가 내부에서 하는 일과 정확히 같다. 이 도구들의 "마법"이 사실은 텍스트 파일 파싱임을 몸으로 이해하게 된다.

② 프로세스 트리와 PPID

모든 프로세스는 부모를 갖고, 부모가 먼저 죽으면 자식은 PID 1(init/systemd)에 입양(reparenting)된다. witr의 계보 역추적은 이 트리를 거꾸로 오르는 것 — 트리 자료구조·재귀·순환 방지가 실제 문제에 쓰이는 사례다.

③ 소켓 inode ↔ 파일 디스크립터 매핑

"어떤 프로세스가 이 포트를 쓰나"의 답은 /proc/net/tcp의 소켓 inode와 /proc/*/fd의 socket:[inode] 링크를 이어 붙이는 것이다. TCP 상태 머신(LISTEN/ESTABLISHED/TIME_WAIT), 16진수 인코딩, IPv6 바이트 순서까지 — 네트워크의 밑바닥을 실습으로 배운다.

④ Go의 크로스플랫폼 추상화

빌드 태그 + 파일명 규칙(_linux.go/_darwin.go)으로 같은 인터페이스를 OS별로 구현하는 방식은 Go 크로스플랫폼 코드의 정석이다. #ifdef 없이 파일 단위로 분기하는 이 패턴은 그대로 자기 프로젝트에 옮겨 쓸 수 있다.

⑤ 현대적 CLI/TUI 만들기 (cobra + Bubble Tea)

cobra로 서브명령·플래그·자동완성을, Bubble Tea의 Elm 아키텍처(Model/Update/View)로 상태 기반 TUI를 짜는 법을 실전 규모로 볼 수 있다. lipgloss의 배경 밝기 적응, bubbles의 table/viewport 조합도 좋은 참고가 된다.

⑥ 적대적 입력을 렌더링하는 보안 감각

output/sanitize.go는 프로세스 이름·명령행에 숨은 악성 ANSI 이스케이프를 무력화한다. 신뢰할 수 없는 데이터(남이 띄운 프로세스의 메타데이터)를 터미널에 그릴 때 반드시 필요한 방어 — 로그 뷰어·모니터링 도구를 만들 때 놓치기 쉬운 포인트를 정확히 짚는다.

7하드웨어 / 시스템 요구사항

witr는 CGO_ENABLED=0으로 정적 링크된 바이너리 파일 하나다(수 MB). 런타임 의존성도, 특별한 하드웨어도 필요 없다. 다만 두 가지를 알아야 한다 — 남의 프로세스를 자세히 보려면 권한이 필요하고, 기능은 OS마다 다르다.

자주 쓰는 CLI 형태

witr <이름>(이름으로), witr --port 8080(포트로), witr --file /var/log/app.log(파일로), witr --container myapp(컨테이너로). 출력 스위치는 -s 짧게(한 줄), -t 트리, --json JSON, --warnings 경고만, --verbose 상세, -x 정확히 일치, -i 인터랙티브 TUI.

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크