Step 37. 라우팅과 게이트웨이 — 편지의 여정을 따라가라

Level 0 — 컴퓨터와 친해지기 | 난이도 ★☆☆☆☆ | 예상 소요 시간 2시간

전제: Step 31~36을 마쳤고, IP 주소와 포트, TCP/UDP/ICMP의 차이를 압니다. 윈도우 파워쉘에서 진행합니다.

준비물: 윈도우 PC, 파워쉘, 인터넷 연결.
주의: 오늘 실습은 100% 안전합니다. 전부 조회 명령입니다. tracert는 완료까지 수십 초 걸릴 수 있는데, 멈춘 게 아니라 한 홉씩 기다리는 중이니 끝날 때까지 두세요.

집에서 택배를 하나 부친다고 생각해 봅시다. 목적지가 같은 동네면 동네 우체국 하나로 끝나지만, 목적지가 부산이면 택배는 집 앞 우체국 → 시내 물류센터 → 부산 물류센터를 거쳐 갑니다. 이 "거쳐 가는 물류센터들"이 오늘의 주인공, 라우터입니다. 지금까지 우리는 편지의 주소(IP)와 규격(TCP, UDP, ICMP)을 배웠고, 오늘은 그 편지가 실제로 움직이는 길을 봅니다. 명령어 한 줄이면, 우리 집에서 구글까지의 여정이 눈앞에 펼쳐집니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

라우터와 홉(hop)이 무엇인지 설명한다
"모르는 주소는 일단 기본 게이트웨이로"라는 규칙을 예시와 함께 말한다
tracert의 원리(TTL을 하나씩 늘리는 속임수)를 설명한다
추적 결과의 별표(응답 없음)와 진짜 끊김을 구별한다
내 컴퓨터의 라우팅 테이블에서 기본 규칙 두 줄을 읽는다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파워쉘 5.1 (일반 권한으로 충분)
오늘의 명령어	`ipconfig`(게이트웨이 확인), `tracert 주소`(경로 추적), `Get-NetRoute`(라우팅 테이블)
필요한 개념	라우터, 홉(hop), 기본 게이트웨이, TTL, 라우팅 테이블

2-1. 라우터 — 네트워크와 네트워크 사이의 이정표

네트워크 세계는 수많은 "동네"로 이루어져 있습니다. 우리 집 네트워크도 하나의 동네, 회사 사내망도 하나의 동네, 구글의 데이터센터도 하나의 거대한 동네입니다. 이 동네들을 서로 이어 주는 장비가 라우터(router)입니다. 편지의 주소를 보고 "이건 오른쪽 길로 가야 하네"라고 다음 동네 방향을 정해 주는 이정표 역할을 합니다.

집에 있는 공유기도 사실은 라우터입니다. 가장 작은 라우터 — 우리 집 동네와 인터넷이라는 큰 세계를 이어 주는 문지방이죠.

2-2. 홉 — 한 단계의 이름

택배가 물류센터 하나를 거칠 때마다 "한 단계"라고 부르듯, 네트워크에서는 라우터 하나를 지날 때마다 1홉(hop)씩 늘어납니다. 집에서 구글까지는 보통 10~20홉 정도입니다. 지구 반대편도 스무 발짝 안에 도착합니다.

2-3. 기본 게이트웨이 — "모르면 일단 여기로"

내 컴퓨터가 모든 목적지의 길을 아는 것은 아닙니다. 실은 아는 게 거의 없고, 딱 하나만 압니다. "같은 동네(같은 네트워크)가 아니면, 일단 기본 게이트웨이(default gateway)로 보낸다."

기본 게이트웨이는 보통 우리 집 공유기의 주소입니다. 컴퓨터는 "부산으로 가는 길"을 모르지만 "일단 현관문 밖으로 내내 주면 공유기가 알아서 해 줄 거야" 하는 셈입니다. 공유기는 다시 통신사의 더 큰 라우터에게 묻고, 그 라우터는 또 다음 라우터에게 묻습니다. 이렇게 "모르면 윗사람에게 묻기"의 연쇄로 편지가 전진합니다.

2-4. TTL — 경로 추적의 비밀 열쇠

Step 36에서 배운 TTL(Time To Live)을 기억하세요. 패킷에 붙은 수명 숫자로, 라우터를 하나 지날 때마다 1씩 깎이고 0이 되면 폐기됩니다. 그리고 여기에 규칙이 하나 더 있습니다. "패킷이 0이 되어 죽으면, 그 자리의 라우터가 ‘여기서 죽었습니다’라고 ICMP로 알려 준다."

이 규칙 덕분에 이런 속임수가 가능합니다. TTL을 1로 해서 보낸다 → 첫 번째 라우터에서 죽는다 → 그 라우터가 자기 주소를 알려 준다. TTL을 2로 하면 → 두 번째 라우터가 알려 준다. 이렇게 1, 2, 3… 하나씩 늘리면 목적지까지의 라우터 목록이 통째로 드러납니다. 이것이 경로 추적 도구 tracert(윈도우) / traceroute(리눅스)의 원리입니다.

3. 따라 하기

3-1. 내 출구 확인 — 기본 게이트웨이 보기

먼저 내 컴퓨터의 "현관문"이 어디인지 확인합니다:

ipconfig

Ethernet adapter 이더넷:

   IPv4 Address. . . . . . . . . . . : 172.30.1.54
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 172.30.1.254

(2026-09-09 실측, 실제로 연결된 어댑터 부분만 발췌. 한글 윈도우에서는 IPv4 주소, 서브넷 마스크, 기본 게이트웨이로 표시됩니다. 여러분의 주소는 다르며, 192.168.0.x 형태가 가장 흔합니다.)

출력 읽는 법: 마지막 줄 "Default Gateway(기본 게이트웨이)"가 오늘의 주인공입니다. 내 패킷이 바깥 세계로 나갈 때 무조건 처음 거치는 문입니다. 윗줄의 내 IP(172.30.1.54)와 게이트웨이(172.30.1.254)의 앞부분(172.30.1)이 같은 것도 보이시나요? 같은 동네라는 뜻입니다.

왜: 모든 길 찾기는 "내 출구가 어디인지"에서 시작합니다. 다음 실습에서 이 주소가 첫 번째 홉으로 등장하는지 확인할 것입니다.

3-2. 예측해 보기 — 첫 홉은 누구일까

실습 전에 예측합니다.

예측: 구글의 DNS 서버(8.8.8.8)까지의 경로를 추적했을 때, 첫 번째 홉(1홉)은 어떤 주소일까요? 아까 본 기본 게이트웨이 주소일까요, 아니면 전혀 다른 낯선 주소일까요?

이유를 붙여 봅시다. "모르는 주소는 일단 게이트웨이로 보낸다"고 배웠으니, 첫 번째로 도착하는 라우터는 당연히 우리 집 공유기여야 합니다. 이제 직접 확인합니다.

3-3. 패킷의 여정 추적 — tracert

tracert 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.30.1.254
  2     *        *        *     Request timed out.
  3     3 ms     2 ms     2 ms  211.xxx.xxx.xxx
  4     1 ms     1 ms     1 ms  211.xxx.xxx.xxx
  5     2 ms     3 ms     1 ms  112.xxx.xxx.xxx
  6    10 ms     9 ms     9 ms  112.xxx.xxx.xxx
  7     9 ms    10 ms     9 ms  112.xxx.xxx.xxx
  8    32 ms    33 ms    32 ms  74.125.147.98
  9    33 ms    33 ms    32 ms  142.251.196.73
 10    35 ms    33 ms    34 ms  108.170.233.191
 11    32 ms    34 ms    32 ms  8.8.8.8

Trace complete.

(2026-09-09 실측. 이름 조회를 건너뛰어 더 빠르게 끝나는 -d 옵션을 붙여 찍었습니다 — tracert -d 8.8.8.8. 통신사 구간의 주소(3~7홉)는 예시 값으로 가공했고, 8~10홉의 74.125, 142.251, 108.170 대역은 구글의 백본 라우터입니다. 여러분의 홉 수와 주소, 시간은 다릅니다. 한글 윈도우에서는 최대 30홉에 대한 경로 추적, 추적을 완료했습니다처럼 한글로 표시됩니다.)

출력 읽는 법: 왼쪽 숫자가 홉 번호입니다. 1번은 예측대로 우리 집 공유기(172.30.1.254)입니다. 그다음 통신사 라우터들(3~7홉)을 지나 구글의 백본망(8~10홉)에 진입하고, 마지막에 목적지에 도착합니다. 가운데의 ms 숫자는 그 홉까지 편지가 갔다 온 시간입니다. 뒤로 갈수록 커지는 것이 정상입니다 — 멀어지니까요. 1~7홉(한국 안)은 10ms 이하인데 8홉부터 32ms로 뛰는 것, 즉 "국내 구간"과 "해외 구간"의 경계가 숫자에서 읽힙니다.

왜: 이 한 장의 목록이 "인터넷은 거대한 릴레이"라는 말의 실물 증거입니다. 이론으로 배운 라우터 릴레이를 내 눈으로 본 것입니다.

3-4. 별표의 수수께끼 — 응답 없는 라우터

방금 실측 결과를 다시 보세요. 2홉이 진짜로 별표였습니다:

  2     *        *        *     Request timed out.

별표 세 개는 "그 라우터가 ICMP 알림을 보내지 않았다"는 뜻입니다. 길이 끊긴 것이 아닙니다. 어떤 라우터는 보안상, 또는 바빠서 이 알림을 무시합니다. 실측에서도 2홉만 침묵하고 3홉부터는 정상이었으며 마지막에 도착까지 했습니다 — 조용한 물류센터가 하나 있는 것일 뿐입니다.

예측: 만약 마지막 도착지까지 줄줄이 별표라면 어떨까요? 힌트는 Step 36에 있습니다. ping(ICMP)을 아예 안 받는 서버도 있다고 배웠습니다. 중간 별표는 무시해도 되지만, 끝까지 별표면서 "Trace complete"가 안 뜨면 그 지점에 장애가 있는 것입니다. 중간 별표는 무시, 끝 별표는 점검 — 이 한 줄이면 됩니다.

3-5. 같은 동네는 홉이 하나 — 게이트웨이 추적

tracert -d 172.30.1.254

Tracing route to 172.30.1.254 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.30.1.254

Trace complete.

(2026-09-09 실측. 공유기 주소는 여러분 것으로 바꾸세요.)

읽는 법: 같은 동네 목적지는 홉이 하나입니다. 이웃이니까 물류센터를 거칠 필요가 없지요. 반면 8.8.8.8은 열한 발짝이었습니다. 홉 수 하나로 "같은 동네인가, 먼 여행인가"를 구분할 수 있습니다.

왜: Step 32의 ARP(이웃에게 직접 묻기)와 오늘의 라우팅(먼 곳은 이정표 따라가기)이 정확히 여기서 만납니다. 홉 1 = 이웃 = ARP가 해결. 홉 2 이상 = 여행 = 라우터가 해결.

3-6. 내 컴퓨터의 라우팅 테이블 들여다보기

라우터만 길 안내표를 갖는 것이 아닙니다. 내 컴퓨터에도 작은 규칙표가 있고, 그것이 라우팅 테이블(routing table)입니다:

Get-NetRoute -AddressFamily IPv4

(출력이 길어서, 실측 결과에서 핵심 두 줄만 발췌했습니다.)

DestinationPrefix NextHop      InterfaceAlias
----------------- -------      --------------
172.30.1.0/24     0.0.0.0      이더넷
0.0.0.0/0         172.30.1.254 이더넷

(2026-09-09 실측. 우분투라면 ip route로 같은 내용을 봅니다 — default via 172.30.1.254 ... 같은 줄이 보일 겁니다.)

출력 읽는 법:

172.30.1.0/24 → NextHop 0.0.0.0 — "우리 동네 주소(172.30.1.x)는 다음 이정표 없이 직접 배달한다." NextHop이 0.0.0.0이면 "게이트웨이 불필요, 이웃에게 직접"이라는 뜻입니다.
0.0.0.0/0 → NextHop 172.30.1.254 — "그 외 모든 주소(default)는 172.30.1.254(게이트웨이)에게 넘긴다."

딱 이 두 줄이 내 컴퓨터의 길 찾기 전부입니다. 같은 동네면 직접, 아니면 게이트웨이로. 세계의 큰 라우터들은 이 표가 수십만 줄인 것뿐, 원리는 같습니다.

왜: "기본 게이트웨이"가 추상 개념이 아니라 시스템에 적힌 실제 규칙임을 확인하는 과정입니다.

4. 미션과 연습문제

미션 — 오늘의 홉 지도 그리기

노트와 펜을 꺼내세요. 진짜 종이입니다:

ipconfig로 내 IP와 기본 게이트웨이를 적습니다
tracert -d 8.8.8.8을 실행하고, 1홉부터 마지막 홉까지를 큼직하게 적습니다 (시간이 걸려도 끝까지 기다리세요)
1홉에 동그라미를 치고 "우리 집 공유기"라고 적습니다
마지막 홉에 "구글 DNS"라고 적고, 그 사이를 "통신사와 인터넷의 라우터들"이라고 적습니다
별표가 있었다면 그 홉에 "조용한 라우터"라고 표시합니다
그림 아래에 이 문장을 씁니다: "모르는 주소는 일단 게이트웨이로. TTL을 하나씩 늘리며 라우터들에게 자기소개를 요구하는 것이 tracert."

연습문제

문제 1. 기본 게이트웨이란 무엇이며, 내 컴퓨터가 어떤 목적지를 게이트웨이로 보내는지의 기준은 무엇인가요?

문제 2. tracert가 경로상의 라우터들을 알아내는 원리를 TTL과 ICMP를 들어 설명하세요.

문제 3. tracert 결과 중간에 * * *가 나왔습니다. 언제는 무시해도 되고, 언제는 점검해야 하나요?

문제 4. 같은 목적지에 대해 "홉 수가 많다 = 느리다"는 항상 맞을까요? 홉 수와 ms 시간이 각각 무엇을 나타내는지로 답하세요.

5. 모범 답안과 완료 기준

미션 모범 답안

완성된 지도의 모습 (2026-09-09 실측 기반):

내 컴퓨터 (172.30.1.54)
   │
   ▼  1홉
[우리 집 공유기] 172.30.1.254  <1ms        ← 기본 게이트웨이
   │
   ▼  2홉
(조용한 라우터) * * *                      ← 별표 = 대답 안 함, 길은 살아 있음
   │
   ▼  3~7홉
통신사 라우터들 (211.xxx, 112.xxx 대역) 1~10ms
   │
   ▼  8~10홉
구글 백본 라우터들 (74.125 / 142.251 / 108.170 대역) 32~35ms
   │
   ▼  11홉
[구글 DNS] 8.8.8.8 32ms  ← Trace complete.

검증하는 법: ① 1홉이 ipconfig에서 본 기본 게이트웨이와 일치하는가 — 일치하면 "모르는 주소는 일단 게이트웨이로" 규칙 확인 완료. ② 마지막 줄이 목적지 주소이고 "Trace complete(추적을 완료했습니다)"가 떴는가 — 그러면 중간에 별표가 있어도 정상입니다. ③ 1홉과 마지막 홉 사이를 "통신사와 인터넷의 라우터들"로 설명할 수 있으면 지도 완성입니다.

연습문제 해답

문제 1 해답. 기본 게이트웨이는 "모르는 주소의 편지를 일단 넘기는 출구"로, 보통 공유기의 주소입니다. 보내는 기준은 같은 동네(같은 네트워크 대역) 여부입니다 — 같은 동네면 직접 배달하고(NextHop 0.0.0.0), 아니면 게이트웨이로 넘깁니다. 실측 라우팅 테이블의 0.0.0.0/0 → 172.30.1.254 줄이 바로 그 규칙입니다.

문제 2 해답. TTL을 1부터 시작해 하나씩 늘려 가며 패킷을 보냅니다. TTL이 0이 된 지점의 라우터는 "여기서 폐기했습니다"라는 ICMP 시간 초과 메시지를 보내 오는데, 그 메시지의 발신자 주소가 곧 그 홉의 라우터 주소입니다. 이것을 목적지에 닿을 때까지 반복하면 경로 전체가 드러납니다.

문제 3 해답. 중간의 별표는 무시, 끝의 별표는 점검입니다. 중간 홉의 별표는 그 라우터가 ICMP 알림을 안내도록 설정된 것일 뿐이고(실측에서도 2홉이 그랬습니다), 이후 홉과 최종 도착이 정상이면 문제없습니다. 반면 끝까지 별표만 이어지고 완료 메시지가 안 뜨면 그 지점 이후에 장애가 있는 것입니다.

문제 4 해답. 항상 맞지는 않습니다. 홉 수는 논리적 경유지 수(이정표를 몇 개 거쳤는가)이고, ms 시간은 실제 체감 거리(물리적 거리와 회선 상태)입니다. 홉이 적어도 해저 케이블을 타면 느리고, 홉이 많아도 국내망 안이면 빠릅니다. 실측에서도 국내 7홉은 10ms 이하, 해외 진입 후 3홉은 32ms대였습니다.

완료 기준 체크리스트

[ ] 라우터와 홉의 의미를 설명할 수 있다
[ ] ipconfig로 내 기본 게이트웨이를 확인할 수 있다
[ ] tracert로 경로를 추적하고 첫 홉이 공유기임을 확인했다
[ ] TTL을 늘려 가며 각 라우터의 자기소개를 받는 tracert의 원리를 설명할 수 있다
[ ] 별표(응답 없음)와 진짜 끊김을 구별할 수 있다
[ ] 라우팅 테이블에서 "직접 배달"과 "기본 규칙" 두 줄을 읽을 수 있다
[ ] 미션: 홉 지도 그리기를 완성했다

6. 흔한 실수와 해결

벽 1. 우분투에서 traceroute가 명령어를 못 찾는다

증상: command not found: traceroute
원인: 우분투 기본 설치에는 없습니다. 빼먹기 쉬운 도구입니다.
해결: sudo apt install -y traceroute로 설치합니다. 윈도우의 tracert는 기본 내장입니다. 이름이 비슷하지만 다르다는 것도 기억해 두세요 — 윈도우는 tracert, 리눅스는 traceroute.

벽 2. 중간이 온통 별표라서 불안하다

증상: 연속된 * * * Request timed out.
원인: 두 가지 경우가 있습니다. (가) 그 구간의 라우터들이 ICMP 알림을 안 보내는 것 — 정상. (나) 진짜로 그 지점 이후가 끊긴 것.
해결: 구별법은 마지막 줄입니다. 목적지 IP가 찍히고 "Trace complete"로 끝났다면 정상입니다. 실측 환경에서도 2홉이 별표였지만 11홉까지 도착했습니다. 끝까지 별표만 나오고 완료 메시지가 없다면 그 지점에 장애가 있는 것입니다.

벽 3. 1홉이 내 공유기 주소가 아니다

증상: 가상머신에서 추적하니 1홉이 우리 집 공유기가 아니라 다른 주소입니다.
원인: 가상머신은 종종 가상화 프로그램이 만들어 준 가상의 작은 동네 안에 있습니다. 가상머신의 게이트웨이는 물리적 공유기가 아니라 가상 공유기입니다. (실측 컴퓨터에도 WSL용 가상 어댑터가 192.168.32.1이라는 별도 동네 주소를 갖고 있었습니다.)
해결: 이상한 것이 아닙니다. "일단 내 게이트웨이로" 규칙이 가상 세계에서도 그대로 적용된 것입니다. 그 가상머신 안에서 ipconfig(또는 ip route)로 확인한 게이트웨이 주소와 1홉이 일치하면 정상입니다.

벽 4. 홉이 30을 넘어간다

증상: 추적이 30홉에서 멈추고 도착하지 않습니다.
원인: 도구의 기본 최대 홉 수가 30이라 거기서 그만둔 것이거나(출력 첫 줄의 "over a maximum of 30 hops"가 그 설정입니다), 경로 이상으로 패킷이 빙빙 도는 경우입니다.
해결: 보통은 전자입니다. tracert -h 50 8.8.8.8처럼 최대 홉을 늘려 다시 시도해 보세요. 그래도 안 되면 그 목적지는 추적을 허용하지 않는 네트워크 뒤에 있는 것입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
라우터	네트워크와 네트워크를 잇는 이정표 장비 (공유기도 작은 라우터)
홉(hop)	라우터 하나를 지나는 한 단계
기본 게이트웨이	"모르는 주소는 일단 여기로"의 출구, 보통 공유기
라우팅 테이블	"이 대역은 이 문으로"라는 규칙 목록 — 내 컴퓨터에도 있음
별표(`* * *`)	ICMP 알림을 안 보내는 라우터 — 길이 끊긴 게 아님

오늘의 명령어

명령	하는 일
`ipconfig`	내 IP와 기본 게이트웨이 확인
`tracert 주소`	목적지까지의 홉(경유 라우터) 추적 (`-d`: 이름 조회 생략으로 빠르게, `-h 숫자`: 최대 홉 변경)
`Get-NetRoute -AddressFamily IPv4`	내 컴퓨터의 라우팅 테이블 보기 (우분투: `ip route`)

명령어보다 중요한 감각

"모르는 주소는 일단 게이트웨이로" — 이 한 줄이 인터넷 길 찾기의 전부입니다. 그리고 tracert는 TTL을 1, 2, 3으로 늘리며 각 라우터에게 "여기서 죽었다"는 신고(ICMP)를 요구하는 영리한 속임수라는 것. 규칙의 부산물(폐기 신고)을 지도 그리기에 쓴 발상을 기억해 두세요.

경로를 읽는 기술은 공격자와 방어자가 똑같이 씁니다. 공격자는 목표 네트워크의 윤곽(어느 통신사, 경계 장비 위치)을 이 도구로 스케치하고, 방어자는 장애 구간을 찾고 평소와 다른 경로로 패킷이 도는지 감시합니다. 오늘의 추적은 누구에게나 열린 합법적 진단이지만, "읽는 기술"과 "비틀는 기술" 사이의 선은 명확히 기억하세요. 그리고 이 지도에는 흥미로운 칸이 하나 남아 있습니다 — 1홉의 주인공, 공유기입니다. 오늘 우리는 그 상자가 "첫 이정표"라는 사실을 확인했고, 이제 그 상자가 매 순간 무슨 일을 하는지 궁금해질 차례입니다. 오늘의 tracert 결과를 노트에 붙여 두세요. 그 상자의 속을 들여다볼 때 이 종이가 최고의 대조 자료가 되어 줄 것입니다.

전부 체크되면 Step 37 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.