GitHub CLI 만료형 OAuth 미리보기: 토큰 복사본의 수명을 점검하기

CLI는 계속 인증되는데 어제부터 돌던 보조 스크립트만 실패한다면 무엇부터 볼까? 인증을 갱신하는 도구와 토큰 문자열을 보관하는 도구가 다를 수 있다. GitHub가 2026년 10월 21일 발표한 GitHub CLI의 만료형 OAuth 공개 미리보기는 이 경계를 드러낸다. 팀이 먼저 정리할 대상은 로그인 횟수보다 토큰이 흘러가는 경로다.

확인된 변화: 선택적으로 시작하는 갱신형 인증

공식 발표에 따르면 v2.103.0부터 gh auth login --expiring으로 참여할 수 있다. gh는 만료형 access token과 순환하는 refresh token을 저장하고 필요할 때 갱신한다. 기존 로그인과 수동 토큰은 그대로 유지되며, 지원하지 않는 서버는 비만료 방식으로 돌아갈 수 있다. github.com·ghe.com과 GHES 3.23 이상이 지원 범위다. 따라서 옵션을 전달했다는 기록만으로 실제 단기 토큰 사용을 단정하지 말고 gh auth status에서 상태를 확인해야 한다.

운영 해석: 갱신은 복사한 문자열까지 전파되지 않는다

발표는 gh auth token 결과를 한 번 저장해 나중에 재사용하는 스크립트가 만료로 실패할 수 있다고 경고한다. 외부 소비자는 필요할 때 새로 읽어야 한다. 여기서 팀이 던질 질문은 단순하다. 현재 작업이 gh를 다시 호출하는가, 아니면 시작할 때 얻은 문자열을 계속 쓰는가? 장시간 실행하는 작업에서는 작업 시작 시점의 정상 응답이 나중 단계의 유효성을 보증하지 않는다. refresh token까지 유출되면 access token의 짧은 수명만으로 위험이 끝난다고 가정해서도 안 된다.

팀이 적용할 점검 순서

먼저 사용하는 gh 버전과 호스트를 기록하고, 토큰을 파일·환경변수·확장 프로그램에 복사하는 경로를 찾아보자. 이는 토큰 값을 수집하라는 뜻이 아니다. 소유 도구와 재조회 시점만 남긴다. 이어 비운영 환경에서 시작 직후와 시간이 지난 뒤 동일한 읽기 작업을 비교하고, 실패 시 만료·권한·네트워크 오류를 분리한다. HTTPS git에는 공식 안내의 gh auth setup-git과 git 2.46 이상 권고를 검토한다. 실제 팀 설정 변경은 별도 검토하며, 이 글은 독자의 로그인이나 설정을 바꾸지 않는다.

도입을 미뤄야 하는 경로도 있다

무조건 전환하는 것이 목표는 아니다. 오래 유효한 토큰을 전제로 만든 외부 도구가 있다면 공식 발표도 해당 흐름의 참여를 보류하라고 안내한다. 이를 무기한 방치할 이유로 삼기보다 담당자·호출 경로·수정 기한을 남기는 편이 낫다. 일반 개발자 OAuth와 CI의 GITHUB_TOKEN을 같은 인증으로 묶어 교체하지 말자. 하나의 플래그가 모든 자동화의 권한·수명·폐기를 통일해 주지는 않는다. 공개 미리보기이므로 지원 범위와 사용 중인 버전의 도움말도 다시 확인한다.

개발자 대화에서 자주 쓰는 “로그인 유지”라는 표현을 이 글에서는 두 질문으로 나눈다. 도구가 갱신할 수 있는가, 소비자가 갱신된 값을 받는가? 커뮤니티 전체가 겪는 장애 비율이나 도입 성과를 측정했다는 뜻은 아니다. 다음 점검에서 토큰 값 대신 소비 경로 하나를 도식으로 남겨보자. 캐시 소유자와 갱신 경계가 보이면 전환 여부를 판단하고 장애를 재현하기가 쉬워진다.

공식 출처와 추가 확인

GitHub Changelog · Expiring OAuth preview

GitHub Docs · CLI authentication

팀 점검 문서에는 비밀값 없이 버전·호스트·캐시 소유자·재조회 시점·검증 결과만 기록하자.