개발 slecs

공개 데이터 불일치 매일 감시

목차

공개 API나 공개 데이터 세트에서 제공하는 정보와 시스템의 실제 상태가 점점 벗어나는 문제를 "드리프트(drift)"라고 부른다. 외부 사용자 입장에서는 우리가 제공한 리스트가 곧 "신뢰할 수 있는 진실"인데, 그게 실제와 맞지 않는 순간 신뢰도가 떨어진다. 이번 작업은 그 드리프트를 매일 자동으로 감시하고, 문제가 생기면 즉시 팀에게 알리는 체계를 만드는 것이었다.

공개 surface 드리프트가 왜 문제인가

공개 API나 데이터 다운로드 링크는 외부 사용자와의 "계약"이다. 우리가 "이렇게 제공한다"고 문서화하고 배포한 것이니, 일관되게 유지돼야 한다. 하지만 실제로는:

  • 내부 시스템이 업데이트되면서 생성 스크립트와 실제 데이터베이스가 점차 벗어남
  • 배포 과정에서 설정이 누락되거나 캐시가 갱신되지 않음
  • 한 번 배포한 후 사이드 이펙트로 공개 리스트가 조용히 변함

사용자 입장에서는 "어제는 있던 항목이 오늘은 없네?", "문서에는 이렇다고 했는데 실제 API 응답이 다르네"라는 불만으로 이어진다. 우리 팀 입장에서도 드리프트를 후발적으로 발견하면 (버그 리포트 받았을 때쯤) 이미 외부 신뢰가 손상된 상태다.

구현: 매일 자동 체크 + Discord 알림

이번에 세 개 파일을 수정했다:

_lib/drift_check_notify.py — 핵심 로직. 실제 데이터와 공개 surface 생성 결과를 비교하고, 차이를 발견하면 Discord로 알림을 발송한다. baseline 데이터와 현재 생성 결과를 비교 후, 심각도별로 필터링해서 정말 대응이 필요한 것만 띄운다.

scripts/gen_public_lists.py — 공개 리스트를 생성하는 스크립트. 이 스크립트의 출력이 공개 API의 소스가 되므로, 이것과 실제 배포된 데이터를 비교하는 기준점이 된다.

data/sites.json — 공개할 항목들의 정의 및 메타데이터. 이 파일이 변경되면 드리프트 체크의 기준점도 영향받는다.

기본 흐름:
- 매일 정해진 시각에 자동 실행
- 현재 시스템 상태 스냅샷 취득
- gen_public_lists.py로 공개 리스트 재생성
- 최근 배포 버전이나 sites.json 내용과 비교
- 차이 발견 시 Discord에 상세 리포트 발송

항목 개선 전 개선 후
드리프트 감지 사용자 리포트 대기 매일 자동 체크
감지 시간 수일~수주 24시간 이내
알림 채널 없음 (우연히 발견) Discord 실시간
대응 준비 급박함 여유 있게 문제 분석 가능

회고: 자동화 감시의 중요성

이런 "드리프트 감시" 같은 업무가 진짜 중요한 이유는, 기술팀이 매 순간 공개한 약속을 일일이 수동으로 검증할 수 없기 때문이다. 시스템이 커질수록, 공개 surface가 많아질수록 손으로 체크하는 방식은 한계가 있다. 결국 "최근엔 문제 없으니까 괜찮겠지"하다가 어느 날 갑자기 터진다.

이런 패턴은 다른 시스템에서도 자주 본다:
- 캐시 일관성: 캐시 갱신 실패 → 구 데이터 노출
- 권한 설정: 공개 범위 설정과 실제 노출 범위 미스매치
- 스키마 진화: API 문서와 실제 응답 구조 불일치

모두 "공개했던 것과 실제가 다르다"는 점에서 공통점이 있다. 이 경우들을 하나하나 손으로 감시할 수는 없고, 결국 자동화된 지속적 검증이 유일한 답이다.

Discord 알림을 선택한 것도 비슷한 맥락이다. 이메일은 묻힐 위험이 높고, 로그는 찾기 불편하고, Slack이나 Discord 같은 실시간 채널은 팀 커뮤니케이션 중심과 맞닿아 있어서 누군가는 반드시 눈에 띄게 된다.

한 가지 배운 점: 알림이 너무 잦으면 피로도만 늘어난다. 이번 구현에서도 "정말 문제가 될 만큼 심각한 드리프트"인지 필터링하는 로직을 중요하게 봤다. 예를 들어 1-2개 항목의 순서 차이는 무시하고, 진짜로 항목이 사라지거나 새로 추가되는 경우만 알리는 식이다. 조용함과 민첩함의 균형이 중요하다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.