| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- 정보처리기사 실기 기출문제
- Spring
- CKA
- Java
- AI
- CloudWatch
- kotlin
- aws
- PETERICA
- Kubernetes
- AWS EKS
- minikube
- SRE
- MySQL
- LLM
- tucker의 go 언어 프로그래밍
- Rag
- 오블완
- 기록으로 실력을 쌓자
- docker
- 티스토리챌린지
- 공부
- kotlin coroutine
- Claude
- CKA 기출문제
- go
- Network
- golang
- 코틀린 코루틴의 정석
- 바이브코딩
- Today
- Total
피터의 개발이야기
[Network] 06. IP 주소만 알면 바로 편지를 건넬 수 있을까? 본문

TCP/IP를 우편 시스템으로 이해하기 — Part 2. 편지에 두 종류의 주소가 필요한 이유
ㅁ 들어가며
VLAN은 하나의 물리적인 스위치 안에 여러 Broadcast Domain을 만든다.
이제 같은 VLAN 10에 연결된 두 컴퓨터가 통신한다고 생각해 보자.
PC A ─ Access VLAN 10 ─ Switch ─ Access VLAN 10 ─ PC B
PC A가 알고 있는 정보는 다음과 같다.
내 IP 주소 : 192.168.10.10
상대의 IP 주소 : 192.168.10.20
애플리케이션은 상대의 IP 주소를 목적지로 데이터를 보낸다.
그런데 스위치는 IP 주소가 아니라 이더넷 프레임의 목적지 MAC 주소를 보고 출력 포트를 고른다.
PC A가 프레임을 만들려면 다음 빈칸을 채워야 한다.
Source MAC : PC A의 MAC 주소
Destination MAC : ???
IP 주소는 알고 있지만 MAC 주소는 모른다.
그렇다면 첫 프레임은 누구에게 보내야 할까?
IPv4 네트워크는 ARP(Address Resolution Protocol)를 사용해 이 질문에 답한다.
“192.168.10.20을 사용하는 장비는 자신의 MAC 주소를 알려 달라.”
이번 글에서는 IP 주소와 MAC 주소가 왜 함께 필요한지,
ARP Request와 ARP Reply가 어떤 순서로 오가는지,
알아낸 결과를 ARP Cache에 왜 저장하는지 살펴본다.
ㅁ 주소가 하나면 더 간단하지 않을까?
우편물을 보낼 때는 도시와 도로를 따라 목적지 지역을 찾아갈 주소가 필요하다.
목적지 동네에 도착한 뒤에는 그 동네 안에서 실제 수신인의 문까지 전달할 방법도 필요하다.
네트워크에서는 IP 주소와 MAC 주소가 서로 다른 범위의 문제를 맡는다.
ㅇ IP 주소는 목적지가 어디에 속하는지 나타낸다
IP Address는 논리적인 주소다.
네트워크의 경계를 표현하고 라우터가 서로 다른 네트워크 사이에서 다음 경로를 선택할 때 사용한다.
장비가 다른 네트워크로 이동하면 일반적으로 그 네트워크에 맞는 IP 주소를 사용해야 한다.
ㅇ MAC 주소는 현재 이더넷 구간에서 프레임을 전달한다
MAC Address는 이더넷 인터페이스를 식별하는 L2 주소다.
같은 이더넷 구간에서 스위치는 목적지 MAC 주소를 보고 프레임을 전달한다.
IP Address : 목적지 호스트를 논리적으로 식별하고 경로 선택에 사용
MAC Address : 현재 이더넷 링크에서 다음 수신 인터페이스에 프레임 전달
두 주소는 같은 대상을 표현하는 중복 정보가 아니다.
IP 주소는 전체 여정의 목적지를 나타내고, MAC 주소는 현재 구간에서 프레임을 누구에게 건넬지 나타낸다.
라우터를 지날 때마다 이더넷 프레임은 새 구간에 맞게 다시 만들어지므로 출발지와 목적지 MAC 주소도 바뀐다.
반면 IP 패킷의 출발지와 목적지 주소는 일반적인 라우팅 과정에서는 유지된다.
NAT처럼 IP 주소를 변경하는 기능은 뒤의 글에서 별도로 다룬다.
ㅁ 이름은 아는데 어느 집인지 모른다
PC A가 192.168.10.20으로 IP 패킷을 보내려고 한다.
이 글에서는 PC A가 목적지를 같은 네트워크의 이웃이라고 이미 판단했다고 가정한다.
어떤 기준으로 같은 네트워크와 다른 네트워크를 구분하는지는 다음 글에서 서브넷 마스크와 함께 살펴본다.
PC A가 만들 IP 패킷은 다음과 같다.
Source IP : 192.168.10.10
Destination IP : 192.168.10.20
이 패킷을 이더넷으로 보내려면 프레임 안에 넣어야 한다.
Ethernet Frame
├─ Source MAC : AA:AA:AA:AA:AA:AA
├─ Destination MAC : 아직 모름
└─ Payload : IP Packet
├─ Source IP : 192.168.10.10
└─ Destination IP : 192.168.10.20
PC A는 먼저 자신이 기억하고 있는 이웃 정보에서 192.168.10.20의 MAC 주소를 찾는다.
정보가 없다면 ARP Request를 보낸다.
ㅁ 모르는 집을 찾으려면 동네 전체에 묻는다
PC A는 누가 192.168.10.20을 사용하는지 모른다.
특정 장비의 MAC 주소를 모르므로 그 장비에게만 질문을 보낼 수도 없다.
그래서 같은 Broadcast Domain의 모두에게 ARP Request를 보낸다.
이더넷 프레임은 다음 목적지 MAC 주소를 사용한다.
Destination MAC : FF:FF:FF:FF:FF:FF
이는 Ethernet Broadcast Address다.
ARP Request의 핵심 내용은 다음과 같다.
보내는 사람의 MAC : AA:AA:AA:AA:AA:AA
보내는 사람의 IP : 192.168.10.10
찾는 대상의 IP : 192.168.10.20
질문: 192.168.10.20을 가진 장비는 MAC 주소를 알려 달라.
스위치는 브로드캐스트 프레임을 VLAN 10의 다른 포트로 플러딩한다.
PC A ─ ARP Request ─ Switch ┬─ PC B
├─ PC C
└─ PC D
같은 VLAN의 PC B, C, D가 모두 요청을 받는다.
하지만 각 장비는 ARP 메시지의 Target Protocol Address, 즉 찾는 대상 IP를 확인한다.
- PC C의 IP가 192.168.10.30이면 자신의 요청이 아니므로 응답하지 않는다.
- PC D의 IP가 192.168.10.40이면 자신의 요청이 아니므로 응답하지 않는다.
- PC B의 IP가 192.168.10.20이면 자신의 주소이므로 응답한다.
질문은 모두에게 전달되지만 답할 장비는 IP 주소의 주인 하나다.
ㅁ 주소의 주인은 자신의 MAC 주소를 답한다
PC B는 PC A에게 ARP Reply를 보낸다.
192.168.10.20은
BB:BB:BB:BB:BB:BB에 있다.
PC B는 ARP Request 안에 들어 있던 PC A의 IP 주소와 MAC 주소를 이미 알고 있다.
따라서 ARP Reply는 일반적으로 PC A의 MAC 주소를 목적지로 하는 유니캐스트 프레임으로 보낼 수 있다.
Ethernet
├─ Source MAC : BB:BB:BB:BB:BB:BB
└─ Destination MAC : AA:AA:AA:AA:AA:AA
ARP Reply
├─ Sender IP : 192.168.10.20
├─ Sender MAC : BB:BB:BB:BB:BB:BB
├─ Target IP : 192.168.10.10
└─ Target MAC : AA:AA:AA:AA:AA:AA
스위치는 앞에서 배운 MAC Address Table을 사용해 이 답장을 PC A가 있는 포트로 전달한다.
PC A는 이제 빈칸을 채울 수 있다.
192.168.10.20 → BB:BB:BB:BB:BB:BB
그리고 원래 보내려던 IP 패킷을 이더넷 프레임에 넣는다.
Ethernet Frame
├─ Source MAC : AA:AA:AA:AA:AA:AA
├─ Destination MAC : BB:BB:BB:BB:BB:BB
└─ Payload : IP Packet
├─ Source IP : 192.168.10.10
└─ Destination IP : 192.168.10.20
이제 스위치는 목적지 MAC 주소 BB:...를 보고 PC B 방향으로 프레임을 전달한다.
ARP는 데이터를 전달하는 대신, 데이터를 담을 첫 이더넷 프레임의 목적지 주소를 준비한 것이다.
ㅁ 매번 동네 전체에 물어봐야 할까?
PC A가 패킷을 보낼 때마다 ARP Request를 브로드캐스트하면 같은 질문이 계속 반복된다.
그래서 운영체제는 알아낸 IP 주소와 MAC 주소의 관계를 잠시 저장한다.
이를 흔히 ARP Cache라고 한다.
Linux에서는 IPv4 ARP 정보와 IPv6 Neighbor Discovery 정보를 함께 다루는 Neighbor Table이라는 표현과 명령을 사용한다.
IP Address MAC Address Interface
192.168.10.20 BB:BB:BB:BB:BB:BB eth0
다음 전송에서는 이 항목을 사용해 ARP Request 없이 바로 프레임을 만들 수 있다.
캐시를 영원히 유지하지는 않는다.
장비가 교체되거나 네트워크 인터페이스가 바뀌면 같은 IP 주소가 다른 MAC 주소를 사용할 수 있다.
오래된 정보를 계속 믿으면 잘못된 장비로 프레임을 보낼 수 있다.
따라서 동적으로 학습한 이웃 정보에는 상태와 유효 시간이 있다.
운영체제는 일정 시간이 지나거나 통신 가능성을 확인할 필요가 생기면 이웃 정보를 다시 검증한다.
Linux의 Neighbor Unreachability Detection 상태에서는 다음과 같은 표현을 볼 수 있다.
- REACHABLE: 최근 통신 가능하다고 확인된 이웃
- STALE: 정보는 있지만 최근 도달 가능성은 확인되지 않은 상태
- DELAY, PROBE: 도달 가능성을 다시 확인하는 과정
- INCOMPLETE: 주소 확인을 시도 중이지만 아직 MAC 주소를 얻지 못함
- FAILED: 주소 확인 또는 도달 가능성 확인에 실패함
모든 운영체제가 같은 이름과 상태 전이를 그대로 보여 주는 것은 아니다.
핵심은 ARP 결과가 영구적인 정답이 아니라 현재 링크의 이웃에 대한 임시 정보라는 점이다.
ㅁ ARP는 어디까지 질문할 수 있을까?
ARP Request는 Ethernet Broadcast Frame으로 전달된다.
라우터는 일반적으로 이 L2 브로드캐스트를 다른 네트워크로 전달하지 않는다.
VLAN도 Broadcast Domain을 분리하므로 ARP Request는 같은 VLAN 범위 안에 머문다.
VLAN 10 ─ ARP Request ─X─ Router ─ VLAN 20
목적지 IP가 인터넷의 원격 서버라면 PC가 그 서버의 MAC 주소를 ARP로 찾는 것은 아니다.
원격 목적지로 가는 첫 번째 L2 수신인은 같은 네트워크에 있는 기본 게이트웨이다.
이 경우 PC는 게이트웨이 IP 주소에 대응하는 MAC 주소를 ARP로 찾고, 이더넷 프레임을 게이트웨이에게 보낸다.
IP Packet의 목적지 IP : 원격 서버 IP
첫 Ethernet Frame의 목적지 MAC : 기본 게이트웨이 MAC
IP 목적지와 현재 프레임의 MAC 목적지가 서로 다를 수 있다는 점이 중요하다.
ARP는 전 세계의 주소록이 아니다.
현재 L2 링크에서 다음으로 프레임을 받을 이웃을 찾는 방법이다.
어떤 경우에 상대 호스트를 직접 찾고 어떤 경우에 게이트웨이를 찾아야 하는지는
다음 두 글에서 서브넷 마스크와 기본 게이트웨이로 이어진다.
ㅁ ARP 메시지 안에는 무엇이 들어 있을까?
패킷 캡처 도구에서 ARP를 열어 보면 다음 필드를 볼 수 있다.
| 필드 | 의미 |
| Hardware Type | 사용하는 L2 기술의 종류이며 이더넷은 일반적으로 1 |
| Protocol Type | 해석하려는 상위 프로토콜이며 IPv4는 0x0800 |
| Hardware Address Length | MAC 주소 길이이며 이더넷은 6바이트 |
| Protocol Address Length | IPv4 주소 길이인 4바이트 |
| Opcode | Request는 1, Reply는 2 |
| Sender Hardware Address | 보내는 장비의 MAC 주소 |
| Sender Protocol Address | 보내는 장비의 IPv4 주소 |
| Target Hardware Address | 대상 장비의 MAC 주소이며 Request에서는 아직 모를 수 있음 |
| Target Protocol Address | 찾으려는 대상의 IPv4 주소 |
이더넷 헤더의 EtherType에는 ARP임을 나타내는 0x0806이 사용된다.
모든 필드를 외우는 것보다 다음 네 가지를 읽을 수 있으면 동작을 추적하기 쉽다.
누가 묻는가? Sender IP / Sender MAC
누구를 찾는가? Target IP
요청인가 답변인가? Opcode
누구에게 전달되는가? Ethernet Destination MAC
ㅁ 주소를 묻는 답변을 믿어도 될까?
기본 ARP에는 답변자의 신원을 인증하는 절차가 없다.
같은 L2 네트워크의 공격자가 “게이트웨이 IP 주소는 내 MAC 주소에 있다”고 거짓 ARP 정보를 보내면
다른 장비의 ARP Cache가 잘못 갱신될 수 있다.
이를 ARP Spoofing 또는 ARP Poisoning이라고 한다.
공격자는 트래픽을 자신에게 우회시켜 내용을 엿보거나 변경하고, 전달하지 않아 통신을 끊을 수 있다.
스위치 환경에서 ARP의 신뢰를 보완하기 위해 DHCP Snooping 정보와 연계한 Dynamic ARP Inspection 같은 기능을 사용할 수 있다. 정적 ARP 항목도 특정 환경에서는 도움이 되지만 규모가 커지면 관리가 어렵다.
이 글에서 기억해야 할 점은 ARP가 편리한 자동 주소 조회인 동시에, 같은 L2 네트워크의 답변을 기본적으로 신뢰하도록 설계된 프로토콜이라는 사실이다.
ㅁ Gratuitous ARP는 묻지 않았는데 왜 답할까?
장비가 자신의 IP와 MAC 주소 관계를 요청 없이 네트워크에 알리는 ARP를 Gratuitous ARP라고 한다.
다음과 같은 상황에서 활용할 수 있다.
- IP 주소가 새 MAC 주소로 이동했음을 주변 장비에 알릴 때
- 고가용성 구성에서 활성 장비가 바뀌어 이웃 캐시를 갱신할 때
- 같은 IP 주소를 다른 장비가 사용하고 있는지 중복 가능성을 확인할 때
Gratuitous ARP의 구체적인 패킷 형태와 운영체제 동작에는 차이가 있을 수 있다.
핵심은 다른 장비가 먼저 질문하기를 기다리지 않고 자신의 IPv4 주소와 MAC 주소 관계를 같은 L2 영역에 알린다는 점이다.
ㅁ 우편 비유를 네트워크 용어로 바꾸면
지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.
| 우편 시스템의 모습 | 네트워크 용어 | 의미 |
| 도시와 동네를 포함한 논리 주소 | IP Address | 호스트와 네트워크를 식별하고 라우팅에 사용하는 주소 |
| 현재 동네에서 실제 문을 찾는 주소 | MAC Address | 이더넷 구간에서 인터페이스를 식별하는 L2 주소 |
| “이 IP 주소의 주인은 누구인가?” | ARP Request | IPv4 주소에 대응하는 MAC 주소를 묻는 브로드캐스트 |
| “이 IP는 이 MAC에 있다” | ARP Reply | 요청한 주소의 대응 관계를 알려 주는 응답 |
| 동네 전체에 묻는 공지 | Ethernet Broadcast | 목적지 MAC FF:FF:FF:FF:FF:FF로 전달하는 프레임 |
| 잠시 적어 둔 이웃 주소록 | ARP Cache / Neighbor Table | IP와 MAC 주소의 대응 관계를 임시 저장한 정보 |
| 요청 없이 새 위치를 알림 | Gratuitous ARP | 자신의 IP와 MAC 관계를 주변에 알리는 ARP |
| 거짓 주소 안내 | ARP Spoofing | 잘못된 IP-MAC 관계를 학습시키는 공격 |
ARP의 전체 동작은 다음처럼 정리할 수 있다.
1. 목적지 또는 다음 홉 IPv4 주소를 결정한다.
2. Neighbor Table에서 대응하는 MAC 주소를 찾는다.
3. 정보가 없으면 ARP Request를 Broadcast한다.
4. 주소의 주인이 ARP Reply로 자신의 MAC 주소를 알린다.
5. 결과를 Cache에 저장한다.
6. 알아낸 MAC 주소로 Ethernet Frame을 만들어 전송한다.
ㅁ 직접 관찰해 보기
같은 IPv4 네트워크에 있는 장비의 주소를 알고 있다면 ARP 동작을 직접 확인할 수 있다.
Linux에서 현재 이웃 테이블을 확인한다.
ip neigh show
같은 네트워크의 아직 통신하지 않은 주소로 ping을 보내기 전과 후의 결과를 비교해 보자.
ping -c 1 192.168.10.20
ip neigh show 192.168.10.20
실제 인터페이스가 eth0이라면 다른 터미널에서 ARP 패킷을 관찰할 수 있다.
sudo tcpdump -n -e -i eth0 arp
출력에서는 다음과 비슷한 흐름을 찾는다.
ARP, Request who-has 192.168.10.20 tell 192.168.10.10
ARP, Reply 192.168.10.20 is-at bb:bb:bb:bb:bb:bb
macOS에서는 이웃 정보를 다음 명령으로 볼 수 있다.
arp -a
운영체제, 권한, 네트워크 캐시 상태에 따라 ARP Request가 바로 보이지 않을 수 있다.
이미 캐시된 항목이 있다면 운영체제가 그 정보를 사용하기 때문이다.
운영 중인 시스템에서 캐시를 강제로 삭제하면 짧은 통신 단절이나 예상하지 못한 재조회가 발생할 수 있으므로,
관찰을 위해 무리하게 상태를 변경하지 않는다.
IPv6에서는 ARP를 사용하지 않고 ICMPv6 기반의 Neighbor Discovery Protocol(NDP)을 사용한다.
따라서 IPv6 트래픽만 있는 환경에서 ARP가 보이지 않는 것은 정상이다.
ㅁ 핵심 정리
- IP 주소는 논리적인 목적지를 나타내고 MAC 주소는 현재 이더넷 구간의 수신 인터페이스를 나타낸다.
- 같은 IPv4 네트워크에서 목적지 MAC 주소를 모르면 ARP Request를 브로드캐스트한다.
- 대상 IP 주소의 주인은 ARP Reply로 자신의 MAC 주소를 알린다.
- 알아낸 IP-MAC 관계는 ARP Cache 또는 Neighbor Table에 임시로 저장된다.
- ARP Request는 라우터를 넘어가지 않으며 같은 Broadcast Domain 안에서 동작한다.
- 원격 목적지에는 서버의 MAC이 아니라 현재 링크의 다음 홉인 기본 게이트웨이 MAC으로 프레임을 보낸다.
- ARP에는 기본 인증 절차가 없어 ARP Spoofing의 대상이 될 수 있다.
- IPv6는 ARP 대신 ICMPv6 기반 NDP를 사용한다.
핵심 용어: IP Address, MAC Address, ARP, ARP Request, ARP Reply, Ethernet Broadcast, ARP Cache, Neighbor Table, Opcode, Gratuitous ARP, ARP Spoofing, NDP
ARP는 최종 목적지를 찾는 프로토콜이 아니다. 현재 이더넷 구간에서 다음으로 프레임을 받을 이웃의 MAC 주소를 찾는 프로토콜이다.
ㅁ 다음 이야기
ARP를 사용하면 IP 주소에 대응하는 MAC 주소를 알아낼 수 있다.
하지만 ARP Request는 같은 Broadcast Domain 안에서만 전달된다.
따라서 PC는 ARP를 보내기 전에 목적지가 같은 동네에 있는지, 라우터 너머의 다른 동네에 있는지 먼저 판단해야 한다.
IP 주소만 보고 그 경계를 어떻게 알 수 있을까?
다음 글에서는 「같은 동네와 다른 동네는 누가 판단할까?」라는 질문을 통해
IPv4 Address, Subnet Mask, Prefix Length, Network Address와 AND 연산을 살펴본다.
'DevOps > Network' 카테고리의 다른 글
| [Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까? (0) | 2026.07.16 |
|---|---|
| [Network] 07. 같은 동네와 다른 동네는 누가 판단할까? (0) | 2026.07.15 |
| [Network] 05. 한 건물을 여러 동네로 나눌 수 있을까? (1) | 2026.07.15 |
| [Network] 04.길이 원을 그리면 편지는 왜 끝없이 늘어날까? (0) | 2026.07.15 |
| [Network] 03. 스위치는 어떻게 편지가 갈 길을 기억할까? (0) | 2026.07.15 |
