WebRTC 성능 최적화: Pion SCTP에 도입된 RACK이 가져온 70%의 변화

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

최근 Go 언어 기반의 WebRTC 구현체인 Pion의 업데이트 노트를 보다가, 제 눈을 의심하게 만드는 수치를 발견했습니다. "70% faster, 30% less latency." 보통 성능 최적화라고 하면 10~20% 내외의 개선만 있어도 대단하다고 박수를 치는데, 이건 차원이 다른 숫자였거든요. 인프라 비용과 사용자 경험 사이에서 늘 줄타기를 하는 제 입장에서는 도저히 그냥 지나칠 수 없는 내용이었습니다. 오늘은 이 성능 향상의 핵심인 Pion SCTP와 RACK 알고리즘에 대해, 그리고 이것이 우리 서비스에 어떤 의미를 갖는지 이야기해볼까 합니다.

솔직히 고백하자면, 저도 주니어 시절에는 WebRTC라고 하면 그저 영상이나 음성을 주고받는 기술 정도로만 생각했습니다. 하지만 실무에서 채팅 기능이나 파일 공유, 혹은 게임의 상태 동기화를 구현하다 보면 결국 '데이터 채널'이라는 녀석과 씨름하게 됩니다. 이때 밑단에서 묵묵히 데이터를 나르는 프로토콜이 바로 SCTP(Stream Control Transmission Protocol)입니다.

SCTP는 꽤 매력적인 친구입니다. TCP처럼 신뢰성 있게 데이터를 보내면서도, 패킷의 순서가 뒤죽박죽이거나 일부가 유실되어도 전체 통신이 멈추지 않게 도와주죠. 예를 들어, 우리가 메신저로 텍스트를 주고받는 중에 고화질 사진을 업로드한다고 상상해 보세요. SCTP 덕분에 사진 업로드 때문에 텍스트 전송이 막히는 일 없이, 멀티플렉싱을 통해 동시에 여러 작업을 처리할 수 있습니다. 원격 수술이나 클라우드 게이밍처럼 0.1초의 지연도 허용되지 않는 환경에서는 이 프로토콜의 역할이 절대적입니다.

하지만 현업에서 네트워크를 다루다 보면, 이론대로 돌아가는 법이 없습니다. "패킷은 반드시 유실된다"는 것이 네트워크 엔지니어링의 슬픈 진리죠. 커피 머신이 고장 나는 것만큼이나 확실하게, 네트워크는 흔들리고 패킷은 사라집니다.

기존의 SCTP가 패킷 유실을 처리하는 방식은 조금 답답한 구석이 있었습니다. 크게 두 가지 전략을 쓰는데, 하나는 '빠른 재전송(Fast Retransmission)'이고 다른 하나는 '타이머 기반 재전송'입니다. 수신 측에서 "어? 3번 데이터가 없는데요?"라고 세 번이나 반복해서 리포트를 보내야 비로소 송신 측이 "아, 3번이 없어졌구나" 하고 다시 보냅니다. 혹은 타이머가 만료될 때까지 기다렸다가 다시 보내기도 하죠.

문제는 이 과정에서 필연적으로 레이턴시, 즉 지연이 발생한다는 점입니다. 실시간성이 생명인 서비스에서 재전송을 위해 기다리는 시간은 사용자에게 "렉 걸렸다"는 불쾌한 경험을 선사합니다. 저 역시 과거에 실시간 화이트보드 동기화 기능을 개발할 때, 네트워크 상태가 조금만 안 좋아져도 드로잉이 툭툭 끊기는 문제 때문에 며칠 밤을 새운 기억이 뼈저리게 남아있습니다.

그런데 이번에 Pion 팀이 SCTP 구현체에 RACK(Recent Acknowledgment)이라는 개념을 도입했습니다. RACK은 단순히 중복된 리포트 횟수를 세는 방식 대신, 패킷이 전송된 시간을 기반으로 유실 여부를 더 똑똑하게 판단합니다. 결과는 놀라웠습니다.

벤치마크 결과를 보면, RACK을 적용한 후 SCTP는 CPU 사용량을 오히려 줄이면서도 전송 속도를 234 Mbps에서 316 Mbps로 끌어올렸습니다. CPU 사용량 대비 처리량으로 환산하면 약 71%의 성능 향상입니다. 레이턴시 또한 27%나 감소했습니다. 쉽게 말해, 서버 리소스는 덜 쓰면서 데이터는 훨씬 더 빠르고 부드럽게 보낼 수 있게 된 것입니다.

이 변화가 우리에게 시사하는 바는 큽니다. 단순히 "기술이 좋아졌네"에서 끝날 일이 아닙니다. 클라우드 비용 절감은 물론이고, 그동안 네트워크 제약 때문에 망설였던 고용량 데이터 실시간 동기화나 고사양 클라우드 게이밍 같은 기능을 더 공격적으로 도입할 수 있는 근거가 되기 때문입니다. 특히 풀링포레스트처럼 대규모 트래픽을 처리해야 하는 환경에서는 CPU 효율 70% 개선이 곧 막대한 인프라 비용 절감으로 이어집니다.

개발자로 일하다 보면 익숙한 도구나 프로토콜을 당연하게 여기고 넘어갈 때가 많습니다. 하지만 이번 Pion의 RACK 도입 사례처럼, 로우 레벨 프로토콜의 개선이 애플리케이션 전체의 퍼포먼스를 뒤바꾸기도 합니다.

지금 여러분이 사용하고 있는 라이브러리나 프로토콜의 릴리즈 노트를 한번 꼼꼼히 살펴보시는 건 어떨까요? 어쩌면 그 속에 여러분이 오랫동안 고민하던 성능 문제의 열쇠가 숨어 있을지도 모릅니다. 기술은 계속 진화하고, 우리는 그 흐름을 놓치지 말아야 하니까요. 오늘도 안정적인 서비스를 위해 고군분투하는 모든 개발자분들을 응원합니다.