앞 편에서 주소창에 입력한 문자열이 완전한 주소로 해석되는 과정을 훑었다. 해석이 끝나 손에 쥔 것은 호스트 이름이지만, 통신망 위의 장치들은 이름으로 서로를 찾지 않는다. 그래서 브라우저는 실제 통신을 시작하기 전에 이 이름을 숫자로 된 주소로 바꾸는 절차를 반드시 거친다. 이번 편은 그 번역, 곧 이름 조회가 어떤 경로로 이루어지고 왜 어떤 때는 순식간에 끝나며 어떤 때는 눈에 띄게 느린지를 다룬다.
이름 조회는 눈에 전혀 보이지 않지만 사이트가 처음 뜨는 속도에 큰 몫을 차지한다. 화면이 늦게 뜨는 원인을 찾을 때 이 단계를 빠뜨리면 엉뚱한 곳만 뒤지게 된다. 조회의 구조와 캐시의 계층, 유효기간의 의미를 알아 두면, 어떤 사이트가 열리지 않을 때 그것이 이름을 못 찾은 것인지 찾고도 연결이 안 되는 것인지를 구분하는 눈이 생긴다.
이름을 숫자로 번역하는 체계
사람에게는 의미가 담긴 이름이 편하지만, 통신망 위의 장치는 숫자로 된 주소를 기준으로 서로를 찾는다. 그래서 브라우저가 어떤 서버에 접속하려면 먼저 그 서버의 이름에 대응하는 숫자 주소를 알아내야 한다. 이 대응표는 한 곳이 통째로 관리하기에는 너무 방대하므로, 전 세계가 나눠 관리하는 거대한 이름 체계가 그 일을 맡는다.
이 체계의 핵심 설계는 책임을 한 곳에 몰지 않고 여러 단계로 나눈다는 점이다. 최상위를 관리하는 곳이 있고, 그 아래 특정 종류의 이름을 맡는 곳이 있으며, 다시 그 아래 개별 이름을 실제로 책임지는 곳이 있다. 이렇게 계층으로 나눈 덕분에 어느 한 곳이 전체를 쥐지 않으면서도 수많은 이름을 안정적으로 다룰 수 있다.
브라우저 입장에서 이 조회는 통신을 시작하기 위한 첫 관문이다. 이 관문을 통과하지 못하면 서버가 아무리 빠르고 문서가 아무리 가벼워도 사용자는 빈 화면만 마주한다. 조회에 걸린 시간은 그대로 첫 응답이 오기까지의 지연에 얹힌다. 그래서 첫인상 속도를 다룰 때 이 단계가 가장 먼저 점검 대상이 된다.
이 이름 체계는 숫자 주소만 담는 것이 아니다. 메일을 어디로 보낼지, 도메인의 관리를 누가 맡는지, 특정 검증 정보가 무엇인지 같은 다양한 기록도 함께 담는다. 브라우저가 주로 쓰는 것은 숫자 주소지만, 같은 체계 위에서 여러 종류의 정보가 함께 오간다. 이 다목적성 때문에 이름 체계는 웹을 떠받치는 기반 시설로 기능한다.
여러 층의 저장소를 거치는 경로
브라우저가 어떤 이름의 숫자 주소를 알아내려 할 때 가장 먼저 하는 일은 자신이 최근에 기억해 둔 값이 있는지 확인하는 것이다. 조금 전에 같은 이름을 조회한 적이 있다면 그 값을 즉시 재사용해, 바깥으로 한 번도 나가지 않고 관문을 통과한다. 이 경우 조회는 사실상 시간이 들지 않는다.
브라우저의 기억에 없으면 그다음으로 운영체제가 관리하는 저장소를 확인한다. 운영체제도 최근에 알아낸 값을 잠시 보관하므로, 다른 프로그램이 이미 조회해 둔 이름이라면 여기서 답을 찾는다. 이 두 단계는 모두 내 컴퓨터 안에서 끝나므로 매우 빠르다. 바깥으로 나가는 조회는 컴퓨터 안에서 답을 찾지 못했을 때에만 일어난다.
컴퓨터 안에서 답이 없으면 바깥의 조회 서버에 대신 알아봐 달라고 요청한다. 보통은 인터넷 사업자나 별도로 지정한 조회 서버가 이 역할을 맡는다. 이 조회 서버는 여러 사용자의 요청을 대신 처리하며 결과를 폭넓게 기억해 두기 때문에, 인기 있는 이름이라면 여기서 바로 답을 받는다.
조회 서버조차 답을 모르면 이제 계층 구조를 위에서부터 따라 내려간다. 최상위를 맡은 곳에 물어 어느 쪽으로 가야 하는지 안내받고, 그 안내를 따라 해당 종류를 맡은 곳으로, 다시 그 이름을 실제로 책임지는 곳으로 차례차례 물어 내려간다. 마침내 책임자가 정확한 숫자 주소를 알려주면 조회가 끝난다. 이 여정을 보면 왜 어떤 조회는 순식간이고 어떤 조회는 느린지가 분명해진다. 가까운 저장소에서 답을 찾으면 눈 깜짝할 사이지만, 맨 끝의 책임자까지 물어 내려가야 하면 여러 번의 오고 감이 쌓인다.
이 구조가 첫 방문자와 재방문자의 체감 속도 차이를 만든다. 재방문자는 여기저기 기억이 남아 있어 관문을 빨리 통과하지만, 처음 오는 사람에게는 긴 경로의 조회 시간이 고스란히 첫인상으로 남는다. 첫 방문 경험을 개선하려면 바로 이 긴 경로를 겨냥해야 한다.
유효기간과 전파의 시간
여러 곳이 조회 결과를 기억해 둔다고 했는데, 이 기억에는 정해진 유효기간이 있다. 이름을 관리하는 쪽이 이 값을 얼마 동안 믿어도 좋은지 함께 알려주고, 각 저장소는 그 기간 동안만 값을 재사용한 뒤 만료되면 다시 물어본다. 이 유효기간이 조회 부담과 반영 속도 사이의 균형을 정한다.
유효기간을 짧게 잡으면 값을 바꿨을 때 빠르게 반영되지만 조회 요청이 자주 일어나 부담이 늘어난다. 반대로 길게 잡으면 조회는 줄어들지만 값을 바꿔도 옛 기억이 남아 있는 동안에는 사람들이 예전 서버로 계속 향한다. 어느 쪽도 공짜가 아니며, 상황에 맞는 절충이 필요하다.
이 성질 때문에 서버를 옮기는 작업에는 요령이 필요하다. 이전을 계획할 때는 먼저 유효기간을 넉넉히 짧게 줄여 둔다. 그러면 곳곳의 기억이 빨리 만료되어, 실제로 값을 바꾼 뒤 새 서버로 넘어가는 전환이 매끄럽게 이뤄진다. 값을 바꾼 뒤 전 세계의 기억이 모두 새 값으로 갱신되기까지 걸리는 시간을 흔히 전파 시간이라 부른다.
이 전파 시간은 유효기간의 영향을 크게 받는다. 유효기간을 미리 줄여 두지 않았다면 옛 값이 오래 살아남아, 일부 사용자는 새 서버로 가고 일부는 옛 서버로 가는 혼란이 생긴다. 그래서 이전 작업은 값을 바꾸는 순간의 조작보다, 며칠 전에 유효기간을 조정하고 새 서버를 미리 준비해 두는 사전 작업이 성패를 가른다. 급하게 값부터 바꾸면 반드시 누군가는 옛 서버로 흘러간다.
암호화된 조회와 사생활
전통적으로 이름 조회는 암호화 없이 오갔다. 그래서 같은 통신망을 지켜보는 누군가가 어떤 사이트의 주소를 물었는지 엿볼 수 있었고, 심한 경우 엉뚱한 답을 끼워 넣어 사용자를 다른 곳으로 유도할 여지도 있었다. 방문 기록이라는 민감한 정보가 그대로 노출되는 오래된 약점이었다.
이 문제를 줄이기 위해, 요즘은 이름 조회를 암호화된 통로로 주고받는 방식이 널리 퍼지고 있다. 조회 내용이 암호화되면 중간에서 엿보거나 변조하기가 훨씬 어려워지고, 사용자가 무엇을 방문하는지가 조금 더 안전하게 지켜진다. 많은 브라우저가 이제 이런 암호화 조회를 기본에 가깝게 지원하며, 신뢰하는 조회 서버를 직접 고를 수도 있다.
다만 암호화된 조회에도 고려할 점은 있다. 조회 내용이 특정 서버로 몰리면 그 서버가 사용자의 방문 습관을 대신 알게 되므로, 누구를 신뢰할 것인가 하는 질문이 새로 생긴다. 또 일부 조직은 안전 관리나 정책상의 이유로 조회 경로를 통제해야 하는데, 암호화 조회가 이런 통제와 부딪히기도 한다. 기술이 한 문제를 풀면 다른 질문이 따라오는 전형적인 사례다.
그럼에도 큰 방향은 분명하다. 사용자의 조회 내용을 보호하려는 흐름은 점점 강해지고 있고, 서비스를 만드는 입장에서도 이 흐름을 이해하고 있어야 한다. 사용자가 무엇을 보는지조차 지켜 주는 태도는 눈에 보이지 않지만 장기적으로 신뢰라는 자산으로 돌아온다.
조회가 실패하는 여러 모습
이름 조회는 언제나 깔끔하게 답을 돌려주지 않는다. 실패에도 여러 모습이 있고, 그 모습을 구분해야 원인을 짚을 수 있다. 가장 단순한 실패는 존재하지 않는 이름을 물었을 때다. 책임자가 그런 이름은 없다고 답하면 브라우저는 곧바로 조회를 접고 오류를 표시한다. 이 경우는 원인이 분명해 진단이 쉽다.
더 까다로운 실패는 답이 아예 돌아오지 않을 때다. 조회 서버가 응답하지 않거나 중간 경로가 막히면, 브라우저는 정해진 시간 동안 기다리다 포기한다. 이 기다림이 사용자에게는 그저 하염없이 느린 로딩으로 느껴진다. 화면이 뜨지 않는데 오류도 뜨지 않는 애매한 상태의 상당수가 이 응답 없는 조회에서 비롯된다.
가장 다루기 어려운 실패는 틀린 답이 돌아오는 경우다. 어딘가에 남아 있던 오래된 기억이 이미 바뀐 옛 주소를 알려주면, 브라우저는 그 주소를 정상으로 여기고 엉뚱한 서버로 향한다. 조회 자체는 성공했으므로 오류가 뜨지 않고, 사용자는 왜 옛 화면이 보이는지 알지 못한다. 이런 실패는 유효기간이 만료되어 기억이 갱신되어야 비로소 풀린다.
이 여러 실패를 구분하는 실무의 방법은 같은 이름을 여러 경로로 조회해 답을 대조하는 것이다. 내 컴퓨터의 기억을 비우고 다시 조회했을 때 결과가 달라지면 오래된 기억이 원인이고, 다른 조회 서버로 물었을 때만 답이 오면 특정 조회 서버의 문제다. 사이트가 열리지 않을 때 그것이 이름을 못 찾은 것인지, 찾았지만 틀린 곳을 찾은 것인지를 먼저 가르는 것이 진단의 출발점이다.
조회에 걸린 시간을 측정하는 것도 진단의 중요한 부분이다. 브라우저의 개발자 도구는 각 요청이 이름 조회에 얼마를 썼는지를 따로 떼어 보여 준다. 이 시간이 유독 길다면 조회 경로 어딘가가 느린 것이고, 이 시간이 거의 없다면 조회는 문제가 아니라는 뜻이다. 막연히 느리다는 인상 대신 이 수치를 확인하면, 개선의 초점을 조회에 둘지 다른 단계에 둘지가 분명해진다.
조회가 실패하거나 느릴 때 기다리는 시간을 얼마로 잡을지도 까다로운 문제다. 이 시간을 짧게 잡으면 느린 조회를 빨리 포기해 다른 경로를 시도할 수 있지만, 조금만 느렸어도 성공했을 조회까지 성급히 접게 된다. 반대로 길게 잡으면 성공 가능성은 높아지지만 실패가 확실한 경우에도 사용자를 오래 기다리게 한다. 어느 쪽도 완벽하지 않아, 사용자가 겪는 실제 상황을 보고 균형을 맞춰야 한다.
결국 조회의 진단은 세 가지 질문으로 정리된다. 답이 돌아오기는 하는가, 돌아온 답이 맞는가, 그리고 답이 돌아오기까지 얼마나 걸리는가다. 첫째가 어긋나면 경로가 끊긴 것이고, 둘째가 어긋나면 오래된 기억이 남은 것이며, 셋째가 어긋나면 경로가 느린 것이다. 이 세 질문을 차례로 짚으면 조회 문제의 대부분은 그 성격이 분명해진다.
미리 조회하고 미리 연결하기
조회가 첫인상 속도를 좌우한다는 사실을 알면, 자연스럽게 이 시간을 앞당길 방법을 찾게 된다. 브라우저에는 앞으로 필요할 이름을 미리 조회해 두라고 귀띔하는 수단이 마련되어 있다. 문서 앞부분에 rel="dns-prefetch" 같은 표시를 넣어 두면, 브라우저는 그 자원을 실제로 쓰기 전에 미리 이름 조회를 시작한다.
한 걸음 더 나아가 rel="preconnect"를 쓰면 조회뿐 아니라 연결을 여는 절차까지 미리 준비한다. 조회와 연결은 이어지는 작업이라, 이 둘을 함께 앞당기면 실제 요청이 시작될 때 이미 길이 닦여 있어 첫 응답이 눈에 띄게 빨라진다. 특히 첫 화면에 꼭 필요한 외부 서버에 이 힌트를 걸어 두면 효과가 크다.
다만 이런 미리 준비는 공짜가 아니다. 실제로 쓰지도 않을 이름을 잔뜩 미리 조회하고 연결하면 오히려 자원을 낭비하고 다른 중요한 작업을 밀어낸다. 그래서 정말로 곧 쓰일 것이 확실한, 특히 첫 화면에 필요한 몇 개에만 이 힌트를 아껴 쓰는 것이 원칙이다.
또 하나 실무에서 신경 쓸 것은 사이트가 의존하는 바깥 자원의 이름 수를 줄이는 일이다. 서로 다른 곳에서 온 자원이 많을수록 조회해야 할 이름도 늘고, 그만큼 관문을 여러 번 통과해야 한다. 꼭 필요하지 않은 외부 의존을 정리하는 것만으로도 초반 속도가 개선된다. 이름 조회는 보이지 않지만 첫인상을 좌우하는 관문이며, 미리 조회하고 미리 연결하는 힌트로 그 관문을 앞당길 수 있다. 다음 편에서는 조회로 알아낸 서버와 실제로 안전한 연결을 맺는 과정을 다룬다.