GitHub 658개 리포지토리 머지 큐 오류 발생
원제: The Silent Merge Queue Corruption That Hit 658 GitHub Repos
왜 중요한가
자동화된 코드 통합 시스템의 정확성 검증과 기능 플래그 설계의 중요성을 보여주는 사례
2026년 4월 23일 GitHub에서 불완전한 기능 플래그로 인해 658개 리포지토리가 손상되는 사고가 발생했다. 머지 큐의 스쿼시 머지 기능에서 잘못된 커밋이 생성되어 이전 작업이 조용히 되돌려졌으며, 4시간 38분간 지속되었다.
GitHub의 머지 큐는 코드가 기본 브랜치에 도달하기 전 마지막 보호 단계를 담당한다. 검토와 CI를 통과한 풀 리퀘스트들을 그룹화하고 통합 상태를 재테스트한 후 순차적으로 반영한다. 이 과정에서 큐가 생성하는 커밋은 검증된 내용과 정확히 일치해야 한다는 중요한 전제가 있다. 4월 23일 GitHub이 Pull Requests 서비스에 배포한 변경사항은 머지 큐 ref 업데이트 중 머지 베이스 계산을 위한 새로운 코드 경로를 도입했다. 이는 미출시 기능을 위해 기능 플래그 뒤에 숨겨져 있어야 했지만, 게이트가 불완전했다. 특히 두 개 이상의 풀 리퀘스트가 있는 스쿼시 방식 머지 큐 그룹에서 새 경로가 의도치 않게 실행되었다. 스쿼시 머지 그룹은 최종 3-way 머지를 위한 올바른 베이스 선택에 의존하는데, 잘못된 베이스로 인해 GitHub은 기본 브랜치를 발전시키는 것처럼 보이면서 실제로는 이미 그룹에 머지된 변경사항을 조용히 삭제하는 커밋을 생성했다. Git 히스토리는 여전히 존재했고 커밋 객체도 구조적으로 유효했지만, 브랜치 끝이 더 이상 큐가 반영하려던 코드를 나타내지 않는 의미적 손상이 발생했다. 3.5시간 동안 이 오류는 GitHub의 자동 모니터링에서 감지되지 않았다. 서비스가 여전히 작동하고 있었기 때문에 요청률, 지연시간, 오류가 문제를 나타내지 않았다. 첫 번째 유용한 신호는 고객들로부터 왔다. 19:38 UTC에 지원 문의가 증가한 후 GitHub이 문제를 인식하고 20:43 UTC에 수정사항을 강제 배포했다. 최종 영향은 658개 리포지토리와 2,092개 풀 리퀘스트였다.