GitHub, 저장소 스타 기록 조회 API 개선: 개인 정보 보호 및 성능 향상

무엇이 달라졌는가

GitHub은 최근 저장소의 스타(Star) 기록을 조회하는 API를 재구축하여 개발자 개인 정보 보호를 강화하고 시스템 성능을 대폭 개선했다. 기존에는 `GET /repos/{owner}/{repo}/stargazers` 엔드포인트가 저장소에 스타를 누른 사용자 목록과 타임스탬프를 페이지별로 제공했다. 이 방식은 개인 정보 노출 위험과 함께 인기 저장소의 경우 수천 건의 데이터베이스 요청을 유발하는 비효율성을 안고 있었다.

새롭게 구축된 엔드포인트는 사용자 식별 정보 없이 최대 30주간의 일별 스타 수를 단일 요청으로 반환한다. 이는 기존 방식이 개별 사용자 기록을 모두 조회한 후 집계하는 것과 달리, 데이터를 집계하기 전에 시간 범위로 스타를 필터링하는 방식으로 동작한다. 예를 들어, 약 25만 1천 개의 스타를 가진 `react/react` 저장소의 전체 스타 기록을 조회하는 데 기존에는 약 2,511회의 요청이 필요했지만, 새 엔드포인트는 약 24회 요청으로 동일한 정보를 얻을 수 있다.

변화의 배경과 맥락

이번 API 개선은 기존 스타 기록 조회 방식이 가진 두 가지 주요 문제점에서 비롯되었다. 첫째, 개인 정보 보호 문제였다. 기존 엔드포인트는 스타를 누른 사용자의 ID를 제공했기 때문에, 악의적인 행위자들이 이를 스팸이나 피싱 캠페인에 활용하기 위해 대량으로 수집하는 사례가 발생했다. 둘째, 성능 문제였다. 인기 있는 저장소의 경우, 스타 기록을 조회할 때 데이터베이스가 수천, 수만 개의 항목을 처리해야 했고, 이는 느린 쿼리 실행과 데이터베이스 부하로 이어졌다.

GitHub은 이러한 위험에 대응하기 위해 먼저 스타게이저 및 워처 목록 접근 권한을 저장소 관리자 및 협업자로 제한했다. 이 조치로 기존 API를 사용하던 많은 도구가 작동을 멈추게 되었고, GitHub은 유지보수 담당자 및 도구 개발자들과 소통하여 그들이 실제로 필요로 하는 것이 무엇인지 파악했다. 그 결과, 개발자들이 필요로 하는 것은 특정 시점 전후의 활동 비교나 새로운 개발자 유입 확인 등 '스타 수의 변화 곡선'이지, 개별 사용자 ID가 아니라는 점을 확인했다.

구체적 동작 방식 및 수치

기존 `GET /repos/{owner}/{repo}/stargazers` 엔드포인트는 "누가 이 저장소에 스타를 눌렀는가?"라는 질문에 답하기 위해 설계되었다. 이 엔드포인트는 페이지당 최대 100명의 사용자 목록을 반환했으며, 특정 미디어 타입을 지정하면 각 항목에 스타가 생성된 시점(`starred_at`)도 포함했다. 그러나 이 모델은 현재 스타를 누른 사람들을 기록하는 데 중점을 두었을 뿐, 스타 기록의 변화를 추적하는 용도로는 적합하지 않았다. 스타가 제거되면 해당 기록도 삭제되었기 때문에, 시간 경과에 따른 성장 곡선을 재구성하려면 모든 현재 스타 기록을 개별적으로 조회하고 처리해야 했다.

새로운 API는 달력 주(calendar week)를 기준으로 스타 기록을 페이지네이션한다. 각 요청은 `page` 및 `per_page` 매개변수를 인덱싱된 `created_at` 범위로 변환하고, 해당 주에 해당하는 스타를 필터링한 다음, 일별 카운트로 그룹화한다. 응답은 최대 30주간의 기록을 포함하며, `page` 값을 증가시키면 저장소의 과거 기록을 역순으로 탐색할 수 있다. 이 방식은 각 요청이 저장소의 모든 현재 스타를 처리하는 대신, 반환될 특정 주간의 스타만 처리하도록 하여 쿼리 비용을 크게 절감한다.

개발자에게 미치는 영향

이번 API 개선은 저장소 유지보수 담당자와 도구 개발자들에게 여러 긍정적인 영향을 미친다. 첫째, 스타 기록 데이터를 훨씬 더 효율적으로 얻을 수 있게 된다. 기존에는 수천 건의 요청과 페이지네이션 처리가 필요했던 작업이 이제 단 몇십 건의 요청으로 완료되어, API 호출 제한(rate limit)에 걸릴 위험이 줄어든다. 둘째, 개인 정보 보호가 강화된다. 사용자 ID가 포함되지 않은 집계된 데이터만 제공되므로, 스팸이나 피싱 목적으로 개인 정보를 수집하는 행위를 근본적으로 차단할 수 있다.

셋째, 데이터베이스 부하가 줄어들어 GitHub 플랫폼의 전반적인 안정성이 향상된다. 기존에는 느린 쿼리가 주당 수만 건 발생하고 이 중 천 건 이상이 데이터베이스 안전 장치에 의해 강제 종료되는 문제가 있었다. 접근 제한 조치 이후 스타게이저 요청이 약 60% 감소하고, 카운트 쿼리에 소요되는 총 시간이 약 80% 줄어들었다. GitHub.com의 저장소 스타게이저 페이지도 캐시된 스타 수를 사용하도록 업데이트되어, 해당 페이지에서 발생하던 느린 쿼리가 완전히 사라졌다.

적용 조건 및 한계

새로운 스타 기록 API는 기존 방식의 많은 문제를 해결했지만, 몇 가지 적용 조건과 한계점도 존재한다. 이 엔드포인트는 각 요청을 정의된 기간(최대 30주)으로 제한하지만, 해당 기간 내의 스타 수에는 제한을 두지 않는다. 따라서 특정 주에 비정상적으로 많은 스타가 발생할 경우, 여전히 느리거나 비용이 많이 드는 쿼리가 발생할 수 있다. 이는 예외적으로 스타 밀도가 높은 주에 대한 확장성 한계로 남아있다.

또한, 달력 주 경계(calendar boundaries)와 제거된 스타(removed stars)는 반환되는 데이터에 영향을 미칠 수 있다. 기존 스타 모델은 스타가 제거되면 해당 기록도 삭제되므로, 과거의 정확한 스타 수를 재구성하는 데는 여전히 제약이 있을 수 있다. GitHub은 이러한 세부 사항들이 새로운 API 계약의 일부임을 명확히 밝히며, 개발자들이 이를 인지하고 활용할 것을 권장한다. 그럼에도 불구하고, 새로운 엔드포인트는 기존보다 훨씬 안전하고 예측 가능한 방식으로 스타 기록을 제공한다.