GitHub, 스타 히스토리 API로 요청 수 2,511개에서 24개로 대폭 절감

GitHub가 리포지토리 스타 히스토리를 집계된 일일 카운트로 제공하는 새로운 API 엔드포인트를 출시했다. 이번 변경은 스타 등록자 개인 정보를 노출해 스팸 및 피싱 캠페인에 악용되던 문제를 해결하고, 기존 방식이 초래한 심각한 데이터베이스 성능 저하를 개선한다.

개인 정보 기반 스크래핑의 문제점

기존에는 GET /repos/{owner}/{repo}/stargazers 엔드포인트를 통해 개별 사용자 레코드와 타임스탬프를 페이지별로 조회해 스타 히스토리를 재구성했다. 약 251,000개의 스타를 보유한 react/react의 경우 전체 성장 곡선을 만드는 데 약 2,511개의 요청이 필요했다. 이 방식은 비효율적이며 위험했다.

• 개인 정보 위험: 공개된 스타 등록자 목록이 스팸 및 피싱에 악용됨
• 데이터베이스 부하: 페이지네이션 버그로 인해 모든 페이지 요청 시 전체 스타 수를 계산해야 함. 주당 약 37,000개의 느린 카운트 쿼리가 실행되었으며 평균 3초가 소요됐고, 1,000개 이상은 안전장치로 인해 중단됨

새로운 설계: 시간 기반 필터링

새 엔드포인트는 집계 후 필터링에서 그룹화 전 필터링으로 처리 모델을 변경했다. 페이지 매개변수를 인덱싱된 created_at 범위로 변환해 데이터베이스가 전체 스타 집합을 스캔하는 대신 요청된 특정 주만 처리하도록 한다.

• 효율성: react/react의 전체 히스토리는 이제 2,511개 대신 약 24개의 요청으로 처리된다. 데이터베이스는 전체 히스토리 동안 각 스타를 약 한 번만 검사한다.
• 응답 구조: 각 요청은 최대 30주간의 일일 카운트를 반환한다. 응답 형식은 주간 커밋 활동 엔드포인트(GET /repos/{owner}/{repo}/stats/commit_activity)와 일치한다.

제한 사항 및 교훈

새로운 설계는 부하를 크게 줄이지만 일부 제약은 그대로 유지된다. 캘린더 경계와 제거된 스타가 데이터에 영향을 미치며, 특히 밀집된 주에는 여전히 느린 쿼리가 발생할 수 있다. 핵심 교훈은 응답 크기를 줄이는 것이 자동으로 쿼리 비용을 줄이지는 않는다는 점이며, 집계 전 필터링이라는 연산 순서가 성능에 결정적이었다.