지웠는데 검색에 남는 이유 — 캐시와 색인의 원리

이름을 검색했을 때 나오는 결과는 인터넷의 '지금'이 아닙니다. 검색엔진이 과거 어느 시점에 수집해 둔 사본입니다. 게시물을 지웠는데도 검색에 한동안 남는 이유, 그리고 그 잔상이 지워지는 경로를 이 기록에 정리합니다. 원리를 알면, 남아 있는 잔상이 왜 남았는지 그리고 언제 어떤 경로로 사라질지를 읽을 수 있게 됩니다.

검색은 실시간이 아닙니다

검색창에 단어를 입력하면 1초 안에 결과가 나옵니다. 그 속도가 가능한 이유는 검색엔진이 질문을 받은 순간 웹 전체를 뒤지는 것이 아니라, 미리 만들어 둔 저장고에서 꺼내 보여주기 때문입니다. 검색결과에 보이는 제목과 두 줄 요약은 모두 그 저장고에 들어 있던 사본입니다.

저장고는 세 단계로 채워집니다. 크롤러라 불리는 수집 프로그램이 웹페이지를 읽어 오고(크롤링), 읽어 온 내용을 검색 가능한 형태로 정리해 목록에 올리고(색인), 페이지 내용의 일부를 보관해 둡니다(캐시·저장본). 검색은 이 목록과 저장본을 뒤지는 일이고, 저장고를 정기적으로 새로 고치는 일까지가 검색엔진의 일과입니다.

그래서 원본과 검색 사이에는 항상 시차가 있습니다. 원본이 지워져도 저장고가 갱신되기 전까지 검색은 옛 사본을 계속 보여줍니다. '지웠는데 검색에 남아 있다'는 경험은 버그가 아니라 이 구조의 자연스러운 결과입니다.

이 구조는 구글, 네이버, 다음 어디든 기본적으로 같습니다. 수집하고, 정리하고, 사본으로 보여줍니다. 서비스마다 다른 것은 수집의 빈도, 사본을 보관하는 기간, 그리고 갱신 요청을 받아 주는 창구의 모양이지, 사본으로 작동한다는 원리 자체가 아닙니다. 그래서 이 기록의 원리 설명은 특정 검색엔진에 한정되지 않으며, 어느 검색에서 잔존을 발견하든 같은 틀로 읽을 수 있습니다.

캐시·스니펫·색인 — 헷갈리는 세 단어

삭제 요청을 다루다 보면 캐시, 스니펫, 색인이라는 단어가 섞여 쓰입니다. 셋은 서로 다른 층위에 있고, 지워지는 경로도 다릅니다. 어디에 무엇이 남아 있는지를 구분해야 어느 창구에 요청할지가 정해지고, 요청서에 이 셋을 섞어 쓰면 처리도 함께 섞입니다.

쉽게 말해 색인은 도서관의 도서 목록, 스니펫은 목록 카드에 적힌 줄거리, 캐시는 서고에 보관된 복사본입니다. 책을 회수해도 목록과 카드가 정리되기 전까지는 그 책이 여전히 서가에 있는 것처럼 보입니다. 잔존을 발견했을 때 '책이 아직 있다'고 항의할 곳과 '목록을 고쳐 달라'고 요청할 곳이 다른 이유이기도 합니다.

참고로 구글은 검색결과에서 저장된 페이지를 직접 열어 보던 공개 캐시 기능을 사실상 거둬들였습니다. 그러나 스니펫과 미리보기는 여전히 수집 시점의 저장본을 바탕으로 만들어지므로, 사용자 눈에는 '지운 내용이 보이는' 상태가 유지될 수 있습니다.

썸네일도 같은 원리로 남습니다. 검색결과나 모바일 화면에 보이는 작은 미리보기 이미지는 수집 시점에 만들어 둔 사본이므로, 원본 이미지가 내려간 뒤에도 한동안 표시될 수 있습니다. 잔존을 점검할 때 본문 잔존과 이미지 잔존을 따로 세어야 하는 이유가 여기에 있습니다.

원본을 지운 뒤, 검색이 갱신되는 경로

원본이 삭제되면 그다음은 크롤러의 재방문, 즉 재크롤에 달려 있습니다. 크롤러는 모든 페이지를 같은 빈도로 돌지 않습니다. 자주 바뀌는 페이지는 자주 들르고, 오래 잠잠한 게시판은 드물게 들릅니다. 분 단위로 갱신되는 뉴스 홈과 몇 년 묵은 게시글의 재방문 주기는 전혀 다릅니다. 통상 며칠에서 몇 주 사이지만, 페이지에 따라 더 길어질 수 있습니다.

재방문한 크롤러가 '페이지가 없다'는 응답을 확인하면 색인에서 내리는 절차가 시작됩니다. 일시적인 서버 오류와 구분하기 위해 한 번이 아니라 여러 번 확인한 뒤에 제거하는 경우도 있어, 원본 삭제와 검색 반영 사이에 또 한 번의 시차가 생깁니다.

한 가지 흔한 함정은 '지워졌지만 지워졌다고 말하지 않는 페이지'입니다. 게시판에 따라 삭제된 글의 주소로 들어가면 '삭제된 게시물입니다'라는 안내문을 정상 페이지처럼 보여주는 경우가 있습니다. 사람 눈에는 분명히 지워진 글이지만, 크롤러 입장에서는 페이지가 멀쩡히 응답하고 있으니 삭제로 인식하지 못합니다. 색인이 예상보다 오래 남는다면 이 경우를 의심해 볼 수 있고, 이때는 공식 갱신 요청 창구가 더 유효합니다.

1. 원본 삭제 — 게시판·플랫폼에서 페이지가 내려갑니다.
2. 크롤러 재방문 — 페이지마다 다른 주기로 다시 찾아옵니다.
3. 삭제 확인 — '페이지 없음' 응답을 확인합니다. 여러 차례 확인하기도 합니다.
4. 색인·스니펫 갱신 — 검색결과에서 항목이 내려가거나 새 내용으로 교체됩니다.

이 네 단계는 기다리면 대부분 끝까지 갑니다. 문제는 그 기간 동안 노출이 계속된다는 것, 그리고 단계마다 걸리는 시간을 바깥에서 알 수 없다는 것입니다. 그래서 노출이 만드는 피해가 큰 사안일수록, 기다리는 대신 다음 절의 공식 창구로 갱신을 앞당깁니다.

갱신을 앞당기는 공식 창구

구글에는 '오래된 콘텐츠 갱신' 도구가 있습니다. 원본 페이지가 이미 삭제됐거나 내용이 바뀌었는데 검색결과에 옛 정보가 남아 있을 때, 해당 검색결과의 갱신이나 제거를 요청하는 창구입니다. 요청 후의 진행 상태도 도구 안에서 확인할 수 있습니다. 원본이 살아 있는 상태에서는 통하지 않습니다 — 이 도구는 검색을 현실에 맞추는 도구이지, 현실을 바꾸는 도구가 아닙니다.

네이버는 고객센터를 통해 검색 반영을 요청할 수 있습니다. 본인 게시물을 삭제했는데 검색에 반영되지 않을 때, 또는 권리침해 게시물이 조치된 뒤에도 검색결과가 남아 있을 때 쓰는 경로입니다. 처리 기준과 양식은 서비스별로 다르므로 고객센터의 최신 안내를 따르는 편이 빠릅니다.

두 창구 모두 '이미 일어난 삭제를 검색에 반영해 달라'는 요청이라는 점을 기억해야 합니다. 원본이 살아 있는 게시물을 검색에서 내리고 싶다면 그것은 갱신 요청이 아니라 권리침해 신고의 영역이고, 요건과 절차가 전혀 다릅니다. 두 경로를 섞어 쓰면 양쪽 모두에서 반려되기 쉽습니다. 순서는 언제나 같습니다 — 원본을 먼저, 검색을 나중에.

운영 관점에서 한 가지를 덧붙이면, 실무에서는 '원본 삭제'가 아니라 '검색 표면에서 사라진 시점'을 종결로 봅니다. 원본·색인·스니펫·이미지가 각각 다른 속도로 지워지기 때문에, 표면별로 상태를 따로 기록하고 갱신 요청 이후에도 재확인을 반복하는 방식이 잔존을 줄입니다. 이런 표면 장부가 있으면 '다 지웠는데 왜 보이느냐'는 막막한 질문이 '어느 표면이 며칠째 남아 있다'는 다룰 수 있는 사실로 바뀝니다.

이미지 검색에만 남는 경우

글은 지워졌는데 이미지 검색에는 사진이 남는 경우가 있습니다. 많은 사이트가 글(HTML)과 이미지 파일을 서로 다른 서버에 나눠 저장하기 때문입니다. 이미지 전송에 특화된 별도 서버망(CDN)에 파일을 올려 두는 구조가 일반적입니다.

이 구조에서는 게시글을 삭제해도 이미지 파일의 주소가 한동안 살아 있을 수 있습니다. 검색엔진의 이미지 색인은 그 파일 주소를 바라보고 있으므로, 글이 사라진 뒤에도 썸네일이 이미지 검색에 남는 일이 생깁니다.

이미지 잔존은 글 잔존보다 발견도 늦습니다. 본인 이름을 검색해 보는 사람은 많아도 이미지 탭까지 확인하는 사람은 적기 때문입니다. 점검할 때는 일반 검색과 이미지 검색을 별개의 표면으로 두고, 각각 확인한 시각과 상태를 기록해 두는 편이 안전합니다.

대응 순서는 본문과 같습니다. 먼저 이미지 파일 주소에 직접 접속해 파일이 지워졌는지 확인하고, 살아 있다면 플랫폼에 파일 삭제까지 요청합니다. 파일이 사라진 뒤에 이미지 검색결과에 대한 갱신 요청을 넣습니다. 글 삭제만 확인하고 끝내면 이미지 잔존을 놓치기 쉽습니다. 특히 얼굴이 나온 사진이 걸린 사안이라면 이미지 표면을 기본 점검 항목에 넣어야 합니다.

기다림과 요청 사이 — 무엇이 합리적인가

모든 잔존에 갱신 요청이 필요한 것은 아닙니다. 노출이 적은 페이지라면 재크롤을 기다리는 것만으로 충분한 경우가 많고, 한두 주 안에 자연히 갱신될 잔존에 매일 마음을 쓰는 것은 소모적입니다. 반대로 이름 검색 첫 화면에 뜨는 결과라면 기다림의 비용이 크므로, 공식 창구를 바로 쓰는 편이 합리적입니다.

판단 기준은 단순합니다. 그 검색결과를 실제로 보는 사람이 얼마나 되는가, 그리고 그 노출이 지금 어떤 피해를 만들고 있는가입니다. 이름이나 상호로 검색했을 때 첫 페이지 안에 보이는 잔존은 우선 처리하고, 그 밖은 주기 점검으로 돌리는 우선순위가 통상적입니다.

갱신 요청에는 비용이 들지 않지만, 건수가 많아지면 시간이 듭니다. 검색어 몇 개를 기준으로 잡고 — 통상 본인 이름, 상호, 사건과 연결된 단어 조합 — 그 검색어의 첫 한두 페이지를 표면 목록으로 관리하면, 모든 잔존을 쫓는 것보다 훨씬 적은 노력으로 노출의 대부분을 다룰 수 있습니다.

마지막으로, 삭제와 갱신이 끝나도 사본이 다른 곳에 다시 올라오면 같은 과정이 처음부터 반복됩니다. 그래서 잔존 관리의 다음 단계는 검색이 아니라 감시입니다. 사본이 만들어지는 경로와 그 길목을 지키는 방법은 형제 기록 '재유포 감시의 방법'에서 이어집니다.