refresh 게이팅 위치 선택 (aggregator vs ML)
상태
승인
후보군
| 방안 | 설명 |
|---|
| aggregator 게이팅 | aggregator가 캐시 hit 시 ML 자체를 호출하지 않음 |
| ML 게이팅 | ML /signals?refresh=가 자체 캐시로 claude 호출 여부 결정 |
결정
aggregator에서 게이팅한다. ML은 무변경(항상 fresh 계산)으로 둔다.
결정 이유
- claude 비용을 막으려면 ML 호출 자체를 건너뛰어야 한다. aggregator 캐시 hit 시 ML을 호출하지 않으면 claude·토스 API·뉴스 fetch 모두 절약된다. ML에 캐시를 두면 HTTP 왕복은 발생한다.
- ML(
signal-service)은 “매 호출마다 fresh 계산, 영속화는 상위가 담당”이라는 기존 주석·설계를 유지한다 (/recommendations 주석: “TTL 캐시 없음 — Aggregator가 DB 영속화를 담당”).
- 캐시·스냅샷·Redis가 모두 aggregator에 있어 게이팅 로직을 한 곳에 둔다.
검토 대안
| 방안 | 기각 이유 |
|---|
| ML 게이팅 | ML 코드 변경 필요, 캐시 분산(aggregator Redis/MySQL과 이중), HTTP 왕복은 여전 |
트레이드 오프
| 구분 | 내용 |
|---|
| 득 | claude·외부 호출 전부 절약, 캐시 단일 위치, ML 무변경 |
| 실 | aggregator가 캐시 정합성(적재 시점·refresh)을 전담 |