Step 36. UDP와 ICMP — 던지는 배달부와 상태 신고 전화

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★☆☆☆ | 예상 소요 시간 3시간

전제: Step 35(TCP)를 끝냈어야 합니다. 윈도우 파워쉘에서 진행합니다. 우분투 가상머신이 있다면 같은 실습을 리눅스 명령으로도 해 볼 수 있습니다.

준비물: 윈도우 PC, 파워쉘, 인터넷 연결.
주의: 오늘 실습은 100% 안전합니다. 진단 명령(ping, Test-NetConnection)만 씁니다. 내 컴퓨터와 공개 서버에 "대답해 주세요"라고 묻는 것이 전부이며, 설정을 바꾸는 명령은 하나도 없습니다.

지난 챕터의 TCP는 정중한 배달부였습니다. 악수하고, 확인하고, 순서를 맞추고. 그런데 세상에는 그런 예절이 사치인 상황도 있습니다. 영상 통화에서 0.1초짜리 목소리 조각이 하나 빠졌다고, 그 조각을 다시 주문해 0.5초 뒤에 받는 것 — 그건 도움이 아니라 재앙입니다. 이미 지나간 순간의 소리니까요. 이런 세계에는 그냥 던지는 배달부 UDP가 필요합니다. 그리고 오늘 함께 배울 ICMP는 배달부가 아니라 "네트워크의 신고 전화"입니다. 여러분이 이미 백 번쯤 써 본 ping이 바로 이 ICMP의 산물입니다.

1. 학습 목표

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

TCP와 UDP의 차이를 "빠진 것을 다시 받는 게 의미 있는가"라는 기준으로 설명한다
어떤 서비스가 왜 UDP를 택했는지 추론할 수 있다
ping의 실체가 ICMP echo 요청/응답임을 설명하고, ping 출력의 시간과 TTL을 읽는다
"ping이 안 된다 = 서버가 죽었다"가 틀린 이유를 설명하고, 교차 확인 방법을 안다
"인터넷이 안 돼요"라는 모호한 신고를 층별 질문으로 나누는 진단 사다리를 사용한다

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

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파워쉘 5.1 (일반 권한으로 충분). 우분투 터미널은 선택
오늘의 명령어	`ping -n 4 주소`(윈도우) / `ping -c 4 주소`(리눅스), 복습: `Test-NetConnection 주소 -Port 443`, `nslookup`
필요한 개념	UDP(비연결형 배달), ICMP(상태 신고 규약), Echo 요청/응답, TTL, 신뢰성 vs 속도

2-1. UDP — 던지고 잊는 배달

UDP(User Datagram Protocol)의 철학은 단순합니다:

악수 없음: 연결을 맺지 않습니다. 그냥 보냅니다.
확인 없음: 받았는지 묻지 않습니다.
재전송 없음: 빠지면 빠지는 대로. 순서도 보장하지 않습니다.

대신 얻는 것이 속도와 가벼움입니다. 인사말을 건너뛰고 바로 본론이니 지연이 적고, 확인 절차가 없으니 부담이 작습니다. TCP가 내용증명(볼낸 증거, 도착 확인, 분실 시 재발송)이라면, UDP는 그냥 우편엽서입니다.

2-2. 신뢰성 vs 속도 — 우열이 아니라 용도

TCP와 UDP는 좋고 나쁨이 아니라 용도의 차이입니다:

기준	TCP	UDP
연결	맺고 시작 (handshake)	없이 그냥 전송
도착 확인	함 (재전송도 함)	안 함
순서 보장	함	안 함
속도·지연	상대적으로 느림	빠름
쓰임	웹, SSH, 메일, 파일 전송	DNS, 영상·음성 통화, 게임, 방송

선택의 기준은 하나입니다. "빠진 것을 다시 받는 게 의미가 있는가?" 파일은 한 글자라도 빠지면 쓸모없으니 TCP. 라이브 영상의 0.1초 조각은 늦게 오면 쓸모가 없으니 UDP입니다.

2-3. ICMP — 네트워크 관리실의 신고

ICMP(Internet Control Message Protocol)는 데이터를 나르는 규약이 아니라, 네트워크 상태를 신고하는 관리용 규약입니다. 대표적인 메시지는 세 가지입니다:

Echo 요청/응답: "거기 있어?" / "응, 있어." — 이것이 ping의 실체입니다.
목적지 도달 불가: "그 주소는 없어요"라는 반송 통지.
시간 초과: "편지가 너무 오래 돌아다녀서 폐기했어요." (TTL 만료)

즉 ping은 별도의 마법 프로그램이 아니라, ICMP라는 관리 규약의 echo 메시지를 보내고 돌아오는 시간을 재는 도구였습니다.

2-4. TTL — 편지에 붙은 수명

모든 패킷에는 TTL(Time To Live, 수명)이라는 숫자가 붙습니다. 출발할 때 보통 64 또는 128에서 시작하고, 라우터(동네와 동네를 잇는 이정표)를 하나 지날 때마다 1씩 깎입니다. 0이 되면 그 자리에서 폐기됩니다. 이정표들이 실수로 서로를 가리켜도 편지가 영원히 빙빙 돌지 않게 하는 안전장치입니다.

오늘 실습에서 이 TTL이 "상대가 얼마나 먼가"를 짐작하게 해 주는 힌트로 쓰입니다. 같은 동네 이웃은 깎인 게 거의 없고, 먼 나라 서버는 많이 깎여서 도착하기 때문입니다.

3. 따라 하기

3-1. ping으로 ICMP를 직접 쏘기

ping -n 4 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114
Reply from 8.8.8.8: bytes=32 time=32ms TTL=114
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 33ms, Average = 32ms

(2026-09-09 실측. 한글 윈도우에서는 8.8.8.8의 응답: 바이트=32 시간=33ms TTL=114처럼 한글로 표시됩니다. 시간과 TTL은 여러분 환경에서 다릅니다.)

새 명령 — ping -n 4: -n 4는 "네 번만 보내 줘"입니다 (리눅스라면 ping -c 4). 안 적으면 윈도우는 기본 4번, 리눅스는 멈출 때까지 보냅니다.

출력 읽는 법: 한 줄이 한 번의 echo 왕복입니다. time=33ms는 갔다 온 데 걸린 시간(밀리초, 1000분의 1초), TTL=114는 편지가 죽기까지 남은 동네 수입니다. 아래 통계에서 Lost = 0 (0% loss)은 네 장 모두 답장이 왔다는 뜻입니다. 8.8.8.8은 구글의 공개 DNS 서버로, 거의 항상 대답하는 좋은 실험 상대입니다.

왜: 지금 여러분은 ICMP 메시지를 직접 쏘고 받은 것입니다. 신비롭던 ping이 오늘로 "내가 아는 규약의 메시지"가 됐습니다.

3-2. TTL 비교 — 가까운 곳과 먼 곳

이번엔 우리 집 공유기(기본 게이트웨이)에 ping을 보냅니다. 게이트웨이 주소가 모르면 ipconfig로 먼저 확인하세요 (실측 컴퓨터는 172.30.1.254였습니다. 여러분은 192.168.0.1 같은 주소일 가능성이 높습니다):

ping -n 4 172.30.1.254

Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64

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

읽는 법: 두 가지 차이가 보입니다. 시간은 time<1ms — 같은 동네라 1ms도 안 걸립니다. 그리고 TTL=64 — 한 장도 깎이지 않은 출발 그대로의 숫자입니다. 공유기까지는 라우터를 거치지 않으니(같은 동네니까) 수명이 그대로인 것입니다. 반면 아까 8.8.8.8은 TTL=114 — 상대가 128에서 출발했다면 14개의 라우터를 지나왔다는 계산이 나옵니다.

예측해 보기: 같은 명령으로 ping -n 4 www.naver.com을 쳐 보면 TTL은 얼마일까요? 64보다 클까요, 작을까요? 예측을 적고 확인해 보세요. (힌트: 네이버도 우리 집은 아니니 라우터를 지나옵니다.)

3-3. DNS는 왜 UDP인가

Step 33에서 배운 DNS 조회를 떠올려 보세요. "이 이름의 IP가 뭐야?" — "142.250.206.46." 질문 한 번, 대답 한 번으로 끝나는 짧은 거래입니다.

예측해 보기: 이 짧은 거래에 TCP를 쓴다면 무엇이 낭비될까요? Step 35의 handshake 세 마디를 상상해 보세요. (정답: 질문 하나를 위해 "여보세요 세 마디 + 작별 네 마디"를 해야 하니, 인사가 본론보다 깁니다. 그래서 DNS의 일반 조회는 UDP로 설계됐습니다. 짧고 빠른 왕복에는 던지는 배달이 맞습니다.)

읽는 법: 규약의 선택에는 이유가 있습니다. "왜 이 서비스는 이 규약을 택했을까?"를 묻는 습관이 네트워크를 입체적으로 보게 합니다.

3-4. UDP의 손실 체감하기 (사고 실험)

실제로 패킷을 버리는 실험 대신, 상상 실험을 합니다. 화상 통화 중 UDP 편지 10개 중 1개가 사라졌다고 가정해 봅시다.

TCP였다면: 그 1개를 재전송하느라 화면이 0.5초 멈추고, 돌아온 조각은 이미 지난 과거의 화면입니다.
UDP라서: 그 순간 화면이 깍두기처럼 깨지거나 소리가 뚝 끊기고, 바로 다음 조각으로 넘어갑니다.

읽는 법: 여러분이 화상 통화에서 겪는 "순간 깨짐"이 바로 UDP의 손실입니다. 그리고 그것은 고장이 아니라 설계된 절충입니다 — 늦게 오는 것보다 없는 게 낫다는 선택의 결과입니다.

3-5. "ping이 안 되는데 사이트는 열린다" — 오판 1위 교정

ping -n 4 www.cloudflare.com

Pinging www.cloudflare.com [104.16.123.96] with 32 bytes of data:
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55
Reply from 104.16.123.96: bytes=32 time=3ms TTL=55
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55

(2026-09-09 실측. 실측 환경에서는 클라우드플레어가 응답했습니다. 여러분 환경에서는 응답이 오거나 안 올 수 있습니다.)

읽는 법: 만약 응답이 없는데 브라우저로는 그 사이트가 열린다면, 그것이 오늘의 핵심 증거입니다. 서버가 죽은 게 아니라, ICMP에 대답하지 않도록 설정된 것입니다. 많은 서버가 관리 부담이나 보안상 이유로 ping을 무시합니다.

그럴 때의 교차 확인법이 Step 34에서 배운 포트 두드리기입니다:

Test-NetConnection www.google.com -Port 443

ComputerName     : www.google.com
RemoteAddress    : 142.251.153.119
RemotePort       : 443
InterfaceAlias   : 이더넷
SourceAddress    : 172.30.1.54
TcpTestSucceeded : True

(2026-09-09 실측.)

읽는 법: TcpTestSucceeded : True는 TCP 악수(SYN → SYN-ACK → ACK)가 성공했다는 뜻입니다. ping(ICMP)과 포트 두드리기(TCP)는 서로 다른 층의 질문입니다. 하나가 침묵해도 다른 하나가 대답하면 서버는 살아 있는 것입니다.

왜: "ping 실패 = 서버 다운"은 초보의 오판 1위입니다. 진단은 항상 여러 신호를 모아서 합니다.

4. 미션과 연습문제

미션 — "인터넷이 안 돼요" 진단 사다리 만들기

친구가 전화로 "인터넷이 안 돼요"라고 했다고 상상하고, 진단 사다리를 직접 실행하며 계획을 완성하세요:

노트에 진단 순서를 적습니다: ① ping으로 공유기 두드리기 → ② ping -n 4 8.8.8.8로 바깥 세계 두드리기 → ③ nslookup www.naver.com으로 이름 풀기 (Step 33 복습)
각 단계를 실제로 실행하고 결과를 노트에 기록하세요 (정상 환경이라면 셋 다 성공할 겁니다 — "평소에 전부 되는 모습"을 기록해 두는 것도 데이터입니다)
각 단계 옆에 "여기서 실패하면 어느 구간의 문제인가"를 한 줄로 적으세요
마지막으로 Test-NetConnection www.google.com -Port 443까지 추가해, 네 번째 질문("문이 열려 있나?")도 사다리에 올리세요

연습문제

문제 1. 다음 서비스가 TCP와 UDP 중 무엇을 쓸지, 이유 한 줄과 함께 분류하세요: ① 은행 앱의 이체 ② 실시간 스포츠 중계 ③ DNS 이름 조회 ④ 온라인 FPS 게임의 총알 위치 ⑤ 파일 다운로드

문제 2. ping의 실체는 무엇인가요? "ping은 ○○○○ 규약의 ○○ 메시지를 보내고 돌아오는 시간을 재는 도구" 형식으로 빈칸을 채워 답하세요.

문제 3. 어떤 주소에 ping을 보냈더니 TTL=64가, 다른 주소에서는 TTL=114가 나왔습니다. 이 차이가 말해 주는 것은 무엇이며, 어느 쪽이 더 "가까운" 상대일까요?

문제 4. 어떤 웹 서버에 ping이 안 되는데 브라우저로는 접속됩니다. 서버가 죽은 걸까요? 무슨 설정일 가능성이 있고, 서버의 생사를 추가로 확인하려면 어떤 명령을 쓰면 될까요?

5. 모범 답안과 완료 기준

미션 모범 답안

진단 사다리의 원칙은 "아래층부터, 가까운 곳부터"입니다. 순서와 각 단계의 의미:

① ping 172.30.1.254 (공유기)     → 실패하면: 내 기기~공유기 사이 문제 (케이블, 와이파이)
② ping -n 4 8.8.8.8 (바깥 세계)  → 실패하면: 공유기~통신사 구간 문제
③ nslookup www.naver.com (이름)  → 실패하면: DNS 문제 (Step 33)
④ Test-NetConnection ... -Port 443 → 실패하면: 상대 서버나 중간 방화벽 문제

실측 컴퓨터(2026-09-09)의 실행 결과 예:

① Reply from 172.30.1.254: bytes=32 time<1ms TTL=64     ← 문지방 생존
② Reply from 8.8.8.8: bytes=32 time=33ms TTL=114        ← 바깥 통행 가능
④ TcpTestSucceeded : True                                ← 구글의 443번 문 열림

검증하는 법: 네 단계를 순서대로 실행했고, 각 단계 옆에 "실패 시 의심 구간"이 적혀 있으면 완료입니다. 이 사다리의 힘은 "안 돼요"라는 한마디를 네 개의 다른 병으로 나눠 준다는 데 있습니다 — ①에서 끊기면 우리 집, ②에서 끊기면 회선, ③에서 끊기면 전화번호부(DNS), ④에서 끊기면 상대 쪽. 어느 질문에서 끊기는가가 곧 진단입니다.

연습문제 해답

문제 1 해답. TCP: ① 이체(한 글자도 빠지면 큰일), ⑤ 파일 다운로드(조각 하나라도 빠지면 파일이 깨짐). UDP: ② 스포츠 중계(늦게 온 과거 화면은 쓸모없음), ③ DNS 조회(질문 한 번, 대답 한 번의 짧은 왕복이라 인사가 사치), ④ FPS 게임의 위치(0.1초 전 위치보다 지금 위치가 중요).

문제 2 해답. "ping은 ICMP 규약의 echo(에코) 메시지를 보내고 돌아오는 시간을 재는 도구"입니다. ping은 별도의 프로그램이 아니라 네트워크 관리용 규약의 기능을 빌려 쓰는 것입니다.

문제 3 해답. TTL은 패킷의 수명으로, 라우터를 하나 지날 때마다 1씩 깎입니다. TTL=64는 출발값(64)이 거의 그대로라 라우터를 거치지 않은 같은 동네 상대(예: 공유기)라는 뜻이고, TTL=114는 128에서 출발해 약 14개의 라우터를 지나온 먼 곳 상대라는 뜻입니다. 가까운 쪽은 TTL=64입니다 (2026-09-09 실측으로도 공유기=64, 8.8.8.8=114로 확인됐습니다).

문제 4 해답. 죽은 게 아닐 가능성이 큽니다. 서버가 ICMP echo에 대답하지 않도록 설정된 것입니다 — 관리 부담이나 보안상 이유로 ping을 무시하는 서버가 많습니다. 추가 확인은 다른 층의 질문으로 합니다: Test-NetConnection 서버주소 -Port 443으로 TCP 악수를 시험하면 됩니다. 브라우저 접속이 된다는 것 자체가 이미 "서버는 살아 있고 443번 문이 열려 있다"는 증거입니다.

완료 기준 체크리스트

[ ] TCP와 UDP의 차이를 "재전송이 의미 있는가"라는 기준으로 설명할 수 있다
[ ] 서비스별 규약 선택의 이유를 추론할 수 있다
[ ] ping이 ICMP echo 요청/응답임을 설명할 수 있다
[ ] ping 출력에서 시간(ms)과 TTL을 읽고, TTL로 거리를 짐작할 수 있다
[ ] ping 침묵이 서버 다운이 아닐 수 있는 이유와 교차 확인법을 말할 수 있다
[ ] 진단 사다리 네 단계를 순서대로 말할 수 있다
[ ] 미션: 진단 사다리를 직접 실행하고 기록을 완성했다

6. 흔한 실수와 해결

벽 1. "ping이 안 되니까 서버가 죽은 줄 알고 신고했어요."

증상: ping 실패만 보고 다운이라고 단정합니다.
원인: ICMP를 막아 둔 서버는 살아 있어도 ping에 침묵합니다.
해결: ping은 "여러 질문 중 하나"일 뿐입니다. 웹 서버라면 브라우저로 접속하거나 Test-NetConnection 주소 -Port 443으로 교차 확인하세요. 한 신호의 침묵은 결론이 아니라 단서입니다.

벽 2. "UDP가 빠르다며, 그럼 다 UDP로 하지 왜 TCP를 써요?"

증상: 빠른 것이 좋아 보이니 자연스럽게 드는 의문입니다.
원인: UDP의 빠름은 "확인의 포기"에서 옵니다. 확인이 필요한 데이터(파일, 계좌 이체, 로그인)에는 그 확인이 본질입니다.
해결: "빠르다"와 "믿을 수 있다"를 분리해 생각하세요. 선택의 기준은 속도가 아니라 "빠지면 안 되는 데이터인가"입니다.

벽 3. "ping 시간이 200ms가 나와요. 고장인가요?"

증상: 응답은 오는데 시간이 큽니다.
원인: 상대가 멀면(해외 서버) 빛의 속도 한계상 수십~수백 ms는 정상입니다. 한국에서 미국 서버까지 왕복 150ms 남짓은 물리 법칙입니다.
해결: 절대 숫자가 아니라 "평소와 비교"가 기준입니다. 같은 대상이 평소 20ms였는데 갑자기 300ms면 이상 신호입니다. 평소 숫자를 기록해 두는 베이스라인 습관(Step 15)이 여기서도 쓰입니다.

벽 4. "ping을 쳤는데 제가 친 이름이 아니라 이상한 이름이 나와요."

증상: ping www.microsoft.com을 쳤더니 이런 줄이 나옵니다 (2026-09-09 실측):

Pinging e13678.dscb.akamaiedge.net [104.94.218.45] with 32 bytes of data:

원인: 오염이 아니라 CDN(콘텐츠 전송 네트워크)의 정상 동작입니다. 마이크로소프트 같은 대형 서비스는 전 세계에 복사본 서버를 두고, 이름 조회 단계에서 "접속한 사람과 가까운 서버"의 이름으로 안내합니다. akamaiedge는 아카마이라는 CDN 회사의 서버입니다.
해결: 이상한 게 아니라 Step 33의 DNS가 일한 흔적입니다. "이름을 물었더니 다른 이름과 주소가 돌아왔다 = CDN 뒤의 서비스"로 읽으면 됩니다.

7. 정리

오늘의 개념

개념	한 줄 설명
UDP	악수·확인·재전송이 없는 "던지는 배달" — 빠르지만 잃을 수 있음
ICMP	네트워크 상태를 신고하는 관리 규약 (echo, 도달 불가, 시간 초과)
ping	ICMP echo 요청을 보내고 응답 시간을 재는 도구
TTL	패킷의 수명 — 라우터 하나당 1씩 깎이고 0이면 폐기
진단 사다리	공유기 → 바깥(8.8.8.8) → 이름(DNS) → 포트(TCP) 순으로 묻는 절차

오늘의 명령어

명령	하는 일
`ping -n 4 주소`	ICMP echo를 4번 보내 응답·시간·TTL 확인 (리눅스: `ping -c 4`)
`Test-NetConnection 주소 -Port 443`	TCP 악수 시험 — ping과 다른 층의 질문
`nslookup 이름`	이름 → 주소 변환 확인 (Step 33 복습)

명령어보다 중요한 감각

오늘의 진짜 수확은 "질문을 나누는 기술"입니다. "인터넷이 안 돼요"는 이름을 못 푸는 것(DNS), 악수가 안 되는 것(TCP), 길 자체가 끊긴 것(ICMP로 확인)이 섞인 말입니다. 같은 "안 됨"이 층별 질문으로 갈라지는 순간, 문제는 절반 풀린 것입니다.

두 가지를 더 기억해 두세요. 첫째, 최신 웹 표준 HTTP/3는 UDP 위에 신뢰성을 다시 만든 QUIC이라는 규약을 씁니다 — 규약이 포기한 확인을 프로그램이 스스로 구현한 것으로, "분류표는 절대적이지 않다"는 좋은 예입니다. 둘째, ICMP가 관리용이라고 순진한 것은 아닙니다. 과거에는 거대한 ping 조각으로 시스템을 다운시키는 공격(Ping of Death) 등이 유행했고, 그래서 오늘날 많은 서버가 ICMP를 제한합니다 — 벽 1의 "침묵하는 서버"들에는 이런 역사가 깔려 있습니다. 참고로 UDP는 악수가 없어서 TCP처럼 "대답 = 열림"으로 스캔하기 어렵습니다. 규약의 성격이 공격과 방어의 지형까지 바꾼다는 것, 그것이 규약을 배우는 이유입니다.

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