CRC 계산기

이 도구는 무엇인가요?

CRC는 Cyclic Redundancy Check(순환 중복 검사)의 약자로, 1975년 W. Wesley Peterson과 D.T. Brown의 논문에서 처음 기술된 오류 검출 코드이며, 이후 Ross Williams의 「A Painless Guide to CRC Error Detection Algorithms」와 ITU-T/ISO 3309 표준과 같은 문헌에서 공식화되었습니다. CRC는 메시지를 하나의 큰 이진수로 취급하고 이를 고정된 생성 다항식으로 나눕니다. 이 나눗셈의 나머지가 체크섬이 됩니다. 다항식 나눗셈은 하드웨어와 소프트웨어 모두에서 계산 비용이 저렴하기 때문에, CRC는 저장 및 전송 시스템에서 기본적인 오류 검사 방식이 되었습니다.

CRC-32——구체적으로는 다항식 0xEDB88320, 초기값 0xFFFFFFFF, 최종 XOR 0xFFFFFFFF를 사용하는 변형——은 IEEE 802.3(이더넷)에서 표준화되어 있으며, ZIP과 gzip 아카이브, PNG 이미지 파일, 그리고 수많은 네트워크 및 저장 프로토콜 내부의 체크섬으로 사용됩니다. 가장 널리 요청되는 CRC 변형이기 때문에 이 도구의 기본 알고리즘으로 설정되어 있습니다. CRC-16/CCITT-FALSE(다항식 0x1021)와 CRC-16/MODBUS(다항식 0x8005, 반전)는 Modbus RTU, XMODEM 등 다양한 임베디드/산업용 통신 표준과 같은 시리얼 프로토콜에서 널리 사용되는 두 가지 16비트 변형입니다.

CRC가 무엇이 아닌지 이해하는 것이 중요합니다. CRC는 암호학적 해시가 아닙니다. CRC는 빠르고 선형적인 함수로, 의도적인 조작에 대한 저항성이 전혀 없습니다. 동일한 CRC 값을 생성하는 다른 메시지를 만드는 것은 어렵지 않습니다. CRC는 잡음이 많은 전송 회선, 디스크 오류, 잘린 다운로드 등으로 인한 무작위 비트 반전을 잡아내는 데는 뛰어나지만, 데이터를 몰래 변조하려는 공격자로부터는 전혀 보호해주지 못합니다.

왜 사용해야 할까요?

• 공장 전력 모니터링 시스템의 Modbus RTU 모듈을 디버깅 중인데 PLC가 보낸 프레임이 체크섬 오류로 수신 장치에서 거부될 때 — 프레임 페이로드를 CRC-16/MODBUS로 여기에 입력해 직접 계산한 값이 표준과 일치하는지 확인해보세요.
• XMODEM으로 통신하는 국산 IoT 기기용 펌웨어를 개발 중인데 C 코드의 CRC-16/CCITT-FALSE 결과가 참조 라이브러리와 다를 때 — 같은 입력값을 여기 붙여넣어서 초기값 설정이 문제인지 비트 반전 순서가 문제인지 원인을 좁혀보세요.
• 회사 네트워크로 대용량 ZIP 파일을 다운로드했는데 연결이 불안정해서 파일이 손상됐을까 걱정될 때, 프로덕션 서버에 압축을 풀기 전에 — 여기서 파일의 CRC-32를 확인하고 동료가 슬랙으로 보낸 체크섬과 비교해보세요.
• 커스텀 PNG 파서를 만들고 있는데 특정 청크가 계속 CRC 검증에 실패할 때 — 해당 청크의 원시 바이트로 CRC-32를 다시 계산해서 문제가 원본 파일이 아니라 내 파싱 로직에 있는지 확인해보세요.
• 다항식 나눗셈으로 CRC를 직접 계산해야 하는 네트워크 자격증 시험이나 데이터통신 과목 과제를 풀 때 — 손으로 계산하면 XOR 단계에서 실수하기 쉬우니, 제출 전에 이 도구로 답을 검증해보세요.
• 팀에서 자체 제작 체크섬을 마이크로서비스 간 통신 프로토콜용 CRC-32 IEEE 802.3 표준으로 전환하는 중일 때 — 샘플 페이로드 몇 개를 여기 붙여넣어 양쪽 유닛 테스트의 기준이 될 참조값을 생성해보세요.

사용 방법

1. "텍스트" 탭을 선택해 입력을 붙여넣거나 입력하거나, "파일" 탭으로 전환해 기기에서 파일을 선택하세요.
2. CRC 알고리즘을 선택하세요: CRC-32(IEEE 802.3, 기본값이자 가장 일반적), CRC-16/CCITT-FALSE, 또는 CRC-16/MODBUS.
3. 체크섬이 자동으로 업데이트되며 16진수, 10진수, 2진수로 표시됩니다.
4. 결과 옆의 "복사"를 클릭하면 클립보드에 복사됩니다.

예시

입력

123456789

결과

0xCBF43926 (3421780262)

이것은 표준으로 공개된 CRC-32(IEEE 802.3) 테스트 벡터입니다. ASCII 문자열 "123456789"의 CRC-32는 항상 0xCBF43926입니다. 이 정확한 문자열을 사용해 다른 올바른 CRC-32 구현과 이 도구의 출력을 비교해볼 수 있습니다.

CRC와 암호학적 해시(MD5 / SHA) 비교

CRC와 암호학적 해시는 모두 데이터를 고정 크기의 지문으로 축소하지만, 서로 다른 문제를 해결하며 상호 교환할 수 없습니다.

관련 도구

오류 검출용 CRC가 아니라 암호학적 체크섬이 필요하다면 아래 도구들이 더 적합합니다.

→ 멀티 알고리즘 해시 생성기 · MD5 생성기 · HMAC 생성기

가장 흔한 CRC 오류 디버깅하기

CRC를 직접 구현할 때 가장 흔한 실수는 다항식 나눗셈 공식 자체가 아니라 자주 간과되는 세 가지 추가 매개변수에서 나옵니다: 레지스터 초기값(init value), 입력·출력 비트 반전 여부(reflected in/out), 그리고 계산 마지막에 적용하는 XOR 값입니다. 두 구현이 완전히 같은 다항식을 쓰더라도 이 세 매개변수 중 하나라도 맞지 않으면 체크섬이 달라집니다.

C, Python 등으로 CRC를 직접 구현하고 있다면, 정확성을 가장 빨리 확인하는 방법은 표준 테스트 벡터를 이용하는 것입니다. ASCII 문자열 "123456789"는 CRC-32 IEEE 802.3에서 항상 0xCBF43926이 나와야 합니다. 구현 결과가 이 값과 다르다면 다항식 나눗셈 로직보다는 앞서 말한 세 가지 숨은 매개변수 중 하나에 문제가 있을 가능성이 큽니다.

Modbus RTU 같은 시리얼 프로토콜에서는 프레임에 담기는 체크섬 바이트의 전송 순서도 흔한 버그 원인입니다. CRC-16/MODBUS는 하위 바이트를 먼저, 상위 바이트를 나중에 보내는 리틀 엔디안 순서를 쓰는데, 이는 보통 헥사값을 빅 엔디안으로 쓰는 습관과 다릅니다. CRC 값 자체는 맞는데 프레임이 계속 거부된다면 전송 바이트 순서부터 확인해보세요.

자주 묻는 질문