깃허브 액션 8시간 44분 장애 끝에 복구...웹훅 85% 차단하며 밀린 작업 처리했다...한국시간 7일 오전 0시 22분 시작, 오전 9시 6분 완화 선언, 러너에 만료된 작업이 배정되는 오류가 원인, 페이지스·코파일럿 서비스도 함께 영향

[한국정보기술신문] 세계 최대 소프트웨어 개발 협업 플랫폼 깃허브(GitHub)의 자동화 서비스 '깃허브 액션(GitHub Actions)'이 8시간 44분 동안 장애를 일으킨 끝에 복구됐다. 깃허브는 한국시간 7일 오전 9시 6분(협정세계시 7일 0시 6분) 자사 상태 페이지에 성능 저하가 완화됐으며 안정성 확인을 위해 모니터링 단계에 들어갔다고 공지했다. 이번 장애로 전 세계 개발자들이 코드를 올릴 때마다 자동으로 실행되는 빌드와 테스트 작업이 무더기로 실패하거나 대기 상태에 머물렀다.

깃허브 액션은 개발자가 코드 저장소에 코드를 올리면 미리 정해둔 절차에 따라 프로그램을 자동으로 만들고 검사한 뒤 서비스에 반영하는 기능이다. 이런 자동화 방식을 지속적 통합·지속적 배포(CI/CD)라고 부른다. 사람이 손으로 하던 반복 작업을 대신하기 때문에 많은 기업이 소프트웨어 개발 과정의 핵심 설비로 쓰고 있다.

깃허브가 공개한 시간대별 기록을 보면 이상 징후는 한국시간 7일 오전 0시 22분(협정세계시 6일 오후 3시 22분)에 처음 감지됐다. 깃허브는 액션의 성능 저하 신고를 접수해 조사에 들어갔다고 알렸고, 19분 뒤에는 액션의 가용성이 떨어진 상태라고 상황을 한 단계 올려 공지했다.

오전 0시 45분 공지에서는 피해 범위가 구체적으로 드러났다. 일부 워크플로가 아예 시작되지 못하거나 실행 도중 실패했고, 액션의 REST 응용프로그램 인터페이스(API)에 보낸 요청 일부도 오류를 냈다. 일부 이용자는 예상하지 못한 사용량 제한에 걸리기도 했다. 깃허브는 이 시점에 장애의 원인 지점을 확인하고 완화 작업에 착수했다고 밝혔다.

이후에도 상황은 쉽게 나아지지 않았다. 오전 3시 46분 공지에서 깃허브는 복구가 예상보다 오래 걸리고 있다고 인정했다. 깃허브가 관리하는 호스티드 러너의 처리 용량이 부족해 대기 중인 작업이 시작되지 못하고 제한 시간을 넘겨 종료되는 일이 이어졌다. 이용자가 직접 운영하는 셀프 호스티드 러너에서도 등록 과정에서 오류나 사용량 제한이 발생했다. 러너는 워크플로에 정의된 작업을 실제로 실행하는 서버를 말한다.

깃허브가 지목한 핵심 원인은 이미 유효하지 않은 작업이 러너에 계속 배정되는 문제였다. 한국시간 7일 오전 5시 34분 공지에서 깃허브는 남은 영향이 이미 사라진 작업을 붙잡고 재시도를 반복하는 러너로 좁혀졌다고 설명했다. 이 현상은 깃허브가 제공하는 러너와 이용자가 직접 운영하는 러너 모두에서 나타났다.

깃허브는 오전 6시 30분 공지에서 해당 문제를 해결하기 위한 변경 사항을 배포하고 있다고 밝혔고, 오전 7시 18분에는 수정이 적용되면서 작업 완료율이 개선되고 있다고 알렸다. 실행이 시작된 워크플로의 성공률은 이 시점에 97%까지 올라갔다. 표준 러너와 대형 러너에서도 밀려 있던 작업이 처리되기 시작했다.

이번 장애 대응에서 눈에 띄는 조치는 웹훅 처리량을 인위적으로 줄인 점이다. 웹훅은 코드를 올리거나 병합 요청을 보내는 등의 사건이 발생했을 때 이를 다른 시스템에 자동으로 알려 다음 동작을 실행시키는 방식이다. 깃허브는 복구 작업을 돕기 위해 웹훅을 조절해 전체의 약 15%만 처리했다. 나머지 85%가량은 즉시 전달되지 않아, 코드를 올려도 새 워크플로가 시작되지 않는 상황이 이어졌다.

이 조치는 밀려 있는 작업을 먼저 해소하기 위한 선택이었다. 오전 5시 34분 기준으로 대기열에 들어간 작업 중 약 65%가 성공했는데, 이는 장애 초기 30~40%까지 떨어졌던 수치에서 회복된 결과다. 깃허브는 오전 8시 13분 공지에서 성공률이 99%에 이르렀고 호스티드 러너 배정을 위한 전역 대기열도 거의 소진됐다고 밝혔다. 밀린 작업 요청을 더 빠르게 처리하기 위한 추가 변경도 배포됐다.

깃허브가 상태 페이지에 남긴 공지를 한국시간 기준으로 정리하면 △0시 22분 성능 저하 조사 시작 △0시 41분 액션 가용성 저하 공지 △0시 45분 원인 지점 확인 및 완화 착수 △1시 33분 액션과 페이지스 동시 가용성 저하 △3시 46분 복구 지연 인정 △5시 34분 원인을 러너 재시도 문제로 특정 △6시 30분 수정 배포 시작 △7시 18분 성공률 97% 회복 △8시 13분 성공률 99% 도달 △9시 1분 대기열 소진 △9시 6분 모니터링 단계 전환 순이다. 공지는 사건이 진행되는 동안 20여 차례 이어졌다.

장애는 액션에 머무르지 않았다. 정적 웹사이트 호스팅 서비스인 깃허브 페이지스는 한국시간 7일 오전 0시 53분 성능 저하 상태로 표시됐다가 오전 1시 19분 정상으로 돌아왔으나, 오전 1시 27분 다시 성능 저하 상태가 됐다. 깃허브는 오전 1시 33분 공지에서 액션과 페이지스 모두 가용성이 떨어진 상태라고 밝혔다. 페이지스는 사이트를 공개하는 과정에서 액션을 사용하기 때문에 영향을 함께 받은 것으로 보인다.

인공지능 개발 도구인 코파일럿 코드 리뷰와 코파일럿 코딩 에이전트에서도 실패나 지연이 나타났다. 다른 플랫폼의 저장소를 깃허브로 옮길 때 쓰는 깃허브 엔터프라이즈 임포터를 이용한 이전 작업은 복구를 지원하기 위해 아예 중단됐다. 깃허브는 오전 9시 1분 공지에서 페이지스와 코파일럿 관련 기능이 회복세를 보이고 있다면서도, 엔터프라이즈 임포터를 이용한 이전 작업은 예방 차원에서 계속 중단해 둔다고 밝혔다.

깃허브는 한국시간 7일 오전 9시 1분 시스템 전반의 대기열이 모두 비워졌고 새 작업이 정상적으로 처리되고 있다고 알렸다. 셀프 호스티드 러너가 작업을 가져오지 못하던 문제에 대한 수정도 전면 적용됐고, 웹훅으로 시작되는 액션 워크플로 처리량도 원래 수준으로 회복됐다.

이어 오전 9시 5분에는 액션과 페이지스에 영향을 준 성능 저하가 완화됐다고 공지했고, 1분 뒤 사건 상태를 모니터링 단계로 바꿨다. 상태 페이지에는 이번 사건의 영향을 받은 서비스로 액션과 페이지스가 명시됐다.

이번 사건은 개발 자동화 기반이 한곳에 집중돼 있을 때 생기는 위험을 다시 보여줬다. 깃허브 액션에 배포 절차를 맡긴 조직은 장애가 이어지는 동안 코드 검증과 배포를 사실상 멈출 수밖에 없다. 복구 과정에서 웹훅을 조절하는 방식이 동원된 점도 눈여겨볼 대목이다. 서비스 자체가 살아나더라도 밀린 작업이 정리되기까지는 이용자가 체감하는 정상화가 늦어질 수 있기 때문이다.

국내 개발 현장에서도 깃허브 액션을 배포 자동화에 활용하는 곳이 적지 않아 야간 시간대 작업에 차질이 있었을 것으로 보인다. 이번 장애가 이어진 시간대는 한국시간으로 자정부터 오전 9시 사이여서, 정기 배포를 새벽에 예약해 둔 조직일수록 영향을 받았을 가능성이 있다.

깃허브는 모니터링 단계에서 안정성이 유지되는지 확인하고 있다. 장애의 근본 원인과 재발 방지 대책을 담은 상세 보고서는 아직 공개되지 않았다.