컴포넌트 인기도 기반 차등 수집
활성도와 유지보수 신호를 수집해 중요한 컴포넌트를 더 자주 갱신하도록 큐를 구성했습니다.
작업 요약
Stars·Forks·Commits·기여자 수 4종 지표 적용
활성도가 높은 컴포넌트를 더 자주 수집했습니다
오픈소스 생태계 전체를 같은 주기로 수집하면 중요한 컴포넌트와 거의 쓰이지 않는 컴포넌트가 같은 빈도로 자원을 사용합니다. 수집 자원이 한정돼 있어, 우선순위를 활성도 지표 데이터로 정했습니다.
Stars나 commits 같은 지표를 갱신 주기를 조정하는 운영 신호로 썼습니다. 산출한 점수에 따라 실제 갱신 주기가 달라지도록 수집 정책에 반영했습니다.
배경
라이브러리/컴포넌트를 선택할 때는 버전 정보에 더해 커뮤니티 활성도·유지보수 상태 같은 질적 정보가 필요합니다. 이런 신호는 소스 저장소에 흩어져 있어 외부 API로 수집·정량화할 필요가 있었습니다.
- Stars·Forks·Commits·기여자 수 등은 라이브러리의 활성도와 신뢰도를 가늠하는 핵심 지표
- 수집 대상 컴포넌트는 많은데 크롤링 자원은 한정 → 모든 컴포넌트를 같은 주기로 갱신하는 방식은 비효율
접근
- 수집
GitHub·GitLab GraphQL API로 활성도 지표 수집
- 점수화
중요도·인기도를 점수로 산출
- 차등 스케줄
점수가 높은 컴포넌트를 더 자주 갱신
- 최신성
한정된 자원으로 주요 데이터를 최신 상태로 유지
인기도 점수로 우선순위를 매겨 갱신 주기를 차등화했습니다. 크롤링 자원은 점수가 높은 컴포넌트에 먼저 배분했습니다.
아키텍처
점수가 높은 컴포넌트는 짧은 주기로, 낮은 컴포넌트는 긴 주기로 재수집되도록 스케줄러가 큐를 구성합니다.
결과
역할
데이터 엔지니어로서 수집 모듈 개발, 인기도 점수화, 차등 수집 전략 수립·적용을 직접 맡았습니다. 외부 GraphQL API로 활성도 지표를 모으는 수집기를 만들었고, 차등 수집 정책은 팀 리뷰를 거쳐 적용했습니다. 점수가 높은 컴포넌트는 짧은 주기로, 낮은 컴포넌트는 긴 주기로 재수집 큐에 배치했습니다.
🕷 라이브러리 크롤러 시리즈 ② — ① 멀티 언어 크롤러 구축 · ③ 누락 점검·Python 전환