웹사이트 주소에 www를 붙여야 할까요?

웹사이트는 www.example.com이나 example.com 어느 쪽으로 운영해도 됩니다. 하나를 공식 주소로 정하고, 두 주소로 오는 방문자를 모두 받아 다른 쪽 주소는 해당 페이지로 영구 이동시키세요.

실제로 할 일은 이것입니다. 하지만 이 네 글자는 여러 가지와 관련이 있습니다. 주소의 모양, 사람들이 주소를 알아보는 방식, 브라우저의 표시 방식, 웹사이트의 동작까지 영향을 받습니다. 자신이 무엇을 결정하고 있는지 알면 이 선택의 깊이가 보입니다.

www는 무슨 역할을 할까요?

www는 World Wide Web의 약자입니다. 웹사이트 주소에서는 관례로 쓰이는 호스트 이름의 한 부분입니다. 웹 서비스에 www라는 이름을 붙이는 선택이 퍼지면서 익숙한 표기가 됐습니다. 이 글자 자체에 주소를 웹사이트로 만드는 특별한 힘이 있는 것은 아닙니다.

https://www.example.com에서 각 부분은 역할이 다릅니다. https://는 암호화로 보호되는 HTTP를 사용한다는 연결 방식을 나타냅니다. www.example.com은 연결할 호스트를 가리킵니다. www.를 없애면 호스트 이름이 달라집니다. 인쇄된 주소에서 https://를 생략하는 것은 독자나 소프트웨어가 연결 방식을 채워 넣도록 맡기는 것입니다.

약자의 전체 이름을 몰라도 웹사이트 주소를 알아볼 수 있습니다. 익숙함과 기술적인 이해는 다릅니다. 명함을 읽기 전에 모든 방문자에게 네트워크 시험을 보게 할 필요는 없습니다.

네 글자도 디자인의 선택입니다

포스터나 이메일 서명, 로고 옆에서는 example.com이 www.example.com보다 눈으로 읽어야 할 글자가 적습니다. 새 웹사이트에서 짧은 주소를 선택할 만한 이유입니다. 우리는 이를 디자인 판단으로 봅니다. 이제 누구나 모든 도메인 끝부분을 알아본다고 단정할 수는 없습니다.

어디에 놓이는지도 중요합니다. 일반 문장 속에 낯선 주소가 나온다면 ‘웹사이트’ 같은 표시를 붙이는 편이 나을 수 있습니다. 회사 이름 아래에 있는 익숙한 주소는 그 자체로 충분할 수 있고요. www.를 붙이는 것도 하나의 단서입니다. 해당 배치에서 독자가 이해하기 쉬운 쪽을 고르세요.

브라우저도 표시 방식을 자체적으로 결정합니다. Chromium의 URL 표시 지침에는 일부 화면에서 www를 생략해 표시를 간단히 하는 방법이 설명돼 있습니다. 실제로 보이는 내용은 브라우저, 버전, 설정, 주소를 보고 있는지 수정 중인지에 따라 달라집니다. 표시가 짧아졌다고 사이트의 공식 호스트 이름이 바뀐 것은 아닙니다.

익숙하다고 믿을 수 있는 것은 아닙니다

주소를 훑어볼 때는 익숙한 부분을 발견하고, 웹사이트처럼 보인다고 판단한 뒤 넘어가기 쉽습니다. 불필요한 글자에 대해 우리가 걱정하는 점은 주의해서 봐야 할 이름에서 시선을 분산시킬 수 있다는 것입니다. 그래서 읽기 쉬운 주소가 중요합니다. 다만 이것이 www.를 없애면 사기를 막을 수 있다는 증거는 아닙니다.

사기 웹사이트도 www를 쓸 수 있습니다. HTTPS도 사용할 수 있습니다. Chrome의 자물쇠 아이콘 변경 설명은 이 차이를 분명히 짚습니다. 연결이 암호화됐다고 상대편 웹사이트를 신뢰할 수 있다는 뜻은 아닙니다.

실제 도메인과 어떤 상황에서 링크를 받았는지 확인하세요. 익숙한 앞부분만으로는 누가 사업을 운영하는지, 결제 요청이 정당한지 알 수 없습니다. 자신의 사이트에 붙일 앞부분을 고르는 것은 브랜드 표현과 설정에 관한 결정이지 안전 인증이 아닙니다.

아래 그림에서 www.example.com.other-site.net은 other-site.net 아래에 속합니다. 앞에 익숙한 www.example.com이 붙어 있어도 example.com의 일부가 되지는 않습니다. 호스트 이름을 끝까지 읽으면 다른 의미가 보입니다.

일반 텍스트는 왜 자꾸 링크가 될까요?

관련된 불편도 있습니다. 두 문자열 사이에 점을 넣으면 앱이 웹사이트 주소를 쓰려는 것으로 판단할 수 있습니다. 문서 일부가 갑자기 파란색으로 바뀌고 클릭할 수 있게 되는 겁니다.

이것은 앱의 동작입니다. 어떤 패턴을 주소로 볼지는 앱의 링크 감지 규칙이 결정합니다. 제품과 설정에 따라 다르므로 text.text가 모든 곳에서 링크로 바뀌지는 않습니다. www의 생략 자체가 모든 텍스트 표시에 적용되는 공통 규칙을 만든 것도 아닙니다.

Word의 자동 하이퍼링크 기능에 관한 Microsoft 문서는 주소처럼 보이는 텍스트를 링크로 바꾸며, 링크의 유효성은 확인하지 않는다고 설명합니다. 이 기능이 방해된다면 편집기의 자동 링크 설정을 바꾸거나 링크를 제거하세요. 웹사이트의 호스트 이름으로는 편집기의 추측을 바꿀 수 없습니다.

두 주소의 도착지는 하나로

기술적으로 example.com과 www.example.com은 서로 다른 호스트입니다. 같은 서버에서 똑같은 페이지를 보여 주더라도 브라우저는 서로 다른 출처로 취급합니다. 따라서 앱을 어떻게 만들었는지에 따라 로그인 상태나 브라우저에 저장한 데이터가 다르게 처리될 수 있습니다. 가능한 결과라는 뜻이지 모든 사이트에 자동으로 문제가 생긴다는 뜻은 아닙니다.

하나의 공개 웹사이트에는 공식 도착지를 하나 정할 것을 권합니다. 다른 주소도 입구로 남겨 두되, 별도의 복사본을 제공하는 대신 방문자를 공식 주소로 보냅니다. 이 선택에 관한 MDN 안내도 일관성을 유지하고 두 가지 주소가 모두 작동하도록 할 것을 권합니다.

일반적인 웹페이지 방문에는 301 영구 리디렉션을 사용하는 것이 표준적인 방법입니다.

예를 들어 짧은 주소를 공식 주소로 정했다면, https://www.example.com/contact/를 연 방문자는 https://example.com/contact/에 도착해야 합니다. 페이지 경로와 쿼리 매개변수를 유지하세요. 예전 주소를 모두 홈페이지로 보내면 방문자는 원하는 페이지를 다시 찾아야 합니다.

개발자에게 알려야 할 구현상의 세부 사항도 있습니다. 폼, API 등 데이터를 제출하는 요청은 별도로 확인해야 합니다. 301은 POST 요청을 GET으로 바꿀 수 있습니다. 요청 메서드와 제출한 본문을 그대로 유지해야 한다면 308처럼 메서드를 보존하는 리디렉션이 적절할 수 있습니다.

사이트 담당자에게 무엇을 물어볼까요?

직접 서버를 설정할 필요는 없습니다. 담당자에게 다음 사항을 확인해 달라고 하세요.

• HTTP와 HTTPS 각각에 www가 있는 주소와 없는 주소, 총 네 가지 입구가 모두 작동해야 합니다. 모두 선택한 HTTPS 주소로 연결돼야 합니다.
• 두 호스트 이름 모두 유효한 HTTPS 인증서가 있어야 합니다. 브라우저는 HTTPS 리디렉션을 받기 전에 먼저 해당 연결을 맺어야 합니다.
• 리디렉션은 대응하는 페이지로 연결되고 쿼리 매개변수를 유지하며, 불필요한 중간 이동을 거치지 않아야 합니다.
• 내부 링크, 사이트맵, 각 페이지의 대표 주소는 선택한 버전으로 통일돼야 합니다.

마지막 항목은 검색 엔진에도 도움이 됩니다. Google은 리디렉션과 대표 URL 지정을 신호로 사용해 어떤 URL이 페이지를 대표하는지 판단합니다. 대표 URL 지정은 검색 엔진을 안내하는 기능이며 방문자를 다른 주소로 이동시키지는 않습니다. 방문자도 일관된 목적지에 도착하도록 리디렉션을 사용하세요.

한 번 고르고, 계속 관리하세요

새 사이트라면 짧은 주소, 홍보물에서 보이는 모양, 서비스 업체가 설명하는 호스팅 제약을 함께 고려하세요. 이미 www로 잘 운영되는 사이트라면 짧은 주소가 유행해 보인다는 이유만으로 이전할 필요는 없습니다.

그보다 중요한 질문은 회사가 그 주소를 계속 관리할 수 있느냐입니다. 회사 도메인은 누가 관리해야 할까요라는 글에서 그 책임을 다룹니다.

www를 붙여도 빼도 잘못된 선택은 아닙니다. 사이트에 맞는 형태를 골라 일관되게 사용하고, 어느 쪽을 입력하든 올바른 페이지로 이어지도록 하세요.