GitHub 장애가 멈춘 것은 저장소만이 아니다

에이전트가 코드를 써도 다음 단계가 멈출 수 있다

수정은 끝났는데 PR을 열 수 없다. PR을 열어도 검증 결과가 오지 않는다. 여러 도구가 이어진 작업에서는 모델이 정상이어도 전체 흐름이 멈춘다. 8월 18일 브리핑에서 언급한 GitHub 장애는 이런 연결을 돌아보게 했다.

당시 관측과 뒤늦은 원인 분석

GitHub는 8월 20일 공개한 8월 17일 장애 후속 글에서 최근 두 장애를 핵심 구성요소의 용량 문제로 설명했다. 코드나 설정 변경이 원인이 아니었다고 밝히며 용량 증설과 병목 해소 방향을 제시했다.

이 원인 설명은 8월 18일 당시 브리핑 뒤에 나온 자료다. 따라서 여기서는 후속 확인 내용으로 구분한다. 장애가 있다는 관측만으로 초기 원인을 추측하는 것과 공식 분석을 반영하는 일은 다르다.

복구는 마지막으로 확인된 상태에서 시작한다

에이전트 작업은 코드 변경, 로컬 테스트, 원격 저장소, PR, CI로 이어진다. 중간에 멈췄을 때 어느 단계까지 끝났는지 알아야 한다.

복구하면서 처음부터 같은 작업을 다시 시키면 중복 변경이나 중복 PR이 생길 수 있다. 저장소의 상태와 원격 결과를 확인하고 다음 단계만 이어가는 방식이 적절하다. 이는 장애 사례에서 도출한 설계 제안이다.

공급자를 바꾸기 전에 중간 결과를 보존하자

대체 모델이 있어도 코드와 테스트 결과가 사라지면 이어받기 어렵다. 우선 복원에 필요한 결과를 남기자.

• 코드 변경과 테스트 결과를 로컬에서 보존한다.
• PR 생성이 실패하면 원격에서 이미 생성됐는지 확인한다.
• 재시도는 간격과 횟수를 제한한다.
• CI가 실행되지 않은 상태를 통과로 처리하지 않는다.

한 번의 장애로 플랫폼의 장기적인 안정성을 단정할 수는 없다. 대신 우리 작업 흐름이 외부 장애를 어떻게 견디는지는 점검할 수 있다.

오늘의 작은 방아쇠는 성공한 작업의 기록만큼, 멈춘 작업의 상태도 잘 남기는 일이다.

참고 자료

• The August 17 outage, and the work ahead — GitHub, 2026-08-20