GitHub CLI(`gh`)는 GitHub의 기능을 터미널로 옮겨놓은 작은 편의 도구처럼 보인다. 실제 README를 따라가면 역할은 더 넓다. pull request와 issue를 현재 코드를 다루는 자리 옆에 두고, 개발자가 작업 맥락을 유지한 채 협업 상태까지 확인하게 한다. `gh pr status` 같은 명령은 브라우저를 덜 열게 만드는 데서 끝나지 않는다. GitHub의 작업 객체를 로컬 개발 흐름에 포함시키는 방식이다.
설계의 방향은 과거의 `hub`와 비교하면 분명해진다. `hub`가 `git`의 프록시였다면 `gh`는 독립 실행형 도구다. 이 차이는 명령어 이름의 문제가 아니다. GitHub를 코드 저장소에 붙은 부가 기능으로 다루는 대신, PR과 이슈를 별도의 운영 단위로 가져온다. GitHub.com뿐 아니라 Enterprise Cloud와 Enterprise Server 2.20+를 지원하고 macOS, Windows, Linux에서 실행되는 것도 같은 방향에 놓인다. 개인 개발 환경과 조직의 파이프라인 사이를 넓게 잇는 선택이다.
README에서 더 중요한 변화는 코딩 에이전트와의 연결이다. `gh skill install cli/cli gh --scope user`로 에이전트가 `gh`를 다루는 skill을 설치하고, 릴리스가 나오면 `gh skill update gh`로 갱신할 수 있다. 사람이 터미널에서 PR을 조회하는 수준을 넘어, 에이전트가 GitHub의 협업 객체를 읽고 작업하는 인터페이스가 된다. 자동화가 깊어질수록 편리함과 통제 사이의 간격도 함께 커진다.
그래서 배포 파일의 출처 검증이 중요해진다. `gh`는 v2.50.0부터 Build Provenance Attestation을 만들고 Sigstore 기반 PKI로 서명한다. v2.93.0부터는 릴리스가 immutable release로 발행된다. 이미 `gh`가 설치돼 있다면 `gh at verify -R cli/cli`로 파일의 attestation을 확인할 수 있고, `cosign verify-blob-attestation`을 사용해도 된다. “실행된다”와 “운영 환경에 넣어도 믿을 수 있다”를 분리해서 확인하는 흐름이다.
GitHub Actions 호스팅 러너에 CLI가 미리 설치되고 매주 업데이트된다는 점도 양면적이다. 시작은 빠르지만 특정 버전에 의존하는 워크플로라면 직접 설치 단계를 넣어야 한다. 이 작은 caveat가 `gh`를 데모용 도구와 운영 도구로 가르는 지점이다. `gh`는 터미널에서 GitHub를 호출하는 명령어 모음이 아니라, 코드 변경부터 협업 상태, 에이전트 작업, 배포 바이너리의 신뢰성까지 한 파이프라인으로 이어 붙이는 도구다.