"EVA" 태그로 연결된 16개 게시물개의 게시물이 있습니다.

안녕하세요. EVA 팀에서 프론트엔드 개발을 담당하고 있는 유준형입니다.

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

단순 접수를 넘어, Agent가 요구사항을 다룬다​

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

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

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

요청자는 형식을 맞추는 데 시간을 쓰기보다, 실제로 불편했던 지점과 기대하는 개선 방향을 짧게 전달하면 됩니다. 그 이후의 정제, 분석, 우선순위화는 자동화된 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를 활용하는 이유는 단순히 자동화를 늘리기 위해서가 아니라, 요구사항 관리 자체를 지속적으로 학습하고 개선해 나가는 프로세스로 만들기 위해서입니다.

1. 서론: 데이터센터 화재, 기업의 존립을 위협하는 ‘빌리언 달러’ 리스크 🥵​

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

👉 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 로 이어지는 선순환 구조를 통해, 데이터센터를 가장 경제적이고 안전하게 운영할 수 있습니다.

단일 프레임은 충분한가?​

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

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

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

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

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

EVA 핵심은 "화재", "낙상", "교통사고" 등 화면 속에서 동시 다발적으로 일어나는 위급 상황을 놓치지 않고 '이해' 하는 것입니다. 하지만 아무리 뛰어난 VLM(Vision-Language Model)이라도 한 번에 너무 많은 것을 물어보면 인지 능력이 급격히 떨어지는 현상이 발생합니다.[2,3]

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

AI는 언제 현실에 개입할 수 있을까?​

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

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

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

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

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

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

단순한 ‘관찰’을 넘어 ‘개입’하는 AI로​

오늘날 AI의 핵심 과제는 단순히 데이터를 분석하거나 장면을 설명하는 것에 그치지 않습니다.

진정한 지능형 시스템은 분석을 바탕으로 물리 세계나 기업 운영 시스템에서 유의미한 액션(Action)을 끌어낼 수 있어야 합니다.

EVA는 이제 시각 정보를 이해하고 상황을 판단하는 '눈'과 '뇌'의 역할을 넘어, Workflow Builder라는 '손'과 결합하고 있습니다.

이는 단순한 알림 중심의 수동적 모니터링을 넘어, 현장의 상황을 스스로 판단하고 문제 해결까지 이어지는 엔드투엔드(End-to-End) 자동화 구조의 완성을 의미합니다.

캠퍼스, 안전을 넘어 지능을 갖다: EVA와 함께하는 Postech Living Lab 프로젝트로 손민준 군(지도 교수 고영명 님)과 협동 연구한 주제입니다.

사용자의 한 줄 질의를 더 똑똑하게: 이미지 컨텍스트로 언어를 보강하는 법​

EVA는 수백~수천 대의 스마트 카메라로 이상 상황을 감지하는 시스템입니다. 우리는 VLM/LLM을 활용해 카메라 컨텍스트를 자동으로 추론하고, 이를 프롬프트에 녹여 넣어 탐지하고자 하는 이미지의 상황이 반영된(camera-context; 카메라 컨텍스트 기반) 이상 탐지 파이프라인을 만들었습니다. 단일 프레임으로 추출한 카메라 컨텍스트를 VLLM의 사전 지식으로 활용했을 때, 기존 베이스라인 대비 의미 있는 정확도 향상과 더 깊은 해석 가능성을 확인했습니다.

캠퍼스, 안전을 넘어 지능을 갖다: EVA와 함께하는 Postech Living Lab 프로젝트로 이재찬 군(지도 교수 고영명 님)과 협동 연구한 주제입니다.

🎯 서론: 피드백을 '사후 보정'에서 '사고 능력 강화'로 전환하다​

EVA가 이미지를 판단할 때, 운영자들은 "이 경우는 안전조끼가 맞아. 왜 헷갈린 거지?" 또는 "여기서는 경보가 나야 하는 것 아닌가?"와 같은 구체적인 피드백을 제공합니다. 이 피드백에는 단순한 정오답을 넘어, 사람이 판단에 이른 이유와 문맥이 담겨 있습니다.

그동안 EVA는 이러한 피드백을 별도의 Vector DB에 저장하여 유사 상황 발생 시 Alert 여부를 보정하는 방식으로 활용해 왔습니다. 이 방식은 신속한 적용이 가능하다는 장점이 있었지만, 모델 자체의 추론 능력을 개선하지 못하고 오류를 사후적으로 필터링하는 구조적 한계를 가지고 있었습니다.

우리는 이 문제를 근본적으로 해결하기 위해 접근 방식을 완전히 바꿨습니다. 사용자 피드백을 단순한 오류 보고가 아니라, 모델이 추론 과정에 직접 활용하여 시각적 사고(Visual Reasoning) 능력을 강화할 수 있는 Instruction 데이터로 재구성한 것입니다.

이 글에서는 사용자 피드백 데이터를 활용한 VLM 기반 Instruction Tuning이 기존의 Vector DB 중심 접근의 한계를 어떻게 극복하고, 모델의 시각적 추론 능력을 어떻게 개선하는지를 중심으로 이야기하려고 합니다.

서론​

사용자는 Chat Agent에게 단순한 텍스트를 입력합니다. "모니터링 시작해주세요.", "사람에 대한 threshold를 0.6으로 맞춰줘.", "타겟 리스트에 나무 추가해."

겉으로 보기엔 단순한 대화지만, LLM 내부에서 이 요청을 처리하기 위해 수행해야하는 작업은 훨씬 복잡합니다.

LLM은 먼저 사용자의 요청이 어떤 종류의 작업인지 스스로 분류해야 합니다.

"이건 Target 설정인가? 시나리오 편집인가? 아니면 단순 조회인가?"

그 다음, 해당 태스크에 필요한 파라미터를 정확히 추출하고, 값이 허용 범위에 있는지 검증하며, 잘못된 값이면 이유까지 사용자 친화적으로 설명해야 합니다.

즉, 사람이 여러 단계에 걸쳐 순차적으로 판단해야 할 일을, 기존 LLM 구조는 한 번의 호출로 모두 처리하도록 설계되어 있었습니다.

이 방식은 외형상 깔끔해 보였지만, 실제로는 예측하기 어려운 문제를 반복적으로 만들어냈습니다.

• 태스크 타입을 잘못 분류하여 엉뚱한 작업을 수행
• 다른 태스크의 규칙이 섞여 충돌 발생
• 잘못 추출한 파라미터가 그대로 통과
• 규칙이 복잡하게 얽혀 유지보수 비용 상승

결국, 근본적인 문제를 해결하기 위해 LangGraph 기반 Multi-Node Routing 구조로 Chat Agent를 재설계하게 되었습니다.