우분투 22.04부터는 ifconfig나 netstat을 기본 설치 상태에서 입력하면 “command not found”가 뜹니다. net-tools 패키지가 최소 설치 목록에서 아예 빠졌기 때문인데, 반면 이 자리를 대체한 iproute2 패키지의 ip, ss 명령어는 리눅스 커널 2.2 시절부터 존재했지만 최근 들어서야 사실상 표준으로 자리 잡았어요. 그렇다면 연결이 갑자기 끊겼을 때, ip·ss·curl·dig 같은 현대 도구로는 정확히 뭐부터 확인해야 할까요?
왜 ifconfig와 netstat은 deprecated 취급을 받을까?
net-tools 패키지는 1990년대 후반 이후로 사실상 개발이 멈춘 도구 모음이에요. 마지막 정식 릴리스가 2001년 즈음에 머물러 있다 보니, VLAN 태깅이나 네트워크 네임스페이스처럼 이후 커널에 추가된 기능을 ifconfig가 아예 인식하지 못하는 상황이 생겨요. 반면 iproute2는 리눅스 커널과 나란히 관리되면서 새 커널 기능이 추가될 때마다 명령어도 같이 업데이트되기 때문에, 데비안·RHEL·아치 계열을 가리지 않고 최근 배포판들은 iproute2를 기본으로 깔고 net-tools는 선택 설치로 돌려놨어요. 결국 도구가 낡아서 못 쓰는 게 아니라, 더 이상 유지보수되지 않는 도구에 의존할 이유가 없어졌다는 쪽이 더 정확한 설명이에요.
ip 명령어는 인터페이스와 라우팅을 어떻게 대체할까?
ip는 인터페이스 조회, IP 주소 관리, 라우팅 테이블 확인을 하나의 명령어 아래 서브커맨드로 묶어서 처리해요. ifconfig가 인터페이스 하나마다 여러 줄을 출력하며 정보를 흩어놓았다면, ip addr show는 같은 정보를 더 정돈된 형태로 보여주면서 서브 인터페이스나 가상 브리지까지 빠짐없이 표시해줘요.
ip addr show # 인터페이스별 IP 주소 확인
ip route show # 라우팅 테이블과 기본 게이트웨이 확인
ip link set eth0 up # 인터페이스 활성화여기서 끝이 아니에요. ip route로 확인하는 라우팅 테이블은 연결 장애의 절반 이상을 설명해주는데, 기본 게이트웨이 항목이 아예 없거나 엉뚱한 인터페이스를 가리키고 있다면 그 시점에서 이미 원인의 대부분을 좁힌 셈이에요.
ss는 netstat과 비교해 무엇이 근본적으로 다를까?
ss는 커널의 netlink 소켓 인터페이스에 직접 질의해서 정보를 가져오는 반면, netstat은 /proc/net 아래 텍스트 파일을 파싱하는 훨씬 느린 경로를 거쳐요. 연결 수가 수천 개를 넘는 운영 서버에서는 이 차이가 체감될 정도로 벌어지고, 그래서 실무에서는 netstat -tulnp 대신 ss -tulnp가 사실상 표준 조합으로 자리 잡았어요.
ss -tulnp # 열려 있는 TCP/UDP 포트와 프로세스 확인
ss -s # 전체 소켓 상태 요약포트가 열려 있어야 할 서비스가 안 뜬다면 ss -tulnp 한 줄로 프로세스가 애초에 그 포트를 리슨하고 있는지부터 확인하는 게 순서예요. 방화벽 규칙을 아무리 뜯어봐도, 서비스 자체가 안 떠 있으면 애초에 막을 트래픽도 없는 셈이니까요. 참고로 포트를 열어둬도 ufw나 firewalld 같은 방화벽이 앞단에서 막고 있으면 외부에서는 여전히 접속이 안 되니, ss로 리슨 여부를 확인한 다음에는 방화벽 규칙도 함께 점검해야 해요.
curl과 dig는 어느 계층의 문제를 구분해줄까?
curl은 HTTP/HTTPS 응답이 실제로 오는지를, dig는 도메인 이름이 IP로 제대로 변환되는지를 각각 확인해서 장애가 애플리케이션 계층 문제인지 DNS 문제인지를 갈라줘요. 흔히 겪는 오해 중 하나가 “핑이 안 되니 서버가 죽었다”인데, 많은 서비스 제공자와 방화벽이 ICMP 패킷만 정책적으로 차단해 두기 때문에 ping 실패와 실제 서비스 장애는 별개인 경우가 많아요.
dig example.com # 도메인의 A 레코드와 TTL, 사용된 DNS 서버 확인
curl -I https://example.com # HTTP 응답 코드와 헤더만 빠르게 확인dig로 IP는 잘 나오는데 curl 응답이 타임아웃이라면 문제는 DNS가 아니라 대상 서버나 그 사이 네트워크 구간에 있는 거고, 반대로 dig 자체가 응답 없음이면 이름 해석 단계에서부터 막힌 거예요. 이 구분만 되어도 다음에 뭘 확인해야 할지가 명확해진다는 게 이 두 명령어의 진짜 가치예요.
연결이 안 될 때 실제로는 어떤 순서로 확인해야 할까?
연결 장애 진단은 계층을 아래에서 위로 하나씩 좁혀나가는 순서로 진행하는 게 가장 효율적이에요. 먼저 ip addr과 ip route로 내 쪽 네트워크 설정(IP, 게이트웨이)이 정상인지 보고, 그다음 ss -tulnp로 필요한 서비스가 실제로 포트를 열고 있는지 확인해요. 이후 dig로 도메인이 올바른 IP로 풀리는지 보고, 마지막으로 curl로 실제 응답이 오는지, 오지 않는다면 traceroute로 어느 구간에서 패킷이 끊기는지를 살펴보는 흐름이에요. 이 순서를 지키면 “일단 재부팅해본다” 같은 막연한 대응 대신, 내 장비 → 로컬 서비스 → 이름 해석 → 원격 서버 순으로 원인을 정확히 좁혀갈 수 있어요.
이 진단 흐름은 클라우드의 ARM 서버든 온프레미스 x86 서버든 아키텍처와 무관하게 그대로 적용되는데, 결국 명령어 자체보다 이 순서를 몸에 익혀두는 쪽이 훨씬 오래 써먹을 수 있는 습관이에요.
그래서 뭐부터 손에 익혀야 할까?
당장 오늘부터 쓸 도구를 하나만 고른다면 ip와 ss 두 개만으로도 일상적인 서버 점검의 대부분이 해결돼요. 여기에 도메인이 걸린 서비스를 운영한다면 dig를, 외부 API나 웹 서비스 연동이 잦다면 curl을 순서대로 익혀두면 충분해요. ifconfig를 여전히 습관처럼 치고 있었다면, 이제는 명령어 하나 바꾸는 것만으로도 훨씬 최신 정보를 훨씬 빠르게 볼 수 있다는 뜻이니 오늘부터 ip로 바꿔보는 게 어떨까요.
자주 묻는 질문
Q1. ifconfig와 netstat은 이제 아예 쓸 수 없나요?
대부분의 배포판에서 net-tools 패키지를 별도로 설치하면 여전히 실행은 되지만, 커널 개발 진영이 2001년부터 유지보수를 중단한 도구라 최신 네트워크 기능(가상 인터페이스, 정책 라우팅 등)을 제대로 보여주지 못해요.
Q2. ip와 ss 중 뭐부터 배워야 하나요?
인터페이스와 IP 주소부터 확인해야 하는 경우가 많으니 ip addr을 먼저 익히고, 그다음 어떤 프로세스가 어떤 포트를 열고 있는지 볼 때 ss로 넘어가는 순서가 자연스러워요.
Q3. ss는 netstat보다 왜 빠른가요?
netstat이 /proc 파일시스템 전체를 훑어 소켓 정보를 수집하는 반면, ss는 커널의 netlink 인터페이스로 직접 질의해서 정보를 가져오기 때문에 연결 수가 많은 서버에서 속도 차이가 크게 벌어져요.
Q4. 핑(ping)은 안 되는데 웹사이트는 열리는 경우도 있나요?
네, 많은 서버와 방화벽이 ICMP 패킷만 별도로 차단해 두기 때문에 ping 실패가 곧 서비스 장애를 의미하지는 않고, curl이나 dig로 실제 서비스 계층을 따로 확인해야 해요.
Q5. dig 대신 nslookup을 써도 되나요?
간단한 조회라면 nslookup도 동작하지만 dig가 TTL, 각 레코드 타입, 질의에 사용된 DNS 서버까지 더 상세하게 보여줘서 실무 진단에는 dig가 표준처럼 쓰여요.
Q6. traceroute 결과에서 중간 구간이 별표(*)로만 나오면 문제가 있는 건가요?
아니요, 일부 라우터가 ICMP 응답 자체를 정책적으로 차단해 두는 경우가 흔해서 별표만으로 장애를 단정할 수는 없고, 마지막 홉까지 도달하는지가 더 중요한 판단 기준이에요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.