본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
본 콘텐츠의 이미지 및 내용을 무단으로 복제, 배포, 수정하여 사용할 경우 저작권법에 의해 법적 제재를 받을 수 있습니다.
이미지 로딩 중...
AI Generated
2025. 12. 5. · 16 Views
허브와 CSMA/CD 완벽 가이드
네트워크의 기초가 되는 허브의 동작 원리와 CSMA/CD 프로토콜을 초급 개발자도 이해할 수 있도록 쉽게 설명합니다. 물리 계층에서 데이터가 어떻게 전달되고, 충돌은 어떻게 해결되는지 실무 관점에서 알아봅니다.
목차
1. 물리 계층에서의 주소 개념
김개발 씨는 신입 시절, 네트워크 교육을 받다가 강사에게 질문을 던졌습니다. "IP 주소는 알겠는데, 물리 계층에서는 주소가 없다고요?
그러면 데이터가 어떻게 목적지를 찾아가나요?" 강사는 빙긋 웃으며 대답했습니다. "좋은 질문입니다.
바로 그게 핵심이에요."
물리 계층은 OSI 7계층 중 가장 아래에 위치하며, 실제 전기 신호나 빛 신호를 전송하는 역할을 합니다. 이 계층에서는 놀랍게도 주소라는 개념이 존재하지 않습니다.
마치 확성기로 소리를 지르면 근처에 있는 모든 사람이 듣게 되는 것처럼, 물리 계층의 신호는 연결된 모든 장치에게 전달됩니다.
다음 코드를 살펴봅시다.
# 물리 계층의 신호 전송을 시뮬레이션
class PhysicalLayer:
def __init__(self):
self.connected_devices = [] # 연결된 모든 장치
def connect(self, device):
# 새 장치를 물리적으로 연결
self.connected_devices.append(device)
def send_signal(self, signal, sender):
# 핵심: 주소 없이 모든 장치에 신호 전달
for device in self.connected_devices:
if device != sender: # 자기 자신 제외
device.receive(signal) # 모두에게 브로드캐스트
김개발 씨는 입사 첫 주, 회사에서 진행하는 네트워크 기초 교육에 참석했습니다. 강사가 칠판에 OSI 7계층을 그리며 설명을 시작했습니다.
"자, 맨 아래 계층이 바로 물리 계층입니다." 김개발 씨는 손을 들었습니다. "강사님, 그런데 물리 계층에서는 데이터가 어떻게 원하는 컴퓨터에 도착하나요?
IP 주소 같은 게 있나요?" 강사는 고개를 저었습니다. "아뇨, 물리 계층에는 주소라는 개념 자체가 없습니다." 이 말을 들은 김개발 씨는 당황했습니다.
주소가 없는데 어떻게 데이터가 전달된다는 걸까요? 쉽게 비유하자면, 물리 계층은 마치 광장에서 확성기로 외치는 것과 같습니다.
누군가가 확성기를 들고 "안녕하세요!"라고 외치면, 광장에 있는 모든 사람이 그 소리를 듣게 됩니다. 특정 사람에게만 소리가 전달되는 게 아니라, 근처에 있는 모든 사람의 귀에 들어가는 것이죠.
네트워크에서도 마찬가지입니다. 물리 계층에서 한 컴퓨터가 전기 신호를 보내면, 같은 네트워크에 연결된 모든 컴퓨터가 그 신호를 수신합니다.
이것을 브로드캐스트라고 합니다. 그렇다면 의문이 생깁니다.
모든 컴퓨터가 신호를 받으면 혼란스럽지 않을까요? 바로 이 문제를 해결하기 위해 상위 계층들이 존재합니다.
2계층인 데이터 링크 계층에서는 MAC 주소를 사용하고, 3계층인 네트워크 계층에서는 IP 주소를 사용합니다. 하지만 물리 계층 자체는 오직 "신호를 전기적으로 전달하는 것"만 담당합니다.
위의 코드를 살펴보면, send_signal 메서드가 핵심입니다. 신호를 보낼 때 목적지 주소를 지정하지 않고, 단순히 connected_devices에 있는 모든 장치에게 신호를 전달합니다.
이것이 바로 물리 계층의 본질입니다. 실제 현업에서 네트워크 문제를 디버깅할 때, 이 개념을 이해하는 것이 중요합니다.
예를 들어 패킷 스니핑 도구가 동작하는 원리도 바로 이것입니다. 물리 계층에서는 모든 신호가 모든 장치에 전달되기 때문에, 자신에게 온 것이 아닌 데이터도 엿볼 수 있는 것입니다.
강사의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 상위 계층이 필요한 거군요.
물리 계층만으로는 특정 대상에게 데이터를 보낼 수 없으니까요." 물리 계층의 이런 특성을 이해하면, 앞으로 배울 허브와 CSMA/CD가 왜 필요한지 자연스럽게 알 수 있습니다.
실전 팁
💡 - 물리 계층은 주소 없이 신호만 전달하는 "바보 같은" 계층이라고 기억하세요
- 패킷 스니핑이 가능한 이유가 바로 물리 계층의 브로드캐스트 특성 때문입니다
2. 허브란 무엇인가
김개발 씨가 서버실에 처음 들어갔을 때, 랙에 꽂힌 수많은 장비들이 눈에 들어왔습니다. "저건 스위치고, 저건 라우터인데...
어? 저 낡은 장비는 뭐죠?" 옆에 있던 박시니어 씨가 대답했습니다.
"아, 저건 허브야. 요즘은 거의 안 쓰지만, 네트워크의 역사를 이해하려면 알아둬야 해."
**허브(Hub)**는 여러 대의 컴퓨터를 연결하는 가장 단순한 네트워크 장비입니다. 마치 멀티탭처럼 여러 개의 포트를 제공하며, 한 포트로 들어온 신호를 나머지 모든 포트로 복사해서 내보냅니다.
물리 계층에서 동작하기 때문에 주소를 확인하지 않고 무조건 신호를 전파합니다.
다음 코드를 살펴봅시다.
# 허브의 동작 원리를 시뮬레이션
class Hub:
def __init__(self, num_ports):
self.ports = [None] * num_ports # 포트 배열
self.port_count = num_ports
def connect_device(self, port_num, device):
# 특정 포트에 장치 연결
self.ports[port_num] = device
def receive_frame(self, from_port, frame):
# 핵심: 수신한 포트를 제외한 모든 포트로 전송
print(f"허브: {from_port}번 포트에서 신호 수신")
for port_num, device in enumerate(self.ports):
if port_num != from_port and device is not None:
print(f"허브: {port_num}번 포트로 신호 전송")
device.receive(frame) # 무조건 모두에게 전달
박시니어 씨는 김개발 씨를 서버실 한쪽 구석으로 데려갔습니다. 거기에는 먼지가 쌓인 오래된 장비가 놓여 있었습니다.
"이게 바로 허브야. 1990년대에는 이게 네트워크의 핵심 장비였어." 김개발 씨가 장비를 자세히 살펴봤습니다.
앞면에 여러 개의 포트가 있고, LED 불빛이 깜빡이고 있었습니다. 일반 스위치와 비슷해 보였습니다.
"스위치랑 뭐가 다른 건가요?" 박시니어 씨가 설명을 시작했습니다. "허브는 정말 단순한 장비야.
그냥 전기 신호를 복사해서 뿌리는 것밖에 할 줄 몰라." 쉽게 비유하자면, 허브는 마치 교실의 확성기와 같습니다. 선생님이 마이크에 대고 말하면, 교실 전체에 스피커로 소리가 퍼지죠.
특정 학생에게만 소리가 가는 게 아니라 모든 학생이 듣게 됩니다. 허브도 마찬가지로, 한 컴퓨터가 보낸 데이터를 연결된 모든 컴퓨터에게 전달합니다.
이런 방식에는 장점도 있습니다. 구조가 단순하기 때문에 저렴하고, 설치와 관리가 쉽습니다.
초창기 네트워크에서는 이것만으로도 충분했습니다. 하지만 심각한 단점도 있습니다.
데이터가 모든 포트로 전달되기 때문에 대역폭이 공유됩니다. 10Mbps 허브에 4대의 컴퓨터가 연결되어 있다면, 실제로 각 컴퓨터가 사용할 수 있는 대역폭은 10Mbps를 나눠 써야 합니다.
위의 코드에서 receive_frame 메서드를 보면, 허브의 동작 원리가 명확하게 드러납니다. from_port로 들어온 프레임을 나머지 모든 포트로 그대로 전송합니다.
주소를 확인하는 로직이 전혀 없습니다. 이것이 허브가 물리 계층 장비인 이유입니다.
실제로 Wireshark 같은 패킷 분석 도구로 네트워크를 모니터링할 때, 허브 환경에서는 네트워크의 모든 트래픽을 볼 수 있습니다. 이는 보안 관점에서 큰 취약점이 됩니다.
김개발 씨가 물었습니다. "그러면 왜 요즘은 허브를 안 쓰나요?" 박시니어 씨가 대답했습니다.
"성능도 문제지만, 가장 큰 문제는 충돌이야. 여러 컴퓨터가 동시에 데이터를 보내면 신호가 섞여버리거든.
이 문제를 해결하기 위해 CSMA/CD가 나왔고, 결국은 스위치가 허브를 대체했지."
실전 팁
💡 - 허브는 물리 계층에서 동작하며, 주소를 이해하지 못합니다
- 허브 환경에서는 보안에 특히 주의해야 합니다 - 모든 트래픽이 모든 장치에 노출됩니다
3. 허브의 특징과 동작 방식
김개발 씨는 허브의 개념을 이해했지만, 실제로 어떻게 동작하는지 더 자세히 알고 싶었습니다. "박시니어 님, 허브가 신호를 복사한다고 하셨는데, 좀 더 구체적으로 설명해 주실 수 있나요?" 박시니어 씨는 화이트보드를 꺼내 들었습니다.
허브는 리피터와 분배기의 역할을 동시에 수행합니다. 수신한 전기 신호를 증폭하여 신호 감쇠를 보상하고, 이를 모든 포트로 동시에 전송합니다.
이 과정에서 데이터의 내용은 전혀 확인하지 않으며, 단순히 비트 스트림을 그대로 복제합니다.
다음 코드를 살펴봅시다.
# 허브의 상세 동작 시뮬레이션
class DetailedHub:
def __init__(self, ports, bandwidth_mbps=10):
self.ports = {i: None for i in range(ports)}
self.bandwidth = bandwidth_mbps # 공유 대역폭
self.is_transmitting = False # 현재 전송 중인지
def amplify_signal(self, signal):
# 리피터 기능: 신호 증폭
return signal * 1.0 # 감쇠된 신호를 원래 강도로
def broadcast(self, signal, source_port):
# 분배기 기능: 모든 포트로 전송
amplified = self.amplify_signal(signal)
for port, device in self.ports.items():
if port != source_port and device:
# 반이중 통신: 동시 송수신 불가
device.receive(amplified)
return f"신호가 {len(self.ports)-1}개 포트로 전송됨"
박시니어 씨는 화이트보드에 허브 그림을 그리기 시작했습니다. 중앙에 허브를 그리고, 주변에 4대의 컴퓨터를 연결했습니다.
"자, 허브의 핵심 특징을 하나씩 설명해 줄게." 첫 번째 특징은 신호 증폭입니다. 전기 신호는 케이블을 따라 이동하면서 점점 약해집니다.
이것을 감쇠라고 합니다. 허브는 약해진 신호를 받아서 원래의 강도로 증폭시킵니다.
이 역할은 리피터와 동일합니다. 마치 산속에서 전화기가 잘 안 터질 때, 중간에 중계기를 설치하는 것과 같습니다.
중계기가 약해진 신호를 받아서 다시 강하게 쏘아주는 것처럼, 허브도 신호를 증폭합니다. 두 번째 특징은 반이중 통신입니다.
허브에 연결된 장치들은 동시에 송신과 수신을 할 수 없습니다. 한 번에 한 방향으로만 통신이 가능합니다.
무전기를 생각하면 됩니다. "오버"라고 말하고 상대방의 응답을 기다려야 하죠.
세 번째 특징은 대역폭 공유입니다. 10Mbps 허브에 4대의 컴퓨터가 연결되면, 4대가 10Mbps를 나눠 써야 합니다.
한 컴퓨터가 대용량 파일을 전송하면 다른 컴퓨터들의 속도가 느려집니다. 위의 코드에서 bandwidth 변수가 이것을 나타냅니다.
모든 포트가 동일한 대역폭을 공유하므로, 네트워크에 연결된 장치가 많아질수록 개별 성능은 떨어집니다. 네 번째 특징은 투명한 전달입니다.
허브는 데이터의 내용을 전혀 확인하지 않습니다. MAC 주소가 뭔지, IP 주소가 뭔지 관심이 없습니다.
그저 받은 신호를 그대로 복사해서 뿌릴 뿐입니다. 김개발 씨가 이해가 됐다는 듯이 말했습니다.
"그러니까 허브는 정말 단순한 장비네요. 생각하는 기능이 전혀 없고요." 박시니어 씨가 고개를 끄덕였습니다.
"맞아. 그래서 **덤 허브(Dumb Hub)**라고도 불러.
하지만 이 단순함 때문에 심각한 문제가 생기지. 바로 충돌이야."
실전 팁
💡 - 허브는 리피터 + 분배기의 결합체라고 이해하면 쉽습니다
- 반이중 통신이므로 동시 송수신이 불가능하다는 점을 기억하세요
4. 콜리전 도메인
박시니어 씨가 화이트보드에 새로운 그림을 그렸습니다. 허브에 연결된 두 대의 컴퓨터가 동시에 데이터를 보내는 상황이었습니다.
"자, 여기서 문제가 발생해. A 컴퓨터와 B 컴퓨터가 동시에 말을 하면 어떻게 될까?" 김개발 씨는 잠시 생각했습니다.
**콜리전 도메인(Collision Domain)**은 충돌이 발생할 수 있는 네트워크 영역을 말합니다. 허브에 연결된 모든 장치는 하나의 콜리전 도메인에 속합니다.
두 개 이상의 장치가 동시에 데이터를 전송하면 신호가 섞여서 충돌이 발생하고, 데이터가 손상됩니다.
다음 코드를 살펴봅시다.
# 콜리전 도메인과 충돌 시뮬레이션
import random
import time
class CollisionDomain:
def __init__(self):
self.medium_busy = False # 전송 매체 사용 중
self.collision_count = 0
def transmit(self, device_id, data):
if self.medium_busy:
# 충돌 발생!
self.collision_count += 1
print(f"충돌 발생! {device_id}의 데이터 손상")
return False
self.medium_busy = True
print(f"{device_id}가 데이터 전송 중: {data}")
time.sleep(0.1) # 전송 시간
self.medium_busy = False
return True
김개발 씨가 대답했습니다. "음...
소리가 섞여서 알아들을 수 없게 되지 않을까요?" 박시니어 씨가 손가락을 튕겼습니다. "정확해!
바로 그게 **충돌(Collision)**이야." 회의실에서 두 사람이 동시에 말을 시작하면 어떻게 될까요? 두 사람의 목소리가 섞여서 무슨 말인지 알아듣기 어렵습니다.
네트워크에서도 마찬가지입니다. 두 컴퓨터가 동시에 전기 신호를 보내면, 신호가 섞여서 데이터가 손상됩니다.
이렇게 충돌이 발생할 수 있는 영역을 콜리전 도메인이라고 합니다. 허브에서는 연결된 모든 장치가 하나의 콜리전 도메인을 공유합니다.
8포트 허브에 8대의 컴퓨터가 연결되어 있다면, 이 8대 모두가 같은 콜리전 도메인에 속합니다. 어느 두 대가 동시에 데이터를 보내든 충돌이 발생합니다.
왜 이런 일이 발생할까요? 허브는 물리 계층에서 동작하기 때문입니다.
허브는 신호를 구분하지 못합니다. 그저 받은 신호를 모든 포트로 전달할 뿐입니다.
여러 신호가 동시에 들어오면, 허브는 그 신호들을 합쳐서 내보내게 되고, 결과적으로 알아볼 수 없는 신호가 됩니다. 위의 코드에서 medium_busy 변수가 핵심입니다.
전송 매체가 이미 사용 중일 때 다른 장치가 전송을 시도하면 충돌이 발생합니다. collision_count가 증가하고 데이터는 손상됩니다.
충돌이 발생하면 어떤 일이 벌어질까요? 먼저, 충돌로 인해 손상된 데이터는 버려집니다.
그리고 데이터를 보낸 컴퓨터들은 일정 시간 후에 다시 전송을 시도해야 합니다. 이 과정에서 시간이 낭비되고, 네트워크 효율이 떨어집니다.
네트워크에 연결된 장치가 많아질수록 충돌 확률은 기하급수적으로 증가합니다. 2대일 때보다 10대일 때, 10대일 때보다 100대일 때 충돌이 훨씬 자주 발생합니다.
이것이 허브 기반 네트워크의 근본적인 한계입니다. 김개발 씨가 물었습니다.
"그러면 충돌을 어떻게 해결하나요?" 박시니어 씨가 미소 지었습니다. "바로 그걸 위해 CSMA/CD라는 프로토콜이 만들어졌어."
실전 팁
💡 - 콜리전 도메인이 클수록 충돌 확률이 높아지고 네트워크 성능이 저하됩니다
- 스위치는 각 포트가 별도의 콜리전 도메인을 가지므로 충돌 문제를 해결합니다
5. CSMA CD 프로토콜 원리
김개발 씨는 점점 네트워크에 흥미가 생겼습니다. "CSMA/CD...
이름부터 복잡해 보이는데요." 박시니어 씨가 웃으며 말했습니다. "이름은 복잡해 보여도, 원리는 우리가 일상에서 늘 하는 행동이야.
회의실에서 발언할 때를 생각해 봐."
**CSMA/CD(Carrier Sense Multiple Access with Collision Detection)**는 이더넷에서 충돌을 관리하는 프로토콜입니다. 데이터를 보내기 전에 회선이 비어있는지 확인하고(Carrier Sense), 여러 장치가 동시에 접근할 수 있으며(Multiple Access), 충돌을 감지하면(Collision Detection) 재전송합니다.
다음 코드를 살펴봅시다.
# CSMA/CD 프로토콜 시뮬레이션
import random
class CSMA_CD:
def __init__(self):
self.carrier_busy = False
def carrier_sense(self):
# 1단계: 회선이 비어있는지 확인
return not self.carrier_busy
def transmit_with_csma_cd(self, device_id, data):
# Carrier Sense: 회선 확인
if not self.carrier_sense():
print(f"{device_id}: 회선 사용 중, 대기...")
return "DEFER"
# 전송 시작
self.carrier_busy = True
print(f"{device_id}: 전송 시작 - {data}")
# Collision Detection: 충돌 감지 (시뮬레이션)
if random.random() < 0.3: # 30% 확률로 충돌
print(f"{device_id}: 충돌 감지! 전송 중단")
self.carrier_busy = False
return "COLLISION"
self.carrier_busy = False
return "SUCCESS"
박시니어 씨가 비유를 들어 설명했습니다. "회의실에서 발언하려면 어떻게 해?" 김개발 씨가 대답했습니다.
"일단 다른 사람이 말하고 있는지 확인하고... 조용하면 말을 시작하죠." "그게 바로 Carrier Sense야.
회선이 비어있는지 확인하는 거지." CSMA/CD의 각 단어를 하나씩 풀어보겠습니다. **CS(Carrier Sense)**는 '반송파 감지'입니다.
데이터를 보내기 전에 먼저 네트워크 회선에 다른 신호가 흐르고 있는지 확인합니다. 회의실에 들어가서 "지금 누가 말하고 있나?"를 확인하는 것과 같습니다.
**MA(Multiple Access)**는 '다중 접속'입니다. 여러 장치가 같은 네트워크 회선을 공유할 수 있다는 의미입니다.
회의실에 여러 사람이 있어도 한 번에 한 사람만 발언하면 문제가 없는 것과 같습니다. **CD(Collision Detection)**는 '충돌 감지'입니다.
혹시 두 장치가 동시에 전송을 시작했다면, 이를 감지하고 전송을 중단합니다. 두 사람이 동시에 말하기 시작했을 때 "아, 먼저 하세요"라고 양보하는 것과 같습니다.
이 세 가지를 합치면 CSMA/CD의 전체 동작 원리가 됩니다. 위의 코드에서 transmit_with_csma_cd 메서드가 이 과정을 보여줍니다.
먼저 carrier_sense로 회선을 확인하고, 비어있으면 전송을 시작합니다. 전송 중에 충돌이 감지되면 즉시 중단하고 "COLLISION"을 반환합니다.
하지만 여기서 의문이 생깁니다. 회선이 비어있는 것을 확인했는데, 왜 충돌이 발생할까요?
이유는 전파 지연(Propagation Delay) 때문입니다. A 컴퓨터가 회선을 확인했을 때 비어있었지만, 그 순간 멀리 있는 B 컴퓨터도 동시에 확인하고 전송을 시작했을 수 있습니다.
신호가 케이블을 타고 이동하는 데는 시간이 걸리기 때문에, 두 컴퓨터 모두 "비어있다"고 판단하고 동시에 전송을 시작하면 충돌이 발생합니다. 김개발 씨가 고개를 끄덕였습니다.
"아, 마치 전화 통화할 때 둘이 동시에 말하기 시작하는 것과 비슷하네요."
실전 팁
💡 - CSMA/CD는 "먼저 듣고, 말하고, 충돌하면 다시"의 원칙을 따릅니다
- 전파 지연 때문에 Carrier Sense만으로는 충돌을 완전히 방지할 수 없습니다
6. 충돌 감지와 재전송 메커니즘
김개발 씨가 질문했습니다. "충돌이 감지되면 어떻게 되나요?
바로 다시 보내면 되나요?" 박시니어 씨가 고개를 저었습니다. "바로 다시 보내면 또 충돌하겠지.
그래서 똑똑한 방법을 쓰는 거야."
충돌이 감지되면 장치는 즉시 **잼 신호(Jam Signal)**를 보내 모든 장치에게 충돌을 알립니다. 그 후 지수적 백오프(Exponential Backoff) 알고리즘을 사용하여 임의의 시간만큼 대기한 후 재전송합니다.
충돌이 반복될수록 대기 시간 범위가 늘어나 충돌 확률을 줄입니다.
다음 코드를 살펴봅시다.
# 충돌 감지 후 재전송 메커니즘
import random
import time
class CollisionHandler:
MAX_ATTEMPTS = 16 # 최대 재시도 횟수
SLOT_TIME = 0.0512 # 슬롯 시간 (51.2 마이크로초)
def send_jam_signal(self):
# 잼 신호: 모든 장치에 충돌 알림
print(">>> 잼 신호 전송: 모든 장치에 충돌 알림 <<<")
def exponential_backoff(self, attempt):
# 지수적 백오프: 대기 시간 계산
k = min(attempt, 10) # 최대 10으로 제한
max_slots = (2 ** k) - 1
wait_slots = random.randint(0, max_slots)
wait_time = wait_slots * self.SLOT_TIME
print(f"시도 {attempt}: 0~{max_slots} 중 {wait_slots} 선택")
print(f"대기 시간: {wait_time:.4f}초")
return wait_time
def handle_collision(self, attempt):
self.send_jam_signal()
if attempt >= self.MAX_ATTEMPTS:
return None # 전송 포기
return self.exponential_backoff(attempt)
박시니어 씨가 설명을 이어갔습니다. "충돌을 감지하면 세 가지 일이 순서대로 일어나." 첫 번째, **잼 신호(Jam Signal)**를 보냅니다.
충돌을 감지한 장치는 즉시 전송을 중단하고, 특별한 신호를 네트워크에 뿌립니다. 이 신호를 받은 모든 장치는 "아, 지금 충돌이 발생했구나"라고 인식합니다.
마치 교통사고가 났을 때 경적을 울려 다른 차들에게 알리는 것과 같습니다. 두 번째, 지수적 백오프를 수행합니다.
이것이 CSMA/CD의 핵심 알고리즘입니다. 만약 충돌 후 모든 장치가 동시에 재전송을 시도한다면 어떻게 될까요?
당연히 또 충돌이 발생합니다. 그래서 각 장치는 무작위 시간만큼 기다린 후 재전송합니다.
여기서 똑똑한 점은 대기 시간의 범위가 점점 늘어난다는 것입니다. 첫 번째 충돌 후에는 0 또는 1 슬롯 중 랜덤하게 선택합니다.
두 번째 충돌 후에는 0, 1, 2, 3 중에서 선택합니다. 세 번째 충돌 후에는 0부터 7까지 중에서 선택합니다.
위의 코드에서 exponential_backoff 메서드가 이를 구현합니다. 시도 횟수가 늘어날수록 max_slots가 기하급수적으로 커집니다.
2의 k승에서 1을 뺀 값이 됩니다. 왜 이렇게 할까요?
충돌이 계속된다는 것은 네트워크가 혼잡하다는 의미입니다. 혼잡할수록 더 넓은 범위에서 랜덤하게 대기 시간을 선택해야 충돌 확률이 줄어듭니다.
마치 러시아워에 도로가 막히면 조금 더 기다렸다가 출발하는 것과 같습니다. 세 번째, 16번의 시도에도 실패하면 전송을 포기합니다.
코드에서 MAX_ATTEMPTS가 16인 이유입니다. 16번이나 충돌이 반복됐다는 것은 심각한 네트워크 문제가 있다는 의미이므로, 상위 계층에 오류를 보고하고 전송을 중단합니다.
김개발 씨가 감탄했습니다. "와, 생각보다 정교한 알고리즘이네요." 박시니어 씨가 덧붙였습니다.
"이 알고리즘 덕분에 허브 기반 네트워크가 그나마 동작할 수 있었어. 하지만 근본적인 한계는 해결하지 못했지."
실전 팁
💡 - 지수적 백오프는 네트워크 혼잡도에 따라 자동으로 대기 시간을 조절합니다
- 실무에서 비슷한 패턴을 API 재시도 로직에 적용할 수 있습니다
7. 허브의 한계와 문제점
교육이 끝나갈 무렵, 김개발 씨가 마지막 질문을 던졌습니다. "그런데 왜 요즘은 허브를 거의 안 쓰나요?
CSMA/CD가 충돌을 해결해 주는데요." 박시니어 씨가 의자를 당겨 앉았습니다. "CSMA/CD는 충돌을 '관리'하는 거지, '해결'하는 게 아니거든."
허브는 성능, 보안, 확장성 측면에서 심각한 한계를 가집니다. 대역폭 공유로 인한 성능 저하, 모든 트래픽이 모든 포트에 노출되는 보안 취약점, 콜리전 도메인이 커질수록 급격히 떨어지는 효율성 때문에 현대 네트워크에서는 스위치로 대체되었습니다.
다음 코드를 살펴봅시다.
# 허브 vs 스위치 성능 비교 시뮬레이션
class NetworkComparison:
def hub_performance(self, num_devices, bandwidth_mbps):
# 허브: 대역폭 공유, 충돌 오버헤드
shared_bandwidth = bandwidth_mbps / num_devices
collision_overhead = 0.3 * (num_devices / 10) # 장치 증가시 충돌 증가
effective = shared_bandwidth * (1 - collision_overhead)
return max(effective, 0)
def switch_performance(self, num_devices, bandwidth_mbps):
# 스위치: 전용 대역폭, 충돌 없음
return bandwidth_mbps # 각 포트가 전체 대역폭 사용
def compare(self, devices=10, bandwidth=100):
hub = self.hub_performance(devices, bandwidth)
switch = self.switch_performance(devices, bandwidth)
print(f"장치 수: {devices}, 대역폭: {bandwidth}Mbps")
print(f"허브: {hub:.2f}Mbps/장치")
print(f"스위치: {switch:.2f}Mbps/장치")
print(f"성능 차이: {switch/hub:.1f}배")
박시니어 씨가 허브의 한계를 하나씩 짚어갔습니다. 첫 번째 문제는 성능 저하입니다.
앞서 배웠듯이 허브는 대역폭을 공유합니다. 100Mbps 허브에 20대의 컴퓨터가 연결되면, 평균적으로 각 컴퓨터는 5Mbps도 제대로 사용하기 어렵습니다.
거기에 충돌로 인한 재전송 오버헤드까지 더해지면 실제 성능은 더욱 떨어집니다. 위의 코드에서 hub_performance 메서드가 이를 계산합니다.
장치 수가 늘어날수록 effective 대역폭은 급격히 감소합니다. 반면 스위치는 각 포트가 전체 대역폭을 독립적으로 사용할 수 있습니다.
두 번째 문제는 보안 취약점입니다. 허브는 모든 포트에 모든 트래픽을 전달합니다.
악의적인 사용자가 패킷 스니퍼를 설치하면, 네트워크의 모든 통신을 도청할 수 있습니다. 아이디, 비밀번호, 개인정보가 모두 노출될 수 있는 심각한 문제입니다.
마치 회의실에서 하는 모든 대화가 건물 전체 스피커로 방송되는 것과 같습니다. 비밀 이야기를 나눌 수 없게 되는 것이죠.
세 번째 문제는 확장성의 한계입니다. 네트워크에 장치가 추가될수록 콜리전 도메인이 커집니다.
콜리전 도메인이 커지면 충돌 확률이 높아지고, 충돌이 많아지면 재전송이 증가하고, 재전송이 증가하면 또다시 충돌이... 악순환이 됩니다.
실제로 허브 기반 네트워크는 30대 이상의 장치가 연결되면 성능이 급격히 저하됩니다. 현대의 사무실이나 데이터센터에서는 사용이 불가능한 수준입니다.
네 번째 문제는 전이중 통신 불가입니다. 허브는 반이중 통신만 지원합니다.
동시에 보내고 받을 수 없습니다. 현대 네트워크는 전이중(Full-duplex) 통신이 표준이지만, 허브는 이를 지원하지 못합니다.
이런 모든 문제를 해결하기 위해 스위치가 등장했습니다. 스위치는 MAC 주소를 학습하여 목적지 포트에만 데이터를 전달합니다.
각 포트가 별도의 콜리전 도메인을 가지므로 충돌이 발생하지 않습니다. 전이중 통신도 지원합니다.
김개발 씨가 정리하며 말했습니다. "결국 허브는 네트워크의 역사를 이해하기 위해 알아야 하는 거네요.
실제로는 스위치를 쓰고요." 박시니어 씨가 고개를 끄덕였습니다. "맞아.
하지만 CSMA/CD의 원리는 아직도 중요해. 무선 네트워크의 CSMA/CA도 비슷한 개념이거든.
기초를 알아야 응용도 이해할 수 있는 법이야."
실전 팁
💡 - 현대 네트워크에서 허브를 발견하면 즉시 스위치로 교체를 권장하세요
- CSMA/CD의 원리는 무선 네트워크의 CSMA/CA를 이해하는 데 기초가 됩니다
이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!
댓글 (0)
함께 보면 좋은 카드 뉴스
Helm 마이크로서비스 패키징 완벽 가이드
Kubernetes 환경에서 마이크로서비스를 효율적으로 패키징하고 배포하는 Helm의 핵심 기능을 실무 중심으로 학습합니다. Chart 생성부터 릴리스 관리까지 체계적으로 다룹니다.
보안 아키텍처 구성 완벽 가이드
프로젝트의 보안을 처음부터 설계하는 방법을 배웁니다. AWS 환경에서 VPC부터 WAF, 암호화, 접근 제어까지 실무에서 바로 적용할 수 있는 보안 아키텍처를 단계별로 구성해봅니다.
AWS Organizations 완벽 가이드
여러 AWS 계정을 체계적으로 관리하고 통합 결제와 보안 정책을 적용하는 방법을 실무 스토리로 쉽게 배워봅니다. 초보 개발자도 바로 이해할 수 있는 친절한 설명과 실전 예제를 제공합니다.
AWS KMS 암호화 완벽 가이드
AWS KMS(Key Management Service)를 활용한 클라우드 데이터 암호화 방법을 초급 개발자를 위해 쉽게 설명합니다. CMK 생성부터 S3, EBS 암호화, 봉투 암호화까지 실무에 필요한 모든 내용을 담았습니다.
AWS Secrets Manager 완벽 가이드
AWS에서 데이터베이스 비밀번호, API 키 등 민감한 정보를 안전하게 관리하는 Secrets Manager의 핵심 개념과 실무 활용법을 배워봅니다. 초급 개발자도 쉽게 따라할 수 있도록 실전 예제와 함께 설명합니다.