인터넷의 구조
우리가 매일 사용하는 인터넷은 하나의 단일 네트워크가 아닙니다.
전 세계 수만 개의 네트워크가 서로 연결되어 만들어진, 말 그대로 네트워크의 네트워크(Network of Networks)입니다.
이 구조를 이해하면 왜 한국에서 미국 서버에 접속하면 느린가?, CDN이 왜 필요한가? 같은 질문에 명확한 답을 낼 수 있게 됩니다.
인터넷의 탄생 배경
인터넷의 시작은 1960년대 미국 국방부의 ARPANET(Advanced Research Projects Agency Network) 프로젝트입니다.
냉전 시대, 핵전쟁이 발생하더라도 통신이 유지되려면 중앙 집중형 네트워크는 위험했습니다. 중앙 노드 하나가 파괴되면 전체 통신이 마비되기 때문입니다. 그래서 중앙 없이도 동작하는 분산형 네트워크라는 개념이 등장했습니다.
ARPANET은 이 목표를 달성하기 위해 패킷 교환(Packet Switching) 방식을 최초로 도입했습니다. 데이터를 작은 조각(패킷)으로 나누어 각각 독립적으로 전송하면, 일부 경로가 파괴되어도 다른 경로를 통해 데이터가 도달할 수 있었습니다.
| 연도 | 사건 |
|---|---|
| 1969 | ARPANET 첫 통신 (UCLA ↔ SRI) |
| 1974 | TCP/IP 개념 발표 (Vint Cerf, Bob Kahn) |
| 1983 | TCP/IP 표준 채택 → 인터넷의 탄생 |
| 1989 | WWW 발명 (Tim Berners-Lee, CERN) |
| 1995 | 상업적 인터넷 폭발 (Netscape, Amazon, eBay) |
| 2007 | 모바일 인터넷 시대 (iPhone 출시) |
1983년에 TCP/IP 프로토콜이 표준으로 채택되면서 서로 다른 종류의 네트워크도 하나로 이을 수 있다는 현재 인터넷의 철학이 완성됐습니다. 그리고 1990년대 팀 버너스-리가 월드와이드웹(WWW)을 발명하면서 인터넷은 연구자들의 도구에서 전 세계 일반 대중의 인프라로 폭발적으로 확산되었습니다.
ISP 계층 구조
인터넷은 자연적으로 만들어진 것이 아니라, ISP(Internet Service Provider)들이 계층적으로 연결하여 구성한 것입니다.
┌────────────────────┐
│ Tier 1 │
│ AT&T · NTT · Lumen │
└───────┬───────┬────┘
│Transit│Transit
┌───────────┘ └───────────┐
▼ ▼
┌────────────┐ ┌────────────┐
│ Tier 2 │ │ Tier 2 │
│ KT │ │ SKB │
└─────┬──────┘ └─────┬──────┘
│ │
┌─────▼──────┐ ┌─────▼──────┐
│ Tier 3 │ │ Tier 3 │
│ 지역 ISP │ │ 지역 ISP │
└─────┬──────┘ └─────┬──────┘
│ │
[가정] [기업]Tier 1 ISP는 전 세계 규모의 백본(Backbone) 네트워크를 운영합니다. AT&T, NTT, Lumen Technologies 같은 기업이 해당합니다. Tier 1끼리는 대등한 관계에서 트래픽을 무료로 교환하는데, 이를 피어링(Peering)이라 합니다. 전 세계 어디든 도달할 수 있는 경로를 자체적으로 보유하고 있기 때문에 다른 ISP에 비용을 낼 필요가 없습니다.
Tier 2 ISP는 국가 또는 지역 규모의 네트워크를 운영합니다. Tier 1에 비용을 지불하고 트래픽 경로를 전달(Transit)받으면서, 동시에 하위 ISP에게 인터넷 서비스를 제공합니다. 한국의 KT, SK브로드밴드, LG유플러스가 여기에 해당합니다.
Tier 3 ISP는 최종 사용자에게 인터넷 접속을 직접 제공하는 소규모 지역 ISP입니다.
이 계층 구조를 이해하면 내 패킷이 인터넷을 어떻게 통과하는가에 대한 윤곽이 잡힙니다. 여러분이 보낸 패킷은 Tier 3 → Tier 2 → Tier 1을 타고 올라갔다가, 다시 Tier 1 → Tier 2 → Tier 3을 타고 목적지에 도달합니다.
IXP와 피어링
모든 트래픽이 Tier 1까지 올라갔다 내려오는 것은 비효율적입니다. 같은 도시 안의 두 ISP가 통신하는데 굳이 다른 나라를 거칠 이유가 없습니다. IXP(Internet Exchange Point)는 이 문제를 해결합니다.
┌───────┐ ┌──────────┐ ┌───────┐
│ ISP A │─────▶│ IXP │─────▶│ ISP B │
│ │◀─────│ │◀─────│ │
└───────┘ └──────────┘ └───────┘
같은 지역 ISP가 직접 트래픽 교환IXP는 같은 지역의 ISP, CDN, 클라우드 사업자들이 직접 트래픽을 교환하는 물리적 시설입니다. 서울의 KINX, 도쿄의 JPIX, 프랑크푸르트의 DE-CIX가 대표적입니다. Tier 1을 거치지 않으므로 지연이 줄고 비용도 절감됩니다.
Google, Netflix 같은 대형 콘텐츠 사업자는 ISP 내부에 서버를 직접 배치하기도 합니다. 이를 오픈 커넥트(Open Connect, Netflix) 또는 캐시 노드라고 합니다.
백본, 엣지, 액세스 네트워크
인터넷의 물리적 구조를 기능별로 나눠 보면 세 가지 영역으로 구분할 수 있습니다.
백본 네트워크(Backbone Network)는 대륙 간, 국가 간을 잇는 초고속 간선 네트워크입니다. 해저 광케이블이나 위성 링크로 구성되며, 인터넷의 "고속도로"에 해당합니다. 대역폭이 수 Tbps에 달합니다.
엣지 네트워크(Edge Network)는 실제 서비스가 사용자에게 전달되는 경계 지점입니다. CDN(Content Delivery Network)의 엣지 서버가 대표적인 예입니다. 사용자와 물리적으로 가까운 곳에 콘텐츠를 캐싱해 두고 제공함으로써 지연을 극적으로 줄입니다.
액세스 네트워크(Access Network)는 최종 사용자가 인터넷에 접속하는 마지막 구간입니다. 집에 깔린 광랜(FTTH), 카페의 Wi-Fi, 스마트폰의 5G — 모두 액세스 네트워크에 해당합니다.
| 영역 | 속도 | 관리자 | 기술 |
|---|---|---|---|
| 백본 | 수 Tbps | Tier 1/2 ISP | 해저 광케이블, DWDM |
| 엣지 | 수 Gbps | CDN, 클라우드 | 캐시 서버, PoP |
| 액세스 | 수백 Mbps~수 Gbps | ISP, 사용자 | FTTH, 5G, Wi-Fi 6 |
라스트 마일(Last Mile)이라고도 불리는 액세스 네트워크가 전체 인터넷 경로에서 가장 병목이 발생하기 쉬운 구간입니다.
해저 케이블과 글로벌 연결
전 세계 인터넷 트래픽의 약 95% 이상은 해저 광케이블을 통해 전송됩니다.
인터넷은 구름(클라우드) 속에 있다는 비유가 인기를 끌지만, 실체는 훨씬 물리적입니다. 바닷속 수천 킬로미터를 가로지르는 케이블이 전 세계 인터넷의 뼈대를 형성하고 있습니다.
위성 통신이라는 대안도 있지만, 위성은 정지궤도 기준으로 약 600ms의 왕복 지연이 생깁니다. 반면 해저 케이블의 광섬유는 빛의 속도로 데이터를 전달하기 때문에 대용량·저지연 통신에 압도적으로 유리합니다.
| 전송 매체 | 왕복 지연 (서울↔뉴욕) | 대역폭 | 비용 |
|---|---|---|---|
| 해저 광케이블 | ~150ms | 수 Tbps | 높음 (건설) |
| 정지궤도 위성 | ~600ms | 수 Gbps | 중간 |
| LEO 위성 (Starlink) | ~40-60ms | 수십 Gbps | 높음 |
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)")
# 실제로는 라우터 처리, 큐잉 등으로 2-3배 소요아무리 코드를 최적화해도 빛의 속도를 넘을 수는 없으므로, 물리적 거리에 의한 지연은 불가피합니다. 이것이 바로 서버 리전 선택과 CDN 배치가 아키텍처 설계에서 중요한 이유입니다.
| 전략 | 효과 |
|---|---|
| 서버 리전을 사용자 근처에 배치 | 물리적 거리 단축 → RTT 감소 |
| CDN으로 정적 콘텐츠 캐싱 | 원본 서버까지 갈 필요 없음 |
| 멀티 리전 배포 | 모든 대륙 근처에 서버 존재 |
| 엣지 컴퓨팅 (Cloudflare Workers) | 사용자 최근접 PoP에서 코드 실행 |
다음 절에서는 이 인터넷 구조 위에서 데이터가 실제로 어떤 형태로 전달되는지 — 패킷 교환, 성능 지표, 병목과 혼잡을 다루겠습니다.