Vision AI 제품 개발 과정 - (3) 모델 최적화 및 경량화, 분석엔진 개발, 시스템 배포 및 운영
이 글은 Vision AI 제품 개발 과정의 세 번째 편으로,
전체 내용은 다음과 같은 흐름으로 구성되어 있습니다:
- (1) Task 정의, 데이터 수집, 데이터 정제
- (2) 데이터 가공, 학습데이터셋 구축, 모델 학습 및 검증
- (3) 모델 최적화 및 경량화, 분석엔진 개발, 시스템 배포 및 운영
8. 모델 최적화 및 경량화
모델 학습과 검증이 완료되면,
실제 시스템 환경에 맞춰 모델을 최적화하고 경량화하는 단계가 필요합니다.
이 과정에서는 추론 속도, 메모리 사용량, 배치 처리 구조, 플랫폼 이식성 등
운영 환경 전반을 고려해 실무에 적합한 모델 구조를 완성합니다.
왜 필요한가?
실제 제품 환경에서는 다음과 같은 요구사항들이 모델 최적화를 필요로 합니다:
| 요구사항 | 세부 내용 |
|---|---|
| 실시간성 | 실시간 분석을 위한 FPS 확보 |
| 자원 효율성 | GPU 메모리와 연산 자원 효율 활용 |
| 시스템 연동 | 분석엔진이나 웹 연동 시 부하 최소화 |
| 환경 제약 | 폐쇄망 등 자원 제약 환경 대응 |
| 확장성 | 모델 복수 탑재 및 멀티 채널 입력 대응 |
이러한 요구사항들을 충족하기 위해서는 모델 단위의 성능 개선을 넘어서,
시스템 전체 관점에서의 최적화가 필요합니다.
최적화(Optimization)
ONNX (Open Neural Network Exchange)
- PyTorch 모델을 범용 포맷으로 변환
- 다양한 프레임워크 및 엔진과의 호환성을 높일 수 있음
- 플랫폼 간 이식성을 확보하는 데 유리
- 다양한 하드웨어(CPU, GPU, NPU 등) 환경에 대응이 가능
- 단, ONNX 자체는 실행 엔진이 아니므로
실제 성능은 런타임에 따라 달라짐
TensorRT (TRT)
- NVIDIA 기반 고속 추론 최적화 엔진
- Layer fusion, kernel auto-tune, quantization 내장
- YOLO 계열과의 궁합이 뛰어남
- 엔진 생성 시점의 GPU 아키텍처에 종속되는 구조
하드웨어 종속성과 아키텍처 호환성
TensorRT 엔진은 하드웨어에 종속되는 형식이지만,
동일한 GPU 아키텍처 간에는 호환됩니다.
예를 들어, A10과 A40은 둘 다 Ampere 아키텍처 기반이기 때문에,
동일한 조건에서 생성한 .trt 파일을 서로 호환하여 사용할 수 있습니다.
실무에서는 A40에서 추출한 엔진 파일을 A10 시스템에 그대로 이식해
테스트/운영을 빠르게 진행하기도 합니다.
| 아키텍처 | 출시 | GPU | 특징 | TRT |
|---|---|---|---|---|
| Volta | 2017 | V100 | 1세대 Tensor Core | ≤8.6 |
| Ampere | 2020 | A10,A40,A100 | 범용 학습·추론 | ≤8.6 |
| Ada Lovelace | 2022 | RTX 4080,4090 | 고해상도 비전 | ≤8.6 |
| Hopper | 2022~ | H100,GH200 | LLM 학습 최적 | 9.x~ |
| Blackwell | 2024~ | B100,B200,5090 | 초거대 추론 특화 | ≥10.8 |
아키텍처별 CUDA와 TensorRT 버전 호환성을 반드시 확인해야 함
- 아키텍처가 변경될 경우(예: Ampere → Blackwell)
.trt엔진 재생성 필요- TensorRT 8.6.1은 Ampere 및 Ada Lovelace까지만 사용 가능
- Blackwell은 반드시 TensorRT 10.8 이상 + CUDA 12.8 이상 환경에서 생성해야 함
경량화(Quantization)
| Precision | 설명 | 특징 |
|---|---|---|
| FP32 | 32bit 부동소수점 | 가장 정확하지만 무겁고 느림 |
| FP16 | 16bit 부동소수점 | 대부분의 실무에서 가장 적절 |
| INT8 | 8bit 정수형 | 가장 빠르지만 정확도 저하 우려 있음 |
일반적으로 FP16 + batch=8이 가장 안정적인 설정으로 많이 사용됩니다.
INT8은 별도의 calibration dataset이 필요하며,
작은 객체 탐지에서는 성능 저하 가능성이 있으므로 주의가 필요합니다.
학습 배치 vs 추론 배치
| 항목 | 학습 배치 (train batch) | 추론 배치 (inference batch) |
|---|---|---|
| 목적 | 모델 업데이트(loss 평균 계산) | 결과 생성 속도 최적화 |
| 설정 기준 | GPU 메모리, 모델 크기 등 | 실시간성(FPS), latency 등 |
| 실무 적용 예 | batch=8~64: 학습 안정성 확보 | batch=8: 실시간/반실시간 기준 최적 |
실시간성이 중요한 시스템에서는
batch=8 정도로 latency와 throughput의 균형을 맞추는 경우가 많습니다.
반면, 실시간 반응성이 매우 중요한 경우에는 batch=1 설정도 고려됩니다.
실행 최적화로서의 batch size 조정
| 항목 | 설명 |
|---|---|
| 목표 | 초당 처리 속도 증가 (throughput), GPU 자원 최대 활용 |
| 영향 받는 요소 | GPU VRAM, 연산 성능, 메모리 대역폭 |
| 예시 | batch=1: 지연(latency) 최소화, batch=8~32: 처리량 최대화 |
| 사용 예 | TensorRT, ONNX Runtime, OpenVINO 등에서도 –batch 옵션 사용 |
즉, batch=8로 설정하는 것은 모델 구조를 바꾸지 않고
실행 환경을 조정하여 성능을 개선하는 실행 최적화 전략(inference optimization)입니다.
# TensorRT 엔진 변환 실제 사용 예시
profile.set_shape(self.input_name, [1, 3, 1280, 1280], # 최소 입력 (1장)
[8, 3, 1280, 1280], # 최적 입력 (8장)
[8, 3, 1280, 1280]) # 최대 입력 (8장)
# min=1, opt=8, max=8 설정 → 실무에서 자주 사용되는 안정적 구성
- 단, batch=8 설정 시 추론을 시작하려면 프레임 8장이 먼저 수집되어야 하므로,
입력 프레임 도착 속도에 따라 추가 지연(latency) 이 발생할 수 있습니다. - 실시간 시스템에서는 이 대기 시간이 3~5초 수준의 latency로 나타날 수 있으며,
Throughput을 높이기 위한 선택이 즉시 응답성과는 상충할 수 있다는 점을 고려해야 합니다.
Latency vs Throughput
| 항목 | 설명 |
|---|---|
| Latency | 하나의 입력(예: 1장 이미지)이 처리되는 데 걸리는 시간 (단위: ms) |
| Throughput | 단위 시간당 처리 가능한 입력 수량 (ex. FPS, samples/sec) |
- 실시간성이 중요한 경우 Latency 최소화
- 대량 데이터 분석이 중요한 경우 Throughput 최대화
→ 이 둘은 Trade-Off 관계에 있으므로 목적에 따라 조정해야 합니다.
Vision AI 기준에서의 Latency vs Throughput
Vision AI에서는
- Latency는 실시간 반응성을 결정하고,
- Throughput은 전체 시스템 처리 효율에 영향을 미칩니다.
예시:
- Latency: 3초 → 프레임 입력 후 3초 뒤 결과 도달
- Throughput: 10 FPS → 초당 10장의 프레임 처리 가능
두 지표는 일반적으로 반비례 관계이며,
모델 처리 속도, 프레임 수집 주기, 배치 크기, 스트림 버퍼링 등의 요소에 따라 달라집니다.
- 실시간 알림이 중요한 시스템 → 낮은 Latency
- 병렬 분석이나 대량 처리 목적 → 높은 Throughput
일반적으로 Throughput을 높이기 위해 batch size를 증가시키면 Latency가 길어지고,
Latency를 줄이기 위해 batch size를 낮추면 Throughput은 감소합니다.
Vision AI 시스템에서는
실제 사용 목적에 맞는 Latency/Throughput 밸런스를 설계하는 것이 핵심입니다.
실무 사례: 실시간이지만 모든 프레임을 처리하지 않는 구조
현재 담당 중인 제품은 실시간 CCTV 기반이지만 모든 프레임을 추론하지는 않으며,
업무 목적에 맞는 반응성 확보를 목표로 시스템이 설계되어 있습니다.
| 항목 | 과거 설정 | 현재 설정 | 개선 효과 |
|---|---|---|---|
| 배치 크기 | batch=16 | batch=8 | 메모리 사용량 감소, latency 완화 |
| Latency | 수 초 이상 | 약 3~5초 수준 | 업무 목적상 허용 가능한 지연 |
| 처리 방식 | 모든 프레임 처리 | 프레임 샘플링 + 배치 추론 | 안정성과 효율성 균형 확보 |
처리 구조 설명
- CCTV 스트림으로부터 초당 30프레임(FPS)의 영상이 시스템에 수신됨
- 프레임 샘플링을 통해 초당 약 10장의 프레임만 분석 대상으로 선택
- 선택된 프레임은 내부 큐에 저장되어 batch 단위로 묶임
- batch가 채워지면 TensorRT 엔진을 통해 추론 수행
- 추론 결과는 후처리 과정을 거쳐 알림 시스템에 전달됨
(이때 알림 시스템의 처리 속도에 따라 추가적인 지연이 발생할 수 있음)
왜 모든 프레임을 처리하지 않는가?
- 모든 프레임을 처리하면 GPU 점유율 급상승 및 시스템 불안정성 초래
- 90% 이상의 GPU 점유율은 멀티 채널 확장 및 장시간 운영에 위험
- 작업자가 빠르게 이동하거나 카메라가 흔들리는 경우 등에서
프레임 일부를 선택적으로 처리해도 안전 이벤트 감지에는 문제가 없음 - 업무 목적은 “즉시 탐지”가 아니라, “위험 상황 발생 시 경고”이기 때문에
3~5초 지연은 업무상 허용 가능한 수준
병목 현상
현재 시스템은 전체적으로 안정적으로 동작하지만,
간헐적인 처리 지연 또는 추론 큐 대기 시간 증가 현상이 관찰되고 있습니다.
- 영상 수신 지연, 큐 적체, 배치 대기, 후처리 전송 등
다양한 병목 가능성이 존재하며 - 현재는 정확한 원인 파악을 위한 프로파일링을 진행 중입니다.
실시간성의 재정의
| 구분 | 설명 |
|---|---|
| 잘못된 정의 | 모든 프레임을 가능한 한 빠르게 처리하는 것 |
| 올바른 정의 | 업무 목적에 맞는 속도로 반응 가능한 시스템을 구성하는 것 |
실시간성은 “속도”가 아니라 “적시성”입니다.
“언제까지 반응하면 되는가”를 기준으로 설계 방향을 잡아야 합니다.
정리
최적화와 경량화는 AI 모델을 실제 제품 환경에 맞게 다듬는 핵심 과정입니다.
- 실시간성과 정확도의 균형점 찾기
- 시스템 자원과 요구사항에 맞는 최적화 전략 수립
- 플랫폼 및 환경에 맞는 이식성 확보
- 실무 환경에 적합한 배치 처리 구조 설계
추론 속도, 메모리 사용량, 배치 처리 구조, 플랫폼 이식성까지 고려해야 하며,
그 모든 조합의 끝에서 “운영 가능한 AI 모델”이 완성됩니다.
9. 분석엔진 개발
모델 최적화 및 경량화가 완료되었더라도, 바로 제품에 탑재할 수는 없습니다.
모델을 어떻게 호출하고, 결과를 어떤 방식으로 처리·활용할 것인지까지 모두 구조화해야 합니다.
이 과정을 분석엔진 개발이라 합니다.
분석엔진은 단순히 모델을 실행하는 것을 넘어,
여러 모델을 통합하고 외부 시스템과 연동하는 AI 제품의 핵심 미들웨어 역할을 수행합니다.
특히 실시간 CCTV 분석처럼 멀티 채널이 기본인 환경에서는
분석엔진 구조가 시스템의 안정성과 확장성을 좌우합니다.
분석엔진 구조의 핵심 요소
| 특징 | 설명 |
|---|---|
| 입력 처리 | 다양한 형태의 이미지/영상 데이터 지원 |
| 공통 인터페이스 | 모델별로 일관된 추론 함수 구조 제공 |
| 출력 형태 | 서비스 연동에 적합한 구조화된 형태로 출력 |
| 호환성 | 다양한 모델 구조 변경 시에도 외부 호출 방식 동일 |
| 블록 기반 구조 | 각 분석 기능을 Block 단위로 분리하여 재사용성과 유지보수 향상 |
| 알람 로직 내장 | 조건 기반 이벤트 감지 및 시스템 알림 연동 가능 |
이러한 구조를 갖추면, 모델이 변경되더라도 외부 시스템과의 연동 방식은 동일하게 유지됩니다.
또한, 결과값은 서비스단에서 후처리하거나
웹과 연동하기에 적합한 형태로 출력되도록 구성되어 있습니다.
제품 적용 시 고려사항
| 항목 | 설명 |
|---|---|
| 멀티 채널 환경 | 실시간 영상 분석 시 일관된 추론 흐름 유지 |
| 후처리 파이프라인 | 시각화, 저장, 알람 등 다양한 후처리 연동 |
| 성능 모니터링 | FPS, 메모리 사용률, latency 등 시스템 자원과 성능 관리 |
| 인터페이스 설계 | 다양한 모델을 유연하게 통합하기 위한 공통 구조 필요 |
인터페이스 개발과 모델 통합
Vision AI 시스템은 시간이 지남에 따라 지속적으로 새로운 모델이 추가됩니다.
따라서 분석엔진은 유연한 인터페이스 구조를 가져야 하며,
모델별 통합을 위한 개발이 중요합니다.
모델 인터페이스는 다음과 같은 함수 구조를 따릅니다:
| 함수 | 설명 |
|---|---|
| load() | 학습된 모델을 메모리에 로드 |
| preprocess() | 입력 데이터를 모델이 처리할 수 있도록 전처리 |
| inference() | 모델을 실행하여 결과 도출 |
| postprocess() | 모델의 출력을 서비스에 맞게 가공 |
이러한 구조는 엔진에서 호출되는 방식이 동일하게 유지되기 때문에,
새로운 모델이 추가되더라도 인터페이스만 맞춰주면 통합이 가능합니다.
또한 모델별로 입력 해상도, 출력 형태, 후처리 방식이 다르므로
config 파일을 함께 구성하여 데이터 흐름을 정의합니다.
정리
분석엔진은 AI 모델을 실제 서비스로 연결하는 핵심 인프라입니다.
- 모델 통합을 위한 공통 구조 설계
- 안정적인 연동을 위한 표준화된 출력 처리
- 실시간성과 유지보수까지 고려한 구조
- 알람 로직을 통한 즉각 대응 체계 마련
- 신규 모델도 인터페이스만 맞추면 손쉽게 통합 가능
분석엔진의 구조가 곧 제품의 신뢰성과 품질을 결정합니다.
기술을 서비스로 만드는 마지막 관문이기에
구조화와 모듈화에 집중된 설계가 필요합니다.
10. 시스템 배포 및 운영
분석엔진을 실제 서비스에 적용하려면
① 시스템 연동 → ② 현장 설치 → ③ 안정적인 운영의
세 단계를 순차적으로 거쳐야 합니다.
연동: 외부 시스템과 연결하기
분석 결과를 사용자에게 전달하고, 외부 시스템과 통합하는 단계입니다.
분석 요청부터 결과 시각화, 스트리밍, 저장, 음성 경고 기능까지 연동하는 것이 주요 역할입니다.
| 구성 요소 | 역할 | 설명 |
|---|---|---|
| Flask (API Agent) | REST API 서버 | 사용자 요청을 분석엔진에 전달하는 웹 인터페이스 |
| Redis | 임시 저장소 | 분석 상태, 시나리오 정보 공유용 메모리 DB |
| RTMP | 스트리밍 프로토콜 | 실시간 영상 전송을 위한 표준 프로토콜 |
| Ant Media Server | 미디어 서버 | RTMP를 웹 브라우저용으로 변환하는 서버 |
| IP Speaker | 음성 경고 | TTS 음성 안내 송출 (예: “보호구를 착용해주세요”) |
이 구성 요소들은 분석엔진 바깥에서 동작하며,
사용자 요청 → 분석 실행 → 결과 전송 → 현장 음성 경고 송출까지의 흐름을 연결합니다.
화학공장에서는 시각적 알림만으로는 즉각적인 대응이 어려운 상황을 고려해,
IP Speaker를 활용한 실시간 음성 안내 시스템을 구축하였습니다.
연동 흐름 예시
- 사용자가 웹에서 분석 요청
- Flask 서버가 요청을 분석엔진에 전달
- 분석 결과 영상이 RTMP로 송출
- Ant Media Server를 통해 웹에 실시간 중계
- Redis 등을 통해 상태값 공유 및 알림 연동
- 분석 결과에 따라 관제 시스템 알림 및 IP Speaker를 통한 음성 알림 송출
시스템 데이터 흐름 다이어그램
[웹 브라우저] ←→ [Flask API] ←→ [분석엔진]
↓
[Redis DB]
↓
[분석엔진] → [RTMP] → [Ant Media Server] → [웹 브라우저]
↓
[IP Speaker]
데이터 흐름 설명:
- 요청 흐름: 웹 → Flask → 분석엔진 (분석 시작/중지)
- 상태 관리: Flask ↔ Redis (분석 상태, 설정 정보 공유)
- 영상 스트리밍: 분석엔진 → RTMP → Ant Media Server → 웹 (실시간 영상 중계)
- 음성 알림: 분석 결과 → IP Speaker (현장 음성 경고)
설치: 실제 환경에 적용하기
시스템 연동이 완료되면, 이를 실제 현장 환경에 설치하고 안정적으로 작동하도록 구성합니다.
이 때 하드웨어 제약, 네트워크 환경, 보안 정책 등 실무 요소를 종합적으로 고려해야 합니다.
배포 환경 고려사항
| 고려 항목 | 세부 내용 |
|---|---|
| 하드웨어 환경 | GPU 사양, 메모리, 저장 공간 등 |
| 네트워크 구성 | 폐쇄망, 인터넷 연결, 포트 및 대역폭 설정 |
| 보안 정책 | 방화벽, 접근 권한, 데이터 암호화 등 |
| 운영 환경 | Linux, Windows, Docker 등 컨테이너 구성 포함 |
| 모니터링 체계 | 로그 수집, 성능 지표, 이상 감지 등 |
운영: 안정적인 사용을 위한 관리 체계
운영 단계에서는 시스템을 안정적·지속적으로 유지할 모니터링과 대응 체계가 필요합니다. 예기치 못한 성능 저하나 사용자 피드백에 유연하게 대응할 수 있어야 합니다.
또한, 시운전 및 실제 사용 과정에서 수집된 데이터를 바탕으로
모델 재학습과 성능 개선 작업을 지속적으로 수행합니다.
이러한 재학습 활동은 AI 시스템의 안정적 운영을 위한 핵심 유지보수 과정의 하나입니다.
운영 모니터링 항목
| 항목 | 설명 |
|---|---|
| 시스템 성능 | CPU, GPU, 메모리, 네트워크 사용률 등 |
| 모델 성능 | 추론 속도, 정확도, 오탐률 등 |
| 로그 분석 | 에러 발생 시점, 원인 추적, 경고 로그 확인 |
| 사용자 피드백 | 기능 개선 요청, 사용 편의성 검토 등 |
시운전 및 모델 개선
시운전 단계에서는 실시간 분석 품질과 오탐/미탐 여부를 집중적으로 점검하였습니다.
현장 적용 초기에 수집된 결과를 기반으로,
다음과 같은 절차로 모델 재학습 및 버전 업데이트가 이루어졌습니다.
화학공장에서의 모델 유지보수 및 재학습 사례
- 초기 시운전
- YOLOv11L 모델을 기반으로 시운전 시작
- 실시간 분석 품질, 오탐/미탐 여부 집중 점검
- 오탐 수집 및 재학습
- 시운전 중 수집된 오탐 데이터를 기반으로
- AI Researcher가 YOLOv12L 모델로 업데이트 및 재학습 수행
- 성능 문제 발생
- YOLOv12L 적용 시 현장 시스템에서 OOM(Out-Of-Memory) 문제 발생
- 메모리 부족으로 안정적인 운용 어려움
- 모델 개선 및 최적화
- AI Engineer가 모델 크기와 추론 효율을 고려
- YOLOv12M으로 모델 변경 후, 재학습 및 최적화
- 운영 모델 구축 및 탑재
- 경량화된 YOLOv12M 모델을 분석엔진에 탑재
- 실시간 운영에 적합한 모델로 최종 구축
실무에서는 더 큰 모델이 항상 더 좋은 성능을 보장하지 않으며,
운영 환경에 맞는 모델 크기 조정과 메모리 최적화가 중요합니다.
정리
시스템 배포 및 운영은
AI 모델이 실제 환경에서 안정적으로 작동할 수 있도록
구성 요소를 연동하고, 운영 환경에 맞춰 설치 및 유지관리하는 단계입니다.
- 시스템 연동: 분석 요청부터 음성 알림까지 외부 시스템과 연결
- 현장 설치: 하드웨어, 네트워크, 보안 환경에 맞춘 구성
- 운영 관리: 성능 모니터링 및 사용자 피드백 반영
- 모델 유지보수: 시운전 → 오탐 수집 → 경량화 재학습 순환 구조
시스템 배포와 운영은 기술을 제품으로 완성하는 마지막 실행 단계입니다.
현장의 제약 속에서도 안정성과 확장성을 유지할 수 있도록
설계와 설치, 유지보수까지 하나의 흐름으로 이어져야 합니다.
Vision AI 제품 개발에서 AI Engineer의 역할
앞서 살펴본 10단계는
AI 분석 시스템을 기획 의도에 맞춰 구현하고, 현장에서 작동할 수 있도록 준비하는
End-to-End AI Engineer의 책임 범위입니다.
이후에는 분석 결과를 사용자에게 제공하고,
웹을 통해 제어 가능한 형태로 연동하는 작업이 이어집니다.
해당 영역은 프론트엔드 및 백엔드 개발을 포함한 웹 서비스 구축의 영역에 해당합니다.
마무리: Vision AI 제품 개발, 그 전 과정을 돌아보며
AI 모델을 만드는 일도 결코 간단하지 않지만,
그 모델을 실제 현장에 적용해 안정적으로 작동하도록 만드는 일은
또 다른 차원의 과제입니다.
Vision AI 제품 개발은 알고리즘 구현에 국한되지 않으며,
현실의 문제를 해결하는 실용적 시스템을 완성하는 과정에 가깝습니다.
Task 정의부터 데이터 수집, 모델 학습, 분석엔진 개발, 시스템 배포와 운영에 이르기까지
모든 단계는 서로 유기적으로 연결되어 있습니다.
각 과정은 기술과 실무, 이론과 현실의 경계를 넘나들며 완성에 이릅니다.
이 글을 통해 단지 “모델을 잘 만드는 방법”이 아니라,
AI를 제품으로, 그리고 가치로 전환하는 과정의 본질에 조금 더 가까워졌기를 바랍니다.
결국 중요한 것은 얼마나 정교한 모델을 만들었느냐가 아니라,
얼마나 현실에서 유용하고 지속 가능한 방식으로 구현했느냐일 것입니다.
Vision AI 제품화는 기술의 완성 이전에, 사람과 현실을 이해하는 데서 시작됩니다.