Zhipu, AI 코딩 도구 ZCode 전면 오픈소스화…남은 세 가지 질문

9월 18일, 개발자 ferstar는 MacBook 디스크를 정리하다가 ~/.zcode 디렉터리가 상당한 용량을 차지하고 있다는 사실을 발견했다. 클라이언트를 리버스 엔지니어링하고 네트워크 요청을 분석한 끝에 그는 Zhipu의 AI 코딩 도구 ZCode가 로컬 워크스페이스 스냅샷을 생성하며, 그 안에 현재 코드 파일뿐 아니라 .git 히스토리, Git LFS 캐시, reflog까지 들어 있다는 것을 밝혀냈다. 게다가 이 암호화된 스냅샷을 알리바바 클라우드 OSS로 업로드하는 경로도 존재했다. ferstar는 전체 조사 과정과 증거 체인을 개인 블로그에 공개했다.

그가 분석한 특정 스냅샷 하나는 약 313MB, 42,411개 파일 규모였고 그중 약 87%가 .git 디렉터리에서 나왔다. 상태 파일에는 이 스냅샷이 564회 업로드를 시도한 기록이 남아 있었다. 다만 이 313MB 스냅샷은 크기 제한을 넘겨 로컬 pending 상태에 머물렀고 실제로 업로드되지는 않았다. ferstar는 이어 더 작은 공개 저장소로 테스트했는데, 538개 파일이 압축·암호화를 거쳐 약 15KB가 되었고 이번에는 서버가 실제로 수신했다.

암호화 방식도 드러났다. 스냅샷은 AES-256-CTR로 암호화되고, 그 키는 다시 서버가 제공한 RSA 공개키로 캡슐화되며 대응하는 개인키는 클라우드가 쥐고 있다. ferstar가 역추적한 흐름에 따르면 클라이언트는 먼저 ZCode 서버에서 snapshot ID, RSA 공개키, OSS 업로드 자격증명을 받아온다. 로컬에서 패키징과 암호화를 마친 뒤 암호문을 알리바바 클라우드 OSS로 직접 올린다. ZCode 서버를 거치지 않는 이 직접 업로드 구조 때문에 감사와 정책 통제가 어렵다는 지적이 나왔다.

Zhipu는 이 문제가 ZCode의 코드베이스 인덱싱 기능에서 비롯됐다고 설명했다. 이 기능은 로컬 인덱싱, 히스토리 버전 세션 체크포인트, 버전 롤백, Repo Wiki 등을 지원하는데, Repo Wiki를 클라우드에서 생성하는 과정에서 저장소 데이터 업로드가 발생할 수 있다는 것이다. Zhipu는 이 기능이 초기에는 기본 활성화 상태였고 관련 데이터는 Wiki 생성 후 파기되며 모델 학습에는 쓰이지 않았다고 밝히고 사용자에게 사과했다.

사흘 뒤 Zhipu는 한 발 더 나아갔다. ZCode 전체를 오픈소스로 공개한 것이다. 현재 ZCode 소스 코드는 Apache 2.0 라이선스로 공개되어 있으며 Desktop, Web, Backend, Agent CLI, Agent Runtime 등 주요 컴포넌트를 포함한다. 동시에 ZCode v3.14.0은 Repo Wiki를 삭제하고 로컬 저장소 스냅샷 생성과 업로드 경로를 끊었다. Zhipu는 중국정보통신연구원(CAICT)과 NSFOCUS에 보안 검증을 의뢰했고, CAICT는 해당 OSS 버킷이 제로 데이터 상태임을, NSFOCUS는 관련 데이터 객체와 버킷이 삭제됐음을 확인했다고 전했다. 장기적인 취약점 대응 및 포상 제도도 약속했다.

사과, 수정, 데이터 삭제, 제3자 검증, 그리고 전격 오픈소스화까지 며칠 만에 연속으로 이뤄진 대응이다. 하지만 전체 코드베이스를 읽고 Shell을 실행하며 MCP와 플러그인을 연결하고 기업 자격증명까지 건드릴 수 있는 Coding Agent에게 오픈소스가 사건의 끝은 아니다. 최소한 세 가지 질문이 남는다. 오늘 공개된 ZCode에서 여전히 어떤 데이터가 로컬을 떠나는가. 왜 오픈소스 저장소에는 사고 이전의 Git 히스토리가 없는가. 데이터 경계 논란을 겪은 Coding Agent에서 '코드 오픈소스 + 제3자 보안 검증'이 신뢰를 얼마나 되돌릴 수 있는가.

Repo Wiki는 사라졌지만 ZCode는 로컬에서만 움직이는 프로그램이 아니다. Zhipu는 오픈소스 저장소에 상당히 상세한 NOTICE 파일을 두고 ZCode에 남아 있는 외부 상호작용 면을 나열했다. 파일, Git, Terminal, Shell, Node REPL은 호스트 운영체제 계정 권한 범위 안에서 파일을 읽고 쓰고 프로세스를 띄우고 네트워크에 접근할 수 있다. 플러그인은 자동 실행 Hook, 로컬 프로그램, 원격 도구를 끌어올 수 있다. MCP는 설정에 담긴 명령, 환경변수, 인증 헤더, OAuth로 외부 서비스에 연결한다. 내장 브라우저는 웹페이지에 접근하고 페이지를 읽고 스크린샷을 찍고 파일을 올리고 내려받는다. 원격 Workspace, SSH, 웹 서비스는 각자 나름의 네트워크와 권한 경계를 가진다.

NOTICE는 또 현재 공유 Agent Runtime이 기본적으로 운영체제 수준 샌드박스를 제공하지 않는다고 경고한다. 독립 CLI에서 --prompt로 비대화형 실행을 하면서 mode를 지정하지 않으면 yolo 모드로 들어가는데, 이 모드에서는 일반 도구 작업이 매번 확인을 거치지 않고 실행될 수 있다.

Repo Wiki 사건에서 가장 눈에 띈 것은 워크스페이스 스냅샷 업로드였기 때문에 초기 논의는 대부분 코드베이스 업로드에 집중됐다. 그러나 Coding Agent가 일하는 방식을 놓고 보면 데이터 경계는 훨씬 복잡하다. 모델 API는 컨텍스트를 가져가야 하고, MCP 서버는 파일과 자격증명에 닿을 수 있으며, 플러그인과 Hook은 도구 인자와 반환값을 읽을 수 있다. Browser Agent는 로그인 세션에 접촉할 수 있고 Shell은 개발자 머신의 다른 디렉터리에 접근할 수 있다. Git, 패키지 관리자, 프로젝트의 lifecycle script도 Agent 실행 체인에 들어올 수 있다.

따라서 Coding Agent의 데이터 처리를 판단할 때 '저장소를 업로드하는가'만 확인하는 것으로는 부족하다. 어떤 데이터가 로컬에만 머무는지, 무엇이 모델 컨텍스트로 들어가는지, 무엇이 Zhipu 자체 서버로 가는지, 무엇이 제3자 모델로 넘어가는지, MCP와 플러그인과 브라우저가 각각 어떤 데이터를 얻는지, 어떤 행동에 사용자 확인이 필요한지, 데이터는 얼마나 보관되는지, 서버 측에서 누가 복호화와 접근 권한을 갖는지를 함께 알아야 한다. ZCode가 오픈소스가 되면서 커뮤니티가 소스를 따라 이 데이터 흐름을 항목별로 점검할 기회는 생겼지만, 현재 공개된 정보만으로 완전한 데이터 흐름도를 그리기는 어렵다.

오픈소스 저장소의 Git 히스토리 문제도 남는다. ferstar가 공개 저장소의 이력을 확인한 결과 빈 initial commit 하나와 feat: open source라는 커밋 하나가 전부였다. 후자는 약 6,973개 파일, 103만 줄을 한 번에 추가했다. 외부가 손에 넣은 것은 개선이 끝난 뒤의 코드 스냅샷인 셈이다. Repo Wiki와 repoSnapshot, 업로드 로직이 들어 있던 이전 버전은 오픈소스 저장소에 함께 오지 않았다.

이 때문에 외부 개발자가 이번 사건을 되짚기가 어려워졌다. 업로드 경로가 언제 처음 들어왔는지, 애초에 어떤 기능을 위해 만들어졌는지, 어떤 수정을 거쳤는지, 기본 활성화가 어느 제품 결정에 해당하는지, 어떤 정식 버전에 이 코드가 포함됐는지, 삭제할 때 구체적으로 무엇이 바뀌었는지는 원래 Git 히스토리와 버전 diff로 단서를 얻을 수 있는 것들이었다. 물론 100만 줄이 넘는 현재 코드를 공개한 것 자체는 가치가 있다. 외부 개발자는 ZCode의 현 구현을 검토하고 Apache 2.0 라이선스에 따라 직접 빌드하고 수정하고 배포할 수 있다. 다만 오픈소스가 보안 사고 이후 신뢰 회복의 역할까지 맡는다면 코드 이력 역시 중요한 보안 증거가 된다.

소프트웨어 보안 사고 조사에서는 흔히 출처 추적이 필요하다. 어떤 기능이 어디서 왔고 언제 코드에 들어왔고 어떻게 진화했으며 수정이 정확히 무엇을 바꿨는지를 따라가는 작업이다. 개선 후 스냅샷만 공개하면 커뮤니티는 ZCode에 지금 그 코드가 남아 있는지 없는지는 확인할 수 있지만, 사고 당시 코드가 어떤 상태였는지에 대해서는 얻을 수 있는 정보가 제한된다.

ferstar는 오픈소스 버전을 추가로 확인한 뒤 체크포인트 메커니즘이 클라우드 저장소 스냅샷이 아니라 로컬 Git diff 중심이라고 판단했다. 그가 소스를 확인한 바로는 현재 체크포인트의 핵심 구현은 로컬 Git CLI를 호출해 git diff --name-status와 git diff --numstat로 변경을 계산하는 것이며 관련 메타데이터는 로컬 ~/.zcode/checkpoints/에 저장된다. 사고 이전 코드가 공개 Git 히스토리에 들어오지 않았기 때문에 외부 연구자가 버전 진화 측면에서 이 기능들의 과거 관계를 계속 대조하기는 당분간 어렵다.

데이터 쪽에도 비슷한 문제가 있다. CAICT는 검사 시점에 OSS 버킷이 제로 데이터 상태였음을, NSFOCUS는 데이터 객체와 버킷이 삭제됐음을 확인했다. 이 검증들은 검사가 이뤄진 시점의 데이터 상태를 설명할 뿐이다. 과거에 성공적으로 업로드된 저장소 스냅샷이 몇 건이었는지, 몇 명의 사용자가 관련됐는지, 객체가 평균 얼마나 보관됐는지, 서버 측 어떤 시스템이나 인원이 복호화와 접근 권한을 가졌는지, 완전한 access log가 있는지, 삭제 범위에 백업과 다른 사본이 포함됐는지는 더 많은 정보가 있어야 복원할 수 있다. '현재 상태 검증'과 '과거 사건 포렌식'은 이렇게 별개로 다뤄야 할 일이 된다.

Zhipu가 택한 경로는 상징적이다. 논란이 일자 관련 기능을 닫고, 클라우드 데이터를 지우고, 제3자 기관에 개선 결과 검증을 맡기고, 마지막으로 제품 소스를 공개해 커뮤니티가 계속 검사하게 했다. 각각 실질적인 효과가 있다. 다만 이 방식을 Coding Agent 데이터 보안 사고 대응 프레임에 놓으면 핵심 질문이 하나 더 남는다. 외부가 어디까지 독립적으로 검증할 수 있는가.

현재까지 Zhipu가 공개한 것은 CAICT와 NSFOCUS 검증 결론의 요약이며 완전한 보안 평가 보고서는 추후 공개하겠다고 밝힌 상태다. 지금 정보로 확인할 수 있는 것은 개선된 버전에서 관련 업로드 경로가 제거됐고 해당 OSS 버킷이 검증 시점에 제로 데이터 상태였다는 정도다. 제3자 검증이 어디까지 다뤘는지는 아직 공개된 정보가 제한적이다. 검증 대상이 v3.14.0 현재 코드만인지 사고 당시 버전도 포함인지, 서버 코드와 OSS audit log를 확인했는지, 암호화 개인키의 수명주기를 대조했는지, 과거 업로드 데이터 규모를 복원할 수 있는지, 백업과 다른 사본이 검증 범위에 들어가는지가 검증 결론의 적용 범위를 좌우한다.

보안 사고에서 '이미 고쳤다'는 하나의 층위일 뿐이다. 외부는 무슨 일이 있었고 영향 범위가 얼마나 컸으며 관련 데이터가 다른 사본으로 남았는지도 알아야 한다. 그래서 보안 감사 보고서에서는 검증 범위가 최종 결론만큼 중요하다. 오픈소스도 마찬가지다. 제조사가 오픈소스로 장기 신뢰를 쌓으려 한다면 현재 소스 공개에 그치지 않고 완전한 Git 히스토리 보존, 공개 Security Advisory 운영, 취약점 신고 채널 개방, 주요 릴리스의 재현 가능 빌드 제공, 버전별 데이터 흐름과 권한 변화 공개까지 나아갈 수 있다. 그렇게 해야 외부가 제조사 선언과 제3자 결론 요약에만 의존하지 않고 수정이 끝났는지 스스로 대조할 조건이 생긴다.

이것은 Coding Agent에서 특히 중요하다. Coding Agent가 가진 권한은 이미 전통적인 IDE를 뚜렷하게 넘어선다. 소스 코드, Shell, 브라우저, GitHub, MCP, 플러그인, 클라우드 서비스, 각종 자격증명이 모두 하나의 Agent 실행 체인에 들어올 수 있다.

ZCode는 고립된 사례가 아니다. 거의 같은 시기 보안 기업 AIR Security가 Claude Code, OpenAI Codex, GitHub Copilot, Gemini CLI에 영향을 주는 공급망 취약점을 공개하고 Plugin4Shell이라는 이름을 붙였다. 사용자가 설치한 플러그인이 검토된 버전인지 보장하기 위해 시스템은 보통 플러그인을 특정 Git commit SHA에 고정한다. 이론적으로 40자리 commit hash는 하나의 코드에 유일하게 대응해야 한다. 그런데 AIR Security 연구원들은 이들 Coding Agent가 checkout 이후 최종 작업 디렉터리의 코드가 실제로 그 commit에 대응하는지 다시 검증하지 않는다는 점을 찾아냈다. 공격자가 플러그인 저장소를 통제하면 Git reference resolution 문제를 악용해 Agent가 표면적으로는 그 SHA를 checkout했는데 최종 작업 디렉터리에는 공격자가 통제하는 코드가 들어가게 만들 수 있다. 플러그인 백그라운드 자동 업그레이드를 지원하는 환경에서는 사용자가 다시 확인하지 않아도 공격 체인이 발동할 수 있다.

AIR Security가 공개한 취약점 공개 및 수정 타임라인에 따르면 Claude Code는 2.1.179에서, Codex는 0.146.0에서 수정됐다. 9월 17일 연구가 공개된 시점에 GitHub Copilot은 아직 패치를 내놓지 않았다. Google은 Gemini CLI가 폐기됐다며 수정하지 않고 해당 공격 경로의 영향을 받지 않는 Antigravity로 이전할 것을 권고했다. AIR Security는 2026년 5월 네 제품에 대해 동작하는 PoC를 완성했고 6월 네 제조사에 조율된 공개를 진행했다고 밝혔다. 현재 공개 자료는 취약점과 공격 체인이 재현 가능하다는 것을 주로 증명하며, 이 취약점이 대규모 실제 공격에 쓰였다는 증거는 아직 없다.

Plugin4Shell과 ZCode는 성격이 다른 문제다. 하나는 데이터 업로드, 다른 하나는 플러그인 공급망이다. 그러나 둘 다 모델 바깥의 Agent 실행 체인에서 벌어진다. 과거 AI 코딩 보안 논의는 모델이 취약한 코드를 생성하는지, Prompt Injection이 Agent를 잘못된 조작으로 유도하는지에 더 집중했다. 지금은 고려해야 할 컴포넌트가 훨씬 많아졌다. Harness, Git, Plugin, MCP, Hook, Browser, Shell, Credential, Workspace, Cloud Storage가 모두 보안 경계의 일부가 될 수 있다.

Coding Agent는 권한이 매우 높은 자리에 있다. 프로젝트를 이해하려면 소스를 읽어야 하고, 테스트하려면 Shell을 돌려야 하고, PR을 올리려면 GitHub에 접근해야 하며, 작업을 끝내려면 패키지 레지스트리와 클라우드 서비스, 나아가 프로덕션 자격증명까지 필요할 수 있다. 이런 환경에서는 평범한 플러그인 취약점 하나의 영향도 증폭된다. Plugin4Shell의 위험은 악성 플러그인이 Agent 실행 체인에 들어가면 개발자가 이미 Agent에 위임한 프라이빗 코드베이스, SSH 키, API 토큰, 클라우드 자격증명, 내부 서비스에까지 닿을 수 있다는 데 있다.

이렇게 보면 ZCode와 Plugin4Shell은 Coding Agent 보안 경계의 양 끝을 각각 드러낸다. 한쪽 끝은 Agent가 어떤 데이터를 밖으로 내보낼 수 있는가이고, 다른 쪽 끝은 누가 Agent 실행 체인에 들어와 이미 부여된 권한을 상속할 수 있는가다. 두 문제는 결국 같은 질문으로 모인다. Coding Agent가 점점 더 많은 도구와 권한을 얻을수록, 그를 둘러싼 보안 설계는 모델만 들여다봐서는 안 된다.

Zhipu는 며칠 안에 Repo Wiki 업로드 경로를 닫고 관련 OSS 버킷을 삭제하고 제3자 기관 검증을 도입했으며 마지막으로 ZCode를 Apache 2.0으로 공개했다. 적어도 폐쇄형 클라이언트 안에서 벌어진 논쟁에 커뮤니티가 계속 검사할 수 있는 경로가 하나 생긴 것은 사실이다.

그러나 아직 완전히 채워지지 않은 정보가 몇 가지 있다. Zhipu가 약속한 완전한 제3자 보안 평가 보고서는 아직 공개되지 않았고, 사고 당시 코드와 완전한 버전 diff도 오픈소스 저장소에 들어오지 않았다. 과거 업로드 데이터의 규모, 접근 기록, 서버 처리 체인 역시 더 완전한 공개가 부족하다. 이번 사건 이후 ZCode가 지속 가능한 데이터 흐름과 권한, 플러그인 보안 메커니즘을 갖출지는 앞으로의 제품 업데이트가 답할 문제다.

이 질문들은 ZCode에만 국한되지 않는다. Coding Agent는 코드 작성을 돕는 도구에서 프로젝트 전체를 읽고 명령을 실행하고 네트워크에 접근하고 외부 시스템에 연결해 개발자를 대신해 작업을 완료하는 소프트웨어로 옮겨가고 있다. 능력이 커지는 만큼 IDE, Shell, 브라우저, Git, 클라우드 서비스, 플러그인 시스템에 흩어져 있던 권한이 하나의 Agent에 집중되기 시작했다. 모든 Coding Agent 제조사가 마주하는 질문은 이렇다. 사용자가 전체 코드베이스와 점점 더 많은 시스템 권한을 Agent에 넘긴 뒤, 제조사는 그 권한이 남용되지 않았다는 것을 무엇으로 증명할 것인가. ZCode의 오픈소스는 그 질문에 대한 하나의 답이다. 다만 그 답이 더 설득력을 얻으려면 오픈소스 이후 얼마나 추적 가능하고 감사 가능하며 외부가 독립적으로 검증할 수 있는 것을 남기는지에 달려 있다.