2026년 4월 8일 오전 10시 30분(EDT)에 게시됨
Roine Bertelson은 스톡홀름에 거주하는 기술 작가, 번역가 및 디지털 전략가로서 AI 도구, Linux, 소비자 기술, 사이버 보안 및 SEO 기반 콘텐츠 분야에서 20년 이상의 실무 경험을 보유하고 있습니다. 그는 복잡한 주제를 독자가 실제 문제를 해결하는 데 도움이 되는 명확하고 실용적인 지침으로 바꾸는 것으로 유명합니다. 사람들은 그가 쓴 도구를 실제로 사용 및 테스트하고, 의도적으로 문제를 해결하고, 현대 기술의 혼란을 인간적이고 정직하며 유용하다고 느껴지는 조언으로 변환하기 때문에 그의 작업을 신뢰합니다.
내 속도 테스트는 잘난척하고 녹색으로 나타났습니다. 다운로드가 빨랐습니다. YouTube는 내가 적극적으로 깨려고 시도하지 않는 한 버퍼링되지 않았습니다. 서류상으로 내 연결은 Reddit 스레드에서 자랑할 만한 것으로 보였습니다. 그럼에도 불구하고... 페이지를 열 때마다 거기에 있었습니다. 그 작고 짜증나는 멈춤. 로딩 바, 스피너, 안심할 수 있는 활동 깜박임이 없습니다. 커밋하기 전에 인터넷이 자체적으로 수집되어야 하는 것처럼 아무것도 없는 이상한 0.5초입니다. 불평할 만큼 길지는 않았지만, 느낄 수 있을 만큼 길었다.
그런 종류의 지연은 벤치마크에 나타나지 않습니다. 그것은 다른 곳에 산다. 근육 기억 속에, 기대 속에, 그리고 그 미묘한 '왜 기분이 안 좋을까?' 100번째 탭 이후부터 시작됩니다. 나는 모두가 하는 일을 했다. 브라우저를 비난했습니다. 탭을 닫았다가 다시 열었습니다. 항상 약간의 죄책감이 있기 때문에 비발디를 다시 비난하는 것을 고려했습니다. 하지만 이것은 RAM도 아니고, CPU도 아니고, 연결 자체도 아니었습니다. DNS는 다른 어떤 일이 시작하기도 전에 조용히 발을 끌었습니다.
실제로 로드가 시작되기 전에 모든 것이 느리게 느껴지는 이유
그 보이지 않는 지연은 대역폭이 아니라 조회 시간이었습니다
웹사이트가 로드되기 전에 시스템은 매우 기본적인 질문을 해야 합니다. '이게 어디에 있지?' 해당 질문은 DNS 확인자에게 전달됩니다. 이는 도메인 이름과 같은 인간의 것을 시스템이 실제로 연결할 수 있는 것으로 변환합니다. 그리고 그 질문에 대한 답이 나올 때까지 아무 일도 일어나지 않습니다. 콘텐츠 로드가 시작되지 않고, 스크립트가 실행되지 않으며, 이미지가 표시되지 않습니다. 모든 것이 거기에 앉아서 DNS가 작업을 마칠 때까지 정중하게 기다리고 있습니다.
그 단계가 조금이라도 느리면 전체 경험이 주저하게 느껴집니다. 깨지진 않았는데, 그냥… 확실하지 않아요. Mint 및 Ubuntu 기반 설정을 포함한 대부분의 Linux 시스템은 기본적으로 ISP가 제공하는 DNS를 사용합니다. 이는 약간 찌그러진 장바구니가 여전히 굴러가는 것과 같은 방식으로 작동합니다.
하지만 이러한 서버가 항상 빠른 것은 아닙니다. 항상 가까이 있지는 않습니다. 그리고 현대의 공개 해석기처럼 응답성이 최적화되는 경우는 거의 없습니다. 따라서 모든 새로운 요청에는 약간의 망설임이 포함됩니다. 비명을 지를 만큼은 아니지만 한숨을 쉬기에 충분합니다.
퀴즈
8가지 질문 · 지식 테스트
MUO DNS 및 네트워킹 챌린지
인터넷이 왜 주저하는지 아시나요? DNS 및 네트워킹 지식을 시험해 보세요.
DNS네트워킹프로토콜보안성능
시작
DNS는 무엇을 의미하나요?
A데이터 네트워크 서비스B동적 이름 시스템C도메인 이름 시스템D디지털 노드 서버
맞습니다! DNS는 도메인 이름 시스템을 의미합니다. 이는 인터넷의 전화번호부처럼 작동하여 'google.com'과 같은 인간 친화적인 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환하여 브라우저가 연결할 위치를 알 수 있도록 합니다.
정답은 아닙니다. 대답은 도메인 이름 시스템입니다. DNS는 우리가 방문하는 모든 사이트에 대해 192.168.1.1과 같은 일련의 숫자를 기억하지 않고 웹을 탐색하는 방법의 중추입니다.
계속
컴퓨터가 웹사이트를 로드하기 전에 도메인 이름을 찾아야 할 때 발생하는 지연을 의미하는 용어는 무엇입니까?
A대기시간 스파이크BDNS 조회 시간C패킷 손실D핸드셰이크 지연
맞습니다! DNS 조회 시간은 도메인 이름을 IP 주소로 확인하기 위해 DNS 서버에 쿼리하는 동안 장치가 경험하는 지연입니다. Cloudflare(1.1.1.1) 또는 Google(8.8.8.8)과 같은 더 빠른 DNS 공급자로 전환하면 이러한 일시 중지를 크게 줄일 수 있습니다.
정답은 아닙니다. 대답은 DNS 조회 시간입니다. 이는 이름 확인 프로세스로 인해 발생하는 특정 지연입니다. 대기 시간 및 패킷 손실은 실제 네트워킹 문제이지만 초기 도메인 조회 일시 중지와는 다른 문제를 나타냅니다.
계속
다음 중 Cloudflare의 기본 공용 DNS 확인자 IP 주소는 무엇입니까?
A8.8.8.8B9.9.9.9C1.1.1.1D208.67.222.222
맞습니다! Cloudflare의 기본 DNS 확인자는 개인정보 보호와 속도에 중점을 두고 2018년에 출시된 1.1.1.1입니다. 지속적으로 세계에서 가장 빠른 DNS 확인자 중 하나로 평가되며 광고 목적으로 쿼리 데이터를 기록하지 않습니다.
정답은 아닙니다. 정답은 Cloudflare에 속한 1.1.1.1입니다. 기록에 따르면 8.8.8.8은 Google의 DNS, 9.9.9.9는 Quad9, 208.67.222.222는 OpenDNS입니다. 모두 ISP의 기본 DNS에 대한 합법적인 대안입니다.
계속
암호화되지 않은 표준 DNS 트래픽은 일반적으로 어떤 포트를 사용합니까?
A포트 80B포트 443C포트 25D포트 53
맞습니다! DNS는 기본적으로 포트 53에서 작동하며 빠른 쿼리에는 UDP를, 대규모 응답이나 영역 전송에는 TCP를 모두 사용합니다. 이는 네트워킹의 가장 기본적인 포트 번호 중 하나이며 방화벽 및 보안 구성에 자주 나타납니다.
정답은 아닙니다. DNS는 포트 53을 사용합니다. 포트 80은 HTTP, 포트 443은 HTTPS, 포트 25는 이메일용 SMTP입니다. 방화벽을 구성하거나 네트워크 문제를 해결하려면 이러한 표준 포트 할당을 아는 것이 필수적입니다.
계속
사용자를 악성 웹사이트로 리디렉션하기 위해 DNS 확인자의 캐시를 손상시키는 공격 유형은 무엇입니까?
ADNS 터널링BDNS 스푸핑CARP 중독DBGP 하이재킹
맞습니다! DNS 캐시 중독이라고도 불리는 DNS 스푸핑에는 확인자의 캐시에 잘못된 DNS 레코드를 삽입하여 사용자가 이를 인지하지 못한 채 공격자가 제어하는 사이트로 리디렉션되도록 하는 작업이 포함됩니다. DNSSEC(DNS 보안 확장)는 이러한 위협을 방어하기 위해 특별히 개발되었습니다.
정답은 아닙니다. 대답은 DNS 스푸핑(또는 캐시 중독)입니다. DNS 터널링은 DNS 쿼리를 사용하여 데이터를 밀수하고, ARP 중독은 로컬 네트워크 트래픽을 표적으로 삼으며, BGP 하이재킹은 훨씬 더 큰 규모로 인터넷 라우팅에 영향을 미칩니다. 캐시 중독은 특히 DNS 확인 프로세스를 표적으로 삼는 공격입니다.
계속
DNS TTL 값은 무엇에 사용되나요?
AI는 DNS 패킷이 이동할 수 있는 최대 홉 수를 설정합니다. BI는 DNS 레코드가 새로 고쳐지기 전에 캐시되는 기간을 정의합니다. CI는 서버가 처리할 수 있는 동시 DNS 쿼리 수를 제한합니다. DI는 서버와 클라이언트 간의 DNS 응답을 암호화합니다.
맞습니다! TTL은 Time To Live를 의미하며 DNS에서는 확인자가 다시 쿼리해야 하기 전에 확인된 레코드를 캐시에 저장해야 하는 시간(초)을 지정합니다. TTL이 낮다는 것은 변경 사항이 더 빠르게 전파된다는 것을 의미합니다. TTL이 높으면 DNS 쿼리 로드가 줄어들지만 업데이트 속도가 느려집니다.
정답은 아닙니다. DNS의 TTL은 홉, 쿼리 제한 또는 암호화가 아닌 레코드의 캐시 수명을 정의합니다. 흥미롭게도 IP 패킷에도 TTL 필드가 있지만 네트워크 홉을 계산하는데, 이는 동일한 용어가 각 상황에서 다른 의미를 갖기 때문에 혼동의 일반적인 원인이 됩니다.
계속
도메인 이름을 IPv6 주소에 매핑하는 역할을 하는 DNS 레코드 유형은 무엇입니까?
AA 레코드BCNAME 레코드CAAAA 레코드DMX 레코드
맞습니다! AAAA 레코드('쿼드-A'로 발음)는 도메인 이름을 128비트 IPv6 주소에 매핑합니다. 표준 A 레코드는 IPv4 주소를 처리하는 반면 CNAME은 별칭 레코드이고 MX 레코드는 이메일 트래픽을 적절한 메일 서버로 전달합니다.
그렇지 않습니다. IPv6 주소는 AAAA 레코드에 저장됩니다. A 레코드는 IPv4를 처리하고 CNAME은 도메인 별칭을 생성하며 MX 레코드는 메일 라우팅을 처리합니다. IPv6 채택이 증가함에 따라 AAAA 레코드가 DNS 구성에서 점점 더 중요해지고 있습니다.
계속
원래 1983년 DNS 사양(RFC 882)에서 DNS가 존재하기 전에 호스트 이름을 확인하는 데 무엇이 사용되었으며 모든 최신 운영 체제에 여전히 존재합니까?
AWINS(Windows 인터넷 이름 서비스)BHOSTS 파일CNIS(네트워크 정보 서비스)DNetBIOS 브로드캐스트
맞습니다! DNS 이전에는 중앙에서 관리되는 HOSTS.TXT 파일이 ARPANET의 모든 컴퓨터에 배포되었습니다. OS는 DNS에 쿼리하기 전에 여전히 로컬 호스트 파일(Linux/Mac의 경우 /etc/hosts, Windows의 경우 C:\Windows\System32\drivers\etc\hosts에 있음)을 확인합니다. 따라서 이 파일을 사용하여 웹사이트를 차단하거나 로컬에서 DNS를 재정의할 수 있습니다.
정답은 아닙니다. 대답은 DNS보다 먼저 존재하는 일반 텍스트 파일인 HOSTS 파일입니다. 모든 최신 OS에서 이름 확인 과정에서 여전히 먼저 확인되기 때문에 악성 코드가 때때로 트래픽을 가로채기 위해 이를 수정하고, 숙련된 사용자가 DNS 설정을 건드리지 않고 광고를 차단하거나 특정 도메인을 무시하도록 편집하는 이유도 있습니다.
내 점수 보기
도전 완료
당신의 점수
/ 8
플레이해주셔서 감사합니다!
다시 시도해 보세요
클릭한 순간
느린 시작과 빠른 인터넷은 매우 특정한 종류의 짜증나는 일입니다.
마침내 나를 넘어뜨린 것은 실패가 아니었습니다. 일관성이었습니다. 페이지가 로드되기 시작하면 페이지가 날아갔습니다. 불만이 없습니다. 지연이 없습니다. 마치 모든 것이 완벽하게 작동하는 것처럼 제자리에 고정되었습니다. 그러나 그 지점에 도달하는 것은 마치 문을 두드리고 누군가가 응답할 때까지 너무 오래 기다리는 것과 같았습니다. 그래서 나는 약간 강박적인 방식으로 주의를 기울이기 시작했습니다. 같은 사이트를 반복적으로 열었습니다. 첫 번째 로드를 새로 고침과 비교했습니다. 캐시된 페이지가 새로운 요청에 비해 어떻게 작동하는지 관찰했습니다.
캐시된 페이지는 즉각적이었습니다. 공격적으로 즉각적입니다. 새로운 요청이 있으신가요? 매번 똑같은 어색한 멈춤. 그때부터 그것은 막연한 성가심을 멈추고 패턴처럼 보이기 시작했습니다. 그리고 DNS는 이러한 패턴에 완벽하게 들어맞습니다. 한번 본 후에는 볼 수 없었습니다. 클릭할 때마다 먼저 목을 비워야 하는 것처럼 느껴졌습니다.
DNS 전환으로 망설임이 즉시 제거되었습니다
더 나은 해결 프로그램은 작업을 더 빠르게 만드는 것이 아니라 올바른 느낌을 갖게 합니다
ISP의 DNS에서 전환하고 몇 가지 잘 알려진 공개 확인자를 테스트했습니다.
- Cloudflare(1.1.1.1)
- 구글 DNS(8.8.8.8)
- Quad9(9.9.9.9)
큰 행사는 없습니다. 시스템 점검이 없습니다. 네트워크 설정을 조용히 변경하고 다시 연결하면 됩니다. 그리고 그 차이는 거의 짜증스러울 정도로 즉각적이었습니다. 페이지가 더 이상 일시 중지되지 않았습니다. 방금 열었어요. 새 탭이 협상처럼 느껴지지 않았습니다. 링크는 내가 클릭하는 순간 응답했습니다. 모든 상호작용에 조용히 살고 있던 그 이상한 마이크로 딜레이가 방금 사라졌습니다. 동일한 시스템, 동일한 브라우저, 모든 것이 동일합니다.
그러나 전체 경험이 더 단단해졌습니다. 더 자신감을 가지세요. 인터넷이 마침내 망설임을 멈추기로 결정한 것처럼. 어디에서도 극적으로 나타나지 않는 변경 사항 중 하나이지만, 일단 알아차리면 시스템이 갑자기 커밋 문제를 일으킨 것처럼 다시 돌아가는 느낌이 듭니다.
Journald는 무시할 수 없는 행동을 만들었습니다
실시간으로 DNS 쿼리를 보는 것은 감정을 증거로 바꿉니다
이 시점에서 나는 단지 개선을 느끼고 싶지 않았습니다. 그 모습을 현장에서 포착하고 싶었어요. 그래서 저는 저널링을 선택했습니다. Linux 시스템에서 어떤 일이 발생하면 대개 어딘가에서 그에 대해 이야기하기 때문입니다.
systemd-resolved를 사용하는 시스템에서는 DNS 쿼리를 실시간으로 볼 수 있습니다:
journalctl -u systemd-resolved -f DNS를 전환하기 전에는 패턴이 명확했습니다. 쿼리가 들어오고 잠시 멈췄다가 해결됩니다. 극적인 것은 없고 단지 시간이 지남에 따라 약간 느린 반응이 쌓일 뿐입니다. 전환 후 모든 것이 조여졌습니다. 이상한 지연과 왕복 횟수가 줄어들어 요청이 더 빠르게 해결됩니다. 시스템이 더 이상 스스로를 추측하지 않는 것처럼 더 깔끔하고 단호해 보였습니다. 그리고 그것은 매우 만족스러운 부분입니다.
이것은 기분이 좋아졌다고 스스로 확신하는 조정 중 하나가 아니었습니다. 로그가 그것을 백업했습니다. 실제로 관찰할 수 있는 방식으로 행동이 변경되었습니다. 이로 인해 모든 것이 조정이라기보다는 처음부터 그렇게 느려서는 안 될 것을 고치는 것 같은 느낌이 들었습니다.
관련
라우터와 컴퓨터 DNS 설정:더 빠른 설정은 다음과 같습니다.
라우터 수준과 PC 수준의 DNS를 비교한 결과 네트워크 속도와 성능이 실질적으로 향상되었습니다.
매번 원시 속도를 쫓는 마찰을 제거하는 것이 좋습니다
이것은 연결을 최대화하는 것이 아닙니다. 다운로드 속도가 갑자기 두 배로 늘어나지는 않습니다. 속도 테스트 결과가 자랑거리로 바뀌지는 않습니다. 대역폭 변경에 관한 내용은 없습니다. 변화하는 것은 모든 것이 시작되는 방식입니다. 그리고 그것이 대부분의 경험이 살아가는 곳입니다. 우리는 대용량 파일을 다운로드하는 데 하루를 보내지 않습니다. 클릭합니다. 우리는 탐색합니다. 탭 사이를 이동합니다. 우리는 의식적으로 생각하는 것보다 더 빠르게 링크를 따라갑니다.
이러한 모든 작업이 시작되기 전에 약간의 지연이 발생하면 합산되어 예상보다 무겁게 느껴집니다. 드라마틱하지 않아요. 대부분의 도구가 관심을 갖는 방식으로는 측정할 수 없습니다. 그러나 이는 시스템의 느낌에 절대적으로 영향을 미칩니다. DNS를 전환하면 이러한 망설임이 사라집니다. 모든 것이 다시 즉각적으로 느껴지게 만듭니다. 반응형. 예측 가능합니다. 그리고 일단 그 마찰이 사라지면 다시 돌아오기가 매우 어렵습니다. 이제 당신은 인터넷 속도가 느린 것이 결코 아니라는 것을 알고 있기 때문입니다. 아주 간단한 질문에 다른 사람이 대답하기를 기다리는 것뿐이었습니다.