성능과 디버깅 — 느림은 어디서 오나, 어떻게 보나
네트워크를 다 배워도, 현장의 질문은 결국 둘로 모인다 — *"왜 느린가"*와 "어디서 막혔나". 이 마지막 편은 그 둘에 답한다. 느림의 물리적 정체를 알면 엉뚱한 곳을 늘리는 헛수고를 피하고, 계층별 도구를 알면 장애를 빠르게 좁힌다. 01편에서 "문제도 계층으로 쪼개 본다"고 했던 그 약속을 여기서 갚는다.
느림의 정체 — 지연 vs 대역폭
성능을 *지연(latency)*과 대역폭(bandwidth) 두 가지로 나눠 봐야 한다. 대역폭은 한 번에 얼마나 굵게 보내느냐(차선 수), 지연은 한 조각이 가는 데 얼마나 걸리느냐(편도 시간)다. 흔한 오해가 — *"느리니 대역폭(인터넷 속도)을 올리자"*인데, 대역폭을 아무리 늘려도 지연은 안 줄어든다. 서울-뉴욕은 빛의 속도만으로도 편도 약 40ms, 왕복 80ms가 물리적으로 걸린다(거리 ÷ 광속). 그래서 왕복(RTT)이 많은 통신은 — 대역폭과 무관하게 왕복 횟수만큼 느리다.
지연은 다시 — 전파 지연(거리/광속, 못 줄임), 전송 지연(데이터 크기/대역폭), 큐잉 지연(혼잡한 라우터에서 줄 섬), 처리 지연으로 쪼개진다. 여기에 패킷 손실(재전송으로 더 느려짐)과 *지터(jitter, 지연의 들쭉날쭉함 — 실시간에 치명적)*가 더해진다. 그래서 *성능 최적화의 핵심은 "왕복을 줄이는 것"*이다 — TCP·TLS 핸드셰이크를 아끼는 연결 재사용(keep-alive·커넥션 풀), 압축으로 보낼 양 줄이기, CDN으로 거리 줄이기, 캐싱으로 아예 안 가기. 이 노트 전체가 *"비싼 왕복을 아끼는 법"*의 변주였던 셈이다.
어디서 막혔나 — 계층별 도구
장애는 아래 계층부터 위로 하나씩 끊어 본다 — 각 계층에 전용 청진기가 있다.
| 계층 | 질문 | 도구 |
|---|---|---|
| 링크·IP | 상대 컴퓨터까지 닿나? 어디서 막히나? | ping(도달·RTT), traceroute(경로·홉별 지연) |
| DNS | 이름이 IP로 풀리나? | dig·nslookup(각 단계 응답) |
| 전송(TCP) | 그 포트가 열렸나? 소켓 상태는? | telnet/nc(포트 연결), ss/netstat(소켓·TIME_WAIT) |
| 응용(HTTP) | 실제 응답·헤더·상태코드는? | curl -v(요청/응답 상세) |
| 전 계층 | 실제로 어떤 패킷이 오갔나? | tcpdump·wireshark(패킷 캡처) |
흐름은 이렇다 — ping이 가는데 curl이 실패하면 IP는 닿지만 응용에서 막힌 것이고, dig가 옛 IP를 주면 DNS 캐시·TTL 문제이며(06편), ss에 TIME_WAIT이 수만 개면 연결을 너무 자주 맺고 끊는 것이다(04편). 한 계층씩 통과 여부를 확인하면 "어디까지 멀쩡하고 어디서 끊겼다"가 빠르게 좁혀진다.
실무에서는 — 막연한 "느려요"를 숫자로 바꾸는 게 먼저다.
ping으로 RTT를,curl -w로 DNS·연결·TLS·첫바이트(TTFB)·전체 시간을 단계별로 재면 — 어느 단계가 느린지가 드러난다(DNS가 느린지, 핸드셰이크가 느린지, 서버 처리가 느린지). 그리고 대역폭은 충분한데 느리다면 십중팔구 *왕복이 많거나 거리가 멀거나 큐잉(혼잡)*이다 — 대역폭을 늘려도 안 풀린다. 전 세계 사용자를 상대하면 Anycast(같은 IP를 여러 지역에 두고 가장 가까운 곳으로 라우팅)와 CDN으로 거리 자체를 줄이는 게 정석이다.
정리하면, 네트워크 성능은 지연과 대역폭으로 나눠 봐야 한다 — 대역폭을 늘려도 지연(거리·왕복·큐잉)은 안 준다. 그래서 최적화의 핵심은 왕복을 줄이는 것(연결 재사용·압축·CDN·캐싱)이다. 장애는 계층별 도구(ping·traceroute·dig·curl·ss·tcpdump)로 아래부터 위로 끊어 좁히고, "느려요"는 단계별 숫자(RTT·TTFB)로 바꿔 원인을 짚는다. 이렇게 전기 신호(01편)부터 지연 측정(11편)까지 — 네트워크는 결국 "성격 다른 문제를 계층으로 나눠, 각 층이 자기 일만 하게 한" 거대한 협업이다. 그 협업의 첫 페이지에서 본 계층화가, 마지막 페이지의 디버깅까지를 관통한다.