ZCode 데스크톱 — GLM-5.3 Max, Idle-time task. 에이전트가 저장소에 상주하는 화면

ZCode 새 작업 화면(GLM-5.3 · Max). 구독자용 Idle-time task는 남는 연산으로 백그라운드 작업을 돌리겠다는 안내다. 이번 사건의 쟁점도 채팅창이 아니라, 켜져 있는 동안 저장소를 가져가는 상주 프로세스였다.

김호광 싸이월드 전 대표 / 2026년 9월 21일

1. 디스크 정리를 하다가 발견된 것

사건은 거창한 해킹이 아니라 디스크 정리에서 시작됐다. 2026년 9월 18일 새벽, 개발자 ferstar가 ZCode의 무단 업로드를 고발하는 글을 공개했다. 디스크 공간을 정리하던 그는 ~/.zcode 폴더가 700MB 넘게 차지하고 있다는 사실을 알아챘다. 추적해 보니 .git 전체 이력을 묶어 암호화한 뒤 알리바바 클라우드 OSS로 올리는 워크스페이스 스냅샷 프로세스가 있었다. 로컬 머신에는 복호화 키가 없었다.

ZCode는 중국 즈푸(Zhipu, Z.ai)가 GLM 모델과 함께 내놓은 데스크톱 코딩 에이전트다. 모델 성능이 좋고 코딩 플랜이 저렴해 한국 개발자들 사이에서도 사용이 늘던 도구였다.

한 마디로 Z.ai의 ZCode로 작성된 소스 코드가 알리바바 클라우드 스토리지에 몰래 저장된 것이다.

독립 감사도 뒤따랐다. 한 사용자가 자기 Windows 장비를 읽기 전용으로 포렌식한 결과, 2026년 7월 5일부터 9월 18일까지 26개 워크스페이스에 걸쳐 30건의 스냅샷 매니페스트, 50,617개 파일, 1.77GB 분량이 확인됐다. 파이프라인은 프롬프트를 보낼 때마다 워크스페이스 전체를 캡처했다. 클라이언트에서 AES-256-CTR로 암호화하고 데이터 키를 RSA-OAEP로 감싼 뒤, zcode.z.ai에 업로드 자격증명을 요청해 알리바바 OSS로 전송하는 방식이었다.

2. 기술적으로 무엇이 문제였나?

이 사건은 "AI가 코드를 봤다"는 수준의 이야기가 아니다. PostgreSQL 생태계의 개발자 Vonng(Ruohang Feng)이 자기 Mac에서 재현한 분석은 세 가지를 드러냈다.

첫째, 범위. 그의 스냅샷 한 건에서 9,619개 파일 중 8,323개가 .git 소속이었고, 바이트 기준으로 93.9%를 차지했다. 파일 필터 체인에서 .git 허용 규칙이 모든 제외 규칙보다 먼저 적용됐다. 그래서 키 필터와 1MB 크기 제한이 .git 아래에는 전혀 작동하지 않았다. 과거에 실수로 커밋했다가 git rm이나 filter-repo로 지운 API 키, 인증서, 비밀번호도 .git/objects 안에 그대로 남아 업로드되는 구조다. 작업 트리가 아니라 저장소의 전 역사를 가져간 것이다.

둘째, 키. 암호화 공개키는 서버가 내려줬고, 사용자가 보유한 복호화 키는 발견되지 않았다. 디스크에 쌓인 수백 MB의 암호문은 사용자도, ZCode 클라이언트 자신도 열 수 없었다. 서버만 복호화할 수 있었다. 소유자가 복원할 수 없는 백업은 백업이 아니라 수집이다.

셋째, 스위치. 가장 심각한 대목이다. 설정에는 "Repository Snapshot Indexing"이라는 항목이 있었고, 그의 장비에서는 줄곧 꺼져 있었다. 9월 13~18일 로그에서 이 필드는 1,339번 나타났고 값은 모두 false였다. 그런데 스냅샷 4건이 바로 그 기간에 생성됐다. 클라이언트는 프롬프트마다 서버에 업로드 자격증명을 무조건 요청했고, 서버가 승인하면 수집이 진행됐다. 사용자 컴퓨터에는 이를 거부할 스위치가 없었다. 언제 수집할지는 서버가 결정했다.

UI에 있는 옵트아웃 스위치가 실제 동작과 연결되지 않았다면, 이는 단순 버그를 넘어 사용자를 오인하게 만든 것이다. 법적으로도 이 차이가 결정적이다.

개인정보처리방침과도 맞지 않았다. ZCode 방침은 수집 대상을 사용자가 대화를 통해 제출한 텍스트, 파일, 코드로 설명했다. 백그라운드 스냅샷은 대화를 통해 제출된 것이 아니므로 방침이 설명하는 범위 밖의 행위다.

3. 즈푸의 대응 - 무엇이 충분하고 무엇이 부족한가?

즈푸는 빠르게 움직였다.

  • 중국정보통신연구원(CAICT)의 기술 평가로 zcode-prod 알리바바 OSS 버킷이 "클라우드 제로 데이터(云端零数据)" 상태임을 확인받았다.
  • v3.14.0에서 Repo Wiki 기능을 제거하고 로컬 저장소 스냅샷 생성·업로드 경로를 끊었다.
  • 녹맹과기(NSFOCUS) 검토로 관련 데이터 객체와 버킷 자체의 삭제를 확인받았다.
  • 전체 코드를 GitHub에 오픈소스로 공개하고, 커뮤니티 참여를 확대하겠다고 밝혔다.
  • 코드 데이터를 현재 보관하지 않으며 모델 학습에 사용한 적이 없다고 설명했다.
  • 상시 취약점 신고·보상 제도 운영과 전체 보안 평가 보고서 공개를 예고했다.
  • 전 사용자 대상 주간 할당량 1회 리셋 보상을 발표한 것으로 알려졌다.

사과, 기능 제거, 삭제 확인, 제3자 감사, 오픈소스화로 이어지는 순서는 교과서적인 사고 대응이다. 이 점은 인정해야 한다. 그러나 세 가지 질문은 남는다.

  1. 클라이언트 오픈소스가 서버를 증명하지는 않는다. 이번 사건의 핵심은 수집 여부를 서버가 결정했다는 점이다. 클라이언트 코드를 공개해도 서버의 자격증명 발급 로직, 복호화 키 관리, 접근 로그는 보이지 않는다.
  2. "학습에 쓰지 않았다"와 "아무도 열어보지 않았다"는 다른 주장이다. 버킷 삭제 확인은 현재 상태만 증명한다. 업로드 이후 누가 복호화했고 어디로 복제됐는지는 서버 측 접근 로그로만 답할 수 있다.
  3. 왜 두 달 전의 교훈을 놓쳤나. 바로 아래 사례다.

4. 이런 사건은 처음이 아니다.

xAI Grok Build CLI (2026년 7월) - 가장 직접적인 전례

보안 연구자 cereblab이 트래픽을 캡처해 보니, "OK라고만 답하고 파일은 읽지 마라"는 프롬프트를 줘도 CLI가 저장소 전체를 Git 번들로 묶어 Google Cloud Storage에 올렸다. 번들을 클론하면 에이전트가 읽은 적 없는 파일과 전체 커밋 이력이 복원됐다. "모델 개선" 옵션을 꺼도 효과가 없었다. 이후 xAI는 서버에서 업로드를 끄고 옵트아웃을 추가했으며, 머스크가 기존 업로드 데이터 삭제를 공개 약속한 것으로 전해진다. 스위치가 무력했다는 점까지 ZCode와 같은 패턴이다.

Nx "s1ngularity" 공급망 공격 (2025년 8월) - 공격자가 AI 도구를 무기로 쓰다

주간 다운로드 400만 건의 Nx 빌드 시스템이 뚫렸다. AI 어시스턴트를 데이터 탈취에 이용한 첫 공급망 공격으로 기록됐다. 악성 코드는 Claude, Gemini, Q 같은 AI CLI를 --yolo, --trust-all-tools 같은 위험 플래그로 실행해 권한 확인을 우회했다. GitGuardian 집계로 2,349개의 고유 시크릿이 1,079개 저장소로 유출됐다. 파일 시스템 전체 접근권을 가진 AI 에이전트는 벤더의 의도와 무관하게 유출 파이프라인이 될 수 있다는 것을 보여준 사례다.

DeepSeek (2025년) - 국경을 넘는 이전에 대한 한국 선례

개인정보보호위원회 점검 결과, 딥시크는 국외 이전에 대해 이용자 동의를 받거나 처리방침을 공개하지 않았다. 또한 국내 이용자가 입력한 프롬프트 정보를 바이트댄스 자회사 볼케이노로 넘긴 것으로 드러났다. 개인정보위는 국외 이전의 합법적 근거 마련, 프롬프트 정보 즉시 파기, 한국어 처리방침 공개 등을 시정권고했다.

삼성전자 ChatGPT 사고 (2023년) - 사용자가 스스로 붙여넣은 경우

한 임직원은 설비 계측 관련 소스코드 전체를 ChatGPT에 입력해 해결 방법을 물었다. 다른 임직원은 수율·불량 설비 파악용 프로그램 코드를 넣어 최적화를 요청했다. 삼성은 생성형 AI에 입력된 내용이 외부 서버에 전송·저장되고, 한번 올라간 내용은 회수·삭제할 수 없다며 사내 사용을 제한했다.

흐름

시기 사례 유출 주체
2023 삼성전자 ChatGPT 사람이 직접 붙여넣음
2025 DeepSeek 서비스가 제3자에 이전
2025 Nx s1ngularity 공격자가 AI 도구를 조종
2026 Grok Build / ZCode 도구 자체가 알아서 가져감

유출의 주체가 점점 사람 손을 떠나고 있다.

5. 한국에서 같은 일이 벌어진다면

흔한 오해부터 짚자. "소스코드는 개인정보가 아니니 개인정보보호법과 무관하다"는 생각은 틀렸다. Git 이력에는 모든 커밋의 작성자 이름과 이메일이 들어 있다. 여기에 .env의 고객 DB 접속정보나 테스트 픽스처 속 실제 고객 데이터까지 포함되면 곧바로 개인정보 유출 사건이 된다. 기업 입장에서는 영업비밀 침해와 개인정보 유출이 동시에 걸린다.

구분 근거 내용
손해배상 (입증책임 전환) 개인정보보호법 제39조 ① 정보주체가 청구하면 처리자가 고의·과실 없음을 입증하지 못하는 한 책임을 면할 수 없음
징벌적 손해배상 개인정보보호법 제39조 ③ 고의 또는 중과실로 유출된 경우 손해액의 5배 이내
법정손해배상 개인정보보호법 제39조의2 손해액 입증 없이 300만원 이하 청구 가능
징벌적 과징금 (2026.9.11 시행) 개정 개인정보보호법 반복·중대 위반 시 전체 매출액의 최대 10% (기존 3%). 대상은 3년 내 고의·중과실 반복, 1,000만 명 이상 대규모 피해, 시정명령 불이행으로 인한 유출 등
영업비밀 침해 징벌배상 부정경쟁방지법 (2024.8.21 시행) 한도를 3배에서 5배로 상향. 미국(최대 2배)보다 높고, 5배는 중국과 같은 수준
형사 (영업비밀) 부정경쟁방지법 제18조 국외 유출 시 15년 이하 징역 또는 15억원 이하 벌금 (국내 유출은 10년/5억원)
형사 (정보통신망) 정보통신망법 제48조·제71조 허용된 접근권한을 넘어 정보통신망에 침입하면 5년 이하 징역 또는 5천만원 이하 벌금
저작권 저작권법 제125조의2 소스코드는 프로그램저작물. 법정손해배상은 저작물당 1천만원, 영리 목적 고의 침해는 5천만원 이하
국외이전 개인정보보호법 제28조의8 적법 근거 없이 국외 서버로 이전하면 별도 위반

ZCode 사례에 적용하면 핵심 쟁점은 "고의 또는 중과실"이다. 옵트아웃을 꺼도 수집이 계속됐고 처리방침의 설명 범위를 벗어났다는 사실은 단순 과실을 넘어 중과실을 다툴 수 있는 정황이 된다. 5배 징벌배상의 문이 열리는 지점이다. 또한 한국법상 유출은 전송되어 통제를 벗어난 시점에 이미 성립한다. 사후 삭제는 배상액 산정에서 감경 사유가 될 수 있지만 책임 자체를 없애지는 못한다.

6. 미국에서라면

구분 근거 내용
영업비밀 (연방) DTSA, 18 U.S.C. §1836 고의적·악의적 유용 시 보상액의 최대 2배 징벌적(exemplary) 배상, 변호사 비용 전가 가능
영업비밀 (주법) 각 주 UTSA / 캘리포니아 CUTSA 고의적·악의적 유용 시 보상액의 2배 이내 징벌배상
캘리포니아 소비자 소송 CCPA §1798.150 2025년부터 소비자 1인·사고 1건당 $107~$799 또는 실손해 중 큰 금액. 대규모 집단소송이면 금액이 급증
캘리포니아 행정 제재 CCPA §1798.155 위반 1건당 최대 $2,663, 고의 위반은 최대 $7,988
무단 접근 CFAA, 18 U.S.C. §1030(g) "권한을 초과한 접근"에 대한 민사 청구권
통신 가로채기 Wiretap Act, 18 U.S.C. §2520 법정손해 $10,000 또는 1일 $100 중 큰 금액 + 징벌적 배상
기만적 관행 FTC Act Section 5 작동하지 않는 옵트아웃은 전형적인 기만행위. FTC 동의명령과 장기 감사 의무로 이어질 수 있음
보통법 불법행위 악의가 인정되면 배심원 재량의 징벌적 배상

미국에서 가장 강력한 무기는 금액 조항보다 작동하지 않는 스위치라는 사실 자체다. FTC는 사용자가 거부했는데도 데이터를 가져간 행위를 기만행위로 다뤄 왔다. 집단소송 원고 측은 로그에 찍힌 false 1,339회를 고의의 증거로 내밀 것이다.

주의: 위 법률 내용은 칼럼 목적의 일반 정보이며 법률 자문이 아니다. 실제 사안은 관할, 약관상 준거법·중재 조항, 피해 입증 방식에 따라 결론이 크게 달라지므로 변호사 검토가 필요하다.

7. 개발자와 기업이 지금 해야 할 일

  • ZCode를 썼다면 자격증명을 전부 교체하라. 삭제 발표와 무관하게, Git 이력에 한 번이라도 들어갔던 키는 이미 노출된 것으로 간주해야 한다. ~/.zcode/v2/checkpoints/*/pending/의 암호문을 정리하고, manifests/의 평문 목록에서 .git 포함 여부를 확인하라.
  • AI 에이전트를 채팅창이 아니라 백그라운드 프로세스로 감사하라. 에이전트 데스크톱 클라이언트는 디스크 전체를 읽고 네트워크에 접근할 수 있는 상주 프로세스다.
  • egress 모니터링을 켜라. Little Snitch, LuLu, OpenSnitch 등으로 AI 도구의 외부 통신 대상과 트래픽 양을 확인하라.
  • 기업은 도입 체크리스트를 만들라. 전송 범위가 필요 최소한인가, 복호화 키는 누가 가지는가, 옵트아웃이 클라이언트에서 강제되는가, 데이터 저장 리전은 어디인가.
  • 민감 저장소는 격리하라. 핵심 IP는 로컬 모델, VPC 내부 배포, 또는 제로 데이터 보존 계약이 있는 엔터프라이즈 플랜에서만 다루는 투트랙이 현실적이다.

8. 맺으며, 신뢰는 스위치에서 시작한다

나는 늘 "LLM은 엑셀이지 오라클이 아니다"라고 말해 왔다. 도구는 도구답게 써야 한다는 뜻이다. 이번 사건은 그 반대편에서 오는 경고다. 우리는 AI 에이전트를 엑셀처럼 내 PC 안에서만 도는 도구로 여겼다. 실제로는 내 저장소 전체를 들고 나갈 수 있는 백도어 원격 프로세스였다.

AI 도구가 나를 존중하는지 판단하려면 세 가지만 물으면 된다. 필요한 만큼만 가져가는가? 키는 누구 손에 있는가? 권한을 투명히 설정할 수 있고 끌 수 있는가? ZCode는 세 질문 모두에서 실패했고, Grok은 두 달 먼저 같은 실패를 했다. 한국은 이달부터 매출 10% 과징금 시대에 들어섰다. 다음 사건은 사과문과 할당량 리셋으로 끝나지 않을 가능성이 크다.

레퍼런스

ZCode 사건

유사 사례

한국 법제

미국 법제