먼저 소식부터 전하면, Z.ai가 자사의 AI 코딩 도구 ZCode 전체 스택을 오픈소스로 공개했습니다(공식 저장소).
Agent CLI 하나만 따로 떼어 공개한 정도가 아닙니다. Desktop 앱과 Web 화면, 백엔드 Server, Agent CLI와 런타임까지 한 저장소에 들어갔습니다. 라이선스도 Apache-2.0이라 코드를 살펴보고 고쳐서 다시 배포할 수 있습니다.
그런데 이번 발표는 공개 범위보다 공개 시점이 더 눈에 들어옵니다. 불과 사흘 전, ZCode가 사용자의 작업공간과 Git 이력을 외부 저장소로 올릴 수 있다는 보안·프라이버시 논란이 불거졌기 때문입니다.
최근 AI 코딩 도구는 터미널 속 챗봇을 넘어, 저장소를 읽고 파일을 고치며 명령을 실행하는 데스크톱 하네스로 넓어지는 흐름입니다. 편리한 만큼 권한도 큽니다. 이제는 “무엇을 할 수 있나”뿐 아니라 실제로 어떤 파일을 읽고, 어디로 보내며, 어떤 권한으로 실행하는지까지 함께 봐야 합니다.
이런 하네스가 모델과 도구 사이에서 어떤 역할을 하는지는 GPT-6 Astra 컴퓨터 사용 후기에서도 따로 다뤘습니다.
모든 제품이 반드시 소스 전체를 공개해야 한다는 뜻은 아닙니다. 다만 권한이 넓어질수록 소스 공개, 독립 보안 점검, 명확한 동의 화면, 확인 가능한 네트워크 기록처럼 사용자가 행동을 검증할 수단도 강해져야 합니다. 이번 ZCode 공개가 눈에 띄는 이유가 여기에 있습니다.
왜 갑자기 이런 결정을 내렸을까
관련 원문은 최초 역분석 글, 회사 대응을 전한 9월 18일 보도, Z.ai 피드백 이슈 #707, 공식 공개 공지, Reddit 공개 토론에서 직접 볼 수 있습니다.
9월 18일, 한 개발자가 ZCode 3.12.3을 역분석한 결과를 공개했습니다. ZCode가 로그인 상태에서 작업공간과 .git 이력을 스냅샷으로 만들고, 이를 암호화해 Alibaba Cloud OSS로 올리는 경로가 있다는 내용이었습니다(분석 원문).
.git·LFS·reflog 등을 묶어 Alibaba Cloud OSS로 보낸다는 작성자의 핵심 주장이 함께 보입니다. 원문 열기 그림 크게 보기Z.ai도 Repo Wiki를 클라우드에서 만들 때 저장소 데이터가 업로드될 수 있었다는 점은 인정했습니다. 이어 3.14.0에서 Repo Wiki와 스냅샷 생성·업로드 경로를 제거했고, 저장 버킷도 삭제했다고 밝혔습니다.
그리고 9월 21일, ZCode의 전체 코드를 공개했습니다. 공식적인 이유는 누구나 코드를 검증할 수 있게 열어 두고 더 투명하게 운영하겠다는 것입니다(공식 공지).
제 눈에는 두 가지 목적이 함께 보입니다. 우선 “문제를 고쳤으니 믿어달라”가 아니라 “코드를 열었으니 직접 확인해달라”는 신뢰 회복입니다. 동시에 몇 달 전부터 GLM용 코딩 하네스로 키워온 ZCode를 공개 플랫폼으로 넓히려는 선택이기도 합니다.
보안 논란을 피해서 지나가기보다 제품 전체를 열어 정면으로 돌파한 셈이죠.
알리바바 클라우드에는 왜, 무엇을 올렸나
여기서는 회사 설명과 독립 분석을 분리해서 봐야 합니다. 회사는 코드 저장소 인덱싱이 로컬 검색, 세션 체크포인트 복구, Repo Wiki에 쓰였고, Repo Wiki 페이지를 클라우드에서 만들 때 저장소 데이터 업로드가 일어날 수 있었다고 설명했습니다. Wiki 생성 뒤에는 데이터를 즉시 파기하고 저장하지 않았다는 입장입니다.
반면 ZCode 3.12.3을 분석한 개발자는 클라이언트가 작업공간을 tar.gz로 묶고 암호화한 뒤, Alibaba Cloud OSS로 직접 보내는 경로를 확인했습니다. 핵심을 표로 정리하면 이렇습니다.
| 궁금한 점 | 확인된 내용 | 근거와 한계 |
|---|---|---|
| 왜 올렸나 | 회사는 Repo Wiki의 클라우드 페이지 생성과 저장소 인덱싱을 이유로 들었습니다. 세션 체크포인트 복구도 함께 언급했습니다. | 회사 설명입니다. 공개된 현재 소스의 체크포인트는 로컬 Git 기반이라, 과거 전체 스냅샷 업로드가 왜 필요했는지는 여전히 논쟁거리입니다. |
| 무엇을 묶었나 | 분석된 한 작업공간의 파일 목록(manifest)에는 소스·문서·설정과 함께 .git/objects, .git/lfs, .git/logs가 들어 있었습니다. 42,411개 파일 중 용량 기준 86.6%가 .git 관련 데이터였습니다. | 특정 사용자와 3.12.3에서 확인된 사례입니다. 모든 사용자에게 같은 범위가 실제 전송됐다고 일반화할 수는 없습니다. |
| Alibaba OSS의 역할 | ZCode 서버가 업로드용 OSS 자격 정보, object key, RSA 공개키를 내려주면 클라이언트가 로컬에서 AES-256-CTR로 암호화해 OSS에 직접 전송하고, OSS가 ZCode 서버에 완료 callback을 보내는 구조였습니다. | 확인된 역할은 객체 저장소와 전송 경로입니다. Alibaba가 코드를 분석했다는 증거는 아닙니다. |
| 실제로 전송됐나 | 최초 제보자의 313MB 암호화 스냅샷은 564회 실패 후 로컬에 남았고, 538개 파일의 작은 공개 저장소 스냅샷 약 15KB는 서버가 접수한 상태로 확인됐습니다. 공식 피드백 저장소의 다른 이용자도 .git/* 2,000여 개가 든 accepted 상태 파일 목록을 제보했습니다. | 독립 분석과 이용자 제보입니다. 전체 영향 사용자 수와 서버 측 이용·복호화 여부는 공개 자료만으로 확인되지 않습니다. |
왜 하필 Alibaba Cloud였는지, 비용·지역·기존 계약 같은 사업적 선택 이유는 공개 자료에서 찾지 못했습니다. 확인되는 것은 OSS가 암호화된 스냅샷을 받는 저장 인프라였고, 암호화용 RSA 공개키는 ZCode 서버가 내려줬으며 클라이언트에는 대응하는 개인키가 없었다는 기술적 구조입니다(독립 분석, Z.ai 피드백 이슈 #707).
.git 전체 포함, lastAcceptedManifestHash, OSS 수신 흔적이라는 제보 내용이 보입니다. 이 화면은 이용자 제보가 실제로 접수됐다는 근거이며, 회사가 내용을 확인했다는 뜻은 아닙니다. 이슈 #707 열기 그림 크게 보기또 하나의 쟁점은 고지 범위입니다. 현재 ZCode 개인정보 처리방침은 대화로 제출한 텍스트·파일·코드 수집과 기기 저장공간의 파일 접근·전송 권한을 설명하지만, 작업공간 전체와 .git 이력을 스냅샷으로 묶는 동작을 구체적으로 적지는 않습니다. 그래서 이 사건은 “클라우드를 썼느냐”보다 사용자가 예상한 범위와 실제 앱의 행동이 같았느냐가 핵심입니다.
자세히 보면 어디까지 공개했나
공식 README에는 클라이언트와 백엔드 서비스, 공유 UI, Agent CLI와 런타임 소스가 모두 포함됐다고 적혀 있습니다. 실제 저장소의 주요 경로를 간단히 나누면 이렇습니다.
| 영역 | 들어 있는 것 | 경로 |
|---|---|---|
| Desktop | Electron 앱과 패키징 소스 | packages/desktop |
| Web | 브라우저 UI와 OAuth·공유 화면 | packages/web |
| Server | HTTP·WebSocket 서비스와 원격 연결 | packages/server |
| Agent | CLI·TUI·런타임·도구 | apps/zcode-cli |
화면에서 버튼을 눌렀을 때 어떤 요청이 만들어지고, 서버를 거쳐 Agent가 어떤 도구를 실행하는지 한 저장소 안에서 따라갈 수 있다는 뜻입니다. 보안 연구자는 네트워크 경로와 파일 처리 코드를 볼 수 있고, 개발자는 인증이나 endpoint 기본값을 직접 바꿔볼 수 있습니다.
다만 공개 이력은 아주 짧습니다. 빈 Initial commit 뒤에 feat: open source 커밋 하나로 6,973개 파일과 1,033,262줄이 한꺼번에 올라왔습니다(커밋 목록). 현재 코드는 볼 수 있지만, 문제가 있던 버전에서 무엇을 빼고 고쳤는지는 Git 이력으로 비교할 수 없습니다.
그리고 ‘전체 스택 공개’가 ‘모든 것이 독립 실행된다’는 뜻은 아닙니다. 모델 가중치는 없고, Z.ai를 비롯한 외부 모델 API와 OAuth·제품 API·CDN 주소도 설정에 남아 있습니다. 공식 기능 전체를 외부 서비스 없이 그대로 자체 호스팅하는 패키지라고 보기는 어렵습니다.
그래서 무엇이 달라지나
사용자 입장에서 가장 큰 변화는 현재 버전의 코드를 직접 확인할 수 있다는 점입니다. 어떤 파일을 읽고 어디로 요청을 보내는지 검색할 수 있고, 이상한 동작을 발견하면 구체적인 코드를 근거로 문제를 제기할 수 있습니다. 공개했다고 자동으로 안전해지는 건 아니지만, 적어도 밖에서 검증할 문은 열렸습니다.
별도 zai-org/feedback 저장소에는 버그 제보, 로드맵, 진행 상태와 비공개 취약점 신고 경로도 마련돼 있습니다. 이제 신뢰 회복은 발표문보다 다음 코드 변경과 이슈 대응으로 확인할 수 있게 됐습니다.
커뮤니티 반응은 어땠을까
Reddit의 공개 소식 글에는 신뢰 회복에 필요한 한 걸음이고 좋은 움직임이라는 긍정적인 반응이 나왔습니다. 반대로 과거에 지적된 업로드 경로가 정말 제거됐는지 확인해야 한다는 회의적인 의견도 보였습니다(관련 게시물).
현재 공개 소스에서는 문제로 지목된 Repo Wiki와 저장소 전체 업로드 경로를 찾지 못했습니다. 회사의 제거 발표와 어긋나지는 않습니다. 하지만 지금 코드에 없다는 사실만으로 과거에 올라간 데이터의 처리와 삭제까지 확인할 수는 없습니다. Z.ai가 인용한 CAICT와 NSFOCUS의 전체 점검 보고서도 이번 조사에서는 찾지 못했습니다.
그러니 오픈소스 공개는 좋은 신호지만, 보안 논란의 종결 선언으로 보기에는 아직 이릅니다.
직접 해보시려면
공식 문서 기준으로는 Git과 Node.js 24.14.0, pnpm 10.33.2가 필요합니다. 이 글에서는 실제 설치와 빌드 성공까지 시험하지 않았으므로, 아래는 사용기가 아니라 공식 개발 절차를 간단히 옮긴 것입니다.
| 순서 | 명령 | 하는 일 |
|---|---|---|
| 1 | git clone https://github.com/zai-org/ZCode.git | 저장소 받기 |
| 2 | pnpm bootstrap | 의존성·로컬 런타임 준비와 workspace 빌드 |
| 3 | pnpm dev:desktop | Desktop 개발 모드 실행 |
| 4 | pnpm dev:web | Web 개발 모드 실행 |
| 선택 | pnpm --filter @zcode/cli dev | Agent CLI를 소스에서 실행 |
통합 배포판은 pnpm build:zcode로 만들 수 있습니다. 다만 다운로드 주소인 ZCODE_DIST_BASE_URL을 따로 지정해야 하고, 결과물을 올릴 서버와 설치 경로도 직접 준비해야 합니다. Desktop 앱을 외부에 배포하려면 macOS 서명·공증 같은 플랫폼 작업도 별도입니다.
코드 구경이 목적이라면 먼저 config/provider/zcode-builtin.json, .env.example, Server의 HTTP 진입점, Agent 도구 구성을 살펴보는 편이 좋습니다. 어떤 외부 주소와 권한을 쓰는지 여기서 가장 빨리 보입니다.
주의할 점은 이렇습니다
| 확인할 것 | 현재 기본값·특징 | 권장 조치 |
|---|---|---|
| Workspace 권한 | Agent가 실행한 OS 계정 권한으로 파일·프로세스·네트워크에 접근 | 전용 계정과 필요한 디렉터리만 사용 |
| Web 접근 | 127.0.0.1은 토큰 없음, 비로컬 바인딩은 기본 토큰 생성 | 외부 공개 시 토큰·TLS·네트워크 제한 적용 |
| 자동 실행 | CLI의 비대화형 --prompt는 별도 지정이 없으면 yolo 모드 | 실제 서비스 저장소에서는 실행 모드와 허용 도구 확인 |
| 외부 서비스 | 모델 API·OAuth·제품 API·CDN 주소가 설정에 포함 | API key 저장 위치와 전송되는 데이터를 확인 |
| 재배포 | Apache-2.0 외에 제3자 코드·폰트·아이콘 고지가 존재 | NOTICE와 제3자 라이선스를 함께 검토 |
특히 Agent에는 기본 OS 샌드박스가 제공되지 않는다고 NOTICE.md에 명시돼 있습니다. 개인 테스트 폴더와 실제 서비스 코드, 배포 자격 증명이 있는 환경을 분리하는 편이 안전합니다.
반가운 공개인 건 맞습니다. 하지만 앞으로 데스크톱 하네스를 고를 때는 기능표만 봐서는 부족합니다. 실제 파일·네트워크 행동, 권한 경계, 외부 전송의 동의와 삭제 경로, 그리고 이를 검증할 수 있는 공개성까지 제품의 일부로 봐야 합니다.
ZCode의 다음 평가는 발표문보다 다음 커밋과 보안 보고서, 그리고 커뮤니티 이슈에 답하는 방식에서 갈릴 것입니다.