본문으로 바로가기
AD Insight
홈페이지 운영

이미지 파일은 있는데 블로그 썸네일이 안 보였던 기록

HTTPS 화면에서 블로그 썸네일이 보이지 않아 파일과 캐시를 따로 확인했다. 캐시에 남은 이전 HTTP 주소를 정리하고 당시 확인한 범위와 남은 한계를 적었다.

확인한 환경
그누보드 기반 사이트 · HTTPS 메인 · 네이버 블로그 RSS 캐시
확인 날짜
이 글의 목차

내가 관리하던 사이트의 HTTPS 메인에서 네이버 블로그 썸네일이 제대로 보이지 않은 적이 있다. 일단 이미지 파일부터 확인했다. 서버에는 파일이 있었는데 피드가 가리키는 주소는 다른 상태였다.

2026-08-11 작업 기록과 당시 보관한 캐시·소스를 다시 읽었다. 문제를 겪던 브라우저 화면은 찾지 못했으므로 이 글에는 수정 전후 화면 대신 보관 소스의 일부를 사용했다.

파일이 있는 곳과 캐시 주소가 달랐다

당시 캐시 JSON에는 블로그 글 3건이 있었다. 세 항목의 썸네일 값이 모두 이전 운영 도메인의 HTTP 절대 주소를 가리켰다. 현재 서버에 파일이 있다는 사실만 확인해서는 화면이 그 파일을 불러온다고 볼 수 없었다.

HTTPS 문서에서 이전 HTTP 주소를 요청한 것이 문제와 관련됐을 가능성이 있었다. 다만 당시 브라우저의 혼합 콘텐츠 차단 로그는 확보하지 못했다. 그래서 브라우저가 바로 그 이유로 차단했다고 단정하지는 않는다. 확인한 것은 캐시 주소에 이전 도메인이 남아 있었다는 점이다.

캐시에서 꺼낸 주소도 다시 확인하게 했다

수정본에서는 캐시에 저장된 썸네일 URL에서 경로를 읽었다. 지정된 썸네일 캐시 경로에 해당하면 현재 사이트의 상대 경로로 돌려주도록 했다. 이전 도메인이 캐시에 남아 있어도 반환할 주소를 다시 맞추는 방식이었다.

주소만 바꾸지는 않았다. 실제 파일이 없거나 너무 작으면 정상 캐시로 쓰지 않도록 검사했다. 이 구현에서는 파일 크기가 512바이트 이하일 때 유효한 썸네일로 보지 않았다. 이 수치는 해당 코드의 조건이며 모든 이미지에 적용할 기준으로 제시하는 것은 아니다.

보관된 PHP 소스에서 썸네일 경로 정규화와 파일 존재·크기 검사 부분을 연 화면
당시 저장 소스 일부를 2026-10-24에 열어 확인한 화면. 당시 브라우저 화면이 아니다. 고객명·도메인·계정이 없는 코드 구간만 사용했다.

새로 받은 파일과 기존 파일의 경로를 맞췄다

썸네일이 빠지거나 파일 상태가 맞지 않으면 피드를 다시 수집하도록 연결했다. 새로 저장한 파일뿐 아니라 이미 저장된 파일을 재사용할 때도 현재 사이트의 상대 경로를 반환하게 했다.

배포 전 서버 파일과 캐시 JSON은 따로 보관했다. 지금 남아 있는 수정 전후 PHP를 비교해도 캐시를 읽은 뒤 URL을 정규화하는 호출과 파일 검사 조건을 확인할 수 있다. 캐시 JSON 자체는 고객의 글 제목과 계정·주소가 있어 공개 이미지로 옮기지 않았다.

당시에는 썸네일 3개와 기존 카드를 함께 봤다

작업보고서에는 PHP 8.5 문법 검사 통과와 PC·모바일에서 블로그 썸네일이 각각 3개 표시됐다는 결과가 남아 있다. 썸네일 3개가 당시 HTTPS 주소에서 HTTP 200과 image/jpeg로 응답했다는 기록도 있다.

기존 건강칼럼 3개가 함께 남아 총 6개 피드 구성을 유지한 것으로 기록돼 있다. 이 숫자는 당시 점검 결과다. 이번 글을 쓰면서 같은 서버에 다시 요청해 확인한 값은 아니다.

다음에는 주소와 응답 기록을 같이 남기려고 한다

같은 문제가 생기면 파일 존재, 캐시의 실제 URL, 브라우저 요청 결과를 나눠 보려고 한다. 파일이 있다고 주소까지 맞는 것은 아니었고 캐시가 있다고 그 내용이 여전히 유효한 것도 아니었다.

이번 기록에는 당시의 차단 콘솔과 브라우저 캡처가 없어 원인을 더 좁힐 자료가 부족하다. 현재 정상 상태가 계속되는지나 검색 노출·유입이 늘었는지도 확인하지 않았다. HTTPS 전환 뒤 주소를 함께 점검하는 순서는 HTTPS 설치 후 주소 확인 글에서 이어 볼 수 있다.

목록으로