분명 이 주소 눌렀는데, 왜 다른 주소로?

예전에 저장한 안내문 링크를 눌렀습니다. 분명 끝이 old-guide였는데, 열리고 보니 주소창에는 new-guide가 적혀 있습니다.

뒤로 가서 다시 눌러 봅니다. 또 같은 곳입니다. 손가락은 한 번 눌렀는데, 주소는 중간에 갈아탄 것 같습니다.

지도를 다시 살피는 장면은 도착한 주소가 달라 당황한 상황의 비유입니다. 실제 링크를 추적하거나 웹사이트 이동을 시험한 화면이 아닙니다.

처음 주소가 새 주소를 안내할 수 있습니다

사이트에서 옛 안내문 주소를 새 주소로 연결해 둔 경우를 생각해 봅시다. 처음 주소로 요청을 받은 서버가 문서 내용 대신 “이 주소로 다시 요청해 주세요”라는 이동 안내를 보낼 수 있습니다. 브라우저가 그 안내를 따라 새 주소를 요청하면, 사용자에게는 주소가 저절로 바뀐 것처럼 보입니다.^[1]

이런 흐름을 리디렉션이라고 부릅니다. HTTP에서는 301이나 302 같은 이동 응답과 함께 다음 주소를 알려줍니다. 링크를 잘못 눌러야만 생기는 일이 아닙니다.

여기서 Location은 이런 이동 응답에서 다음에 요청할 주소를 가리키는 헤더입니다. 예시처럼 /new-guide라는 경로일 수도 있고, https로 시작하는 전체 주소일 수도 있습니다.^[2]

브라우저가 요청을 한 번 더 보냈다는 것이 핵심입니다. 서버 안의 실제 파일이 어디로 옮겨졌는지까지 보여 주는 증거는 아닙니다.

옛 링크를 살려 두는 방법이기도 합니다

사이트가 글 주소나 도메인을 바꾸더라도, 이미 공유된 링크와 북마크를 모두 고칠 수는 없습니다. 옛 주소에서 새 주소를 안내하면 기존 링크를 통해 찾아온 사람도 새 위치로 이어질 수 있습니다.^[1]

가게 문 앞에 “입구를 옆으로 옮겼습니다”라는 안내를 남겨 두는 것과 비슷합니다. 처음 찾아간 주소가 틀렸다기보다, 그 주소가 다음 위치를 알려 준 셈입니다. 같은 사이트 안에서 경로만 바뀌는 경우도 있고, 다른 도메인으로 이어지는 경우도 있습니다.

대표적으로 301은 영구 이동, 302는 임시 이동을 알리는 상태 코드입니다.^[3] 숫자는 서버가 이 이동을 어떻게 안내하는지 나타냅니다. 주소창만 보고 둘 중 어떤 응답이었는지 알아낼 수 있는 것은 아닙니다.

주소가 바뀌었다고 모두 같은 원인은 아닙니다

서버의 HTTP 이동 응답만 방법인 것은 아닙니다. 페이지의 HTML 설정이나 자바스크립트가 다른 주소로 이동시키는 경우도 있습니다.^[1] 그래서 주소가 달라졌다는 관찰만으로 “이 사이트는 301을 보냈다”고 확정하면 안 됩니다.

앞서 본 40편의 퍼센트 인코딩은 주소의 문자를 옮겨 적는 규칙이고, 45편의 앱 연결은 링크를 어떤 프로그램이 맡아 여는지에 관한 이야기였습니다. 이번 글에서는 처음 요청한 주소가 다음 요청할 주소를 안내하는 흐름에 집중합니다.

또 리디렉션 자체가 안전한 목적지를 보증하는 표시는 아닙니다. 정상적인 주소 정리에도 쓰이므로 무조건 오류나 위험이라고 볼 수도 없지만, 예상과 다른 사이트에 도착했다면 최종 주소와 내용을 확인해야 합니다.

다음에는 도착한 주소까지 확인하기

• 처음 받은 링크와 최종 주소를 비교합니다. 도메인이 달라졌는지, 같은 사이트에서 경로만 바뀌었는지 봅니다.
• 기대한 서비스와 문서가 맞는지 확인합니다. 예상하지 못한 로그인·결제 요청이 나오면 바로 입력하기보다 알고 있는 공식 주소에서 다시 찾아갑니다.
• 여러 주소를 계속 오가거나 오류가 나면 반복해서 누르기보다 원래 사이트의 안내와 문의 경로를 확인합니다. 화면만으로 이동 설정의 원인을 단정하지 않습니다.

손가락은 한 번 눌렀지만 브라우저는 안내를 받고 한 번 더 찾아갔을 수 있습니다. 처음 주소와 마지막 주소 사이에, 짧은 길 안내가 있었던 겁니다.