Grok Build 저장소 전송 분석이 오늘 개발자 커뮤니티에서 꽤 크게 번졌다. 독립 연구자가 grok 0.2.93의 네트워크 트래픽을 캡처했더니, 에이전트가 읽은 파일뿐 아니라 Git 이력을 포함한 저장소 묶음도 별도 스토리지 경로로 전송됐다는 내용이다.
처음엔 나도 “클라우드 코딩 에이전트가 코드를 서버에 보내는 게 당연한 것 아닌가” 싶었다. 맞는 말이다. 모델이 원격에 있으면 작업에 필요한 코드 문맥은 나가야 한다. 근데 필요한 문맥과 저장소 전체는 같은 말이 아니다. 특히 .env, 과거 커밋, 에이전트가 열지 않은 파일까지 범위가 넓어지면 이건 성능보다 운영 경계의 문제다.
Grok Build 저장소 전송 분석에서 확인된 것
0.2.93 한 버전의 재현 가능한 관측이다
이번 논란의 1차 소스는 독립 연구자 cereblab의 와이어 수준 분석이다. 테스트 대상은 Apple Silicon용 grok 0.2.93이고, 실제 자격 증명 대신 가짜 canary 문자열을 넣은 throwaway 저장소를 썼다. mitmproxy로 요청 경로, 상태 코드, 바이트 수를 잡고 로컬 업로드 큐도 풀어서 확인했다.
보고서가 주장하는 핵심은 두 갈래다. 하나는 에이전트가 읽은 파일 내용이 모델 요청인 /v1/responses로 전송됐다는 것. 다른 하나는 추적 파일과 Git 이력을 묶은 저장소 아카이브가 /v1/storage를 통해 업로드됐다는 것이다. 테스트용 .env 값은 모델 요청과 session_state 아카이브에서 모두 확인됐다고 적었다.
12GB 무작위 파일 저장소 실험에서는 모델 요청이 약 192KB였던 반면, 스토리지 전송은 캡처를 중단한 시점까지 5.10GiB에 도달했다. 다만 전체 12GB가 끝까지 전송됐다고 입증한 건 아니다. 분석자가 이 한계를 직접 적어둔 점은 오히려 신뢰를 높인다. 센 숫자만 떼어 모든 저장소를 끝까지 업로드한다고 말하면 원문보다 더 나간 주장이다.
전송과 학습 사용은 구분해야 한다
더 중요한 제한도 있다. 이 분석은 데이터가 전송되고 서버가 HTTP 200으로 수락한 것까지 보여준다. 그 데이터가 모델 학습에 쓰였다는 사실은 입증하지 않는다. “Improve the model” 설정을 꺼도 trace 관련 업로드 플래그가 유지됐다는 관측과, 실제 학습 사용 여부는 별개의 문제다.
xAI의 개인정보 처리방침은 서비스에서 수집·사용하는 개인정보와 비즈니스 상품의 고객 데이터 처리 범위를 구분한다. 하지만 정책 문서만 읽어서는 특정 CLI 버전이 어떤 파일을 어떤 엔드포인트로 보내는지 알기 어렵다. 반대로 패킷 캡처 하나만으로 모든 계정 유형과 조직 정책을 일반화할 수도 없다. 정책과 실제 동작을 같이 봐야 하는 이유다.
왜 이 논란이 코딩 에이전트 보안 문제인가
“읽을 수 있음”과 “전송해도 됨”은 다르다
코딩 에이전트는 저장소를 읽어야 일한다. 문제는 개발자 노트북의 저장소가 코드만 담고 있지 않다는 데 있다. 오래된 커밋에는 삭제한 키가 남을 수 있고, 테스트 fixture에는 고객과 비슷한 형태의 데이터가 들어가며, 로컬 설정에는 내부 호스트와 계정명이 섞인다. 현재 워킹 트리가 깨끗해 보여도 Git 이력까지 묶으면 노출 범위가 확 커진다.
그래서 권한을 “이 디렉터리를 읽을 수 있다” 하나로 끝내면 안 된다. 파일 읽기, 모델 문맥 전송, 세션 보관, 진단 trace 업로드, 제품 개선 사용은 서로 다른 목적이다. 사용자 화면에서 토글 하나로 뭉쳐 보이더라도 운영팀은 별도 경계로 봐야 한다.
이전에 쓴 Agentjacking이 AI 코딩 에이전트 보안을 흔들었다에서는 외부 도구 출력이 실행 지시로 승격되는 문제를 다뤘다. 이번 건은 방향이 반대다. 외부 입력이 안으로 들어오는 대신, 내부 저장소가 에이전트의 부가 기능을 타고 밖으로 나갈 수 있다. 둘 다 본질은 같다. 모델의 지능보다 데이터와 권한의 이동 경로가 먼저다.
공식 최신 버전과 분석 버전을 섞지 말아야 한다
xAI는 2026년 5월 Grok Build를 터미널 코딩 에이전트로 공개했고, 공식 변경 기록은 7월 12일 기준 v0.2.98을 최신으로 표시한다. 논란의 분석 대상은 v0.2.93이다. 버전이 이미 다르다.
이 차이를 두고 “옛 버전 얘기니 끝”이라고 말하는 것도 성급하고, “최신 버전도 무조건 똑같다”고 말하는 것도 성급하다. 팀이 해야 할 일은 간단하다. 설치된 버전을 고정하고, 같은 테스트 저장소와 가짜 canary로 최신 버전의 전송 범위를 다시 확인하는 것이다. 공식 변경 기록에 보안 관련 수정이 보이면 적용하고, 보이지 않으면 공급사에 동작 범위와 보존 정책을 직접 묻는 편이 낫다.
팀에서 바로 확인할 코딩 에이전트 경계
저장소를 열기 전에 노출 자산부터 센다
나는 새 코딩 에이전트를 팀 저장소에 붙일 때 기능 데모보다 먼저 노출 자산 목록을 보는 게 맞다고 생각한다. 아래 정도는 로컬에서 바로 확인할 수 있다.
# 현재 Git이 추적하는 파일 범위
git ls-files
# 무시되는 파일 중 로컬에 남아 있는 민감 후보
git ls-files --others --ignored --exclude-standard
# 최근 이력에 환경 변수나 키 파일이 들어간 적이 있는지 점검
git log --all --name-only --pretty=format: | sort -u
이 명령이 안전을 보장하진 않는다. 그래도 “에이전트가 지금 보는 폴더”와 “저장소에 실제로 들어 있는 자산”이 다를 수 있다는 건 금방 드러난다. .env를 .gitignore에 넣었다고 끝이 아니다. 예전 커밋, 서브모듈, 생성물, 홈 디렉터리의 공용 설정까지 따로 봐야 한다.
그다음엔 테스트 저장소를 만든다. 실제 키 대신 식별 가능한 canary 문자열을 넣고, 에이전트가 읽어야 하는 파일과 읽지 말아야 하는 파일을 나눈다. 프록시나 호스트 방화벽 로그로 목적지와 전송량을 확인한다. 이 과정 없이 고객 저장소부터 여는 건 너무 비싸게 배우는 방식이다.
샌드박스와 네트워크 허용 목록을 같이 쓴다
이번 Hacker News 토론은 확인 시점에 406점과 158개 댓글이 붙었다. 반응 중 가장 현실적이었던 건 “코딩 도구를 별도 샌드박스에 넣고, 프로젝트 디렉터리만 보여주며, 네트워크도 필요한 모델 호스트로 제한한다”는 운영 방식이었다.
파일 샌드박스만 쓰면 읽을 수 있는 범위는 줄지만, 허용된 파일이 어디로 전송되는지는 통제하지 못한다. 네트워크 허용 목록만 쓰면 목적지는 줄지만, 에이전트가 홈 디렉터리 전체를 읽는 문제는 남는다. 둘을 같이 써야 실패 반경이 작아진다.
조직용 제품이라면 감사 로그도 필요하다. 어떤 세션이 어떤 저장소에서 시작됐는지, 어느 도메인으로 몇 바이트가 나갔는지, 세션 아카이브가 얼마 동안 보관되는지 확인할 수 있어야 한다. “우리는 학습에 쓰지 않는다”는 문구만으로는 사고 조사에 부족하다. 전송, 저장, 보존, 삭제를 각각 증명할 수 있어야 한다.
이번 논란을 과장 없이 받아들이는 법
공급사 답변 전까지는 검증된 범위만 말한다
GeekNews의 한국어 요약도 이 사건을 빠르게 전달했지만, 핵심은 원문이 적어둔 한계까지 같이 읽는 것이다. 특정 버전, 특정 소비자 계정, 특정 운영체제에서 재현됐다. 모든 설정 조합을 시험하지 않았고, 모델 학습 사용도 입증하지 않았다. 이 선을 지키면 글이 덜 자극적이어도 훨씬 쓸모 있다.
내 판단은 이렇다. 이번 분석만으로 Grok Build 전체를 악성 도구라고 부를 근거는 부족하다. 반대로 클라우드 코딩 에이전트는 원래 코드를 보내니까 괜찮다고 넘길 일도 아니다. 저장소 전체와 Git 이력이 별도 trace 경로로 이동한다면 사용자가 예상하는 최소 문맥 전송을 넘어설 수 있다. 제품은 그 차이를 명확히 설명해야 한다.
결국 팀이 소유해야 할 건 경계와 증거다
코딩 에이전트가 강해질수록 설치는 더 쉬워지고, 경계 확인은 더 어려워진다. 한 줄 설치 뒤에 파일 접근, 명령 실행, 네트워크 전송, 세션 저장이 한꺼번에 붙는다. 편한 UX가 위험하다는 뜻은 아니다. 편한 UX일수록 운영 증거를 별도로 남겨야 한다는 뜻이다.
지금 Grok Build를 쓰고 있다면 먼저 버전을 확인하고 실제 저장소 대신 테스트 저장소에서 재현하는 게 맞다. 고객 코드나 운영 키가 있는 환경이라면 공급사의 공식 설명과 수정 여부가 확인될 때까지 읽기 범위와 네트워크를 제한하는 편이 안전하다.
나는 이번 이슈를 “또 AI가 위험하다”는 뉴스로 소비하고 싶지 않다. 오히려 코딩 에이전트를 팀 도구로 들일 때 무엇을 검증해야 하는지 아주 구체적으로 보여준 사례에 가깝다. 모델 비교표보다 먼저 볼 건 저장소 경계다. 그리고 그 경계는 프롬프트가 아니라 파일 시스템, 네트워크, 로그로 증명해야 한다.