ASCII 통신과 Binary 통신의 차이: 장비 프로토콜 데이터 형식 완벽 이해

ASCII Protocol과 Binary Protocol은 무엇이 다른가#

1장 같은 데이터를 왜 전혀 다른 모습으로 보낼까#

장비 Log를 보다 보면 어떤 데이터는 바로 읽을 수 있습니다.

OPEN,DEV01,1

반면 어떤 데이터는 다음처럼 보입니다.

AA 55 05 10 01 23 45 6F

첫 번째는 사람이 쉽게 읽을 수 있지만 두 번째는 Protocol 문서가 없으면 의미를 알기 어렵습니다.

두 방식은 대표적으로 다음과 같이 구분할 수 있습니다.

Text / ASCII Protocol
→ 문자를 이용해 의미를 표현

Binary Protocol
→ Byte 값 자체에 의미를 부여

둘 중 하나가 무조건 우수한 것은 아닙니다.

장비 성능, 데이터 양, 개발 편의성, 실시간성, 유지보수 환경에 따라 적합한 방식이 달라집니다.

2장 Text Protocol이란 무엇인가#

Text Protocol은 사람이 읽을 수 있는 문자 형태로 Message를 표현하는 방식입니다.

예:

OPEN,DEV01,1

또는:

STATUS,DEV03

JSON을 사용하는 경우에는:

{
  "deviceId": "DEV01",
  "command": "OPEN"
}

처럼 표현할 수도 있습니다.

핵심은 데이터 의미가 문자열 형태로 드러난다는 것입니다.

2.1 ASCII Protocol이라는 표현#

산업 장비 문서에서는 흔히:

ASCII Protocol

이라는 표현을 사용합니다.

예:

<STX>OPEN,01<ETX>

또는:

#STATUS,03\r\n

처럼 ASCII Character와 Delimiter를 이용합니다.

다만 실제 Text Protocol이 반드시 순수 ASCII만 사용하는 것은 아닙니다.

UTF-8 기반 Text를 사용하면서 ASCII 영역의 문자와 구분자를 중심으로 Protocol을 구성할 수도 있습니다.

3장 Text Protocol은 Field를 어떻게 구분할까#

예를 들어:

OPEN,DEV01,1

이라는 Message가 있습니다.

,를 Field Separator로 사용한다면:

OPEN
→ Command

DEV01
→ Device ID

1
→ Parameter

로 나눌 수 있습니다.

또 Message 끝은:

CR

LF

CRLF

등으로 표현할 수 있습니다.

예:

OPEN,DEV01,1\r\n

입니다.

3.1 구분자도 Protocol의 일부다#

다음 두 Message는 사람에게 거의 같아 보입니다.

OPEN,DEV01,1\r\n
OPEN|DEV01|1\n

하지만 장비 입장에서는 완전히 다른 Protocol일 수 있습니다.

따라서 다음을 확인해야 합니다.

Field Separator

Message Terminator

Whitespace 처리

대소문자 구분

Encoding

4장 Binary Protocol은 무엇인가#

Binary Protocol은 Byte 값 자체에 의미를 부여합니다.

예:

AA 55 05 10 01 23 45 6F

Protocol 문서가 다음처럼 정의되어 있다고 가정해보겠습니다.

AA 55
→ Header

05
→ Length

10
→ Command

01
→ Device Address

23 45
→ Data

6F
→ Checksum

사람이 바로 읽기는 어렵지만 장비에서는 각 Byte 위치를 기준으로 빠르게 처리할 수 있습니다.

5장 Binary라는 말은 암호화라는 뜻이 아니다#

자주 생기는 오해입니다.

AA 55 05 10 01 23 45 6F

처럼 사람이 쉽게 읽을 수 없다고 해서 암호화된 것은 아닙니다.

Binary는 단지 데이터 표현 방식입니다.

다음은 별개의 개념입니다.

Binary Encoding
≠
Encryption

누군가 Protocol 구조를 알고 있다면 Binary Packet도 그대로 해석할 수 있습니다.

6장 같은 명령을 Text와 Binary로 비교해보자#

장비 01에 Open Command를 보낸다고 가정하겠습니다.

Text Protocol:

OPEN,01\r\n

ASCII Byte로 보면:

4F 50 45 4E 2C 30 31 0D 0A

총 9 Byte입니다.

Binary Protocol에서는 가상의 규칙으로:

AA 01 10 01 BC

처럼 표현할 수 있습니다.

예를 들어:

AA
→ Header

01
→ Address

10
→ Open Command

01
→ Parameter

BC
→ Checksum

총 5 Byte입니다.

이런 구조에서는 Binary가 더 적은 전송량을 사용할 수 있습니다.

7장 숫자 하나도 Text와 Binary에서는 크기가 달라진다#

숫자:

12345

를 Text로 보내면 ASCII 기준:

31 32 33 34 35

즉 5 Byte가 필요합니다.

반면 16-bit Integer로 표현할 수 있는 값이라면 Binary에서는:

30 39

처럼 2 Byte만으로 표현할 수 있습니다.

이것이 Binary Protocol이 전송 효율 측면에서 유리한 이유 중 하나입니다.

8장 Text Protocol의 가장 큰 장점은 사람이 바로 읽을 수 있다는 것이다#

현장에서 다음 Log를 봅니다.

STATUS,DEV03,ERROR

Protocol 문서가 없어도 어느 정도 의미를 추측할 수 있습니다.

반면:

AA 55 08 13 03 07 01 9C

는 쉽게 해석하기 어렵습니다.

그래서 Text Protocol은:

초기 개발

시험 장비

Debugging

운영 Log

사람이 직접 Command를 입력하는 Console

환경에서 편리합니다.

9장 Terminal 하나만으로도 Text Protocol을 테스트할 수 있다#

Serial Terminal에서 다음을 직접 입력한다고 하겠습니다.

STATUS,DEV01

장비가:

OK,DEV01,READY

라고 응답합니다.

사람이 눈으로 바로 확인할 수 있습니다.

그래서 단순한 장비에서는 Text Protocol이 유지보수 측면에서 매우 편리할 수 있습니다.

10장 Binary Protocol은 전송 효율에 강점이 있다#

Binary Protocol은 보통 Field를 고정된 Byte 수로 표현할 수 있습니다.

예:

Address
1 Byte

Command
1 Byte

Status
1 Byte

Temperature
2 Bytes

같이 구성할 수 있습니다.

Text로:

DEVICE=17,TEMP=25.3,STATUS=1

을 보내는 것보다 Data Size를 크게 줄일 수 있습니다.

10.1 장비가 많아질수록 차이가 커질 수 있다#

Sensor 한 대가 1초마다 한 번씩 데이터를 보낼 때는 큰 차이가 없을 수 있습니다.

하지만:

장비 1,000대

초당 여러 Message

장기간 운영

처럼 규모가 커지면 Byte 수 차이가 전체 Traffic과 처리량에 영향을 줄 수 있습니다.

11장 Binary가 항상 더 빠른 것은 아니다#

Binary Format이 작다고 해서 시스템 전체가 반드시 더 빠른 것은 아닙니다.

성능에는 다음도 영향을 줍니다.

Baud Rate

Network Latency

Application 처리 속도

Database

Timeout

Retry

Device CPU

Protocol 설계

예를 들어 20 Byte와 40 Byte의 차이가 실제 업무 처리 시간에서는 거의 의미가 없는 시스템도 있습니다.

따라서:

Binary
=
무조건 고성능

이라고 단순화하면 안 됩니다.

12장 Text Parsing은 어떻게 이루어질까#

예:

OPEN,DEV01,1

을 수신했다면 Application은 먼저 문자열을 구분자로 나눌 수 있습니다.

개념적으로:

split(",")

결과:

[0] OPEN

[1] DEV01

[2] 1

그 다음:

Command 확인

Device ID 확인

Parameter 변환

을 수행합니다.

13장 Binary Parsing은 Offset을 기준으로 한다#

Binary Packet:

AA 55 05 10 01 23 45 6F

이 있다고 하겠습니다.

Protocol이 고정되어 있다면:

Offset 값 의미
0~1 AA 55 Header
2 05 Length
3 10 Command
4 01 Address
5~6 23 45 Data
7 6F Checksum

처럼 Offset으로 바로 접근할 수 있습니다.

14장 Binary에서는 Endianness를 반드시 확인한다#

2 Byte Data:

12 34

가 있다고 하겠습니다.

Big Endian이라면:

0x1234

입니다.

Little Endian이라면:

0x3412

로 읽습니다.

따라서 Binary Protocol에서:

Length

Timestamp

Counter

Sensor Value

같은 Multi-byte Field를 읽을 때 Byte Order를 확인해야 합니다.

15장 Text Protocol에서도 Frame 경계가 필요하다#

Text라고 해서 Frame 문제가 없어지는 것은 아닙니다.

예:

OPEN,DEV01\r\nSTATUS,DEV01\r\n

처럼 여러 Message가 연속해서 들어올 수 있습니다.

Application에서는:

\r\n

을 Message Delimiter로 사용해 분리할 수 있습니다.

즉 Text Protocol도 결국:

Message가 어디서 시작하고
어디서 끝나는가

를 정의해야 합니다.

16장 Binary에서는 Header와 Length를 많이 사용한다#

Binary Protocol에서 대표적인 구조는:

[HEADER][LENGTH][COMMAND][DATA][CHECKSUM]

입니다.

예:

AA 55 05 10 01 23 45 6F

Receiver는:

AA 55 발견
↓
Length 읽기
↓
필요 Byte 수만큼 수신
↓
Checksum 검증

순서로 Frame을 찾을 수 있습니다.

17장 한 번의 read가 하나의 Message라는 보장은 없다#

Serial이나 TCP에서 매우 중요한 개념입니다.

송신:

OPEN,DEV01\r\n

을 한 번 보냈다고 하겠습니다.

수신 Application에서는:

OPEN,

이 먼저 들어오고:

DEV01\r\n

이 나중에 들어올 수 있습니다.

Binary도 마찬가지입니다.

AA 55 05

와:

10 01 23 45 6F

로 나뉘어 들어올 수 있습니다.

따라서 Receive Buffer와 Parser가 필요합니다.

18장 반대로 여러 Message가 한 번에 들어올 수도 있다#

Text:

STATUS,01\r\nSTATUS,02\r\nSTATUS,03\r\n

Binary:

AA ... CHK AA ... CHK AA ... CHK

처럼 여러 Frame이 한 번의 read 결과에 들어올 수도 있습니다.

따라서:

read()
=
한 Packet

이라고 가정하면 안 됩니다.

19장 Text Protocol에도 Length Field를 사용할 수 있다#

Text라고 항상:

CRLF

만 이용하는 것은 아닙니다.

예:

LEN=12;OPEN,DEV01

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

반대로 Binary에서도 Delimiter 방식이 가능합니다.

즉:

Text = Delimiter

Binary = Length

이라는 공식은 없습니다.

20장 Binary Payload 안에는 어떤 값이든 들어갈 수 있다#

Binary Protocol에서는 Payload가:

00

02

03

FF

등 어떤 Byte 값도 포함할 수 있습니다.

따라서 0x02를 STX, 0x03을 ETX로 사용하는 Protocol이라면 Payload 안에 같은 값이 등장했을 때 처리 방법이 필요합니다.

대표적으로:

Length Field

Escape

Byte Stuffing

Encoding

등을 사용합니다.

21장 Text Protocol도 Delimiter 문제를 해결해야 한다#

Text Message:

NAME,KIM,DEV01

에서 ,가 Separator라고 하겠습니다.

그런데 실제 Data 값이:

KIM,MARK

이라면 어떻게 할까요?

다음과 같은 규칙이 필요합니다.

Quote 처리

Escape

Length

Encoding

즉 Text라고 Parsing 문제가 단순하게 사라지는 것은 아닙니다.

22장 Checksum과 CRC는 Text와 Binary 모두 사용할 수 있다#

오류 검출 방식은 Binary만의 기능이 아닙니다.

Text Message:

OPEN,01*5A

처럼 끝에 Checksum을 붙일 수 있습니다.

Binary:

AA 55 05 10 01 23 45 6F

에서도 Checksum이나 CRC를 사용할 수 있습니다.

즉:

Text / Binary

와:

Checksum / CRC

는 별도의 선택 문제입니다.

23장 Text Protocol의 오류 검출은 단순 문자열 검증만으로 충분할까#

다음 Message:

OPEN,DEV01

이:

OPEN,DEV02

로 전송 중 변경되었다면 문법적으로는 여전히 정상입니다.

따라서 중요한 장비 Protocol에서는 Text 방식이라도:

Checksum

CRC

Message Authentication

등을 사용할 수 있습니다.

24장 Binary Protocol에서 Checksum은 어디를 계산할까#

예:

AA 55 05 10 01 23 45 CHK

라고 하겠습니다.

Checksum 계산 범위가:

05부터 45까지

일 수도 있고:

AA부터 45까지

일 수도 있습니다.

Header를 제외할 수도 있습니다.

그래서 Protocol 문서에서:

Checksum Algorithm

Checksum Range

를 둘 다 확인해야 합니다.

25장 주차관제 장비에서는 어떤 방식을 볼 수 있을까#

현장에서는 두 방식 모두 만날 수 있습니다.

예를 들어 간단한 Controller Command는:

OPEN,01\r\n

같은 Text Protocol일 수 있습니다.

반면 Sensor 상태나 Device Event는:

AA 55 08 01 10 00 01 27 4B

같은 Binary Format일 수 있습니다.

26장 하나의 시스템 안에서도 여러 Protocol이 섞인다#

예:

Loop Sensor
↓
RS-485 Binary Protocol
↓
Controller
↓
TCP JSON
↓
Server
↓
REST API
↓
Management UI

처럼 구성할 수 있습니다.

같은 업무 Data가 구간마다 다른 Format으로 변환될 수 있습니다.

27장 Gateway는 Text와 Binary를 서로 변환할 수도 있다#

예:

RS-485 Device

AA 55 05 10 01 ...
        ↓
Gateway
        ↓
JSON

{
  "device": 1,
  "status": "open"
}

Gateway는 단순 전송 장비가 아니라:

Frame Parsing

Protocol Conversion

Address Mapping

Data Normalization

을 수행할 수 있습니다.

28장 Debugging에서는 Text가 확실히 편리하다#

Text Log:

2026-09-24 14:00:01 RX STATUS,DEV01,OPEN

은 사람이 바로 읽을 수 있습니다.

Binary Log:

2026-09-24 14:00:01 RX AA 55 05 20 01 01 4D

는 별도의 Decoder가 필요합니다.

그래서 Binary Protocol을 사용하는 시스템에서도 Log에서는 Parsed 결과를 함께 남기는 것이 좋습니다.

29장 좋은 Binary Log는 Raw와 Parsed를 함께 남긴다#

예:

RX RAW:
AA 55 05 20 01 01 4D

HEADER : AA55
LENGTH : 05
COMMAND: 20
DEVICE : 01
STATUS : 01
CHECK  : 4D

이런 형태면:

현장 운영자

개발자

Protocol 담당자

가 모두 활용할 수 있습니다.

30장 Text도 Raw Log를 남길 필요가 있다#

Application에서는:

Invalid Command

라고만 남겼는데 실제 원본이:

OPEN,,DEV01

이었을 수도 있습니다.

따라서 Text Protocol에서도:

Raw Message

Parsed Result

Timestamp

Direction

을 남기면 분석에 도움이 됩니다.

31장 Binary Protocol은 Parser 검증을 더 엄격하게 해야 한다#

Binary Frame의 Length 값이 손상되어:

FF FF

처럼 비정상적으로 큰 값이 들어오면 Parser가 무한정 Data를 기다릴 수 있습니다.

따라서:

Maximum Frame Length

Minimum Frame Length

Command별 Data Length

Checksum 검증

같은 방어가 필요합니다.

32장 Text Protocol도 입력값 검증이 필요하다#

예:

OPEN,DEV01,999999999999

같은 Message가 들어올 수 있습니다.

따라서:

Field 수

문자열 길이

숫자 범위

허용 Command

Encoding

을 검증해야 합니다.

33장 보안은 Text와 Binary 중 어느 쪽이 더 안전할까#

둘 중 하나가 자동으로 더 안전한 것은 아닙니다.

Text:

OPEN,DEV01

은 사람이 쉽게 읽을 수 있습니다.

하지만 Binary:

AA 01 10 01 BC

도 Format을 알고 있으면 쉽게 해석할 수 있습니다.

따라서 보안은 별도로:

Authentication

Authorization

Encryption

Integrity Protection

Replay Protection

을 설계해야 합니다.

34장 Binary가 읽기 어렵다고 보안 기능은 아니다#

다음 두 Message가 같은 의미라고 하겠습니다.

OPEN,01
AA 01 10 5B

후자가 사람이 읽기 어렵다는 사실은:

공격자가 이해하기 어렵다.

는 정도의 일시적인 난이도만 높일 수 있을 뿐 보안 설계가 아닙니다.

Protocol Format은 Capture와 분석을 통해 파악될 수 있습니다.

35장 Text Protocol에서는 명령 삽입을 조심한다#

Text 기반 Command를 Application에서 그대로 조합한다면:

Command Separator

Line Break

Escape Character

특수 문자

처리를 잘못해 Parsing 문제가 생길 수 있습니다.

특히 외부 입력값을 그대로 Device Command 문자열에 삽입하는 방식은 피해야 합니다.

입력값을 검증하고 허용된 Command만 생성해야 합니다.

36장 Binary Parser에서도 길이와 Offset 검증이 중요하다#

Binary Parser가:

Length = 10

이라고 읽었는데 실제 Receive Buffer에는 4 Byte만 있다면 즉시 Field에 접근하면 안 됩니다.

먼저:

필요 Byte 확보
↓
Length 범위 검증
↓
Checksum 검증
↓
Field Parsing

순서로 처리해야 합니다.

37장 전송 효율만으로 Protocol을 선택하면 안 된다#

Protocol을 선택할 때 고려할 항목은 더 많습니다.

장비 CPU

Memory

Network 속도

Data 빈도

Debugging 필요성

개발 인력

장기 유지보수

확장성

기존 장비 호환성

입니다.

38장 Text Protocol이 적합할 수 있는 상황#

다음과 같은 환경에서는 Text 방식이 실용적일 수 있습니다.

Message 양이 적음

사람이 직접 Debugging해야 함

Command 구조가 단순함

개발·유지보수 편의성이 중요함

Bandwidth가 충분함

예:

STATUS,01

RESET,03

VERSION

같은 단순 Command입니다.

39장 Binary Protocol이 적합할 수 있는 상황#

다음과 같은 경우에는 Binary가 유리할 수 있습니다.

Sensor Data가 많음

전송량을 줄여야 함

저속 Serial Link

저사양 MCU

고정된 Field 구조

빠른 Parsing이 중요함

하지만 이것도 절대적인 규칙은 아닙니다.

40장 Binary에서 가변 길이 Data를 사용하면 구조가 복잡해진다#

예:

HEADER
LENGTH
COMMAND
DATA
CRC

에서 Data 길이가 계속 달라지면 Parser는 Length에 크게 의존합니다.

Length Field 하나가 손상되면 이후 Frame Boundary도 무너질 수 있습니다.

따라서:

Length 검증

Maximum Length

CRC

Resynchronization

이 중요합니다.

41장 Text도 가변 길이 Data에서 문제가 생긴다#

예:

EVENT,DEV01,2026-09-24,ALARM

처럼 Data가 길어질 수 있습니다.

구분자 기반 Parser라 해도:

Field 개수

최대 Message Length

종료 문자

Escape 규칙

을 검증해야 합니다.

42장 장애가 발생하면 먼저 Protocol 유형부터 확인한다#

Raw Data가 다음처럼 보인다고 하겠습니다.

4F 50 45 4E 2C 30 31 0D 0A

ASCII로 변환하면:

OPEN,01

입니다.

이런 패턴이 반복된다면 Text 기반 Protocol일 가능성이 있습니다.

반면:

AA 55 0C 01 04 00 FF 12 79 31

처럼 Printable Character와 관계없이 Byte 값이 사용된다면 Binary Protocol 가능성이 높습니다.

43장 HEX Dump에서 Printable ASCII를 찾아보는 것도 방법이다#

예:

31 32 33 34 35

는 ASCII로:

12345

입니다.

Binary Packet 내부의 Payload 일부만 Text일 수도 있습니다.

따라서:

Binary Packet
=
모든 Byte가 Binary Number

라고 생각하지 않습니다.

실제로 모든 Data는 Byte이며 각 Field를 어떤 의미와 Encoding으로 해석하는지가 핵심입니다.

44장 Protocol 유형을 분석하는 순서#

처음 보는 장비라면 다음 순서로 확인합니다.

1. Protocol 문서 확보
↓
2. Raw Data Capture
↓
3. HEX와 ASCII 동시 표시
↓
4. Message Boundary 탐색
↓
5. Delimiter 반복 여부 확인
↓
6. Header Pattern 탐색
↓
7. Length 후보 찾기
↓
8. Command 후보 찾기
↓
9. Checksum·CRC 확인
↓
10. 여러 Frame 비교

45장 ASCII와 Binary 비교#

비교 항목 Text·ASCII Protocol Binary Protocol
사람이 읽기 쉬움 어려움
Debugging 편리 Decoder 필요
전송량 상대적으로 커질 수 있음 작게 구성 가능
숫자 표현 문자열 정수 Byte
Parsing Delimiter·문자열 중심 Offset·Length 중심
Endianness 영향 적은 경우 많음 매우 중요할 수 있음
Frame 경계 CR/LF·Delimiter 등 Header·Length 등
오류 검출 Checksum·CRC 가능 Checksum·CRC 가능
확장성 사람이 수정하기 쉬움 Protocol 설계 필요
보안 별도 설계 필요 별도 설계 필요

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

46.1 ASCII Protocol은 사람이 읽을 수 있으니 보안에 취약하고 Binary는 안전하다#

둘 다 별도의 보안 기능이 없으면 안전하다고 볼 수 없습니다.

46.2 Binary는 항상 Text보다 빠르다#

Protocol Size뿐 아니라 전체 시스템 처리 구조가 성능을 결정합니다.

46.3 Text에는 Checksum이 필요 없다#

중요한 Data라면 Text Protocol에서도 무결성 검증이 필요할 수 있습니다.

46.4 Binary는 항상 고정 길이다#

가변 길이 Binary Protocol도 매우 많습니다.

46.5 ASCII Protocol이면 모든 Byte를 문자로 해석하면 된다#

Control Character와 Binary Field가 함께 사용될 수도 있습니다.

46.6 JSON이면 반드시 HTTP를 사용한다#

아닙니다.

JSON은 Data Format이고 Serial이나 TCP에서도 전송할 수 있습니다.

46.7 Binary Protocol이면 RS-485다#

아닙니다.

Binary Protocol은 TCP·UDP·Serial 등 다양한 전송 방식 위에서 사용할 수 있습니다.

47장 현장 점검 체크리스트#

□ Text Protocol인지 Binary Protocol인지 확인했는가?

□ Encoding이 ASCII인지 UTF-8인지 확인했는가?

□ Message 종료 문자를 확인했는가?

□ CR·LF·CRLF 중 무엇을 사용하는가?

□ Binary Header Pattern을 확인했는가?

□ Length Field의 위치와 의미를 확인했는가?

□ Endianness를 확인했는가?

□ Payload Encoding을 확인했는가?

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

□ Message 최대 길이를 확인했는가?

□ Timeout·Retry 정책을 확인했는가?

□ Raw와 Parsed Log를 함께 확보했는가?

□ 민감한 Payload를 Log에 그대로 저장하고 있지 않은가?

48장 자기 점검#

48.1 Text Protocol과 Binary Protocol의 가장 큰 차이는 무엇인가#

Text Protocol은 의미를 문자 형태로 표현하고 Binary Protocol은 Byte 값 자체에 의미를 부여합니다.

48.2 Binary Protocol이 전송량 측면에서 유리할 수 있는 이유는 무엇인가#

숫자나 상태를 문자열 대신 적은 수의 Byte로 표현할 수 있기 때문입니다.

48.3 Text Protocol에서도 Frame 경계가 필요한가#

필요합니다.

CR·LF·Delimiter 또는 Length 등의 규칙으로 Message 경계를 정의해야 합니다.

48.4 Binary Protocol에서 가장 주의할 항목은 무엇인가#

Header, Length, Offset, Endianness, Checksum·CRC 등 Protocol 구조를 정확히 따라야 합니다.

48.5 Binary Protocol은 암호화된 Protocol인가#

아닙니다.

Binary 표현과 Encryption은 서로 다른 개념입니다.

49장 이 글을 마치며#

장비 통신에서 Text와 Binary의 차이는 단순히:

사람이 읽을 수 있는가?

만의 문제가 아닙니다.

Text Protocol은:

OPEN,DEV01,1

처럼 의미를 문자로 표현합니다.

Binary Protocol은:

AA 55 05 10 01 23 45 6F

처럼 Byte 위치와 값에 의미를 부여합니다.

전체적으로 보면:

업무 의미
↓
Protocol
↓
Text 또는 Binary 표현
↓
Frame
↓
Byte Stream
↓
RS-232 / RS-485 / TCP

으로 이어집니다.

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

Text Protocol은 사람이 읽고 Debugging하기 쉽지만 표현에 필요한 Byte 수가 커질 수 있습니다.

Binary Protocol은 적은 Byte로 정보를 표현하고 고정 Offset Parsing에 유리하지만 사람이 직접 해석하기 어렵습니다.

Text와 Binary 모두 Frame의 시작과 끝, Length, 오류 검출 규칙이 필요합니다.

Binary라는 이유만으로 보안성이 높아지는 것은 아니며 인증·암호화는 별도로 설계해야 합니다.

어떤 Protocol이 더 좋은가는 전송량 하나가 아니라 장비 성능·운영·Debugging·호환성까지 함께 판단해야 합니다.

결국 Text와 Binary Protocol을 이해한다는 것은 둘 중 하나를 더 좋은 방식으로 선택하는 것이 아닙니다.

같은 업무 데이터를 서로 다른 방식으로 표현했을 때 Byte Stream이 어떻게 달라지고, 수신측 Parser가 그 데이터를 어떤 규칙으로 다시 의미 있는 값으로 복원하는지를 이해하는 것이 핵심입니다.

이 페이지의 목차