이름과 주소

사용자는 IP 주소가 아니라 이름(www.example.net)을 입력합니다. 이 레슨에서는 그 이름이 어떻게 IP 주소로 바뀌는지(DNS), 그리고 IP 주소가 실제로는 이진수라는 점을 정리합니다. DNS는 도메인 연결, 배포, HTTPS 인증서 발급 등 프론트엔드 작업과 직접 맞닿아 있습니다.

DNS — 이름을 주소로 바꾸는 시스템

DNS(Domain Name System) 는 도메인 이름을 IP 주소로 바꿔주는, 전 세계에 분산된 디렉터리입니다. 전화번호부에서 이름으로 번호를 찾는 것과 비슷합니다. 가장 기본이 되는 것은 A 레코드(Address)로, www.example.net 같은 이름을 IPv4 주소로 연결합니다.

DNS 조회를 수행하는 클라이언트 코드를 resolver라고 하며, 모든 OS에 내장되어 있습니다. 그래서 ping·nc·브라우저는 직접 DNS를 구현하지 않고 OS의 resolver를 호출합니다. 터미널에서 직접 조회할 때는 host(읽기 쉬운 형식)나 dig(상세 정보)를 씁니다.

$ host google.com
# google.com has address 142.250.x.x
 
$ dig www.example.com   # question / answer / TTL 등 상세 정보

DNS가 동작하지 않으면 IP 주소를 알 수 없어 사이트에 접속할 수 없습니다. 또한 도메인은 HTTPS(TLS) 인증서와 쿠키 보안의 기준이 되므로(인증서는 특정 도메인에만 유효하고, 쿠키도 도메인에 묶임), DNS는 단순한 이름 변환을 넘어 보안의 기반이기도 합니다.

주요 레코드 타입

도메인을 설정할 때 자주 다루는 레코드입니다. 배포 플랫폼에 커스텀 도메인을 연결할 때 직접 등록하게 됩니다.

캐싱과 TTL

resolver는 매번 전 세계의 권한 서버까지 찾아가지 않습니다. 보통 가까운 캐싱 DNS 서버(집 공유기, ISP, 또는 8.8.8.8 같은 공용 DNS)에 먼저 묻습니다. 캐시에 없으면 root → TLD(.com 등) → 해당 도메인 순으로 단계를 밟아 답을 찾고, 그 결과를 캐시에 저장해 다음 조회를 빠르게 합니다.

캐싱은 속도를 높이지만 부작용도 있습니다. 서버 IP를 바꿔도 예전 주소가 캐시에 남아 있으면, 일부 사용자는 한동안 옛 서버로 접속합니다. 그래서 각 레코드에는 TTL(Time To Live) 값이 있어 “이 결과를 몇 초 동안 캐시해도 되는지”를 정합니다.

이 점은 배포·이전 작업에서 실질적인 영향을 줍니다. 서버나 호스팅을 옮기기 전에 미리 TTL을 짧게(예: 300초) 낮춰 두면, 변경 후 사용자들이 새 주소로 빠르게 전환됩니다. 반대로 TTL이 길면(예: 24시간) 변경이 모두에게 반영되기까지 오래 걸립니다. “DNS는 바꿨는데 일부만 새 서버로 간다”는 상황의 흔한 원인이 이 캐시와 TTL입니다.

IP 주소는 사실 이진수다

IPv4 주소는 32비트 값 입니다. 241.10.27.53 처럼 점으로 구분한 네 덩어리(dotted quad) 표기는 사람이 읽기 쉽도록 만든 관례일 뿐, 실제 네트워크에서는 32개의 비트로 전송됩니다. 네 덩어리 각각을 옥텟(octet) 이라 부르며, 한 옥텟은 8비트입니다.

각 옥텟이 0~255 범위인 이유는 8비트로 만들 수 있는 값의 개수가 정해져 있기 때문입니다. n비트로는 2ⁿ개의 서로 다른 값을 표현할 수 있습니다. 8비트면 2⁸ = 256가지이므로 0부터 255까지입니다.

각 비트 자리는 2의 거듭제곱만큼의 가중치를 가지며, 켜진(1) 자리의 가중치를 더하면 그 옥텟의 값이 됩니다.

비트:    1    1    0    0    0    0    0    0
가중치: 128   64   32   16    8    4    2    1
값:     128 + 64 = 192

기억해 둘 점은, IP 주소는 더하거나 곱하는 수량이 아니라 식별자라는 것입니다. 우편번호처럼, 같은 네트워크 안에서 서로 겹치지 않게 구분하는 역할을 합니다. 이 비트 단위 관점은 다음 레슨의 CIDR·서브넷 계산에서 다시 쓰입니다.