L2 계층 완전 정복 : MAC 주소의 왜 세상에 하나뿐인 주소가 필요한가?

네트워크를 이해하기 위한 참조 이미지

MAC 주소의 비밀: 왜 세상에 하나뿐인 주소가 필요한가?

10년 넘게 소프트웨어를 만지면서 처음 몇 년은 MAC 주소를 그냥 "네트워크 카드에 붙어있는 고유 번호" 정도로만 알았다. 실제로 그 수준으로도 개발하는 데 별 지장이 없었다. 그런데 어느 날 현장에서 네트워크 장애가 터졌을 때 처음으로 MAC 주소가 어떻게 움직이는지 직접 추적해야 하는 상황이 왔다. 그때 비로소 이게 단순한 식별자가 아니라 L2 통신 전체를 떠받치는 기둥이라는 걸 느꼈다. 주민등록번호처럼 외부에서 부여하는 게 아니라, 태어날 때부터 칩에 새겨진 지문 같은 것이었다.

---

MAC 주소가 뭔지, 교과서 말고 현장 언어로

MAC 주소는 Media Access Control Address의 줄임말이다. 48비트, 16진수 6쌍으로 표현된다. 예를 들면 이렇게 생겼다.

AA:BB:CC:DD:EE:FF

앞 3바이트 (OUI): AA:BB:CC → 제조사 식별자 (IEEE에서 할당)
뒤 3바이트 (NIC): DD:EE:FF → 제조사가 개별 장치에 부여하는 일련번호

예시: 00:1A:2B:3C:4D:5E
  → 00:1A:2B = 특정 제조사 (Wireshark OUI 조회로 확인 가능)
  → 3C:4D:5E = 그 제조사가 만든 n번째 NIC 카드

공장에서 NIC(Network Interface Card)를 만들 때 ROM에 이 주소를 구워 넣는다. 물리적으로 변경이 불가능하도록 설계된 번호다. 세상 어느 도시의 어느 건물에 있는 장비든, 이 번호가 같은 장비는 없어야 한다는 게 설계 원칙이다.

처음 이 개념을 배웠을 때 솔직히 "그냥 IP 주소 하나면 되는 거 아닌가?" 싶었다. 그런데 실제로 사무실 네트워크 장비를 교체하는 작업을 도운 적이 있었는데, 교체한 스위치가 자꾸 이상하게 동작하는 거였다. 나중에 보니 기존 장비의 MAC 주소가 다른 시스템에 하드코딩돼 있어서 새 장비를 못 알아보는 상황이었다. 그때 처음으로 "아, 이 번호가 단순한 식별자가 아니구나" 싶었다. 자동차의 VIN 번호처럼, MAC 주소는 장비의 신분증이나 다름없다.

한 가지 중요하게 짚고 싶은 건, 교과서에서는 MAC 주소를 "절대 바뀌지 않는 고유 번호"라고 가르치는 경우가 많다는 점이다. 하지만 실제로는 소프트웨어적으로 바꿀 수 있다(MAC 스푸핑). 처음 배울 때 이 사실을 몰랐다면 나중에 보안 문제를 다룰 때 허를 찔릴 수 있다. "완벽한 고유성"이라는 말을 너무 믿으면 안 된다는 게 현장에서 배운 교훈이다.

---

L2에서 MAC 주소가 하는 실제 역할 - 스위치 옆에 앉아서 배운 것

L2 계층에서 통신은 IP 주소가 아니라 MAC 주소로 목적지를 찾는다. 이 사실이 처음엔 잘 안 와닿았다. IP 주소가 있는데 왜 MAC 주소가 또 필요하냐는 것이다.

비유하면 이렇다. IP 주소는 "서울시 강남구 역삼동 123번지"라는 우편 주소고, MAC 주소는 그 건물 안에서 "302호 거주자 홍길동"의 실제 얼굴이다. 우편은 주소로 건물까지 오지만, 건물 안에서 실제로 누구한테 전달할지는 얼굴을 보고 판단한다. 스위치가 하는 일이 그것이다. 같은 네트워크 안에서 어떤 포트에 어떤 MAC이 연결돼 있는지 기억해두고, 패킷이 오면 해당 포트로만 내보낸다.

/* 스위치의 MAC 주소 테이블 (CAM Table) 구조 예시 */

포트     MAC 주소            VLAN
----     ----------------    ----
Gi0/1    AA:BB:CC:11:22:33   10
Gi0/2    AA:BB:CC:44:55:66   10
Gi0/3    AA:BB:CC:77:88:99   20
Gi0/4    AA:BB:CC:AA:BB:CC   20

/* 스위치는 이 테이블을 보고 목적지 MAC에 해당하는 포트로만 프레임을 전송
   테이블에 없는 MAC이 오면? → 모든 포트로 플러딩(Flooding) */

실제로 네트워크 담당자 옆에 앉아서 스위치 CLI에 접속해 CAM 테이블을 처음 봤을 때 꽤 신선했다. MAC 주소와 포트 번호가 빼곡하게 정리돼 있었는데, 마치 건물 수위실의 출입 명부 같다는 느낌이었다. 어떤 기기가 어느 포트에 붙어있는지 실시간으로 알고 있다는 게 신기했다. 그리고 테이블에 없는 MAC이 오면 모든 포트로 일단 뿌린다(플러딩)는 것도 그때 처음 눈으로 확인했다.

스위치가 허브보다 낫다고 하는 이유가 바로 이 CAM 테이블 때문이다. 허브는 신호가 들어오면 아무 생각 없이 모든 포트에 뿌린다. 학교 방송처럼 전 교실에 다 들린다. 스위치는 목적지 MAC을 알면 딱 그 포트에만 보낸다. 장비가 수십, 수백 대인 환경에서 이 차이는 성능에 직결된다. 다만 스위치도 처음 통신하거나 테이블이 갱신되지 않은 경우엔 결국 플러딩을 한다는 점은 허브와 비슷한 한계다. "스위치는 무조건 완벽하다"는 생각은 버리는 게 좋다.

---

ARP가 없으면 MAC 주소는 그림의 떡이다

IP 주소는 아는데 MAC 주소를 모를 때 어떻게 할까. ARP(Address Resolution Protocol)가 그 다리 역할을 한다. 같은 네트워크 안에서 IP는 알지만 MAC을 모를 때 "이 IP 쓰는 사람 MAC 주소 알려줘"라고 브로드캐스트로 물어보는 것이다. 마치 카페에서 이름을 모르는 지인을 찾을 때 "혹시 여기 안경 쓰신 분 계세요?"라고 전체에 물어보는 것과 같다.

/* ARP 동작 과정 */

1. PC-A (IP: 192.168.1.10)가 PC-B (IP: 192.168.1.20)에 데이터 보내려 함
2. PC-A의 ARP 테이블에 192.168.1.20의 MAC이 없음
3. ARP Request 브로드캐스트 전송:
   "192.168.1.20을 쓰는 장비야, 네 MAC 주소 알려줘"
   → 목적지 MAC: FF:FF:FF:FF:FF:FF (브로드캐스트)
4. PC-B가 자신의 IP임을 인식하고 ARP Reply 유니캐스트 응답:
   "나야, 내 MAC은 AA:BB:CC:DD:EE:FF"
5. PC-A가 ARP 테이블에 저장 후 통신 시작

/* Windows에서 ARP 테이블 확인 */
arp -a

/* Linux/Mac에서 확인 */
arp -n
ip neigh show

ARP 때문에 실제로 골머리를 앓은 적이 있다. 특정 장비가 루프에 빠져서 ARP 패킷을 수만 개씩 뿌려대던 상황이었는데, 처음엔 왜 네트워크 전체가 느려지는지 전혀 몰랐다. Wireshark를 설치하고 패킷을 캡처해보니 ARP Request가 폭발적으로 쏟아지는 게 보였다. 어느 MAC에서 패킷이 발생하는지 추적해서 해당 포트를 내리고 나서야 네트워크가 정상으로 돌아왔다. 그 이후로 ARP를 가볍게 보지 않게 됐다.

ARP가 브로드캐스트 기반이라는 게 구조적으로 가진 약점이다. 같은 서브넷의 모든 장비가 ARP 요청을 전부 받는다는 뜻이기 때문이다. 장비가 수백 대인 환경에서 이 브로드캐스트가 계속 쌓이면 "브로드캐스트 스톰"이 발생할 수 있다. VLAN으로 브로드캐스트 도메인을 쪼개는 이유가 바로 여기에 있다. 또 ARP에는 인증 개념이 없어서 "ARP 스푸핑"이라는 공격도 가능하다. 즉, 가짜 ARP 응답을 먼저 보내서 트래픽을 가로채는 것이다. ARP 자체가 설계될 때 보안보다 편의성을 우선시했기 때문에 생기는 구조적 한계라고 본다.

---

MAC 스푸핑 - 지문을 위조하는 방법과 그 위험

MAC 주소가 ROM에 새겨졌다고 해서 변경이 절대 불가능한 건 아니다. OS 레벨에서 소프트웨어적으로 MAC을 바꿀 수 있다. 이걸 MAC 스푸핑이라고 한다. 여권의 사진을 바꾸는 것처럼, 외관상 다른 장비인 척 할 수 있다.

/* Linux에서 MAC 주소 일시 변경 (테스트/실습 용도) */

# 현재 MAC 확인
ip link show eth0

# 네트워크 인터페이스 내리기
sudo ip link set eth0 down

# MAC 주소 변경
sudo ip link set eth0 address AA:BB:CC:DD:EE:FF

# 인터페이스 올리기
sudo ip link set eth0 up

# 변경 확인
ip link show eth0

/* 주의: 재부팅하면 원래 MAC으로 돌아옴 (영구 변경은 별도 설정 필요) */
/* 실무에서는 보안 정책 확인 후 진행할 것 */

한번은 보안 점검 차원에서 테스트 환경에서 직접 MAC 스푸핑을 해본 적이 있다. 위 명령어 몇 줄만으로 2분도 안 걸렸다. "MAC 주소만 등록해두면 보안이 된다"고 생각하던 팀원에게 이걸 눈앞에서 보여줬을 때 꽤 충격을 받더라. 그 이후로 팀 내에서 802.1X 도입 논의가 진지하게 시작됐다. 직접 보여주는 것만큼 설득력 있는 방법은 없다는 걸 그때 다시 한 번 느꼈다.

합법적인 용도도 분명 있다. ISP 환경에서 공유기를 교체할 때 기존 MAC을 그대로 쓰거나, 개인정보 보호 목적으로 MAC을 랜덤하게 바꾸는 기능이 요즘 스마트폰에도 기본으로 들어있다. 하지만 "MAC 주소만으로 접근 제어"를 한다는 건 자물쇠 없는 철문과 다를 게 없다. 보안 설계를 할 때 MAC 주소를 신뢰의 근거로 삼는 순간 구멍이 생긴다. 반드시 802.1X 같은 인증서 기반의 접근 제어와 함께 써야 의미가 있다. MAC 스푸핑은 기술적으로 막기 어렵지만, 인증서는 위조가 훨씬 어렵기 때문이다. 이 차이를 이해하는 것이 네트워크 보안의 첫 걸음이라고 생각한다.

---

느낀점

10년 동안 소프트웨어를 만들면서 MAC 주소는 늘 배경 지식 어딘가에 있었다. 중요한 건 알았지만 왜 중요한지는 현장에서 실제로 장애를 겪고 패킷을 잡아보기 전까지 진짜로 이해하지 못했다.

교과서에서 읽는 MAC 주소와, Wireshark에서 실제로 ARP 브로드캐스트가 폭증하는 걸 눈으로 보면서 MAC을 추적하는 경험은 완전히 다르다. 이론을 먼저 배우고 나서 현장에서 "아 이게 그거구나" 하는 순간이 오는데, 그 순간이 올 때까지 포기하지 않는 게 중요한 것 같다. 나는 네트워크 쪽을 "내 영역이 아니다"라고 생각하던 시절이 있었는데, 지금 돌이켜보면 그 생각이 꽤 오랫동안 성장을 막았다.

추상 계층 아래를 알면 위에서 생기는 문제가 다르게 보이기 시작한다. L2를 모를 때는 네트워크 장애가 생기면 "네트워크 팀 문제"로 넘겼다. 지금은 패킷이 어떻게 흐르는지 그림이 그려지니까 문제가 생겼을 때 어디를 봐야 할지 감이 온다. 소프트웨어 개발자라도 네트워크 기초를 익혀두는 게 분명히 값어치가 있다. 그게 10년차가 되어서도 계속 배우게 되는 이유인 것 같다.

---

참고 자료 및 출처

• IEEE OUI(제조사 식별자) 조회: https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries
• Wireshark OUI 조회 도구: https://www.wireshark.org/tools/oui-lookup.html
• RFC 826 - ARP 표준 명세: https://datatracker.ietf.org/doc/html/rfc826
• Linux ip 명령어 공식 문서(iproute2): https://man7.org/linux/man-pages/man8/ip-link.8.html
• 802.1X 포트 기반 네트워크 접근 제어 표준: https://standards.ieee.org/ieee/802.1X/7345/
• Cisco - Understanding and Configuring VLANs: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/vlans.html