| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- Kubernetes
- 바이브코딩
- docker
- kotlin
- Spring
- LLM
- MySQL
- CKA
- minikube
- PETERICA
- Rag
- kotlin coroutine
- AI
- aws
- tucker의 go 언어 프로그래밍
- CKA 기출문제
- Claude
- golang
- Network
- SRE
- go
- AWS EKS
- Java
- 코틀린 코루틴의 정석
- 공부
- 오블완
- 기록으로 실력을 쌓자
- 정보처리기사 실기 기출문제
- 티스토리챌린지
- CloudWatch
- Today
- Total
피터의 개발이야기
[Network] 03. 스위치는 어떻게 편지가 갈 길을 기억할까? 본문

TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면
ㅁ 들어가며
앞의 글에서는 여러 컴퓨터가 하나의 통신 매체를 공유할 때 생기는 문제를 살펴보았다.
허브는 한 포트에서 받은 신호를 다른 모든 포트로 반복한다. 누구에게 가는 데이터인지 판단하지 않기 때문에 하나의 충돌 도메인을 모두가 공유한다.
그렇다면 중간 장치가 편지의 목적지를 읽고 필요한 방향으로만 보내면 어떨까?
문제는 중간 장치가 처음부터 각 컴퓨터의 위치를 알지 못한다는 점이다.
새 컴퓨터는 언제든 연결될 수 있고, 다른 포트로 옮겨질 수도 있다.
모든 주소와 위치를 사람이 미리 입력하는 방식은 불편하고 확장하기 어렵다.
스위치는 이 문제를 의외로 단순한 방법으로 해결한다.
편지를 보낸 사람의 위치를 보고 길을 배운다.
이번 글에서는 스위치가 MAC 주소를 학습하고, 목적지를 아는 프레임과 모르는 프레임을 어떻게 다르게 처리하는지 살펴본다.
ㅁ 우체국에 주소별 창구가 생겼다
네 집이 하나의 동네 우체국에 연결되어 있다고 생각해 보자.
민수의 집 ── 1번 길 ─┐
영희의 집 ── 2번 길 ─┤
동네 우체국
철수의 집 ── 3번 길 ─┤
지수의 집 ── 4번 길 ─┘
이 우체국에는 네 개의 배달길이 있지만 처음에는 어느 길 끝에 누가 사는지 모른다.
민수가 영희에게 편지를 보낸다.
편지는 1번 길을 통해 우체국에 들어온다. 봉투에는 두 가지 정보가 적혀 있다.
보낸 사람: 민수
받는 사람: 영희
우체국은 아직 영희가 어느 길에 있는지 모른다.
하지만 한 가지는 새로 알게 되었다.
민수의 편지가 1번 길에서 들어왔으니, 민수에게 가는 길은 1번이다.
우체국은 이 정보를 주소 장부에 적는다.
| 사람 | 연결된 길 |
| 민수 | 1번 |
스위치의 MAC 주소 학습도 이 장면과 같다.
ㅁ 스위치는 받는 사람이 아니라 보낸 사람을 보고 배운다
이더넷에서 데이터는 프레임(Ethernet Frame)이라는 단위로 전달된다.
프레임의 헤더에는 대표적으로 다음 두 주소가 들어 있다.
Source MAC Address : 보낸 장비의 MAC 주소
Destination MAC Address : 받을 장비의 MAC 주소
스위치는 프레임이 들어오면 먼저 출발지 MAC 주소(Source MAC Address)를 확인한다.
그리고 다음 관계를 기록한다.
이 프레임의 출발지 MAC 주소는 이 포트 방향에 있다.
예를 들어 다음 프레임이 1번 포트로 들어왔다고 하자.
Source MAC AA:AA:AA:AA:AA:AA
Destination MAC BB:BB:BB:BB:BB:BB
Ingress Port 1
스위치는 주소 테이블에 다음 정보를 추가한다.
| MAC 주소 | 포트 |
| AA:AA:AA:AA:AA:AA | 1 |
여기서 중요한 점이 있다.
스위치는 목적지 주소 BB:...를 보고 B가 있는 포트를 배우지 않는다. 목적지 주소에는 B가 실제로 어느 포트에 있는지 증명할 정보가 없기 때문이다.
반면 출발지 A의 프레임이 1번 포트로 직접 들어왔다는 사실은 A가 1번 포트 방향에 있다는 관찰 결과다.
그래서 스위치는 출발지 주소로 위치를 학습하고, 목적지 주소로 보낼 길을 결정한다.
ㅁ 목적지를 모르면 어떻게 해야 할까?
스위치는 A의 위치를 배웠지만 아직 B의 위치는 모른다.
그렇다고 프레임을 버리면 첫 통신은 영원히 시작할 수 없다.
스위치는 프레임이 들어온 포트를 제외한 나머지 모든 포트로 복사해 보낸다.
┌─ 2번 포트로 전송
1번 포트 ── 스위치 ─ 3번 포트로 전송
└─ 4번 포트로 전송
이를 Unknown Unicast Flooding이라고 한다.
- Unicast는 한 수신인에게 보내는 프레임이라는 뜻이다.
- Unknown은 목적지 MAC 주소가 테이블에 없다는 뜻이다.
- Flooding은 들어온 포트를 제외한 같은 네트워크의 다른 포트로 프레임을 보내는 동작이다.
B가 3번 포트에 연결되어 있다면 B는 프레임을 받아들인다. 목적지 주소가 자신과 다른 C와 D는 프레임을 받아들이지 않는다.
허브와 결과가 비슷해 보이지만 차이가 있다.
허브는 주소를 이해하지 못해 항상 신호를 반복한다. 스위치는 주소를 확인했지만 아직 목적지를 배우지 못했기 때문에 일시적으로 플러딩한다.
허브는 몰라도 계속 모두에게 보내고, 스위치는 모를 때만 모두에게 묻는다.
ㅁ 답장이 돌아오면 길이 완성된다
B가 A에게 답장을 보낸다.
답장 프레임은 3번 포트로 스위치에 들어온다.
Source MAC BB:BB:BB:BB:BB:BB
Destination MAC AA:AA:AA:AA:AA:AA
Ingress Port 3
스위치는 출발지 B의 주소를 보고 새로운 정보를 학습한다.
| MAC 주소 | 포트 |
| AA:AA:AA:AA:AA:AA | 1 |
| BB:BB:BB:BB:BB:BB | 3 |
이번에는 목적지 A의 주소가 테이블에 있다.
따라서 답장 프레임을 1번 포트로만 보낸다. 2번과 4번 포트에는 전달하지 않는다.
이 동작을 Known Unicast Forwarding이라고 한다.
B의 답장 → 3번 포트 → 스위치 → 1번 포트 → A
첫 편지에서는 목적지를 몰라 여러 방향으로 보냈지만, 한 번의 왕복이 일어난 뒤에는 A와 B의 위치를 모두 알게 되었다.
이후 두 장비 사이의 프레임은 필요한 포트로만 전달할 수 있다.
ㅁ 스위치의 주소 장부는 무엇일까?
스위치가 MAC 주소와 포트의 관계를 저장하는 장부를 보통 MAC Address Table이라고 한다.
환경과 문서에 따라 다음 이름도 사용한다.
- FDB(Forwarding Database): 프레임을 어느 포트로 전달할지 판단하는 데이터베이스
- CAM Table: 스위치가 주소 검색에 사용하는 메모리 방식에서 유래한 표현
세 용어는 문맥에 따라 조금씩 강조점이 다르지만, 입문 단계에서는 다음 장부를 가리킨다고 이해해도 충분하다.
MAC Address Port
AA:AA:AA:AA:AA:AA 1
BB:BB:BB:BB:BB:BB 3
CC:CC:CC:CC:CC:CC 2
스위치는 이 테이블을 사용해 목적지 MAC 주소가 어느 포트에 있는지 찾는다.
이 장부는 관리자가 모든 항목을 직접 작성하지 않아도 된다. 스위치가 실제 프레임을 관찰하며 동적으로 채운다.
이것이 MAC Learning이다.
ㅁ 장부를 영원히 믿어도 될까?
컴퓨터의 위치는 바뀔 수 있다.
노트북이 다른 포트에 연결될 수도 있고, 가상 머신이 다른 호스트로 이동할 수도 있다. 그런데 스위치가 예전 정보를 영원히 기억한다면 프레임을 잘못된 포트로 보낼 수 있다.
그래서 동적으로 학습한 MAC 주소 항목에는 유효 시간이 있다.
일정 시간 동안 해당 출발지에서 프레임이 들어오지 않으면 스위치는 오래된 항목을 삭제한다. 이를 Aging이라고 한다.
프레임 관찰
↓
MAC 주소와 포트 학습
↓
일정 시간 동안 다시 관찰되지 않음
↓
테이블에서 제거
삭제된 주소가 다시 통신하면 처음처럼 출발지 주소를 보고 새 위치를 학습한다.
이미 등록된 MAC 주소가 다른 포트에서 들어오면 스위치는 최신 관찰에 맞춰 포트 정보를 갱신할 수 있다.
스위치의 테이블은 고정된 주소록이 아니다.
현재 관찰한 네트워크의 모습을 잠시 기억한 지도에 가깝다.
ㅁ 브로드캐스트는 알고 있어도 모두에게 보낸다
Unknown Unicast는 목적지를 모르기 때문에 여러 포트로 보낸다.
하지만 처음부터 모두에게 전달하기 위한 프레임도 있다. 목적지 MAC 주소가 다음과 같은 Broadcast Address인 경우다.
FF:FF:FF:FF:FF:FF
스위치는 브로드캐스트 프레임을 들어온 포트를 제외한 같은 브로드캐스트 도메인의 다른 포트로 전달한다.
여기서 Unknown Unicast와 Broadcast의 차이를 구분해야 한다.
| 구분 | 여러 포트로 보내는 이유 |
| Unknown Unicast | 한 수신인에게 보내려 하지만 그 위치를 모름 |
| Broadcast | 처음부터 같은 네트워크의 모두에게 보내려 함 |
스위치가 MAC 주소를 모두 학습해도 브로드캐스트를 특정 포트 하나로만 보낼 수는 없다. 모든 장비에게 전달하는 것이 프레임의 목적이기 때문이다.
즉, 스위치는 불필요한 유니캐스트 전달을 줄이지만 브로드캐스트의 범위까지 자동으로 나누지는 않는다.
ㅁ 우편 비유를 네트워크 용어로 바꾸면
지금까지의 동작을 실제 네트워크 용어와 연결하면 다음과 같다.
| 우편 시스템의 모습 | 네트워크 용어 | 의미 |
| 봉투 | Ethernet Frame | 이더넷 구간에서 전달되는 데이터 단위 |
| 보낸 사람 주소 | Source MAC Address | 스위치가 장비의 위치를 학습하는 주소 |
| 받는 사람 주소 | Destination MAC Address | 스위치가 출력 포트를 결정할 때 조회하는 주소 |
| 편지가 들어온 길 | Ingress Port | 프레임이 스위치로 들어온 포트 |
| 주소별 배달 장부 | MAC Address Table / FDB | MAC 주소와 포트의 대응 관계 |
| 보낸 사람의 위치 기록 | MAC Learning | 출발지 MAC 주소를 수신 포트와 연결해 저장하는 동작 |
| 모르는 주소를 여러 길로 전달 | Unknown Unicast Flooding | 목적지 항목이 없을 때 다른 포트로 전송하는 동작 |
| 아는 주소의 길만 선택 | Known Unicast Forwarding | 테이블에 있는 목적지 포트로만 전달하는 동작 |
| 오래된 주소 기록 삭제 | Aging | 일정 시간 사용되지 않은 동적 항목을 제거하는 동작 |
스위치의 전체 판단 순서는 다음과 같이 정리할 수 있다.
1. 프레임을 받는다.
2. Source MAC Address를 Ingress Port와 함께 학습한다.
3. Destination MAC Address를 FDB에서 찾는다.
4-1. 목적지를 알면 해당 포트로 Forwarding한다.
4-2. 목적지를 모르면 들어온 포트를 제외하고 Flooding한다.
이 다섯 단계가 스위치의 기본 동작을 이해하는 뼈대다.
ㅁ 직접 따라가 보기
다음과 같이 세 장비가 스위치에 연결되어 있다고 가정해 보자.
A(AA:AA) ── Port 1
B(BB:BB) ── Port 2 ── Switch
C(CC:CC) ── Port 3
처음에는 FDB가 비어 있다. 아래 프레임이 차례로 들어올 때 테이블과 출력 포트가 어떻게 바뀌는지 적어 보자.
| 순서 | 들어온 포트 | 출발지 | 목적지 |
| 1 | 1 | AA:AA | BB:BB |
| 2 | 2 | BB:BB | AA:AA |
| 3 | 3 | CC:CC | AA:AA |
정답은 다음과 같다.
ㅇ 첫 번째 프레임
- AA:AA → Port 1을 학습한다.
- BB:BB는 아직 모르므로 Port 2와 Port 3으로 플러딩한다.
ㅇ 두 번째 프레임
- BB:BB → Port 2를 학습한다.
- AA:AA는 Port 1에 있으므로 Port 1로만 전달한다.
ㅇ 세 번째 프레임
- CC:CC → Port 3을 학습한다.
- AA:AA는 Port 1에 있으므로 Port 1로만 전달한다.
Linux가 브리지로 동작하는 환경이라면 다음 명령으로 커널의 FDB를 볼 수 있다.
bridge fdb show
특정 브리지의 항목만 보고 싶다면 다음처럼 확인한다.
bridge fdb show br br0
표시 형식과 지원 옵션은 Linux 및 iproute2 버전에 따라 다를 수 있다.
일반 PC가 단순한 호스트로만 동작하고 브리지가 없다면 학습된 FDB가 보이지 않는 것이 정상이다.
ㅁ 핵심 정리
- 스위치는 출발지 MAC 주소와 프레임이 들어온 포트를 연결해 학습한다.
- 목적지 MAC 주소는 전달할 출력 포트를 결정하는 데 사용한다.
- 목적지를 알면 해당 포트로만 Known Unicast Forwarding한다.
- 목적지를 모르면 들어온 포트를 제외한 다른 포트로 Unknown Unicast Flooding한다.
- Broadcast Frame은 처음부터 모두에게 보내는 프레임이므로 학습이 끝나도 여러 포트로 전달된다.
- 동적으로 학습한 항목은 Aging을 통해 오래된 정보가 되기 전에 제거된다.
핵심 용어: Ethernet Frame, Source MAC, Destination MAC, Ingress Port, MAC Address Table, FDB, CAM Table, MAC Learning, Forwarding, Flooding, Aging
스위치는 목적지를 보고 배우지 않는다. 출발지를 보고 길을 배우고, 목적지를 보고 그 길을 선택한다.
ㅁ 다음 이야기
스위치는 프레임을 관찰하며 주소와 포트를 학습한다.
덕분에 이미 아는 목적지의 프레임은 필요한 길로만 보낼 수 있다.
그렇다면 스위치 사이에 여분의 길을 하나 더 만들면 더 안전해질까?
한 길이 끊어졌을 때 다른 길을 사용할 수 있으니 좋아 보인다.
하지만 두 길이 원을 만들면 브로드캐스트 프레임은 어느 지점에서 멈춰야 할까?
다음 글에서는 「길이 원을 그리면 편지는 왜 끝없이 늘어날까?」라는 질문을 통해 L2 Loop, Broadcast Storm, MAC Flapping과 STP가 필요한 이유를 살펴본다.
'DevOps > Network' 카테고리의 다른 글
| [Network] 05. 한 건물을 여러 동네로 나눌 수 있을까? (1) | 2026.07.15 |
|---|---|
| [Network] 04.길이 원을 그리면 편지는 왜 끝없이 늘어날까? (0) | 2026.07.15 |
| [Network] 02. 모두가 동시에 말하면 누가 들을 수 있을까? (0) | 2026.07.15 |
| [Network] 01. 컴퓨터 두 대를 연결하면 끝이 아니었을까? (0) | 2026.07.15 |
| [Network] TCP/IP를 우편 시스템으로 이해하기 (0) | 2026.07.15 |
