GitHub가 기업 단위 GitHub Apps 설치를 정식 제공하고 거버넌스·보안·관리 설정 관련 API 권한을 확장했습니다. 더 많은 기업 자동화에서 개인의 classic PAT 대신 앱 신원을 사용할 수 있게 하는 변화입니다. GitHub 공식 발표
자동화가 직원의 토큰에 묶여 있으면 퇴사나 역할 변경이 작업 중단으로 이어질 수 있습니다. 앱 신원으로 옮길 때는 소유권과 권한을 업무 단위로 정리할 기회가 됩니다.
이 글의 목차
사람의 토큰과 업무의 신원을 분리하는 이유
개인의 PAT로 운영하는 자동화는 그 사람의 계정 상태와 권한에 의존합니다. 담당자가 역할을 바꾸거나 계정을 정리하면 오래된 자동화가 갑자기 멈출 수 있어요. 앱 신원은 작업을 개인의 일상 계정과 나누어 관리하는 기반이 됩니다. 다만 앱에도 관리 책임자가 필요하며 개인 계정에서 벗어났다는 이유로 소유권까지 없어지는 것은 아닙니다.
기업 설정을 바꾸는 자동화는 일반 저장소 읽기보다 영향 범위가 클 수 있습니다. 현재 어떤 API를 호출하는지와 읽기만 필요한지, 정책을 변경하는지부터 목록으로 만듭니다. 이름이 비슷한 앱 권한을 추정해서 넓게 주기보다 각 호출에 필요한 권한과 설치 범위를 대조하면 과도한 접근을 줄이는 방향으로 이전할 수 있습니다.
인증 방식 변경과 기능 이전은 따로 검증합니다
새 앱이 인증에 성공해도 기존 스크립트가 쓰는 모든 API를 호출할 수 있다는 뜻은 아닙니다. REST와 GraphQL 호출, 기업과 조직 수준의 설정은 지원 범위와 권한 조건이 다를 수 있어요. 정상 응답을 받는 것뿐 아니라 필요한 항목이 빠지지 않는지, 변경 요청이 의도한 대상에만 적용되는지도 확인해야 합니다.
앱의 비밀 값과 키를 누가 보관하고 갱신할지도 정합니다. 작업 신원을 바꿔도 자격 증명을 소스 저장소에 넣거나 여러 작업이 하나의 광범위한 권한을 공유하면 위험은 남습니다. 조회 자동화와 정책 변경 자동화를 나누어 관리하면 문제가 생겼을 때 중단하거나 권한을 회수할 범위도 명확해집니다.
읽기 작업부터 나란히 비교하는 이전 예시
예를 들어 기업 설정을 정기적으로 수집하는 작업이라면 기존 PAT 경로와 앱 경로를 같은 입력으로 비교할 수 있습니다. 결과가 같고 필요한 권한만으로 동작하는지 확인한 뒤 운영 호출을 옮깁니다. 정책을 변경하는 작업은 단순 병렬 실행하면 중복 변경이 생길 수 있으므로 별도 시험 대상과 승인 절차를 사용해야 합니다.
전환 후에는 기존 토큰의 마지막 사용 기록과 남은 소비자를 확인하고 폐기 시점을 정합니다. 실패할 때 어떤 담당자가 앱 설정과 키, API 변경을 확인할지도 문서화합니다. GitHub Enterprise Server를 사용한다면 클라우드의 정식 제공 소식만으로 판단하지 않고 해당 서버 버전의 지원 범위를 별도로 확인합니다.
토큰 교체 전에 준비할 목록
- 자동화가 호출하는 REST·GraphQL 작업을 기록합니다.
- 앱 권한과 설치 범위를 필요한 기업·조직에 맞춥니다.
- 신규 자격 증명 검증 후 기존 토큰의 사용처와 폐기 시점을 정합니다.
개인 토큰을 한꺼번에 지우기보다 업무 흐름별로 이전합니다. 실패 시 담당자가 즉시 식별되는 운영 구조까지 함께 만듭니다.
발표문 기준일: 2026-10-23 · 확인일: 2026-10-24
.jpg){kind=link}