왜 순서가 필요한가
인터넷이 안 될 때 가장 흔한 실수는 바로 결론부터 내리는 것이다.
"공유기가 고장 났나?" "통신사 문제인가?" "DNS가 이상한가?" "서버가 죽었나?"
이 추측들은 모두 가능하다. 하지만 처음부터 하나를 찍으면 시간이 오래 걸린다. 인터넷은 여러 층이 쌓인 구조이기 때문이다. 아래층에서 막혔는데 위층만 계속 고치면 문제는 그대로 남는다.
도로에 비유하면 이렇다. 택배가 도착하지 않았을 때는 먼저 집 문이 잠겼는지, 골목길이 막혔는지, 고속도로가 끊겼는지, 주소가 틀렸는지, 받는 사람이 부재중인지 차례로 확인해야 한다. 받는 사람이 부재중인지부터 확인한다고 해서 막힌 골목길이 뚫리지는 않는다.
인터넷도 같다. 문제를 고치는 기본 순서는 가까운 곳에서 먼 곳으로, 아래에서 위로 올라가는 것이다.
케이블과 와이파이
내 IP 주소
게이트웨이
바깥 IP 주소
DNS
웹 서버와 서비스
이 순서를 몸에 익히면 "인터넷이 안 된다"는 막연한 말이 "DNS에서 막힌다", "게이트웨이 밖으로 못 나간다", "서버의 443번 포트에서 실패한다"처럼 구체적인 문장으로 바뀐다. 고치는 힘은 이 구체적인 문장에서 나온다.
AI 생성 이미지
1단계: 길이 실제로 열려 있는지 본다
가장 먼저 볼 것은 물리적인 길이다. 랜 케이블이 꽂혀 있는지, 와이파이에 연결되어 있는지, 신호가 너무 약하지 않은지 확인한다.
이 단계는 너무 단순해 보여서 자주 건너뛴다. 그러나 인터넷의 가장 아래에는 비트가 지나가는 길이 있다. 케이블이 빠져 있거나 와이파이가 끊겨 있으면 IP 주소, DNS, 웹 서버는 아직 등장할 차례가 아니다.
확인할 것은 다음과 같다.
유선 연결이라면 케이블이 컴퓨터와 스위치 또는 공유기에 제대로 꽂혀 있는가
다른 케이블이나 다른 포트에 꽂아도 같은 증상이 나는가
와이파이라면 올바른 무선 네트워크에 붙어 있는가
신호가 매우 약하거나 중간에 자주 끊기지는 않는가
네트워크 인터페이스가 꺼져 있지는 않은가
여기서 보는 것은 "내 컴퓨터가 네트워크 문을 열었는가"이다. 아직 목적지가 어디인지 묻는 단계가 아니다.
2단계: 내 주소가 제대로 있는지 본다
길이 열려 있다면 다음은 내 IP 주소를 본다. IP 주소는 인터넷에서 목적지를 찾기 위한 위치 단서다. 우편물을 받으려면 집 주소가 필요하듯, 네트워크에 참여하려면 적절한 IP 주소가 필요하다.
특히 확인할 값은 네 가지다.
IP 주소
서브넷 마스크 또는 프리픽스 길이
게이트웨이 주소
DNS 서버 주소
집이나 작은 사무실에서는 보통 DHCP가 이 값을 자동으로 나누어 준다. DHCP는 새로 들어온 장치에게 "너는 이 주소를 쓰고, 밖으로 나갈 때는 이 문을 이용하고, 이름을 물어볼 때는 이 서버에 물어봐"라고 알려 주는 안내 데스크와 같다.
여기서 이상한 주소를 받으면 통신이 제대로 되지 않는다. 예를 들어 같은 네트워크가 192.168.0.x를 쓰는데 내 컴퓨터만 전혀 다른 대역의 주소를 가지고 있다면, 같은 방 안의 장치들과도 대화가 어려울 수 있다.
또 게이트웨이가 비어 있으면 같은 네트워크 안에서는 통신할 수 있어도 바깥 인터넷으로 나가지 못한다. 게이트웨이는 다른 네트워크로 나가는 출입문이기 때문이다. DNS 서버 주소가 비어 있거나 틀렸다면 숫자 IP 주소로는 나갈 수 있어도, 이름으로는 목적지를 찾지 못할 수 있다.
3단계: 게이트웨이까지 닿는지 본다
내 주소가 정상이라면 이제 가까운 출입문, 즉 게이트웨이에 닿는지 확인한다. 집에서는 보통 공유기가 게이트웨이다.
이때 자주 쓰는 도구가 ping이다. ping은 아주 짧은 확인용 메시지를 보내고 응답이 돌아오는지 보는 도구다. 비유하자면 복도 끝 관리실에 "거기 있나요?" 하고 물어본 뒤 "네, 있습니다"라는 대답이 돌아오는지 확인하는 것이다.
ping으로 게이트웨이에 응답이 온다면 적어도 다음은 알 수 있다.
내 장치의 네트워크 인터페이스가 동작한다
같은 네트워크 안에서 프레임이 오갈 수 있다
내 IP 설정과 게이트웨이 주소가 어느 정도 맞다
스위치나 와이파이 구간이 완전히 끊기지는 않았다
반대로 게이트웨이에 ping이 가지 않는다면 아직 바깥 인터넷을 볼 단계가 아니다. 이때는 케이블, 와이파이, IP 대역, 서브넷 마스크, 공유기 상태를 다시 봐야 한다.
주의할 점도 있다. 어떤 장비는 보안 때문에 ping 응답을 막을 수 있다. 그래서 ping 실패가 항상 장비 고장을 뜻하지는 않는다. 하지만 작은 네트워크를 고칠 때 게이트웨이 ping은 여전히 좋은 첫 확인 도구다. 실패했다면 "게이트웨이가 고장 났다"고 바로 결론 내리기보다, 그 구간을 더 자세히 보라는 신호로 받아들이면 된다.
4단계: 이름 말고 숫자 주소로 바깥에 나가 본다
게이트웨이까지 된다면 이제 바깥 IP 주소로 나가 본다. 이때는 도메인 이름이 아니라 숫자 IP 주소를 직접 사용한다.
왜 이름을 빼고 시험할까? DNS 문제와 경로 문제를 나누기 위해서다.
예를 들어 어떤 공인 IP 주소로는 통신이 되는데 example.com 같은 이름으로는 접속이 안 된다면, 길 자체는 열려 있을 가능성이 크다. 문제는 이름을 IP 주소로 바꾸는 DNS 쪽일 수 있다.
반대로 숫자 IP 주소로도 바깥에 나가지 못한다면 DNS를 보기 전에 라우팅, NAT, 방화벽, 통신사 회선 같은 경로 문제를 먼저 봐야 한다.
이 단계에서 유용한 도구가 traceroute이다. 운영체제에 따라 이름은 조금 다를 수 있지만 개념은 같다. traceroute는 목적지까지 가는 동안 어떤 라우터들을 지나가는지 한 단계씩 확인한다.
택배 추적 화면을 떠올리면 쉽다. "집하 완료 → 물류센터 도착 → 지역 터미널 이동 → 배송 중"처럼 중간 지점이 보인다. traceroute도 패킷이 지나가는 중간 라우터들을 보여 준다.
여기서 비유가 끝나는 지점도 분명히 해야 한다. 택배 추적은 택배 회사가 기록을 남겨 보여 주는 것이지만, traceroute는 IP 패킷의 TTL 값을 이용해 중간 라우터로부터 응답을 유도한다. 즉 인터넷 장비가 모두 친절하게 전체 지도를 알려 주는 것은 아니다. 어떤 구간은 응답하지 않거나 별표처럼 보일 수 있고, 실제 서비스 통신은 되는데 traceroute만 중간에 끊겨 보일 때도 있다.
그래도 traceroute는 "내 공유기 근처에서 막히는지", "통신사망 안쪽까지는 가는지", "멀리 있는 목적지 근처에서 멈추는지"를 가늠하게 해 준다.
5단계: DNS가 이름을 주소로 바꾸는지 본다
숫자 IP로는 되는데 이름으로 안 된다면 DNS를 확인한다.
DNS는 전화번호부와 비슷하다. 사람은 web.example.local 같은 이름을 기억하고, 컴퓨터는 192.168.20.10 같은 IP 주소로 찾아간다. DNS는 이 둘을 연결해 준다.
이때 쓰는 도구가 nslookup 또는 비슷한 DNS 조회 도구다. 이 도구는 "이 이름의 IP 주소가 무엇인가요?"라고 DNS 서버에 직접 물어본다.
DNS 점검에서 확인할 것은 다음과 같다.
내 컴퓨터가 어떤 DNS 서버를 사용하고 있는가
그 DNS 서버에 실제로 질의가 도착하는가
도메인 이름이 올바른 IP 주소로 응답되는가
예전 주소가 캐시에 남아 있지는 않은가
내부용 이름을 외부 DNS에 묻고 있지는 않은가
증상으로 보면 다음처럼 나눌 수 있다.
IP로는 되는데 이름으로는 안 됨
이 경우 DNS 서버 주소가 틀렸거나, DNS 서버가 응답하지 않거나, 해당 이름의 레코드가 없을 가능성이 크다.
어떤 사이트 이름만 안 됨
전체 DNS가 아니라 특정 도메인의 레코드, 권한 있는 DNS 서버, 캐시 문제일 수 있다.
방금 주소를 바꿨는데 여전히 예전 곳으로 감
DNS 캐시와 TTL을 봐야 한다. TTL은 "이 답을 얼마 동안 믿고 써도 되는가"를 정한 시간이다. 우체국 게시판에 붙은 임시 안내문처럼, 시간이 지나야 새 정보로 바뀔 수 있다.
다만 웹에서는 한 가지를 더 기억해야 한다. 숫자 IP 주소로 접속했을 때 단순한 연결 확인은 될 수 있지만, 실제 웹사이트는 도메인 이름을 기준으로 여러 사이트를 나누어 운영하기도 한다. 그래서 "IP로는 된다"는 말은 주로 길과 서버 연결이 되는지 확인했다는 뜻으로 이해하면 좋다. 최종적으로는 DNS가 올바른 이름을 올바른 주소로 바꾸는지까지 확인해야 한다.
6단계: 서비스가 실제로 응답하는지 본다
DNS까지 정상이라면 이제 목적지 서버의 서비스가 응답하는지 본다. 웹이라면 HTTP 또는 HTTPS 응답을 확인한다.
이때 유용한 도구가 curl이다. curl은 브라우저처럼 웹 서버에 요청을 보내고 응답을 확인하는 도구다. 다만 화면을 예쁘게 그리지 않고, 서버가 어떤 상태 코드와 내용을 돌려주는지 더 직접적으로 보여 준다.
브라우저는 많은 일을 한꺼번에 한다. DNS 조회, TCP 연결, TLS 확인, HTTP 요청, HTML 해석, 이미지와 스크립트 추가 요청까지 처리한다. 그래서 브라우저 화면만 보면 어느 단계에서 막혔는지 흐릿할 때가 있다.
curl을 사용하면 웹 대화의 핵심을 더 작게 볼 수 있다.
서버에 연결이 되는가
TCP 포트가 열려 있는가
HTTPS 인증서 문제는 없는가
HTTP 상태 코드가 무엇인가
서버가 본문을 돌려주는가
예를 들어 서버가 404를 돌려준다면 길은 열려 있지만 요청한 자원이 없다는 뜻이다. 500번대 응답은 서버 내부 처리에서 문제가 났을 가능성을 가리킨다. 연결 자체가 거부된다면 웹 서버 프로그램이 꺼져 있거나, 포트가 닫혀 있거나, 방화벽이 막고 있을 수 있다.
즉 "웹사이트가 안 열린다"는 말도 여러 종류로 나뉜다. 길이 없는 것, 이름을 못 찾는 것, 문은 닫힌 것, 문 안에서 오류가 난 것은 서로 다른 문제다.
증상으로 원인을 좁히는 법
이제 몇 가지 대표 증상을 순서대로 해석해 보자.
같은 네트워크는 되는데 밖은 안 됨
내 컴퓨터에서 같은 방의 다른 컴퓨터나 공유기에는 닿지만 인터넷 사이트에는 닿지 않는 경우다.
이때 의심할 곳은 게이트웨이 이후다. 게이트웨이 설정이 비어 있거나 틀렸을 수 있다. 공유기의 바깥쪽 연결이 끊겼을 수도 있다. NAT가 제대로 동작하지 않거나, 통신사 회선 문제가 있을 수도 있다.
먼저 게이트웨이 주소가 맞는지 보고, 게이트웨이에 닿는지 확인한다. 그다음 숫자 IP로 바깥에 나가 본다. 여기서 막히면 DNS가 아니라 경로 문제다.
IP로는 되는데 이름으로는 안 됨
숫자 IP 주소로 접속하면 되지만 도메인 이름으로는 안 되는 경우다.
이때는 DNS가 핵심 후보가 된다. 내 컴퓨터에 설정된 DNS 서버가 틀렸는지, DNS 서버까지 통신이 되는지, 이름에 대한 레코드가 있는지 확인한다.
작은 인터넷 실험에서는 이런 일이 자주 생긴다. 웹 서버는 192.168.20.10에서 잘 동작하는데, 클라이언트가 web.example.local을 모른다면 DNS 서버 설정이나 A 레코드를 봐야 한다.
이름도 주소도 맞는데 웹만 안 됨
DNS도 되고 서버 IP까지도 닿는데 웹페이지가 열리지 않는 경우가 있다.
이때는 포트와 서비스 계층을 본다. 웹 서버가 TCP 80번 또는 443번에서 기다리고 있는지, 방화벽이 해당 포트를 허용하는지, HTTPS 인증서가 올바른지 확인한다.
서버 컴퓨터 자체는 켜져 있어도 웹 서버 프로그램은 꺼져 있을 수 있다. 건물은 보이지만 가게 문이 닫힌 상태와 같다.
나만 안 되고 다른 사람은 됨
이 경우는 내 장치 쪽 문제일 가능성이 커진다. 내 와이파이 연결, IP 설정, DNS 캐시, 브라우저 캐시, 방화벽, VPN 설정을 본다.
반대로 모두가 안 된다면 공통 구간을 찾는다. 같은 공유기를 쓰는 사람 모두가 안 된다면 공유기나 회선 쪽을 본다. 전 세계 사용자에게 안 된다면 서버, DNS, CDN, BGP 경로 같은 더 넓은 영역까지 봐야 한다.
장애를 찾을 때 중요한 질문은 "누가 영향을 받는가"이다. 한 사람인지, 한 방인지, 한 회사인지, 한 지역인지에 따라 의심할 구간이 달라진다.
로그와 패킷 관찰은 대화를 엿보는 일이다
도구로도 원인이 선명하지 않을 때가 있다. 이때는 로그와 패킷을 본다.
로그는 장비와 프로그램이 남긴 일기장이다. 웹 서버 로그에는 누가 언제 어떤 요청을 했고, 어떤 상태 코드로 응답했는지가 남을 수 있다. 방화벽 로그에는 어떤 통신을 허용했고 어떤 통신을 차단했는지가 남을 수 있다. DNS 서버 로그에는 어떤 이름을 누가 물었는지가 남을 수 있다.
로그를 보면 추측이 줄어든다.
"요청이 서버까지 왔는가?" "서버가 거절했는가, 아예 못 받았는가?" "방화벽이 중간에서 막았는가?" "DNS 질의가 들어오긴 했는가?"
패킷 관찰은 더 낮은 단계의 대화를 보는 일이다. 패킷은 인터넷에서 오가는 데이터 묶음이다. 패킷을 관찰하면 내 컴퓨터가 실제로 어떤 IP로 요청을 보내는지, TCP 연결 시도가 오가는지, DNS 응답이 돌아오는지 볼 수 있다.
물론 패킷 내용을 볼 때는 주의가 필요하다. 다른 사람의 통신을 허락 없이 들여다보면 안 된다. 작은 실험망이나 자신이 관리하는 장비에서 문제 해결 목적으로 사용해야 한다. 또한 HTTPS처럼 암호화된 통신은 중간에서 내용을 쉽게 읽을 수 없다. 볼 수 있는 것은 주로 연결 상대, 포트, 흐름, 오류 같은 겉모습이다.
그래도 이 겉모습만으로도 많은 것을 알 수 있다. 요청이 나갔는데 응답이 안 오는지, 애초에 요청이 나가지 않는지, 응답은 왔는데 운영체제나 브라우저가 거부하는지 구분할 수 있기 때문이다.
고칠 때의 기본 문장
인터넷 문제를 고칠 때는 다음 문장으로 정리하면 좋다.
"어디까지는 되고, 어디부터는 안 된다."
이 문장이 나오면 문제는 이미 절반쯤 좁혀진 것이다.
케이블과 와이파이는 된다
IP 주소도 받았다
게이트웨이 ping도 된다
바깥 IP도 된다
그런데 이름 조회가 안 된다
이 경우 DNS를 보면 된다.
또는 이렇게 말할 수도 있다.
내 IP 주소는 정상이다
게이트웨이까지는 된다
하지만 바깥 IP로 나가지 못한다
이 경우 DNS보다 라우팅, NAT, 공유기 WAN, 통신사 회선을 먼저 본다.
마지막으로 이렇게 정리될 수도 있다.
DNS는 올바른 IP를 돌려준다
서버 IP에도 닿는다
하지만 HTTPS 연결에서 실패한다
이 경우 웹 서버 포트, 방화벽, TLS 인증서, 서버 로그를 확인한다.
인터넷 장애 해결은 특별한 감각이 아니라 순서의 기술이다. 아래에서 위로, 가까운 곳에서 먼 곳으로, 숫자 주소에서 이름으로, 연결에서 서비스로 올라가면 된다. 이렇게 보면 인터넷은 더 이상 검은 상자가 아니다. 우리가 앞에서 만든 작은 인터넷처럼, 여러 장치와 약속이 이어진 구조로 보인다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.