ss vs netstat: Linux 포트 명령어, 무엇을 쓸까

ss를 쓰세요 — 모든 요즘 리눅스 배포판의 현재 표준이고, netstat는 거기서는 레거시입니다. Ubuntu, Fedora, Debian에서 netstat 바이너리는 이제 선택 패키지 net-tools에 들어 있고, ss는 iproute2에 내장되어 어디에나 설치돼 있습니다. 바쁜 서버에서 ss가 더 빠른 이유도 단순합니다 — /proc를 파일 하나씩 훑지 않고 커널에서 소켓 통계를 직접 읽기 때문입니다. 발목을 잡는 건 문법입니다: -tulpn이 모든 곳에서 같은 뜻은 아니므로, 이 글은 정확한 플래그 매핑과 외워둘 명령, 그리고 새벽 2시 장애 대응 중에 떠오르는 질문들의 답을 담았습니다.

netstat는 deprecated된 건가?

리눅스에서는 사실상 그렇습니다. netstat, ifconfig, route가 들어 있는 net-tools 패키지는 몇 년째 최신 커널 기능을 따라가지 못하고 있고, 어느 주요 배포판에도 기본 설치되지 않습니다. 여전히 존재하고, 여전히 실행되고, 언인스톨할 것도 없습니다. 하지만 새 기능은 iproute2(ss와 ip의 배후 패키지)에만 들어갑니다.

실무에서 체감되는 결과 셋:

1. 새 설치에는 없다. 기본 상태의 Ubuntu 24.04나 Fedora 서버에는 net-tools를 손으로 설치하기 전까지 netstat가 없습니다. 수많은 사람이 netstat 대체재를 검색하는 이유가 이것입니다 — 바이너리가 그냥 없는 겁니다.
2. 최신 소켓 정보가 없다. netstat는 TCP fast open, 서브플로 단위 소켓 통계, cgroup 소켓 귀속 같은 기능 이전의 도구입니다. ss는 이를 기본으로 보고합니다.
3. Windows는 예외다. Windows에서 netstat는 멀쩡히 살아 있습니다 — netstat -ano는 지금도 그쪽에서 PID와 리스닝 포트를 연결하는 표준 방법입니다. deprecation 이야기는 리눅스에만 해당합니다.

Linux의 ss 명령은 무엇인가?

ss는 “socket statistics”입니다. 모든 TCP, UDP, Unix 소켓에 대한 커널의 시점을 덤프합니다: 상태, 주소, 포트, 프로세스, 타이머, 큐 깊이까지. 실무의 주력 형태는 다음과 같습니다:

# 모든 리스닝 소켓 + 점유 프로세스까지
sudo ss -tulpn

플래그를 하나씩 풀면: TCP(-t), UDP(-u), 리스닝 소켓만(-l), 프로세스 표시(-p), 숫자 출력 — DNS 조회 없음(-n). -p에는 sudo가 중요합니다: root가 아니면 포트는 보여도 자신이 소유하지 않은 소켓의 프로세스 이름은 얻지 못합니다.

업무 대부분을 커버하는 원라이너 둘 더:

# 443 포트와 주고받는 모든 ESTABLISHED 연결 + 프로세스
sudo ss -tnp 'sport = :443 or dport = :443'

# 요약 테이블: 상태별 소켓 수
ss -s

이 필터 문법은 netstat의 “grep에게 맡기고 기도하기” 방식에 비해 진짜 업그레이드입니다 — 커널 안에서 실행되므로 텍스트 매칭이 아니라 정확한 조건입니다.

포트를 점유 중인 프로세스는 어떻게 확인하나?

두 도구를 집어 드는 가장 흔한 이유 하나짜리입니다. ss로는:

sudo ss -ltnp 'sport = :8080'

개발 서버가 돌고 있는 머신의 출력 예:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

users:(...) 필드가 프로세스 이름과 PID를 바로 줍니다 — 두 번째 명령이 필요 없습니다. 포트는 바쁜데 프로세스가 안 보이면, 보통 다른 네트워크 네임스페이스(컨테이너)가 잡고 있는 소켓입니다. 호스트에서 sudo ss -ltnp를 실행해 프로세스 열이 빈 포트를 찾고, docker ps로 대조하거나 nsenter로 컨테이너 네임스페이스에 들어가 보세요.

전용 도구를 선호한다면? sudo lsof -i :8080 -sTCP:LISTEN이 같은 일을 하고, macOS와 대부분의 BSD에서도 동일하게 동작합니다 — 런북에 살아남은 이유입니다. 다만 리눅스에서는 ss가 이미 그 자리에 있습니다.

ss와 netstat의 차이는 무엇인가?

같은 일, 다른 배관: netstat는 사용자 공간에서 /proc/net/tcp를 긁어 모으고, ss는 netlink로 커널에 직접 묻습니다. 그래서 소켓 5만 개가 열린 서버에서 ss는 밀리초 단위로 돌아오고 netstat는 그렇지 못합니다. 일상에서 차이는 플래그입니다. 모니터에 붙여둘 만한 매핑:

하고 싶은 것	netstat	ss
리스닝 TCP 포트 + 프로세스	netstat -tlpn	ss -tlpn
전체 TCP + UDP 연결	netstat -tulpna	ss -tulpna
라우팅 테이블	netstat -r	ip route
인터페이스 통계	netstat -i	ip -s link
커널 소켓 요약	—	ss -s
포트 기준 커널 필터링	—	ss -tnp 'sport = :22'

첫 두 줄이 똑같다는 데 주목하세요: 운 좋게도 ss의 짧은 플래그는 흔한 경우 netstat의 것과 겹치므로, 손근육의 기억은 대부분 이주를 살아남습니다. 아래쪽 줄이 netstat에 답이 없는 영역입니다 — 라우팅과 인터페이스 업무는 ip 명령으로 옮겨갔고, 요약/필터 줄은 ss에만 존재합니다.

그래도 netstat를 써야 할 때는?

솔직한 경우는 둘입니다. 첫째, 이식성: Linux, AIX, 오래된 BSD가 섞인 플릿이라면 netstat가 유일하게 모든 곳에 있는 문법입니다. 둘째, 오래된 런북의 손근육 연속성 — 런북이 netstat -tlpn이라 쓰고 박스에 net-tools가 설치돼 있다면, 여전히 잘 동작합니다.

그 외에는 기본값을 ss로 잡고 런북을 갱신하세요. 서버에서 런북을 고쳐 쓸 때 짝이 되어 주는 건 journalctl 치트시트입니다 — 시작하지 않는 서비스를 진단할 때 포트 확인과 자연스럽게 이어집니다: /en/blog/2026-09-02/journalctl-cheat-sheet.

ss: command not found가 뜨는 이유는?

당신이 아주 오래된 배포판(2007년 이전, iproute2가 표준이 되기 전)을 쓰고 있거나 — 훨씬 가능성 높게 — 애초에 리눅스가 아니기 때문입니다. ss는 macOS 명령이 아닙니다; macOS는 lsof와 netstat는 있어도 ss는 없습니다. BSD도 대부분 마찬가지입니다. Windows라면 netstat -ano나 PowerShell의 Get-NetTCPConnection을 쓰세요.

진짜 리눅스인데 ss가 없다면 iproute2를 설치합니다:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

30초 요약

리눅스에서는 매번 netstat보다 ss: 미리 설치돼 있고, 더 빠르고, 커널 안에서 필터링할 수 있습니다. netstat -tlpn은 ss -tlpn으로, 프로세스 추적은 sudo ss -ltnp 'sport = :PORT'로, 라우팅 테이블은 이제 ip route의 영역입니다. netstat는 크로스 플랫폼 스크립트와 오래된 손근육을 위해 남겨두고, 플래그 매핑은 이 페이지를 남겨두세요.