장비 통신 패킷 구조 이해하기: STX·ETX·Header·Address·Checksum 분석

STX부터 ETX까지 하나의 장비 Packet을 해부하기#

1장 HEX 한 줄도 규칙을 알면 문장처럼 읽을 수 있다#

장비 통신 Log에서 다음과 같은 데이터를 처음 보면 낯설게 느껴질 수 있습니다.

02 10 01 A0 05 01 31 32 33 34 35 7B 03

그냥 숫자가 늘어서 있는 것처럼 보입니다.

하지만 Protocol의 규칙을 알고 있다면 다음처럼 나눌 수 있습니다.

02
→ STX

10
→ Header

01
→ Device Address

A0
→ Command

05
→ Length

01
→ Sequence

31 32 33 34 35
→ Payload

7B
→ Checksum

03
→ ETX

갑자기 의미 없는 HEX가 하나의 문장처럼 보이기 시작합니다.

장비 Packet 분석에서 가장 중요한 것은 숫자를 외우는 것이 아니라 각 Byte가 어떤 역할을 맡고 있는지 경계를 찾는 것입니다.

2장 Packet과 Frame은 어디서 시작하고 어디서 끝날까#

Serial 통신은 기본적으로 Byte Stream으로 들어옵니다.

예를 들어 수신 Program에서는 다음처럼 보일 수 있습니다.

... 41 42 43 02 10 01 A0 05 01 31 32 33 34 35 7B 03 55 56 ...

여기서 어느 부분이 하나의 Message인지 알아야 합니다.

Protocol이:

STX = 0x02
ETX = 0x03

을 사용한다면:

02
↓
10 01 A0 05 01 31 32 33 34 35 7B
↓
03

을 하나의 Frame으로 판단할 수 있습니다.

즉 STX와 ETX는 Packet의 경계를 찾는 방법 중 하나입니다.

3장 STX는 무엇인가#

STX는 Start of Text의 약자입니다.

ASCII Control Character에서 0x02가 STX로 정의되어 있기 때문에 많은 Legacy Device Protocol이 이를 Frame 시작 표시로 사용합니다.

예:

02 10 01 A0 ...
^^
STX

Receiver는 Stream을 읽다가:

0x02

를 발견하면:

새 Frame이 시작될 가능성이 있다.

고 판단할 수 있습니다.

3.1 모든 Protocol이 0x02를 STX로 쓰는 것은 아니다#

중요합니다.

어떤 Protocol은:

0x02

하나를 사용할 수 있지만 다른 Protocol은:

AA 55

또는:

7E

같은 별도의 Start Pattern을 사용할 수 있습니다.

또 어떤 Protocol은 아예 STX를 사용하지 않을 수도 있습니다.

따라서:

장비 Packet은 무조건 0x02로 시작한다.

고 생각하면 안 됩니다.

4장 ETX는 무엇인가#

ETX는 End of Text의 약자입니다.

ASCII Control Character 0x03을 Frame 종료 표시로 사용하는 Protocol이 많습니다.

예:

02 10 01 A0 05 01 31 32 33 34 35 7B 03
                                       ^^
                                       ETX

Receiver는 ETX를 만나면:

하나의 Frame이 끝났다.

고 판단할 수 있습니다.

4.1 ETX가 없는 Protocol도 많다#

예를 들어 다음처럼 Length만 사용하는 Protocol도 있습니다.

[HEADER][LENGTH][DATA][CRC]

Receiver는 Length를 읽고:

앞으로 20 Byte를 더 읽으면
하나의 Frame이다.

라고 판단합니다.

또 고정 길이 Frame을 사용할 수도 있습니다.

항상 16 Byte

즉 Frame 경계는 크게:

Delimiter 기반

Length 기반

Fixed Length 기반

조합 방식

으로 생각할 수 있습니다.

5장 Header는 Packet을 해석하기 위한 안내판이다#

Header에는 Packet을 해석하는 데 필요한 Metadata가 들어갈 수 있습니다.

예:

Protocol Version

Message Type

Device Address

Command

Length

Flags

하지만 Header라는 이름의 고정된 구조가 존재하는 것은 아닙니다.

Protocol마다 완전히 다릅니다.

예를 들어:

02 10 01 A0 05 ...

에서 0x10이 Protocol Version일 수도 있고 Message Type일 수도 있습니다.

정답은 Protocol Specification에서 확인해야 합니다.

6장 Device Address는 누구에게 보내는 Packet인지 알려준다#

RS-485처럼 여러 장비가 하나의 Bus를 공유하면 Address가 중요합니다.

예:

Master
 │
 ├─ Device 01
 ├─ Device 02
 ├─ Device 03
 └─ Device 04

Packet:

02 10 03 A0 ...

에서 Protocol이 세 번째 Byte를 Address로 정의했다면:

03

번 Device를 대상으로 하는 Message일 수 있습니다.

6.1 Source와 Destination이 둘 다 있을 수도 있다#

일부 Protocol은:

Source Address
Destination Address

를 모두 가질 수 있습니다.

예:

02 01 05 A0 ...
   ^^ ^^
   │  │
   │  Destination
   Source

이런 구조에서는 누가 누구에게 보냈는지 명확하게 구분할 수 있습니다.

7장 Command는 장비에게 무엇을 할지 알려준다#

Command Field는 Packet의 목적을 나타냅니다.

예를 들어 제조사가 다음처럼 정의했다고 가정해보겠습니다.

Command 의미
0x10 상태 조회
0x20 설정 조회
0x30 설정 변경
0x40 Event 보고

이때 Packet:

02 01 10 ...

에서:

10

은 상태 조회를 의미할 수 있습니다.

하지만 Command 값은 제조사 Protocol마다 완전히 다릅니다.

8장 Command가 같아도 Request와 Response가 다를 수 있다#

어떤 Protocol은 Request와 Response에 같은 Command Code를 사용합니다.

예:

Request

02 01 10 ...

Response:

02 01 10 ...

대신 Header의 Flag로 방향을 구분할 수 있습니다.

다른 Protocol은:

Request Command
0x10

Response Command
0x90

처럼 별도 Code를 사용할 수도 있습니다.

따라서 Command 값 하나만 보고 Packet 방향을 단정해서는 안 됩니다.

9장 Length는 Parser에게 매우 중요한 정보다#

Length Field가 있다고 하겠습니다.

02 10 01 A0 05 01 31 32 33 34 35 ...
            ^^
            Length

0x05가 Payload Length라면 뒤에 정확히 5 Byte를 읽습니다.

31
32
33
34
35

이렇게 Length를 이용하면 Parser는 Stream에서 Packet의 끝을 찾는 데 도움을 받을 수 있습니다.

9.1 Length가 무엇을 세는지 확인해야 한다#

매우 중요한 부분입니다.

어떤 Protocol은:

Payload Length

만 셉니다.

다른 Protocol은:

Command + Payload

길이를 나타낼 수도 있습니다.

또 다른 Protocol은:

STX부터 ETX까지 전체 Frame Length

를 의미할 수도 있습니다.

그래서:

Length = 0x05

만 보고 반드시 Payload 5 Byte라고 해석하면 안 됩니다.

Length의 기준 범위는 Protocol 문서에서 반드시 확인해야 합니다.

10장 Length가 잘못되면 전체 Stream 해석이 무너질 수 있다#

정상:

STX
LEN = 5
DATA = 5 Bytes
CHECK
ETX

인데 손상으로 Length가:

LEN = 9

가 되었다고 하겠습니다.

Parser는 원래 Packet 뒤에 있던 다음 Frame의 일부까지 Data로 읽을 수 있습니다.

Packet 1
──────────────┐

Packet 2      │
───────┐      │
       └──────┘

결과적으로 하나의 Byte 오류가 이후 여러 Frame의 Parsing 오류로 이어질 수 있습니다.

11장 Sequence Number는 Packet의 순서를 추적한다#

Sequence Number는 Packet에 번호를 붙이는 방식입니다.

예:

SEQ 01

SEQ 02

SEQ 03

SEQ 04

수신 Log가:

01
02
04

라면:

03이 빠졌다.

고 판단할 수 있습니다.

11.1 Sequence Number는 TCP Sequence Number와 같은 것은 아니다#

개념적으로 순서를 관리한다는 점은 비슷하지만 구현 목적과 동작 방식은 다를 수 있습니다.

장비 Protocol에서는 단순히:

0 ~ 255

범위의 1 Byte Counter를 사용할 수도 있습니다.

예:

FE
FF
00
01

처럼 Overflow 후 다시 0으로 돌아갈 수도 있습니다.

11.2 Sequence가 반복되면 재전송일 수도 있다#

예:

SEQ 10
SEQ 11
SEQ 11
SEQ 12

11이 두 번 보입니다.

가능한 원인:

재전송

응답 Timeout

장비 Restart

Sequence 관리 Bug

등입니다.

Sequence Number 하나만으로 원인을 확정하지 말고 Timestamp와 Response Log를 함께 봅니다.

12장 Payload가 실제 업무 데이터다#

Payload는 장비가 실제로 전달하려는 Data입니다.

예:

31 32 33 34 35

ASCII로 해석하면:

1 2 3 4 5

즉:

"12345"

가 됩니다.

예를 들어 카드 Reader라면 카드 ID일 수 있습니다.

12.1 Payload는 Command에 따라 구조가 달라질 수 있다#

CMD = 0x10일 때:

Temperature
Status

를 담고,

CMD = 0x20일 때:

Device ID
Firmware Version

을 담을 수 있습니다.

즉 Payload를 해석하려면 먼저 Command를 알아야 합니다.

Command
↓
Payload Format 결정

입니다.

13장 Payload 안에도 여러 Field가 존재할 수 있다#

예를 들어 Payload 8 Byte가 다음과 같다고 하겠습니다.

01 02 07 E9 09 18 0A 1E

Protocol이 다음처럼 정의할 수도 있습니다.

Offset 길이 의미
0 1 상태
1 1 Sensor 번호
2 2 연도
4 1 월
5 1 일
6 1 시
7 1 분

이렇게 Packet 분석은 결국 Byte Offset과 Field Length를 읽는 작업입니다.

14장 Multi-byte 값에서는 Endianness도 중요하다#

2 Byte 값:

01 02

가 있다고 하겠습니다.

Big Endian이면:

0x0102

이고 Little Endian이면:

0x0201

입니다.

Length, Timestamp, Register Value 같은 Multi-byte Field를 분석할 때 Byte Order를 확인해야 합니다.

15장 Checksum은 왜 필요한가#

전송 과정에서 Data가 손상될 수 있습니다.

송신:

10 20 30 40

수신:

10 20 31 40

한 Byte가 바뀌었습니다.

그런데 Packet에 Checksum이 있다면 Receiver는 Data가 정상인지 검사할 수 있습니다.

15.1 단순 합산 Checksum 예#

예를 들어 Protocol이 다음과 같이 정의되었다고 가정합니다.

Checksum
=
Data Byte 합계의 하위 8 Bit

Data:

01 02 03

이면:

01 + 02 + 03
=
06

따라서 Checksum은:

06

이 될 수 있습니다.

이것은 교육용 예이며 실제 Protocol마다 계산법이 다릅니다.

16장 Checksum이라고 항상 Byte 합계를 쓰는 것은 아니다#

Checksum이라는 이름 아래에서도 여러 방식이 있습니다.

예:

Sum

XOR

1's Complement

2's Complement

LRC

따라서 Protocol 문서에서:

Checksum

이라고만 써 있다면 정확한 Algorithm을 확인해야 합니다.

17장 CRC는 Checksum보다 복잡한 오류 검출 방식이다#

CRC는 Polynomial 연산을 이용해 Frame 손상을 검출합니다.

대표적으로 다음 요소가 Algorithm을 결정합니다.

Polynomial

Initial Value

Input Reflection

Output Reflection

Final XOR

Byte Order

그래서:

CRC-16 사용

이라는 정보만으로는 구현하기 부족할 수 있습니다.

17.1 CRC가 더 강력하다고 무조건 직접 선택하는 것은 아니다#

이미 제조사 Protocol이:

Checksum

을 사용하도록 정의했다면 개발자가 임의로 CRC로 바꿀 수 없습니다.

장비 통신에서는:

더 좋은 Algorithm보다 서로 같은 Algorithm을 사용하는 것이 먼저입니다.

18장 ETX까지 확인해야 하나#

STX/ETX 기반 Protocol이라면 ETX도 중요한 Frame 검증 요소가 될 수 있습니다.

예:

02 ... CHECKSUM 03

Length만큼 읽었는데 마지막에:

03

이 없다면:

Frame 손상

Parsing 위치 오류

Byte 누락

잘못된 Length

등을 의심할 수 있습니다.

19장 하나의 Packet을 실제로 해부해보자#

예시 Packet:

02 10 01 A0 05 01 31 32 33 34 35 7B 03

이를 Field별로 나눠보겠습니다.

Offset 값 의미 예시
0 02 STX
1 10 Header / Version
2 01 Device Address
3 A0 Command
4 05 Payload Length
5 01 Sequence
6~10 31 32 33 34 35 Payload
11 7B Checksum 예시
12 03 ETX

이제 단순한 13 Byte가 아니라 하나의 구조로 보입니다.

20장 Payload를 ASCII로 바꾸면 무엇이 보일까#

Payload:

31 32 33 34 35

는 ASCII Code 기준으로:

31 → 1
32 → 2
33 → 3
34 → 4
35 → 5

입니다.

따라서:

"12345"

가 됩니다.

이런 변환은 장비 Protocol 분석에서 매우 자주 사용합니다.

21장 모든 HEX를 ASCII로 바꾸면 안 된다#

다음 Packet:

02 10 01 A0 05 01 31 32 33 34 35 7B 03

에서:

31 32 33 34 35

는 Text Data일 수 있지만:

A0

는 Command Code일 수 있습니다.

즉:

모든 Byte
→ ASCII

로 바꾸면 오히려 의미가 이상해질 수 있습니다.

Field별 Encoding을 확인해야 합니다.

22장 Binary와 ASCII가 하나의 Packet 안에 섞일 수도 있다#

실제 장비 Protocol에서는 다음처럼 사용할 수 있습니다.

STX
Binary

Address
Binary

Command
Binary

Payload
ASCII

Checksum
Binary

ETX
Binary

즉 하나의 Packet 안에서도 Encoding이 섞일 수 있습니다.

따라서 Packet 전체를 한 가지 방식으로 해석해서는 안 됩니다.

23장 Stream에서는 Packet이 한 번에 들어온다는 보장이 없다#

Application이 Serial Port에서 데이터를 읽는다고 하겠습니다.

송신 장비는:

02 10 01 A0 05 01 31 32 33 34 35 7B 03

을 한 번 전송했습니다.

그런데 Application의 read()에서는 다음처럼 나뉘어 들어올 수도 있습니다.

첫 번째 read

02 10 01 A0

두 번째:

05 01 31 32 33

세 번째:

34 35 7B 03

따라서 read() 한 번을 하나의 Packet이라고 가정하면 안 됩니다.

24장 반대로 여러 Packet이 한 번에 들어올 수도 있다#

예:

02 ... 03 02 ... 03 02 ... 03

처럼 여러 Frame이 Receive Buffer에 한꺼번에 들어올 수 있습니다.

따라서 Parser는:

Receive
↓
Buffer에 누적
↓
Frame Boundary 탐색
↓
한 Frame 추출
↓
남은 Byte 유지

방식으로 동작하는 것이 일반적입니다.

25장 Parser는 STX만 찾으면 끝나는 것이 아니다#

다음 Stream:

55 77 02 10 01 A0 05 ...

에서 STX를 찾았습니다.

하지만 이후에도 다음을 검사해야 합니다.

Header 유효?

Length 정상?

최대 Packet Size 이내?

Checksum 정상?

ETX 정상?

하나라도 맞지 않으면 잘못된 Frame일 수 있습니다.

26장 Payload 안에 STX나 ETX 값이 나오면 어떻게 할까#

매우 중요한 Protocol 설계 문제입니다.

Payload 안에 실제 Data로:

0x02

또는:

0x03

이 들어갈 수 있다고 하겠습니다.

Parser가 무조건:

0x03
=
Frame 종료

라고 판단하면 Packet이 중간에서 잘립니다.

이 문제를 해결하는 방법에는 Protocol에 따라:

Length Field

Byte Stuffing

Escaping

COBS

SLIP 방식

특수 Encoding

등이 있습니다.

27장 Escape 방식은 어떻게 동작할까#

예를 들어 Protocol에서:

0x02
0x03
0x10

을 특수 문자로 예약했다고 가정합니다.

Payload에 0x03이 들어가야 한다면:

10 03

처럼 Escape Sequence로 바꿔 전송할 수 있습니다.

Receiver는 다시 원래 Byte로 복원합니다.

정확한 방식은 Protocol마다 다릅니다.

28장 Length가 있으면 ETX가 필요 없을까#

반드시 그렇지는 않습니다.

어떤 Protocol은:

STX
Length
Data
Checksum
ETX

처럼 둘 다 사용합니다.

왜 중복처럼 보이는 기능을 같이 사용할까요?

Parser가 여러 조건을 교차 확인할 수 있기 때문입니다.

STX 확인

Length 확인

Checksum 확인

ETX 확인

을 모두 통과해야 정상 Frame으로 인정할 수 있습니다.

29장 Sequence가 빠졌다고 반드시 Packet 손실은 아니다#

Log:

SEQ 01
SEQ 02
SEQ 04

가 있다고 하겠습니다.

03이 보이지 않습니다.

가능한 원인:

Packet Loss

Log 누락

Filtering

다른 통신 Channel

장비 Restart

Sequence 정책

등이 있습니다.

따라서 Sequence Gap 하나만으로 통신선 문제라고 단정하지 않습니다.

30장 주차관제 현장에서 Packet은 어떻게 흐를까#

카드 Reader에서 카드가 인식됐다고 하겠습니다.

Packet:

STX
↓
Reader Address
↓
CARD_DETECTED
↓
Length
↓
Card ID
↓
Timestamp
↓
Checksum
↓
ETX

Controller는 이를 수신하고:

Checksum 검사
↓
Address 확인
↓
Command 확인
↓
Card ID 추출
↓
권한 조회

를 수행합니다.

그 다음 Response를 생성할 수 있습니다.

ALLOW

또는:

DENY

입니다.

31장 통신 성공과 실제 차단기 동작은 구분한다#

Controller가 Gate에 Open Command를 전송했다고 하겠습니다.

OPEN_GATE

Gate Controller가 ACK를 보냅니다.

ACK

하지만 이것이 반드시:

차단기가 실제로 열렸다.

는 뜻은 아닙니다.

실제 System은:

Command 수신
↓
ACK
↓
Relay 동작
↓
Motor 동작
↓
Open Sensor 감지
↓
OPEN_COMPLETE

처럼 구성될 수 있습니다.

Packet 분석에서는 이 차이를 항상 고려해야 합니다.

32장 Timestamp도 Packet 분석에서 중요하다#

다음 Log를 생각해보겠습니다.

12:00:00.100 TX OPEN

12:00:00.120 RX ACK

12:00:03.500 EVENT OPENED

이 기록을 보면:

통신 응답
20ms

실제 물리 동작
3.4초

처럼 서로 다른 시간을 구분할 수 있습니다.

따라서 장비 Log에는 가능하면 정확한 Timestamp를 남기는 것이 좋습니다.

33장 Packet Log에는 Direction도 남겨야 한다#

다음 Log:

02 01 10 ...
02 01 90 ...

만 보면 어느 것이 송신이고 어느 것이 수신인지 알기 어렵습니다.

따라서:

TX 02 01 10 ...

RX 02 01 90 ...

처럼 Direction을 기록합니다.

더 좋게는:

Timestamp
Port
Direction
Raw HEX
Parsed Result

를 같이 기록합니다.

34장 좋은 Packet Log의 예#

예:

2026-09-24 14:10:31.125
PORT: COM3
DIR : RX
RAW : 02 10 01 A0 05 01 31 32 33 34 35 7B 03

STX      : 02
VERSION  : 10
ADDRESS  : 01
COMMAND  : A0
LENGTH   : 05
SEQUENCE : 01
PAYLOAD  : "12345"
CHECKSUM : 7B
ETX      : 03

이런 Log는 장애 분석 속도를 크게 높입니다.

35장 개인정보가 Payload에 들어갈 수 있다#

Packet 안에는:

Card ID

차량번호

회원번호

전화번호

출입 기록

등이 포함될 수 있습니다.

따라서 Debug Log라고 해서 무조건 원본 Packet을 장기간 저장하는 것은 적절하지 않을 수 있습니다.

필요에 따라:

Masking

Hashing

Access Control

Retention Policy

Encryption

등을 적용합니다.

36장 Checksum Error가 발생하면 어디부터 볼까#

다음 순서로 확인합니다.

Checksum Algorithm
↓
Checksum 계산 범위
↓
Byte Order
↓
Length
↓
Payload
↓
Cable / Noise
↓
Baud / Parity
↓
Collision

즉 Checksum Code만 의심하지 않습니다.

37장 Length Error가 발생하면 어디부터 볼까#

확인:

Length가 무엇을 세는가?

Header 포함?

Payload만?

Checksum 포함?

ETX 포함?

Endian은?

Escape 전 길이인가?

Escape 후 길이인가?

Length 정의 하나가 잘못되면 Parser 전체가 무너질 수 있습니다.

38장 STX는 보이는데 ETX가 계속 안 나온다면#

가능한 원인:

Byte Loss

잘못된 Length

ETX가 Payload 내부에서 Escape 처리됨

Serial 설정 오류

Noise

Parser Bug

입니다.

무조건 송신 장비가 ETX를 안 보냈다고 결론 내리지 않습니다.

39장 ETX는 보이는데 STX가 없다면#

가능한 원인:

Capture 중간에서 시작

Receive Buffer 일부 누락

잘못된 Stream 위치

STX 손상

Parser가 앞 Frame을 놓침

등입니다.

Streaming Protocol에서는 동기화를 다시 잡는 전략이 중요합니다.

40장 Parser는 오류 후 어떻게 복구해야 할까#

잘못된 Frame 하나 때문에 이후 모든 Data가 깨져서는 안 됩니다.

예를 들어:

STX 발견
↓
Length 비정상
↓
Frame 폐기
↓
다음 STX 검색

같이 다시 Synchronization을 잡을 수 있습니다.

이를 Resynchronization이라고 생각하면 됩니다.

41장 무한정 Length를 믿으면 안 된다#

손상된 Length 값이:

65535

로 들어왔다고 하겠습니다.

Parser가 실제로 65535 Byte를 기다리면 Buffer 문제가 생길 수 있습니다.

따라서 Protocol Parser에는:

Maximum Frame Size

같은 제한이 필요합니다.

예:

if length > 1024:
    frame_error

처럼 방어적으로 처리할 수 있습니다.

42장 Packet Parser는 상태 기계로 만들기 좋다#

개념적으로:

WAIT_STX
↓
READ_HEADER
↓
READ_LENGTH
↓
READ_PAYLOAD
↓
READ_CHECKSUM
↓
WAIT_ETX
↓
VALIDATE

같은 State Machine을 사용할 수 있습니다.

오류 발생 시:

RESET
↓
WAIT_STX

로 돌아갑니다.

이 방식은 Serial Stream Parser를 안정적으로 구현하는 데 유용합니다.

43장 하나의 Packet을 분석하는 기본 순서#

Raw Data를 받으면 다음 순서로 봅니다.

1. Frame 시작 위치 찾기
↓
2. Header 구조 확인
↓
3. Address 확인
↓
4. Command 확인
↓
5. Length 확인
↓
6. Sequence 확인
↓
7. Payload 분리
↓
8. Encoding 확인
↓
9. Checksum / CRC 검증
↓
10. Frame 종료 확인

44장 여러 Packet을 비교하면 Protocol이 보인다#

예:

02 10 01 A0 05 01 31 32 33 34 35 7B 03

02 10 02 A0 05 02 31 32 33 34 36 7D 03

02 10 03 B0 02 03 01 00 4A 03

여러 Sample을 비교하면:

항상 같은 값

장비마다 바뀌는 값

Command마다 바뀌는 값

Length에 따라 이동하는 값

을 찾을 수 있습니다.

Protocol 분석에서 하나의 Frame보다 여러 조건의 Frame 비교가 훨씬 중요합니다.

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

45.1 STX는 항상 0x02다#

아닙니다.

Protocol마다 Frame 시작 방식이 다릅니다.

45.2 ETX가 있으면 Length는 필요 없다#

둘을 함께 사용하는 Protocol도 있습니다.

45.3 Length는 항상 Payload 길이다#

아닙니다.

어떤 범위를 세는지 Protocol마다 다릅니다.

45.4 모든 Payload는 ASCII다#

Binary·BCD·Integer·Bit Field 등 다양한 형식을 사용할 수 있습니다.

45.5 Checksum은 단순 합산이다#

다양한 Algorithm이 존재합니다.

45.6 CRC가 틀리면 CRC Code 문제다#

전송 과정에서 Byte가 손상됐을 수도 있습니다.

45.7 Sequence가 하나 빠지면 Packet Loss가 확실하다#

Log 누락이나 Protocol 정책 등 다른 원인도 가능합니다.

46장 Packet 분석 체크리스트#

□ STX 또는 Frame 시작 규칙을 확인했는가?

□ Header 길이가 고정인지 가변인지 확인했는가?

□ Source·Destination Address 구조를 확인했는가?

□ Command Code 표를 확보했는가?

□ Length가 어느 범위를 의미하는지 확인했는가?

□ Multi-byte 값의 Endianness를 확인했는가?

□ Sequence Number의 증가 규칙을 확인했는가?

□ Payload Encoding을 확인했는가?

□ Checksum 또는 CRC Algorithm을 확인했는가?

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

□ ETX 또는 종료 규칙을 확인했는가?

□ Payload 내부에 Delimiter가 들어갈 수 있는지 확인했는가?

□ Escape 규칙을 확인했는가?

□ 최대 Frame Length를 확인했는가?

□ Timestamp와 TX/RX Direction을 기록했는가?

47장 자기 점검#

47.1 STX와 ETX는 무엇을 위한 것인가#

Byte Stream에서 하나의 Frame이 시작하고 끝나는 위치를 식별하는 데 사용할 수 있습니다.

47.2 Length가 왜 중요한가#

Parser가 Payload 또는 Frame의 크기를 판단하고 정확한 경계를 찾는 데 사용됩니다.

47.3 Sequence Number는 왜 사용하는가#

Frame 순서, 누락, 중복 또는 재전송을 추적하는 데 활용할 수 있습니다.

47.4 Checksum과 CRC의 역할은 무엇인가#

전송 과정에서 Frame Data가 손상되었는지 검출하는 데 사용합니다.

47.5 Packet을 분석할 때 가장 먼저 해야 할 일은 무엇인가#

각 Byte의 의미를 추측하기 전에 해당 Protocol이 Frame의 시작과 끝을 어떻게 정의하는지 확인하는 것입니다.

48장 이 글을 마치며#

처음에는:

02 10 01 A0 05 01 31 32 33 34 35 7B 03

같은 HEX 데이터가 의미 없는 숫자처럼 보입니다.

하지만 구조를 나누면:

STX
↓
Header
↓
Device Address
↓
Command
↓
Length
↓
Sequence
↓
Payload
↓
Checksum
↓
ETX

라는 하나의 Message가 됩니다.

이 과정에서 중요한 것은 각 Byte를 무작정 해석하는 것이 아닙니다.

먼저:

Frame의 시작은 어디인가?

Frame의 끝은 어디인가?

Length는 무엇을 의미하는가?

Command에 따라 Payload가 어떻게 달라지는가?

Checksum은 어떤 범위를 검사하는가?

를 확인해야 합니다.

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

STX와 ETX는 Frame 경계를 표시하는 방법 중 하나이며 모든 Protocol이 사용하는 것은 아닙니다.

Length는 Payload 길이일 수도 있고 전체 Frame 길이일 수도 있으므로 Protocol 정의를 확인해야 합니다.

Payload의 의미는 Command에 따라 달라질 수 있고 Binary와 ASCII가 한 Frame 안에 섞일 수도 있습니다.

Checksum이나 CRC Error는 Algorithm 문제뿐 아니라 Noise·Byte 손실·Serial 설정 오류 같은 하위 계층 문제에서도 발생할 수 있습니다.

Serial이나 TCP의 한 번의 read 결과가 반드시 하나의 Packet과 일치하는 것은 아니므로 Stream Parser가 필요합니다.

결국 Packet을 해부한다는 것은 HEX 값을 많이 외우는 일이 아닙니다.

Byte Stream에서 하나의 Frame을 정확하게 찾아내고, 각 Field의 위치와 길이, 의미, 검증 관계를 순서대로 복원하는 것이 핵심입니다.

이 페이지의 목차