이더넷 프레임 데이터가 포장되는 방식을 이해하기

이더넷 프레임 구조

이더넷 프레임 구조: 데이터가 포장되는 방식 이해하기

10년 넘게 현장에서 네트워크 장애를 대응하면서 느낀 건, 대부분의 문제는 결국 프레임 하나를 잘못 해석하거나 프레임이 어디서 깨졌는지 못 잡아서 생긴다는 거다. L2 계층이 "기초 중의 기초"라고 치부되곤 하는데, 솔직히 이더넷 프레임 구조를 손으로 그릴 수 있는 개발자를 현장에서 많이 보지 못했다. 이 글은 교과서식 나열이 아니라, 실제 내가 손을 데어 가면서 익힌 감각을 글로 옮긴 것이다.

---

이더넷 프레임이란 무엇인가: 택배 상자 비유

이더넷 프레임을 처음 이해할 때 가장 유용했던 비유는 택배 상자다. 내용물(데이터)을 보내려면 그냥 던질 수 없다. 받는 사람 주소, 보내는 사람 주소, 내용물 유형(파손 주의인지 냉동 식품인지), 그리고 박스가 도중에 찌그러지지 않았는지 확인할 검수 스티커까지 붙여야 한다. 이더넷 프레임이 딱 그 구조다.

프레임은 물리 계층(케이블, 빛, 전파)을 타고 이동하는 데이터의 최소 단위인데, 이게 없으면 스위치는 패킷을 어디로 보내야 할지 알 방법이 없다. 상자 겉면에 주소가 없는 택배를 물류센터 직원이 어떻게 분류하겠나. 그것과 완전히 같은 이야기다.

직접 경험한 일인데, 초기에 네트워크 문제가 생겼을 때 상위 팀에서 "IP 설정 문제 아니냐"고 먼저 의심했다. 근데 실제로 Wireshark를 켜보니 프레임 자체가 이상하게 잘려서 도착하고 있었다. 그때 "아, 문제는 L3 위가 아니라 L2 아래에 있구나"를 처음으로 피부로 느꼈다. 그 이후로 장애가 나면 제일 먼저 프레임 레벨부터 확인하는 습관이 생겼다. 이더넷 프레임의 개념을 모르는 사람은 이 과정 자체를 건너뛴다. 처음부터 추상화된 레이어만 보다 보면, 문제의 근원이 가장 아래 계층에 있을 때 손을 못 쓰게 된다. 비유가 거창해 보여도, 실제로 이 택배 박스 개념을 머릿속에 넣고 있는 사람과 그렇지 않은 사람의 장애 대응 속도 차이는 크다.

---

프레임 구조 분해: 도시락통 칸칸이 나눠진 것처럼

이더넷 프레임은 크게 다음 필드로 구성된다. 도시락통을 떠올리면 된다. 각 칸에 밥, 반찬, 국이 따로 담기듯, 프레임도 역할별로 칸이 나뉜다.

Preamble (7바이트) + SFD (1바이트)
수신 측에게 "야, 데이터 온다, 준비해" 하고 알리는 신호다. 실제 데이터가 아니라 타이밍 동기화 목적이다. 알람 소리가 울리면 눈을 뜨는 것처럼 수신 측이 준비 태세를 갖춘다.

Destination MAC Address (6바이트)
받는 사람 주소다. 스위치가 이 값을 보고 어느 포트로 내보낼지 결정한다.

Source MAC Address (6바이트)
보내는 사람 주소다. 스위치는 이 값으로 MAC 테이블을 학습한다.

EtherType / Length (2바이트)
도시락통 뚜껑에 "오늘은 한식입니다"라고 써진 것과 같다. IPv4인지 IPv6인지 ARP인지 이 필드가 알려준다.

Payload (46~1500바이트)
실제 내용물이다. 최소 46바이트를 채우지 못하면 패딩을 채워 넣는다.

FCS (4바이트)
Frame Check Sequence다. 수신 측이 데이터가 깨졌는지 확인하는 체크섬이다. 택배 검수 스티커가 훼손됐으면 반품처리하듯, FCS가 맞지 않으면 프레임은 버려진다.

+----------+-----+------------------+------------------+-----------+---------+-----+
|Preamble  | SFD | Dst MAC (6B)     | Src MAC (6B)     | EtherType | Payload | FCS |
| 7 bytes  | 1B  | FF:FF:FF:FF:FF:FF| AA:BB:CC:DD:EE:FF| 0x0800    | 46~1500B| 4B  |
+----------+-----+------------------+------------------+-----------+---------+-----+

현장에서 신입 때 이 구조를 처음 배웠을 때는 그냥 시험용 암기 대상이었다. 근데 어느 날 점보 프레임(Jumbo Frame) 설정을 잘못 건드렸다가 일부 구간에서 패킷이 드랍되는 사고가 났다. MTU 값이 맞지 않아서 페이로드가 너무 커진 것이었는데, 이 구조를 모르는 동료는 "인터넷이 불안정하다"고만 했다. 반면 프레임 구조를 알고 있던 나는 10분 만에 페이로드 크기 문제를 의심하고 설정을 찾아냈다. 각 필드의 역할을 아는 것만으로도 디버깅의 출발점이 달라진다. 사람들이 이 구조를 "외워야 할 것"으로만 여기는 게 아쉽다. 실제로는 네트워크에서 뭔가 이상할 때 "어느 칸이 문제인가"를 따져보는 사고 도구에 가깝다.

---

MAC 주소의 실체: 주민등록번호가 아니라 호텔 방번호

많은 사람들이 MAC 주소를 "절대로 바뀌지 않는 하드웨어 고유 주소"라고 알고 있다. 원칙은 맞다. 제조사가 NIC에 굽는 값이고, 앞 3바이트는 OUI(제조사 식별자), 뒤 3바이트는 고유 번호다. 그런데 현장에서는 좀 다른 이야기를 한다.

나는 MAC 주소를 호텔 방번호에 비유한다. 체크인할 때는 305호라는 방이 있고, 내가 그 방을 쓰지만, 다음 손님이 오면 같은 방번호를 다른 사람이 쓴다. MAC spoofing이 그거다. 소프트웨어적으로 MAC 주소를 바꿔버리면, 스위치는 전혀 모른다. 실제로 보안 이슈 대응을 하면서 MAC 변조 공격을 추적한 적이 있었는데, 처음에 "MAC은 안 바뀌잖아요"라고 하던 주니어가 로그를 보고 나서 얼굴이 새하얘지더라.

그 이후로 나는 MAC 주소를 신뢰의 절대 기준으로 삼지 않는다. 보안 구성을 설계할 때 MAC 주소만 믿으면 안 된다는 걸 그 경험에서 배웠다. MAC 주소 기반 접근 제어(MAC ACL)만으로 보안을 구성한 네트워크를 봤을 때, 솔직히 걱정부터 앞선다. 공격자가 합법적인 장비의 MAC 주소를 복사해서 쓰는 건 툴 하나면 5분이면 끝난다. MAC 주소는 편리한 식별 수단이지, 신뢰할 수 있는 인증 수단이 아니다. 이 차이를 현장에서 이해하느냐 못 하느냐는 보안 설계의 질에 직접 영향을 준다.

---

FCS의 역할: 계약서 마지막 도장

FCS는 CRC-32 알고리즘으로 계산된 4바이트 값이다. 송신 측이 프레임 전체(헤더+페이로드)를 계산해서 붙이고, 수신 측이 다시 계산해서 비교한다. 다르면 그냥 드랍된다. 재전송 요청도 없다. L2에는 재전송 메커니즘이 없기 때문에 상위 프로토콜(TCP)이 그걸 처리한다.

계약서에 최종 도장이 하나 틀려있으면 무효처리하는 것과 같다. 내용은 다 맞아도 도장 하나 때문에 날아간다. 현장에서 물리 케이블 불량이나 전기 잡음이 심할 때 FCS 오류율이 치솟는 걸 보면서, 이 4바이트가 얼마나 중요한 역할을 하는지 체감했다.

실제로 어느 날 특정 서버에서만 패킷 유실이 일어났을 때, 상위 팀은 라우팅 문제라고 했다. 근데 Wireshark를 잡아보니 FCS 오류가 폭발하고 있었다. 케이블 불량이었다. 라우팅 설정을 열 번 뒤져봐도 안 나왔을 문제를, FCS 오류를 알아보는 눈이 있었기 때문에 10분 만에 찾았다. 숫자 4바이트가 네트워크 품질 지표가 된다는 게 처음엔 실감이 안 났다. 지금은 FCS 오류율만 봐도 해당 물리 구간에 문제가 있는지 없는지 바로 감이 온다. FCS를 "그냥 체크섬"으로만 알고 넘어가면, 케이블 문제를 소프트웨어 문제로 오판하는 실수를 하게 된다.

---

실제 프레임 캡처: Wireshark로 직접 보는 법

아래는 Wireshark 또는 tcpdump로 실제 이더넷 프레임을 캡처하고 분석하는 예제다. 터미널에서 바로 실행 가능하다.

# tcpdump로 이더넷 프레임 헤더 포함 캡처 (Linux/macOS)
sudo tcpdump -i eth0 -e -XX -c 10

# 특정 호스트로 가는 ARP 프레임만 캡처
sudo tcpdump -i eth0 -e arp

# 파일로 저장 후 Wireshark에서 분석
sudo tcpdump -i eth0 -w capture.pcap

# Python으로 raw 소켓 이용해 이더넷 프레임 수동 구성 (Linux root 필요)
import socket
import struct

# 소켓 생성 (raw ethernet)
sock = socket.socket(socket.AF_PACKET, socket.SOCK_RAW)
sock.bind(("eth0", 0))

# 이더넷 프레임 직접 구성
dst_mac = b'\xff\xff\xff\xff\xff\xff'  # 브로드캐스트
src_mac = b'\xaa\xbb\xcc\xdd\xee\xff'  # 출발지 MAC (예시)
ethertype = b'\x08\x00'                 # IPv4
payload = b'Hello, L2 World!' + b'\x00' * 30  # 최소 46바이트 패딩

frame = dst_mac + src_mac + ethertype + payload
sock.send(frame)
print(f"Frame sent: {len(frame)} bytes")

책으로 백 번 읽는 것보다 실제 패킷 하나를 직접 해부하는 게 훨씬 빠르게 몸에 밴다. 처음 Wireshark를 켜서 프레임을 캡처했을 때, 교과서에서만 보던 필드들이 실제로 눈앞에 나타나는 걸 보고 "아, 이게 진짜구나"라는 느낌을 받았다. 나는 지금도 새로운 프로토콜을 공부할 때 반드시 패킷 캡처부터 한다. 개념이 아무리 복잡해도, 실제 프레임을 눈으로 보면 정리가 된다. tcpdump나 Wireshark를 처음 쓰는 사람에게는 처음엔 너무 많은 정보가 쏟아져서 당황스러울 수 있다. 그래서 나는 처음에 ARP 패킷만 필터링해서 보는 걸 권한다. 구조가 단순하고, 필드가 명확하게 보여서 시작점으로 좋다. 이더넷 프레임 캡처 능력은 단순한 기술이 아니라, 네트워크를 읽는 언어를 익히는 것과 같다.

---

현장에서 느낀 장점: 문제의 근원을 바로 찾는 힘

이더넷 프레임 구조를 제대로 이해하고 나면 장애 대응 속도가 확실히 달라진다. 어느 날 특정 서버에서만 패킷 유실이 일어났는데, 상위 팀은 라우팅 문제라고 했다. 근데 Wireshark를 잡아보니 FCS 오류가 폭발하고 있었다. 케이블 불량이었다. 라우팅 설정을 열 번 뒤져봐야 안 나왔을 문제를, 프레임 구조를 알고 있었기 때문에 10분 만에 찾았다.

또 하나, 점보 프레임(Jumbo Frame) 설정 문제도 있었다. MTU를 9000으로 키웠는데 일부 구간에서 드랍이 생겼다. 프레임 크기와 페이로드 최대값을 이해하고 있으면 바로 MTU 미스매치를 의심할 수 있다. 모르면 그냥 "인터넷이 느리다"로 끝나버린다.

---

현장에서 느낀 단점: 추상화가 너무 잘 돼 있어서 생기는 문제

솔직히 말하면, 요즘 개발 환경에서는 이더넷 프레임을 직접 다룰 일이 거의 없다. OS가, 드라이버가, 라이브러리가 다 알아서 처리한다. 그래서 역설적으로 추상화가 너무 잘 돼 있어서, 뭔가 이상해도 "왜 이상한지" 모르는 개발자가 늘어난다.

내가 신입 때 VLAN 태깅된 환경에서 802.1Q 헤더 때문에 프레임 크기가 4바이트 늘어나는 걸 몰라서 한참 헤맸다. 나중에 알고 보면 별것도 아닌데, 개념 없이 현장에 들어가면 이런 것들에서 막힌다. 기초가 없으면 도구가 뭘 하는지 이해 못 하고, 도구가 실패했을 때 손을 못 쓴다. 추상화는 생산성을 높여주지만, 동시에 문제 해결 능력의 하한선을 낮춘다. 기초를 아는 사람은 추상화 위에서도 잘 다루고, 추상화가 실패했을 때도 직접 대응할 수 있다.

---

마무리: 데이터가 포장되는 방식을 알면 보이는 것들

이더넷 프레임 구조를 처음 배울 때는 그냥 암기 대상이었다. 시험 문제 나오니까. 근데 10년 지나고 돌아보니, 이게 네트워크의 거의 모든 것의 출발점이다. MAC 주소 없으면 스위칭 없고, FCS 없으면 신뢰성 없고, EtherType 없으면 상위 프로토콜 구분을 못 한다. 프레임 하나에 L2가 하는 일의 전부가 담겨 있다.

그리고 현장에서는 "이론은 알겠는데 실제로는 어떻게요?"라는 질문을 자주 받는다. 답은 간단하다. Wireshark 켜고 프레임 하나 잡아서 직접 필드를 눈으로 확인하는 것. 책으로 백 번 읽는 것보다 실제 패킷 하나 직접 해부하는 게 훨씬 빠르게 몸에 밴다. 나는 지금도 새로운 프로토콜을 공부할 때 반드시 패킷 캡처부터 한다. 그게 10년 넘게 쌓아온 내 나름의 방식이다.

이더넷 프레임은 네트워크 통신의 가장 작은 단위지만, 이 안에 네트워크가 어떻게 작동하는지의 철학이 다 들어있다. 작은 것에서 큰 그림을 읽는 능력, 그게 L2를 제대로 이해하는 사람이 가진 무기다.

---

출처 및 참고 경로

• IEEE 802.3 이더넷 표준: https://standards.ieee.org/ieee/802.3
• Wireshark 공식 문서: https://www.wireshark.org/docs/
• Cisco - Ethernet Frame Format: https://www.cisco.com/c/en/us/support/docs/networking/802-11-wireless-lan-technologies/116467-technote-802.html
• Python socket 공식 문서 (AF_PACKET): https://docs.python.org/3/library/socket.html
• tcpdump 공식 매뉴얼: https://www.tcpdump.org/manpages/tcpdump.1.html