JPEG-over-WebSocket에서 탈출: 로봇 영상을 WebRTC SFU로 1초 지연까지 줄인 설계

2023년 10월 12일 · ◷ 3분

기존 관제 시스템의 영상 경로는 JPEG 캡처 이미지를 WebSocket으로 전달하는 방식이었다. 영상 확인 자체는 가능했지만 지연이 커서 원격 제어와 장애 대응에는 활용하기 어려웠다.

이 글은 로봇 단 송출, 미디어 서버, 웹 수신 경로를 분리해 저지연 스트리밍을 만든 과정을 정리한다.

문제 정의

실시간 영상은 단순 모니터링이 아니라 원격 제어와 안전 대응의 핵심 입력이다. 하지만 기존 방식은 프레임 캡처/인코딩/전송 오버헤드가 커서 지연이 수 초 단위로 발생했다.

운영에서 필요한 수준은 아래와 같았다.

프로토콜 선택 전에 구간별 지연 예산을 먼저 잡았다.

총합을 1초 이내로 맞추는 것이 목표였다. 이 예산을 두고 나니 각 구간의 최적화 우선순위가 명확해졌다.

웹 클라이언트 호환성을 기준으로 후보를 추리면 HLS/MPEG-DASH/QUIC/WebRTC가 남는다. 이 중 HLS/MPEG-DASH는 지연 특성상 제외했고, QUIC과 WebRTC를 비교했다.

당시(2023년) 기준으로는 QUIC 기반 상용 SaaS 선택지가 제한적이었고, WebRTC는 브라우저 호환성/보안/운영 레퍼런스가 충분했다.

결론적으로 클라이언트 수신 경로는 WebRTC로 결정했다.

WebRTC 중계 방식은 MCU와 SFU 중 SFU를 선택했다.

서비스 구조가 1:N 중심이었기 때문에 SFU가 더 적합했다.

로봇 USB 카메라는 JPEG 프레임을 반환하기 때문에, 실시간 스트리밍에는 RAW 변환 후 연속 프레임 코덱으로 재인코딩이 필요했다.

핵심 선택은 아래와 같다.

예시 파이프라인:

gst-launch-1.0 v4l2src device=/dev/video0 ! nvjpegdec ! nvv4l2h264enc ! h264parse ! srtclientsink uri=srt://127.0.0.1:9999

중요한 점은 로봇 송출 구간과 웹 수신 구간을 분리했다는 점이다. 로봇→서버 단방향 송출에서는 WebRTC를 강제하지 않고 SRT/RTP 계열을 사용해 시그널링/ICE 절차 부담을 줄였다.

필수 조건은 아래 다섯 가지였다.

후보는 Ant Media, Red5, Janus, Mediasoup였고, 운영 인력 제약을 고려해 관리 도구와 SaaS 가용성을 우선했다. 최종적으로 비용/운영성 균형에서 Ant Media Server를 선택했다.

AWS 환경에 Ant Media Server를 배포하고, EC2 Auto Scaling + 클러스터 구성을 통해 트래픽 증가 시 수평 확장하도록 설계했다.

즉, 로봇 송출 최적화와 서버 확장 전략을 하나의 운영 경로로 맞췄다.

실서비스에서는 관제 앱 원격 제어에 사용할 수 있는 지연 수준(약 1초 내외, 당시 운영 환경 기준)을 확보했다. 다만 네트워크 대역폭 제약으로 고화질 영상에는 한계가 있었고, 일부 ML 워크로드에는 추가 튜닝이 필요했다.

정리하면, 이 설계의 핵심은 “단일 프로토콜 고집"이 아니라 로봇 단 처리(GStreamer), 전송 구간(SRT), 웹 배포 구간(WebRTC SFU)을 분리한 데 있었다.

참고: WebRTC 표준은 브라우저 실시간 미디어 전송에서 지연/보안/연결 복구(ICE) 모델을 정의한다. WebRTC 1.0: Real-Time Communication Between Browsers

참고: GStreamer 문서는 실시간 미디어 파이프라인 구성과 코덱/플러그인 운용 기준을 제공한다. GStreamer Documentation

참고: SRT는 불안정 네트워크에서 지연/복구 균형을 맞추기 위해 설계된 전송 프로토콜이다. SRT (Secure Reliable Transport)