장비 통신 프로토콜이란? Packet·Command·Response 구조 이해하기

장비끼리 대화하려면 왜 통신 프로토콜이 필요한가#

1장 선을 연결했다고 장비가 서로 대화할 수 있는 것은 아니다#

RS-232, RS-422, RS-485 또는 Ethernet으로 두 장비를 연결했다고 생각해보겠습니다.

물리적으로는 연결되어 있습니다.

장비 A
   │
   │ RS-485
   │
장비 B

Baud Rate도 같습니다.

9600-8-N-1

A/B 배선도 정상입니다.

그런데 장비 A가 보내는 명령을 장비 B가 이해하지 못합니다.

왜 그럴까요?

전기적으로 데이터를 전달할 수 있다는 것과 그 데이터의 의미를 이해할 수 있다는 것은 다른 문제이기 때문입니다.

1.1 RS-485는 대화 규칙을 알려주지 않는다#

RS-485가 알려주는 것은 대략 다음과 같은 영역입니다.

어떤 전기 신호를 사용할 것인가

차동 신호를 어떻게 전달할 것인가

여러 Transceiver를 어떻게 연결할 것인가

하지만 다음은 알려주지 않습니다.

0x10은 무슨 명령인가?

첫 번째 Byte는 Address인가?

Packet은 어디서 시작하는가?

Data Length는 어디에 있는가?

오류는 어떻게 확인하는가?

정상 처리되면 무엇을 응답하는가?

이 규칙을 정하는 것이 통신 프로토콜입니다.

2장 프로토콜은 장비 사이의 언어다#

사람끼리 대화하려면 같은 언어와 문법이 필요합니다.

장비도 마찬가지입니다.

예를 들어 Controller가 다음 데이터를 보냅니다.

02 05 10 01 00 A7 03

사람에게는 단순한 Hexadecimal 숫자처럼 보입니다.

하지만 Protocol을 알고 있다면 다음과 같이 해석할 수도 있습니다.

02
→ Start

05
→ Device Address

10
→ Command

01 00
→ Data

A7
→ Checksum

03
→ End

즉 같은 Byte라도 약속을 알고 있어야 의미가 생깁니다.

3장 Packet은 문장이고 Protocol은 문법이다#

둘을 구분하면 이해하기 쉽습니다.

Packet 또는 Frame은 실제로 전달되는 데이터 덩어리입니다.

Protocol은 그 Packet을 어떻게 만들고 해석할지 정한 규칙입니다.

예:

[STX][ADDRESS][COMMAND][LENGTH][DATA][CHECKSUM][ETX]

이라는 Packet 구조가 있다고 하겠습니다.

Protocol 문서는 각각의 Field가 무엇을 의미하는지 정의합니다.

Field 역할
STX Frame 시작
Address 대상 장비
Command 수행할 명령
Length Data 길이
Data 실제 전달 내용
Checksum 오류 검출
ETX Frame 종료

따라서 Packet을 캡처했다고 해서 바로 내용을 이해할 수 있는 것은 아닙니다.

Protocol Specification이 필요합니다.

4장 장비 통신의 기본은 Command와 Response다#

산업 장비 통신에서는 흔히 다음 구조를 사용합니다.

Controller
    │
    │ Command
    ▼
Device
    │
    │ Response
    ▼
Controller

예를 들어 중앙 Controller가 Gate Controller에 상태를 묻습니다.

GET_STATUS

장비가 응답합니다.

STATUS_OK

실제 Binary Protocol에서는 다음처럼 표현될 수 있습니다.

TX
02 01 20 00 21 03

RX
02 01 20 01 00 22 03

사람이 읽기 어렵더라도 Protocol 문서를 이용하면 각 Byte의 의미를 해석할 수 있습니다.

4.1 모든 Command가 Response를 갖는 것은 아니다#

Protocol에 따라:

Request → Response

구조를 사용할 수도 있고:

Event → 일방 전송

방식을 사용할 수도 있습니다.

예를 들어 Sensor가 차량을 감지할 때:

CAR_DETECTED

Event를 Controller에 비동기적으로 전송할 수 있습니다.

따라서 장비 Protocol을 분석할 때:

누가 먼저 송신하는가?

응답이 반드시 있는가?

장비가 스스로 Event를 보내는가?

도 확인해야 합니다.

5장 Device Address는 누구에게 보내는 데이터인지 알려준다#

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

예:

Master
 │
 ├─ Device 1
 ├─ Device 2
 ├─ Device 3
 └─ Device 4

Master가:

05 10 01 ...

을 보냈다고 가정하겠습니다.

Protocol에서 첫 번째 Byte가 Device Address라면:

05

번 장비만 응답하도록 만들 수 있습니다.

5.1 Address도 RS-485가 정의하지 않는다#

RS-485 자체에는:

Device Address

개념이 없습니다.

Address는:

Modbus RTU

BACnet

제조사 전용 Protocol

같은 상위 Protocol이 정의합니다.

그래서 같은 RS-485 Cable을 사용하는 두 장비라도 Protocol이 다르면 서로 대화할 수 없습니다.

6장 Header와 Payload를 구분하면 Packet이 보이기 시작한다#

Packet은 보통 크게 다음처럼 나눌 수 있습니다.

Header
↓
Payload
↓
Trailer

Header#

Packet을 해석하는 데 필요한 정보를 포함할 수 있습니다.

예:

Start Marker

Address

Command

Length

Version

Payload#

실제로 전달하려는 Data입니다.

예:

카드 ID

온도

차량번호

Sensor 상태

Device 설정값

Trailer#

Packet 끝이나 무결성을 확인하는 정보가 들어갈 수 있습니다.

Checksum

CRC

ETX

모든 Protocol이 이 구조를 그대로 사용하는 것은 아니지만 분석할 때 매우 유용한 관점입니다.

7장 Binary Protocol과 Text Protocol은 무엇이 다른가#

장비 Protocol은 크게 Binary와 Text 형태로 나누어 생각할 수 있습니다.

7.1 Binary Protocol#

예:

02 01 10 03 41 42 43 9A 03

장점:

Data 크기가 작음

처리가 빠름

Embedded 장비에 적합

단점:

사람이 바로 읽기 어려움

Protocol 문서 없이는 분석이 어려움

7.2 Text Protocol#

예:

DEVICE=01;CMD=STATUS;VALUE=OK

또는 JSON:

{
  "deviceId": 1,
  "command": "status"
}

장점:

사람이 읽기 쉬움

Debugging 편리

확장하기 쉬움

단점:

Binary보다 Data 크기가 커질 수 있음

Parsing 비용이 증가할 수 있음

어떤 방식이 무조건 더 좋은 것은 아닙니다.

장비 성능, Network 환경, 개발 편의성 등을 고려해 결정합니다.

8장 ASCII Protocol도 장비 통신에서 많이 사용한다#

Text Protocol이 항상 JSON을 의미하는 것은 아닙니다.

Legacy Device에서는 간단한 ASCII Protocol을 많이 사용합니다.

예:

<STX>OPEN,01<ETX>

또는:

#STATUS,03\r\n

처럼 구성할 수 있습니다.

여기에서도 Protocol 문서는 다음을 정의해야 합니다.

Message 시작 문자는 무엇인가?

Field 구분자는 무엇인가?

Command 이름은 무엇인가?

줄 끝은 CR인가 LF인가?

Checksum이 있는가?

9장 Checksum과 CRC는 데이터가 깨졌는지 확인한다#

장거리 Serial Communication에서는 Noise나 Timing 문제 때문에 Data가 손상될 수 있습니다.

예:

송신
01 10 05 7A

수신
01 10 04 7A

Byte 하나가 달라졌습니다.

이런 문제를 검출하기 위해 Protocol은:

Checksum

LRC

CRC

등을 사용할 수 있습니다.

9.1 Checksum과 CRC는 같은 것은 아니다#

Checksum은 여러 방식이 존재합니다.

예:

Byte 합계

XOR

보수

CRC 역시 다양한 Polynomial과 초기값을 사용할 수 있습니다.

따라서:

CRC를 사용한다.

라는 정보만으로는 부족합니다.

다음까지 확인해야 할 수 있습니다.

Polynomial

Initial Value

Byte Order

Final XOR

Reflection 여부

Protocol 문서가 중요한 이유입니다.

10장 ACK와 NACK는 처리 결과를 알려준다#

일부 장비 Protocol은 다음과 같은 응답을 사용합니다.

ACK
→ 정상 수신 또는 정상 처리

NACK
→ 거부 또는 오류

하지만 여기서 주의해야 합니다.

ACK가:

Packet을 정상적으로 받았다.

는 의미일 수도 있고:

실제 장비 동작까지 완료했다.

는 의미일 수도 있습니다.

Protocol에 따라 다릅니다.

10.1 통신 성공과 업무 완료를 구분한다#

예를 들어 차단기 Open Command를 보냅니다.

OPEN_GATE

장비가 ACK를 보냅니다.

ACK

이것이 반드시:

차단기가 실제로 완전히 열렸다.

는 뜻은 아닐 수 있습니다.

실제 흐름은:

Command 수신
↓
ACK
↓
Motor 동작
↓
Open Sensor 감지
↓
OPEN_COMPLETED Event

처럼 구성될 수도 있습니다.

따라서 통신의 성공과 물리적 업무 완료를 분리해서 봐야 합니다.

11장 Status Code와 Error Code가 필요한 이유#

Command를 처리하지 못했을 때 단순히:

FAIL

이라고만 응답하면 원인을 알기 어렵습니다.

그래서 Protocol은 Error Code를 정의할 수 있습니다.

예:

Code 의미 예시
0x00 정상
0x01 잘못된 Command
0x02 잘못된 Parameter
0x03 Device Busy
0x04 권한 없음
0xFF General Error

이 값은 예시일 뿐이며 실제 의미는 제조사마다 다릅니다.

따라서 0xFF를 보고 임의로:

CRC Error다.

라고 추측해서는 안 됩니다.

12장 Protocol Version은 왜 중요할까#

장비 Firmware가 업데이트되면서 Protocol도 바뀔 수 있습니다.

예:

Protocol v1

CMD 0x10
Data 4 Bytes

새 버전:

Protocol v2

CMD 0x10
Data 8 Bytes

라면 기존 Software가 Packet을 잘못 해석할 수 있습니다.

12.1 장비를 교체했는데 갑자기 통신이 안 된다면#

확인합니다.

Model

Firmware Version

Protocol Version

Packet Format

Command Set

Connector와 Baud Rate가 같다고 Protocol까지 같다는 보장은 없습니다.

13장 모든 장비가 Protocol을 협상하는 것은 아니다#

일부 Network Protocol은 연결 초기 단계에서:

Version Negotiation

Capability Negotiation

등을 수행합니다.

하지만 산업용 Serial Device에서는 그런 기능 없이:

정해진 설정

정해진 Packet

정해진 Command

만 사용하는 경우도 많습니다.

따라서:

연결하면 서로 버전을 알아서 맞춘다.

라고 가정해서는 안 됩니다.

14장 실제 장비 통합은 네 층을 나누어 봐야 한다#

서로 다른 제조사의 장비를 연동할 때 다음 네 가지를 구분하면 좋습니다.

Physical Interface
↓
Serial / Network 설정
↓
Protocol Frame
↓
Business Meaning

예를 들어:

Physical Interface#

RS-485

Serial Setting#

19200-8-E-1

Protocol#

[ADDR][CMD][DATA][CRC]

Business Meaning#

CMD 0x10
=
Gate Open

입니다.

이 네 단계 중 하나라도 다르면 정상적으로 연동되지 않을 수 있습니다.

15장 주차관제 시스템으로 보면 어떻게 연결될까#

예를 들어 다음 시스템이 있다고 하겠습니다.

Card Reader
↓
Controller
↓
Server
↓
Gate Controller

차량 또는 카드가 인식됩니다.

1단계#

Reader가 Controller에 Event를 보냅니다.

CARD_DETECTED

2단계#

Controller 또는 Server가 권한을 확인합니다.

Authorized

3단계#

Gate Controller에 Command를 보냅니다.

OPEN

4단계#

Gate Controller가 처리 결과를 보냅니다.

ACK

5단계#

Sensor를 통해 실제 상태를 확인할 수 있습니다.

GATE_OPEN

이 흐름 전체가 하나의 Protocol일 수도 있고 여러 Protocol의 조합일 수도 있습니다.

16장 제조사가 다르면 Protocol Gateway가 필요할 수도 있다#

다음과 같은 시스템을 생각해보겠습니다.

Reader A
제조사 Protocol A

Controller B
제조사 Protocol B

물리 Interface가 모두 RS-485라고 해도 Protocol이 다르면 직접 통신할 수 없습니다.

그 사이에서:

Protocol A
↓
Gateway
↓
Protocol B

형태의 변환이 필요할 수 있습니다.

Gateway는:

Command Mapping

Data Conversion

Address Translation

Checksum 재계산

등을 수행할 수 있습니다.

17장 Serial과 Ethernet도 Protocol 관점에서는 같은 질문을 던진다#

RS-485 장비:

RS-485
↓
Binary Frame

Ethernet 장비:

TCP/IP
↓
JSON

처럼 구조가 다를 수 있습니다.

하지만 Integration 관점에서는 동일한 질문을 합니다.

어디서 Message가 시작되는가?

누구에게 보내는가?

어떤 Command인가?

Data 길이는 얼마인가?

정상 응답은 무엇인가?

오류는 어떻게 표현하는가?

18장 TCP를 쓴다고 Protocol이 없어지는 것은 아니다#

TCP는 신뢰성 있는 Byte Stream을 제공합니다.

하지만 TCP 자체는:

이 Byte가 Gate Open Command다.

라고 알려주지 않습니다.

예:

TCP
↓
01 05 10 00 35 7A

이 Byte의 의미를 결정하는 것은 Application Protocol입니다.

따라서:

TCP를 쓰니까 별도 Protocol은 필요 없다.

는 잘못된 생각입니다.

19장 TCP에서는 Packet 경계를 별도로 생각해야 한다#

TCP는 Byte Stream입니다.

Application에서:

Message A

Message B

를 두 번 보냈다고 수신 측에서 반드시 같은 두 번의 read()로 들어온다는 보장은 없습니다.

따라서 Protocol에서:

Length

Delimiter

Fixed Length

Header

등을 이용해 Message Boundary를 정의해야 합니다.

장비 Protocol 설계에서 매우 중요한 부분입니다.

20장 Raw HEX를 받으면 어디서부터 봐야 할까#

예를 들어 다음 Data를 얻었다고 하겠습니다.

02 05 10 03 41 42 43 A7 03

바로 의미를 추측하지 않습니다.

다음 순서로 봅니다.

1. 시작 Byte가 있는가?

2. 끝 Byte가 있는가?

3. Length처럼 보이는 값이 있는가?

4. Address 후보는 무엇인가?

5. Command가 반복되는 위치가 있는가?

6. Payload는 어디인가?

7. 마지막 값이 Checksum인가?

여러 Sample을 비교하면 Pattern을 찾기 쉬워집니다.

21장 한 Packet만 보고 Protocol을 추측하면 위험하다#

다음 두 Packet을 비교한다고 하겠습니다.

02 01 10 01 41 53 03

02 02 10 01 41 54 03

변하는 위치:

01 ↔ 02

를 보고 Address라고 추정할 수 있습니다.

하지만 Sample이 하나라면:

02

가 Address인지 Length인지 Command인지 알기 어렵습니다.

그래서 Protocol 분석에서는 여러 조건에서 수집한 Frame을 비교하는 것이 중요합니다.

22장 Protocol 문서에서 먼저 찾아야 할 것#

제조사 문서가 있다면 다음 항목부터 찾습니다.

Physical Interface

Baud Rate

Data Bits

Parity

Stop Bits

Packet Format

Address

Command Table

Response Format

Checksum / CRC

Timeout

Retry

Protocol Version

이 정도만 확보해도 대부분의 Integration 작업을 시작할 수 있습니다.

23장 Protocol 문서가 있어도 실제 로그와 비교해야 한다#

문서에는:

Firmware v1.5

기준 Protocol이 적혀 있는데 현장 장비가:

Firmware v3.0

일 수도 있습니다.

또는 제조사가 문서에 반영하지 않은 확장 Command가 있을 수 있습니다.

그래서:

Manual
+
실제 Raw Frame

을 같이 확인하는 것이 좋습니다.

24장 통신 장애를 계층별로 나누면 훨씬 쉬워진다#

장비가 응답하지 않는다고 하겠습니다.

물리 계층#

전원

Cable

A/B

TX/RX

Ground

전송 설정#

Baud

Data Bits

Parity

Stop Bits

Protocol#

Address

Command

Length

CRC

Application#

권한

업무 상태

Database

장비 상태

이렇게 나누면 원인을 훨씬 빠르게 좁힐 수 있습니다.

25장 CRC Error를 Protocol 문제로만 보지 않는다#

Frame 구조가 맞는데 CRC Error가 반복됩니다.

가능한 원인은:

CRC Algorithm 오류

만 있는 것이 아닙니다.

다음도 가능합니다.

Noise

Baud 불일치

A/B Polarity

Collision

Reflection

Byte 누락

즉:

CRC ERROR

는 하위 전송 과정에서 Data가 손상됐다는 결과일 수도 있습니다.

26장 Timeout도 원인이 아니라 결과다#

Application Log:

DEVICE TIMEOUT

을 봤다고 하겠습니다.

뜻은:

정해진 시간 안에
기대한 Response를 받지 못했다.

입니다.

원인은 다음 어디든 있을 수 있습니다.

전원

Cable

Address

Command

Protocol Version

Device Busy

Network

Application

따라서 Timeout이라는 단어 자체를 Root Cause로 취급하면 안 됩니다.

27장 시험 환경에서는 정상·오류 Frame을 비교해본다#

예를 들어 Simulator에서 정상 Frame을 보냅니다.

02 01 10 03 41 42 43 A7 03

그다음 Length를 의도적으로 변경합니다.

02 01 10 05 41 42 43 A7 03

Receiver가:

NACK

Frame Error

Timeout

중 무엇을 반환하는지 확인합니다.

다음에는 Checksum을 바꿉니다.

02 01 10 03 41 42 43 FF 03

이런 방식으로 Protocol의 실제 Error Handling 동작을 확인할 수 있습니다.

운영 장비가 아닌 Simulator나 Test Bench에서 수행해야 합니다.

28장 Protocol 분석에서는 원시 데이터를 보존한다#

장애가 발생하면 다음처럼 Parsing된 Log만 남는 경우가 있습니다.

Invalid Packet

하지만 이것만으로는 분석하기 어렵습니다.

가능하다면 원시 데이터도 남깁니다.

RX RAW:
02 01 10 03 41 42 43 A7 03

그리고:

Timestamp

Direction

Port

Device ID

Parsed Result

를 함께 기록하면 분석에 큰 도움이 됩니다.

29장 개인정보가 포함된 Payload는 그대로 남기지 않는다#

장비 Data에는 다음이 포함될 수 있습니다.

카드 ID

차량번호

사용자 ID

출입 기록

결제 정보

Protocol Debugging을 위해 Raw Packet을 저장하더라도 조직 정책과 관련 법규에 맞게:

Masking

접근 통제

보관 기간 제한

암호화

를 적용해야 합니다.

Protocol Log가 곧 개인정보 Log가 될 수 있기 때문입니다.

30장 Protocol은 보안 기능과 같은 의미가 아니다#

자체 Binary Protocol을 사용한다고 해서 안전한 것은 아닙니다.

누군가 Format을 알게 되면:

Command 재전송

Frame 위조

Replay

Device Control

등이 가능할 수 있습니다.

Protocol과 별개로:

Authentication

Authorization

Encryption

Replay Protection

을 고려해야 합니다.

31장 장비 Protocol 분석 순서#

알 수 없는 장비를 처음 연동한다면 다음 순서가 효율적입니다.

1. Interface 확인
↓
2. 통신 설정 확인
↓
3. 제조사 Protocol 문서 확보
↓
4. 정상 Raw Frame 수집
↓
5. 여러 Frame 비교
↓
6. Header·Address·Command 후보 찾기
↓
7. Length 확인
↓
8. Payload 분리
↓
9. Checksum·CRC 확인
↓
10. Response 관계 확인
↓
11. Timeout·Retry 확인
↓
12. Simulator에서 재현

32장 장비 통신에서 가장 자주 하는 실수#

32.1 RS-485가 같으면 서로 통신할 수 있다#

아닙니다.

상위 Protocol까지 같아야 합니다.

32.2 Packet을 Capture하면 의미를 바로 알 수 있다#

Protocol 문서나 여러 Sample 비교가 필요합니다.

32.3 ACK가 오면 장비 동작도 완료됐다#

Protocol 정의에 따라 다릅니다.

32.4 CRC Error면 CRC Code가 잘못됐다#

Physical Layer 손상도 의심해야 합니다.

32.5 TCP를 사용하면 Message Boundary도 자동으로 보존된다#

아닙니다.

TCP는 Byte Stream입니다.

32.6 Binary Protocol은 암호화되어 있다#

Binary라는 것과 Encryption은 전혀 다른 개념입니다.

32.7 제조사 문서와 장비가 항상 동일하다#

Firmware와 Protocol Version 차이를 확인해야 합니다.

33장 현장 점검표#

확인 항목 질문
Interface RS-232·RS-422·RS-485·TCP 중 무엇인가
Serial 설정 Baud·Data Bit·Parity·Stop Bit가 같은가
Address 대상 장비 Address가 맞는가
Frame 시작·끝·길이를 어떻게 판단하는가
Command Command Code가 무엇을 의미하는가
Payload 실제 업무 Data는 어디에 있는가
Integrity Checksum·CRC 방식은 무엇인가
Response 정상·오류 응답은 무엇인가
Timing Timeout·Retry 기준은 무엇인가
Version Firmware·Protocol Version이 맞는가
Security 인증·암호화가 필요한가
Logging Raw Frame과 Timestamp를 확보했는가

34장 자기 점검#

34.1 왜 장비 통신에 Protocol이 필요한가#

Byte의 위치와 의미, Command와 Response, 오류 검출 방식 등을 서로 동일하게 해석하기 위해 필요합니다.

34.2 RS-485를 사용하면 Address도 자동으로 생기는가#

아닙니다.

Address는 상위 Protocol에서 정의합니다.

34.3 Header와 Payload의 차이는 무엇인가#

Header는 Packet을 해석하는 데 필요한 제어 정보를 담고 Payload는 실제 전달하려는 Data를 담습니다.

34.4 ACK를 받으면 업무가 완료된 것인가#

반드시 그렇지 않습니다.

Protocol이 ACK를 어떤 의미로 정의했는지 확인해야 합니다.

34.5 Binary Protocol이면 안전한가#

아닙니다.

Binary Encoding과 Authentication·Encryption은 별개의 문제입니다.

35장 이 글을 마치며#

장비끼리 데이터를 주고받는다는 것은 단순히 Wire를 연결하고 Byte를 보내는 일이 아닙니다.

먼저:

Physical Interface

가 필요하고:

Baud Rate
Data Bits
Parity
Stop Bits

같은 전송 조건이 맞아야 합니다.

그 위에서:

Header
Address
Command
Length
Payload
Checksum

같은 Protocol의 약속이 맞아야 비로소 서로의 말을 이해할 수 있습니다.

전체 구조를 보면:

업무 의미
↓
Command / Response
↓
Packet / Frame
↓
Byte Stream
↓
RS-232 / RS-422 / RS-485 / TCP
↓
Cable 또는 Network

처럼 이어집니다.

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

물리적으로 연결됐다는 것과 서로 대화할 수 있다는 것은 다른 문제입니다.

Protocol은 Byte가 어디서 시작하고 무엇을 의미하며 어떤 응답을 해야 하는지를 정의합니다.

RS-485나 TCP 같은 하위 기술이 Address·Command·업무 의미까지 정의해주는 것은 아닙니다.

ACK·CRC Error·Timeout 같은 값은 반드시 Protocol 정의와 하위 전송 상태를 함께 보고 판단해야 합니다.

서로 다른 제조사의 장비를 연결할 때는 Connector보다 Protocol Specification을 비교하는 것이 더 중요할 수 있습니다.

결국 장비 Protocol을 이해한다는 것은 Hexadecimal 숫자를 많이 외우는 것이 아닙니다.

원시 Byte 한 줄을 Address·Command·Length·Payload·검증값이라는 약속으로 다시 나누고, 그 값이 실제 장비의 어떤 행동으로 이어지는지를 추적할 수 있는 것이 핵심입니다.

이 페이지의 목차