네트워크 인프라 이해하기 · 맺음 · 한 번의 통신으로 전체를 다시 보기

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

이 책에서는 브라우저에 주소를 입력하면 웹사이트가 나타나는 과정부터 살펴보았습니다. 마지막으로 같은 요청과 응답을 다시 따라가 보겠습니다. IP·MAC 주소, 스위칭·라우팅이 맡는 일에 장비 배치와 이중화, 보안과 복구를 함께 놓으면 각각 배운 내용이 하나의 망에서 어떻게 쓰이는지 정리할 수 있습니다.

주소를 찾은 뒤에도 첫 프레임의 목적지는 따로 정한다↑

웹사이트의 IP 주소는 IP 통신의 목적지를 가리키고, 프레임의 목적지 MAC 주소는 현재 링크에서 데이터를 받을 상대를 가리킵니다. 두 주소가 가리키는 대상이 언제 같고 언제 다른지부터 되짚어 보겠습니다.

이 책의 웹 접속 과정에서 사용한 PC는 10.0.0.25/24, 게이트웨이는 10.0.0.1입니다. 주소를 DHCP로 받았든 직접 설정했든, 단말은 사용할 주소와 마스크·게이트웨이·DNS 설정을 알아야 합니다. DHCP 임대가 있다는 사실만으로 서버까지의 통신이 보장되지는 않습니다. 받은 값이 연결된 망의 주소 계획과 맞고, 그 설정으로 실제 목적지에 도달할 수 있는지는 별도로 확인합니다.

브라우저가 www.imbizcorp.com에 접속하려면 사용할 주소를 찾습니다. 여기서는 웹 접속 과정 글에 기록한 2026년 9월 3일의 응답 예시 104.21.30.148을 그대로 되짚습니다. 현재 DNS 응답이나 원본 서버의 고정 주소라는 뜻은 아닙니다. 다른 시각이나 환경에서는 다른 주소가 선택될 수 있으므로, 실제 장애 조사에서는 그때의 이름 해석 결과와 선택된 주소를 먼저 기록합니다.

PC는 이 목적지를 로컬 대역 밖으로 판단하고 게이트웨이에 보냅니다. Ethernet으로 연결된 사례라면 ARP로 10.0.0.1의 MAC 주소를 알아내 첫 프레임을 만듭니다. 프레임의 목적지 MAC은 게이트웨이지만 그 안의 목적지 IP는 여전히 웹 접속 상대입니다. 같은 로컬 망의 장비와 통신한다면 목적지 장비의 MAC을 찾는다는 차이도 함께 떠올려 볼 수 있습니다.

스위치는 MAC 테이블을 보고 프레임을 전달하고, VLAN은 로컬 통신 범위를 나눕니다. 링크를 여러 개 두었다면 루프를 막는 STP와 흐름을 분산하는 링크 집성의 역할도 구별해야 합니다. 어느 기능도 “연결선이 많으니 더 잘될 것”이라는 추측으로 대신할 수 없습니다. 주소 판단은 IP와 서브넷, 첫 프레임의 실제 전달은 ARP와 L2 스위칭에서 다시 확인할 수 있습니다.

근거: RFC 826 — ARP, RFC 1812 — 로컬·원격 목적지와 다음 홉.

장비가 맡은 역할과 함께 멈출 범위를 도면에 표시한다↑

기업망을 설계한다고 공유기 한 대에 모인 기능을 반드시 여러 장비로 나눠야 하는 것은 아닙니다. 어떤 업무에 어느 정도의 연결과 용량이 필요한지, 장애가 나면 어디까지 영향을 받아도 되는지를 먼저 정합니다. 그 조건에 맞춰 장비의 역할을 나누거나 함께 배치합니다.

공유기에서 기업망으로 확장하는 글은 한 상자 안에서도 여러 기능이 다른 상태와 책임을 가진다는 점을 보여 주었습니다. Cisco의 계층형 설계에서는 단말을 연결하는 Access, 접속 구간을 모으는 Distribution, 여러 집계 블록을 잇는 Core의 역할을 구별했습니다. 이 이름을 장비 수와 일대일로 맞추기보다 실제 통신이 어느 경계를 지나는지 도면에서 설명해 보는 편이 중요합니다.

이중화한 두 경로가 같은 전원이나 관로를 사용한다면 하나의 사고로 함께 끊길 수 있습니다. 경로가 하나 남아도 업무 트래픽을 감당할 용량이 부족할 수 있습니다. 장비가 대체 경로를 찾는 시간과 사용자가 업무를 다시 하는 시간도 다를 수 있습니다. 그래서 정상 도면과 함께 장애 도면을 그리고, 남는 연결·용량·통신 상태를 따로 확인했습니다.

이 기준은 작은 현장에도 적용됩니다. 업무 중단을 거의 허용할 수 없다면 작은 망에도 이중화와 복구 절차가 필요합니다. 반대로 건물이 크다는 이유만으로 모든 곳에 복잡한 계층과 프로토콜을 둘 필요는 없습니다. 주소 계획과 보안 정책, 관리 경로를 검토하고 실제로 운영할 수 있는 구성을 골라야 합니다. 어떤 제품을 골랐는지뿐 아니라 왜 그 구성이 필요한지도 설명할 수 있어야 합니다.

책을 마치며 자신의 망에 질문해 볼 수 있습니다. 어떤 서비스가 어느 장비를 지나고, 그중 하나가 멈추면 어느 업무까지 영향을 받을까요? 용량 계산, 장애 범위, 설계 검증에서 같은 도면을 다시 볼 수 있습니다. 정확한 장비 수를 외우는 대신 정상과 장애 상황에서 선택을 설명할 수 있다면 설계 지침을 자기 현장에 적용할 근거가 생깁니다.

근거: Cisco Campus LAN and Wireless LAN 설계 가이드.

연결을 복구하는 일과 안전하게 업무를 재개하는 일을 구별한다↑

일반적인 네트워크 장애에서는 영향을 받은 업무와 고장 구간을 찾아 필요한 기능부터 복구합니다. 반면 침해가 진행 중이라면 연결을 되살리기 전에 피해 확산을 막아야 합니다. 서비스가 끊겼다는 결과만 같을 뿐, 원인에 따라 먼저 해야 할 조치는 달라집니다.

일반 장애에서는 정상 단말과 장애 단말을 비교하고, 요청이 마지막으로 확인된 지점과 응답이 사라진 지점을 찾습니다. 주소 설정·MAC 테이블·경로·정책·세션 상태를 무작정 모두 바꾸기보다 관찰값으로 조사 범위를 좁힙니다. 변경 전 상태와 시각을 남기고, 예상한 결과가 나오지 않으면 되돌릴 수 있어야 합니다. 패킷이 다시 오간 뒤에는 실제 사용자가 업무를 끝까지 수행할 수 있는지도 확인합니다.

보안 침해에서는 격리할 범위와 지속되는 피해를 함께 판단합니다. 감염이나 정보 유출이 진행 중이라면 확인된 단말·구간을 신속히 격리하고 증거를 보존해야 합니다. 제한된 차단으로 확산을 막을 수 있는지 확신할 수 없다면 더 넓은 범위, 필요한 경우 망 전체의 연결을 차단해야 할 수 있습니다. 이것은 모든 연결 실패를 보안 사고로 보고 망을 끊으라는 뜻이 아니라, 진행 중인 피해를 가용성만을 이유로 방치하지 말라는 원칙입니다.

평소의 접근 통제도 이 판단과 이어집니다. 내부에 접속해 있다는 이유만으로 모든 서비스를 신뢰하지 않고 사용자·단말·자원별로 필요한 권한을 확인합니다. 방화벽·탐지·인증·정보 보호 기능은 서로 다른 관찰과 통제를 맡습니다. 네트워크 보안과 장애 판정·복구는 이 역할을 망의 실제 연결과 함께 설명한 글입니다. 자세한 제품 설정과 조직별 사고 절차는 해당 조건에 맞춰 더 정해야 합니다.

처음에는 “인터넷이 안 된다”는 한 문장이었습니다. 이제는 어느 주소로 보냈는지, 누구에게 프레임을 넘겼는지, 어느 경로와 정책을 거쳤는지, 응답이 어디까지 돌아왔는지를 나누어 물을 수 있습니다. 여기에 업무 영향과 남은 용량, 안전하게 복구할 조건까지 더하면 기술 지식이 운영 판단으로 이어집니다. 이 책은 여기서 마칩니다. 다시 확인하고 싶은 부분은 주제별 핵심 경로나 용어 사전에서 찾아 읽어도 좋습니다.

근거: NIST SP 800-61 Rev. 3 — 사고 대응, NIST SP 800-207 — Zero Trust Architecture.

용어사전↑