1. 소비자 업로드 → 비동기 생성 흐름
접수는 동기로 즉시 응답하고, 실제 분석·생성은 응답 이후 after()로 백그라운드에서 진행합니다.
flowchart TD U[사용자: 사진 업로드 + 스타일 선택] --> UP[generateDiary Server Action] UP --> ST[원본 사진 Storage 업로드] ST --> INS[diaries: status=pending 행 생성] INS --> RESP[즉시 응답: 접수 완료] RESP --> U2[사용자: 홈으로 이동
다른 화면 봐도 됨] INS -. after 백그라운드 .-> AN[1단계: 사진 분석] AN -- 안전하지 않음 --> REJ[status=rejected] AN -- 안전함 --> PR[프롬프트 조립
사진유형+스타일+공통] PR --> GEN[2단계: 이미지 생성] GEN -- 성공 --> DONE[결과 Storage 업로드
status=done] GEN -- 실패 --> FAIL[status=failed
error_code 기록] DONE --> HOME[홈 피드 / 스토리 뷰어] FAIL --> HOME REJ --> HOME
2. 관리자 4스타일 비교 흐름
스타일마다 따로 호출하면 4배 과금되는 문제를 해결하기 위해, 2×2 그리드 이미지 1장을 한 번에 요청합니다.
flowchart LR A[관리자: 사진 업로드] --> AN2[1단계 분석 1회 호출] AN2 --> FETCH[4개 스타일 활성 프롬프트 조회] FETCH --> ASM[2x2 그리드 프롬프트 조립
칸마다 다른 스타일 지시] ASM --> GEN2[이미지 생성 1회 호출] GEN2 --> SAVE[style_test_runs에 기록
성공/실패 관계없이] SAVE --> HIST[테스트 히스토리 화면]
3. Batch API 테스트 흐름
배치 처리는 즉시 끝나지 않을 수 있어, 자동 폴링 대신 관리자가 "상태 확인"을 눌러 직접 조회하는 방식으로 설계했습니다.
flowchart LR A2[관리자: 사진/유형/스타일 선택] --> SUB[batchGenerateContent 제출] SUB --> JOB[작업 이름 반환
BATCH_STATE_RUNNING] JOB -- 상태 확인 클릭 --> POLL[작업 상태 조회] POLL -- RUNNING --> JOB POLL -- SUCCEEDED --> IMG[결과 이미지 추출·표시]