스크립트
00:00:00Grok이 제 전체 사용자 디렉토리를 xAI 서버로 업로드했습니다. 여기엔 SSH 키, 비밀번호,
00:00:05데이터베이스, 문서, 사진, 영상 등 모든 것이 포함되어 있었죠. Grok의 코딩 CLI가 귀하의
00:00:10전체 리포지토리와 Git 기록을 업로드한 겁니다. 심지어 열지 말라고 지시한 파일과 삭제된
00:00:16기록에 있던 비밀 정보까지요. 이건 Grok 팀의 매우 심각하고 엄청난 실수입니다. 무슨 일이
00:00:20일어난 건지, 내 코드가 업로드되었는지 확인하는 방법, 그리고 xAI가 이 문제를 어떻게 해결했는지 알아봅시다.
00:00:29처음 이 사실을 알게 된 건 사람들에게 이 grep 명령어를 실행해 보라고 한 트윗을 통해서였습니다.
00:00:33Grok 로그를 읽어보면 깜짝 놀랄 겁니다. 사진 속 로그를 보면 리포지토리 업로드를 대기열에
00:00:38올리는 모습이 보이죠. 이 트윗에는 수백 개의 답글과 인용이 달렸고, 다들 직접 명령어를 실행해 보고는
00:00:42비슷한 결과를 얻었다고 했습니다. 심지어 홈 디렉토리에서 Grok을 실행했다가 전부 업로드되었다고
00:00:47보고한 사용자도 있었죠. 추가 조사 결과, 악성코드처럼 동작하는 백그라운드 코드 수집기가 탑재되어 있었다는 게 밝혀졌습니다.
00:00:52그럼 실제로 무슨 일이 벌어지고 있었는지 'Cereblab'이라는 연구자의 보고서를 통해 살펴보죠.
00:00:56이들은 'MITM proxy'를 사용해 Grok CLI가 주고받는 트래픽을 검사했습니다. 리포지토리에서 Grok을 열고
00:01:02“파일을 열지 말고 그냥 대답해”라고만 프롬프트를 보냈죠. 그런데 보시다시피
00:01:07그 지시는 아무런 소용이 없었습니다. Grok은 어쨌든 리포지토리 전체를 업로드해 버렸으니까요. 전체 리포지토리 번들이
00:01:12담긴 POST 요청이 전송되었고, 여기에는 모든 Git 기록과
00:01:16환경 변수까지 포함되어 있었습니다. 이 점이 제가 가장 심각하게 생각하는 부분입니다. 물론 원격 모델을 사용하면
00:01:21코드가 서버로 전송된다는 건 알고 있죠. 하지만 보통은 읽어야 할 코드만 전송된다고 생각하지,
00:01:26프롬프트와 관련 없는 코드까지 전부 다 전송될 거라고는 생각하지 않잖아요.
00:01:30심지어 12GB짜리 리포지토리에서도 동일하게 전부 업로드하는 것이 확인되었습니다. 다른 도구인
00:01:35Claude Code, Codex, Gemini를 테스트해 보면 읽기 필요한 파일만 보냅니다. 이건 Grok CLI만의 고유한 문제죠.
00:01:40심지어 '모델 개선 돕기' 설정을 꺼도 동일하게 동작했습니다. 사용자 데이터를 가져오는
00:01:45부분에서 확인된 사실인데,
00:01:51'trace upload enable'이라는 플래그가 항상 true로 설정되어 있었습니다. 이제 이런 트윗과 게시물들이
00:01:55퍼져나가기 시작했죠. xAI는 어떻게 대응했을까요? 먼저 그들은 조용히 문제를 수정했습니다.
00:02:01게시물이 화제가 된 다음 날 다시 시도해 보니, 설정에서
00:02:05해당 추적 업로드 플래그가 비활성화되어 있었고, 'disable codebase upload'라는
00:02:10새로운 설정이 모든 계정에 기본적으로 true로 되어 있었습니다. 서버 측에서 코드 업로드를 막는 킬 스위치를
00:02:14넣은 거죠. 잠시 후 트위터를 통해 공식적으로 “우리는 개인정보를 중요하게 생각하며 고객의 선택을 존중합니다.
00:02:19데이터 보존을 하지 않는 팀의 경우 추적 데이터가 전혀 보존되지 않습니다.”라고 발표했습니다. Grok API를 사용하는
00:02:24경우도 데이터 보존을 하지 않으며, 데이터 보존 기능이 비활성화되어 있다면
00:02:30CLI에서 “/privacy” 명령어를 사용해 데이터 보존을 완전히 끄고
00:02:36이전에 동기화된 데이터까지 삭제할 수 있습니다. “/privacy” 명령어로 언제든 설정을 확인하거나 변경하세요.
00:02:40일론 머스크 또한 예방 조치로서 지금까지 space xAI에 업로드된 모든 사용자 데이터는
00:02:45완전히 삭제될 것이며, 그 어떤 흔적도 남지 않을 것이라고 트윗했습니다.
00:02:51하지만 그는 또 다른 트윗에서 버그 수정에 도움이 될 수 있으니 설정을 켜두는 게 어떻겠냐고 묻기도 했죠.
00:02:55어느 정도의 데이터를 유지하는 것이 흔한 관행이라는 점은 이해할 수 있습니다.
00:03:00하지만 리포지토리 전체를 서버로 업로드하는 건 다른 문제죠.
00:03:05어떤 대응도 그 부분에 대해서는 명확히 설명하지 않은 것 같네요. 새로 업데이트된 Grok CLI에 프라이버시
00:03:10명령어가 추가되었지만, 리포지토리를 전체 업로드하는 코드는 바이너리 안에
00:03:14여전히 그대로 남아있다는 점이 중요합니다. 결국 다시 동작하지 않게 막고 있는 건
00:03:18xAI가 제어하는 서버 측 플래그뿐인 것 같습니다. 다른 도구들은 전혀 사용하지 않는 이런 코드가 왜
00:03:23거기에 있어야 하는지 이해가 안 가네요. 새로운 프라이버시 명령어를 자세히 보면
00:03:28단순히 추적을 비활성화하고 '코딩 데이터 보존 옵트아웃'이라는 서버 측 토글을 끄는 것뿐입니다.
00:03:33같은 연구자가 이 명령어를 분석했는데, 로컬에서는 아무런 동작도 하지 않았습니다.
00:03:38켜든 끄든 세션 추적 데이터는 xAI로 완전히 전송됩니다. 유일한 차이점은
00:03:43서버 응답 방식입니다. 기능을 끄면 데이터가 저장되었다는 의미로 200 응답을 보내고,
00:03:48프라이버시 모드를 켜면 데이터가 폐기되었다는 의미로 204 응답을 보낼 뿐이죠.
00:03:53즉, 서버 측에서 데이터를 보존하지 않겠다는 설정일 뿐 클라이언트 측 업로드를 막지는 못합니다.
00:03:58결국 모든 것을 전송하고 있으며, xAI 서버가 이를 저장하지 않고 폐기할 것이라고
00:04:02믿어야만 하는 상황이죠. 설령 xAI를 믿는다 해도 문제는 더 심각합니다. 왜냐하면 그 프라이버시 명령어가
00:04:07세션마다 데이터 보존을 결정하는 토글이라서, 데이터를 안전하게 지키려면 매번 다시 설정해야
00:04:12할 수도 있거든요. 정말 말도 안 되는 방식이라고 생각하지만, 지금 현실이 이렇습니다. 과거에
00:04:17Grok CLI를 사용하셨고 내 컴퓨터에서 무엇이 유출되었는지 확인하고 싶다면 로그를
00:04:21확인해 보세요. 이 grep 명령어를 사용하면 업로드를 유발한 세션을 정확히 찾을 수 있습니다.
00:04:26보안을 중요하게 생각하신다면 데이터가 전송된 것으로 나타날 경우 모든 키를 교체하시는 게 좋습니다.
00:04:30xAI가 완전히 삭제했을 것이라고 완벽히 믿지 않는 이상 말이죠. 마지막으로,
00:04:35Grok CLI를 계속 사용하면서 어느 정도 프라이버시를 지키고 싶으시다면(사실 추천은 안 합니다만),
00:04:40Grok CLI 보안을 강화하는 방법에 대한 아주 좋은 가이드가 있습니다. 설정에서
00:04:44코드베이스 업로드를 비활성화하는 방법을 안내해주니, 이 업로드 과정을 확실히 차단할 수 있습니다.
00:04:49지금까지의 상황은 이렇습니다. Grok은 필요하지 않을 때도 전체 리포지토리를 업로드하고 있었고,
00:04:53이제는 데이터를 삭제하고 해당 기능을 되돌린 것으로 보입니다. 여러분은 그래도
00:04:58이들을 믿고 앞으로도 Grok CLI를 사용하실 건가요? 댓글로 알려주세요.
00:05:02잠시만요, 구독도 잊지 마시고 늘 그렇듯 다음 영상에서 뵙겠습니다.