이미지 호스팅 공유 링크, 구글에 검색될 수도 있다? 무료 7개 서비스 noindex 실측

디시인사이드나 단톡방에 아무 생각 없이 붙여넣은 스크린샷이, 지금 이 순간 구글 색인에 올라가 있어서 누군가 site: 검색 한 번으로 찾아낼 수 있는 상태일지도 모릅니다. 해킹이 필요한 게 아니라, robots 설정 하나가 어긋난 것만으로 벌어지는 일입니다.

2026년 7월 말, 보안 업계에 실제로 이런 일이 터졌습니다. 구글에서 site:claude.ai/share를 검색하기만 해도 다른 사람들의 AI 대화 기록이 대량으로 나왔는데, 그 안에는 API 키, 암호화폐 개인키, 법률 상담 내용, 이력서까지 들어 있었습니다. 원인은 해킹이 아니라 설정 충돌이었습니다. 그 공유 페이지들은 robots.txt에서 "크롤링 금지"로 설정돼 있었는데, 동시에 X-Robots-Tag: none도 걸려 있었습니다. 문제는 Googlebot이 robots.txt에서 이미 막히면 애초에 페이지에 도달조차 못 하고, 원래 효력을 발휘했어야 할 noindex 태그도 읽을 수 없다는 점입니다. 결과적으로 외부 링크를 통해 페이지가 발견되고 색인까지 됐는데, 이걸 막을 장치는 아무것도 작동하지 않았습니다. 1년 사이 같은 유형의 사고가 이번이 네 번째로, 그 전에는 ChatGPT(추정 7만~10만 건의 대화)와 Grok(수십만 건)에서도 같은 구조의 문제가 있었습니다.

이미지 호스팅과 직접적인 관련은 없어 보일 수 있습니다 — 저건 AI 대화 공유 링크지 이미지가 아니니까요. 하지만 메커니즘은 그대로 옮겨 적용됩니다. "링크만 알면 볼 수 있게 하되 공개는 안 하겠다"는 공유 기능이라면, 크롤러를 제대로 차단하지 않는 순간 전부 같은 논리에 걸립니다. 이미지 호스팅의 보기 페이지도 "URL만 알면 볼 수 있는" 방식이라는 점은 똑같고, robots.txt, meta robots, X-Robots-Tag라는 같은 3중 구조로 막아야 합니다. 이 중 한 층이라도 잘못 설정되면 이미지도 똑같이 검색 결과로 새어 나갑니다. 여러 기업의 보안 감사를 맡아본 경험으로 보면, 솔직히 이미지 유출은 대화 유출보다 알아채기가 더 어렵습니다. 무심코 보낸 스크린샷이 검색될 거라고는 누구도 생각하지 않으니까요.

그래서 직접 테스트해봤습니다.

이미지가 검색되는지 결정하는 3개 층

표를 보기 전에 판단 기준부터 정리하겠습니다. 특정 URL이 구글에 색인되는지는 서로 독립된 3개 층으로 결정됩니다.

robots.txt는 크롤러가 해당 경로에 들어갈 수 있는지를 결정합니다. 페이지 HTML 안의 <meta name="robots">는 크롤러가 들어온 뒤 색인할지 말지를 결정합니다. HTTP 응답 헤더의 X-Robots-Tag는 meta 태그와 동일한 효과를 내는 별도의 독립적인 색인 지시로, HTML을 건드리지 않아도 설정할 수 있다는 점만 다릅니다. 이 3개 층은 원래 서로 독립적인데도, 종종 같은 하나의 설정처럼 취급됩니다 — 이게 바로 Claude 사고의 근본 원인입니다. robots.txt에서 막혔는데 X-Robots-Tag는 제대로 설정돼 있어서, 아무도 그걸 읽어낼 수 없었던 겁니다.

한 가지 원칙은 꼭 기억해둘 만합니다. noindex가 효력을 내려면, 크롤러가 먼저 "들어갈 수 있어야" 합니다. robots.txt에서 특정 경로를 disallow해두고 그 경로 밑의 noindex 태그도 작동하길 기대하는 건 애초에 모순된 설계이고, 결과적으로 둘 다 작동하지 않을 가능성이 높습니다.

테스트 방법: 무엇을 했고, 무엇을 하지 않았는지

솔직히 이런 테스트에서 가장 위험한 건 "기억에 의존해서 쓰는 것"입니다. 그래서 방법부터 공개합니다. 2026년 9월, 브라우저 User-Agent로 각 서비스의 보기 페이지에 curl -I를 실행해 HTTP 헤더(X-Robots-Tag 유무)를 확인하고, 전체 HTML을 받아 <meta name="robots">를 찾았으며, 각 서비스의 robots.txt도 직접 가져왔습니다. 자바스크립트로 콘텐츠를 렌더링해서 curl로는 실제 링크를 가져올 수 없는 서비스(Imgur 홈페이지 추천 영역이 대표적입니다)는 브라우저 자동화 도구로 페이지를 실제로 불러온 뒤 링크를 추출했습니다.

실제로 검색되는지는 별도로 구글 검색 확인도 진행했습니다 — 다만 여기서 한계 하나는 솔직하게 밝혀야겠습니다. 제가 사용한 검색 도구 자체가 imgur.com이라는 도메인에 접근이 막혀 있었습니다(구글이 막은 게 아니라, 검색 도구의 크롤러가 imgur 쪽 방어에 걸린 것입니다). 그래서 Imgur의 "이미 검색됐는지" 항목만은 같은 방법으로 검증할 수 없었고, 기술 설정 측면에서 "이론적으로 색인 가능"이라고만 판단해 표에 그 한계를 그대로 표기했습니다. 숨기고 싶은 게 아니라 도구의 한계이고, 테스트한 척하는 것보다 한계를 명확히 밝히는 게 더 중요하다고 생각합니다.

실측 결과

아래 표는 이번에 실제로 가져온 URL과 응답이며, 문서를 보고 추측해서 만든 표가 아닙니다.

서비스	보기 페이지 예시	robots.txt 제한	meta robots / X-Robots-Tag	색인 상태 (2026-09 실측)
Imgur	imgur.com/gallery/xxx	/gallery/ 경로 미차단	둘 다 미설정(기본값은 색인 가능)	기술적으로는 색인 가능; 검색 도구가 imgur.com에 막혀 직접 검증 불가
ImgBB	ibb.co/xxx	robots.txt가 완전히 비어 있음	둘 다 미설정	이미 색인됨 — 일반 키워드 검색만으로 실제 이미지 페이지 다수 발견
Postimages	postimg.cc/xxx	robots.txt가 완전히 비어 있음	둘 다 미설정	이미 색인됨 — 파일명이 그대로 남은 이미지 페이지 다수 발견
Flickr	flickr.com/photos/user/id	Googlebot을 포함한 명시적 크롤러들이 /photos/ 접근 허용	noarchive만 있고 noindex는 없음	이미 색인됨 — 특정 사용자의 특정 사진 페이지를 실제로 발견
Catbox	files.catbox.moe/xxx	일부 관리 경로만 차단, ClaudeBot / GPTBot은 명시적으로 차단	파일 자체가 순수 바이너리 직링크라 meta 태그를 넣을 HTML 페이지가 없음	구조적으로 "색인 가능한 보기 페이지" 자체가 존재하지 않음 — 페이지가 없으니 meta robots라는 개념 자체가 성립하지 않음
구글 포토 공유 링크	photos.app.goo.gl/xxx	/share/ 경로가 robots.txt에서 명확히 제외되지 않음	페이지가 JS 렌더링이라 curl로는 내용 판단 불가	이미 색인됨 — 다른 사람의 공유 링크가 검색으로 나오고, 일부는 지금도 열림
lpic.cc	lpic.cc/단축코드	Allow: /(홈 레벨에서 전면 개방)	보기 페이지 소스에 index: false, follow: true가 명시돼 있음	명확한 noindex — 설계 단계부터 보기 페이지를 색인시키지 않도록 정해둔 방식

솔직히 구글 포토 행을 봤을 때는 조금 놀랐습니다.

서비스별 해석: 문제는 어느 층에 있는가

ImgBB와 Postimages는 이번 테스트에서 가장 명확한 두 반례입니다. robots.txt는 그냥 빈 내용을 그대로 돌려주는데, 이건 경로 제한이 전혀 없다는 뜻입니다. 페이지에도 meta robots 태그가 전혀 없습니다. 제한도 없고 태그도 없으니 결국 "완전 개방" 상태이고, 이건 업로드할 때 사용자가 끌 수 있는 옵션이 아니라 기본값입니다. 검색해보면 거의 바로 나왔고, 검색 결과 페이지 제목이 스마트폰 카메라가 생성한 원본 파일명(IMG_에 날짜·시간이 붙은 형식)인 경우도 적지 않았습니다. 스마트폰에서 바로 업로드한 사진이라는 게 한눈에 보입니다.

Flickr의 상황은 더 미묘하고, 오해하기도 쉽습니다. robots.txt에는 Googlebot을 포함해 거의 40개에 달하는 명시적 크롤러가 나열돼 있는데, 이 목록이 제외하는 건 일부 특정 계정과 기능 페이지뿐이고, 일반 사용자의 /photos/사용자명/사진ID 경로는 제외 목록에 들어 있지 않습니다. 페이지 자체는 noarchive(캐시 스냅샷 안 함)만 있고 noindex는 전혀 없습니다. 실제로 검색에서 찾은 사례는 조금 아이러니하게도, Flickr 공식 계정이 "Flickr 사진을 어떻게 공유하는지" 설명하는 튜토리얼 게시물이었습니다 — 공유 방법을 알려주는 게시물 자체가 검색된 셈입니다.

구글 포토 공유 링크는 이번 테스트에서 가장 신경 쓰인 항목입니다. 공유 링크는 언뜻 "보낸 사람만 볼 수 있는" 사적인 방식처럼 보이지만, 특별한 검색 연산자 없이 일반 키워드만으로 다른 사람의 photos.app.goo.gl 공유 단축 URL을 검색 결과에서 찾을 수 있었습니다(프라이버시를 고려해 실제 링크는 여기에 싣지 않습니다). 클릭했을 때 로그인을 요구하는 링크는 공유 권한이 나중에 바뀌었거나 만료됐다는 뜻이고, 여전히 열리는 링크도 있었습니다 — 즉 "특정 사람에게만 준" 링크가 한때, 혹은 지금까지도 공개 검색으로 발견될 수 있다는 뜻입니다. 이건 Claude 유출 사고와 같은 형태의 위험입니다. 링크 자체는 공개할 의도가 없었지만, 크롤링 규칙의 디테일이 검색엔진에 걸릴지 말지를 결정한 겁니다.

Catbox는 오히려 특이한 케이스입니다. 다른 서비스들처럼 별도의 "보기 페이지"가 없고, 업로드가 끝나면 바로 파일 직링크 URL이 주어지며, 열면 이미지 자체가 표시될 뿐 meta robots를 넣을 HTML 외피가 존재하지 않습니다. 즉 기존의 "meta robots 확인"이라는 방법론 자체가 여기서는 성립하지 않습니다. 그렇다고 더 안전하다는 뜻은 아니고, 위험이 다른 곳으로 옮겨갈 뿐입니다. 구글 이미지 검색은 직링크 이미지 파일 URL 자체를 색인할 가능성이 여전히 있고, 그 판단 기준은 HTML 페이지와는 다릅니다. 이 부분은 안정적인 검증 방법을 찾지 못했습니다. 솔직히 말해 검증이 안 됐고, 숫자를 지어내지는 않겠습니다.

lpic.cc — 제 제품이지만 다른 서비스와 같은 기준으로 테스트하지 않을 수는 없습니다. 소스 코드를 보면 보기 페이지의 metadata에 robots: { index: false, follow: true }가 명시적으로 하드코딩돼 있습니다. 즉 단축코드가 누군가에게 공유돼 크롤러에 발견되더라도, 페이지 자체가 "색인하지 말라"고 구글에 알리는 구조입니다. 이건 이번 테스트를 위해 급하게 추가한 게 아니라 설계 단계부터 정해진 동작입니다. 다만 솔직히 말하면, noindex가 막는 건 검색 결과 노출뿐이고 "URL만 알면 열 수 있다"는 문제 자체는 막지 못합니다. 비밀번호 보호 기능이 별도로 존재하는 이유가 바로 이거고, 둘을 같이 써야 방어로서 완결됩니다.

이게 실제로 어떤 위험이 되는가

기술적인 이야기를 쉽게 풀면 이렇습니다. 개인정보, 영수증, 대화 스크린샷, 신분증이 담긴 이미지를 ImgBB나 Postimages처럼 기본값이 전면 개방된 이미지 호스팅에 올렸다면, 이론상 누구나 키워드나 이미지 안에 보이는 텍스트 일부만으로도 그 이미지를 찾을 수 있습니다. 상대에게 공유받은 링크가 없어도, 검색엔진이 이미 크롤링했다면 그냥 그 자리에 있는 겁니다. 이건 파일을 "공개"로 설정해 자기 웹사이트에 올린 것과 본질적으로 다르지 않습니다.

더 간과하기 쉬운 상황도 있습니다. 커뮤니티나 SNS에 이미지 호스팅 링크를 붙일 때, 대부분은 "이 이미지가 검색될까"를 굳이 생각하지 않습니다. 하지만 사진에 본인 이름, 주소, 주민등록번호 일부(연말정산, 반품, 각종 신청서 스크린샷에 흔합니다)가 찍혀 있다면, 검색엔진에 색인되는 순간 그 정보는 본인이 직접 발견해서 삭제 요청을 할 때까지 인터넷에 계속 노출됩니다. 그리고 애초에 어디에 삭제 요청을 해야 하는지 모르는 사람이 대부분입니다.

내 공유 링크를 지키는 방법

모든 이미지에 이만큼의 경계가 필요한 건 아닙니다. 중요한 건 "가볍게 돌리는 밈"과 "개인정보가 찍힌 스크린샷"을 구분해서 서로 다른 등급으로 다루는 겁니다. 구체적으로 세 가지입니다.

• 업로드 전후로 직접 검색해봅니다. 파일명이나 이미지 속 특정 문구로 구글 검색을 걸어 색인 흔적이 있는지 확인합니다.
• 민감한 내용은 기본값이 전면 개방된 호스팅을 피하고, noindex를 명시하거나 비밀번호 보호를 지원하는 서비스를 씁니다.
• 공유 링크에는 유효 기간을 능동적으로 설정합니다. "어차피 URL 아는 사람 없으니 괜찮다"는 전제에 의존하지 않습니다 — Claude 사고가 이미 증명했듯, 크롤러는 URL을 미리 알 필요조차 없고, 외부 링크 하나만 있어도 충분합니다.

"공유 링크는 기본적으로 색인에서 제외"와 "비밀번호 보호"를 처음부터 같이 갖춘 이미지 호스팅을 찾고 있다면, lpic.cc의 보기 페이지는 애초에 noindex 설계인 데다 비밀번호 보호 기능까지 있어서 이 두 층을 한 번에 채웁니다. 다만 제약도 솔직히 밝혀둡니다. 무료 플랜에서 업로드한 미디어는 기본적으로 30일 뒤 만료됩니다(업로드 폼은 "조회 시 자동 연장"이 기본값으로 켜져 있습니다). 만료되면 삭제되고, 서비스 자체는 광고 수익으로 운영됩니다 — 이런 트레이드오프는 업로드 후가 아니라 미리 알고 있어야 할 부분입니다.

자주 묻는 질문 FAQ

Q1: noindex만 설정하면 이미지가 절대 검색되지 않나요? 절대는 아닙니다. noindex는 크롤러에 대한 "요청"이고, 대부분의 경우 구글은 이를 존중하지만 전제는 크롤러가 실제로 이 태그를 읽을 수 있어야 한다는 겁니다. robots.txt에서 같은 경로가 막혀 있으면 크롤러는 애초에 들어가지 못해 noindex를 볼 수도 없는데, 이게 바로 Claude 사고의 원인입니다.

Q2: Catbox처럼 직링크형인 이미지 호스팅도 이미지가 검색될 수 있나요? HTML 페이지가 없어서 meta robots로는 판단할 수 없습니다. 이론적으로는 구글 이미지 검색이 직링크 이미지 파일 URL 자체를 색인할 가능성이 있지만, 검증 방식이 일반 웹페이지와 다르고 이번 테스트에서는 신뢰할 만한 검증 방법을 찾지 못했습니다. 검증되지 않은 단정은 하지 않겠습니다.

Q3: ImgBB에 올린 이미지가 검색되는 걸 발견했어요. 색인을 지울 수 있나요? 먼저 원본 이미지를 삭제해서 URL을 무효화한 뒤, 구글 서치 콘솔의 "URL 삭제" 도구로 제거 요청을 넣으면 자연스러운 재크롤링을 기다리는 것보다 훨씬 빠릅니다.

Q4: 이 글은 2026년 9월 결과인데, 나중에 플랫폼이 설정을 바꾸면 어떡하죠? robots.txt와 meta 태그는 언제든 바뀔 수 있고, 이런 설정에 영구적인 보장은 애초에 없습니다. 이 표를 외우기보다는, 필요할 때마다 직접 curl -I나 브라우저 개발자 도구로 확인하는 습관을 들이는 게 결론 자체보다 오래갑니다.

Q5: Flickr는 왜 Googlebot만 허용하고 다른 대부분의 크롤러는 막나요? 의도된 구분입니다. 주요 검색엔진은 인덱싱을 허용해 트래픽과 노출을 유지하고, 익명의 제3자 크롤러는 차단해 콘텐츠 도용·오남용 위험을 낮추는 것 — 둘은 서로 다른 판단 기준이지 같은 결정을 두 번 적용한 게 아닙니다.

Q6: 한국에서 개인정보가 담긴 이미지가 검색에 노출됐다면, 개인정보보호법으로 대응할 수 있나요? 가능합니다. 이름, 주소, 주민등록번호 일부처럼 특정 개인을 알아볼 수 있는 정보가 담긴 이미지가 검색엔진에 색인됐다면 개인정보보호법상 개인정보에 해당할 수 있고, 정보주체는 해당 플랫폼(개인정보처리자에 해당하는 경우)에 삭제를 요구할 수 있습니다. 다만 이건 사후 구제 수단일 뿐, robots.txt와 noindex 설정을 처음부터 제대로 해두는 것을 대신하지는 못합니다.

참고 자료

• Claude 공유 링크가 구글에 색인된 사고 보도(2026-07-29)
• Imgur, ImgBB(ibb.co), Postimages(postimg.cc), Flickr, 구글 포토(photos.google.com), Catbox(catbox.moe) 각 서비스의 robots.txt, 2026년 9월 직접 확인
• 위 각 서비스 보기 페이지의 HTTP 헤더와 HTML 소스, 2026년 9월 curl 및 브라우저 자동화 도구로 실측
• lpic.cc 보기 페이지 metadata 소스 코드(app/(public)/[locale]/[code]/page.tsx)