전송 후 파일이 손상됐나요? 데이터 손실 예방 방법

현대 HTTPS 기반 서비스에서 전송 후 파일 손상은 드뭅니다. TCP 체크섬, TLS 1.3 무결성, AES-GCM 인증 태그가 전송 중 비트 오류를 모두 잡아내기 때문입니다. 손상이 발생한다면 대부분 엔드포인트에서 생깁니다: 부분 파일을 기록한 중단된 다운로드, 쓰기 중 디스크 오류, 또는 스트림을 잘라내는 클라이언트 버그. 양쪽에서 SHA-256 해시로 검증하세요. 해시가 일치하면 파일은 동일합니다. 일치하지 않으면 재전송합니다. AES-256-GCM을 사용하는 서비스는 무결성 검사가 내장되어 있어, 복호화 성공 자체가 무결성 증명입니다.

전송 중 손상이 드문 이유

모든 HTTPS 요청은 TLS 무결성 검사를 포함합니다. AES-256-GCM이나 ChaCha20-Poly1305 같은 AEAD 암호를 사용하는 TLS 1.3은 레코드별로 인증 태그를 생성합니다. 전송 중 비트가 뒤집히면 태그 검증이 실패하고 애플리케이션에 도달하기 전에 레코드가 거부됩니다. TCP는 세그먼트별로 자체 16비트 체크섬을 추가합니다. 두 검사를 통과하는 무음 손상의 확률은 TLS만으로도 약 2^128분의 1로 천문학적으로 낮습니다.

암호화되지 않은 프로토콜(FTP, 일반 HTTP)은 덜 견고합니다. TCP 체크섬은 일부 오류를 놓칩니다. 불량 RAM이 있는 중간 하드웨어에서 비트가 조용히 뒤집힐 수 있습니다. 이것이 자격 증명 유출 문제 외에도 대용량 전송에 일반 FTP를 피해야 할 실질적인 이유입니다.

손상이 실제로 발생하는 곳

전송 후 손상의 일반적인 원인을 빈도 순으로 정리합니다.

연결 끊김으로 인한 부분 파일 저장. 75%에서 연결을 잃은 브라우저 다운로드는 "현재 있는" 것처럼 보이지만 열리면 깨진 75% 완성 파일을 저장하는 경우가 많습니다. Chrome과 Firefox는 이제 대부분 이를 .crdownload나 .part로 플래그하지만 구형 버전과 일부 서드파티 관리자는 그렇지 않습니다.

로컬 디스크 쓰기 오류. 고장 나는 외장 드라이브, 가득 찬 디스크, 또는 불량 섹터는 파일을 부분적으로 쓰게 합니다. Windows는 항상 이를 명확하게 표시하지 않습니다. macOS는 때로 표시합니다.

안티바이러스 격리로 인한 파일 수정. 실시간 AV가 실행 파일 섹션을 제거하거나 "위생처리"를 위해 다운로드 도중 아카이브를 수정하여 파일이 기술적으로는 존재하지만 논리적으로는 손상되는 경우가 있습니다.

스트림을 잘라내는 클라이언트 버그. 잘 유지된 클라이언트에서는 드물지만, 일부 레거시 FTP 클라이언트, 구형 SyncToy 버전, 또는 커스텀 업로드 스크립트는 알려진 잘라내기 버그가 있습니다.

SHA-256 해시로 검증하세요

파일이 온전히 전송됐다는 것을 증명하는 유일한 신뢰할 수 있는 방법은 양쪽에서 암호화 해시를 계산하여 비교하는 것입니다. SHA-256은 보편적이고, 빠르며(AES-NI를 사용하는 현대 CPU에서 500MB/s), 충돌 저항성이 있습니다.

macOS/Linux: shasum -a 256 file.mov. Windows 10+: certutil -hashfile file.mov SHA256. 둘 다 64자 16진수 문자열을 생성합니다. 링크와 함께 해시를 전송하세요("SHA256: a1b2c3...") 그러면 수신자가 다운로드 후 검증할 수 있습니다.

해시가 일치하면 파일은 비트 단위로 동일합니다. 다르다면 재전송하세요.

AES-GCM이 무결성을 무료로 제공합니다

AES-256-GCM(연관 데이터가 있는 인증 암호화)으로 암호화하는 서비스는 모든 블록에 인증 태그를 포함합니다. 수신자가 복호화할 때 태그 검증 실패는 암호문이 변조되거나 손상됐음을 의미하며, 복호화는 "GCM authentication failed" 같은 오류와 함께 하드 실패합니다.

이는 파일이 성공적으로 복호화된다면 수정되지 않은 것이 보장된다는 의미입니다. 수신자 측에서 별도의 SHA-256 검사가 필요하지 않습니다. HexaTransfer, Smash의 Secure 모드, SwissTransfer, Tresorit Send, Proton Drive가 모두 바로 이 이유로 AES-GCM 또는 XChaCha20-Poly1305(유사한 인증 모드)를 사용합니다.

부분 다운로드 감지

부분 다운로드의 명확한 신호: 디스크의 파일 크기가 전송 페이지가 표시한 크기보다 작습니다. 다운로드된 파일을 우클릭하고 크기를 확인하여 발신자의 보고 크기와 비교하세요. 일치하지 않으면 다운로드가 완료되지 않은 것입니다.

미디어 파일은 이를 잘 드러냅니다. 부분 MP4는 1분 재생 후 끊깁니다. 부분 ZIP은 추출 시 "아카이브가 손상되었습니다"를 반환합니다. 부분 PDF는 처음 몇 페이지를 표시한 후 오류가 납니다. 텍스트 파일은 종종 정상적으로 열리지만 조용히 잘려있어 가장 최악의 경우 알아차리지 못합니다.

불안정한 연결을 위한 재개 가능한 다운로드

수신자의 연결이 다운로드 중 끊긴다면 재개 지원이 중요합니다. HTTP range 요청(RFC 7233)은 클라이언트가 오프셋에서 재시작할 수 있게 합니다. curl은 -C -, wget은 -c로 처리합니다. 브라우저 기반 다운로드 관리자는 서버가 범위를 지원하면 동일 세션 내에서 Firefox와 Chrome이 재개합니다.

일반 POST를 사용하거나 Range 헤더를 노출하지 않는 서비스는 끊김 시 전체 재시작을 강제합니다. 20Mbps 셀룰러로 10GB 파일을 받는 경우에는 매우 힘든 상황입니다.

미디어별 검증 도구

비디오 파일: ffprobe -v error file.mp4는 오류를 조용히 보고합니다. 출력이 비어 있으면 컨테이너 구조가 온전합니다. 심층 확인은 ffmpeg -v error -i file.mp4 -f null -로 모든 프레임을 순회하며 디코드 오류를 보고합니다.

PDF: Acrobat의 "유효성 검사" 명령이 개체 구조를 확인합니다. qpdf --check file.pdf가 명령줄에서 동일한 작업을 합니다.

아카이브: unzip -t file.zip과 7z t file.7z는 추출 없이 테스트합니다. 빠르고 대부분의 손상을 잡아냅니다.

무결성이 내장된 서비스를 선택하세요

중요한 전송에는 암호화 무결성을 설계로 제공하는 서비스를 선택하세요. 엔드투엔드 AES-GCM 암호화, 다운로드 페이지의 SHA-256 해시 표시, 또는 클라이언트의 명시적 체크섬 검증 모두 희망 대신 증명을 제공합니다. HexaTransfer는 AES-256-GCM을 사용하므로 성공적인 복호화 자체가 파일이 변경되지 않았음을 검증하며, 전송당 10GB 한도는 대부분의 전문 납품물을 커버합니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.