xAI Grok Build CLI가 xAI로 전송하는 데이터: 와이어 수준 분석

 (gist.github.com/cereblab)
1P by GN⁺ | ★ favorite | 댓글 1개
  • grok 0.2.93의 네트워크 트래픽을 직접 캡처한 결과, Grok Build는 읽은 파일을 마스킹 없이 전송하고 session_state로 저장했으며 테스트용 .env 비밀값도 두 경로에 그대로 포함했음
  • 모델 요청이 에이전트가 읽은 파일을 보내는 것과 별개로, 모든 추적 파일과 Git 이력을 담은 저장소 전체가 git bundle로 업로드됐고 열지 말라고 지정한 파일도 원문 그대로 복구됐음
  • 12GB 무작위 파일 저장소에서 /v1/responses 요청은 총 192KB였지만 /v1/storage 전송량은 캡처 중단 시점까지 5.10GiB에 달해 약 27,800배 차이가 났으며, 모든 저장 요청이 HTTP 200을 반환했음
  • 업로드 목적지는 Google Cloud Storage의 grok-code-session-traces 버킷이었고, “Improve the model”을 꺼도 trace_upload_enabled: true와 upload_enabled: true가 유지되며 전체 저장소 업로드가 계속됐음
  • 실험은 데이터의 전송·수락·저장을 입증하지만 모델 학습에 사용됐는지는 확인하지 못했으며, .gitignore 파일과 모든 계정·설정 조합도 시험하지 않아 결과는 2026년 7월의 특정 버전에 한정됨

테스트 대상과 분석 범위

  • 대상은 일반 소비자 계정으로 로그인한 xAI 공식 Grok Build CLI였음
    • 설치 경로는 ~/.grok/bin/grok
    • 브라우저에서 X 또는 SuperGrok 계정으로 인증하며 API 키는 사용하지 않음
    • 테스트 바이너리는 Apple Silicon용 grok 0.2.93 (f00f96316d4b)임
    • SHA-256은 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c임
  • 바이너리 문자열에서 자체 Rust 업로드 구성요소와 저장소 관련 상수가 확인됐음
    • crates/codegen/xai-data-collector/src/gcs.rs
    • storage_client.rs, queue.rs, file_access_tracker.rs, circuit_breaker_observer.rs
    • xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
    • grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
  • 모든 캡처는 테스트 수행자의 컴퓨터와 트래픽만을 대상으로 했으며, 저장소에는 실제 자격 증명 대신 고유 canary 문자열을 넣었음

재현 및 트래픽 캡처 방법

  • macOS Apple Silicon에서 mitmproxy의 CA를 로그인 키체인에 신뢰 인증서로 추가하고 HTTPS_PROXY와 SSL_CERT_FILE을 설정해 Grok의 HTTPS 요청을 캡처함
  • Grok은 이 구성에서 인증서 고정(certificate pinning) 으로 캡처를 차단하지 않았음
  • mitmdump 애드온으로 요청별 메서드, 호스트, 경로, 응답 상태, 요청 바이트 크기를 기록하고 xAI 호스트로 향하는 요청 본문을 저장함
  • ~/.grok/upload_queue/*를 실행 중 복사한 뒤 gzip과 tar로 풀어 전송 대기 중인 스테이징 아티팩트도 검사함
  • 각 파일에는 출처를 구분할 수 있는 고유 마커를 넣었으며, 비밀 파일에는 다음과 같은 가짜 값을 사용함
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

채널 A: 읽은 파일과 .env의 모델 요청 전송

  • Grok이 읽은 파일 내용은 POST cli-chat-proxy.grok.com/v1/responses의 모델 턴 본문에 직렬화됐음
    • 캡처된 48,070바이트 요청에는 "model":"grok-4.5"와 메시지 배열이 포함됐음
    • .env의 API_KEY와 DB_PASSWORD canary가 줄바꿈까지 원문 그대로 발견됐음
    • 소스, 로직, README, 중첩된 JavaScript 파일과 두 비밀값을 포함한 6개 마커를 요청 본문에서 복구할 수 있었음
  • 같은 내용은 session_state 아카이브에도 들어가 POST /v1/storage로 업로드됐으며, 해당 저장 요청은 HTTP 200으로 수락됐음
    • 압축 아카이브를 풀어 검사하자 두 비밀값과 다른 파일 마커가 모두 발견됐음
    • 비밀값은 모델이 일시적으로 처리하는 데 그치지 않고 저장용 아카이브에도 기록됐음
  • Reply exactly OK, do not read any files라는 통제 프롬프트에서는 열지 않은 untouched_secret.txt의 마커가 /v1/responses 본문에 나타나지 않았음
    • 이는 모델 요청 채널이 에이전트가 실제로 읽은 파일을 중심으로 구성된다는 범위만 입증함
    • 별도의 저장소 전체 스냅샷 채널에는 읽지 않은 파일도 포함되므로, 이 통제 결과가 전체 저장소 업로드를 부정하지는 않음
  • 비밀값은 .env 또는 secrets.env에 있었고 Git으로 추적되는 파일이었음
    • .gitignore에 포함된 파일도 업로드되는지는 별도로 시험하지 않았음
    • canary는 실제 고엔트로피 토큰 형식이 아니므로 sk-… 같은 특정 형태를 위한 별도 마스킹 장치가 전혀 없다고까지 입증하지는 않음
    • 확인된 범위는 테스트한 .env 내용이 마스킹되지 않은 채 전송됐다는 점임

채널 B: 읽지 않은 파일까지 포함한 저장소 전체 업로드

  • /v1/storage는 모델이 읽은 파일을 보내는 /v1/responses와 별개로 작업 공간 전체 스냅샷을 업로드했음
  • 실제 cereblab_api 저장소에서 Reply with exactly: OK. Do not read or open any files.라고 지시한 뒤 실행함
    • Grok은 POST /v1/storage로 152,102바이트 git bundle을 전송했고 서버는 HTTP 200을 반환했음
    • 캡처한 uploaded_repo.bundle을 git clone하자 열지 말라고 지정한 src/_probe/never_read_canary.txt가 복구됐음
    • 파일 안의 CANARY-XR47P2-NEVERREAD-UNIQUE 마커도 원문 그대로 남아 있었음
    • bundle에는 4개 커밋, 47개 파일과 전체 Git 이력이 포함됐음
  • 두 번째 독립 저장소 cereblab_auth에서도 같은 결과가 재현됐음
    • POST /v1/storage로 31,743바이트 git bundle이 업로드되고 HTTP 200을 반환했음
    • 복원된 저장소에서 읽지 않은 파일의 CANARY-AUTH-4T8K2-NEVERREAD 마커가 그대로 확인됐음
  • 별도의 298개 파일 규모 cereblab_api 실행에서는 스테이징된 manifest가 읽지 않은 파일까지 열거했음
    • src/_probe/never_read_canary.txt와 src/apns.ts, src/index.ts 등의 실제 소스가 함께 기록됐음
    • metadata.json의 파일별 fileId는 gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_… 형태였음
    • 이 실행은 할당량에 막혀 콘텐츠 blob 전송까지 완료하지 못했지만, 별도의 git bundle 실험과 12GB 실험에서 실제 업로드가 확인됐음
  • 바이너리에는 after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator 같은 문자열도 포함돼 작업 공간 수집 메커니즘과 일치했음

12GB 저장소에서 확인한 다중 GiB 전송

  • 압축이 거의 되지 않는 무작위 파일로 저장소 크기를 늘리며 업로드 동작을 관찰함
    • 64MB에서는 약 48MB 크기의 단일 POST /v1/storage가 HTTP 200을 반환했지만 로그는 보존하지 못함
    • 약 600MB에서는 약 7.5MB 청크 수십 개가 모두 HTTP 200을 반환했으나 로그가 남아 있지 않음
    • 약 3GB에서는 multipart 초기화 후 storage.googleapis.com으로 50MB 단위 PUT이 관찰됐지만 직접 PUT 로그는 보존하지 못함
    • 약 12GB에서는 약 75MB 청크를 /v1/storage로 계속 전송했으며 5.10GiB 시점에서 캡처를 중단함
  • 보존된 wire_12gb.log에는 /v1/storage* HTTP 200 응답이 총 83개 있음
    • 콘텐츠 업로드 POST /v1/storage 82개
    • 이 가운데 약 75MB 청크 73개
    • 73개 청크의 합계는 5,476,083,317B, 즉 5.10GiB 또는 5.48GB임
    • 작은 POST 9개와 /v1/storage/batch_exists 중복 확인 1개도 포함됨
    • 전체 /v1/storage* 요청 바이트는 5,476,228,005B이며 실패한 저장 요청은 없었음
  • 캡처는 업로드가 계속되는 중에 중단됐으므로 12GB 전체 업로드 완료를 입증하지는 않음
    • 마지막 기록도 약 75MB 청크에 대한 HTTP 200이었음
    • 입증된 범위는 5.10GiB 이상이 실패 없이 전송됐고 중단 시점에도 계속 증가하고 있었다는 것임
  • 같은 세션의 두 채널 사이에는 큰 용량 차이가 있었음
    • /v1/responses는 5개 요청을 합쳐 196,705B, 약 192KB였고 가장 큰 요청도 60,394B였음
    • /v1/storage는 5.10GiB였음
    • 약 27,800배 차이가 발생해 모델 요청에 포함되지 않은 대량의 저장소 데이터가 별도 저장 채널로 이동했음
  • 모델 할당량 오류와 저장 업로드는 독립적으로 발생했음
    • /v1/responses에서 HTTP 402가 1회, 429가 3회 발생함
    • 세션 bookkeeping 요청에서는 관련 없는 404가 1회 발생함
    • 첫 429 이후에도 /v1/storage HTTP 200이 76회 이어졌음
    • 저장 요청 82개는 모두 성공했으며 테스트 범위에서 저장 용량 제한 오류는 발생하지 않았음
  • 이 결과는 로컬 upload_queue가 비워지는 현상에 의존하지 않음
    • 큐는 업로드 성공과 폐기 모두에서 비워질 수 있어 증거로 사용하지 않았음
    • 근거는 요청 본문이 실제 네트워크로 나가 HTTP 200을 받은 캡처와 업로드된 git bundle에서 파일을 복구한 결과임

저장 위치와 원격 측정

  • 저장 목적지는 AWS S3가 아니라 Google Cloud Storage의 grok-code-session-traces 버킷으로 확인됐음
    • 바이너리에 grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy가 포함됐음
    • 보존된 metadata.json의 파일 목적지가 gs://grok-code-session-traces/…로 기록됐음
    • 약 3GB 실험에서는 해당 GCS 호스트로 직접 multipart PUT도 관찰했지만 로그는 보존하지 못함
    • 바이너리에 aws-sdk-s3가 포함돼 있어도 테스트에서 확인된 목적지는 GCS였음
  • 제3자 및 자체 원격 측정 요청도 확인됐음
    • Mixpanel의 api.mixpanel.com/track과 /engage
    • grok.com/_data/v1/events
    • 해당 요청은 모두 HTTP 200을 반환했음
  • 검토한 CLI 설치 스크립트와 quickstart 자료에서는 repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces 업로드를 찾지 못했음
    • 모든 xAI 문서와 도움말을 조사한 것은 아니므로 어디에도 문서화되지 않았다고 단정할 수 없음
    • 확인 가능한 범위는 CLI 자체 설정 자료에서 드러나지 않았다는 것임
  • ~/.grok/upload_queue는 한 턴에 약 3GB 스냅샷을 스테이징할 수 있고 부하가 높으면 수십GB까지 증가해 디스크를 소진할 수 있었음
    • 이는 업로드의 개인정보 문제와 별개인 신뢰성 문제임

“Improve the model” 설정과 정책 범위

  • 클라우드 코딩 에이전트가 작업에 필요한 코드 문맥을 서버로 보내는 행위 자체는 필요한 동작임
  • 테스트에서 확인된 동작은 다음 세 가지로 구분됨
    • .env 같은 비밀 파일을 마스킹 없이 전송함
    • 해당 내용을 명시된 GCS 버킷에 저장함
    • 저장소 전체 업로드가 검토한 CLI 설정 자료에 드러나지 않은 채 기본 활성화돼 있음
  • xAI 소비자 정책은 모델 개선을 위한 데이터 이용과 opt-out을 광범위하게 다루며, Private Chat은 자동 opt-out이고 opt-out은 소급 적용되지 않음
    • 관련 문서는 xAI Privacy Policy와 Consumer ToS임
    • 이러한 일반적 학습 정책은 특정 repo_state 및 GCS 업로드 파이프라인을 문서화하는 것과 같지 않음

  • “Improve the model”을 꺼도 업로드는 중단되지 않음

    • 설정을 끈 상태에서도 전체 저장소가 git bundle로 /v1/storage에 업로드됐고 HTTP 200을 반환함
    • git clone으로 읽지 않은 파일과 Git 이력을 복구할 수 있었음
    • CLI가 받은 /v1/settings에는 "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true가 유지됐음
    • "max_upload_file_bytes": 1073741824로 파일당 1GiB 제한도 반환됐음
    • 테스트 결과에서 opt-out은 학습 여부를 제어하지만 저장소가 컴퓨터를 떠나 업로드·저장되는 동작은 차단하지 않았음

입증하지 않은 사항과 증거의 한계

  • 네트워크 캡처만으로는 xAI가 데이터를 모델 학습에 사용한다는 사실을 입증할 수 없음
    • 확인된 범위는 전송, HTTP 200 수락, 저장용 아카이브와 GCS 목적지임
  • 3GB 실행에서 관찰한 storage.googleapis.com/grok-code-session-traces 직접 PUT 로그는 덮어써져 보존되지 않았음
    • 다중 GiB 업로드 근거는 보존된 12GB 실행의 /v1/storage 로그와 버킷을 명시한 바이너리 및 metadata임
  • 크기별 시험 중 64MB, 600MB, 3GB 로그는 남아 있지 않고 12GB 로그만 보존됐음
  • 12GB 실행은 약 5.10GiB에서 중단됐으므로 전체 12GB가 끝까지 업로드된다고 단정할 수 없음
  • 모든 계정 등급과 구성 조합을 시험하지 않았음
    • 무료 등급에서 다중 GiB 업로드가 성공했음
    • SuperGrok에서는 “Improve the model”을 끈 상태에서도 git bundle 업로드가 성공했음
    • 테스트에서 업로드를 끄는 설정을 찾지 못했지만 어떤 환경에서도 절대 비활성화할 수 없다고 단정하지 않음
  • 초기에는 PID 단위 nettop 결과를 근거로 대용량 blob이 업로드되지 않았다고 잘못 판단했으나 이를 철회함
    • 별도 업로드 조정 프로세스와 Google IP로 직접 향하는 사전 서명 PUT은 API 호스트나 단일 PID 기준 측정에서 빠질 수 있었음
    • 이후의 프록시 와이어 캡처가 초기 판단을 대체함
  • 결과는 grok 0.2.93, macOS Apple Silicon, 2026년 7월 환경에 한정되며 xAI가 이후 동작을 변경할 수 있음

보존된 주요 증거

  • secrets_responses_body.bin: .env 원문이 /v1/responses 본문에 포함됐음을 보여줌
  • secrets_session_state.tar.gz: 같은 비밀값이 /v1/storage용 아카이브에 들어 있음을 보여줌
  • wire_12gb.log: 5.10GiB 저장 업로드, 83개 /v1/storage* HTTP 200, 저장 실패 0건과 두 채널의 약 27,800배 용량 차이를 기록함
  • model_limit.txt: 모델 요청에서 발생한 402 1회와 429 3회를 기록함
  • crate_strings.txt: xai-data-collector, grok-code-session-traces, storage.googleapis.com 문자열을 보존함
  • uploaded_repo.bundle: 업로드된 git bundle에서 읽지 않은 파일과 전체 Git 이력을 복구한 첫 번째 저장소 증거임
  • uploaded_repo_auth.bundle: 두 번째 독립 저장소에서 같은 결과를 재현한 증거임
  • staged_base_tree_manifest.json: 읽지 않은 파일이 저장소 스냅샷 manifest에 열거됐음을 보여줌
  • staged_metadata.json: 파일 목적지가 gs://grok-code-session-traces/…임을 보여줌
  • gcs_puts.txt는 직접 GCS PUT을 보존하지 못해 비어 있는 placeholder이며, 해당 PUT의 보존 증거로 사용할 수 없음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 코딩 도구와 LLM 제공자를 항상 분리하고, bubblewrap 샌드박스로 코딩 도구의 권한을 제한함
    도구는 작업 프로젝트 디렉터리만 읽을 수 있고, .git은 읽기 전용이며 민감한 디렉터리는 빈 디렉터리로 마운트함
    네트워크 네임스페이스도 격리해 Unix 소켓의 HTTP 프록시로만 인터넷에 접근시키고, 특정 LLM 제공자 호스트만 허용하되 도구 자체의 호스트는 차단함
    예를 들어 Crush에는 *.openrouter.ai 접근을 허용하지만 LLM 목록 자동 업데이트에 쓰이는 *.charm.land는 막음. 덕분에 yolo 모드로 모든 작업을 맡기기가 훨씬 편해짐

    • bubblewrap에서는 Docker Hub의 debian:unstable 같은 rootfs를 받아 별도 폴더에 완전한 배포판 환경으로 구성하는 편이 좋음
      그 안에 AI 에이전트를 설치한 뒤, 배포판 rootfs는 읽기 전용으로, 맞춤형 /home/user는 읽기·쓰기로 지정해 bwrap을 실행하는 스크립트를 만들면 됨. 지정한 디렉터리 밖의 중요한 파일은 보이지 않고, 여러 에이전트를 서로 보이지 않게 실행할 수도 있음
      더 강화하려면 내부에서 gVisor의 runsc ... do ...를 호출하거나 muvm 같은 가상 머신 모니터를 사용할 수 있음. bwrap은 환경 구성을 맡기고 별도의 샌드박스 도구로 잠그는 방식이라 신뢰하기 좋음
      설정이 올바르다면 bwrap만으로도 대부분의 공격자를 막기에 충분하며, 권한 상승에는 사실상 Linux 커널 제로데이를 써야 할 가능성이 큼
    • 이를 구현할 때 어떤 방식을 사용하는지 궁금함
    • 이런 추가 보안 강화가 단지 안심을 주는 데 그치는지, 실제로 위험한 동작을 잡아낸 적이 있는지 궁금함
      제약으로 막아야 할 만큼 어리석은 행동을 하는 모델이라면 애초에 쓸 가치가 없다고 봄. 나도 자체 환경을 강화하는 중이며, 관행 자체를 비판하려는 것은 아님

  • claude-code, Codex, grok-build 같은 독점 네이티브 코딩 에이전트 실행기는 다음 업데이트에 어떤 비공개 기능이 추가될지 알 수 없어 프라이버시 측면에서 위험함
    opencode에서 API를 통해 모델을 쓰는 편이 훨씬 안전하지만, 네이티브 실행기만큼 좋은 성능을 내기는 어렵다는 절충이 따름

    • 사용량이 충분하면 서버 측 도구 호출만으로도 전체 코드베이스를 재구성할 수 있고, 이 과정은 완전히 탐지하기 어려움
      Grok의 방식이 더 노골적일 뿐 opencode도 실질적인 보안 경계를 만들지 못하며, 치토스를 자물쇠로 쓰는 밈과 비슷함
    • Codex는 오픈소스임
    • 자동 업데이트 자체도 큰 문제임
      Windows XP SP1의 원격 코드 실행 취약점 같은 것을 즉시 패치하지 않는 것도 위험하지만, 지난 수십 년 동안 업데이트를 하지 않아 생겼을 법한 피해보다 자동 업데이트로 발생한 피해를 더 많이 봤음
    • 자체 에이전트를 사용하지만, 그것 때문에 회사 계정이 차단될 위험은 감수할 수 없음

  • “에이전트가 읽은 파일과 무관하게 추적 중인 모든 파일 내용과 Git 이력을 포함한 저장소 전체를 업로드한다”는 것은 매우 충격적임
    Elon이 따라잡으려고 이런 일을 할 수도 있으리라 어느 정도 예상했지만 심각하게 우려됨. 가격 경쟁력이 있고 grok-4.5의 성능도 충분히 좋지만, 바로 이런 이유로 선택하지 않았음

    • 명백한 데이터 유출이며 불법이어야 함
    • Microsoft와의 협력 관계 때문에 OpenAI도 모든 GitHub 저장소에 접근할 수 있는지 궁금함
    • 결국 바닥을 향한 경쟁임
    • 어떤 데이터를 공유해야 하는지에 관한 정보를 찾지 못해 무료 체험조차 망설였음
    • 이런 CLI는 항상 접근 가능한 디렉터리를 제한하는 샌드박스 안에서 실행함
      CLI가 실수로 SSH 키나 다른 민감한 정보를 가져갈 수도 있고, 프로그래머는 실제로 이런 실수를 자주 저지름. “접근 가능한 모든 파일 업로드”가 고의인지 실수인지에 안전을 맡기고 싶지 않음

  • 첫 번째 항목인 “저장소 안의 비밀정보 파일을 모델이 읽었다”는 것은 사실상 의도된 동작임
    LLM은 파일을 읽기 전에 그 안에 비밀정보가 있는지 판단할 수 없음. 평문 비밀정보가 담긴 파일에 LLM 접근 권한을 주고 읽었다며 놀라는 쪽이 근본적인 문제임
    다만 저장소 전체를 자동으로 업로드하는 것은 터무니없음. 수 GB 규모의 저장소라면 일부 회선에서 매우 오래 걸리고, 모든 데이터를 모으려는 다른 목적이 없다면 대체로 무의미해 보임

  • 에이전트를 실행한 현재 작업공간은 적어도 에이전트가 자유롭게 다룰 수 있다고 늘 가정해 왔기 때문에 예상된 동작처럼 보임
    대부분의 에이전트는 첫 프롬프트에서 코드와 그 안의 비밀정보까지 읽음. 서버에서 이를 활용해 프롬프트 왕복 시간과 도구 호출을 줄인다면 오히려 사용자에게 이득 아닌지 궁금함

    • 파일을 읽고 응답을 전달할 때는 일반적인 메시지 API를 사용함
      그런데 여기서는 프로젝트 폴더 전체를 GCP 스토리지 버킷으로 빼내는 별도 엔드포인트가 발견됨. 대규모 분산 시스템을 설계해 본 사람이라면 훈련 데이터를 긁어모으려는 구조임을 알 수 있음
    • Cursor는 로컬에서 일종의 색인 작업을 하는 것으로 알고 있음
      모든 파일을 업로드하지 않고도 검색을 통해 관련 부분만 찾아 모델이 사용할 수 있도록 전송할 수 있음

  • 개요를 사람이 작성했다면 좋았겠지만, 내용 자체는 불안함

    • 업로드되는 내용을 보여주는 코드 블록 몇 개와 2~3개 문단이면 충분했을 글임
      AI가 작성한 보고서는 읽기가 너무 고역이라 10초 정도 훑다가 흥미를 잃었음
    • 최소한 사람이 LLM과 몇 차례 더 다듬어 문체를 개선할 수도 있었음

  • 훔친 내용이 “모든 비즈니스를 자동화”한다는 Macrohard 프로젝트나 “everything app”에 들어갈지 궁금함
    모든 것을 직접 만들 필요 없이 훔치면 된다는 발상처럼 보임

    • 사용자가 이런 특권을 누리려고 돈까지 낸다는 점이 화룡점정임
      도덕성이 없는 채 이런 회사를 운영한다면 사기의 규모가 드러나고 규제가 막기 전에 최대한 많이 훔치려 할 것임. 실제로 그렇게 하고 있다는 뜻은 아니지만, 경제적 유인은 정확히 그 방향으로 정렬돼 있음

  • AI 에이전트는 실행기가 시작된 디렉터리의 파일을 읽을 수 있다고 봐야 함
    대부분 첫 프롬프트에서 코드와 그 안의 비밀정보까지 읽으며, .env는 로컬 환경용이라 실제 비밀정보를 담아서는 안 됨. AI 에이전트는 지시를 신뢰할 수 없으므로 진짜 비밀정보와 격리해야 함
    이런 전제를 받아들인다면 코드를 매번 컨텍스트로 보내는 것보다 서버에 올려 두는 편이 나을 수도 있음

    • LLM의 작동 방식상 결국 코드는 컨텍스트를 통해 다시 전달돼야 함
      이렇게 별도 업로드할 이유는 Musk가 다음 모델을 위해 프로젝트 구성, 인기 라이브러리, CI 작업 흐름 같은 깨끗한 훈련 데이터를 확보하려는 것뿐이라고 봄
    • 한 번 업로드해도 추론 과정에는 여전히 들어가며, 절약되는 것은 약간의 HTTP 트래픽 정도임
    • 이야기의 핵심은 크지 않음. Grok이 다른 제공자보다 컨텍스트 구성에서 10% 정도 더 공격적이거나, 단순히 이 방식이 더 빨리 출시할 수 있었던 것일 가능성이 큼
      모든 제공자는 결과 개선에 도움이 된다면 같은 일을 할 능력과 유인이 있음
      진짜 차이는 .env 같은 비밀정보 파일을 가리지 않고 전송하고, 일시적으로 처리하는 데 그치지 않고 이름이 지정된 GCS 버킷에 저장하며, CLI 설정 문서에 업로드 방식을 알리지 않은 채 기본 활성화했다는 것임
      접근 가능한 경로에 암호화되지 않은 .env를 두어서는 안 됨. Grok이 비밀정보를 식별해 무시하는 편이 낫겠지만, 사용자가 그런 동작에 의존해서는 안 됨

  • “Improve the model” 설정을 켜든 끄든 저장소 전체가 똑같이 업로드된다는 점은 매우 심각함
    대부분의 AI 업체도 데이터 수집에 동의하면 자체 실행기에서 비슷한 일을 하겠지만, 명시적으로 껐는데도 업로드하는 것은 악의적임

  • 코드베이스 전체를 업로드하면 모델이 “생각”하는 동안 클라이언트에 실제 도구 호출을 요청하지 않고도 코드를 살펴볼 수 있음
    클라이언트로 다시 요청하는 것의 단점이 무엇인지 불분명해 아주 좋은 이유는 아니지만, 생각할 수 있는 최선의 명분임

    • 실제 목적은 영업비밀, 앱 설계, 사내 업무 지식을 훔치거나 코드·앱·도구·절차를 복제하려는 것에 더 가까워 보임
      원래 비공개였던 코드가 이제 그들의 코드가 됨
    • 컴퓨터가 오프라인이어도 어딘가의 컨테이너를 통해 휴대전화에서 원격 제어하고, 나중에 로컬 개발로 돌아와 GCP 버킷의 변경 사항을 동기화하려는 용도일 수 있음
      꽤 유용하지만 Elon에게 저장소 전체를 넘길 만큼 유용하지는 않음. 거부할 수 없게 만들고 전혀 공개하지 않았다는 사실은 이 데이터를 맡겨서는 안 된다는 판단을 더욱 강화함
답변달기