‘Rivian and Volkswagen Technology Group’은 Amazon Kinesis Video Streams를 활용해 어떻게 실시간 차량 보안을 구축했을까?

이 글은 AWS for Industries 블로그에 게시된 글(How Rivian and Volkswagen Technology Group Built Real-Time Vehicle Security with Amazon Kinesis Video Streams)를 한국어로 번역 및 편집하였습니다. 영어 원문 블로그는, Rivian and Volkswagen Group Technologies에서 Anirban Kundu, Adam Arsenault, Aditya Purohit이, AWS에서는 Asif Khan, and Ajay Paknikar이 작성하였습니다.

이 블로그에서는 Rivian and Volkswagen Group Technologies(이하 Rivian)가 AWS와 협력하여 Rivian의 Gear Guard 기능을 고도화하고, 이를 통해 차량 보안을 어떻게 개선했는지 소개합니다. Rivian은 Amazon Kinesis Video Streams(KVS) 를 활용해 보다 정교한 실시간 비디오 스트리밍 솔루션을 구축했습니다. 그 결과, Rivian 차량 소유자는 Rivian 모바일 애플리케이션에서 차량 카메라의 라이브 영상(실시간 카메라 피드) 에 더 즉각적으로 접근할 수 있게 되었습니다.

소개

Rivian은 R1T 픽업트럭, R1S SUV, 전기 배송 밴(EDV, Electric Delivery Vans) 으로 잘 알려진 선도적인 전기차 제조사로, 자동차 솔루션을 지속적으로 혁신하고 있습니다. Rivian의 핵심 서비스 중 하나인 Gear Guard는 차량 소유자가 자리를 비운 동안 차량과 차량 내 물품을 보호할 수 있도록 설계된 포괄적인 기능 모음입니다. 초기 Gear Guard는 차량 탑재 카메라와 AI 알고리즘을 활용해 수상한 사람의 움직임을 감지하고, 영상을 녹화한 뒤 Rivian 모바일 앱을 통해 차량 소유자에게 알림을 보내는 방식이었습니다. 이때 생성된 영상과 녹화 데이터는 차량 내부에 로컬로 저장되었습니다. 이 중요한 보안 기능이 자연스럽게 다음 단계로 발전한 방향은, 차량에서 Rivian 모바일 앱으로 실시간 라이브 영상을 직접 스트리밍하는 기능을 도입하는 것이었습니다. 이를 통해 감지된 사건이 발생했을 때 차량 소유자는 즉시 영상으로 상황을 확인할 수 있게 되었습니다.

그림 1. Rivian Gear Guard 캐릭터

라이브 비디오 스트리밍을 위한 비즈니스 및 기술 요구사항

Gear Guard에 라이브 비디오 스트리밍을 구현하기 위해서는 핵심적인 기능, 성능, 보안 요구사항을 충족할 수 있는 더 견고한 솔루션이 필요했습니다. 이 시스템의 1차 목표는 차량 소유자가 인증된 모바일 기기를 통해 원격으로 Gear Guard 보안 카메라의 실시간 영상 스트림을 확인할 수 있도록 지원하는 것입니다. 차량 소유자는 필요할 때 온디맨드로 라이브 뷰를 시작할 수 있으며, 차량이 주차되어 있고 잠겨 있으며 무인 상태인 상황에서도 Gear Guard 경보 시스템의 알림(notification)에 대응해 라이브 영상을 확인할 수 있습니다.

새로운 라이브 비디오 스트리밍 서비스를 개발하면서, Rivian이 정리한 핵심 기능 요구사항에는 다음이 포함되었습니다.

• 차량 카메라(트럭 적재함 카메라 포함)에서 원격으로 라이브 영상을 확인할 수 있는 기능
• 특정 카메라를 선택하거나, 카메라 간 화면을 순환하며 보여주는 보기 모드를 선택할 수 있는 기능
• 경보(alarm) 또는 움직임(motion) 이벤트에 대응해 모바일 알림을 생성하고, 가장 관련성이 높은 카메라 스트림을 선택할 수 있는 버튼과 안내를 위한 썸네일(thumbnails)을 제공하는 기능
• 실시간 스트리밍과 동시에 이벤트를 차량 내부 저장소에 녹화하는 기능
• 다양한 셀룰러 및 Wi-Fi 네트워크 제공업체와 여러 종류의 모바일 기기를 지원하는 기능

Rivian이 빠르고 쾌적한 사용자 경험을 위해 중요하게 본 핵심 성능 지표는 다음과 같습니다.

• 활성화 시간(Activation time): 요청 후 스트림이 화면에 표시되기까지 5초 미만
• 스트림 지연(Stream latency): 카메라 촬영부터 모바일 화면 표시까지 1초 미만
• 카메라 전환 시간(Camera switching time): 카메라 선택 후 화면에 표시되기까지 1초 미만

Rivian이 정리한 핵심 개인정보(프라이버시) 및 보안 요구사항은 다음과 같습니다.
Rivian은 설계 전 과정에서 최종 사용자의 프라이버시를 최우선 과제로 두었습니다. 이를 위해 프라이버시 임계치 분석과 보안 위협 분석을 수행했습니다. 예를 들어, Gear Guard 애플리케이션은 공장 모드(factory mode)에서는 비활성화되도록 설계했습니다. 이는 서라운드 뷰 보정(calibration) 과정에 영향을 주거나, 원치 않는 영상 트리거가 발생하는 것을 방지하기 위한 조치입니다. 또한 Rivian은 이 기능이 스토킹 등 악용되는 것을 막기 위해 세션 단위 및 일 단위 사용량 제한을 적용했습니다.

Amazon Kinesis Video Streams를 선택한 이유

여러 대안을 검토한 끝에 Rivian은 Amazon Kinesis Video Streams를 비디오 스트리밍 서비스로 선택했습니다.Amazon Kinesis Video Streams가 Rivian이 요구한 기능 요건, 성능/확장성 요건, 보안/프라이버시 요건을 모두 충족했기 때문입니다. 의사결정 과정에서 특히 중요하게 고려된 Kinesis Video Streams의 주요 특징은 다음과 같습니다.

• 다양한 스트리밍과 메시징 프로토콜 지원: WebRTC(Web Real-Time Communication), RTSP(Real-Time Streaming Protocol), SCTP(Stream Control Transmission Protocol) 등 다수 프로토콜 지원
• 강력한 시그널링(Signaling) 인프라: 완전관리형 시그널링, STUN 및 TURN 서버 제공, 오토스케일링 지원, 통신을 위한 채널의 동적 생성 지원
• 포괄적인 옵저버빌리티(Observability): 서버 상태 및 가동률(uptime) 실시간 모니터링, 비용 모니터링, Amazon CloudWatch와 메트릭/알림 연동, 성능 추적을 위한 커스텀 대시보드 구성 가능
• 보안: AWS 보안 서비스 및 Rivian의 보안 모델과 잘 맞물리는 네이티브 서비스들과의 내장 통합 제공
• 확장성: 오픈 표준 API 지원(예: SigV4 서명 URL을 활용해 유효한 서명이 포함된 임시 URL 생성), Rivian의 IoT 및 모바일 기기에서 벤더 종속성을 줄인 기능 구현 가능. 또한 다양한 언어의 알고리즘, 클라이언트 구현, 레퍼런스 SDK 제공
• 성능: 네이티브 WebRTC 기반으로 1초 미만 지연(sub-second latency) 스트리밍을 지원하며, 수백만 동시 스트림까지 확장 가능한 오토스케일링과 최적 성능을 위한 리전 별 배포 지원
• 심층 기술 협업: Amazon Kinesis Video Streams 서비스 팀과의 긴밀한 파트너십을 통해 SDK 통합과 SigV4 디버깅 기능을 성공적으로 구현했고, 개발을 가속화하는 동시에 복잡한 구현 과제 해결

시스템 아키텍처

Gear Guard 라이브 카메라 아키텍처는 WebRTC를 중심으로 설계되었습니다. WebRTC는 지연 시간이 더 낮고, 양방향 오디오/비디오를 지원하기 때문에, 향후 클라이언트(모바일 앱)에서 차량으로 음성 상호작용 기능을 확장할 수 있는 기반을 제공합니다.

그림 2. Gear Guard 기술 아키텍처

스트리밍 시작 시퀀스(Start Streaming Sequence)

주요 구현 하이라이트

모바일–차량 간 지표와 이벤트 교환을 위한 데이터 채널 활용

WebRTC 데이터 채널은 모바일 애플리케이션과 차량 간에 보다 견고하고 양방향으로 정보를 주고받기 위해 활용되었습니다. 여기에는 모바일 앱에서 차량으로 전송되는 원격 명령(예: 카메라 전환 요청)이 포함되며, 사용자가 다른 카메라 뷰를 선택할 수 있도록 해줍니다. 반대로, 차량에서는 모바일 애플리케이션으로 세션 종료(tear down) 요청을 전송해 스트리밍 세션이 종료되었음을 알렸습니다. 또한 데이터 채널은 스트리밍 시작까지 소요된 시간과 같은 핵심 메트릭을 전달하는 데에도 활용되어, 성능 모니터링과 최적화를 가능하게 했습니다. 보다 효율적이고 구조화된 통신을 보장하기 위해, 이 채널을 통해 전송되는 모든 데이터는 Protocol Buffers(protobuf) 형식으로 포맷팅했습니다.

시그널링 서버 자격 증명을 위한 차량 인증서 기반 인증 및 전달

Go 언어 기반의 클라우드 서비스가 차량과 모바일 애플리케이션을 인증하고, SDP offer 협상 및 ICE hop 구성을 위해 필요한 SigV4 서명 URL(v4 signed URL) 과 임시 자격 증명, 그리고 TURN/STUN 연결 정보를 제공합니다. 요청 순서는 중요하지 않지만, SDP offer는 5분 이내에 시작되어야 합니다. 차량은 차량의 아이덴티티가 포함된 인증서로 mTLS를 사용하여 서비스에 인증됩니다. 모바일 애플리케이션 요청은 OAuth2 JWT로 인증하고, 요청한 사용자가 해당 차량에 대해 프로비저닝(권한 부여/등록) 되어 있는지 검증합니다.

이 서비스는 멀티 리전 Amazon DynamoDB 테이블을 사용해 차량의 시그널링 채널 존재 여부를 확인한 다음, 차량에 대해 새 Kinesis Video Streams WebRTC 시그널링 채널을 생성하거나 기존 채널을 재사용합니다. DynamoDB 레코드에는 30일 만료가 설정되며, 이 값은 요청이 발생할 때마다 갱신됩니다.

DynamoDB 레코드의 만료 이벤트는 AWS Lambda 함수를 트리거하여, 30일 동안 사용되지 않은 시그널링 채널을 종료(tear down) 하도록 합니다. 이를 통해 Gear Guard 서비스의 활성 사용자 추적이 가능해지고, 프로비저닝된 리소스 비용을 줄이는 데도 도움이 됩니다. SDP offer 전송에는 WSS 엔드포인트가 사용됩니다. SigV4 URL에는 ChannelARN, ClientId, Expiration, Security Token 등의 정보가 포함됩니다. 서비스는 또한 STUN/TURN 서버(UDP, 보안 UDP 및 TCP) 및 해당 접속에 필요한 자격 증명도 함께 제공합니다.

그림 3. Gear Guard 라이브 카메라 피드

AWS 리전 기반 시그널링 서버 및 TURN 서버 할당

P2P 연결이 TURN 서버를 사용하게 되는 경우, 차량이 위치한 동일한 AWS 리전에서 시그널링 서버와 TURN 서버를 할당하고자 했습니다. 이는 예를 들어 차량과 모바일 앱이 모두 미국 서부(US West Coast) 에 있는데도, 시그널링 채널이 미국 동부(US East Coast) 에 프로비저닝되는 상황을 피하기 위한 것입니다. 아래는 가능한 조합입니다.

그림 4. Gear Guard 리전별 배포

구현을 최적화하기 위해, us-east-1과 us-west-2 리전에 모두 배포된 Amazon Elastic Kubernetes Service(Amazon EKS) 기반의 클라우드 서비스는 커스텀 지리적 위치 기반 서비스(geolocation)를 사용합니다. 이 지리적 위치 기반 서비스는 차량이 캔자스주 리바논(Lebanon, Kansas; 39°50′N 98°35′W) 을 기준으로 동쪽에 있는지 서쪽에 있는지를 식별하는 데 도움을 줍니다. AWS와 Rivian은 이 지점을 미국의 중간 지점으로 간주했으며(그림 4의 점선으로 표시), 서비스는 이를 기준으로 차량이 위치한 리전과 동일한 애플리케이션 공존(co-located) 리전에서 Amazon Kinesis Video Streams 시그널링 채널을 프로비저닝하도록 합니다. 위 예시(그림 4)에서는 모바일이 동부 해안에 있든 서부 해안에 있든 관계없이 car-01은 us-west-2에 시그널링 채널이 설정됩니다. 마찬가지로 car-02는 us-east-1 리전에 설정됩니다.

프로덕션 운영에서 얻은 교훈(1년 회고)

프로덕션에 적용한 지 1년이 지난 시점에서, 다음과 같은 핵심 인사이트가 도출되었습니다.

• 지연 시간: WebRTC 선택은 저지연 스트리밍을 달성하는 데 효과적이었으며, 이는 HLS(Http Live Streaming) 같은 다른 스트리밍 프로토콜 대비 큰 장점이었습니다.
• 다중 시청자를 위한 확장성: WebRTC의 피어 투 피어 특성상, 각 클라이언트는 고유한 암호화 키를 가진 별도의 SRTP/SRTCP 스트림이 필요합니다. 따라서 동일 차량에서 두 번째 클라이언트가 스트림을 요청하면 새 스트림을 다시 시작해야 하며, 하나의 차량 스트림을 여러 피어에게 직접 공유하는 데 제약이 생깁니다. 현재 설계는 라이브 뷰를 위한 1개의 P2P 연결에 최적화되어 있으며, 시그널링 채널당 최대 10명 참가자를 지원합니다.
• 비용 관리: 커넥션 서비스를 통해, 사용자 요청에 따라 시그널링 채널을 최적화된 방식으로 프로비저닝 및 종료 합니다. 이를 통해 기능을 사용하지 않는 사용자에게는 시그널링 채널이 미리 프로비저닝되지 않도록 하여 비용을 절감합니다.
• 과제와 해결 방안:
  • 네트워크 인터페이스 바인딩: AWS SDK for C++는 소켓 연결에서 특정 네트워크 인터페이스에 바인딩하는 기능을 지원하지 않았습니다. 하지만 Rivian의 스트리밍 APN은 기본 네트워크 인터페이스와 다르기 때문에, 이 기능이 필수였습니다. 다행히 SDK가 오픈소스였고, Rivian은 네트워크 바인딩을 위한 패치를 만들어 스트리밍 인터페이스에 바인딩할 수 있었습니다.
  • 차량 웨이크업 시간: 슬립(sleep) 상태의 차량이 모바일 명령에 응답하고 스트리밍을 시작하기까지 걸리는 시간을 최적화하는 것이, 중요한 성능 고려사항이었습니다.

개선 사항 및 향후 계획

Rivian은 Gear Guard 라이브 캠 기능을 지속적으로 발전시키고 있으며, 다음과 같은 개선을 계획하고 있습니다.
연결의 여러 단계가 사용자에게 더 잘 보이도록 가시성을 높이고, 스트리밍 중에는 차량의 네트워크 상태도 사용자가 확인할 수 있도록 하는 차세대 사용자 인터페이스 업데이트를 포함합니다.
적응형 비트레이트(adaptive bitrate)와 ICE 재시작 같은 최적화를 통해 세션을 더 견고하게 만들고, 이 기능에서 가장 중요한 KPI인 세션 성공률(session success rates)을 개선할 계획입니다. Amazon Kinesis Video Streams WebRTC SDK는 미디어 채널에서 TWCC(Transport Wide Congestion Control)를 지원하므로 적응형 비트레이트 구현에 활용할 수 있습니다. 또한 SDK는 restartIce()도 지원하며, 연결 끊김(connectivity drops)이나 네트워크 전환(network switches) 상황에서 재연결을 위해 이를 사용할 예정입니다.

결론

Rivian이 Amazon Kinesis Video Streams를 활용해 구현한 Gear Guard 라이브 카메라는 영상 녹화본은 Rivian 인프라나 AWS 클라우드에 저장되지 않도록 하여 차량 보안을 한층 강화하면서도, 차량 소유자의 프라이버시를 최우선으로 고려한 보다 정교한 솔루션을 보여줍니다.
Rivian은 낮은 지연 시간과 양방향 커뮤니케이션 역량을 제공하는 WebRTC를 전략적으로 활용했으며, Amazon Kinesis Video Streams와의 매끄러운 통합을 통해 더 견고한 시그널링과 안전한 자격 증명 관리를 구현했습니다. 그 결과, 강력한 실시간 비디오 스트리밍 경험을 제공할 수 있었습니다.