라이브러리/컴포넌트를 선택할 때는 버전 정보뿐 아니라 커뮤니티 활성도·유지보수 상태 같은 질적 정보가 필요합니다. 이런 신호는 소스 저장소에 흩어져 있어, 외부 API로 수집·정량화할 필요가 있었습니다.
Stars·Forks·Commits·기여자 수 등은 라이브러리의 활성도와 신뢰도를 가늠하는 핵심 지표
수집 대상 컴포넌트는 많은데 크롤링 자원은 한정 → 모든 컴포넌트를 같은 주기로 갱신하는 방식은 비효율
2접근
① 수집GitHub·GitLab GraphQL API로 활성도 지표 수집
→
② 점수화중요도·인기도를 점수로 산출
→
③ 차등 스케줄점수 높은 컴포넌트일수록 자주 갱신
→
④ 최신성한정 자원으로 핵심 데이터 최신 유지
핵심은 "모두 똑같이 자주 긁기"가 아니라, 인기도 점수로 우선순위를 매겨 갱신 주기를 차등화한 것입니다. 자원을 가장 가치 있는 컴포넌트에 집중시켰습니다.
3아키텍처
소스 저장소GitHub / GitLab
→
수집 모듈GraphQL로 Stars·Forks·Commits·기여자 수집
→
점수 엔진중요도·인기도 점수 산출
→
차등 스케줄러점수별 갱신 주기 결정
점수가 높은 컴포넌트는 짧은 주기로, 낮은 컴포넌트는 긴 주기로 재수집되도록 스케줄러가 큐를 구성합니다.
4임팩트
풍부한 정보 — 라이브러리의 활성도·유지보수 상태 등 질적 정보 제공
자원 효율 — 한정된 크롤링 자원을 인기도 높은 컴포넌트에 집중
최신성 유지 — 핵심 컴포넌트의 정보를 더 자주 갱신해 신선도 확보
5역할
데이터 엔지니어로서 수집 모듈 개발 → 인기도 점수화 → 차등 수집 전략 수립·적용을 담당했습니다. 외부 GraphQL API로 활성도 지표를 모으는 수집기를 만들고, 점수 기반으로 갱신 주기를 다르게 가져가는 전략을 설계·적용해 자원 효율과 최신성을 동시에 달성했습니다.