DNS

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

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

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

DNS와 CDN은 둘 다 사용자가 서비스에 도달하는 경로에 등장하지만 맡는 역할은 다릅니다. DNS는 이름을 실제 목적지 정보로 바꾸는 해석 계층이고, CDN은 그 다음 단계에서 사용자와 가까운 위치에서 콘텐츠를 전달하거나 원본 접근을 줄이는 전달 계층입니다. DNS는 '어디로 갈지'를 정하고, CDN은 '그 목적지에서 어떻게 더 빠르고 안정적으로 줄지'를 다룹니다. DNS만으로는 지리적 캐시가 생기지 않고, CDN만으로는 사용자가 어느 엣지로 가야 할지 결정할 수 없습니다. 실제로 CDN은 DNS를 이용해 사용자를 가장 가까운 엣지로 안내하는 방식으로 두 가지가 함께 동작합니다.

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