네트워크 인프라 이해하기 · 도입 · 통신 전체를 먼저 보기

인터넷이 안 될 때, 어디서부터 봐야 할까

접속 실패를 링크·주소·이름·경로·서비스의 증거로 좁히는 진단 지도

BY 주식회사 아이엠비즈니스플랫폼 PUB 2026-07-24 UPD 2026-10-24 READ 약 11분

브라우저에 “인터넷에 연결할 수 없음”이 떠도 원인은 하나가 아닙니다. 요청과 응답이 어디에서 멈췄는지 알려면 정상 통신부터 이해해야 합니다. 이 책에서는 단말의 주소 설정과 스위칭·라우팅을 익힌 뒤, 실제 망의 설계와 외부 연결, 보안과 장애 복구를 살펴봅니다. 먼저 접속이 안 될 때 무엇부터 확인하면 좋을지 알아보겠습니다.

이 책의 전체 차례 · 35편

도입 · 통신 전체를 먼저 보기

같은 연결 실패라도 원인은 다릅니다. 단말에서 서버까지 요청과 응답을 먼저 훑고, 각 단계가 맡는 일을 나누어 읽습니다.

제1부 · 내 PC는 통신할 준비를 어떻게 할까

목적지가 같은 망인지 판단하는 기준을 익히고, 필요한 주소 크기를 계산한 뒤 단말이 설정을 받는 과정을 살펴봅니다.

제2부 · 가까운 장비까지 데이터는 어떻게 전달될까

보낼 MAC 주소를 찾는 과정에서 출발해 VLAN, 루프 방지, 링크 집성과 VLAN 사이의 전달을 연결합니다.

제3부 · 다른 네트워크와 인터넷으로는 어떻게 나갈까

라우터의 경로 선택을 먼저 이해하고 NAT, 정적 경로의 장애 전환, OSPF의 경로 계산으로 나아갑니다.

제4부 · 배운 원리로 실제 망을 어떻게 설계할까

공유기에 모인 기능을 나누는 이유에서 출발합니다. Cisco의 참조 설계에 역할·주소·용량·장애 경계를 대입하고 필요한 계층과 이중화를 정합니다.

제5부 · 사내망을 지사·클라우드·인터넷과 연결하기

사내망을 지사·클라우드·인터넷과 연결할 때 필요한 조건을 알아봅니다. 회선을 개통하는 일과 주소를 배정받는 일, 목적지까지의 경로를 알리는 일을 구별하고 BGP와 재분배 정책으로 이어갑니다.

제6부 · 연결된 망을 안전하게 유지하고 장애에서 복구하기

설계에 포함한 보안 정책을 실제 통신 경로에 적용하고, 공격 대응·장애 시험·서비스 복구까지 이어 봅니다. 침해가 진행 중일 때는 피해 확산 방지가 우선입니다.

맺음 · 한 번의 통신으로 전체를 다시 보기

처음 보았던 웹 접속을 다시 설명하고, 정상 통신과 일반 장애·보안 사고를 구별해 봅니다. 외운 용어를 실제 설계와 운영 판단으로 연결하며 책을 마칩니다.

한 번의 웹 접속으로 네트워크 전체를 다시 살펴보기

화면에는 똑같이 “인터넷 연결 실패”라고 나오는데, 원인은 왜 제각각일까↑

브라우저가 흰 화면을 보여 주는 이유는 하나가 아닙니다. 무선 연결이 끊겼을 수도 있고, 단말이 주소를 받지 못했거나 DNS가 이름을 풀지 못했을 수도 있습니다. 목적지까지 가는 경로가 사라졌거나 서버가 연결을 거부해도 사용자에게는 모두 “인터넷이 안 된다”로 보입니다.

진단의 첫 원칙은 장비 이름을 추측하지 않는 것입니다. 관찰한 증상을 통신 단계로 나눈 뒤, 각 단계가 남기는 증거를 확인합니다. 링크 상태, IP 설정, DNS 응답, ARP·라우팅 테이블, TCP 응답은 서로 다른 질문에 답합니다.

예를 들어 사용자가 https://www.imbizcorp.com을 열지 못한다는 신고만 남겼다고 해 보겠습니다. Wi-Fi Association이 끊겼다면 단말에서 프레임 자체가 나가지 않습니다. DHCP 실패라면 링크는 살아 있어도 올바른 Source IP와 Default Gateway가 없습니다. DNS 실패라면 IP로 직접 접속할 때는 열릴 수 있고, TCP 실패라면 DNS Answer까지 정상이어도 SYN에 응답이 오지 않습니다. 같은 화면을 만든 원인이지만 각 경우에 마지막으로 성공한 동작은 전혀 다릅니다.

따라서 장애 문장을 장비 이름이 아니라 관찰 가능한 동작으로 바꿔야 합니다. “방화벽 문제 같다”보다 “단말에서 DNS Answer는 받았고, 2026-09-03 확인 당시 응답 중 하나인 104.21.30.148:443으로 SYN을 보냈지만 SYN-ACK이 없다”가 훨씬 유용합니다. 이 문장에는 정상인 단계와 처음 실패한 단계가 함께 들어 있습니다. 이후 담당자가 바뀌어도 같은 패킷과 시각을 기준으로 조사를 이어 갈 수 있다는 점이 단계별 진단의 실무적 의미입니다.

이 글에서 예로 드는 TCP 기반 HTTPS 웹사이트가 열리려면 단말의 링크와 주소 설정, 이름 해석, 목적지까지의 경로, TCP·TLS 연결, 서버 응답이 준비되어야 합니다. 어느 단계가 실패했는지에 따라 확인할 장비와 기록이 달라집니다. 정상인 마지막 단계와 실패한 첫 단계를 찾으면 원인을 조사할 구간을 좁힐 수 있습니다.

이 절의 근거 IETF RFC 1122

어디부터 볼지 막막하다면, 지금 단말에서 확인할 수 있는 증거부터 찾는다↑

먼저 단말이 네트워크에 붙어 있는지 봅니다. Ethernet 포트가 올라와 있거나 Wi-Fi가 연결되었다는 표시는 L1·L2 연결의 출발점일 뿐, IP 통신 전체가 정상이라는 뜻은 아닙니다.

다음으로 IP 주소, Subnet Mask, Default Gateway와 DNS 서버를 확인합니다. 예를 들어 사내망에서 받아야 할 주소의 대역이 10.20.30.0/24인데 단말에 169.254.23.8이 잡혔다면, 웹 서버보다 DHCP 과정을 먼저 봐야 합니다. 반대로 주소 설정이 맞으면 같은 네트워크의 게이트웨이까지 도달하는지 확인합니다.

가까운 증거는 단순히 물리 계층부터 기계적으로 훑으라는 뜻이 아닙니다. 현재 증상과 가장 가까우면서 즉시 확인할 수 있는 값을 먼저 대조하라는 뜻입니다. 한 사용자만 실패하면 그 단말의 IP 설정과 ARP Cache가 좋은 출발점이고, 같은 Access 스위치의 사용자 전체가 동시에 실패하면 Uplink와 VLAN 상태가 더 가까운 증거일 수 있습니다. 장애 범위와 마지막 변경 시각을 함께 보면 첫 확인 지점을 더 정확히 고를 수 있습니다.

각 확인에는 정상 기준이 필요합니다. 인터페이스가 Up 상태라는 값만 보지 말고 오류 카운터가 늘어나는지, DHCP Lease에 받은 Prefix와 Gateway가 설계값인지, Gateway IP에 대한 ARP Entry가 Complete인지 확인합니다. 현재 값을 평소 정상 단말이나 같은 VLAN의 정상 포트와 비교하면 “값이 있다”와 “값이 맞다”를 구분할 수 있습니다. 이 비교가 없으면 존재하는 설정 하나를 정상의 증거로 오해하기 쉽습니다.

예를 들어 사내 단말이 10.20.30.0/24 대역의 주소를 받아야 하는데 169.254.23.8만 가지고 있다면, 웹 서버보다 주소 설정 과정이 먼저입니다. 반대로 주소와 Gateway가 맞고 Gateway의 MAC도 ARP Cache에서 확인된다면 조사 지점은 DNS 또는 그 다음 홉으로 이동합니다. 한 단계의 성공은 전체 성공이 아니라 다음 단계로 넘어갈 근거입니다.

이 절의 근거 IETF RFC 1122

링크부터 서비스까지, 다섯 관문은 무엇이 정상인지 서로 다르게 말해 준다↑

접속 실패를 나누는 다섯 관문
관문	확인할 질문	대표 증거
링크	단말과 첫 장비가 프레임을 주고받을 수 있는가?	신호, 포트 상태, 오류 카운터
주소	단말이 올바른 네트워크 설정을 가졌는가?	IP, Mask, Gateway, DHCP Lease
이름	도메인이 목적지 IP로 해석되는가?	DNS 질의·응답, 캐시
경로	패킷과 응답이 서로의 방향으로 전달되는가?	ARP, Route, NAT, 홉별 캡처
서비스	목적지 프로세스가 연결과 요청에 응답하는가?	TCP 플래그, TLS 경고, HTTP 상태

Ping 하나로 다섯 관문을 모두 판정할 수는 없습니다. ICMP가 정책으로 차단되어도 웹은 열릴 수 있고, 같은 장비의 ICMP 응답이 정상이어도 DNS나 TCP 서비스는 실패할 수 있습니다.

관문은 독립적인 시험 목록이 아니라 앞 단계의 출력이 다음 단계의 입력이 되는 흐름입니다. DHCP가 준 DNS 서버 주소가 틀리면 이름 관문에서 멈추고, DNS가 오래된 서버 IP를 돌려주면 TCP는 정상적으로 동작하면서도 엉뚱한 목적지에 연결을 시도합니다. ARP가 Gateway MAC을 찾지 못하면 올바른 DNS Answer를 받아도 원격 Prefix로 패킷을 보낼 수 없습니다. 따라서 실패한 관문뿐 아니라 그 관문이 받은 입력값이 어디에서 왔는지도 확인해야 합니다.

ping과 traceroute도 질문을 좁혀 쓰면 의미가 생깁니다. Gateway Ping은 로컬 L2·L3 왕복의 한 증거이고, 목적지 IP Ping은 ICMP 경로와 응답 정책의 증거입니다. 이름으로 실행한 시험에는 DNS 결과까지 섞입니다. 명령 하나의 성공·실패를 네트워크 전체 판정으로 확대하지 말고, 그 명령이 실제로 어떤 프로토콜과 목적지를 사용했는지 기록해야 다섯 관문 중 어디까지 확인했는지 알 수 있습니다.

시험 도구는 관문에 맞춰 선택합니다. 주소로는 열리지만 이름으로는 열리지 않는다면 DNS 증거를, SYN만 반복된다면 Return Path와 방화벽을, TLS Alert가 돌아온다면 인증서와 암호 조건을 봅니다. 도구의 유명세보다 지금 답해야 할 질문이 먼저입니다.

이 절의 근거 IETF RFC 1122

도해에서 확인할 내용 링크·주소·Gateway·DNS·서비스가 이어지는 성공 예와 중간 연결이 끊긴 실패 예를 비교합니다. 성공 예의 DHCP 할당·게이트웨이 ARP 응답·PAT 변환·이름 해석 성공을 실패 예의 APIPA 주소·WAN 인증 실패·질의 차단 항목과 대조합니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

요청이 서버까지 갔다면 끝일까? 응답이 돌아오는 길도 따로 확인해야 한다↑

요청 패킷이 서버에 도착했다고 통신이 끝난 것은 아닙니다. 서버의 응답이 단말까지 돌아와야 합니다. Asymmetric Routing 자체는 설계에 따라 정상일 수 있습니다. 그러나 Stateful 방화벽이나 Connection Tracking과 결합된 NAT 장비가 한 방향만 관찰하면, 응답을 기존 흐름으로 인정하지 못하거나 NAT Mapping을 찾지 못할 수 있습니다.

패킷 캡처도 한 지점만 보면 결론을 서두르기 쉽습니다. 단말에서 요청이 나갔다는 사실과 경계 장비에서 같은 흐름이 보인다는 사실, 서버 쪽에서 응답이 나왔다는 사실을 시간과 5-Tuple로 연결해야 합니다. 어느 지점에서 값이 달라지는지도 함께 기록합니다.

단말 10.20.30.25:51514가 서버 104.21.30.148:443으로 SYN을 보냈다고 가정하겠습니다. 서버에서 SYN이 보이는데 단말에서 SYN-ACK이 보이지 않는다면 요청 방향은 적어도 서버까지 도달했습니다. 이제 서버의 Default Gateway, 반환 Route, 경계의 NAT Mapping과 방화벽 상태를 응답 방향으로 따라가야 합니다. 요청을 다시 캡처하는 것만으로는 돌아오는 길의 어느 지점에서 사라졌는지 알 수 없습니다.

여러 지점의 캡처를 연결할 때는 주소가 변할 수 있다는 점도 반영합니다. 내부에서는 Source가 10.20.30.25:51514이지만 NAT 바깥에서는 198.51.100.8:40001일 수 있습니다. 두 패킷의 TCP Sequence Number, 목적지, 시각과 NAT Log를 함께 대조해야 같은 흐름임을 확인할 수 있습니다. 양방향 확인은 경로가 반드시 대칭이어야 한다는 뜻이 아니라, 각 방향이 필요한 Route와 중간 장비의 상태 조건을 모두 만족하는지 확인한다는 뜻입니다.

따라서 패킷 캡처는 위치와 시각을 함께 기록합니다. 단말에서 나간 TCP SYN, 경계에서 주소가 바뀐 같은 SYN, 서버 쪽 SYN-ACK을 Sequence·Flag·5-Tuple로 연결합니다. 마지막으로 보인 요청과 처음 사라진 응답 사이가 실제 조사 구간입니다. “서버까지 Ping이 된다”는 결과만으로 이 왕복을 대신할 수 없습니다.

이 절의 근거 IETF RFC 1812

정상으로 확인된 마지막 지점과 처음 실패한 지점 사이에 원인이 있다↑

상황: 사내 노트북에서 도메인 이름으로는 서비스가 열리지 않지만 서버 IP에는 접속됩니다.

링크와 IP 설정이 맞는지 확인합니다. IP 접속이 되므로 이 단계는 우선순위가 내려갑니다.
같은 단말에서 대상 이름의 DNS 질의와 응답을 확인합니다.
응답이 없으면 설정된 DNS 서버까지의 경로와 서버 로그를 확인합니다.
잘못된 주소가 오면 권한 서버의 레코드, 내부·외부 분리 DNS와 캐시 만료를 봅니다.
수정 뒤 같은 이름을 다시 질의하고 실제 연결 목적지가 바뀌었는지 재검증합니다.

이 방식의 핵심은 모든 장비를 한꺼번에 의심하지 않고, 정상으로 확인된 마지막 관문과 실패한 첫 관문 사이로 조사 범위를 줄이는 것입니다.

성공한 시험과 실패한 시험 모두 비교할 수 있을 만큼 구체적으로 기록합니다. 예를 들어 “DNS 정상” 대신 조회한 이름, 응답 IP, 응답 시각과 사용한 DNS 서버를 적습니다. TCP 연결이 실패했다면 양쪽 IP·포트, SYN 재전송 횟수와 RST·ICMP 응답 여부를 기록합니다. 이렇게 해야 어느 지점까지 정상이고 어디부터 실패했는지 장비와 링크를 짚어 설명할 수 있습니다.

수정 뒤에는 같은 조건으로 다시 시험해 원래 증상이 사라졌는지 확인해야 합니다. DNS Cache를 비우지 않은 상태에서 TTL 만료 여부도 확인하지 않으면 예전 Answer로 시험할 수 있고, 기존 TCP 세션을 재사용하면 새 방화벽 정책을 지나지 않을 수 있습니다. 변경 전후 캡처와 카운터를 보존하고 한 번에 한 조건만 바꾸면 무엇이 복구를 만들었는지 설명할 수 있습니다. 이 절차는 빠른 임시 복구와 원인 규명을 동시에 가능하게 합니다.

이 절차가 남기는 결론은 “DNS가 의심된다”가 아니라 어느 Query가 어디까지 갔고 어떤 Answer가 돌아왔는지입니다. 정상인 마지막 증거와 실패한 첫 증거를 붙여 놓으면 담당 장비와 필요한 변경도 함께 좁아집니다.

이 절의 근거 IETF RFC 1122 · IETF RFC 1812

이제 브라우저의 요청 하나를 따라가며 각 기술이 맡은 일을 차례로 살펴본다↑

브라우저의 웹 접속 과정에서 요청과 응답의 전체 왕복을 먼저 봅니다. 이후 주소와 DHCP로 통신을 준비하고, ARP·VLAN을 거쳐 라우팅과 NAT로 다른 망에 나가는 원리를 익힙니다. 이 원리를 실제 망의 설계와 외부 연결, 보안·검증·복구에 적용한 뒤 마지막에는 같은 웹 접속을 다시 설명하며 책을 마칩니다.

처음부터 모든 프로토콜을 외울 필요는 없습니다. 각 글에서 같은 질문을 반복하면 됩니다. 장비는 어떤 값을 입력으로 받고, 무엇을 판단하며, 어떤 상태를 남기고, 다음에 무엇을 내보내는가?

다음 글에서는 www.imbizcorp.com을 여는 요청과 응답을 따라가며 DNS, ARP, 라우팅, NAT, TCP와 TLS가 어떤 일을 맡는지 먼저 살펴봅니다. 이후에는 그중 한 과정을 글마다 자세히 설명합니다. ARP를 읽을 때는 누구의 MAC 주소를 찾는지, NAT를 읽을 때는 주소·포트가 어떻게 바뀌고 응답이 어떻게 돌아오는지에 집중하면 됩니다.

명령 결과를 볼 때도 같은 기준을 적용해 보세요. 라우팅 테이블에 경로가 있다는 사실과 그 경로로 패킷이 전달된다는 사실은 다릅니다. 설정과 테이블을 확인한 뒤 실제 패킷이나 서비스 응답까지 대조하는 습관이 장애 원인을 찾는 데 도움이 됩니다.

처음에는 낯선 용어가 많아도 괜찮습니다. 전체 흐름을 먼저 읽고 필요한 부분으로 돌아오면 앞서 본 장면을 더 자세히 이해할 수 있습니다. 마지막 글에서는 같은 웹 접속을 다시 살펴보며 주소·전달·설계·복구가 하나의 통신에서 어떻게 연결되는지 정리하겠습니다.

이 절의 근거 IETF RFC 1122 · IETF RFC 1812 · IETF RFC 8200

도해에서 확인할 내용 단말의 준비부터 ARP, DNS, TCP/TLS, PAT, ISP·IXP, Web 서버와 응답 경로까지 다섯 구간을 따라갑니다. 요청·응답 패킷 화살표를 구분하고, 공유기 상자의 192.168.1.50:5001 ↔ 198.51.100.78:15001 변환과 응답의 역매핑 값을 비교합니다.