배경
#7에서 /start는 업로드 검증만 수행하고 실제 AI 분석 파이프라인 시작은 후속 작업으로 분리했습니다. 이번 이슈는 그 후속 작업으로, 업로드된 사진들을 Vertex AI로 분석해 테마를 만들고 분류하는 파이프라인을 /start 호출 시점에 실제로 트리거합니다.
제안 내용
/start가 업로드 검증을 마치면 AnalysisStartRequestedEvent를 발행하고, AnalysisPipelineEventListener가 이를 동기(같은 스레드)로 구독해 파이프라인을 시작합니다.
- Vertex AI API 호출 1회로 테마 생성, 사진 분류, 테마별 짧은 리캡 문구(
RecapContent - badge+text)를 함께 받아옵니다.
- 테마별 대표 사진 1장을 선정해 배경 제거 스티커를 생성하고 GCS에 업로드합니다. (스티커 생성 실패는 partial-failure-tolerant하게 처리)
- 이번 스코프는 검증 목적의 최소 구현으로, 분석 결과는 DB에 영속화하지 않고 로그로만 확인합니다.
- 실제 GCS에 올린 테스트 사진 27장으로 Vertex AI를 직접 호출해 6개 테마 분류 및 스티커 생성까지 end-to-end로 검증을 목표로합니다.
대안 및 설계 근거
사진을 Vertex AI에 전달하는 방식으로 두 가지를 검토했습니다.
- 방법 1 (서버 경유 바이트 전송): GCS → 서버가 다운로드 → 메모리 적재 → Gemini API로 재업로드. 사진 100장(약 500MB)을 요청마다 서버가 중계해야 해서 네트워크 대역폭/메모리(OOM) 병목과 대용량 HTTP payload 문제가 발생합니다.
- 방법 2 (Vertex AI + GCS URI 직접 참조, 채택): 서버는
gs://... 경로 문자열만 Vertex AI에 전달(Part.fromUri)하고, 실제 대용량 전송은 구글 내부망에서 처리됩니다. 서버의 네트워크 부하와 이그레스 비용이 거의 0에 수렴하고, 요청 페이로드도 가벼워 100장 규모에서도 안정적입니다.
이런 이유로 방법 2를 채택했습니다.
배경
#7에서
/start는 업로드 검증만 수행하고 실제 AI 분석 파이프라인 시작은 후속 작업으로 분리했습니다. 이번 이슈는 그 후속 작업으로, 업로드된 사진들을 Vertex AI로 분석해 테마를 만들고 분류하는 파이프라인을/start호출 시점에 실제로 트리거합니다.제안 내용
/start가 업로드 검증을 마치면AnalysisStartRequestedEvent를 발행하고,AnalysisPipelineEventListener가 이를 동기(같은 스레드)로 구독해 파이프라인을 시작합니다.RecapContent- badge+text)를 함께 받아옵니다.대안 및 설계 근거
사진을 Vertex AI에 전달하는 방식으로 두 가지를 검토했습니다.
gs://...경로 문자열만 Vertex AI에 전달(Part.fromUri)하고, 실제 대용량 전송은 구글 내부망에서 처리됩니다. 서버의 네트워크 부하와 이그레스 비용이 거의 0에 수렴하고, 요청 페이로드도 가벼워 100장 규모에서도 안정적입니다.이런 이유로 방법 2를 채택했습니다.