GPU 인퍼런스(GPU Inference)가 전체 비용의 80%를 차지하며, OpenCLIP ViT-H/14 모델 사용 시 g6.xlarge 인스턴스 기준 월 588달러 소요
CPU 인퍼런스(CPU Inference)는 0.2 img/s로 실용성이 낮으며, 스팟 인스턴스(Spot Instances)를 활용하면 GPU 비용을 60-70% 절감 가능
벡터 데이터베이스(Vector Database), 이미지 저장, 백엔드(Backend) 인프라는 상대적으로 저렴하며, 트래픽 규모에 따라 인스턴스 및 CDN 비용 증가
유지보수(Maintenance)가 핵심 과제로, 모델 업데이트, 트래픽 급증, 장애 발생 시 지속적인 관리 필요
본 분석에 따르면, GPU 인퍼런스(GPU Inference)가 이미지 검색 시스템 운영 비용의 80%를 차지하며, OpenCLIP ViT-H/14 모델을 g6.xlarge 인스턴스에서 실행하는 데 월 588달러가 소요된다. CPU 인퍼런스(CPU Inference)는 성능 저하로 인해 실용성이 낮으며, 스팟 인스턴스(Spot Instances)를 활용하면 비용을 60-70% 절감할 수 있다. 하지만, 스팟 인스턴스는 AWS의 예고 없는 종료 가능성으로 인해 라이브 검색 환경에서는 위험 부담이 존재한다.
100만 개의 벡터를 저장하는 데 필요한 벡터 데이터베이스(Vector Database) 비용은 Pinecone, Qdrant, pgvector on RDS를 기준으로 월 50~270달러 수준이다. 이미지 저장 및 전송을 위한 S3와 CloudFront는 각각 월 11.50달러, 0~15달러로, 전체 비용에서 차지하는 비중은 작다. 하지만, 트래픽이 증가함에 따라 이 증가할 수 있으며, 1000만 개 이상의 이미지로 확장 시 데이터베이스 쿼리 지연 시간이 문제가 될 수 있다.
백엔드는 GPU와 벡터 데이터베이스 간의 요청을 라우팅하며, Rust를 사용하여 메모리 효율성과 동시성을 확보할 수 있다. 자동 스케일링(Auto Scaling)을 통해 트래픽 급증에 대응하며, 2개의 t3.small 인스턴스(월 57달러)로 시작하여 트래픽 규모에 따라 인스턴스 수를 늘릴 수 있다. 엔터프라이즈 트래픽(Enterprise Traffic)의 경우, 6개 이상의 인스턴스가 필요할 수 있으며, 이는 백엔드 비용 증가로 이어진다.
100만 개의 이미지를 임베딩하는 데 약 3.7시간이 소요되며, I/O 병목 현상을 해결하기 위해 비동기 배치 처리(Async Batching)를 활용한다. Python과 asyncio, aiohttp를 사용하여 이미지 다운로드를 배치 처리하고, GPU를 효율적으로 활용한다. 비동기 처리 없이 12시간 이상 소요될 수 있는 작업을 단축하며, 초기 데이터 로딩을 위한 별도의 인스턴스 사용을 권장한다. 구체적인 구현 코드는 본문에 포함되지 않았다.
이미지 검색 시스템 구축 자체는 비교적 간단하지만, 유지보수(Maintenance)가 핵심적인 과제로 부각된다. 모델 업데이트, 트래픽 급증, 장애 발생 시 지속적인 관리가 필요하며, 이는 개발자의 시간 투자를 요구한다. 100만 개 이상의 이미지로 확장 시 GPU 비용 증가, 벡터 데이터베이스 성능 저하, 백엔드 용량 확충 등 추가적인 비용 발생이 예상된다. AI 모델 업데이트(Model Updates)는 전체 시스템의 재구성을 필요로 할 수 있다.