GitHub CLI 업데이트가 갑자기 막힌 이유: 서명 키 교체의 두 단계

9월 15일 나온 GitHub CLI 2.101.0은 기능보다 패키지 서명 키 공지가 더 중요합니다. 공식 APT·RPM 저장소와 개별 RPM 패키지는 이제 새 PGP 키 하나로만 서명됩니다. 2026년 4월 8일 전에 공식 Linux 저장소로 gh를 설치했고 키링을 갱신하지 않았다면, 프로그램이 고장 난 것이 아니라 패키지 관리자가 새 서명을 신뢰하지 못해 업데이트를 거부할 수 있습니다.

이 문제는 모든 gh 사용자에게 생기지 않습니다. macOS와 Windows, Homebrew, GitHub Releases의 바이너리, 소스 빌드는 해당 PGP 키를 쓰지 않습니다. Linux에서도 4월 8일 이후 공식 설치 절차를 다시 실행했다면 키링에 새 키가 이미 들어 있을 가능성이 큽니다. 중요한 것은 운영체제 이름보다 "어떤 배포 경로를 썼고, 그 경로의 신뢰 저장소가 언제 갱신됐는가"입니다.

무엇이 바뀌었나

기존 키의 지문은 2C6106201985B60E6C7AC87323F3D4EA75716059이고, 만료 시각은 2026년 9월 5일 12:44:10 UTC였습니다. 새 키의 지문은 7F38BBB59D064DBCB3D84D725612B36462313325입니다. GitHub는 4월 8일 두 키가 함께 든 키링을 배포하기 시작했고, 8월에는 APT 저장소를 두 키로 서명하는 전환 단계를 거쳤습니다. 9월 8일 병합된 PR #14197은 저장소 설정과 배포 워크플로를 새 키 전용으로 바꿨습니다.

실제 2.101.0 태그의 script/distributions에는 지원 배포판마다 새 지문만 SignWith로 지정돼 있습니다. script/rpmmacros의 %_gpg_name도 새 지문을 가리키고, 배포 워크플로의 repomd.xml 서명 명령도 같은 키를 명시합니다. 릴리스 노트만 바뀐 것이 아닙니다. 서명을 만드는 실행 경로가 함께 바뀌었습니다.

GitHub CLI 저장소 서명 키가 키링 선배포, 구키와 신키의 겹치는 서명, 신키 단독 서명 순서로 전환된 흐름

그림 1. 서명 키 교체는 신키를 먼저 배포하고 겹치는 검증 기간을 둔 뒤 단독 서명으로 넘어간다. 출처: github.com/cli/cli/issues/13118.

왜 "새 키를 서버에 올렸다"로 끝나지 않나

PGP 저장소 서명은 발행자와 클라이언트가 같은 전환 상태를 공유해야 작동합니다. 서버가 새 키로 서명해도 클라이언트 키링에 새 공개키가 없으면 검증은 실패합니다. 반대로 클라이언트가 새 키를 미리 신뢰해도 서버가 여전히 예전 키로만 서명하는 동안에는 기존 서명을 계속 검증할 수 있어야 합니다.

그래서 이번 교체는 겹치는 기간을 뒀습니다. 먼저 공개 키링에 구키와 신키를 함께 넣고, APT 메타데이터를 두 키로 서명했습니다. 클라이언트가 새 키를 받아갈 시간을 준 뒤 구키가 만료된 다음 신키 단독 서명으로 바꿨습니다. 이 순서를 뒤집으면 최신 클라이언트만 업데이트되고 오래된 이미지나 서버는 한꺼번에 멈출 수 있습니다.

GitHub 저장소의 신키 서명을 패키지 관리자가 로컬 키링으로 확인한 뒤에만 업데이트를 허용하는 신뢰 체인

그림 2. 서버 서명과 로컬 키링이 연결되지 않으면 패키지 관리자는 업데이트를 거부한다. 출처: github.com/cli/cli/blob/v2.101.0/docs/install_linux.md.

저는 공식 키링을 다시 내려받아 확인했습니다. SHA-256은 공식 설치 문서의 값 6084d5d7bd8e288441e0e94fc6275570895da18e6751f70f057485dc2d1a811b와 일치했고, 키링에는 구키와 신키의 기본 지문이 모두 있었습니다. 현재 APT Release.gpg와 RPM repomd.xml.asc의 issuer fingerprint는 신키 하나였습니다. 이 재계산은 2.101.0 공지가 설명한 최종 상태와 맞습니다.

영향 범위부터 좁혀라

업데이트 실패가 보인다고 곧바로 키 파일을 덮어쓰면 원인을 놓칠 수 있습니다. 먼저 설치 경로를 구분해야 합니다.

  • 공식 APT 또는 RPM 저장소를 2026년 4월 8일 전에 등록했고 이후 키링을 갱신하지 않았다면 영향을 받을 수 있습니다.
  • 4월 8일 이후 공식 설치 절차를 사용했다면 현재 키링에 두 키가 들어 있어야 합니다.
  • Homebrew, Windows 패키지, 릴리스 바이너리, 소스 빌드는 이 저장소 키 교체의 대상이 아닙니다.
  • 오래된 Docker 베이스 이미지도 별도 점검 대상입니다. 이미지 안에 예전 저장소 설정과 키링이 고정돼 있으면, 나중 레이어의 apt update가 갑자기 실패합니다.
오래된 공식 APT와 RPM 저장소 및 Docker 이미지는 점검 대상으로, macOS Windows Homebrew 릴리스 바이너리는 직접 영향이 아닌 것으로 나눈 표

그림 3. 이번 교체의 직접 영향은 운영체제 전체가 아니라 공식 Linux 저장소의 오래된 키링에 한정된다. 출처: github.com/cli/cli/issues/13118.

Debian·Ubuntu에서는 signed-by=가 가리키는 실제 키링 경로를 먼저 찾고 gpg --show-keys로 두 기본 지문을 확인하는 편이 안전합니다. 경로가 /etc/apt/keyrings/일 수도 있고, 예전 설치라면 /usr/share/keyrings/일 수도 있습니다. RPM 계열은 설치 당시 가져온 키가 로컬 RPM 키링에 남기 때문에, 배포판별 공식 절차로 저장소 설정을 다시 받고 새 지문을 확인해야 합니다.

자동화에서 놓치기 쉬운 지점

CI와 Docker에서는 "키링 다운로드"와 "패키지 목록 갱신"을 서로 다른 레이어로 나누는 경우가 많습니다. 오래 캐시된 앞 레이어가 예전 키링을 들고 있으면, 뒤 레이어만 다시 실행될 때 검증이 실패합니다. 해결은 검증을 끄는 것이 아니라 apt update보다 앞에서 공식 키링을 갱신하고, 내려받은 파일의 SHA-256과 지문을 확인하는 것입니다.

키링 URL이 HTTPS라고 해서 내용 검증이 끝난 것도 아닙니다. 공식 문서에 고정된 SHA-256과 실제 파일 해시를 비교하고, gpg --show-keys로 예상 지문을 확인해야 합니다. 저장소 설정의 signed-by가 다른 파일을 가리키면 올바른 키링을 내려받고도 실패합니다. RPM 계열도 패키지 관리자가 보여 주는 가져오기 지문을 공식 값과 대조해야 합니다.

2024년에도 같은 구키의 만료 때문에 설치와 업데이트가 중단됐습니다. 당시에는 키 만료일을 연장하는 응급 조치를 썼고, GitHub CLI 팀은 담당자가 바뀌며 이 시한에 대한 조직 지식이 사라졌다고 적었습니다. 이번에는 신키를 미리 배포하고 겹치는 서명 기간을 둔 뒤 단독 서명으로 넘어갔습니다. 운영 교훈은 단순합니다. 만료일 알림만 두지 말고, 새 키 배포와 이중 서명, 클라이언트 갱신률, 단독 서명 전환을 각각 검증해야 합니다.

실무 체크리스트

  1. gh가 어떤 경로로 설치됐는지 확인합니다.
  2. 공식 APT·RPM 저장소라면 실제 키링 또는 RPM 키 저장소에서 신키 지문을 찾습니다.
  3. 키링을 갱신할 때 공식 URL과 SHA-256을 함께 검증합니다.
  4. APT의 signed-by 경로가 갱신한 파일과 같은지 확인합니다.
  5. Dockerfile에서는 패키지 목록 갱신보다 앞에서 키링을 교체하고 캐시가 오래된 레이어를 다시 빌드합니다.
  6. 검증을 끄거나 --nogpgcheck로 우회하지 않습니다. 실패는 공급망 경계가 작동하고 있다는 신호입니다.

이번 변경의 핵심은 새 지문 자체보다 전환 순서입니다. 발행자는 두 키가 공존하는 기간을 만들고, 소비자는 실제 신뢰 저장소가 새 키를 받았는지 확인해야 합니다. 둘 중 한쪽만 끝나면 릴리스는 정상인데 업데이트만 실패하는 이상한 상태가 남습니다.

참고 자료

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기