지푸 ZCode로 저장소를 연 뒤, .env와 삭제한 키, Git 전체 이력은 누가 묶어 올리는가

코딩 도우미는 보완과 오류 수정을 위해 코드를 읽습니다. 저장소를 열 때, 넘기고 있다고 여기는 것은 지금 작업 영역 가운데, 이번 일에 필요한 몇 개 파일입니다. 루트의 .env를 .gitignore에 넣었다면 「도우미는 못 보고, 클라우드는 더더욱 못 본다」고 읽는 사람이 많습니다. 2026년 9월 18일, 개발자 ferstar는 다른 층을 적었습니다. 지푸(Zhipu) 공식 데스크톱 앱 ZCode는 로그인 뒤에 이 기기에서 작업 영역 스냅샷을 만듭니다. 목록에서 용량의 대부분을 차지하는 것은 src/가 아니라, 온전한 .git입니다.

앞글은 비밀번호를 ChatGPT나 Gemini에 붙이기 전에, 반드시 가려야 할 글자를 썼습니다. 그건 내가 골라 붙인 한 단락입니다. 이 글은 질문을 바꿉니다. .env를 입력칸에 붙이지 않았어도, 작업 영역 스냅샷의 Git 객체 저장소, LFS 캐시, reflog는 이미 지운 키를 같이 가져가는가. 키를 옮긴다면 형태는 s.html?id=…#… 일회용 링크로 둡니다. 만들기와 읽기 모두 가입은 필요 없습니다. MyPassGen 도구는 열면 바로 씁니다. 아래는 클라이언트를 분해하는 방법도, 남의 업로드를 막는 절차도 아닙니다. ferstar의 2026년 9월 18일 검증과, 같은 날 한국어 보도가 옮긴 공식 설명이 이미 적은 숫자, 그리고 내 컴퓨터에서 열 수 있는 checkpoints를 나란히 둡니다.

저장소를 연다고, 지금 이 파일만 넘기는 것은 아니다

대화에 함수 한 조각을 붙이면, 모델이 먹는 것은 내가 고른 맥락입니다. 작업 영역 스냅샷은 다른 길입니다. 클라이언트가 연 저장소를 기준으로 묶고, 범위는 「이번 질문에 쓸 파일」보다 클 수 있습니다. ferstar가 적은 목록에서 용량을 나누면, .git/lfs/, .git/objects/, .git/logs/를 합쳐 약 86.6%이고, 나머지 소스와 문서는 약 13.4%입니다. 지금 디렉터리에서 .env를 지웠어도, 객체 저장소의 옛 커밋 blob은 따라갈 수 있습니다.

이건 「웹페이지가 방금 만든 비밀번호를 업무 데이터로 내보내는가」와 같은 길이 아닙니다. MyPassGen 생성 페이지는 브라우저 Network에서 평문이 업무 데이터로 나가지 않았는지 대조할 수 있습니다. 데스크톱 도우미가 스냅샷을 치면, 자기 로컬 디렉터리와 자기 송신 연결을 씁니다. 작업 영역에서 git rm한 파일은 Git에게 「지금 트리에 없다」일 뿐, 「이력에 한 번도 없었다」가 아닙니다. 가리지 않은 키를 커밋에 쓴 일과, 비밀번호를 메일 본문에 쓴 일은 같은 층입니다. 상대가 보는 것은 내가 일부러 남긴 사본입니다. 이메일 본문에 임시 비밀번호를 쓰면, 보낸편지함·전달·휴대폰 미리보기에 무엇이 남는가에 있습니다.

섞이기 쉬운 층이 하나 더 있습니다. .gitignore가 막는 것은 「앞으로 이 경로를 추적하지 말라」입니다. 「이 경로가 예전에 커밋된 적 있다」는 막지 못합니다. 도우미가 작업 영역의 현재 파일만 읽으면 무시 규칙은 아직 쓸모가 있습니다. 스냅샷이 .git 디렉터리 전체를 넣으면 무시 규칙은 도움이 되지 않습니다. 원격에 안 올린 로컬 브랜치, reflog의 조작 기록, .git/config의 사내 저장소 주소는 모두 「지금 편집기 탭에서는 안 보이지만, 객체 저장소에는 있는」 쪽입니다.

9월 18일 검증과 공식 설명에 적힌 숫자

ferstar는 출발점을 이렇게 적었습니다. 이 기기의 ~/.zcode가 700MB를 넘었습니다. 그중 v2/checkpoints/는 약 303MB이고, 안에는 약 313MB짜리 .enc가 있습니다. 상태 파일은 작업 영역을 묶기 전 약 345MB, 암호화 후 313070842바이트, 종류는 baseline, failureCount는 564라고 적었습니다. 이 상업 프로젝트 스냅샷은 로컬 pending에 걸려 있었고, 검증은 전송에 실패했다고 밝혔습니다. 아주 작은 공개 저장소도 있습니다. 538개 파일, 압축·암호화 후 약 15KB, 상태는 서버가 수신했습니다. 그래서 「정말 나갔는가」는, 적어도 이 한 번에서는, 작은 저장소가 나갔습니다.

같은 상업 프로젝트의 파일 목록 집계입니다. 모두 42411개 파일. .git/lfs/는 약 196.1MB(56.8%), .git/objects/는 약 102.2MB(29.6%), .git/logs/는 약 0.6MB(0.2%). 커뮤니티의 다른 재현은 ZCode 3.12.3에서 한 프로젝트 스냅샷이 약 748MiB이고, 그중 .git이 약 98.91%라고 적었습니다. 포착 시점으로 검증이 지목한 것은 질문 전의 captureBeforePrompt와, 작업이 끝날 때의 repo-wiki-update입니다. 한 활성 세션 로그에는 스냅샷 포착이 최대 62번 나타났습니다.

공식 설명은 9월 18일 17:44에 나왔고, 한국어 보도는 그날 밤 옮겼습니다. 요점은 이렇습니다. 문제는 「코드 저장소 인덱스」에 있고, 로컬 인덱스, 세션 체크포인트 롤백, Repo Wiki에 쓰입니다. Repo Wiki가 클라우드에서 페이지를 만들 때 저장소 데이터 업로드를 「유발할 수 있다」고 했습니다. Wiki를 만든 뒤 관련 업로드 데이터는 바로 폐기되고 저장하지 않는다고 했습니다. 출시 초기에 기본으로 켜져 일부 사용자가 영향을 받았고, 문제는 「이미 수정됐다」고 했습니다. 가까운 시일 안에 ZCode를 오픈소스하고 제3자 심사를 도입하며, 모든 사용자에게 주간 할당을 한 번 더 초기화한다고 했습니다. 공식은 「업로드가 있었다」는 점을 부정하지 않았습니다. 남는 의문은 업로드 범위, 그때 끌 수 있었는지, 「바로 폐기」를 바깥에서 어떻게 대조하는가입니다. 9월 20일, InfoQ가 전한 내용에 따르면 타이위안 청밍 테크가 베이징 지푸화장에 공문을 보내 삭제, 흐름, 로그, 책임 주체를 설명하라고 했습니다. 그건 기업 쪽의 추궁이지, 이 기기에서 열 수 있는 폐기 증명은 아닙니다.

.git이 대부분이다: 삭제한 키는 객체 저장소에 남는다

지금 작업 영역에 .env가 없다는 것은, 지금 체크아웃한 트리에 그 경로가 없다는 뜻일 뿐입니다. Git 객체 저장소는 내용으로 blob을 둡니다. 어떤 커밋이 DATABASE_URL=이나 AWS_SECRET_ACCESS_KEY=를 썼고, 나중에 파일을 고치고 다시 커밋하고, 심지어 지금 브랜치에서 지워도, 옛 blob은 gc가 진짜로 버릴 때까지 .git/objects에 남는 경우가 많습니다. LFS 캐시는 예전의 큰 파일을 남길 수 있습니다. reflog는 이 기기에서 옮긴 브랜치를 적습니다. 이 셋을 스냅샷에 넣으면, 클라우드가 받는 것은 「지금 편집기 한 화면」이 아니라, 이 저장소가 이 기기에 쌓아 둔 이력입니다.

검증은 한 문장을 더 적었습니다. 작업 영역 필터가 일부 키 파일은 빼지만, .git은 묶음에 들어갑니다. 이 문장은 따로 멈춰 볼 가치가 있습니다. 오늘 .env를 저장소 밖으로 빼고 .env.example만 남기면, 지금 트리는 깨끗해 보입니다. 객체 저장소에 작년에 잘못 올린 커밋이 있고, 필터가 작업 영역 경로만 보면, 그걸 빼지 않습니다. 사내 GitLab 도메인이 .git/config에 있고, 아직 안 올린 기능 브랜치 이름이 refs와 reflog에 있습니다. 「이미 gitignore했다」로 되돌릴 수 있는 것들이 아닙니다.

「비밀번호 해시가 새어 나갔다고, 남이 이미 평문을 읽었다」와는 대조할 수 있어도, 서로 대신할 수는 없습니다. 해시는 한 방향 저장이고, 그래도 바꿔야 합니다. Git 이력의 키는 자주 그냥 평문입니다. 이 기기에서 흔한 약한 비밀번호 목록을 대조하는 일은, 공개 목록에 맞았다는 것만 증명합니다. 어떤 스냅샷이 옛 커밋을 가져갔는지는 증명하지 않습니다. 기기에서 유출 목록만 대조하는 것과 전체 유출 조회는 무엇이 다른가에 있습니다. 바꿔야 하는 것은 커밋에 한 번 들어갔던 그 묶음입니다. 「지금 작업 영역이 깨끗하다」는 한 눈이 아닙니다.

암호문으로 묶었다고, 나만 풀 수 있는 것은 아니다

검증이 복원한 송신 형태는 이렇습니다. 클라이언트가 zcode.z.ai에 스냅샷 업로드 자격 증명을 요청하고, 객체 키, 크기 한도, RSA 공개키 한 개를 받습니다. 이 기기가 작업 영역을 tar.gz로 묶고 AES-256-CTR로 암호화한 뒤, 그 공개키로 대칭키를 감싸고, tar.gz.enc를 알리윈 OSS로 바로 올립니다. 비밀키는 처음부터 끝까지 클라우드에만 있습니다. 이 기기의 수백 메가바이트 .enc는 내가 열 수 없고, 클라이언트도 열 수 없습니다. 알고리즘 이름에 AES-256이 적혀 있어도, 해결하는 것은 「길과 버킷 안이 평문 파일이 아니다」입니다. 복호화 권한을 나에게 넘긴 것은 아닙니다.

이건 「클라우드 페이지가 암호화됨이라고 쓴다」와 같은 경계입니다. 사업자가 키를 대신 쥐면 저장 쪽은 여전히 열 수 있습니다. 이 기기에서 내가 쥔 비밀번호로 먼저 암호화하면, 상대는 암호문만 봅니다. 차이는 「AES 네 글자가 나왔는가」가 아니라, 비밀키나 비밀번호가 누구 손에 있는가입니다. MyPassGen 파일 암호화는 브라우저에서 AES-256-GCM으로 스트림 암호화를 하고, 파일 하나는 5GB를 넘지 않으며, 출력은 .lock / .enc입니다. 열면 바로 씁니다. 비밀번호는 다른 길로 보내고, 파일은 업무 데이터로 올라가지 않습니다. ZCode 그 스냅샷의 봉투 키는 서버가 공개키를 내려주고 비밀키를 스스로 쥐므로, 목표는 정반대입니다. 서버가 풀 수 있게 하는 것입니다. 파일을 클라우드에 넣기 전에, 평문은 누가 읽을 수 있고 암호는 어느 길로 보내야 하는가에 있습니다.

공식은 Wiki를 만든 뒤 바로 폐기하고 저장하지 않는다고 적었습니다. 폐기가 서버에서 일어난다면, 백업, 객체 저장 버전, 비밀키 사본을 내 컴퓨터에서 대조할 수 없습니다. ferstar는 3.14.0을 대조하며, 업로드 경로 코드가 클라이언트에서 빠졌고 upload-credential이 404를 돌려주며, 로컬에는 checkpoint만 남는다고 적었습니다. 이건 「이 새 클라이언트가 그 자격 증명 요청 길을 더 이상 쓰지 않는다」는 증명입니다. 「이미 받아 넣은 작은 저장소 스냅샷이 모든 사본에서 물리적으로 지워졌다」는 증명은 아닙니다. 「암호화됐다」를 「나만 볼 수 있다」로 읽으면, 진짜로 해야 할 교체를 빠뜨립니다.

설정을 꺼도 묶음은 멈추지 않는다

검증은 스위치 두 개와 코드 경로를 맞춰 봤습니다. optimizeAgentExperienceEnabled(경험 최적화)가 맡는 것은 데이터를 학습에 쓸지입니다. 꺼도 스냅샷은 칩니다. repoSnapshotIndexingEnabled(저장소 스냅샷 인덱스)가 맡는 것은 서버가 스냅샷을 받은 뒤 인덱스를 만들지입니다. 꺼도 이 기기의 묶음은 갑니다. 3.12.3에서 포착과 업로드를 맡은 논리는 로그인으로 JWT를 받은 뒤에 올라가고, 화면에는 「묶어서 올리지 않기」를 따로 끄는 칸이 없었습니다. 공식 설명은 사용자가 끄고, 그 자리에서 송신이 멈췄는지 확인할 수 있는 스위치를 나열하지 않았습니다. 기능이 초기에 기본으로 켜져 있었고, 문제는 이미 수정됐다고만 했습니다.

그래서 「Repo Wiki를 안 켰다」와 「학습을 껐다」는 3.12.3의 면책 문구가 될 수 없습니다. 기준으로 삼을 것은 이 기기 checkpoints 디렉터리에 그때 새 .enc가 있었는지, 상태가 pending인지 수신됐는지입니다. 검증이 말한 3.14.0으로 올린 뒤에는 같은 디렉터리를 다시 보세요. 올릴 대기 중인 새 묶음이 생기는지, 자격 증명을 요청하는 주소가 성공을 돌려주는지. 클라이언트는 핫업데이트를 합니다. 버전 숫자와 디렉터리는 내가 반복해서 볼 수 있는 두 가지입니다. 뉴스 제목은 아닙니다.

9월 18일 그날 저장된 공식 개인정보 처리방침 스냅샷은, 페이지에 여전히 2026년 6월 15일 갱신이라고 적혀 있었습니다. 방침은 대화에 제출한 글, 파일, 코드를 수집한다고 씁니다. 그건 도우미가 모델을 부르는 흔한 범위입니다. 검증은, 그때 글 어디에도 저장소 전체 스냅샷이나 온전한 Git 이력을 클라우드에 올린다는 말이 없다고 지적했습니다. 방침 문장과 이 기기의 목록이 맞지 않으면, 목록과 상태 파일을 기준으로 하세요. 「개인정보 처리방침에 동의했으니, 대화칸의 그 한 단락만 올라갔다」로 거꾸로 추측하지 마세요.

대조표: 현재 파일, Git 이력, 대화에 무엇이 남는가

저장소에 한 번 들어갔던 같은 테스트 키는, 「누가 다시 읽을 수 있는가」를 적어도 네 갈래로 나눌 수 있습니다. 차이는 도우미 브랜드가 아니라, 사본이 어디로 복제됐고 복호화 권한이 누구 손에 있는가입니다.

다섯째 줄과 앞 네 줄을 섞지 마세요. 온전한 s.html?id=…#…를 저장소에 쓰고 도우미를 열면, 이력과 스냅샷은 여전히 주소 전체를 받을 수 있습니다. 암호문을 맡긴 서버만 키를 못 봅니다. 번호와 키를 가르면, 전문 검색으로도 열 수 있는 온전한 링크가 나오지 않습니다. 온전한 링크는 비밀번호 자체처럼 다루세요. 이 기기에서 먼저 암호화한 뒤 동기화하는 것은 파일입니다. Git 객체 저장소에 평문을 한 번 커밋하면, 나중에 .lock을 보탠다고 옛 blob이 지워지지 않습니다.

그 자리에서 확인하기

아래 단계는 어떤 브랜드의 약속도 필요로 하지 않습니다. 처음부터 끝까지, 실제 업무 계정에 로그인하지 않고, 회사 저장소를 가리키지 않는 테스트 비밀번호와 일회용 저장소를 쓰세요. 빈 디렉터리에 orange-lake-7 한 줄을 쓰고 커밋한 뒤 지우는 식이면 됩니다. 지금 쓰는 마스터 비밀번호, 운영 API 키, 살아 있는 일회용 링크로는 연습하지 마세요.

1. ZCode 정보 화면이나 설치 패키지의 버전 숫자를 봅니다. 검증은 3.12.3을 문제 버전, 3.14.0을 업로드 경로가 빠진 버전으로 적었습니다. 지금 읽는 숫자를 기준으로 하세요. 단체 공지로 이 한 눈을 대신하지 마세요.
2. 이 기기 데이터 루트의 v2/checkpoints를 엽니다(macOS / Linux는 흔히 ~/.zcode/v2/checkpoints, Windows는 설치 뒤 사용자 디렉터리를 따릅니다). .enc가 있는지, 옆에 상태 JSON이 있는지. 열 수 있는 칸만 봅니다. workspacePath가 연 적 없다고 생각한 프로젝트인지, encryptedSizeBytes, failureCount, kind. 경로가 맞으면, 이 기기가 그 저장소를 묶은 적이 있다는 뜻입니다. failureCount가 크다는 것은 그때 전송이 안 됐다는 뜻일 뿐, 다른 저장소가 한 번도 성공하지 않았다는 증명은 아닙니다.
3. 빈 테스트 저장소를 따로 만들고, 테스트 비밀번호 한 줄을 커밋한 뒤 지금 트리에서 지웁니다. git log -p 또는 git log --all --full-history -- 파일이름으로 옛 커밋이 남았는지 봅니다. 남았다면 「이미 지웠다」가 객체 저장소를 구하지 못합니다. 이건 Git 자체의 동작이고, 어떤 도우미와도 무관합니다. 스냅샷이 .git을 넣으면 읽는 것이 바로 이 층입니다.
4. 테스트 저장소를 3.12.3이 연 적이 있다면, checkpoints로 돌아가 그 경로에 해당하는 새 묶음이 있는지 봅니다. 업그레이드 뒤에 한동안 더 보고, 올릴 대기 중인 새 .enc가 생기는지 확인하세요. 이 기기의 파일은 내가 반복해서 볼 수 있는 증거입니다. 남의 클라이언트를 분해할 필요는 없고, 해서도 안 됩니다.
5. 실제 저장소에 한 번이라도 커밋된 비밀번호, 토큰, 사내 주소는 「이미 이 기기를 떠났다」로 다룹니다. 원래 서비스에서 교체하고, 새 무작위 비밀번호로 바꿉니다. MyPassGen 비밀번호 생성의 무작위 모드는 6–128자, 기본 16자이며, 8자 미만이면 약하다고 알립니다. 열면 바로 쓰고, 생성 결과는 업무 데이터로 올라가지 않습니다. 재사용한 비밀번호는 강도 검사로 이 기기에서 흔한 약한 비밀번호 목록과 대조하세요. 공개 목록에 맞았다는 것은 증명하지만, 어떤 스냅샷의 범위는 증명하지 않습니다.
6. MyPassGen 일회용 링크를 하나 더 만들고, 같은 테스트 비밀번호 한 줄을 넣습니다. 만료는 24시간, 읽기 횟수는 1로 둡니다. 채팅이나 티켓에는 우물정 앞의 s.html?id=…만 붙이고, 키는 전화나 대면으로 말합니다. 열면 바로 쓰고, 가입은 필요 없습니다. 수신 쪽이 번호만 있으면 링크가 불완전해야 합니다. 두 반쪽을 맞춰야 복호화됩니다. 읽은 뒤에는 클립보드를 덮어쓰세요. #가 있는 주소를 저장소에 쓰지 말고, 결과 페이지 전체를 어떤 도우미 대화칸에도 붙이지 마세요.

회사 저장소라면 반 걸음을 더 합니다. 도우미가 기본으로 여는 루트 디렉터리가 무엇인지, 키 디렉터리를 작업 영역 밖으로 뺄 수 있는지, 옛 스냅샷에 기업 쪽 삭제 회신이 있는지를 물어보세요. MyPassGen은 어떤 클라우드가 사본을 따로 뒀는지 대신 판단하지 않습니다. 대조 결과는 방금 연 그 창들과 Git 로그를 기준으로 하세요.

키를 넘겨야 할 때는 길을 가른다

일대일이고, 상대가 바로 열 수 있으면, 비밀번호를 Git에 들어가고, 도우미 작업 영역에 들어가고, 객체 저장소에 남을 파일에 쓰지 마세요. 이 기기에서 비밀번호를 만든 뒤 일회용 링크로 감쌉니다. 일회용 링크를 만들 때 브라우저는 AES-256-GCM으로 암호화합니다. 평문 한도는 32KB입니다. 읽기 횟수는 기본 1, 상한 10입니다. 만료는 1시간, 24시간, 7일, 또는 횟수만 두고 TTL을 두지 않을 수 있습니다. 서버는 암호문만 잠시 둡니다. 키는 URL의 # 뒤에 두고, 접속 로그와 Referer에는 이 조각이 보이지 않습니다. 저장소와 도우미 대화칸에는 보입니다. 그래서 온전한 링크를 커밋에 쓰지 마세요.

저장소나 티켓에 입구를 남겨야 하면 길을 가릅니다. 파일에는 담당자와 번호, 「키는 전화로」라는 한 문장만 둡니다. 전화, 대면, 또는 다른 메신저 계정에는 # 뒤 조각만 보냅니다. 한쪽만으로는 풀리지 않습니다. 이는 쓰는 방법이지, 제품이 기본으로 쪼개는 기능이 아닙니다. 만들기 페이지가 내는 것은 여전히 링크 전체이며, 일대일 전달에는 그편이 편합니다. 미리보기 카드를 그리는 채널이면, 테스트 링크로 미리보기가 횟수를 세는지 먼저 봅니다. 일회용 링크를 슬랙이나 카카오톡에 보내면, 미리보기가 먼저 한 번 태우나에 있습니다. 오류와 설정 발췌는 먼저 UTM 제거로 가린 뒤, 도우미에 붙일지 정하세요.

32KB를 넘는 키 묶음이나 내보내기 표는 일회용 글 링크에 억지로 넣지 않습니다. 파일 암호화로 갑니다. 브라우저에서 AES-256-GCM 스트림 암호화를 하고, 파일 하나는 5GB를 넘지 않으며, 출력은 .lock / .enc입니다. 비밀번호는 다른 길로 보냅니다. 이 기기에서 먼저 암호화한 뒤 동기화하면, 상대는 암호문만 봐야 합니다. 가리지 않은 .env를 Git에 미는 일과, 암호화하지 않은 인증서 묶음을 클라우드에 미는 일은 같은 층입니다. 「이게 키다」를 증명하는 한 부가, 이미 지웠다고 생각한 작업 영역을 떠났습니다. 브라우저에서 암호화할 때 평문이 업무 데이터로 나가지 않았는지 그 자리에서 확인하는 방법은 브라우저에서 암호화할 때, 평문이 올라가지 않았는지 그 자리에서 확인하는 방법에 있습니다.

「checkpoints에 그 경로의 .enc가 있는가」, 「git log가 테스트 비밀번호를 아직 읽는가」, 「클라이언트만 올리면 옛 스냅샷이 비는가」 세 번을 확인하면, 이 글의 질문에 답할 수 있습니다. 지금 트리에서 .env를 지웠다고, 객체 저장소와 예전에 친 스냅샷이 같이 비는 것은 아닙니다. 공식이 고친 것은 그들이 바꿀 수 있는 클라이언트 경로입니다. 이미 받아 넣은 묶음과, 저장소 옛 커밋의 평문은, 버전을 한 번 올린다고 비지 않습니다. 이 기기의 디렉터리와 Git 로그는 확인하는 입구입니다. 「키를 대화칸에 안 붙였으니 끝났다」고 가정하는 자리로는 부족합니다.

자주 묻는 질문

이미 올렸습니다. 옛 스냅샷도 없나요?

같은 일이 아닙니다. 새 버전이 막는 것은 다음 자격 증명 요청과 직전송입니다. 이 기기의 옛 .enc, 상태 파일, 그리고 공식이 「만든 뒤 바로 폐기한다」고 한 클라우드 사본은 「업그레이드」라는 동작 안에 없습니다. 지금 checkpoints가 남았는지, 실제 키를 바꿨는지를 기준으로 하세요.

작업 영역에서 .env를 이미 gitignore했습니다. 그래도 바꿔야 하나요?

이력을 보세요. 지금 트리를 보지 마세요. 무시 규칙은 앞으로의 추적만 막습니다. 옛 커밋에 평문이 나왔다면, 이미 복제된 것으로 다룹니다. 테스트 저장소에서 git log로 한 번 대조하는 편이, 필터를 믿는 것보다 직접적입니다.

스냅샷이 암호화돼 있으니, 새어 나가지 않은 것으로 봐도 되나요?

안 됩니다. 검증은 비밀키가 클라우드에만 있고, 이 기기의 암호문은 내가 풀 수 없다고 적었습니다. 암호화가 막는 것은 「버킷에 평문 tar가 누워 있는 일」입니다. 「저장소 주인만 읽을 수 있는 일」이 아닙니다. 폐기를 바깥에서 증명할 수 없으면, Git에 한 번 들어간 키는 바꿔야 할 재료로 두세요.

만들기와 읽기에 가입이 필요한가요? 길을 잘못 보냈을 때 고객지원이 찾아 주나요?

가입은 필요 없습니다. 만들기와 읽기 모두 방문객에게 열려 있습니다. 암호문이 횟수나 만료로 태워진 뒤에는 서버 쪽 평문 백업이 없고, 찾아 줄 고객지원 메일함도 없습니다. 길을 잘못 보냈으면 비밀번호를 새로 만들고 링크를 다시 만드세요. 같은 주소를 새로고침하며 운을 시험하지 말고, 결과 페이지를 저장소에 써서 다시 보내지 마세요.