리뷰로거 — 유환호가 맡은 AI 검색 최적화 작업

어떤 문제를 풀고, 무엇을 만들고 적용했는가

1. 01

   경쟁률 통계가 실제보다 낮게 나가고 있었다

   체험단 플랫폼 중 8곳은 신청자 수를 목록에 아예 싣지 않는데, DB 스키마가 그 값을 0으로 저장하고 있었다. "신청자 없음"과 "신청자 수 모름"이 같은 값이 되면서, 평균 경쟁률이 4.87:1로 실제(5.76:1)보다 낮게 나오고 있었다. 하필 이 통계는 "블로그·기사에 인용하셔도 됩니다"라고 공개까지 해 둔 페이지였다. 신청자 수 미공개 플랫폼 목록을 만들어 통계·정렬 로직 양쪽에서 제외했고, 그 목록이 실데이터와 계속 맞는지 대조하는 검사도 함께 만들었다.

2. 02

   월간 리포트를 만들려다 발견한 삭제 정책

   운영 DB는 마감 30일 뒤 공고 행을 지운다. "지금 데이터가 많이 남아 있으니 지난달 리포트가 성립한다"고 판단했다가, 그게 완전성의 증거가 아니라는 걸 다시 확인했다 — 데이터가 많이 남아 있는 것과 그 달의 데이터가 전부 남아 있는 것은 다른 말이다. 삭제 영향이 없는 날들의 기간 분포로 역산해, 8월 1~2일 발견분 중 약 115건(0.66%)이 이미 지워졌을 것으로 추정했다. 리포트에 그 추정치를 한계로 그대로 실었고, 다음 달부터는 삭제되기 전에 영구 보존하는 별도 테이블을 새로 설계했다.

3. 03

   수집 자동화가 며칠간 멈춰 있었다

   데이터로 역산해 보니 자동 수집이 특정 날짜를 마지막으로 멈춰 있었다. 문제는 멈춘 것 자체가 아니라 멈춘 줄 아무도 몰랐다는 것이었다. 새 모니터링 인프라를 붙이는 대신, 데이터 자체(마지막 수집 시각)를 심박으로 쓰는 검사를 만들었다 — 일정 시간 이상 새 수집이 없으면 실패로 보고한다.