GitHub REST API에 사용자·조직·저장소·엔터프라이즈 팀별 비용 센터 조회 추가, 사용자 지정 역할의 접근 범위는 변경 로그와 문서의 서술이 다름

Published · AI Daily — AI-assisted deep research, methodology & disclosure

2026년 11월 3일 GitHub는 사용자, 조직, 저장소, 엔터프라이즈 팀이 속한 비용 센터를 돌려주는 REST 엔드포인트를 추가해, 모든 비용 센터를 나열해 훑을 필요가 없어졌습니다. 응답에는 비용 센터 ID와 이름이 담기고, 없으면 memberships가 비어 있습니다. 문서는 resource_type(user, repository, organization, team)과 name 매개변수, API 버전 2026-03-10, 세분화된 토큰으로는 GitHub App 사용자·설치 토큰 두 가지뿐이며 Enterprise billing 읽기 권한이 필요하다고 보여 줍니다. 접근 권한은 두 출처를 함께 읽어야 합니다. 변경 로그는 사용자 지정 역할 사용자가 이미 볼 수 있는 것만 조회한다고 하고, 문서는 그런 보유자도 '볼 수 있다'고만 하고 제한을 쓰지 않으므로 실제 역할로 시험해야 합니다. 속도나 요청 한도 수치는 없습니다.

2026년 11월 3일 GitHub는 어떤 리소스가 어느 비용 센터에 속하는지 알려 주는 REST API 엔드포인트를 추가했습니다. 변경 로그에 따르면 사용자, 조직, 저장소, 엔터프라이즈 팀을 조회할 수 있습니다. 이전에는 모든 비용 센터를 나열하고 각각의 리소스를 훑어야 했습니다. 이제는 리소스 유형과 이름을 하나의 엔드포인트에 넘기면 응답에 비용 센터의 ID와 이름이 담깁니다. 리소스가 어떤 비용 센터에도 속하지 않으면 memberships 배열이 비어서 돌아옵니다.

REST 문서가 세부 사항을 채웁니다. 요청은 엔터프라이즈 청구 경로의 비용 센터 멤버십에 대한 GET이며 쿼리 매개변수는 둘, resource_type(user, repository, organization, team 중 하나)과 name입니다. 사용자와 조직은 name이 로그인 이름이고, 저장소는 owner/repo 형식이며, 팀은 엔터프라이즈 팀 슬러그입니다. 엔터프라이즈는 슬러그로 지정하고, 문서의 예시는 API 버전 2026-03-10을 보냅니다. 문서에 적힌 상태 코드는 200, 400, 403, 404, 500, 503입니다. 200 응답 예시는 사용자 octocat에게 Engineering Team이라는 비용 센터를 가리키는 멤버십이 하나 있음을 보여 줍니다.

접근 권한은 두 출처가 정확히 같은 말을 하지 않으므로 함께 읽어야 합니다. 변경 로그는 엔터프라이즈 소유자, 청구 관리자, 엔터프라이즈 청구에 대한 읽기 권한이 있는 GitHub App이 엔터프라이즈 안의 모든 리소스를 조회할 수 있다고 하고, 이어서 조직 소유자와 엔터프라이즈 청구 읽기를 포함한 사용자 지정 역할 사용자는 이미 볼 수 있는 리소스와 비용 센터만 조회할 수 있다고 합니다. REST 페이지는 엔터프라이즈 소유자, 청구 관리자, 엔터프라이즈 안의 조직 소유자가 멤버십 정보를 볼 수 있고, 엔터프라이즈 청구에 대한 세분화된 읽기 권한이 있는 사용자 지정 역할 보유자도 볼 수 있으며, 그 읽기 권한을 가진 GitHub App 설치 토큰은 엔터프라이즈 안의 모든 리소스의 멤버십을 얻을 수 있다고 말합니다. 페이지는 조직 소유자를 자신이 소유한 조직, 그 조직에 속한 사용자, 볼 수 있는 저장소, 보이는 엔터프라이즈 팀으로 한정하지만, 사용자 지정 역할 보유자에 대한 제한은 쓰지 않았습니다. 즉 사용자 지정 역할의 범위는 변경 로그에는 한 가지로 서술되어 있고 문서에서는 열려 있으므로, 의존하기 전에 실제 사용자 지정 역할로 시험해 봐야 합니다.

토큰도 좁습니다. 문서는 이 엔드포인트가 GitHub App 사용자 액세스 토큰과 설치 액세스 토큰이라는 두 가지 세분화된 토큰 유형에서 동작하며 읽기 수준의 'Enterprise billing' 권한이 필요하다고 말합니다. 이 엔드포인트에 다른 토큰 유형은 나열되어 있지 않으므로, 다른 자격 증명을 쓰는 스크립트는 새 호출로 옮기기 전에 확인해야 합니다.

실제로 무엇이 달라질까요? 저장소와 사용자 목록을 관리하는 재무 또는 플랫폼 팀은 이제 모든 비용 센터의 리소스 목록을 내려받아 결합하는 대신 '이 저장소는 어느 비용 센터가 내는가'를 직접 물을 수 있습니다. 호출이 줄고 감사가 쉬워질 것이지만, 두 출처 모두 얼마나 빨라지는지는 수치로 밝히지 않습니다. 또한 비용 센터 데이터만 읽을 뿐 비용 센터가 무엇을 청구하는지 바꾸거나 리소스를 비용 센터에 배정하지는 않습니다. 빈 memberships 배열은 유용한 신호로, 어떤 비용 센터도 포함하지 않는 리소스를 보여 주므로 팀은 이를 훑어 배분되지 않은 지출을 찾을 수 있습니다.

요약하면, 새 엔드포인트는 리소스로 비용 센터를 바로 찾게 해 줍니다. 사용자 지정 역할의 범위는 변경 로그와 문서가 다르게 쓰고 있으므로 실제 역할로 시험해야 하고, 토큰은 GitHub App 사용자·설치 토큰 두 가지만 문서에 나옵니다. 속도나 요청 한도의 수치는 두 출처 모두 없습니다.

Sources

FAQ

이 새 엔드포인트는 어떤 문제를 해결하나요?

이전에는 리소스의 비용 센터를 알려면 모든 비용 센터를 나열하고 각 리소스를 훑어야 했습니다. 이제 resource_type(user, repository, organization, team)과 이름을 하나의 엔드포인트에 넘기면 비용 센터 ID와 이름이 돌아옵니다. 어느 센터에도 속하지 않으면 memberships 배열이 비어 있습니다.

사용자 지정 역할은 어디까지 조회할 수 있나요?

두 출처의 서술이 다릅니다. 변경 로그는 엔터프라이즈 청구 읽기를 포함한 사용자 지정 역할 사용자가 이미 볼 수 있는 리소스와 비용 센터만 조회할 수 있다고 합니다. REST 문서는 그런 보유자도 멤버십을 볼 수 있다고만 하고 제한을 쓰지 않습니다. 단정하지 말고 이전 전에 실제 역할로 시험하세요.

어떤 토큰으로 호출할 수 있나요?

문서는 GitHub App 사용자 액세스 토큰과 설치 액세스 토큰의 두 가지 세분화된 토큰만 나열하고 Enterprise billing 읽기 권한을 요구합니다. 이 엔드포인트에 다른 토큰 유형은 나열되지 않으므로 다른 자격 증명을 쓰는 스크립트는 새 호출로 옮기기 전에 확인하세요.