NETWORK ENGINEERING

밀리초의 경제학: TCP/IP 스택에서 발생하는 패킷 유실이 분산 트랜잭션에 미치는 누적 편향

재전송 타이머와 혼잡 제어 알고리즘의 상호작용 — 왜 0.1%의 패킷 손실이 처리율을 절반으로 떨어뜨리는가

Network Engineering · 18 min read

네트워크 운영자들은 오래 전부터 하나의 역설에 익숙해져 있다. 대역폭을 10배로 늘려도, 원거리 통신의 체감 속도는 거의 개선되지 않는다는 사실이다. 그 이유는 대역폭이 아니라 지연 시간(latency)과 패킷 손실률(loss rate)이 실제 처리율(throughput)을 지배하기 때문이다. 이 글은 포르투갈어권 무상 호스팅 시절 수많은 네트워크 장애를 추적하며 얻은 경험을 바탕으로, TCP/IP 스택이 패킷 유실에 어떻게 반응하며 그 누적 효과가 분산 시스템에 어떤 편향을 남기는지를 계층별로 분해한다.

1. TCP의 근본 전제: “모든 패킷은 도착한다”는 신념

TCP는 1974년 Vint Cerf와 Robert Kahn이 제안한 이래 반세기 가까이 인터넷의 신뢰성 전송 계층을 담당해 왔다. RFC 793(1981)에서 공식화된 TCP의 핵심은 “IP는 신뢰할 수 없다”는 전제 하에, 전송측이 수신측의 확인(ACK)을 받을 때까지 패킷을 재전송할 수 있는 상태로 보관한다는 점이다. 이 간단한 원칙이 모든 이야기의 출발점이다.

송신측은 패킷을 보낸 뒤 타이머를 시작한다. 일정 시간(RTO, Retransmission Timeout) 내에 ACK가 돌아오지 않으면 해당 패킷을 유실된 것으로 간주하고 재전송한다. 문제는 “일정 시간”을 어떻게 정할 것인가이다. 너무 짧게 잡으면 단순한 지연을 손실로 오판해 불필요한 재전송이 폭증하고, 너무 길게 잡으면 실제 손실이 발생했을 때 복구가 지연된다.

1.1. Jacobson의 RTT 평활화와 RTO 계산

현대 TCP 구현은 Van Jacobson이 1988년에 제안한 RTT 평활 추정(smoothed RTT estimation) 기법을 사용한다. 각 연결마다 최근 왕복 시간(RTT)의 지수 가중 평균(SRTT)과 그 변동 폭(RTTVAR)을 유지하며, 이를 바탕으로 RTO를 다음과 같이 계산한다.

이 수식이 우아한 이유는 네트워크 상태의 변화에 적응적으로 반응하기 때문이다. 안정된 네트워크에서는 RTTVAR이 작아져 RTO가 평균 RTT에 가깝게 수렴하고, 지연이 요동치는 네트워크에서는 RTTVAR이 커져 RTO가 여유 있게 확장된다. 하지만 이 적응성에는 대가가 있다. RTO의 최솟값이 1초로 규정되어 있기 때문에, 데이터 센터 내부처럼 RTT가 수백 마이크로초 수준인 환경에서는 단 한 번의 패킷 손실이 수천 배의 지연을 유발할 수 있다.

2. Mathis 공식: 패킷 손실과 처리율의 수학적 관계

1997년 Matt Mathis 등이 발표한 논문 “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm”은 TCP의 장기 평균 처리율을 단순한 수식으로 기술했다. 이른바 Mathis 공식이다.

여기서 BW는 달성 가능한 대역폭, MSS는 최대 세그먼트 크기, RTT는 왕복 시간, p는 패킷 손실 확률이다. 이 공식이 던지는 메시지는 충격적이다. 처리율은 손실률의 제곱근에 반비례한다는 것. 이는 손실이 1%에서 4%로 늘어나면 처리율이 절반으로 떨어진다는 의미이며, 네트워크 엔지니어가 손실률을 “1%면 괜찮지 않나”라고 생각해서는 안 되는 이유를 수학적으로 보여준다.

2.1. 숫자로 보는 가혹한 현실

예를 들어, RTT가 100ms인 대륙 간 회선에서 MSS가 1460바이트일 때, 각 손실률에 따른 최대 처리율은 다음과 같다.

패킷 손실률 (p)	이론적 최대 처리율	체감
0.01% (10-4)	약 11.68 Mbps	HD 스트리밍 가능
0.1% (10-3)	약 3.69 Mbps	HD 불안정, SD 수준
1% (10-2)	약 1.17 Mbps	체감 속도 심각 저하
5% (5 × 10-2)	약 522 Kbps	사용 불가에 가까움

주목할 점은 링크의 물리적 대역폭이 아무리 크더라도 위 한계를 넘을 수 없다는 사실이다. 10Gbps 해저 케이블이 있어도 손실률이 1%라면, 단일 TCP 스트림으로는 1.17Mbps밖에 끌어낼 수 없다. 이것이 대륙 간 데이터 전송에서 다중 병렬 스트림(예: rsync의 –whole-file, aria2의 멀티커넥션)이 필수가 되는 이유다.

3. 혼잡 제어 알고리즘의 세대교체: Reno에서 BBR까지

Mathis 공식은 ‘손실 기반 혼잡 제어’를 가정한 것이다. 즉, TCP가 패킷 손실을 혼잡의 신호로 해석하고 전송률을 조절하는 방식 말이다. 그러나 이 접근법은 지난 10년간 근본적 도전에 직면했다.

3.1. 손실 기반의 한계: Reno, CUBIC

전통적 알고리즘인 TCP Reno(1990)는 AIMD(Additive Increase, Multiplicative Decrease) 원리를 따른다. 매 RTT마다 혼잡 윈도우(cwnd)를 선형적으로 증가시키다가, 손실이 감지되면 절반으로 줄인다. 이 “톱니파(sawtooth)” 패턴은 안정적이지만 대역폭 활용이 비효율적이다.

Linux 커널이 2.6.19부터 기본값으로 채택한 TCP CUBIC(2008)은 cwnd 증가 곡선을 3차 함수로 대체하여 고속·고지연 네트워크에서의 성능을 크게 개선했다. 그러나 본질적으로는 여전히 손실을 신호로 사용하기 때문에, 버퍼 블로트(bufferbloat)가 발생하는 환경에서는 오히려 지연을 악화시키는 약점이 있다.

3.2. BBR의 철학적 전환

2016년 Google이 공개한 BBR(Bottleneck Bandwidth and RTT)은 근본적으로 다른 접근법을 취한다. BBR은 손실을 혼잡의 신호로 사용하지 않는다. 대신 링크의 최대 전송 가능 대역폭(BtlBw)과 최소 RTT(RTprop)를 실시간으로 추정하여, 두 값의 곱인 BDP(Bandwidth-Delay Product)를 목표 in-flight 데이터량으로 설정한다.

이 접근의 장점은 명확하다. 과도한 버퍼링 없이도 링크를 포화시킬 수 있으며, 패킷 손실이 발생하는 무선 링크나 해저 케이블 같은 환경에서도 CUBIC 대비 수 배의 처리율을 달성한다. 2019년 Youtube 트래픽의 대부분이 BBR로 전환되면서, 동영상 재버퍼링 비율이 현저히 감소했다는 Google의 내부 보고가 있다.

그러나 BBR에도 비판이 있다. 동일 병목에서 CUBIC 플로우와 공존할 경우 BBR이 불공정하게 큰 몫을 차지하는 “공정성 문제”가 지적되었고, 이를 개선한 BBRv2, BBRv3가 순차적으로 개발되고 있다.

4. 패킷 손실이 발생하는 실제 지점들

4.1. 라우터 큐의 테일 드롭

대부분의 인터넷 코어 라우터는 FIFO 큐에 테일 드롭(tail drop) 정책을 기본으로 한다. 큐가 가득 차면 새로 들어오는 패킷을 단순히 버린다. 이 단순한 규칙은 구현이 쉽지만, 다수의 TCP 플로우가 동시에 혼잡 윈도우를 줄이는 글로벌 동기화(global synchronization) 현상을 일으켜 대역폭 활용률을 떨어뜨린다. 이를 완화하기 위한 AQM(Active Queue Management) 기법으로 RED, CoDel, FQ-CoDel 등이 개발되었다.

4.2. 무선 링크의 비트 오류

Wi-Fi, LTE, 5G 같은 무선 링크에서는 혼잡이 아닌 채널 간섭에 의한 패킷 손실이 빈번하다. 문제는 TCP가 이 둘을 구분하지 못한다는 것이다. 간섭으로 인한 단일 패킷 손실에도 TCP는 혼잡으로 오판하고 전송률을 절반으로 떨어뜨린다. 이 때문에 무선 환경에서는 링크 계층에서의 ARQ(Automatic Repeat reQuest)나 FEC(Forward Error Correction)가 필수적이다.

4.3. 미들박스와 MTU 블랙홀

기업 네트워크 경계에는 방화벽, NAT, 로드 밸런서 같은 미들박스가 깔려 있다. 이들은 종종 MTU보다 큰 패킷을 단편화하거나, ICMP “Fragmentation Needed” 메시지를 차단하여 PMTUD(Path MTU Discovery) 블랙홀을 만든다. 이 경우 특정 크기 이상의 패킷이 조용히 사라지는데, 일반적인 ping으로는 감지되지 않고 대용량 전송 시에만 증상이 나타나 디버깅이 극도로 어렵다.

5. 실측의 도구들: ping을 넘어서

네트워크 문제의 원인을 밝히는 데 있어 평균 지연(ping의 avg 값) 하나에 의존하는 것은 치명적이다. 실제 체감 품질을 좌우하는 것은 지연의 분포와 분산이다. 이를 제대로 보기 위한 몇 가지 도구를 살펴보자.

• mtr (My TraceRoute): traceroute와 ping을 결합한 도구. 각 홉별 손실률과 지연의 중앙값, 표준편차를 실시간으로 보여준다.
• iperf3: 종단 간 대역폭을 정확하게 측정. UDP 모드에서는 지터(jitter)와 손실률을 별도로 보고한다.
• tcptraceroute: TCP SYN 패킷으로 경로를 추적. ICMP가 차단된 경로에서도 동작하며, 실제 TCP 트래픽이 받는 처리를 확인할 수 있다.
• ss -i: Linux에서 현재 TCP 연결별 혼잡 윈도우, 재전송 수, RTT 변동을 실시간 조회.
• pping (passive ping): 실제 트래픽을 가로채 측정하므로 활성 프로빙의 부작용이 없다.

이 도구들을 다룰 때 명심해야 할 것은, 평균보다 p99(99분위)가 훨씬 더 서비스 품질의 현실을 반영한다는 점이다. 평균 지연이 50ms여도 p99가 800ms라면, 100번 중 1번은 사용자가 눈에 띄게 끊김을 느낀다.

“평균은 거짓말한다. 꼬리가 진실을 말한다.
p99와 p999를 보지 않는 SRE는 결국 사용자 불만의 꼬리를 만나게 된다.”

6. 분산 트랜잭션에서의 누적 편향

마이크로서비스 아키텍처가 보편화되면서, 단일 사용자 요청 한 건이 내부에서 수십 개의 서비스 호출로 분기되는 것이 일반적이다. 이때 각 내부 호출에서 발생하는 네트워크 지연은 단순히 합산되지 않는다. 병렬 호출의 완료 시간은 가장 느린 호출에 의해 결정된다는 꼬리 지연(tail latency)의 법칙이 작동한다.

Google의 Jeff Dean은 “The Tail at Scale”(2013)에서 이 현상을 정량화했다. 단일 서비스의 p99 지연이 10ms이고, 한 요청이 100개 서비스를 호출한다면, 적어도 한 호출이 꼬리에 걸릴 확률은 63%가 넘는다. 즉, 거의 모든 사용자 요청이 꼬리 지연을 경험하게 된다. 이 때문에 구글은 요청 복제, 해지 가능한 예비 요청, 백업 요청 등 다양한 기법으로 꼬리를 잘라낸다.

여기서 패킷 손실의 누적 효과가 결정적이다. 손실률 0.1%는 단일 TCP 연결에서는 견딜 만하지만, 100개의 내부 연결을 동시에 사용하는 시스템에서는 매 요청마다 약 10%의 확률로 누군가가 재전송 타이머에 걸린다. 그 타이머가 1초라면, 1%의 사용자가 1초의 불필요한 지연을 경험한다. 이것이 분산 시스템에서 네트워크 품질에 집착해야 하는 이유다.

7. 결론: 네트워크는 눈에 보이지 않지만 수학적으로 계산 가능하다

패킷 손실은 단순한 ‘가끔 일어나는 사고’가 아니다. Mathis 공식이 보여주듯, 손실률은 가능한 처리율의 근본 한계를 결정하는 수학적 인자다. 그리고 그 한계는 사용자 체감 속도, 분산 트랜잭션의 일관성, 궁극적으로는 애플리케이션의 신뢰도로 귀결된다.

과거 수만 개의 무상 호스팅 사이트를 운영하며 우리가 배운 것은, 결국 “네트워크는 계산 가능하다”는 사실이었다. RTT, 손실률, BDP, 그리고 혼잡 제어 알고리즘의 특성을 이해하면, 왜 어떤 경로가 느린지, 어디를 고쳐야 체감이 달라지는지를 수식으로 예측할 수 있다. 감이 아닌 숫자로 이야기해야 네트워크 문제는 풀린다.

다음 글에서는 이 네트워크 위에 구축되는 분산 시스템이 일관성과 가용성 사이에서 어떤 타협을 강요받는지 — 즉 CAP 정리의 세계로 들어가 본다.