지푸(Zhipu) 산하 AI 코딩 도구 ZCode가 백그라운드에서 작업 디렉터리 전체를 압축해 업로드한다는 사실이 9월 18일 개발자들에 의해 드러났다. 대상에는 Git 전체 이력, LFS 대용량 파일 캐시, 로컬 설정까지 포함됐다. 같은 날 늦게 ZCode 측은 사과문을 내고 업로드가 실제로 있었다는 점을 인정하면서, 원인을 '저장소 인덱싱' 기능 탓으로 돌리고 문제는 이미 수정됐다고 밝혔다.
개발자들이 밝혀낸 것
가장 먼저 세부 내용을 공개한 건 기술 블로거 Ferstar였다. 그는 블로그에서 ZCode의 로컬 스냅샷 메커니즘을 분석했다. 로그인 후 프로그램과 함께 실행되는 백그라운드 프로세스가 작업 디렉터리 전체를 패키징하고, AES-256-CTR로 파일 내용을 암호화한 뒤, 서버가 내려준 RSA 공개키로 키를 감싸 폼 전송 방식으로 알리바바 클라우드 OSS에 직접 업로드한다는 것이다. 복호화에 필요한 개인키는 서버 쪽에만 있어서, 사용자 손에 있는 .enc 파일은 스스로 열 수 없다.
그가 제시한 샘플은 구체적이었다. 압축 전 345MB였던 작업 디렉터리가 암호화 후 313MB, 파일 목록은 42,411개였다. 대부분은 .git 디렉터리로 전체의 86.6%를 차지했고, 그중 LFS 캐시가 196.1MB, Git 오브젝트가 102.2MB였으며 실제 소스코드와 설정은 약 46MB에 불과했다. 트리거 시점은 두 가지로, 프롬프트를 제출할 때마다 한 번, 작업이 끝난 뒤 Repo Wiki를 갱신할 때 한 번이었다. 한 세션에서 최대 62회의 스냅샷이 기록됐다.
같은 날 한 개발자가 지푸의 공개 피드백 저장소에 이슈를 올렸는데, 제목에서 '왜'를 세 번 연달아 물었다. 왜 Git 전체 이력을 몰래 업로드하는지, 왜 사용자 본인도 열 수 없게 암호화하는지, 왜 끄는 스위치조차 제공하지 않는지였다. 이슈에는 로컬 업로드가 실패한 뒤 스냅샷이 반복적으로 재시도되며 564회에 이르렀다는 내용도 담겼다. 다른 개발자는 자신의 환경에서 이를 재현했는데, 한 프로젝트의 스냅샷이 748MiB였고 .git 비중이 98.91%, 버전은 ZCode 3.12.3이었다.
먹통이 된 스위치는 이번 논란에서 가장 날카로운 지점이다. Ferstar에 따르면 화면상의 '경험 최적화'와 '저장소 스냅샷 인덱싱' 스위치는 서버가 그 데이터를 모델 학습에 쓸지 여부만 제어할 뿐, 로컬 패키징과 업로드는 스위치 상태와 무관하게 그대로 진행된다. Git 이력에는 이미 삭제한 줄 알았던 키, 폐기된 옛 설정, 푸시되지 않은 브랜치 기록, 사내 도메인명 등이 남아 있을 수 있다. 현재 코드에는 보이지 않아도 .git 안에는 고스란히 남아 있다.
지푸의 해명
ZCode의 사과문은 업로드 원인을 '저장소 인덱싱' 기능으로 돌렸다. Repo Wiki 페이지를 생성할 때 저장소 데이터 업로드가 발생할 수 있으며, 데이터는 클라우드에서 Wiki 생성이 끝난 직후 즉시 폐기되고 별도로 보관하지 않는다는 설명이다. 이 기능은 출시 초기 기본값이 켜짐이었고 일부 사용자가 영향을 받았으나, 현재는 수정됐다고 밝혔다.
제시된 대응책은 세 가지다. 조만간 ZCode 코드베이스를 오픈소스로 공개하고, 제3자 평가를 요청해 검토 진행 상황을 공개한다는 것, 그리고 그날 전체 사용자에게 주간 쿼터를 한 번 더 초기화해준다는 것이다. 다만 성명에서 다루지 않아 현재로선 검증이 불가능한 부분도 있다. 영향을 받은 사용자와 저장소가 얼마나 되는지, 데이터가 OSS에 실제로 얼마나 머물렀는지, '폐기'가 독립적인 감사를 거쳤는지, 수정 이후 버전 번호가 무엇인지 등이다. 오픈소스 공개 시점도 '조만간'이라고만 적혀 있다.
같은 날 지푸는 신모델 GLM-5.3-FlashX도 공개하며 초당 200토큰의 출력 속도를 내세웠다. 한 개발자는 블로그에서 두 사건을 나란히 놓고 '온 인터넷이 코드가 어디로 갔는지 묻는 사이, 지푸는 신모델 출시로 바쁘다'고 비꼬았다.
국내 개발자가 지금 할 수 있는 일
ZCode 사용자 중에는 회사 프로젝트에서 시험 삼아 써본 이들이 적지 않은데, Git 이력은 현재 코드보다 기업에 더 민감한 경우가 많다. 아직 구버전을 쓰고 있다면 비교적 안전한 조치는 세 가지다. 먼저 수정된 버전으로 업그레이드하고, 로컬의 ~/.zcode/v2/checkpoints 아래에 업로드 대기 중인 스냅샷이 남아 있는지 확인한 뒤, 이력에 등장했던 키와 토큰을 전부 교체하는 것이다. '폐기했다'는 말이 이미 유출된 부분까지 커버한다고 기대해서는 안 된다.
Ferstar는 더 강력한 방법도 제시했다. macOS에서는 chflags uchg, 리눅스에서는 chattr +i로 스냅샷 디렉터리를 쓰기 불가로 잠가 파일시스템 단에서 아예 스냅샷 생성을 막는 방식이다. 대가로 체크포인트 롤백과 타임라인 기능도 함께 먹통이 된다.
이런 코딩 에이전트는 저장소를 읽어야 작동하므로 로컬 인덱싱 자체가 특이한 일은 아니다. 문제는 경계에 있다. 로컬에서 읽는 것과 클라우드로 보내는 것은 별개이고, 현재 코드를 보내는 것과 이력 전체를 보내는 것 역시 별개다. 지푸가 약속한 오픈소스 공개가 실제로 이뤄진다면, 외부에서도 스냅샷 모듈이 정확히 어떤 경로를 패키징하는지, 스위치가 어디에 연결돼 있는지를 스스로 확인할 수 있게 된다.
참고 출처: 스냅샷 메커니즘과 파일 구성을 분석한 Ferstar의 기술 블로그, zai-org/feedback의 공개 이슈, 펑황왕 테크(Phoenix Tech), CocoLoop, Elliot's Harness Lab; 귀인·수정 상태·보상 조치는 ZCode의 사과문으로 확인.