# xAI Grok Build CLI가 xAI로 전송하는 데이터: 와이어 수준 분석 > Clean Markdown view of GeekNews topic #31375. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31375](https://news.hada.io/topic?id=31375) - GeekNews Markdown: [https://news.hada.io/topic/31375.md](https://news.hada.io/topic/31375.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-13T10:01:24+09:00 - Updated: 2026-07-13T10:01:24+09:00 - Original source: [gist.github.com/cereblab](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547) - Points: 1 - Comments: 1 ## Topic Body - `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](https://x.ai/legal/privacy-policy)와 [Consumer ToS](https://x.ai/legal/terms-of-service)임 - 이러한 일반적 학습 정책은 특정 `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의 보존 증거로 사용할 수 없음 ## Comments ### Comment 61696 - Author: neo - Created: 2026-07-13T10:01:25+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48877371) - 코딩 도구와 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에게 저장소 전체를 넘길 만큼 유용하지는 않음. 거부할 수 없게 만들고 전혀 공개하지 않았다는 사실은 이 데이터를 맡겨서는 안 된다는 판단을 더욱 강화함