410 Gone: 404와 언제 다르게 쓰나

Problem

URL이 페이지 대신 410 Gone을 반환합니다. 대부분의 4xx 코드와 달리 이건 보통 버그가 아닙니다 — 서버가 리소스를 의도적으로 제거했고 다시 돌아오지 않는다고 말하는 것입니다. 문제는 그게 의도한 바였는지, 그리고 그걸 설정한 게 당신인지입니다.

Symptoms

• HTTP 점검이 리다이렉트 없이 최종 상태 410을 보여줍니다.
• 되던 URL이 이제 Gone입니다 — 대개 콘텐츠 마이그레이션, CMS 정리, 플러그인 변경 직후입니다.
• Search Console이 페이지가 “제거됨”으로 뜨거나 평소보다 빨리 색인에서 빠진다고 보고합니다.
• 페이지를 복구했다고 생각한 뒤에도 일부 클라이언트·캐시가 계속 410을 반환합니다.

What This Error Actually Means

RFC 9110 §15.5.11은 410을 이렇게 정의합니다: 리소스가 “더 이상 오리진 서버에서 이용 불가하며 이 상태가 영구적일 가능성이 높다.” 마지막 단어가 핵심입니다. 404는 못 찾음 — 애초에 없었을 수도, 일시적으로 없을 수도, URL을 잘못 쳤을 수도 — 를 말합니다. 410은 존재했고, 일부러 제거했으니, 그만 물어보라를 말합니다.

명세는 410이 선택적이고 의도적임을 분명히 합니다: “수신자에게 리소스가 의도적으로 이용 불가함을 알려 웹 유지보수 작업을 돕는 것이 주 목적”입니다. 서버는 무엇을 삭제했는지 추적할 의무가 없습니다. 영구성을 신호하고 싶지 않거나 그럴 필요가 없다면 404도 완벽히 유효한 답입니다. 410은 제거가 최종임을 알 때 내리는 선택입니다.

그 “영구” 약속에서 두 가지 결과가 따라옵니다. 첫째, 정상적인 클라이언트와 크롤러는 410을 404보다 URL을 잊으라는 더 강한 신호로 취급합니다. 둘째 — 사람들이 놀라는 지점 — 410은 기본적으로 캐시 가능합니다. HTTP의 휴리스틱 캐싱 규칙은 캐시가 404나 301을 캐시할 수 있는 것과 똑같이, 명시적 캐시 헤더가 전혀 없어도 410을 저장하게 허용합니다. CDN이 기억해도 되는 영구 제거 코드는 들리는 그대로 끈질깁니다.

Top 3 Causes

1. 의도적이고 올바른 제거 — 당신(또는 CMS·프레임워크)이 진짜 은퇴한 콘텐츠에 일부러 410을 반환했습니다: 단종 제품, 삭제된 계정, 후속 없는 만료 캠페인. 설계대로 동작하는 410입니다. 고칠 것 없이 — 코드가 크롤러에 도달하는지만 확인하세요.
2. 플러그인·CMS발 실수 410 — 마이그레이션, “휴지통” 상태, SEO 플러그인의 제거 설정, 대량 편집이 살아 있는 URL을 Gone으로 뒤집었습니다. 단서는 지키고 싶은 페이지가 410을 내고 트래픽이 절벽처럼 떨어진 것입니다. 410이 404보다 빨리 색인에서 빼라고 Google에 말하기 때문에 이게 위험한 경우입니다.
3. 캐시에 낀 오래된 410 — 오리진은 고쳤는데, 410이 휴리스틱하게 캐시 가능하다 보니 CDN·프록시가 여전히 캐시된 410을 서빙합니다. 오리진은 200이라는데 방문자와 크롤러는 캐시가 퍼지될 때까지 Gone을 봅니다.

Diagnose with DechoNet

• HTTP 점검은 최종 상태가 정말 410인지, 404·소프트 404(200으로 서빙된 “못 찾음” 페이지)·Gone으로 끝나는 리다이렉트 체인이 아닌지 확인합니다. 응답 헤더도 보여주므로, 경로에 CDN이 있는지, 410에 캐시 헤더가 설정됐는지 볼 수 있습니다.
• 고친 뒤 자신의 네트워크 바깥에서 HTTP 점검을 다시 돌리세요. 오리진은 200을 서빙하는데 점검이 여전히 410을 반환하면, Gone 응답이 중간 노드에 캐시된 것입니다 — 오리진을 계속 만지지 말고 CDN을 퍼지하라는 신호입니다.

Resolution Checklist

• 410이 의도적인지 판단하세요. 이 URL이 대체물 없이 진짜 영구 은퇴인가요? 그렇다면 410이 옳습니다 — 크롤러가 도달할 수 있는지 확인하는 단계로 넘어가세요. 콘텐츠가 이동했다면 410이 아니라 새 URL로 301이 필요합니다.
• 실수라면: 무엇이 설정했는지 찾으세요. CMS의 휴지통·제거 상태, SEO 플러그인 제거 규칙, 최근 대량 편집이나 마이그레이션 스크립트를 확인하세요. URL이 진짜 콘텐츠를 서빙하도록 복구하세요.
• 캐시를 퍼지하세요. 410은 기본 캐시 가능이라, 오리진을 고친 뒤에도 CDN·프록시가 Gone을 계속 서빙할 수 있습니다. 모든 캐시 계층에서 URL을 무효화하고 외부 도구로 재테스트하세요.
• 마이그레이션을 통째로 410 하지 마세요. 섹션 전체를 은퇴시키나요? 옛 URL을 가장 가까운 새 대응물로 301 매핑하고, 진짜 후속이 없는 것만 410으로 남기세요. 410의 벽은 리다이렉트할 수 있었던 링크 자산을 버립니다.
• 대량 정리(해킹·스팸 URL)라면: 410이 맞는 도구입니다 — 쓰레기를 색인에서 조금 빨리 뺍니다. 하지만 그 URL도 보이려면 크롤링돼야 하므로, 제출하거나 즉시가 아닌 점진적 소거를 예상하세요.
• HTTP 점검을 다시 돌려 최종 코드가 의도와 맞는지 확인하세요.

When to Escalate

• 의존하는 페이지가 410을 내는데 CMS에서 원인을 못 찾겠다면, 배포나 리버스 프록시를 소유한 사람에게 넘기세요 — 엣지의 규칙(WAF, 리다이렉트 맵, 오래된 rewrite)이 요청이 애플리케이션에 닿기도 전에 410을 반환할 수 있습니다.
• 지키려는 URL을 Google이 빼고 있고 410이 실수로 확인됐다면, 먼저 코드를 고친 뒤 Search Console로 재색인을 요청하세요. 회복은 즉시가 아니며, 잘못된 410이 오래 돌았을수록 순위가 다시 쌓이는 데 오래 걸립니다.