Applied Intuition의 능동 안전 및 SDS(Self-Driving System)팀은 시스템 복잡성의 증가, 장기적인 극단적 사례, 그리고 빠듯한 일정 속에 더욱 강화된 규제와 같이 고객사가 겪고 있는 동일한 과제에 직면해 있으며, 이를 따라잡기 위해 당사는 자체 개발 툴을 활용합니다.
이 블로그에서는 기존의 능동 안전 개발이 왜 느리고 단편화되었는지, ADP (Applied Development Platform)가 이를 어떻게 변화시키는지, 그리고 당사의 SDS팀이 이 플랫폼을 어떻게 활용하고 있는지에 대해 설명합니다.
왜 능동 안전 개발은 느리고 단편화되었는가?
Euro NCAP 2026은 더 높은 속도, 야간 조건, 더 복잡한 교차로 및 취약한 도로 이용자 시나리오로 충돌 회피 테스트를 확대합니다. 물리적 시험장은 여전히 중요하지만, 도로 주행 테스트만으로 이 모든 것을 커버하는 것은 비현실적입니다. 따라서 이를 위해서는 통합된 시뮬레이션 및 데이터 플랫폼이 필수적입니다.
분산된 워크플로로 인한 검증 속도 저하
많은 자율 긴급 제동(AEB) 및 차선 유지 보조(LKA) 프로그램은 조각난 도구와 인수인계 과정에 의존합니다.
- 트랙, 시험장, 차량에서 수집된 데이터는 일관되지 않은 수집 경로와 파이프라인을 통해 유입됩니다.
- KPI 계산, 분석, 분류 작업이 서로 다른 팀이 보유한 여러 도구에 분산되어 있습니다.
- 테스트 결과의 피드백 루프가 기능 담당자에게 전달되기까지 몇 주가 소요될 수 있습니다.
그 영향은 측정 가능합니다.
한 도시형 대중교통 프로그램에서 실제 테스트 캠페인은 저속 AEB가 보행자를 안정적으로 회피함을 보여주었습니다. 그러나 매우 느린 보행자(보행 보조기 사용자와 유사한 약 0.5m/s)를 대상으로 한 후속 시뮬레이션에서는 셔틀이 전혀 제동하지 않는다는 사실이 드러났습니다. 근본 원인 분석은 팀과 도구에 분산되어 단일 엔지니어의 워크스테이션에서 수행되었으며, 수 주가 소요된 끝에 매우 느린 보행자를 정적 장애물로 분류한 인식 시스템의 문제로 귀결되었습니다. 프로그램이 분산되고 로컬에서 실행되는 툴에 의존할 때 이러한 수 주에 걸친 검증 루프는 흔히 발생합니다.
KPI 격차는 실제 성과
대부분의 팀은 개발을 안내하기 위해 KPI를 원하지만, 대규모 데이터셋에 대한 최신 지표는 드뭅니다.
- 서로 다른 그룹이 일관성 없는 툴과 방법론으로 지표를 계산
- 결과는 주요 마일스톤 이후 정적 보고서로 도착
- 분석은 종종 비용이 많이 드는 테스트 캠페인이 끝난 후에야 시작
그 결과 통찰력이 지연되고 데이터 수집은 비효율적이게 됩니다.
예를 들어 스웨덴의 겨울 테스트나 호주의 고온 환경 캠페인은 수개월 전부터 계획되어 수주간 진행되지만, 분석은 캠페인 종료 후 시작될 수 있습니다. 데이터 수집을 집중시킬 수 있었던 중요한 발견이 너무 늦게 도출되어 추가 출장 필요성과 프로그램 지연이 수개월 발생합니다.
AEB 의 경우, 수천 시간의 주행 시간당 발생하는 오탐지 활성화 건수는 KPI입니다. 목표치가 0에 가까워질수록 모든 이벤트를 분류해야 하며, 새로운 스택 릴리스마다 대표적 운영 설계 영역(ODD) 데이터셋을 기준으로 검증해야 합니다. 분산된 툴에서 이를 수행하는 것은 곧바로 주요 운영 부담으로 이어집니다.
구조화되지 않은 분류 작업을 통한 시간 낭비
문제가 감지되면 팀은 종종 다음과 같이 분류 작업을 수행합니다.
- 로그 뷰어, 맞춤형 스크립트, 내부 툴, 스프레드시트 간 전환
- 이메일이나 채팅을 통한 스크린샷 및 로그 발췌문 공유
- 소유권 변경이나 맥락 상실로 인한 분석 재실행
그 결과 문제 해결이 느려지고 오류가 발생하기 쉬우며 지식 연속성이 저하됩니다.
개방형 재시뮬레이션을 통한 AEB 오탐지 모니터링이 대표적인 사례입니다. 팀은 주행 데이터 수집, 인제스트, 대규모 재시뮬레이션, KPI 계산, 분류, 회귀 검증 과정을 종종 독점적 레거시 시스템을 가로질러 연결해야 합니다. 엔지니어들은 핵심 스택 개발과 승인에 집중하기보다 복잡한 인프라 운영에 매달리게 됩니다.
롱테일 현상을 놓치는 도로 테스트
도로 및 트랙 테스트는 드물지만 안전에 치명적인 시나리오를 다루기 어렵습니다.
- 특정 지역이나 계절에만 나타나는 행위자
- 악천후 또는 저시정 조건
- 복잡한 교차로 또는 특이한 인프라
순수 도로 환경에서 무스 같은 대형 동물 감지 검증은 어렵습니다. 이는 접촉이 드물고, 행동이 다양하며, 조건이 변하기 때문입니다. 시뮬레이션은 동물 행동, 날씨, 교통량을 체계적으로 변화시켜 이러한 격차를 해소할 수 있으며, 특히 실제 사건과 아차 사고를 재사용 가능한 매개변수화된 시나리오로 전환할 수 있다면 더욱 유용합니다.
ADP는 능동 안전 워크플로우를 어떻게 변화시키나요?
ADP(Applied Development Platform) 는 데이터, KPI, 트라이아지, 시뮬레이션을 단일 플랫폼에 통합하여 능동 안전 팀이 툴을 연결하는 데 시간을 낭비하지 않고 스택 개선에 집중할 수 있도록 합니다.
KPI에서 신호까지 하나의 워크플로우
ADP는 단일 환경에서 상위 성능 지표와 하위 센서 데이터를 연결합니다.
- 트랙, 도로, 시뮬레이션 전반의 KPI (예: AEB 오탐률, LKA 차선 유지 품질, NCAP 2026 효과성 점수)로 시작
- 도로 유형, 환경, 차량 또는 소프트웨어 버전으로 필터링하여 성능 저하 지점 파악
- KPI 이상치에서 정확한 원인을 규명하기 위한 시퀀스 분석
- 동일한 웹 UI 내에서 센서 신호, 객체 목록, 플래너 출력, 작동 명령을 모두 검사
내부적으로 ADP를 활용하여 다양한 시나리오와 스택 버전 전반에 걸친 NCAP 2026 AEB 효과성을 모니터링하고, 대규모 실제 데이터셋에 대한 개방 루프 재시뮬레이션을 통해 AEB 오탐률을 추적합니다. 이러한 워크플로우를 단일 플랫폼에서 실행함으로써 KPI와 기반 데이터 뷰를 시간 경과에 따라 일관되고 비교 가능하게 유지합니다.
내장된 분류 구조
ADP는 임의적 조사 대신 구조화된 분류 흐름을 구현합니다.
- KPI 이상 또는 테스트 실패 감지
- 관련 데이터셋 및 시퀀스 식별 및 그룹화
- 개별 시퀀스 및 프레임 검사 및 주석 추가
- 명확한 컨텍스트(데이터, 조건, 스택 버전)로 문제 정의
- 해결까지 소유권 및 상태 추적
이를 통해 중복 작업을 줄이고, 분류 작업을 더 예측 가능하게 하며, 관련 장면 라이브러리를 구축합니다. AEB 오탐지 모니터링의 경우, ADP는 기록된 대규모 트래픽 로그 컬렉션을 처리하고, 로그 재생 모드에서 AEB 스택을 재시뮬레이션하며, 시나리오 메타데이터, 센서 데이터, KPI 기여도 등 전체 컨텍스트와 함께 각 활성화 사례를 자동으로 노출하여 효율적인 트라이지를 지원합니다.
실제 데이터와 긴밀히 연계된 시뮬레이션
ADP는 시뮬레이션을 실제 현장 발견 사항과 직접 연결합니다.
- 차량 또는 트랙 데이터에서 흥미로운 사건 또는 근접 사고 감지
- 주체, 궤적, 환경을 포함한 시나리오 추출
- 매개변수화된 시나리오 또는 시나리오 군으로 변환
- 시뮬레이션에서 변형 실행을 통해 시스템 동작 탐색 및 개선 사항 테스트
- 유망한 수정안을 시뮬레이션으로 검증한 후, 적절한 경우 실제 도로에서 확인
이 루프는 KPI 모니터링 및 트라이아지와 동일한 플랫폼에서 실행되므로 시뮬레이션은 별도의 일회성 작업이 아닙니다. 예를 들어, 겨울철 무스 감지 아차 사고는 다음 실제 테스트 캠페인 전에 다양한 속도, 조명, 기상 조건에서 재현되는 시나리오 템플릿이 될 수 있습니다.

Applied Intuition의 SDS 팀은 ADP를 어떻게 활용하나요?
Applied Intuition의 SDS 팀은 자체 능동 안전 기능을 개발하기 위해 매일 ADP를 사용하며, 플랫폼의 내부 고객 역할을 수행합니다.
생산 환경 도구로 SDS 구축
고객에게 제공하는 것과 동일한 생산용 ADP 플랫폼에서 SDS를 운영합니다. 별도의 내부 프로토타입 스택은 없습니다. 실제로는 두 가지 주요 설정을 사용합니다.
- 대규모 데이터 수집 관리 및 실제/합성 시나리오에 대한 대규모 시뮬레이션 실행을 위한 전용 ADP 서버
- 신규 기능 및 수정 사항의 신속한 테이블 위 테스트를 위한 개발자 머신의 로컬 ADP 인스턴스
두 환경 모두 동일한 UI와 워크플로를 공유하므로 엔지니어들은 신속한 로컬 실험에서 대규모 평가로 원활하게 전환할 수 있으며, 이는 고빈도 개발 주기를 지원합니다. 엔지니어들이 의존하는 동일한 기능들—데이터 수집, KPI 계산, 트라이아지, 시뮬레이션—이 OEM 및 Tier 1 업체들에게도 제공됩니다. 이는 많은 툴들이 주로 데모나 일회성 프로젝트를 위해 구축되는 분야에서 흔치 않은 사례입니다.
AEB를 통한 엔드투엔드 사례
AEB 개발 워크플로가 이를 어떻게 구현하는지 보여줍니다.
- 로컬 반복: 엔지니어는 Euro NCAP 및 FMVSS 시나리오의 하위 집합을 활용해 로컬에서 새로운 AEB 기능을 설계 및 테스트하여 회귀 현상을 조기에 포착합니다.
- 대규모 시뮬레이션: 안정화된 변경 사항은 ADP 서버에서 대규모 합성 및 실제 데이터셋을 통해 평가되어 AEB KPI를 추정합니다.
- 오탐률 추정: ADP는 대규모 기록된 교통 로그 세트에서 AEB 스택을 재시뮬레이션하고 오탐 활성화 사례를 집계하여 현실적인 오탐률을 산출합니다.
- NCAP 및 규제 점수: ADP 내 Euro NCAP 및 FMVSS 테스트 스위트에서 AEB를 재실행하며, 스코어보드는 현재 시스템의 NCAP 점수, 별점 등급, 규제 통과/불합격 결과를 표시합니다.
- 구조화된 트라이아지: 오탐 발생 또는 특정 시나리오 성능 저하 시 개발자는 ADP 내에서 개별 시뮬레이션 로그(내부 신호, 객체 궤적, 플래너 결정, 액추에이터 명령)를 검토하여 다음 반복 작업을 추진합니다.
로컬 테스트부터 대규모 재시뮬레이션, KPI 검토, 트라이아지까지 이 루프가 주로 ADP를 통해 실행되므로 SDS 엔지니어는 모든 의미 있는 변경 사항에 대해 신속하고 일관된 피드백을 받습니다. 이는 또한 SDS 작업으로 인한 모든 개선 사항(예: 향상된 협업 또는 더 효율적인 NCAP 워크플로)이 동일한 플랫폼을 사용하는 고객 팀에게 즉시 제공됨을 의미합니다.
능동 안전 분야에서 함께 일해 보세요
능동 안전 또는 ADAS 시스템을 구축 중이며 느린 검증 루프, KPI 격차, 트라이아지 병목 현상, 롱테일 커버리지와 같은 과제를 가지고 있다면, ADP가 어떻게 도움이 될 수 있는지 더 자세히 알아보세요.
저희 SDS 팀이 플랫폼을 활용하는 방식을 확인하고, 유사한 워크플로우가 귀사의 개발 및 검증 프로세스에 어떻게 적용될 수 있는지 살펴보실 수 있습니다.
툴링 중심 워크플로우와 대규모 능동 안전 개발에 열정을 가진 엔지니어라면, 저희와 함께 기술의 한계를 넘어서고자 하는 분들과의 대화를 항상 환영합니다.
.webp)
.webp)

