1. AI 모델 서빙 아키텍처의 종합 평가

a. 왜 지금 아키텍처가 타당하고 적절한가?

• 현재 우리 서비스는 사용자가 업로드한 다수의 이미지를 AI로 분석, 분류, 정리하는 기능이 핵심이며,

  그 과정은 멀티모델(CLIP, arcFace, Stable Diffusion 등)을 기반으로 하면서도 각 연산 단위가 서로 강하게 결합되어 있지 않도록 분리되어야 함

• 우리는 FastAPI 기반의 서버를 중심으로 내부 모듈들을 기능별로 모듈화하면서도,

  확장 가능한 구조를 고려해 메시지큐, 캐싱, 비동기 처리 등 마이크로서비스 설계의 기초를 마련

• 특히 초기 사용자가 확보되지 않았을 때는 MVP 서비스 운영에 적합한 효율성 중심의 단일 서비스 기반 구조(v1/v2)이며,

  v3 이후에는 모델 서빙 분리, 리소스 병렬 처리, GPU 서버와의 분산 확장까지 자연스럽게 연계될 수 있게 설계됨

• 복잡한 도구 추상화, 체인 구조, RAG, MCP 등은 현재 서비스 흐름과 요구사항에 비해 과설계라는 판단 하에 과감히 제외

  이 결정은 단순한 생략이 아닌, “지금은 단순하게, 나중엔 확장 가능하게”를 위한 전략적 판단

b. 현재 아키텍처의 강점

• 기능별로 분리된 서비스 구조 (embedding, duplicate, category 등)는 각 모듈의 독립성과 테스트 용이성을 확보

• Redis를 기반으로 캐시 + 메시지큐를 통합 운영하면서도, 다중 인스턴스에서도 일관된 상태 공유가 가능하도록 구성

• NAT, Load Balancer, VPC 외부 통신 구조까지 실제 운영 환경에서 문제가 생기지 않도록 미리 구조적 병목을 검토하고 대비

• 모델 서빙 방식은 CLIP, arcFace, Stable Diffusion의 용도와 특성에 따라 분리된 구조로,

  CPU/GPU 리소스 최적화와 모델 별 경량화 전략(스레드 제한, LoRA 등)까지 반영

• 전체 흐름이 단순하면서도, 확장을 고려한 설계로 구성되어 있어 이후 마이크로서비스로 전환하거나, 에이전트 기반의 LLM 흐름을 붙이기도 용이

c. 보완해야 할 여지

• 현재는 모든 처리를 FastAPI 중심의 하나의 서버에서 수행 중이며, 모델 서빙, 이미지 처리 로직이 아직 완전히 분리되어 있지 않음

  → 향후에는 이러한 컴포넌트들을 서비스 단위로 독립 배포·스케일링할 수 있는 구조로 전환할 필요가 있음

• GPU 서버에 대한 부하 제어, 장애 감지, 작업 재시도 등 운영 안정성 측면의 자동화가 부족함

  → 작업 상태 추적, 실패한 작업의 자동 복구 등을 고려한 처리 흐름의 통제 강화가 요구됨

• 모니터링은 Prometheus/Grafana로 구성되어 있으나, 개별 작업자(워커) 수준의 상태 추적 및 자가 회복 로직 구성은 미비함

  → 작업 단위로 상태를 추적하고, 문제가 생겼을 때 자동 복구되도록 시스템 수준의 자율성을 높이는 방향으로 개선 가능