185. 바이트 카운트 (Byte Counting) 방식

핵심 인사이트 (3줄 요약)

본질: 바이트 카운트 (Byte Counting) 방식은 프레임 (Frame) 시작 부분에 길이 정보를 적어 두고, 수신기가 그 숫자만큼 바이트를 읽어 프레임 경계를 정하는 가장 단순한 길이 기반 프레이밍 (Framing) 기법이다.

가치: payload 안에 특수 구분 문자를 피하기 위한 stuffing이 필요 없어서 구조가 단순하고 오버헤드가 작다.

판단 포인트: 길이 필드 하나가 깨지면 다음 프레임 경계까지 연쇄적으로 무너질 수 있으므로, 재동기화 (Resynchronization) 장치 없이 단독으로 쓰기에는 매우 취약하다.

Ⅰ. 개요 및 필요성

바이트 카운트 방식은 "프레임 길이를 먼저 말해 주고 그만큼 읽는다" 는 발상에서 출발한다. 데이터 링크 계층 (Data Link Layer) 수신기는 연속적으로 들어오는 바이트 스트림만 보면 어디서 프레임이 시작하고 끝나는지 알 수 없다. 이때 프레임 맨 앞에 count field를 두면, 수신기는 별도의 종료 문자 없이도 경계를 계산할 수 있다.

이 방식이 매력적인 이유는 매우 직관적이기 때문이다. 시작 플래그나 escape 문자를 넣지 않아도 되고, payload 안에 어떤 바이트가 들어와도 특별히 변형하지 않아도 된다. 즉 송신기는 "이 프레임은 총 48바이트다" 또는 "payload 길이는 47바이트다"라고 적어 두고, 수신기는 그 규칙만 믿고 읽으면 된다.

다만 이 단순함은 길이 필드에 대한 절대적 신뢰를 전제로 한다. 바이트 카운트는 경계를 표시하는 다른 단서가 거의 없기 때문에, count 값이 틀리면 수신기는 다음 프레임의 일부를 현재 프레임이라고 오해할 수 있다. 그래서 이 기법은 "효율적이지만 스스로 회복하기 어려운" 프레이밍 방식으로 이해해야 한다.

📢 섹션 요약 비유: 바이트 카운트 방식은 택배 상자 겉면에 "안에 물건 12개"라고 적어 두고 그 숫자만 믿고 확인하는 것과 같다. 라벨이 맞으면 빠르지만, 라벨이 틀리면 뒤의 상자까지 같이 헷갈리기 쉽다.

Ⅱ. 아키텍처 및 핵심 원리

핵심 원리는 간단하다. 송신기는 프레임 앞에 count field를 붙이고, 수신기는 먼저 그 필드를 읽은 뒤 남은 길이만큼 데이터를 모은다. 여기서 count가 프레임 전체 길이인지, payload 길이인지, 헤더를 포함하는지는 프로토콜 규약으로 명확히 정해져 있어야 한다. 규약이 흔들리면 같은 바이트열도 송수신 측이 다르게 해석한다.

설계 요소	선택 포인트	영향
count field 크기	1바이트, 2바이트, 그 이상	최대 프레임 크기 결정
길이 기준	전체 길이 vs payload 길이	파서 구현 방식 차이
보호 장치	header checksum, CRC (Cyclic Redundancy Check)	길이 필드 오류 탐지력 향상
sanity check	최대 길이 제한, timeout	비정상 count에 대한 방어

아래 그림은 정상 동작 시 수신기가 어떻게 프레임을 자르는지 보여 준다.

┌───────────────────────────────────────────────────────────────────┐
│ Normal parsing with byte counting                                 │
├───────────────────────────────────────────────────────────────────┤
│ Stream : [05][A][B][C][D][04][X][Y][Z]                            │
│          └──── Frame 1 ────┘└── Frame 2 ──┘                      │
│                                                                   │
│ Receiver steps                                                    │
│   1) read count = 05                                              │
│   2) collect next 4 bytes -> Frame 1 complete                     │
│   3) next byte becomes new count = 04                             │
│   4) collect next 3 bytes -> Frame 2 complete                     │
└───────────────────────────────────────────────────────────────────┘

이 방식은 parser state machine도 단순하게 만든다. READ_LENGTH -> READ_BODY -> FRAME_DONE처럼 상태가 명확하고, delimiter를 찾기 위해 바이트를 계속 검색할 필요도 없다. 그래서 바이트 카운트는 초기 설계나 제어가 쉬운 환경에서 매력적으로 보인다.

그러나 이 단순성은 길이 필드가 정확하다는 전제와 함께만 성립한다. delimiter 기반 방식은 다음 flag를 찾으며 다시 동기화를 시도할 수 있지만, 바이트 카운트는 잘못 읽기 시작하면 다음 length byte 자체를 놓쳐 버릴 위험이 크다.

📢 섹션 요약 비유: 바이트 카운트는 영화관 좌석표에 "이번 줄은 10칸"이라고 써 놓고 그 숫자만큼만 세는 방식과 같다. 숫자만 맞으면 아주 빠르지만, 한 번 잘못 적히면 다음 줄 시작점도 같이 틀어진다.

Ⅲ. 비교 및 연결

바이트 카운트 방식의 장단점은 delimiter 기반 프레이밍과 비교할 때 가장 잘 보인다. 바이트 스터핑 (Byte Stuffing)과 비트 스터핑 (Bit Stuffing)은 payload 안에 경계 표시와 같은 패턴이 나오더라도 escape나 stuffed bit로 구분할 수 있고, 다음 flag를 찾으면 재동기화 가능성이 있다. 반면 바이트 카운트는 오버헤드는 적지만, 길이 필드 손상에 특히 약하다.

비교 항목	바이트 카운트	바이트 스터핑	비트 스터핑
경계 인식	length field	flag + escape byte	flag bit pattern + stuffed bit
payload 투명성	매우 높음	escape 오버헤드 필요	stuffed bit 오버헤드 필요
정상 시 효율	높음	중간	중간
오류 후 복원력	낮음	중간	높음

아래 그림은 count field 하나가 깨졌을 때 왜 문제가 커지는지 보여 준다.

┌───────────────────────────────────────────────────────────────────┐
│ Desynchronization by one corrupted length field                    │
├───────────────────────────────────────────────────────────────────┤
│ Original : [05][A][B][C][D][04][X][Y][Z]                          │
│ Corrupt  : [07][A][B][C][D][04][X][Y][Z]                          │
│                                                                   │
│ Receiver thinks Frame 1 = [07][A][B][C][D][04][X]                 │
│ Remaining stream starts at [Y]                                    │
│   -> Y is now misread as the next length field                    │
│   -> all later boundaries become unreliable                       │
└───────────────────────────────────────────────────────────────────┘

이 취약점 때문에 순수한 byte counting은 현대 링크 계층에서 단독 framing 방식으로는 잘 쓰이지 않는다. 다만 길이 필드 자체는 여전히 중요해서, 이미 외부에서 경계가 잡혀 있거나 헤더가 강하게 보호되는 프로토콜에서는 length 정보를 적극 사용한다. 즉 문제는 length field 자체가 아니라, 그것만 믿고 전체 동기화를 맡기는 설계다.

184번 프레이밍 메커니즘 문서와 연결하면 위치가 명확하다. 프레이밍의 큰 분류 중 바이트 카운트는 "가장 단순한 길이 기반 방식"이고, 이후 기술은 delimiter와 stuffing을 통해 복원력과 투명성을 더 강화하는 방향으로 발전했다.

📢 섹션 요약 비유: 바이트 카운트는 책갈피 없이 "이 장은 20쪽"이라고 메모만 남기는 방식과 같다. 메모가 맞으면 빠르지만, 숫자 하나가 틀리면 다음 장 시작도 함께 잃어버린다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 "바이트 카운트를 쓸 수 있는가?"보다 "길이 필드를 얼마나 믿어도 되는 환경인가?" 를 먼저 따져야 한다. 잡음이 적고, 헤더를 보호할 수 있고, 비정상 길이에 대한 sanity check가 있다면 length-prefixed parsing은 여전히 유용하다. 반대로 raw link 위에서 재동기화 수단 없이 단독으로 쓰면 장애 한 번이 전체 스트림 해석 오류로 번질 수 있다.

실무 판단 기준

count field 보호가 있는가? 헤더 checksum이나 CRC가 없으면 길이 오류를 늦게 발견한다.
최대 길이 제한을 두었는가? 비정상 count가 버퍼 고갈이나 과도한 대기를 유발하지 않게 해야 한다.
재동기화 단서가 있는가? start delimiter, timeout, reset 절차가 있으면 복구 가능성이 높아진다.
링크 품질이 어떤가? 노이즈가 심한 환경에서는 delimiter 기반 방식이 더 안전하다.

현실적인 설계 선택

적합한 경우: 비교적 신뢰할 수 있는 내부 링크, 이미 외부 계층에서 경계가 확보된 프로토콜, 단순한 길이 prefix가 큰 효율을 주는 환경
부적합한 경우: 에러가 자주 발생하는 raw channel, 수신기가 스스로 프레임 경계를 다시 찾아야 하는 환경
보완책: header CRC, maximum frame length, timeout discard, delimiter와 length의 병행 사용

안티패턴

count field만 있으면 자동으로 안전하다고 믿는 설계
길이 오류 시 parser reset 전략 없이 계속 다음 바이트를 길이로 해석하는 구현
"length field가 있으니 stuffing이나 delimiter는 불필요하다"라고 단정하는 답안

기술사 답안에서는 바이트 카운트를 단순히 "길이를 적는다"에서 끝내지 말고, 오버헤드는 작지만 동기화 상실에 약하다는 본질을 분명히 써야 한다. 그리고 현대 설계에서는 보통 보호 장치와 함께 쓰거나, delimiter 기반 방식으로 진화했다는 연결까지 보여 주는 것이 좋다.

📢 섹션 요약 비유: 바이트 카운트 방식은 빠른 계산대와 같다. 손님 수만 정확히 세면 빨리 끝나지만, 숫자를 잘못 세면 다음 줄 손님까지 같이 꼬여 버린다.

Ⅴ. 기대효과 및 결론

바이트 카운트 방식의 장점은 분명하다. 구조가 단순하고, payload를 가공하지 않아도 되며, 정상 동작 시 parsing 비용이 낮다. 그래서 framing의 출발점을 설명할 때 매우 좋은 예가 되고, 실제 시스템에서도 length field 자체는 여전히 널리 쓰인다.

하지만 순수한 byte counting은 self-recovery가 약하다는 치명적 한계를 가진다. 프레임 경계가 오직 숫자 하나에 의존하면, 그 숫자가 깨졌을 때 수신기는 어디서 다시 맞춰야 하는지 알기 어렵다. 그래서 현대 링크 설계는 delimiter, stuffing, 헤더 보호, timeout 같은 장치를 함께 넣어 복원력을 강화한다.

정리하면 바이트 카운트 방식은 "가장 단순한 길이 기반 프레이밍이지만, 길이 필드 오류에 취약해 단독 사용은 위험한 방법" 으로 기억하면 된다. 시험에서는 장점보다 이 취약점과 진화 방향을 함께 쓰는 것이 핵심이다.

📢 섹션 요약 비유: 바이트 카운트는 줄자 하나로 상자를 포장하는 방법과 같다. 줄자가 정확하면 깔끔하지만, 눈금 하나가 틀리면 포장 전체가 비뚤어진다.

📌 관련 개념 맵

개념	연결 포인트
프레임 (Frame)	바이트 카운트가 경계를 정해 주는 데이터 링크 계층의 기본 단위다
Count Field	프레임 길이를 명시하는 핵심 헤더 요소다
Resynchronization	길이 필드 오류 후 다시 경계를 찾는 능력으로, 바이트 카운트의 약점이 드러나는 지점이다
바이트 스터핑 (Byte Stuffing)	delimiter 기반 재동기화를 가능하게 하는 대안 방식이다
비트 스터핑 (Bit Stuffing)	비트 지향 링크에서 flag 충돌을 막는 진화형 방식이다
CRC (Cyclic Redundancy Check)	길이 필드와 프레임 전체 오류를 탐지하는 보호 수단이다

📈 관련 키워드 및 발전 흐름도

Continuous byte stream
    │
    ▼
Length field based framing
    │
    ▼
Fast normal parsing
    │
    ├──────────────▶ Corrupted count -> desynchronization cascade
    ├──────────────▶ Header protection and sanity checks
    └──────────────▶ Byte stuffing / bit stuffing evolution

이 흐름도는 바이트 카운트가 단순한 length framing에서 출발해, 오류 취약점 때문에 보호 장치와 다른 framing 기법으로 확장되는 과정을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

바이트 카운트 방식은 상자 맨 앞에 "안에 물건이 몇 개 들어 있어요"라고 숫자를 적어 두는 방법이에요.
숫자가 맞으면 아주 빨리 셀 수 있지만, 숫자 하나가 틀리면 다음 상자까지 같이 헷갈려요.
그래서 요즘은 숫자만 믿지 않고, 따로 표식도 붙이거나 다시 확인하는 방법을 함께 써요.