Checksum과 CRC 차이: 장비 통신에서 데이터 오류를 검출하는 방법

Checksum과 CRC 차이: 장비 통신에서 데이터 오류를 검출하는 방법#

1장 Packet 길이는 정상인데 왜 장비가 데이터를 버릴까#

장비 Log에 다음과 같은 기록이 있다고 하겠습니다.

RX FRAME
01 03 00 00 00 02 C4 0B

RESULT
CRC ERROR

Packet의 길이는 정상입니다.

Address도 있어 보이고 Command도 들어 있습니다.

그런데 장비는 데이터를 처리하지 않습니다.

이런 상황에서 중요한 질문은 다음입니다.

전송된 Byte와
수신된 Byte가
정말 같은가?

Cable을 통해 Data가 이동하는 동안:

Noise

Signal Reflection

Collision

Baud 설정 오류

Buffer 문제

등으로 일부 Bit가 변할 수 있기 때문입니다.

Checksum과 CRC는 바로 이 문제를 확인하기 위해 사용합니다.

---

2장 오류 검출값은 Packet의 지문과 비슷하다#

송신할 Data가 다음과 같다고 하겠습니다.

10 20 30 40

송신 측은 이 Data를 이용해 검사값을 계산합니다.

DATA
10 20 30 40

↓ 계산

CHECK
A0

그리고 함께 전송합니다.

10 20 30 40 A0

수신 측에서도 같은 Data를 이용해 다시 계산합니다.

10 20 30 40

↓ 동일한 계산

A0

Packet 안에 들어 있던 값과:

A0

다시 계산한 값이 같다면 정상으로 판단할 수 있습니다.

---

3장 전송 중 Byte 하나가 바뀌면 어떻게 될까#

송신:

10 20 30 40

이었는데 Noise 때문에 수신 Data가:

10 20 31 40

으로 바뀌었다고 하겠습니다.

수신 측에서 다시 검사값을 계산하면 기존 값과 달라질 수 있습니다.

Packet Check
A0

Calculated Check
A1

결과:

CHECK ERROR

가 됩니다.

즉 Checksum과 CRC의 핵심 목적은 전송 과정에서 Data가 손상되었는지 검출하는 것입니다.

---

4장 Checksum이란 무엇인가#

Checksum은 Data를 이용해 비교적 간단한 연산으로 검사값을 만드는 방법을 통칭합니다.

대표적으로:

Byte Sum

XOR

Complement

LRC

같은 방식이 있습니다.

중요한 점은:

Checksum
=
한 가지 고정 Algorithm

이 아니라는 것입니다.

Protocol 문서에서 어떤 방식을 사용하는지 확인해야 합니다.

---

5장 가장 단순한 합산 Checksum#

다음 Data가 있다고 하겠습니다.

01 02 03 04

모든 Byte를 더합니다.

01 + 02 + 03 + 04
=
0A

따라서 단순한 방식에서는:

Checksum = 0x0A

가 될 수 있습니다.

Frame:

01 02 03 04 0A

처럼 구성할 수 있습니다.

---

5.1 1 Byte Checksum에서는 Overflow를 어떻게 처리할까#

예를 들어:

F0 + 30
=
120

Hexadecimal로:

0x120

입니다.

Checksum을 1 Byte로 저장한다면 Protocol에 따라 하위 8 Bit만 사용할 수 있습니다.

0x20

하지만 다른 Protocol은:

Complement

Carry 처리

Modulo 연산

등 다른 규칙을 사용할 수 있습니다.

따라서 단순히:

모두 더하면 된다.

고 생각하면 안 됩니다.

---

6장 XOR Checksum은 어떻게 계산할까#

XOR 방식에서는 각 Byte를 순서대로 XOR 합니다.

Data:

01 02 03

계산:

01 XOR 02
=
03

03 XOR 03
=
00

따라서:

Checksum = 00

이 됩니다.

XOR 방식은 구현이 간단하고 작은 MCU에서도 쉽게 계산할 수 있습니다.

---

6.1 XOR 방식의 한계#

XOR은 단순하고 빠르지만 오류 검출 능력에는 한계가 있습니다.

예를 들어 일부 특정 변화 패턴은 서로 상쇄되어 같은 결과를 만들 수 있습니다.

따라서 높은 신뢰성이 필요한 통신에서는 CRC 같은 더 강력한 오류 검출 방식을 사용하는 경우가 많습니다.

---

7장 Checksum은 암호화도 인증도 아니다#

중요한 구분입니다.

Checksum이 맞다는 것은:

전송 Data와 검사값의 관계가
Protocol 규칙에 맞는다.

는 의미입니다.

하지만:

누가 보냈는가?

허가된 장비인가?

누군가 의도적으로 내용을 변경했는가?

까지 증명하지는 않습니다.

따라서:

Checksum
≠
Authentication

Checksum
≠
Encryption

입니다.

---

8장 CRC란 무엇인가#

CRC는 Cyclic Redundancy Check의 약자입니다.

단순히 Byte를 더하는 대신 Data Bit를 하나의 긴 Bit Stream으로 보고 정해진 Polynomial을 이용해 계산합니다.

개념적으로:

Original Data
↓
CRC Algorithm
↓
Remainder
↓
CRC Value

형태입니다.

이 CRC 값을 Packet에 포함해 전송합니다.

---

9장 CRC를 왜 많이 사용할까#

CRC는 특히 다음과 같은 오류 검출에 강점을 가질 수 있습니다.

단일 Bit Error

여러 Bit Error

Burst Error

실제 검출 성능은 어떤 CRC Polynomial을 사용하는지와 Message Length 등에 따라 달라집니다.

그래서:

CRC-16

CRC-32

처럼 Bit 수만 보는 것보다 정확한 CRC Variant를 확인해야 합니다.

---

10장 CRC-16이라고 모두 같은 CRC가 아니다#

현장에서 가장 흔하게 생기는 문제 중 하나입니다.

문서에:

CRC-16

이라고만 적혀 있다고 하겠습니다.

개발자가 CRC-16 Library를 하나 골라 계산했습니다.

그런데 장비와 값이 다릅니다.

왜 그럴까요?

CRC 계산에는 여러 Parameter가 있기 때문입니다.

대표적으로:

Polynomial

Initial Value

Input Reflection

Output Reflection

Final XOR

Result Byte Order

등이 영향을 줍니다.

---

11장 Polynomial은 무엇인가#

CRC에서는 특정 생성 다항식을 사용합니다.

예를 들어 어떤 CRC Algorithm에서는:

0x8005

또는 이를 LSB-first 형태로 표현한:

0xA001

같은 값을 볼 수 있습니다.

하지만 이 숫자 하나만 같다고 동일한 CRC라고 볼 수 없습니다.

Initial Value와 Reflection 설정 등도 같아야 합니다.

---

12장 Initial Value도 결과를 바꾼다#

CRC Register를 계산 시작 전에 어떤 값으로 초기화할지 정해야 합니다.

예:

0x0000

또는:

0xFFFF

입니다.

같은 Data와 같은 Polynomial을 사용해도 Initial Value가 다르면 CRC 결과가 달라질 수 있습니다.

---

13장 Bit Reflection은 무엇인가#

일부 CRC는 Byte 내부 Bit 처리 순서를 반대로 다룹니다.

예:

원래

10110000

Reflection:

00001101

처럼 생각할 수 있습니다.

이런 설정은:

RefIn

RefOut

등으로 문서에 표시될 수 있습니다.

---

14장 Final XOR도 확인해야 한다#

CRC 계산 마지막에 결과에 특정 값을 XOR하는 Variant도 있습니다.

예:

Calculated CRC
1234

Final XOR
FFFF

Result
EDCB

처럼 달라질 수 있습니다.

따라서 CRC를 구현할 때는:

Polynomial만 확인

해서는 부족합니다.

---

15장 CRC Byte 순서도 다를 수 있다#

CRC 값이:

0x4B37

이라고 하겠습니다.

Packet에:

4B 37

순서로 넣을 수도 있고:

37 4B

순서로 넣을 수도 있습니다.

즉 계산 결과가 맞더라도 Packet에 삽입하는 Byte Order가 다르면 통신에 실패할 수 있습니다.

---

16장 CRC 계산 범위도 반드시 확인한다#

Packet:

02 01 10 03 41 42 43 CRC 03

이 있다고 하겠습니다.

CRC를 어디까지 계산해야 할까요?

Protocol에 따라:

01부터 Payload까지

일 수도 있고:

STX를 포함

할 수도 있습니다.

또는:

ETX 제외

처럼 정의될 수도 있습니다.

따라서 확인해야 합니다.

CRC Algorithm

CRC Parameters

CRC 계산 시작 위치

CRC 계산 종료 위치

---

17장 같은 Algorithm인데 CRC가 다르면 무엇부터 볼까#

개발자 A:

CRC = 4B37

장비:

CRC = 374B

라면 Algorithm 자체보다 먼저:

Byte Order

를 확인해볼 수 있습니다.

반대로 완전히 다른 값이라면:

Polynomial

Initial Value

Reflection

Final XOR

계산 범위

를 차례로 확인합니다.

---

18장 CRC 계산의 기본 흐름#

개념적인 과정은 다음과 같습니다.

Data 준비
↓
Initial Value 설정
↓
각 Byte 처리
↓
각 Bit 처리
↓
Polynomial 적용
↓
필요하면 Reflection
↓
Final XOR
↓
CRC 결과

실제 구현은 Algorithm에 따라 세부 동작이 달라집니다.

---

19장 LSB-first CRC-16 예제를 살펴보자#

교육용으로 다음 형태의 CRC 계산을 생각해볼 수 있습니다.

Initial Value
0xFFFF

Polynomial
0xA001

처리 방향
LSB-first

이 구성은 특정 산업 Protocol에서 볼 수 있는 형태와 유사합니다.

중요한 것은:

0xA001을 사용한다.

만 보고 모든 장비에 그대로 적용하지 않는 것입니다.

---

20장 Java로 CRC-16 계산해보기#

시험 환경에서 사용할 수 있는 기본 예입니다.

public static int crc16(byte[] data) {
    int crc = 0xFFFF;

    for (byte b : data) {
        crc ^= b & 0xFF;

        for (int i = 0; i < 8; i++) {
            if ((crc & 0x0001) != 0) {
                crc = (crc >>> 1) ^ 0xA001;
            } else {
                crc >>>= 1;
            }
        }
    }

    return crc & 0xFFFF;
}

이 코드는 특정 Parameter 조합의 예입니다.

실제 장비에 적용하기 전에 제조사 Protocol 문서와 Known Test Vector를 이용해 결과를 검증해야 합니다.

---

21장 C#으로 CRC-16 계산해보기#

public static ushort Crc16(byte[] data)
{
    ushort crc = 0xFFFF;

    foreach (byte b in data)
    {
        crc ^= b;

        for (int i = 0; i < 8; i++)
        {
            if ((crc & 0x0001) != 0)
                crc = (ushort)((crc >> 1) ^ 0xA001);
            else
                crc >>= 1;
        }
    }

    return crc;
}

이 역시 교육용 예제이며 장비 Protocol의 CRC Variant와 일치하는지 반드시 확인해야 합니다.

---

22장 Python으로 CRC-16 계산해보기#

def crc16(data: bytes) -> int:
    crc = 0xFFFF

    for b in data:
        crc ^= b

        for _ in range(8):
            if crc & 0x0001:
                crc = (crc >> 1) ^ 0xA001
            else:
                crc >>= 1

    return crc & 0xFFFF

테스트할 때는 임의의 Packet보다 제조사가 제공한:

Input Data

Expected CRC

조합을 사용하는 것이 좋습니다.

---

23장 Known Test Vector가 중요한 이유#

Protocol 문서에 다음처럼 적혀 있다고 하겠습니다.

DATA:
01 03 00 00 00 02

CRC:
C4 0B

이런 Sample은 매우 중요합니다.

내 CRC 구현에 같은 Data를 넣었을 때 동일한 결과가 나오는지 비교할 수 있기 때문입니다.

만약 결과가 다르면 실제 장비에 연결하기 전에 Algorithm 설정부터 다시 확인할 수 있습니다.

---

24장 Modbus RTU에서는 CRC를 어떻게 사용할까#

Modbus RTU는 대표적으로 CRC-16을 사용하는 Protocol입니다.

Frame은 개념적으로:

Address
↓
Function
↓
Data
↓
CRC

형태입니다.

예:

01 03 00 00 00 02 C4 0B

이런 Frame을 볼 수 있습니다.

여기서 마지막 두 Byte가 CRC입니다.

Modbus RTU에서는 CRC 결과 Byte가 전송되는 순서도 확인해야 합니다.

---

25장 Checksum Error가 발생하면 무엇을 의미할까#

Application Log:

CHECKSUM ERROR

는 다음을 의미할 뿐입니다.

Packet 안의 검사값
≠
수신 Data로 다시 계산한 검사값

왜 다른지는 아직 알 수 없습니다.

가능한 원인은 매우 많습니다.

---

26장 CRC Error도 원인이 아니라 결과일 수 있다#

CRC Error의 원인 후보:

Noise

Cable 손상

A/B Polarity

Baud Rate 불일치

Parity 오류

Collision

Byte 누락

Parser Bug

CRC Algorithm 불일치

따라서:

CRC ERROR
↓
CRC Code 수정

으로 바로 가면 안 됩니다.

---

27장 Physical Layer 문제도 CRC Error를 만든다#

정상 송신:

01 03 00 00 00 02

Noise로 수신:

01 03 00 00 01 02

가 되었다고 하겠습니다.

수신 Application은 Frame 구조 자체는 정상처럼 볼 수 있습니다.

하지만 CRC를 계산하면 실패합니다.

이런 경우 CRC는 전기적 장애를 발견한 결과입니다.

---

28장 Baud Rate가 틀려도 CRC Error가 날 수 있다#

송신:

19200 baud

수신:

9600 baud

라면 Byte 자체가 제대로 복원되지 않을 수 있습니다.

그러면 Packet:

Address
Command
Data
CRC

가 모두 잘못 읽힐 수 있습니다.

따라서 CRC Error 발생 시 Serial Parameter도 확인해야 합니다.

---

29장 Collision도 CRC Error를 만들 수 있다#

2-Wire RS-485에서 두 장비가 동시에 Bus를 Drive한다고 하겠습니다.

Device A
───────┐
       ├── Bus
Device B
───────┘

두 Signal이 충돌하면 Receiver에서는 깨진 Byte를 읽을 수 있습니다.

결국 상위 Protocol에는:

CRC ERROR

로 나타날 수 있습니다.

---

30장 Packet이 잘렸는데 CRC만 검사하면 어떻게 될까#

정상 Frame:

01 03 00 00 00 02 C4 0B

수신:

01 03 00 00 00

처럼 일부만 들어왔다고 하겠습니다.

이 상태에서 CRC 검증부터 수행하면 안 됩니다.

먼저:

Minimum Frame Length

Length Field

Frame Boundary

를 검증해야 합니다.

권장 순서는:

Frame Length
↓
Header
↓
Length
↓
CRC
↓
Payload

입니다.

---

31장 Checksum이나 CRC가 맞아도 데이터가 옳다는 뜻은 아니다#

중요합니다.

Packet:

Device Address = 01
Command = OPEN
CRC = 정상

이라고 하겠습니다.

CRC가 정상이라는 것은:

수신한 Byte가
검사값과 일치한다.

는 뜻입니다.

하지만:

OPEN 명령 자체가 잘못된 명령인지

Device 01이 올바른 대상인지

사용자에게 권한이 있는지

는 판단하지 않습니다.

---

32장 CRC는 보안 기능이 아니다#

공격자가 Packet 구조와 CRC Algorithm을 알고 있다고 하겠습니다.

Data를 변경한 뒤 CRC를 다시 계산할 수 있습니다.

따라서:

CRC
≠
위조 방지

입니다.

보안 목적의 무결성 검증에는 상황에 따라:

MAC

HMAC

Digital Signature

Authenticated Encryption

같은 별도의 보안 기술이 필요합니다.

---

33장 CRC와 HMAC은 무엇이 다른가#

CRC:

목적
→ 우발적인 Data 손상 검출

HMAC:

목적
→ 비밀 Key를 이용한 Message 인증과 무결성 확인

입니다.

따라서:

CRC 정상

이라고 해서 신뢰할 수 있는 장비가 보낸 Packet이라는 뜻은 아닙니다.

---

34장 Checksum과 CRC 비교#

비교 항목	단순 Checksum	XOR Checksum	CRC
계산 구조	합산 등	XOR	Polynomial 기반
구현 난이도	낮음	매우 낮음	상대적으로 높음
계산 비용	낮음	낮음	높을 수 있음
오류 검출력	제한적	제한적	일반적으로 우수
Burst Error 대응	약함	약함	선택한 CRC에 따라 강함
Parameter 확인	계산법	범위	Polynomial·Init·Reflection 등
보안 기능	없음	없음	없음

---

35장 CRC-16과 CRC-32는 단순히 16 Bit와 32 Bit 차이일까#

기본적으로 결과 Width가 다릅니다.

CRC-16
→ 16 Bit

CRC-32
→ 32 Bit

하지만 어떤 CRC가 적절한지는 단순히 Bit 수만으로 결정하지 않습니다.

다음이 영향을 줍니다.

Message Length

필요한 오류 검출 특성

기존 Protocol

Hardware 지원

호환성

그리고 이미 정의된 Device Protocol에서는 개발자가 임의로 CRC 종류를 바꿀 수 없습니다.

---

36장 Packet에서 CRC 위치는 어디일까#

다음 구조가 흔합니다.

STX
↓
Address
↓
Command
↓
Length
↓
Payload
↓
CRC
↓
ETX

하지만 Protocol에 따라:

CRC
↓
ETX

일 수도 있고:

ETX
↓
CRC

일 수도 있습니다.

또 STX·ETX 자체가 없을 수도 있습니다.

따라서 Packet 구조를 먼저 확인합니다.

---

37장 Text Protocol에도 Checksum과 CRC를 사용할 수 있다#

예:

OPEN,DEV01*5A\r\n

처럼 Text Message 마지막에 Checksum을 붙일 수 있습니다.

또 ASCII로 CRC 값을 표현할 수도 있습니다.

예:

STATUS,01*4B37\r\n

즉 Checksum과 CRC는 Binary Protocol만의 기술이 아닙니다.

---

38장 Binary Protocol이라고 반드시 CRC를 쓰는 것도 아니다#

다음처럼:

Header

Length

Command

Payload

만 있는 Binary Protocol도 존재할 수 있습니다.

또는:

XOR Checksum

을 사용할 수도 있습니다.

따라서:

Binary
=
CRC

라는 공식은 없습니다.

---

39장 주차관제 현장에서는 CRC Error를 어떻게 볼까#

예를 들어 차량번호 인식 장비가 Controller에 Data를 보낸다고 하겠습니다.

Address
↓
Vehicle Event
↓
Timestamp
↓
Plate Data
↓
CRC

Controller에서:

CRC FAIL

이 발생합니다.

바로 LPR 장비 불량이라고 판단하지 않습니다.

확인:

Cable

Noise

Connector

Serial Setting

Gateway

Packet Parser

CRC Parameter

순으로 범위를 좁힙니다.

---

40장 특정 시간대에만 CRC Error가 늘어난다면#

예:

평상시
CRC Error 0

18:00~19:00
CRC Error 급증

주변 환경과 비교해봅니다.

Gate Motor 작동 증가

조명 점등

Inverter 가동

Traffic 증가

등과 관련될 수 있습니다.

이런 패턴은 CRC Algorithm 자체의 문제보다는 Physical Layer나 Collision 가능성을 살펴보게 하는 단서가 됩니다.

---

41장 장비 교체 후 CRC가 전부 틀린다면#

기존 장비:

Protocol v1

신규 장비:

Protocol v2

라고 하겠습니다.

Frame은 거의 같지만:

CRC Initial Value

CRC Range

Byte Order

가 달라졌을 수 있습니다.

장비 교체 후 모든 Frame이 일관되게 CRC 실패한다면 Firmware와 Protocol Version도 확인합니다.

---

42장 간헐적 CRC Error와 지속적 CRC Error를 구분한다#

모든 Packet이 CRC Error#

먼저 의심:

Algorithm 불일치

Initial Value 불일치

계산 범위 오류

Byte Order

Protocol Version

가끔 CRC Error#

먼저 의심할 수 있는 항목:

Noise

Collision

Cable

Connector

Reflection

Buffer 문제

물론 이것만으로 확정할 수는 없지만 진단 방향을 잡는 데 도움이 됩니다.

---

43장 Raw Packet을 반드시 남긴다#

다음 Log만 있다면:

CRC ERROR

원인을 찾기 어렵습니다.

가능하면:

2026-09-24 14:30:12.124

RX RAW:
01 03 00 00 00 02 C4 0A

CALCULATED CRC:
0BC4

RECEIVED CRC:
0AC4

RESULT:
CRC ERROR

처럼 남기는 것이 좋습니다.

---

44장 CRC Log에 어떤 정보를 같이 남길까#

추천 정보:

Timestamp

Device ID

Direction

Raw HEX

Frame Length

Received CRC

Calculated CRC

Error Type

입니다.

Serial 환경이라면:

Port

Baud Rate

Parity

등도 도움이 될 수 있습니다.

---

45장 개인정보가 있는 Payload는 그대로 저장하지 않는다#

Packet에:

차량번호

Card ID

회원번호

같은 정보가 있다면 Raw Packet Log 자체가 민감한 정보가 될 수 있습니다.

필요에 따라:

Masking

Encryption

Access Control

Retention Limit

을 적용합니다.

---

46장 Checksum Error 장애 진단 순서#

Checksum이나 CRC가 실패한다면 다음 순서가 실용적입니다.

1. Frame 길이 확인
↓
2. Raw Byte 확인
↓
3. Serial 설정 확인
↓
4. Packet 구조 확인
↓
5. 계산 범위 확인
↓
6. Algorithm 확인
↓
7. Initial Value 확인
↓
8. Reflection 설정 확인
↓
9. Byte Order 확인
↓
10. Cable·Noise·Collision 확인

---

47장 모든 CRC가 실패할 때#

다음 항목을 먼저 확인합니다.

CRC Variant

계산 시작 Offset

계산 종료 Offset

CRC Field 포함 여부

STX 포함 여부

ETX 포함 여부

CRC Byte Order

모든 Packet에서 똑같이 실패한다면 전기적 Noise보다 구현이나 Protocol 해석 문제일 가능성을 먼저 살펴볼 수 있습니다.

---

48장 가끔씩만 CRC가 실패할 때#

정상 Frame과 오류 Frame을 비교합니다.

예:

정상
01 03 00 00 00 02 C4 0B

오류
01 03 00 00 01 02 C4 0B

특정 Byte가 간헐적으로 변한다면:

Noise

Collision

Signal Integrity

Buffer

등을 조사합니다.

---

49장 CRC Error를 무조건 재전송으로 덮지 않는다#

Application에서:

CRC FAIL
↓
Retry

를 구현하는 것은 일반적인 복구 방식이 될 수 있습니다.

하지만 CRC Error가 지속적으로 발생하는데 Retry만 늘리면:

Bus Traffic 증가

Latency 증가

장애 은폐

로 이어질 수 있습니다.

오류율 자체를 Monitoring하는 것이 중요합니다.

---

50장 오류율을 측정하면 장애가 보인다#

예:

1시간 수신 Frame
100,000

CRC Error
5

와:

1시간 수신 Frame
100,000

CRC Error
12,000

은 완전히 다른 상태입니다.

따라서 단순히:

CRC Error 발생

보다:

CRC Error Rate

를 Monitoring하면 상태 변화를 더 쉽게 발견할 수 있습니다.

---

51장 현장 판단표#

증상	우선 확인
모든 Frame CRC 실패	Algorithm·범위·Byte Order
간헐적 CRC 실패	Noise·Cable·Collision
장비 교체 후 CRC 실패	Firmware·Protocol Version
Baud 변경 후 개선	Signal Integrity·Serial 설정
Motor 작동 시 CRC 증가	EMI·Ground
특정 Device만 CRC 실패	Local Cable·설정·Device
Frame Length도 이상	Parser·Byte Loss·Serial 설정
CRC 값 Byte만 반대	Endianness 가능성

---

52장 흔히 하는 잘못된 판단#

52.1 Checksum과 CRC는 같은 것이다#

둘 다 오류 검출 목적이지만 계산 방식과 검출 능력이 다릅니다.

52.2 CRC-16이면 모두 같은 값을 만든다#

아닙니다.

CRC Variant에 따라 결과가 다릅니다.

52.3 CRC Error는 Software Algorithm 문제다#

Cable·Noise·Collision로 Data가 바뀌어도 발생합니다.

52.4 CRC가 정상이라면 Packet 내용도 업무적으로 올바르다#

CRC는 전송 무결성만 검사합니다.

52.5 CRC가 있으면 보안성이 확보된다#

아닙니다.

공격자는 CRC를 다시 계산할 수 있습니다.

52.6 CRC-32가 CRC-16보다 항상 더 좋은 선택이다#

기존 Protocol과 필요한 오류 검출 특성 등을 함께 고려해야 합니다.

52.7 Checksum은 Binary Protocol에서만 사용한다#

Text Protocol에서도 사용할 수 있습니다.

---

53장 현장 체크리스트#

□ Checksum인지 CRC인지 확인했는가?

□ 정확한 Algorithm 이름을 확인했는가?

□ Polynomial을 확인했는가?

□ Initial Value를 확인했는가?

□ RefIn·RefOut 설정을 확인했는가?

□ Final XOR 값을 확인했는가?

□ CRC 계산 범위를 확인했는가?

□ CRC Byte Order를 확인했는가?

□ 제조사 Known Test Vector가 있는가?

□ 실제 Frame으로 검증했는가?

□ 모든 Frame이 실패하는지 일부만 실패하는지 확인했는가?

□ Serial 설정이 맞는가?

□ Cable·Noise·Collision 가능성을 확인했는가?

□ Raw Packet을 기록했는가?

□ 민감한 Payload가 Log에 노출되지 않는가?

---

54장 자기 점검#

54.1 Checksum과 CRC의 목적은 무엇인가#

전송된 Data가 손상되었는지 검출하는 것입니다.

54.2 CRC-16이면 항상 같은 값이 나오는가#

아닙니다.

Polynomial, Initial Value, Reflection, Final XOR 등 Parameter에 따라 달라집니다.

54.3 모든 Packet에서 CRC가 실패하면 무엇을 먼저 확인해야 하는가#

CRC Variant, 계산 범위, Byte Order와 Protocol Version을 확인합니다.

54.4 간헐적으로 CRC Error가 발생하면 무엇을 확인해야 하는가#

Noise, Cable, Collision, Signal Integrity 같은 Physical Layer 문제도 확인합니다.

54.5 CRC가 정상이면 Packet을 신뢰해도 되는가#

전송 과정에서 검사값과 Data가 일치한다는 의미일 뿐 송신자 인증이나 업무적 정확성을 보장하지는 않습니다.

---

55장 이 글을 마치며#

장비 통신에서 Checksum과 CRC의 핵심 목적은 단순합니다.

송신 Data
↓
검사값 계산
↓
Data + 검사값 전송
↓
수신 Data로 다시 계산
↓
두 값 비교

입니다.

하지만 실제 현장에서는:

CRC가 맞다.

CRC가 틀리다.

만 확인해서는 부족합니다.

CRC가 틀렸다면:

Algorithm이 다른가?

계산 범위가 다른가?

Byte Order가 다른가?

전송 중 Byte가 손상됐는가?

Serial 설정이 잘못됐는가?

Bus Collision이 있었는가?

까지 내려가야 합니다.

특히 다음 다섯 가지를 기억하면 됩니다.

Checksum과 CRC는 Data 전송 과정에서 발생한 오류를 검출하기 위한 기술입니다.

Checksum은 단순 합산이나 XOR 등 다양한 방식이 있으며 하나의 고정 Algorithm이 아닙니다.

CRC-16이라는 이름만으로는 부족하며 Polynomial·Initial Value·Reflection·Final XOR·Byte Order까지 확인해야 합니다.

CRC Error는 Algorithm 문제뿐 아니라 Noise·Cable·Collision·Serial 설정 오류에서 발생할 수도 있습니다.

CRC는 우발적인 데이터 손상을 검출하는 기술이지 인증이나 암호화를 제공하는 보안 기술은 아닙니다.

결국 Checksum과 CRC를 이해한다는 것은 계산 공식을 외우는 것이 아닙니다.

어떤 Byte를 어떤 규칙으로 계산했고, 수신측이 같은 범위와 같은 규칙으로 다시 계산했는지를 추적할 수 있는 것이 핵심입니다.