PinLog AI 컬렉션 표지 기능 협의 요청

[ghkim1632]

공통 확정사항

• 컬렉션은 표지 생성을 기다리지 않고 즉시 생성한다.
• 표지는 비동기로 생성한다.
• AI 이미지는 글자 없는 정사각형 삽화다.
• 제목과 공개 키워드 최대 4개는 프런트에서 표시한다.
• Context 원문과 PRIVATE_ONLY, BLOCKED 키워드는 사용하지 않는다.
• 모든 키워드 분석 완료를 기다리되 최대 10분까지만 기다린다.
• 이미지 생성 중 컬렉션이 변경되면 기존 작업을 무효화하고 최신 내용으로 다시 시작한다.
• 이전 버전의 결과가 늦게 도착하면 저장하지 않는다.
• 표지 생성이 완료된 이후 컬렉션이 변경되어도 재생성하지 않는다.
• 네트워크·429·5xx 오류는 최대 2회 재시도한다.
• 안전 정책 거절은 재시도하지 않고 즉시 실패 처리한다.
• 생성 중에는 별도 상태 문구 없이 공통 임시 표지를 표시한다.
• 생성 성공 시 AI 표지로 교체한다.
• 최종 실패 시 저장된 기본 일러스트 중 공개 키워드 벡터와 가장 유사한 이미지를 적용한다.
• 공개 키워드가 없으면 공통 기본 표지를 유지한다.
• 피드와 컬렉션 상세에만 표지를 표시하며 책장 책등은 기존 UI를 유지한다.
• 화면에 생성 중인 표지가 있으면 30초마다 상태를 갱신한다.
• 화풍은 자유롭게 하되 공통 프레임, 약한 밝기·채도 보정, 종이 질감을 적용한다.
• 작은 인물·뒷모습·실루엣은 허용하지만 얼굴 중심 이미지는 제외한다.
• 생성 성공 후 사용자나 운영자가 재생성·교체하는 기능은 제공하지 않는다.

---

Spring 백엔드 담당자에게 확인할 내용

1. 작업 생성과 상태 관리

• 컬렉션 생성 트랜잭션에서 표지 작업 상태를 함께 PENDING으로 생성할 수 있는가?
• 표지 상태를 어느 스키마와 테이블에서 관리하는 것이 적절한가?
• 다음 상태 모델에 문제가 없는가?
  • PENDING
  • PROCESSING
  • COMPLETED
  • FAILED
  • CANCELLED
• generation_version 또는 input_hash를 사용해 이전 결과를 폐기할 수 있는가?
• 컬렉션 제목 수정, Record 추가·제거 시 아직 완료되지 않은 표지 버전을 자동으로 무효화할 수 있는가?
• 이미 COMPLETED된 표지는 컬렉션 변경 이벤트에서 제외할 수 있는가?

2. 키워드 대기와 작업 실행

• 컬렉션에 연결된 활성 Context의 keyword_status를 한 번의 집계 쿼리로 확인할 수 있는가?
• 모든 Context가 종료 상태가 되거나 10분이 경과했을 때 표지 요청을 시작할 수 있는가?
• 마지막 컬렉션 변경 시점부터 10분 제한을 다시 계산할 수 있는가?
• 연속 편집을 묶기 위한 대기 시간을 둘 필요가 있는가?
  • 후보: 즉시, 마지막 변경 후 30초, 마지막 변경 후 1분
• 기존 AI 재스캔 스케줄러를 확장할지, 표지 전용 스케줄러를 둘지 의견이 필요한가?

3. AI 서버 요청 데이터

• Spring이 다음 데이터를 조립해 AI 서버에 전달하는 구조가 적절한가?
  • collectionId
  • generationVersion
  • 컬렉션 제목
  • 대표 장소명 목록
  • PUBLIC 키워드 ID, 표시명, confidence
  • 키워드 분석 종료 여부
• FastAPI의 core.* 접근 금지 원칙을 유지하기 위해 모든 Core 데이터는 Spring이 전달하는 것으로 합의 가능한가?
• Context 원문이 요청 DTO나 로그에 포함되지 않음을 어떻게 테스트할 것인가?

4. 프런트 API 계약

• 컬렉션 목록·상세·피드 응답에 다음 필드를 추가할 수 있는가?
  • coverStatus
  • coverUrl
  • fallbackCoverKey
• 성공한 표지를 제공할 고정 URL을 만들 수 있는가?
  • GET /api/core/v1/collections/{collectionId}/cover
• PENDING과 FAILED 상태에서 프런트가 기본 표지를 선택할 수 있도록 응답을 구성할 수 있는가?
• 이미지 응답에 ETag와 Cache-Control을 적용할 수 있는가?
• 삭제되거나 비공개 대상이 된 컬렉션의 표지 접근을 차단할 수 있는가?

5. DB와 마이그레이션

• 표지 상태와 결과가 AI 파생 데이터라면 ai 스키마에 두는 것에 동의하는가?
• AI 테이블을 추가할 경우 Flyway 마이그레이션과 AI 테스트 스키마 스냅샷을 어떻게 함께 갱신할 것인가?
• core.collection과 AI 표지 테이블 사이에 FK를 두지 않는 기존 AI 스키마 원칙을 유지할 것인가?

---

AI 서버 담당자에게 확인할 내용

1. GMS 이미지 생성 지원

• 현재 GMS에서 이미지 생성 모델을 지원하는가?
• 사용할 수 있는 모델명과 API 형식은 무엇인가?
• 정사각형 출력이 직접 지원되는가?
• 응답은 URL, base64, 바이너리 중 어떤 형식인가?
• 호출당 비용 또는 크레딧 차감량은 얼마인가?
• 분당·일일 호출 한도는 얼마인가?
• 평균 및 상위 95% 생성 시간을 실측할 수 있는가?
• 안전 정책 거절과 기술 오류를 응답에서 구분할 수 있는가?

2. 표지 프롬프트 입력

• 프런트에 표시하는 PUBLIC 키워드는 최대 4개로 합의됐다.
• 이미지 프롬프트에도 동일한 4개를 사용할 것인가?
• 다른 수 또는 다른 선정 기준을 사용할 경우 이유와 기준은 무엇인가?
• 키워드 선정 시 frequency와 confidence를 어떻게 반영할 것인가?
• 장소명은 최대 몇 개까지 전달하는 것이 적절한가?
• 장소가 100개인 컬렉션에서 대표 장소를 어떤 기준으로 선정할 것인가?
• 공개 키워드가 하나뿐이면 해당 키워드만 사용하는 것으로 충분한가?
• 공개 키워드가 없을 때 제목과 장소명만으로 생성할 것인가?

3. 공통 이미지 생성 규칙

• 다음 공통 프롬프트 규칙을 적용할 수 있는가?
  • 정사각형 편집 일러스트
  • 글자·문자·로고·워터마크 금지
  • 하나의 명확한 중심 대상
  • 가장자리 여유 공간
  • 과도한 채도와 극단적인 명암 제한
  • 얼굴 중심 인물 금지
  • 작은 인물, 뒷모습, 실루엣 허용
  • 화풍과 테마는 자유
• 프롬프트에 포함된 사용자 제목을 명령이 아닌 데이터로 안전하게 분리할 수 있는가?
• 제목이나 장소명이 프롬프트 지시문으로 해석되지 않도록 방어할 수 있는가?

4. 상태 전이와 경합 처리

• 요청의 generationVersion이 현재 버전과 일치할 때만 처리·저장할 수 있는가?
• 처리 중 컬렉션이 변경되면 실행 중인 외부 요청을 취소할 수 있는가?
• 실제 취소가 불가능하면 늦게 도착한 결과를 저장하지 않고 폐기할 수 있는가?
• 기술 오류는 최초 호출 이후 최대 2회 재시도하는 것으로 구현 가능한가?
• 안전 정책 거절은 재시도 없이 FAILED로 처리할 수 있는가?
• 재시도 시 최초에 고정한 동일 입력과 동일 버전을 사용할 수 있는가?

5. 이미지 후처리

• 생성 결과를 다음 규격으로 표준화할 수 있는가?
  • 512×512
  • sRGB
  • WebP
  • 약한 밝기·채도 정규화
  • 공통 종이 질감 적용 가능 여부
• 최대 파일 크기를 어느 정도로 제한하는 것이 적절한가?
  • 제안: 300KB
• 잘못된 MIME 타입, 손상된 파일, 비정상 크기를 검증할 수 있는가?

6. 실패용 기본 일러스트 유사도

• context_embedding이 아니라 PUBLIC keyword_preset.embedding만 사용한다는 데 동의하는가?
• 공개 키워드가 여러 개면 confidence 가중 평균 벡터를 만들 수 있는가?
• 공개 키워드가 한 개면 해당 키워드 벡터를 그대로 사용할 수 있는가?
• 기본 일러스트 설명도 같은 embedding profile로 사전 임베딩할 수 있는가?
• 기본 일러스트가 적을 경우 정확한 cosine 검색만으로 충분한가?
• 최소 유사도 기준은 어떤 평가 데이터로 정할 것인가?
• 기준 미달 시 공통 기본 표지를 반환할 수 있는가?
• 동점일 때 collectionId 기반으로 결과를 고정할 수 있는가?

---

프런트엔드 담당자에게 확인할 내용

1. 표지 카드 구성

• AI 이미지 영역을 1:1 정사각형으로 표시할 수 있는가?
• 다음 카드 구성으로 피드와 상세 화면을 통일할 수 있는가?
  • 정사각형 이미지
  • 컬렉션 제목
  • PUBLIC 키워드 최대 4개
  • 공통 미색 프레임
  • 얇은 테두리
  • 종이 질감
• AI 이미지의 그림체가 달라도 같은 시리즈처럼 보이도록 공통 프레임을 적용할 수 있는가?
• 책장 화면의 책등은 기존 UI를 유지하는 데 문제가 없는가?

2. 상태별 표시

• PENDING: 공통 임시 표지
• COMPLETED: AI 생성 표지
• FAILED이며 fallbackCoverKey 존재: 유사도 기반 기본 일러스트
• FAILED이며 키워드 없음: 공통 기본 표지

위 상태별 표시를 별도 문구 없이 처리할 수 있는가?

3. 상태 갱신

• 현재 화면에 PENDING 항목이 있을 때만 30초 폴링을 실행할 수 있는가?
• 카드별 요청이 아니라 목록 API 하나를 다시 조회할 수 있는가?
• 모든 항목이 종료 상태가 되면 폴링을 중단할 수 있는가?
• 완료된 이미지로 교체될 때 레이아웃 이동 없이 자연스럽게 전환할 수 있는가?

4. 기본 일러스트 자산

• 기본 일러스트를 프런트 정적 자산으로 관리하는 것에 동의하는가?
• 필요한 기본 일러스트 수는 몇 장인가?
• 각 자산에 변경되지 않는 coverKey를 부여할 수 있는가?
• 이미지 파일명과 coverKey 매핑을 코드에서 안전하게 관리할 수 있는가?
• 존재하지 않는 coverKey를 받으면 공통 기본 표지로 대체할 수 있는가?
• 기본 일러스트 설명과 테마 정보를 AI 담당자에게 전달할 수 있는가?

5. 접근성과 실패 대응

• 이미지 대체 텍스트는 컬렉션 제목 기반으로 제공할 수 있는가?
• 이미지 다운로드 실패 시 공통 기본 표지로 대체할 수 있는가?
• 모바일·태블릿·PC에서 정사각형 비율과 제목·키워드 영역을 유지할 수 있는가?

---

인프라 담당자에게 확인할 내용

1. GMS 연결

• 현재 GMS 인증 정보로 이미지 생성 API도 호출할 수 있는가?
• 별도 API 키나 Secret이 필요한가?
• AI Pod에서 이미지 생성 엔드포인트로 나가는 네트워크가 허용되는가?
• 이미지 생성 호출의 쿼터와 비용을 어디에서 관측할 수 있는가?
• GMS 이미지 모델 장애를 감지할 메트릭이나 알림을 구성할 수 있는가?

2. 저장 위치 검토

현재 S3나 외부 오브젝트 스토리지는 사용하지 않는다. 다음 선택지를 비교해 달라.

• PostgreSQL BYTEA
• 백엔드 PVC
• AI PVC
• 별도 파일 제공 서비스와 PVC

각 방식에 대해 다음을 확인해 달라.

• 현재 단일 노드·단일 디스크 구조에서 가장 안전한 방식
• 백엔드와 AI가 다른 네임스페이스에 있는 점
• AI 서버가 외부 Ingress를 사용하지 않는 점
• 백업과 복구 절차
• 롤링 배포 중 데이터 보존
• PVC 삭제 시 local-path-retain 복구 절차
• 서버 재이미징 시 외부 백업 가능 여부

3. PostgreSQL 저장안을 사용할 경우

• 현재 PostgreSQL 20Gi PVC에서 표지 저장 공간을 감당할 수 있는가?
• 백업 PVC 10Gi와 7일 보존 정책에 영향이 있는가?
• pg_dump에 표지 바이너리가 포함됐을 때 백업 시간과 크기가 허용 범위인가?
• 주 1회 서버 외부 복사 대상에 표지 데이터도 포함되는가?
• 이미지당 300KB 제한과 예상 컬렉션 수를 기준으로 용량을 산정할 수 있는가?
• DB 용량 임계치 알림을 추가해야 하는가?

4. AI 서버 자원

• PNG를 WebP로 변환할 CPU·메모리 여유가 있는가?
• 현재 AI Pod의 384Mi request / 768Mi limit에서 이미지 후처리가 가능한가?
• 임시 파일이 필요하면 writableTmp를 활성화해야 하는가?
• 파일 전체를 메모리에 올리는 방식이 안전한가?
• 동시 이미지 생성 개수를 제한해야 하는가?

5. 서비스 간 통신

• 현재 운영 백엔드가 dev AI 서비스를 호출하는 구조를 표지 기능에도 그대로 사용할 것인가?
• 표지 기능의 운영 배포 전에 AI 서비스의 prod 승격이 필요한가?
• Spring → AI 내부 API에 필요한 NetworkPolicy가 이미 충분한가?
• 이미지 결과를 AI에서 Spring으로 전송하거나 DB에 저장할 때 요청 크기 제한 문제가 없는가?

6. 관측과 운영

다음 지표를 수집할 수 있는가?

• PENDING, PROCESSING, COMPLETED, FAILED 작업 수
• 이미지 생성 성공률
• 안전 정책 거절 수
• 재시도 횟수
• 평균 및 상위 95% 생성 시간
• 생성 이미지 평균·최대 크기
• 오래된 PROCESSING 작업 수
• 폐기된 이전 버전 결과 수
• 표지 데이터의 총 저장 용량

[colosair]

AI 파트입니다. 답변 순서를 먼저 제안드립니다.

40여 항목에 지금 답하면 그 답의 대부분이 추측이 됩니다. 한 가지가 나머지 전부의 전제라 그것부터 재고 나머지를 답하는 편이 빠릅니다.

전제 하나 — GMS 가 이미지를 생성하는가

확인된 것    GMS 는 이미지를 읽는다 (vision)
            S15P11A705-227 에서 1x1 PNG 를 세 벤더 경로에 실어 보내 전부 200 · 내용 응답 확인
확인 안 된 것  GMS 가 이미지를 만드는가 (generation)

둘은 다른 기능입니다. -227 이 답한 것은 입력이고, 표지 기능이 필요한 것은 출력입니다.

현재 코드가 부르는 GMS 엔드포인트는 /v1/chat/completions 와 /v1/messages 둘뿐입니다. 이미지 생성 경로는 코드에도 설정에도 없습니다 — 지원 여부를 실측 없이 말할 수 없습니다.

여기서 안 되면 설계 대부분이 무의미해집니다. 외부 API 를 새로 뚫는 것은 비용·보안·게이트웨이 정책이 걸린 다른 논의입니다.

그래서 먼저 잴 것 — 「AI 서버 1」의 8개 항목

지원 여부 · 모델명 · API 형식
정사각형 직접 지원 여부
응답 형식 (URL · base64 · 바이너리)
호출당 비용 · 크레딧
분당 · 일일 한도
p50 / p95 생성 시간
안전 정책 거절과 기술 오류의 구분 가능 여부

이 측정은 S15P11A705-253(이미지 토큰 소비 실측)과 같은 하네스를 씁니다. 묶으면 호출 몇 번으로 둘 다 답합니다.

---

지금 답할 수 있는 것 — 이미 실측된 것들

「PUBLIC 키워드 최대 4개」 — 오늘 확정됐습니다

S15P11A705-278(back#173)이 표시용 정렬 규칙을 정하고 있습니다.

빈도 내림차순 → 동점 시 축(category) 라운드로빈 → preset id
상한 4

「이미지 프롬프트에도 같은 4개를 쓸 것인가」는 프론트 표시와 목적이 다릅니다. 표시는 「무엇이 대표적인가」이고 프롬프트는 「무엇이 그림이 되는가」입니다. 다만 다른 기준을 쓸 근거가 아직 없으므로 같은 4개로 시작하고, 생성 품질을 보고 갈릴 때 나누는 편이 낫다고 봅니다.

「frequency 와 confidence 를 어떻게 반영하는가」

back#173 의 정렬에는 confidence 가 안 들어갑니다. 빈도만 씁니다.

이유 — 시연 DB 실측에서 Collection 의 63% 가 모든 Keyword 빈도 1 이라 빈도가 못 가르고, confidence 는 판정 LLM 값이라 문턱을 정한 적이 없습니다(T47 미결). 근거 없는 가중치를 넣으면 그 자체가 새 미결이 됩니다.

표지 프롬프트에서 confidence 를 쓰려면 문턱부터 정해야 합니다.

「폴백용 유사도에 keyword_preset.embedding 을 쓴다」 — 가능합니다

V100__ai_tables.sql:14   embedding VECTOR(1536) NOT NULL

컬럼이 있고 부트스트랩에서 채워집니다. context_embedding 이 아니라 keyword_preset.embedding 만 쓰는 데 동의합니다 — Context 본문이 표지 생성 경로에 들어가지 않는 것이 낫습니다.

다만 기본 일러스트 설명을 같은 profile 로 사전 임베딩해야 비교가 성립합니다. profile 이 갈리면 코사인이 무의미해집니다(embedding profile parity CI 가 그것을 지키는 이유입니다).

「분당·일일 한도」 — 기존 실측값을 그대로 쓰지 마십시오

T27   GMS 판정 쿼터는 상수가 아니다
      07-29 분당 2건  →  07-30 분당 30건 이상
      공용 게이트웨이라 시점 · 프로바이더 경로별로 다르다

판정(텍스트) 쿼터이고 이미지 생성은 별도 측정이 필요합니다. 그리고 그때 잰 값도 다음 주에 다를 수 있습니다 — 한도를 설계 상수로 박으면 안 됩니다.

---

설계에 대해 짚어 둘 것 하나

확정사항에 이런 항목이 있습니다.

생성 성공 후 사용자나 운영자가 재생성 · 교체하는 기능은 제공하지 않는다
안전 정책 거절은 재시도하지 않고 즉시 실패 처리한다
최종 실패 시 기본 일러스트 폴백

즉 한 번 FAILED 가 되면 그 컬렉션은 영구히 폴백 이미지입니다.

같은 구조가 이미 있고, 그것을 되살리는 경로가 어디에도 없다는 것을 오늘 확인했습니다.

ai.context_ai_state    PENDING · PROCESSING · COMPLETED · FAILED · CANCELLED
FAILED -> PENDING      back · ai · infra 어디에도 코드가 없다
공용 계약 05 §7.3       "Spring 이 PENDING 으로 되돌린다" 를 규정하는데 구현이 없다

표지 상태 모델이 같은 형태라 같은 막다른 길이 하나 더 생깁니다. 게다가 폴백조차 조건부입니다 — 공개 키워드가 없으면 공통 기본 표지인데, 키워드는 context_keyword 에서 오고 그것이 FAILED 면 키워드가 없습니다. 두 실패가 겹치면 근거 없는 기본 표지로 떨어집니다.

설계 단계에서 회수 경로를 함께 정하시길 제안드립니다. 나중에 붙이는 것보다 쌉니다.

---

정리

1  GMS 이미지 생성 지원 여부를 먼저 잰다 (-253 과 묶어서)
2  그 결과를 들고 나머지 항목에 답한다
3  상태 모델을 정할 때 FAILED 회수 경로를 함께 정한다

측정을 마치는 대로 「AI 서버 1」 전체와 나머지 절에 답변 올리겠습니다.

S15P11A705-253 과 묶어 진행하며, 백엔드·프론트 질문 중 AI 파트 답이 선행인 항목이 있으면 알려 주십시오 — 그것부터 답하겠습니다.

[cherry-go-round]

Spring 백엔드 쪽 §1~5에 답합니다. 바로 답할 수 있는 것과, 착수 전에 정해야 하는 것을 나눠 적습니다.

먼저 정해야 하는 것 셋

① 스키마 소유와 Flyway 구간 — P 절차 대상입니다

§1이 *"컬렉션 생성 트랜잭션에서 표지 작업 상태를 함께 PENDING으로 생성"*을 묻고 §5가 *"ai 스키마에 두는 것에 동의하는가"*를 묻는데, 이 둘을 동시에 만족시키면 우리 규약을 깹니다.

백엔드 하네스가 이렇게 정하고 있습니다.

Backend Flyway migrations use V2–V99 only; V100–V199 belongs to the AI part. … do not depend on objects from another part's range — apply order differs by environment.

ai 스키마 테이블은 V100+ 구간(AI 소유)입니다. 그런데 §1대로면 Spring이 컬렉션 생성 트랜잭션에서 그 테이블에 INSERT하게 되고, 이는 백엔드가 AI 구간 객체에 의존하는 형태입니다. 환경별로 적용 순서가 달라 기동이 깨질 수 있는 바로 그 경우입니다.

선택지가 몇 개 보입니다.

• 상태는 core(백엔드 소유, V2~V99)에 두고 AI는 결과만 쓴다 → 이번엔 AI가 core 객체에 의존
• 상태와 결과를 분리해 각자 자기 구간에 둔다 → 테이블 둘, 조회 시 조인 또는 두 번 읽기
• Spring이 INSERT하지 않고 이벤트만 발행하고 AI가 자기 테이블에 PENDING을 만든다 → 기존 ContextAiRequested 선례와 같은 형태

어느 쪽이든 마이그레이션 번호 구간과 스키마 소유에 관한 결정이고, 백엔드 문서 규약이 그 경우를 docs/ai/proposals/의 P 번호 절차로 지정하고 있습니다. BD로 우리가 단독 결정할 사안이 아닙니다. P 제안을 먼저 올려 주시면 그 위에서 구현 논의를 하겠습니다.

② 표지 이미지를 둘 곳이 없습니다

§4가 coverUrl과 GET /api/core/v1/collections/{id}/cover를 요청하는데, 바이트를 어디에 저장하는지가 명세에 없습니다.

확인해 보니 앱 설정과 인프라 저장소 양쪽에 오브젝트 스토리지가 없습니다. PVC는 PostgreSQL과 모니터링 스택에만 있습니다. 즉 지금 구성으로는 512×512 WebP를 둘 자리가 없습니다.

정해야 할 것 — DB bytea인지, 새 PVC + 로컬 볼륨인지, 외부 오브젝트 스토리지 도입인지. 셋 다 인프라 요청이 선행되고 성격이 크게 다릅니다. ETag·Cache-Control은 어디에 두든 붙일 수 있지만, 저장소가 정해지지 않으면 §4 전체가 성립하지 않습니다.

③ 응답 필드 추가와 새 엔드포인트는 공용 계약 개정이 선행입니다

coverStatus·coverUrl·fallbackCoverKey를 컬렉션 목록·상세·피드 응답에 넣는 것, 그리고 GET .../cover 신설은 08_API_명세 소유입니다. 우리가 임의로 넣을 수 없습니다. docs PR이 먼저 필요합니다.

답할 수 있는 것

질문	답
컬렉션 생성 트랜잭션에서 PENDING 함께 생성	가능합니다 — 트랜잭션 안에서 상태를 쓰고 커밋 이후 발행하는 형태(outbox)를 이미 씁니다. 단 위 ①이 정해져야 합니다
상태 모델 PENDING/PROCESSING/COMPLETED/FAILED/CANCELLED	문제없습니다. ai.context_ai_state와 같은 계열이라 일관됩니다
활성 Context keyword_status 집계 쿼리	가능합니다. keyword_status는 S15P11A705-209로 이미 들어와 있습니다
마지막 변경 시점부터 10분 재계산	가능합니다. 다만 대기를 타이머가 아니라 DB 상태 + 주기 폴링으로 구현해야 재시작에 견딥니다
Spring이 Core 데이터를 조립해 전달 (FastAPI의 core.* 접근 금지 유지)	동의합니다. AiProcessClient가 이미 그 방식입니다
core.collection과 AI 테이블 간 FK 없음 원칙 유지	유지합니다. 파트 간 적용 순서가 다르다는 같은 이유입니다
삭제·비공개 컬렉션의 표지 접근 차단	가능합니다. 06 §7의 다단 삭제 상태 확인과 같은 규칙을 적용하면 됩니다

잔가지 넷

늦은 결과 차단 메커니즘이 이미 있습니다. 06 §7이 *"늦게 도착하는 AI 결과는 State가 차단합니다 … AI 워커는 대상 단계가 PROCESSING일 때만 결과를 저장"*이라고 정해 뒀습니다. 여기에 generation_version을 더하면 방어가 두 벌이 됩니다. 둘 다 두려면 어느 쪽이 권위인지 정해야 하고, 아니면 기존 State 방어를 그대로 쓰는 편이 단순합니다.

스케줄러를 추가할 때 함정이 있습니다. AiIntegrationConfig javadoc에 적혀 있는데, TaskScheduler 빈이 생기는 순간 @Scheduled 메서드가 조용히 로컬 단일 스레드 실행자로 떨어집니다. 전용 스케줄러를 권합니다 — 재스캔과 표지는 주기·실패 성격이 달라 한 스케줄러에 묶으면 한쪽 지연이 다른 쪽을 밀어냅니다. 다만 추가 시 그 함정을 확인해 주세요.

연속 편집 묶기는 10분 상한과 하나로 합치는 게 낫습니다. "마지막 변경 후 N초 대기"와 "최대 10분"을 별도 규칙으로 두면 상태 전이가 두 벌이 됩니다. "마지막 변경 후 N초가 지났고, 그 사이 모든 Context가 종료 상태이거나 첫 대기 시작으로부터 10분이 지났으면 시작한다" 한 문장으로 표현되는 쪽이 구현과 테스트가 단순합니다. 이미지 생성이 호출당 비용이라 N은 짧지 않은 게 좋겠습니다.

Context 원문 미노출 테스트 — 지금 로그 방어를 신뢰할 수 없습니다. §3이 *"Context 원문이 요청 DTO나 로그에 포함되지 않음을 어떻게 테스트할 것인가"*를 물었는데, BT-06에서 확인된 대로 Alloy 로그 마스킹이 캡처 그룹만 치환해 실제로 값을 가리지 못하는 상태입니다. 인프라 수정 전까지 "로그에 남아도 마스킹된다"는 가정을 쓸 수 없습니다.

그래서 테스트는 두 층으로 가야 합니다 — ① 요청 DTO 직렬화 결과에 원문이 없음을 단언, ② 대역(FastApiProcessStub 방식)으로 실제 전송 본문을 캡처해 확인. 로그는 코드 규율로만 지키고, BT-06 수정이 배포 전 선행 조건이라는 점은 이미 place-suggestion 요청에도 적혀 있습니다.

정리

①②③이 정해지기 전에는 백엔드가 착수할 수 있는 범위가 좁습니다. 반대로 ①만 P 절차로 정해지면 §1·§2·§5는 바로 진행 가능합니다 — 상태 관리와 대기·실행 로직은 저장소 결정과 독립적입니다.

②(이미지 저장소)를 가장 먼저 좁혀 주시면 좋겠습니다. 선택에 따라 인프라 요청 리드 타임이 붙고, §4의 응답 계약 모양도 거기서 결정됩니다(고정 URL을 우리가 서브하는지, 외부 URL을 그대로 내려주는지).

[ghkim1632]

답변 감사합니다. AI·백엔드 의견과 GMS 사용량을 검토해 기능 방향을 변경하려고 합니다.

GMS는 이미지 생성을 지원하지만 크레딧 사용량이 커서 기존 임베딩·키워드 판정 등 다른 AI 기능에 영향을 줄 가능성이 있습니다. 따라서 컬렉션마다 이미지를 생성하는 방식은 제외하고, 미리 준비한 기본 일러스트를 DB에 한 번만 등록한 뒤 PUBLIC 키워드 벡터 유사도로 하나를 선택하는 방식으로 진행하고자 합니다.

변경된 기능 방향

• 런타임 GMS 이미지 생성 호출 없음
• 기본 일러스트 여러 장을 사전에 등록
• 컬렉션의 대표 PUBLIC 키워드는 back#173의 규칙을 그대로 사용
  • 빈도 내림차순
  • 동점 시 category 라운드로빈
  • 이후 preset ID
  • 최대 4개
• confidence는 사용하지 않음
• context_embedding은 사용하지 않음
• PUBLIC keyword_preset.embedding만 사용
• 키워드 벡터와 기본 일러스트 벡터를 비교해 가장 유사한 이미지 선택
• 컬렉션에 한 번 표지가 배정되면 이후 제목·Record 구성이 바뀌어도 유지
• 키워드가 없거나 매칭 기준에 미달하면 공통 기본 표지 사용

이 방식에서는 이미지 생성용 PENDING → PROCESSING → COMPLETED → FAILED 상태 모델과 생성 재시도, 안전 정책 거절, 늦은 이미지 생성 결과 폐기 등이 필요하지 않습니다.

제안하는 파트별 책임

Spring 백엔드

• 컬렉션과 활성 Context의 키워드 준비 상태 확인
• 대표 PUBLIC 키워드 ID 최대 4개 집계
• AI 서버의 내부 표지 매칭 API 호출
• AI가 반환한 coverKey 검증 및 컬렉션 표지 배정 저장
• 컬렉션·피드·상세 API에 coverKey 또는 coverUrl 제공
• 이미지 바이너리 공개 응답과 캐시 처리
• 컬렉션 삭제 시 표지 배정 조회 제외

AI 서버

• PUBLIC keyword_preset.embedding 조회
• 최대 4개 키워드 벡터의 단순 평균 계산
• 기본 일러스트 벡터와 cosine similarity 계산
• 최소 유사도 기준 적용
• 가장 유사한 coverKey와 유사도 반환
• 동일 embedding profile 유지
• 외부 GMS 호출 없이 DB 벡터 연산만 수행

프런트엔드

• 반환된 coverKey 또는 coverUrl로 표지 표시
• 표지가 아직 배정되지 않았거나 키워드가 없으면 공통 기본 표지 표시
• 제목과 PUBLIC 키워드 최대 4개를 이미지 밖에서 렌더링
• 기본 일러스트 세트의 전체적인 프레임·여백·색감을 통일

인프라

• 기본 이미지 BYTEA 저장 시 DB·백업 용량 검토
• 이미지 응답 캐시 정책과 DB 용량 모니터링 검토
• AI 서버 내부 매칭 API의 기존 NetworkPolicy 사용 가능 여부 확인

제안 DB 분리안

스키마 소유권 충돌을 피하기 위해 각 파트가 자기 데이터를 소유하는 구조를 제안합니다.

core.cover_asset
- cover_key
- image_data BYTEA
- media_type
- image_hash
- is_active
- created_at

core.collection_cover
- collection_id
- cover_key
- assigned_at

ai.cover_asset_embedding
- cover_key
- embedding VECTOR(1536)
- embedding_profile
- is_active

• 실제 이미지와 공개 응답은 Spring 책임이므로 core에 둡니다.
• 표지 임베딩과 유사도 계산 데이터는 AI 책임이므로 ai에 둡니다.
• core와 ai 사이에는 FK를 두지 않습니다.
• 두 스키마의 연결 계약은 변경되지 않는 coverKey로만 유지합니다.
• Spring은 ai 테이블을 직접 읽거나 쓰지 않습니다.
• AI 서버는 core 테이블을 직접 읽거나 쓰지 않습니다.
• Spring이 키워드 ID를 내부 API로 전달하면 AI는 coverKey만 반환합니다.

기본 일러스트 벡터는 새로운 GMS 호출 없이 만들 수 있습니다. 각 일러스트에 사람이 PUBLIC preset 키워드 ID를 등록하고, 해당 keyword_preset.embedding의 평균을 일러스트 벡터로 저장하는 방식을 제안합니다.

예:

forest_walk
→ 산책, 조용한, 자연, 여유
→ 네 preset embedding의 평균

저장 용량 관점

이미지는 컬렉션마다 저장하지 않고 기본 일러스트 원본만 한 번 저장합니다.

예를 들어 512×512 WebP를 장당 최대 300KB로 제한하면:

기본 일러스트 20장 → 최대 약 6MB
기본 일러스트 30장 → 최대 약 9MB

컬렉션이 늘어나도 core.collection_cover의 작은 매핑 행만 증가하므로, 동적 생성 이미지를 컬렉션마다 저장하는 방식과는 DB 부담이 크게 다릅니다.

그래도 BYTEA 사용과 백업 영향은 인프라 검토를 선행하겠습니다.

API 계약 변경

이미지 생성 상태가 없어지므로 기존에 제안했던 다음 필드는 필요하지 않습니다.

• coverStatus
• fallbackCoverKey

공용 API에는 다음 중 하나만 있으면 됩니다.

coverKey

또는

coverUrl

이미지 제공 엔드포인트는 자산 단위 캐시가 가능하도록 다음 형태를 제안합니다.

GET /api/core/v1/covers/{coverKey}

동일한 일러스트를 여러 컬렉션이 공유하므로 컬렉션별 이미지 URL보다 브라우저 캐시 효율이 좋습니다.

처리 흐름

컬렉션 생성
→ Spring이 키워드 준비 상태 확인
→ 대표 PUBLIC 키워드 ID 최대 4개 결정
→ AI 내부 매칭 API 호출
→ AI가 coverKey와 similarity 반환
→ Spring이 core.collection_cover에 배정 저장
→ 프런트에 coverKey 또는 coverUrl 반환

키워드가 아직 처리 중이면 공통 기본 표지를 보여주고 Spring이 DB 상태 기반으로 다시 확인합니다. 최대 대기 시점에도 PUBLIC 키워드가 없으면 공통 기본 표지를 최종 배정합니다.

요청사항

1. 이 구조를 스키마 소유권 변경에 관한 P 제안으로 진행해야 하는지 확인 부탁드립니다.
2. Spring 담당자는 core.cover_asset과 core.collection_cover 소유 가능 여부를 검토해 주세요.
3. AI 담당자는 ai.cover_asset_embedding과 내부 매칭 API 소유 가능 여부를 검토해 주세요.
4. 인프라 담당자는 고정 이미지 최대 20~30장, 총 10MB 미만을 전제로 PostgreSQL BYTEA와 현재 백업 구조의 수용 가능 여부를 검토해 주세요.
5. 공용 문서 담당자는 컬렉션·피드 응답의 coverKey 또는 coverUrl과 이미지 조회 엔드포인트 개정을 검토해 주세요.

이 안은 Spring이 AI 스키마에 의존하거나 AI가 Core 스키마에 접근하지 않으면서, 기존 pgvector 자산을 재사용하고 GMS 크레딧 소비를 제거하는 것을 목표로 합니다.

[colosair]

AI 파트입니다. 변경안 중 키워드 상한 수치 하나만 짚습니다. 제 앞선 코멘트에 적은 「상한 4」도 함께 정정합니다.

항목	내용
지적	본문의 「최대 4개」가 현재 병합값과 다릅니다
사실	KEYWORD_LIMIT = 3 — back#173 · 병합 커밋 c451e4d1 · 2026-08-03 병합
경위	S15P11A705-278에서 정렬 규칙을 정하며 4 → 3으로 확정됐습니다
정렬	빈도 내림차순 → 축(category) 라운드로빈 → preset id 오름차순 (이 부분은 본문과 같습니다)
영향	일러스트 벡터를 사전 등록하는 설계라, 등록 기준 개수가 3인지 확인이 필요합니다

나머지 항목은 확인 후 별도로 답변드리겠습니다.

[colosair]

AI 파트입니다. 요청사항 3번 — ai.cover_asset_embedding 과 내부 매칭 API 소유 가능 여부에 답합니다.

결론부터 적습니다.

내부 매칭 API        소유 가능합니다. 기존 경계 안이라 새로 짤 것이 거의 없습니다
cover_asset_embedding  소유 자체는 가능하나 공용 계약 개정과 P 번호가 앞에 놓입니다
                     그리고 이 테이블이 없어도 같은 기능이 서는 안이 있습니다 (§4)
먼저 정해야 할 것     최소 유사도 기준값과 「평균」 집계 — 둘 다 AI 파트가 잴 일입니다 (§5)

---

1. 소유 가능 여부 — 자산 일치, DDL 실행 주체는 back

제안 스키마가 전제하는 것이 현행 자산과 맞는지부터 확인했습니다.

항목	현행	판정
차원	keyword_preset.embedding VECTOR(1536) — back/src/main/resources/db/migration/V100__ai_tables.sql:14	제안의 VECTOR(1536) 과 일치합니다
profile	embedding_profile VARCHAR(100) NOT NULL (V100:15). 현재 값은 openai-text-embedding-3-small-1536-cosine-v1 하나이고, 정본은 ai/app/core/config.py:102-104 이며 CI embedding-profile-parity 잡이 back 과 대조합니다	그대로 씁니다
구분 컬럼	이름이 scope 가 아니라 visibility 입니다 (V100:16). 값은 PUBLIC · PRIVATE_ONLY · BLOCKED 세 등급 (V100:19-20)	이름만 맞춰 주시면 됩니다
PUBLIC 실수	프리셋 27개 중 PUBLIC 25 · PRIVATE_ONLY 2 (ai/data/keyword_preset.yaml, 미지정은 PUBLIC 기본 — ai/app/bootstrap/load_presets.py:78)	매칭 후보 어휘가 25개입니다
profile NULL	DB 가 NOT NULL 입니다	profile 없는 벡터 행은 만들 수 없습니다

자산 쪽에는 막는 것이 없습니다.

DDL 실행 권한 부재

다만 「소유」가 「우리가 테이블을 만든다」는 뜻이라면 현행 구조와 다릅니다.

권한   infra/platform/postgres/ai-shared-database-bootstrap-configmap.yaml
      :44  GRANT USAGE ON SCHEMA ai
      :46  GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA ai
      :60  ai_schema_create_denied   ← CREATE 미부여를 부트스트랩 SQL 안에서 assert 합니다

도구   ai 레포에 마이그레이션 도구가 없습니다 (Alembic·Flyway 0건, app/ 에 DDL 0건)

계약   docs/static/05_AI_설계.md:880-881
      "ai 스키마를 포함한 DB Migration의 실행 주체는 back입니다"
      "ai 레포는 AI 스키마 요구사항과 Query를 구현하지만 Migration을 실행하지 않습니다"
      같은 규정이 ai/docs/spec/architecture.md:14 에도 있습니다

실제 이력도 그렇습니다 — V1·V100·V101·V102 를 통째로 만든 back 커밋 946df11 의 author 가 AI 파트입니다. 내용은 우리가 쓰고 실행은 back 이 합니다. 이 형태를 그대로 쓰면 됩니다.

6번째 테이블 — 계약 개정과 P 번호 선행

docs/static/05_AI_설계.md §12 는 ai 스키마 테이블을 5개만 열거합니다(§12.1~§12.5). ai/docs/proposals/README.md:36 의 P6 「AI 스키마 5테이블 확정」 이 Accepted 상태로 그것을 굳혀 두었습니다.

ai.cover_asset_embedding 은 6번째입니다. 요청사항 1번의 답으로 읽어 주십시오 — 네, P 절차 대상입니다. 05 §12 개정과 P 번호가 코드보다 앞에 놓입니다.

---

2. 계산 위치 — 메모리, DB 왕복 0회

제안서의 「외부 GMS 호출 없이 DB 벡터 연산만 수행」은 DB 연산조차 필요 없습니다.

기존 코드   ai/app/service/keyword_service.py:35-46  _topk() 가 numpy 로 cosine 을 잽니다
           27 x 1536 행렬 곱을 이미 요청마다 하고 있습니다. 표지 30벡터는 같은 규모입니다

캐시       preset 벡터는 기동 시 1회 적재해 프로세스 메모리에 상주합니다
           ai/app/cache/preset_cache.py · 계약은 ai/docs/spec/architecture.md:161-173

선례       ai/docs/spec/keyword-preset.md:61-62
           "Preset이 25~30개이므로 Cache에 적재된 벡터로 메모리에서 계산합니다.
            DB 왕복과 인덱스가 필요 없는 규모입니다"

pgvector   <=> 연산자는 개인 검색 한 곳에만 씁니다
           ai/app/repository/context_embedding_repo.py:22

일러스트 20~30장은 이미 하고 있는 것과 같은 규모입니다. 인덱스도, ANN 도, 쿼리 튜닝도 논의 대상이 아닙니다.

---

3. 내부 매칭 API — 기존 경계 안

새 엔드포인트는 지금 노출 중인 것 옆에 그대로 들어갑니다.

현재 노출   POST /internal/v1/context/process · POST /internal/v1/search
           /health · /ready                        ai/app/main.py:156-166

인증       X-Internal-Secret 을 /internal/ 접두 전체에 겁니다
           ai/app/core/security.py:12,21-26  →  새 라우터는 인증을 따로 짤 것이 없습니다

타임아웃    back → ai 는 process 1s/3s · search 1s/5s
           back/src/main/resources/application.yml:134-135,140-141
           표지 매칭은 GMS 호출이 없고 응답이 numpy 곱 한 번이라 search 보다 짧게 잡을 수 있습니다

다만 엔드포인트 신설은 05_AI_설계.md §13 개정이 코드보다 먼저입니다. ai/docs/spec/architecture.md:280-282 가 그 순서를 규정합니다 — 내부 API 스키마는 Spring 연동 계약이므로 계약 변경이 필요하면 static/05 개정을 거칩니다.

---

4. 더 싼 안 — 벡터를 저장하지 않는 구조

§1·§2 를 합치면, 벡터를 DB 에 두는 것이 이 설계에서 가장 비싼 부분입니다. 그 비용이 무엇을 사는지 되짚어 보시길 제안드립니다.

제안 원안   ai.cover_asset_embedding 에 벡터를 저장한다
           → 새 테이블 · 공용 계약 개정 · P 번호 · 낡음 검출 부재(§6) · 재계산 경로 없음

대안 A     일러스트 → PUBLIC preset ID 목록 매핑만 둔다. 벡터는 저장하지 않는다
           기동 시 preset 캐시에서 평균내 메모리에 올린다
           → 표지 30 x 1536 은 이미 하고 있는 27 x 1536 과 같은 규모다
           → profile 이 바뀌어도 preset 이 재생성되면 표지 벡터가 자동으로 따라온다
           → 낡음이 원리상 생기지 않는다 (§6 이 통째로 사라진다)
           → 내부 매칭 API 계약은 원안과 완전히 같다. coverKey 만 반환한다

대가도 적습니다. preset 캐시의 무효화 경로가 프로세스 재시작뿐입니다(architecture.md:171-172). 무중단으로 일러스트를 켜고 끄려면 재시작이 필요합니다. 일러스트 세트가 자주 바뀌지 않는다면 이 대가는 작습니다 — 20~30장을 사전 등록하고 그대로 쓰는 설계라면 그 조건에 맞습니다.

남는 질문은 그 매핑을 어디에 두는가 하나입니다.

대안 A-1   ai 스키마에 매핑 테이블 (cover_key, preset_id)
          → 여전히 새 테이블이다. 계약 개정과 P 번호는 그대로 필요하다
          → 대신 벡터가 아니라 출처를 저장하므로 §6 의 낡음이 사라진다

대안 A-2   ai/data/ 의 YAML — DDL 도 계약 개정도 필요 없다
          keyword_preset.yaml 이 이미 그 방식이고, 부트스트랩 경로도 있다
          → 대가: 일러스트 세트를 바꾸려면 사람이 GitHub 에 PR 을 내야 한다
          → 대가: core.cover_asset 의 cover_key 행과 YAML 이 FK 없이 손으로 맞아야 한다
                 (지금 제안에도 core↔ai 사이 FK 가 없으므로 이 비용은 원안에도 있습니다)

A-2 가 가장 쌉니다. 새 테이블도, 공용 계약 개정도, P 번호도 없습니다. 다만 「운영자가 화면에서 일러스트를 관리한다」는 요구가 나중에 붙으면 A-1 이나 원안으로 가야 하므로, 그 요구가 있는지부터 정해 주시면 셋 중 하나로 좁혀집니다.

---

5. 먼저 정해야 할 것 둘

최소 유사도 기준값 — 지금 정할 근거 부재

제안서의 「최소 유사도 기준 적용」과 「매칭 기준 미달이면 공통 기본 표지」가 이 값을 필요로 합니다. 그런데 이 벡터 공간에서 코사인이 적합/부적합을 못 가른다는 실측이 이미 있습니다.

ai/docs/implements/2026-07-31-candidate-threshold.md:76-77

fit    (63건)  min 0.3001  p50 0.4051  max 0.5956
unfit  (10건)  min 0.3100  p50 0.3224  max 0.4225      ← 구간이 겹칩니다

τ 를 0.30~0.45 로 훑어 어느 값도 채택 기준에 미달했습니다
최선 후보 τ=0.34 에서도 교환비 1.22 · Context 단위 정당 5 · 부당 5 로 동률입니다

기존 SIMILARITY_FLOOR = 0.30(ai/app/core/config.py:123)은 Context 본문 → preset 분포에서 나온 값입니다. 표지 매칭은 preset 평균 → 일러스트 평균이라 분포가 다릅니다. 그대로 옮겨 쓸 수 없습니다.

값을 정하려면 재야 하고, 그것은 AI 파트 일입니다. 일러스트 세트와 각 일러스트의 preset 목록이 확정되면 후보 매칭 분포를 뽑아 기준값을 제안드리겠습니다. 다만 위 실측을 보면 「기준 미달」이 실제로는 거의 발생하지 않거나, 반대로 유의미하게 가르지 못할 가능성이 둘 다 있습니다. 재고 나서 답을 드리겠습니다.

「단순 평균」 — 이 벡터 공간에서 미측정인 집계

제안서의 AI 파트 책임에 「최대 3개 키워드 벡터의 단순 평균 계산」이 있습니다.

현황   app/ 전체에 벡터 평균을 쓰는 코드가 0건입니다
선례   ai/app/service/judge_vote.py:15 는 confidence 집계에서
      "평균은 이상치 하나에 끌린다"며 중앙값을 택했습니다

「평균이 나쁘다」고 말하는 것이 아닙니다. 벡터 평균과 스칼라 평균은 다른 문제이고, 정규화된 임베딩의 평균이 합리적인 경우도 많습니다. 다만 우리가 이 벡터 공간에서 평균을 재 본 적이 없고, 인접 과제에서 다른 집계를 택한 선례가 있습니다. 위 기준값 측정과 같은 하네스에서 평균·정규화 후 평균·최댓값 집계를 함께 재겠습니다. 결과가 갈리지 않으면 제안대로 단순 평균으로 갑니다.

---

6. 낡음 검출 부재 — 가장 큰 구멍

저장 안(원안·A-1)을 택하실 경우 이 절이 가장 중요합니다.

profile 의 낡음 검출 한계

규정   ai/docs/spec/model-profile.md:129-130
      "description·examples 변경은 Preset Embedding 재생성 대상입니다"
      그런데 이 항목은 "Profile 접미사를 올리지 않는 경우" 목록 아래에 있습니다

즉    preset 텍스트를 고치면 preset embedding 이 바뀌는데
      embedding_profile 컬럼 값은 그대로입니다

따라서 표지 벡터가 preset 평균이라면, profile 이 같은 채로 조용히 낡습니다
      is_active 도 안 바뀌고 어떤 컬럼도 안 바뀝니다. 신호가 나오는 자리가 없습니다

이미 일어난 사례 하나

preset 텍스트 개정은 가정이 아니라 이번 주에 일어난 일입니다.

ai 커밋 2ee6291 (S15P11A705-228)  프리셋 examples 개정
                                 ai/docs/implements/2026-08-03-dev-deploy-gap.md:145

그 개정을 따라가야 하는 값
  infra apps/dev/ai/values.yaml:77  bootstrap.version = "preset-204824bd37e6"  (개정 전)
  ai origin/dev 현재 봉인 값                          = preset-ab321360b0df
  근거: 같은 문서 :19, :176, :211-215

같은 문서 :286 — "bootstrap.version 에 검사가 없다.
                 프리셋 파일이 바뀌어도 봉인 값이 낡았다는 신호가 어디에서도 나지 않는다"

preset 텍스트를 추적하는 마커가 이미 하나 있는데 그것조차 낡은 채로 며칠 갔습니다. 표지 벡터에는 그런 마커가 아예 없습니다.

제안 스키마의 출처 부재

ai.cover_asset_embedding 이 cover_key · embedding · embedding_profile · is_active 인데, 그 벡터가 어떤 preset ID 들의 평균인지가 어느 컬럼에도 남지 않습니다.

이것이 낡음보다 더 큰 문제를 하나 더 만듭니다.

keyword_preset   재생성 경로가 있습니다 — app/bootstrap/load_presets.py 가 YAML 에서 다시 만듭니다
cover_asset_embedding   출처가 없으면 재생성 경로가 없습니다
                        profile 을 올리는 날 사람이 일러스트별 키워드를 다시 등록해야 합니다

출처(preset ID 목록)만 저장하면 profile 전환 재생성이 GMS 임베딩 호출 0회로 끝납니다 — preset 이 재생성된 뒤 그 벡터들을 다시 평균내면 되기 때문입니다. 이것이 가장 값싼 방어입니다. 그리고 출처를 저장할 것이라면 벡터는 안 저장해도 됩니다 — 그것이 §4 의 대안입니다.

---

7. 정정 하나 — Spring 의 ai 접근

제안 DB 분리안에 이 문장이 있습니다.

Spring은 ai 테이블을 직접 읽거나 쓰지 않습니다.

이 조항이 필요한 이유 — 스키마 소유권 충돌 회피 — 에는 동의합니다. 다만 현행 시스템의 서술로는 맞지 않습니다. Spring 은 이미 네 곳에서 ai 를 읽고 씁니다.

back/src/main/java/com/pinlog/pinlogback/domain/
  ai/repository/ContextAiStateRepository.java:38-42     INSERT INTO ai.context_ai_state
  ai/repository/AiDerivedDataRepository.java:48,60      UPDATE ai.context_ai_state
                                                        UPDATE ai.context_embedding
  ai/repository/ContextKeywordRepository.java:94-108    core.* JOIN ai.context_ai_state
                                                        JOIN ai.context_keyword JOIN ai.keyword_preset
  feed/repository/FeedKeywordRepository.java:42-67      같은 형태의 조인 두 벌

그리고 공용 계약이 그 쓰기를 규정합니다.

docs/static/06_데이터모델_및_무결성.md:32-39   쓰기 매트릭스
  ai.context_ai_state    백엔드: 최초 생성 · PENDING · CANCELLED · retry_count · Finalizer FAILED
  ai.context_embedding   백엔드: is_deleted 만 UPDATE

같은 문서 :43
  "백엔드는 ai.context_keyword를 읽기 조인할 권리를 가집니다"

ai/docs/spec/architecture.md:50 의 시스템도에도 Spring -.읽기 조인.-> ai 화살표가 있습니다

실제 경계는 단방향입니다 — 금지된 것은 FastAPI 가 core.* 에 닿는 것이지 그 역이 아닙니다. ai/docs/spec/architecture.md:12 가 "ai 스키마만 사용합니다. core.*는 조회도 하지 않습니다" 라고 적고, ai/docs/proposals/README.md 의 P9 가 그것을 "FastAPI core.* 접근 금지(DB role ai 한정, 조인은 백엔드 방향만)" 로 굳혀 두었습니다.

---

8. AI 파트가 할 것

즉시 가능    내부 매칭 API 구현 (§3) — 계약 개정 후
            벡터 계산 (§2) — 새로 만들 인프라 없음

먼저 잰다    최소 유사도 기준값 (§5) — 일러스트 세트와 preset 매핑이 확정되면 착수
            집계 방식 (평균 · 정규화 후 평균 · 최댓값) 비교 — 같은 하네스

먼저 정한다  저장 안 vs 비저장 안 (§4) — 운영자 관리 화면 요구 유무가 갈림점
            그 결정이 P 제안의 범위를 정합니다 (테이블 신설인가, 매핑 파일인가)

문서 선행    05 §12 개정 (테이블을 두는 경우) · §13 개정 (엔드포인트) · P 번호

§4 의 갈림점 하나만 정해 주시면 나머지는 저희가 진행하겠습니다 — 운영자가 화면에서 일러스트 세트를 관리하는 요구가 있는지 여부입니다. 없다면 새 테이블 없이 갈 수 있고, 그러면 §6 의 낡음 문제도 함께 사라집니다.

core.cover_asset·core.collection_cover 설계와 BYTEA·백업은 각각 백엔드·인프라 소관이라 이 코멘트에서 다루지 않았습니다.