안녕하세요, SCV입니다.
AI 코딩 에이전트가 작업에 필요한 소스 일부를 모델 서버로 보내는 일은 클라우드형 서비스의 작동 방식상 어느 정도 예상할 수 있습니다. 그러나 에이전트가 읽지 않은 파일, 전체 Git 이력, 과거 커밋에 남아 있던 비밀값까지 저장소 묶음으로 만들어 별도 스토리지에 올린다면 이야기가 달라집니다. 2026년 7월 공개된 Grok Build CLI 네트워크 분석은 바로 그 경계를 건드렸습니다.
먼저 결론부터 정리하겠습니다. 독립 보안 연구자 CEREBLAB은 macOS Apple Silicon 환경의 grok 0.2.93을 프록시로 관찰해 2개의 전송 경로를 확인했습니다. 첫 번째는 모델 답변에 필요한 파일 내용이 들어가는 /v1/responses, 두 번째는 세션 상태와 저장소 스냅샷이 들어가는 /v1/storage였습니다. 테스트에서 읽은 .env의 가짜 API 키와 비밀번호가 마스킹되지 않은 채 첫 번째 경로와 세션 아카이브에 포함됐고, 별도의 Git bundle에는 읽지 말라고 지시한 파일과 전체 커밋 이력이 들어 있었습니다.
이 사건을 현재 진행형으로만 쓰는 것도 정확하지 않습니다. 최초 공개 뒤인 2026년 7월 13일, 같은 연구자가 서버 설정에서 disable_codebase_upload: true와 trace_upload_enabled: false를 확인했고 전체 코드베이스 업로드가 더 이상 발생하지 않는다고 재검증했습니다. 이후 grok 0.2.99에서도 전체 저장소 업로드가 기본적으로 꺼진 상태를 확인했습니다. 따라서 정확한 표현은 “특정 버전과 당시 서버 설정에서 실제 업로드가 확인됐고, 공개 뒤 서버 측에서 중단됐다”입니다.
다만 중단됐다는 사실만으로 사후 대응이 끝나는 것은 아닙니다. 이미 전송된 데이터의 범위, 보관 기간, 접근 기록, 삭제 완료를 사용자가 독립적으로 확인할 방법은 여전히 분명하지 않습니다. 해당 기간 Grok Build를 회사 저장소에서 실행했다면, 지금 업로드가 꺼졌더라도 당시 저장소에 있던 자격 증명은 교체 대상으로 보는 편이 안전합니다.
문제의 구조를 한눈에 보기
모델 답변 경로와 저장소 스냅샷 경로는 서로 달랐습니다.
SECTION 01
1. 연구자가 실제로 확인한 2개의 전송 채널
이번 분석을 이해하려면 “모델이 읽은 파일 전송”과 “저장소 전체 스냅샷 업로드”를 분리해야 합니다. 둘을 섞으면 정상적인 클라우드 추론과 과도한 수집의 경계가 흐려집니다.
채널 A인 POST /v1/responses는 모델 턴을 처리하는 요청입니다. 연구자가 심은 가짜 비밀값 API_KEY=CANARY...와 DB_PASSWORD=CANARY...는 Grok이 해당 파일을 읽은 뒤 요청 본문에서 원문 그대로 발견됐습니다. 같은 내용은 session_state 아카이브에도 담겨 POST /v1/storage 경로로 전송될 준비가 된 상태가 확인됐습니다. 여기서 입증된 것은 테스트에 사용한 Git 추적 .env 내용이 마스킹되지 않았다는 점입니다. 모든 형태의 토큰에 탐지기가 전혀 없다고 일반화하거나, .gitignore에 포함된 파일까지 무조건 같은 방식으로 처리된다고 단정할 근거는 부족합니다.
채널 B는 더 큰 문제였습니다. Grok에 “정확히 OK라고 답하고 어떤 파일도 열지 말라”고 지시했는데도 저장소가 Git bundle로 묶여 /v1/storage로 전송됐고 서버는 HTTP 200을 반환했습니다. 캡처한 bundle을 다시 git clone하자 에이전트가 읽지 않은 canary 파일, 47개 파일, 4개 커밋과 전체 Git 이력이 복원됐습니다. 두 번째 독립 저장소에서도 다른 canary를 사용해 같은 결과가 재현됐습니다.
Git 이력이 포함된다는 점은 특히 중요합니다. 현재 작업 트리에서 비밀 파일을 삭제했더라도 과거 커밋에 키나 고객 정보가 남아 있다면 bundle을 통해 함께 이동할 수 있기 때문입니다. .gitignore는 아직 Git에 추가되지 않은 파일을 보호하는 규칙이지, 이미 커밋된 기록을 지우는 장치가 아닙니다.
SECTION 02
2. 192KB 요청과 5.10GiB 업로드가 보여 준 것
연구자는 압축이 잘 되지 않는 무작위 파일로 약 12GB 저장소를 만들고 전송량을 비교했습니다. 같은 세션에서 모델 요청인 /v1/responses 5건의 합계는 196,705바이트, 약 192KB였습니다. 반면 /v1/storage는 캡처를 중단할 때까지 5,476,228,005바이트, 약 5.10GiB를 전송했습니다. 약 75MB 크기 청크 73개를 포함한 저장 요청은 모두 HTTP 200을 받았습니다.
두 경로의 차이는 약 27,800배입니다. 모델 요청이 192KB에 불과하므로 모델이 5GiB의 파일을 일일이 읽고 답변 문맥으로 사용했다고 볼 수 없습니다. 그럼에도 별도 저장 채널에서 수 GiB가 빠져나갔다는 사실은 작업에 필요한 파일만 보내는 흐름과 다른 전체 저장소 수집 경로가 존재했음을 강하게 뒷받침합니다.
여기에도 한계는 있습니다. 12GB 전체가 끝까지 업로드된 것은 아닙니다. 연구자가 5.10GiB 지점에서 캡처를 멈췄고, 64MB·600MB·3GB 시험의 상세 로그는 보존되지 않았습니다. 그러므로 “12GB 전부가 서버에 저장됐다”고 쓰면 과장입니다. 입증된 범위는 5.10GiB 이상이 성공 응답을 받으며 계속 전송되고 있었다는 것입니다.
SECTION 03
3. 왜 단순한 ‘클라우드 AI니까 당연하다’로 넘길 수 없나
클라우드형 코딩 에이전트는 답변을 만들기 위해 관련 코드를 서버에 보낼 수밖에 없습니다. 사용자가 파일 분석을 요청했다면 해당 파일 내용이 모델 API로 전송되는 것은 예상 가능한 동작입니다. 하지만 이 사건의 핵심은 필요한 문맥 전송 자체가 아닙니다.
첫째, 전송 범위가 작업 필요성을 넘어섰습니다. 명시적으로 열지 말라고 한 파일과 전체 Git 이력이 별도 bundle에 포함됐습니다. 최소 수집 원칙으로 보면 “현재 작업에 필요한 코드 조각”과 “저장소 전체 및 과거 기록”은 같은 범주가 아닙니다.
둘째, 비밀값 마스킹이 확인되지 않았습니다. 테스트용 .env 값이 모델 요청과 저장용 세션 아카이브에서 그대로 복구됐습니다. 사용자가 실제 운영 키를 저장소에 둔 것 자체도 잘못된 보안 습관이지만, 에이전트가 이를 탐지해 경고하거나 전송 전 제외하지 않은 것은 별도의 제품 안전 문제입니다. 사용자 실수와 제품의 과도한 전송은 동시에 성립할 수 있습니다.
셋째, “Improve the model” 설정을 꺼도 당시 전체 저장소 업로드는 계속됐습니다. 연구자가 확인한 서버 설정에는 trace_upload_enabled: true, upload_enabled: true가 남아 있었습니다. 모델 개선 동의와 서비스 처리를 위한 전송·보관이 법적·기술적으로 다른 개념일 수는 있지만, 사용자 입장에서는 같은 화면의 개인정보 설정이 코드의 외부 전송까지 막아 줄 것으로 오해하기 쉽습니다. 전송, 보관, 학습을 각각 분리해 설명하고 제어했어야 합니다.
넷째, 설치 및 빠른 시작 자료에서 이 구체적인 저장소 스냅샷 파이프라인을 연구자가 찾지 못했습니다. 모든 xAI 문서를 전수 조사한 것은 아니므로 “어디에도 고지하지 않았다”고 단정할 수는 없습니다. 그러나 개발자가 CLI를 설치하고 처음 실행하는 경로에서 전체 Git bundle 업로드가 명확히 드러나지 않았다면 실질적인 동의의 질은 낮아집니다.
SECTION 04
4. 현재 상태: 전체 저장소 업로드는 중단됐지만 논점은 남았다
2026년 7월 13일 재검증에서 서버는 disable_codebase_upload: true를 반환했고 같은 클라이언트에서도 전체 저장소 업로드가 더 이상 실행되지 않았습니다. 연구 페이지는 이 문제를 FIXED로 표시하고 있습니다. 이는 신규 실행의 가장 큰 위험이었던 “읽지 않은 저장소 전체와 Git 이력 업로드”가 서버 측 전역 플래그로 차단됐다는 의미입니다.
새로 추가된 /privacy opt-out은 별도로 이해해야 합니다. 연구자의 A/B 테스트에서는 opt-in과 opt-out 모두 모델 턴과 세션 추적 요청 자체는 전송됐고, /privacy 명령은 codingDataRetentionOptOut: true를 서버에 설정해 보관 방식을 바꾸는 동작으로 분석됐습니다. 즉 전체 코드베이스 업로드를 멈춘 핵심 장치는 개인정보 명령이 아니라 disable_codebase_upload 전역 플래그였습니다. 현재도 클라우드 모델이 답변에 필요한 파일과 세션 데이터를 전송하는 기본 구조까지 사라진 것은 아닙니다.
xAI 측은 과거 업로드 데이터 삭제를 약속한 것으로 보도됐지만, 삭제 완료 여부와 영향을 받은 사용자·버전·세션의 정확한 범위는 외부에서 확인하기 어렵습니다. 삭제 약속은 필요한 조치지만, 이미 노출 가능성이 생긴 자격 증명의 안전을 되돌려 주지는 않습니다. 키가 실제로 악용되지 않았더라도 “누가 접근했는지 확인할 수 없는 외부 저장소로 전송됐다”는 사실만으로 교체 판단을 내리는 것이 일반적인 사고 대응 원칙에 가깝습니다.
SECTION 05
5. 이번 분석이 입증하지 않은 것
가장 중요한 선 긋기는 “업로드·수락·저장”과 “모델 학습 사용”을 구분하는 것입니다. 네트워크 캡처는 데이터가 기기를 떠나 특정 엔드포인트로 전송되고 HTTP 200을 받았다는 사실, 저장용 아카이브와 GCS 목적지 문자열을 보여 줍니다. 하지만 그 데이터가 실제 학습 파이프라인에 투입됐는지까지는 보여 주지 못합니다.
또한 실험은 grok 0.2.93, macOS Apple Silicon, 2026년 7월 당시 계정과 서버 설정에 한정됩니다. 모든 운영체제, 모든 계정 등급, 모든 설정 조합에서 똑같았다고 일반화할 수 없습니다. .gitignore 파일의 전체 저장소 업로드 포함 여부도 별도 실험으로 입증되지 않았습니다. 반대로 이 한계들이 캡처된 Git bundle과 복원된 미열람 파일, 성공한 다중 GiB 전송이라는 핵심 증거를 무효화하지는 않습니다.
따라서 가장 정확한 요약은 다음과 같습니다. “특정 Grok Build 버전과 당시 서버 설정에서 전체 Git 저장소와 이력이 별도 저장 채널로 업로드됐고, 읽은 비밀 파일은 마스킹되지 않았다. 학습 사용은 입증되지 않았으며, 전체 코드베이스 업로드는 이후 서버 측에서 비활성화됐다.”
SECTION 06
6. Grok Build를 사용했다면 바로 할 일
첫 번째는 사용 시점을 확인하는 것입니다. 2026년 7월 13일 이전 또는 수정 상태를 확인하기 전에 Grok Build를 민감한 저장소에서 실행했다면 영향 가능성을 열어 두는 편이 안전합니다. 로컬 로그와 ~/.grok/upload_queue 흔적은 참고할 수 있지만, 큐가 비었다는 사실만으로 업로드 성공 여부를 단정해서는 안 됩니다. 큐는 성공 또는 폐기 상황 모두에서 비워질 수 있기 때문입니다.
두 번째는 비밀정보 목록을 만드는 것입니다. 현재 파일뿐 아니라 Git 전체 이력을 기준으로 API 키, 클라우드 액세스 키, 데이터베이스 비밀번호, OAuth 클라이언트 시크릿, 배포 토큰, 서명 키를 찾습니다. 실제 값이 존재했다면 단순 삭제가 아니라 폐기와 재발급이 필요합니다. 권한을 최소화하고 새 키 발급 뒤 이전 키를 즉시 비활성화해야 합니다.
세 번째는 로그를 점검하는 것입니다. GitHub, GitLab, AWS, Google Cloud, Azure, 데이터베이스, 결제 및 배포 서비스의 접근 로그에서 낯선 IP, 비정상 시간대, 권한 상승, 대량 조회를 확인합니다. 키 교체만 하고 접근 기록을 보지 않으면 이미 발생한 오용을 놓칠 수 있습니다.
네 번째는 회사 보안팀과 법무·개인정보 담당자에게 알리는 것입니다. 저장소에 고객 개인정보, 계약상 비밀, 제3자 라이선스 코드, 규제 대상 데이터가 있었다면 개인 개발자의 도구 설정 문제가 아니라 조직 차원의 외부 전송 사고가 될 수 있습니다. 관련 고객·파트너 통지 의무는 계약과 관할 법률에 따라 달라지므로 담당 조직이 판단해야 합니다.
다섯 번째는 삭제 요청과 증거 보존을 병행하는 것입니다. xAI에 계정과 사용 기간, 사용한 CLI 버전, 관련 세션을 적어 보유 데이터의 범위·삭제·처리 이력을 문의합니다. 동시에 로컬 로그, 실행 시각, 저장소 커밋 해시, 당시 설정 화면을 보존합니다. 삭제를 요청한다고 해서 조사에 필요한 로컬 증거까지 지우면 안 됩니다.
SECTION 07
7. 앞으로 AI 코딩 에이전트를 안전하게 쓰는 기준
가장 현실적인 방어는 에이전트가 볼 수 있는 경계를 줄이는 것입니다. 개인 홈 디렉터리 전체가 아니라 작업용 복제본이나 임시 컨테이너에서 실행하고, SSH 키·클라우드 설정·브라우저 프로필·비밀번호 저장소는 마운트하지 않습니다. 네트워크를 허용해야 한다면 필요한 모델 API 호스트만 허용하는 egress 제어도 도움이 됩니다.
저장소에는 실제 운영 비밀값을 두지 않습니다. .env.example에는 키 이름과 더미 값만 남기고 실제 값은 비밀관리 서비스나 CI/CD의 보호된 변수에서 주입합니다. 이미 커밋된 비밀은 파일 삭제만으로 끝내지 말고 Git 이력 정리와 키 교체를 함께 수행합니다. 이력 재작성은 협업자에게 영향을 주므로 조직 절차에 따라 진행해야 합니다.
도구를 도입할 때는 “학습에 사용하지 않음” 한 문장만 확인해서는 부족합니다. 어떤 파일이 전송되는지, 저장소 전체 스냅샷을 만드는지, 서버 보관 기간은 얼마인지, 하위 처리업체는 누구인지, 삭제 요청이 가능한지, 기업용 zero data retention 계약이 실제 어느 엔드포인트에 적용되는지 확인해야 합니다. 전송·보관·학습은 서로 다른 질문입니다.
조직에서는 허용 도구 목록과 버전 고정을 운영해야 합니다. 자동 업데이트만 믿지 말고 새 버전 배포 전 샌드박스에서 파일 접근과 네트워크 전송을 검사합니다. 최소한 테스트용 canary 문자열을 심고 프록시나 방화벽 로그에서 외부 전송 여부를 확인하면 “문서상 약속”과 “실제 동작”의 차이를 잡는 데 도움이 됩니다.
SECTION 08
8. 최종 판단
이번 사건은 “AI가 코드를 본다”는 일반론보다 더 구체적입니다. 읽은 파일이 모델 요청에 들어가는 예상 가능한 동작 옆에, 읽지 않은 파일과 Git 이력까지 별도 스토리지 경로로 보내는 동작이 존재했습니다. 모델 개선 설정을 꺼도 멈추지 않았고, 공개 뒤 서버 측 플래그로 중단됐다는 시간 순서까지 확인됐습니다. 그래서 보안 이슈의 핵심은 단순 클라우드 사용이 아니라 최소 수집, 명확한 고지, 비밀정보 처리, 사용자가 통제할 수 있는 전송 차단 장치가 부족했다는 데 있습니다.
현재 전체 저장소 업로드가 꺼졌다는 점은 분명히 반영해야 합니다. 동시에 과거 사용자는 “수정됐으니 괜찮다”는 말만으로 사고 대응을 끝내면 안 됩니다. 당시 저장소에 실제 자격 증명이나 고객 데이터가 있었다면 교체·로그 검토·내부 보고·삭제 문의까지 진행하는 것이 안전합니다.
AI 코딩 에이전트는 개발 속도를 크게 높이지만, 로컬에서 실행된다는 이유만으로 로컬 도구는 아닙니다. 앞으로의 기본 전제는 간단합니다. 에이전트가 읽을 수 있는 파일은 외부로 전송될 수 있고, 제품 버그가 있으면 그 범위가 더 넓어질 수 있습니다. 따라서 신뢰는 브랜드나 설정 문구가 아니라 최소 권한, 격리, 네트워크 관찰, 비밀정보 분리로 만들어야 합니다.
SECTION 09
9. 기업 도입 전 확인해야 할 계약·기술 체크리스트
기업이 AI 코딩 도구를 승인할 때는 일반 소비자용 개인정보 설정과 기업 계약을 구분해야 합니다. “학습에 사용하지 않는다”는 약속만으로는 부족하며, 추론을 위해 전송된 코드가 어느 지역의 어떤 저장소에 머무는지, 백업과 장애 복구 복제본까지 언제 삭제되는지, 지원 인력이 평문에 접근할 수 있는지 확인해야 합니다. zero data retention이 제공된다면 모델 요청, 세션 추적, 파일 업로드, 오류 로그 등 모든 엔드포인트에 동일하게 적용되는지도 계약서에 명시해야 합니다.
기술 검증에는 최소 3가지 시험이 필요합니다. 먼저 작업과 무관한 canary 파일을 저장소에 두고 에이전트가 읽지 않은 상태에서 외부 전송 여부를 확인합니다. 다음으로 가짜 API 키를 포함한 파일을 읽게 해 비밀 탐지·경고·마스킹이 작동하는지 봅니다. 마지막으로 학습 거부와 보관 거부를 각각 켜고 네트워크 요청과 서버 응답이 어떻게 달라지는지 비교합니다. 설정 화면의 문구가 아니라 패킷과 감사 로그로 결과를 남겨야 합니다.
운영 단계에서는 버전 변경을 공급망 변경으로 취급하는 편이 좋습니다. 자동 업데이트 뒤 바이너리 해시와 권한, 새 도메인 접속, 업로드 크기를 점검하고 이상이 있으면 중앙 방화벽에서 즉시 차단할 수 있어야 합니다. 개발자 개인에게 모든 책임을 넘기지 말고 승인된 샌드박스, 비밀관리, 로그 수집, 사고 신고 채널을 조직이 제공해야 합니다. 그래야 생산성 도구의 편익을 유지하면서도 예기치 않은 수집 동작을 빠르게 발견하고 영향 범위를 줄일 수 있습니다.
FAQ
자주 묻는 질문
SOURCES
근거와 원문
확인일: 2026년 7월 15일. 제품 동작과 정책은 이후 변경될 수 있습니다.
'NEWS' 카테고리의 다른 글
| 배민 우버에 인수된다? 공식 발표 뜯어보니 실제 인수자는 SSW (0) | 2026.07.20 |
|---|---|
| 내 GitHub가 축구 선수 카드가 된다? GitFut 사용법과 토발즈 96점 분석 (0) | 2026.07.15 |
| Anthropic Claude 연구: Global Workspace와 J-space로 보는 AI의 숨은 사고 구조 (0) | 2026.07.07 |
| Codex Micro 티저: AI 코딩 전용 버튼이 온다 (0) | 2026.07.03 |
| GitHub CD-ROM 이벤트 신청 후기: 내 공개 repo를 진짜 CD로 받는다고? (1) | 2026.07.03 |
