301·302·307·308 리디렉션 차이｜짧은 링크 상태 코드를 고르는 법
일반적인 짧은 링크처럼 사용자를 다른 페이지로 보내는 GET 요청이라면 목적지가 오래 유지될 때 301, 캠페인 종료 후 다시 바꿀 가능성이 있을 때 302가 가장 단순합니다. 307과 308은 POST처럼 요청 메서드와 본문을 그대로 보존해야 할 때 선택합니다. 숫자가 비슷해도 영구성·메서드 보존·캐시 영향이 다르므로 먼저 링크의 수명과 요청 종류를 확인해야 합니다.
301·302·307·308은 무엇이 다를까?
네 상태 코드는 모두 Location 헤더에 적힌 새 주소로 브라우저를 이동시키지만 의미는 두 축으로 갈립니다. 301과 308은 영구 이동, 302와 307은 임시 이동입니다. 또 307과 308은 원래 요청의 메서드와 본문을 바꾸지 않는다는 보장이 분명합니다. MDN의 307 설명은 307이 302와 달리 요청 메서드와 본문을 재사용한다고 밝힙니다.
| 상태 코드 | 이동 의미 | 메서드 처리 | 대표 상황 |
| 301 | 영구 | 일부 클라이언트가 POST를 GET으로 바꿀 수 있음 | 페이지 주소 영구 변경 |
| 302 | 임시 | 일부 클라이언트가 GET으로 바꿀 수 있음 | 목적지를 자주 교체하는 공유 링크 |
| 307 | 임시 | 메서드와 본문 보존 | 일시적인 API·폼 경로 이동 |
| 308 | 영구 | 메서드와 본문 보존 | 요청 방식까지 유지하는 영구 이전 |
짧은 링크에는 301과 302 중 무엇이 맞을까?
짧은 링크의 목적지를 나중에 바꿀 수 있게 운영한다면 302가 보수적인 선택입니다. 브라우저와 중간 캐시가 이전 목적지를 영구 위치로 기억할 가능성을 낮춰 관리 화면에서 목적지를 바꾼 뒤 새 위치로 보내기 쉽습니다. 반대로 단축 주소와 목적지의 관계를 앞으로 바꾸지 않을 것이 확실하고 검색엔진에도 영구 이동으로 알리고 싶다면 301을 고려할 수 있습니다.
Google Search의 리디렉션 안내는 301과 308을 영구 서버 측 리디렉션으로, 임시 이동은 임시 리디렉션으로 구분합니다. 다만 짧은 링크 자체를 검색 결과에 올리는 것이 목적이 아니라면 SEO 신호보다 링크 관리 방식과 캐시 문제를 먼저 보는 편이 현실적입니다.
307과 308은 언제 필요한가요?
사용자가 클릭하는 일반 링크는 대부분 GET 요청이라 302와 307의 체감 차이가 작습니다. 차이는 폼 제출이나 API 호출처럼 POST·PUT 메서드와 요청 본문이 있는 상황에서 커집니다. 임시 이동 뒤에도 같은 POST를 보내야 하면 307, 영구 이전 뒤에도 같은 메서드와 본문을 보존해야 하면 308이 의도에 맞습니다.
결제·신청처럼 중복 제출 위험이 있는 요청은 상태 코드만 보고 바꾸면 안 됩니다. 목적지 서버가 같은 본문을 안전하게 처리하는지, 재시도 시 중복 작업이 생기지 않는지, 인증 헤더가 다른 도메인으로 넘어가도 되는지까지 별도로 확인해야 합니다. 단순 공유용 짧은 링크와 업무 처리 API는 같은 리디렉션 정책을 쓰지 않는 편이 안전합니다.
영구 리디렉션을 잘못 쓰면 어떤 문제가 생길까?
목적지를 자주 교체해야 하는 링크에 301이나 308을 쓰면 일부 브라우저와 캐시가 옛 목적지를 오래 기억할 수 있습니다. 서버 설정을 바꿨는데도 특정 사용자에게만 이전 페이지가 보이면 서버 장애처럼 느껴지지만 실제 원인은 캐시일 수 있습니다. 배포 전에 시크릿 창, 다른 네트워크, 캐시를 비운 브라우저에서 각각 확인해야 합니다.
- 캠페인 링크처럼 목적지가 바뀔 수 있으면 임시 상태를 우선합니다.
- 영구 이전은 이전 주소를 다시 쓰지 않을 때만 적용합니다.
- POST·PUT 요청은 메서드가 유지되어야 하는지 확인합니다.
- 리디렉션이 두 번 이상 이어지지 않게 최종 목적지로 바로 연결합니다.
- HTTP에서 HTTPS로 이동한 뒤 다시 다른 주소로 보내는 연쇄를 줄입니다.
- Location 헤더에 완전한 최종 주소가 들어가는지 검사합니다.
실제 상황에서는 어떻게 선택할까?
사례 1: 행사 안내 짧은 주소
행사 전에는 신청 페이지, 행사 당일에는 안내 페이지, 종료 뒤에는 결과 페이지로 같은 짧은 주소의 목적지를 바꿔야 했습니다. 운영자는 302를 유지하고 목적지만 단계별로 교체했습니다. 그 결과 사용자가 저장해 둔 같은 주소를 계속 쓰면서도 영구 캐시 때문에 옛 신청 화면에 머무는 문제를 줄였습니다.
사례 2: API 경로 영구 이전
POST 본문을 받는 API가 새 도메인으로 완전히 이전됐고 기존 클라이언트를 한 번에 바꾸기 어려웠습니다. 개발팀은 단순 301 대신 메서드 보존이 명확한 308을 검토하고, 중복 처리 방지 키와 인증 전달을 시험했습니다. 충분한 호환성 검증 뒤 구형 경로를 단계적으로 종료했습니다.
배포 전에 어떻게 검증할까?
- 링크가 영구인지 임시인지 문장으로 먼저 정의합니다.
- GET 외의 메서드가 들어오는지 서버 로그와 호출 코드를 확인합니다.
- curl의 응답 헤더에서 상태 코드와 Location 값을 확인합니다.
- 리디렉션을 따라간 최종 주소와 전체 이동 횟수를 기록합니다.
- 모바일 앱 안 브라우저와 데스크톱 브라우저에서 같은 결과인지 봅니다.
- 목적지를 바꾼 뒤 캐시된 사용자가 새 위치로 갈 수 있는지 재시험합니다.
검증은 최종 화면이 열리는지만 보면 부족합니다. 최초 응답의 상태 코드, 중간 경유지, 최종 상태를 나눠 확인해야 어느 단계에서 잘못됐는지 알 수 있습니다. 짧은 링크를 새로 만들 때도 임시 이동이 기본인지, 서비스가 목적지 변경을 허용하는지 함께 확인하세요.
확인한 출처
관련 도구
FAQ
짧은 링크는 무조건 301이어야 하나요?
아닙니다. 목적지를 바꿀 가능성이 있으면 302 같은 임시 이동이 관리하기 쉽고, 영구 이동이 확실할 때만 301을 고려합니다.
302와 307은 GET 링크에서도 다른가요?
GET 요청에서는 결과가 비슷하지만 POST·PUT처럼 본문이 있는 요청은 307이 메서드와 본문 보존을 명확히 보장합니다.
301을 적용했다가 302로 바꾸면 바로 반영되나요?
서버 설정은 바뀌어도 브라우저나 중간 캐시에 이전 301이 남을 수 있어 시크릿 창과 다른 기기에서 따로 확인해야 합니다.
리디렉션이 여러 번 이어져도 괜찮나요?
작동할 수는 있지만 지연과 실패 지점이 늘어나므로 가능하면 한 번의 이동으로 최종 목적지에 도착하도록 정리하는 편이 좋습니다.
← 허브로 돌아가기