즈푸 ZCode 코드 유출 파문 추적: 에이전트의 데이터 행위는 누가 감사하나?

글 | 린커, 정하오

지난 2년간 에이전트 보안 논의의 중심은 주로 모델 통제 불능, 프롬프트 주입, 외부 공격자에 맞춰져 있었다. 이에 비해 에이전트 제조사 자신의 데이터 행위는 1급 위험으로 다뤄지는 경우가 드물었다.

최근 드러난 즈푸(Zhipu) ZCode 사건은 문제의 방향을 그동안 제대로 다뤄지지 않았던 쪽으로 돌리고 있다. 바로 에이전트의 제조사 자체가 데이터 외부 유출의 원천이 될 수 있느냐는 것이다.

9월 18일, 기술 블로거 ferstar가 즈푸 ZCode에 대한 리버스 엔지니어링 분석을 공개했다. 그는 사용자가 계정에 로그인만 하면 ZCode가 백그라운드에서 전체 작업 프로젝트와 완전한 수정 이력을 함께 압축·암호화해 클라우드 서버로 업로드한다는 사실을 발견했다.

소프트웨어 인터페이스에는 실제로 작동하는 종료 스위치가 없고, 암호화 파일의 복호화 키는 즈푸 측에만 보관돼 있다. 즈푸는 곧바로 사과하며 문제가 한 기능이 기본 활성화된 데서 비롯됐고, 데이터는 사용 후 즉시 폐기된다고 밝혔으며, 조만간 코드 저장소를 오픈소스로 공개하고 제3자 감사를 도입하겠다고 약속했다.

ZCode가 이번에 드러낸 문제는 이미 업계의 고립된 사례가 아니다.

얼마 전 독립 보안 연구자 cereblab은 패킷 캡처 분석을 통해 xAI의 프로그래밍 에이전트 도구 Grok Build가 사용자의 전체 프로젝트를 구글 클라우드 스토리지로 압축 업로드한다는 사실을 입증했다. 여기에는 사용자가 AI에게 읽지 말라고 명시한 파일과 비식별화되지 않은 비밀번호까지 포함됐다.

더 앞서서는 Claude Code가 사용자 모르게 위치와 신원 정보를 회신한 사실이 드러났고, Anthropic 엔지니어는 사후에 그것이 의도적인 실험이었다고 확인하기까지 했다.

더 중요한 것은, 이 문제들이 규제나 보안 감사가 아니라 대개 커뮤니티의 개인에 의해 발견됐다는 점이다. 그리고 현재 업계가 에이전트를 위해 구축한 보안 프레임워크에는 제조사 자신의 행위를 구속하는 규칙이 지금까지 단 한 조항도 없다.

1. 시작은 하드디스크 이상

9월 18일, 기술 블로거 ferstar는 ZCode의 로컬 디렉터리를 점검하던 중 하드디스크 점유 공간이 비정상적이라는 점을 알아챘다. 그는 약 313MB에 달하는 암호화 파일을 찾았는데, 평소 크기를 훨씬 넘어서는 용량이었다. 파일은 열리지 않았지만, 첨부된 파일 목록을 보면 이 패키지가 약 4만 2천 개의 파일을 담고 있으며, 그중 8할 이상이 프로젝트의 이력 수정 기록에 해당했다.

이 기록에는 프로젝트 파일뿐 아니라 과거에 다운로드했던 대용량 파일 캐시와 로컬 작업 로그까지 포함돼 있었다. 압축된 것은 프로젝트 자체만이 아니라 프로젝트의 '태어나서부터의 이력'까지였다.

이후의 코드 분석에서 이 이력 기록이 압축 과정에서 모든 보안 필터링 규칙에서 면제된다는 사실이 드러났다.

ZCode의 파일 선별 로직은 순서대로 판정하는데, 이력 기록 디렉터리의 통과가 키 필터링과 용량 제한보다 앞에 배치돼 있다. 즉 pem, key 등 비밀번호 파일에 대한 필터링과 1MB 용량 상한이 이력 기록 디렉터리 아래의 어떤 내용에도 적용되지 않는다는 뜻이다.

이는 수백 메가바이트 규모의 압축 파일을 통째로 가져갈 수 있고, 과거에 이력 기록에 커밋됐다가 삭제된 비밀번호와 키도 그대로 업로드된다는 의미다.

더 골치 아픈 조작은 그다음에 있다. 복호화 키가 사용자의 컴퓨터에 없다는 점이다.

ferstar는 파일의 업로드 경로를 분해·복원했다. 먼저 클라이언트가 즈푸 서버에 업로드 자격증명과 암호화용 공개키를 요청하고, 이어서 로컬에서 압축·암호화를 완료한 뒤, 즈푸 자체의 비즈니스 서버를 우회해 알리바바 클라우드의 클라우드 스토리지 서비스로 직접 업로드하고, 그다음 클라우드 스토리지가 즈푸 백엔드로 콜백한다.

여기서 암호화 방식을 잠깐 설명하자면.

공개키는 자물쇠에 해당한다. 누구나 그것으로 물건을 상자에 잠글 수 있다. 개인키는 열쇠에 해당한다. 열쇠를 가진 사람만 열 수 있다. ZCode의 방식은, 자물쇠는 서버가 임시로 발급하고 열쇠는 서버 쪽에만 보관하며, 에이전트가 사용자 컴퓨터에서 암호화 패키지를 생성하므로 사용자 자신조차 그 안에 무엇이 들어 있는지 볼 수 없다는 것이다.

ferstar는 이 메커니즘이 두 시점에 작동한다는 것을 발견했다. 하나는 사용자가 AI에 요청을 보내기 전이고, 다른 하나는 작업이 끝난 뒤다. 활발하게 사용하는 과정에서 그는 최대 62회의 스냅샷 기록을 관찰했다.

인터페이스에서 이와 관련돼 보이는 두 옵션을 그가 코드 로직과 하나씩 대조해 확인한 결과, 하나는 '경험 최적화'라는 이름으로 실제로는 데이터가 모델 훈련에 쓰이는지 여부만 제어하고, 다른 하나는 '저장소 스냅샷 인덱스'라는 이름으로 실제로는 서버 측이 데이터를 받은 뒤 검색 디렉터리를 만들지 여부만 제어했다.

둘 다 꺼도 로컬의 압축과 업로드는 그대로 실행된다. 스냅샷과 업로드를 담당하는 컴포넌트는 소프트웨어가 시작될 때 무조건 로드되며, 유일한 전제는 사용자가 로그인 상태라는 점뿐이다.

프로젝트 파일 외에도 스냅샷은 매번 ZCode 자체의 전역 설정까지 함께 압축해 프로젝트를 넘나들며 가져간다.

ferstar는 그 313MB짜리 전송 대기 파일을 수동으로 삭제해 보았다. 30분 뒤 ZCode는 자동으로 새 압축 파일을 다시 생성했다. 에이전트는 몰래 업로드가 안 되면 반복해서 재시도하는 것이다.

지워도 다시 만들어진다. 이는 있어도 그만인 보조 기능이 가질 법한 집요함이 아니다.

2. 제대로 답하지 못한 것들

이 글이 그날 밤 커뮤니티에서 빠르게 확산되자, 즈푸는 신속히 대응하고 사과했다.

이번 문제는 ZCode의 '코드 저장소 인덱스' 기능에서 비롯됐습니다. 이 기능은 사용자가 로컬에서 저장소 인덱스를 생성하도록 돕기 위한 것으로, 이력 버전을 포함한 세션 체크포인트 복원, 이력 버전 롤백 및 Repo Wiki 등의 기능을 지원합니다.

Repo Wiki 기능은 Wiki 페이지를 생성할 때 저장소 데이터 업로드를 유발할 수 있습니다. Wiki 페이지가 클라우드에서 생성된 후 관련 업로드 데이터는 즉시 폐기되며 저장되지 않습니다. 이 기능이 출시 초기에 기본 활성화되어 일부 사용자가 영향을 받았으며, 이에 대해 깊이 사과드립니다. 현재 관련 문제는 수정되었습니다.

즈푸는 또한 조만간 ZCode 코드 저장소를 오픈소스로 공개하고, 제3자 평가 인력을 초청해 시스템 운영 상황을 검토하게 하며, 전체 사용자에게 주간 할당량 1회 초기화를 추가 보상으로 당일 지급하겠다고 약속했다.

여기서 '코드 저장소 인덱스'는 프로젝트 파일에 대한 목록과 검색 시스템을 구축하는 것이고, 'Repo Wiki'는 프로젝트에 대한 설명 문서를 자동으로 생성하는 기능이며, '세션 체크포인트 복원'과 '이력 버전 롤백'은 사용자가 AI와 대화하는 과정에서 이전의 어느 단계로 되돌아갈 수 있게 하는 기능이다.

이 기능들 자체는 합리적이고 대응도 신속했지만, 핵심은 다음과 같다.

그것이 설명한 것과 커뮤니티가 추궁한 것은 같은 사안이 아니다.

즈푸는 이 인덱스가 '사용자가 로컬에서 생성하도록 돕기 위한 것'이라고 말했다. 로컬에서 생성하는 것이라면 왜 프로젝트 전체를 클라우드로 보내야 하는가? 로컬에서 인덱스를 만들고, 로컬에서 스냅샷을 찍고, 로컬에서 롤백하는 것은 기술적으로 충분히 가능하며, 시중에는 그렇게 하는 도구도 있다.

설명은 '로컬 인덱스'와 '클라우드 업로드'를 한 문장으로 합쳐, 마치 후자가 전자의 자연스러운 연장인 것처럼 만들었다. 하지만 그 사이에는 핵심 고리에 대한 설명이 빠져 있다.

대응은 문제를 Repo Wiki가 'Wiki 페이지를 생성할 때 저장소 데이터 업로드를 유발할 수 있다'는 데로 돌렸다. 그러나 ferstar의 리버스 엔지니어링 기록을 보면 업로드가 유발되는 시점 중 하나는 사용자가 매번 질문을 보내기 전이며, 설명 문서 생성과는 무관하다.

ZCode의 현재 공식 문서는 설명 문서를 생성할 때 프로젝트의 이력 수정 기록을 읽지 않고, 필요에 따라 필터링된 코드 컨텍스트만 읽는다고 명시하고 있다. 이는 이 기능이 기술적으로 이력 기록을 필요로 하지 않는다는 뜻이다.

그렇다면 이전에 업로드된 패키지에서 왜 86.6%가 이력 기록인가? 설명은 애초에 업로드 범위가 왜 그렇게 컸는지, 설계상 의도인지 프로그램 오류인지 답하지 않았고, 어느 버전부터 수정했는지도 밝히지 않았다.

설명이 사용한 표현은 이 기능이 '출시 초기에 기본 활성화'됐다는 것인데, 이는 메커니즘 차원의 데이터 외부 유출을 한 기능의 스위치 설정 문제로 표현한 것에 가깝다.

ferstar의 코드 분석을 보면 인터페이스의 두 관련 옵션은 하나는 훈련을, 하나는 인덱스를 관리하지만, 둘 다 압축과 업로드 행위 자체는 통제하지 못한다.

커뮤니티가 의심하는 핵심은 사용자가 보는 제어 항목이 실제로 일어나는 일을 통제하지 못한다는 점이다. 이는 '어떤 기능이 기본으로 켜져 있었다'와는 차원이 다른 문제다.

곧이어 더 민감한 증거 하나가 커뮤니티에서 다시 발굴됐다. 바로 ZCode v3.12.2 버전의 업데이트 로그로, 날짜는 2026년 9월 16일, ferstar가 글을 올리기 이틀 전이었다.

'저장소 스냅샷 업로드의 메모리 점유 최적화'라는 기록이 하나 있다. 엔지니어링 팀이 우발적인 행위에 대해 메모리를 최적화하기는 어렵다. 이는 '저장소 스냅샷 업로드'가 내부적으로 지속적으로 개선되는 정상 기능이었다는 뜻이다.

이 업데이트 로그는 사건이 확산된 뒤 삭제됐다. 공개 기록을 삭제하는 행위 자체가 원래 행위와는 별개의 새로운 문제다.

'관련 업로드 데이터는 즉시 폐기되며 저장되지 않는다'는 말은 데이터를 얼마나 보관하는지에 대한 답이다. 하지만 사용자가 정말 알아야 할 것은 훨씬 많다. 예컨대 데이터가 이미 컴퓨터를 떠났는지, 서버가 처리하는 과정에서 누가 접근 권한을 갖는지, 암호화 패키지의 복호화 능력이 누구 손에 있는지, 이전에 이미 업로드된 데이터에 어떤 삭제 정책이 적용됐는지 등이다.

암호화 방식을 보면 열쇠는 서버 쪽에 있다. 따라서 '암호화 업로드'가 증명하는 것은 전송 도중 제3자에게 가로채이지 않는다는 것이지, 즈푸 자신이 내용을 해독할 수 없다는 결론을 내릴 수는 없다.

ZCode 개인정보 처리방침 영문판은 수집 범위를 사용자가 'through conversation'(대화를 통해) 제출한 텍스트, 파일, 코드라고 표현하고 있다. 그러나 백그라운드 스냅샷은 사용자가 대화를 통해 제출한 것이 아니므로, 이 행위는 개인정보 처리방침이 기술한 범위에 들어 있지 않다. '대화 중에 우리에게 제출'하는 것과 '백그라운드에서 전체 프로젝트를 자동 압축'하는 것은 별개의 문제다.

이 개인정보 처리방침에는 또한, 신규 기능이 원래 목적과 직접적이거나 합리적인 연관이 없는 정보 수집을 수반할 때는 페이지 안내, 인터랙션 흐름 등의 방식으로 별도로 고지하고 사용자 동의를 받아야 한다고 명시돼 있다.

또 다른 개발자 펑뤄항의 코드 분석에서는, 클라이언트가 매번 질문을 보낼 때마다 무조건 서버 측에 업로드 자격증명을 신청하고, 서버 측이 자격증명을 발급하면 수집하고 발급하지 않으면 수집하지 않는다는 사실이 드러났다.

ferstar가 발견한 그 313MB짜리 파일은 당시 전송 대기 상태였고 이미 564회 실패했다. 펑뤄항은 자신의 Mac에서 ferstar의 포렌식 절차를 독립적으로 재현했고, 4개 작업공간의 스냅샷 기록에서 적어도 하나의 스냅샷 상태 파일에 서버 측 수신 확인 표시가 기록돼 있음을 확인했다.

코드 로직상 이 표시는 업로드가 서버 측에서 수신 확인된 뒤에만 생성된다. 이는 적어도 한 대의 기기에서 데이터가 실제로 로컬을 떠났다는 뜻이다. 즈푸의 사과, 약속, 보상은 논란이 확산된 지 몇 시간 안에 모두 나왔고, 반응 속도는 장기간 은폐를 준비한 것 같지는 않다.

하지만 '즉시 폐기'든 '저장하지 않음'이든 이런 약속은 외부에서 검증할 수도, 반증할 수도 없다. 사용자가 볼 수 있는 것은 데이터가 자신의 컴퓨터를 떠났다는 사실뿐이고, 그 뒤에 무슨 일이 일어났는지는 전적으로 제조사의 자기 규율에 달려 있다.

즈푸가 약속한 오픈소스와 제3자 감사가 이 점을 바꿀 수 있을지는, 오픈소스로 공개되는 것이 어느 버전인지, 감사가 클라이언트를 대상으로 하는지 서버를 대상으로 하는지에 달려 있다. 이 질문들에는 현재 답이 없다.

3. 코드 데이터보다 더 민감한 것

만약 정말로 일부 제조사가 의도적으로 사용자 데이터를 수집한다면, 그들이 원하는 것은 사용자 코드 자체가 아닐 수도 있다.

각 코드 호스팅 플랫폼의 공개 프로젝트가 모델 훈련에 충분한 말뭉치를 제공하기 때문이다. 사유 코드에는 물론 영업 비밀이 포함되지만, 모델 개선 관점에서 보면 코드 텍스트 한 묶음을 더 얻는 것의 한계 가치는 높지 않다.

정말로 희소한 것은 세 가지다.

첫째는 변경의 인과 사슬이다.

프로젝트의 이력 수정 기록에 저장된 것은 스냅샷 한 장 한 장이 아니라 '바꾸기 전에는 이랬고, 무슨 이유로, 이렇게 바뀌었다'는 완전한 과정이다. 이런 전후 맥락을 지닌 시퀀스는 프로그래밍 모델을 훈련하는 데 가장 이상적인 학습 자료다. 프로젝트의 현재 상태와 수정 의도 하나가 주어졌을 때 모델이 어떤 변경을 해야 하는지를 가르쳐 주기 때문이다.

둘째는 결과 라벨이 붙은 사용 궤적이다.

ZCode의 트리거 메커니즘은 사용자가 매번 질문을 보내기 전에 '파노라마 사진'을 한 장 찍고, 동시에 롤백 기능을 갖춰 사용자가 AI가 만든 수정을 되돌릴 수 있다. 이 두 동작이 결합하면 '질문 + 조작 전 상태 + 조작 후 상태 + 사용자 만족 여부(되돌렸는지)'의 완전한 순환을 자연스럽게 기록하게 된다. 이런 데이터는 AI 훈련에서 극도로 비싸서 보통 사람을 따로 고용해 라벨링해야 하는데, ZCode의 스냅샷 메커니즘은 사용자가 정상적으로 사용하는 과정에서 이런 라벨을 무료로 생성하게 만드는 셈이다.

셋째는 어떤 모델도 본 적 없는 실제 프로젝트다.

현재 공개된 프로그래밍 평가 문제는 거의 모두 각 모델이 훈련 때 '한 번 풀어본' 것이라 성적이 부풀려져 있다. 실제로 훈련 세트에 들어간 적 없는 사유 프로젝트는 내부 역량 평가를 하는 데 가장 가치 있는 원료다.

이 세 가지는 실제로 ZCode 업로드 패키지의 구성과 높은 수준으로 일치한다. 이것이 커뮤니티가 '설명 문서를 생성하기 위한 것일 뿐'이라는 해명을 끝내 받아들이지 않는 이유다.

하지만 반대로 말하면, 목표가 정말로 훈련 데이터를 체계적으로 수집하는 것이라면 더 정확한 방법은 질문 내용과 코드 변경만 추출하는 것이고, 굳이 수백 메가바이트의 대용량 파일 캐시와 완전한 작업 로그까지 함께 압축할 필요는 없다.

이런 과도한 수집의 형태는, 엔지니어링 팀이 스냅샷 기능을 개발하면서 범용 압축 로직 하나를 재사용해 인덱스와 롤백에 관련된 모든 파일을 한꺼번에 집어넣은 것에 더 가깝다. 게다가 클라우드 스토리지 자체에 비용이 들고, 다수의 개인 사용자가 쓰는 소규모 프로젝트와 연습용 코드는 모델 훈련에 대한 실제 가치가 제한적이며, 유료 고객 특히 기업 고객의 데이터에 손을 대는 것은 위험 대비 수익이 극히 불리하다.

인정해야 할 것은, 이 데이터를 이용해 모델과 도구를 개선하려는 동기는 성립하고 경로도 이미 마련돼 있다는 점이다. 그러나 업로드 패키지의 조잡한 정도를 보면, 공격적인 제품 결정에 엔지니어링 차원의 게으름이 겹친 것이 '즈푸가 의도적으로 무언가를 꾸몄다'는 것보다 기존 증거에 더 부합한다.

물론 즈푸에 주관적 고의가 없다고 해서 이 문제의 심각성을 무시할 수는 없다. 이는 분명 사용자에게 보안 위험을 초래한다.

4. 에이전트 제조사들의 집단적 월권

ZCode 사건과 비슷한 파문은 올해 이미 한 번 이상 일어났다.

올해 7월, 독립 보안 연구자 cereblab은 xAI의 Grok Build에 대해 완전한 네트워크 패킷 캡처 분석을 수행하고 모든 증거와 재현 절차를 공개했다.

그가 발견한 현상은 ZCode보다 더 과장됐다. Grok Build는 사용자의 전체 프로젝트를 코드 패키지로 압축해 구글의 클라우드 스토리지 서비스로 업로드하며, 업로드 범위는 모든 파일을 포괄한다. 여기에는 사용자가 대화 중에 AI에게 '읽지 말라'고 명시한 파일도 포함된다. 12GB짜리 테스트 프로젝트에서 패킷 캡처가 중단된 시점까지 확인된 파일 용량은 5GB를 넘어섰다.

테스트에서는 프로젝트의 비밀번호와 키 파일조차 그대로 업로드되고 어떤 비식별화 처리도 거치지 않았다는 사실도 드러났다. 사용자가 설정에서 '모델 개선' 옵션을 꺼도 업로드는 그대로 진행됐다. 꺼지는 것은 훈련 권한일 뿐, 코드가 컴퓨터를 떠나는지 여부에는 영향을 주지 않았다.

머스크는 사건이 폭로된 뒤 업로드된 모든 데이터를 삭제하겠다고 공개적으로 약속했고, xAI는 서버 측에서 업로드 기능을 껐다.

더 앞선 3월 31일에는 Claude Code가 한 버전 릴리스에서 설정 파일 하나의 부주의로 약 60MB의 소스 맵 파일이 공개 배포되는 설치 패키지에 잘못 포함됐고, 외부 개발자가 이 도구의 아키텍처를 볼 수 있게 됐다.

커뮤니티는 Claude Code가 매시간 Anthropic 서버에 원격 설정을 한 번씩 폴링하며, 설정 항목에 프로그램을 강제 종료하거나 사용자 권한 프롬프트를 우회할 수 있는 여러 제어 스위치가 포함돼 있고, 모두 백그라운드에서 효력을 발휘하며 사용자의 능동적 업데이트가 필요 없다는 사실을 발견했다.

Claude Code는 사용자의 프록시, 게이트웨이 주소, 중국 시간대 등의 환경 신호를 읽고, 시스템 프롬프트의 은닉 문자를 통해 분류 결과를 서버 측으로 되돌려 보낸 사실이 드러난 적이 있다. Anthropic 엔지니어는 이후 이것이 계정 남용 방지와 증류 방지를 위한 능동적 실험이었다고 확인하기까지 했다.

주관적 고의의 정도로 보면, Claude Code는 제조사 스스로 인정한 의도적 실험이고, Grok Build는 지금까지 업로드 메커니즘의 존재를 부인하지 않았으며, ZCode의 의도는 아직 결론이 나지 않았다.

데이터 수집 범위로 보면, Grok Build는 사용자가 '읽지 말라'고 명시한 파일까지 가져갔고, ZCode는 프로젝트 이력의 86.6%를 압축했다. Claude Code가 전송한 것은 행동 메타데이터로 규모는 다르지만 성격상 알 권리와 관련된다는 점은 같다.

세 사고에서 경계해야 할 점은 그것들이 모두 우연히 발견됐다는 것이다. 하나는 설정 실수로 소스가 유출됐고, 하나는 보안 연구자의 능동적 패킷 캡처 덕분이었고, 하나는 블로거가 하드디스크 공간이 이상하다는 것을 알아챈 덕분이었다. 어느 것도 제조사 스스로의 디버그나 업계 감사, 규제 순찰에서 나온 것이 아니다.

ZCode가 올해 7월 출시될 때 즈푸의 홍보는 직접적으로 Claude Code를 겨냥했고, 때마침 Claude Code 원격 측정 논란이 지나간 지 몇 주 뒤였다. ZCode는 스스로를 '제조사의 원격 통제에서 벗어날 수 있는' 대안으로 포지셔닝했다. 그리고 Grok Build의 업로드 사건도 7월에 발생해 거의 ZCode 출시와 같은 달이었다.

석 달 뒤, 같은 성격의 문제가 ZCode 자신에게서 드러났고 데이터 범위는 더 컸다. 신뢰 카드를 내세운 쪽이 먼저 넘어졌다. 이는 아마 올해 AI 도구 경쟁에서 가장 경고적인 장면일 것이다.

5. 보안 규칙은 바깥만 향한다

에이전트가 지난 1년간 얻은 권한은 그 이전에 개인용 컴퓨터에 설치된 어떤 종류의 소프트웨어보다 크다.

에이전트는 현재 프로젝트 디렉터리의 모든 파일을 읽을 수 있고, 명령줄 작업을 자율적으로 실행할 수 있으며, 동시에 항상 제조사 서버와의 연결을 유지하고, 백그라운드에서 원격 설정 업데이트를 받을 수도 있다.

그 전에는 이 네 조건을 동시에 충족하는 소비자용 소프트웨어가 거의 없었고, 이런 새 권한을 둘러싼 보안 규칙은 실제로 지난 1년간 빠르게 갱신됐다.

2025년 말, 국제 애플리케이션 보안 기구 OWASP가 자율 AI 에이전트를 대상으로 한 첫 10대 위험 목록을 발표했다. 2026년 1월, 싱가포르는 자율 AI 에이전트를 대상으로 한 첫 거버넌스 프레임워크를 내놓으며 각 에이전트가 검증 가능한 디지털 신원을 지니도록 요구했다. 2월, 미국 국립표준기술연구소(NIST)는 AI 에이전트 표준 이니셔티브를 시작했다. 8월 2일, 유럽연합 인공지능법의 고위험 의무가 정식 발효됐다. 업계 차원에서도 프로그래밍 에이전트를 전문으로 하는 인증 표준이 이미 등장했다.

규칙의 수는 늘고 있지만, 그것들이 막는 것은 도구가 외부 공격자에게 악용되는 것이다. 예컨대 악의적 명령에 납치되거나, 권한을 넘어 다른 시스템을 호출하도록 유도되는 것 등이다.

방어선 전체의 설계 가정은 제조사가 사용자 편에 서 있고, 위협은 바깥에서 온다는 것이다.

ZCode와 Grok Build의 외부 전송 통로는 정확히 이 가정의 사각지대에 서 있다. 그것들은 AI 도구의 능력 목록에 없고, 권한 승인 절차의 관할을 받지 않으며, 도구 순환 전체의 바깥에서 작동하고, AI 어시스턴트 자신조차 그 존재를 감지하지 못한다. 기존의 어떤 보안 프레임워크를 가져다 조항별로 심사해도 이 행위들은 경보를 울리지 않는다.

상장사 재무제표를 감사하듯 에이전트의 데이터 행위를 감사해야 한다는 견해도 제기됐다.

이 비유는 부분적으로 성립한다. 정기적이고, 표준화되고, 독립 제3자가 작성하고, 구매자가 읽을 수 있는 감사 보고서라는 형식은 옳다.

하지만 재무 감사가 심사하는 것은 법이 기업에 보관을 강제하는 장부다. '어떤 데이터가 사용자의 컴퓨터를 떠났는지' 같은 기록은 어떤 법규도 제조사에 보관을 요구하지 않으므로 증거 자체가 부족하다.

에이전트 클라이언트는 매주 업데이트될 수 있고, 어떤 것은 매시간 원격 설정을 한 번씩 폴링해 자신의 행동을 바꾸기도 하므로, 연간 감사 보고서는 작성되는 순간 이미 유효기간이 지난다.

상장사 감사 뒤에는 증권법과 감사 기관의 연대 배상 책임이 있지만, 에이전트 감사 뒤에는 현재 아무것도 없다.

오픈소스는 널리 논의되는 또 다른 경로다. 즈푸는 이번 사건 뒤 ZCode 코드 저장소를 오픈소스로 공개하겠다고 약속했고, OpenAI의 Codex CLI와 앞선 Gemini CLI도 오픈소스 라이선스를 채택했다.

오픈소스는 커뮤니티가 클라이언트에 유사한 외부 전송 메커니즘이 있는지 검사할 수 있게 해 주며, 이런 투명성 자체가 구속력을 형성한다. 하지만 오픈소스에는 몇 가지 본질적 한계가 있다. 그것은 클라이언트만 비출 뿐 서버는 비추지 못한다. 데이터가 제조사 서버로 보내진 뒤 무슨 일이 일어나는지는 아무도 볼 수 없다.

수정된 버전만 오픈소스로 공개하고 사건 당시의 코드를 공개하지 않는다면, 그것은 과거의 행위에 대해 증명력이 0이다. 게다가 사용자가 앱 스토어나 설치 프로그램에서 받는 것은 컴파일된 완성품이므로, 공개된 소스 코드와 같은 것인지 여부는 별도의 재현 가능한 검증을 하지 않는 한 확인할 방법이 없다.

현재 더 실용적인 몇 가지 경로가 더 실행 가능성이 높다.

첫째는 제조사가 에이전트가 어떤 서버 주소에 연결하고 어떤 범주의 데이터를 전송하는지 공개적으로 선언하도록 요구해, 비정상 트래픽을 독립 도구로 대조할 수 있게 하는 것이다. cereblab의 Grok Build 분석도 표준 네트워크 패킷 캡처 도구로 완성됐다. 제조사가 능동적으로 출구 선언을 제공했다면 검증 비용이 크게 낮아졌을 것이다.

둘째는 사용자 자신의 컴퓨터에 읽고 내보낼 수 있는 외부 전송 로그를 남겨, 매번 전송한 용량, 목적지, 데이터 범주를 명시하게 하는 것이다. 이는 '암호화 패키지가 당신 기기에서 생성되는데 당신은 그 안에 무엇이 있는지 볼 수 없다'는 가장 거슬리는 설계를 직접 해소한다.

셋째는 책임 보험 메커니즘으로, 인증 기관이 아니라 보험 인수자가 제조사의 데이터 행위를 평가하게 하는 것이다. 전자는 판단 실수에 대해 돈을 물어야 하므로, 현재 '진지한 감사'를 경제적 이익으로 바꿀 수 있는 유일한 메커니즘이다.

이 방안들은 기술적으로 모두 어렵지 않다. 어려운 것은 동력이다.

현재 그것들의 실행을 밀어붙이는 힘은 두 가지뿐이다. 기업 고객의 구매 감사와 우발적인 커뮤니티 폭로다. 전자는 기업 버전만 포괄하고, 후자는 전적으로 운에 달렸다.

그래서 결국 이번 사고의 숨은 모순은 보안 기술 방안보다 더 해결하기 어려울 수 있다.

ZCode와 Grok Build의 시나리오에서 '동의' 버튼을 누르는 것은 개발자 개인이고, 데이터 유출의 결과를 떠안는 것은 그의 고용주와 고객이다. 후자는 처음부터 끝까지 어떤 동의 절차에도 등장하지 않았고, 자신의 코드가 압축 업로드된 적이 있다는 사실을 알 수 있는 어떤 경로도 없다.

위험의 부담자와 권한 부여자가 같은 사람이 아니므로, 개인 차원의 사전 동의는 구조적으로 이 문제를 풀 수 없다. 팝업창을 아무리 명확히 쓰고 스위치를 아무리 눈에 띄게 배치해도 마찬가지다.

현실의 방향은 대체로 계층화일 가능성이 크다.

대기업은 구매 계약에 데이터 행위 조항과 감사권을 넣을 것이고, 이를 위해 치르는 비용은 결국 가격에 반영될 것이다. 개인 개발자가 쓰는 소비자 버전은 계속해서 아무도 감사하지 않고 아무도 책임지지 않는 상태에 머물 것이다. 하지만 이곳이 바로 대다수가 일과를 마친 뒤에도 계속 코드를 쓰는 곳이고, 그들이 개인 계정으로 회사 프로젝트를 열기 가장 쉬운 곳이기도 하다.