천사티비 주소가 열려도 글이 사라질 때

무엇을 바꾸고 무엇을 고정했나요?

2026-11-04에 로컬 Python HTTP 서버와 HTTPConnection으로 GET 요청을 보냈습니다. 같은 글을 직접 주는 경우, 글로 이동시키는 경우, 홈으로 보내는 경우, 없는 페이지로 보내는 경우를 만들었습니다. 네 조건마다 세 번 실행했고, 각 응답의 상태·Location·본문 제목을 기록했습니다.

로그인, 쿠키, DNS 변경, 이동통신망 차이는 이번 실험의 변수가 아닙니다. 외부 바로가기의 실제 동작을 이 결과로 대신 판정하지 않습니다. 단순한 주소 이동에서 상태 코드와 목적 화면이 어떻게 엇갈릴 수 있는지 확인한 실험입니다.

열두 번 확인한 결과

12회 응답과 본문 제목 원기록(JSON)에는 각 요청 경로와 이동 대상이 함께 있습니다. 빈 응답으로 끝나는 302와 실제 문서를 돌려주는 마지막 응답을 한 줄의 성공 표시로 합치지 않았습니다.

같은 200인데 왜 결과가 달랐을까요?

200은 이번 요청에 응답이 왔다는 뜻이지, 이용자가 원한 글을 받았다는 뜻까지 담고 있지는 않습니다. 글을 유지한 조건과 홈으로 보낸 조건은 두 번째 요청에서 서로 다른 내용을 받았습니다. 원래 글 경로가 이동 과정에서 보존됐는지를 따로 봐야 이 차이가 드러납니다.

MDN의 302 설명은 Location이 알려 주는 다른 주소로 일시적으로 이동하는 응답을 설명합니다. 이 실험은 GET만 사용했으므로 로그인 제출이나 결제 요청처럼 메서드가 중요한 흐름의 검증 결과로 확대하지 않습니다.

404도 “전체 서버가 꺼졌다”는 증거는 아닙니다. 이번에는 서버가 계속 응답했지만 요청한 /missing 문서가 없었습니다. 404의 정의와 함께 보면, 한 글의 실패와 전체 사이트 접속 실패를 나눠 기록할 이유가 분명해집니다.

사용자는 어떤 정보를 남기면 될까요?

1. 원래 열려던 화면: 홈페이지인지, 특정 글인지 먼저 적습니다.
2. 마지막 주소의 경로: 이동 뒤에도 글 경로가 남아 있는지 확인합니다. 인증값이 포함된 전체 주소를 공개할 필요는 없습니다.
3. 도착한 화면: 홈, 오류 안내, 원래 글 중 실제로 무엇이 표시됐는지 적습니다.
4. 재현 조건: 한 번만 발생했는지, 같은 링크에서 반복되는지 구분합니다.

일반 방문자에게 개발자 도구가 필수는 아닙니다. “글 링크를 눌렀는데 홈이 열렸다”는 설명만으로도 “사이트가 안 된다”보다 상황이 정확해집니다. 도구를 사용할 수 있다면 Network의 문서 요청에서 상태와 Location을 추가합니다.

관찰별로 다음 행동도 달라집니다

성공 코드만 보는 방식은 빠르지만 경로 손실을 놓칩니다. 반대로 화면만 보면 서버 응답을 알 수 없습니다. 목적 경로와 도착 화면을 먼저 기록하고, 가능한 경우 응답 코드를 붙이는 순서가 이번 실험에서 얻은 가장 유용한 기준입니다.