SpaceXAI가 Grok Build를 오픈 소스로 공개했으며, 이에 대해 세 가지 버전의 이야기가 즉시 유포되기 시작했습니다:

1. "Grok 4.5가 이제 오픈 소스입니다."
2. "Grok 스택 전체를 오프라인으로 실행할 수 있습니다."
3. "코드가 공개되었기 때문에 개인정보 보호 문제가 해결되었습니다."

앞의 두 가지는 틀렸습니다. 세 번째는 방향성 측면에서 유용할 수 있으나, 입증된 것은 전혀 아닙니다.

저는 7월 21일자 공개 저장소(repository)를 클론하여 2,847개의 추적된 파일을 확인하고, 현재의 텔레메트리(telemetry) 및 세션 업로드 제어 기능을 추적했으며, 해당 소스를 Grok Build 0.2.93의 와이어 레벨(wire-level) 보고서와 비교했습니다.

제가 발견한 내용은 다음과 같습니다.

요약 (TL;DR)

• 아니요, Grok 4.5는 오픈 소스가 아닙니다. SpaceXAI는 모델 가중치(model weights)가 아니라 Grok Build 에이전트 하네스(agent harness)와 터미널 UI를 공개했습니다.
• 이번 릴리스는 실제 Apache 2.0 코드입니다. 라이선스 약관에 따라 퍼스트 파티(first-party) 코드를 검사, 수정, 포크(fork), 재배포 및 상업적으로 사용할 수 있습니다.
• 로컬 모델이 지원됩니다. 로컬 추론 엔드포인트(inference endpoint)를 포함하여 커스텀 base_url로 Grok Build를 지정할 수 있습니다.
• 로컬 우선(Local-first)이 기본적으로 오프라인임을 의미하지는 않습니다. 모델 추론, 인증, 텔레메트리(telemetry), 트레이스 업로드(trace uploads), 원격 세션, 플러그인 및 MCP 서버는 별도의 네트워크 경로를 사용합니다.
• 이전의 저장소 업로드 발견 사항은 0.2.93 버전에서 실제였습니다. SpaceXAI가 이를 비활성화했다고 보고되었으나, 저는 여전히 제가 배포할 정확한 바이너리(binary)를 직접 와이어 테스트(wire-test)할 것입니다.

실제로 무엇이 오픈 소스가 되었는가

SpaceXAI의 공식 발표는 정확합니다. 코딩 에이전트와 TUI를 오픈 소스로 공개했다는 것입니다.

공개 저장소에는 다음이 포함됩니다:

• 컨텍스트를 조립하고 도구를 배정하는 에이전트 루프(agent loop);
• 파일 읽기, 편집, 검색 및 셸(shell) 도구;
• 전체 화면 터미널 인터페이스 및 인라인 디프 뷰어(inline diff viewer);
• 스킬, 플러그인, 훅(hooks), MCP 서버 및 서브 에이전트(subagents);
• 헤드리스 모드(headless mode) 및 에이전트 클라이언트 프로토콜(Agent Client Protocol) 지원;
• 워크스페이스(workspace), 체크포인트(checkpoint) 및 세션 코드.

그 차이점은 다음과 같습니다:

저장소(repository)에 따르면 자체 코드(first-party code)는 Apache 2.0 라이선스를 따릅니다. 제3자(third-party) 및 벤더 제공(vendored) 컴포넌트는 원래의 라이선스를 유지합니다. 또한 현재 외부 기여(external contributions)는 허용되지 않는다고 명시되어 있습니다.

이 마지막 지점은 저를 놀라게 했습니다. 포크(fork)는 할 수 있지만, SpaceXAI가 저의 풀 리퀘스트(pull request)를 병합(merge)할 것이라고 가정해서는 안 됩니다. 이것은 검사 가능하고 재사용 가능한 코드로서의 오픈 소스이지, 아직 일반적인 커뮤니티 유지 관리형 업스트림(upstream)은 아닙니다.

모델은 여전히 비용이 많이 드는 부분입니다

오픈 소스 라이선스는 하네스(harness) 라이선스 비용을 제거해 줍니다. 하지만 모델 추론(inference) 비용을 제거하지는 않습니다.

Grok 4.5는 여전히 API 모델입니다. SpaceXAI는 현재 다음과 같이 나열하고 있습니다:

여기에 첫 번째 고통스러운 계산(pain translation)이 있습니다.

10M 입력 x $2/M = $20
2M 출력 x $6/M = $12
월간 모델 청구액 = $32

이를 100M 입력과 20M 출력으로 확장하면 다음과 같습니다:

100M 입력 x $2/M = $200
20M 출력 x $6/M = $120
월간 모델 청구액 = $320

그리고 긴 컨텍스트(long-context) 에이전트 요청은 단순한 추정치를 두 배로 늘릴 수 있습니다:

300K 입력 x $4/M = $1.20
50K 출력 x $12/M = $0.60
요청 1회 = $1.80

근무일 기준 하루에 50번씩 실행한다고 가정하면, 그 이론적 최대치는 다음과 같습니다:

$1.80 x 50 x 22 근무일 = 개발자 1인당 월 $1,980

이것은 측정된 평균 Grok Build 청구액이 아닙니다. 공개된 긴 컨텍스트 요율이 해당 워크로드(workload)에 대해 시사하는 바입니다. 제 요점은 더 간단합니다: 오픈 소스 소프트웨어와 무료 추론은 서로 다른 주장입니다.

네, 로컬 모델을 지정할 수 있습니다

공식 문서에는 커스텀 모델 설정(custom model configuration)이 노출되어 있습니다:

[models]
default = "local-coder"

...

설정을 변경한 후, Grok Build가 무엇을 발견했는지 검사할 수 있습니다:

grok inspect
grok -p "Explain this repository" -m local-coder

이 부분이 제가 진심으로 흥미롭다고 느끼는 릴리스의 대목입니다. Grok Build는 로컬 모델, 기업 게이트웨이(company gateway), 또는 다른 호환 가능한 API를 둘러싼 오픈 에이전트 셸(open agent shell)이 될 수 있습니다.

하지만 축하하기 전에 도구 호출(tool calling) 기능을 테스트해 볼 것입니다. 코딩 질문에 답할 수 있는 로컬 모델이라 할지라도 에이전트 루프(agent loop)에서는 실패할 수 있기 때문입니다. 잘못된 형식의 도구 인자(malformed tool arguments), 셸 오류 후의 취약한 복구 능력, 컨텍스트 손실(context loss), 또는 과도한 재시도(excessive retries)는 설정을 사용할 수 없게 만들 수 있습니다.

개인정보 보호의 함정은 네 개의 별도 스위치입니다

저는 /privacy opt-out이 마스터 스위치일 것이라고 예상했습니다.

하지만 그렇지 않습니다.

현재 소스 문서(source documentation)는 이들을 별개로 취급합니다:

사용자 가이드(user guide)에는 /privacy가 텔레메트리(telemetry)나 트레이스 업로드(trace upload)를 변경하지 않는다고 명시되어 있습니다.

따라서 저의 보수적인 설정은 다음과 같이 시작합니다:

[features]
telemetry = false

...

저는 또한 현재 소스가 해당 값들을 어떻게 해결(resolve)하는지도 확인했습니다. 요구 사항, 환경 변수(environment variable), 로컬 설정(local config), 또는 원격 설정(remote setting)이 없으면 텔레메트리는 비활성화(disabled) 상태로 폴백(fallback)됩니다. 하지만 원격 설정이 해결된 값에 영향을 미칠 수 있으며, 트레이스 업로드는 명시적으로 설정되지 않은 경우 텔레메트리를 따릅니다.

이것이 제가 폴백에 의존하는 대신 두 값을 직접 설정하려는 이유입니다.

이전 개인정보 보호 보고서가 증명한 것

원래의 와이어 레벨 분석(wire-level analysis)은 제어된 저장소(repositories)를 통해 Grok Build 0.2.93을 테스트하고 도구의 트래픽을 캡처했습니다.

가장 강력한 결과는 "클라우드 모델이 파일을 보았다"는 것이 아니었습니다. 모든 클라우드 코딩 에이전트는 관련 컨텍스트(context)가 필요하기 때문입니다.

더 강력한 결과는 별도의 저장 경로(storage path)였습니다:

• 보존된 한 번의 실행 동안 약 192 KB가 모델 턴(model-turn) 요청을 통해 전송되었습니다.
• 약 5.10 GiB가 저장 요청(storage requests)을 통해 전송되었습니다.
• 캡처된 Git 번들(Git bundle)은 에이전트가 읽지 말라고 지시받았던 파일을 재구성했습니다.
• 해당 번들에는 Git 히스토리(Git history)도 포함되어 있었습니다.

연구자는 SpaceXAI가 해당 데이터로 학습했다는 것을 증명하지는 않았습니다. 전송(Transmission)과 저장(Storage)은 입증되었으나, 학습(Training)은 입증되지 않았습니다.

SpaceXAI는 서버 측에서 전체 코드베이스 업로드(whole-codebase upload) 기능을 비활성화했으며, 이전에 업로드된 데이터는 삭제될 것이라고 이전에 밝힌 바 있습니다. 제가 감사(audit)한 현재 소스에는 codebase_upload 또는 git bundle 문자열이 포함되어 있지 않습니다.

하지만 제가 그냥 넘어가려 하지 않는 부분은 이것입니다: 현재의 트리(tree)에는 여전히 세션 추적(session-trace) 업로드, GCS 저장소, 업로드 대기열(upload-queue), 텔레메트리(telemetry), 그리고 원격 설정(remote-settings) 코드가 포함되어 있습니다.

이것이 과거의 동작이 여전히 남아있다는 것을 증명하는 것은 아닙니다. 다만 정적 소스 검색(static source search)이 패킷 캡처(packet capture)를 대체할 수는 없다는 것을 증명할 뿐입니다.

"이것을 신뢰해야 할까?" 결정 트리

def should_you_run_grok_build(repo):
    if repo == "public or disposable":
        return "공식 빌드를 시도하되, 설정(config)과 로그(logs)를 점검하십시오."
...

이번 주에 제가 할 일

개인용 공개 저장소(personal public repo)의 경우: 바이너리(binary)를 설치하고, 텔레메트리(telemetry)와 추적 업로드(trace upload)를 명시적으로 끈 다음, 첫 번째 작업을 수행하기 전에 grok inspect를 사용하겠습니다.

비공개 스타트업 저장소(private startup repo)의 경우: 가짜 비밀값(fake secrets)을 포함한 카나리 클론(canary clone)을 생성하고, 로깅 프록시(logging proxy) 뒤에서 실행하며, 정확한 클라이언트 버전을 확인하겠습니다. 이전의 영향을 받은 빌드가 접근했을 수 있는 모든 실제 자격 증명(credential)을 교체(rotate)하겠습니다.

기업(enterprise)의 경우: 소스를 포크(fork)하여 고정(pin)하고, 관리형 설정(managed configuration)에서 요구 사항을 정의하며, 제어된 엔드포인트(endpoint)를 통해 추론(inference)을 라우팅하고, 팀에 꼭 필요한 경우가 아니라면 원격 세션 공유(remote session sharing)를 차단하겠습니다.

로컬 LLM(local-LLM) 설정의 경우: 5개의 데모가 아니라 50개의 실제 작업을 테스트하겠습니다. 저는 작업 완료(task completion), 재시도 횟수(retry count), 도구 호출 유효성(tool-call validity), 지연 시간(latency), 그리고 총 연산 시간(total compute time)에 집중할 것입니다.

Grok 4.5 사용자의 경우: 모델 비용 모니터링(model-cost monitoring)을 유지하겠습니다. Apache 라이선스가 토큰당 $2/$6 요금이나 2배의 긴 컨텍스트(long-context) 가격을 변경하지는 않습니다.

더 큰 그림

이번 릴리스는 AI 코딩 도구에 대해 중요한 시사점을 던져줍니다.

모델은 단지 한 계층일 뿐입니다. 에이전트 하네스(agent harness)가 어떤 파일을 읽을지, 어떤 컨텍스트를 조립할지, 어떤 명령을 실행할지, 무엇이 영속화될지, 그리고 결과가 어디로 갈지를 결정합니다. 이 계층은 모델만큼이나 많은 보안 및 비용 위험을 초래할 수 있습니다.

하네스를 오픈 소스로 공개하는 것은 업계를 올바른 방향으로 이끌기 때문에 중요합니다. 왜냐하면 이러한 의사결정 과정을 검사 가능하게 만들기 때문입니다. 또한 이는 기준을 높입니다. 이제 코드를 읽을 수 있게 되었으니, 저는 공급업체와 팀들이 실제 런타임 구성(effective runtime configuration)에 대해서도 설명해 주기를 기대합니다.

Grok, OpenAI, Anthropic, 그리고 로컬에서 호환되는 엔드포인트 전반에 걸쳐 하나의 경로가 필요하다면, TokenMix이 대략적으로 도움을 줍니다. 공개 고지: 저는 연구 부서에서 일하고 있습니다. 전체 소스 감사 분석은 원래 Grok 빌드 기사에 나와 있습니다.

요점 정리 (Bottom line)

Grok Build는 의미 있는 Apache 2.0 릴리스입니다. Grok 4.5는 여전히 비공개이며, 로컬 우선(local-first) 방식은 여전히 구성이 필요하고, 개인 정보 보호 문제는 여전히 런타임에서 검증되어야 합니다.

저는 소스를 사용할 것입니다. 저는 '오픈'이라는 말에 제 신뢰를 위탁하지 않을 것입니다.

만약 모델 엔드포인트와 런타임 정책이 여전히 원격으로 제어된다면, 사설 저장소(private repository)를 가진 오픈 소스 에이전트를 신뢰하시겠습니까?