ZCode 내부 분석: 사용자 모르게 Git 이력을 클라우드에 업로드

Zhipu의 AI 코딩 데스크톱 앱 ZCode는 로그인 상태에서 작업 공간을 백그라운드로 압축하고 암호화해 Aliyun OSS로 업로드함. 전체 Git 이력, LFS 캐시, reflog, 전역 앱 설정까지 수집함 암호화에 쓰는 RSA 공개키는 서버가 전달하며, 복호화 개인키는 서버만 보유함. 로컬에 남은 암호화 파일도 사용자나 ZCode 클라이언트가 직접 열 수 없음 조사한 스냅샷은 42,411개 파일로 구성되며, .git이 용량의 86.6% 를 차지함. 과거 커밋에서 삭제한 민감 정보와 푸시하지 않은 브랜치의 흔적까지 업로드 범위에 들어감 경험 최적화와 저장소 스냅샷 인덱싱 설정을 꺼도 캡처와 업로드는 계속됨. 개인정보 처리방침에도 전체 작업 공간과 Git 이력을 전송한다는 고지가 없음 파일을 삭제하면 다시 생성하므로, 대응책은 체크포인트 디렉터리의 파일시스템 불변 잠금임. 업로드할 로컬 파일 생성을 막지만, 체크포인트 롤백과 타임라인 기능도 사용할 수 없게 됨 조사 출발점: 업로드 대기 중인 313MB 파일 ~/.zcode가 700MB 이상을 차지하는 것을 확인하면서 조사가 시작됨 cli/는 세션 데이터베이스와 실행 로그 등 약 257MB를 차지함 computer-use/는 번들 앱과 런타임 의존성 등 약 130MB를 차지함 v2/checkpoints/는 약 303MB를 차지함 v2/checkpoints/에서 상용 프로젝트를 대상으로 한 313MB 암호화 파일과 상태 메타데이터가 발견됨 workspaceSizeBytes는 345,549,173, encryptedSizeBytes는 313,070,842였음 kind는 전체 스냅샷을 뜻하는 baseline, failureCount는 564였으며 파일은 pending/에서 재시도를 기다리고 있었음 전체 저장소는 10GB였지만, node_modules 등 일부 항목을 제외한 345MB는 거의 전부 핵심 지식재산에 해당했음 app.asar에서 재구성한 업로드 경로 로그에 명시적인 업로드 URL이 없어 클라이언트의 app.asar를 역공학 분석해 전송 흐름을 확인함 먼저 클라이언트가 https://zcode.z.ai의 POST /api/v1/snapshot/upload-credential 을 호출해 업로드 자격 증명을 요청함 서버는 snapshot_id, RSA 공개키, max_size, 동적 객체 키(Object Key), OSS 폼 자격 증명과 콜백 정보를 반환함 ...