DNS

사용자는 example.com 같은 이름은 기억하지만 93.184.216.34 같은 숫자는 기억하지 못합니다. 더 큰 문제는 서비스가 이전되거나 인프라가 바뀌면 IP 주소는 언제든지 바뀔 수 있다는 점입니다. 이름과 주소가 코드나 설정에 직접 박혀 있으면 변경이 생길 때마다 모든 클라이언트와 시스템 설정을 다시 고쳐야 합니다. 서버 수가 늘고 지역이 분산되면 이 문제는 단순한 기억의 불편을 넘어 운영의 복잡성으로 바뀝니다. 수많은 이름과 주소 대응을 중앙 파일 하나에 적어 두는 방식은 규모가 커지는 순간 깨집니다.

인터넷 초기에 호스트 이름은 HOSTS.TXT 파일 같은 중앙 목록으로 관리했습니다. 스탠포드 연구소가 이 파일을 주기적으로 배포했고, 연결된 장치가 수백 대일 때는 가능한 방식이었습니다. 그러나 연결 장치가 수천, 수만 대로 늘어나자 누가 최신 목록을 갖고 있는지 보장하기 어려웠고 갱신 자체가 병목이 됐습니다. 1983년 DNS가 도입된 이유는 이 확장성 문제를 해결하기 위한 것이었습니다. 계층적 권한 위임과 분산 조회 구조 덕분에 어떤 중앙 서버도 전체 목록을 갖고 있을 필요가 없어졌습니다. 오늘날 클라우드, 이메일, 서비스 디스커버리, 글로벌 트래픽 제어가 모두 DNS 위에 기대는 것은 이름을 인프라 변화와 분리하는 이 구조가 매우 강력하기 때문입니다.

브라우저나 애플리케이션이 도메인 이름을 만나면 먼저 재귀 리졸버에 질의합니다. 리졸버는 캐시에 없으면 루트 서버에 묻고, 루트 서버는 TLD 서버 위치를 알려주고, TLD 서버는 권한 네임서버 위치를 알려줍니다. 권한 네임서버가 마침내 실제 IP 주소를 돌려주면, 리졸버는 그 결과를 TTL만큼 캐시에 저장합니다. 이 과정은 대부분 수십 밀리초 안에 끝납니다. TTL이 중요한 이유는 캐시가 얼마나 오래 이전 답을 믿을지 결정하기 때문입니다. TTL을 300초로 설정했다면 변경 후 최대 5분간은 일부 클라이언트가 예전 IP로 접속을 시도할 수 있습니다.

DNS와 IP는 역할이 다릅니다. IP는 패킷이 실제로 향하는 숫자 주소이고, DNS는 사람이 쓰는 이름을 그 주소로 바꾸는 해석 계층입니다. 이름 없이 IP만 쓰면 운영이 경직되고, IP 없이 DNS만 있으면 패킷은 목적지를 찾지 못합니다. DNS와 DHCP는 둘 다 설정 자동화처럼 보이지만 판단 기준이 다릅니다. DHCP는 장치가 네트워크에 붙을 때 IP, 게이트웨이, DNS 서버 주소 같은 출발에 필요한 설정을 배정하고, DNS는 그 설정을 바탕으로 목적지 이름을 어디로 보낼지 찾습니다. 장치의 접속 성립이 문제면 DHCP, 서비스 이름 해석이 문제면 DNS를 봐야 합니다. DNS와 ARP는 모두 해석이지만 범위가 다릅니다. DNS는 인터넷 전체에서 도메인 이름을 IP로 바꾸고, ARP는 같은 LAN 안에서 IP를 MAC으로 바꿉니다. DNS 장애는 이름 해석 실패로, ARP 장애는 같은 서브넷 안의 장치에만 닿지 않는 증상으로 드러납니다.

DNS는 웹사이트 연결, 이메일 라우팅, 내부 서비스 이름 관리, 로드 밸런서와 CDN 연결처럼 주소를 직접 노출하지 않고 인프라를 운영해야 하는 곳이라면 어디서나 쓰입니다. 운영에서는 레코드 타입을 외우는 것보다 TTL과 캐시 전파 시간을 감안해 변경 작업을 계획하는 감각이 더 중요합니다. 장애 조치나 인프라 이전을 준비할 때 TTL을 미리 300초 이하로 줄여 두지 않으면, 설정은 바꿨는데 사용자 일부는 여전히 예전 목적지로 가는 상황이 생깁니다. DNS를 잘 쓴다는 것은 이름을 예쁘게 붙이는 일이 아니라, 변화하는 인프라를 사용자에게 끊김 없이 숨기는 운영 기술에 가깝습니다.