💡 핵심 인사이트
데이터가 랜선을 타고 날아가다 보면 번개나 노이즈 때문에 멀쩡하던 0이 1로 깨지는 일이 밥 먹듯이 발생합니다.
이를 수신 측에서 알아채고 고쳐내기 위한 통신 시스템의 생존 본능이 **오류 제어(Error Control)**이며, 크게 "네가 직접 고쳐봐!"라는 순방향(FEC) 방식과 "모르겠으니까 다시 보내!"라는 역방향(ARQ) 방식으로 나뉩니다.

Ⅰ. 오류가 발생하는 이유 (노이즈)

송신 컴퓨터가 100만 원 송금을 위해 0000을 보냈습니다. 하지만 구리선이나 공기 중의 전파는 외부 환경에 극도로 취약합니다. 옆에서 전자레인지를 켜거나(백색 잡음), 벼락이 치거나(임펄스 잡음), 다른 선의 신호가 간섭을 일으키면(누화), 수신기에 도착한 신호는 0010으로 깨져서 도착할 수 있습니다. 100만 원이 200만 원으로 둔갑하는 참사가 벌어집니다.

이런 물리적인 에러를 2계층(데이터 링크)이나 4계층(전송)에서 어떻게든 발견하고 수습하는 것이 오류 제어입니다.

Ⅱ. 잉여 비트 (Redundancy Bit)의 마법

오류 제어의 가장 근본적인 철학은 **"원본 데이터만 덜렁 보내지 말고, 원본을 수학적으로 계산한 '힌트(잉여 비트)'를 뒤에 달아서 같이 보내자"**입니다.

• 송신 측: "내 원본 데이터의 1의 개수를 다 세어보니 짝수 개야!"라는 힌트(패리티 비트)를 꼬리에 달아 보냅니다.
• 수신 측: 데이터를 받고 나서 자신도 1의 개수를 세어봅니다. "어? 난 홀수 개가 나오는데? 아까 꼬리에 달린 힌트는 짝수라고 했으니 오는 길에 누군가 깨졌구나!"라고 오류 발생 사실을 즉시 깨닫게(검출, Detection) 됩니다.

Ⅲ. 오류를 고치는 두 가지 길 (FEC vs BEC/ARQ)

에러가 났다는 것을 알았다면, 시스템은 둘 중 하나의 결단을 내려야 합니다.

1. 전진 오류 수정 (FEC, Forward Error Correction) - 스스로 고친다

• 꼬리에 다는 힌트(잉여 비트)를 엄청나게 길고 복잡한 수학 공식(해밍 코드 등)으로 달아 보냅니다.
• 수신기는 에러를 발견하면 송신기에 "다시 보내"라고 말하지 않습니다. 힌트를 수학적으로 역산하여 **어디가 어떻게 깨졌는지 스스로 알아내고 그 자리에서 깨진 0을 1로 셀프 수리(Correction)**해 버립니다.
• 장점: 송신기와 다시 연락할 필요가 없어 재전송 지연이 없습니다. 우주 탐사선 통신이나 실시간 화상회의에 씁니다.
• 단점: 힌트 데이터가 너무 커서 대역폭 낭비가 극심합니다.

2. 후진 오류 수정 (BEC / ARQ) - 쿨하게 버리고 재요청한다

• 꼬리에 아주 짧은 힌트(CRC 등)만 달아 보냅니다.
• 수신기는 에러를 발견하면 어디가 깨졌는지 추리하지 않습니다. 쓰레기 데이터로 취급해 가차 없이 버려버리고, 송신 측에게 삐삐를 쳐서 "에러 났으니까 원본 다시 쏴줘(ARQ)!"라고 요청합니다.
• 장점: 평소에 보내는 힌트 데이터가 작아 인터넷이 엄청 빠릅니다. 인터넷 다운로드나 일반적인 통신 환경(TCP)의 99%가 이 방식을 씁니다.
• 단점: 핑퐁(재요청-재전송)을 해야 하므로 지연(Delay)이 발생합니다.

📢 섹션 요약 비유: 오류 제어는 택배 파손 처리법입니다. FEC(스스로 수정)는 택배 안에 강력 접착제와 설계도를 같이 넣어 보내서, 도착한 물건이 부서져 있으면 손님이 직접 본드로 붙여서(수리) 쓰는 방식입니다(오래 걸리고 택배가 무거움). ARQ(재요청)는 택배를 뜯어보고 부서졌으면 쿨하게 쓰레기통에 던진 뒤, 쇼핑몰에 전화해서 "새 물건으로 다시 보내!"라고 진상(?)을 부리는 가장 흔하고 효율적인 환불/교환 방식입니다.