내 메시지는 어떻게 지구 반대편까지 갈까

네트워크는 '멀리 떨어진 컴퓨터끼리 신호를 주고받아 이야기하는 것'이에요. 먼저 두 컴퓨터를 잇고, 선이든 무선이든 길을 만들어요. 주고받는 말은 결국 0과 1이라는 신호로 바뀌어 건너가요. 컴퓨터가 둘만이 아니라 여럿이 그물처럼 이어지면, 누구와도 이야기할 수 있게 돼요. 멀리 + 신호로 + 그물로, 이 셋이 네트워크의 전부예요.

큰 데이터는 한 번에 못 보내요. 그래서 작은 조각인 패킷으로 쪼개요. 조각마다 '몇 번째인지'와 '어디로 가는지'를 적은 꼬리표를 붙여요. 조각들은 따로따로 길을 떠나니, 한 길이 막혀도 다른 길로 돌아갈 수 있어요. 도착한 곳에서는 꼬리표의 번호 순으로 조각을 다시 합쳐서 원래 데이터로 되돌려요. 쪼개고, 꼬리표를 붙이고, 합치기. 이게 패킷이에요.

IP 주소는 '인터넷에 연결된 컴퓨터마다 붙는 고유한 주소'예요. 집 주소처럼 세상에 하나뿐이라야 헷갈리지 않아요. 점으로 나뉜 숫자(예 203.0.113.5)로 적어요. 패킷은 받는 주소를 보고 그 컴퓨터를 정확히 찾아가요. 만약 같은 주소가 둘이면 누구한테 가야 할지 몰라 헷갈리니까, 주소는 꼭 하나뿐이라야 해요.

인터넷의 데이터(패킷)는 목적지까지 한 번에 가지 않아요. 중간 역(라우터)을 여러 개 거쳐서 단계적으로 닿죠. 각 역은 패킷을 잠깐 받았다가 다음 역으로 넘겨요. 받아서, 다시 보내고. 이걸 역마다 되풀이하면, 아무리 먼 곳이라도 한 걸음씩 가까워져 결국 도착해요. 그래서 지구 반대편의 화면도 내 화면에 뜨는 거예요.

네트워크는 모든 일을 한꺼번에 하지 않고 층으로 나눠 각 층이 제 일만 해요. 보낼 때는 메시지를 겹겹이 감싸요. 편지지(내용)에 속봉투(정확히 다 왔는지), 겉봉투(어디로 갈지 주소), 마지막에 우체바구니(0과 1의 실제 신호)까지요. 이걸 캡슐화라고 불러요. 받는 쪽에서는 거꾸로 겉봉투부터 한 겹씩 벗겨 안의 메시지에 도달해요. 층으로 나누면 각 층은 윗층 아랫층을 몰라도 자기 일만 잘하면 돼서 단순하고 튼튼해져요.

라우팅은 패킷을 목적지까지 한 역 한 역 넘기며 길을 찾는 일이에요. 각 역(라우터)은 '길 안내표'를 봐요. 목적지마다 다음에 누구에게 넘길지가 적혀 있죠. 길이 여럿이면 가장 빠른 길을 골라요. 가장 중요한 건 중앙 관제탑이 없다는 거예요. 각 역이 스스로 판단해요. 그래서 한 역이 멈춰도 다른 역들이 우회로를 찾아 편지는 계속 가요. 이 분산 덕분에 인터넷은 잘 끊기지 않아요.

사람은 숫자 주소를 외우기 어려워요. 그래서 외우기 쉬운 이름(도메인)을 쓰고, DNS가 그 이름을 컴퓨터가 아는 숫자 주소로 바꿔 줘요. DNS는 이름과 주소 짝이 가득 든 거대한 전화번호부 같아요. 이름을 물어보면 주소를 알려 주죠. 게다가 한 번 찾은 이름은 잠깐 기억(캐시)해 둬서, 같은 이름을 다시 찾을 땐 번호부까지 안 가도 돼 훨씬 빨라요. 덕분에 우리는 숫자 대신 이름만 기억하면 돼요.

패킷은 도중에 빠지거나 순서가 뒤바뀔 수 있어요. TCP는 그걸 알아서 메워줘요. 받으면 받았다고 확인(ACK)을 보내고, 확인이 안 오면 그 조각을 다시 보내고(재전송), 도착한 조각에 붙은 번호로 순서를 맞춰요. 그래서 받는 쪽에는 늘 '빠짐없이, 순서대로' 도착해요. 빠르기만 한 게 아니라 믿을 수 있게 보내는 약속, 그게 TCP예요.

TCP는 확인(ACK)과 재전송으로 빠짐없이 보내요. 정확한 대신 그만큼 기다리죠. UDP는 그 확인을 생략해요. 받았는지 묻지 않고 빠르게 연달아 쏘고, 몇 개 빠져도 멈추지 않고 그냥 가요. 그래서 게임이나 영상통화, 생방송처럼 늦으면 안 되는 일에 잘 맞아요. 한두 조각 빠진 건 티도 잘 안 나거든요. 정확함이 먼저면 TCP, 빠름이 먼저면 UDP. 둘 다 있는 건 목적이 다르기 때문이에요.

IP 주소는 건물(컴퓨터)을 찾아 줘요. 그런데 한 건물 안엔 여러 호실, 곧 여러 앱이 있어요. 그 호실 번호가 포트예요. 그래서 정확한 목적지는 'IP 주소 + 포트 번호'예요. 건물을 찾고, 그 안의 호실까지 찾는 거죠. 자주 쓰는 앱은 대표 호실 번호가 정해져 있어요. 웹은 80, 안전한 웹(HTTPS)은 443처럼요. 도착한 패킷은 포트 번호를 보고 그 번호의 호실, 곧 맞는 앱으로 들어가요.

집 안 여러 기기는 저마다 집 안 주소를 가지지만, 바깥으로 나갈 땐 공유기를 거쳐 하나의 공인 주소로 나가요. 이게 NAT예요. 공유기는 '어느 기기가 어디로 보냈는지'를 표에 적어두고, 응답이 돌아오면 그 표를 보고 맞는 기기에 정확히 되돌려줘요. 그래서 주소 하나로 여럿이 같이 써도 안 헷갈려요. 게다가 바깥에서 먼저 거는 접속은 표에 짝이 없어서 그냥 막혀요. 안에서 시작한 것만 돌아올 수 있죠. 덕분에 NAT는 천연 방화벽 역할도 해요.

웹은 요청과 응답 한 쌍으로 움직여요. 브라우저가 '이거 줘'(요청)하면 서버가 '여기'(응답)하고 건네줘요. 요청엔 GET(주세요)·POST(받아주세요) 같은 동작이 붙어 무엇을 하려는지 알려요. 한 페이지는 보통 여러 요청-응답으로 글과 그림 조각을 모아 조립돼요. 그리고 HTTP는 지독한 건망증이에요. 매 요청을 처음 보는 손님처럼 대해서, 방금 누가 뭘 했는지 스스로는 기억하지 못해요. 이 약점을 메우는 방법은 다음 강에서 만나요.

사람은 웹페이지(HTML)를 눈으로 보지만, 앱끼리는 화면이 아니라 데이터를 주고받아요. 그 데이터를 정해진 형식으로 주고받는 약속된 창구가 API예요. 약속된 요청(예 서울 날씨?)을 보내면, 그림이 아니라 깔끔한 데이터(온도 23, 맑음 같은 이름과 값)로 답해요. 그래서 다른 앱이 그 데이터를 곧장 쓸 수 있어요. 게다가 여러 API를 조합하면 새 서비스가 돼요. 지도 API에 날씨 API를 얹으면 지도 위에 날씨가 뜨는 식이죠. 우리가 쓰는 많은 앱이 사실은 여러 창구에서 데이터를 받아 합쳐 보여 주는 거예요.

HTTP는 건망증이라 부탁마다 우리를 처음 보는 손님으로 대해요. 그래서 그냥 두면 로그인이 매번 풀려야 맞아요. 이 문제를 푸는 게 쿠키와 세션이에요. 처음 들어올 때 서버가 작은 통행증(쿠키)을 한 장 발급해 줘요. 손님은 다음 방문마다 그 통행증을 같이 보여 줘요. 서버는 통행증에 적힌 번호를 보고 '아, 그 사람!' 하고 알아봐요. 이렇게 같은 손님이라는 걸 이어서 기억하는 게 세션이에요. 덕분에 매번 다시 로그인하지 않아도 돼요. 통행증 번호로 누구인지 알아보는 이 일은, 그 사람이 진짜 맞는지 확인하는 인증 이야기로 이어져요.

보통 HTTP는 내용이 평문이라 중간에서 누구나 엿볼 수 있어요. HTTPS는 내용을 자물쇠로 잠가(암호화) 중간에서 봐도 뒤죽박죽이라 못 읽게 해요. 핵심 아이디어는 두 가지예요. 하나, 공개키라는 자물쇠는 누구에게나 나눠 주되 그걸로 잠근 건 오직 내 비밀키로만 열려요. 둘, 인증서로 상대가 진짜 그 사이트인지 먼저 확인해요. 그래서 카드 번호도 인터넷으로 안심하고 보낼 수 있어요. 그게 HTTPS예요.

주소창에 주소를 입력하면, 이 영역에서 배운 것이 순서대로 일어나요. 먼저 DNS가 이름을 숫자 주소(IP)로 바꿔 주고, 그 주소까지 길을 찾아 패킷이 건너가요. TCP가 빠짐없이 순서대로 닿게 믿음을 주고, HTTPS가 그 통로를 잠가 남이 못 보게 해요. 그 위에서 HTTP가 '이 페이지 주세요, 여기 있어요' 하고 페이지를 주고받죠. 패킷, 주소, 길, 계층이 이 한 흐름에 다 들어 있어요. 인터넷은 결국, 이 약속들이 차곡차곡 손잡고 도는 거대한 우편 시스템이에요.