현업에서 Vision AI와 MLOps 플랫폼을 개발하며 배운 Edge Vision AI의 구조와 생태계, 그리고 AI를 실제 현실 세계에 배치하기 위해 어떤 기술들이 필요한지 정리한 글입니다.
아래 내용은 GeekNews 스타일에 맞게 GPT로 요약한 것으로 글의 내용을 완벽히 담지 못하니 직접 본문에서 확인하시는 것을 권장 드립니다.
- 왜 Vision AI는 Edge와 잘 맞는가
- 영상은 데이터가 크고 지속적으로 발생하기 때문에 모든 영상을 Cloud로 전송하면 네트워크 사용량과 비용이 커짐
- 지연이나 네트워크 장애, 개인정보·내부 영상의 외부 전송 문제도 존재
- 실제 필요한 것이 영상 자체보다 영상에서 추출한 정보인 경우가 많아, 데이터가 발생하는 현장에서 바로 추론하는 Edge AI와 특히 잘 맞음
- Edge에서는 어떤 Vision AI를 사용하는가
- Classification, Object Detection, Segmentation 등이 대표적인 Vision Task
- MobileNet·EfficientNet 같은 경량 CNN부터 YOLO, RT-DETR, RF-DETR 등 다양한 모델이 존재
- 같은 Object Detection이라도 모델마다 구조, 크기, 정확도와 요구 Hardware가 크게 다름
- Edge에서는 가장 높은 Benchmark보다 제한된 자원과 목적에 맞는 모델을 선택하는 것이 중요함
- 현업에서 모델 선택은 Benchmark만의 문제가 아님
- 여러 Camera Stream을 동시에 처리해야 하는 Edge 환경에서는 모델 크기와 연산량이 직접적인 제약이 됨
- YOLO는 Nano·Small처럼 10M Parameter 이하의 경량 Variant가 있고 다양한 Hardware에서 실행하기 쉬워 Edge에서 특히 유리함
- 하지만 실제로 더 중요한 차이는 ONNX, TensorRT, Core ML, LiteRT, Qualcomm QNN, Hailo 등 얼마나 다양한 Runtime과 Accelerator로 Export할 수 있는가
- 특정 NPU에서는 지원 Operator와 Quantization 방식까지 모델별로 다시 검증해야 하기 때문에, Benchmark가 좋은 모델이라고 실제 Device에 쉽게 올라가는 것은 아님
- 반대로 YOLO는 기술적으로 배포가 편하지만 Ultralytics의 AGPL-3.0 License 때문에 비공개 상용 제품에서는 별도 License 검토가 필요함
- 결국 현업의 모델 선택은 정확도뿐 아니라 모델 크기, Hardware, Runtime 생태계, 배포 편의성과 License까지 함께 보는 문제
- 모델을 Edge에 맞게 최적화하는 과정
- 처음부터 작은 모델을 선택하거나 Quantization, Pruning, Knowledge Distillation, Resolution 조정 등의 방법을 활용
- 중요한 것은 단순히 모델 파일을 작게 만드는 것이 아니라 연산량과 Memory 사용량을 낮춰 제한된 Hardware에서도 현실적인 성능을 확보하는 것
- Edge Device는 NPU Board 하나를 의미하지 않음
- 모델 크기와 Camera 수, FPS뿐 아니라 Codec, 전력, 발열, I/O, 설치 환경, 장기 공급까지 고려해야 하는 하나의 System
- Raspberry Pi 같은 SBC부터 Hailo NPU가 통합된 산업용 Edge AI Box, NVIDIA Jetson, GPU 기반 Edge Server까지 선택지가 다양함
- 자동차·로봇·Smart Camera처럼 개발자가 Hardware를 직접 선택할 수 없고 제품 자체에 AI Hardware가 통합된 경우도 존재
- 같은 NPU나 GPU를 사용해도 Camera 입력, Codec, Thermal Design, 전원과 현장 조건에 따라 실제 적합성이 달라지기 때문에 TOPS 하나로 Device를 비교하기 어려움
- NPU가 있다고 AI가 자동으로 빨라지는 것은 아님
- PyTorch 모델을 GPU/NPU에 전달한다고 해당 가속기에서 자동으로 실행되는 것은 아님
- TensorRT, OpenVINO, Core ML 같은 Runtime과 Compiler를 통해 모델을 Hardware가 처리할 수 있는 형태로 변환해야 함
- 지원하지 않는 Operator가 있으면 일부 연산이 CPU로 넘어가거나 모델 변환 자체가 실패할 수도 있음
- 결국 실제 성능은 Model ↔ Runtime ↔ Hardware가 얼마나 잘 맞물리는지가 결정함
- 실제 Edge Vision AI는 모델 하나로 끝나지 않음
- 실제 System은 대략
Camera → Decode → Preprocess → AI Model → Postprocess → Tracking / Logic → Event - 여러 Camera를 처리하면 Decode, Frame Scheduling, 병렬 처리, Memory Copy, GPU/NPU 사용률까지 고려해야 함
- 모델 Inference를 몇 ms 줄이는 것보다 Decode나 데이터 복사의 병목을 해결하는 것이 더 큰 효과를 내기도 함
- 결국 핵심은 가장 강력한 Hardware를 사용하는 것이 아니라 제한된 연산 자원을 전체 System에서 얼마나 효율적으로 사용하는가
- 실제 System은 대략
- 모델 학습에서 현장 배포까지
- 대규모 Dataset과 연산 자원이 필요한 Training은 GPU Server나 Cloud에서 수행하는 것이 일반적
- 학습한 모델을 평가하고 최적화한 뒤 Edge Device에 배포
- Device가 늘어나면 어떤 모델이 어디에 배포되어 있는지, Update와 Rollback을 어떻게 할 것인지 관리해야 하며 여기서 MLOps가 필요해짐
- 즉 Cloud는 모델을 만들고 관리하고, 실제 AI 연산은 데이터가 발생하는 Edge에서 수행하는 구조
- 더 큰 AI와 더 가까운 AI
- Foundation Model 중심의 Cloud AI는 더 많은 데이터와 연산 자원을 사용해 AI가 할 수 있는 일의 상한을 높이는 방향
- Edge AI는 이미 가능한 기술을 감당할 수 있는 비용과 전력으로 더 많은 현실 공간에 배치할 수 있도록 문턱을 낮추는 방향
- 실제 현장에서는 가장 범용적이고 똑똑한 모델보다 특정 목적을 정해진 비용 안에서 안정적으로 수행하는 System이 더 중요할 수 있음
- Edge에서는 특히 모델을 만드는 것보다 그 이후 실제 Device에 배포하고 오래 운영하는 과정에서 많은 문제가 시작됨
- 결국 AI가 산업과 일상에 확산되는 과정은 더 큰 모델을 만드는 경쟁뿐 아니라, 이미 확보한 AI를 더 많은 장소에서 현실적으로 운영할 수 있게 만드는 방향으로도 발전하고 있음