2026. 3. 15. 21:43ㆍ잡다한 궁금증
안녕하세요!
최근 전공 과제로 '2차원 패리티 비트를 활용한 오류 검출 알고리즘'을 빡빡하게 설계하면서
골머리를 앓았던 이슈가 하나 있었는데요.
오류를 복구하는 방식에 대한 제 고정관념이 산산조각 난 경험이었습니다.
과제를 해결하기 위한 알고리즘을 설계하다 보니,
"에러가 나면 수신자가 복잡한 수학 연산을 돌려서 직접 오류 위치를 찾아 복구해야 한다"
라는 결론에 도달하게 되었습니다.
생각해 보니, 저는 인터넷 통신에서 데이터가 깨지면 무조건 송신자한테
"야, 통신 불량이다! 다시 보내!" 라고 요청하는 아주 정직한 방식만 고수한다고 굳게 믿고 있었더라고요.
"어차피 다시 보내달라고 하면 되는데, 왜 수신자가 오버헤드를 감수하면서까지 빡빡하게 연산을 돌려 스스로 고쳐야 하는 거지?"
과제를 마친 후 이 찝찝함을 참지 못하고 파헤쳐 본 가벼운 리서치 결과, 제 오해를 바로 잡아준 통신 최적화 기법,
FEC(전진 오류 수정)와 현대 네트워크 프로토콜(TCP/UDP)의 차이에 대해 제 개인 개발일지에 공유해 봅니다.
1. 빡빡하게 수학으로 묶어서 스스로 고치는 방식, FEC
제가 과제로 설계했던 것처럼 패리티를 이중 삼중으로 덧대어 검사하는 방식의 목표는 단 하나입니다.
데이터가 망가졌을 때 송신자에게 다시 보내달라고 징징대지 않는 것이죠.
송신자가 데이터를 보낼 때 가로, 세로, 심지어 대각선까지 빡빡하게 패리티(검사 힌트)를 잔뜩 붙여서 보냅니다.
그러면 수신자는 에러가 났을 때 연립방정식 풀듯이 교차점을 찾아내서 스스로 데이터를 원상복구해 버립니다.
이런 훌륭하고 독립적인 방식을 통신 공학에서는 FEC(Forward Error Correction)라고 부릅니다.
하지만 이 방식은 치명적인 비효율성을 안고 있습니다. 진짜 데이터를 지키겠다고 검사식을 잔뜩 붙이다 보니,
전체 전송량이 너무 무거워져서 결국 '검사용 패리티 비트' 자체가 통신 중 깨져버리는 역효과가 나기 쉽다는 겁니다.
2. 현대 네트워크는 어떻게 에러를 대할까? TCP vs UDP
그렇다면 우리가 평소에 쓰는 인터넷 통신은 어떨까요?
리서치를 통해 알아낸 현대 네트워크의 오류 처리 방식은 크게 두 가지로 나뉩니다.
(1) TCP - 꼼꼼한 A/S 고객
무거운 패리티 연산 대신, 데이터가 멀쩡한지만 확인하는 아주 가벼운 꼬리표만 붙여 보냅니다.
에러가 나면 쿨하게 버리고 송신자에게 "다시 보내!"라고 재전송을 요청하죠.
파일 다운로드처럼 데이터의 무결성이 중요한 상황에서 쓰는 정직한 방식입니다.
(2) UDP - 일단 던지는 쿨가이
속도가 생명입니다.
에러가 나면? 복구고 뭐고 그냥 쓰레기통에 버립니다.
재전송 요청도 안 합니다. 그냥 뒤따라오는 최신 데이터를 1밀리초라도 빨리 화면에 띄우는 데 집중하죠.
실제 통신망에서는 저처럼 무겁게 16비트 검사식을 돌리는 대신, 상황에 맞춰 철저하게 분업화를 하고 있었습니다.
3. 리서치 과정에서 얻은 소소한 깨달음
사실 오랫동안 통신의 지배자는 데이터 무결성을 보장하는 TCP였습니다.
하지만 롤 한타나 배틀그라운드 같은 실시간 게임 환경에서는 얘기가 다릅니다.
과거의 위치 데이터가 깨졌다고 꼼꼼하게 재전송을 기다리면 핑이 튀고 캐릭터가 멈춰버리니까요.
그래서 요즘은 무조건 빠른 UDP가 게임이나 실시간 스트리밍 분야의 대세로 떠오르고 있습니다.
근데 가만히 생각해 보면,
속도 때문에 일단 냅다 던지고 보는 UDP 환경이야말로 제가 과제로 설계했던 FEC 방식이 절실하게 필요한 곳이더라고요.
게임 서버에서 UDP로 최신 데이터를 미친 듯이 쏘면서 그 사이에 빡빡한 FEC 연산 힌트들을 섞어 보내면,
클라이언트는 재전송 딜레이 없이 즉각적으로 깨진 데이터를 자체 복구하며 화면을 부드럽게 이어갈 수 있으니까요.
'에러 나면 무조건 다시 받으면 된다'는 단편적인 고정관념에서 벗어나,
네트워크 환경(속도 vs 무결성)에 따라 에러를 다루는 통신 공학의 치열한 최적화 방식을 알게 된 아주 유익한 리서치였습니다.
긴 글 읽어주셔서 감사합니다!
'잡다한 궁금증' 카테고리의 다른 글
| [잡다한 궁금증] Python은 인터프리터 언어인데 컴파일을 한다고? (0) | 2026.03.11 |
|---|