들어가며: 객체 검출에서 움직임 이해로​

영상에서 차량을 찾는 것만으로는 과속이나 위험한 접근을 판단할 수 없습니다. 같은 차량을 시간에 따라 연결하고, 화면 속 이동을 실제 거리로 환산해야 비로소 km/h 단위의 속도를 얻을 수 있습니다.

이번 연구의 목표는 저 FPS CCTV에서도 차량의 ID를 안정적으로 유지하고, 카메라 장면을 실제 도로 좌표로 보정해 EVA가 활용할 수 있는 속도 정보를 생성하는 것이었습니다.

연구팀은 하나의 Tracking 모델을 교체하는 데 그치지 않고, 저 FPS에서의 차량 연결부터 픽셀 좌표의 실제 거리 변환, 속도 결과를 확인하는 화면까지 전체 과정을 하나의 파이프라인으로 구현하고 검증했습니다. 아래 데모에서는 차량별 ID와 이동 궤적, 측정 영역, 추정 속도가 함께 표시되는 모습을 확인할 수 있습니다.

1. 이미지 Feature 추출: 차량의 생김새를 표현하다​

저 FPS 영상에서는 프레임 사이에 차량이 크게 이동해 이전 Bounding Box와 현재 Bounding Box가 겹치지 않는 경우가 많습니다. 위치만으로 같은 차량을 찾기 어려우므로, 검출된 차량 이미지를 비교할 수 있는 Feature Vector로 변환했습니다.

왜 세 가지 Feature가 필요했을까?​

차량의 생김새를 구분하는 단서는 형태, 색상, 윤곽으로 나눌 수 있습니다. 각 단서는 강한 장면과 약한 장면이 달랐기 때문에 하나의 Feature만으로 모든 CCTV 환경을 안정적으로 처리하기 어려웠습니다.

DINOv2: 차량의 전체적인 외형을 표현하다​

DINOv2는 이미지에서 형태와 질감, 구성 요소를 종합한 Deep Feature를 추출합니다. 연구 초기에는 EVA의 VLM 활용 방향과 연결하기 쉬운 Qwen 계열의 시각 Feature도 후보로 검토했습니다. 하지만 VLM은 이미지의 의미적 유사성을 이해하는 데 강한 반면, Tracking은 외형이 비슷한 차량 한 대 한 대를 구분해야 합니다. 동일 차량과 다른 차량의 유사도 분포를 비교한 결과 DINOv2가 두 그룹을 더 분명하게 나눴고, 이에 따라 Deep Feature의 기본 모델로 선택했습니다.

HSV: 색 분포를 수치화하다​

HSV는 색상 계열(Hue), 색의 진함(Saturation), 밝기(Value)를 분리해 표현합니다. 차량 Crop의 RGB 값을 HSV로 변환한 뒤 H·S·V 값을 각각 정해진 구간의 Histogram에 누적하면, 차량에 어떤 색이 얼마나 포함됐는지를 하나의 Feature Vector로 만들 수 있습니다.

HSV 색상 공간(왼쪽)과 픽셀 값을 구간별로 누적하는 Histogram 예시(오른쪽)

서로 다른 차량의 색 분포는 각 Histogram Bin에서 더 작은 값을 합산하는 Histogram Intersection으로 비교했습니다. 색 분포가 많이 겹칠수록 점수가 커지므로, 차종이 같아도 차체 색상이 다른 차량을 빠르게 구분하는 데 도움이 됩니다.

HOG: 윤곽과 밝기 경계를 수치화하다​

HOG는 차량 Crop을 흑백으로 변환한 뒤, 픽셀마다 밝기가 변하는 방향과 강도를 계산합니다. 작은 Cell 안에서 방향별 Gradient를 Histogram으로 만들고, 주변 Cell을 Block으로 묶어 정규화한 뒤 이어 붙이면 색상에 덜 의존하는 윤곽 Feature가 완성됩니다.

밝기 변화의 방향과 강도를 방향별 Histogram으로 표현하는 HOG 예시
출처: LearnOpenCV

어느 하나의 Feature만으로는 모든 장면을 충분히 설명하기 어려웠습니다. 주간처럼 색상 정보가 선명한 장면에서는 HSV가 강한 구분력을 보였고, 색상 단서가 약한 장면에서는 HOG의 윤곽 정보가 보완 역할을 했습니다. 최종적으로 세 점수를 정규화한 뒤 DINOv2 0.3 : HSV 0.5 : HOG 0.2 비율로 결합했습니다.

이 Fusion 방식은 어느 한 Feature가 조명이나 가림의 영향을 받아 흔들릴 때 다른 Feature가 판단을 지지하도록 합니다. 영상 환경에 따라 최적 비율은 달라질 수 있지만, 세 Feature를 함께 사용하는 구성은 다양한 CCTV에 적용하기 위한 안정적인 공통 기준이 되었습니다. 통합 Feature는 각 차량의 시각적 지문으로 사용되며, 다음 단계의 Tracking에서 과거 Track과 현재 Detection을 비교하는 기준이 됩니다.

2. 저 FPS Tracking: Feature와 이동 정보로 ID를 연결하다​

이미지 Feature가 비슷하다는 이유만으로 두 차량을 바로 연결하면 비슷한 색상과 차종이 동시에 등장할 때 ID가 뒤바뀔 수 있습니다. 반대로 Motion만 사용하면 이동 이력이 없는 신규 차량이나 프레임 간격이 긴 영상에 대응하기 어렵습니다. 따라서 Appearance를 중심으로 후보를 찾고 Motion 정보를 보조 신호로 사용하는 방식을 적용했습니다.

Feature별 유사도를 결합하고, Motion·점수 기준을 통과한 후보만 1:1로 연결하는 흐름

먼저 과거 Track과 현재 Detection의 모든 조합에 대해 통합 Feature 유사도를 계산합니다. 이동 이력이 있는 Track에는 최근 방향과 속도를 바탕으로 만든 Motion Prior를 더해, 현재 위치에 실제로 도착할 수 있는 차량인지 확인합니다. Appearance가 멀리 이동한 차량의 후보를 찾는다면, Motion은 그 후보가 물리적으로 가능한지를 한 번 더 확인하는 역할입니다.

다음으로 Hungarian Matching을 이용해 전체 후보를 중복 없이 1:1로 배정합니다. 다만 배정됐다는 이유만으로 바로 같은 차량이라고 판단하지는 않습니다. 유사도 자체가 충분한지, 다음 후보보다 뚜렷하게 나은지, Track과 Detection이 서로를 가장 좋은 후보로 선택했는지를 확인한 뒤 연결을 승인합니다.

승인 조건을 통과하지 못한 조합은 제외하고 남은 후보를 다시 탐색합니다. 이렇게 하면 첫 배정에 가려졌던 정상 후보를 되찾으면서도 억지 연결을 줄일 수 있습니다. 승인된 결과만 Track Memory에 반영하고, 신규 차량과 화면을 벗어난 차량을 별도로 관리해 한 번의 오검출이 이후 매칭까지 연쇄적으로 흔드는 문제를 막았습니다.

야간 Tracking 성능 개선​

야간에는 주간에 유효했던 색상과 위치 정보가 동시에 흔들렸습니다. 경광등이나 헤드라이트의 Glare가 차량을 덮으면 같은 차량의 HSV 색 분포가 프레임마다 크게 달라집니다. 검출 Bounding Box도 차체가 아닌 빛 번짐이나 노면 반사를 따라 움직일 수 있어, 실제 진행 방향과 반대쪽으로 이동한 것처럼 보이기도 합니다. 저 FPS에서는 다음 관측까지 차량이 멀리 이동하므로 Appearance와 Motion 중 하나만으로 이 오류를 복구하기 어려웠습니다.

시간 순으로 나열한 프레임. Bounding Box가 Glare Blob에 맞춰지면서 관측 접지점이 진행 방향과 반대로 이동

이에 따라 모든 기준을 단순히 완화하는 대신, 야간의 실패 원인에 맞춰 Feature 조합과 후보 비교 방식, Track 유지 정책을 함께 조정했습니다.

UA-DETRAC 12개 시퀀스를 1 FPS로 평가한 결과, IDF1은 64.0에서 75.3, MOTA는 56.5에서 64.8로 높아졌고 ID Switch는 640에서 176으로 줄었습니다. Deep Feature 교체의 기여는 약 15%였으며, 나머지 개선은 이미 배정된 후보를 제외하는 경쟁 규칙과 야간 전용 Gate·Lifecycle 조정에서 얻었습니다. 좋은 Feature를 추출하는 것만큼, 불확실한 연결을 언제 거절하고 언제 다시 검토할지 정하는 Matching 절차가 중요하다는 결론을 얻었습니다.

3. 픽셀을 미터로 바꾸는 Camera Calibration​

Tracking 결과로 알 수 있는 값은 차량의 픽셀 위치와 시간입니다. 하지만 원근 때문에 같은 픽셀 거리도 화면의 앞쪽과 뒤쪽에서 서로 다른 실제 거리를 의미합니다. 따라서 속도를 계산하기 전에 픽셀 좌표를 도로 위의 미터 좌표로 변환해야 합니다.

원근에 따라 실제로 같은 5 m가 화면에서 서로 다른 픽셀 길이로 보이는 예시

속도를 추정하는 흐름은 간단합니다.
먼저 Tracking으로 같은 차량의 위치와 촬영 시각을 이어 붙이고, Calibration으로 화면 속 위치를 실제 도로 위 위치로 바꿉니다. 마지막으로 두 시점 사이에 차량이 이동한 실제 거리와 경과 시간을 비교해 속도를 구합니다.

처음에는 단안 Depth, 차량 평균 길이, Vanishing Point를 이용한 자동 보정을 검토했습니다. 자동화에는 유리했지만, 저 FPS·회전 차량·희미한 차선이 함께 나타나는 CCTV에서는 작은 추정 오차가 전체 좌표계와 속도에 크게 전달됐습니다. 그럴듯하지만 잘못된 결과가 만들어져도 사용자가 원인을 확인하기 어렵다는 문제도 있었습니다.

최종적으로는 사용자가 신뢰할 수 있는 도로 평면의 기준을 정하고, 시스템이 Homography 계산·검증·저장을 담당하는 사용자 정의형 Calibration을 선택했습니다. 입력 방식은 다음 두 가지입니다.

여기서 Homography는 화면에 사다리꼴로 보이는 도로 영역을 위에서 내려다본 평면으로 펼치는 변환입니다. 영상 속 네 점과 실제 도로 위 좌표를 대응시키면, 차량의 픽셀 위치를 미터 단위 위치로 바꿀 수 있습니다.

• 실제 도로에서 직사각형인 영역의 네 꼭짓점과 길이·폭
• 실제 (X, Y) 좌표를 아는 4개 이상의 기준점 또는 도면 대응점

BrnoCompSpeed는 고정형 도로 카메라 영상과 차량별 실측 속도를 제공하는 공개 차량 속도 추정 벤치마크 데이터셋입니다.
이 데이터셋의 9개 카메라 시점에서 실제 Tracking 궤적을 사용해 비교한 평균 절대오차는 다음과 같았습니다.

이 결과에서 얻은 설정 원칙은 단순합니다.
Calibration 영역은 차량이 실제로 지나는 도로 위에 두고, 진행 방향으로 가능한 한 길게 잡아야 합니다. 짧은 구간에서는 1 m의 입력 오차가 큰 비율 오차가 되지만, 긴 구간에서는 같은 오차의 영향이 작아집니다. 차량 위치를 도로에 투영할 때는 여러 점의 평균보다 Bounding Box의 하단 중심점 한 곳을 사용하는 방식이 가장 안정적이었습니다.

4. VLM 기반 실제 도로 크기 추정​

사용자 정의형 Calibration에는 도로 영역의 실제 길이와 폭이 필요합니다. 정확한 값을 직접 측정하는 것이 가장 안전하지만, 모든 현장에서 운영자가 처음부터 적절한 영역과 수치를 판단하기는 어렵습니다. 이에 VLM이 표시된 도로 영역과 주변 장면을 보고 실제 크기의 초깃값을 제안할 수 있는지 검증했습니다.

실험에서는 도로 영역의 네 꼭짓점을 P1–P4로 표시하고, 파란 외곽선과 반투명한 빨간 면으로 측정 영역을 강조했습니다. 이미지 표시만 제공하거나 좌표만 전달하는 방식보다, 표시된 이미지와 네 꼭짓점의 픽셀 좌표를 함께 제공하고 질문은 짧게 유지했을 때 가장 안정적인 결과를 얻었습니다.

VLM에 전달하기 위해 도로 영역을 표시한 예시

Qwen3.8-27B-FP8을 사용해 7개 장면의 3개 카메라 시점, 총 21개 이미지를 대상으로 입력 형식을 개선한 결과는 다음과 같습니다.

평균 비율 오차는 VLM이 추정한 길이·폭이 실제 값에서 평균적으로 얼마나 벗어났는지를 나타내며, 낮을수록 좋습니다.

입력 방식을 개선해 평균 비율 오차를 절반 가까이 줄였지만, 7.80 m의 길이 오차는 속도 계산에 필요한 절대 기준으로 바로 사용하기에는 컸습니다. 긴 원근 설명이나 Thinking을 추가하는 방식도 모든 장면에서 일관된 개선으로 이어지지 않았습니다.
따라서 현재 단계에서 VLM이 실측값을 자동 확정하도록 하기보다는, 사람이 확인할 수 있는 설정 가이드로 활용하는 것이 적절하다고 판단했습니다.

5. 실제 촬영 시간을 이용한 속도 계산​

최종 속도 추정기는 세 가지 정보를 함께 사용합니다.

• Track ID는 같은 차량의 관측을 연결합니다.
• Calibration 결과는 Bounding Box 하단 중심점을 실제 도로 위 좌표로 바꿉니다.
• 실제 촬영 시각은 프레임 수가 아닌 정확한 시간 차이를 제공합니다.

Track별로 최근 위치 이력을 유지한 뒤, 최근 Window의 처음과 마지막 지점이 실제 도로 위에서 얼마나 떨어져 있는지 확인합니다. 이 거리를 두 지점 사이의 실제 촬영 시간으로 나누어 평균 속력을 계산합니다.
프레임 수가 아니라 실제 Timestamp를 사용하기 때문에 입력 FPS가 달라져도 같은 시간 기준을 유지할 수 있습니다. 계산 결과에는 EMA를 적용해 Bounding Box의 작은 흔들림을 줄였습니다.

현재 출력은 순간속도가 아니라 최근 Window의 양 끝점을 기준으로 한 지면상 평균 속력입니다. 따라서 곡선 주행에서는 실제 이동 경로보다 짧게 측정될 수 있으며, 카메라 흔들림이나 비평면 도로에서도 별도의 보정이 필요합니다.

차량 속도 추정 데모

6. 제품화 계획: 연구 결과를 EVA의 기능으로​

이번 연구의 목표는 속도값을 계산하는 기술을 만드는 데서 그치지 않고, 현장 운영자가 실제로 설정하고 활용할 수 있는 EVA 기능의 기반을 마련하는 것이었습니다. 차량의 속도와 이동 방향을 EVA의 탐지 영역, 객체 정보, 이벤트 규칙과 결합하면 단순 모니터링을 넘어 다음과 같은 상황을 감지할 수 있습니다.

이번 연구는 기술적인 성능 검증에만 머물지 않고, 제품화를 전제로 사용자가 기능을 설정하고 결과를 확인하는 UX까지 함께 고려하여 진행했습니다. 이를 바탕으로 운영자가 카메라 화면에서 차량이 지나는 측정 영역을 지정하면 VLM이 길이와 폭의 초깃값을 제안하고, 사용자는 현장 정보나 실측값으로 이를 확인·수정할 수 있도록 구성했습니다. 이후 Overlay 미리보기에서 영역, 차량 궤적, 추정 속도를 한 화면에 보여주어 설정이 올바른지 바로 검증할 수 있습니다.

설정이 완료된 뒤에는 사용자가 구역별 제한 속도와 관심 시나리오를 선택하고, 발생한 이벤트를 EVA의 알림 채널과 대시보드에 연결하는 흐름으로 이어집니다. 고정 카메라에서는 검증된 Calibration을 반복 사용할 수 있으며, 카메라 위치나 Zoom이 바뀐 경우에는 재설정이 필요하다는 안내를 제공하는 방식도 함께 고려하고 있습니다. 이처럼 기술 내부의 복잡성은 줄이고, 사용자가 설정의 근거와 결과를 쉽게 확인할 수 있도록 하는 것이 제품 UX의 핵심입니다.

이번 연구에서 개발한 차량 속도 추정 기술은 현장별 설정 가이드, VLM 기반 초기값 제안, 결과 검증 화면, 시나리오 설정과 알림 연동을 포함하는 제품화 과정을 거쳐 EVA의 정식 기능으로 제공될 예정입니다.

작은 VLM에게 "알아서 깊게 생각해"라고 요청하는 것만으로는 일관된 판단을 기대하기 어렵습니다. 모델은 하나의 호출 안에서 여러 문제를 동시에 해결하려 하고, 애매한 증거를 오래 되짚다가 결론을 내리지 못할 수도 있습니다.

이번 향상된 Thinking 모드에서는 모델의 내부 추론에 모든 판단을 맡기는 대신, 사고의 흐름 자체를 역할과 구조로 설계했습니다. 기준을 먼저 세우고, 볼 영역을 고정한 뒤, 서로 다른 관점에서 판단하고, 마지막 결정은 코드가 담당하도록 파이프라인을 재구성했습니다.

핵심은 생각을 더 많이 시키는 것이 아니라, 보고, 판단하고, 의심해야 할 순서를 명확하게 만드는 것입니다.

1. 기존 Thinking 구조의 문제​

기존 개발 버전은 incidents 블록에 포함된 여러 위험 상황을 한 번의 VLM 호출에서 동시에 판정했습니다.

구조는 단순하지만, 한 번의 호출에 서로 다른 문제를 모두 맡긴다는 점에서 두 가지 문제가 발생했습니다.

1) 한 번에 여러 문제를 동시에 판단​

호출 한 번이 fall, smoke, fire를 동시에 판정합니다. 어떤 항목은 쉽게 판단할 수 있어도, 하나의 애매한 항목이 전체 Reasoning Budget을 차지할 수 있습니다.

2) 생각의 범위를 제한하기 어려움​

Reasoning은 모델 내부에서 일어나는 블랙박스 과정입니다. 애플리케이션이 조절할 수 있는 값은 사실상 Budget 숫자 하나뿐이고, 모델이 어떤 기준으로 무엇을 반복해서 검토하는지는 통제하기 어렵습니다.

2. 실제 Thinking trace가 보여준 한계​

증기가 깔린 설비실에서 smoke를 판정하는 상황을 살펴보면, 모델이 "깊이 생각한다"는 것이 항상 새로운 근거를 찾는다는 의미는 아니라는 점을 확인할 수 있습니다.

Smoke 판정에 사용한 설비 장면

Qwen3.5VL-9B-Thinking Langfuse Trace

모델은 흰색 증기를 발견한 뒤, 증기인지 가스 누출인지 판단하기 위해 같은 규칙을 반복해서 읽었습니다. 그러나 반복 과정에서 새로운 시각 증거가 추가되지는 않았습니다.

"Wait, let's look closer."의 반복 — 새로운 시각 증거는 0개

이 trace에서 확인한 대표적인 문제는 다음과 같습니다.

결국 소형 VLM에게 "알아서 깊게 생각해"라고 요청하는 것만으로는 충분하지 않습니다. 모델이 무엇을 먼저 확인하고, 언제 판단을 끝내며, 애매한 경우 어떻게 처리할지를 구조로 안내해야 합니다.

3. 설계 철학: 사고의 흐름을 구조로 만든다​

향상된 Thinking 모드는 다음 세 가지 원칙을 중심으로 설계했습니다.

새 아키텍처는 시나리오를 먼저 규칙으로 정리하고, 서로 다른 역할의 Voter가 독립적으로 판단하도록 구성됩니다.

• 두 Voter는 병렬·독립적으로 실행되며 서로의 출력을 볼 수 없습니다.
• 모든 호출은 enable_thinking: false인 Instruct 방식으로 실행합니다.
• 하나의 호출에는 하나의 판단 문제만 전달합니다.
• 최종 알람은 두 Voter가 모두 Positive일 때만 발생합니다.

이 구조에서 LLM은 모든 것을 한 번에 결정하지 않습니다. 각 단계가 자신의 역할에 집중하고, 코드가 단계 사이의 연결과 최종 결정을 통제합니다.

4. 핵심 장치: "지금 여기를 보고 있어"​

판단하기 전에 모델이 어디를 보고 있는지부터 근거로 출력하도록 만들었습니다. 이를 담당하는 역할이 focus_locator입니다.

focus_locator는 판정을 내리는 역할이 아니라, 관찰 대상과 위치를 제안하는 역할만 합니다. 이후 vote_context는 전체 프레임과 Locator가 지정한 영역의 Crop을 함께 보고, vote_skeptic은 Locator의 설명을 참고하지 않고 전체 프레임만으로 독립 검증합니다.

왜 성능에 도움이 되는가​

• 8B급 VLM은 이미지 전체의 인상으로 판단하기 쉽습니다. 명시된 영역의 증거를 먼저 제공하면 판단을 해당 근거에 정박(grounding)할 수 있습니다.
• 20% Margin Crop은 대상을 확대하면서도 주변 맥락을 유지합니다. 대상의 일부만 보고 오판하는 문제를 줄이기 위한 장치입니다.
• 어디를 보았는지가 텍스트로 남기 때문에, 오판이 발생했을 때 시선이 잘못되었는지 판단이 잘못되었는지 구분할 수 있습니다.

5. 실패한 trace를 구조로 해결하기​

기존 Thinking trace에서 나타난 문제를 새로운 Pipeline의 역할과 Gate로 대응했습니다.

이렇게 하면 모델의 내부 추론을 길게 만드는 대신, 판단에 필요한 검토 과정을 시스템의 관찰 가능한 단계로 바꿀 수 있습니다.

6. Before / After​

변경의 핵심은 호출 횟수를 늘리는 데 있지 않습니다. 판단 기준, 관찰 영역, 긍정과 반증의 역할, 최종 결정을 각각 분리해 실패 지점을 추적할 수 있게 만든 데 있습니다.

7. 시나리오를 더 유연하게 확장하기​

기존 구조에서는 LLM이 판단 범위를 벗어나기 쉬웠기 때문에 탐지 대상을 연기·화재·쓰러짐 세 가지로 고정할 수밖에 없었습니다.

새 구조에서는 사용자가 incidents 블록을 직접 수정해도, 먼저 rule guide가 판정 기준을 정리합니다. Voter는 생성된 기준에 따라서만 판단합니다.

예를 들어 다음과 같은 요구사항을 입력할 수 있습니다.

• “연기 발생” → 검은 연기 탐지
• “화재 발생” → 영역의 대부분을 차지하는 큰 불꽃 탐지

수정된 문구는 그대로 Rule Guide로 생성되고, 이후 각 Voter는 해당 기준을 사용합니다. 따라서 새로운 시나리오를 추가할 때마다 Router나 판정 코드를 수정할 필요가 줄어듭니다.

8. 성능 결과​

Precision 0.8273: 오탐 억제​

SINGLE 평가에서 신규 구조는 Precision을 크게 높였습니다.

Precision은 0.7316에서 0.8273으로 0.0957p 상승했습니다. 반면 Recall은 0.9006에서 0.7823으로 낮아졌습니다. 두 Voter가 모두 Positive여야 알람이 발생하는 AND Gate가 오탐을 억제하는 대신, 일부 실제 사례를 보수적으로 차단한 결과입니다.

카테고리별 성능​

연기·불꽃은 모든 지표가 1.0000에 도달했고, 화재는 Precision이 0.8085로 향상되었습니다. 특히 화재 오탐을 9건으로 억제하면서 운영 환경에서 불필요한 알람을 줄이는 효과를 확인했습니다.

위와 같은 쓰러짐 사례에서는 사람이 바닥에 수평으로 누워 있는지, 단순히 웅크리거나 앉은 자세는 아닌지, 직접적인 시각 증거가 충분한지를 단계적으로 확인합니다.

반대로 붉은 빛이 보이는 장면에서는 조명이나 반사광을 실제 화염으로 단정하지 않습니다. 야간 환경, 광원, 화염 형태, 연소 단서와 연기 동반 여부를 함께 검토한 뒤 명확한 근거가 없으면 alert: false를 반환합니다.

한 줄 요약​

8B에게 깊은 생각을 시키는 대신, 사고가 흘러야 할 길을 우리가 먼저 놓았습니다 — 기준을 세우고, 시선을 고정하고, 판단하고, 의심하도록.

EVA의 기능과 사용자 요청이 늘어나면서, 각각의 요청을 어떤 사전 정의 경로에서 처리할지 결정하는 일이 점점 어려워지고 있습니다. EVA v3.1에서는 Chat 아키텍처를 Router 기반 Agent에서 Tool-calling Agent로 변경했습니다.

기존 아키텍처는 요청을 분류한 뒤 사전 정의된 처리 경로로 전달했습니다. 새로운 아키텍처에서는 LLM에 사용 가능한 기능 목록을 제공하고, 요청을 처리하는 데 필요한 Tool을 선택한 뒤 실행 결과를 바탕으로 응답하도록 합니다.

1. 왜 아키텍처를 변경했는가​

Router 기반 아키텍처는 요청 유형별 처리 경로가 명확하다는 장점이 있습니다. 하지만 기능과 질문 유형이 늘어나면서 다음과 같은 한계가 드러났습니다.

• 새로운 기능을 추가하려면 Router와 연결된 Graph 분기를 함께 수정해야 하는 경우가 많습니다.
• Prompt와 코드에 포함된 매뉴얼 내용을 업데이트하고 관리하기 어렵습니다.
• 현재 Runtime 설정에 대한 질문과 일반적인 기능 설명 질문이 같은 Q&A 흐름에 섞일 수 있습니다.

2. Router 기반 Agent와 Tool-calling Agent​

두 아키텍처는 서로 다른 질문에 답합니다.

Router 기반 설계에서는 코드가 사용할 수 있는 분기를 정의하고 그중 하나를 선택합니다. Tool-calling 설계에서는 LLM이 사용 가능한 Tool Schema를 전달받고, 요청에 필요한 Tool을 판단합니다.

이 차이는 단순히 Router를 LLM으로 교체하는 것에 그치지 않습니다. 처리 결정을 어디에서 내리고, 기능을 시스템에 어떻게 추가할지까지 바꾸는 구조적 변화입니다.

Router 기반 Agent
사용자 요청
  → 요청 유형 분류
  → 사전 정의된 하나의 경로 선택
  → Node 또는 Subgraph 실행
  → 응답

Tool-calling Agent
사용자 요청
  → 의도 분석
  → 필요한 Tool 선택
  → Tool 실행
  → 실행 결과 확인
  → 응답

3. Prepare–Decide–Tool–Compose–Finalize 흐름​

새로운 Agent는 다음 다섯 가지 개념적 단계로 동작합니다.

사용자 요청
  ↓
Prepare
  ↓
Decide
  ↓
Tool
  ↓
Compose
  ↓
Finalize

예를 들어 “AI 추론 간격을 30초로 변경해줘.”라는 요청은 다음과 같이 처리할 수 있습니다.

Decide
  → set_detection_interval 선택
  → 입력값 30초 검증
  → 설정 변경
  → 실행 결과 반환
  → 최종 응답 생성

모든 요청이 각 단계를 별도의 작업으로 수행해야 하는 것은 아닙니다. 중요한 점은 Tool 선택, 실행, 응답 생성이 일관된 생명주기 안에서 명시적으로 처리된다는 것입니다.

4. 매뉴얼 Q&A를 Prompt에서 Knowledge RAG로​

아키텍처 변경은 EVA의 매뉴얼과 기능 관련 질문을 처리하는 방식에도 영향을 줍니다.

Prompt 기반 Chat​

기존 설계에서는 요청 유형에 따라 Guide를 선택하고, 답변을 생성하기 전에 해당 내용을 Prompt에 포함했습니다.

사용자 질문
  → 질문 분류
  → 관련 Guide 선택
  → Guide를 Prompt에 포함
  → LLM 응답 생성

예를 들어 객체 탐지 민감도에 대한 질문이 용어나 App 기능 질문으로 분류되면, 코드가 TERM_GUIDE 또는 APP_GUIDE를 선택해 Prompt에 포함하는 방식입니다.

이 방식에는 다음과 같은 한계가 있습니다.

• 별도의 문서 검색 단계가 없습니다.
• Prompt에 포함된 Guide 내용의 범위 안에서만 답변합니다.
• Guide가 변경되면 Prompt 또는 코드를 수정해야 할 수 있습니다.
• 코드가 질문에 맞는 Guide를 선택해야 합니다.

Tool-calling 기반 Chat​

새로운 설계에서는 매뉴얼 질문이 answer_eva_question을 선택합니다. 이 Tool은 질문을 임베딩하고 Knowledge 저장소를 검색한 뒤, 관련 페이지를 답변 모델의 Context로 전달합니다.

사용자 질문
  → answer_eva_question 선택
  → 질문 임베딩 생성
  → Qdrant에서 관련 페이지 검색
  → 검색된 페이지 내용을 Context로 전달
  → 답변 생성

예를 들어 “EVA에서 탐지 시나리오는 어떻게 설정하나요?”라는 질문이 들어오면, 시스템은 관련 설정 절차가 포함된 매뉴얼 페이지를 검색하고 그 페이지를 근거로 답변을 생성합니다.

이제 매뉴얼은 독립적으로 관리되는 Knowledge 소스가 됩니다. 관련된 페이지만 검색할 수 있고, 검색 결과에 파일명과 페이지 번호 같은 Metadata를 포함할 수도 있습니다. 매뉴얼이 변경되면 Chat Prompt 자체를 수정하는 대신 문서를 다시 Ingest하여 반영할 수 있습니다.

다만 검색 품질이 답변 품질에 직접 영향을 준다는 새로운 책임이 생깁니다. Knowledge Pipeline과 평가 체계가 Chat 시스템의 중요한 구성 요소가 됩니다.

5. 페이지 단위 Knowledge Ingest​

RAG 검색을 사용하려면 매뉴얼을 사용자가 질문하기 전에 검색 가능한 형태로 저장해야 합니다. 현재 Ingest 흐름은 다음과 같습니다.

PDF 또는 Markdown
  ↓
본문, 표, 그림 정보 추출
  ↓
페이지 단위 콘텐츠 구성
  ↓
Embedding 생성
  ↓
페이지 벡터를 Qdrant에 저장

질문 시에는 다음 흐름이 실행됩니다.

사용자 질문
  → Query Embedding 생성
  → Qdrant 유사도 검색
  → 관련 페이지 반환
  → 답변 Context로 사용

왜 페이지 단위로 검색하는가​

한 페이지에는 함께 읽어야 의미가 생기는 정보가 포함되어 있는 경우가 많습니다. 예를 들어 한 페이지에 다음 내용이 함께 있을 수 있습니다.

• 상단의 기능 설명
• 중단의 설정 화면 이미지
• 하단의 주의사항

페이지를 너무 작은 문장 단위 Chunk로 분리하면 이와 같은 관련 정보가 서로 다른 검색 결과로 나뉠 수 있습니다. 페이지 단위 검색은 설명, 설정 절차, 표, 그림 설명, 주의사항 사이의 관계를 유지합니다.

페이지 단위 검색의 목적은 단순히 Chunk를 크게 만드는 것이 아닙니다. 한 페이지 안에서 함께 설명되는 정보의 관계를 보존하는 것입니다.

현재 구조에서는 페이지 단위로 관련 자료를 찾은 뒤, 페이지 텍스트와 Metadata를 ToolResult에 포함해 답변 모델에 전달합니다. 이렇게 하면 설명, 설정 절차, 표, 주의사항 사이의 관계를 유지하면서 Knowledge 검색과 답변 생성의 책임을 분리할 수 있습니다.

고객 환경에 맞는 Knowledge 확장​

Knowledge에는 EVA 매뉴얼뿐만 아니라 고객 환경에 따라 필요한 문서도 함께 포함할 수 있습니다. 고객사별 운영 매뉴얼, 설비 기준서, 작업 절차서, 안전환경규정집 등을 Ingest하면, 일반적인 기능 설명을 넘어 해당 현장의 기준과 규정에 근거한 답변을 제공할 수 있습니다.

예를 들어 안전환경규정집을 Knowledge에 추가하면, 탐지 알람이 발생했을 때 단순히 알람 사실만 확인하는 데 그치지 않고 해당 알람과 관련된 안전·환경 규정, 현장 대응 절차, 후속 보고 기준을 질의할 수 있습니다. 고객별 문서를 별도의 Knowledge 소스로 관리하면 현장마다 다른 규정과 운영 기준을 반영하면서도 동일한 Tool-calling 흐름으로 검색하고 답변할 수 있습니다.

6. 전체 아키텍처​

전체 시스템은 오프라인 Knowledge Ingest 흐름과 온라인 Inference 흐름으로 구성됩니다.

오프라인 Knowledge 흐름
PDF / Markdown
  → 본문, 표, 그림 정보 추출
  → 페이지 단위 텍스트 구성
  → 페이지 Embedding 생성
  → 벡터를 Qdrant에 저장

온라인 Inference 흐름
사용자 요청
  → 대화 이력과 현재 설정 준비
  → 사용 가능한 Tool Registry를 LLM에 Bind
  → LLM이 필요한 Tool call 생성
  → 선택된 Tool 실행
  → ToolResult 반환
  → 필요할 때 자연어 답변으로 Compose
  → 응답 Finalize

Tool-calling 기반 Chat​

Tool Registry에는 다음과 같은 종류의 기능이 포함될 수 있습니다.

• 애플리케이션 상태를 변경하는 Action Tool
• Knowledge 기반 답변을 제공하는 Q&A Tool
• 일반적인 대화를 처리하는 Conversation Tool
• Runtime 정보나 시스템 상태를 조회하는 Meta Tool

answer_eva_question이 선택되면 Query Embedding 생성과 Qdrant 검색 흐름이 시작됩니다. 검색된 페이지 내용은 ToolResult로 반환되고, 이후 Compose 모델이 최종 답변을 만드는 데 사용할 수 있습니다.

이 구조는 각 구성 요소의 책임도 분리합니다. Tool은 구체적인 작업을 수행하고, Knowledge 검색은 근거를 제공하며, LLM은 최종 응답을 생성합니다.

7. 구조 변경으로 얻는 효과​

Tool-calling이 주는 실질적인 이점​

Tool-calling의 장점은 단순히 LLM이 함수를 호출할 수 있다는 데 있지 않습니다. 요청 해석, 실제 작업, Knowledge 검색, 최종 답변의 책임을 분리해 각 단계가 명확한 역할을 수행하도록 한다는 점이 핵심입니다.

• 기능 확장: 새로운 기능을 Router 분기와 Graph 경로에 일일이 연결하는 대신 Tool과 Schema를 Registry에 추가할 수 있습니다.
• 최신 정보 사용: 매뉴얼과 Runtime 상태를 Prompt에 고정하지 않고, 필요한 시점에 Knowledge 또는 상태 조회 Tool에서 가져올 수 있습니다.
• 안전한 실행: Action Tool마다 입력 검증과 권한, 실행 조건을 둘 수 있어 자연어 해석과 실제 상태 변경을 분리할 수 있습니다.
• 관찰과 개선: 어떤 Tool을 선택했는지, 어떤 입력을 전달했는지, 검색 결과가 무엇이었는지를 단계별로 기록하고 평가할 수 있습니다.

평가한 요청 기준으로는 기존 Router 기반 흐름보다 평균 응답 속도가 약 30% 빨라졌습니다. 불필요한 분류 단계를 줄이고 요청에 필요한 Tool을 직접 실행한 결과입니다.

기능 확장 용이성​

기존 아키텍처에서는 새로운 기능을 추가할 때 Router와 Graph 분기를 함께 수정해야 할 수 있었습니다. 새로운 아키텍처에서는 기능을 Tool로 구현하고 Schema와 함께 Registry에 등록할 수 있습니다.

기존
  → Router와 Graph 분기 수정

변경 후
  → Tool 구현
  → Tool Schema 등록

독립적인 Knowledge 관리​

매뉴얼 내용을 더 이상 Prompt나 애플리케이션 코드 안에서 관리할 필요가 없습니다. 매뉴얼을 Knowledge 문서로 관리하고 Ingest Pipeline을 통해 반영할 수 있습니다.

요청 목적의 명확한 분리​

같은 주제라도 사용자의 요청 목적에 따라 서로 다른 Backend에 연결할 수 있습니다.

현재 Runtime 값
  → Runtime 설정 조회

기능 설명
  → Knowledge 검색

설정 변경
  → Action Tool

응답 속도 개선과 함께 기능 수가 늘어날 때 처리 구조를 더 유연하게 확장할 수 있게 되었습니다.

8. 새롭게 고려해야 할 운영 항목​

구조가 유연해진 만큼 모니터링하고 평가해야 할 영역도 새롭게 생겼습니다.

특히 성공적인 Tool-calling 시스템을 만들기 위해서는 최종 답변의 문장만 평가해서는 부족합니다. 올바른 Tool을 선택했는지, 입력값이 유효했는지, Action이 안전했는지, 답변이 적절한 Knowledge 페이지에 근거했는지도 함께 확인해야 합니다.

마무리​

Router 기반 Agent에서 Tool-calling Agent로의 전환은 단순히 Chat 컴포넌트 하나를 교체한 것이 아닙니다. 코드가 요청의 처리 경로를 결정하던 구조에서, LLM이 요청을 처리하는 데 필요한 기능과 Knowledge를 선택하는 구조로 바꾼 것입니다.

이 구조를 통해 EVA는 매뉴얼을 독립적인 Knowledge 소스로 관리하고, Registry에 Tool을 추가하는 방식으로 기능을 확장할 수 있게 되었습니다. 동시에 Tool Schema, Action 안전성, 검색 품질, 문서 버전 관리, End-to-end 평가가 안정적인 Agent 운영을 위한 핵심 요소가 되었습니다.

이때 중요한 것은 단순히 모든 프레임이 처리되었는지를 확인하는 것만이 아닙니다. 어느 처리 단계에 리소스가 집중되고 있는지, 반대로 활용되지 못하고 있는 리소스는 어디에 있는지, 특정 카메라나 Connection에 처리가 편중되고 있는지를 파악해야 합니다.

EVA Scope는 EVA에서 생성되는 Frame Journey 데이터를 바탕으로 AI 파이프라인 전체의 처리 흐름을 관측합니다. 이를 통해 병목, 지연, 유휴, 처리 편차를 종합적으로 분석하고, 제한된 운영 환경에서 EVA가 더 안정적이고 효율적으로 동작할 수 있도록 개선 방향을 판단하는 데 필요한 근거를 제공합니다.

이번 글에서는 대규모 CCTV AI 운영 환경에서 프레임 처리 상태를 관측하기 위해 설계한 EVA Scope의 구조와 주요 기능을 소개합니다.

1. EVA Scope 한눈에 보기​

수많은 Connection의 상태와 Risk Score를 한 화면에서 확인하고, 문제가 있는 대상을 우선적으로 분석할 수 있습니다.

Connections List에서는 다음과 같은 정보를 Connection 단위로 확인할 수 있습니다.

• Connection별 정상·주의·경고 상태
• 최신 Risk Score
• Bottleneck·Idle·Imbalance·Error 지수
• 최근 시간대별 상태 추이
• 전체 프레임 처리량
• 마지막 데이터 수집 상태
• EVA App 연결 상태
• 활성화된 Alert 수

운영자는 모든 Connection을 순서대로 확인할 필요가 없습니다. 위험도가 높은 Connection을 먼저 확인하고, 해당 Connection의 상태가 언제부터 변화했는지 확인한 뒤, 상세 분석 화면으로 이동할 수 있습니다.

2. Signal-to-Insight Flow​

EVA Scope의 핵심은 그저 데이터를 많이 보여주는 것이 아닙니다. 대규모 프레임 데이터 속에서 처리 효율에 영향을 주는 신호를 찾고, 이를 Connection·카메라·처리 단계·개별 프레임 수준의 분석으로 연결하는 것입니다.

Connections List​

먼저 전체 Connections(EVA App) 목록과 상태를 확인합니다. EVA Scope는 네 가지 세부 Index로 처리 효율에 영향을 주는 요인을 설명하고, Risk Score로 Connection 단위의 우선순위를 결정합니다.

운영자는 다음과 같은 정보를 확인할 수 있습니다.

• 어떤 Connection의 Risk Score가 높은가?
• 최근 처리 효율은 개선되고 있는가, 저하되고 있는가?
• 특정 시간대에 처리량이나 지연 시간이 변화했는가?
• 특정 Connection의 데이터 수집 상태는 안정적인가?

Alert History​

핵심 지표가 설정된 기준을 벗어나거나, 수집 상태에 대한 추가 확인이 필요한 경우 Alert History에 기록됩니다. Alert History에는 문제가 발생한 시간대와 Connection, 상태, Risk Score가 표시됩니다.

Hourly Overview​

문제가 발생한 Connection을 선택합니다. 시작 시간과 종료 시간을 설정하여 해당 시간대에 유입된 Image Frame을 분석할 수 있으며, 해당 시간 동안 프레임의 종료 상태와 상태 추이, 처리 시간 및 주요 지표의 변화 등을 확인해 문제를 파악할 수 있습니다. 보존 기간(7일) 내에서 과거 구간에 대한 분석도 가능합니다.

Index Analysis​

EVA Scope는 처리 효율을 구성하는 네 가지 Index를 제공합니다. 각 Index의 변화와 세부 구성 요소를 함께 보여주기 때문에, 단순히 지표가 높다는 사실을 넘어 어떤 요인이 영향을 주었는지 확인할 수 있습니다.

• Bottleneck Index: 처리 지연과 Queue 대기
• Idle Index: Vision·Agent 및 프레임 유입 구간의 유휴 수준
• Imbalance Index: 카메라별 처리 편차
• Error Index: 오류 프레임 비율

이 흐름을 통해 운영자는 Alert를 확인하는 데서 멈추지 않고, 처리 효율을 높이기 위해 어떤 단계와 리소스를 우선적으로 조정해야 하는지 판단할 수 있습니다. EVA Scope가 스스로 개선안을 결정하는 것은 아닙니다. 대신 리소스 재배치, Queue 정책 조정, 카메라별 처리 정책 검토, 추론 환경 개선과 같은 후속 조치를 판단할 수 있는 근거를 제공합니다.

3. 대규모 CCTV 운영 환경에서 왜 Observability가 필요한가?​

소규모 환경에서는 몇 대의 카메라와 하나의 EVA App만 확인해도 시스템 상태를 어느 정도 파악할 수 있습니다.

하지만 운영 규모가 커지면 다음과 같은 문제가 발생합니다.

• 수십 개 EVA App의 상태를 각각 확인해야 함
• 수백~수천 대 카메라의 프레임 처리 상태가 분산되어 있음
• 최종 Drop 결과만으로는 장애 발생 단계를 알기 어려움
• 문제 발생 시간대와 원본 프레임을 연결하기 어려움
• 사용자가 문제를 인지한 뒤 직접 데이터를 찾아야 함

특히 이미지 프레임 처리 파이프라인은 단순한 요청-응답 구조가 아닙니다.

하나의 프레임이 여러 비동기 처리 단계를 통과하며, 일부 프레임은 처리 과정 중 Drop되거나 다른 상태로 종료되기도 합니다. 따라서 UI로 확인 가능한 알림만으로는 EVA가 최적의 상태인지 파악하기가 어렵습니다.

Frame Ingest
    ↓
Frame Queue
    ↓
Vision Inference
    ↓
Agent Queue
    ↓
Agent Inference
    ↓
Finished / Dropped / Error

EVA의 동작이 최적 상태인지를 확인하기 위해서는 프레임이 어떤 경로를 거쳤고, 각 단계에서 얼마나 시간을 소비했는지 확인해야 합니다.

EVA Scope는 다음 세 가지 정보를 함께 사용합니다.

1. 프레임의 최종 상태
2. 각 처리 단계의 타임스탬프
3. Connection·카메라·시간대별 처리 맥락

이를 통해 단순히 “비효율이 발생했다”가 아니라 다음과 같은 질문에 답할 수 있습니다.

• 어느 EVA App에서 병목이 발생했는가?
• 어느 시간대부터 부하가 시작되었는가?
• 병목은 Vision인가, Agent인가, Queue인가?
• 특정 카메라에만 문제가 집중되었는가?
• 현재도 병목이 지속되고 있는가?
• 조치 이후 실제로 처리 효율이 변화하였는가?

4. EVA Scope Core Intelligence​

EVA Scope Core Intelligence는 대량의 프레임 데이터를 수집하고, 집계하고, 운영 가능한 신호로 변환하는 핵심 기술 영역입니다.

4.1 전체 아키텍처​

EVA Scope는 EVA App의 Image Frame Journey 데이터를 수집해 데이터베이스에 저장하고, 이를 대시보드에서 분석합니다. EVA Scope에서 Journey란 하나의 이미지 프레임이 Ingest부터 Queue, Vision, Agent를 거쳐 최종 상태에 도달하기까지의 처리 과정을 의미합니다.

수십 개의 EVA App
        ↓
수백~수천 대의 Camera
        ↓
EVA App stats-dump(JSONL)
        ↓
FastAPI Backend
        ↓
Streaming Parser
        ↓
Hourly Rollup Accumulator
        ↓
ClickHouse
    ├─ Raw Frame Data
    ├─ Hourly Health Rollup
    ├─ Ingestion Ledger
    └─ Alerts
        ↓
Next.js Dashboard
    ├─ Connections List
    ├─ Alert History
    └─ Detailed Analysis

현재 설계는 Connection당 시간당 약 50MB의 dump 파일과 최대 100개 Connection 규모를 고려합니다. 이 정도 규모에서는 모든 Raw 데이터를 매번 조회하는 방식보다, 운영 관제용 데이터와 상세 분석용 데이터를 분리하는 것이 중요합니다.

4.2 Raw와 Rollup: 대규모 데이터 수집과 저장 전략​

대규모 환경에서 모든 프레임 Raw 데이터를 항상 저장하고 조회하면 저장 공간과 조회 비용이 빠르게 증가합니다. EVA Scope는 수집 과정에서 데이터를 스트리밍 방식으로 처리하면서 Raw 데이터와 Rollup 데이터를 분리합니다. rollup_only 정책에서는 스트림을 소비하면서 시간 단위 집계만 생성하고, Raw 프레임은 저장하지 않습니다. 반대로 full 정책에서는 동일한 스트림을 Rollup 집계와 Raw batch insert에 함께 사용합니다.

스트리밍 기반 데이터 처리​

EVA App의 통계 데이터는 JSONL 형식으로 제공됩니다. EVA Scope는 dump 파일 전체를 데이터베이스에 저장하거나 메모리에 올리지 않고 라인 단위로 읽으면서 필요한 정보만을 집계합니다.

• 상태별 프레임 수
• 카메라별 프레임 수와 Drop 수
• End-to-End 지연 시간
• Vision·Agent 추론 시간
• Queue 대기 비율
• 각 처리 단계의 실제 사용 시간

이 방식은 dump 파일 전체 크기에 비례해 메모리가 증가하는 것을 방지합니다.

Rollup 데이터​

Rollup은 Connection과 시간 버킷 단위로 집계한 운영 데이터입니다. Rollup 데이터는 스트리밍 기반 데이터 처리를 통해 집계한 데이터를 바탕으로 필요한 정보만 가공하여 제공합니다.

• 전체 프레임 수
• Finished·Filtered·Dropped·Error 수
• End-to-End P50/P95 지연시간
• 카메라별 프레임 및 Drop 수
• Bottleneck·Idle·Imbalance 지수
• Risk Score

Connections List와 Alert 탐지는 Rollup 데이터를 사용합니다. 따라서 수천 대의 카메라 데이터를 매번 Raw 수준으로 전체 스캔하지 않아도 전체 운영 상태를 빠르게 확인할 수 있습니다.

Raw 데이터​

Raw 데이터는 개별 프레임의 상세 분석에 사용됩니다. EVA Scope는 모든 Raw 데이터를 수집하지 않고, 운영자가 분석하고자 하는 Connection과 시간대에 대해서만 Raw 데이터를 수집·저장합니다.

• 특정 카메라의 오류 프레임 확인
• 개별 프레임의 처리 과정 추적
• Vision·Agent 처리 시간 확인
• 특정 시간대 상세 분석

Connection별 저장 정책도 제공합니다.

기본 정책에서는 Rollup을 중심으로 운영하고, 사용자가 상세 분석을 요청한 경우 필요한 시간대의 Raw 데이터를 다시 수집할 수 있습니다. 즉, EVA Scope는 모든 데이터를 같은 방식으로 저장하지 않습니다. 운영에 필요한 데이터는 가볍게 집계해 빠르게 조회하고, 원인 분석에 필요한 데이터는 필요할 때 상세하게 확인할 수 있도록 분리합니다. 이러한 Rollup 정책을 바탕으로 모든 Connections에 대한 관제 기능은 유지하면서, 저장 공간은 99%를 절감할 수 있습니다.

4.3 핵심 지표 설계​

EVA Scope는 다양한 지표를 사용해 대규모 운영 환경에서의 서비스 운영 효율성과 효과성을 진단합니다.

마치며​

대규모 CCTV AI 환경의 진짜 어려움은 ‘인프라 부족’보다 ‘AI 시스템 내부 동작의 불투명성’에 있습니다. 수천 대의 카메라에서 쏟아지는 프레임 속에서 어디에 병목이 생겼는지, 어느 리소스가 놀고 있는지 모른다면 GPU 서버를 증설해도 문제는 해결되지 않습니다. 기존에는 운영 중인 수많은 EVA 중 개선이 필요한 EVA를 식별하기조차 어려웠고, 설령 찾아내더라도 시스템의 로그를 분석하는 등 수십 분, 수백 분의 시간이 필요했습니다. EVA Scope는 이러한 과정을 획기적으로 줄여 직관적인 신호로 전환합니다. 이미지 프레임의 유입부터 마지막 Agent의 추론까지 전체 여정을 투명하게 시각화함으로써, 운영자는 명확한 데이터를 바탕으로 AI 시스템의 구성과 설정을 최적화할 수 있습니다.

단순히 ‘서버가 살아있는가’를 확인하는 모니터링을 넘어, 나아가 ‘어디에 장애가 발생했는가’를 확인하는 관제 시스템을 넘어, 제한된 시스템 리소스 안에서 EVA가 안정적이고 효율적으로 동작할 수 있도록, 어디를 관찰하고 무엇을 개선해야 하는지 판단할 수 있게 해주는 것.

이것이 대규모 CCTV AI 운영 환경에서 EVA Scope가 제공하고자 하는 가치입니다.

카메라와 사업장이 늘어나면 알람의 양도 함께 늘어납니다. 오탐이 쌓이면 현장은 알람을 믿지 않게 되고, 카메라가 정상 연결되어 있는지 확인하는 단순한 시스템 모니터링만으로는 탐지 품질을 개선하기 어렵습니다. 운영자는 어떤 카메라와 시나리오에 문제가 있는지, 수정한 설정이 실제로 효과가 있었는지까지 확인할 수 있어야 합니다.

EVAmentor는 EVA의 판단과 사용자 피드백을 바탕으로 성능을 측정하고, 문제를 진단하고, 개선 방향을 찾고, 개선 결과까지 검증하는 운영 솔루션입니다. 단순히 시스템 상태를 알려주는 모니터링에 머무르지 않고, 오탐 원인을 확인해 어떤 피드백과 설정을 적용할지 함께 살펴보는 멘토링을 제공합니다. 시스템을 지켜보는 것을 넘어 탐지 품질을 지속적으로 다듬도록 돕는 것이 EVAmentor의 역할입니다.

1. EVAmentor 한눈에 보기​

EVAmentor는 문제 발견 → 원인 진단 → 개선 → 검증의 운영 사이클을 하나의 화면 흐름으로 연결합니다. 운영자는 흩어져 있던 알람, 피드백, 설정 변경 이력을 같은 기준으로 살펴보면서 "무엇을 먼저 확인하고 어떻게 개선할지"를 결정할 수 있습니다.

개요 - 현장의 탐지 상태를 읽는 첫 화면​

사이트별로 카메라 수, 알람 부하, 알람 정확도, 피드백 효과율과 최근 알람을 한눈에 확인합니다. 단순히 알람 건수를 보여주는 것이 아니라, 발생한 알람 중 실제 위험으로 판단된 비율과 사용자 피드백이 오탐 감소에 기여한 정도를 함께 보여줍니다. 운영자는 현재 현장의 탐지 품질과 우선적으로 살펴볼 문제를 빠르게 파악할 수 있습니다.

조치 필요 - 무엇부터 볼지 정하기​

수십~수백 대의 카메라와 시나리오를 모두 직접 확인하는 대신, 최근 데이터와 검토 이력을 기준으로 상태를 자동 분류합니다. 이를 통해 운영자는 전체 목록을 처음부터 훑지 않고, 데이터가 끊겼거나 오탐이 집중된 대상처럼 즉시 조치가 필요한 항목부터 확인할 수 있습니다.

정확도 분석 ① - 성능의 흐름과 원인 보기​

알람 정확도와 피드백 효과율을 산출식과 함께 보여주고, 시나리오·카메라별 상세 지표로 내려갈 수 있습니다. 숫자만 비교하는 것이 아니라 어떤 알람과 검토 결과가 지표를 만들었는지 확인할 수 있어, 시나리오를 유지하거나 제거하는 판단에도 근거를 제공합니다.

변경 이벤트 영향 분석에서는 정확도 추이 위에 시나리오 수정이나 모델 교체 시점을 표시합니다. 그래서 운영자는 성능 변화와 설정 변경의 관계를 기억이나 추측이 아니라 기록으로 확인할 수 있습니다.

• 정확도가 언제 변했는가
• 그 시점에 무엇을 수정했는가
• 수정 후 실제로 효과가 있었는가

정확도 분석 ② - 탐지 설정을 데이터로 비교하기​

VLM 판단뿐 아니라 앞단의 객체와 threshold 설정도 알람의 양과 질을 좌우합니다. 예를 들어 안전모 미착용을 person 객체로 탐지할지 bare head 객체로 탐지할지에 따라 같은 시나리오의 결과가 달라질 수 있습니다. 기준 설정과 비교 설정의 정확도·알람 수를 나란히 비교해, 어느 카메라의 설정을 먼저 바꿀지 데이터로 결정할 수 있습니다.

피드백 분석 - 피드백 루프 점검하기​

EVA는 사용자 피드백을 바탕으로 유사한 오탐 알람을 억제합니다. EVAmentor에서는 이 필터가 올바르게 작동하는지 다음 항목으로 확인합니다.

• 실제 오탐을 제대로 필터링했는가
• 실제 위험을 잘못 필터링하지 않았는가
• 어떤 참조 이미지가 판단에 크게 기여했는가

각 이벤트에는 참조 이미지와 유사도 점수가 남아 필터링 이유도 확인할 수 있습니다. 잘못 필터링된 위험 사례를 빠르게 찾아 피드백을 정리하거나, 특정 참조 이미지가 과도한 필터링을 만들고 있는지 점검할 수 있습니다.

A/B 테스트 - 오탐 재발을 기다리지 않기​

시나리오를 수정한 뒤 현장에서 같은 상황이 다시 발생하기를 기다릴 필요가 없습니다. 과거의 오탐 이미지를 사용해 수정안을 바로 검증하고, 드물게 발생하는 오탐도 짧은 시간 안에 재현해 볼 수 있습니다.

1. 과거 오탐 이미지를 기존 시나리오로 재판정합니다.
2. AI 초안 또는 직접 수정으로 시나리오를 개선합니다.
3. 같은 이미지에 수정안을 적용해 결과를 비교합니다.

수정안이 오탐은 줄이고 기존 정탐은 유지하는지 배포 전에 확인할 수 있습니다. 즉, 현장에 적용한 뒤 문제가 드러나는 방식에서 벗어나 적용 전에 부작용을 확인하는 방식으로 운영 순서를 바꿀 수 있습니다.

이미지 갤러리 - 검토를 실제 개선으로 연결하기​

알람과 필터링된 이벤트를 한곳에서 확인하고 정탐·오탐을 레이블링합니다. 아직 검토하지 않은 건을 이미지로 비교하며 개별 또는 조건별로 일괄 처리할 수 있습니다. 등록한 레이블은 EVAmentor 안에만 남는 것이 아니라 EVA App의 분석 결과에도 반영되어 다음 탐지의 근거가 됩니다.

2. EVAmentor가 만드는 가치​

수백 대 카메라의 성능을 관리할 수 있습니다​

모든 알람을 하나씩 확인하는 대신, 사이트·카메라·시나리오별 성능을 자동 집계하고 조치 우선순위를 제시합니다. 카메라가 늘어나도 운영자는 같은 기준으로 중요한 문제부터 확인할 수 있습니다. 운영자의 일과가 알람을 무작정 열어보는 일에서, 조치 필요 목록의 상위 항목을 검토하는 일로 바뀌는 이유입니다.

보이지 않던 문제를 드러냅니다​

잘못된 피드백 필터, 검토 공백, 데이터가 끊긴 카메라, 현장과 맞지 않게 된 시나리오를 상태와 지표로 표시합니다. 특히 알람은 계속 발생하지만 아무도 검토하지 않는 사각지대나, 실제 위험까지 필터링하는 부작용처럼 눈에 잘 띄지 않는 문제를 드러냅니다. 모든 지표의 산출 근거를 함께 보여주기 때문에 운영 판단을 설명할 수 있습니다.

검토 부담은 줄고, 데이터는 운영 자산이 됩니다​

이미지를 보며 바로 레이블링하고, 필요한 건은 일괄 처리할 수 있습니다. 무엇부터 검토할지 상태별 우선순위가 제시되므로 같은 시간에도 더 중요한 이벤트를 먼저 처리할 수 있습니다. 이렇게 쌓인 검토 이력은 시나리오 수정 전후의 성능을 비교하고 장기 추세를 확인하는 운영 자산이 됩니다.

개선은 감이 아니라 검증으로 이루어집니다​

과거 오탐 이미지, 객체·threshold 비교, AI 시나리오 초안, 변경 이벤트 분석을 통해 수정 전부터 적용 후까지 효과를 확인합니다. 경험과 감에 의존해 설정을 바꾸고 현장 알람을 기다리던 과정을, 데이터를 기반으로 수정하고 즉시 검증하는 과정으로 바꿉니다.

사람의 판단이 시스템을 다시 똑똑하게 만듭니다​

EVAmentor의 레이블과 검토 결과는 EVA App의 다음 판단에 반영됩니다. 그 효과를 다시 측정하면서 측정 → 진단 → 개선 → 반영 → 재측정의 선순환이 만들어집니다. 이 루프가 반복될수록 현장에 맞지 않는 판단은 줄고, 운영자가 알람을 신뢰할 수 있는 기반은 커집니다.

3. 마치며​

EVA가 현장을 지켜보는 시스템이라면, EVAmentor는 EVA를 지켜보며 더 정확하게 만드는 시스템입니다.

탐지 결과 · 피드백 수집
    ↓
성능 지표 집계
    ↓
조치 필요 대상 자동 분류
    ↓
근거 이미지 검토 · 정탐/오탐 확정
    ↓
A/B 테스트 · 탐지 설정 비교
    ↓
개선 효과 재측정

탐지 품질은 한 번의 튜닝이 아니라 이 루프를 꾸준히 운영할 때 만들어집니다.

EVA는 모델 최적화나 애플리케이션 레벨의 스케줄링에만 의존하지 않습니다. 서버에 장착된 GPU 개수, GPU별 메모리 용량, MIG 분할 가능 여부, MPS 적용 효과, Vision Worker와 vLLM 인스턴스의 배치 구조까지 함께 고려해 환경별 최적 구성으로 배포합니다.

즉, EVA는 AI 모델을 실행하는 서비스에 그치지 않고, HW 단계의 GPU 구성과 Serving Framework의 동작 방식까지 고려하여 시스템 자원을 최대한 효율적으로 활용합니다. 이를 통해 제한된 서버 자원에서도 다수의 카메라 요청을 안정적으로 처리할 수 있도록 구성합니다.

이번 글에서는 실제 EVA 실험 데이터를 기반으로 다음 세 가지 관점에서 MIG/MPS 적용 효과를 비교합니다.

• 다중 GPU 서버(PRO 5000 x3)에서 MIG 적용 효과
• 단일 GPU 서버(PRO 6000 x1)에서 MIG 적용 효과
• Vision Worker가 많은 환경에서 MPS 적용 효과

이를 통해 MIG와 MPS를 무조건 적용하는 것이 아니라, 서버 구성과 워크로드 특성에 따라 어떤 조합이 EVA 운영에 가장 적합한지 판단할 수 있는 기준을 제시합니다.

• MIG(Multi-Instance GPU): 하나의 물리 GPU를 여러 개의 독립 GPU 인스턴스로 분할하는 기능입니다. Vision과 vLLM을 서로 다른 인스턴스에 배치해 자원 경합을 줄일 수 있습니다.
• MPS(Multi-Process Service): 여러 CUDA 프로세스 요청을 하나의 서버 프로세스가 받아 GPU 실행을 조정하는 기능입니다. 다중 프로세스 환경에서 컨텍스트 전환 오버헤드를 완화할 수 있습니다.

1. EVA 추론 구조​

EVA 서버에서는 크게 두 계층의 추론 파이프라인이 동시에 동작합니다.

• Vision: RT-DETRV2, Owl-v2, OmDet, LLMDet 등 다양한 객체 탐지 모델을 여러 Worker 프로세스로 병렬 처리
• vLLM(VLM Serving): Agent 요청을 받아 사용자가 작성한 시나리오를 여러 Task로 분해하고, 단계별 추론을 통해 해당 상황인지 판단

EVA의 추론 구조에서 중요한 점은 Vision과 vLLM의 GPU 사용 패턴이 서로 다르다는 것입니다.

카메라가 많이 사용하는 모델일수록 해당 모델에 더 많은 Worker를 배정해 모델별 추론 요청을 병렬로 처리합니다. 반면 vLLM은 continuous batching을 통해 여러 요청을 한 번에 처리하므로, 단순히 인스턴스 수를 늘린다고 항상 처리량이 증가하지는 않습니다.

따라서 EVA에서는 서버 구성과 워크로드 특성에 따라 MIG와 MPS 적용 여부를 다르게 판단해야 합니다.

2. 실험 환경​

2.1 서버 구성​

이번 실험은 다음 두 가지 GPU 서버 구성을 기준으로 진행했습니다.

2.2 서비스 배치​

EVA는 Vision과 vLLM의 GPU 사용 패턴이 다르기 때문에, 두 워크로드를 어떤 GPU 또는 MIG 인스턴스에 배치하는지가 중요합니다.

기본적으로 Vision은 객체 탐지 요청을 처리하는 영역으로 구성하고, vLLM은 Agent의 VLM 기반 판단 요청을 처리하는 영역으로 구성합니다. MIG를 적용하는 경우에는 Vision이 사용하는 GPU 또는 MIG 슬라이스를 제외한 나머지 GPU 자원에 vLLM 인스턴스를 각각 하나씩 구성합니다.

예를 들어 PRO 5000 x3 서버에서 MIG를 적용하면 총 6개의 24GB MIG 슬라이스가 생성됩니다. 이 중 1개 슬라이스는 Vision에 할당하고, 나머지 5개 슬라이스에는 vLLM 인스턴스를 각각 1개씩 배치합니다. PRO 6000 x1 서버에서도 동일하게 4개의 24GB MIG 슬라이스 중 1개는 Vision, 나머지 3개는 vLLM 인스턴스로 구성합니다.

이 구성은 Vision과 vLLM을 최대한 분리하여 자원 경합을 줄이고, vLLM 인스턴스를 남은 GPU 자원에 고르게 배치했을 때 MIG가 실제 처리량 개선으로 이어지는지를 확인하기 위한 실험입니다.

3. 지표 정의​

이번 글에서는 Vision과 Agent 처리량을 다음 기준으로 비교했습니다.

환산식은 다음과 같습니다.

• Vision req/s = 1시간 누적 Vision 처리 건수 / 3600
• Agent req/min = 1시간 누적 VLM responses / 60

4. PRO 5000 x3 환경에서 MIG 적용 효과​

4.1 실측 결과​

PRO 5000 x3 환경에서는 다음 조건을 기준으로 MIG 적용 구성의 성능 변화를 측정했습니다.

• 테스트 시나리오: 단일 시나리오
• Vision 모델 구성: 단일 Vision 모델

따라서 아래 결과는 PRO 6000 x1 환경과 직접 비교하기보다는, PRO 5000 x3 동일 조건 내에서 MIG 적용 구성 전후의 변화로 해석하는 것이 적절합니다.

4.2 해석​

다중 GPU 환경인 PRO 5000 x3 구성에서는 MIG로 vLLM 인스턴스를 늘려도 vLLM 처리량 개선 효과가 크지 않았습니다.

이미 vLLM이 continuous batching을 통해 동시 요청을 효율적으로 처리하고 있었기 때문에, 인스턴스 수 증가가 곧바로 처리량 향상으로 이어지지 않았습니다. 또한 MIG 분할로 인한 인스턴스별 가용 자원 축소와 전체 워크로드 배치 변화가 함께 작용하면서 Vision 처리량은 감소하는 경향을 보였습니다.

운영 관점에서는 MIG 적용 시 다음 요소를 함께 고려해야 합니다.

• MIG 분할 정책 관리
• 인스턴스별 모니터링
• 장애 발생 시 재배치 및 복구 절차
• 워크로드별 인스턴스 크기 조정

따라서 PRO 5000 x3와 같은 다중 GPU 환경에서는 기본적으로 MIG 미적용 구성을 우선 검토하고, Vision과 vLLM 간 자원 충돌이 명확하게 확인되는 경우에만 MIG 적용을 고려하는 것이 적절합니다.

5. PRO 6000 x1 환경에서 MIG 적용 효과​

5.1 실측 결과​

PRO 6000 x1 환경에서는 다음 조건을 기준으로 MIG 적용 구성의 성능 변화를 측정했습니다.

• 테스트 시나리오: 2개 이상의 복합 시나리오
• Vision 모델 구성: 다양한 Vision 모델

따라서 아래 결과는 PRO 5000 x3 환경과 직접 비교하기보다는, PRO 6000 x1 동일 조건 내에서 MIG 적용 구성 전후의 변화로 해석하는 것이 적절합니다.

5.2 해석​

단일 GPU 환경인 PRO 6000 x1 구성에서는 MIG 적용 효과가 명확하게 나타났습니다.

MIG 미적용 상태에서는 Vision Worker와 vLLM이 하나의 물리 GPU를 공유합니다. 이 경우 Vision의 다수 Worker가 짧은 추론 요청을 반복적으로 발생시키고, vLLM은 비교적 큰 단위의 추론을 처리하기 때문에 GPU 점유권 전환이 자주 발생할 수 있습니다.

MIG를 적용해 Vision과 vLLM이 사용하는 GPU 자원을 하드웨어 레벨의 독립 인스턴스로 격리하면, 워크로드 간 자원 경합을 줄이고 각 추론 파이프라인을 더 안정적으로 실행할 수 있습니다.

이 결과를 보면 단일 GPU에서 Vision과 vLLM을 함께 운영해야 하는 고밀도 환경에서는 MIG가 효과적인 선택이 될 수 있습니다. 특히 Vision과 vLLM의 GPU 사용 패턴이 크게 다를수록, MIG를 통한 하드웨어 레벨 격리 효과가 더 크게 나타납니다.

6. Vision Worker가 많은 환경에서 MPS 적용 효과​

Vision 모델은 여러 Worker 프로세스가 동시에 GPU에 요청을 보내는 구조로 동작합니다. 이때 Worker 수가 많아지면 프로세스 간 GPU 점유 전환이 빈번해질 수 있습니다.

MPS를 적용하면 여러 CUDA 프로세스 요청을 하나의 MPS 서버가 조정하여 처리하므로, 다중 프로세스 환경에서 컨텍스트 전환 오버헤드를 줄이고 GPU 활용률을 높일 수 있습니다.

이번 실험에서는 PRO 5000 환경에서 MIG를 적용하지 않은 상태로 MPS 효과를 비교했습니다.

MPS 적용 결과, Vision 전체 처리량은 23.770 req/s에서 25.980 req/s로 약 9.3% 증가했습니다.

모델별로 보면 Owl-v2의 처리량 증가폭이 가장 컸고, RT-DETRV2, OmDet, LLMDet도 소폭 개선되었습니다. 이는 Vision Worker가 많은 환경에서 MPS가 다중 프로세스 요청을 보다 안정적으로 조정하는 데 도움이 될 수 있음을 보여줍니다.

7. 최종 결론​

이번 실험을 통해 MIG와 MPS는 모든 환경에 동일하게 적용하는 기능이 아니라, GPU 구성과 워크로드 특성에 따라 선택적으로 적용해야 한다는 점을 확인했습니다.

7.1 다중 GPU 서버(PRO 5000 x3)​

PRO 5000 x3처럼 물리 GPU가 여러 개인 환경에서는 Vision과 vLLM을 GPU 단위로 분리할 수 있습니다. 이 경우 MIG를 추가로 적용해 vLLM 인스턴스를 늘리더라도 처리량 개선 효과는 제한적이었습니다.

• vLLM은 이미 continuous batching으로 동시 요청을 효율적으로 처리
• 인스턴스 수 증가가 처리량 향상으로 바로 이어지지 않음
• MIG 분할 시 운영 복잡도와 자원 단편화 가능성 증가
• 기본 구성은 MIG 미적용을 우선 권장

7.2 단일 GPU 서버(PRO 6000 x1)​

PRO 6000 x1처럼 하나의 물리 GPU에서 Vision과 vLLM을 함께 운영해야 하는 환경에서는 MIG 적용 효과가 컸습니다.

• Vision과 vLLM의 GPU 사용 패턴이 다름
• 단일 GPU 공유 시 컨텍스트 스위칭 비용이 커질 수 있음
• MIG 적용 시 워크로드 간 자원 경합 완화
• 단일 GPU 고밀도 구성에서는 MIG 우선 검토 권장

7.3 Vision Worker가 많은 환경​

Vision Worker가 많은 환경에서는 MPS 적용이 효과적일 수 있습니다.

• 다수 Worker가 동시에 GPU 요청을 발생
• 프로세스별 GPU 점유 전환 비용 증가 가능
• MPS 적용 시 Vision 전체 처리량 약 9.3% 증가
• Vision 중심 서버에서는 MPS 적용을 기본 옵션으로 검토

8. 운영 권장안​

정리하면, EVA에서는 MIG와 MPS를 단순히 “켜는 기능”으로 보지 않습니다. 서버 구성, Vision/VLM 배치, Worker 수, vLLM 처리 방식, 운영 복잡도를 함께 고려해 환경별 최적 구성을 선택합니다.

9. 참고 자료​

이번 분석 글의 프레임을 정리할 때 아래 자료의 관점을 참고했습니다.

• NVIDIA 기술 블로그: Getting the Most Out of the NVIDIA A100 GPU with Multi-Instance GPU https://developer.nvidia.com/blog/getting-the-most-out-of-the-a100-gpu-with-multi-instance-gpu/
• NVIDIA 기술 블로그: Boost GPU Memory Performance with No Code Changes Using NVIDIA CUDA MPS https://developer.nvidia.com/blog/boost-gpu-memory-performance-with-no-code-changes-using-nvidia-cuda-mps/
• NVIDIA 공식 문서: Multi-Process Service (MPS) https://docs.nvidia.com/deploy/mps/latest/index.html
• vLLM 공식 블로그 https://vllm.ai/blog
• Anyscale 기술 블로그: Continuous Batching 기반 vLLM 처리량 분석 https://www.anyscale.com/blog/continuous-batching-llm-inference

대규모 카메라 환경에서는 단순히 더 높은 성능의 GPU를 사용하는 것만으로는 충분하지 않습니다. 모든 카메라의 스트리밍을 안정적으로 유지해야 하고, 여러 카메라에서 동시에 발생하는 AI 추론 요청을 제한된 CPU, 메모리, 네트워크, GPU 자원 안에서 처리해야 합니다.

특히 AI 파이프라인이 특정 카메라나 특정 모델에 치우치면 일부 카메라는 정상적으로 분석되지 못하거나, 이벤트 발생 후 알람까지의 지연 시간이 증가할 수 있습니다. 따라서 EVA는 영상 수집부터 AI 추론, 스트리밍 송출까지 전체 파이프라인을 기준으로 인프라를 최적화하고 있습니다.

이번 글에서는 EVA가 대규모 카메라 환경을 안정적으로 수용하기 위해 적용한 주요 인프라 최적화 기술을 소개합니다.

1. VM·VLM 분리 아키텍처​

EVA는 모든 영상을 고비용 VLM으로 분석하지 않습니다. 먼저 VM(Vision Model)이 객체 존재 여부와 기본 조건을 확인하고, 실제 판단이 필요한 경우에만 VLM(Vision Language Model)을 수행합니다.

예를 들어 보호구 미착용 탐지의 경우, 사람이 존재하지 않거나 탐지 대상과 관련 없는 프레임은 초기 단계에서 제외됩니다. 실제로 사람이 확인되고 보호구 착용 여부 판단이 필요한 경우에만 후속 VLM 추론을 수행합니다.

초기 구조에서는 모든 프레임을 VLM 중심으로 처리했기 때문에 GPU 연산량이 빠르게 증가했습니다. 반면 현재 구조는 VM이 먼저 판단 대상을 선별함으로써 VLM 호출 횟수를 크게 줄입니다.

이 구조를 통해 EVA는 동일 서버 환경에서 수용 가능한 카메라 수를 약 20대 수준에서 최대 100대 수준까지 향상시켰습니다. 해당 수치는 동일 서버 환경에서 모든 프레임을 VLM 중심으로 처리하던 초기 구조와, VM 기반 선별 후 필요한 경우에만 VLM을 수행하는 현재 구조를 비교한 내부 검증 기준입니다.

2. 작업 분해 및 GPU 병렬 처리​

EVA는 여러 카메라에서 동시에 발생하는 추론 요청을 하나의 큰 작업으로 처리하지 않습니다. 대신 탐지 단계 판단, 예외 상황 검사, 이미지 설명 생성, 벡터화 등 여러 개의 작은 작업으로 분해하여 수행합니다.

분해된 작업은 여러 추론 인스턴스에 분산·병렬 처리됩니다. 이를 통해 다수의 카메라에서 동시에 요청이 발생하더라도 특정 작업이 전체 파이프라인을 막지 않도록 설계했습니다.

이 방식의 핵심은 불필요한 추론을 조기에 종료하는 것입니다. 초기 단계에서 알람 조건에 해당하지 않는다고 판단되면 후속 VLM 호출이나 이미지 설명 생성, 벡터화 작업을 수행하지 않습니다.

그 결과 GPU 자원을 실제 판단이 필요한 작업에 집중할 수 있었고, 실제 운영 환경에서 시간당 시나리오 처리량을 360건에서 1,192건으로 3배 이상 향상시켰습니다.

3. 탐지 모드 기반 추론 최적화​

모든 시나리오를 동일한 방식으로 처리하면 불필요한 GPU 사용량이 증가합니다. EVA는 사용자가 작성한 시나리오의 특성을 분석하여 가장 적합한 탐지 방식을 자동으로 선택합니다.

단순 객체 존재 여부만 확인하면 되는 시나리오는 VM 중심으로 처리하고, 복합적인 상황 판단이 필요한 경우에만 VLM 기반 추론을 수행합니다.

예를 들어 “사람이 보이면 알려줘”와 같은 시나리오는 고비용 VLM을 사용할 필요가 없으므로 VM만으로 처리할 수 있습니다. 반면 “작업자가 안전모를 착용하지 않고 위험구역에 진입”과 같은 시나리오는 객체 존재 여부뿐 아니라 보호구 착용 여부와 공간적 맥락까지 함께 판단해야 하므로 추가적인 추론 단계가 필요합니다.

이처럼 EVA는 시나리오 특성에 따라 필요한 수준의 모델만 사용함으로써 GPU 사용량을 줄이면서도 탐지 성능을 유지합니다.

4. 모델별 Worker 동적 할당​

EVA는 사용 중인 모델과 카메라 수에 따라 Worker를 동적으로 할당합니다.

예를 들어 특정 시점에 OMDet을 사용하는 카메라가 많다면 해당 모델에 더 많은 Worker를 배정하고, 사용량이 적은 모델은 최소 자원만 사용하도록 조정합니다. 이를 통해 GPU 자원이 특정 모델에 과도하게 집중되는 것을 방지하고, 전체 GPU 활용률을 안정적으로 유지할 수 있습니다.

Worker를 고정적으로 배치하면 실제 사용량과 무관하게 특정 모델이 자원을 점유하거나, 반대로 요청이 많은 모델의 처리량이 부족해질 수 있습니다.

EVA는 모델별 요청량을 기준으로 Worker를 조정하여 처리 지연으로 인해 AI 추론 대상 프레임이 누락되는 비율을 10% 이내로 관리하고 있습니다. 해당 수치는 100대 카메라 기준의 내부 부하 테스트 환경에서, AI 추론 요청이 동시에 발생하는 상황을 기준으로 관리하는 운영 지표입니다.

5. 우선순위 큐 기반 요청 스케줄링​

대규모 카메라 환경에서는 일부 카메라에서 일시적으로 많은 요청이 발생할 수 있습니다. 이때 요청을 단순 FIFO 방식으로 처리하면 특정 카메라가 시스템 자원을 과도하게 점유하고, 다른 카메라의 분석이 지연될 수 있습니다.

EVA는 카메라별 추론 요청을 우선순위 큐로 관리하여 모든 카메라가 균등하게 AI 파이프라인을 사용할 수 있도록 설계했습니다.

이 구조를 통해 일부 카메라에서 요청이 폭증하더라도 다른 카메라의 AI 추론이 지연되지 않도록 제어합니다. 또한 오래된 프레임이 뒤늦게 처리되어 잘못된 알람으로 이어지는 것을 방지하고, 실시간성이 필요한 AI 파이프라인의 안정성을 유지합니다.

6. 운영 상태 기반 동적 FPS 제어​

EVA는 카메라의 운영 상태에 따라 영상 수집 및 처리 빈도를 동적으로 조정합니다.

단순 연결 상태, AI 추론이 수행 중인 상태, 사용자가 실시간 스트리밍 화면을 시청하는 상태는 요구되는 처리 수준이 서로 다릅니다. 따라서 모든 카메라를 동일한 FPS로 처리하면 불필요한 CPU, GPU, 네트워크 사용량이 증가합니다.

예를 들어 단순 연결 상태에서는 최소한의 프레임만 수집하여 연결 상태를 유지합니다. AI 추론이 필요한 경우에는 분석에 필요한 프레임만 선별하여 처리하고, 사용자가 실시간 영상을 시청하는 경우에만 높은 FPS의 스트리밍 처리를 수행합니다.

특히 EVA는 수집된 모든 프레임을 디코딩하거나 AI 분석에 사용하지 않습니다. 추론에 필요한 프레임만 선택적으로 추출하여 파이프라인을 수행함으로써 불필요한 영상 수집, 디코딩, 전처리, 추론 작업을 최소화합니다.

내부 검증 결과, 동일 서버 스펙에서 Monitoring On 상태의 카메라 50대 연결 시 CPU 사용률을 100% 수준에서 약 65% 수준까지 낮춰 약 35%의 CPU 리소스 절감 효과를 확인했습니다.

7. 멀티 사용자 스트리밍 최적화​

관제 환경에서는 하나의 카메라 영상을 여러 사용자가 동시에 모니터링하는 경우가 많습니다.

일반적인 구조에서는 사용자 수가 증가할수록 동일 영상에 대한 디코딩, 전처리, 인코딩 작업이 반복 수행되어 CPU와 메모리 사용량이 크게 증가할 수 있습니다. EVA는 이러한 문제를 줄이기 위해 동일 카메라에 대한 영상 처리 작업을 공유하는 구조를 적용했습니다.

EVA는 동일 카메라에 대해 디코딩, 전처리, 인코딩 작업을 한 번만 수행하고, 이후 생성된 스트림을 여러 사용자에게 공유합니다. 이를 통해 사용자가 증가하더라도 추가 비용은 주로 네트워크 전송 수준으로 제한됩니다.

결과적으로 다수의 사용자가 동시에 영상을 모니터링하는 환경에서도 안정적인 스트리밍 품질을 유지하면서 서버 자원 소모를 최소화할 수 있습니다.

마치며​

EVA의 인프라 효율성은 단일 GPU 성능에만 의존하지 않습니다. 영상 수집, 프레임 선별, AI 추론, 요청 스케줄링, 스트리밍 송출까지 전체 파이프라인을 함께 최적화한 결과입니다.

EVA는 다음과 같은 기술을 결합하여 동일 서버 환경에서 더 많은 카메라를 안정적으로 수용할 수 있도록 설계되었습니다.

결국 EVA의 대규모 카메라 수용 능력은 하나의 최적화 기술만으로 만들어진 것이 아닙니다. 제한된 서버 자원을 더 효율적으로 사용하기 위해, AI 모델 구조와 시스템 인프라를 함께 설계한 결과입니다.

앞으로도 EVA는 더 많은 카메라, 더 복잡한 시나리오, 더 다양한 운영 환경을 안정적으로 지원하기 위해 인프라 최적화 기술을 지속적으로 고도화해 나갈 예정입니다.

그동안 EVA는 GPU 기반 환경에서 Vision Model, Vision Language Model, Agent 파이프라인을 운영해왔습니다. 하지만 더 높은 전력 효율과 비용 효율적인 확장성을 확보하기 위해 Rebellions NPU 환경에서도 EVA가 상용 서비스 수준으로 동작할 수 있는지 검증하고 최적화를 진행했습니다.

NPU에서 EVA를 구동하는 과정은 단순한 모델 포팅 작업이 아니었습니다. GPU 중심으로 구성된 AI 서비스 파이프라인을 NPU 환경에서도 안정적으로 운영하기 위해서는 모델 컴파일, 입력 해상도, 병렬 처리, CPU와 NPU 간 자원 배치까지 함께 고려해야 했습니다.

NPU 상용화를 위해 검증한 최적화 포인트​

1. 모델을 NPU 실행 구조에 맞게 최적화하기​

NPU 환경에서 가장 먼저 확인한 것은 모델이 NPU 실행 구조에 적합하게 변환될 수 있는지였습니다. GPU에서는 PyTorch 기반 모델을 비교적 유연하게 실행할 수 있지만, NPU에서는 전용 컴파일러를 통해 모델 구조와 입력 형태를 명확하게 정의하는 과정이 필요합니다.

EVA에서 사용하는 Vision 모델은 다양한 카메라 영상과 시나리오를 처리하기 때문에, 모델 자체의 실행뿐 아니라 전처리, 후처리, 입력 Shape, 좌표 복원 방식까지 함께 고려해야 했습니다.

이를 위해 EVA는 모델 구조를 NPU 실행에 적합한 형태로 정리하고, 입력 Shape을 고정하며, 이미지 전처리와 추론 결과의 원본 좌표 복원 과정을 EVA 파이프라인에 맞게 재구성했습니다.

이 과정은 단순히 모델을 NPU에 올리는 작업이 아니라, 실제 서비스 환경에서 안정적인 응답 속도와 일관된 추론 결과를 제공하기 위한 최적화 작업이었습니다.

2. 입력 해상도와 세밀한 판단 성능의 균형​

NPU에서 추론 속도를 높이기 위해서는 입력 이미지 해상도를 조정하는 최적화가 필요합니다. 하지만 모든 시나리오에서 이미지 전체를 낮은 해상도로 변환하면 세밀한 판단이 필요한 경우 성능에 영향을 줄 수 있습니다.

특히 보호구 착용 여부처럼 작은 영역을 정밀하게 판단해야 하는 시나리오에서는 이 균형이 중요합니다. 안전모, 마스크, 보안경, 장갑과 같은 보호구는 전체 이미지에서 차지하는 비중이 작기 때문에, 이미지 전체를 축소하면 모델이 봐야 할 핵심 정보가 충분히 전달되지 않을 수 있습니다.

EVA는 이 문제를 단순히 전체 이미지 해상도를 높이는 방식으로 접근하지 않았습니다. 대신 먼저 판단에 필요한 영역을 찾고, 해당 영역만 Crop한 뒤 모델이 요구하는 입력 해상도로 다시 구성하는 방식을 적용했습니다.

예를 들어 보호구 착용 여부를 판단해야 하는 경우, 전체 이미지를 그대로 VLM에 전달하지 않고 사람 영역을 중심으로 이미지를 잘라낸 뒤, 해당 영역을 모델 입력 크기에 맞춰 확대하여 추론합니다.

이 방식은 다음과 같은 장점이 있습니다.

• 이미지 전체를 고해상도로 처리하지 않아도 되어 추론 비용을 줄일 수 있습니다.
• 모델이 실제로 판단해야 하는 영역은 충분한 해상도로 전달할 수 있습니다.
• 작은 객체나 세밀한 상태 판단에서도 성능 저하를 줄일 수 있습니다.

즉, EVA는 NPU 환경에서 단순히 해상도를 낮추는 것이 아니라, 모델이 봐야 할 영역과 그렇지 않은 영역을 구분하여 처리합니다.

3. 실제 운영 데이터 기반 탐지 성능 검증​

NPU 상용화를 위해서는 속도뿐 아니라 탐지 성능도 함께 검증해야 합니다. 모델이 NPU 환경에서 안정적으로 동작하더라도 GPU 환경 대비 판단 성능이 유지되는지 확인해야 실제 서비스에 적용할 수 있습니다.

EVA는 다양한 운영 환경에서 수집된 실제 탐지 데이터를 바탕으로 자체 검증 데이터셋을 구축했습니다. 공개 벤치마크 데이터셋이 아니라, EVA가 실제로 판단해야 하는 시나리오를 기준으로 성능을 검증했습니다.

검증 대상에는 다음과 같은 현장 시나리오가 포함되었습니다.

이 데이터를 기반으로 GPU 환경과 NPU 환경에서 동일한 시나리오를 검증했습니다. 그 결과 NPU 환경에서도 주요 시나리오에 대해 GPU 대비 유사한 수준의 탐지 성능을 확보할 수 있음을 확인했습니다.

다만 작은 객체나 세밀한 시각 정보가 필요한 시나리오는 입력 해상도 변화에 민감할 수 있기 때문에, 앞서 설명한 Crop 기반 입력 최적화와 함께 적용하는 것이 중요했습니다.

4. VLM 호출을 효율화하기 위한 작업 분해 구조​

NPU 환경에서는 하나의 큰 추론 작업을 처리하는 방식보다, 실제 판단에 필요한 요청을 선별하고 고비용 추론을 효율적으로 사용하는 구조가 중요합니다. 특히 VLM은 Vision Encoder와 LLM Decoder가 함께 동작하기 때문에, 여러 카메라에서 동시에 요청이 발생하는 환경에서는 요청 수와 실행 단계를 체계적으로 관리해야 합니다.

EVA는 모든 프레임을 VLM으로 판단하지 않고, 먼저 VM이 객체 존재 여부와 기본 조건을 확인한 뒤 필요한 경우에만 VLM을 수행합니다.

예를 들어 보호구 미착용 탐지의 경우, 사람이 존재하지 않는 프레임은 초기 단계에서 제외하고, 실제로 사람 영역이 확인된 경우에만 후속 판단을 수행합니다. 또한 복합 시나리오도 하나의 큰 요청으로 처리하지 않고, 탐지 단계 판단, 예외 상황 검사, 알람 메시지 생성 등 작은 작업 단위로 나누어 처리합니다.

이를 통해 NPU 환경에서 VLM 호출을 효율적으로 관리하고, 실제 판단이 필요한 요청에 연산 자원을 집중할 수 있습니다.

5. 다중 NPU 기반 Worker와 vLLM 인스턴스 분산 구성​

NPU에서 EVA를 상용 서비스로 운영하기 위해서는 여러 카메라에서 동시에 발생하는 Vision과 VLM 요청을 안정적으로 처리할 수 있어야 합니다. 이를 위해 EVA는 Vision 영역과 Agent 영역을 분리하고, NPU 코어와 vLLM 인스턴스를 역할에 따라 분산 배치했습니다.

Vision 영역에서는 객체 탐지 Worker를 NPU 코어별로 배치하여 다수의 카메라 요청을 병렬로 처리합니다. 이때 카메라 수와 모델별 요청량을 기준으로 적정 Worker 수를 조정하여, NPU 코어가 안정적으로 활용될 수 있도록 구성했습니다.

VLM 영역에서는 단일 vLLM 인스턴스에 모든 요청을 집중시키지 않고, 여러 vLLM 인스턴스를 분산 구성하여 동시 처리량을 확보했습니다. 특히 이미지 입력 처리를 담당하는 Vision Encoder 구간의 부하를 고려하여, 여러 인스턴스가 독립적으로 요청을 처리할 수 있도록 구성한 것이 중요했습니다.

정리하면 EVA의 NPU 최적화는 단순히 NPU 장비를 추가하는 방식이 아니라, Vision Worker와 vLLM 인스턴스를 NPU 구조에 맞게 배치하여 전체 추론 파이프라인의 안정성을 높이는 과정입니다. 이를 통해 다수의 카메라 요청이 동시에 발생하는 환경에서도 안정적인 서비스 구성이 가능해졌습니다.

6. NUMA Alignment와 CPU Pinning​

NUMA는 Non-Uniform Memory Access의 약자이며, CPU 소켓별 메모리 접근 지연이 달라지는 구조를 의미합니다.

NPU 최적화에서 모델과 파이프라인만큼 중요한 것이 서버 자원 배치입니다. 실제 상용 환경에서는 하나의 서버에서 여러 개의 vLLM 인스턴스가 동시에 구동됩니다. 이때 각 프로세스가 어떤 CPU 코어를 사용하고, 해당 CPU 코어가 어떤 NUMA Node에 속해 있으며, NPU 장치와 물리적으로 얼마나 가까운지가 전체 응답 시간에 영향을 줄 수 있습니다.

다중 인스턴스 환경에서는 CPU, Memory, NPU 간 데이터 이동 경로를 명확하게 정렬하는 것이 중요합니다. EVA는 이를 위해 vLLM 인스턴스별로 CPU Pinning과 NUMA Alignment를 적용하는 구조를 검증합니다.

최종 상용 환경에서는 vLLM별로 독립된 컨테이너 또는 Pod를 구성하고, 각 환경에 CPU Pinning과 NUMA Alignment를 적용하는 구조가 필요합니다.

이는 단순한 서버 설정이 아니라, NPU 기반 AI 서비스를 더 안정적으로 운영하기 위한 인프라 최적화 과정입니다.

마치며​

이번 최적화 과정에서 EVA는 NPU를 GPU의 단순 대체재로 바라보지 않았습니다. GPU 중심으로 구성된 AI 서비스 파이프라인을 NPU 환경에서도 안정적으로 운영하기 위해서는 모델, 입력 파이프라인, 추론 단계, Worker 배치, vLLM 인스턴스 구성, 서버 자원 정렬까지 함께 고려해야 했습니다.

NPU에서 EVA를 안정적으로 운영하기 위해 함께 최적화한 요소는 다음과 같습니다.

• NPU 실행 구조에 맞는 모델 구성
• 고정된 입력 파이프라인
• 해상도 저하를 보완하는 Crop 기반 입력 최적화
• 실제 운영 데이터 기반 탐지 성능 검증
• Vision과 VLM의 분산 처리 구조
• CPU Pinning과 NUMA Alignment 기반 자원 정렬

EVA는 이러한 과정을 통해 NPU 환경에서도 주요 탐지 시나리오에 대한 성능을 유지하고, 다수의 카메라 요청을 안정적으로 처리할 수 있는 구조를 확보했습니다.

앞으로도 EVA는 Rebellions NPU 환경에서 Vision Encoder 병렬화, 모델 양자화, 멀티 NPU 스케줄링, 컨테이너 기반 자원 격리 등을 지속적으로 고도화하여 다양한 하드웨어 환경에서 안정적으로 동작하는 Physical AI 플랫폼으로 확장해 나갈 예정입니다.

EVA를 특정 목적에 맞게 안정적으로 운영하려면 객체, 민감도, Vision 모델 같은 설정값을 시나리오와 카메라 환경에 맞게 지속적으로 조정해야 합니다. 문제는 "과거 데이터와 현재 화면 상황을 함께 보고 지금 어떤 값을 설정해야 하는지"를 사람이 일관되게 판단하기가 매우 어렵다는 점입니다.

이런 사용자 운영 어려움을 해소하고, 원하는 탐지를 더 쉽게 수행할 수 있도록 EVA는 Meta 지능화를 적용할 예정입니다. Meta 지능화는 계속 고도화되며, v3.0에서는 객체 민감도 추천과 Vision 모델 추천을 우선 제공합니다.

1. 왜 Meta 지능화가 필요한가​

소규모 환경에서는 운영자가 직접 카메라별 파라미터를 조정하는 것이 가능해 보일 수 있습니다. 하지만 카메라가 100대 이상으로 늘어나면 상황이 완전히 달라집니다.

카메라마다 설치 높이, 화각, 조도, 배경 반사, 작업 동선이 다르고, 같은 시나리오라도 오탐/미탐 패턴이 다르게 나타납니다. 결국 "카메라 1대 단위 최적화"가 필요해지는데, 이 작업은 시간이 많이 들 뿐 아니라 전문적인 운영 노하우도 요구됩니다.

운영자가 실제로 부딪히는 문제는 다음과 같습니다.

• 객체 정의가 넓거나 모호하면 오탐이 늘고 불필요한 추론이 증가합니다.
• 민감도가 낮으면 비대상 객체까지 탐지하고, 높으면 필요한 객체를 놓칩니다.
• 모델 성능은 시나리오(예: 화재/연기/쓰러짐), 카메라 각도, 조도, 배경 구조에 따라 달라집니다.
• 설정을 바꿔도 효과를 즉시 검증하기 어렵고, 카메라 수가 많아질수록 수동 조정 비용이 급격히 증가합니다.

즉, "초기 한 번 설정"으로는 장기 운영 품질을 유지하기 어렵고, 데이터 기반 자동 최적화 계층이 필수입니다.

2. Meta 지능화가 동작하는 방식​

Meta 지능화는 주기적으로 카메라별 상태를 확인하고, 다음 신호를 기반으로 동작합니다.

• 최근 탐지 알람 발생 데이터
• 사용자 피드백 누적 정도
• 추천 판단에 활용 가능한 이미지 축적량

핵심은 피드백이 충분히 쌓인 카메라일수록 Meta 지능화가 해당 카메라를 더 자주 분석하고, 더 정확한 추천을 제공할 수 있다는 점입니다.

즉, Meta 지능화는 일회성 분석이 아니라 "카메라별 운영 상태 + 피드백 축적도"를 반영해 추천 빈도와 품질을 함께 높이는 방식으로 동작합니다.

아래 화면처럼 운영자는 실제 탐지 알림과 추천 메시지를 함께 확인할 수 있고, EVA는 누적된 피드백과 탐지 결과를 바탕으로 민감도 조정 추천을 제공합니다. 예를 들어 특정 객체가 반복적으로 낮은 민감도에서 탐지되는 경우, 현재 화면 상황에 더 적합한 민감도 값으로 조정하라는 안내를 받을 수 있습니다.

이 과정은 단순 추천에서 끝나지 않고, 현장에서 실제 운영되는 탐지 데이터를 지속적으로 분석해 EVA의 운영 전략과 추천 정밀도를 함께 고도화하는 기반으로 작동합니다.

즉, 카메라가 늘고 데이터가 축적될수록 EVA는 더 현장 적합한 방향으로 진화합니다.

3. 객체 민감도 추천 로직​

Meta 지능화의 추천 로직은 다음 순서로 수행됩니다.

• 동일 객체에 대해 5개 Vision 모델로 추론을 수행합니다.
• 모델별 추론 결과를 앙상블해 자동 라벨링합니다.
• 20개 이상의 이미지에서 정탐/오탐 분리가 가능한지 검증합니다.
• 분리 가능성이 확인된 경우에만 민감도/모델 추천을 생성합니다.

여기서 단일 모델이 아니라 앙상블을 사용하는 이유는 명확합니다.

• Vision 모델이 오탐한 객체는 VLM 단계에서도 오탐으로 이어질 가능성이 높습니다.
• 초기 시각 인식이 흔들리면, 상위 판단 모델(VLM)의 결론도 함께 왜곡될 수 있기 때문입니다.
• 따라서 하나의 모델 결과를 신뢰하기보다, 여러 모델의 합의로 객체 정합성을 먼저 확보하는 것이 더 안정적입니다.¹²

또한 효율성 측면에서도 장점이 있습니다.

• VLM은 추론 비용과 리소스 사용량이 크기 때문에, 라벨링 단계에서 매번 VLM을 대량 호출하는 방식은 비효율적입니다.
• 반면 여러 Vision 모델 기반 앙상블은 상대적으로 낮은 비용으로 대량 샘플을 빠르게 검증할 수 있어 운영에 더 적합합니다.

실제 내부 검증에서도 다중 Vision 모델 앙상블 라벨링이 단일 판단 대비 약 30% 높은 라벨링 정확도를 보였습니다.

또한 이 라벨링 과정에서 이미 여러 Vision 모델 결과가 확보되므로,

• 현재 모델에 적절한 민감도를 즉시 추천할 수 있고
• 모든 시나리오가 동일 대상을 탐지하는 경우 모델 변경 추천까지 연결할 수 있습니다.

추천 메시지 예시:

탐지 대상 {객체}에 대한 오탐이 발생하고 있습니다. {A} 모델로 설정 및 {0.xx}로 민감도를 조정해보세요.
ℹ️ 모든 시나리오의 탐지 대상이 동일한 경우에만 모델 변경을 추천합니다.

맺음말​

Meta 지능화는 운영자가 감으로 조정하던 민감도/모델 선택을 데이터 기반 추천으로 전환하는 EVA의 운영 최적화 계층입니다.

v3.0에서는 객체 민감도와 Vision 모델 추천을 시작으로, 앞으로 Meta 지능화를 더 고도화해 시나리오별 운영 품질을 지속적으로 개선해 나갈 예정입니다.

EVA v3.0에서는 화면에서 즉시 식별 가능한 사고 상황 탐지의 오탐을 줄이기 위해 Thinking 모드를 새롭게 추가했습니다. 핵심은 VLM이 즉시 결론을 내리기 전에 내부 추론을 수행해 오탐 가능성과 논리적 오류를 다각도로 점검한 뒤, 위험 상황 여부를 판단하도록 한 것입니다.

Thinking 모드는 특히 화면에서 즉시 식별 가능한 상황에서 다각도로 오탐 가능성을 검토해야 하는 시나리오에 적합합니다.

또한 VLM은 맥락에 따라 사용자의 쿼리에 긍정적으로 반응하려는 경향이 있으며, 기본 모드에서 오탐 상황을 예외 규칙으로 계속 추가하는 방식은 처리 지연을 키우고 운영 복잡도를 높일 수 있습니다.¹²

결과적으로 EVA v3.0에서는 모델 자체의 Thinking 모드를 활용해 장면을 빠르게 해석하고, 상식적 사고에 기반해 오탐 가능성을 먼저 검토한 뒤 알람을 발생시키도록 설계하여 탐지 신뢰성을 높였습니다.

1. 왜 Thinking 모드가 필요하며, 어떻게 신뢰도를 높였는가​

기존의 단순 질의 기반 방식에서는 "화재가 났는가", "사람이 쓰러졌는가"처럼 화면에서 바로 보이는 상황도 카메라 각도, 반사, 가림, 저조도 등으로 인해 오탐이 발생할 수 있습니다.

여기에 더해, 운영 중 오탐 사례를 발견할 때마다 규칙을 계속 덧붙이는 방식은 다음과 같은 한계를 만듭니다.

• 예외 규칙 증가로 인한 시나리오 관리 복잡도 상승
• 판단 경로 증가로 인한 처리 지연 가능성 확대
• 사용자별 규칙 편차로 인한 운영 일관성 저하

Thinking 모드는 이런 문제를 줄이기 위해, "빠른 단정"보다 "검토 후 판단"을 우선하는 설계를 채택했습니다.

핵심 원칙​

• 즉시 식별 가능한 장면에 집중: 한 화면에서 비교적 명확히 판별 가능한 사고 상황에 우선 적용합니다.
• 오탐 가능성 다각도 검토: 내부 추론으로 반례와 논리적 오류를 먼저 점검합니다.
• 최종 알람은 사고 항목 기준: 위험 상황이 확인되면 사용자 시나리오의 사고 항목과 매칭해 알람을 발생시킵니다.

판단 가이드라인​

Thinking 모드는 모델이 과도한 추론에 빠지지 않도록, 시스템 프롬프트 차원에서 다음과 같은 운영 정책을 명시합니다.

• 직접 가시 증거 우선: 화면의 주 장면에서 직접 보이는 근거만 사용합니다.
• 활성 사고 항목만 판단: 사용자 입력에서 활성화된 사고 항목만 같은 순서로 판정합니다.
• 애매하면 False: 근거가 약하거나 모호/가림/노이즈가 있으면 False를 반환합니다.
• 사고별 정밀 가드:
  • 쓰러짐: 단순 웅크림/무릎/앉음/원근 모호성만으로는 True 금지
  • 연기/불꽃: 증기/먼지/반사/블러/광원 아티팩트만으로는 True 금지
  • 화재: 실제 화염/연소 단서가 없는 밝은 조명/반사만으로는 True 금지
• 출력 강제 규격화: 사고 항목별 결과를 JSON 스키마로만 반환해 후처리 일관성을 확보합니다.

즉, Thinking 모드는 단순한 감지 기능이 아니라 "근거 중심 판정 + 오탐 억제 가드"를 동시에 적용하는 운영형 판단 모드로 설계되었습니다.

2. 성능 리뷰​

Thinking 모드는 단순히 "정답/오답"만 보는 방식이 아니라, 에이전트가 중간 근거를 생성하고 이를 시나리오 규칙과 매칭하는 구조로 동작합니다. 아래 사례에서처럼 먼저 장면 단서를 추론한 뒤, 최종적으로 사용자 시나리오와 비교해 알람 여부를 결정합니다.

출처: 한국지능정보사회진흥원

이 사례는 쓰러짐(Fall/Down) 탐지에 해당하며, Thinking 모드는 다음과 같은 핵심 추론을 거쳐 alert: true를 판단합니다.

• 장면 분석: 산업 현장 바닥 위에 사람이 헬멧과 작업복을 착용한 채 수평으로 누워 있는 상태를 확인
• 자세 판별: 웅크림/앉음/작업 자세가 아니라, upright posture를 잃고 바닥에 쓰러진 자세로 판단
• Fall 가드라인 대조: "직접적으로 바닥에 쓰러진 시각 근거" 조건을 충족하는지 검증
• 모호성 점검: 일시적 자세 변화나 스트레칭 같은 반례 가능성이 낮음을 확인
• 최종 판정: 쓰러짐의 직접 근거가 충분하여 alert: true 반환

위 사례와는 반대로, 자동차에서 화재가 발생한 것처럼 보이지만 실제 화재가 아닌 장면에서도 Thinking 모드는 단일 단서로 즉시 판단하지 않고 다각도로 검토합니다.

모델의 중간 추론에서 핵심적으로 확인한 포인트는 다음과 같습니다.

• 장면 맥락 점검: 야간 주차장 환경과 다수 광원(가로등, 헤드라이트)을 먼저 확인
• 의심 단서 재해석: 차량 뒤 붉은 빛을 화염으로 단정하지 않고 반사광/광원 아티팩트 가능성 검토
• 화재 가드라인 적용: 실제 화염 형태, 연소 단서, 연기 동반 여부를 재확인
• 최종 판정: 명확한 화염·연소 증거가 없어 alert: false 결론

즉, Thinking 모드는 밝은 붉은 빛처럼 오인하기 쉬운 시각 단서에 대해서도 반례를 함께 검토한 뒤 결론을 내려, 오탐을 줄이고 신뢰성 있는 알람을 제공합니다.

그 결과, Thinking 모드 실험에서는 시나리오별로 다음과 같은 성능이 측정되었습니다.

쓰러짐​

연기/불꽃​

화재​

요약하면, Thinking 모드는 즉시 식별 가능한 쓰러짐, 연기/불꽃, 화재 시나리오에서 성능이 크게 향상되었습니다.

⚠️ Thinking 모드는 다른 시나리오에서도 좋은 성능을 제공할 수 있지만, 사람의 행위나 착용 상태를 면밀히 살펴봐야 하거나 특정 환경 규칙 기반으로 탐지해야 하는 시나리오에서는 추론 시간이 매우 길어질 수 있어 특정 시나리오에 대해서만 추천합니다.

3. 사용성: 시나리오 추가 없이 위험 상황만 수정하여 운영​

Thinking 모드는 EVA v3.0에서 별도 시나리오를 매번 새로 만들지 않아도, 위험 상황 항목을 추가/수정하는 방식으로 즉시 식별 가능한 사고 탐지를 확장할 수 있습니다.

## 💡 Thinking 모드로 탐지를 수행합니다.
객체가 탐지되면 설정된 탐지 간격에 따라 에이전트가 오탐 가능성과 논리적 오류를 검토하여
위험 상황 여부를 판단하고, 위험 상황인 경우 알람이 발생합니다.

### 위험 상황(최대 3개까지 상황 지원)
복잡하거나 모호한 상황은 판단에 시간이 오래 걸릴 수 있습니다.
예시를 참고하여 한 화면에서 명확하게 판단 가능한 위험 상황을 작성해주세요.

- 화재 발생

**좋은 예시**
- 화재 발생
- 연기 발생
- 사람이 바닥에 쓰러짐

**권장하지 않는 예시**
- 작업자의 특정 행위 중 위험한 상황 탐지
- 객체의 상태를 복합적으로 판단해야 하는 상황

맺음말​

Thinking 모드의 핵심은 "즉시 반응"보다 "내부 추론을 통한 검토 후 판단"에 있습니다. 이를 통해 즉시 식별 가능한 사고 시나리오에서 오탐 가능성을 낮추고, 현장 운영자가 신뢰할 수 있는 알람 품질을 확보할 수 있습니다.

EVA v.3.0에서는 보호구 미착용 탐지의 오탐을 줄이기 위해, VLM 추론 방식을 단계적으로 재설계한 PPE 모드를 새롭게 추가했습니다. 핵심은 "사용자 질의에 바로 답하게 하는 방식"에서 벗어나, 모델이 먼저 장면을 설명하고 그 설명을 기반으로 판단하도록 에이전트 구조를 고도화한 것입니다.

1. 왜 기존 방식에서 오탐이 많이 발생했나: VLM의 질의 편향과 할루시네이션​

보호구 미착용 탐지에서 사용자 질의가 "안전모를 안 쓴 사람 찾아줘"처럼 직접적일수록, 일부 VLM은 질의 의도에 맞춰 긍정(동의) 성향의 답변을 생성하는 경향을 보입니다. 이때 실제 이미지 근거가 충분하지 않아도 "미착용"으로 답해 오탐(False Positive)이 늘어날 수 있습니다.

이 문제는 VLM/LLM 영역에서 보고되는 할루시네이션(hallucination) 및 시코팬시(sycophancy, 사용자 견해에 과도하게 맞추는 경향)와 맞닿아 있습니다.¹²³

반대로, 같은 이미지에 대해 "무엇이 보이는지 설명해줘"처럼 설명 중심 프롬프트를 사용할 때는 사용자 의도를 맞추려는 압력이 줄어들어, 객체 상태를 더 사실적으로 표현하는 경향을 확인했습니다.

2. EVA v.3.0 에이전트 고도화: "질의에 답변"이 아니라 "설명 후 판단"으로​

EVA v.3.0의 PPE 모드는 VLM이 사용자 의도에 직접 끌려가지 않도록, 탐지 과정을 3단계 파이프라인으로 분리했습니다.

기존 방식이 "사용자 질의 -> 즉시 판정"에 가까웠다면, PPE 모드는 "대상 선별 -> 영역 확인 -> 상태 설명 -> 규칙 매칭"으로 판단 근거를 분리해 오탐을 줄입니다.

핵심 원칙​

• 작업 맥락을 먼저 확인: 사람 단위 박스 정보와 함께, 고소 작업처럼 전체 이미지 맥락이 필요한 상황까지 반영해 작업 대상을 선별합니다.
• 착용 여부와 확인 가능성을 분리: "무엇을 착용했는가"와 "판단에 필요한 신체 부위가 실제로 보이는가"를 분리해 검증합니다.
• 최종 판단은 규칙으로 일관되게: 탐지 항목, 유사어, required area 확인 결과를 함께 매칭해 알람 발생 기준을 표준화합니다.

3-Stage 처리 흐름​

Stage 1. 작업 대상 선별 및 요구 영역 정의​

• Enrich Required Equipments
  • 탐지 항목에 대해 유사어를 추출합니다.
• Find Worker
  • 객체 탐지 모델이 찾은 대상에 대해 박스를 표시하고, VLM이 작업 상황에 해당하는 사람인지 판단합니다.
  • 고소 작업자처럼 이미지 전체 맥락을 통해 확인 가능한 작업 상황도 있으므로, 전체 이미지를 기반으로 판단합니다.
  • 대상이 여러 명인 경우 병렬로 판단합니다.
  • ℹ️ 대상이 5명 이상인 경우 바운딩 박스 크기가 가장 큰 5개에 대해서만 판단합니다.
  • 작업 상황에 해당하는 사람이 있는 경우 Stage 2로 넘어갑니다.
• Required Body Parts
  • 탐지 항목을 확인하기 위한 신체 부위를 추출합니다.
  • 예시: 마스크 -> 얼굴 정면/측면, 헬멧 -> 머리

Stage 2. 착용 아이템 및 영역 확인​

• Explain Worker
  • Stage 1에서 탐지된 사람을 대상으로 착용 아이템(안전모, 마스크 등)을 추출합니다.
  • 대상이 여러 명인 경우 병렬로 실행합니다.
• Check Body Parts
  • Stage 1에서 탐지된 사람을 대상으로 required body parts가 실제로 확인되는지 점검합니다.
  • 대상이 여러 명인 경우 병렬로 실행합니다.

Stage 3. 규칙 매칭, 알람, 설명 생성​

• Matching Equipments
  • 탐지된 아이템이 탐지 항목의 유사어에 없고, required body parts가 확인되는 경우 알람을 발생합니다.
  • 알람 메시지에 미충족된 탐지 항목을 표시합니다.
  • 예시: 보호 장비 미착용 탐지 (안전모, 마스크)
• Image Description
  • 알람과 함께 이미지 설명을 생성합니다.

이 구조를 통해 PPE 모드는 "VLM의 즉시 단정"이 아니라 "대상 선별 + 영역 확인 + 아이템 추출 + 규칙 매칭"으로 최종 결론을 내리며, 현장 운영에서 필요한 재현성과 신뢰도를 높입니다.

3. 성능 리뷰​

PPE 모드는 단순히 "정답/오답"만 보는 방식이 아니라, 에이전트가 중간 근거를 생성하고 이를 시나리오 규칙과 매칭하는 구조로 동작합니다. 아래 사례에서처럼 먼저 착용 아이템과 확인 가능한 신체 부위를 각각 추론한 뒤, 최종적으로 사용자 시나리오와 비교해 알람 여부를 결정합니다.

예를 들어 위와 같은 이미지에 대해 Agent는 다음과 같은 중간 결과를 생성합니다.

# 착용 아이템
"worn_items" = ["mask", "gloves", "pants", "shoes"]
"evidence" = "The person is wearing a mask, gloves, pants, and shoes."

# 착용 부위 확인
"target_region": "upper head and crown area",
"visible": true,
"evidence": "The top of the person's head and crown are clearly visible from the front."

이후 PPE 모드는 위 설명 결과를 사용자 시나리오(예: 마스크와 안전모 미착용 탐지)와 매칭하여, 탐지 항목 미검출 + 착용 부위 확인 조건이 충족될 때 알람을 발생시킵니다. 특히 이 사례에서는 착용 아이템에 마스크는 포함되어 있지만 헬멧이 없고, 머리가 확인되었기 때문에 헬멧 미착용 알람이 발생합니다.

그 결과, 전체적으로 PPE 관련 7개 시나리오 데이터셋에서 다음과 같은 성능 향상이 확인되었습니다.

수치 기준으로 보면 PPE 모드는 기본 모드 대비 탐지 신뢰도가 뚜렷하게 개선되었습니다.

운영 관점에서는 특히 Precision의 큰 상승이 의미가 큽니다. 즉, "미착용"으로 울린 알람이 실제 위반일 확률이 높아져, 불필요한 확인 업무와 알람 피로를 줄이는 데 직접적으로 기여합니다.

4. 사용성: 시나리오 추가 없이 탐지 항목만 바꿔서 운영​

PPE 모드에서는 아래와 같은 형식으로 탐지 시나리오가 생성되므로, 사용자는 별도 시나리오를 새로 만들지 않고도 원하는 보호구 미착용 탐지를 간단하게 변경할 수 있습니다.

## 💡 PPE 모드로 탐지를 수행합니다.
사람이 탐지되면 설정된 탐지 간격에 따라 에이전트가 작업 상황에 해당하는 사람을 확인하며,
탐지 항목 중 하나라도 충족되지 않는 경우 알람이 발생합니다.

> ⚠️ 정확한 안전 장비 착용 확인을 위해 탐지 대상은 사람의 전신을 박스 표시하도록 설정해주세요.

> 예시: "person" 또는 "worker"

> 사람이 5명 이상인 경우 박스 표시가 큰 순서로 5명에 대해서만 탐지를 수행합니다.

### 작업 상황(한 가지 작업 상황만 작성 가능)
탐지하려는 사람의 작업 상태 또는 행동을 작성해주세요.
- 의자에 앉아서 납땜 작업 중


### 탐지 항목 (최대 3개까지 지원)
사람이 반드시 착용하고 있어야 하는 보호 장비 또는 항목을 작성해주세요.
- 마스크
- 헬멧

맺음말​

PPE 모드의 핵심은 "질문에 바로 답하게 하는 구조"에서 "근거를 설명한 뒤 판단하는 구조"로 전환한 데 있습니다. 이를 통해 보호구 미착용 탐지에서 오탐을 줄이고, 현장 운영자가 신뢰할 수 있는 알람 품질을 만드는 데 집중했습니다.

Vision Transformer(ViT)는 분류, 검출, 분할, 멀티모달 백본까지 폭넓게 쓰이지만, 높은 계산량 때문에 실제 배포 단계에서 병목이 자주 발생합니다. 이번 글에서는 ICML 2026에 채택된 ToaSt 논문의 문제의식, 방법론, 실험 결과를 논문 구조에 맞춰 자세히 정리합니다.

ToaSt의 핵심은 아래 한 줄로 요약할 수 있습니다.

• MHSA와 FFN을 분리해 각각 다른 전략으로 압축하고, 레이어 간 전파 문제를 피하면서 정확도-효율 균형을 동시에 개선한다.

1. 문제 배경: ViT는 어디서 느려지는가?​

ViT 계산량은 크게 두 축에서 발생합니다.

• Attention: 토큰 수 (N)에 대해 대략 (O(N^2))
• FFN: 채널 차원 (D) 중심의 큰 연산량

논문에서 인용한 분석에 따르면 표준 ViT에서 FFN이 전체 FLOPs의 약 61%, Attention이 약 19%를 차지합니다. 즉 attention만 줄여서는 전체 효율을 충분히 끌어올리기 어렵고, FFN 중복을 직접 다뤄야 합니다.

Figure 1. ToaSt는 MHSA와 FFN을 분리 압축해 레이어 간 전파 문제를 줄인다.

2. 기존 접근의 한계: 왜 새로운 설계가 필요했나?​

논문은 기존 ViT 경량화 방법을 크게 세 그룹으로 정리합니다.

2.1 Structured Weight Pruning​

• 장점: 채널/헤드/블록 단위로 잘라서 일반 GPU에서도 가속 가능
• 한계: 정확도 회복을 위한 재학습 비용이 큼
• 실제 문제: ViT 계열은 원래 학습도 길어(수백 epoch), pruning 후 긴 fine-tuning이 실무에서 부담

2.2 Token Compression / Token Merging​

• 장점: (N)을 줄여 attention의 (O(N^2)) 비용을 직접 줄임
• 한계 1: FFN의 (D^2) 지배 항을 직접 줄이지 못함
• 한계 2: 한 레이어의 token 선택이 이후 레이어로 전파되어 전역 의존성이 생김

2.3 Joint / Hybrid Methods​

• 장점: 여러 축을 동시에 최적화해 큰 가속 잠재력
• 한계: 최적화 공간이 복잡하고 설정 민감도가 높음
• 일부 방식은 하드웨어/커널 의존성이 커 범용 배포가 어렵기도 함

ToaSt는 이 지점에서 "한 번에 다 최적화"가 아니라 "모듈별로 분리해 단순하고 안정적으로 압축"하는 철학을 택합니다.

3. ToaSt 방법론: Layer-Independent Compression​

ToaSt는 Transformer block의 입출력 인터페이스 ((N \times D))를 유지한 채, 블록 내부만 줄입니다. 이렇게 하면 앞 레이어의 압축 결정이 뒤 레이어로 강하게 전파되는 문제를 줄일 수 있습니다.

3.1 MHSA: Coupled Structured Pruning​

MHSA에서 Q, K, V, Proj는 수학적으로 서로 연결돼 있습니다. ToaSt는 이 연결성을 무시하지 않고, 인덱스를 동기화해 함께 pruning합니다.

• Q-K 동기화 pruning
• V-Proj 동기화 pruning
• 헤드 내부 차원 (d_k) 축소, 전역 임베딩 차원 (D) 인터페이스는 유지

중요도는 Geometric Median 기반 기준으로 계산하고, 작은 모델을 제외한 대부분 설정에서 첫 레이어를 보존한 채 나머지 레이어에 높은 pruning 비율을 적용합니다. 논문은 비정렬 pruning(non-align) 대비 정렬 pruning(align)이 고 pruning ratio에서 정확도 붕괴를 크게 줄인다고 보고합니다.

3.2 FFN: Token Channel Selection (TCS)​

FFN은 (D \rightarrow 4D \rightarrow D) 구조를 갖고, 전체 연산량 비중이 큽니다. ToaSt는 FFN에 대해 학습 없는 동적 채널 선택(TCS)을 적용합니다.

논문에서 제시한 FFN 분석의 핵심 관찰은 3가지입니다.

• 깊은 레이어로 갈수록 활성값 sparsity 증가
• effective rank 붕괴(실질 표현 차원 축소)
• 높은 (R^2) 재구성(채널 간 선형 중복 큼)

이 관찰을 바탕으로 TCS는 토큰 일부를 샘플링해 채널 중요도를 추정하고, 중요 채널만 남깁니다. 중요도 계산은 CLS 전역 정보와 patch saliency를 결합한 형태이며, CLS가 없는 Swin 계열에는 patch 기반 항만 사용합니다.

또한 FC1(확장부)은 보수적으로, FC2(축소부)는 더 공격적으로 적용하는 비대칭 정책을 사용합니다. 논문 설정에서는 FC2 깊은 레이어에서 최대 90%까지 pruning을 적용합니다.

Figure 2. Swin-Base FFN 분석: 깊은 레이어일수록 중복이 커진다.

Figure 3. ToaSt 전체 구조: MHSA는 coupled pruning, FFN은 TCS로 분리 처리.

4. 실험 설정과 주요 결과​

4.1 평가 설정​

• 분류: ImageNet-1K
• 다운스트림: COCO 2017 detection (Cascade R-CNN/Mask R-CNN 백본)
• 백본: DeiT(T/S/B), ViT-MAE(B/L/H), Swin(T/S/B) 총 9개
• 측정: Top-1/Top-5, FLOPs, H100 기준 throughput/speedup

4.2 ImageNet 분류 결과​

논문이 강조한 포인트는 "연산 감소 + 정확도 상승 동시 달성"입니다.

대표 결과는 다음과 같습니다.

1. ViT-MAE-Huge: Top-1 88.52% (baseline 86.88 대비 +1.64%p), FLOPs 39.4% 감소, Throughput 1.59x
2. DeiT-Small: Top-1 83.40% (baseline 79.82 대비 상승), FLOPs 45.7% 감소, Throughput 2.07x
3. Swin-Base: Top-1 85.21% (baseline 83.50 대비 상승), FLOPs 42.7% 감소, Throughput 1.28x

토큰 압축 계열(ToMe, DiffRate)과 유사 FLOPs 구간 비교에서도 ToaSt가 더 높은 정확도를 보인 사례가 다수 제시됩니다.

4.3 Downstream 전이 성능 (COCO)​

분류에서 만든 압축 백본을 detection에 전이했을 때도 성능이 유지됩니다.

• Swin-Small: 52.2 box mAP (baseline 51.9)
• Swin-Base(설정별): 52.2 / 51.8 box mAP

즉 단순히 분류 과적합용 pruning이 아니라, 백본 수준의 중복 제거로 이어질 가능성을 보여줍니다.

5. Ablation에서 확인된 핵심 포인트​

논문은 구성 요소별 기여를 분리해 분석합니다.

• MHSA only: 속도는 개선되지만 정확도 하락이 발생하는 설정 존재
• MHSA + TCS(ToaSt): 속도 추가 개선 + 정확도 회복(또는 baseline 초과) 패턴 확인

또한 FFN의 FC1/FC2 민감도 분석에서,

• FC1은 초기 레이어에서 민감해 보수적 pruning이 유리
• FC2는 후반 레이어에서 높은 pruning 허용

이라는 비대칭 정책의 근거를 제시합니다.

논문은 이를 "TCS가 중복 채널 노이즈를 걸러 정확도 향상에도 기여"하는 신호로 해석합니다.

6. 실무 관점에서의 해석​

ToaSt를 실무 관점에서 보면 다음 장점이 있습니다.

• 모듈 분리 설계로 최적화가 비교적 단순
• FFN 중심 절감으로 실제 연산비 절감 기여가 큼
• structured 형태라 범용 GPU에서 가속 실현 가능성 높음
• 대형 모델일수록 복구 epoch가 줄어드는 경향 보고

특히 "모델이 커질수록 pruning 후 복구가 빠르다"는 관찰은 대형 파운데이션 모델 운영 환경에서 중요한 시사점입니다.

7. 한계와 향후 과제​

저자들이 명시한 한계는 레이어별 pruning ratio를 수동 튜닝한다는 점입니다. 향후 방향은 아래와 같습니다.

• ratio 자동 탐색/학습화
• VLM으로의 확장
• quantization과의 결합

마무리​

ToaSt는 ViT 압축에서 반복적으로 등장하는 두 문제를 동시에 겨냥합니다.

• token 중심 압축만으로는 FFN 중복 제거가 부족하다는 점
• 강하게 결합된 전역 최적화가 재학습 비용과 불안정성을 키운다는 점

이를 해결하기 위해 MHSA와 FFN을 분리해 각각 다른 원리로 압축했고, 논문 결과는 정확도-효율 trade-off에서 일관된 개선을 보여줍니다.

핵심 메시지는 명확합니다.

ViT 경량화는 "토큰만"이 아니라 "채널까지" 같이 봐야 한다. 그리고 모듈 특성에 맞춘 분리 설계가 실제 성능과 운영 효율을 함께 끌어올린다.

EVA 서비스의 핵심 기능 중 하나는 수십 대의 카메라 영상을 실시간으로 확인하는 실시간 스트리밍입니다. 단순히 영상을 짧게 확인하는 수준을 넘어, 현장을 장시간 관제해야 하는 사용자가 늘어남에 따라 예상치 못한 성능 병목 현상이 발생하기 시작했습니다.

"화면을 오래 켜두면 브라우저가 점점 느려지다가 결국 탭이 죽어버려요."

이 문제를 해결하기 위해 저희 팀이 진행했던 Canvas, Web Worker, 그리고 OffscreenCanvas를 이용한 렌더링 구조 개선 여정을 공유하고자 합니다.

1. 배경: 왜 오래 켜둘수록 문제가 생겼을까?​

초기 EVA의 스트리밍 방식은 가장 보편적인 <img> 태그와 Blob(Object URL)의 조합이었습니다.

기존 방식 (Blob 기반 렌더링)​

1. 서버로부터 MJPEG 스트림 데이터를 Blob 형태로 수신합니다.
2. URL.createObjectURL(blob)으로 임시 URL을 생성합니다.
3. <img> 태그의 src에 할당하여 브라우저가 이미지를 그리게 합니다.

구현은 매우 간단했지만, '장시간 관제'라는 특수한 환경에서 두 가지 치명적인 문제가 드러났습니다.

• 메모리 오버헤드: 매 프레임(초당 30회 내외)마다 고유한 URL 문자열이 생성됩니다. revokeObjectURL을 호출하더라도 브라우저 내부의 이미지 캐시와 가비지 컬렉터(GC)의 지연으로 인해 메모리 점유율이 우상향하며 결국 Out of Memory(OOM) 오류를 유발했습니다.
• 메인 스레드 블로킹: 이미지의 디코딩 과정이 메인 스레드(UI 스레드)에서 발생합니다. 고해상도 영상을 처리할 때 이벤트 루프가 지연되면서 클릭이나 스크롤 같은 UI 반응이 느려지는 Jank 현상이 발생했습니다.

2. 네트워크 탭 분석: MJPEG의 정체​

성능 개선을 위해 가장 먼저 분석한 것은 네트워크 레이어였습니다. MJPEG 스트리밍은 일반적인 HTTP 요청과 다릅니다.

multipart/x-mixed-replace​

MJPEG은 Content-Type: multipart/x-mixed-replace; boundary=... 헤더를 사용합니다. 이는 단일 HTTP 연결을 통해 서버가 끊임없이 이미지 프레임을 밀어주는 방식입니다.

• 네트워크 탭의 특징: 요청이 완료되지 않고 계속 'Pending' 상태로 유지됩니다. 브라우저는 연결을 끊지 않고 계속해서 들어오는 바이너리 데이터를 받아들입니다.
• 바이너리 데이터 구조: 각 프레임은 특정 boundary 문자열로 구분된 JPEG 바이너리 데이터(0xFF 0xD8 ... 0xFF 0xD9)입니다.

기존 방식은 이 거대한 바이너리 덩어리를 통째로 Blob으로 만들어 메인 스레드에서 파싱했기 때문에, 데이터가 쌓일수록 브라우저의 부담은 기하급수적으로 늘어날 수밖에 없는 구조였습니다.

3. 1차 개선: Canvas와 createImageBitmap​

저희는 먼저 브라우저의 가비지 컬렉터에 의존하던 메모리 관리 방식을 명시적 관리 방식으로 전환하기 위해 Canvas API를 도입했습니다.

비동기 비트맵 렌더링​

createImageBitmap API는 이미지를 화면에 그리기 전에 백그라운드에서 비동기적으로 디코딩할 수 있게 해줍니다.

// @src/entities/devices/components/stream/MJPEGStream.tsx
// 캔버스에 비트맵을 그린 직후 즉시 메모리 해제
const bitmap = await createImageBitmap(blob);
ctx.drawImage(bitmap, 0, 0);
bitmap.close(); // 명시적으로 메모리 반환

이 방식의 핵심은 bitmap.close()입니다. 개발자가 직접 사용이 끝난 비트맵 리소스를 파괴함으로써 메모리 점유율을 일정하게 유지할 수 있게 되었습니다. 또한 <img> 태그의 src 변경 시 발생하는 리플로우(Reflow) 를 제거하고 GPU 가속을 활용하는 캔버스 드로잉으로 전환하며 렌더링 효율을 높였습니다.

4. 2차 개선: Web Worker를 통한 연산 분리​

렌더링은 가벼워졌지만, 스트림 데이터를 수신하고 바이너리에서 JPEG 프레임을 찾아내는(Boundary Parsing) 작업은 여전히 메인 스레드의 몫이었습니다. 초당 수백만 바이트의 데이터를 실시간으로 문자열 검색하는 것은 CPU에 큰 부담을 줍니다.

이를 해결하기 위해 Web Worker를 도입하여 "데이터 처리는 백그라운드에서, 화면 그리기는 메인에서" 라는 역할 분담을 적용했습니다.

데이터 전송 최적화 (Transferable Objects)​

워커에서 메인 스레드로 대량의 이미지를 보낼 때 데이터를 복제(Copy)하면 심각한 성능 저하가 발생합니다. 저희는 Transferable Objects 기능을 사용하여 데이터 복사 없이 메모리의 소유권만 이전하는 Zero-copy 방식을 택했습니다.

5. 최종 개선: OffscreenCanvas의 도입​

하지만 여전히 최종 드로잉 작업은 메인 스레드에서 일어나야 했습니다. 마지막 퍼즐 조각은 OffscreenCanvas였습니다. 이 API를 사용하면 캔버스의 제어권 자체를 워커로 넘길 수 있습니다.

메인 스레드가 블락되어도(왼쪽) 워커에서 동작하는 이미지 처리는 중단 없이 실시간으로 반영됩니다. (출처: 카카오 테크 블로그)

렌더링 부하 0%를 향하여​

transferControlToOffscreen()을 통해 제어권을 넘긴 후, 워커 내부에서 직접 렌더링을 수행합니다.

// @src/entities/devices/components/stream/mjpeg.worker.ts
const bitmap = await createImageBitmap(blob);
if (ctx && canvas) {
  // 워커가 직접 캔버스에 드로잉 (메인 스레드 간섭 0%)
  ctx.drawImage(bitmap, 0, 0);

  if (config.showArea && config.area) {
    drawPolygonArea(ctx, config.area); // 영역 표시 로직도 워커에서 수행
  }
}
bitmap.close();

이 구조에서는 메인 스레드에 아무리 무거운 작업이 걸려도, 스트리밍 영상은 별도의 스레드에서 끊김 없이 독립적으로 재생됩니다.

🌐 브라우저 호환성 및 자동 분기 처리​

OffscreenCanvas는 강력한 기능을 제공하지만, 브라우저마다 지원 여부가 다릅니다. EVA 서비스에서는 사용자 환경을 고려하여 이를 자동으로 감지하고 분기 처리하도록 구현되었습니다.

EVA의 맞춤 렌더링 전략:

• 최신 브라우저: OffscreenCanvas를 활성화하여 메인 스레드 부하를 0%로 유지합니다.
• 하위 브라우저(예: Safari 15 이하): 기능을 감지하여 1차 개선안인 메인 스레드 Canvas 렌더링 방식으로 자동 전환(Fallback)합니다.

이를 통해 어떤 브라우저 환경에서도 끊김 없는 스트리밍 경험을 보장합니다.

6. 추가 최적화: 버퍼 재사용과 파싱 속도 향상​

성능은 디테일에서 결정됩니다. 워커 내부 로직에서도 몇 가지 최적화를 더했습니다.

1. 고정 버퍼 재사용: 매번 새로운 Uint8Array를 생성하는 대신, 고정된 크기의 버퍼를 재사용하고 copyWithin을 사용하여 데이터를 관리했습니다. 이는 가비지 컬렉션(GC) 발생 빈도를 대폭 줄여줍니다.
2. indexOf 기반 고속 파싱: 바이너리 데이터에서 매칭 바이트를 찾을 때 단순 루프 대신 내장 indexOf를 활용하여 불필요한 바이트 검사를 건너뛰도록 구현했습니다. 단순 연산만으로도 프레임 드랍을 획기적으로 줄일 수 있었습니다.

7. 결론: 더 견고해진 EVA 모니터링 환경​

이번 최적화 작업을 통해 EVA 서비스는 다음과 같은 결과를 얻었습니다.

• 메모리 안정성: 장시간 구동 시에도 메모리 점유율이 일정하게 유지되며 OOM 오류가 사라졌습니다.
• UI 반응성: 고해상도 스트리밍 중에도 메뉴 이동, 버튼 클릭 등 UI 조작이 네이티브 앱 수준으로 부드러워졌습니다.
• 안정적인 프레임: 스레드 분리를 통해 네트워크 지연이나 메인 스레드 부하와 무관하게 일정한 프레임 레이트를 확보했습니다.

프론트엔드 성능 최적화의 핵심은 **"브라우저의 메인 스레드를 얼마나 자유롭게 유지하느냐"**에 있다는 것을 다시 한번 체감할 수 있는 프로젝트였습니다.

긴 글 읽어주셔서 감사합니다!

참고 기술 요약​

• Web Workers API: 백그라운드 스레드에서 연산 수행
• OffscreenCanvas: 메인 스레드로부터 독립된 렌더링
• createImageBitmap: 비동기 이미지 디코딩 및 명시적 메모리 관리
• Transferable Objects: 복사 비용 없는 고속 데이터 전송

참고 링크​

• 카카오 테크 블로그 - OffscreenCanvas
• MDN - Web Workers
• MDN - OffscreenCanvas
• MDN - createImageBitmap
• MDN - Transferable Objects

EVA는 요구사항 기반 개발 과정에서도 AI Agent를 핵심 실행 주체로 활용합니다.

현장에서 해결이 필요한 문제나 고도화 아이디어가 생기면, 담당자는 eva-req@spectrabrain.ai 으로 메일을 보내는 것만으로 프로세스를 시작할 수 있습니다.

여기서 중요한 점은 메일 작성 자체가 복잡하지 않다는 것입니다.

요청자는 형식을 맞추는 데 시간을 쓰기보다, 실제로 불편했던 지점과 기대하는 개선 방향을 짧게 전달하면 됩니다. 그 이후의 정제, 분석, 우선순위화는 자동화된 Agent 워크플로우가 이어받아 처리합니다.

1) 간단히 작성한 메일도 Agent가 구조화한다​

요청자는 형식보다 맥락에 집중해 메일을 보냅니다. Review Agent는 이 입력을 바로 실무에서 다룰 수 있는 요구사항 형태로 정리합니다.

정제 과정에서 Agent는 누락된 맥락을 보완하고, 불명확한 표현을 개발 검토가 가능한 언어로 바꿉니다. 즉, 사람의 자유로운 입력을 시스템이 이해할 수 있는 구조로 변환하는 단계라고 볼 수 있습니다.

이 단계가 끝나면 요구사항은 단순한 메모가 아니라, 우선순위 판단과 구현 검토가 가능한 형태로 정리됩니다.

2) EVA 매뉴얼과 로직 문서를 기반으로 분석​

정제된 요구사항은 EVA의 내부 지식과 결합되어 분석됩니다.

• 사용자 매뉴얼 (User Manual)
• 로직 문서 (Technical/Logic Documentation)

Review Agent는 해당 문서를 바탕으로 어떤 영역이 영향을 받는지, 어떤 방식으로 해결할 수 있는지, 그리고 무엇을 먼저 처리해야 하는지를 1차적으로 분석합니다.

• 영향 받는 기능/로직
• 기존 기능으로 대응 가능한지 여부
• 신규 구현 필요 여부
• 기술적 리스크와 기대 효과
• 개발 우선순위

이 과정을 거치면 요구사항은 “무엇이 문제인지”를 설명하는 수준을 넘어, “어떻게 해결할 수 있는지”와 “왜 지금 처리해야 하는지”를 함께 담은 실행 가능한 개발 단위로 전환됩니다.

3) Release 이후에도 이어지는 Agent 루프​

구현이 끝나고 Release가 이루어지면, Release Agent가 변경사항을 기준으로 매뉴얼과 로직 문서를 업데이트합니다. 이렇게 최신화된 문서는 다음 요구사항 분석의 기준 데이터가 되고, Agent는 제품이 발전하는 속도에 맞춰 더 정확한 판단을 내리게 됩니다.

EVA의 요구사항 운영에서 핵심은 이 과정이 한 번으로 끝나지 않는다는 점입니다. 요구사항 수집부터 분석, 개발, Release, 문서 갱신까지가 단절 없이 이어지며 하나의 자동화된 루프를 구성합니다.

이 루프를 통해 Agent는 다음과 같은 신호를 지속적으로 학습합니다.

• 어떤 요구사항이 실제로 구현되었는지
• 어떤 방식으로 해결되었는지
• 어떤 표현이 부정확했는지

Review Agent는 입력을 구조화하고 분석하며 우선순위를 제시하고, Release Agent는 구현 결과를 문서에 반영해, 다음에 들어오는 요구사항을 더 정확하게 분석할 수 있도록 돕습니다.

그래서 실제 운영에서는 다음과 같은 변화가 나타납니다.

• 요구사항 분석 정확도 향상
• 중복 요청 자동 정리
• 문서 품질 개선

결론: Agent는 기능이 아니라 운영 프로세스다​

EVA에서 Agent는 특정 업무를 부분적으로 돕는 보조 기능에 머물지 않습니다. 요구사항이 메일로 접수되는 순간부터 내용을 정제하고, 매뉴얼과 로직 문서를 바탕으로 분석하고, 우선순위를 도출하고, Release 이후 다시 문서를 갱신하는 전 과정에 관여합니다.

즉, EVA의 요구사항 관리는 사람이 일일이 형식을 맞추고 후속 정리를 반복하는 방식이 아니라, AI Agent가 흐름 전체를 이어받아 관리하기 쉬운 형태로 정리하고 다음 의사결정에 필요한 정보까지 축적해 나가는 구조에 가깝습니다.

결국 요구사항은 단발성 요청으로 소모되지 않고, 제품의 발전 방향을 더 정확하게 결정할 수 있도록 돕는 운영 데이터로 쌓이게 됩니다. EVA가 Agent를 활용하는 이유는 단순히 자동화를 늘리기 위해서가 아니라, 요구사항 관리 자체를 지속적으로 학습하고 개선해 나가는 프로세스로 만들기 위해서입니다.

최근 데이터센터 화재는 단순한 시설 피해를 넘어 서비스 중단에 따른 천문학적인 배상 책임을 야기하고 있습니다.

👉 SK C&C 판교 데이터센터 화재 (2022): 리튬이온 UPS 배터리실에서 시작된 불씨는 카카오 등 주요 서비스 장애로 이어졌으며, 피해 규모는 수천억 원에 달하는 것으로 추정됩니다.

👉 프랑스 OVHcloud 화재 (2021): UPS 전력 장비 발화로 발생한 이 사고는 약 1,500억 원(€105M)의 총 피해를 냈으며, 이 중 보험금으로 지급된 금액만 약 800억 원(€58M)에 달해 보험사의 인수 부담을 극대화했습니다.

이러한 대형 사고들은 AI 시대의 데이터센터가 기존의 물리적 보안 수준으로는 통제 불가능한 리스크를 안고 있음을 시사합니다.

😲 2. 데이터센터 보험 구조와 AI GPU 센터의 ‘보험료 급등’ 원인​

데이터센터 보험은 일반적으로 Property(건물 및 서버), Business Interruption(기업 휴지), Cyber Liability(사이버 책임), General Liability(일반 배상)를 묶은 패키지 형태입니다.

👉 자산 가치 비례 보험료율 통상적으로 Property 보험료율은 자산 가치의 0.2% ~ 0.5% 수준이지만, 최근 AI 데이터센터는 다음과 같은 이유로 리스크 등급이 상향 조정되어 보험료가 급격히 상승하고 있습니다.

👉 고밀도(High-Density) 서버의 위험성 AI GPU 클러스터는 일반 서버 대비 전력 밀도가 비약적으로 높습니다. 이는 곧 화재 확률의 산술적 증가를 의미합니다.

😎 3. 보험사 언더라이팅(Underwriting) 핵심 체크리스트 분석​

글로벌 보험 브로커(Aon, Marsh, FM Global 등)는 시설 규모보다 '사고 가능성을 낮추는 기술적 장치'를 중심으로 위험을 평가합니다. EVA는 이 평가 항목들에서 압도적인 가산점을 확보할 수 있는 솔루션입니다.

👉 전력 및 전기 설비 리스크 (Power Infrastructure)
현황: 데이터센터 화재의 40~50%가 전력 설비에서 기인합니다. 특히 리튬이온 배터리의 열폭주(Thermal Runaway)는 보험료 상승의 주범입니다.
🌈 EVA의 역할: 배터리 셀 단위의 미세한 온도 변화나 열화상 징후를 실시간 감지하여, 리튬 배터리 리스크를 획기적으로 낮춥니다.

👉 화재 감지 및 소화 시스템의 고도화
현황: 보험사는 초기 연기 감지나 가스 소화 시스템 유무를 최우선으로 봅니다.
🌈 EVA의 역할: AI 시각 지능을 통해 불꽃이나 연기를 즉각 인지함으로써 감지 속도를 수 초 내로 단축합니다.

👉 운영 및 관리 리스크 (Human Error)
현황: 보험사는 24/7 운영 관제 체계와 열화상 점검 여부를 매우 중요하게 평가합니다.
🌈 EVA의 역할: 관리자의 육안 점검에 의존하던 체계를 AI 자동 관제로 전환합니다.

❣️ 4. EVA 도입의 경제적 기대효과: Risk Engineering 중심의 접근​

보험 시장은 이제 사고 후 보상에서 미래 사고 가능성을 낮추는 'Risk Engineering' 시장으로 변모했습니다. EVA 같은 AI 안전 솔루션은 보험사와 가입자 모두에게 Win-Win 구조를 제공합니다.

👉 보험료 직접 할인 (15% ~ 30%)
리스크 관리 시스템이 잘 갖춰진 경우, 실제 보험료율을 15%에서 최대 30%까지 할인받는 사례가 존재합니다. 수천억 원 가치의 데이터센터 자산을 고려할 때, 이는 솔루션 도입 비용을 상회하는 직접적인 재무적 이익입니다.

👉 핵심 리스크 통제 포인트 (5대 핵심 항목)
EVA는 보험료를 좌우하는 실무적 핵심 5가지 항목을 모두 충족합니다.

• 배터리 시스템(UPS) 상시 모니터링: 열폭주 사전 대응
• 전력 밀도 대응: AI GPU 서버의 케이블 및 PDU 과열 집중 감시
• 지능형 화재 감지: 시각적 데이터 기반의 초고속 알람
• 24시간 무중단 관제: 위험 행동 및 안전 규정 위반, 작업자 실수
• 사고 대응 시간 단축: 알람 발생부터 조치까지의 프로세스 효율화

🥰 5. AI Safety System이 곧 데이터센터 비즈니스 연속성입니다​

데이터센터 운영사 입장에서 EVA는 단순히 '보안용 CCTV'가 아닙니다.
재무적 가치: 보험료 절감 및 사고 시 발생하는 수천억 원 규모의 비즈니스 중단(Business Interruption) 손실 방지
운영적 가치: 초고밀도 AI 서버 환경에서의 전력 및 화재 리스크 관리 표준 확립
대외적 신뢰: 보험사의 엄격한 리스크 평가를 통과한 '안전한 데이터센터'라는 브랜드 가치 확보
AI Safety System → Risk Reduction → Insurance Discount 로 이어지는 선순환 구조를 통해, 데이터센터를 가장 경제적이고 안전하게 운영할 수 있습니다.

오늘은 많은 분이 궁금해하시는 GPU 모델을 NPU로 옮기는 '포팅(Porting)' 과정과 그 뒤에 숨겨진 기술적 과제들을 공유하고자 합니다.

1. GPU 모델의 NPU 포팅(Porting) 과정​

NPU는 특정 연산에 최적화된 구조를 갖추고 있어, 새로운 모델이 출시되어도 즉시 실행하기 어렵습니다. 따라서 하드웨어의 잠재력을 최대한 이끌어내기 위해 다음과 같은 필수 단계를 거칩니다.

• 모델 변환 (Model Conversion) PyTorch나 TensorFlow로 개발된 원본 모델을 NPU가 이해할 수 있는 실행 형식으로 변환합니다. Rebellions의 ATOM Compiler를 통해 모델의 연산 그래프(Computational Graph)가 분석되고, NPU 아키텍처에 맞는 .rbln 실행 형태로 변환됩니다.

• NPU 최적화 컴파일 (Optimizing Compilation) Rebellions SDK(RBLN SDK)의 컴파일러를 통해 하드웨어 맞춤형 실행 파일로 컴파일합니다.

  • 그래프 최적화: 불필요한 연산을 제거하고 데이터 흐름을 재배치합니다.
  • 연산 융합 (Operator Fusion): 여러 작은 연산을 하나의 큰 커널로 합쳐 메모리 접근 횟수와 오버헤드를 줄입니다.
  • 데이터 레이아웃 최적화: NPU 메모리 구조에 맞춰 텐서 배치를 변경하여 접근 속도를 높입니다.

• 양자화 (Quantization) NPU 아키텍처에 맞는 연산 정밀도를 적용하여 성능과 메모리 효율을 개선합니다. EVA의 경우 FP16 기반 추론 환경을 기준으로 안정적인 성능을 확보하도록 최적화했습니다.

• vLLM 통합 및 검증 최적화된 모델을 vLLM-RBLN 서빙 프레임워크에 이식합니다. TTFT(첫 토큰 생성 시간)와 Throughput(처리량) 등 핵심 지표를 측정하며 GPU 환경과 비교 검증을 수행합니다.

2. EVA Application 최적화 및 기술적 과제 해결​

포팅된 파운데이션 모델 위에 실질적인 서비스인 EVA Application을 올리는 과정에서는 다음과 같은 구체적인 최적화 로드맵을 실행하고 있습니다.

• EVA Vision 최적화 (1:1 Mapping & Batching) NPU 코어와 Vision Worker를 1:1로 매핑하여 컨텍스트 스위칭 오버헤드를 제거했습니다. 또한 Continuous Batching 기술을 응용하여 수백 대의 카메라 데이터를 지연 없이 실시간으로 처리할 수 있는 기반을 만들고 있습니다.

• EVA Agent 최적화 (VLM 부하 절감) VLM(Vision-Language Model)의 입력 해상도를 1280x720으로 표준화하고, 2단계 추론(Two-Stage Reasoning) 구조를 활용해 불필요한 VLM 호출 횟수를 최소화했습니다. 이는 고비용 연산인 Vision Encoder의 부하를 즉각적으로 줄여줍니다.

• 시스템 메모리 관리 및 KV Cache 최적화 Rebellions와 협력하여 vLLM-RBLN 인스턴스의 메모리 사용 패턴을 분석하고, 페이지 단위 메모리 관리 구조를 기반으로 자원 활용 효율을 개선하고 있습니다. 이를 통해 동일한 하드웨어 환경에서도 더 많은 시각 데이터를 안정적으로 처리할 수 있도록 최적화를 진행하고 있습니다.

• VLM Vision Encoder 병렬 처리 VLM 추론에서 큰 연산 비중을 차지하는 Vision Encoder 단계의 병렬 처리 구조를 개선하고 있습니다. Vision Encoder 연산이 여러 NPU 코어에 효율적으로 분산 실행되도록 최적화하여 VLM 서빙 처리량 향상을 목표로 하고 있습니다.

3. 결론: PoC를 넘어선 상용 제품으로의 진화​

우리는 스트레스 테스트를 통해 발견된 기술적 과제들을 하나씩 해결해 나가며, 리소스를 최대 활용하는 최적화 작업을 지속하고 있습니다. Rebellions와의 긴밀한 협력을 통한 Vision Encoder 병렬 처리, 그리고 EVA 플랫폼의 지능형 스케줄러 개발에 이르기까지 모든 단계는 'EVA on NPU' 솔루션을 단순한 기술 검증(PoC) 수준을 넘어 상용 제품으로 완성시키는 과정에 있습니다.

결국 AI 서비스의 성공은 경제성, 확장성, 서비스 품질이라는 세 가지 조건을 모두 충족하는 데 있습니다. EVA는 앞으로도 최신 NPU 기술을 적극 수용하여, 고객에게 가장 경쟁력 있는 TCO와 압도적인 성능을 갖춘 Physical AI 플랫폼의 글로벌 표준을 제시하겠습니다.

최근 Vision-Language Model(VLM)은 단일 이미지에 대한 이해 능력에서 매우 높은 성능을 보여주고 있습니다. 대규모 멀티모달 모델들은 다중 이미지와 텍스트 조건을 함께 처리하는 구조를 제시하며, 멀티 프레임 기반 추론 가능성을 이론적으로 확장해왔습니다.

그러나 실제 산업 현장의 탐지 시나리오는 연구 환경과 다르게 훨씬 복잡합니다. 단일 프레임으로는 충분해 보이던 문제도, 실제 운영 환경에서는 다양한 오탐과 경계 사례를 만들어냅니다.

예를 들어, 사람이 바닥에 누워 있는 장면이 있습니다. 그 순간만 보면 쓰러짐으로 판단하기 쉽습니다. 하지만 바로 직전 프레임에서는 스트레칭을 하고 있었을 수도 있고, 작업 도중 잠시 자세를 바꾼 것일 수도 있습니다.

야간 환경에서는 렌즈 플레어나 조명 반사, 빛 번짐 현상이 화재의 색상 패턴과 유사하게 나타나 단일 이미지 기준으로는 화재로 오탐되는 경우도 존재합니다. 사람조차 한 장의 스냅샷만 보고는 확신하기 어려운 상황에서, 모델에게 단일 프레임만을 제공하는 것은 구조적으로 한계를 가질 수밖에 없습니다.

이러한 사례는 공통적으로 “맥락 부족”이라는 문제를 공유합니다.

시간은 가장 강력한 컨텍스트다​

탐지 시나리오 중에는 본질적으로 시간적 흐름을 전제로 하는 것들이 존재합니다.

배회는 일정 시간 이상 동일 공간에 머무르는 패턴을 봐야 정의할 수 있습니다. 장시간 방치 역시 특정 물체가 놓인 뒤 일정 시간 이상 변화가 없다는 조건이 필요합니다.

이러한 문제를 단일 프레임으로 해결하려는 시도는 구조적으로 어렵습니다. “상태”가 아니라 “변화”를 봐야 하기 때문입니다.

우리는 이를 세 가지 컨텍스트 수준으로 구분했습니다.

• 단일 이미지 기반 판단
• 짧은 구간의 멀티 이미지 기반 순간적 맥락 판단
• 시간 흐름을 포함한 멀티 이미지 기반 Temporal 판단

실제 운영 환경에서는 이 세 가지가 혼재합니다. 어떤 시나리오는 단일 프레임으로 충분하고, 어떤 시나리오는 몇 초 간격의 연속 프레임이 필요하며, 또 어떤 경우는 수십 초 이상의 흐름을 봐야 합니다.

EVA의 Multi Frame Manager​

EVA에서는 사용자가 작성한 시나리오를 단순한 텍스트 조건으로 보지 않습니다. 해당 시나리오가 요구하는 “맥락 수준”을 분석한 뒤, 그에 맞는 프레임 수집 전략을 결정합니다.

예를 들어, 쓰러짐 탐지라면 단일 프레임이 아니라 전후 몇 초 구간을 포함한 멀티 이미지가 필요합니다. 반면 장시간 방치는 슬라이딩 윈도우 기반으로 일정 시간 동안의 프레임을 지속적으로 수집해야 합니다.

이 과정을 담당하는 모듈이 Multi Frame Manager입니다. 이 모듈은 시나리오 특성에 따라 아래의 사항을 동적으로 결정합니다.

• 필요한 프레임 수
• 수집 간격
• 유지 시간
• 이벤트 트리거 확장 여부

수집된 이미지는 단순히 나열되지 않습니다. 시간 순서가 명확히 정렬된 상태로 VLM에 전달되며, 모델이 프레임 간 변화를 비교하도록 유도하는 시스템 프롬프트가 함께 적용됩니다.

멀티 이미지 기반 VLM 추론 전략​

멀티 프레임 입력이 들어오면 VLM은 단순히 각 장면의 객체를 개별적으로 검출하는 데 그치지 않습니다. EVA에서는 멀티 이미지를 독립적인 데이터 집합이 아닌, 하나의 연속된 흐름(Context)으로 해석하도록 추론 구조를 설계했습니다.

이를 위해 프레임들은 다음과 같은 전략을 통해 모델에 전달됩니다.

• 시간 순서 기반 프레임 정렬: 과거에서 현재로 이어지는 시계열 데이터를 구성하여 사건의 인과관계를 파악합니다.
• 비교 유도 시스템 프롬프트: "이전 프레임 대비 변화된 지점을 식별하라"는 지시어를 통해 프레임 간 상관관계를 분석합니다.
• 시간적 맥락 추론 (Temporal Reasoning): 단편적인 스냅샷 판단이 아닌, 시간의 흐름에 따른 상태 변화를 논리적으로 도출합니다.

Case Study: 오탐을 줄이는 시간적 맥락의 힘​

아래의 사례는 단일 프레임의 정보가 멀티 프레임의 '맥락'을 통해 어떻게 정확하게 정정되는지 보여주는 대표적인 예시입니다.

• Single Image: 사람이 바닥에 낮게 엎드린 자세로 정지해 있습니다. 이 순간만 본 VLM은 상황을 "사람이 쓰러져 있음(Collapse)"으로 오판할 확률이 매우 높습니다.
• Multi-Image: 이어지는 프레임에서 사람이 팔을 움직여 휴대폰을 조작하고, 고개를 숙여 화면을 응시하는 미세한 움직임이 포착됩니다.
• 결과: EVA는 시간적 맥락 추론을 통해 이를 "앉아서 휴대폰 사용 중으로 판단" 으로 최종 결론 내립니다.

이처럼 모델이 각 프레임을 개별적으로 판단하는 것이 아니라 프레임 간 차이를 비교하며 상황을 이해하도록 유도하는 것이 핵심입니다.

쓰러짐과 같은 고위험 탐지의 경우, 모델은 다음과 같은 점진적 상황 구체화 (Progressive Situation Refinement) 과정을 거칩니다.

1. 초기 상태 식별: 대상 객체(사람 등)와 초기 시각적 특징(누운 자세 등) 확인
2. 동적 변화 감지: 이전 프레임 대비 신체 각도의 유의미한 변화나 자발적인 움직임 추적
3. 상태 지속성 검증: 변화된 자세가 외부 충격에 의한 정지인지, 의도적인 동작이 수반되는지 판단
4. 최종 문맥 확정: 유사한 시각적 패턴을 가진 노이즈(Noise)와 실제 이벤트(Event)를 정교하게 구분

이러한 시간적 맥락 추론 구조는 단일 이미지 기반 판단에서 발생하는 수많은 엣지 케이스 오탐을 획기적으로 줄여주며, 실제 운영 환경에서 훨씬 안정적인 결과를 제공합니다.

이처럼 모델이 각 프레임을 개별적으로 판단하는 것이 아니라 프레임 간 차이를 비교하며 상황을 이해하도록 유도하는 것이 핵심입니다.

쓰러짐이나 화재와 같은 고위험 탐지의 경우, 모델은 다음과 같은 점진적 상황 구체화 과정을 거칩니다.

1. 초기 상태 식별: 대상 객체(사람, 차량 등)와 초기 시각적 특징(누운 자세, 붉은 빛 등) 확인
2. 동적 변화 감지: 이전 프레임 대비 객체의 이동 궤적이나 추가적인 등화 장치 점등 등의 변화 추적
3. 상태 지속성 및 인과관계 검증: 일시적인 빛 번짐인지, 자발적인 움직임에 의한 상태 변화인지 인과관계를 판단
4. 최종 문맥 확정: 유사한 시각적 패턴을 가진 노이즈(Noise)와 실제 이벤트(Event)를 정교하게 구분

이러한 시간적 맥락 추론 구조는 단일 이미지 기반 판단에서 발생하는 수많은 엣지 케이스(Edge Case) 오탐을 획기적으로 줄여주며, 실제 운영 환경에서 훨씬 안정적인 결과를 제공합니다.

결과적으로 EVA의 멀티 프레임 추론 구조는 단순히 입력 이미지를 늘리는 방식이 아니라, 시간적 변화(temporal change)를 모델의 추론 과정에 직접 포함시키는 접근 방식이라고 볼 수 있습니다.

멀티 프레임의 대가: 연산 비용​

정확도 향상에는 비용이 따릅니다.

멀티 프레임 기반 추론은 더 많은 시각 정보를 활용할 수 있다는 장점이 있지만, 동시에 연산 비용 증가라는 문제를 동반합니다. 멀티모달 모델에서 이미지 입력은 일반적으로 Vision Encoder를 통해 임베딩으로 변환된 후 LLM으로 전달되며, 이 과정은 비교적 높은 연산 비용을 요구합니다.

특히 멀티 프레임 분석에서는 다음과 같은 상황이 자주 발생합니다.

• 연속된 프레임 중 동일하거나 매우 유사한 이미지가 반복되는 경우
• 여러 요청이 동일한 카메라 프레임을 참조하는 경우
• 동일한 이미지를 기반으로 여러 질의를 수행하는 경우

이러한 경우 Vision Encoder가 동일한 이미지를 반복적으로 처리하게 되면서 불필요한 연산이 발생할 수 있습니다.

EVA에서는 이러한 문제를 해결하기 위해 vLLM에서 제공하는 Encoder Cache 기능을 최대한 활용하는 구조로 개발되었습니다.

vLLM은 멀티모달 입력 처리 시 Vision Encoder 결과를 캐싱하고 재사용할 수 있도록 Encoder Cache Manager 구조를 제공합니다.

• https://docs.vllm.ai/en/latest/api/vllm/v1/core/encoder_cache_manager/

이를 활용하면 동일한 이미지 입력에 대해 이미 생성된 encoder embedding을 재사용할 수 있어 Vision Encoder 연산을 반복 수행하지 않아도 됩니다.

EVA에서는 이러한 캐싱 기능을 효과적으로 활용하기 위해 Agent 레이어에서 요청을 관리하는 구조를 적용했습니다.

Agent는 다음과 같은 방식으로 요청을 조정합니다.

• 동일 이미지 입력이 재사용될 수 있도록 요청을 구성
• 캐시 활용이 가능하도록 이미지 단위를 기준으로 요청을 관리
• 불필요한 중복 인코딩이 발생하지 않도록 요청 흐름을 최적화

이를 통해 멀티 프레임 기반 분석 환경에서도 Vision Encoder 연산을 최소화하면서 GPU 자원을 보다 효율적으로 활용할 수 있습니다.

결론​

멀티 프레임 기반 VLM 추론은 단일 이미지 기반 분석보다 상황 이해 능력과 탐지 정확도를 크게 향상시킬 수 있는 접근 방식입니다.

그러나 프레임 수가 증가할수록 Vision Encoder 연산량이 크게 증가하기 때문에 성능 향상뿐만 아니라 연산 효율성과 인프라 비용을 함께 고려한 설계가 중요합니다.

EVA에서는 이러한 문제를 해결하기 위해 vLLM의 Encoder Cache 기능을 적극적으로 활용하고, 이를 효과적으로 사용할 수 있도록 Agent 레이어에서 요청을 관리하는 구조를 적용했습니다.

이러한 구조를 통해 멀티 프레임 분석 환경에서도 추론 성능을 유지하면서 불필요한 연산을 줄이고, GPU 자원 활용 효율과 인프라 운영 비용 측면에서도 지속적인 개선을 이루고 있습니다.

해당 기능은 EVA v2.6.0 부터 제공됩니다.

이제 AI의 승부처는 "얼마나 거대하고 성능 높은 파운데이션 모델(Foundation Model)인가"가 아니라, "그 모델을 활용해 실제 환경에서 얼마나 복잡한 업무를 수행(Application)할 수 있는가"로 옮겨왔다는 점입니다.

패러다임의 전환: 성능에서 실행력으로​

• 기존 패러다임: "얼마나 똑똑한가?" - 지금까지 AI 업계는 주로 파운데이션 모델(Foundation Model)의 규모와 성능에 집중해왔습니다. GPT-4, Claude, Gemini 등 거대 언어 모델들은 더 많은 파라미터, 더 큰 데이터셋, 더 높은 벤치마크 점수를 경쟁의 핵심으로 삼았습니다. 이는 "얼마나 똑똑한 AI인가?"라는 질문에 답하려는 시도였습니다.

• 새로운 패러다임: "얼마나 일을 대신 수행할 수 있는가?" - 하지만 OpenClaw의 등장은 완전히 다른 질문을 던집니다. "그 모델을 활용해 실제 환경에서 얼마나 복잡한 업무를 수행(Application)할 수 있는가?" 이제 AI의 가치는 단순한 지능 수준이 아니라, 실제 컴퓨팅 환경에서의 실행 능력으로 평가받게 됩니다.

OpenClaw의 접근법​

• 실시간 화면 해석과 상황 인식 : 사용자의 화면을 실시간으로 해석하는 능력은 AI가 단순한 텍스트 처리를 넘어 시각적 컨텍스트를 이해하고 반응할 수 있음을 의미합니다. 이는 멀티모달 AI의 실용적 구현체라 할 수 있습니다.
• 직접적인 애플리케이션 제어 : 가장 혁신적인 부분은 AI가 다양한 애플리케이션을 직접 제어한다는 점입니다. 이는 AI가 단순한 조언자나 정보 제공자를 넘어 실제 업무의 실행자로 진화했음을 보여줍니다.

EVA의 접근법: 물리적 환경에서의 실행 중심 AI​

EVA(Evolved Vision Agent)는 산업 현장이라는 거친 현실 세계에서 동일한 '실행의 가치'를 증명하고 있습니다.

• 실시간 현장 해석과 시각적 추론(Visual Reasoning) EVA는 CCTV 스트리밍을 통해 현장의 맥락을 읽습니다. 단순히 객체를 탐지하는 것을 넘어, "저 작업자가 왜 위험한가?", "저 구역에 지금 사람이 있어도 되는가?"와 같은 고차원적 질문에 답합니다. 이는 VLM(Vision Language Model)을 산업 현장에 최적화하여 구현한 멀티모달 AI 서비스입니다.

• 직접적인 물리적 대응과 제어(Physical Action Trigger) EVA는 위험 상황에서 물리적 액션을 직접 트리거합니다. 경중에 따라 담당자에게 즉시 알림을 보내는 것은 물론, 현장의 사이렌을 울리거나 위험 공정의 설비를 직접 멈추는 '물리적 통제'까지 연결됩니다. AI가 판단에서 멈추지 않고 사고를 막는 '최종 실행자'로 기능하는 것입니다.

산업 전반에 미치는 영향: AI 패러다임의 대전환​

개발 방향성의 근본적인 변화 AI 기술의 발전 방향이 과거와는 확연히 다른 궤도로 진입하고 있습니다. 기존의 개발 방식이 더 거대한 파라미터를 가진 모델을 구축하고 점수화된 성능 지표(Benchmark)를 높이는 데 치중했다면, 이제는 '실질적인 효용성'이 그 중심에 서게 되었습니다. 단순히 똑똑한 모델을 만드는 것을 넘어, AI가 실제 사용자의 환경에서 얼마나 완성도 있게 작업을 완수할 수 있는지가 핵심 지표가 된 것입니다. 즉, 모델 자체의 지능보다는 사용자의 고유한 워크플로우에 얼마나 깊숙이 통합되어 실질적인 도움을 줄 수 있느냐가 향후 AI 개발의 새로운 나침반이 될 것입니다.

이러한 패러다임의 변화는 AI 기업들의 경쟁력을 평가하는 잣대 또한 재정의하고 있습니다. 단순히 기술력을 과시하는 시대를 지나, 이제 시장에서의 우위는 다음의 세 가지 핵심 요소에 의해 결정될 것입니다.

• 첫째는 실행의 안정성입니다. 아무리 뛰어난 지능을 가졌더라도 복잡한 다단계 작업을 중간에 끊김 없이, 그리고 오류 없이 얼마나 안정적으로 수행해낼 수 있는지가 기업의 신뢰도를 결정짓게 됩니다.
• 둘째는 통합 능력입니다. AI가 독자적으로 존재하는 것이 아니라, 사용자가 기존에 사용하던 다양한 소프트웨어 및 시스템과 얼마나 유기적이고 자연스럽게 맞물려 돌아가는지가 중요한 차별화 포인트가 됩니다.
• 마지막으로 가장 중요한 것은 사용자 경험(UX)입니다. 기술적 화려함보다는 실제 업무 현장에서 효율성을 얼마나 직관적으로 향상시키고, 사용자의 피로도를 줄여주는지가 AI 서비스의 성패를 가르는 최종적인 기준이 될 것입니다.

실행 중심 AI 시대의 개막​

OpenClaw가 제시하는 방향성은 단순한 기술적 진보를 넘어, AI 산업 전체의 패러다임 전환을 의미합니다. 이제 AI의 가치는 "얼마나 똑똑한가"가 아니라 "얼마나 유용한 일을 실제로 해낼 수 있는가"로 측정될 것입니다. 이러한 변화는 AI 개발자, 기업, 그리고 사용자 모두에게 새로운 기회와 도전을 제시합니다. 앞으로의 AI 경쟁은 벤치마크 점수가 아닌 실제 업무 환경에서의 성과로 판가름날 것이며, 이는 AI가 진정으로 인간의 삶을 개선하는 도구로 자리잡는 중요한 전환점이 될 것입니다.

본 포스트에서는 텍스트-비디오 검색 분야의 최신 연구인 Q₂E (Query-to-Event Decomposition)[1] 논문을 참고하여, VLM이 단일 화면 내의 복합적인 시나리오를 깊이 있게 인지하도록 만드는 '시나리오 분해(Scenario Decomposition)' 기법을 소개합니다.

1. 🚀 문제 : VLM의 인지의 병목​

EVA Agent는 복잡한 도심 도로나 다중 이용 시설을 24시간 감시해야 합니다. 초기에는 VLM의 범용적인 능력을 믿고, 인간처럼 한 번에 모든 상황을 파악하길 기대했습니다.

[초기 접근: 통합 질의 (Unified Query)]
"이 CCTV 화면을 보고 화재, 사람 쓰러짐, 교통사고, 긴급차량 진입 여부를 모두 확인해서 알려줘."

하지만 결과적으로 모델은 '선택적 인지' 의 한계를 드러냈습니다. 예를 들면, 화면 중앙의 큰 버스는 잘 보지만, 그 뒤편에서 발생하는 화재 징후나 쓰러진 사람은 단순히 배경으로 치부해버릴 수 있습니다.

이는 모델의 Attention 메커니즘이 여러 타겟(Target)으로 분산되면서, 중요한 위험 신호에 대한 Contextual Understanding(맥락적 이해) 깊이가 얕아지기 때문에 발생하는 문제입니다.

2. 💡 해결책: Q₂E 기반의 인지 능력 확장​

이 문제를 해결하기 위해 우리는 "복잡한 사건을 쪼개면(Decompose) 이해도가 높아진다"는 Q₂E 논문의 핵심 철학을 도입했습니다.

2.1. 논문의 통찰 (Q₂E: Query-to-Event)​

논문은 "산불"이라는 단어 하나로 검색하는 것보다, 이를 "전조 -> 진행 -> 결과"라는 사건의 흐름으로 분해해서 모델에 주입했을 때, 모델이 해당 사건을 훨씬 더 풍부하게 이해하고 찾아낸다는 것을 증명했습니다.

2.2. EVA Agnet 도입 : Scenario Decomposition (시나리오 분해)​

우리는 이 개념을 "Multi-Scenario Understanding(다중 시나리오 이해)"로 확장했습니다. VLM에게 한 번에 넓게 보라고 하는 대신, 각 시나리오별로 깊게 볼 수 있는 '관점'을 부여하는 것입니다.

• Before (단일 시각): "화재, 사람 쓰러짐, 교통사고가 확인되면 알려줘" -> (모호함, 주의력 분산)
• After (다중 시각 분해):
  1. [화재 사건 시각]: "이미지의 픽셀 변화, 색상, 연기 질감에 집중해서 화재 징후가 있는지 봐줘."
  2. [안전 관제 시각]: "사람의 자세(Pose)와 주변 사물과의 관계를 보고 쓰러짐이 있는지 봐줘."
  3. [교통 관제 시각]: "차량 간의 충돌, 비정상적인 정차 위치를 보고 사고 여부를 판단해줘."

이렇게 질문을 분해(Decomposition)하면, VLM의 Visual Encoder는 각 질문에 맞는 Feature(특징)에 강하게 Attention을 활성화시킵니다. 즉, 같은 이미지를 보더라도 '무엇을 인지해야 하는가'가 명확해지면서 숨겨진 상황을 찾아내는 능력이 부여됩니다.

3. 🏛️ 시스템 구현: 전문화된 Multi-Agent 아키텍처​

전체 파이프라인​

EVA Agent는 다음 5단계로 복합 시나리오를 처리합니다.

1. Classifier (Single or Multi): 입력된 시나리오 개수 판단
2. Scenario Decomposition: Multi 시나리오인 경우 개별 시나리오로 분해
3. Scenario Enrichment: 각 시나리오에 풍부한 탐지 조건 주입[4]
4. Scenario Clustering: 시나리오 개수 N이 N>4인 경우 유사 시나리오 그룹핑
5. Parallel Inference: 병렬 VLM 추론 및 결과 통합 (개념도 예시: 하나의 이미지가 4개의 서로 다른 Prompt 경로로 나뉘어 처리됨)

Stage 1: Scenario Classification​

사용자로부터 받은 탐지 시나리오 설명을 LLM이 분석하여 Single/Multi 여부를 판단합니다.

[e.g.]
"화재가 발생한 경우거나, 사람이 쓰러진 경우이거나, 교통사고가 확인되는 경우"

[LLM Prompt]
다음 시나리오 설명을 분석하고, 단일 상황(Single)인지 복수 상황(Multi)인지 판단하세요:
"{user_input}"

[LLM 출력]
{
  "type": "multi",
  "count": 3,
  "scenarios": ["화재", "낙상", "교통사고"]
}

Q₂E 방법론과 비교:

• Q₂E: "2025 LA Fire"라는 단일 쿼리를 받아 Event Decomposition 수행
• EVA: "화재 or 낙상 or 교통사고"라는 복합 쿼리를 받아 Scenario Decomposition 수행

Stage 2: Scenario Decomposition​

Q₂E 방법론이 하나의 복잡한 쿼리를 Prequel/Current/Sequel로 분해한 것처럼, 우리는 복잡한 화면을 도메인별 관찰 지시(Domain-specific Directives)로 분해합니다.

[Q₂E의 Decomposition]
Query: "2025 LA Fire"
→ Prequel: "What could happen before?"
→ Current: "What happens during?"
→ Sequel: "What could be the outcome?"

[EVA의 Decomposition]
Query: "화재 or 낙상 or 교통사고"
→ Scenario 1: "화재 징후 탐지"
→ Scenario 2: "낙상 사고 탐지"
→ Scenario 3: "교통 사고 탐지"

Stage 3: Scenario Enrichment​

Q₂E의 Refinement와의 비교:

Enrichment 예시 (참고: Turning Simple User Requests into AI-Understandable Instructions)

Stage 4: Scenario Clustering (N>4인 경우)​

Enriched Prompt가 4개를 초과하면, 의미적으로 유사한 시나리오를 그룹핑하여 병렬 추론 효율을 높입니다.

Clustering 조건:

IF N > 4:
    LLM에게 요청: "이 시나리오들을 시각적 유사성 기준으로
                   최대 4개로 Grouping"
ELSE:
    각 시나리오를 독립적으로 처리

[시나리오가 많은 경우 예시]
Input: ["화재", "연기", "폭발", "낙상", "쓰러진사람",
        "교통사고", "충돌", "긴급차량"]  // 8개

[LLM 기반 Semantic Grouping]
Group 1 (화재 관련): ["화재", "연기", "폭발"]
Group 2 (인명사고 관련): ["낙상", "쓰러진사람"]
Group 3 (교통사고 관련): ["교통사고", "충돌"]
Group 4 (긴급 대응): ["긴급차량"]

→ 8개 시나리오를 4개 그룹으로 압축
→ VLM Latency 최적화 (메모리 효율 ↑)

Stage 5: Parallel VLM Inference​

각 Enriched Prompt를 VLM에 병렬로 전달합니다.

[e.g.]
enriched_prompts = [Group1_prompt, Group2_prompt, Group3_prompt, Group4_prompt]

PARALLEL_EXECUTE:
    FOR each prompt IN enriched_prompts:
        result = VLM(frame=cctv_image, instruction=prompt)
        results.append(result)

WAIT_ALL_COMPLETE

→ Q₂E의 Multi-modal Description 생성과 유사한 병렬 처리 구조

핵심 차이점:

• Q₂E: 하나의 비디오를 여러 모달(Video, Audio, Text)로 분석
• EVA: 하나의 화면을 여러 시나리오(Fire, Fall, Traffic)로 분석

4. 📊 실제 사례: 통합 vs 분해 시나리오 비교​

단순히 질문을 여러 번 하는 것이 아닙니다. 핵심은 "모델이 상황을 얼마나 더 정확하게 인지하게 되었는가"입니다.

실제 EVA 평가 영상을 활용하여, 동일한 복합적인 상황이 포함된 영상에서 통합 시나리오와 분해 시나리오의 인지 차이를 비교했습니다.

4.1.테스트 시나리오​

3가지 위급 상황이 순차적으로 재생되는 영상에 대해 "통합 시나리오" VS "분해된 멀티 시나리오" 로 모든 상황을 정확히 인지하는지 비교합니다.

통합 시나리오 프롬프트​

"1대 이상의 긴급차량이 존재하거나,
화재가 발생하거나,
넘어진 사람이 최소 1명 이상 존재하는 경우"

분해된 멀티 시나리오 프롬프트​

각 시나리오별로 Enrich된 "탐지 기준 & 예외 조건"을 명시합니다.:

4.2. 실험 결과​

4.3. 상세 분석​

1) 통합 시나리오의 한계 (Attention 간섭)​

VLM 응답

분석 결과:
✅ 쓰러진 사람 1명 확인됨 (Scene 1)
✅ 긴급차량(경찰차) 1대 확인됨 (Scene 2)
❌ 화재 징후 없음

판정: 위급 상황 1건 미탐지

문제점:

• Attention 편향: 앞선 장면(사람, 차량)에 인지 자원이 집중되어 후속 상황을 간과함.
• 시각적 특징 소홀: 화재 특유의 미세한 픽셀 변화(연기, 불꽃)보다 명확한 객체(사람, 차) 위주로 탐색하는 경향 보임.

2) 분해된 시나리오 탐지 결과​

[화재 탐지 결과]
⚠️ 화재 감지

탐지된 시각적 특징:
✓ 주황색/빨간색 불꽃 확인 (Scene 3, 우측 하단)
✓ 회색 연기 수직 상승 패턴 확인
✓ 불규칙한 경계의 밝은 영역 확인

위치: 화면 우측 하단 영역
신뢰도: 0.91
판정: 화재 발생 (즉시 소방 출동 필요)

탐지 요인:

• 전문화(Specialization): Fire Agent가 화재 관련 Feature(색상, 패턴)에만 Visual Encoder의 자원을 집중함.
• 간섭 차단: 다른 위급 상황 정보가 노이즈로 작용하지 않아 오탐 및 미탐율 감소.

5. 결론: "질문의 깊이가 이해의 깊이를 결정한다"​

이번 연구 및 개발 과정을 통해 얻은 결론은 명확합니다. VLM의 성능을 제한하는 것은 모델 자체의 파라미터 수가 아니라, 우리가 모델에게 세상을 어떻게 보라고 지시하는 '방법'에 있었다는 점입니다.  

Q₂E 방법론이 텍스트 검색의 정확도를 높이기 위해 쿼리를 분해했듯, 우리는 CCTV 관제라는 복잡한 도메인에서 시나리오 분해(Scenario Decomposition)를 통해 VLM에게 다중 상황을 동시에, 그리고 깊이 있게 인지할 수 있는 능력을 성공적으로 부여했습니다.

앞으로 우리는 이 방법론을 더욱 고도화하여, 정적 이미지 분석을 넘어 비디오의 시간적 맥락까지 이해하는 Temporal Event Decomposition으로 확장해 나갈 계획입니다.

(본 포스팅은 Q₂E: Query-to-Event Decomposition 논문의 방법론을 Vision Task의 Multi-Scenario Cognition 문제 해결에 창의적으로 적용한 사례입니다.)

References​

[1] Shubhashis Roy Dipta, Francis Ferraro. "Q₂E: Query-to-Event Decomposition for Zero-Shot Multilingual Text-to-Video Retrieval." arXiv:2506.10202v2, 2025.

[2] Standley, T., Zamir, A., Chen, D., Guibas, L., Malik, J., & Savarese, S. "Which Tasks Should Be Learned Together in Multi-task Learning?" ICML 2020.

[3] Pratt, S., Covert, I., Liu, R., & Farhadi, A."What Does CLIP Know About a Red Circle? Visual Prompt Engineering for VLMs." ICCV 2023.

[4] EVA Tech Blog: Turning Simple User Requests into AI-Understandable Instructions

산업 현장에서 사고는 예고 없이 발생합니다. 사람이 쓰러지고, 팔이 설비에 끼이며, 화재가 발생하는 순간은 대부분 아주 짧은 시간 안에 일어납니다.

Physical AI는 이 순간을 인식하는 것에서 멈추지 않고, 현장의 물리적인 동작으로 이어질 수 있어야 합니다.

이번 글에서는 레고 기반 시뮬레이션을 통해 EVA가 사고를 어떻게 탐지하고, 그 판단이 실제 설비 동작으로 어떻게 연결되는지를 하나의 흐름으로 살펴봅니다.

레고로 단순화한 산업 현장 시뮬레이션​

복잡한 산업 현장을 그대로 재현하는 대신, 레고를 활용해 사고 상황을 단순하게 구성했습니다.

사람이 쓰러지는 상황, 팔이 설비에 끼이는 상황, 화재가 발생하는 상황을 각각 독립적인 시나리오로 구성했습니다.

EVA: 상황을 이벤트로 해석하는 AI​

이 시뮬레이션에서 중요한 것은 단순히 사람이 보이거나 불꽃이 감지되는 것이 아닙니다.

EVA는 각 상황을 사전에 정의된 탐지 시나리오로 해석하고, 이를 하나의 의미 있는 이벤트로 판단합니다.

아래는 EVA에서 탐지 시나리오를 구성하는 화면입니다.

탐지는 곧 다음 행동을 결정하는 트리거 조건이 됩니다.

Physical Action Trigger: AI 판단이 현실을 움직일 때​

이벤트가 발생하면 EVA의 역할은 단순한 탐지에서 끝나지 않습니다.

EVA는 탐지된 이벤트를 Physical Action Trigger로 변환하여, 현장의 설비와 장치가 즉시 반응할 수 있도록 연결합니다.

이때 중요한 것은 각 사고 상황에 맞는 물리적 대응이 사전에 정의된 구조 안에서 실행된다는 점입니다. 사람의 개입을 기다리지 않고, AI의 판단이 곧바로 현실의 동작으로 이어집니다.

이러한 구조를 통해 AI의 판단은 화면 속 알림이나 로그로 남는 것이 아니라, 현장의 상태를 실제로 변화시키는 행동이 됩니다.

Physical Action Trigger는 AI가 ‘무엇을 보았는가’를 넘어, ‘현장에서 무엇이 달라져야 하는가’를 실행하는 지점입니다.

EVA → n8n → 설비 제어 워크플로우​

이러한 Physical Action은 하드코딩된 로직이 아니라 워크플로우 기반으로 구성됩니다.

EVA에서 발생한 탐지 이벤트는 Webhook을 통해 n8n으로 전달되고, n8n은 이벤트의 중요도에 따라 Agent가 해당하는 설비 제어 시그널을 전송합니다.

이 구조를 통해 설비가 변경되거나 시나리오가 확장되더라도 워크플로우를 유연하게 재사용할 수 있습니다.

Physical AI를 상상하게 만드는 구조​

이번 레고 시뮬레이션은 실제 산업 현장을 그대로 재현한 것은 아닙니다.

하지만 사고가 발생하고, AI가 이를 인지하며, 판단이 물리적인 동작으로 이어지는 구조는 현장과 동일합니다.

EVA는 AI를 화면 속 결과로 남겨두지 않고, 현실 세계에 직접 개입하는 Physical AI를 실현합니다.