Backup Comparison

제로노하우(ZK) 백업 서비스 비교

수정 원칙: 문서 내부 모순을 정리하고, 근거가 약한 수치는 삭제하거나 완화했습니다. 시점에 따라 바뀌는 항목에는 "확인 필요"를 표시했습니다.

등급 기준: 암호 설계(AEAD 여부, 키 길이) 40%, 독립 감사 30%, 클라이언트 코드 검증 가능성 20%, 관할권 10%

먼저 짚을 것: "백업"과 "제로노하우"는 좀처럼 같이 오지 않습니다

시중의 제로노하우 서비스 대부분은 동기화 클라우드입니다. 진짜 백업이 요구하는 것은 불변 스냅샷, 장기 버전 보관, 스케줄과 재시도, 오프사이트 3-2-1입니다. 이것을 모두 갖춘 제로노하우 제품은 드뭅니다.

A. 관리형 서비스

용도별 선택:

• Proton Drive: 감사, 제로노하우, 생태계를 한 번에 원할 때. 파일당 최대 200개 버전을 최대 10년까지 보관하므로(유료 플랜 기준) 랜섬웨어에서 롤백할 수 있습니다. 다만 개수 상한 때문에 자주 바뀌는 파일은 오래된 버전부터 밀려나고, 기록은 삭제할 수 있어 불변이 아닙니다. 사진·문서 백업에는 적합하고 시스템 이미지 백업에는 부적합합니다. (동기화 기능 범위는 확인 필요)
• Tresorit: 규제 산업·기업용. 인증 수준은 높지만 클라이언트가 폐쇄소스라 구현을 직접 검증할 수 없습니다.
• Filen 또는 Internxt: 코드를 직접 검증하고 싶을 때. Filen은 전체 코드가 공개돼 있지만 감사 이력이 약합니다. Internxt는 감사와 공개 코드를 모두 갖췄지만 PQ 적용 범위가 제한적입니다.
• SpiderOak: 오래된 백업 전문 서비스. 2007년부터 클라이언트측 암호화를 유지해 왔고, 2017년에 "zero knowledge" 대신 "no knowledge"로 표현을 바꿨습니다. 다만 암호 세대가 한 단계 뒤처지고, 웹 로그인 경로는 신뢰 경계를 깹니다.

B. 목록에서 빼야 할 것 (마케팅 함정)

C. 암호 강도 최우선이라면: 클라이언트측 백업 도구 + 불변 스토리지

동기화형과 스냅샷형의 차이 (랜섬웨어 관점):

• 동기화형 (Cryptomator, Proton Drive, Tresorit, Sync.com 등): 로컬이 감염되면 그 변경이 클라우드로 그대로 전파됩니다. 이는 특정 제품이 아닌 동기화 방식 공통의 한계입니다. 복원은 클라우드의 버전 기록에 의존하며, 이 기록은 보존 기간이나 개수가 제한되고 삭제할 수도 있습니다.
• 스냅샷형 (Kopia, restic, Arq 등): 과거 스냅샷은 새 백업으로 덮어써지지 않습니다. 다만 랜섬웨어가 저장소 접근 권한까지 탈취하면 스냅샷을 지울 수 있으므로, Object Lock이나 append-only 설정이 함께 있어야 완전합니다.

핵심: 버전 기록만으로는 부족합니다. 진짜 방어는 삭제와 덮어쓰기가 불가능한 시점(Object Lock / 불변 보존)입니다.

D. 최종 추천

E. 공통 한계

• 양자내성은 아직 초기 단계입니다. 독립 감사를 마친 주요 서비스 중 저장 파일에 PQ를 기본 적용한 곳은 확인되지 않습니다.
  • Proton은 OpenPGP 기반 PQ 하이브리드(ML-KEM + X25519)를 발표했지만, Drive 적용 여부는 확인이 필요합니다.
  • Tresorit의 PQ 적용 상태도 확인이 필요합니다.
  • Internxt의 Kyber-512는 계정 키와 공유 키에만 적용됩니다.
  • ShieldFive는 기본 적용을 주장하지만 감사가 없습니다.
• 웹 앱은 신뢰 경계입니다. 브라우저는 매번 서버에서 받은 JS로 복호화하므로, 제공자가 악성 코드를 배포하면 보호 모델이 무너집니다. 가능하면 오픈소스 네이티브 앱을 쓰세요.
• 비밀번호를 잃으면 데이터도 사라집니다. 복구 키는 오프라인에 보관하세요.
• "제로노하우"라는 단어를 그대로 믿지 마세요. 다음 네 가지를 확인해야 합니다.
  1. 모든 파일에 기본 적용되는가 (opt-in 폴더가 아닌가)
  2. 파일명까지 암호화되는가
  3. 완료된 제3자 감사가 있는가
  4. 클라이언트 코드를 읽을 수 있는가

출처 및 주의

• 원문 수치의 상당 부분은 벤더 발행 자료(ShieldFive 비교 페이지)에 의존했습니다. 최종 사용 전에 각사 보안 백서, 감사 보고서, 요금제 페이지 같은 1차 출처로 교차 확인하세요.
• 참고 출처:
  • ShieldFive 비교 페이지 (벤더 자료)
  • SpiderOak 리뷰
  • r/ProtonDrive

F. Kopia + B2 / S3 운영 메모

가격은 2026년 10월 기준 제3자 자료와 us-east-1 단가입니다. 서울 리전은 더 비쌉니다. 사용 전 각사 요금 페이지에서 확인하세요.

저장소 선택

• 공식 추천은 없습니다. Kopia 문서는 지원 저장소를 나열만 합니다.
  • 안정 지원: S3·S3 호환, B2, Azure, GCS, SFTP, WebDAV, 파일시스템
  • 실험적 지원: Google Drive, Rclone
• 커뮤니티 합의도 없습니다. Kopia + Object Lock 사례로 확인된 것은 다음 두 가지입니다.
  • B2: S3 호환 방식으로 연결해야 Object Lock을 쓸 수 있습니다.
  • IDrive e2: Object Lock까지 잘 동작한다는 사용자 후기가 있습니다.
• Wasabi와 R2는 Kopia 사례를 찾지 못했습니다.

Kopia 저장소 구조

• 저장소는 그 자체로 완결돼 있습니다. 버킷 접속 정보와 비밀번호만 있으면 새 컴퓨터에서도 복구할 수 있습니다.
• 로컬에는 원본이 남지 않습니다.
  • 캐시: ~/Library/Caches/kopia
  • 연결 설정: ~/Library/Application Support/kopia/repository.config
  • 비밀번호: macOS 키체인
• 비밀번호를 잃으면 복구할 수 없습니다. 오프라인에 따로 보관하세요.
• 파일 수가 많아도 불리하지 않습니다. 작은 파일은 묶음으로 올라가므로, 객체 수는 묶음 수로 정해집니다. 2TB면 약 10만 개입니다.

.storageconfig로 접두어별 저장 등급 지정

저장소 루트에 .storageconfig를 두면 접두어마다 S3 저장 등급을 다르게 정할 수 있습니다. 용량 대부분인 p만 싼 등급에 두고, 자주 읽는 메타데이터는 Standard에 두는 식입니다.

{
  "blobOptions": [
    { "prefix": "p", "storageClass": "DEEP_ARCHIVE" },
    { "storageClass": "STANDARD" }
  ]
}

• 위 예시는 문법 확인이 필요합니다. 쓰기 전에 공식 문서에서 확인하세요.
• x, q, kopia.repository는 바로 읽을 수 있는 등급이어야 합니다. 아카이브 등급에 들어가면 저장소를 열 수 없습니다.
• Glacier IR을 쓸 때도 유용합니다. x, q를 Standard에 두면 다음 비용이 줄어듭니다.
  • 메타데이터를 읽을 때마다 붙는 꺼내기 비용
  • 작은 인덱스에 적용되는 128KB 최소 과금과 90일 최소 보관
• 저장소를 옮길 때도 필요합니다. sync-to로 복사한 파일은 기본 등급(Standard)으로 들어가므로, 복사 전에 이 파일이나 S3 수명 주기 규칙을 준비해야 합니다.

B2 vs Glacier Instant Retrieval (2TB 기준)

• 손익분기점: 월 보관료 차이는 약 $6입니다. 전체 복구 한 번 비용이 약 3년치 보관료 차이와 비슷합니다.
• B2가 Kopia와 더 편합니다.
  • 정리 작업과 검증을 자주 돌려도 추가 비용이 거의 없습니다.
  • 정리 작업이 묶음을 다시 써도 조기 삭제 요금이 없습니다.

Glacier Flexible / Deep Archive를 쓸 때

• 전체 복구에는 위 비용에 더해 인터넷 전송료 약 $175와 복원 중 임시 사본 보관료가 듭니다.
• 비용은 가장 싸지만 운영 부담이 큽니다.
  • 바로 읽을 수 없습니다. p를 읽을 수 없으므로 kopia snapshot verify로 실제 데이터를 검증할 수 없습니다.
  • 복구 단계가 깁니다. 필요한 묶음 파일을 찾고, AWS에 복원 요청을 넣고, 12~48시간 기다린 뒤에야 Kopia로 복구할 수 있습니다.
  • 정리 작업을 직접 관리해야 합니다. 정리 주기가 최소 보관 기간보다 짧으면 조기 삭제 요금이 쌓입니다.
  • 설정 실수가 치명적입니다. .storageconfig가 틀려서 메타데이터가 아카이브 등급에 들어가면 저장소를 열 수 없습니다.

일부 파일 복구와 삭제

• 일부 파일 복구
  • CLI: kopia restore <스냅샷ID>/경로 ./복구할곳
  • 마운트: kopia mount로 스냅샷을 폴더처럼 열어 필요한 파일만 복사
  • KopiaUI: 스냅샷을 탐색하며 파일 단위로 복구
  • 받는 데이터는 메타데이터와 해당 파일이 든 묶음뿐입니다.
• 일부 파일 삭제
  1. kopia snapshot fix remove-files --filename='패턴' --commit으로 기존 스냅샷에서 파일을 뺍니다.
  2. kopia maintenance run --full을 돌리면, 참조가 사라진 데이터가 안전 대기 시간 뒤에 지워집니다.
  • Object Lock 보존 기간 안에는 실제로 지워지지 않습니다.
  • 같은 내용이 다른 경로에도 있으면 데이터가 남습니다(중복 제거).
  • 앞으로 백업에서 빼려면 .kopiaignore나 kopia policy set --add-ignore로 제외합니다.

B2에서 S3로 옮기기

B2로 시작해 실제 사용량과 복구 패턴을 본 뒤 S3로 옮기는 계획은 무리가 없습니다.

1. S3 버킷을 만듭니다. Object Lock은 버킷을 만들 때 켜야 합니다.
2. 접두어별 저장 등급을 정합니다. .storageconfig나 수명 주기 규칙을 쓰고, 정하지 않으면 Standard로 들어갑니다.
3. B2 저장소에 연결된 상태에서 kopia repository sync-to s3 --bucket=… --parallel=8로 복사합니다. 비밀번호, 암호화 형식, 스냅샷 기록이 그대로 유지됩니다.
4. kopia repository connect s3 …로 새 저장소에 연결합니다.
5. kopia snapshot verify와 실제 복구 테스트로 검증합니다.
6. S3 저장소에서 Object Lock 관련 정리 설정(--extend-object-locks 등)을 다시 확인합니다.

비용과 주의할 점:

• 이전 비용: B2 전송료는 월 보관량의 3배까지 무료이고, S3 업로드 전송료도 무료입니다. 요청비만 조금 듭니다.
• 시간: 데이터가 sync-to를 실행하는 컴퓨터를 거쳐 가므로 회선 속도에 따라 수 TB면 며칠이 걸릴 수 있습니다.
• 보존 기간: B2의 Object Lock 보존 기간이 남아 있으면 그동안 두 곳에 요금을 함께 냅니다. 처음부터 보존 기간을 짧게(예: 30일) 잡는 것이 좋습니다.

출처

• Kopia Repositories 문서
• Kopia 포럼: Backblaze - b2 vs s3
• Kopia 포럼: iDrive e2 works well with Kopia
• Backblaze B2 Pricing Explained (October 2026) – Upstash
• AWS S3 Pricing Explained (2026) – Upstash
• Amazon S3 Pricing Guide (2026) – CloudForecast