GitHub 별 기록 API가 돌아왔다…사용자 신원은 빠졌다
GitHub가 2026년 9월 4일 개별 사용자를 노출하지 않고 저장소의 별 증가 추이를 제공하는 새 REST API를 공개했다. GitHub의 공식 변경 기록 은 이 엔드포인트가 시점별 별 개수를 반환해, 개인정보 보호를 위해 기존 stargazer 목록 접근이 제한된 뒤 멈춘 성장 추적 연동을 대체한다고 설명한다.
새 API의 첫 적용 결과도 확인됐다. GitHub의 9월 4일 공개에 이어 Star History의 9월 5일 적용 기록 은 새 엔드포인트로 공개 저장소 차트를 복구했으며, 종전 목록 API의 4만 개 별 수집 한도도 차트 계산에서 사라졌다고 밝혔다. 제목의 ‘돌아왔다’는 기존 사용자 목록 API가 복원됐다는 뜻이 아니라, 신원을 제외한 집계 API를 통해 별 기록 차트가 다시 작동하게 됐다는 의미다.
새 응답은 주간 객체 안에 일별 증가량을 담는다
새 경로는 GET /repos/{owner}/{repo}/stargazers/history다. 응답은 별을 누른 계정의 목록이 아니라 달력상 한 주를 나타내는 객체 배열이며, 가장 최근 주부터 저장소 생성 시점 방향으로 정렬된다.
GitHub REST 문서의 별 기록 명세 에 따르면 각 객체는 주의 시작을 나타내는 Unix 타임스탬프인 week, 해당 주의 별 증가량인 total, 일요일부터 시작하는 7개의 일별 개수를 담은 days를 반환한다. 별이 늘지 않은 주도 0으로 채워지며, 주와 날짜의 경계가 반드시 UTC에 맞는 것은 아니다.
문서의 예시 응답은 week와 함께 total 19, days [0, 12, 7, 0, 0, 0, 0]을 보여준다. 이는 누적 별 수가 19라는 뜻이 아니라 그 주에 19개가 추가됐고, 월요일과 화요일에 각각 12개와 7개가 늘었다는 뜻이다. total은 days의 합과 대응하지만 과거 어느 시점까지의 누적치는 포함하지 않는다.
페이지당 최대 30주, 최대 100페이지를 요청할 수 있다. 공개 저장소 데이터는 인증 없이도 조회할 수 있으며, 세분화된 개인 액세스 토큰이나 GitHub App 토큰을 사용할 때는 저장소 Metadata 읽기 권한이 필요하다. 요청에는 application/vnd.github+json Accept 헤더가 권장되고 공식 예시는 X-GitHub-Api-Version에 2026-03-10을 사용한다.
사용자별 기록에서 시간 구간별 집계로 바뀌었다
기존 GET /repos/{owner}/{repo}/stargazers 방식은 stargazer 한 명마다 레코드 하나를 반환했다. application/vnd.github.star+json 미디어 타입을 지정하면 사용자 객체와 starred_at 시각을 함께 받아, 타임스탬프를 정렬하고 누적하는 방식으로 성장 곡선을 만들 수 있었다.
문제는 차트에 필요하지 않은 login, avatar_url, 프로필 주소 같은 계정 정보까지 응답에 포함됐다는 점이다. 수집량과 요청 횟수도 별을 누른 사용자 수에 비례했고, 기존 페이지 상한 때문에 별이 4만 개를 넘은 저장소에서는 전체 사용자별 기록을 끝까지 가져올 수 없었다. Star History는 이 구간 뒤의 곡선을 표본 페이지와 현재 별 수로 보완했기 때문에 꼬리 부분이 실제보다 직선에 가까웠다고 설명했다.
2026년 중반 GitHub가 개인정보 오용 방지를 이유로 stargazer 목록과 관련 화면의 접근을 저장소 관리자와 협업자로 제한하면서, 소유하지 않은 공개 저장소를 그리던 차트가 작동하지 않게 됐다. 새 history 엔드포인트는 계정 식별자를 돌려주지 않는 대신 주간 합계와 일별 분포를 제공한다. 요청 비용의 기준도 저장소의 인기도가 아니라 저장소가 존재한 기간으로 옮겨간다.
따라서 두 API는 모든 용도에서 같은 결과를 내는 대체재가 아니다. 새 API로 저장소 관심도의 증가 시점과 속도는 계산할 수 있지만, 누가 별을 눌렀는지 또는 개별 계정이 정확히 어느 시각에 행동했는지는 알 수 없다. 사용자 이름이나 starred_at을 후속 분석·중복 제거 키로 사용하던 연동은 집계 API만으로 기존 기능을 재현할 수 없다.
차트 변환은 역순 정렬과 누적 합산이 핵심이다
기존 코드는 사용자별 starred_at을 오래된 순서로 정렬한 뒤 레코드마다 누적값을 하나씩 늘렸다. 새 구조에서는 먼저 필요한 페이지를 모두 가져와 최신 주 우선 배열을 과거순으로 뒤집고, 각 주의 days를 일요일부터 순서대로 펼쳐야 한다. 그 일별 증가량을 차례로 더하면 기존 누적 별 곡선과 같은 형태를 만들 수 있다.
주간 차트라면 days를 펼치지 않고 total만 누적해도 된다. 일별 차트는 week를 기준점으로 삼고 days의 배열 위치를 날짜에 대응시켜야 하지만, 경계가 UTC와 일치한다고 가정해 week를 임의로 UTC 자정에 다시 맞추면 날짜가 어긋날 수 있다. API가 제공한 구간 경계를 보존하는 편이 안전하다.
변환 과정에서는 각 주의 total과 days의 합이 일치하는지 확인할 수 있다. 이는 응답 자체를 다시 검증하기 위한 별도 통계가 아니라, 페이지 결합이나 배열 처리 중 일부 값을 빠뜨렸는지 찾는 무결성 검사다. 여러 페이지에 걸친 주간 객체는 모두 과거순으로 정렬한 뒤 한 번만 누적해야 페이지 경계에서 중복 계산을 피할 수 있다.
가장 중요한 제약은 total이 누적치가 아닌 해당 주의 증가량이라는 사실이다. 별도 기준 누적값이 없다면 임의의 중간 페이지부터 읽어 정확한 과거 총계를 만들 수 없다. 특정 날짜의 누적 별 수를 계산하려면 저장소 생성 주까지 앞선 증가량을 확보해야 한다.
현재 별 개수는 별도 응답으로 분리됐다
GitHub는 현재 별 개수를 반환하는 GET /repos/{owner}/{repo}/stargazers/count도 함께 제공한다. 응답은 count 하나이므로, history가 맡는 과거 증가량과 현재 시점의 총계를 서로 다른 데이터로 관리할 수 있다. 별을 달았다가 취소한 사용자는 현재 count에 포함되지 않는다.
차트에서는 history의 일별 또는 주별 증가량으로 곡선을 만들고 count를 마지막 표시값과 비교하는 구성이 가능하다. 그러나 history를 전부 누적한 값에 현재 count를 다시 더하면 같은 별을 중복 계산한다. 반대로 일부 history 페이지만 읽은 뒤 count를 끝점으로 연결하면 시작점과 끝점은 보여도 그 사이의 정확한 곡선은 복원할 수 없다.
Star History가 요청한 후속 개선도 이 지점에 있다. 주간 객체마다 누적값이 추가되면 모든 과거 페이지를 읽지 않고도 일부 구간의 정확한 곡선을 계산할 수 있지만, 현재 명세에는 week·total·days만 있다. 시간 단위 데이터도 제공되지 않아, 사용자별 starred_at으로 가능했던 시간대별 분석은 일 단위보다 세밀하게 재현할 수 없다.
확인된 현재 상태는 새 집계 엔드포인트가 공개됐고 Star History의 공개 저장소 차트가 이를 사용해 다시 작동한다는 것이다. 기존 목록 API가 되돌아온 것은 아니며, 사용자별 신원과 타임스탬프가 필요했던 분석은 여전히 대체 경로가 없다. 앞으로의 변화는 주간 누적값 같은 추가 필드가 명세에 들어오는지, 다른 차트 도구가 사용자 이벤트 모델을 집계 모델로 얼마나 전환하는지에 달려 있다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.