비트(bit)부터 패킷(packet)까지: 컴퓨터가 데이터를 표현하고 전달하는 방법

비트부터 패킷까지: 컴퓨터가 데이터를 표현하고 전달하는 방법#

RFID 판독기는 태그를 읽었는데 차단기가 열리지 않는다. 화면에는 태그값이 깨진 문자로 표시된다. 서버에는 요청을 받았다는 로그도 남아 있다. 그렇다면 통신은 정상일까?

아직 그렇게 판단할 수 없다. 장비가 데이터를 보낸 것, 수신 장비에 바이트가 도착한 것, 프로그램이 값을 올바르게 해석한 것, 출입 판단을 마친 것은 서로 다른 단계다. 어느 단계에서 문제가 생겼는지 알려면 데이터가 비트와 바이트로 표현되는 순간부터 메시지로 해석되는 순간까지 따라가야 한다.

이 글에서는 비트·바이트·16진수·문자 인코딩을 먼저 살펴보고, 데이터가 프레임과 패킷에 실려 전달되는 구조를 설명한다. 이어서 RFID 판독기와 번호판 인식 카메라 사례를 통해 헥스 덤프를 읽고 현장 장애의 범위를 좁히는 방법을 알아본다.

비트와 바이트는 무엇인가#

비트는 데이터의 기본 단위다#

비트(Bit)는 0 또는 1로 표현하는 데이터 단위다. 여러 비트를 조합하면 숫자와 문자뿐 아니라 장비 상태나 명령 코드도 나타낼 수 있다.

바이트(Byte)는 일반적으로 비트 8개를 묶은 단위다. 예를 들어 다음은 8비트, 즉 1바이트다.

01000001

이 값을 10진수로 표시하면 65, 16진수로 표시하면 41이다. ASCII 문자 규칙으로 해석하면 영문 대문자 A가 된다.

표현 방법 값 설명
이진수 01000001 한 바이트를 구성하는 비트
10진수 65 같은 값을 10진수로 표시
16진수 41 같은 값을 16진수로 표시
ASCII 문자 A 문자 규칙에 따라 해석한 결과

네 줄이 각각 다른 데이터는 아니다. 하나의 바이트를 어떻게 표시하고 해석하느냐에 따라 결과가 달라진 것이다.

이 차이는 통신 장애를 분석할 때 중요하다. 로그에 41이 보인다고 해서 무조건 문자 A가 전송됐다고 결론 내릴 수 없다. 프로그램이 숫자 65를 보냈을 수도 있고, 여러 필드로 구성된 바이너리 메시지의 일부일 수도 있다.

전송 속도와 데이터 크기의 단위도 다르다#

전송 속도는 흔히 초당 비트 수인 bps로, 데이터 크기는 바이트 단위로 표시한다. 두 단위를 혼동하면 필요한 대역폭이나 전송 시간을 잘못 계산할 수 있다.

예를 들어 8메가비트(Mb)는 비트 수만 바이트로 환산하면 1메가바이트(MB)다. 다만 실제 통신에서는 응용 데이터 외에 프레임과 패킷의 헤더, 응답, 재전송 등에 쓰이는 데이터도 전달된다. 따라서 네트워크의 표시 속도 전체를 실제 업무 데이터의 전송 속도로 볼 수는 없다.

이진수와 16진수는 왜 함께 사용할까#

컴퓨터가 처리하는 바이트를 모두 이진수로 표시하면 사람이 읽기 어렵다.

01010100 01000001 01000111

16진수는 4비트를 한 자리로 표현한다. 따라서 한 바이트는 보통 16진수 두 자리로 표시할 수 있다.

54 41 47

위 두 줄은 같은 바이트열이다. 통신 로그나 패킷 분석 도구에서 바이트를 16진수로 보여주는 이유도 여기에 있다. 16진수는 별도의 전송 방식이 아니라 바이트를 읽기 쉽게 표시하는 방법이다.

예를 들어 ASCII 문자열 OPEN은 다음 바이트로 표현된다.

문자:      O   P   E   N
16진수:   4F  50  45  4E

헥스 덤프에서 4F 50 45 4E을 발견하면 ASCII로 OPEN이라고 읽을 수 있다. 그렇다고 곧바로 실제 장비의 열기 명령이라고 판단해서는 안 된다. 장비의 명령 형식에는 시작 값, 길이, 체크섬, 종료 값 등이 추가될 수 있고, OPEN이라는 문자열 자체가 명령이 아닐 수도 있다.

문자는 어떤 규칙으로 바이트가 될까#

ASCII와 Unicode의 차이#

ASCII는 영문자, 숫자, 일부 기호와 제어 문자를 표현하는 문자 규칙이다. 영문 A를 값 41로 표현하는 것이 한 예다.

Unicode는 여러 언어의 문자에 고유한 값을 부여하는 문자 체계다. Unicode 문자를 실제 바이트로 표현할 때는 UTF-8, UTF-16 같은 인코딩 방식을 사용한다. 따라서 Unicode 자체를 하나의 바이트 인코딩 방식으로 생각하면 혼동하기 쉽다.

장비와 서버가 같은 문자를 다루더라도 서로 다른 인코딩으로 바이트를 만들거나 읽으면 화면에 깨진 문자가 나타날 수 있다. 영문과 숫자만 사용할 때는 문제가 드러나지 않다가 한글 상태명이나 사용자 이름을 추가한 뒤 오류가 발견되기도 한다.

RFID 태그 ID도 반드시 문자로 전송되지는 않는다#

RFID 판독기 화면에 태그 ID 12345678이 표시된다고 해보자. 이 값의 전송 형태는 장비 규약에 따라 다를 수 있다.

  • 숫자 문자 1부터 8까지를 ASCII 바이트로 전송
  • 태그 ID를 숫자 데이터로 변환해 정해진 길이의 바이트로 전송
  • 식별자, 상태값, 길이 등과 함께 제조사 고유 형식으로 전송

수신 프로그램이 ASCII 문자열을 기대하는데 판독기가 바이너리 형식으로 보낸다면, 데이터가 정상 도착해도 값이 깨지거나 엉뚱한 ID로 해석될 수 있다. 이때 필요한 것은 화면에 보이는 값을 추측하는 일이 아니라 제조사 통신 명세와 실제 수신 바이트를 비교하는 일이다.

데이터는 어떻게 프레임과 패킷에 실릴까#

서로 다른 계층의 전송 단위#

네트워크를 설명할 때 프레임, 패킷, 세그먼트, 메시지라는 용어가 함께 등장한다. 각각 주로 가리키는 단계가 다르다.

용어 주로 사용하는 계층 의미
프레임(Frame) 데이터링크 계층 같은 링크에서 데이터를 전달하는 단위
패킷(Packet) 네트워크 계층 IP 주소를 바탕으로 네트워크 사이를 전달하는 단위
세그먼트(Segment) TCP 전송 계층 포트와 전송 제어 정보를 포함하는 단위
메시지(Message) 응용 계층 프로그램이 주고받으려는 논리적 내용

이더넷으로 IP 통신을 한다면 일반적으로 IP 패킷이 이더넷 프레임 안에 실린다. 여러 프레임이 모여 하나의 IP 패킷을 만든다고 설명하면 구조를 잘못 이해하기 쉽다.

또한 물리 매체로는 전기 신호, 빛, 무선 신호 등이 전달되지만, 어떤 신호 규칙과 프레임 형식을 사용하는지는 해당 통신 기술이 정한다. 모든 센서나 시리얼 장비가 이더넷 프레임을 사용하는 것은 아니다.

카메라가 HTTP 요청을 보낼 때#

주차장 입구의 번호판 인식 카메라가 중앙 서버에 JSON 형식의 HTTP POST 요청을 보낸다고 가정해 보자. 현장 구성에 따라 카메라, 스위치, 라우터, 방화벽, 서버를 거칠 수 있다.

이더넷·IP·TCP를 사용하는 구간에서 데이터의 포함 관계를 단순화하면 다음과 같다.

이더넷 프레임
└─ IP 패킷
   └─ TCP 세그먼트
      └─ HTTP 메시지
         └─ JSON 본문

이더넷 프레임에는 해당 링크에서 전달하는 데 필요한 정보가 담긴다. IP 패킷에는 출발지와 목적지 IP 주소가, TCP 세그먼트에는 포트와 전송 제어에 필요한 정보가 담긴다. HTTP 메시지에는 요청 방식과 헤더, 본문이 포함된다.

이때 JSON 본문은 HTTP 메시지의 본문이다. 다만 네트워크 캡처에서 보이는 TCP 세그먼트 한 개가 HTTP 요청 한 개와 언제나 정확히 일치하는 것은 아니다. TCP는 프로그램에 연속된 바이트 흐름을 제공하기 때문이다.

현장에서 계층별로 확인할 내용#

확인 영역 장비·구성 예 판단에 필요한 정보
물리 연결 UTP 케이블, 광포트, 무선 연결 전원, 케이블, 포트 상태, 링크 표시
데이터링크 스위치 포트, MAC 주소, VLAN 링크 오류, 프레임 오류, VLAN 설정
네트워크 라우터, 방화벽, IP 주소 주소 충돌, 경로, 방화벽 정책, MTU
응용 처리 판독기 프로그램, 관제 서버 인코딩, 메시지 형식, 업무 처리 결과

이 표는 장애를 한 번에 진단하는 공식이 아니다. 문제가 관찰되는 위치를 찾기 위한 지도다.

메시지와 페이로드는 무엇이 다를까#

메시지는 보통 응용 프로그램이 주고받으려는 논리적인 내용을 가리킨다. “태그 ID를 보고한다” 또는 “차단기를 열도록 요청한다”는 식으로 의미를 설명할 수 있다.

페이로드는 특정 계층에서 실제로 전달하려는 내용 부분을 가리킨다. 따라서 어느 계층의 페이로드인지 함께 확인해야 한다.

  • 이더넷 프레임의 페이로드에는 IP 패킷이 실릴 수 있다.
  • IP 패킷의 페이로드에는 TCP 데이터가 실릴 수 있다.
  • HTTP 요청의 본문에는 JSON 데이터가 들어갈 수 있다.

제조사 로그에서는 message와 payload를 다른 뜻으로 사용할 수도 있다. 로그에 payload라고 표시됐다는 사실만으로 그 값이 순수한 업무 데이터인지, 장비 프로토콜의 헤더까지 포함한 바이트열인지는 알 수 없다.

헥스 덤프로 통신 데이터 읽기#

헥스 덤프(Hex Dump)는 실제 바이트를 16진수로 나열해 보여주는 방식이다. 문자열이 깨지거나 값이 잘못 해석될 때, 화면에 표시된 결과 대신 수신한 바이트 자체를 확인할 수 있다.

OPEN 예제#

다음은 실제 장비에 전송할 명령이 아닌, 문자와 바이트의 관계를 보여주는 교육용 예제다.

4F 50 45 4E 0D 0A
 O  P  E  N  CR LF

ASCII 기준으로 4F 50 45 4E은 OPEN이다. 0D와 0A는 각각 CR과 LF다. 텍스트 기반 통신 규약에서는 줄 끝을 나타내는 데 사용될 수 있다. 다만 해당 장비가 실제로 CR LF를 메시지 종료 조건으로 사용하는지는 명세서로 확인해야 한다.

같은 영문 글자라도 16비트 단위의 다른 문자 표현을 사용한다면 바이트 배열이 달라질 수 있다.

ASCII 또는 UTF-8의 영문 OPEN:
4F 50 45 4E

UTF-16BE로 표현한 영문 OPEN:
00 4F 00 50 00 45 00 4E

영문 OPEN이 두 경우에 똑같이 보이더라도 실제 바이트는 다르다. 수신 장비가 예상한 인코딩으로 읽지 않으면 값이 잘못 표시된다.

TAG:123456 예제#

시험용 RFID 시뮬레이터가 다음 문자열을 ASCII로 보낸다고 가정하자.

TAG:123456

해당 문자열의 바이트를 16진수로 표시하면 다음과 같다.

54 41 47 3A 31 32 33 34 35 36
 T  A  G  :  1  2  3  4  5  6

헥스 덤프를 읽을 때는 단순히 문자로 바꾸는 데서 멈추지 않는다. 다음 질문까지 확인해야 한다.

  1. 이 바이트는 판독기의 송신 기록인가, 컨트롤러의 수신 기록인가?
  2. 전체 메시지인가, 헤더를 제외한 일부 데이터인가?
  3. TAG:가 실제 프로토콜의 필드 표시인가?
  4. 뒤에 종료 값이나 오류 검출 값이 붙는가?
  5. 컨트롤러는 123456을 어떤 태그 ID로 해석했는가?

같은 바이트를 관찰했어도 마지막 질문에 답하지 못하면 업무 처리 결과까지 확인한 것은 아니다.

주차관제 현장에서 데이터 흐름 따라가기#

다음은 RFID 판독기와 게이트 컨트롤러, 중앙 서버가 연결된 현장을 이해하기 위한 예시다. 실제 설치 방식과 판단 주체는 제품 및 현장 구성에 따라 달라진다.

RFID 판독기 → 게이트 컨트롤러 → 중앙 서버
                                     ↓
                               출입 판단 결과
                                     ↓
                                차단기 제어

판독기: 태그값을 만든다#

판독기는 태그를 읽고 식별값을 얻는다. 이후 해당 장비의 규약에 맞춰 식별값을 바이트로 표현한다.

이 단계에서 확인할 내용은 태그 읽기 성공 여부와 판독기가 만들어낸 값이다. 판독기 화면의 성공 표시만으로 다음 장비에 같은 값이 전송됐다고 단정할 수는 없다.

통신 구간: 바이트를 전달한다#

장비에 따라 시리얼 통신이나 TCP 기반 통신을 사용할 수 있다. 시리얼 통신에서는 배선과 통신 속도, 패리티 등 양쪽 설정을 확인한다. TCP 기반 통신에서는 주소, 포트, 네트워크 경로와 방화벽 정책 등을 확인한다.

어느 방식이든 이 단계의 질문은 같다. 판독기가 보낸 바이트가 다음 장비에 도착했는가?

컨트롤러와 서버: 값을 해석하고 판단한다#

바이트가 도착하면 수신 측은 메시지 경계를 찾고, 필드와 인코딩을 규약에 따라 해석한다. 그다음 출입 정책을 적용한다.

태그 ID가 정확하게 해석됐더라도 출입 권한이 없으면 차단기 열기 명령이 생성되지 않을 수 있다. 반대로 출입이 승인됐어도 제어 명령 전달이나 차단기 동작에 문제가 생길 수 있다.

따라서 “차단기가 열리지 않는다”는 하나의 증상에 대해 다음을 각각 확인해야 한다.

단계 확인 질문
판독 태그를 실제로 읽었는가?
전송 판독기가 어떤 바이트를 보냈는가?
수신 컨트롤러가 같은 바이트를 받았는가?
해석 수신 측에서 같은 태그 ID로 해석했는가?
판단 출입 허용 결과가 생성됐는가?
제어 열기 명령이 전달되고 처리됐는가?

통신 장애가 생겼을 때 어디부터 볼까#

데이터가 전혀 도착하지 않을 때#

전원과 연결 상태, 케이블, 포트를 확인한다. 네트워크 장비를 사용하는 경우에는 링크 상태, IP 주소, 라우팅과 방화벽 정책을 살펴본다. 시리얼 연결이라면 배선과 양쪽 통신 설정을 비교한다.

데이터가 간헐적으로 누락될 때#

오류가 발생한 시각과 반복 조건을 먼저 기록한다. 물리 연결 문제와 통신 오류뿐 아니라 타임아웃, 재시도, 수신 프로그램의 처리 지연도 가능성에 포함한다.

CRC 오류가 반복적으로 관찰된다면 케이블과 접점, 전기적 간섭, 배선 조건 등을 살펴볼 단서가 된다. 다만 오류 발생만으로 특정 케이블이나 장비의 고장을 확정하지는 않는다.

데이터는 도착하지만 값이 깨질 때#

송신 지점과 수신 지점의 원시 바이트를 비교한다. 두 값이 같다면 문자 인코딩, 필드 길이, 숫자 해석, 제조사 메시지 형식을 확인한다. 두 값이 다르다면 통신 경로와 중간 처리 과정을 조사한다.

특히 로그에 표시된 문자열만 비교하면 프로그램이 이미 잘못 해석한 결과를 원본으로 착각할 수 있다. 가능하다면 가공 전 바이트를 기준으로 비교한다.

값은 정상인데 차단기가 열리지 않을 때#

출입 판단 결과와 제어 명령의 생성·전달·처리 결과를 구분한다. 서버 로그에 요청이 남았다는 것은 요청을 관찰했다는 뜻이지, 판단과 장비 동작까지 완료됐다는 뜻은 아니다.

시험 환경에서 직접 확인해 보기#

실제 차단기나 운영 장비 대신 시험용 송신 프로그램과 수신 프로그램을 사용하면 바이트와 문자 해석의 차이를 확인할 수 있다.

  1. 송신 프로그램이 TAG:123456을 ASCII 또는 UTF-8 바이트로 만든다.
  2. 수신 프로그램은 받은 바이트를 16진수와 문자열로 각각 출력한다.
  3. 바이트가 54 41 47 3A 31 32 33 34 35 36인지 비교한다.
  4. 문자열이 TAG:123456으로 해석되는지 확인한다.
  5. 다음에는 송신·수신 측의 인코딩이나 메시지 경계 조건을 다르게 설정하고 결과가 어떻게 달라지는지 관찰한다.

이 실습의 목표는 실제 장비 명령을 만드는 것이 아니다. 도착한 바이트와 프로그램이 해석한 문자열을 별개의 결과로 확인하는 것이다.

캡처와 로그를 다룰 때 주의할 점#

패킷 캡처와 장비 로그에는 카드 식별값, 차량번호, 인증 정보 등이 포함될 수 있다. 문제 분석에 필요한 시간대와 장비로 수집 범위를 제한하고, 공유할 때는 식별 정보와 인증 정보를 가린다.

또한 실제 차단기를 움직일 수 있는 명령을 임의로 전송하지 않는다. 명령 형식이나 오류 복구 절차를 검증해야 한다면 장비 제조사의 절차를 확인하고, 승인된 시험망이나 시뮬레이터에서 먼저 수행한다.

분석 기록에는 다음을 남겨두면 이후에도 같은 과정을 재현하기 쉽다.

  • 문제 발생 시각과 대상 장비
  • 기대한 결과와 실제 결과
  • 송신 측·수신 측에서 확인한 바이트
  • 사용한 인코딩과 메시지 형식
  • 통신 오류 및 업무 처리 결과
  • 변경한 설정과 변경 후 결과

자주 헷갈리는 질문#

비트와 바이트는 어떻게 다른가?#

비트는 0 또는 1 한 값이다. 바이트는 일반적으로 비트 8개를 묶은 단위다.

바이너리와 16진수는 어떻게 다른가?#

바이너리는 문맥에 따라 이진수 표기나 문자로 표현하지 않은 데이터 형식을 가리킨다. 16진수는 바이트 값을 사람이 읽기 쉽게 나타내는 표기 방식이다. 따라서 바이너리 데이터도 헥스 덤프로 표시할 수 있다.

ASCII와 Unicode는 어떻게 다른가?#

ASCII는 제한된 문자들을 표현하는 문자 규칙이다. Unicode는 여러 언어의 문자에 값을 부여하는 체계이며, UTF-8과 UTF-16 등은 Unicode 문자를 바이트로 표현하는 방식이다.

프레임과 패킷은 어떻게 다른가?#

프레임은 데이터링크 계층의 전송 단위이고, IP 패킷은 네트워크 계층의 전송 단위다. 이더넷 통신에서는 IP 패킷이 이더넷 프레임에 실린다.

헥스 덤프에서 실제 업무 데이터를 어떻게 찾는가?#

먼저 캡처가 어느 계층부터 시작하는지 확인한다. 이후 프로토콜 분석 결과나 명세서의 헤더 길이와 필드 구조를 이용해 해당 데이터의 시작 위치를 찾는다. 헤더 크기를 무조건 고정값으로 가정하면 옵션, 태그, 확장 헤더 등이 있는 경우 위치를 잘못 계산할 수 있다.

정리#

비트와 바이트는 데이터가 표현되는 기본 단위다. 이진수와 16진수는 그 값을 표시하는 방법이고, 인코딩과 프로토콜은 바이트에 문자와 숫자, 명령의 의미를 부여한다. 프레임과 패킷은 그 데이터를 전달하는 서로 다른 계층의 단위다.

RFID 판독기의 태그값이 깨져 보이거나 차단기가 열리지 않는다면 “통신 오류”라는 한 단어로 묶지 말자. 읽은 값 → 전송한 바이트 → 수신한 바이트 → 해석한 값 → 출입 판단 → 장비 동작을 차례로 확인하면 문제가 발생한 지점을 더 정확하게 찾을 수 있다.

이 페이지의 목차