SpaceXAI의 Grok Build AI 코딩 도구가 연구원들에 의해 사용자 저장소 전체를 Google Cloud 스토리지로 업로드하는 것이 발견되면서 비판을 받고 있습니다. 이번 보안 침해 사고는 AI 어시스턴트가 얼마나 많은 독점 데이터를 수집하고 보유할 수 있는지에 대한 우려를 불러일으켰습니다.

과도한 데이터 보유 및 보안 리스크

Cereblab의 분석에 따르면 Grok Build 명령줄 인터페이스(CLI)는 전체 코드베이스를 압축하여 클라우드로 전송했습니다. 더욱 심각한 점은, 이 도구가 무시하도록 설정된 파일까지 열어보고 개발자가 git 히스토리에서 삭제한 비밀 정보(secrets)를 추출했다는 것입니다.

이러한 수준의 데이터 수집은 Claude Code와 같은 경쟁사들을 압도할 정도입니다. King’s College London의 보안 연구원인 Lukasz Olejnik 박사는 이러한 수집 행위가 소스 코드, 인프라 구성도, 취약점 및 인증 정보를 원격 서버에 노출시킬 수 있다고 경고했습니다.

SpaceXAI와 Elon Musk의 대응

SpaceXAI는 업로드 기능을 중단했습니다. 연구원들은 현재 Grok 서버에서 disable_codebase_upload: true 플래그를 확인했으며, 이는 자동 업로드가 더 이상 실행되지 않음을 의미합니다.

Elon Musk는 X를 통해 이전에 업로드된 모든 데이터가 "완전히 그리고 철저히 삭제될 것"이라고 게시했습니다. 또한 그는 SpaceXAI가 "디버깅 문제"를 위해 데이터를 보유할 수 있도록 해달라고 사용자들에게 요청했는데, 많은 이들은 이 요청이 모순적이라고 보고 있습니다.

회사는 데이터 보유를 관리하기 위해 /privacy CLI 명령어를 제안했지만, Cereblab은 해당 명령어가 세션별 저장 여부만 전환할 뿐, 이번 스캔들의 원인이 된 체계적인 저장소 업로드를 중단시키지는 못한다고 지적했습니다.

개발자와 기업에 이것이 중요한 이유

이번 사건은 AI 기반 코딩 에이전트가 더 이상 단순한 자동 완성 도구가 아니라는 점을 개발자와 기업에 경고합니다. 이들은 스스로 코드를 읽고, 수정하고, 커밋할 수 있습니다. 에이전트가 ignore 파일을 우회하거나 삭제된 비밀 정보를 다시 불러올 수 있는 상황에서, "데이터 보유 제로(zero data retention)"라는 주장은 UI상의 약속이 아닌 기술적 테스트를 통해 증명되어야 합니다.

CTO와 제품 책임자(product owners)에게 이번 사건은 다음과 같은 필요성을 강조합니다:

  • 독립적인 감사: 실제 코드베이스를 대상으로 한 AI 도구의 감사.
  • 계약 조항: 데이터 처리, 보유 기간 및 삭제 보장을 명시하는 계약 조항.
  • 런타임 보호 조치: 특히 인증 정보나 특허 알고리즘을 포함하는 저장소에 대해 파일 수준의 권한을 강제하는 보호 조치.

핵심 요약

  • 의도치 않은 데이터 범위 설정: Grok Build는 제한된 파일과 삭제된 비밀 정보를 포함한 전체 저장소를 Google Cloud로 업로드했습니다.
  • 완화 조치 현황: SpaceXAI는 자동 업로드를 비활성화했으며, 이미 수집된 데이터를 삭제하겠다고 약속했습니다.
  • 보안 시사점: 이번 침해 사고는 독점 로직과 인증 정보를 유출할 수 있는 AI 코딩 에이전트의 과도한 데이터 보유 위험성을 부각했습니다.

SpaceXAI의 Grok Build 도구가 사용자 코드베이스 전체를 Google Cloud로 몰래 업로드하여 독점 소스 파일과 삭제된 비밀 정보를 노출한 사실이 적발되었습니다.

무슨 일이 일어났는가

Cereblab은 Grok Build CLI의 네트워크 트래픽을 추적하여 Google Cloud 버킷으로 연결되는 것을 확인했으며, 이 도구가 전체 git 저장소를 자동으로 패키징하여 업로드한다는 사실을 발견했습니다. 요컨대, 어시스턴트가 무시하도록 설정된 데이터를 가져온 것입니다.

침해 사고 발견 경위

연구원들이 페이로드를 조사한 결과, 업로드 플래그가 기본적으로 활성화되어 있으며 전역적인 거부(opt-out) 설정이 없음을 확인했습니다. Lukasz Olejnik 박사는 이러한 "과도한 데이터 보유"가 비즈니스 로직, 인프라 세부 정보 및 인증 토큰을 유출할 수 있다고 경고했습니다. Claude Code를 기준으로 다른 AI 코딩 어시스턴트와 비교했을 때, Grok Build의 동작은 현저히 더 침해적입니다.

SpaceXAI의 대응

보고서가 공개된 후, SpaceXAI는 disable_codebase_upload: true 플래그를 반환하는 업데이트를 배포하여 사실상 해당 기능을 종료했습니다. Elon Musk는 X를 통해 업로드된 모든 데이터가 "완전히 그리고 철저히 삭제될 것"이라고 발표하며 "개인정보 보호 설정은 항상 존중된다"고 재차 강조했습니다. 또한 그는 "디버깅 문제"를 위해 회사가 데이터를 보유할 수 있도록 해달라고 요청했는데, 이는 많은 이들이 모순적이라고 느끼는 부분입니다.

회사는 데이터 보유를 제어하기 위해 /privacy CLI 명령어를 권장했지만, 연구원들은 이것이 세션별 저장 여부만 전환할 뿐 체계적인 저장소 업로드를 중단시키지는 못한다고 지적했습니다.

개발자와 기업에 이것이 중요한 이유

AI 기반 코딩 에이전트는 자동 완성을 넘어 코드를 읽고, 수정하고, 커밋할 수 있는 자율적인 도구로 진화하고 있습니다. 에이전트가 로컬 ignore 파일을 우회하거나 삭제된 비밀 정보를 다시 불러올 수 있는 상황에서, "데이터 보유 제로(zero data retention)"라는 약속은 단순한 UI 설정이 아닌 기술적 테스트를 통해 검증되어야 합니다. CTO와 제품 책임자는 다음과 같은 조치를 취해야 합니다:

  • 실제 코드베이스에서 AI 도구의 동작에 대한 독립적인 감사를 의뢰하십시오.
  • 데이터 처리, 보관 기간 및 삭제 보장을 정의하는 명확한 계약을 협상하십시오.
  • 민감한 저장소에 대해 파일 수준의 권한을 강제하는 런타임 보호 조치를 구현하십시오.

이번 침해 사고는 AI의 편의성과 보안 사이의 절충(trade-off)에 대한 더 넓은 질문을 던집니다. SpaceXAI는 업로드 기능이 모델 개선을 위한 사용 지표를 수집하기 위한 것이었다고 주장하며, 해당 기능을 비활성화하고 기존 업로드 데이터를 삭제하겠다고 약속했습니다. 비판론자들은 기존 설계에 투명한 옵트아웃(opt-out) 기능이 부족했으며, 사고 발생 후 도입된 개인정보 보호 명령이 이미 클라우드에 저장된 데이터를 소급하여 보호하지 못한다는 점을 지적합니다.

SpaceXAI의 반론

SpaceXAI는 업로드 기능이 모델 개선을 위한 사용 지표를 수집하기 위한 목적이었다고 주장합니다. SpaceXAI는 기능을 신속하게 비활성화하고 기존 업로드 데이터를 삭제하겠다고 약속한 것을 책임 있는 대응의 증거로 꼽습니다. 비판론자들은 초기 설계에 명확한 옵트아웃 기능이 없었으며, 개인정보 보호 명령이 이미 클라우드에 저장된 데이터를 보호하지 못한다고 반박합니다.

시사점

AI 코딩 어시스턴트가 전체 저장소를 조용히 탈취할 수 있다면, 신뢰는 마케팅의 문제가 아닌 기술적인 문제가 됩니다. 기업은 숨겨진 데이터 유출을 방지할 수 있는 검증 가능하고 실행 가능한 통제 수단을 요구해야 하며, 그렇지 않으면 경쟁 우위를 제공하는 바로 그 코드를 노출할 위험을 감수해야 합니다.