고손실 구간에서 전송 속도가 무너지는 가장 큰 이유는 혼잡제어(Congestion Control) 가 손실을 곧바로 혼잡 신호로 해석하고, 과격하게 전송률을 낮추기 때문입니다. 특히 모바일·와이파이·위성처럼 손실과 지터가 섞이는 환경에서는 전통 알고리즘이 대역폭을 제대로 활용하지 못하죠. 여기서는 CUBIC과 BBR을 비교하고, 고손실 네트워크에서 체감 성능을 실제로 끌어올리는 실전 팁을 더 깊게 정리합니다.
1) 혼잡제어의 기본: 대역폭·RTT·손실의 삼각관계
혼잡제어는 송신 윈도우(cwnd)와 전송 속도를 조절해 사용 가능한 대역폭을 최대한 쓰되 지연과 손실을 최소화하는 기술입니다. 핵심은 세 가지 신호의 균형입니다.
- 대역폭(Throughput): 병목 링크가 허용하는 최고 속도. 한계치를 넘으면 큐가 쌓이고 지연이 폭증합니다.
- RTT: 왕복 지연. 큐가 쌓이면 RTT가 늘어나고 변동성(jitter)도 커집니다.
- 손실: 혼잡으로 드롭된 것인지, 무선 오류인지 구분이 중요합니다.
손실=혼잡으로만 보는 접근은 무선 오류가 많은 구간에서 불필요한 감속을 초래합니다. 반대로 지연·RTT 신호를 무시하면 큐 빌드업으로 p95/p99 꼬리 지연이 길어집니다. CUBIC vs BBR의 차이는 바로 이 해석 방식에 있습니다.
2) CUBIC: 손실 기반의 탄탄한 기본값
CUBIC은 손실을 혼잡 신호로 보고, 큐빅 함수로 cwnd를 늘렸다 줄입니다. 장점과 한계를 정확히 이해해두면 선택이 쉬워집니다.
- 장점
- RTT 편향이 적어 고속 유선망에서 공정성이 우수합니다.
- 대부분의 OS와 클라우드에서 기본값이라 상호 운용성이 좋아요.
- 트래픽 혼합 상황에서 과도한 공격성을 보이지 않아 운영 리스크가 낮습니다.
- 한계(고손실 환경)
- 무선 오류까지 손실로 해석해 과감한 감속이 잦습니다.
- 회복 곡선이 상대적으로 느려 평균 스루풋이 낮고, 꼬리 지연이 길어지기 쉽습니다.
- 언제 맞나
- 코어망 혼잡이 명확하고, 손실이 실제 혼잡 신호일 때
- 다수 참여자가 CUBIC/RENO인 공존 환경에서 공정성을 우선할 때
3) BBR: 대역폭·RTT 모델 기반의 현대적 접근
BBR(Bottleneck Bandwidth and RTT) 는 손실 대신 병목 대역폭(BtlBw) 과 최소 RTT(minRTT) 를 추정해 pacing 으로 전송률을 맞춥니다.
- 핵심 아이디어
- “가용 대역폭 × 최소 RTT”를 기준으로, 큐가 차기 전에 속도를 정합니다.
- 손실이 높아도 대역폭이 살아 있으면 감속하지 않음 → 활용률↑
- 효과
- 초기 수렴이 빠르고, 작은 세션(API/이미지)에서도 체감 개선이 큽니다.
- 무선 손실이 잦아도 평균 스루풋을 잘 유지합니다.
- BBR v2 개선점
- 경쟁 알고리즘(CUBIC 등)과의 공정성 보강
- ECN 신호 반영, 큐 빌드업 억제 강화 → 지연 안정성 향상
- 주의
- 과한 pacing 설정은 오히려 큐를 만들 수 있습니다(특히 라스트마일 버퍼가 작을 때).
- 경로별/리전별로 지표를 보며 점진 도입이 안전합니다.
4) 고손실 네트워크에서의 선택과 조합
- 무선·위성·모바일 이동
- 손실률 1~5% 구간에서도 BBR이 속도 유지를 잘함.
- 스트리밍/텔레메트리/화상 같은 연속 트래픽에 특히 유리합니다.
- 혼합 트래픽·레거시 공존
- 외부 공개 API나 파트너 연계처럼 상대가 대부분 CUBIC이면, BBR v2 또는 도메인 분리(내부=BBR, 외부=CUBIC) 전략이 현실적입니다.
- 짧은 세션/소량 객체
- BBR은 초기에 빠르게 목표에 도달해 API·이미지·타일에서 TTFB/완료시간이 줄어듭니다.
- initcwnd(초기 윈도우)와 어플리케이션 레벨 리트라이 백오프가 결과를 좌우합니다.
5) HTTP/3(QUIC)와의 시너지
QUIC은 사용자 공간에서 동작해 정밀 pacing, 스트림 단위 복구, HOL 블로킹 제거를 제공합니다.
- BBR + QUIC
- 스트림별 독립 회복으로 손실의 국소화 → 꼬리 지연 감소
- 정밀 pacing 타이머로 대역폭 추정이 더 안정
- CUBIC + QUIC
- 구현 가능하며, TCP 대비 재전송·손실 처리에서 이점을 얻습니다.
- 그러나 고손실 환경의 체감 개선 폭은 보통 BBR 조합이 더 큽니다.
- 운영 팁
- H3(HTTP/3) 경로에서 우선 A/B를 돌리고, 서버↔클라이언트 양쪽이 H3 지원인지 확인합니다.
- MTU/PMTUD 실패 시 단편화가 성능을 크게 깎으니 보수적으로 세팅하세요.
6) 운영 튜닝 포인트(실전)
- 알고리즘 스코핑
- 전면 전환 대신 손실 상위 경로(해외 리전, 모바일 게이트웨이, 위성 백홀)부터 BBR 적용 → 24~72시간 A/B.
- pacing_rate·cwnd 캡
- BBR의 핵심은 pacing. 상한(cap) 을 두고 p95 지연·큐 길이를 모니터링합니다.
- 과도하면 queue build-up → 지연 폭증 루프가 생깁니다.
- ECN 활성화
- 스위치·LB가 지원하면 ECN으로 손실 없이 혼잡을 신호화 → BBR v2의 지연 안정성↑.
- MTU/MSS 보정
- VPN/무선 구간에서 단편화가 있으면 재전송 폭탄이 발생합니다. MSS 고정 및 보수적 MTU로 시작.
- 초기 윈도우(initcwnd)/재시도 설계
- 짧은 세션 비중이 크면 initcwnd를 소폭 키우고, 앱 레벨 리트라이는 지수 백오프 + 지터로 제한(최대 2~3회).
- 관측 대시보드
- Throughput, TTFB, p95/p99, 손실률, 재전송률, ECN mark율, inflight 바이트, pacing rate.
- 같은 요일·시간대에 전/후 비교로만 판단하세요.
- 캐시·압축·애플리케이션 협업
- 네트워크가 좋아져도 쓸모없는 바이트를 줄이지 않으면 체감이 제한됩니다. 캐시 키 정리, 이미지/텍스트 압축 임계치, 서버 사이드 렌더 단위 최적화와 병행하세요.
7) 체크리스트: 바로 적용
- 손실 상위 경로 부분 전환(BBR v2) → 72시간 A/B
- pacing 상한·cwnd 캡 설정, p95 지연·큐 길이 모니터
- ECN 지원 경로 점검 및 활성화
- MTU/MSS 일관성 확보, 단편화 최소화
- initcwnd 합리화(짧은 세션 위주 서비스)
- HTTP/3(QUIC) 우선 경로에서 테스트
- 대시보드에 Throughput·Loss·RTT·ECN·Inflight·Pacing 고정 노출
8) 자주 묻는 질문(FAQ)
Q. 손실률이 높으면 무조건 BBR이 정답인가요?
A. 아닙니다. 손실이 무선 오류성이면 BBR이 유리하지만, 코어 혼잡이 뚜렷하면 CUBIC이 더 안정적일 수 있습니다. 반드시 경로별 A/B로 확인하세요.
Q. BBR이 ‘공정하지 않다’는 피드백이 있습니다.
A. BBR v2로 전환하고 ECN을 켠 다음, pacing 상한을 낮춰 큐 빌드업을 억제하세요. 공정성 메트릭(공유 링크에서 타 플로우의 스루풋)을 함께 보세요.
Q. 짧은 HTTP 요청 위주 서비스에선 무엇이 더 유리합니까?
A. 대개 BBR입니다. 초기 수렴이 빠르고, initcwnd 최적화와 맞물리면 TTFB가 안정적으로 내려갑니다.
Q. TCP와 QUIC 중 무엇부터 바꿔야 하나요?
A. 인프라 여건이 되면 H3(QUIC) 경로에서 A/B를 먼저 진행하세요. 그다음 TCP 경로에 BBR을 단계 적용하는 순서가 안전합니다.
마무리
Congestion Control(BBR/CUBIC) 의 선택은 환경 의존적입니다. 손실은 많은데 대역폭은 살아 있는 구간이라면 BBR이 평균 스루풋을 끌어올리고, 코어 혼잡이 잦은 구간에서는 CUBIC의 보수성이 예측 가능성을 줍니다. 정답은 부분 도입 → 지표 검증 → 점진 확대입니다.
오늘은 손실 상위 경로에 BBR v2 + ECN을 켜고 pacing 상한을 잡아보세요. 내일은 HTTP/3 구간과 MTU/MSS를 손보세요. 대역폭 활용률은 오르고, p95/p99 지연 꼬리는 짧아질 것입니다.