AI 리포트 캐시가 오래된 모델 결과를 붙잡던 문제
중복 호출을 줄이기 위한 AI 캐시가 모델 변경과 충돌하지 않도록 provider, model, payload 저장 기준을 점검한 기록입니다.
Code notes
코드에서 확인한 구현 포인트
배포 기준 2026.03.14
관련 파일
apps/web/lib/ai-report.tsapps/web/lib/ai-model.tsapps/web/lib/region-ai-policy.ts구현 메모
ai_reports에는 provider, model, payload를 함께 저장해 같은 세션의 중복 AI 호출을 줄인다.
modelOverride가 들어온 경우 캐시된 model과 비교해 오래된 모델 결과를 그대로 쓰지 않게 했다.
캐시 저장 실패는 사용자 리포트 실패로 이어지지 않도록 생성된 payload 반환과 저장 책임을 분리했다.
캐시는 비용을 줄이지만 품질을 고정한다
같은 분석 세션의 AI 리포트를 매번 다시 만들면 비용이 늘고, 사용자가 같은 리포트를 열 때마다 문장이 바뀌는 문제가 생긴다. 그래서 Tangly는 ai_reports에 생성된 payload를 저장하고 재사용한다.
그런데 모델 정책을 바꾸기 시작하면서 다른 문제가 생길 수 있었다. 더 좋은 모델로 다시 생성해야 하는 상황에서도 예전 캐시를 그대로 쓰면 품질 개선이 반영되지 않는다.
modelOverride와 캐시 불일치
서버에서는 캐시된 리포트의 provider와 model을 함께 저장한다. 그리고 특정 모델로 다시 생성해야 할 때는 저장된 model과 요청한 modelOverride가 같은지 확인한다.
모델이 다르면 캐시를 무조건 신뢰하지 않고 새 리포트를 만들 수 있게 했다. 비용 절약과 품질 개선이 서로 충돌하지 않도록 작은 조건문을 둔 것이다.
캐시 저장 실패는 사용자 실패가 아니다
AI 리포트 생성은 성공했는데 캐시 저장만 실패할 수도 있다. 이때 사용자에게 실패를 보여주는 것은 과하다. 사용자는 결과를 받아야 하고, 캐시는 운영 최적화에 가깝다.
그래서 저장 실패는 내부적으로만 다루고, 가능한 경우 생성된 payload를 그대로 반환한다. 비용 최적화 장치가 핵심 경험을 막아서는 안 된다.
배운 점
AI 캐시는 단순히 sessionId로만 보면 부족하다. 어떤 입력과 어떤 모델로 만든 결과인지까지 함께 봐야 한다.
특히 글로벌 모델 전략이나 첫 분석 premium 정책처럼 모델 선택이 바뀌는 구조에서는 캐시 키와 재생성 조건이 제품 정책의 일부가 된다.
Keep reading
다른 글 이어서 보기
AI Debugging
2026.05.03
8 min read
AI JSON 응답이 흔들릴 때 sanitize 계층 만들기
AI 리포트가 화면에서 기대하는 형태와 다르게 돌아올 때, 응답 계약과 정규화 계층으로 제품을 지킨 기록입니다.
AI Debugging
2026.05.03
8 min read
모바일 AI 분석이 멈춘 것처럼 보이던 문제
사진 촬영, 업로드, 분석 요청이 이어지는 모바일 AI 흐름에서 타임아웃과 재시도 기준을 나눈 기록입니다.
AI Debugging
2026.03.22
8 min read
주간 AI 리포트가 빈말이 되지 않게 fallback 만들기
주간 리포트에 충분한 데이터가 없거나 AI 생성이 실패해도 사용자에게 의미 있는 요약을 보여주기 위한 방어 로직입니다.