OpenCV 5는 컴퓨터 비전 라이브러리를 다시 추론 런타임으로 만든다

OpenCV 5의 핵심은 “오래된 컴퓨터 비전 라이브러리의 메이저 버전업”이 아니다.
공식 글이 강조하듯 OpenCV는 여전히 GitHub star 8만 개 이상, 하루 100만 회 이상 설치되는 기반 라이브러리다.
문제는 그 기반이 놓인 환경이 OpenCV 4 시대와 달라졌다는 점이다.
지금의 vision pipeline은 imread와 resize만으로 끝나지 않고, ONNX 모델, transformer, vision-language model, edge device, Python-first workflow, vendor-specific accelerator를 한 흐름 안에서 다룬다.

OpenCV 5는 이 변화에 맞춰 라이브러리의 중심축을 다시 잡는다.
새 DNN 엔진은 network를 layer list가 아니라 typed operation graph로 보고, dynamic shape와 operator fusion을 다룬다. core는 FP16/BF16, bool, 64-bit integer, 0D/1D tensor, broadcasting을 받아들인다.
HAL은 vendor가 최적화 kernel을 꽂을 수 있는 표면으로 정리되고, 3D vision은 calibration·stereo·point cloud 계층으로 재편된다.
즉 OpenCV 5는 “classical CV + modern inference + hardware portability”를 하나의 API 표면 아래 다시 묶으려는 릴리스다.

중요한 caveat도 있다.
OpenCV 공식 발표는 OpenCV 5를 2026년 6월 CVPR 시점의 큰 릴리스로 소개하지만, 확인 시점의 GitHub Releases API에서는 최신 formal release가 4.13.0이고, 5.0.0은 tag로 확인된다.
PyPI의 opencv-python도 아직 5.x wheel을 노출하지 않았고, 공식 글은 pip version이 6월 8일 공개될 예정이라고 적는다.
따라서 제품 업그레이드는 “OpenCV 5 기능이 공개됐다”와 “내 패키징 채널·backend·wheel이 바로 안정화됐다”를 분리해서 봐야 한다.

무엇을 해결하려는가

OpenCV 4.x의 가장 큰 마찰은 현대 ONNX 모델을 가져왔을 때 자주 드러났다.
작은 CNN이나 오래된 detector는 잘 돌아가도, dynamic shape, control flow, transformer block, QDQ quantization graph가 들어가면 DNN module이 operator를 이해하지 못하거나 shape 가정에서 깨지는 일이 많았다.
그래서 실제 제품 팀은 OpenCV로 pre/post-processing을 하고, inference는 ONNX Runtime, TensorRT, OpenVINO, PyTorch 계열 런타임으로 분리하는 구조를 택하곤 했다.

OpenCV 5의 문제의식은 이 분리를 줄이는 데 있다.
공식 글은 OpenCV 4.x 시절 ONNX operator coverage가 약 22% 수준이었고, OpenCV 5에서 80%+로 올라갔다고 설명한다.
단순히 operator 수가 늘었다는 뜻만은 아니다.
모델을 flat layer sequence로 걷는 방식에서 벗어나, graph 전체를 분석하고 shape inference, constant folding, fusion, memory pooling을 할 수 있게 만들었다는 점이 핵심이다.

이 변화는 edge vision 팀에게 특히 중요하다.
실제 pipeline에서는 inference만 빠르면 끝나지 않는다. camera frame resize, color conversion, normalization, letterboxing, NMS, mask resize, overlay 같은 주변 연산이 모델 앞뒤를 감싼다.
OpenCV가 이 전후처리의 사실상 표준 도구였다면, OpenCV 5는 inference runtime과 hardware acceleration까지 같은 좌표계에 놓으려 한다.

핵심 아이디어 / 구조 / 동작 방식

OpenCV 5 DNN의 설계는 호환성과 재작성 사이에서 타협점을 찾는다.
새 엔진은 graph 기반이지만, 기존 DNN API를 통째로 버리지 않는다. readNet* 계열 호출에서 engine을 고를 수 있고, 기본값은 새 엔진을 먼저 시도한 뒤 실패하면 classic engine으로 fallback하는 ENGINE_AUTO다.

새 엔진이 제공하는 기능은 네 가지로 요약된다.
첫째, If와 Loop subgraph를 받아들여 control-flow ONNX 모델을 다룬다.
둘째, symbolic/dynamic shape를 shape inference 안에서 처리한다.
셋째, QDQ graph를 이해해 quantized model 경로를 넓힌다.
넷째, MatMul→Softmax→MatMul 같은 attention pattern을 fused attention으로 접어 transformer 계산을 최적화한다.
공식 글은 이를 FlashAttention-style implementation이라고 설명한다.

그럼에도 GPU inference까지 새 엔진이 곧장 다 해결한다는 뜻은 아니다.
OpenCV 5의 graph engine은 현재 CPU-first다.
GPU가 필요하면 classic engine의 CUDA/OpenVINO backend나 ENGINE_ORT의 execution provider 경로가 더 현실적일 수 있다.
OpenCV 5가 흥미로운 이유는 지금 당장 모든 accelerator를 대체해서가 아니라, DNN graph와 HAL이 장기적으로 “OpenCV 코드 그대로 hardware path를 바꾸는” 토대를 만들기 때문이다.

공개된 근거에서 확인되는 점

공식 OpenCV 5 글은 Intel Core i9-14900KS, Ubuntu 24.04 LTS 환경에서 새 DNN engine이 ONNX Runtime보다 빠르게 나온 사례들을 제시한다.
일부 숫자만 옮기면 다음과 같다.
낮을수록 빠른 inference time이다.

다만 benchmark 해석은 신중해야 한다.
별도 OpenCV 5 DNN benchmark wiki는 Intel i9, i7, Apple M1, Apple M5, AMD 등 여러 플랫폼과 많은 모델을 비교하며, ONNX Runtime이 더 빠른 모델도 명확히 보여 준다.
예를 들어 일부 OCR, decoder, pose, lightweight model, quantized path에서는 ONNX Runtime이 우세한 항목이 있다.
따라서 이 수치의 올바른 결론은 “OpenCV 5가 언제나 ONNX Runtime을 이긴다”가 아니라, OpenCV DNN이 이제 단순 fallback이 아니라 실제 비교 대상이 될 만큼 넓고 빠른 runtime으로 올라왔다에 가깝다.

OpenCV 5가 다루는 모델 범위도 넓어졌다.
공식 글은 YOLO 계열, RF-DETR, Grounding DINO, SAM 계열, DINOv2, OWLv2, BiRefNet, OCR 모델, restoration/generative 모델 등을 언급한다.
더 흥미로운 부분은 LLM/VLM이다.
OpenCV 5는 DNN module 안에 tokenizer와 KV cache를 넣어 Qwen 2.5, Gemma 3, PaliGemma, GPT 계열 모델을 같은 Net API 안에서 실행하는 방향을 보여 준다.
이것이 dedicated LLM serving stack을 대체한다는 뜻은 아니지만, vision pipeline 안에서 captioning, OCR 후처리, open-vocabulary query 같은 작은 language step을 별도 framework 없이 붙이는 길은 열린다.

LaMa inpainting 예시는 그 방향을 잘 보여 준다.
이미지와 mask를 넣고, DNN forward 한 번으로 object removal 결과를 얻는 데모다.
OpenCV가 오래 맡아 온 image manipulation과 새 DNN engine이 같은 라이브러리 안에서 만나는 사례다.

Core 쪽 변화도 단순 청소가 아니다. cv::Mat이 0D scalar와 1D array를 자연스럽게 표현하고, FP16/BF16, bool, 64-bit integer, N-dimensional operation, broadcasting을 다루면 Python/NumPy와 DNN 사이의 불필요한 reshape·copy·type conversion이 줄어든다.
C API 제거와 C++17 minimum, Python 3-only, NumPy 2.x 대응은 오래된 호환성을 줄이고 현대 언어 binding에 맞추는 방향이다.

3D vision도 재편됐다.
기존 calib3d의 역할은 geometry, calibration, stereo, point cloud 계층으로 쪼개지고, multi-camera calibration, point cloud/mesh I/O, TSDF/RGB-D fusion, visual odometry, USAC/MAGSAC 계열 robust estimation이 강조된다.
로봇, SfM, reconstruction 팀에게는 DNN 못지않게 중요한 변화다.

마지막으로 문서화가 Sphinx + Doxygen pipeline으로 바뀌었다.
왼쪽 navigation, hand-written tutorial, Python signature 병기, link checker 같은 변화는 headline feature는 아니지만, 라이브러리 adoption 비용을 직접 낮춘다.

실무 관점에서의 해석

OpenCV 5를 도입하려는 팀은 세 가지 질문을 먼저 해야 한다.

첫째, 내 workload가 새 DNN engine의 CPU-first 장점과 맞는가.
CPU inference, edge CPU, x86/ARM 서버, 하나의 dependency로 pre/post-processing과 inference를 묶고 싶은 pipeline이라면 OpenCV 5의 가치가 크다.
반대로 이미 TensorRT, CUDA, OpenVINO, Core ML, NNAPI, dedicated ONNX Runtime EP에 강하게 묶인 production path라면, 새 엔진으로 바로 갈아타기보다 ENGINE_CLASSIC, ENGINE_ORT, backend/target 조합을 비교해야 한다.

둘째, 패키징 상태를 확인했는가.
확인 시점의 opencv/opencv repository는 Apache-2.0 license, default branch는 4.x, 5.0.0 tag와 5.x branch가 보인다.
그러나 GitHub release object와 PyPI wheel은 시점별로 다르게 열릴 수 있다.
CI가 pip install opencv-python에 의존한다면 6월 8일 이후 wheel 상태, contrib package, platform wheel, ABI, Python version support를 별도로 봐야 한다.

셋째, OpenCV 5의 장점이 전체 pipeline 병목과 연결되는가.
단일 모델 forward가 몇 ms 빠른 것보다, resize/color conversion/normalization/NMS/mask operation/data copy가 accelerator와 CPU 사이를 왕복하지 않게 하는 것이 더 큰 이득일 수 있다.
OpenCV 5의 새 HAL과 non-CPU HAL roadmap은 바로 이 지점을 겨냥한다.
지금은 CPU HAL과 vendor-tuned path가 중심이지만, 장기적으로는 pre/post-processing과 model execution이 같은 hardware memory 안에 머무는 구조가 목표다.

내가 보기에는 OpenCV 5의 의미는 “OpenCV가 또 하나의 모델 런타임을 만들었다”보다 더 넓다.
이 릴리스는 computer vision stack에서 오래 분리되어 있던 세 층, 즉 classical image operations, neural inference, hardware-specific acceleration을 다시 하나의 개발자 경험으로 묶으려 한다.
OpenCV가 이미 수많은 production system의 전후처리와 camera pipeline에 들어가 있다는 점을 생각하면, 이 결합은 작은 변화가 아니다.

결론: OpenCV의 다음 10년을 위한 재기반화

OpenCV 5는 눈에 띄는 숫자를 많이 갖고 있다.
ONNX operator coverage 80%+, 여러 CPU benchmark에서 ONNX Runtime 대비 빠른 사례, LLM/VLM support, tokenizer와 KV cache, FP16/BF16, 0D/1D tensor, 새 HAL, 3D module 재편이 모두 headline이 될 만하다.
하지만 더 중요한 것은 방향이다.
OpenCV는 “이미지 처리 유틸리티 모음”이 아니라, modern AI vision pipeline의 공통 runtime이 되려 한다.

물론 전환은 한 번에 끝나지 않는다.
GPU support in the new DNN engine, non-CPU HAL, wheel/package rollout, backend별 maturity는 5.x cycle에서 계속 확인해야 한다.
공식 benchmark wiki가 보여 주듯 ONNX Runtime이 여전히 더 나은 모델과 플랫폼도 많다.
그럼에도 OpenCV 5는 현대 CV 제품 팀이 다시 한 번 질문하게 만든다.
“이 pipeline에서 OpenCV는 단순 전후처리 library인가, 아니면 inference와 hardware path까지 품을 수 있는 실행 기반인가?”

그 질문이 가능해졌다는 것 자체가 이번 릴리스의 가장 큰 변화다.