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


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

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


![리디렉션 적용 전후를 비교하는 플로우 이미지](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp)


## DNS와 검색 봇은 'www'를 똑똑히 보고 있다 {#sec-e0d49c76d3ea}

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

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

**1. Yahoo Japan의 사례**
```bash
$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...
```
야후 재팬은 Apex 도메인으로 접속했을 때 `www`가 붙은 주소로 `301 Moved Permanently` 리다이렉트를 보냅니다.

**2. Google의 사례**
```bash
$ 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` 응답을 반환합니다.

## 왜 반드시 한쪽을 리다이렉트해야 하는가? {#sec-cf467e61a55d}

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

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

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

---

## 해결책: 웹 서버 단계에서의 강제 리다이렉트 {#sec-e499a7960796}

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

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

```nginx
# 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 등)를 변경하지 않고 그대로 유지하며 리다이렉트하기 때문에 현대 웹 환경에서 더 안전하기 때문입니다.

## 마치며 {#sec-ad06e7ff5f93}

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