인터넷의 구조

우리가 매일 사용하는 인터넷은 하나의 단일 네트워크가 아닙니다.

전 세계 수만 개의 네트워크가 서로 연결되어 만들어진, 말 그대로 네트워크의 네트워크(Network of Networks)입니다.

이 구조를 이해하면 왜 한국에서 미국 서버에 접속하면 느린가?, CDN이 왜 필요한가? 같은 질문에 명확한 답을 낼 수 있게 됩니다.

인터넷의 탄생 배경

인터넷의 시작은 1960년대 미국 국방부의 ARPANET(Advanced Research Projects Agency Network) 프로젝트입니다.

ARPANET은 연구자들이 떨어진 컴퓨터 자원을 공유하고 패킷 교환을 실험하기 위해 추진한 네트워크였습니다.

인터넷 개발 참여자들의 역사 정리는 ARPANET을 핵전쟁 생존용으로 만들었다는 설명이 잘못이라고 밝힙니다.

패킷 교환은 데이터를 작은 조각으로 나누어 공유 링크로 전달합니다. 대체 경로를 이용할 수 있는지는 실제 연결과 라우팅 상태에 달려 있습니다.

1983년 ARPANET의 TCP/IP 전환은 서로 다른 네트워크를 연결하는 인터넷의 발전에서 중요한 이정표였습니다.

1989년 팀 버너스-리의 제안에서 출발한 월드와이드웹(WWW)이 1990년대에 확산되면서 인터넷은 일반 대중이 사용하는 인프라로 성장했습니다.

ISP 계층 구조

인터넷은 ISP·콘텐츠 사업자·기업 등이 운영하는 자율 시스템(AS)이 연결된 구조입니다. Tier는 이들 사이의 트랜짓 구매와 피어링 관계를 설명하는 관행적 분류이며, 국가나 물리적 크기의 고정 순위는 아닙니다.

• Tier 1: 통상 트랜짓을 구매하지 않고 자체 고객과 무정산 피어링을 통해 인터넷 경로에 도달하는 망을 뜻합니다.
• Tier 2: 트랜짓을 구매하면서 다른 망과 피어링도 하는 사업자를 가리킵니다.
• Tier 3: 주로 상위 사업자의 트랜짓을 이용해 최종 사용자에게 접속을 제공하는 망을 설명할 때 씁니다.

트랜짓은 사업자가 고객에게 다른 네트워크로의 도달 경로를 제공하는 관계입니다. 피어링은 두 망이 합의한 범위의 트래픽을 교환하는 관계로, 무정산 방식도 유상 방식도 있습니다.

패킷이 반드시 Tier 3 → Tier 2 → Tier 1 순서로 이동하는 것은 아닙니다. 목적지 경로와 사업 관계, 직접 피어링, IXP, CDN 캐시 등에 따라 경로가 달라집니다.

IXP와 피어링

인접한 망끼리 트래픽을 직접 교환할 수 있다면 먼 트랜짓 경로를 줄일 여지가 있습니다. IXP(Internet Exchange Point)는 여러 망이 만나는 공유 교환 인프라를 제공합니다.

IXP는 같은 지역의 ISP, CDN, 클라우드 사업자들이 직접 트래픽을 교환하는 물리적 시설입니다.

서울의 KINX, 도쿄의 JPIX, 프랑크푸르트의 DE-CIX가 대표적입니다.

IXP 접속만으로 피어링이 자동 성립하는 것은 아닙니다. 참여자 사이의 계약·라우팅 정책이 필요하며 지연과 비용 개선도 실제 경로·요금에 따라 달라집니다.

Google, Netflix 같은 대형 콘텐츠 사업자는 ISP 내부에 서버를 직접 배치하기도 합니다.

이를 오픈 커넥트(Open Connect, Netflix) 또는 캐시 노드라고 합니다.

백본, 엣지, 액세스 네트워크

인터넷의 물리적 구조를 기능별로 나눠 보면 세 가지 영역으로 구분할 수 있습니다.

백본 네트워크(Backbone Network)는 대륙 간, 국가 간을 잇는 초고속 간선 네트워크입니다.

해저 광케이블이나 위성 링크로 구성되며, 인터넷의 "고속도로"에 해당합니다.

다수의 고속 회선과 파장을 묶어 큰 트래픽을 처리하며 용량은 링크와 집계 범위에 따라 다릅니다.

엣지 네트워크(Edge Network)는 실제 서비스가 사용자에게 전달되는 경계 지점입니다.

CDN(Content Delivery Network)의 엣지 서버가 대표적인 예입니다.

사용자와 물리적으로 가까운 곳에 콘텐츠를 캐싱해 두고 제공함으로써 지연을 극적으로 줄입니다.

액세스 네트워크(Access Network)는 최종 사용자가 인터넷에 접속하는 마지막 구간입니다.

집에 깔린 광랜(FTTH), 카페의 Wi-Fi, 스마트폰의 5G — 모두 액세스 네트워크에 해당합니다.

라스트 마일(Last Mile)이라고도 부르는 액세스 구간은 병목 후보 중 하나입니다. 실제 병목은 경로의 링크 용량과 부하를 확인해 판단합니다.

해저 케이블과 글로벌 연결

대륙을 오가는 국제 데이터 트래픽의 대부분은 해저 광케이블을 통해 전송됩니다.

해저 케이블은 특히 대양을 건너는 국제 통신의 주요 기반입니다.

인터넷은 구름(클라우드) 속에 있다는 비유가 인기를 끌지만, 실체는 훨씬 물리적입니다.

바닷속 수천 킬로미터를 가로지르는 케이블이 전 세계 인터넷의 뼈대를 형성하고 있습니다.

정지궤도 위성은 궤도 고도 때문에 긴 전파 경로가 필요합니다. 광섬유와 위성 모두 신호 속도와 실제 경로 길이의 영향을 받으며, 광섬유 내 빛의 속도는 진공보다 느립니다.

SpaceX의 Starlink 같은 저궤도(LEO) 위성 인터넷은 정지궤도보다 지연이 훨씬 짧습니다.

섬, 산간 지역, 재난 복구처럼 케이블 구축이 어렵거나 끊긴 상황에서 해저 케이블의 보완재 역할을 할 수 있습니다.

해저 케이블 장애 사례

다만 해저 케이블이 손상되면 그 영향은 광범위합니다.

2006년 대만 남부 해역에서 지진이 발생해 여러 해저 케이블이 끊어졌을 때, 한국을 포함한 아시아 전역의 인터넷 속도가 크게 저하된 사례가 있습니다.

이러한 리스크를 줄이기 위해 Google, Meta, Microsoft, Amazon 같은 빅테크 기업들은 자체 해저 케이블을 구축하고 있습니다.

개발자와 인터넷 구조의 접점

개발자 관점에서 이 구조를 이해해야 하는 이유는 명확합니다.

서울에서 미국 동부 리전 서버에 API를 호출하면, 그 패킷은 해저 케이블을 타고 태평양을 건너갑니다.

아래 거리는 계산 연습용 근사 입력이며 실제 케이블 경로를 측정한 값이 아닙니다. 출력은 그 거리와 가정한 신호 속도만으로 계산한 왕복 전파 시간입니다.

SPEED_OF_LIGHT_KM_S = 200000  # 광섬유 내 빛의 속도 (진공 대비 ~2/3)

routes = {
    "서울 → 도쿄": 1200,
    "서울 → 미국 서부": 9000,
    "서울 → 미국 동부": 12000,
    "서울 → 유럽": 10000,
}

for route, distance_km in routes.items():
    rtt_ms = (distance_km * 2) / SPEED_OF_LIGHT_KM_S * 1000
    print(f"{route}: ~{rtt_ms:.0f}ms (물리적 최소 RTT)")
    # 실제 RTT에는 경로 우회, 전송·처리·큐잉 지연 등이 추가됨

아무리 코드를 최적화해도 빛의 속도를 넘을 수는 없으므로, 물리적 거리에 의한 지연은 불가피합니다.

이것이 바로 서버 리전 선택과 CDN 배치가 아키텍처 설계에서 중요한 이유입니다.

다음 절에서는 이 인터넷 구조 위에서 데이터가 실제로 어떤 형태로 전달되는지 — 패킷 교환, 성능 지표, 병목과 혼잡을 다루겠습니다.