새 썸네일인데 왜 아직 예전 것이 보이나

먼저 두 문제를 분리하라

“썸네일이 갱신되지 않는다”와 “썸네일이 보이지 않는다”는 겉으로 같아 보이지만 서로 아무 상관이 없다. 앞의 것은 캐시 문제이고 알아서 해결된다. 뒤의 것은 파일이나 권한 문제이고, 당신이 뭔가를 하지 않으면 해결되지 않는다.

판별에는 십 초가 걸린다. 예전 이미지가 보이는가, 아니면 이미지가 아예 없는가? 예전 이미지라면 캐시된 사본이고, 다음 몇 절이 전부 해당된다. 회색 상자, 검은 화면, 또는 당신이 고르지 않은 영상 캡처가 보인다면 맞춤 썸네일이 아예 적용되지 않은 것이다. 마지막 두 절로 건너뛰라. 실제로 하고 싶은 일이 썸네일 교체라면 — 절차, 무엇이 초기화되는지, 오래된 영상이 그럴 값을 하는지 — 썸네일 바꾸기 가이드를 보세요.

모든 것을 설명하는 숫자 하나

썸네일은 i.ytimg.com에서 제공되고, 이 호스트는 모든 응답에 캐싱 규칙을 담아 보낸다. 세 가지 다른 파일 — 정적 hqdefault.jpg, 정적 maxresdefault.jpg, 그리고 인터페이스가 실제로 쓰는 매개변수 붙은 WebP 크롭 하나 — 을 요청했고, 셋 다 같은 답을 돌려줬다.

대부분의 경우 두 시간이 이야기의 전부다. 유튜브가 당신의 변경을 느리게 처리하는 것이 아니다. 변경은 이미 끝났다. 유튜브의 저장소와 당신의 눈 사이에 있는 모든 캐시가, 올바르게, 가진 것을 계속 내보내도 된다고 들었을 뿐이다.

그리고 URL은 절대 바뀌지 않는다

이것이 두 시간을 중요하게 만드는 부분이다. 썸네일은 영상 id로 만든 경로에 놓인다 — i.ytimg.com/vi/<id>/hqdefault.jpg — 그리고 그 안에는 이미지의 어느 버전인지 말해주는 것이 없다. 썸네일을 바꿔도 주소는 바이트 단위로 동일하므로, 예전 바이트를 들고 있는 캐시는 멈춰야 한다는 사실을 알 방법이 없다.

매개변수가 붙은 변형은 서명처럼 보이는 값을 달고 있어서, 다르게 동작하는지 확인해 봤다. 아니었다. rs 토큰을 훼손해도 유효한 이미지가 돌아왔고, sqp 매개변수를 훼손하면 오류가 아니라 다른 크기의 이미지가 돌아왔다. 그 매개변수들은 크롭을 서술하는 것이고 버전 도장이 아니다. URL 공간에는 버전이 없다.

즉 이 구조에는 당신이 촉발할 수 있는 무효화 단계가 없다. 캐시된 썸네일은 삭제되지 않는다. 만료될 뿐이다.

누가 사본을 들고 있나

별개의 캐시 넷, 별개의 시계 넷. 갱신이 그렇게 앞뒤가 안 맞아 보이는 이유다. 휴대폰에서는 새것, 노트북에서는 예전 것, 친구에게는 예전 것, 시크릿 창에서는 새것.

당신의 브라우저. 두 시간 지시와 함께 이미지를 디스크에 갖고 있고, 그 시간이 끝날 때까지 다시 묻지 않는다.

당신에게 응답한 CDN 엣지. age 헤더가 응답 시점에 그 사본이 얼마나 오래됐는지 알려준다. 같은 파일에서 0초부터 2371초까지 봤다. 엣지가 다르면 나이도 다르니, 다른 네트워크에 있는 두 사람이 서로 다른 이미지를 보는 것은 정상이다.

링크 미리보기를 긁어간 모든 앱. 메신저, 슬랙, 디스코드, 게시판은 미리보기 이미지의 사본을 자기 일정에 따라 보관하는데, 보통 두 시간보다 훨씬 길고 당신이 통제할 수 없다.

임베드와 서드파티 클라이언트. 정적 경로를 쓰는 것은 모두 같은 두 시간 지시를 받고, 자기 사본을 저장하는 것은 원하는 만큼 오래 들고 있는다.

지금 당장 현재 파일을 보는 방법

변경이 반영됐는지 알기 위해 기다릴 필요는 없다. 기다림은 남들이 보게 되기까지의 시간일 뿐이다. 값싼 순서로 세 가지 확인이 있고, 대부분에게는 첫 번째로 충분하다.

첫 번째의 원리는 캐시가 쿼리 문자열까지 포함한 URL 전체를 키로 쓴다는 점이다. 그래서 당신이 아무렇게나 붙인 매개변수는 새 키가 되고, 따라서 새로 받아오는 것이 보장된다. 확인해 봤다. hqdefault.jpg?cb=12345는 200을 돌려줬고 바이트는 깨끗한 URL과 정확히 같았으며 etag도 같았다. 원하는 결과가 바로 그것이다. 다른 이미지가 아니라, 사실의 새 사본.

1. 아무 매개변수를 붙여 파일을 열어보라새 탭에 i.ytimg.com/vi/<영상 id>/maxresdefault.jpg?cb=1 을 붙여 넣으라. 물음표 뒤에는 무엇이든 되고, 매번 바꾸면 된다. 보이는 것이 지금 유튜브 저장소에 있는 것이며, 중간에 캐시가 없다.
2. 증거가 필요하면 터미널에서 etag를 확인하라같은 URL에 curl -I 를 하면 cache-control, etag, age가 출력된다. etag를 적어두고 변경한 뒤 다시 요청하라. etag가 달라졌다면 저장된 파일이 정말 다른 이미지라는 뜻이다. 브라우저가 여전히 무엇을 보여주든 상관없다.
3. 그다음에야 피드를 보라파일 자체가 맞다면 남은 차이는 캐시의 나이이고 업로드 문제가 아니다. 파일에 무엇을 해도 남의 사본이 더 일찍 만료되지는 않는다.

할 일과 하지 말 일

할 일은, 두 시간 동안 아무것도 하지 않기다. 만족스럽지 않은 문장이고, 흔한 경우에는 그것이 처방의 전부다. 변경은 이미 저장되어 있고 남은 것은 시계뿐이다.

하지 말 일이 말할 가치가 있는 쪽이다. 영상을 다시 올리지 말라. 썸네일은 같은 영상 id에 붙은 별개의 객체이고, 새로 올리면 그 영상의 모든 노출과 모든 댓글을 버리게 된다. 기다리면 해결될 문제 때문에 말이다. “강제로” 반영시키려고 썸네일을 또 바꾸지도 말라. 바꿀 때마다 초기화되는 것은 없고, 새 이미지에 대해 두 시간이 새로 시작된다. 십 분짜리 문제가 반나절이 되는 경로가 그것이다.

그리고 영상이 썸네일 테스트 중이라면, 진행 중에 무언가를 바꾸는 것이야말로 측정 가능한 손해를 실제로 내는 유일한 행동이다. 이유는 A/B 테스트 가이드에 있다. 지금 읽고 있는 숫자가 어느 변형에서 나온 것인지 더는 알 수 없게 된다.

링크 미리보기는 당신이 통제하지 못하는 캐시다

당신 영상 링크가 메신저에 붙여지면 그 앱은 페이지를 한 번 가져와 og:image를 읽고 — 흐릿한 썸네일 가이드에서 측정했듯 그것은 maxresdefault.jpg를 가리킨다 — 미리보기 이미지의 사본을 자기 쪽에 보관한다. 그 뒤로 앱이 보여주는 것은 유튜브의 파일이 아니라 앱이 찍어둔 스냅샷이다.

그것을 일괄로 비우는 방법은 없고, 두 시간 헤더는 앱이 스스로 저장한 사본에는 적용되지 않는다. 자기 캐시를 다시 읽게 하는 도구를 공개한 곳은 두 곳이다. 페이스북의 Sharing Debugger와 링크드인의 Post Inspector. 나머지에 대한 실용적인 답은 이렇다. 변경 전에 올라간 링크는 예전 이미지를 유지하고, 변경 후에 올라간 링크는 새 이미지를 받는다.

캐시 문제가 아예 아닐 때

예전 이미지도 새 이미지도 없다면 캐시는 관계가 없고 기다려도 소용없다. 답으로 판명되는 빈도 순으로 세 가지 원인이 있다.

계정에서 맞춤 썸네일을 쓸 수 없다. 업로드는 조용히 자동 생성 프레임으로 대체된다. 요건이 바뀌었고 옛 조언이 틀렸기 때문에 이건 별도의 가이드가 있다. 맞춤 썸네일 옵션이 보이지 않는 이유.

파일이 거부됐다. 업로드한 기기의 한도 초과(컴퓨터 50 MB, 휴대폰 2 MB), 지원하지 않는 형식, 또는 정책에 따른 삭제. 거부된 업로드는 이전 썸네일을 그대로 남기는데, 그 모습이 정확히 “내 변경이 적용되지 않았다”처럼 보인다. 파일이 한도 아래인지, 허용 형식인지 확인하라. 목록은 크기와 규격 가이드에 있다.

보고 있는 변형이 존재하지 않는다. 모든 영상에 모든 크기가 있는 것은 아니다. 폭이 1280픽셀 미만인 원본에서는 maxresdefault.jpg가 작은 대체 본문과 함께 404를 돌려준다. 2005년 업로드에서 확인했다. maxres와 sddefault는 둘 다 404, hqdefault는 정상. 인터페이스가 아니라 URL로 시험하고 있다면 그 404는 변형에 관한 것이고 당신의 썸네일에 관한 것이 아니다. 썸네일 정책에 따른 삭제는 밖에서 보면 똑같아 보이지만 캐시 문제가 전혀 아닙니다.

스튜디오도 증거가 아니고, 당신의 피드도 아니다

스튜디오는 방금 저장한 파일을 CDN 없이 그대로 보여주므로 즉시 갱신되고, 시청자가 무엇을 보는지에 대해서는 아무것도 알려주지 않는다. 당신의 피드는 그 반대다. 오래된 사본을 갖고 있을 확률이 가장 높은 표면인데, 가장 최근에 방문한 사람이 당신이고 따라서 브라우저가 가진 캐시 이미지가 누구보다 오래된 것이기 때문이다.

이 비대칭이, 같은 두 시간 안에서 “나에게는 갱신됐는데 구독자에게는 아니다”와 “그들에게는 갱신됐는데 나에게는 아니다”가 모두 정상인 이유이고, 두 관찰 모두 행동할 가치가 없는 이유다.

문제 자체를 없애는 확인

당황해서 하는 썸네일 교체는 거의 모두 공개 전에 내릴 수 있었던 결정이다. 사람들이 업로드 한 시간 뒤에 썸네일을 바꾸는 이유는, 다른 영상들 옆에 놓인 자기 썸네일을 처음 본 곳이 피드이기 때문이다. 그리고 그 시점의 교체는 두 시간짜리 낡은 캐시를, 테스트가 돌고 있다면 테스트까지 비용으로 치른다.

먼저 피드에서 보는 것이 바로 미리보기 도구의 용도다. 실제 경쟁 영상들 사이에, 실제로 렌더링되는 크기로, 영상이 붙기 전에 본다. 캐시 문제의 가장 좋은 해결은 두 번째 업로드가 필요하지 않게 하는 것이다.

모두가 묻는 질문