우리가 만든 작은 인터넷에서 진짜 인터넷까지

작은 모델은 장난감이 아니라 축소판이다

이 책에서 만든 작은 인터넷은 진짜 인터넷을 흉내 낸 장난감이 아니다. 크기만 줄인 축소판에 가깝다. 방 안의 컴퓨터 두 대, 스위치 하나, 라우터 몇 대, DNS 서버, 웹 서버를 놓고 연결했을 뿐이지만 그 안에는 인터넷의 중요한 원리가 거의 들어 있다.

진짜 인터넷은 훨씬 크다. 집, 회사, 학교, 데이터센터, 통신사, 해저 케이블, 위성망까지 이어진다. 하지만 질문은 같다.

• 데이터가 지나갈 길이 있는가?

• 목적지를 나타내는 주소가 있는가?

• 다음 길을 고르는 장치가 있는가?

• 사람이 기억하는 이름을 숫자 주소로 바꿀 수 있는가?

• 데이터가 중간에 쪼개져도 다시 맞출 수 있는가?

• 상대를 믿고 안전하게 통신할 수 있는가?

이 질문에 답하는 과정이 곧 인터넷을 만드는 과정이다.

도로 비유로 말하면, 우리는 골목길 하나를 만들고 주소를 붙이고 우체국과 안내소를 세웠다. 진짜 인터넷은 그 골목이 도시, 고속도로, 항구, 국제 항로로 확장된 모습이다. 여기까지가 비유다. 실제 인터넷에서는 도로 대신 케이블과 전파와 광섬유가 있고, 주소판 대신 IP 주소가 있으며, 우체국과 안내소 대신 스위치와 라우터와 DNS가 움직인다.

AI 생성 이미지

브라우저 요청 하나에 모두가 들어 있다

인터넷 전체를 가장 쉽게 다시 보는 방법은 브라우저에 주소 하나를 입력하는 장면을 따라가는 것이다.

예를 들어 사용자가 브라우저에 https://web.example.local/index.html을 입력했다고 하자. 여기서는 이 책에서 써 온 작은 인터넷의 실험용 이름이라고 생각하면 된다. 겉으로는 주소를 치고 엔터를 누른 일뿐이다. 하지만 안에서는 여러 층의 약속이 차례로 협력한다.

먼저 컴퓨터는 이 이름이 실제로 어느 IP 주소를 가리키는지 알아야 한다. 이때 DNS가 등장한다. DNS는 전화번호부처럼 이름을 주소로 바꿔 준다. web.example.local이라는 사람이 읽기 쉬운 이름은 192.168.20.10 같은 IP 주소로 바뀐다. 전화번호부 비유는 여기까지다. 실제 DNS는 여러 서버가 계층적으로 답을 나누어 관리하고, 답을 캐시에 잠시 저장한다.

IP 주소를 알게 되면 컴퓨터는 목적지가 같은 네트워크 안에 있는지 확인한다. 같은 네트워크라면 스위치를 통해 바로 보낼 수 있다. 다른 네트워크라면 게이트웨이, 즉 라우터에게 맡긴다. 이때 최종 목적지 IP 주소는 서버의 주소로 남아 있지만, 가까운 구간에서 받을 장치를 나타내는 MAC 주소는 다음 장치의 MAC 주소로 바뀐다.

그다음 데이터는 TCP 또는 UDP 같은 전송 방식 위에 실린다. 웹은 오랫동안 주로 TCP를 사용해 왔다. TCP는 택배 상자마다 번호를 붙이고, 도착했는지 확인하고, 빠진 상자가 있으면 다시 보내는 방식과 비슷하다. 이 비유는 데이터의 순서 확인과 재전송을 설명하기 위한 것이다. 실제 TCP는 순서 번호, 수신 확인, 재전송, 흐름 제어 같은 규칙으로 신뢰성을 만든다. 요즘은 HTTP/3처럼 UDP 위에서 QUIC을 사용하는 웹 통신도 있지만, "데이터를 어떤 방식으로 주고받을지 정하는 층이 필요하다"는 핵심은 같다.

웹 요청 자체는 HTTP가 맡는다. 브라우저는 "이 경로의 문서를 주세요"라는 요청을 만들고, 웹 서버는 상태 코드와 본문을 담아 응답한다. HTTPS라면 이 HTTP 대화가 TLS라는 암호화된 통로 안에 들어간다. 그래서 중간의 장비들은 패킷을 전달할 수는 있지만, 보호된 내용까지 쉽게 읽을 수는 없다.

마지막으로 이 모든 데이터는 비트가 되어 랜카드, 케이블, 와이파이, 광섬유를 지난다. 스위치는 MAC 주소를 보고 가까운 장치로 프레임을 보내고, 라우터는 IP 주소를 보고 다음 네트워크로 패킷을 넘긴다. 서버에 요청이 도착하면 서버는 같은 원리로 응답을 되돌려 보내고, 브라우저는 받은 조각들을 맞춰 화면에 웹페이지를 그린다.

정리하면 하나의 웹 요청 안에는 비트 이동, MAC, IP, 라우팅, DNS, TCP나 UDP 같은 전송 방식, HTTP, HTTPS/TLS가 모두 들어 있다. 각각은 따로 존재하는 지식이 아니라, 한 번의 통신을 완성하기 위해 순서대로 손을 잡는 부품이다.

작은 스위치와 라우터는 어디까지 커지는가

우리가 만든 작은 네트워크에서 스위치는 같은 방 안의 컴퓨터들을 연결했다. 진짜 인터넷에서도 스위치의 역할은 크게 다르지 않다. 다만 규모가 커진다.

집 안에서는 공유기 안의 작은 스위치가 노트북, 데스크톱, TV를 연결한다. 회사에서는 층마다 스위치가 있고, 여러 스위치가 다시 큰 스위치에 묶인다. 데이터센터에서는 수천, 수만 대의 서버가 여러 단계의 스위치 구조로 연결된다. 원리는 같다. 가까운 네트워크 안에서 MAC 주소나 더 높은 단계의 규칙을 바탕으로 데이터를 적절한 방향으로 보낸다.

라우터도 마찬가지다. 작은 인터넷에서 라우터는 클라이언트 네트워크와 서버 네트워크를 이었다. 집에서는 공유기가 집 안과 통신사망 사이의 라우터 역할을 한다. 통신사 안에는 더 큰 라우터들이 있고, 통신사와 통신사 사이에도 라우터가 있다. 국가와 국가 사이를 오가는 데이터는 육상 광케이블, 해저 케이블, 인터넷 교환 지점, 여러 통신사망을 거칠 수 있다.

하지만 크기가 커져도 라우터의 핵심 질문은 바뀌지 않는다.

"이 목적지 IP 주소로 가려면 다음에 어디로 보내야 하는가?"

작은 인터넷에서는 우리가 직접 라우팅 테이블에 경로를 적었다. 전 세계 인터넷에서는 수많은 네트워크 운영자가 BGP를 사용해 "이 IP 주소 대역은 우리 쪽으로 오면 갈 수 있다"고 서로 알린다. 작은 설계도에서는 라우터 세 대가 경로를 나누어 가졌고, 실제 인터넷에서는 AS라는 큰 네트워크들이 경로를 나누어 가진다.

그래서 진짜 인터넷은 한 회사가 가진 거대한 장비 하나가 아니다. 서로 다른 운영자가 자기 네트워크를 관리하면서, 공통 약속으로 연결한 거대한 협력 구조다.

공통 약속이 없으면 인터넷은 이어지지 않는다

인터넷이 전 세계에서 동작하려면 장비 회사, 운영체제, 브라우저, 서버, 통신사가 같은 방식으로 대화해야 한다. 내 컴퓨터가 만든 패킷을 다른 나라의 서버가 이해해야 하고, 어떤 회사의 라우터가 보낸 경로 정보를 다른 회사의 라우터가 해석할 수 있어야 한다.

이때 필요한 것이 표준이다. 표준은 "이렇게 말하면 모두가 이렇게 이해하자"는 공개 약속이다.

IETF는 인터넷 기술 약속을 논의하고 다듬는 대표적인 공동체다. 특정 회사의 명령어를 정하는 곳이라기보다, TCP/IP, DNS, HTTP 같은 인터넷의 여러 규칙이 어떻게 동작해야 하는지 공개적으로 논의하는 장이라고 이해하면 쉽다.

RFC는 이런 논의와 결과가 문서로 정리된 형태다. RFC는 Request for Comments의 줄임말이다. 이름만 보면 "의견을 요청하는 글"이라는 뜻이지만, 많은 RFC는 실제 인터넷 기술의 기준 문서처럼 사용된다. 모든 RFC가 곧 표준은 아니지만, 인터넷을 이해할 때 중요한 약속들이 RFC 형태로 남아 있다.

ICANN은 도메인 이름과 인터넷 주소 자원의 전 세계적 조정을 맡는 조직이다. 예를 들어 같은 최상위 도메인이 충돌하지 않게 관리하고, IP 주소와 관련된 큰 배분 체계가 질서 있게 움직이도록 돕는다. 인터넷에 중앙 주인이 있다는 뜻은 아니다. 오히려 인터넷이 여러 운영자의 협력 구조이기 때문에, 이름과 번호처럼 충돌하면 안 되는 자원은 함께 조정해야 한다.

생활 비유로 말하면 IETF는 교통 규칙을 논의하는 공개 회의에 가깝고, RFC는 그 규칙을 적어 둔 문서이며, ICANN은 도시 이름과 큰 주소 체계가 겹치지 않게 조정하는 기관에 가깝다. 비유는 여기까지다. 실제로는 각 조직의 역할이 더 복잡하고, 여러 지역 인터넷 등록 기관, 통신사, 기업, 연구자, 개발자가 함께 인터넷을 운영한다.

고장이 나도 같은 질문으로 좁힌다

작은 인터넷을 만들며 배운 가장 중요한 습관은 문제를 순서대로 좁히는 것이다. 진짜 인터넷에서도 이 습관은 그대로 통한다.

웹사이트가 열리지 않을 때 바로 "인터넷이 고장 났다"고 말하면 원인을 찾기 어렵다. 대신 이렇게 나누어 물어야 한다.

첫째, 비트가 지나갈 길이 있는가? 케이블이 연결되어 있는지, 와이파이가 붙어 있는지, 랜카드가 살아 있는지 본다.

둘째, 가까운 네트워크 안에서 통신할 수 있는가? IP 주소와 서브넷이 맞는지, 게이트웨이에 닿는지 확인한다.

셋째, 먼 네트워크로 나갈 경로가 있는가? 라우터, NAT, 통신사 구간, 라우팅 문제가 없는지 본다.

넷째, 이름이 주소로 바뀌는가? 숫자 IP로는 되는데 도메인 이름으로 안 된다면 DNS를 의심한다.

다섯째, 목적지 프로그램이 열려 있는가? 서버가 켜져 있는지, 포트가 열려 있는지, 방화벽이 막고 있지 않은지 확인한다.

여섯째, 믿을 수 있는 통신인가? HTTPS 인증서 이름, 유효 기간, 시간 설정, 암호화 연결 문제를 본다.

이 순서는 집 네트워크에서도, 회사 네트워크에서도, 데이터센터에서도 크게 다르지 않다. 장비 이름과 도구는 달라질 수 있지만 "어디까지는 되고 어디부터는 안 되는가"를 찾는 방식은 같다.

미래의 인터넷에서도 남는 세 가지 질문

인터넷 기술은 계속 변한다. IPv6는 더 넓은 주소 공간을 제공하고, QUIC 같은 새로운 전송 기술은 연결 시간을 줄이고 성능을 높이려 한다. CDN, 클라우드, 위성 인터넷, 사물인터넷, 인공지능 서비스도 인터넷 위에서 계속 확장된다.

하지만 형태가 바뀌어도 핵심 질문은 오래 남는다.

첫째, 어떻게 찾을 것인가. 사람은 이름을 기억하고, 컴퓨터는 주소를 사용한다. 그래서 DNS, IP 주소, 라우팅 정보가 필요하다. 미래에도 서비스와 장치를 찾는 문제는 사라지지 않는다.

둘째, 어떻게 보낼 것인가. 데이터는 결국 작은 조각으로 나뉘어 여러 장비를 지나간다. 어떤 길로 보낼지, 중간에 사라진 조각을 어떻게 처리할지, 빠르게 보낼지 정확하게 보낼지를 정해야 한다.

셋째, 어떻게 믿을 것인가. 상대가 진짜인지, 내용이 중간에 바뀌지 않았는지, 허락된 사람만 접근하는지 확인해야 한다. 암호화, 인증서, 방화벽, 권한 관리, 로그는 이 질문에 답하기 위한 도구다.

이 세 질문을 기억하면 새로운 기술이 나와도 길을 잃지 않는다. 이름은 달라질 수 있다. 장비는 더 빨라질 수 있다. 프로토콜은 개선될 수 있다. 그래도 인터넷은 결국 찾고, 보내고, 믿는 문제를 해결하는 시스템이다.

이제 머릿속에 인터넷을 조립할 수 있다

처음에는 인터넷이 보이지 않는 거대한 무언가처럼 느껴졌을 것이다. 하지만 한 장씩 쌓아 보면 인터넷은 여러 단순한 약속의 조합이다.

비트는 신호가 되어 길을 지난다. 랜카드는 컴퓨터의 네트워크 문이 된다. 스위치는 가까운 장치들을 묶는다. MAC 주소는 가까운 구간의 이름표가 된다. IP 주소는 더 먼 목적지를 찾는 주소가 된다. 라우터는 네트워크와 네트워크를 잇는다. DNS는 이름을 주소로 바꾼다. TCP와 UDP는 데이터를 어떤 방식으로 주고받을지 정한다. HTTP는 웹의 요청과 응답을 만든다. HTTPS와 방화벽은 통신을 더 안전하게 다듬는다. 캐시, CDN, 로드 밸런서는 더 빠르고 안정적인 서비스를 만든다.

우리가 만든 작은 인터넷은 이 모든 것을 손에 잡히는 크기로 줄여 놓은 모델이었다. 이제 그 모델을 크게 펼치면 집 인터넷이 되고, 회사망이 되고, 데이터센터가 되고, 통신사망이 되고, 전 세계 인터넷이 된다.

인터넷을 만든다는 말은 세상의 모든 케이블을 직접 까는 일이 아니다. 데이터가 지나갈 길을 이해하고, 주소를 붙이고, 길을 고르고, 이름을 해석하고, 안전하게 주고받는 약속을 조립하는 일이다.

이제 웹페이지 하나가 열릴 때 그 뒤에서 어떤 일이 일어나는지 머릿속으로 따라갈 수 있다. 그것이 이 책에서 만든 가장 중요한 결과다. 작은 인터넷을 이해하면, 진짜 인터넷도 더 이상 막연한 구름이 아니다. 여러 장치와 약속이 차례로 협력해 움직이는, 만들고 고칠 수 있는 구조다.