[AI] 기존 레코드 임베딩·키워드 누락 보정 및 장애 대응 처리

[ghkim1632]

AI 서버가 동작하기 전에 저장된 레코드가 맥락 검색 결과에 노출되지 않는 문제가 확인되었습니다.

확인한 바로는 해당 레코드에 대해 맥락 임베딩이 생성되지 않았고, 검색에 필요한 키워드도 생성되지 않아 발생한 문제로 보입니다.

다음 두 가지 대응이 필요합니다.

1. 기존 레코드 보정

• 임베딩 및 키워드가 누락된 기존 레코드를 조회
• 해당 레코드에 대해 임베딩과 키워드를 일괄 재생성
• 처리 이후 맥락 검색이 정상적으로 동작하는지 확인

2. AI 서버 장애 대응

• AI 서버가 동작하지 않더라도 원본 레코드 저장은 정상적으로 완료
• 임베딩 및 키워드 생성 상태를 별도로 관리
• 생성 실패 시 재시도할 수 있도록 실패 레코드를 저장하거나 작업 큐에 등록
• 스케줄러 등을 통해 미처리 레코드를 주기적으로 확인하고 재처리
• 반복 실패 시 원인 확인이 가능하도록 로그와 실패 상태 관리

AI 서버 장애가 복구된 이후 누락된 데이터가 자동으로 보정될 수 있는 구조가 필요해 보입니다. 기존 데이터 보정 범위와 재처리 방식을 검토 부탁드립니다.

[colosair]

확인이 늦었습니다. 요구 둘의 상태가 크게 다릅니다 — 갈라서 답합니다.

요구 2 (장애 대응 구조) — 이미 있습니다

말씀하신 구조가 back 에 구현돼 있습니다.

ai.context_ai_state                          단계별 상태 관리 (embedding_status · keyword_status)
AiRescanScheduler                            @Scheduled(fixedDelayString) 주기 재처리
AiRescanStateRepository                      만료 후보 선정 · FOR UPDATE SKIP LOCKED
AiRescanProperties                           주기·만료 시간·최대 재시도

원본 저장은 AI 호출과 분리돼 있어 AI 서버가 죽어도 Record 저장은 완료됩니다. 재시도 횟수도 retry_count 로 관리되고 소진되면 FAILED 로 넘어갑니다.

즉 「자동 보정 구조」는 설계돼 있고 돌고 있습니다.

요구 1 (기존 레코드 보정) — 이것이 실제 문제입니다

재처리가 안 되는 이유가 정확히 둘입니다. 코드로 확인했습니다.

AiRescanStateRepository.EXPIRED_STAGE_PREDICATE

  (embedding_status = 'PENDING'    AND 만료)
  OR (keyword_status = 'PENDING'    AND 만료)
  OR (embedding_status = 'PROCESSING' AND 만료)
  OR (keyword_status = 'PROCESSING' AND 만료)

① FAILED 는 후보에 안 들어갑니다. 화이트리스트라 자동으로 빠지고, 코드 주석이 그것이 의도임을 명시합니다.

FAILED·CANCELLED를 조건에 적지 않는다. (…) 블랙리스트(<> 'COMPLETED' 등)로 쓰면 나중에 추가되는 status가 조용히 후보가 된다.

② retry_count < maxRetry 조건도 걸립니다. 재시도를 소진한 것은 상태와 무관하게 빠집니다.

회수 경로가 두 겹으로 막혀 있습니다. 이건 결함이 아니라 설계입니다 — 영구 실패를 무한히 재시도하지 않으려는 것이고, CANCELLED(사용자가 지운 것)가 FAILED 로 뒤집히는 사고를 막습니다.

왜 FAILED 가 생겼는가 — 원인은 이미 고쳤습니다

말씀하신 「AI 서버가 동작하기 전에 저장된 레코드」에 더해, 한 가지 원인이 더 있었습니다.

배포분 d317f56 (07-29)   GMS 429(쿼터 초과)를 PermanentError 로 오분류
                        → 재시도 없이 즉시 FAILED 확정

즉 일시적 쿼터 초과가 영구 실패로 굳었습니다. 분류는 이후 수정돼 현재 배포분에는 없습니다만, 이미 FAILED 로 굳은 레코드는 스스로 풀리지 않습니다.

그래서 필요한 것

「한 번 실패로 굳은 것을 다시 밀어 넣는 경로」 하나입니다. 지금 어디에도 없습니다.

정해야 할 것이 셋입니다.

무엇을 되살리는가   FAILED 전부인가 · 특정 기간인가 · 429 로 실패한 것만인가
어떻게 실행하는가   운영자 호출 API 인가 · 일회성 스크립트인가 · 자동인가
쿼터를 어떻게 쓰는가  GMS 는 분당 2건 안팎만 통과합니다(T27). 한 번에 밀면 다시 429 입니다

세 번째가 실무적으로 가장 무겁습니다. 무조건 재처리하면 진짜 영구 실패도 다시 돌아 쿼터를 먹고, 그 사이 신규 Record 가 밀립니다.

선행 — 운영에 실제로 몇 건인지 모릅니다

지금까지 측정은 전부 로컬 시연 DB 기준입니다. 운영 DB 의 embedding_status 별 건수를 아직 못 봤습니다.

S15P11A705-274(검색 컷 운영 DB 실측)에서 그것부터 확인하도록 해 뒀습니다. FAILED 가 몇 건인지 알아야 위 셋을 정할 수 있습니다 — 두어 건이면 수동으로 끝나고, 수십 건이면 쿼터 계획이 필요합니다.

진행

1  운영 DB 의 상태별 건수 확인          S15P11A705-274
2  회수 범위·실행 방식·쿼터 계획 결정
3  구현

1이 끝나면 이 이슈에 숫자를 올리고 2를 결정하겠습니다. 혹시 특정 Record 가 안 보인다는 사용자 제보가 있으면 그 ID 를 알려 주십시오 — 실제 사례가 있으면 범위 판단이 훨씬 정확해집니다.

[colosair]

원인이 둘로 갈렸습니다 — 각각 이슈로 남겼습니다

앞서 답변드린 조사를 마무리하고 원인별로 이슈를 나눴습니다. 처방이 서로 다릅니다.

#99   상태 행이 아예 없다 — 재스캔의 FROM 절에 들어오지도 못한다
          AI 접수 코드(back#82, 2026-07-29) 이전에 만들어진 Context
          처방: 백필 + 재발 방지

#100   행은 있는데 FAILED 로 굳었다 — 되살리는 코드가 어디에도 없다
          AI 가 20~25분 죽으면 그 창이 통째로 굳는다 (기본값 산수)
          AI 가 죽지 않아도 네 경로로 같은 일이 난다
          처방: 회수 경로 신설

이 이슈는 두 원인의 상위 증상으로 열어 둡니다. 둘 다 닫히면 여기도 닫습니다.

두 이슈가 공통으로 막힌 곳

규모를 모릅니다. 운영 DB 접근 경로가 없어 상태별 건수를 못 봤고, 두 이슈 다 「몇 건인지 알아야 처방을 정할 수 있다」로 끝납니다.

S15P11A705-274(검색 컷 운영 DB 실측)가 그 접근을 다루므로, 그때 상태별 건수도 함께 보겠습니다. 확인 쿼리는 두 이슈 본문에 적어 뒀습니다.

알려 주시면 도움이 되는 것

특정 Record 가 안 보인다는 사용자 제보가 있으면 그 ID 를 알려 주십시오. 실제 사례가 하나 있으면 위 둘 중 어느 경로인지 바로 갈리고, 회수 범위 판단이 훨씬 정확해집니다.