YM Guide의 운영 부채는 추천보다 데이터 갱신에 있었다

YM Guide는 청년 정책 정보를 질문과 추천으로 좁혀 주려는 제품이었다. 원천 API의 호출 제한을 고려해 가공 데이터를 저장하고 서비스하는 구조를 택했다. 요청할 때마다 원천을 조회하지 않는 이점이 있었지만, 그만큼 데이터 갱신은 내가 책임져야 했다.

빠른 응답과 최신 정보는 다른 축이었다

저장된 데이터를 조회하면 응답 경로가 단순해진다. 그러나 저장된 정책이 오래되었다면 빠르게 잘못된 판단을 돕는 결과가 될 수 있다. 정책의 신청 기간과 조건은 추천 점수보다 먼저 유효해야 하는 정보다.

기존 회고에는 갱신이 수동이라는 운영 부채를 명시했다. 이 부분을 지금도 완료된 자동화처럼 바꾸어 말하고 싶지는 않다. 수동 처리는 출시를 앞당기는 선택이 될 수 있지만, 누가 언제 확인할지 빠져 있으면 반복 작업이 아니라 잊힌 작업이 된다.

수집 실패를 빈 목록으로 숨기지 않기

당시 공개 예제에는 API 실패 시 빈 배열을 반환하는 코드가 있었다. 화면 전체가 멈추지 않는 장점은 있지만, 지금 보면 “해당 정책 없음”과 “정책을 가져오지 못함”을 구별하기 어렵다. 사용자에게 두 상황은 다른 안내가 필요하다.

다시 만든다면 마지막으로 성공한 데이터와 수집 상태를 분리하겠다. 갱신 실패 때 기존 정보를 보여 줄 수 있더라도 마지막 확인 시점을 남겨야 한다. 오래된 데이터를 계속 노출할지, 일부 추천을 제한할지는 정보의 성격에 맞춰 정해야 한다. 무조건 캐시를 보여 주는 것이 정답은 아니다.

자동화한다면 성공 기준부터

스케줄러가 실행됐다는 사실만으로 갱신이 완료된 것은 아니다. 예상보다 데이터가 급감했는지, 필수 필드가 사라졌는지, 만료 정책이 남아 있는지도 확인해야 한다. 지금이라면 수집·검증·공개 반영을 구별하고, 검증 실패로 기존 데이터를 유지한 경우도 운영 기록에 남기겠다.

이 제품을 돌아보며 추천 알고리즘에만 집중하면 안 된다는 것을 배웠다. 오래된 입력 위의 정교한 정렬은 신뢰를 만들지 못한다. 다음 작업의 우선순위를 고른다면 가중치 하나를 더 조정하기 전에 데이터가 언제, 어떻게 갱신되는지부터 확인하겠다.

관련 기록: YM Guide의 수동 갱신과 추천 설계