RcloneView에서 클라우드 동기화 체크섬 불일치 오류 해결하기
클라우드 동기화 중 발생하는 체크섬 불일치는 대부분 데이터가 손상되었다는 의미가 아니라, 소스와 대상이 서로 다른 해시 알고리즘을 사용한다는 의미입니다. 이를 진단하고 해결하는 방법을 안내합니다.
rclone이 클라우드 제공자 간에 파일을 동기화할 때는 전송된 데이터가 원본과 일치하는지 확인하기 위해 체크섬을 비교합니다. 소스와 대상 제공자가 서로 다른 해시 알고리즘을 사용하거나, 한쪽 제공자가 체크섬을 전혀 반환하지 않는 경우 rclone은 불일치를 보고하거나 불필요하게 파일을 재전송할 수 있습니다. 이 가이드에서는 이러한 현상이 발생하는 이유와 RcloneView에서 해결하는 방법을 설명합니다.

모든 클라우드를 한 곳에서 관리하고 동기화하세요
RcloneView는 rclone의 크로스플랫폼 GUI입니다. 폴더를 비교하고, 파일을 전송·동기화하고, 깔끔한 시각적 인터페이스로 멀티 클라우드 워크플로를 자동화하세요.
- 원클릭 작업: 복사 · 동기화 · 비교
- 안정적인 자동화를 위한 스케줄러와 작업 이력
- Google Drive, OneDrive, Dropbox, S3, WebDAV, SFTP 등 지원
핵심 기능은 무료. Plus로 자동화 기능 이용 가능.
체크섬 불일치의 의미
체크섬(또는 해시)은 파일 내용으로부터 계산된 고정 길이 문자열입니다. 두 파일이 동일한 체크섬을 생성하면 두 파일은 동일합니다. rclone은 다음과 같은 목적으로 체크섬을 사용합니다:
- 업로드 검증 — 전송 후 대상 파일이 소스와 일치하는지 확인합니다.
- 변경 감지 — 동기화 중 체크섬과 크기가 변경되지 않은 파일은 건너뜁니다.
- 무결성 보장 — 파일의 해시가 예상과 다르면 손상으로 표시합니다.
불일치란 한쪽에서 계산된 해시가 다른 쪽과 일치하지 않는다는 뜻입니다. 실제 데이터 손상을 나타낼 수도 있지만, 더 흔한 경우는 제공자 간의 해시 알고리즘 비호환성을 반영하는 것입니다.
제공자별 해시 차이
클라우드 제공자마다 지원하는 해시 알고리즘이 다릅니다:
| 제공자 | 지원 해시 |
|---|---|
| 로컬 디스크 | MD5, SHA-1, SHA-256 (OS에 따라 다름) |
| Google Drive | MD5 |
| OneDrive | SHA-1, QuickXorHash |
| Dropbox | Dropbox 콘텐츠 해시 (커스텀) |
| Amazon S3 | MD5 (ETag, 단 멀티파트 업로드는 제외) |
| Backblaze B2 | SHA-1 |
| Azure Blob | MD5 |
| SFTP | MD5, SHA-1 (서버가 지원하는 경우) |
| Wasabi | MD5 (ETag) |
| Cloudflare R2 | MD5 (ETag) |
공통 해시를 공유하는 제공자 간에 동기화할 경우(예: Google Drive MD5와 Azure Blob MD5), 체크섬이 원활하게 작동합니다. 공통 해시가 없는 경우(예: Google Drive MD5와 OneDrive QuickXorHash), rclone은 체크섬을 직접 비교할 수 없습니다.
rclone이 불일치하는 해시를 처리하는 방법
rclone은 해시 비교에 있어 지능적으로 동작합니다:
- 공통 해시 발견 — rclone은 공유된 알고리즘을 사용하여 파일을 비교합니다. 문제 없음.
- 공통 해시 없음 — rclone은 파일 크기와 수정 시간 비교로 대체합니다. 크기와 시간이 일치하는 파일은 동일한 것으로 간주됩니다.
--checksum플래그 활성화 — rclone은 시간 비교 없이 체크섬만 사용합니다. 공통 해시가 없으면 일치 여부를 확인할 수 없으므로 rclone은 모든 파일을 재전송합니다.
이 세 번째 시나리오가 예기치 않은 동작의 가장 흔한 원인입니다: 호환되지 않는 제공자 간에 --checksum을 활성화하면 불필요한 재전송이 강제로 발생합니다.
일반적인 오류 시나리오
시나리오 1: S3 멀티파트 업로드 ETag 불일치
멀티파트 업로드를 사용하여 큰 파일을 S3에 업로드하면 결과로 생성되는 ETag는 단순한 MD5 해시가 아니라 각 파트의 합성 해시입니다. rclone이 계산한 파일의 로컬 MD5는 S3 ETag와 일치하지 않으며, 다음 동기화 시 불일치가 발생합니다.
해결 방법: 이는 예상된 동작입니다. rclone은 가능한 경우 예상 해시를 메타데이터에 저장하여 이를 처리합니다. 큰 파일이 재전송되는 것이 보인다면, 해당 동기화 작업에 한해 --ignore-checksum을 안전하게 사용할 수 있습니다.
시나리오 2: Google Drive에서 OneDrive로 동기화
Google Drive는 MD5를 사용하고 OneDrive는 QuickXorHash를 사용합니다. 겹치는 해시 알고리즘이 없습니다.
해결 방법: rclone은 자동으로 크기 + 수정 시간 비교로 대체합니다. 이 조합에는 --checksum을 사용하지 마세요. 그렇지 않으면 모든 파일이 재전송됩니다.
시나리오 3: 암호화된(Crypt) 리모트
rclone crypt를 사용할 때 암호화된 파일은 평 문 소스와 다른 해시를 갖습니다. rclone은 내부적으로 이를 처리하지만, crypt 리모트의 해시를 원본 제공자의 해시와 직접 비교하면 절대 일치하지 않습니다.
해결 방법: 항상 암호화된 스토리지를 직접 보는 것이 아니라, crypt 리모트 레이어를 통해 파일을 비교하세요.
RcloneView에서 체크섬 동작 구성하기
--checksum 플래그 사용하기
--checksum 플래그는 파일 전송 필요 여부를 판단할 때 rclone이 수정 시간이 아닌 체크섬만 사용하도록 지시합니다. 다음의 경우 활성화하세요:
- 소스와 대상이 동일한 해시 알고리즘을 지원하는 경우.
- 가장 강력한 무결성 보장을 원하는 경우.
- 로컬 디스크와 MD5를 지원하는 제공자 간에 동기화하는 경우.
다음의 경우에는 사용하지 마세요:
- 소스와 대상에 공통 해시가 없는 경우 — 모든 파일의 재전송이 강제됩니다.
- 큰 파일을 S3로 동기화하는 경우 (멀티파트 ETag가 일치하지 않습니다).
--ignore-checksum 플래그 사용하기
--ignore-checksum 플래그는 모든 체크섬 검증을 건너뜁니다. 다음의 경우 사용하세요:
- 데이터가 올바르다는 것을 확인했지만 체크섬이 절대 일치하지 않는 경우 (예: S3 멀티파트 ETag).
- 매우 큰 데이터셋에서 해시 계산을 건너뛰어 더 빠른 동기화를 원하는 경우.
- 제공자가 일관되지 않거나 잘못된 해시를 반환하는 경우 (드물지만 가능함).
기본값으로 사용하지는 마세요 — 체크섬은 실제 손상을 감지하기 위해 존재합니다.
데이터 무결성 확인하기
해시 알고리즘 불일치가 아닌 실제 손상이 의심되는 경우:
rclone check실행 — 소스와 대상 파일을 비교하고 차이점을 보고합니다. RcloneView에서는 폴더 비교 화면을 사용할 수 있습니다.- 다운로드하여 로컬에서 비교 — 소스와 대상 양쪽에서 파일을 다운로드한 다음
md5sum또는sha256sum으로 로컬 체크섬을 계산합니다. - 전송 로그 확인 — 원본 전송 중 발생한 오류에 대해 RcloneView의 작업 기록을 검토합니다.
빠른 참조: 해시 호환성 매트릭스
| 동기화 방향 | 공통 해시 | 체크섬 플래그 안전 여부 |
|---|---|---|
| 로컬 → Google Drive | MD5 | 예 |
| 로컬 → OneDrive | SHA-1 | 예 |
| 로컬 → S3 (작은 파일) | MD5 | 예 |
| 로컬 → S3 (멀티파트) | 없음 (ETag가 다름) | 아니오 |
| Google Drive → OneDrive | 없음 | 아니오 |
| Google Drive → S3 | MD5 | 예 (작은 파일) |
| S3 → Backblaze B2 | 없음 (MD5 대 SHA-1) | 아니오 |
| S3 → Azure Blob | MD5 | 예 (작은 파일) |
시작하기
- rcloneview.com에서 RcloneView를 다운로드하세요.
- 위 표를 사용하여 사용 중인 제공자의 해시 지원 여부를 확인하세요.
- 불필요한 재전송을 방지하기 위해 호환되지 않는 제공자 간에는
--checksum사용을 피하세요. - RcloneView에서 폴더 비교 기능을 사용하여 동기화 결과를 시각적으로 확인하세요.
대부분의 체크섬 불일치 오류는 데이터 손상이 아니라 제공자 간 해시 알고리즘 불일치입니다. 각 제공자가 지원하는 해시를 이해하는 것이 이러한 문제를 빠르게 해결하는 핵심입니다.
관련 가이드: