먼저 결론입니다. 「암호화됨」은 묶인 바이트가 워크스페이스 평문이 아니라는 뜻입니다. 복호화 권한이 사용자에게 있다는 뜻도, 클라우드가 내용을 못 읽는다는 뜻도 아닙니다. 봉투 암호화에서는 대칭키를 서버가 내려 준 공개키로 한 겹 더 감싸고, 개인키는 클라우드에 둡니다. 설계 목표는 클라우드가 열 수 있게 하는 쪽입니다. 그 자리에서 대조할 수 있는 것은 세 가지입니다. 이 암호문을 직접 열 수 있는지, Network에 워크스페이스 평문이 있는지, 화면 스위치를 끈 뒤에도 새 전송 대기 묶음이 생기는지. 「이 기기에서 AES를 했다」를 「나만 복호화한다」로 읽지 마세요.
검색 의도를 한 문장으로 먼저 답하기
전송 구간 암호화와 「키를 내가 가진다」는 같은 층이 아닙니다. 클라이언트는 이 기기에서 AES로 워크스페이스를 암호문으로 만든 뒤 객체 저장소에 올릴 수 있습니다. 키를 감싼 공개키가 서버에서 오고, 개인키가 이 컴퓨터에 들어온 적이 없다면, 그 파일은 복구용 백업이 아닙니다. 클라우드만 뜯을 수 있는 봉투입니다. 경로를 엿보는 쪽은 평문을 못 보고, 개인키를 가진 서버는 봅니다.
이 글은 「클라이언트가 워크스페이스를 암호화해 올린다」는 소식을 보고, 「디스크에 암호문이 있다」와 「영지식」을 나누고 싶은 사람, 그리고 저장소나 키를 동료에게 넘기되 복호화 권한을 제작사에 맡기고 싶지 않은 개발자를 위한 것입니다. 제작사 공지를 대신하지 않고, 특정 편집기의 삭제 안내도 아닙니다. 가져갈 것은 봉투 암호화가 키를 누구 손에 두는지, 평문 목록이 이미 얼마나 넓은 범위를 적었는지, 「즉시 파기」가 증명하지 못하는 것, 그리고 「이 암호문을 내가 열 수 있는가」를 이 기기에서 대조하는 방법입니다.
이번 분해가 적어 둔 층
2026년 9월 18일, ferstar가 조사 기록을 공개했습니다. 출발은 패킷 경쟁이 아니라 디스크 정리였습니다. 로컬 ~/.zcode가 700MB를 넘었고, v2/checkpoints/ 안에 약 313MB짜리 .enc가 있었습니다. 옆의 상태 파일은 워크스페이스 약 345MB, kind는 baseline, failureCount는 564라고 적혀 있었습니다. 저장소 자체는 약 10GB였고, 의존성을 뺀 345MB는 거의 프로젝트 핵심 파일이었습니다.
업로드 흐름은 두 단계로 복원됐습니다. 첫째, 클라이언트가 zcode.z.ai에 POST /api/v1/snapshot/upload-credential을 보냅니다. 서버는 스냅샷 번호, 객체 저장소 폼 서명, 크기 상한, 그리고 이번 라운드의 RSA 공개키를 돌려줍니다. 둘째, 이 기기가 tar.gz를 만들고, 일회용 대칭키로 AES-256-CTR을 한 뒤, RSA-OAEP-SHA256으로 그 대칭키를 감쌉니다. 마지막에 tar.gz.enc를 폼 POST로 알리바바 클라우드 OSS에 바로 올리면, 저장소가 제작사 백엔드에 콜백해 등록합니다. 업무 서버는 이 암호문 파일을 거치지 않지만, 등록 권한과 개인키는 클라우드에 남습니다.
범위는 현재 작업 트리만이 아니었습니다. 로컬 평문 목록은 파일 42,411개를 적었습니다. .git/lfs/ 약 196.1MB(56.8%), .git/objects/ 약 102.2MB(29.6%), .git/logs/ 약 0.6MB, 소스와 문서 약 46.2MB(13.4%). .git 합계는 86.6%입니다. 업로드가 성공하면 클라우드가 받는 것은 커밋 이력, 지웠지만 객체 저장소에 남은 키, 아직 푸시하지 않은 로컬 브랜치 이름, .git/config의 내부망 호스트입니다. 워크스페이스를 가로지르는 추가 목록은 전역 설정에 해시를 매겨 함께 가져갑니다.
9월 18일 17:44, 제작사는 사용자 커뮤니티에 상황 설명을 올렸습니다. 업로드는 기본으로 켜진 코드 저장소 색인에서 나왔고, 세션 체크포인트, 버전 되돌리기, Repo Wiki에 쓰이며, Wiki를 만든 뒤 데이터는 즉시 파기한다고 했습니다. 9월 21일 《每日经济新闻》 보도에 따르면 ZCode는 소스 공개를 알렸고, 중국정보통신연구원(CAICT)은 zcode-prod 저장 버킷이 데이터 0건이라고 평가했으며, 녹맹과기(NSFOCUS)는 버킷과 객체가 삭제됐다고 했습니다. 클라이언트 v3.14.0은 스냅샷 생성과 업로드 경로를 걷어 냈습니다. ferstar의 보충은 이렇습니다. 313MB 상업 프로젝트는 크기 제한을 넘어 564회 재시도했고, 근거리망 밖으로 나가지 않았습니다. 파일 538개의 공개 저장소 워크스페이스는 압축·암호화 후 약 15KB였고, 상태는 서버가 수락한 것이었습니다. 「이 기기에서 무엇이 나갔는가」에 대해, 적어도 그 작은 한 건은 나갔습니다.
봉투 암호화가 내 복호화와 다른 이유
AES-256-CTR에 RSA-OAEP를 더하는 구성은 교과서의 봉투입니다. 내용은 짧은 수명의 대칭키로 암호화하고, 대칭키는 공개키로 한 겹 더 감쌉니다. Google Cloud의 한국어 설명도 같은 층을 가릅니다. 데이터를 암호화하는 키(DEK)를, 그 키를 감싸는 키(KEK)와 나눕니다. 알고리즘 이름은 단단해 보이지만, 「누가 읽는가」를 정하는 것은 공개키가 어디서 오고 개인키가 어디에 남는가입니다. 조사 기록은 이렇게 적습니다. 공개키는 업로드 자격 증명을 신청할 때 서버가 내려 주고, 대응하는 개인키는 이 컴퓨터에 들어오지 않습니다. 이 기기에 이미 있는 개인키로 그 봉투를 열어 보려 해도 성공하지 못했습니다. 클라이언트 자신도 디스크의 그 암호문을 열지 못합니다.
이것은 「내가 다시 열 수 있는 백업」과 방향이 반대입니다. Time Machine, 로컬 Git 객체, 비밀번호로 암호화한 뒤 복사해 둔 파일은 복호화 재료가 사용자 쪽에 있습니다. 비밀번호, 로컬 키, 또는 열 수 있는 키체인입니다. 서버가 개인키를 독점하면 설계 목표는 바뀝니다. 전송 중 제삼자는 못 보고, 도착한 뒤 클라우드는 뜯을 수 있습니다. ferstar의 문장은 용도를 고정합니다. 서버만 쓸 수 있는 열쇠가 하는 일은, 서버가 코드를 읽는 것이지 사용자에게 되돌리기를 주는 것이 아닙니다.
《每日经济新闻》 보도에서 상하이자오퉁대학 데이터법연구센터의 허위안은 범위를 더 좁혀 말했습니다. 암호화는 안전 조치이지 익명화가 아니고, 고지와 최소 수집을 대신하지도 않습니다. 서비스 제공자가 복호화 능력을 여전히 쥐고 있으면, 암호화된 데이터도 복구되고 처리될 수 있습니다. 「쓴 뒤 즉시 삭제」는 장기 보관을 낮출 뿐, 처음 수집이 필요했는지는 답하지 않습니다. 두 문장을 붙이면 이렇습니다. 알고리즘 강도는 키의 주인을 증명하지 못하고, 파기 선언은 수집 범위를 증명하지 못합니다.
운영 중인 저장소, 실제 클라우드 키, 고객 코드로 「업로드를 재현」하는 실험은 하지 마세요. 대조할 것은 이 기기에 전송 대기 암호문이 이미 있는지, 상태 파일의 경로와 실패 횟수, 그리고 그 파일을 직접 열 수 있는지입니다. 살아 있는 저장소를 한 번 더 보내도 개인키가 이 기기로 돌아오지 않습니다.
평문 목록이 이미 범위를 적는다
암호문을 열지 못한다고 범위를 추측만 할 수 있는 것은 아닙니다. 묶을 때 만든 파일 목록은 로컬에 남고, 평문입니다. 42,411개 기록은 「현재 소스」와 「저장소의 일생」을 갈라 놓습니다. 현재 트리는 약 13.4%이고, 나머지는 LFS 캐시, 전체 객체 저장소, reflog입니다. 지금 작업 트리에서 지운 API 키도, 한 번 커밋됐다면 .git/objects에 남아 있을 수 있습니다. 아직 푸시하지 않은 브랜치 이름은 공개되지 않은 기능을 드러냅니다. 내부망 Git 호스트 이름은 .git/config에 있고, 암호문을 열지 않아도 목록 쪽에서 그 이름이 묶음에 들어갔는지를 볼 수 있습니다.
화면의 두 스위치는 이름만 보면 총스위치 같지만, 코드에서는 아니었습니다. 조사 기록을 대조한 결과는 이렇습니다. 「경험 최적화(Optimize Experience)」는 모델 학습에 쓸 수 있는지만 제어합니다. 「저장소 스냅샷 색인(Repo Snapshot Indexing)」은 클라우드가 색인을 만드는지만 제어합니다. 묶기와 직접 업로드는 로그인 JWT가 유효하면 그대로 갑니다. 포착 지점은 프롬프트를 보내기 전과, 작업이 끝날 때의 repo-wiki-update입니다. 활성 세션 한 번에서 포착은 최대 62회까지 기록됐습니다. 전송 대기 묶음을 손으로 지운 뒤 약 30분이 지나자 새 313MB 파일이 생겼고, 실패 횟수는 564에서 565가 됐습니다. 파일을 지우는 것은 스위치를 끄는 것이 아닙니다.
9월 18일에 아카이브된 개인정보 처리방침은 페이지에 마지막 업데이트가 2026-06-15라고 남아 있었습니다. 수집 범위는 대화에 제출한 텍스트, 파일, 코드라고 적혀 있고, 「로그인한 뒤 전체 워크스페이스와 Git 이력을 자동으로 묶는다」는 문장은 없었습니다. 방침이 지지하는 결론은, 제작사가 세션 제출을 선언했다는 것입니다. 지지하지 못하는 결론은, 전체 스냅샷이 동의한 그 페이지에 이미 적혀 있었다는 것입니다. 스위치와 개인정보 처리방침은 실제 산출물과 대조해야 합니다. 로컬에 새 .enc가 있는지, 상태 파일의 workspacePath가 지금 쓰는 상업 프로젝트인지.
「암호화됨」과 「즉시 파기」가 각각 증명하는 것
뉴스 문장을 「지지하는 결론 / 지지하지 못하는 결론」으로 나누는 편이 형용사를 따라가는 것보다 안정적입니다. 디스크에 암호문이 있다는 것은, 묶인 바이트가 디렉터리 트리 평문이 아니라는 것만 지지합니다. 즉시 파기는, 제작사가 Wiki를 만든 뒤 그 객체를 오래 두지 않겠다고 선언했다는 것만 지지합니다. 공개된 소스에서 /api/v1/snapshot/upload-credential이 검색되지 않는다는 것은, 지금 공개된 트리에서 그 경로가 빠졌다는 것만 지지합니다. 저장 버킷 평가가 데이터 0건이라는 것은, 평가 당시 그 버킷이 비어 있었다는 것만 지지합니다.
이 문장들은 반대편을 덮지 못합니다. 암호문은 사용자가 워크스페이스를 복구할 수 있음을 지지하지 못합니다. 즉시 파기는 파기 전에 아무도 개인키를 쥐지 않았음을 지지하지 못하고, 수집 범위가 켠 옵션과 같았음도 지지하지 못합니다. 커밋 두 번으로 평탄해진 공개 소스는, 이전 사이드카가 어떻게 쓰였는지 대조하는 데 쓸 수 없습니다. 나중에 비운 버킷은, 9월 18일 이전에 이미 수락된 객체를 누가 열었고 누가 복사했는지 거꾸로 증명하지 못합니다. ferstar는 이렇게 적었습니다. 체크포인트 되돌리기가 정말로 전체 업로드를 필요로 한다면, 「만든 뒤 즉시 파기」와 시간이 어긋납니다. 공개 트리의 체크포인트 구현은 이 기기의 Git diff이고, 메타데이터는 ~/.zcode/checkpoints/의 JSON에 있으며, 그 업로드 경로에 기대지 않습니다.
| 보이는 말 | 지지하는 결론 | 지지하지 못하는 결론 |
|---|---|---|
| 디스크에 .enc가 있고 알고리즘이 AES-256이다 | 묶인 바이트는 워크스페이스 평문이 아니다 | 나만 복호화하고, 클라우드는 내용을 못 읽는다 |
| 자격 증명을 신청할 때 서버가 RSA 공개키를 내린다 | 봉투를 여는 개인키는 이 컴퓨터에 없다 | 기기 사이를 복구하는 내 백업이다 |
| 「경험 최적화」와 「저장소 색인」을 끈다 | 학습 허용이나 클라우드 색인은 멈췄을 수 있다 | 묶기와 직접 업로드도 반드시 같이 멈춘다 |
| 공식 설명이 Wiki 생성 후 즉시 파기라고 한다 | 제작사가 그 객체를 오래 두지 않겠다고 선언했다 | 처음 묶은 범위가 켠 스위치와 같다 |
| 평가가 저장 버킷을 데이터 0건이라고 한다 | 평가 당시 그 버킷은 비어 있었다 | 더 일찍 받은 객체가 한 번도 복호화되거나 복사되지 않았다 |
| 313MB 한 건이 564회 실패했다 | 이 상업 프로젝트 스냅샷은 나가지 않았다 | 어떤 사용자의 기기에서도 워크스페이스가 나간 적이 없다 |
그 자리에서 대조할 수 있는 층
구호는 증거가 되지 않습니다. 아래는 사용자가 통제하는 세 층만 대조합니다. 이 기기에 전송 대기 산출물이 있는지, 요청이 워크스페이스 평문을 가져갔는지, 이 암호문을 직접 열 수 있는지. 운영 중인 저장소에 「테스트 업로드」를 한 번 더 넣지 마세요.
- 홍보 페이지보다 이 기기의 데이터 디렉터리를 먼저 보세요. AI 코딩 클라이언트의 체크포인트나 캐시 디렉터리에 수백 MB짜리
.enc와,workspacePath·encryptedSizeBytes·failureCount를 적은 상태 파일이 있으면 묶기는 이미 일어났습니다. 경로가 지금 쓰는 프로젝트와 맞으면, 「대화 맥락만 보낸다」보다 더 단단한 증거입니다. - 개발자 도구나 시스템 네트워크 관찰을 열고 Preserve log를 켜세요. 요청 줄과 호스트 이름만 보세요. 업로드 자격 증명을 신청하는 인터페이스가 있는지, 객체 저장소로 바로 가는 폼 POST가 있는지. 대조하는 것은 「암호문이 이 기기를 떠났는가」이지, 저장소를 한 번 더 보내는 일이 아닙니다. 요청 본문에 소스, 비밀번호,
.pem평문이 보이면 이 층은 이미 실패한 것입니다. - 땅에 붙는 질문을 하나 하세요. 이 로컬 암호문을, 내 비밀번호나 이 기기의 개인키로 열 수 있는가. 열리지 않고, 제작사도 클라이언트가 열지 못한다고 하면 키의 주인은 사용자 쪽이 아닙니다. 열려야 「이것은 나를 위한 백업」이라고 말할 수 있습니다.
- 이름이 「개인정보 / 색인 / 최적화」처럼 보이는 스위치를 모두 끄고, 세션 한 주기를 기다린 뒤 체크포인트 디렉터리에 새 전송 대기 묶음이 있는지, 실패 횟수가 계속 오르는지 보세요. 스위치 문장은 총스위치를 증명하지 못합니다. 새 파일이 증명합니다.
- 직접 다시 열 수 있는 파일이 필요할 때는, 계산 경계가 적힌 다른 경로로 바꾸세요. 파일 암호화를 열고, 버려도 되는 카나리아 파일을 고르세요. 파일 이름은
canary-fp-20260922-vendor-key.txt로 두고, 비밀번호는 이 컴퓨터에만 남기세요. Network를 열고 Preserve log를 켠 뒤 암호화하세요. 요청 줄과 요청 본문에 파일 내용, 비밀번호, 전체 파일 이름의 업무 칸이 보이면 안 됩니다. 출력은.lock/.enc이고, 파일당 5 GB를 넘지 않습니다. 같은 비밀번호로 이 기기에서 복호화하면 카나리아가 돌아와야 합니다. 열 수 있는 이유는 비밀번호가 사용자 손에 있기 때문이지, 알고리즘 이름에 AES가 있기 때문이 아닙니다.
다섯째 단계는 파일 암호화가 코딩 클라이언트를 대신하라는 뜻이 아닙니다. 같은 「이 기기에서 암호화」라도, 키 유도와 AES-256-GCM이 지금 연 탭에 남고, 파일과 비밀번호는 기본적으로 업무 데이터로 올라가지 않는다는 대조를 제공할 뿐입니다. 암호문은 가져갈 수 있고, 열 수도 있습니다. 앞 글의 중계 문제는 다른 층입니다. HTTPS는 프록시 그 홉까지만 보호합니다. 이 글이 더하는 층은, 암호문이 떠난 뒤 봉투를 뜯는 사람이 누구인가입니다.
완전한 비밀번호와 암호문을 같은 채팅으로 보내지 마세요. 파일 암호화의 .lock은 클라우드 드라이브에 복사할 수 있습니다. 비밀번호는 이미 확인한 다른 경로로 보내거나, 짧은 비밀번호를 열람 후 파기 링크의 # 뒤에 두세요. 열쇠와 자물쇠를 같은 메시지에 붙이면, 그 메시지를 볼 수 있는 사람에게 봉투는 이미 없습니다.
로컬 암호화를 과하게 읽는 세 가지
첫째, 「이 기기에서 AES를 호출했다」를 「나만 복호화한다」로 읽는 경우입니다. 호출이 이 기기에서 일어났다는 것은, 평문을 묶을 때 그 내용이 아직 이 컴퓨터에 있었다는 뜻입니다. 공개키가 서버에서 오고 개인키가 기기에 남지 않으면 복호화 권한은 클라우드에 있습니다. 알고리즘 목록, 키 길이, CTR인지 GCM인지는 「개인키가 누구의 프로세스에 있는가」에 답하지 못합니다.
둘째, 「객체 저장소로 바로 올리고 업무 서버를 거치지 않는다」를 「제작사가 못 본다」로 읽는 경우입니다. 파일은 애플리케이션 서버를 건너뛸 수 있습니다. 등록 콜백과 개인키는 여전히 제작사 쪽에 있습니다. 업무 서버를 건너뛰면 줄어드는 것은 애플리케이션 로그의 평문 사본이지, 복호화 권한이 아닙니다. 중계 글은 HTTPS가 애플리케이션 계층 프록시를 막지 못한다고 적었습니다. 여기서 막지 못하는 것은 「개인키를 가진 그 끝」입니다.
셋째, 「즉시 파기 / 소스 공개 / 저장 버킷이 비었다」를 「수집한 적이 없다」로 읽는 경우입니다. 파기는 보관을 낮추고, 소스 공개는 현재 트리를 대조하게 하며, 빈 버킷은 평가 당시에 객체가 없었다는 뜻입니다. 셋 다 자동으로, 과거 객체가 한 번도 열리지 않았다거나 당시 스위치가 전체 Git을 덮었다는 뜻이 되지 않습니다. 인수인계 문서에 적을 것은, 이 기기가 아직 전송 대기 묶음을 만들고 있는지, 그리고 밖으로 보낼 암호문을 직접 열 수 있는지입니다. 뉴스 제목의 「이미 고쳤다」가 아닙니다.
자주 묻는 질문
디스크에 이미 암호문이 있으면, 이 기기 영지식과 같은가요?
같지 않습니다. 암호문은 묶인 바이트가 워크스페이스 평문이 아니라는 뜻입니다. 키를 감싼 RSA 공개키가 서버에서 그때그때 내려오고 개인키가 이 기기에 남지 않으면, 사용자와 클라이언트 모두 그 파일을 열지 못합니다. 클라우드가 읽도록 만든 봉투이지, 직접 복구하려는 백업이 아닙니다.
공식 설명이 업로드 뒤 즉시 파기라고 하면, 무엇을 더 대조할 수 있나요?
「즉시 파기」가 낮추는 것은 장기 보관입니다. 처음 묶은 범위가 켠 스위치를 넘었는지, 파기 전에 누가 개인키를 쥐고 있었는지는 답하지 않습니다. 나중에 저장 버킷을 비워도, 9월 18일 이전에 이미 받은 객체를 누가 열었고 누가 복사했는지는 거꾸로 증명되지 않습니다.
화면의 「경험 최적화」「저장소 색인」을 끄면 업로드도 같이 멈추나요?
분해된 이전 클라이언트에서 이 둘은 각각 「학습에 쓸 수 있는지」와 「클라우드가 색인을 만드는지」를 다룹니다. 묶기와 직접 업로드는 끊지 않습니다. 볼 것은 「스냅샷 생성을 멈추는」 독립 스위치가 있는지, 끈 뒤에도 로컬에 새 전송 대기 암호문이 생기는지입니다.
내가 다시 열 수 있는 파일을 동료에게 넘기려면 어느 경로를 쓰나요?
지금 연 탭에서 AES-256-GCM으로 암호화하고, 비밀번호는 이미 확인한 받는 사람에게만 알리세요. 파일 암호화를 열면 됩니다. 파일당 5 GB를 넘지 않고, 출력은 .lock / .enc이며, 파일과 비밀번호는 기본적으로 올라가지 않습니다. 열어 바로 쓰며 계정은 필요 없습니다. 짧은 비밀은 열람 후 파기로 바꾸고, 키는 링크의 # 뒤에 둡니다. 형태는 s.html?id={id}#{key}입니다. 티켓이나 로그에 휴대폰 번호, 주민등록번호가 겹쳐 있으면 먼저 링크 정리에서 규칙 마스킹을 하세요. 원문은 업무 데이터로 올라가지 않습니다.
직접 열 수 있어야 할 때는, 열어 바로 쓰는 경로로 바꾸기
「암호문은 내가 열고, 비밀번호는 Network에 들어가지 않는다」를 계산 경계가 적힌 페이지로 연습하려면 FastPwd 파일 암호화를 열면 됩니다. 가입은 필요 없습니다. 위의 카나리아를 고르고, 지금 연 탭에서 AES-256-GCM을 한 뒤 다섯째 절과 대조하세요. 요청에 파일 내용과 비밀번호가 보이면 안 되고, 같은 비밀번호로 이 기기에서 돌아와야 합니다. 출력 .lock / .enc는 클라우드 드라이브에 복사할 수 있습니다. 비밀번호는 같은 채팅에 적지 말고, AI 대화창에도 적지 마세요.
저장소 조각을 클라우드 모델에 넘길 때는, 받는 쪽이 붙여 넣은 전문을 본다고 먼저 가정하세요. 중계는 HTTPS가 끝나는 지점에 평문 호출 데이터를 남깁니다. 앞 글에 적어 두었습니다. 이 글이 한 가지 더 묻는 것은, 클라이언트가 먼저 「암호화」한 뒤 올린다면 봉투를 여는 개인키가 사용자 쪽에 있는가입니다. 두 층을 모두 통과하지 못하면, 살아 있는 클라우드 키, SSH 개인키, 고객 데이터를 워크스페이스에 넣은 채 묶는 도구에 맡기지 마세요. 규칙 마스킹은 흔한 칸만 가립니다. 키 한 덩어리는 열람 후 파기로 바꾸거나, 아예 밖으로 보내지 마세요.
다음에 「로컬에서 암호화한 뒤 올립니다」라는 설명을 보면 세 가지만 기억하세요. 첫째, 알고리즘 이름만 묻지 말고 개인키나 비밀번호가 누구 손에 있는지 묻습니다. 둘째, 목록이 현재 파일이 아닌 .git 이력까지 덮는지 묻습니다. 셋째, 파기 선언이 아니라 직접 열 수 있는 암호문으로 대조합니다. 인수인계 문서에 적을 수 있는 것은 이 세 문장입니다. 「디스크에 암호문이 있으니 클라우드는 못 본다」는 적을 수 없습니다.
더 읽을거리
클라우드에 올리기 전 압축파일에 비밀번호를 걸어도 파일 이름은 막지 못하고, 이 기기의 AES-GCM도 아닙니다. 클라우드에 올리기 전, 압축파일 비밀번호가 막는 범위와 그것이 기기 AES-256-GCM이 아닌 이유를 보세요. HTTPS는 중계 그 홉까지만 암호화하고, 프롬프트 안의 SSH 키는 막지 못합니다. LLM 중계 6TB 호출 데이터에 SSH 키가 나타나는 이유, HTTPS가 막지 못하는 층을 보세요. 페이지의 「로컬 암호화」를 Network로 직접 대조하는 방법은 브라우저 로컬 암호화에서 원문이 이 기기를 떠나지 않았는지 확인하는 방법을 보세요.