BGP 인터넷 라우팅 완전 가이드 2025: AS, Peering, Path Selection, RPKI, Anycast — 인터넷의 진짜 작동 원리

A.

IGP vs BGP의 근본 차이:

IGP (OSPF, IS-IS, RIP)는 단일 관리 도메인 내에서 작동한다. 목표: 최단 경로 또는 가장 빠른 경로. 한 조직이 모든 라우터를 통제하므로 단순한 메트릭 (hop count, link cost)이면 충분.

BGP는 서로 다른 조직 간 통신이다. 수만 개의 AS가 각자의 이익과 정책을 가진다. 단순히 "최단"이 기준이 될 수 없다. 왜?

이유 1: 경제적 고려

Transit vs Peering의 차이:

내 AS → Peering으로 Facebook: 무료
내 AS → Transit ISP → Facebook: 돈 지불

단순 hop 수로는 둘 다 같을 수 있다. 하지만 비용은 극적으로 다르다. BGP operator는 돈을 안 내는 경로를 선호한다.

LOCAL_PREF attribute로 이를 표현:

• Customer 경로: LOCAL_PREF = 200 (수익 창출, 최우선).
• Peer 경로: LOCAL_PREF = 100 (무료).
• Transit 경로: LOCAL_PREF = 50 (비용 발생, 최후).

이유 2: 성능 vs Hop Count

Hop 수가 적다고 빠른 게 아니다:

경로 A: 3 hop, 하지만 혼잡한 peering 경로
경로 B: 5 hop, 여유 있는 tier 1 전용선

경로 B가 실제로는 빠를 수 있다. BGP는 이를 정책으로 반영:

• 특정 경로를 prefer/deprefer.
• AS_PATH prepending으로 덜 매력적으로.
• Community로 원격 AS에게 힌트.

이유 3: 안정성과 신뢰

신뢰할 수 있는 이웃 선호:

Cloudflare는 2015년 Hacking Team의 BGP hijack을 피하려고 특정 AS를 차단했다. 단순 최단 경로였다면 침해당했을 것.

정치적 이유:

• 분쟁 중인 국가의 네트워크 우회.
• 감시 우려가 있는 경로 회피.
• 규제 준수 (특정 국가 경유 금지).

이유 4: 트래픽 엔지니어링

링크 부하 관리:

• 한 링크가 과부하면 일부 트래픽을 다른 링크로 유도.
• AS_PATH prepending, MED, community 사용.
• 이는 "최단 경로"와 무관.

이중화 경로:

• 기본 경로 + 백업 경로.
• 기본이 죽으면 백업으로.
• 평소엔 백업을 의도적으로 덜 매력적으로.

이유 5: 상호 합의

Peering 계약:

"너는 너의 고객에게만 우리를 알리고,
 우리도 우리 고객에게만 너를 알린다.
 제3자 (우리 peer나 transit)에게는 안 된다."

이 Valley-Free Routing 원칙은 단순 최단 경로로는 표현 불가. 정책이 필요.

결과:

BGP의 decision process는 수십 개 단계:

1. Highest LOCAL_PREF (정책).
2. Shortest AS_PATH (약간의 최단성).
3. Lowest ORIGIN.
4. Lowest MED (이웃의 선호).
5. eBGP over iBGP.
6. ...

최단 경로는 2단계에서 등장하지만, 1단계 (LOCAL_PREF)가 우선한다. 경제와 정책이 거리보다 중요하다.

"인터넷은 엔지니어링이 아닌 정치학":

BGP는 기술적으로 최적 경로를 찾지 않는다. 경제적/정책적으로 받아들일 수 있는 경로를 찾는다. 이는 버그가 아니라 기능이다. 75,000개의 독립적인 조직이 협력하려면 각자의 이익을 존중하는 프로토콜이 필요하다.

교훈:

인터넷의 놀라운 점은 "서로 이해관계가 다른 75,000개의 조직이 자발적으로 협력"하는 것이다. BGP는 이 협력을 가능하게 하는 정치적 프로토콜이다. 기술적으로 우아하진 않지만, 작동한다. 그리고 40년 넘게 작동해 왔다.

최단 경로 알고리즘을 사용했다면 인터넷은 존재하지 않았을 것이다. 모든 AS가 "내 돈 안 내는 경로"를 강제할 수 없다면 peering 자체가 성립 안 된다. BGP의 "추악한" 복잡성이 사실은 인터넷의 정치적 기적을 가능하게 한다.

A.

정의의 차이:

Transit: Customer-Provider 관계.

• Customer가 Provider에게 돈을 낸다.
• Provider는 customer에게 인터넷 전체의 경로를 제공.
• Customer의 트래픽을 어디든 전달.

Peering: Equal Exchange 관계.

• 보통 돈 지불 없음 (또는 소액).
• 두 AS가 서로의 고객 간 트래픽만 교환.
• 제3자 (다른 peer)의 트래픽은 거래 대상 아님.

트래픽 흐름의 차이:

Transit 예시:

My AS → Transit ISP → 세계 어디든 (Google, Facebook, 중국 등)

Transit ISP가 나를 위해 인터넷 전체에 연결.

Peering 예시:

My AS (customers: 1M users) ←→ Netflix AS (customer: Netflix)

내 고객 ↔ Netflix 직접. 빠르고 무료. 하지만 Netflix를 통해 Google에 못 감.

경제적 관점:

Transit 비용 (대략):

• 대도시, 1 Gbps: $500-2,000/month.
• 소도시, 1 Gbps: $2,000-10,000/month.
• 100 Gbps: $20,000-100,000/month.

Peering 비용:

• Public peering (IX): $500-5,000/month (포트 비용).
• Private peering: Cross-connect fee (~$200/month).
• 실제 트래픽: 무료.

Peering은 극적으로 저렴. 트래픽이 많을수록 차이 증가.

Tier 1의 정의:

Tier 1 ISP: 어떤 transit도 구매하지 않고 전 세계 모든 AS에 도달 가능한 ISP.

Tier 1의 특징:

• Settlement-free peering만 함 (다른 Tier 1과 상호 무료 교환).
• 약 12-20개 존재 (명확한 리스트 없음).
• 예: AT&T, Verizon, Level 3 (Lumen), Cogent, NTT, Telia, Deutsche Telekom, Tata Communications...

왜 peering만 하는가:

답 1: 정의상 그렇다

Tier 1은 "transit 안 사는 AS"로 정의된다. 만약 transit을 산다면 그 순간 Tier 1이 아니게 된다. 단순한 tautology다.

답 2: 상호 의존성

Tier 1은 모두 평등하다는 암묵적 합의가 있다. 만약 AT&T가 Verizon에게 돈을 내면:

• AT&T < Verizon을 의미.
• AT&T의 위상 하락.
• 시장 권력 균형 깨짐.

그래서 상호 무료 peering이 표준. "우리는 동등하다".

답 3: 순수 경제

Tier 1은 다음을 가진다:

• 자체 글로벌 백본: 수십 ~ 수백 국가.
• 자체 고객: 수만 개 기업, 작은 ISP.
• 자체 peering: 다른 Tier 1, 대형 콘텐츠 회사 (Google, Facebook).

이미 "인터넷 전체"에 도달 가능. transit을 살 이유가 없다.

답 4: 비즈니스 모델

Tier 1의 수익:

• Customer (작은 ISP, 기업)에게 transit 판매.
• 대역폭 사용량 과금.
• 수십억 달러 규모.

Transit을 산다면 비용 발생 → 수익률 감소.

Peering이 "공짜"인 이유:

"공짜 peering"은 사실 상호 이익이다:

A가 B에게 peering 제안:

• A의 고객이 B의 콘텐츠를 원함 (traffic in).
• B의 고객이 A의 콘텐츠를 원함 (traffic out).
• 양쪽 모두 서로가 필요.
• Transit 대신 peering으로 비용 절감.

핵심 조건:

• 트래픽 비율이 비슷해야 (보통 1:2 이내).
• 지리적 커버리지 비슷.
• 규모 비슷.

비대칭이면 peering 거부:

• Netflix → ISP: Netflix가 훨씬 많이 보냄.
• 초기엔 ISP들이 peering 거부.
• Netflix가 transit으로 돈 내거나, CDN 구축.
• 현재는 대부분 ISP가 Netflix와 peering (트래픽이 너무 많아 어쩔 수 없이).

Settlement vs Paid Peering:

드물지만 돈이 오가는 peering:

• 한쪽이 훨씬 강력할 때.
• Netflix가 Comcast에 "paid peering" 지불 (2014).
• 논란: "망 중립성" 위반 주장.

Tier 1 간 긴장:

Tier 1들도 peering 분쟁이 있다:

Cogent vs Level 3 (2005):

• 트래픽 불균형 주장.
• Level 3가 Cogent를 일방적으로 depeer (peering 종료).
• 3주간 인터넷 분열: Cogent 고객이 Level 3 고객에게 도달 불가.
• 결국 재peering.

이런 분쟁은 인터넷의 취약성을 보여준다. "하나의 인터넷"이 실제론 정치적 합의에 의존.

현대 변화:

Content ISP의 부상:

• Google, Facebook, Netflix, Amazon이 자체 AS + 자체 글로벌 네트워크.
• Tier 1과 동급이 됨.
• 전통 Tier 1 (Level 3 등)이 콘텐츠 회사보다 덜 중요해짐.

Peering의 민주화:

• Internet Exchange (IX)가 많아짐.
• 작은 네트워크도 peering 가능.
• DE-CIX, AMS-IX, LINX 등에 수백~수천 참여자.

교훈:

Peering과 Transit은 인터넷의 경제 구조를 정의한다. BGP는 기술이지만, 이 기술을 돌리는 것은 경제와 정치다.

• 돈 많은 회사 → transit 구매 여유.
• 대규모 콘텐츠 회사 → peering 협상력.
• 작은 ISP → transit 의존.

인터넷의 "평등"은 환상이다. 실제로는 계층 구조가 명확하며, Tier 1이 그 정점에 있다. 하지만 이 계층이 협력하기 때문에 우리가 "하나의 인터넷"을 경험한다.

다음에 당신의 패킷이 Google로 갈 때, 그 경로의 각 hop마다 돈과 정치적 결정이 개입되어 있음을 기억하자. 이것이 진짜 인터넷이다.

A.

BGP의 근본적 취약점:

BGP는 1980년대에 설계되었다. 당시 인터넷은 신뢰 기반 학술 네트워크. "누가 거짓말을 하겠어?"라는 가정.

문제: BGP는 광고된 prefix가 진짜인지 검증하지 않는다.

어떤 AS가 광고함: "8.8.8.0/24 (Google DNS)는 내가 가지고 있어!"
다른 AS: "알았어. 너에게 라우팅할게."

검증 없음. 단지 받아들임.

Hijacking의 종류:

1. Prefix Hijacking (원본 위조):

공격자 AS가 다른 AS의 prefix를 자기 것인 것처럼 광고:

정당한 소유자: Google AS 15169 광고 "8.8.8.0/24"
공격자: AS 99999 광고 "8.8.8.0/24"

BGP의 "more specific prefix wins" 규칙 때문에 더 작은 prefix가 이긴다:

Google: "8.8.8.0/24" (256개 주소)
공격자: "8.8.8.0/25" (128개 주소) ← 이긴다!

더 작은 prefix (긴 mask)가 route lookup에서 우선된다. 공격자가 /25 또는 더 작게 광고하면 트래픽이 공격자에게.

2. AS Path Manipulation:

공격자가 가짜 AS_PATH로 광고:

공격자 AS 99999 광고:
  prefix: 8.8.8.0/24
  AS_PATH: [99999, 15169]  # "Google과 연결되어 있어!"

다른 AS는 "공격자를 통해 Google로 갈 수 있음"으로 오해.

3. Route Leak:

실수로 peer 경로를 transit에게 광고:

A는 B의 peer (서로 고객 교환)
A는 C의 customer (C가 transit)
A가 실수로 B의 경로를 C에게 광고
C → A → B로 트래픽
A는 대량 트래픽을 감당 못함 → 장애

2019년 Verizon 사건이 이 유형.

실제 사례들:

2008 Pakistan YouTube:

• Pakistan Telecom이 YouTube 국내 차단용으로 208.65.153.0/24 광고.
• 실수로 전 세계에 전파.
• BGP가 더 구체적 prefix를 받아들임.
• 전 세계 YouTube 트래픽이 Pakistan으로.
• 수 시간 다운.

2018 Amazon Route 53:

• 공격자가 Amazon DNS (205.251.192.0/24)를 hijack.
• 암호화폐 지갑 사이트 조회가 가짜 DNS 응답.
• 사용자가 가짜 지갑 사이트로.
• 수십만 달러 탈취.

2021 Twitter:

• AS가 짧은 시간 Twitter IP hijack.
• 탐지와 복구 빠름.

RPKI: Resource Public Key Infrastructure

암호학적 해결책. 2011년 표준화.

기본 아이디어:

1. RIR이 인증서 발급: ARIN, RIPE, APNIC 등이 각 AS와 prefix 할당을 인증.

2. ROA 생성: 소유자가 "이 prefix를 이 AS가 광고할 권한이 있음" 이라는 서명된 선언 생성.

Resource Origin Authorization (ROA):
  Prefix: 8.8.8.0/24
  ASN: 15169 (Google)
  Max Length: 24
  Signed by: ARIN (via certificate chain)
  Valid Until: 2026-01-01

3. RPKI Repository: 모든 ROA를 공개 저장소에.

4. Router Validation: BGP 라우터가 RPKI 정보를 가져와 실시간 검증.

검증 프로세스:

라우터가 BGP UPDATE 받음:

Prefix: 8.8.8.0/24
AS_PATH: [..., 99999]  # 위조

라우터가 RPKI 확인:

ROA 조회: 8.8.8.0/24 who owns?
답변: AS 15169 (Google)

AS 99999 ≠ AS 15169 → INVALID → 경로 거부.

4가지 상태:

• Valid: ROA가 있고 origin AS와 일치.
• Invalid: ROA가 있지만 일치 안 함 → 위험.
• Not Found: ROA 없음 → 중립.
• Unknown: 기술적 에러.

실전 행동:

• Valid: 경로 수용 + LOCAL_PREF 상향.
• Invalid: 경로 거부.
• Not Found: 일반 처리.

RPKI의 한계:

1. Origin만 검증:

• "누가 광고하는가"만 확인.
• 경로 중간의 변조는 검증 못 함.
• 예: A → B → C를 A → X → Y → C로 조작 가능.

2. 배포 불완전:

• 2025년 기준 전체 prefix의 ~50%만 ROA 있음.
• 나머지는 Not Found (검증 불가).
• 완전 방어 불가.

3. 실수 ROA:

• 잘못 작성된 ROA가 정당한 경로를 거부.
• 2019년 Cloudflare 자체 실수로 일부 경로 invalid 처리.

4. ROA 관리 부담:

• prefix 변경 시 ROA 업데이트 필요.
• 자동화 안 되면 실수 가능.

BGPsec: 완전한 해결책?

BGPsec: BGP UPDATE 전체를 암호학적으로 서명. 각 AS가 자기 서명 추가.

AS_PATH: [AS1 (sig by AS1), AS2 (sig by AS2), AS3 (sig by AS3)]

각 홉에서 이전 서명 검증 + 자기 서명 추가.

장점: 완벽한 경로 검증.

단점:

• 매우 느림: 서명 검증 = CPU 부담.
• 메모리 폭발: 서명 저장.
• 모든 라우터 업그레이드 필요: 한 곳이라도 미지원이면 무의미.

결과: 2025년까지도 배포 거의 0%. 실용화 어려움.

현대 방어 전략:

1. RPKI 완전 채택:

• Cloudflare, Google, Microsoft 강력 push.
• 많은 ISP가 이제 기본 drop.

2. Route Filtering:

• IRR (Internet Routing Registry) 기반 필터.
• 이웃이 광고할 수 있는 것을 미리 합의.
• Prefix list.

3. BGP Monitoring:

• BGPStream, RIPE RIS 등 실시간 모니터링.
• 이상 감지 시 자동 알림.
• Cloudflare Radar 같은 공개 dashboard.

4. MANRS:

• Mutually Agreed Norms for Routing Security.
• 참여 AS가 베스트 프랙티스 약속.
• 2025년 기준 800+ 참여.

교훈:

BGP 보안의 교훈:

1. 프로토콜은 업그레이드가 어렵다:

• 1980년대에 설계된 결함이 2020년대까지.
• 수만 조직의 조율 필요.
• "기술적 부채"의 극단적 사례.

2. 완벽한 방어는 없다:

• RPKI는 origin만 방어.
• BGPsec은 배포 못 함.
• 실시간 모니터링과 빠른 대응이 중요.

3. 신뢰 기반의 취약성:

• 초기 인터넷은 "선의"에 의존.
• 규모가 커지면 악의적 행위자 필연.
• 보안은 처음부터 설계해야.

4. 경제적 유인:

• RPKI 구현은 투자가 필요.
• 일부 ISP는 "남이 하면 되지" 태도.
• 인프라 보안은 공공재 문제.

5. 교육과 인식:

• 많은 실수가 BGP 오퍼레이터의 교육 부족.
• 복잡한 프로토콜, 소수 전문가.

결론:

BGP hijacking은 해결되지 않은 문제다. RPKI는 큰 진전이지만 완벽하지 않다. 진정한 해결책은:

1. RPKI 100% 채택.
2. BGPsec 또는 대체 기술.
3. 실시간 모니터링과 자동 대응.
4. 국제 협력과 표준.

이는 수십 년의 노력을 요구한다. 그 동안 우리는 "BGP는 불완전하다" 는 사실을 인지하고, 중요한 시스템에는 추가 방어 (암호화, 인증, 모니터링)를 둬야 한다.

인터넷은 40년 넘게 "동작하지 않아야 할 시스템이 기적적으로 동작"하고 있다. BGP는 그 기적의 핵심이며, 보안 역시 끊임없이 진화 중이다.

A.

Anycast의 정의:

하나의 IP 주소를 여러 물리적 위치에서 BGP로 광고. 각 사용자의 요청은 BGP 경로 선택에 따라 가장 가까운 위치로 라우팅.

Unicast vs Anycast:

Unicast (일반):

IP 1.1.1.1 → 단 하나의 서버 (예: 미국 Virginia)
전 세계 사용자가 모두 Virginia로

Anycast:

IP 1.1.1.1 → 여러 서버 (미국 Virginia, 영국 London, 일본 Tokyo, ...)
한국 사용자 → Tokyo (가장 가까움)
영국 사용자 → London
미국 사용자 → Virginia

기술적 구현:

단계 1: 같은 prefix를 여러 장소에서 광고:

Cloudflare 네트워크:

Virginia (AS 13335, via ISP A): 1.1.1.0/24 광고
London (AS 13335, via ISP B): 1.1.1.0/24 광고
Tokyo (AS 13335, via ISP C): 1.1.1.0/24 광고
... 300+ POP ...

같은 AS number, 같은 prefix, 여러 BGP 세션.

단계 2: BGP Path Selection:

사용자의 패킷이 인터넷에 도착하면:

• 사용자의 ISP가 BGP 경로 테이블 확인.
• 1.1.1.0/24 에 대해 여러 경로가 있음.
• BGP가 가장 짧은 AS_PATH 또는 정책 기반으로 선택.
• 보통 가장 가까운 광고 지점이 선택됨.

단계 3: 패킷 전달:

선택된 경로를 따라 패킷이 흐름. 실제로 가장 가까운 Cloudflare POP에 도착.

"가장 가까운"의 의미:

BGP에서 "가까움"은 AS hop 수 기반. 물리적 거리와 항상 일치하지 않음:

• Tokyo 사용자 → Tokyo POP (1-2 hops).
• 하지만 때때로 "미국 경유"가 BGP상 더 짧을 수도.
• Local ISP의 peering 선택이 좌우.

예시: Cloudflare 1.1.1.1:

사용자가 dig @1.1.1.1 google.com 실행:

1. 사용자 ISP가 1.1.1.1의 경로 확인.
2. 여러 경로 중 하나 선택 (BGP 결정).
3. 패킷이 그 경로로 이동.
4. 중간 라우터들도 같은 결정.
5. 가장 가까운 Cloudflare POP에 도착.
6. POP이 DNS 응답.

사용자는 자신이 어느 POP과 통신하는지 모른다. 그저 "1.1.1.1"에 묻고 답을 받는다.

사용 사례:

1. DNS:

• Cloudflare DNS (1.1.1.1).
• Google DNS (8.8.8.8).
• OpenDNS.
• 모두 anycast로 글로벌 서비스.

왜 DNS에 적합:

• UDP 기반: 연결 없음, 경로 변경 OK.
• 짧은 응답: 재전송 저렴.
• 저지연이 중요: 지리적 가까움.

2. CDN:

• Cloudflare, Fastly, Akamai.
• 정적 콘텐츠 edge 캐시.
• 단일 URL → 가장 가까운 POP.

3. DDoS 방어:

• 공격 트래픽이 여러 POP에 분산.
• 단일 POP의 한계 초과해도 총 용량은 극대.
• Cloudflare가 수백 Gbps DDoS를 흡수.

4. NTP (시간 동기화):

• time.google.com, time.cloudflare.com.
• 가장 가까운 서버로 낮은 jitter.

5. QUIC/HTTP/3:

• UDP 기반이라 anycast 친화적.
• Connection migration 지원 (경로 변경 OK).

HTTPS / TCP의 어려움:

전통적 문제:

• TCP 연결은 stateful.
• 중간에 BGP 경로 변경 → 패킷이 다른 POP으로.
• 다른 POP엔 연결 상태 없음 → RST (연결 끊김).

해결책:

1. Sticky Routing:

• 같은 사용자 → 같은 POP 일관되게.
• BGP 경로가 바뀌어도 짧은 시간만 다름.
• 대부분 TCP 연결은 short-lived → 괜찮음.

2. Session Sync:

• 여러 POP이 TCP 상태 공유.
• 복잡, 오버헤드 큼.
• 실전에선 잘 안 씀.

3. Load Balancing 뒤에:

• Anycast IP → L4 LB → Backend.
• L4 LB가 stateful 처리.
• BGP 변경 시 약간의 손실 감수.

4. QUIC 전환:

• QUIC는 connection ID 기반.
• IP 변경에 강함.
• 미래의 방향.

Cloudflare의 아키텍처:

Cloudflare는 anycast를 극한으로 활용:

• 300+ POP 전 세계.
• 모든 고객 사이트가 같은 anycast IP 범위.
• BGP가 자동으로 사용자를 가까운 POP으로.
• 각 POP이 모든 고객을 서비스.

효과:

• 낮은 지연: 평균 50ms 미만 (글로벌).
• 자동 failover: POP 다운 시 BGP가 자동 우회.
• 무한 확장: POP 추가 = 자동 부하 분산.
• DDoS 방어: 전 세계 용량을 한 고객에게.

한계와 함정:

1. 비결정적 라우팅:

• 어느 POP으로 가는지 예측 어려움.
• 같은 사용자가 짧은 시간에 다른 POP 방문 가능.
• 디버깅 어려움.

2. BGP 지식 필요:

• 복잡한 설정.
• BGP 에러가 큰 영향.
• 전문 지식 요구.

3. 비용:

• 여러 POP 운영.
• BGP peering 관리.
• Tier 1/2 ISP 관계.

4. 데이터 locality:

• 각 POP이 같은 데이터를 가져야 함.
• 전 세계 동기화 필요.
• 복제/캐싱 인프라.

5. 정치적 우회:

• 국가 간 라우팅은 BGP 정책의 결과.
• 때때로 "중국 경유 일본 사용자"처럼 이상한 경로.

Anycast의 대안:

GeoDNS:

• DNS가 사용자 위치에 따라 다른 IP 반환.
• 단순하지만 덜 정확.
• DNS 캐싱 문제.

GSLB (Global Server Load Balancing):

• 제품 기반 (F5, Citrix).
• 다양한 기준으로 라우팅.
• 비쌈.

CDN 자체:

• Anycast + smart routing 조합.
• 최고의 성능.

교훈:

Anycast는 단순한 아이디어, 강력한 결과의 예다. "같은 IP를 여러 곳에서 광고" = BGP가 알아서 처리. 이 40년 된 프로토콜이 현대 인터넷의 핵심 기능을 만든다.

핵심 통찰:

1. BGP가 "의도치 않게" 로드 밸런싱을 제공한다.
2. DNS 같은 stateless 서비스에 완벽.
3. TCP도 가능하지만 주의 필요.
4. QUIC와 함께 진정한 TCP+ anycast 가능.

당신이 1.1.1.1 DNS를 쓸 때, 당신의 쿼리는 당신과 물리적으로 가장 가까운 Cloudflare POP으로 간다. 미국에 있으면 미국 POP, 한국에 있으면 일본 POP (Cloudflare 한국 POP이 없으면). 이 모든 것이 사용자가 의식하지 못한 채 일어난다.

그것이 Anycast의 마법이다. 복잡한 글로벌 분산을 단순한 IP 주소 하나로 추상화한다. 사용자는 복잡성을 보지 못하지만, 그 혜택 (낮은 지연, 높은 가용성, DDoS 방어)을 누린다.

인터넷의 배후에서 BGP는 끊임없이 경로를 계산한다. Anycast는 그 계산을 우리를 위한 최적화로 바꾸는 영리한 트릭이다.

A.

2021년 10월 4일, 오후 3시 40분 (UTC):

Facebook, Instagram, WhatsApp, Messenger가 동시에 인터넷에서 사라졌다. 전 세계 35억 사용자가 영향을 받았다. 6시간 만에 복구되었고, Facebook이 공식 사후 분석을 발표했다.

타임라인:

15:40 UTC: Facebook 엔지니어가 네트워크 유지보수 명령 실행. 백본 네트워크 용량 평가가 목적.

15:41 UTC: 의도치 않게 전체 백본에 영향을 주는 명령이 실행됨. 이 명령이 Facebook의 DNS 서버에 도달하는 모든 BGP 경로를 제거.

15:41 UTC (즉시):

• Facebook의 DNS 서버들이 자신들이 네트워크에서 "분리"된 것을 감지.
• DNS 서버들이 자체 안전 장치로 BGP 광고를 자진 withdraw.
• "이상하니까 나를 쓰지 마" → 세계에 알림.

결과:

• facebook.com, instagram.com, whatsapp.com 등의 DNS resolution 실패.
• 사용자 브라우저: "DNS_PROBE_FINISHED_NXDOMAIN".
• 앱: 에러 또는 infinite loading.
• Facebook이 인터넷에서 사라짐.

더 심각한 연쇄 효과:

1. 내부 시스템 접근 불가:

• Facebook 엔지니어들의 VPN, 사내 메일, 인증 시스템이 모두 facebook.com 기반.
• 엔지니어가 원격으로 문제를 고칠 수 없음.

2. 물리적 시설 접근 문제:

• 데이터센터의 카드 키 시스템이 Facebook 인증 API에 의존.
• 직원이 데이터센터에 물리적으로도 못 들어감.

3. 공식 커뮤니케이션:

• 내부 슬랙 (Workplace by Facebook)도 다운.
• 엔지니어들이 Twitter, Discord로 조율.

복구 시도:

1. 원격 복구 불가 확인: BGP 설정 복구가 원격으로 불가능.

2. 물리적 출동: 엔지니어들이 데이터센터로 이동.

3. 카드 키 문제: 보안 시스템에 우회 접근 필요.

4. 그라인더와 각력: 일부 보도에 따르면 문자 그대로 각력 도구로 서버실 문을 열었다 (Facebook은 공식 부인).

5. 수동 복구: 각 데이터센터의 라우터를 손으로 재구성.

6. 점진적 BGP 광고 재시작: 한 번에 모든 것을 올리면 트래픽 폭풍. 단계적 복구.

7. 21:05 UTC: 서비스 완전 복구. 약 6시간.

기술적 분석:

DNS 서버의 자동 withdraw 로직:

Facebook의 DNS 인프라는 안전 장치로 다음을 구현:

• DNS 서버가 백본 네트워크와의 통신을 지속적으로 체크.
• 연결이 끊기면 "나는 외로움" 상태.
• 이 상태에서 BGP 광고 철회 → "나 쓰지 마".

이 로직은 정상적으론 좋은 설계:

• 분리된 DNS 서버가 stale 응답을 주지 않게.
• 네트워크 복구 후 자동 재합류.

문제는 공시성:

• 모든 DNS 서버가 동시에 백본과 분리.
• 모두 동시에 withdraw.
• 완전한 DNS 블랙아웃.

원래의 유지보수 명령:

Facebook의 post-mortem에 따르면:

• 엔지니어가 명령 실행.
• 검증 시스템 버그로 위험한 명령이 차단 안 됨.
• 명령이 전체 백본 설정을 변경.
• DNS 서버로의 모든 경로 제거.

두 가지 연쇄 실패:

1. 설정 검증 버그: 위험한 명령이 통과.
2. DNS auto-withdraw: 설계상 안전 장치가 오히려 악화.

Post-mortem의 교훈:

Facebook의 공개 사후 분석에서 밝힌 것:

1. 검증 시스템 강화:

• 백본 설정 변경에 더 엄격한 검증.
• 자동 롤백 메커니즘.

2. Out-of-band 관리:

• BGP와 독립적인 관리 네트워크.
• 원격 복구를 위한 별도 경로.

3. DNS 로직 개선:

• Gradual withdrawal: 갑작스런 전면 철회 방지.
• 연결 복구 시 빠른 재광고.

4. 물리적 접근 redundancy:

• 카드 키 시스템이 인터넷 인증에 의존 안 하게.
• Offline fallback.

5. 내부 시스템 decoupling:

• 내부 도구가 외부 서비스에 의존하지 않게.
• "dogfooding"의 한계.

업계 전반의 교훈:

1. 자동화의 양면성:

• 자동화는 효율을 주지만 실수를 증폭.
• 한 명의 명령이 전체 조직을 영향.
• "Blast radius" 고려 필수.

2. 의존성 사이클:

• 내부 시스템이 자체 서비스에 의존.
• 자체 서비스가 다운되면 복구도 불가.
• 독립성이 내결함성의 기초.

3. BGP의 파워:

• BGP 한 번의 실수가 전 세계를 영향.
• 6시간 다운타임의 비즈니스 손실 수억 달러.
• 프로토콜의 정치적, 경제적 영향력.

4. 사이트 신뢰성의 본질:

• 완벽한 시스템은 없다.
• 빠른 복구와 학습이 핵심.
• Post-mortem 공유로 업계 발전.

유사 사건들:

Facebook 사건이 유일하지 않다:

Amazon S3 2017:

• 엔지니어 오타로 잘못된 명령.
• S3의 핵심 서비스 몇 시간 다운.
• 인터넷의 상당 부분 영향.

Slack 2022:

• 네트워크 설정 실수.
• 몇 시간 다운.

Google Cloud 2020:

• 인증 시스템 장애.
• Gmail, YouTube, Drive 영향.

패턴:

• 변경이 원인: 대부분 장애가 "변경" 때문.
• 자동화의 실수: 자동화 시스템이 오히려 확대.
• 의존성 폭포: 한 시스템이 다른 시스템을 무너뜨림.

BGP의 "단일 실패 지점":

Facebook 사건의 핵심 통찰:

• BGP는 인터넷의 신경계다.
• 한 조직의 BGP가 제대로 작동 안 하면 그 조직은 존재하지 않는다.
• 물리적 서버는 멀쩡한데 인터넷에서 안 보임.

이는 사이버 존재의 현실을 보여준다. 클라우드 시대에 "살아있음"은 "BGP로 도달 가능함"이다.

개인적 성찰:

이 사건은 기술 전문가들에게 교훈을 준다:

1. 겸손:

• 세계 최고의 엔지니어링 조직도 실수한다.
• 완벽한 시스템은 존재하지 않는다.

2. 복잡성의 위험:

• 시스템이 복잡할수록 예상 못한 실패 가능.
• Facebook의 인프라는 극도로 복잡.

3. Resilience 투자:

• 평상시엔 낭비처럼 보여도 장애 시 생명.
• Redundant management, out-of-band access.

4. Post-mortem 문화:

• Facebook이 투명하게 공개했다는 것 자체가 긍정.
• 비난 없는 문화가 진짜 학습을 만든다.

5. "BGP를 알라":

• 일반 개발자도 BGP의 존재를 인식해야.
• 당신의 서비스가 "갑자기 사라진" 이유가 BGP일 수 있다.

결론:

2021년 Facebook 사건은 BGP의 힘을 대중에게 각인시켰다. 이전에는 네트워크 전문가들만 알던 용어가 뉴스 헤드라인에 등장했다. 일반인도 "BGP"를 듣게 되었다.

기술적 교훈: BGP는 복잡하고 강력하며 위험하다. 한 번의 실수가 수십억 명에게 영향을 줄 수 있다.

비즈니스 교훈: 단일 실패 지점을 제거하라. 의존성을 분리하라. 자동화를 검증하라.

인간적 교훈: 엔지니어는 큰 책임을 진다. 몇 줄의 코드, 한 번의 명령이 전 세계에 영향을 준다. 겸손과 신중함이 그래서 중요하다.

Facebook은 그 6시간 동안 수억 달러의 손실과 수백만 사용자의 불만을 감수했다. 하지만 업계 전체가 배웠다. 다른 조직들이 자신의 아키텍처를 재검토했다. 이것이 실패를 통한 학습이다.

BGP는 인터넷의 가장 약한 고리 중 하나다. 그러나 가장 필수적이기도 하다. 40년 넘게 인터넷을 움직여 왔고, 앞으로 수십 년 더 움직일 것이다. 그동안 이런 사건들이 반복될 것이고, 그때마다 인터넷은 조금씩 더 견고해질 것이다.

다음번에 Facebook에 접속이 안 될 때, 잠시 생각해보자: BGP가 제대로 동작하지 않으면 현대 문명의 상당 부분이 멈춘다. 이것이 인터넷 인프라의 진짜 얼굴이다.