소속: 4by4 Inc. · Pixell Lab 역할: ML Engineer 기간: 2023.10 – 2024.03 산업 도메인: 미디어 AI SaaS (Video Enhancement)
Situation
PMS alpha에서 FHD 30fps 실시간 처리를 달성했으나, On-Premise 싱글 GPU 구조의 한계가 명확해졌다. Cloud 환경에서도 동일한 성능을 유지해야 했고, GPU Cluster를 활용하여 동시에 여러 비디오를 처리할 수 있는 구조가 필요했다. 또한 SharpClear 단일 모델에서 Super Resolution 등 더 많은 모델에 대한 추론 파이프라인 지원이 요구되었다.
alpha에서 분석한 Python GIL 및 Disk I/O 병목, Pipe 기반 IPC의 구조적 한계를 해결하는 것이 핵심 과제였다.
Task
- 팀 구성:
- Sales & PM ×1: BM 기획, 프로젝트 관리
- DL Researcher ×2: Model 개발
- Backend Engineer ×1: Backend Service 개발
- ML Engineer(본인) ×1: Inference Pipeline 개발
- 담당 영역:
- Cloud에서도 FHD 30fps 가능한 고성능 Inference Pipeline 개발
- SR Model Inference Class 구현
- Pipe 기반 IPC를 Ray + 비동기로 전환
- Video 생성 시 프레임 전달을 Disk를 거치지 않도록 변경
- Docker 이미지 자동 배포 (GHCR)
- MLflow 기반 모델 관리 및 배포 자동화 (AWS ECS)
- 목표: SharpClear + SuperResolution 지원. Cloud 환경에서도 FHD 30fps 처리.
Action
기술 스택 & 시스템 구성
| 분류 | 기술 |
|---|---|
| Language | Python |
| Framework | Ray |
| ML Ops | MLflow (AWS ECS), GitHub Actions |
| Deployment | Docker, GHCR |
| Infrastructure | On-Premise + AWS (VM 기반 Ray Cluster) |
이전 버전 대비 변경점
| 항목 | alpha | v1.0 | 개선 효과 |
|---|---|---|---|
| IPC 방식 | Pipe 기반 싱글 서브프로세스 | Ray Remote Actor + 비동기 | 1:N Processor 병목 해소, 전체 속도 44% 향상 |
| Disk I/O | FFmpeg으로 디스크에 프레임 저장 후 경로 전달 | 인메모리 프레임 전달 + 직접 인코딩 | 373MBps 절감 (30fps FHD 기준) |
| 모델 | SharpClear 단일 | SharpClear + Super Resolution (택 1) | 모델 확장 |
| 모델 관리 | 수동 | MLflow (AWS ECS) | 버전 관리 체계화 |
| CI/CD | 수동 빌드 | GitHub Actions + GHCR | Docker 이미지 자동 배포 |
| 클러스터 | On-Premise 싱글 노드 | On-Premise + AWS Ray Cluster | GPU Cluster 활용 |
핵심 구현 사례
1. Pipe 기반 IPC → Ray Remote Actor 비동기 구조 전환
문제: alpha의 기존 구조는 FFmpeg으로 디스크에 프레임을 저장한 뒤, Pipe로 이미지 경로를 추론 Processor들에게 전달하는 방식이었다. 각 프로세스가 로컬 디스크에서 이미지를 읽고 결과를 다시 저장하기 때문에 Disk I/O가 심각한 병목이었으며, 특히 AWS EBS 같은 네트워크 스토리지 환경에서는 이 병목이 치명적이었다.
구현: 전임자가 만든 추론 파이프라인을 버리고 완전히 새롭게 재설계했다. GPU별로 Ray Remote Actor를 생성하고, 주 Processor가 프레임을 모두 메모리에 보유한 채 추론 Processor(Remote Actor)로 직접 전송하는 구조로 전환했다. 주 Processor와 추론 Processor 모두 비동기 구조를 적용했으며, 한 추론 Processor에 동시에 2개의 요청을 전송하도록 설계했다.
추론 Processor는 전처리 → H2D(Host to Device) → Inference → D2H(Device to Host) → 후처리를 수행하는데, CPU-bound 작업(전/후처리)과 GPU-bound 작업(Inference)이 분리되어 있다. 동시 2개 요청을 보내면 한 요청이 GPU에서 추론하는 동안 다른 요청의 CPU-bound 전/후처리가 병렬로 진행되어 추론 속도를 더욱 끌어올릴 수 있었다.
추론 결과는 다시 주 Processor로 전달되고, 주 Processor는 이를 바로 비디오로 인코딩한 뒤 메모리를 해제한다. 결과적으로 Disk I/O를 획기적으로 줄여 30fps FHD 기준 373MBps를 절감하고, 전체 Inference 속도를 44% 향상시켰다.
2. Inference Processor 공통 인터페이스 설계
문제: alpha에서는 GPU와 NPU의 추론 코드가 완전히 분리되어 있어 유지보수 부담이 있었다.
구현: 추론 Processor의 공통 인터페이스를 선언하고 이를 상속하는 구조로 구현하여, Nvidia GPU를 사용하든 다른 장치(예: Furiosa NPU)를 사용하든 주 Processor의 추론 엔진을 공통으로 사용할 수 있게 했다. 이를 통해 디바이스 추가 시 인터페이스 구현체만 작성하면 되는 구조를 확보하여 유지보수성을 향상시켰다.
3. SR Model Inference Class 구현
SharpClear에 이어 Super Resolution 모델에 대한 Inference Class를 구현했다. SR 모델은 출력 해상도가 입력의 4배이므로 결과 이미지의 메모리 크기가 4배가 되는 점 외에는 큰 기술적 이슈 없이 기존 인터페이스를 확장하여 지원했다.
4. MLflow 기반 모델 관리 및 배포 자동화
문제: alpha에서는 모델 버전 관리와 배포가 수동이었다.
구현: AWS ECS에 MLflow를 배포하여 모델 버전 관리를 체계화했다. ONNX와 TensorRT 아티팩트를 모두 MLflow 모델 아티팩트로 관리하여, 모델의 변환 이력과 최적화 결과를 추적할 수 있게 했다. GitHub Actions를 연계하여 Docker 이미지의 GHCR 배포까지 자동화했다.
5. Ray Cluster 구축 및 운영
On-Premise 환경과 AWS VM 기반 환경 모두에서 Ray Cluster를 구축하고 운영했다. GPU Cluster를 통해 동시에 여러 비디오를 처리할 수 있는 구조를 확보했다.
Result
기술 성과
- 추론 파이프라인 전면 재설계: Ray Remote Actor 비동기 구조 + 동시 2요청 파이프라이닝
- Pipe → Ray 전환 + Multi-Processing 도입으로 전체 Inference 속도 44% 향상
- 인메모리 프레임 전달로 Disk I/O 373MBps 절감 (30fps FHD 기준)
- GPU/NPU 공통 Inference Processor 인터페이스 확립
- SharpClear + Super Resolution 지원 (택 1)
- On-Premise + AWS Ray Cluster 구축 및 운영
- MLflow(ONNX + TensorRT 아티팩트) 기반 모델 버전 관리 및 GHCR 자동 배포 구성
비즈니스 임팩트
- 외부 고객과 PoC를 진행할 수 있는 서비스 구성 확보
- 외부 및 내부 고객에게 서비스를 오픈하는 사례 발생, 상용화 가능성 검증
회고
잘한 점
전임자가 만든 추론 파이프라인을 과감히 버리고 완전히 새롭게 재설계한 것이 핵심적인 판단이었다. 이를 통해 컴퓨터 자원을 훨씬 효율적으로 사용할 수 있게 되었다. 특히 Disk I/O 병목을 근본적으로 제거한 덕분에 클라우드 환경에서 저성능 EBS를 사용하더라도 무리 없이 비디오 인코딩을 수행할 수 있게 되었으며, 이는 Cloud 확장의 핵심 전제 조건이었다. 또한 Inference Processor의 공통 인터페이스를 설계하여 GPU/NPU 디바이스에 관계없이 주 Processor의 추론 엔진을 공통으로 사용할 수 있는 구조를 확보한 것은 이후 버전의 유지보수성에 크게 기여했다.
아쉬운 점 / 다시 한다면
한 번에 하나의 모델에 대한 추론 및 비디오 인코딩만 가능한 구조였다. Denoise 후 SR 등 다중 모델을 직렬로 처리하는 워크플로우는 지원하지 못했으며, 이는 v2.0에서 해결하게 되었다. 또한 AWS에서 Ray Cluster를 VM 기반으로 운영했는데, 프로비저닝 시 간헐적으로 AZ 관련 오류가 발생하여 Worker Node가 프로비저닝되지 않는 문제가 있었다.
배운 점
기존 코드를 개선하는 것보다 근본적으로 재설계하는 것이 더 나은 결과를 가져올 수 있다는 것을 경험했다. alpha의 Pipe + Disk I/O 구조를 패치하는 것이 아니라, 인메모리 전달 + 비동기 Ray Actor라는 새로운 구조로 전환함으로써 Disk I/O 병목을 근본적으로 제거하고 Cloud 환경에서의 확장성까지 확보할 수 있었다. 또한 추론 Processor에 동시 2요청을 보내 CPU-bound와 GPU-bound 작업을 파이프라이닝하는 설계를 통해, 하드웨어 자원의 유휴 시간을 최소화하는 것이 성능 최적화의 핵심이라는 것을 체감했다.