ARP

IP 주소로 목적지를 안다고 해서 바로 데이터를 보낼 수 있는 것은 아닙니다. 같은 네트워크 안에서 실제로 프레임을 전달하는 이더넷은 IP가 아니라 MAC 주소를 씁니다. IP 계층은 '10.0.0.5에 보내라'고 하지만, 바로 아래의 이더넷 계층은 '그 장치의 물리 주소가 뭔데?'라고 묻습니다. 이 문제는 장치가 추가되거나 교체될 때마다 반복됩니다. IP와 MAC의 대응표를 사람이 일일이 관리하는 것은 현실적이지 않고, DHCP로 주소가 동적으로 바뀌는 환경에서는 불가능에 가깝습니다. ARP는 이 간극을 자동으로 메우는 프로토콜로, IP 주소만 알면 같은 네트워크 안에서 상대방의 MAC 주소를 알아낼 수 있게 합니다.

이더넷이 로컬 네트워크 표준으로 자리 잡던 시기에, 프레임을 전달하려면 목적지의 48비트 MAC 주소가 반드시 필요했습니다. 동시에 TCP/IP가 인터넷 표준으로 확산되면서 애플리케이션과 라우팅은 IP 기반으로 움직이게 됐습니다. 문제는 두 계층이 서로 다른 주소 체계를 쓴다는 점이었습니다. IP는 논리적 위치를 나타내고, MAC은 장치에 고정된 물리 식별자입니다. 장치가 몇 대일 때는 정적 매핑으로 버틸 수 있었지만, 네트워크 규모가 커지고 DHCP로 주소가 동적으로 배정되기 시작하면서 수동 관리는 불가능해졌습니다. RFC 826으로 1982년에 표준화된 ARP는 이 두 주소 체계를 자동으로 이어 주기 위해 등장했습니다. IP와 이더넷이라는 두 계층 사이의 간극이 네트워크가 존재하는 한 사라지지 않기 때문에, ARP는 단순한 설계에도 오랫동안 쓰이고 있습니다.

ARP는 요청-응답 구조로 동작합니다. 송신 장치가 목적지 IP의 MAC 주소를 모르면 ARP 요청을 이더넷 브로드캐스트로 보냅니다. '10.0.0.5를 쓰는 장치, MAC 주소가 뭐야?'라는 질문이 같은 LAN 세그먼트의 모든 장치에 전달되고, 해당 IP를 가진 장치만 자신의 MAC을 담은 응답을 유니캐스트로 돌려보냅니다. 응답을 받은 송신 장치는 IP-MAC 매핑을 ARP 캐시에 저장합니다. 대부분의 운영체제에서 캐시 유효 시간은 수십 초에서 수 분 정도이며, 유효한 동안은 같은 목적지에 대해 다시 브로드캐스트하지 않습니다. 목적지가 다른 서브넷에 있다면 ARP는 최종 목적지가 아니라 기본 게이트웨이의 MAC 주소를 찾습니다. 라우터가 프레임을 받은 뒤에는 IP 라우팅으로 다음 홉을 결정하고, 그 홉의 네트워크에서 다시 ARP가 동작합니다.

ARP와 DNS는 둘 다 알고 있는 식별자로 모르는 식별자를 찾는다는 패턴에서 비슷합니다. 차이는 동작 범위와 변환하는 주소의 종류입니다. DNS는 도메인 이름을 IP 주소로 변환하며 인터넷 전체에 걸쳐 계층적으로 동작합니다. ARP는 IP 주소를 MAC 주소로 변환하며 같은 LAN 세그먼트 안에서만 동작합니다. 라우터를 넘어가면 ARP 브로드캐스트는 전달되지 않습니다. 그래서 DNS 문제는 이름 해석 실패로 나타나고, ARP 문제는 같은 서브넷인데도 특정 장치에만 통신이 안 되는 증상으로 나타납니다. ping이 다른 서브넷으로는 가는데 같은 서브넷 내 특정 장치에만 안 된다면 ARP 캐시나 브로드캐스트 경로를 먼저 살펴볼 수 있습니다.

ARP는 운영체제가 자동으로 처리하므로 애플리케이션 개발자가 직접 다룰 일은 드뭅니다. 하지만 네트워크 문제가 생겼을 때 ARP 캐시를 확인하는 것은 기본적인 진단 습관입니다. arp -a 명령으로 테이블을 보면 같은 서브넷 내 장치와 통신이 안 될 때 올바른 매핑이 있는지, 오래된 항목이 남아 있지는 않은지 빠르게 확인할 수 있습니다. ARP는 인증 메커니즘이 없습니다. 같은 네트워크의 공격자가 거짓 응답을 보내 트래픽을 가로채는 ARP 스푸핑이 가능한 이유입니다. 보안이 중요한 환경에서는 정적 ARP 항목 설정이나 Dynamic ARP Inspection 같은 방어 수단을 고려해야 합니다. ARP 자체는 단순하지만 이 단순함이 보안 취약점이 되므로, 내부 네트워크 보안 설계에서 빠뜨리면 안 되는 점검 항목입니다.