실무

경찰청 자율주행 순찰차 V2X 데이터 연동

Data Engineer, Senior Backend Engineer · 2025 · 6개월 · 4명 · 4 min read 읽기

경찰청 자율주행 순찰차 프로토타입을 위한 V2X 데이터 통신 미들웨어를 구축하여 차량-인프라 간 실시간 데이터 교환 기반 마련

Overview

경찰청 의뢰로 개발된 자율주행 순찰차 프로토타입의 데이터 통신 레이어를 구축했습니다. 통신/보안모듈 담당 기업(M사)과 협업하여, M사가 소켓을 통해 전달하는 ASN.1 표준 규격의 원본 V2X 데이터를 파싱·검증하고, 이를 내부 파이프라인에 태워 차량 탑재 센서와 도로변 인프라 유닛 간 실시간 데이터 교환 기반을 마련했습니다.

System Architecture

구성도 업데이트 예정입니다.

Constraints

  • 정부 프로젝트 보안 및 규정 준수 요건
  • V2X 메시지 실시간 지연시간 100ms 이내
  • 기존 차량 ECU 인터페이스와 연동 필수
  • 외부 보안모듈 벤더(M사)와의 협업 필요
  • 프로토타입 시연을 위한 6개월 납기

Tech Stack

  • Java 17 / Spring Boot
  • TCP Socket Server (M사 클라이언트 연동)
  • ASN.1 (SAE J2735 기반 V2X 표준 규격)
  • Apache Kafka
  • Protocol Buffers
  • Redis
  • Docker
  • Linux (Ubuntu)

Learnings

  • 정부 프로젝트는 초기에 규정 준수 요건을 명확히 해야 함 — 프로젝트 중반에 발견하면 비용이 큰 재작업이 발생
  • 하드웨어 인터페이스 제약(ECU 프로토콜)은 반드시 초기에 프로토타입으로 검증해야 함
  • 외부 벤더와 소켓으로 직접 연동할 때는 어느 쪽이 서버/클라이언트 역할을 맡을지를 상대 시스템의 보안 정책까지 고려해 결정해야 함 — 원본 데이터를 보유한 쪽이 클라이언트로 능동적으로 push하는 구조가 보안 제약이 있는 상대 시스템과의 연동에서는 더 자연스러웠음
  • 이종 시스템 간 바이트 스트림을 주고받을 때는 바이트 오더(Endianness) 불일치를 초기에 반드시 검증해야 함 — 정수 필드 값이 이상하게 나오는 문제는 파싱 로직 자체보다 바이트 오더 문제일 가능성을 먼저 의심해야 함
  • Kafka 재생 기능은 현장 테스트 중 간헐적 V2X 전송 문제를 디버깅하는 데 매우 유용했음
  • 교차 벤더 협업에는 명시적인 인터페이스 계약이 필요 — ASN.1 규격 자체가 외부 벤더와의 계약이었고, 내부적으로는 Protocol Buffers 스키마가 팀 간 살아있는 계약 역할을 했음

Problem

자율주행 순찰차 프로토타입은 차량과 도로 인프라 간 신뢰성 높은 저지연 데이터 채널을 필요로 했습니다. M사로부터 전달되는 V2X 데이터는 ASN.1 표준 규격(Header/Data Segment/Trailer로 구성된 비트 플래그 기반 구조)으로 인코딩돼 있어, 이를 정확히 파싱할 C 구조체 기반 스키마를 자체적으로 구현해야 했습니다. 또한 정부 보안 요건을 충족하면서 실시간으로 검증·파싱·라우팅해야 했습니다.

Approach

(1) 수신 레이어. 데이터 플랫폼(Java/Spring Boot)이 소켓 서버 역할로 특정 포트를 열어두고, M사(통신/보안모듈)가 클라이언트로 접속해 ASN.1 인코딩된 원본 V2X 데이터를 push하는 구조로 설계했습니다. 이는 통신/보안모듈이 외부 인바운드 연결을 최소화하는 보안 정책을 따르고, 원본 데이터를 보유한 쪽이 능동적으로 전송하는 흐름이 자연스러웠기 때문입니다. (2) 파싱 레이어. ASN.1 규격의 Header/Data Segment/Trailer 구조에 맞춘 C 구조체 기반 스키마를 정의하고, 이를 기준으로 원본 바이트 스트림을 파싱했습니다. 이 과정에서 M사 시스템과 우리 시스템 간 바이트 오더(Endianness) 불일치로 타임스탬프·좌표값 등 정수 필드가 역순으로 파싱되는 문제를 발견해, ByteBuffer의 바이트 오더를 명시적으로 지정하는 방식으로 해결했습니다. (3) 내부 파이프라인 연동. 파싱이 끝난 데이터를 Protocol Buffers로 재직렬화해 Kafka 기반 내부 파이프라인에 태우고, 스키마 검증·실시간 라우팅을 처리하는 미들웨어 레이어를 구성했습니다. 현장 테스트 중에는 V2X 데이터 흐름을 시각화하고 전송 이상을 감지하는 모니터링 대시보드를 구현했습니다.

Key Decisions

데이터 플랫폼을 소켓 서버로, M사(통신/보안모듈)를 클라이언트로 설계

Reasoning:

통신/보안모듈은 보안 정책상 외부에서의 인바운드 연결을 최소화해야 하는 제약이 있어, 자체적으로 리스닝 포트를 여는 대신 우리 쪽으로 능동적으로 접속해 데이터를 push하는 구조가 적합했습니다. 데이터 플랫폼이 특정 포트를 열어두고 대기하는 서버 역할을 맡아, 원본 데이터를 보유한 M사가 준비되는 대로 전송할 수 있도록 했습니다.

Alternatives considered:
  • 데이터 플랫폼이 클라이언트로 M사 서버에 주기적으로 폴링(polling)
  • 메시지 큐를 중간에 두고 양쪽 모두 비동기로 연동

ASN.1 원본 데이터를 C 구조체 기반 스키마로 직접 파싱

Reasoning:

M사로부터 전달되는 V2X 데이터가 ASN.1 표준(Header/Data Segment/Trailer, 비트 플래그 기반)으로 인코딩돼 있어, 이 구조를 그대로 반영한 C 구조체 스키마를 자체 구현해 바이트 단위로 정확히 매핑했습니다. 이 과정에서 바이트 오더(Endianness) 차이로 정수 필드가 역순으로 파싱되는 문제를 발견해 명시적 바이트 오더 지정으로 해결했습니다.

Alternatives considered:
  • 범용 ASN.1 파싱 라이브러리 도입
  • M사 측에 데이터 포맷 변경 요청

V2X 메시지 직렬화에 Protocol Buffers 채택 (내부 파이프라인 구간)

Reasoning:

ASN.1 파싱이 끝난 데이터를 내부 Kafka 파이프라인에 태울 때는 바이너리 직렬화로 JSON 대비 메시지 크기를 ~60% 줄여 100ms 지연 예산 내에서 처리 가능했습니다. 스키마 레지스트리를 통해 내부 컨슈머 간 인터페이스 호환성을 강제할 수 있었습니다.

Alternatives considered:
  • ASN.1 포맷을 내부 파이프라인까지 그대로 유지
  • JSON over HTTP/REST

Kafka를 V2X 데이터 백본으로 채택

Reasoning:

Kafka의 파티셔닝된 로그는 현장 테스트 디버깅 및 분석을 위한 메시지 재생 기능을 제공합니다. 실시간 대시보드, 데이터 레이크, 알림 등 여러 컨슈머가 독립적으로 구독할 수 있습니다.

Alternatives considered:
  • 직접 TCP 소켓 통신
  • IoT용 MQTT

Redis를 활용한 무상태 미들웨어

Reasoning:

무상태 설계로 현장 테스트 시 수평 확장이 가능합니다. Redis가 TTL 기반으로 처리 중인 메시지 상태를 저장하여 차량 재연결 시 처리할 수 있습니다.

Alternatives considered:
  • 상태 내장 미들웨어
  • 데이터베이스 기반 세션 상태

Result & Impact

  • 종단간 80ms 미만 (목표: 100ms)
    V2X 메시지 지연시간
  • 프로토타입 현장 테스트 중 99.8%
    메시지 전달률
  • 경찰청 시연에 맞춰 일정 내 납품
    프로토타입 마일스톤

경찰청 관계자들에게 프로토타입 시연이 성공적으로 이루어졌습니다. V2X 미들웨어 레이어는 자율주행 팀이 안정적인 실시간 인프라 데이터 위에 상위 레벨 의사결정 로직을 구현할 수 있는 기반을 제공했습니다.

전체 프로젝트