네트워크 인프라 이해하기 · 제1부 · 내 PC는 통신할 준비를 어떻게 할까
내 PC는 목적지가 같은 네트워크에 있는지 어떻게 판단할까
32비트 주소와 Prefix를 비교해 ARP 대상이 호스트인지 Gateway인지 정하는 과정
단말은 패킷을 보내기 전에 목적지 IP가 자신과 같은 네트워크에 있는지 판단합니다. 자신의 Subnet Mask를 자신과 목적지 IP에 각각 적용해 두 Network Address를 비교하고, 결과에 따라 목적지 호스트 또는 Default Gateway의 MAC 주소를 찾습니다. 이 글에서는 실제 32비트 값과 AND 계산을 따라가며 이 판단이 첫 프레임의 목적지 MAC을 어떻게 바꾸는지 확인합니다.
점으로 구분한 IPv4 주소를 비트로 펼치면 네트워크 경계가 보인다↑
192.0.2.34는 점으로 구분한 네 숫자지만 장비는 32비트 값으로 처리합니다. 각 숫자는 8비트인 옥텟이며 0부터 255까지 표현합니다. 점 표기는 사람이 읽기 위한 형식이고, 네트워크 경계는 비트 위치로 정합니다.
주소 하나만으로는 어느 비트까지 네트워크 부분인지 알 수 없습니다. /24 Prefix 또는 255.255.255.0 Subnet Mask가 앞 24비트를 네트워크 부분으로 사용한다는 경계를 알려 줍니다.
예를 들어 192.0.2.130의 마지막 옥텟 130은 이진수로 10000010입니다. Prefix가 /25라면 마지막 옥텟의 첫 비트까지 네트워크 부분이고 나머지 7비트가 호스트 부분입니다. 그래서 192.0.2.130/25는 192.0.2.128/25에 속합니다. 점 사이의 숫자 모양보다 Prefix가 가르는 비트 위치가 네트워크 소속을 정합니다.
같은 주소라도 /24로 해석하면 Network Address는 192.0.2.0, /26으로 해석하면 192.0.2.128이 됩니다. IP 주소만 따로 비교해서는 두 단말이 On-Link인지 알 수 없는 이유입니다. 장비 설정이나 장애 기록에는 주소와 Prefix를 항상 함께 적어야 합니다. 192.0.2.130이라고만 기록하면 전달 판단에 필요한 절반의 정보가 빠진 셈입니다. 라우터와 호스트의 Route 출력에서도 주소 옆 Prefix를 한 값처럼 읽어야 합니다.
주소의 앞부분이 네트워크, 뒷부분이 호스트라는 설명은 Prefix 경계가 옥텟에 맞을 때만 단순하게 보입니다. /27처럼 경계가 옥텟 중간에 오면 마지막 옥텟 안에서도 네트워크 Bit와 호스트 Bit가 나뉩니다. 따라서 점으로 찍힌 숫자의 모양보다 32비트와 Prefix 길이를 기준으로 읽어야 합니다. 계산 결과를 문서에 남길 때도 주소와 Prefix를 한 쌍으로 기록합니다.
이 절의 근거 IETF RFC 791 · IETF RFC 4632
도해에서 확인할 내용 IPv4 주소 192.168.10.15의 네 옥텟을 32비트로 펼친 모습입니다. 각 옥텟의 이진수와 2의 거듭제곱으로 표시한 자리 가중치를 대조해 십진수 주소 값이 만들어지는 과정을 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
단말은 IP 주소와 Subnet Mask를 AND해 자신이 속한 네트워크를 알아낸다↑
단말은 자신의 주소와 Mask를 Bitwise AND로 계산합니다. Mask가 1인 위치는 주소 비트를 남기고, 0인 위치는 0으로 만듭니다.
내 주소 192.0.2.34 /24
Mask 255.255.255.0
AND 결과 192.0.2.0 ← 내 네트워크같은 연산을 목적지에도 적용해 결과를 비교합니다. Prefix 길이가 같은 상황에서 두 Network Address 값이 같으면 On-Link, 다르면 원격 목적지로 판단합니다.
192.0.2.130/26의 Mask는 255.255.255.192입니다. 마지막 옥텟에서 130은 10000010, Mask의 192는 11000000입니다. 두 값을 AND하면 10000000, 즉 128이 남아 Network Address는 192.0.2.128이 됩니다. 목적지 192.0.2.190도 같은 결과가 나오지만 192.0.2.200은 192.0.2.192가 나옵니다.
운영체제는 이 계산 결과를 바탕으로 Connected Route를 설치하고 목적지 조회에 사용합니다. 사용자가 매 패킷마다 이진수 계산을 직접 하는 것은 아니지만, Route 출력에 보이는 192.0.2.128/26은 이 연산의 결과입니다. 장애 때는 계산식만 맞추는 데서 끝내지 말고 실제 인터페이스 Prefix와 Connected Route가 같은 범위를 가리키는지 확인해야 설정이 전달 동작에 반영되었는지 알 수 있습니다.
Route 테이블은 이 직접 연결 Prefix와 더 구체적인 Route, Default Route를 함께 가질 수 있습니다. 일반적인 호스트 판단에서는 Prefix 비교가 첫 설명이지만, 실제 전송은 정책 Route·VPN·호스트 Route 같은 더 구체적인 설정의 영향을 받을 수 있으므로 최종 Route 조회 결과도 확인합니다.
이 절의 근거 IETF RFC 1122 · IETF RFC 4632
도해에서 확인할 내용 호스트 IP 192.168.10.130과 /26 Subnet Mask의 Bitwise AND 결과가 네트워크 ID 192.168.10.128이 되는 과정을 확인합니다. 주소·마스크·연산 결과의 마지막 옥텟을 비교하면 네트워크에 속하는 비트와 192.168.10.128~191 범위를 대조할 수 있습니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
목적지가 같은 네트워크라면 단말은 그 호스트의 MAC을 직접 찾는다↑
목적지 192.0.2.80에 /24 Mask를 적용하면 192.0.2.0이 나옵니다. 내 네트워크와 같으므로 단말은 ARP로 192.0.2.80의 MAC 주소를 묻습니다.
응답을 받으면 Ethernet 목적지에 그 MAC을 넣고, IP 목적지에는 계속 192.0.2.80을 넣습니다. 스위치는 MAC 테이블을 이용해 프레임을 해당 포트로 전달합니다.
단말이 192.0.2.80을 On-Link로 판단하면 ARP Request의 Target IP에 그 주소를 넣고 Broadcast 프레임으로 보냅니다. 응답을 받은 뒤 Data 프레임의 Destination MAC은 192.0.2.80을 가진 NIC의 MAC이 됩니다. 이 과정에서 Default Gateway는 관여하지 않습니다. 같은 Subnet 통신을 Gateway ACL이나 라우터 캡처에서 찾지 못하는 것이 정상일 수 있는 이유입니다.
ARP 응답이 없으면 단말은 프레임에 넣을 목적지 MAC 주소를 알 수 없습니다. 애플리케이션에서는 연결 시간 초과로 보이더라도 TCP 연결 전에 막힌 상황일 수 있습니다. ARP Cache의 Incomplete 상태와 반복되는 요청, 스위치의 VLAN과 MAC 학습 위치를 함께 확인합니다. 주소 계산상 같은 망에 있어도 실제 링크가 끊겼거나 상대 장비가 꺼져 있으면 통신할 수 없습니다.
ARP Reply가 없다고 해서 곧바로 스위치가 고장났다고 결론 내리지는 않습니다. 상대 호스트가 꺼졌거나 다른 VLAN에 놓였을 수 있고, 단말의 Mask가 잘못되어 실제로는 원격인 주소를 로컬이라고 믿었을 수도 있습니다. ARP의 질문 대상이 맞는지 먼저 확인하면 L2 문제와 주소 판단 오류를 구분할 수 있습니다. 같은 시각의 Route 조회 결과를 함께 저장하면 그 판단을 다시 검증할 수 있습니다.
이 절의 근거 IETF RFC 1122 · IETF RFC 826
목적지가 다른 네트워크라면 왜 서버가 아니라 Gateway의 MAC을 찾을까↑
198.51.100.20/24의 네트워크 결과는 198.51.100.0이므로 로컬 Prefix와 다릅니다. 단말은 서버의 MAC을 찾으려 하지 않고 설정된 Default Gateway 192.0.2.1의 MAC을 ARP로 조회합니다.
Ethernet 목적지 게이트웨이 MAC
IP 목적지 198.51.100.20게이트웨이는 프레임을 받은 뒤 기존 L2 헤더를 벗기고 IP 목적지로 경로를 조회합니다. 다음 링크에 맞는 새 L2 헤더를 만들어 패킷을 이어 보냅니다.
원격 서버가 여러 라우터 밖에 있어도 클라이언트가 알아야 할 MAC은 첫 Gateway 하나뿐입니다. 클라이언트는 IP 패킷의 Destination을 198.51.100.20으로 유지하고, Ethernet Destination에 192.0.2.1의 MAC을 넣습니다. Gateway는 자신의 MAC으로 온 프레임을 받아 L2 헤더를 제거한 뒤 IP Destination으로 Route 조회를 수행합니다. 다음 링크에서는 전혀 다른 출발지·목적지 MAC을 가진 프레임이 만들어집니다.
따라서 서버의 MAC 주소가 클라이언트 ARP Cache에 없다는 것은 문제가 아닙니다. 오히려 원격 서버 IP에 대해 ARP를 반복한다면 클라이언트의 Mask나 On-Link Route가 잘못되었을 가능성이 큽니다. 반대로 Gateway MAC을 정상적으로 알아도 Gateway 이후 Route가 없으면 ICMP Unreachable이 오거나 패킷이 폐기될 수 있습니다. ARP 성공은 첫 홉 전달 준비의 증거이지 End-to-End Reachability의 증거가 아닙니다.
이 구분은 “IP 주소는 End-to-End 목적지를, MAC 주소는 현재 링크의 다음 전달 대상을 가리킨다”는 원리를 보여 줍니다. 라우터를 지날 때 출발지·목적지 MAC은 새 링크에 맞게 바뀌고 TTL도 줄어듭니다. 일반적인 라우팅에서 최종 IP Destination은 NAT 같은 별도 기능이 개입하지 않는 한 유지됩니다.
이 절의 근거 IETF RFC 1122 · IETF RFC 826
도해에서 확인할 내용 Source와 Destination에 같은 Mask를 적용한 두 네트워크 ID를 비교하고, On-link·Off-link 가지의 ARP Target과 L2 목적지 MAC을 확인합니다. 로컬 목적지는 192.168.10.42, 원격 목적지의 다음 전달 대상은 게이트웨이 192.168.10.1입니다. 아래 두 프레임 상자에서 최종 목적지 IP와 현재 링크의 목적지 MAC을 구분합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Subnet Mask 하나가 틀리면 같은 장비를 서로 가깝게도 멀게도 판단한다↑
단말과 게이트웨이가 같은 IP 대역처럼 보여도 Mask가 다르면 판단 결과가 달라집니다. 단말이 너무 넓은 Mask를 사용하면 실제로는 라우터 너머에 있는 주소를 로컬이라고 판단하고 응답 없는 ARP를 반복할 수 있습니다.
반대로 마스크를 너무 좁게 설정하면 실제로 같은 서브넷에 있는 목적지를 외부 망으로 판단해 게이트웨이에 보낼 수 있습니다. 이때 프레임의 목적지는 게이트웨이 자신의 MAC 주소입니다. 이후 전달 여부는 게이트웨이의 경로와 정책에 달려 있으며, 이미 받은 패킷을 라우팅하는 이 동작을 Proxy ARP라고 부르지는 않습니다.
예를 들어 한쪽은 /24, 다른 쪽은 /25로 설정하면 같은 두 주소를 두고도 로컬 여부를 다르게 판단할 수 있습니다. 넓은 범위를 로컬로 보는 쪽은 목적지에 직접 ARP하고, 좁게 보는 쪽은 게이트웨이로 보낼 수 있습니다. 원격 주소에 대한 ARP에 라우터가 대신 응답하는 Proxy ARP가 마스크 오류를 가리는 경우와, 게이트웨이가 자기 MAC으로 받은 프레임을 라우팅하는 경우를 구별해야 합니다.
Mask 오류를 확인할 때는 두 끝점의 설정을 모두 봐야 합니다. 한쪽의 Ping만 성공하거나 Gateway를 거치면 우연히 통신되는 결과가 설정 정상의 증거가 되지 않습니다. 양쪽에서 상대 IP에 대한 Route 조회 결과와 ARP 대상을 비교하고, DHCP가 배포한 Option과 수동 설정을 대조합니다. 잘못된 Mask를 고친 뒤에는 기존 ARP·Route Cache를 갱신해 새 판단으로 다시 시험해야 합니다.
같은 VLAN의 두 호스트가 서로 다른 Mask를 쓰면 한쪽 방향만 성공하는 비대칭 증상도 생깁니다. 예를 들어 A는 B를 On-Link로 보고 직접 보내지만 B는 A를 Off-Link로 보고 Gateway에 보낼 수 있습니다. 장애 분석에서는 양쪽 호스트의 주소·Prefix·Route와 ARP가 확인하려는 실제 IP를 함께 비교해야 합니다.
이 절의 근거 IETF RFC 1122 · IETF RFC 4632
접속이 안 될 때는 단말이 누구에게 ARP했는지와 Route 결과부터 맞춰 본다↑
상황: 192.0.2.34 단말이 같은 VLAN의 192.0.2.130 서버에 접속하지 못합니다.
- 양쪽 단말의 Prefix를 확인합니다. 한쪽이
/25, 다른 쪽이/24인지 봅니다. - 각 단말이 상대 주소와 게이트웨이 중 누구에게 ARP를 보내는지 캡처합니다.
- 로컬 Route와 Default Route가 어떤 Prefix로 설치되었는지 확인합니다.
- DHCP Option과 수동 설정의 Mask를 같은 설계값으로 맞춥니다.
- ARP Cache를 갱신한 뒤 양방향 통신과 반환 경로를 다시 확인합니다.
첫 번째 관찰값은 운영체제의 Route 조회 결과입니다. 목적지 192.0.2.130이 Connected Route와 일치하는지, Default Route로 향하는지 확인합니다. 그다음 캡처에서 실제 ARP Target IP가 상대 호스트인지 Gateway인지 봅니다. 계산상 예상한 분기와 패킷이 일치하지 않으면 더 구체적인 호스트 Route, VPN Route, 정책 Route처럼 기본 인터페이스 Prefix보다 우선하는 항목을 찾아야 합니다.
변경은 한 끝점의 Mask만 임시로 넓히는 방식으로 끝내지 않습니다. VLAN의 설계 Prefix, Gateway 인터페이스, DHCP Scope, Static 호스트 설정과 네트워크 Monitoring 대상까지 같은 값으로 맞춥니다. 수정 뒤에는 같은 Subnet의 양 끝점과 다른 Subnet 목적지를 각각 시험합니다. 이 두 시험을 함께 해야 로컬 ARP와 Gateway 전달이 모두 의도한 분기로 돌아왔는지 확인할 수 있습니다.
핵심은 “Ping이 안 된다”가 아니라 단말이 누구의 MAC을 찾았고 그 판단이 주소 계획과 일치했는지입니다. 이 결과를 이해하면 서브넷 크기 계산도 실제 전달 범위와 연결해서 볼 수 있습니다.
이 절의 근거 IETF RFC 1122 · IETF RFC 826
용어사전↑
출처와 검증
- IETF RFC 791 — IPv4 주소와 헤더의 기본 규격
- IETF RFC 1122 — 호스트의 Subnet·Gateway 처리 요구사항
- IETF RFC 4632 — CIDR Prefix와 주소 집계
- IETF RFC 826 — IPv4 ARP 동작
예시 IPv4 주소는 RFC 5737 문서 대역과 RFC 1918 사설 대역을 사용했습니다. 운영체제의 On-Link Route 표현과 Proxy ARP 기본 동작은 구현에 따라 다를 수 있습니다.