💡 핵심 인사이트
바이트 카운트 방식은 프레임을 자를 때 특수 문자를 쓰지 않고, 프레임 헤더 맨 앞쪽 칸(Count Field)에 "이 프레임은 나를 포함해서 총 몇 바이트짜리야"라고 길이를 숫자로 적어 넣는 아주 직관적이고 고전적인 프레이밍 기법입니다.
하지만 헤더의 숫자 하나가 에러로 깨지면 뒤따라오는 모든 통신이 연쇄 붕괴되는 치명적인 '동기화 상실' 버그가 있어 현대에는 쓰이지 않습니다.

Ⅰ. 바이트 카운트 방식의 동작 원리

가장 심플한 아이디어에서 출발했습니다. 수신기가 어디서 데이터를 잘라야 할지 고민하게 놔두지 말고, 아예 편지봉투 겉면에 내용물의 무게(길이)를 적어주자는 것입니다.

[정상적인 전송 시나리오]

• 송신: [5] [A] [B] [C] [D] | [4] [X] [Y] [Z] | [6] [1] [2] [3] [4] [5]
  • 첫 번째 프레임: 맨 앞의 숫자 5를 보고 "아, 나(1바이트)를 포함해서 총 5바이트를 읽으면 프레임 하나가 끝나는구나!"라고 해석하여 정확히 D까지 자릅니다.
  • 두 번째 프레임: 그다음 글자인 4를 읽고 "이번엔 4바이트네!" 하고 Z까지 예쁘게 자릅니다.

Ⅱ. 치명적 단점: 도미노 붕괴 (동기화 상실)

아이디어는 좋았으나, 물리적인 네트워크의 노이즈(번개, 잡음)를 너무 얕본 것이 화근이었습니다.

[에러 발생 시나리오]

• 원본 전송: [5] A B C D | [4] X Y Z | [6] 1 2 3 4 5
• 도중에 번개가 쳐서 첫 번째 프레임의 길이값 5가 에러가 나서 7로 바뀌어 수신기에 도착했습니다.
• 수신기의 오작동: [7] A B C D 4 X
  • 수신기는 맨 앞의 7을 맹신하고 7바이트를 덜컥 읽어버립니다. 즉, 두 번째 프레임의 앞부분(4, X)까지 첫 번째 프레임의 데이터인 줄 알고 잘못 삼켜버립니다.
• 연쇄 폭발: 이제 첫 번째 프레임을 다 읽었으니 다음 글자를 새로운 프레임의 '길이'로 인식해야 합니다. 남은 글자는 [Y]입니다. 수신기는 엉뚱한 문자 Y(아스키코드 값)를 '길이'로 해석해 버리고, 어마어마한 바이트를 한 번에 꿀꺽하려다가 버퍼가 터지거나 완전히 쓰레기 데이터로 해석해 버립니다.

Ⅲ. 시사점과 진화

바이트 카운트 방식은 **"단 한 번의 오류가 뒤따라오는 모든 프레임의 경계선(동기화)을 영구적으로 박살 내버린다"**는 끔찍한 교훈을 인류에게 안겨주었습니다. 수신기가 스스로 에러를 복구하고 프레임 경계를 다시 찾을(Resynchronization) 방법이 전혀 없기 때문입니다.

이 실패를 딛고, 길이에 의존하지 않고 "프레임이 시작될 때는 반드시 01111110 이라는 특수한 깃발(Flag)을 무조건 흔들자!"라는 문자/비트 스터핑 방식으로 기술이 진화하게 되었습니다.

📢 섹션 요약 비유: 바이트 카운트는 김밥을 썰 때 **"이번엔 5cm, 다음엔 4cm 썰어!"라고 적힌 '레시피 메모장'**만 믿고 기계가 눈을 감은 채 써는 것입니다. 만약 잉크가 번져서 5cm가 7cm로 보이면, 첫 김밥을 7cm로 썰어버리고, 그다음부터는 김밥의 속 재료 단면을 칼로 난도질하며 줄줄이 모든 김밥을 터뜨려버리는 처참한 연쇄 사고가 발생합니다.