Mevid 아키텍처 깊어보기: 멀티뷰 비디오 Re-ID의 한계를 깬 실전 파이프라인
개발자로 10년쯤 구르다 보면, 영상 기반의 CCTV 객체 분석이나 멀티 카메라 트래킹(Multi-camera Tracking) 프로젝트를 마주하게 되는 서늘한 순간이 찾아옵니다. 현업에서 이 작업을 해보신 분들은 제 말에 뼈저리게 공감하실 겁니다. 이게 얼마나 지옥 같은 일인지 말이죠. 분명 카메라 A에서 완벽하게 추적되던 사람이 잠깐 기둥 뒤로 지나가서 카메라 B에 나타나면, 시스템은 조명이 살짝 바뀌었다는 이유만으로 완전히 새로운 객체(ID)로 인식해버립니다. 기획자가 해맑은 표정으로 ‘아니, 옷 색깔이 똑같은데 왜 동일인인지 못 잡아요?’라고 물어볼 때마다, 우리는 치솟는 VRAM 사용량과 터져나가는 OOM(Out of Memory) 로그를 보며 조용히 한숨만 내쉬게 되죠. 기존에 우리가 맹신하며 쓰던 SORT나 DeepSORT 기반의 객체 추적 프레임워크들은 소규모 단일 카메라 환경에서는 그럭저럭 잘 돌아가지만, 수십 대의 카메라가 맞물리는 엔터프라이즈 환경에서는 텐서(Tensor) 메모리 누수와 식별 오류로 인해 처참하게 무너져 내립니다. 이런 기술적 회의감에 빠져 있던 최근, 컴퓨터 비전과 엣지 AI 생태계에서 제 호기심을 강하게 자극하는 프로젝트를 하나 뜯어보게 되었습니다. 바로 오늘 깊게 파헤쳐볼 Mevid(MEVID) 프레임워크입니다. 과연 이들은 우리가 현업에서 겪는 이 고질적인 메모리 병목과 추적 실패의 늪을 어떻게 탈출했을까요? 커피 한 잔 타오시고, 지금부터 저와 함께 이 흥미로운 아키텍처의 밑바닥까지 진지하게 딥다이브 해보시죠.
먼저 바쁜 현업 분들을 위해 핵심만 짚고 넘어가겠습니다. Mevid(Multi-view Extended Videos with Identities)는 단순하게 크기만 키운 벤치마크 데이터셋이 절대 아닙니다. 시공간(Spatial-temporal) 트랙릿(Tracklet) 기반의 텐서 처리 로직과 여러 비전 모델들을 유기적으로 결합한 ‘반자동화(Semi-automatic) 어노테이션 파이프라인’을 통해, 대규모 멀티뷰 비디오 객체 재식별(Re-ID) 과정에서 발생하는 메모리 병목과 추론 비용을 극적으로 낮춘 실전형 프레임워크입니다.
표면적으로 Mevid는 WACV 2023에 발표된 ‘비디오 기반 사람 재식별을 위한 대규모 데이터셋’으로 널리 알려져 있습니다. 하지만 시니어 백엔드 및 AI 아키텍트로서 제가 진짜로 주목한 부분은, 이들이 1,000만 장이 넘는 거대한 프레임과 33개의 각기 다른 뷰포인트 데이터를 처리하기 위해 밑바닥부터 꼼꼼하게 설계한 내부 파이프라인 아키텍처입니다. 기존 시스템들과 비교했을 때 가장 눈에 띄는 아키텍처적 차이는 바로 ‘프레임(Frame)’ 단위 처리에서 ‘트랙릿(Tracklet)’ 단위 처리로의 과감한 패러다임 전환입니다. 우리가 흔히 아는 기존 영상 처리 프레임워크들은 매 프레임마다 무거운 CNN이나 Vision Transformer 기반의 인코더를 통째로 태워 특징(Feature)을 추출합니다. 이렇게 되면 1초에 30프레임씩 쏟아지는 영상을 다중 카메라 스트림으로 처리할 때 웬만한 GPU 메모리로는 버텨낼 재간이 없습니다. 반면 Mevid 파이프라인은 연속된 영상 스트림을 일정 길이의 트랙릿(평균 약 590프레임 단위의 의미 있는 흐름)으로 묶어서 버퍼링합니다. 그리고 이 묶여진 시공간 구간 내에서 사람의 표면적인 외형(Appearance) 정보와 시간적 흐름에 따른 보행 패턴(Gait) 정보를 영리하게 분리하여 임베딩 공간에 매핑합니다.
> ‘사람이 코트를 벗거나 다른 옷으로 갈아입어도 반드시 동일인으로 추적해 내야 한다.’
이것이 바로 Mevid 코어 로직을 관통하는 가장 묵직한 핵심 철학입니다. 이들은 이 극악의 난이도를 자랑하는 목표를 달성하기 위해 내부적으로 객체 탐지(Object Detection) 프로세스부터 포즈 추정(Pose Estimation), 멀티 객체 트래킹(MOT), 그리고 최종 Re-ID 모듈까지 마치 하나의 정교한 팩토리 컨베이어 벨트처럼 엮은 반자동화(Semi-automatic) 파이프라인 프레임워크를 훌륭하게 구현해 냈습니다. 특히 이들의 메모리 처리 방식은 현업 개발자 입장에서 무릎을 탁 치게 만듭니다. 33개의 카메라에서 쏟아지는 비디오 텐서를 한 번에 메모리에 얹으면 시스템은 즉시 다운됩니다. 이를 방지하기 위해 Mevid 팀은 Kitware의 DIVE 시스템을 포크(Fork)하여 파이프라인에 이식했는데, 이는 사실상 동적 메모리 스와핑(Dynamic Memory Swapping)에 가까운 역할을 수행합니다. 화면에 움직임이 없는 의미 없는(Empty) 프레임이 들어오면 무거운 연산을 가차 없이 스킵해버리고, 액터(Actor)가 화면에 등장해 링킹되는 그 찰나의 순간에만 무거운 Re-ID 추론 모델을 활성화하여 VRAM에 적재하는 스마트한 메모리 할당 방식을 채택한 것이죠. 보안과 민감 정보 처리 측면에서도 깊은 인사이트를 줍니다. 비디오 픽셀 데이터 원본을 통째로 중앙 데이터베이스에 저장하는 멍청한 짓을 피하고, 시스템 단말(Edge)에서 즉시 비식별화된 생체 특징 벡터(Biometric Vector)만을 추출하여 분리합니다. 이는 GDPR이나 국내의 엄격한 개인정보보호법 등 프라이버시 규제가 빡빡한 현대의 클라우드 인프라 아키텍처와 매우 훌륭한 궁합을 보여주는 설계입니다.
자, 아무리 아키텍처가 훌륭해도 실무에 쓸 수 없으면 반쪽짜리 학술 논문에 불과하죠. ‘그래서 이걸 당장 우리 회사 프로젝트 백엔드에 어떻게 이식할 수 있는데?’라는 가장 실용적이고 프래그마틱(Pragmatic)한 고민을 해보겠습니다. 단순히 연구실 서버에서나 돌아가는 장난감이 아니라, 실제 거대 스마트 팩토리의 작업자 동선 추적이나 대형 리테일 백화점의 VIP 고객 이탈 분석 시스템에 이 파이프라인을 도입한다고 상상해 보세요. 전체 아키텍처는 대략 이런 유려한 흐름을 타게 될 겁니다. 우선 데이터 수집 계층(Ingestion Layer)에서 매장의 각 층에 설치된 수십 대의 CCTV RTSP 영상 스트림을 Kafka나 RabbitMQ 같은 튼튼한 메시지 브로커로 빨아들입니다. 그 다음 중간 처리 계층(Processing Layer)에서 Mevid 기반의 트랙릿 추출 툴체인 워커(Worker)들이 비디오 청크를 컨슘(Consume)하기 시작하죠. 바로 이 지점에서 코어 비즈니스 로직이 폭발력을 가집니다. 특정 고객이 화장실이나 피팅룸에 들어가서 입고 있던 겉옷을 벗고 전혀 다른 색상의 옷을 입고 나와도(의상 변화), Mevid의 파이프라인은 앞서 언급한 포즈와 시간적 보행 패턴을 결합한 다중 뷰포인트 로직을 통해 이 사람을 정확히 동일 인물로 식별하고 추적해 냅니다. 마지막으로 추출된 고차원 식별 벡터 값은 Milvus, Pinecone, Qdrant 같은 현대적인 고성능 벡터 데이터베이스(Vector DB)에 저장되어 초고속 병렬 매칭에 사용됩니다. 기존 방식대로라면 무거운 딥러닝 서버 10대가 굉음을 내며 끙끙대며 처리해야 했을 작업을, 워크로드를 영리하게 쪼갠 엣지 노드(Edge Node) 몇 대 수준으로 최적화할 수 있는 강력한 무기인 셈입니다. 특히 이 프레임워크에 내장된 GUI 툴체인을 사내 데이터 라벨링 파이프라인 플랫폼에 통합해 놓으면, ML 엔지니어와 외부 데이터 라벨러 사이에서 발생하는 지옥 같은 소통 비용과 휴먼 에러를 절반 이하로 뚝 떨어뜨릴 수 있죠.
하지만 언제나 그렇듯, 엔지니어의 세계에 완벽한 구원투수나 은통알(Silver Bullet)은 존재하지 않습니다. 이제 시니어의 솔직하고 비판적인 잣대를 들이대 볼 시간입니다. 칭찬만 늘어놓기엔 실제로 코드를 클론(Clone)받아 로컬에서 굴려보면서 겪었던 ‘빡침’과 아쉬운 점들이 너무나 명확히 보였거든요. 우선 Mevid의 가장 강력한 장점은 현존하는 오픈소스 비전 파이프라인 중 타의 추종을 불허하는 압도적인 스케일과 환경 강건함(Robustness)입니다. 무려 158명의 고유 신원, 598번의 의상 변화, 1000만 장 이상의 프레임을 단일 시스템에서 매끄럽게 다루는 시도는 정말 흔치 않은 축복입니다. 복잡한 조명이나 스케일 변화에 대한 대응력은 이전 세대의 벤치마크 프레임워크들을 가볍게 씹어먹습니다. 하지만, 이를 로컬 환경이나 자사 서버에 도커(Docker) 컨테이너 기반으로 올려서 커스텀 데이터를 태워보려고 시도하는 순간 꽤나 가혹한 러닝 커브와 스파게티 코드의 늪을 마주하게 됩니다. 공식 리포지토리의 핵심인 반자동 어노테이션 툴체인(DIVE 포크 버전) 코드를 뜯어보면 경악스러운 부분들이 존재합니다. 데이터베이스 경로(Pathnames)나 등록된 사진의 개수, 폴더 트리 구조 같은 민감한 설정값들이 철저하게 자신들의 연구용 MEVA 데이터 구조에만 맞춰 하드코딩(Hard-coded)되어 있는 치명적인 설계 결함이 곳곳에 숨어 있습니다. 연구 목적으로 학회에서 논문 실적을 내기에는 이보다 더 훌륭할 수 없겠지만, 당장 내일 상용 서비스 백엔드에 이 프레임워크를 이식해야 하는 현업 개발자라면 이 끔찍한 코드 결합도(Coupling)를 일일이 찾아내어 끊어내고 환경 변수로 빼내는 대대적인 리팩토링 과정이 강제됩니다. 게다가 아무리 동적 스킵 로직이 잘 되어 있다 하더라도, 이 거대한 파이프라인의 레이어들을 원활하게 병렬로 돌리기 위해서는 로컬 기준 최소 24GB 이상의 VRAM(예를 들어 RTX 3090 또는 4090 급 이상의 하드웨어)을 지속적으로 요구하는 하드웨어 의존성 역시 도입을 망설이게 만드는 무시할 수 없는 아키텍처적 트레이드오프(Trade-off)로 작용합니다.
결론적으로 Mevid 프레임워크는 단순히 컴퓨터 비전(CV) 연구자들만의 전용 장난감이나 학술적 결과물로 치부하기엔 너무나 아까운 보물입니다. 단일 이미지 프레임 기반의 얄팍한 공간 분석 시대가 이미 저물고, 이제는 다중 시점(Multi-view)의 입체적 결합과 시간의 흐름(Temporal)을 종합적으로 고려하는 차세대 비디오 아키텍처로 패러다임이 완전히 넘어가고 있음을 보여주는 매우 중요한 변곡점 역할을 하고 있습니다. 여러분이 화면을 그리는 프론트엔드를 개발하든, 데이터를 깎는 백엔드를 개발하든, 결국 다가오는 미래의 엔터프라이즈 서비스들은 이러한 거대하고 무거운 AI 파이프라인 노드들과 어떻게 효율적으로 통신하고 한정된 메모리 자원을 할당할 것인가에 대한 뼈를 깎는 싸움이 될 것입니다. 당장 이 거대한 프레임워크를 여러분의 사내 프로젝트에 억지로 우겨넣어 도입할 필요는 없습니다. 하지만 Mevid가 그 무거운 영상 속 객체의 트랙릿을 어떻게 추적해 내고, VRAM을 아끼기 위해 동적으로 메모리를 스왑하며, 개인정보 보안을 분리해 유지하는지 그 치열한 ‘철학’과 ‘엔지니어링적 접근법’만큼은 주말에 시간을 내어 깃허브 코드를 통해 꼭 한 번 깊게 뜯어보시길 강력히 권합니다. 우리 현업 개발자들이 앞으로 마주하게 될 다음 세대의 트러블슈팅과 아키텍처적 영감은, 바로 이러한 극한의 최적화를 향한 밑바닥 흙먼지 속에서 시작될 테니까요.
References
- https://openaccess.thecvf.com/content/WACV2023/papers/Clipp_MEVID_Multi-View_Extended_Videos_With_Identities_for_Video_Person_Re-Identification_WACV_2023_paper.pdf
- https://github.com/Kitware/MEVID
- https://arxiv.org/abs/2211.04561
