PlusInsight
공간 행동 분석 플랫폼

01 CONTEXT & PROBLEMS

고객마다 다른 환경을
하나의 제품으로 다루기

PlusInsight는 카메라에서 들어오는 사람의 위치와 행동 데이터를 분석해, 공간 안의 이동과 행동을 이해하도록 돕는 온프레미스 플랫폼입니다. 고객마다 설치 환경과 필요한 분석 범위가 달랐고, 제한된 장비에서 현재 상태를 보여주는 처리와 일별 분석을 함께 운영해야 했습니다.

고객별 요구를 소스코드 복제로 해결하면 업데이트와 운영 비용이 누적됩니다. 반대로 하나의 고정된 시스템만 유지하면 현장의 차이를 수용할 수 없습니다. 그래서 공통 제품을 유지하면서도 환경별 변화를 관리하는 구조가 필요했습니다.

02 SYSTEM APPROACH

공통 플랫폼과
고객별 변화를 분리하기

이 프로젝트에서 중요한 추상화는 “고객마다 다른 제품”을 만드는 것이 아니라, 공통으로 유지할 플랫폼과 고객 환경에 따라 달라져야 하는 운영 요소를 구분하는 것이었습니다.

분석 처리, 데이터 흐름, 모델 적용, 설치·업데이트·관측의 기본 구조는 공통 기반으로 유지했습니다. 반면 고객별 제품 유형, 저장 프로필, 수집기, 모니터링, 설치 설정과 변경 이력은 별도의 운영 가능한 경계로 다뤘습니다.

이 구분을 통해 새 고객을 지원할 때마다 소스코드를 복제하는 대신, GitHub Actions 기반 푸시 GitOps 워크플로로 환경별 설치·패치·버전·설정·변경 이력을 적용해 같은 코드베이스를 배포하고 관리할 수 있게 했습니다. AWS ECS는 고객 운영 환경이 아니라 내부 공유·개발·테스트 환경으로 별도 관리했습니다.

시간 범위와 처리 책임에 따라 분석 경로를 분리

시스템의 중심에는 카메라 인식 결과를 축적하는 공통 행동 데이터 계층을 두었습니다. 고객 환경에 따라 ClickHouse 또는 기존 OpenSearch를 저장소로 선택할 수 있었지만, 이후 처리 경로는 특정 저장소나 고객 환경에 묶이지 않고 같은 원본 기록을 기준으로 동작하도록 구성했습니다.

그 위에서 처리는 시간 범위와 결과의 성격에 따라 세 경로로 나뉩니다. Realtime은 현재 시점에 빠르게 응답해야 하는 상태를, Today는 하루가 진행되는 동안 갱신되는 중간 상태를, Daily는 마감된 시간 범위에 대한 확정 결과를 맡습니다. 각 경로는 실행 주기와 계산 범위, 결과 저장을 분리해 긴 일별 처리가 현재 응답을 지연시키거나 반대로 실시간 요구가 일별 처리를 흔들지 않게 했습니다.

flowchart TB
Input["카메라 인식 결과"] --> TCP["TCP 수집 경로"]
TCP --> Storage{"저장소"}
Storage --> CH["ClickHouse"]
Storage --> OS["OpenSearch"]
CH --> Raw["공통 행동 데이터"]
OS --> Raw
Raw --> Realtime["Realtime"]
Raw --> Today["Today"]
Raw --> Daily["Daily"]
Realtime --> Result["분석 결과"]
Today --> Result
Daily --> Result
Result --> Dashboard["대시보드 조회"]

대시보드는 처리 중간 단계를 직접 담당하지 않고, 각 경로가 남긴 분석 결과를 조회하는 소비자로 분리했습니다. 공통 분석 결과 계층 위에서 고객사별 분석 범위와 화면 구성을 조정할 수 있게 해, 공통 처리 구조를 유지하면서도 맞춤형 웹 대시보드를 제공할 수 있도록 했습니다.

03 CONTRIBUTION & OUTCOME

분리된 구조 위에서
병목을 찾아 교체

공통 데이터 계층과 시간별 분석 경로의 책임을 분리해 둔 덕분에, 성능 문제는 전체 시스템을 다시 만드는 일이 아니라 병목이 발생한 경로를 확인하고 교체하는 문제로 다룰 수 있었습니다.

후처리가 새벽에 수 시간 걸리는 상황에서, 단순히 장비를 늘리는 대신 병목이 발생하는 지점을 확인했습니다. 데이터의 형태와 처리 흐름을 다시 살핀 뒤, 데이터 특성에 더 알맞은 저장 구조로 교체하고 수집·저장·후처리 파이프라인을 함께 최적화했습니다.

구조의 경계가 분명했기 때문에 전체 시스템을 흔들지 않고 저장·후처리 경로를 교체할 수 있었고, 제한된 온프레미스 장비에서도 일일 후처리 시간을 수 시간에서 수 분으로 줄였습니다. 이는 단일 구성 요소의 교체보다 데이터 형태·저장 구조·수집 경로·후처리 방식·운영 제약을 함께 보고 병목을 제거한 결과입니다.