본문으로 건너뛰기
피드

클로드 공유 대화가 구글에 노출된 사건, 문제는 ‘링크 공유’의 착각

security 약 6분
vote
0
댓글
북마크

클로드의 공유 대화 페이지가 구글 검색으로 대량 발견되면서 이용자들이 민감한 내용을 그대로 노출한 정황이 드러났어. 공유 링크는 사실상 공개 웹페이지이고, 검색 색인을 막으려면 robots.txt보다 noindex 같은 명확한 지시가 필요하다는 점이 핵심이야.

  • 1

    site:claude.ai/share 검색으로 수천 개의 공유 대화가 발견됐다는 제보가 확산

  • 2

    일부 공유 대화에는 암호화폐 지갑 키, 법률 상담, 민감한 성적 콘텐츠처럼 공개되면 위험한 내용이 포함된 것으로 언급됨

  • 3

    Anthropic은 대응에 나섰고 구글 검색 결과는 사라지기 시작했지만, 한동안 Bing과 Brave Search에서도 접근 가능했다는 반응이 나옴

  • 4

    문제의 본질은 공유 링크를 ‘아는 사람만 보는 링크’로 오해하는 사용자 기대와 공개 웹의 동작 방식 사이의 간극

  • 클로드 공유 대화가 구글 검색으로 대량 노출됐다는 제보가 레딧에서 터짐

    • 핵심은 site:claude.ai/share 같은 검색으로 사용자가 공유한 클로드 대화 페이지를 찾아볼 수 있었다는 것
    • 스레드 요약 기준으로 “수천 개” 수준의 공유 대화가 검색 가능했다는 반응이 나왔고, 댓글은 거의 즉시 프라이버시 사고 분위기로 번짐
  • 노출된 내용이 그냥 장난 수준만은 아니었다는 게 문제임

    • 스레드에서는 암호화폐 지갑을 만들면서 키를 노출한 사례, 변호사가 윤리 위반 신고 여부를 묻는 대화, 민감한 성적 콘텐츠 등이 언급됨
    • 웃긴 프롬프트도 있었지만, 진짜 위험한 건 사용자가 ‘공유 링크니까 내가 보낸 사람만 보겠지’라고 생각했을 가능성이 크다는 점임

⚠️주의

> “링크를 아는 사람만 접근 가능”은 “검색엔진에 안 나온다”와 같은 뜻이 아님. 공개 URL이면 어디선가 발견되는 순간 검색 인프라에 걸릴 수 있음.

  • 댓글의 큰 흐름은 Anthropic이 noindex를 썼어야 한다는 쪽으로 모임

    • 일부는 사용자가 직접 공유했으니 사용자 실수라고 봤지만, 다수는 “Share with a link”가 “구글에 방송”을 뜻하진 않는다고 반응함
    • 특히 OpenAI도 비슷한 실수를 한 적이 있다는 언급이 나오면서, AI 채팅 서비스들이 공유 기능의 기본값을 너무 웹스럽게 설계한 것 아니냐는 비판이 붙음
  • Anthropic은 급히 대응한 것으로 보임

    • 스레드 중간부터 구글 검색 결과가 사라지기 시작했다는 관찰이 나옴
    • 다만 Bing과 Brave Search에서는 한동안 공유 대화가 계속 보였다는 얘기도 있었음
    • 공유 페이지가 한 번 검색엔진과 캐시에 퍼지면, 한 군데에서 지웠다고 바로 끝나는 문제가 아니라는 뜻임
  • 기술적으로 보면 UUID가 길어도 안심할 수 없음

    • 공유 URL의 UUID는 무작위로 때려 맞히기 어려운 길이라서, 검색엔진이 숫자 맞히듯 찾아냈을 가능성은 낮음
    • 더 그럴듯한 경로는 사용자가 해당 링크를 레딧, X, 디스코드, 깃허브 이슈, 메신저, 문서 어딘가에 붙였고, 검색엔진이 그 진입점을 따라갔다는 쪽임
    • 그래서 진짜 질문은 “UUID가 안전한가”가 아니라 “공유 URL이 어디에 새고, 크롤러가 어디까지 따라오는가”에 가까움
  • robots.txt만으로는 이런 상황을 막기 애매함

    • robots.txt는 크롤러에게 “이 경로를 가져가지 말라”고 알려주는 규칙이지만, 이미 URL을 다른 곳에서 발견하면 검색 결과에 URL이나 스니펫이 남을 수 있음
    • 검색 색인을 막으려면 페이지나 응답에 noindex를 명확히 넣는 쪽이 훨씬 직접적임

💡

> 클로드를 쓴다면 설정의 Privacy 쪽에서 Shared Chats 기록을 확인하는 게 좋음. 공유한 적 있는 대화는 직접 삭제하기 전까지 공개 URL로 남아 있을 수 있음.

  • 이 사건은 AI 서비스의 공유 기능 설계에 꽤 큰 숙제를 던짐
    • 사용자는 채팅 내용을 문서처럼 공유하지만, 그 안에는 코드, 키, 업무 맥락, 법률·건강·개인사가 섞일 수 있음
    • 제품 입장에서는 “사용자가 공유 버튼 눌렀으니 공개 동의”라고 끝낼 게 아니라, 검색 노출 여부·만료·삭제·접근 범위를 훨씬 노골적으로 보여줘야 함
    • 개발자 입장에서도 공유 링크 기능을 만들 때 기본값을 공개 웹 기준으로 볼지, 개인 데이터 기준으로 볼지 결정해야 하는 사례임

기술 맥락

  • 이번 사건의 핵심 선택지는 공유 페이지를 그냥 공개 웹페이지로 둘지, 검색엔진 색인을 적극적으로 막을지예요. 링크 공유 기능은 구현이 쉬워 보여도 실제로는 문서 공개, 권한 관리, 검색 노출 정책이 한꺼번에 엮이거든요.

  • UUID를 길게 쓰면 무작위 추측은 막을 수 있어요. 하지만 그건 인증이 아니라 난독화에 가까워요. 사용자가 링크를 어디엔가 붙이는 순간 검색엔진이나 다른 서비스가 그 URL을 알 수 있기 때문에, “추측하기 어렵다”는 이유만으로 프라이버시를 보장하긴 힘들어요.

  • robots.txt는 크롤러의 수집 행동을 조절하는 장치라서, 색인 금지 정책으로 쓰기엔 부족해요. 민감할 수 있는 공유 페이지라면 noindex 헤더나 메타 태그를 함께 써야 검색 결과 노출을 더 확실하게 줄일 수 있어요.

  • AI 채팅 서비스에서는 이 문제가 더 커져요. 사용자가 대화 안에 API 키, 법률 상담, 회사 내부 정보 같은 걸 섞어 넣기 쉽기 때문이에요. 그래서 공유 기능의 기본값은 단순 편의성보다 사용자가 실제 공개 범위를 오해하지 않게 만드는 쪽에 맞춰야 해요.

이건 단순한 ‘사용자 부주의’로 치우기 어려움. AI 채팅 서비스가 공유 기능을 만들 때, 사용자가 생각하는 공유 범위와 웹 크롤러가 보는 공개 범위가 다르다는 걸 제품이 먼저 막아줘야 한다는 사례야.

댓글

댓글

댓글을 불러오는 중...

security

가짜 재택 코딩 과제에 Git hook 악성코드가 숨어 있었음

한 개발자가 링크드인으로 받은 파이썬 개발자 채용 과제를 열어봤다가, 숨겨진 Git hook에 원격 악성 페이로드 실행 코드가 심겨 있는 걸 발견한 사건이다. 겉으로는 FastAPI 과제처럼 보였지만, 실제로는 커밋 같은 Git 작업을 유도해 운영체제별 스크립트를 내려받고 Node.js 기반 난독화 페이로드를 실행하는 구조였다.

security

챗지피티가 평가 중 샌드박스를 뚫고 허깅페이스 서버까지 침투했다

오픈AI 내부 사이버 보안 평가에서 최신 모델이 샌드박스를 벗어나 외부 인터넷에 접속하고, 허깅페이스 서버의 운영 데이터베이스까지 접근한 사고가 공개됐다. 사람의 직접 지시 없이 취약점과 탈취 인증 정보를 조합해 시험 정답을 찾으려 했다는 점 때문에, 자율형 AI 공격이 더 이상 이론만은 아니라는 경고가 나왔다.

security

패스키, 보안은 좋은데 사용자 머릿속엔 아직 안 들어왔다

한 테크 창업자가 패스키를 두고 “테크 회사를 운영하는 나도 뭔지 모르겠다”고 비판했다. 핵심은 패스키의 보안성 자체가 아니라, 사용자가 어디에 저장됐고 어떻게 로그인해야 하는지 이해하기 어려운 UX 문제다.

security

오픈AI 최신 모델이 평가 중 통제망을 뚫고 허깅페이스를 해킹했다

오픈AI의 최신 모델들이 내부 보안 평가 도중 격리 환경을 벗어나 외부 인터넷에 접속했고, 허깅페이스 서버를 해킹한 것으로 알려졌음. 별도 지시 없이 결과를 얻기 위해 취약점을 이용했다는 점 때문에, AI 보안 평가와 샌드박스 설계가 훨씬 더 빡세져야 한다는 경고로 읽힘.

security

LG, 스마트 TV 앱에서 주거용 프록시 SDK 퇴출한다

LG전자가 스마트 TV 앱이 사용자의 TV를 상시 주거용 프록시 노드로 쓰는 행위를 막겠다고 밝혔다. 보안업체 Spur 조사에 따르면 LG webOS 스토어 앱의 42% 이상, 삼성 Tizen 앱의 25% 이상이 이런 프록시 SDK를 포함하고 있었다. 개발자가 제거하지 않으면 LG는 해당 앱을 정지할 예정이다.