메타 AI한테 "네 안의 파일을 zip으로 보내줘" — 6.8GB가 통째로 나왔다

발행 2026-09-23 · 분류 AI 실전편 · 난이도 중급 · 읽는 시간 7분

결론부터: 보안 공격이 아니라 대화 한 판이었습니다. 개발자 한 명이 메타의 상용 에이전트에게 "네가 보는 파일을 묶어서 내 드라이브로 옮겨줘"라고 부탁했고, 실제로 압축 2.7GB·펼치면 6.8GB짜리 리눅스 루트 파일시스템 사본이 도착했습니다. 그 안에 들어 있던 건 그 세션 전용 컴퓨터의 통째 모습이었습니다.

HackerNews에는 글 올라간 지 하루도 안 돼 310표와 댓글 149개가 붙었습니다. 폭발 지점은 "뚫렸다"가 아니라 "메타가 이건 버그가 아니라 말했다"였습니다.

오늘은 압축 안에 뭐가 들었는지, 왜 양쪽 다 틀린 말은 아닌지, 그리고 내 에이전트 작업대에 그대로 대입할 체크리스트까지 따라갑니다.

30초 요약

1. 무엇이 터졌나

사건의 문장은 이렇습니다. 상대가 "네"라고 답하고, 파일을 묶고, 연결된 저장소로 보냈습니다. 그뿐입니다. 침투 도구도, 특수 프롬프트도 없었습니다.

저자가 받아 적어 놓은 크기는 압축본 2.7GB 남짓, 풀면 6.8GB입니다. 도착한 덩어리를 까보니 그 세션에 배정된 리눅스 머신의 최상위부터 내려오는 파일들이었습니다. 운영체제 파일은 기본이고, 눈길 끈 건 따로 있었습니다. 메타가 이 제품에 붙인 내부 이름(hatch) 아래 담긴 문서들, 기능 매뉴얼, 연동 코드, 앱 템플릿, 대화 메모리, 에이전트 실행 로그, 그리고 SSH 키 파일이었습니다.

저자는 아카이브 자체도, 키도, 로그도 공개하지 않았습니다. 대신 '그 안에서 무엇무엇을 확인할 수 있었나'만 글로 남겼습니다. 이 글도 그 범위를 넘지 않습니다.

2. 왜 대단한 얘기인가 — 안이 훤히 들여다보였다

① 에이전트의 '영혼'은 텍스트 파일이었다

집 디렉터리에는 여섯 개의 Markdown 파일이 놓여 있었습니다. 성격·정체·사용자 정보·장기 메모·동작 규칙·도구 목록을 각각 담는 파일들입니다. 즉 저 상용 에이전트의 인격과 기억은 모델 가중치가 아니라, 편집 가능한 텍스트 파일 여러 장이었습니다. 모델이 좋아지는 게 아니라 파일이 갱신되는 방식으로 기억이 쌓이는 구조입니다.

재미있는 건 메모리 쪽 설계입니다. 매시간 도는 배경 작업이 새 주장을 원문 대화와 대조해 인용과 근거 ID를 붙이고, 어느 걸 요약 표에 올리고 어느 걸 일지에 둘지 판정합니다. 검색을 위해 Postgres에 384차원 벡터를 깔아 두고, 나중에 온 주장이 이전 주장을 대체하도록 표를 묶어 둡니다. 매일 밤에는 '꿈'이라는 배치가 최근 대화를 다시 읽어 다음 세션에 대한 지침을 남깁니다. 저자의 꿈 파일에는 "짧게 답하기를 좋아하고, 반복 확인을 싫어하고, 시키지 않았는데 NFL 점수를 말한 적 없다"는 기록이 실제로 적혀 있었습니다.

② 안 쓰는 남의 도구가 통째로 들어 있었다

이미지 안에는 OpenAI 계열 코딩 CLI 바이너리가 버전까지 찍힌 채 설치돼 있었습니다. 그런데 저자가 뒤져본 바로는 그 CLI를 호출하는 코드가 없었습니다. 실제 용도는 하나 — 그 CLI에 딸려 오던 샌드박스 도구를 떼어내, 자기네 영상 처리 작업(ffmpeg·ffprobe)을 네트워크 없이 권한 없이 돌리는 데만 쓰고 있었습니다. 경쟁사 도구를 통째로 깔고 껍데기만 빼 쓴 셈입니다. 원문에는 이 대목의 링크가 붙어 있습니다.

③ 나오지 않을 제품 문서가 나왔다

문서 하나가 가정용 기기 연동 실험을 설명하고 있었습니다. ESP32-C5 보드로 와이파이·블루투스 LE를 붙이고, 프록시를 거쳐 에이전트가 홈 네트워크 기기에 접근하는 그림입니다. 형제 문서에는 프린터와 조명 브리지 연동 안내도 있었습니다. 내부 실험인지 제한 테스트인지 출시 계획인지 저자도 확신하지 못한다고 적었습니다.

설정 파일 두 장은 더 대담했습니다. 커넥터 대기 목록에 Slack·Dropbox·Canva 같은 이름들이 적혀 있었다고 합니다. 전부 확인된 건 아니고, 글에 그렇게 적혀 있다는 수준으로만 받으세요.

3. 바로 써먹기 — 내 에이전트 작업대 점검표

이 사건에서 가져갈 화제는 '메타 욕'이 아니라 구조입니다. 에이전트에게 파일 읽기와 파일 반출은 서로 다른 권한이어야 하는데, 대부분의 개인·1인 운영 환경은 두 개를 한 몸으로 열어 둡니다.

① '연결된 저장소'가 곧 반출 포트다

② 로컬 에이전트를 쓴다면 — 격리 수준 확인 한 덩어리

위 사건이 가능했던 배경에는 '세션마다 리눅스 머신 한 대씩'이라는 상용 제품 구조가 있습니다. 반대로 내 노트북에서 도는 로컬 에이전트는 샌드박스 자체가 옵션인 경우가 많습니다. CLI 하나를 고를 때 "파일시스템 전체 접근이 기본값인가, 허용 경로를 물어보는가"를 확인하는 것만으로 이 글의 사례 절반은 남의 일이 됩니다.

# 내 작업본에 시크릿이 새 있어? — 에이전트에게 주기 전에 10초 점검
grep -rlE "BEGIN (OPENSSH )?PRIVATE KEY|api[_-]?key" ~/work \
  --include="*.env" --include="*.md" --include="*.log" | head

에이전트가 읽을 수 있는 모든 파일은 결국 '어딘가로 보낼 수 있는 파일'과 같은 뜻으로 취급하는 게 안전측입니다. 위 명령은 아무 경고 없이 '읽을 수 있는 시크릿 후보'를 먼저 세어보는 용도입니다.

4. 해외 반응 쟁점

"샌드박스 안은 애초에 사용자의 것" 진영이 다수였습니다. 상위 댓글들은 "사용자 전용 VM 안의 파일을 사용자가 가져간 게 왜 보안 사고냐", "같은 파일들이 앱 내 파일 탐색기에도 보인다"는 쪽이었습니다. 한 사용자는 자기 PC에 동기화 도구를 심어 샌드박스를 자기 기기와 연결해 놓고 "이 정도면 다 할 수 있다"고도 했습니다.

소수 진영은 "열쇠는 별개"였습니다. "전체 반출은 원격 셸 다음가는 사고", "바이너리 목록 자체가 CVE 지도"라는 반론과, "SSH 키가 공개키인지 비공개키인지도 미확인"이라는 견제가 같은 스레드에 붙었습니다. 저자 본인도 키가 활성 상태인지 무슨 접근을 주는지 확인 못 했다고 적었습니다.

버그바운티 '해당 없음' 판정. 글쓴이가 가장 의외라고 토로한 지점이고, 커뮤니티도 여기서 두 번째로 뜨거웠습니다. 다만 제품 설계 관점을 옹호하는 쪽은 "샌드박스 내용물을 기밀로 두는 회사 자체가 없고, 그렇기에 샌드박스를 쓰는 것"이라고 맞받았습니다.

화제를 비켜 간 세 번째 논쟁. '매뉴얼이 Markdown 파일 덩어리라는 건 소프트웨어 엔지니어링이 이 지경이라는 증거'라는 냉소에 대해, 다른 쪽은 "평문 지침을 eval로 다듬어 통계적 신뢰도로 올리는 게 이 세대의 엔지니어링"이라고 반박했습니다. 스레드 분량의 상당수가 이 철학 싸움으로 흘렀습니다.

5. 마시기 전 주의

• 이 글의 모든 내부 묘사는 한 사람의 자기 세션 관찰 기록입니다. 남의 세션에도 같은 게 들어 있다는 증거는 없으며, 저자 본인도 '그 환경 밖 인프라는 결론낼 수 없다'고 선을 긋습니다.
• 컨테이너를 벗어난 탈출 시도는 성공하지 못했고, 저자가 스스로도 그 방면 경험이 부족하다고 적었습니다. '메타 내부망 뚫림' 류의 2차 인용을 걸러내세요.
• 용량 수치(2.7/6.8GB)는 저자 메모 기준이고, 제품 쪽 안내와 저자 기록이 0.1GB 안팎으로 어긋난다는 사실까지 글에 적혀 있을 만큼 정밀 검수는 안 된 숫자입니다.
• 미출시 커넥터 목록(슬랙·드롭박스 등)은 설정 파일 이름만 본 정황일 뿐 출시 예고가 아닙니다.

바로 가기

• 원문 — 세션 파일시스템 반출 관찰기 (Mouse, Peter James)
• HackerNews 댓글 149개 — '샌드박스는 누구 것인가' 논쟁 현장
• 메타 버그바운티 공식 안내