체크섬 — CRC32와 SHA-256, 무엇을 언제 쓰나

체크섬은 데이터를 짧은 고정 길이 값으로 압축해, 전송이나 저장 중에 내용이 바뀌었는지 검증하는 장치다. CRC32는 우연한 오류(비트 뒤집힘) 검출에, SHA-256은 의도적 위변조 방지와 무결성 증명에 쓴다. 둘은 이름만 비슷할 뿐 목적과 안전성이 완전히 다르다.

이 둘을 혼동하면 큰일 난다. 나는 파일 다운로드 검증에 CRC32를 쓰려다 리뷰에서 지적받은 적이 있다. "그건 공격자를 못 막는다"는 한마디에 정신이 들었다. 그날 이후로 "실수 검출"과 "위변조 방지"를 분명히 구분하게 됐다.

CRC32 — 빠른 오류 검출용

CRC(순환 중복 검사)는 데이터를 다항식으로 나눈 나머지를 체크섬으로 삼는다. 계산이 아주 빠르고 하드웨어 가속도 흔해서, 통신 프레임이나 압축 파일(zip, gzip), 저장 매체에서 우연히 발생한 비트 오류를 잡는 데 널리 쓰인다.

# 리눅스에서 CRC32 계산
$ cksum data.bin
2352755680 1048576 data.bin
#  ^체크섬     ^바이트 수
# gzip은 내부에 CRC32를 담아 압축 해제 시 검증한다

하지만 CRC32는 암호학적으로 안전하지 않다. 원하는 체크섬이 나오도록 데이터를 조작하는 게 수학적으로 쉽다. 즉 공격자가 파일을 바꾸면서도 CRC를 똑같이 맞출 수 있다. 그래서 CRC는 "실수로 깨졌나?"에는 답하지만 "누가 일부러 바꿨나?"에는 답 못 한다.

SHA-256 — 위변조까지 막는 해시

SHA-256은 암호학적 해시 함수다. 입력이 조금만 달라도 출력이 완전히 뒤바뀌고(눈사태 효과), 같은 해시가 나오는 다른 입력을 일부러 만들어내는 게 계산상 불가능하다. 이 성질(충돌 저항성) 덕에 배포 파일 검증, 서명, 블록체인, Git 객체 식별 등에 쓰인다.

$ sha256sum ubuntu.iso
e4b3...c9f1  ubuntu.iso
# 배포처가 공개한 값과 비교해 위변조 여부 확인
$ echo "e4b3...c9f1  ubuntu.iso" | sha256sum -c
ubuntu.iso: OK

다운로드 페이지가 SHA-256 값을 함께 공개하는 이유가 이것이다. 중간에서 파일이 바뀌면 해시가 달라져 즉시 들통난다.

정면 비교

그럼 뭘 언제 쓰나

• 내부 데이터가 전송 중 깨졌나만 확인: CRC32면 충분하고 빠르다. 신뢰할 수 있는 환경 안에서의 오류 검출이 목적일 때.
• 외부에서 받은 파일이 진짜인가 증명: SHA-256을 쓴다. 공급망·다운로드·배포 검증은 예외 없이.
• 비밀번호 저장: 둘 다 아니다. 이건 bcrypt·argon2 같은 느린 전용 해시를 써야 한다. SHA-256은 너무 빨라 무차별 대입에 취약하다.

개인적으로 기준을 이렇게 정리해 뒀다. "적이 없는 오류 검출은 CRC, 적이 있는 무결성은 SHA, 사람이 정한 비밀은 argon2." 세 문제를 하나의 도구로 풀려다 매번 사고가 났다.

체크섬은 오류를 고치지 못한다

한 가지 흔한 오해를 짚고 가자. 체크섬은 "깨졌는지"를 탐지할 뿐, 깨진 걸 복구하지는 못한다. CRC32든 SHA-256이든 마찬가지다. 값이 안 맞으면 "이 데이터는 신뢰할 수 없다"까지만 알려준다. 그다음은 재전송이나 재다운로드로 해결해야 한다. 실제로 오류를 정정까지 하려면 해밍 코드나 리드-솔로몬 같은 오류 정정 부호(ECC)가 필요하고, 이건 체크섬과는 다른 영역이다. 나는 이 둘을 처음에 뭉뚱그렸다가, "체크섬 넣었으니 데이터 안전하다"고 착각해 재시도 로직을 빼먹은 적이 있다.

MD5는 왜 빼놨나

MD5·SHA-1도 여전히 보인다. 하지만 둘은 충돌을 실제로 만들어내는 공격이 나와 있어서, 보안 목적으론 이미 폐기 대상이다. 단순 캐시 키나 중복 파일 탐지처럼 공격자가 없는 상황에서만 남겨 쓰고, 무결성 증명엔 SHA-256 이상을 쓰는 게 맞다.

자주 묻는 질문

CRC32로 다운로드 파일을 검증해도 되나요?

안전하지 않습니다. CRC32는 우연한 비트 오류는 잘 잡지만, 공격자가 파일을 바꾸면서 체크섬을 똑같이 맞추기가 쉽습니다. 외부에서 받은 파일의 진위를 검증하려면 SHA-256처럼 충돌 저항성이 있는 암호학적 해시를 써야 합니다.

SHA-256이 있는데 CRC32는 왜 아직 쓰나요?

속도와 목적이 다르기 때문입니다. 이더넷 프레임이나 zip 압축처럼 초당 막대한 데이터에서 우연한 오류만 걸러내면 되는 곳에서는 훨씬 빠른 CRC32가 적합합니다. 보안이 목적이 아닌 오류 검출에는 굳이 무거운 암호 해시를 쓸 이유가 없습니다.

비밀번호도 SHA-256으로 해시하면 되나요?

안 됩니다. SHA-256은 의도적으로 빠르게 설계돼 무차별 대입 공격에 취약합니다. 비밀번호는 bcrypt, scrypt, argon2처럼 계산 비용을 조절할 수 있는 느린 전용 해시로 솔트와 함께 저장해야 합니다.

MD5는 이제 쓰면 안 되나요?

보안 용도로는 쓰면 안 됩니다. MD5와 SHA-1은 충돌을 실제로 생성하는 공격이 공개돼 무결성·서명 목적에는 부적합합니다. 다만 공격자가 개입할 수 없는 캐시 키나 중복 탐지 같은 비보안 용도로는 속도 때문에 여전히 사용되기도 합니다.