17. 전송 지연 (Transmission Delay) - 패킷길이/대역폭

핵심 인사이트 (3줄 요약)

본질: 전송 지연(Transmission Delay)은 네트워크 장비(라우터/NIC)가 데이터 패킷의 첫 비트부터 마지막 비트까지 물리적인 통신 선로 위로 **'모두 밀어 넣는(Push) 데 걸리는 시간'**이다.

가치: 이 지연은 패킷의 길이($L$, bits)를 링크의 전송 속도/대역폭($R$, bps)으로 나눈 값($L/R$)으로 결정되며, 기업이 "100M 랜을 기가 랜(1Gbps)으로 업그레이드했다"고 할 때 직접적이고 즉각적으로 감소하는 유일한 지연 요소다.

융합: 전파 지연(날아가는 시간)이 바꿀 수 없는 자연의 섭리라면, 전송 지연은 자본 투자(대역폭 확장)와 소프트웨어 설정(MTU 최적화, 헤더 압축)을 통해 엔지니어가 0에 가깝게 통제하고 튜닝할 수 있는 물리/데이터링크 계층의 핵심 성능 변수다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념:
- 수식: $d_{trans} = L / R$
- $L$ (Length): 전송하려는 데이터 패킷의 총 길이 (단위: Bits). 헤더와 페이로드를 모두 포함한다.
- $R$ (Rate): 네트워크 인터페이스 카드(NIC)나 공유 매체가 1초당 뿜어낼 수 있는 전송률 즉, 대역폭 (단위: bps, bits per second).
필요성: 통신 속도를 논할 때 사람들은 흔히 100Mbps, 10Gbps라는 대역폭(R) 수치만 바라본다. 하지만 장비 입장에서 대역폭이란 1초에 밀어낼 수 있는 비트의 양일 뿐이다. 만약 보내야 할 짐(패킷 길이 L)이 엄청나게 크다면, 대역폭이 넓어도 짐 전체를 도로 위에 올리는 데 시간이 오래 걸린다. 트래픽 혼잡(큐잉)도 없고 거리(전파)가 아무리 짧아도, 근본적으로 거대한 덩어리를 좁은 틈으로 짜내는 시간 자체가 존재함을 정량적으로 분석하기 위해 고안된 개념이다.
💡 비유: 마트의 계산대(네트워크 인터페이스)를 상상해 보자.
- 패킷 길이($L$): 손님의 카트에 담긴 물건의 총 개수다. (물건이 100개)
- 대역폭($R$): 계산원(바코드 스캐너)이 1초에 물건을 찍어내는 속도다. (1초에 10개)
- 전송 지연($L/R$): 첫 번째 물건부터 마지막 100번째 물건까지 바코드를 전부 찍어서 계산대 밖으로 완전히 내보내는 데 걸리는 시간이다. (100개 / 10개 = 10초).
전송 지연의 메커니즘 시각화:

  ┌─────────────────────────────────────────────────────────┐
  │        전송 지연(Transmission Delay)의 수식적 원리 도식         │
  ├─────────────────────────────────────────────────────────┤
  │                                                         │
  │ [송신 라우터 인터페이스]                   [전송 매체(전선)]       │
  │                                                         │
  │ 패킷 대기열 (길이 L = 10,000 Bits)                         │
  │ [██████████████████]                                    │
  │                    ──▶ | 1초에 밀어넣는 양: R = 1,000 bps |│
  │                        |──────────────────────────────| │
  │                                                         │
  │  시간 t=0 : 첫 번째 비트(0)가 선로에 막 올라감.                    │
  │  시간 t=1 : 1,000개의 비트가 선로로 밀려 나감.                     │
  │   ...                                                   │
  │  시간 t=10: 마지막 10,000번째 비트가 드디어 선로 위로 올라탐!!         │
  │                                                         │
  │  * 결론: 패킷 전체(L)를 선로에 쏟아붓는 데 소요된 시간 (L/R) = 10초     │
  │  * 주의: 이 시간은 패킷이 수신기에 '도착'한 시간이 아니라,             │
  │         내 공유기에서 '전부 빠져나간' 시간일 뿐임. (전파 지연 별도) │
  └─────────────────────────────────────────────────────────┘

[다이어그램 해설] 라우터의 랜카드(NIC)는 패킷을 마법처럼 한 방에 공간 이동시키는 것이 아니다. 비트들을 직렬로 한 줄로 세워 선로의 클럭(Clock) 속도에 맞춰 1비트씩 펌프질한다. 이 펌프질 속도가 대역폭($R$)이고, 펌프질해야 할 전체 물량이 패킷 길이($L$)다. 그림처럼 $L$이 10,000인데 펌프가 초당 1,000번 작동한다면, 내 컴퓨터에서 그 패킷이 꼬리까지 완전히 떨어져 나가는 데 무조건 10초가 걸린다. 이것이 전송 지연이다.

📢 섹션 요약 비유: 주사기(선로) 안에 든 약물 100cc(패킷 길이)를 주삿바늘의 굵기(대역폭)에 맞춰 꾹 눌러서 바늘 밖으로 100cc를 완전히 다 짜내는 데 걸리는 물리적인 힘과 시간이 바로 전송 지연입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

대역폭($R$)과 패킷 길이($L$)의 상관관계 수학

현대 통신망에서 전송 지연이 체감 지연에 미치는 영향을 계산해 보자.

패킷 길이 ($L$)	대역폭 ($R$)	전송 지연 ($d_{trans} = L/R$)	평가
1500 Bytes (12,000 Bits)	10 Mbps (구형 랜선)	$12,000 / 10^7 = \mathbf{1.2 ms}$	음성 통화(VoIP) 패킷 수백 개가 쌓이면 엄청난 지연 유발
1500 Bytes (12,000 Bits)	1 Gbps (현재 기가랜)	$12,000 / 10^9 = \mathbf{12 \mu s}$	사람의 체감이나 네트워크 큐잉에 거의 영향 없음
9000 Bytes (Jumbo Frame)	1 Gbps	$72,000 / 10^9 = \mathbf{72 \mu s}$	점보 프레임 적용 시 전송 시간은 늘어나지만, CPU 오버헤드 대폭 감소
9000 Bytes (72,000 Bits)	100 Gbps (백본망)	$72,000 / 10^{11} = \mathbf{0.72 \mu s}$	지연 거의 소멸. 빛의 전파 지연(Propagation)만 남음

위 표가 보여주는 핵심은 "현대 기가비트급 광대역 통신망에서, 작은 패킷(1500B 이하)의 전송 지연 자체는 마이크로초 단위로 수렴하여 사실상 0이 되었다"는 점이다. 과거 모뎀 시절(56kbps)에는 사진 한 장(1MB)을 밀어 넣는 데 140초가 걸리는 전송 지연 지옥이었지만, 현재의 병목은 전송 지연이 아닌 버퍼 큐 대기(Queuing)와 빛의 속도 한계(Propagation)로 넘어갔다.

스토어-앤-포워드 (Store-and-Forward) 라우팅의 전송 지연 누적

패킷이 인터넷을 통과할 때 하나의 라우터만 거치는 것이 아니다. N개의 라우터를 거친다면, 각 라우터는 들어오는 패킷을 버퍼에 "모두 저장(Store)"한 뒤, 에러를 검사하고 다음 라우터로 "전송(Forward)"한다.

라우터가 3개인 경로를 통과할 때:
- 1번째 라우터가 밀어 넣는 시간: $L/R$
- 2번째 라우터가 버퍼에 다 받을 때까지 대기 + 다시 밀어 넣는 시간: $L/R$
- 3번째 라우터: $L/R$
총 누적 전송 지연 = $N \times (L/R)$

만약 패킷 길이가 엄청나게 크다면, 매 홉(Hop)마다 이 거대한 $L/R$ 시간이 곱해져 엄청난 지연을 유발한다. 이것이 우리가 대용량 파일을 보낼 때 굳이 1500바이트 크기의 작은 파편(패킷)으로 잘게 쪼개어 보내는(패킷 스위칭) 가장 강력한 수학적 이유다. 패킷을 쪼개면 앞 파편이 2번 라우터를 지날 때 뒤 파편이 1번 라우터를 통과하는 파이프라이닝(Pipelining) 병렬 처리가 발생하여 누적 $L/R$ 딜레이가 획기적으로 상쇄된다.

📢 섹션 요약 비유: 100칸짜리 긴 기차(거대 패킷)가 역(라우터)을 통과하려면 꼬리가 완전히 들어올 때까지 기다려야 다음 역으로 출발할 수 있습니다. 하지만 기차를 1칸짜리 자동차 100대로 쪼개면, 앞차가 다음 역에 도착할 때 뒷차도 출발할 수 있어 전체 이동 시간이 압도적으로 줄어드는 원리입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 지연 요소 제어 권한 및 투자 관점

지연 종류	해결책 / 튜닝 방안	주체	해결의 난이도 및 비용
전파 지연 ($d/s$)	CDN 구축, 사용자와 가까운 에지(Edge) 서버 배치	클라우드 아키텍트, 앱 개발자	물리적 한계로 매우 어려움 (우회해야 함)
큐잉 지연 ($d_{queue}$)	QoS 알고리즘 적용, 버퍼 크기 조절 (AQM)	네트워크 소프트웨어 엔지니어	장비 교체 없이 알고리즘 튜닝으로 상당 부분 통제 가능
전송 지연 ($L/R$)	10G/40G 회선 증설 (R 상향), 패킷 쪼개기 (L 하향)	인프라 투자 책임자, 자본(돈)	자본 투입으로 가장 즉각적이고 확실하게 해결 가능

자본주의 인프라 구조에서 전송 지연($L/R$)은 가장 정직한 지표다. 느리다면 돈을 내고 더 굵은 회선(R)을 통신사로부터 사면 수식에 의해 정확히 지연이 쪼그라든다.

과목 융합 관점

운영체제 / 하드웨어: 하드디스크나 NVMe SSD의 속도 스펙(순차 쓰기 3000MB/s)이 곧 $R$에 해당하며, 저장하려는 파일 크기가 $L$이다. 운영체제에서 대용량 파일을 복사할 때 걸리는 시간은 완벽한 전송 지연($L/R$)의 컴퓨터 내부 버전이다.
정보보안 (Security): IPsec VPN이나 TLS 암호화를 적용하면 원래 1000바이트였던 페이로드에 암호화 헤더와 패딩(Padding)이 붙어 패킷 길이($L$)가 1100바이트 이상으로 커진다. $R$(대역폭)이 고정된 상태에서 $L$이 커졌으므로, 보안을 강화할수록 물리적인 전송 지연이 필연적으로 증가하는 강력한 트레이드오프가 발생한다.
📢 섹션 요약 비유: 전파 지연(물리 거리)이 하나님이 정해놓은 거스를 수 없는 규칙이라면, 큐잉 지연(대기열)은 똑똑한 경찰관(QoS)의 교통정리로 풀 수 있는 문제고, 전송 지연(차선 폭)은 돈을 엄청나게 부어 도로를 넓히면(R 증가) 가장 빠르고 무식하게 해결되는 과제입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 데이터센터 스위칭 아키텍처 업그레이드 (Store-and-Forward vs Cut-Through): 주식 초단타 매매(HFT)를 위한 증권사망. 두 서버 간의 핑이 마이크로초 단위에서 승부가 난다. 현재 10G 스위치를 쓰고 있는데 대역폭(R)은 충분하나 지연을 더 줄여야 한다. [해결책] 기존 스위치는 패킷의 머리부터 꼬리(L)가 100% 버퍼에 다 들어올 때까지 기다렸다가 다음 포트로 밀어내는 Store-and-Forward 방식을 쓴다. 이때 필수적으로 $L/R$ 전송 지연이 발생한다. 아키텍트는 넥서스(Nexus) 급의 Cut-Through 스위치로 장비를 교체한다. 이 스위치는 패킷의 맨 앞 목적지 MAC 헤더(14바이트)만 버퍼에 들어오는 순간, 꼬리가 선로에 진입하기도 전에 목적지 포트로 전송(Forwarding)을 시작한다. 즉 패킷 전체를 기다리는 $L/R$ 전송 지연 타임을 아예 파이프라이닝으로 증발시켜 지연을 나노초 단위로 베어낸다.
시나리오 — IoT 저대역폭 망(LoRa, NB-IoT)에서의 전송 지연 병목 설계: 스마트 팩토리 외곽에 온도 센서를 깔고 LoRa망(수십 kbps 속도)으로 데이터를 받으려 한다. 엔지니어가 평소 웹 개발하듯 JSON 포맷으로 패킷 길이($L$)를 500바이트로 넉넉하게 짜서 코딩했다. [해결책] 재앙적 설계다. 기가랜 환경에서는 $L$이 500바이트든 1500바이트든 전송 지연이 $1\mu s$ 이하로 체감 안 되지만, $R$이 고작 10kbps인 IoT 망에서 500바이트(4,000비트)를 보내려면 전송 지연($L/R$)만 무려 **0.4초(400ms)**가 걸린다. 무선 매체를 0.4초나 독점하면 배터리 소모가 극심하고 다른 센서들의 전파 충돌이 폭증한다. 엔지니어는 화려한 JSON 포맷을 버리고, 바이너리 비트 마스킹으로 데이터 길이($L$)를 단 10바이트(80비트)로 극단적 다이어트를 시켜 전송 지연을 8ms 수준으로 최소화해야만 저전력 장거리망(LPWAN) 생태계가 붕괴하지 않는다.

특정 애플리케이션의 응답 지연 발생 시 전송/전파 병목을 가르는 의사결정 흐름은 다음과 같다.

  ┌───────────────────────────────────────────────────────────────────┐
  │        네트워크 지연 모델 기반: 전송 지연(L/R) 병목 해결 의사결정 플로우    │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [파일 전송 또는 스트리밍 시, 응답 시작은 빠르나 전체 완료가 극도로 지연됨]  │
  │                │                                                  │
  │                ▼                                                  │
  │      패킷의 크기(L)를 줄여서(Ping 10바이트 등) 테스트하면 지연이 사라지는가?│
  │          ├─ 예 ─────▶ [전파/큐잉이 아닌 전형적인 전송 지연(L/R) 병목]   │
  │          │                     │                                  │
  │          │                     └─▶ [해결책: 대역폭(R) 증설, 압축(L 감소) 적용] │
  │          │                                                        │
  │          └─ 아니오 (패킷을 작게 쏴도 여전히 100ms 넘게 걸림)            │
  │                │                                                  │
  │                ▼                                                  │
  │      목적지의 물리적 거리가 멀거나(전파 지연), 경로 상 라우터 혼잡(큐잉)인가? │
  │          ├─ 예 ─────▶ [CDN 에지 캐싱 도입 (거리 d 축소)]            │
  │          │                     │                                  │
  │          │                     └─▶ [SD-WAN 우회 경로 또는 QoS 우선순위 적용] │
  │          │                                                        │
  │          └─ 아니오 ──▶ [수신 측 서버의 애플리케이션 DB/CPU 처리 지연 의심] │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "핑 쳐봐"라는 말의 핵심은 작은 패킷(L=64바이트)을 쏴본다는 것이다. 작은 패킷을 쏠 때는 핑이 10ms로 아주 좋은데, 큰 파일(L=거대함)을 다운로드할 때만 속도 딜레이가 심하다면 그것은 전파(거리)의 문제가 아니라 순전히 펌프의 구멍이 좁은 전송 지연(대역폭 R 부족)의 문제다. 즉시 회선 용량을 늘리는 자본 투입이 정답이 된다. 반대로 작은 패킷을 쏴도 핑이 200ms라면, 회선이 아무리 두꺼워도(R이 무한대) 거리가 너무 멀다는 뜻이므로 대역폭 증설은 헛돈 쓰는 짓이다.

도입 체크리스트

기술적: VoIP(인터넷 전화)망 설계 시, 음성 데이터 알맹이(L)는 매우 작은데 IP/UDP/RTP 헤더가 40바이트씩 붙어 배보다 배꼽이 커지는 전송 지연 비효율을 막기 위해, cRTP(압축 RTP) 기능을 라우터에 활성화하여 패킷 길이를 줄였는가?
운영·보안적: VPN 환경에서 MTU 크기를 계산할 때, 암호화 헤더 부착으로 인해 패킷 길이가 인터페이스 허용치(1500B) 초과하여 파편화(Fragmentation)가 발생하면 라우터의 처리/전송 지연이 기하급수적으로 튀므로, MSS/MTU 값을 선제적으로 하향 조절(Tuning) 했는가?

안티패턴

단일 지연 지표의 오류: 네트워크 모니터링 대시보드에서 Ping 수치 하나만 띄워놓고 "핑이 5ms니 속도 완벽하네!"라고 착각하는 행위. 핑(ICMP) 패킷은 크기($L$)가 겨우 32바이트라 10Mbps 낡은 회선에서도 전송 지연 없이 눈썹 휘날리게 날아간다. 하지만 이 회선에 10MB짜리 실제 비즈니스 파일을 얹는 순간 전송 지연 공식($L/R$)에 의해 지연 시간은 수 초 단위로 터져버린다. 인프라 대시보드는 대역폭 모니터링(R)과 패킷 지연을 반드시 분리해서 감시해야 한다.
📢 섹션 요약 비유: 자전거 1대가 터널을 통과하는 시간(Ping 테스트)만 재보고 "이 터널 엄청 빠르네!"라고 좋아하다가, 거대한 덤프트럭 100대(실제 대용량 패킷)를 보냈을 때 입구에서 전부 끼여서 꼼짝 못 하는(전송 지연 병목) 대참사가 일어나는 격입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

최적화 지점	전송 지연(L/R) 병목 방치 시	전송 지연 최적화 (R 증설/L 압축) 적용	아키텍처 개선 효과
회선 속도(R) 상향	다운로드 큐 적체, 버퍼블로트 연쇄 폭발	파이프 확대에 따른 대규모 패킷 즉시 소화	전체 큐잉 지연까지 덩달아 해소되는 선순환 효과
패킷 쪼개기/압축(L)	거대 프레임 1개가 라우터 전체 지연 유발	병렬 파이프라이닝 및 오버헤드 최소화	저속망(IoT) 배터리 절감 및 동시다발적 전송 달성
스위칭 아키텍처	Store & Forward로 홉마다 수 ms 지연 누적	Cut-Through 도입으로 전송 지연 증발	나노초 단위의 초단타 매매 등 초저지연 비즈니스 획득

미래 전망

광 전송 대역폭의 극대화(400G~800G): 백본망에서 대역폭($R$)이 400Gbps~800Gbps로 향하면서, 수식 $L/R$의 분모가 사실상 무한대에 가까워지고 있다. 미래의 통신망에서 "전송 지연(Transmission Delay)"이라는 개념 자체는 인간이 느낄 수 없는 수학적 0의 영역으로 소멸할 것이며, 오직 빛의 전파 속도 지연(d/s)과 AI 라우팅의 처리 지연만이 남은 과제로 대두될 것이다.
의미 기반 헤더 압축(Semantic Compression): 패킷 길이($L$)를 극단적으로 줄이기 위해, 미래의 AI 네트워킹은 보내려는 데이터의 중복된 메타데이터를 생략하고 딥러닝 잠재 공간(Latent Space)의 핵심 특징 벡터만 몇 바이트로 압축하여 쏘고, 수신단 AI가 이를 복원해 내는 방식으로 진화해 L을 극한으로 다이어트시킬 것이다.

참고 표준

컷스루 스위칭 (Cut-through Switching): 전송 지연(Transmission Delay) 자체를 회피하기 위해, 이더넷 프레임 전체 길이를 버퍼에 기다리지 않고 앞 6바이트(목적지 MAC)만 확인한 뒤 하드웨어적으로 즉각 포워딩하는 데이터센터 스위치 최고급 스펙.
RoHC (Robust Header Compression, RFC 3095): 대역폭이 좁은 무선망에서 40바이트에 달하는 무거운 IPv4/UDP/RTP 헤더를 단 1~2바이트로 압축시켜 패킷 길이($L$)를 줄임으로써 전송 지연을 극복하는 인터넷 표준 기술.

결국 전송 지연($d_{trans}$)은 정보가 물질 세계의 문을 통과하는 가장 정직한 시간이다. 우리는 마법의 지팡이(QoS, 라우팅 알고리즘)로 패킷이 대기하는 시간(큐잉)을 줄일 수는 있지만, 좁은 구멍(R)으로 큰 물건(L)을 밀어 넣는 데 필요한 물리적 시간 자체는 결코 속일 수 없다. 네트워크를 확장하고 병목을 없애는 최후의 수단이 결국 "돈을 들여 회선 대역폭을 넓히는 것(스케일 아웃)"으로 귀결되는 이유가 바로 전송 지연 공식의 분모($R$)가 가진 자본주의적 물리학 때문이다.

  ┌──────────────────────────────────────────────────────────────────┐
  │         전송 지연 (L/R) 한계 돌파를 위한 하드웨어 아키텍처 진화 로드맵       │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  1막 (회선 속도의 투쟁)        2막 (스위칭 구조의 혁신)       3막 (페이로드 다이어트) │
  │   │                       │                      │               │
  │   ▼                       ▼                      ▼               │
  │ [R(대역폭)의 무한 상향]  →  [Store-and-Forward 탈피] → [L(길이)의 AI 극한 압축] │
  │   │                       │                      │               │
  │   ├─ 10M → 10G → 800G망   ├─ Cut-Through 스위치 도입 ├─ 헤더 압축 (RoHC, QUIC) │
  │   ├─ 광 모듈/PAM-4 기술 도입 ├─ 버퍼 대기 시간(L/R) 자체 증발 ├─ 시맨틱 데이터 전송 시대 │
  │   └─ "파이프를 계속 키워라!"  └─ "기다리지 말고 바로 쏴라!" └─ "보낼 알맹이를 줄여라!"│
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 로드맵은 $L/R$이라는 지연 공식을 박살 내기 위한 엔지니어들의 3가지 무기를 보여준다. 첫 번째 무기는 분모($R$)를 키워버리는 광케이블 대역폭의 진화다. 두 번째 무기는 패킷 전체를 기다리는 $L$ 시간 자체를 없애버리기 위해 머리만 들어오면 즉시 쏴버리는 컷스루 스위치의 하드웨어 혁신이다. 세 번째 무기는 미래의 무기로, 분자($L$) 자체를 혁신적인 압축 기술과 헤더 다이어트를 통해 줄여버리는 소프트웨어적 진화다.

📢 섹션 요약 비유: 전송 지연과 싸우는 것은 막힌 터널을 뚫는 과정입니다. 터널을 크게 파거나(대역폭 R 확장), 차 꼬리가 다 들어올 때까지 기다리지 않고 톨게이트를 열어주거나(컷스루 스위치), 아예 화물을 고압축 캡슐(패킷 L 감소)로 만들어 쏘아버리는 방식입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
대역폭 (Bandwidth, R)	전송 지연 공식을 지배하는 분모. 이 수치가 높을수록 1초에 밀어내는 패킷량이 많아져 전송 지연이 0에 가깝게 수렴한다.
MTU (Maximum Transmission Unit)	한 번에 밀어 넣을 수 있는 패킷의 최대 크기($L$). MTU가 너무 크면 해당 패킷의 전송 지연이 길어져 뒤따라오는 다른 패킷의 큐잉 지연을 유발할 수 있다.
전파 지연 (Propagation Delay)	전송 지연이 패킷을 '선로로 밀어 넣는' 시간이라면, 전파 지연은 선로에 올라탄 패킷이 '빛의 속도로 날아가는' 시간으로 두 지표를 완벽히 구분해야 한다.
컷스루 스위칭 (Cut-through)	패킷의 전체 길이($L$)가 다 수신 버퍼에 들어올 때까지 발생하는 전송 지연 대기시간을 삭제하고, 목적지 주소만 확인 즉시 포워딩을 시작하는 초저지연 기술이다.
패킷 단편화 (Fragmentation)	지나치게 큰 데이터($L$)를 네트워크가 허용하는 MTU 크기 이하로 잘게 쪼개어, 홉(Hop) 간 이동 시 파이프라이닝을 통해 전체 누적 전송 지연을 대폭 단축하는 기법이다.

👶 어린이를 위한 3줄 비유 설명

전송 지연은 100칸짜리 꼬마 기차가 장난감 터널 입구로 '한 칸씩 칙칙폭폭 전부 빨려 들어가는 데' 걸리는 시간이에요.
기차가 1000칸으로 엄청 길어지거나(패킷 길이 L이 큼), 터널 입구가 너무 좁아서 기차가 천천히 들어가야 한다면(대역폭 R이 작음) 들어가는 시간(전송 지연)이 엄청 오래 걸리겠죠?
인터넷을 기가 인터넷으로 비싸게 바꾸면 터널 입구가 뻥 뚫려서 거대한 기차도 1초 만에 쑥! 하고 들어가 버리게 만들어 준답니다.