[웹 기반기술 43] DNS - 리다이렉트, www와 non-www

하나의 서비스에는 사용자가 도달하는 입구가 여럿이다. 앞자리가 붙은 이름과 붙지 않은 뿌리 이름, 보안 연결과 일반 연결, 끝에 빗금이 있는 주소와 없는 주소가 모두 같은 곳을 가리킬 수 있다. 이 여러 입구를 그대로 두면 같은 내용이 여러 주소로 흩어져 검색과 캐시와 통계가 모두 어지러워진다. 리다이렉트는 이 흩어진 입구들을 하나의 대표 주소로 모으는 길 안내다.

이번 편은 리다이렉트와 주소 정규화를 다룬다. 리다이렉트가 어떻게 동작하는 길 안내인지, 영구와 임시 안내가 어떻게 구분되는지, 앞자리 유무를 어떻게 정하는지, 여러 입구를 하나로 모으는 순서는 어떻게 짜는지, 정규화가 검색과 캐시에 왜 중요한지, 그리고 실무에서 흔히 겪는 함정은 무엇인지를 차례로 짚는다. 정규화를 제대로 해 두면 서비스의 주소가 하나로 또렷해진다.

리다이렉트라는 길 안내

리다이렉트는 어떤 주소로 온 요청을 다른 주소로 다시 보내는 응답이다. 서버는 요청받은 주소에서 곧바로 내용을 돌려주는 대신, 진짜 주소는 여기라며 다른 주소를 알려 준다. 브라우저는 그 안내를 받아 새 주소로 다시 요청을 보내고, 그제야 내용을 받는다. 리다이렉트는 내용을 주는 것이 아니라 갈 곳을 알려 주는 이정표다.

이 안내는 응답에 담긴 상태와 목적지 주소로 표현된다. 서버가 다시 보낼 주소를 응답 머리에 담아 돌려주면, 브라우저는 그 주소로 자동으로 옮겨 간다. 사용자는 대개 이 과정을 의식하지 못한 채 최종 주소에 도달한다. 겉으로는 한 번에 도착한 것처럼 보여도, 안에서는 요청이 두 번 오간 셈이다.

리다이렉트가 필요한 이유는 하나의 서비스에 여러 주소가 존재하기 때문이다. 옛 주소를 새 주소로 옮겼거나, 여러 형태의 이름을 대표 이름으로 모으거나, 일반 연결을 보안 연결로 올릴 때 리다이렉트가 그 다리를 놓는다. 사용자가 어느 입구로 들어오든 결국 같은 대표 주소에 도달하게 만드는 것이 리다이렉트의 목적이다.

리다이렉트는 이름 조회 단계가 아니라 그 뒤의 연결 단계에서 일어난다는 점을 구분해야 한다. 이름 조회는 주소를 찾는 일이고, 리다이렉트는 이미 연결된 서버가 다른 주소로 다시 보내는 일이다. 그래서 리다이렉트를 설정하는 곳은 이름 레코드가 아니라 서버나 그 앞의 처리 계층이다. 이 구분을 흐리면 리다이렉트를 엉뚱한 곳에서 찾게 된다.

안내를 어느 계층에서 수행하느냐도 선택의 여지가 있다. 이름이 가리키는 서버가 직접 안내를 돌려줄 수도 있고, 그 앞에 놓인 전송망이나 처리 계층이 서버에 닿기 전에 안내를 처리할 수도 있다. 앞단에서 안내를 처리하면 요청이 서버까지 가지 않고 되돌아오므로 서버의 부담이 줄고 응답도 빠르다. 단순한 주소 정규화라면 앞단에서 처리하는 편이 효율적이고, 내용에 따라 달라지는 복잡한 안내라면 서버가 맡는 편이 자연스럽다.

영구와 임시의 구분

리다이렉트에는 이 이동이 영구적인지 임시적인지를 나타내는 구분이 있다. 영구 안내는 앞으로 이 주소는 항상 저 주소로 옮겨진다는 뜻이고, 임시 안내는 지금만 잠시 저 주소로 간다는 뜻이다. 이 구분은 단순한 표시가 아니라 브라우저와 검색 엔진의 행동을 다르게 만든다. 어느 쪽을 쓰느냐에 따라 결과가 크게 달라진다.

영구 안내를 받으면 브라우저는 그 안내를 저장해 두고, 다음에 같은 옛 주소로 갈 일이 있으면 서버에 묻지 않고 곧바로 새 주소로 향한다. 검색 엔진도 옛 주소의 평판을 새 주소로 넘기고 색인을 새 주소로 옮긴다. 그래서 대표 주소로 모으는 정규화에는 영구 안내가 알맞다. 이동이 확정적이라는 신호를 주어야 검색 평판이 대표 주소로 모인다.

임시 안내는 이동이 잠정적일 때 쓴다. 점검 중에 잠시 다른 곳으로 보내거나, 조건에 따라 목적지가 바뀌는 경우처럼 나중에 원래대로 돌아올 여지가 있을 때다. 임시 안내는 브라우저가 저장하지 않고 검색 평판도 넘기지 않으므로, 언제든 되돌릴 수 있다. 잠정적인 이동에 영구 안내를 쓰면 되돌리기 어려운 상태에 갇힌다.

영구와 임시를 잘못 고르면 대가가 크다. 잠깐의 이동에 영구 안내를 쓰면 브라우저가 그것을 저장해 버려, 나중에 원래 주소로 돌아와도 사용자가 여전히 옛 안내를 따라 엉뚱한 곳으로 향한다. 이 저장은 서버가 강제로 지우기 어려우므로 오래 남는다. 그래서 영구 안내는 정말로 확정된 이동에만 신중하게 써야 한다.

앞자리 유무의 선택

대표 주소를 정할 때 오래된 고민이 앞자리를 붙일 것인가다. 뿌리 이름을 대표로 삼을 수도 있고, 앞자리가 붙은 이름을 대표로 삼을 수도 있다. 어느 쪽이 절대적으로 옳은 것은 아니지만, 둘 중 하나를 대표로 정하고 나머지를 그쪽으로 모으는 것만은 반드시 해야 한다. 두 이름을 모두 방치하면 같은 내용이 두 주소로 갈라진다.

앞자리가 붙은 이름을 대표로 삼으면 기술적으로 유리한 점이 있다. 앞자리가 붙은 이름에는 다른 이름을 가리키는 별칭을 걸 수 있어, 목적지 주소가 바뀌어도 별칭만 두면 자동으로 따라간다. 반면 뿌리 이름에는 이 별칭을 그대로 쓸 수 없다는 제약이 있어, 외부 서비스로 연결할 때 특별한 우회가 필요하다. 이 제약이 앞자리 있는 이름을 대표로 선호하게 만드는 이유다.

뿌리 이름을 대표로 삼으면 주소가 짧고 깔끔하다는 장점이 있다. 사용자가 앞자리 없이 이름만 입력해도 되므로 기억하고 전하기가 쉽다. 다만 앞서 말한 별칭 제약 때문에, 뿌리 이름을 외부 전송망이나 호스팅으로 연결하려면 대행 기관이 제공하는 특별한 기능에 기대야 한다. 이 기능의 유무가 뿌리 이름을 대표로 쓸 수 있는지를 좌우한다.

어느 쪽을 고르든 중요한 것은 하나로 정하고 일관되게 모으는 것이다. 대표 주소를 정했으면 나머지 형태로 들어온 모든 요청을 영구 안내로 대표 주소로 보내야 한다. 사용자가 앞자리를 붙이든 안 붙이든, 보안 연결이든 아니든, 결국 하나의 대표 주소에 도달하게 만드는 것이 정규화의 목표다. 선택 자체보다 일관성이 중요하다.

여러 입구를 하나로 모으는 순서

입구를 모을 때는 흩어진 형태를 빠짐없이 대표 주소로 향하게 해야 한다. 앞자리가 붙은 형태와 붙지 않은 형태, 보안 연결과 일반 연결, 끝 빗금의 유무가 조합을 이루므로, 이 조합 중 대표가 아닌 모든 형태를 대표로 보내는 안내를 두어야 한다. 하나라도 빠뜨리면 그 형태로 들어온 요청이 대표 주소로 모이지 않고 흩어진다.

이때 안내가 여러 단계로 겹치지 않도록 순서를 짜야 한다. 예를 들어 일반 연결의 앞자리 없는 주소로 들어온 요청을, 먼저 보안 연결로 보내고 다시 앞자리를 붙이는 식으로 두 번 안내하면 요청이 세 번 오간다. 가능하면 한 번의 안내로 최종 대표 주소에 곧바로 도달하게 하는 것이 좋다. 안내가 겹치면 그만큼 사용자가 도달하는 시간이 늘어난다.

모으는 안내는 대개 서버나 그 앞의 처리 계층에서 규칙으로 정한다. 어떤 형태로 들어오든 대표 형태가 아니면 대표 형태로 다시 보내는 규칙을 두면, 개별 주소마다 안내를 일일이 두지 않아도 된다. 이 규칙은 들어온 주소의 이름과 연결 방식을 보고 대표와 다르면 안내하는 방식으로 동작한다. 규칙 하나로 모든 형태를 포괄하는 것이 관리에 유리하다.

보안 연결로 올리는 안내는 특히 신경 써야 한다. 일반 연결로 들어온 요청을 보안 연결로 보내는 안내가 있어야 사용자가 실수로 안전하지 않은 경로로 접속하는 것을 막을 수 있다. 다만 이 안내만으로는 첫 요청이 일반 연결로 오가는 순간의 위험이 남으므로, 다음 편에서 다룰 강제 장치를 함께 두어야 완전해진다. 리다이렉트는 강제의 출발점이지 끝은 아니다.

정규화가 지키는 검색과 캐시

같은 내용이 여러 주소로 존재하면 검색 엔진이 혼란을 겪는다. 검색 엔진은 각 주소를 별개의 것으로 보고 평판을 나누어 매기므로, 흩어진 주소들은 각각 낮은 평판을 갖게 된다. 하나의 대표 주소로 모으면 그 평판이 한곳에 쌓여 검색 노출이 유리해진다. 정규화는 검색 평판을 분산시키지 않고 응집시키는 일이다.

대표 주소를 명시하는 별도의 표시도 함께 두는 것이 좋다. 리다이렉트로 요청을 모으는 것과 별개로, 각 문서에 자신의 대표 주소가 무엇인지를 밝히는 표시를 두면 검색 엔진이 대표를 더 확실히 인식한다. 리다이렉트가 요청 자체를 모은다면, 이 표시는 검색 엔진에게 대표를 알리는 선언이다. 둘을 함께 쓰면 정규화가 더 견고해진다.

캐시의 관점에서도 정규화가 중요하다. 중간의 캐시 계층은 주소를 기준으로 내용을 저장하므로, 같은 내용이 여러 주소로 존재하면 같은 것을 여러 번 저장하게 되어 효율이 떨어진다. 대표 주소로 모으면 캐시가 하나의 주소에 집중되어 적중률이 높아진다. 주소가 하나로 정리되는 것은 캐시의 효율에도 직접 이롭다.

통계와 분석도 정규화의 덕을 본다. 방문 기록이 여러 주소로 갈라지면 같은 페이지의 방문이 나뉘어 집계되어 실제 인기를 파악하기 어렵다. 대표 주소로 모으면 방문이 한 주소로 집계되어 분석이 정확해진다. 정규화는 검색과 캐시뿐 아니라 서비스를 이해하는 눈까지 또렷하게 만든다.

정규화가 주는 이 여러 이점은 결국 하나의 원리에서 나온다. 같은 것에는 같은 이름을 부여한다는 원리다. 하나의 내용에 하나의 대표 주소가 대응하면, 그 주소를 기준으로 삼는 모든 체계가 일관되게 동작한다. 검색은 평판을 모으고, 캐시는 저장을 모으고, 통계는 방문을 모은다. 반대로 하나의 내용에 여러 이름이 붙으면 이 모든 체계가 제각기 갈라진다. 정규화는 겉으로는 주소를 다듬는 사소한 작업처럼 보이지만, 그 밑바탕에는 하나의 대상에 하나의 이름을 지킨다는 단단한 원칙이 있다.

실무에서 겪는 정규화의 함정

가장 흔한 함정은 안내가 무한히 도는 것이다. 대표가 아닌 형태를 대표로 보내려다 규칙을 잘못 짜면, 안내받은 주소가 다시 자신을 안내하는 순환에 빠진다. 브라우저는 이 순환을 감지하면 오류를 내고 멈춘다. 안내 규칙을 짤 때는 대표 형태로 들어온 요청은 더 안내하지 않고 그대로 처리되는지를 반드시 확인해야 한다.

두 번째 함정은 안내가 여러 단계로 겹쳐 느려지는 것이다. 연결 방식과 앞자리를 각각 다른 단계에서 안내하면 요청이 여러 번 오가 도달이 늦어진다. 이런 겹침은 개별로는 문제없어 보여도 쌓이면 체감 속도를 떨어뜨린다. 여러 조건을 한 번의 안내로 처리해 최종 대표 주소로 곧바로 보내도록 규칙을 정리해야 한다.

세 번째 함정은 보안 연결로 올리는 안내에서 인증서가 이름과 맞지 않는 것이다. 앞자리 없는 이름으로 보안 연결을 시도하는데 인증서에 그 이름이 담겨 있지 않으면, 안내가 이루어지기도 전에 신뢰 오류가 난다. 정규화에서 다루는 모든 이름 형태가 인증서에 함께 담겨 있어야 안내가 매끄럽게 이어진다. 인증서의 이름 범위와 정규화의 이름 범위를 맞추어야 한다.

마지막 함정은 옛 주소의 안내를 성급히 임시로 두는 것이다. 대표 주소로 옮기는 정규화는 확정된 이동이므로 영구 안내를 써야 검색 평판이 옮겨 가는데, 임시 안내로 두면 평판이 넘어가지 않아 정규화의 효과가 반감된다. 이동이 확정적이라면 영구 안내를 쓰는 것이 원칙이다. 이렇게 리다이렉트의 원리, 영구와 임시의 구분, 앞자리 선택, 입구를 모으는 순서, 정규화의 이점, 그리고 실무의 함정까지 이해하면 서비스의 주소가 하나로 또렷해진다. 다음 편은 이 안내를 넘어 보안 연결을 강제하는 장치를 다룬다.