DNS의 원리와 TTL: 도메인 변경 시 전파가 느린 이유

 서버 이전 후 변경된 도메인 정보가 바로 반영되지 않는 이유는 무엇일까요? DNS 작동 원리와 캐싱, 그리고 전파 시간을 결정하는 TTL(Time To Live)의 개념을 완벽하게 정리해 드립니다.


"어제 서버를 옮겼는데, 왜 아직도 옛날 사이트가 보이죠?"

웹사이트 운영자나 개발자가 호스팅을 이전하거나 서버 IP를 변경했을 때 가장 많이 겪는 당혹스러운 상황이 있습니다. 분명 설정을 다 바꿨는데, 내 컴퓨터에서는 새 사이트가 뜨고 옆자리 동료의 컴퓨터에서는 여전히 옛날 사이트가 뜨는 현상입니다. 심지어 모바일에서는 접속조차 안 되기도 합니다.

이 미스터리한 현상의 범인은 바로 DNS(Domain Name System)의 작동 방식과 TTL(Time To Live)이라는 설정 때문입니다. 인터넷 주소록이 어떻게 업데이트되는지, 그리고 왜 전 세계에 퍼지는 데 시간이 걸리는지 그 원리를 알기 쉽게 파헤쳐 보겠습니다.


1. DNS의 기본 원리: 인터넷의 거대한 전화번호부

우리가 인터넷을 할 때 google.com이나 naver.com 같은 문자로 된 도메인 이름을 입력합니다. 하지만 컴퓨터는 숫자로 된 IP 주소(예: 192.168.1.1)만 이해할 수 있습니다.

이때 DNS는 우리가 입력한 도메인 주소를 컴퓨터가 이해하는 IP 주소로 변환해 주는 역할을 합니다. 마치 스마트폰 전화번호부에서 친구 이름(도메인)을 검색하면 실제 전화번호(IP)를 찾아 연결해 주는 것과 같습니다. 이 변환 과정을 'DNS 조회(Lookup)'라고 합니다.


2. 속도의 비결이자 지연의 원인, 'DNS 캐시(Cache)'

만약 우리가 네이버에 접속할 때마다 전 세계 어딘가에 있는 DNS 서버에 "네이버 IP가 뭐였지?"라고 매번 물어본다면 어떻게 될까요? 인터넷 속도는 끔찍하게 느려지고, DNS 서버는 과부하로 다운될 것입니다.

이를 방지하기 위해 컴퓨터와 네트워크 장비들은 한 번 알아낸 IP 주소를 일정 시간 동안 기억해 둡니다. 이를 DNS 캐시(DNS Cache)라고 합니다.

  • 브라우저 캐시: 크롬, 사파리 등 웹 브라우저가 자체적으로 저장.
  • OS 캐시: 윈도우, 맥OS 등 운영체제가 저장.
  • ISP 캐시: 통신사(KT, SKT, LG U+)의 DNS 서버가 저장.

문제는 도메인 IP를 변경했을 때 발생합니다. 나는 정보를 바꿨지만, 사용자의 컴퓨터나 통신사는 여전히 "내가 기억하고 있는 옛날 주소가 맞아"라며 자신의 캐시에 저장된 옛날 IP로 접속을 시도하기 때문입니다. 이것이 변경 사항이 즉시 반영되지 않는 핵심 이유입니다.


3. 유효기간의 설정, TTL(Time To Live)

그렇다면 캐시는 언제까지 옛날 정보를 기억하고 있을까요? 이 유효기간을 결정하는 값이 바로 TTL(Time To Live)입니다.

TTL은 '데이터가 살아있는 시간'을 초(Second) 단위로 설정합니다. 도메인 관리자(네임서버)가 설정할 수 있으며, 이 시간이 지나야만 캐시가 만료되고 새로운 정보를 다시 받아옵니다.

  • TTL이 3600(1시간)인 경우: 사용자가 한 번 접속하면 1시간 동안은 다시 묻지 않고 저장된 정보를 씁니다. 즉, 도메인을 변경해도 최대 1시간 동안은 변경 전 사이트로 접속될 수 있습니다.
  • TTL이 86400(24시간)인 경우: 변경 사항이 반영되기까지 최대 하루가 걸립니다.


4. 도메인 전파(Propagation): 전 세계로 퍼지는 시간

도메인 정보를 변경하면 이 정보가 전 세계의 모든 네임서버에 업데이트되는 과정을 '전파(Propagation)'라고 부릅니다. 보통 짧게는 수 시간에서 길게는 48시간(2일)까지 걸린다고 말하는 이유가 여기에 있습니다.

내가 사용하는 통신사(ISP)의 DNS 서버는 업데이트되었어도, 해외 사용자가 쓰는 구글 DNS(8.8.8.8)는 아직 업데이트되지 않았을 수 있습니다. 각 DNS 서버마다 설정된 캐시 갱신 주기가 제각각이기 때문에, 지구 반대편까지 정보가 도달하는 데 물리적인 시간이 소요되는 것입니다.


5. 서버 이전 시 다운타임을 줄이는 꿀팁

서버 이전을 앞두고 있다면 TTL을 전략적으로 조절하여 접속 불가 시간(Downtime)을 최소화할 수 있습니다.

  1. 이전 하루 전: 현재 도메인의 TTL 값을 300초(5분) 이하로 매우 짧게 줄입니다. 이렇게 하면 전 세계 DNS 서버들이 내 도메인 정보를 5분마다 갱신하게 됩니다.
  2. 이전 당일: DNS 레코드의 IP 주소를 새로운 서버로 변경합니다. TTL이 짧기 때문에 대부분의 사용자가 5분 내에 새로운 IP를 받아 가게 됩니다.
  3. 이전 완료 후: 안정화가 확인되면 TTL 값을 다시 3600초(1시간) 이상으로 늘려 DNS 조회 부하를 줄여줍니다.


기다림은 버그가 아닙니다

도메인 변경 후 사이트가 바로 뜨지 않는 것은 오류가 아니라, 인터넷 전체의 효율성을 위해 설계된 캐싱 시스템의 자연스러운 현상입니다.

TTL은 '신선도 유지 기간'과 같습니다. 너무 짧게 잡으면 서버가 힘들어하고, 너무 길게 잡으면 정보 갱신이 느려집니다. 평소에는 TTL을 넉넉하게(1시간~1일) 유지하여 안정성을 높이고, 변경 작업이 있을 때만 전략적으로 줄이는 것이 스마트한 서버 관리의 핵심입니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

VPC 네트워크 설계: 서브넷(Subnet)을 퍼블릭/프라이빗으로 나누는 기준

  클라우드 보안의 시작, 네트워크 격리 클라우드 인프라를 구축할 때 가장 먼저 마주하는 용어 중 하나가 바로 VPC(Virtual Private Cloud) 입니다. VPC는 클라우드 내에 만드는 우리만의 가상 데이터 센터입니다. 하지만 단순히 VPC를 만들었다고 끝이 아닙니다. 이 거대한 공간을 어떻게 쪼개고(Subnetting), 어떤 용도로 사용할지 결정하는 것이 보안과 효율성을 좌우합니다. 많은 초보 설계자가 범하는 실수는 모든 리소스를 인터넷에 노출된 하나의 서브넷에 몰아넣는 것입니다. 이는 마치 현관문 없이 금고를 길거리에 두는 것과 같습니다. 오늘은 안전하고 튼튼한 인프라를 위해 서브넷을 퍼블릭(Public)과 프라이빗(Private)으로 나누는 결정적 기준을 알아보겠습니다. 1. 서브넷 분리의 핵심 원리: 라우팅 테이블과 인터넷 게이트웨이 퍼블릭과 프라이빗을 나누는 기준은 물리적인 위치가 아닙니다. 바로 ' 인터넷과 직접 통신할 수 있는가?' 입니다. 이를 기술적으로 결정하는 것은 라우팅 테이블(Routing Table) 설정입니다. 퍼블릭 서브넷: 라우팅 테이블이 인터넷 게이트웨이(IGW, Internet Gateway) 를 향해 열려 있습 니다. 외부에서 들어오는 트래픽을 직접 받을 수 있고, 내부에서 밖으로 나갈 수도 있습니다. 프라이빗 서브넷: 인터넷 게이트웨이로 가는 경로가 없습니다. 외부에서 직접 접근할 수 없으며, 내부IP(Private IP)로만 통신합니다. 2. 퍼블릭 서브넷(Public Subnet): 외부와 소통하는 접점 퍼블릭 서브넷은 외부 사용자의 요청을 가장 먼저 받아내는 '안내 데스크' 역할을 합니다. 따라서 반드시 외부 인터넷 접근이 필요한 리소스 만 이곳에 배치해야 합니다. 퍼블릭 서브넷 배치 기준 로드 밸런서 (Load Balancer, ALB/NLB): 사용자의 트래픽을 받아 뒷단의 서버로 분산시켜주는 역할을 하므로 반드시 공인 IP를 가지고 외부에 노출되어야...
자세한 내용 보기

온프레미스 vs 클라우드: 인프라 아키텍처의 결정적 차이 5가지

기업의 운명을 가르는 선택, 인프라 아키텍처 디지털 전환(DX)이 가속화되면서 모든 기업은 중요한 기로에 서 있습니다. 바로 "데이터와 시스템을 어디에 둘 것인가?"라는 질문입니다. 과거에는 회사 내부에 서버실을 구축하는 것이 당연했지만, 이제는 클라우드가 강력한 대안으로 자리 잡았습니다. 하지만 무조건적인 클라우드 전환이 정답은 아닙니다. 이 글에서는 IT 인프라의 두 축인 온프레미스(On-Premise) 와 클라우드(Cloud) 의 개념을 명확히 하고, 의사 결정에 꼭 필요한 5가지 결정적 차이를 분석해 드립니다. 1. 개념의 차이: 소유할 것인가, 빌려 쓸 것인가? 본격적인 비교에 앞서 두 개념을 가장 쉽게 이해하는 방법은 '부동산'에 비유하는 것입니다. 온프레미스(On-Premise): 직접 땅을 사고 집을 짓는 '자가 주택'과 같습니다. 하드웨어부터 네트워크, 운영체제까지 기업이 직접 구매하여 사내 전산실이나 데이터 센터 에 구축하고 운용합니다. 모든 통제권이 나에게 있습니다. 클라우드(Cloud): 필요한 만큼 공간을 빌려 쓰는 '호텔'이나 '공유 오피스'와 같습니다. AWS, Azure, Google Cloud 같은 공급자가 구축해 둔 거대한 인프라 자원을 인터넷을 통해 필요한 만큼 빌려 쓰고, 쓴 만큼 비용을 지불합니다. 2. 비용 구조: 초기 투자비용(CAPEX) vs 운영 비용(OPEX) 가장 큰 차이는 돈을 쓰는 방식에 있습니다. 온프레미스: 초기 투자 중심 (CAPEX) 온프레미스는 시스템 구축 초기에 막대한 자본적 지출(CAPEX)이 발생합니다. 서버, 스토리지, 네트워크 장비를 직접 구매해야 하며, 이를 설치할 공간과 전력, 냉각 시스템도 갖춰야 합니다. 구축 후에는 감가상각을 통해 비용을 처리합니다. 장기적으로 시스템 변경이 거의 없다면 총비용 면에서 유리할 수 있습니다. 클라우드: 운영 비용 중심 (OPEX) 클라우드는 초기 구축비...
자세한 내용 보기

로드 밸런서(ELB/ALB)의 알고리즘: 라운드 로빈 vs 리스트 커넥션

  트래픽 폭주, 서버가 버티는 비결 웹 서비스 운영 중 사용자가 급격히 늘어날 때, 단 한 대의 서버로는 모든 요청을 처리할 수 없습니다. 이때 등장하는 구세주가 바로 로드 밸런서(Load Balancer) 입니다. AWS의 ELB(Elastic Load Balancing)나 ALB(Application Load Balancer)가 대표적인 예입니다. 로드 밸런서는 들어오는 트래픽을 여러 대의 서버(EC2 등)에 골고루 나눠주는 교통경찰 역할을 합니다. 하지만 무턱대고 나누는 것이 아닙니다. ' 어떤 규칙'으로 나눌 것인가 에 따라 서비스의 안정성과 속도가 완전히 달라집니다. 오늘은 가장 대표적인 두 가지 알고리즘, 라운드 로빈(Round Robin) 과 리스트 커넥션(Least Connection) 을 비교 분석해 봅니다. 1. 라운드 로빈(Round Robin): 공평하게 순서대로 가장 기본적이고 직관적인 방식입니다. ' 순차적 분산' 이라고도 부릅니다. 작동 원리 마치 카드 게임에서 딜러가 플레이어들에게 카드를 한 장씩 순서대로 나눠주는 것과 같습니다. 서버가 A, B, C 세 대가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C, 네 번째는 다시 A에게 보냅니다. 현재 서버의 상태나 부하량은 고려하지 않고 오직 순서 에만 입각해 트래픽을 배분합니다. 장점 단순함: 구현이 매우 쉽고 이해하기 편합니다. 리소스 소모 적음: 로드 밸런서가 복잡한 계산을 할 필요가 없어 자체 부하가 적습니다. 동일 환경에 유리: 모든 서버의 스펙이 동일하고, 처리해야 할 요청의 성격(처리 시간)이 비슷할 때 가장 효율적입니다. 단점 부하 불균형: 어떤 요청은 1초 만에 끝나지만, 어떤 요청은 1분이 걸릴 수 있습니다. 라운드 로빈은 이를 무시하고 계속 요청을 보내기 때문에, 운 나쁘게 무거운 작업만 할당받은 특정 서버가 과부하로 뻗어버릴 수 있습니다. 2. 리스트 커넥션(Least Con...
자세한 내용 보기