깃허브, 스타 이력 조회 개편…요청 수 감소와 통계의 한계 공개

저장소의 관심도 변화를 분석하려는 개발자에게는 통계를 얼마나 적은 요청으로 얻는지와 그 통계가 무엇을 세는지가 함께 중요하다. 깃허브는 10월 14일 공개한 기술 글에서 개인 식별정보 없이 일별 스타 집계를 반환하는 이력 API 설계를 설명했다. 회사에 따르면 한 번의 요청으로 최대 30주를 조회할 수 있다.

먼저 해석해야 할 부분은 기록의 범위다. 깃허브 설명상 이용자가 스타를 취소하면 해당 레코드는 삭제된다. 따라서 이 집계는 과거에 일어난 모든 스타 추가와 취소를 보존한 사건 기록이 아니다. 이를 활용하는 국내 개발팀도 특정 시점의 관심도나 캠페인 효과를 분석할 때 이런 삭제 동작을 고려할 필요가 있다.

요청 수 비교는 약 25만1천 스타를 대상으로 한 react/react 사례다. 깃허브가 제시한 전체 이력 조회 요청은 기존 약 2,511회에서 새 방식 약 24회로 줄었다. 이는 필요한 요청 횟수의 변화이며, 응답시간이 같은 비율로 단축됐다는 측정 결과는 아니다. 다른 저장소에서도 같은 수치가 나온다는 근거는 제시된 자료에 없다.

회사가 설명한 구현의 핵심은 집계 전에 조회 범위를 좁히는 것이다. 페이지 매개변수를 생성 시각 인덱스의 주 단위 기간으로 바꾸고, 그 기간에 들어오는 레코드만 일별로 합산한다. 깃허브는 전체 이력을 읽는 동안 각 스타 레코드를 대략 한 번씩 처리한다고 밝혔다. 다만 기간 안의 스타 수에는 상한이 없어 특정 주에 스타가 몰리면 쿼리 비용이 커질 수 있다.

기존 방식에는 페이지마다 저장소의 현재 스타 전체를 세는 쿼리가 실행되는 버그도 있었다고 회사는 보고했다. 접근 제한 직전 일주일의 느린 쿼리 기록에는 해당 쿼리가 약 3만7천 건 남았고 평균 소요시간은 약 3초였다. 데이터베이스 보호 장치가 중단한 쿼리도 1천 건을 넘었다는 설명이다.

관련 배경으로 클라우드플레어는 10월 13일 D1의 계정별 저장공간 사용량을 미리 집계하는 구조를 공개했다. 데이터베이스별 변화분을 별도 테이블에 쌓고 매초 계정 합계에 반영하며, 결과에는 최종적 일관성이 적용된다고 밝혔다. 요청 시 대상 기간을 좁히는 깃허브 방식과 비동기 사전 계산 방식은 구별된다. 이 자료는 깃허브의 성능 수치를 독립 검증한 결과가 아니다.