지난주 개발 도구 소식 중에 헤드라인만 보면 훈훈하게 읽히는 뉴스가 하나 있었다. SpaceXAI가 자사 코딩 에이전트 Grok Build의 소스 코드를 Apache 2.0 라이선스로 공개했다는 소식이다. 유료 상용 도구가 소스를 열었다니, 얼핏 개발자 친화적인 미담처럼 들린다.
그런데 이 공개에는 배경이 있다. Grok Build가 사용자 컴퓨터의 파일을 몰래 서버로 빼돌리고 있었다는 사실이 며칠 전 들통났고, 소스 공개는 그 사건이 터진 직후에 나온 결정이었다. 좋게 보면 신뢰를 회복하려는 카드였고, 냉정하게 보면 등 떠밀려 연 문이었다. 그래서 이 뉴스는 "코딩 에이전트가 오픈소스가 됐다"보다 "코딩 에이전트를 어디까지 믿고 내 컴퓨터를 맡길 수 있나"라는 질문으로 읽는 편이 정확하다.
Grok Build가 하는 일
먼저 Grok Build가 뭘 하는 물건인지부터 짚자. 이름은 낯설어도 요즘 개발자들이 쓰는 코딩 에이전트는 대체로 비슷한 골격을 갖고 있다.
Grok Build는 터미널에서 돌아가는 코딩 에이전트다. 화면 전체를 채우는 텍스트 인터페이스(TUI) 위에서 사람이 "이 버그 고쳐줘"라고 말하면, 에이전트가 프로젝트 코드를 읽고, 파일을 직접 고치고, 셸 명령을 실행하고, 필요하면 웹을 검색하면서 긴 작업을 알아서 진행한다. 사람이 앉아서 대화하듯 쓸 수도 있고, 사람 없이 CI 파이프라인 안에서 자동으로 돌릴 수도 있다. 코드 자동완성 수준을 넘어서, 개발자가 손수 처리하던 자잘한 일을 통째로 넘겨받는 조수에 가깝다.
여기서 한 가지 개념만 이해하면 나머지 이야기가 쉬워진다. 바로 하네스(harness)다. 하네스는 AI 모델 자체가 아니라, 모델을 감싸서 실제 일을 시키는 바깥 껍데기를 말한다. 모델은 글자를 생성할 뿐이고, 그 글자를 받아서 "이건 파일을 열라는 뜻이구나", "이건 명령을 실행하라는 뜻이구나" 하고 해석해 손발을 움직여주는 장치가 하네스다. 사용자의 질문에 프로젝트 파일 내용을 얼마나 붙여서 모델에게 넘길지, 모델이 요청한 도구를 어떤 순서로 실행할지, 결과를 화면에 어떻게 그릴지가 전부 하네스의 몫이다. 같은 모델을 써도 하네스가 잘 짜여 있으면 훨씬 똑똑하게 일한다. 최근 코딩 도구 경쟁의 승부처가 모델 성능만이 아니라 이 하네스의 완성도로 옮겨간 이유다.
이번에 SpaceXAI가 공개한 것이 바로 이 하네스다. Grok Build는 거의 전부(저장소 통계로 99.6퍼센트)가 러스트(Rust)로 짜여 있고, 공개 범위에는 에이전트 런타임, 터미널 인터페이스, 명령줄 실행 파일, 도구 구현, 작업 공간 관리, 설정 계층이 들어간다. MCP 서버나 스킬, 플러그인, 훅 같은 확장을 어떻게 붙이는지, 에디터에 끼워 넣는 ACP(Agent Client Protocol)를 어떻게 처리하는지까지 코드로 다 들여다볼 수 있게 됐다. 에이전트가 겉으로 어떻게 동작하는지 궁금했던 사람에게는 교과서 한 권이 통째로 열린 셈이다.
등 떠밀린 공개
그럼 잘나가는 상용 도구가 왜 갑자기 속을 다 보여줬을까. 사건의 순서를 따라가 보면 답이 나온다.
7월 초, @a_green_being이라는 사용자가 Grok Build 0.2.93 버전을 뜯어보다가 이상한 통신을 발견했다. 에이전트가 모델과 주고받는 정상적인 대화 트래픽(약 192킬로바이트)과는 별개로, 완전히 다른 저장소 채널로 대용량 데이터가 빠져나가고 있었다. 한 번의 실행에서 약 5.1기가바이트가 73개 조각으로 쪼개져 SpaceXAI가 관리하는 저장소로 전송됐다. 내용물은 단순히 작업 중인 코드가 아니었다. 프로젝트 전체를 통째로 묶은 깃(Git) 번들은 물론, 홈 디렉터리에 있던 SSH 키, 비밀번호 관리자 데이터베이스, 문서와 사진, 동영상까지 함께 올라갔다.
SSH 키는 서버에 접속하는 열쇠고, 비밀번호 관리자 데이터베이스는 말 그대로 계정 비밀번호가 담긴 금고다. 코딩을 도와달라고 켠 도구가 개발자의 열쇠 꾸러미를 통째로 복사해 가고 있었다는 뜻이다. 사용자가 명시적으로 허락한 적도, 화면에 고지된 적도 없는 동작이었다.
이 사고가 하필 하네스에서 났다는 점은 곱씹어볼 만하다. 앞서 설명했듯 하네스가 하는 일은 모델에게 넘길 맥락을 그러모으는 것이다. 프로젝트 구조를 파악한다며 파일을 훑고, 도움이 될 자료를 모아 정리하는 과정이 곧 하네스의 본업이다. 그 수집의 손이 어디까지 뻗치는지, 모은 것을 어디로 보내는지를 정하는 것도 하네스다. 바꿔 말하면 코딩 에이전트에서 사용자 데이터가 과하게 긁혀 나갈 위험이 가장 크게 도사린 자리가 바로 이 바깥 껍데기다. 성능을 끌어올리는 것도 하네스고, 이런 사고가 터지는 곳도 하네스다. 이번에 공개된 코드가 다름 아닌 그 부분이라는 사실은 그래서 가볍지 않다.
파장이 커지자 SpaceXAI는 빠르게 움직였다. 7월 12일 기본 설정을 바꿔 이 업로드를 꺼버렸고, 다음 날 여섯 번의 재검증으로 더 이상 전송이 일어나지 않는다는 것을 확인했다. 일론 머스크는 이미 쌓인 데이터를 삭제하겠다고 밝혔지만, 정말 지워졌는지는 외부에서 확인할 방법이 아직 없다. 그리고 7월 15일, 회사는 Grok Build의 하네스를 오픈소스로 공개했다. 공개된 코드에서 문제의 업로드 기능은 아예 호출되지 않도록 오류를 반환하게 막아둔 상태다.
이 순서가 중요하다. 소스 공개는 "우리 도구는 이제 숨기는 게 없습니다, 직접 확인해 보세요"라는 메시지를 담은 신뢰 회복 조치였다. 코드가 열려 있으면 누구든 데이터가 어디로 흐르는지 직접 감사할 수 있으니, 논리적으로는 맞는 처방이다.
'오픈소스'라는 말의 크기
문제는 이 처방에 별표가 여러 개 달려 있다는 점이다. 공개됐다는 말이 실제로 얼마나 열렸다는 뜻인지 따져보면 생각보다 좁다.
첫째, 정작 두뇌에 해당하는 모델은 닫혀 있다. Grok Build를 움직이는 Grok 4.5 모델은 여전히 비공개다. 우리가 볼 수 있는 것은 모델에게 말을 걸고 대답을 받아 손발을 움직이는 껍데기일 뿐, 판단을 내리는 알맹이는 아니다. 실행하려면 여전히 SpaceXAI 계정으로 로그인해야 한다. 로컬에서 컴파일해 자기 추론 서버에 물릴 수 있다는 이야기가 나오지만, 결국 성능의 핵심인 모델은 회사가 쥐고 있다.
둘째, 코드를 함께 고칠 수는 없다. 저장소의 기여 안내에는 외부 기여를 받지 않는다고 못박혀 있다. SpaceXAI는 내부 모노레포에서 개발하고 공개 저장소에 주기적으로 그 결과만 내보내는 방식을 쓴다. 즉 이건 "함께 만드는" 오픈소스가 아니라 "열어서 보여주는" 오픈소스다. 버그를 발견해도 패치를 보낼 창구가 없다.
셋째, 막상 가장 궁금한 부분을 볼 수 없다. 공개된 저장소의 커밋 기록은 단 하나뿐이다. 처음부터 지금까지의 변경 이력이 아니라, 특정 시점의 스냅숏 하나만 올라와 있다는 뜻이다. 그래서 문제의 업로드 기능이 원래 어떻게 심어졌고 어떤 의도로 설계됐는지는 코드가 공개된 지금도 추적할 수 없다. 가장 해명이 필요한 대목이 기록에서 빠져 있는 셈이다.
정리하면 이번 공개는 "앞으로 이 도구가 뭘 하는지는 코드로 확인할 수 있다"까지는 사실이지만, "지난번에 왜 그랬는지"나 "이 도구의 성능을 내 마음대로 바꿀 수 있다"까지는 닿지 못한다. 오픈소스라는 단어가 주는 인상과 실제 열린 범위 사이에 거리가 꽤 있다.
파일을 만지는 조수를 어디까지 믿을까
이 사건이 Grok Build 한 제품의 해프닝으로 끝나지 않는 이유가 있다. 요즘 코딩 에이전트는 예외 없이 사용자의 파일 시스템, 셸, 인증 정보에 손을 댄다. 그렇게 하지 않으면 애초에 일을 대신해줄 수가 없다. 편리함의 근원과 위험의 근원이 같은 곳에 있다.
지금까지 개발자가 상용 코딩 도구를 쓸 때 데이터가 어디로 가는지는 대체로 회사의 약속에 기대는 수밖에 없었다. 개인정보 처리방침에 그렇게 적혀 있으니 믿는 식이다. 그런데 이번 일은 그 약속과 실제 동작이 다를 수 있다는 것을, 그것도 대형 업체의 도구에서 벌어질 수 있다는 것을 보여줬다. 하네스가 열려 있었다면 사용자는 문제의 통신을 훨씬 빨리 잡아냈을 것이다. 실제로 공개 이후 여러 개발자가 곧바로 코드에서 데이터 경로를 훑기 시작했다.
사실 모델은 닫고 하네스는 여는 구성이 Grok Build만의 선택은 아니다. 요즘 상용 코딩 도구들은 대체로 성능의 원천인 모델은 사업 자산으로 끌어안고, 사용자 컴퓨터와 맞닿는 실행 계층은 어느 정도 열어두는 쪽으로 수렴하고 있다. 개발자가 도구를 믿고 쓰려면 최소한 자기 파일을 만지는 손이 뭘 하는지는 볼 수 있어야 하기 때문이다. 이번 사건은 그 손을 열어두는 일이 배려나 선택의 문제가 아니라 최소한의 조건에 가깝다는 것을 거꾸로 증명한 셈이다.
그래서 하네스를 여는 흐름 자체는 방향이 맞다. 모델은 성능과 사업 논리 때문에 닫아두더라도, 내 컴퓨터를 실제로 만지는 바깥 껍데기만큼은 열어두는 편이 서로에게 안전하다. 감시할 수 있는 조수와 감시할 수 없는 조수는 신뢰의 무게가 다르다. 다만 이번처럼 사건이 터진 뒤에야, 그것도 이력이 지워진 스냅숏으로 여는 방식은 그 취지를 절반만 살린다. 진짜 신뢰는 문제가 생기기 전부터 열려 있었고 언제든 되짚어볼 수 있을 때 쌓인다.
코딩 에이전트를 쓰는 입장에서 이번 일이 남기는 실질적인 교훈은 분명하다. 에이전트에게 작업 폴더를 열어줄 때, 그 폴더 안에 SSH 키나 자격 증명 파일이 함께 놓여 있지 않은지 한 번 더 확인하는 습관이다. 도구가 아무리 똑똑해도, 접근 범위를 정해주는 건 결국 사용자의 몫이다. Grok Build가 등 떠밀려 연 문 앞에서, 우리가 챙길 수 있는 건 그 정도의 경계심이다.