www.와 Apex 도메인, 왜 하나로 합쳐야 할까? (301/308 리다이렉트의 중요성)

최근 크롬(Chrome)이나 엣지(Edge), 사파리(Safari) 같은 현대적인 브라우저들을 유심히 관찰해 보신 적 있나요? 주소창에 www.naver.com이나 www.google.com을 입력해도 어느 순간 www가 사라지고 도메인 본체(Apex Domain)만 남는 것을 볼 수 있습니다. 심지어 모바일용 m. 도메인도 숨겨지곤 하죠.

이것은 현대 브라우저들이 주소창을 더 깔끔하게 시각화하기 위해 채택한 "사소한 하위 도메인(Trivial Subdomains)" 숨기기 정책 때문입니다. 사용자 입장에서는 주소가 짧아 보여 쾌적할 수 있지만, 웹 개발자라면 여기서 한 걸음 더 들어가 생각해야 합니다. "브라우저가 숨겨서 보여주는 것" 과 "실제로 별개의 도메인으로 동작하는 것" 은 완전히 다른 문제이기 때문입니다.

리디렉션 적용 전후를 비교하는 플로우 이미지

DNS와 검색 봇은 'www'를 똑똑히 보고 있다

실제 DNS 처리 과정이나 검색 엔진 로봇(Googlebot 등)에게 www.example.com과 example.com은 엄연히 다른 목적지입니다. 만약 이 두 주소가 모두 200 OK 응답을 반환하며 동일한 콘텐츠를 보여주고 있다면, 이는 기술적으로 '중복 콘텐츠'를 가진 두 개의 사이트가 운영되는 것과 같습니다.

글로벌 IT 기업들은 이 문제를 어떻게 해결하고 있는지 curl 명령어로 직접 확인해 보겠습니다.

1. Yahoo Japan의 사례

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

야후 재팬은 Apex 도메인으로 접속했을 때 www가 붙은 주소로 301 Moved Permanently 리다이렉트를 보냅니다.

2. Google의 사례

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

구글 역시 마찬가지입니다. google.com으로 접속하면 www.google.com으로 리다이렉트 시킨 뒤, 최종적으로 www 도메인에서만 200 응답을 반환합니다.

왜 반드시 한쪽을 리다이렉트해야 하는가?

단순히 "깔끔해 보여서"가 아닙니다. 여기에는 명확한 SEO(검색 엔진 최적화)와 운영 효율상의 이유가 있습니다.

1. Canonical Tag의 한계

많은 개발자가 <link rel="canonical" href="..."> 태그를 설정했으니 괜찮다고 생각합니다. 하지만 캐노니컬 태그는 검색 엔진에게 주는 "힌트"일 뿐입니다. 로봇이 두 URL을 모두 크롤링해야 한다는 사실은 변하지 않으며, 이 과정에서 크롤링 예산(Crawl Budget)이 낭비됩니다. 로봇이 내 사이트의 새로운 글을 긁어갈 시간에 이미 있는 글의 '복사본'을 긁고 있게 되는 셈이죠.

2. 링크 주스(Link Juice)의 분산

웹상의 다른 사이트들이 내 글을 링크할 때, 누군가는 www를 붙이고 누군가는 떼고 링크를 겁니다. 리다이렉트 처리가 되어 있지 않으면 해당 페이지가 쌓아야 할 권위도(Authority)가 두 도메인으로 분산되어, 검색 순위 경쟁에서 손해를 보게 됩니다.

해결책: 웹 서버 단계에서의 강제 리다이렉트

이 처리는 애플리케이션(Django, Node.js 등) 코드 레벨이 아닌, Nginx나 Apache 같은 웹 서버(인프라) 단계에서 처리하는 것이 가장 효율적입니다. 애플리케이션까지 요청이 도달하기 전에 서버에서 즉시 돌려보내는 것이 리소스 소모가 적고 속도도 빠르기 때문입니다.

아래는 example.com을 운영할 때, 모든 요청을 Apex 도메인(https://example.com)으로 통일하는 Nginx 설정 예시입니다. (반대로 www로 통일하고 싶다면 대상 주소만 바꾸면 됩니다.)

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 308 https://example.com$request_uri;
}

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. 실제 서비스 로직 (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... 서비스 설정 및 Proxy Pass 등
}

Tip: 여기서 301 대신 308 상태 코드를 사용한 이유는, 308 Permanent Redirect가 HTTP 메서드(POST, PUT 등)를 변경하지 않고 그대로 유지하며 리다이렉트하기 때문에 현대 웹 환경에서 더 안전하기 때문입니다.

마치며

브라우저가 주소를 숨겨준다고 해서 서버까지 방관해서는 안 됩니다. www와 Apex 도메인이 공존하며 둘 다 200을 띄우고 있다면, 지금 즉시 웹 서버 설정을 확인해 보세요. 한쪽으로의 확실한 리다이렉트 처리는 검색 엔진에게 내 사이트의 정체성을 명확히 알리는 가장 기초적이고도 중요한 작업입니다.