UDP가 빠르다고 맹신하는 당신, 그 선택이 장애콜을 부릅니다.

1. 배경: 웃을 수 없는 농담

"UDP 농담을 하나 해주려고 했는데, 당신이 못 받을 수도 있겠네요(might not get it)."

개발자들 사이에서 도는 아주 오래된 농담입니다. UDP(User Datagram Protocol)의 '비연결성'과 '신뢰성 없음'을 빗댄 말장난이죠. 다들 이 농담을 듣고 킥킥거리지만, 저는 웃지 못합니다. 10년 전, 검색 로그 수집 서버를 구축할 때 겪었던 악몽이 떠오르기 때문입니다.

당시 우리는 초당 수만 건의 트래픽을 처리해야 한다는 압박감에 시달렸습니다. "TCP의 3-way Handshake 오버헤드도 아깝다"는 팀장의 말 한마디에 로그 수집기를 UDP로 구현했습니다. 결과는 어땠을까요. 네트워크 스위치에서 잠깐의 병목이 발생했을 때, 수백만 건의 과금 관련 로그가 공중분해 되었습니다. 그날 밤새도록 유실된 데이터를 복구하느라 DB 트랜잭션 로그를 뒤지며 뼈저리게 느꼈습니다.

코드는 자산이 아니라 부채입니다. 그리고 검증되지 않은 '속도'는 이자가 가장 비싼 악성 부채입니다.

2. 현황 및 문제점: 주니어 개발자의 '속도 지상주의'

최근 코드 리뷰를 하다 보면 걱정스러운 패턴이 보입니다.

이력서 주도 개발(RDD)의 폐해: 단순히 "UDP를 사용한 실시간 통신 구현"이라는 한 줄을 이력서에 넣기 위해, 데이터 정합성이 중요한 로직에까지 UDP를 무리하게 도입합니다.
어플리케이션 레벨의 복잡도 증가: UDP는 패킷 전송을 보장하지 않습니다. 이를 보완하겠답시고 어플리케이션 단에서 재전송 로직, 순서 보장 로직(Sequencing)을 직접 짭니다. 결국 TCP가 커널 단에서 해주는 일을 엉성하게 유저 레벨에서 구현하다 버그만 양산합니다.
비즈니스 맥락 부재: 동영상 스트리밍이나 게임 캐릭터의 위치 정보처럼 몇 프레임 날아가도 되는 데이터와, 결제/로그/주문처럼 단 1비트도 날아가면 안 되는 데이터의 경계를 구분하지 못합니다.

3. 분석: TCP vs UDP 트레이드오프

냉정하게 비교해 봅시다. 우리가 얻는 것과 잃는 것은 명확합니다.

4. 해결방안 및 제언

무조건 TCP만 쓰라는 말이 아닙니다. 기술에는 선악이 없습니다. 적합성만 있을 뿐입니다.

기본값은 무조건 TCP입니다.
특별한 이유가 없다면 TCP를 쓰십시오. HTTP/1.1, HTTP/2 모두 TCP 위에서 돕니다. 전 세계 수많은 엔지니어가 수십 년간 최적화해 둔 안정성을 굳이 걷어찰 이유가 없습니다. 병목은 네트워크 프로토콜보다는 당신이 짠 비효율적인 쿼리나 루프 문에서 발생할 확률이 99%입니다.
UDP는 '잃어버려도 되는' 데이터에만 쓰십시오.
VoIP(음성 통화), 실시간 스트리밍, FPS 게임의 좌표 동기화 등이 여기에 해당합니다. 잠깐 화면이 깨지거나 목소리가 끊겨도 서비스 전체가 셧다운 되지는 않으니까요. 하지만 로그 수집, 결제 신호, 채팅 메시지 전송에 UDP를 쓰겠다고 한다면 저는 그 PR(Pull Request)을 절대 승인하지 않을 겁니다.
HTTP/3(QUIC)에 대한 오해를 버리십시오.
"구글이 만든 QUIC이 UDP 기반이니까 UDP가 미래다"라고 주장하는 분들이 있습니다. QUIC은 UDP 위에서 TCP의 신뢰성 기능을 재구현하고 최적화한 프로토콜이지, 쌩(Raw) UDP를 막 써도 된다는 뜻이 아닙니다. 구글 엔지니어 수준으로 네트워크 혼잡 제어를 직접 구현할 자신이 없다면, 검증된 라이브러리와 프로토콜을 사용하십시오.

5. 결론: 방어적 코딩이 당신의 칼퇴를 지킵니다

"UDP 농담을 던졌는데 못 받았다"는 건 웃어넘길 수 있습니다. 하지만 "고객의 주문 데이터를 던졌는데 서버가 못 받았다"는 건 웃을 수 없는 현실입니다.

개발자의 실력은 얼마나 빠른 코드를 짜느냐가 아니라, 얼마나 안정적인 시스템을 설계하느냐에서 드러납니다. 화려한 기술 스택보다는 보수적인 선택이 때로는 가장 혁신적인 결과를 만듭니다. 오늘 당신이 작성한 코드가 누군가의 금전적 손실로 이어지지 않도록, 한 번 더 의심하고 검증하십시오. 시스템은 당신의 낙관보다 훨씬 자주, 그리고 비열하게 실패합니다.