ZCode, 42,411개 파일을 Zhipu만 열 수 있는 아카이브로 압축했다

2026년 9월 18일, 한 개발자가 ferstar라는 필명으로 분해 분석한 글을 공개했다. 대상은 ZCode, 중국 모델 개발사 Zhipu AI가 만든 데스크톱 AI 코딩 에이전트이다. 그는 자신의 홈 디렉터리에 있던 숨겨진 폴더가 700MB를 넘게 커진 것을 발견한 뒤 이 글을 썼다. 그 안에는 345MB 작업 공간에서 가져온 42,411개 파일—그중 86.6%가 Git 기록—을 담은 313MB 암호화 아카이브가 있었고, 이는 클라이언트가 패키징해 Alibaba Cloud 객체 스토리지에 업로드하려고 준비한 것이었다. 아카이브는 Zhipu 서버만 풀 수 있는 키로 봉인되어 있었고, 클라이언트에는 그것이 만들어지는 것을 막는 스위치가 없었다. Zhipu는 같은 날 저녁 사과했다. 아카이브 자체의 신뢰도 등급과 피해 상태를 포함한 전체 기록은 Orca AI Incident Archive에 있으며, 이 아카이브는 문서화된 각 AI 사건을 인용 출처와 함께 기록한다.

ZCode는 Zhipu의 데스크톱 코딩 에이전트로, 프로젝트를 읽고 셸 명령을 실행하며 코드를 작성한다. 이 회사는 홍콩에서 티커 2513.HK로 거래되며, 국제 사업 부문의 브랜드는 Z.ai인데, 이는 ferstar가 조사한 ZCode 서버에 나타나는 이름이다. 그와 다른 여러 개발자를 이후 인터뷰한 상하이 언론사 The Paper에 따르면, 그의 게시물 제목은 대략 "ZCode의 전체 Git 이력 은밀한 업로드의 장막을 걷다"였고, 게시된 지 몇 시간 만에 중국 개발자 그룹들 사이로 퍼졌다고 한다.

숨겨진 폴더 안에는 무엇이 있었나요

Ferstar가 직접 제시한 수치가 이 사안의 척추이며, The Next Web, InfoQ, 중국국가인민방송(CNR) 재정 데스크가 이를 일관되게 재인용했다. 그의 ZCode 체크포인트 디렉터리에 있던 아카이브는 313MB였다. 그 옆의 상태 파일에는 약 345MB, 42,411개 파일 규모의 워크스페이스가 기록되어 있었다. .git 디렉터리가 전체 용량의 86.6%를 차지했다. Git 대용량 파일 저장소 캐시 196.1MB, 전체 커밋 이력을 담은 Git 객체 102.2MB, 그리고 일부 리플로그가 여기에 해당한다. 실제 소스 코드와 문서는 약 13.4%에 불과했다.

이 구분이 중요한 이유는 Git 기록이 현재 트리에서 제거된 자료가 살아남는 경향이 있는 곳이기 때문이다. The Paper의 설명은 이 점을 직접적으로 짚는다. 이런 종류의 아카이브는 최초 커밋부터 프로젝트의 편집 이력을 담을 수 있으며, 삭제된 콘텐츠, 커밋되지 않은 초안, 오래된 구성 파일, 그리고 오래전에 코드에서 제거되었지만 이전 커밋과 대용량 파일 캐시에 남아 있는 자격 증명까지 포함할 수 있다.

Ferstar 자신의 313MB 아카이브는 그의 컴퓨터를 떠난 적이 없습니다. 상태 로그에는 564번의 실패한 업로드 시도가 나타났고, 크기 제한을 초과한 채 대기 상태에서 멈춰 있었습니다. 파이프라인이 실제로 작동하는지 시험하기 위해 그는 538개 파일로 된 작은 공개 저장소를 시도했습니다. 그 스냅샷은 약 15KB로 압축·암호화되어 서버에 수락되었습니다. 그 전송은 기록상 종단 간 완료가 확인된 전송이며, 이것이 이 발견을 코드를 읽는 연습에서 수신 측이 입증된 유출로 바꿔 놓은 것입니다.

캡처는 사용자가 “내 저장소 업로드”로 인식할 만한 어떤 동작과도 연결되어 있지 않았다. ferstar의 재구성에 따르면, 하나의 트리거는 모델에 제출되는 각 프롬프트 전에 실행되었고, 또 다른 트리거는 Repo Wiki 업데이트 작업으로 실행되었다. 보류 중인 아카이브를 삭제해도 멈추지 않았다. Tencent Cloud 개발자 커뮤니티의 한 게시글에는 패키지가 30분 이내에 다시 빌드되었고 실패 카운터가 564에서 565로 증가했다고 기록되어 있다. 그 작성자가 찾은 유일하게 신뢰할 수 있는 중지 방법은 체크포인트 디렉터리를 쓰기 불가능하게 만들어 디스크 쓰기 단계에서 캡처가 실패하게 하는 것이었으며, 그 대가로 체크포인트 롤백과 타임라인 인터페이스를 잃었다.

공급업체만 사용할 수 있는 키

암호화는 전형적인 봉투 암호화였고, 바로 그 부분을 사용자들은 우회할 수 없었다. ferstar의 리버스 엔지니어링을 토대로 한 InfoQ의 재구성은 클라이언트가 zcode.z.ai에서 스냅샷 ID, RSA 공개 키, Alibaba Cloud OSS 업로드 자격 증명을 가져온 뒤 워크스페이스를 로컬에서 패키징하고 암호화하여 암호문을 OSS로 직접 전송한다고 설명한다. 콘텐츠는 AES-256-CTR로 암호화되었고, 대칭 키는 서버의 공개 키 아래 RSA-OAEP-SHA256으로 래핑되었으며, 그 키 쌍의 개인 키 부분은 Zhipu의 클라우드에 남아 있었다.

라우팅은 암호화만큼이나 중요하다. 클라이언트가 Zhipu 자체 애플리케이션 서버를 거치지 않고 Alibaba Cloud에 곧바로 업로드했기 때문에, 트래픽은 이를 기록하거나 필터링할 수 있는 Zhipu 서비스를 거치지 않았고, 따라서 외부로 나가는 것을 기록하거나 필터링할 Zhipu 서비스가 경로에 존재하지 않았다. 또한 개인 키가 기기에 전혀 없었기 때문에 ferstar는 자신의 아카이브를 열 수 없었다. The Next Web에 따르면 그는 자신의 컴퓨터에 있는 모든 개인 키를 시도했지만 실패했다. 그는 자신의 게시물에서 이 방식을 서버만 사용할 수 있는, 오직 한 가지 목적만 지닌 키라고 설명했다.

클라이언트의 두 설정은 이것을 막았어야 할 것처럼 보였지만, 둘 다 그러지 못했다. "환경 최적화" 토글은 데이터를 모델 학습에 사용할 수 있는지를 결정했고, "리포지토리 스냅샷 인덱싱" 토글은 서버가 이미 도착한 스냅샷에 대한 인덱스를 구축할지 여부를 결정했다. 둘 다 캡처 이후 단계에서 작동한다. Ferstar는 캡처가 무조건 실행되고 있음을 발견했으며, The Next Web은 그가 개인정보 처리방침을 읽어본 결과 대화 텍스트와 파일 수집에 대해서는 설명했지만 전체 Git 이력을 담은 자동 워크스페이스 스냅샷에 대해서는 아무 말도 없었다고 보도했다.

Zhipu가 내놓은 설명, 그리고 그 후 나흘

Zhipu는 보도자료가 아니라 ZCode 공식 사용자 그룹을 통해 같은 날 대응했습니다. Global Times가 보도하고 Security Inside가 재게재한 내용에 따르면, 회사는 이 동작을 코드베이스 인덱싱이라는 기능 때문이라고 설명했습니다. 이 기능은 로컬 인덱싱, 세션 체크포인트 복원, 버전 롤백 및 Repo Wiki 생성을 지원하며, 회사는 Repo Wiki 단계가 저장소의 클라우드 업로드를 촉발했다고 밝혔습니다. 이 기능은 출시 이후 기본적으로 켜져 있었습니다. Zhipu는 업로드된 데이터가 Repo Wiki 페이지 생성에만 사용되었고 이후 즉시 파기되었으며, 저장되거나 학습에 사용되지 않았다고 밝히고 영향을 받은 사용자들에게 사과했습니다. 또한 ZCode 코드베이스를 오픈소스로 공개하고 제3자 검토를 초대해 결과를 공개하겠다고 약속했으며, 보상으로 모든 ZCode 사용자에게 주간 할당량 재설정을 한 번 더 제공했습니다.

수정 사항은 다음 날 도착했다. The Paper는 ZCode 3.14.0이 9월 19일 출시되었으며 변경 로그에 "저장소 위키의 비정상 업로드 문제 수정"이라고 적혀 있었다고 보도했고, ferstar가 같은 날 업로드 체인과 그 엔드포인트가 사라졌음을 확인했다고 전했다. 9월 20일 Zhipu의 MaaS 플랫폼은 입력과 출력이 정적으로 저장되지 않는 제로 리텐션 옵션을 곧 제공할 예정이라고 발표했으며, The Paper는 이 옵션이 신청 기반 옵트인 방식이고 Batch API와 File API는 제외되며, 법률 또는 남용 조사상 필요한 경우에는 여전히 30일 이상 보관을 허용한다고 언급했다. 9월 21일에는 클라이언트 소스가 Apache 2.0 라이선스로 GitHub에 공개되어 데스크톱 앱, 웹 클라이언트, 백엔드, 에이전트 CLI 및 에이전트 런타임을 포함했다.

두 건의 감사가 의뢰되었고 그 결론은 요약본으로 공개되었다. 중국정보통신연구원(China Academy of Information and Communications Technology)은 zcode-prod Alibaba Cloud OSS 버킷이 Zhipu가 말하는 제로 데이터 상태에 있음을 발견했다. 보안 업체 NSFOCUS는 모든 데이터 객체와 버킷 자체가 삭제되었으며, ZCode 3.14.0에서 로컬 저장소 스냅샷을 트리거하거나 파일을 외부로 전송할 수 있는 경로가 더 이상 남아 있지 않다고 보고했다. 전체 평가 보고서는 아직 나오지 않았으며, The Next Web은 Zhipu가 그 보고서에 대한 일정을 제시하지 않았다고 보도했다.

더 많이 주장했다가 철회한 고객

실제 손실에 관한 가장 심각한 주장은 ferstar에서 나오지 않았다. 9월 19일 China National Radio에 따르면, Taiyuan Chengming Technology는 Zhipu에 'Chengming [2026] Legal Letter No. 1'이라는 번호의 법률서한을 보냈으며, ChainCatcher가 이를 상세히 재현했다. 이 회사는 자사의 코딩 작업 공간 6개가 동의 없이 업로드되었다고 밝혔다. 해당 데이터는 34,500개 파일과 약 425MB의 평문으로, 전체 소스 코드, 시스템 아키텍처, 버전 이력, 데이터베이스 비밀번호, 클라우드 자격 증명 및 직원 개인정보를 열거하고 있다. 또한 1,947개 파일과 약 144MB로 구성된 일곱 번째 작업 공간은 패키징 및 암호화되었지만 32번의 업로드 재시도에 실패했다고 밝혔다. 또한 자사 클라이언트가 9월 16일 버전 3.12.3으로 업데이트되었음에도, Zhipu가 사과한 날인 9월 18일 00:28에도 업로드가 여전히 탐지되었다고 지적했다.

그 편지는 감사에서 답하지 않은 질문, 즉 데이터가 국외로 반출되었는지 여부를 물었다. Chengming은 ZCode의 네트워크 요청이 싱가포르 법인을 가리켰지만 서비스 계약은 Beijing Zhipu Huazhang과 체결되었다고 말했으며, Zhipu에 어느 당사자가 책임이 있는지, 그리고 중국 본토 외부로 이전되거나 저장된 것이 있는지 밝히라고 요구했다. 그 편지는 열두 가지 요구 사항을 제시했는데, 여기에는 업로드된 모든 데이터와 그 파생물, 캐시 및 백업을 삭제하고 서면 증명서를 제출할 것, 데이터가 어디로 갔는지 그리고 제3자와 공유되었거나 학습에 사용되었는지 설명할 것, 개인 키가 어떻게 보관되는지 설명하고 접근 로그를 제공할 것, "파괴되었다"는 주장의 정확한 범위를 정의할 것, 다시는 업로드하지 않겠다고 서면으로 약속할 것이 포함되었다. Zhipu에 10월 10일까지 서면 답변하도록 기한을 주었고, 손해배상을 청구하고 규제 당국에 민원을 제기할 권리를 보유했다. Caixin Global은 Zhipu가 해당 혐의를 사실이 아니라고 말했다고 보도했다.

이틀 뒤 Chengming은 이를 철회했다. 중국국가라디오의 경제부는 9월 21일 회사가 철회 성명을 내어, 앞선 발언들이 잘못된 증거와 부정확한 설명, 과장된 표현에 근거했으며 Zhipu의 명성에 손해를 입혔고, 언론에 더 이상 말하지 않겠다고 밝혔다고 보도했다. The Next Web에 따르면 로이터도 이 철회를 보도했다. 이 사건의 아카이브 항목은 발견 당일인 9월 18일 날짜로 되어 있으며, 그 편지와 10월 10일 마감 시한, 철회는 모두 그 날짜 이후에 나왔다. 10월 말 현재 공개 기록상, 자사 비밀이 노출됐다는 주장을 뒷받침하는 이름이 밝혀진 회사는 없다.

히스토리가 지워진 오픈소스 릴리스

클라이언트를 오픈소스로 공개하는 것이 Zhipu가 가장 의지한 해결책이었지만, 거기에는 구멍이 있었다. The Paper에 따르면 공개된 저장소에는 두 개의 커밋이 들어 있다. 하나는 빈 최초 커밋이고, 다른 하나는 약 6,973개 파일과 103만 줄을 추가한 단일 커밋이며, 풀 리퀘스트는 잠겨 있고 이슈는 닫혀 있다. 배포 당시 업로드 파이프라인이 어땠는지, 그리고 어떤 릴리스에 그것이 포함되었는지는 이제 누구나 읽을 수 있는 히스토리에는 남아 있지 않다.

Ferstar의 후속 설명 자체가 그 한계를 명확히 한다. 그는 업로드 파이프라인이 사라졌고 남은 체크포인트 메커니즘은 로컬 Git 작업만 수행한다는 점을 확인한 뒤, 버킷 감사가 무엇을 보여줄 수 있고 무엇을 보여줄 수 없는지 지적했다. 버킷을 비우고 삭제하는 것은 올바른 손실 방지 조치지만, 9월 20일 이후에 수행된 제3자 점검은 그 시점에 버킷이 비어 있었다는 것만 입증할 수 있다. 9월 18일 이전에 무엇이 오갔는지, 무엇인가가 복호화·복사·백업되었는지, 또는 파이프라인이 얼마나 오래 실행되었는지는 재구성할 수 없다. 삭제 주장은 여전히 상당 부분 삭제한 당사자의 말에 의존한다.

InfoQ의 분석은 남아 있는 질문들을 같은 기준으로 나열한다. 저장소 스냅샷이 몇 개나 성공적으로 업로드되었고 몇 명의 사용자가 업로드했는지, 객체가 얼마나 오래 보존되었는지, 어떤 서버 측 시스템이나 직원이 이를 복호화할 수 있었는지, 완전한 접근 로그가 존재하는지, 그리고 삭제가 백업과 다른 사본까지 포함했는지다. 또한 수정 후에도 ZCode가 여전히 무엇인지 언급한다. 프로젝트 자체의 NOTICE는 공유 에이전트 런타임이 기본적으로 운영 체제 수준의 샌드박스를 제공하지 않으며, 클라이언트가 사용자 계정 권한 범위 내에서 파일을 읽고 프로세스를 시작하며 네트워크에 접근할 수 있는 셸, 터미널, Git, MCP, 플러그인 및 내장 브라우저 표면을 유지한다고 경고한다.

무엇이 확립되어 있으며, 어떤 자료도 답하지 못하는 것은 무엇인가

해당 메커니즘은 논란의 여지가 없다. Zhipu의 자체 성명도 저장소 데이터가 업로드되었고, 해당 기능이 기본 활성화되어 있었으며, 데이터가 회사가 통제하는 클라우드 버킷으로 전송되었다는 점을 인정한다. Ferstar의 측정 결과, 공급업체의 사과, 두 차례의 위탁 감사, 오픈소스 공개는 모두 동일한 사슬을 설명한다. 기록 어디에도 워크스페이스가 실효성 있는 옵트아웃 없이 머신을 떠났다는 점을 반박하지 않는다. 기록에 남은 피해는 가상이 아니라 현실화된 것이다. 전송은 실제로 일어났고, 그 안에 자신의 코드가 포함된 사람들은 이를 막을 수도, 점검할 수도 없었다.

분쟁의 대상이거나 단순히 알려지지 않은 것은 규모와 결과다. 어떤 출처도 영향을 받은 기본값을 얼마나 많은 사용자가 실행했는지, 파이프라인이 9월 18일 이전 얼마나 오랫동안 운영되었는지, 또는 업로드된 객체가 실제로 복호화된 적이 있는지를 밝히지 않는다. 위키 생성 후 데이터가 파기되었고 학습에 사용되지 않았다는 Zhipu의 보증은 회사 자체의 진술이다. CAICT와 NSFOCUS의 조사 결과는 수정 후 버킷의 상태를 설명할 뿐, 그 버킷을 거쳐 간 내용을 설명하지는 않는다. 해당 아카이브는 문서화 항목에서 기록에 A등급을 부여하는데, 그 문서는 메커니즘에 관해서는 충실하지만 범위에 관해서는 빈약하다.

무엇이 바뀌었고, 무엇이 바뀌지 않았는가

상업적 비용은 즉각적이었다. China National Radio는 Zhipu의 홍콩 상장 주식이 9월 21일 1.79%, 9월 22일 6.55%, 9월 23일 12.4% 하락해 3거래일 동안 누적 16% 넘게 하락했다고 보도했으며, Zhipu는 얼마나 많은 사용자가 영향을 받았는지, 또는 과거 데이터가 복호화되었는지나 백업되었는지에 대해 답하지 않았다.

ZCode 사용자가 그 발견 이후 나흘 동안 실제로 받은 것:

• 9월 18일: 코드베이스 인덱싱을 원인으로 지목하는 공개 사과, 클라이언트 오픈소스화 및 제3자 검토 의뢰 약속, 그리고 사용자당 주간 할당량 재설정 1회 추가.

• 9월 19일: ZCode 3.14.0에서 Repo Wiki가 제거되고 로컬 스냅샷 생성 및 업로드 경로가 삭제되었다. Ferstar는 다음 날 업로드 체인이 사라졌음을 확인했다.

• 9월 20일: Zhipu의 MaaS 플랫폼에 대해 발표된 제로 리텐션 옵션으로, 옵트인 방식이며 Batch API와 File API는 제외되고, 여전히 30일 이상의 법적 보존 의무가 적용됩니다.

• 9월 21일: ZCode가 사고 이전 커밋 이력 없이 Apache 2.0으로 공개됨; CAICT와 NSFOCUS 요약에서는 스토리지 버킷이 비어 있고 이그레스 경로가 존재하지 않는다고 보고함.

그중 어느 것도 소급 적용되지 않는다. Chengming이 제기한 구체적인 질문들—데이터가 어디로 갔는지, 누가 복호화할 수 있었는지, 국외로 반출되었는지, 그리고 "파괴됨"이 무엇을 포함했는지—은 10월 10일 마감 시한을 명시해 서면으로 제출되었고, 그 질문을 한 회사와 함께 철회되었다. Zhipu는 날짜를 정하지 않은 채 전면적인 제3자 평가 보고서를 약속했다. 그 보고서가 나오기 전까지, 파이프라인이 수신한 데이터로 무엇을 했는지에 대한 유일한 공개 설명은 그것을 구축한 회사의 설명이며, 독립적으로 측정 가능한 유일한 산출물은 한 개발자의 노트북에서 빠져나오는 데 564번 실패한 313MB 파일이다.