인터넷의 구조

매일 쓰는 인터넷은 하나의 거대한 네트워크가 아닙니다. 전 세계의 수많은 통신 사업자, 기업, 대학, 콘텐츠 사업자가 각자 운영하는 네트워크들이 서로 연결된, 말 그대로 네트워크의 네트워크(network of networks)입니다. 이 구조를 알면 한국에서 미국의 서버에 접속하면 왜 느린지, CDN이 왜 필요한지 같은 질문에 답할 수 있습니다.

인터넷은 어떻게 시작되었나

인터넷은 1960년대 말 미국 국방부의 연구 기관 ARPA가 지원한 ARPANET에서 시작되었습니다. ARPANET은 멀리 떨어진 연구 기관들이 컴퓨터 자원을 나누어 쓰고, 데이터를 작은 조각으로 나누어 보내는 패킷 교환을 실험하려고 만든 네트워크였습니다. 흔히 핵전쟁에서도 살아남는 통신망을 만들려고 시작했다고 알려져 있지만, 인터넷을 만든 사람들이 직접 정리한 역사는 이것이 잘못 알려진 이야기라고 밝힙니다.

1983년의 TCP/IP 전환은 서로 다른 네트워크를 하나로 잇는 인터넷이 자리 잡은 이정표로 꼽힙니다. 웹은 그보다 뒤에 나온 인터넷 위의 서비스 가운데 하나로, 인터넷과 웹은 같은 말이 아닙니다. 1990년대에 웹이 퍼지면서 인터넷은 연구자의 도구에서 모든 사람이 쓰는 기반 시설이 되었습니다.

망과 망은 어떻게 이어지나

인터넷에 연결된 각 네트워크는 하나의 기관이 자기 정책으로 운영하는 자율 시스템(autonomous system, AS)이며, AS마다 고유한 번호가 있습니다. AS들은 서로 두 가지 관계를 맺습니다. 트랜짓(transit)은 돈을 받고 고객에게 인터넷의 나머지 전부로 가는 길을 제공하는 관계이고, 피어링(peering)은 두 망이 서로의 고객에게 가는 트래픽만 직접 주고받는 관계로, 대개 돈을 주고받지 않지만 유료인 경우도 있습니다.

이 관계에 따라 사업자를 흔히 세 단계로 나눕니다. Tier 1은 누구에게도 트랜짓을 사지 않고 다른 Tier 1들과의 피어링만으로 인터넷 전체에 닿는 망이고, Tier 2는 트랜짓을 사면서 다른 망과 피어링도 하는 망, Tier 3는 주로 위 단계의 트랜짓을 사서 최종 사용자에게 접속을 파는 망입니다. 이것은 사업 관계로 나눈 관행적인 분류이며, 나라나 회사의 크기로 정한 순위가 아닙니다.

그래서 패킷이 언제나 Tier 3에서 Tier 2를 거쳐 Tier 1로 올라갔다 내려오는 것은 아닙니다. 예를 들어 접속망 A가 트랜짓을 사면서 콘텐츠망 B와 직접 피어링도 하고 있다면, B의 서버로 가는 트래픽은 피어링 링크로 바로 가고, 피어링하지 않은 다른 목적지로 가는 트래픽만 트랜짓으로 갑니다. 피어링이 하나 있다고 해서 모든 목적지의 트랜짓이 필요 없어지는 것은 아닙니다.

인터넷 교환 지점

같은 지역의 망들이 트래픽을 직접 주고받으면 먼 트랜짓 경로를 돌지 않아도 됩니다. 인터넷 교환 지점(internet exchange point, IXP)은 여러 망이 장비를 들여와 서로 연결할 수 있게 만든 공용 시설로, 서울의 KINX, 도쿄의 JPIX, 프랑크푸르트의 DE-CIX가 대표적입니다.

IXP에 들어왔다고 해서 피어링이 저절로 맺어지는 것은 아닙니다. 참여한 망들이 누구와 어떤 경로를 주고받을지 서로 합의하고 라우팅을 설정해야 하며, 그래야 지연과 비용이 줄어듭니다. 넷플릭스와 구글 같은 대형 콘텐츠 사업자는 한 걸음 더 나아가, 자기 콘텐츠를 담은 캐시 서버를 통신 사업자의 망 안에 직접 놓기도 합니다. 넷플릭스의 Open Connect가 그 예로, 사용자가 많이 보는 영상은 해외의 원본 서버가 아니라 국내 통신사 망 안의 캐시에서 내려옵니다.

더 깊이: AS 번호는 어떻게 나누어 주고 어떻게 늘렸나

AS 번호는 IANA가 블록 단위로 다섯 지역 인터넷 등록 기관(regional internet registry, RIR)인 AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC에 나누어 주고, 각 RIR이 자기 지역의 운영자에게 다시 배정합니다. 처음에는 BGP 메시지에 2바이트로 실렸기 때문에 번호가 65,536개뿐이었습니다. 이 번호가 바닥날 것에 대비해 RFC 4893을 거쳐 지금의 RFC 6793이 AS 번호를 4바이트로 넓혔고, IANA의 등록부도 16비트 범위와 32비트 범위를 나누어 관리합니다.

번호를 넓힐 때 가장 까다로운 점은 2바이트 번호만 아는 오래된 BGP 라우터가 함께 남아 있다는 것입니다. 4바이트를 지원하는 라우터는 세션을 맺을 때 그 사실을 알리고, 상대가 지원하지 않으면 AS_PATH를 2바이트 형식으로 보내면서 2바이트로 나타낼 수 없는 번호를 자리 표시용 번호 AS_TRANS(23456)로 바꿉니다. 진짜 경로는 AS4_PATH라는 새 속성에 4바이트로 함께 실리는데, 이 속성은 선택적 전이(optional transitive) 속성이라 내용을 모르는 오래된 라우터도 그대로 다음 이웃에게 넘깁니다. 그래서 경로를 받은 새 라우터는 두 속성을 합쳐 원래 경로를 되살릴 수 있고, 오래된 라우터의 경로에 보이는 23456은 그 자리에 실제로는 4바이트 AS가 있다는 뜻입니다.

IP 주소처럼 AS 번호에도 용도가 정해진 범위가 있습니다. 64512부터 65534까지와 4200000000부터 4294967294까지는 RFC 6996이 정한 사설용(private use) 번호로, 한 기관 안에서 BGP를 쓸 때 공인 번호 없이 씁니다. 사설 IP 주소와 마찬가지로 이 번호는 인터넷으로 나가는 경로의 AS_PATH에서 지워야 합니다. 64496부터 64511까지와 65536부터 65551까지는 문서와 예제용이고(RFC 5398), 0과 65535, 4294967295는 예약된 번호입니다.

백본, 엣지, 액세스

인터넷의 물리적인 구조는 하는 일에 따라 세 영역으로 나누어 볼 수 있습니다.

백본은 인터넷의 고속도로로, 여러 회선과 파장을 묶어 막대한 트래픽을 나릅니다. 엣지의 대표는 CDN(content delivery network)으로, 사용자와 가까운 서버에 콘텐츠를 저장해 두었다가 요청이 오면 먼 원본 서버까지 가지 않고 바로 응답합니다. 다만 로그인한 사용자의 개인 정보처럼 원본에서 새로 만들어야 하는 응답은 캐시만으로 해결되지 않습니다. 액세스 구간은 라스트 마일(last mile)이라고도 부르며, 가입한 상품의 속도와 무선 환경의 영향을 많이 받아 병목이 되기 쉬운 곳입니다. 실제로 어디가 병목인지는 경로의 각 구간을 재어 보아야 알 수 있습니다.

해저 케이블과 위성

대륙 사이를 오가는 데이터는 거의 모두 바닷속의 광케이블을 지나갑니다. 인터넷이 구름 속에 있다는 비유와 달리, 실제로는 수천 킬로미터의 케이블이 해저에 깔려 있고, 그것이 끊기면 인터넷이 느려지거나 끊깁니다. 2006년 12월 대만 남쪽 바다에서 일어난 지진으로 여러 해저 케이블이 함께 끊겼을 때, 한국을 포함한 아시아 여러 나라의 국제 통신이 크게 느려지고 복구에 몇 주가 걸렸습니다. 이런 위험을 줄이려고 구글, 메타, 마이크로소프트, 아마존 같은 기업들은 자기 해저 케이블을 직접 깔기도 합니다.

위성도 인터넷을 나르지만 지연의 사정이 다릅니다. 정지궤도 위성은 적도 위 약 35,786km에 떠 있어서, 신호가 그만큼 올라갔다 내려오는 데만 왕복으로 수백 밀리초가 걸립니다. Starlink 같은 저궤도 위성은 약 550km 높이에 있어 지연이 훨씬 짧지만, 위성과 지상국의 배치, 동시에 쓰는 사용자 수에 따라 성능이 달라집니다. 위성 인터넷은 섬이나 산간 지역, 케이블이 끊긴 재난 상황처럼 케이블을 쓰기 어려운 곳을 보완합니다.

거리가 정하는 최소 지연

서울에서 미국 동부의 서버에 API를 호출하면, 그 패킷은 해저 케이블을 따라 태평양과 미국 대륙을 건너갑니다. 광섬유 속에서 빛은 진공에서보다 느려서 초당 약 20만 킬로미터를 가므로, 거리만으로도 넘을 수 없는 최소 지연이 정해집니다. 다음 코드는 가정한 경로 길이로 요청이 갔다가 응답이 돌아오는 왕복 전파 지연을 계산합니다.

FIBER_KM_PER_S = 200_000            # 광섬유 속 빛의 속도(진공의 약 3분의 2)

routes = {                          # 계산을 위해 가정한 편도 경로 길이(km)
    "서울 → 도쿄": 1_200,
    "서울 → 미국 서부": 9_000,
    "서울 → 유럽": 10_000,
    "서울 → 미국 동부": 12_000,
}
for route, km in routes.items():
    rtt_ms = km * 2 / FIBER_KM_PER_S * 1000
    print(f"{route}: 왕복 전파 지연 약 {rtt_ms:.0f}ms")

서울 → 도쿄: 왕복 전파 지연 약 12ms
서울 → 미국 서부: 왕복 전파 지연 약 90ms
서울 → 유럽: 왕복 전파 지연 약 100ms
서울 → 미국 동부: 왕복 전파 지연 약 120ms

미국 동부까지 12,000km라면 편도에 12,000 ÷ 200,000 = 0.06초, 왕복에 120ms가 걸립니다. 이것은 거리만으로 정해지는 바닥값이며, 실제 케이블은 직선보다 훨씬 돌아가고, 라우터에서 기다리는 시간과 서버가 처리하는 시간이 더해지므로 실제 왕복 시간은 이보다 큽니다. 지연의 여러 성분은 다음 글에서 나누어 봅니다.

코드를 아무리 다듬어도 빛보다 빠르게 데이터를 보낼 수는 없으므로, 사용자와 서버 사이의 거리를 줄이는 것이 지연을 줄이는 가장 확실한 방법입니다. 그래서 서비스를 설계할 때 서버의 위치를 고르는 일이 중요합니다.

정리

• 인터넷은 수많은 자율 시스템(AS)이 서로 연결된 네트워크의 네트워크이며, ARPANET에서 시작해 1983년 TCP/IP로 전환하며 자리 잡았습니다. 웹은 그 위의 서비스 가운데 하나입니다.
• AS들은 인터넷 전체로 가는 길을 사고파는 트랜짓과, 서로의 고객에게 가는 트래픽만 직접 주고받는 피어링으로 연결되며, Tier는 이 관계로 나눈 관행적인 분류입니다.
• IXP는 여러 망이 직접 연결하는 공용 시설이고, 대형 콘텐츠 사업자는 통신사 망 안에 캐시를 두기도 합니다.
• 인터넷의 물리 구조는 백본, 엣지, 액세스로 나눌 수 있으며, 대륙 사이의 데이터는 거의 모두 해저 케이블로 오갑니다.
• 광섬유 속 빛의 속도 때문에 거리만으로 최소 지연이 정해지므로, 서버의 위치와 CDN이 응답 시간을 좌우합니다.

연습 문제

1. 거리와 전송 속도

광섬유 속 빛의 속도가 초당 200,000km이고 편도 경로가 6,000km라면 왕복 전파 지연은 얼마인가요? 거리는 그대로 두고 회선의 전송 속도만 열 배로 올리면 이 값도 열 배 줄어드나요?

2. 정지궤도 위성의 지연

정지궤도 위성은 지상에서 약 35,786km 높이에 있습니다. 사용자의 요청이 위성을 거쳐 지상국에 가고, 응답이 다시 위성을 거쳐 사용자에게 돌아온다면, 전파의 속도를 초당 300,000km로 보았을 때 위성 구간의 왕복 지연은 최소 얼마인가요? 지상의 경로와 처리 시간은 무시하고, 위성이 사용자와 지상국 바로 위에 있다고 단순하게 가정합니다.

3. 피어링과 트랜짓

통신사 A는 Tier 1 사업자에게 트랜짓을 사고 있고, 동영상 서비스 B와는 서울의 IXP에서 직접 피어링하고 있습니다. A의 가입자가 B의 동영상을 볼 때와, B와 피어링하지 않은 해외 쇼핑몰 C에 접속할 때 트래픽은 각각 어떤 길로 가나요? B가 A의 망 안에 캐시 서버를 둔다면 무엇이 달라지나요?

다음 글 데이터 전송의 기본 원리에서는 데이터가 패킷으로 나뉘어 전달되는 패킷 교환의 원리와, 지연을 이루는 네 가지 성분, 대역폭과 처리량을 살펴봅니다.