1. 향후 개선 아이디어 및 확장 계획

a. 모델 서빙 구조의 기능/자원 분리

• 현재는 다양한 AI 모델이 FastAPI 서버 내부에 함께 포함되어 있고, 연산 리소스 요구(GPU/CPU)나 호출 빈도도 모델마다 다름
• 이후에는 모델을 기능 단위(예: 이미지 임베딩, 얼굴 클러스터링, 스타일 변환 등)로 완전히 분리하고, 독립된 서빙 인스턴스 혹은 API 서비스로 운용할 수 있도록 개선할 예정
• 이를 통해 모델별 리소스 효율을 높이고, 업데이트/배포 주기도 각자 다르게 관리할 수 있음

b. 작업 흐름 자동화 및 복구 기능 강화

• 현재는 Redis 메시지큐 기반의 작업 분산 구조를 갖췄지만, 실패 작업의 재시도, 상태 추적, 경량화된 상태 저장 등 작업 안정성을 위한 보완 로직이 부족
• 향후에는 각 작업 단위의 상태를 추적하고, 장애 발생 시 자동 재처리, 워커 감지 및 재시작이 가능한 구조로 발전시킬 예정

c. 기능별 컴포넌트의 독립 배포 및 확장 구조 정비

• 현재는 모든 주요 기능(embedding, duplicate, style_transform, score 등)이 한 FastAPI 앱에 포함되어 있음
• 향후에는 각 기능 단위를 별도의 서비스로 분리하여 배포하고, 트래픽 변동, 요청량에 따라 개별적으로 스케일링 가능한 구조로 개선할 예정
• 이렇게 하면 컴포넌트별 병목 대응, 운영 단위 최소화, 자동 확장 같은 이점 확보 가능

d. 모니터링 정밀도 향상 및 Alert 체계 강화

• 현재는 CPU/GPU 사용량, 큐 길이 등 주요 지표를 Prometheus + Grafana로 시각화하고 있으나, 서비스별 오류율, 평균 처리 시간, 워커 상태 등의 세분화된 지표는 아직 추적되지 않음
• 향후에는 작업 실패 알림, 큐 적체 감지, 리소스 임계치 경고 등 운영 중 알림 체계를 강화하여 사고 발생 시 즉각 대응 가능한 운영 체계로 발전시킬 예정

e. 쿠버네티스 기반 배포 구조 도입 검토

• 다중 인스턴스 환경에서의 확장성과 자원 효율성을 높이기 위해, 각 기능 모듈을 컨테이너 단위로 구성하여, 클러스터 환경 내에서 배포·관리할 수 있는 체계 도입을 검토 중
• 이를 통해 CPU/GPU 리소스를 동적으로 할당하고, 서비스별 상태 관리, 자동 재시작, 수평 확장 등 현대적인 운영 환경을 구축할 수 있음

f. 사용자 지향 기능 및 프론트 연동 확장

• 현재는 백엔드 중심 구조지만, 향후에는 프론트엔드와의 연결성을 고려하여 실시간 처리 진행 상황 표시, 스타일 변환 대기열 상태 확인 등 사용자 중심 인터랙션 기능 강화도 고려 중
• 이미지 선택, 앨범 생성, 공유 기능 등 사용자 경험 확장을 위한 API 및 시스템 설계도 병행할 예정