네트워크 — 왜 이렇게 생겼고, 어떻게 동작하나

네트워크는 외울 게 많아 보인다. TCP handshake, DNS 계층, CIDR, TLS, HTTP/2… 그런데 이것들은 따로 만들어진 규칙이 아니라, 하나의 설계 철학에서 순서대로 파생된 결과다.

인터넷은 “중앙이 없어도, 일부가 끊겨도 동작해야 한다”는 원칙으로 설계됐다. 이 원칙을 알면 왜 패킷 교환인지, 왜 TCP와 IP가 나뉘었는지, 왜 DNS가 계층 구조인지가 외울 것이 아니라 이해할 것이 된다. 세 단계로 보면 된다. 왜 이렇게 설계됐나(역사) → 주소를 어떻게 나누나(CIDR) → 실제로 한 요청이 어떻게 흐르나(전체 통합).

① 왜 이렇게 설계됐나 — 역사가 곧 이유

회선 교환(전화)은 중앙 교환기가 끊기면 다 죽는다. 그래서 패킷 교환이 나왔고, 신뢰성(TCP)과 주소·라우팅(IP)을 분리해 각자 진화할 수 있게 했다. DNS는 hosts.txt를 수동 관리하던 혼란에서 태어났다. 설계 결정 하나하나에 “이런 문제가 있어서 이렇게 풀었다”는 맥락이 있다.

→ 네트워크 역사 — ARPANET에서 TCP/IP까지

② 주소를 어떻게 나누나 — CIDR

IP가 43억 개나 되는데도 부족했던 건 Class A/B/C 체계의 낭비 때문이었다. CIDR은 주소를 비트 단위로 유연하게 쪼개 이 낭비를 줄였다. /24가 왜 254개인지, 서브넷을 어떻게 더 쪼개는지, AWS VPC를 어떻게 설계하고 왜 CIDR이 겹치면 안 되는지 — 클라우드 인프라 설계의 기초다.

→ CIDR — 왜 존재하는가, IP 주소 고갈의 해결책

③ 한 요청이 어떻게 흐르나 — 전체 통합

위의 조각들이 실제로 어떻게 맞물리는지는 “www.naver.com을 치면 무슨 일이 벌어지나” 하나로 통합된다. DNS 쿼리 → TCP 3-way handshake → TLS → HTTP/2 → L4/L7 LB → WAS → CDN까지. 앞의 역사와 주소 체계가 여기서 한 줄로 꿰진다.

→ www.naver.com을 치면 무슨 일이 벌어지나

면접에서 이 그림이 유용한 이유

“URL 치면 무슨 일이 일어나나”는 단골 질문이다. 단순 암기로 나열하면 얕고, 설계 의도로 풀면 깊다. “인터넷은 중앙 없이 견디게 설계됐다 → 그래서 패킷 교환, TCP/IP 분리, 계층적 DNS, 비트 단위 주소(CIDR)가 나왔다 → 한 요청은 이 조각들을 순서대로 통과한다”고 엮으면, 각 단계에서 왜 그렇게 동작하는지까지 설명할 수 있다.