ZCode가 올린 것은 프롬프트 파일이 아니라 작업공간 전체였나

ZCode의 데이터 처리 논란은 사용자가 AI 프롬프트에 직접 첨부한 파일을 전송했다는 수준의 문제가 아니었다. 연구자 ferstar의 역분석 보고서는 사용자가 로그인한 상태에서 데스크톱 클라이언트가 암호화된 작업공간 스냅샷을 묶어 Aliyun(알리바바 클라우드) OSS(Object Storage Service)로 전송하려 했다고 주장했다. Z.AI는 관련 기능인 ‘코드베이스 인덱싱(Codebase Indexing)’의 문제를 인정하며, 초기에는 기본 활성화돼 있던 Repo Wiki 생성 과정에서 저장소 데이터 업로드가 촉발될 수 있었다고 설명했다.235

연구자가 본 스냅샷의 범위

ferstar의 기술 보고서에 따르면, 이 스냅샷은 프롬프트에 넣은 일부 파일이 아니라 작업공간 전체를 포괄할 수 있었다. 보고된 포함 대상은 다음과 같다.

• 전체 .git 디렉터리와 커밋 이력
• Git LFS 에셋 캐시와 reflog
• 작업공간 파일
• 전역 애플리케이션 설정35

한 보도는 암호화 아카이브의 크기를 약 313MB로 전했다. 분석을 인용한 보도에 따르면, 관련 RSA 개인키는 Z.AI 측에만 있었기 때문에 사용자가 확보한 암호문을 독자적으로 복호화하거나, 암호문만으로 삭제 여부를 검증하기는 어려웠다.4

다만 이는 역분석과 네트워크 트래픽 관찰에 근거한 보고이지, 영향을 받은 모든 기기를 대상으로 한 독립적·공식적 전수 목록은 아니다. OSS로의 전송 시도가 관찰됐다는 사실만으로 모든 시도가 완료됐다고 단정할 수는 없으며, 전송된 객체가 이후 얼마나 오래 남아 있었는지도 그것만으로 알 수 없다.316

Repo Wiki는 어떻게 업로드 경로가 됐나

Z.AI는 문제가 코드베이스 인덱싱에서 비롯됐다고 설명했다. 이 기능은 Repo Wiki와 버전 관련 작업 등에 쓰이며, Repo Wiki 페이지를 생성할 때 저장소 데이터 업로드가 발생할 수 있었다는 것이다. 회사는 이 기능이 출시 초기에는 기본으로 켜져 있었다고 밝혔다.2511

이 설명은 어떤 제품 기능 경로에서 전송이 발생했는지는 보여준다. 그러나 이를 일반적인 ‘파일 업로드’ 동의와 동일시하기는 어렵다. 논란의 핵심은 범위와 동의였다. 사용자와 연구자들은 해당 전송에 대해 명확하고 실효성 있는 확인 절차 없이 작업공간 전체 패키지가 만들어졌다고 지적했다.36

Z.AI의 조치: 기능 제거·오픈소스·외부 감사

논란이 불거진 뒤 Z.AI는 사과하고 영향을 받은 기능을 비활성화했다고 밝혔다.2 이후 회사는 ZCode v3.14.0에서 Repo Wiki를 제거하고, 로컬 저장소 스냅샷을 생성·업로드하던 워크플로도 중단했다고 발표했다.16

Z.AI는 ZCode를 오픈소스로 공개해 외부 검토를 받겠다고 했으며, 중국정보통신기술원(CAICT)과 NSFOCUS의 평가가 진행됐다고 전해졌다.1023

ZCode가 공개한 평가 결과에 따르면 다음과 같다.

• CAICT는 조치 이후 알리바바 클라우드 OSS의 zcode-prod 버킷이 데이터 0건 상태임을 확인했다.
• NSFOCUS는 해당 버킷과 관련 백업 저장소의 데이터 객체 삭제를 확인했다.16

별도로 즈푸는 MaaS(Model as a Service) 플랫폼에 데이터 미보존(no-data-retention) 옵션을 도입할 계획이라고 밝혔다. 이 옵션에서는 입출력 데이터가 현재 요청 처리에만 쓰이고 이후 삭제된다는 방침이다. 다만 이는 플랫폼의 향후 처리 정책에 관한 제안으로, 이전 ZCode 워크플로에서 실제로 어떤 일이 있었는지를 독립적으로 입증하는 근거로 보기는 어렵다.24

아직 검증되지 않은 부분

회사의 시정 조치는 의미가 있지만, 그것만으로 과거의 모든 질문에 답할 수는 없다. 시정 후 특정 버킷이 비어 있었다는 감사 결과는 해당 시점에 검토 대상 버킷이 비워졌다는 주장에는 힘을 실어준다. 하지만 더 넓은 로그와 완전한 처리 기록 없이는 데이터가 다른 곳에 복제되지 않았는지, 삭제 전 접근되지 않았는지, 다른 목적으로 이용되지 않았는지를 독립적으로 증명할 수 없다.

Z.AI는 보고된 코드와 관련 데이터가 보존되지 않았고 모델 학습에도 사용되지 않았다고 밝혔다.41 그러나 여기서 검토한 공개 자료에는 보고된 모든 스냅샷에 대해 이 부정적 주장을 종단 간으로 검증할 수 있는 독립 감사 기록은 제시되지 않았다. 따라서 결론은 제한적이다. 회사는 학습 이용을 부인했지만, 공개 검증은 아직 불완전하다.

청밍테크놀로지가 ‘처리 목록’을 요구한 이유

타이위안 청밍테크놀로지는 회사 데이터와 영업비밀이 무단 업로드됐다고 주장하며 즈푸에 법적 요구서를 보냈다. 이 회사가 요구한 것은 단순 삭제를 넘어, 저장 위치, 국외 이전 가능성, 제3자 제공 여부, 모델 학습 이용 가능성, 접근·반출 로그, 서버·캐시·백업·재해복구 시스템 전반의 삭제 증빙이었다.172126

이 요구는 AI 코딩 도구에 대해 이용자와 기업이 점점 더 기대하는 기준을 보여준다. ‘삭제했다’는 선언만이 아니라 무엇을 수집했는지, 어디로 이동했는지, 누가 처리할 수 있었는지, 삭제를 어떻게 확인할 수 있는지를 추적 가능하게 설명하라는 것이다.

시장 반응은 즉각적이었지만 장기 판단의 근거는 아니다

보도에 따르면 논란 뒤 Z.AI 주가는 장중 최대 5% 하락했다.35 다만 이후 시세 페이지에는 1.79% 상승으로 표시된 종가도 있었고, 다른 시장 보도는 당일 더 낮은 종가를 전했다.3438 엇갈린 시세 기록이 뒷받침하는 결론은 제한적이다. 사건이 단기적인 시장 우려를 낳았다는 점은 확인되지만, 장기 기업가치에 미친 영향을 단정하기에는 부족하다.

개발팀이 확인할 기준

이번 사례는 AI 코딩 도구를 평가할 때 로컬 인덱싱, 프롬프트 맥락 전송, 작업공간 전체 스냅샷 업로드를 반드시 구분해야 한다는 점을 보여준다. 각 동작은 문서, 네트워크 점검, 소스 검토 등을 통해 이해할 수 있어야 하며, 각각 따로 제어할 수 있어야 한다.

독점 코드, 비밀정보, 규제 대상 데이터를 다루는 팀이라면 업로드에 대한 명시적 동의를 요구하고, 작업공간 범위를 최소화하며, 외부 통신 목적지를 점검할 필요가 있다. 또한 보존 기간, 하도급 처리자, 삭제 절차, 감사 증거를 구체적으로 명시한 공급업체 약정을 받아야 한다. 이번 사안에서 Z.AI의 스냅샷 업로드 흐름 제거는 보고된 메커니즘에 대응한 조치다. 하지만 과거 데이터 처리에 관한 더 큰 질문이 남아 있었기에 패치 이후에도 논란은 계속됐다.1617