--- title: "깃허브 액션, 내부 데이터베이스 마이그레이션 여파로 4시간 지연" published: 2026-05-26T11:42:58.000Z canonical: https://jeff.news/article/3252 --- # 깃허브 액션, 내부 데이터베이스 마이그레이션 여파로 4시간 지연 깃허브에서 2026년 5월 12일 13:41부터 17:43 협정세계시까지 일부 서비스 처리 지연이 발생했음. 내부 데이터베이스 마이그레이션으로 복제 지연이 생겼고, 작업 큐에 쌓이는 요청을 처리할 워커가 부족해진 게 원인이었음. - 깃허브에서 2026년 5월 12일 13:41부터 17:43 협정세계시까지 약 4시간 동안 일부 서비스 처리 지연이 발생함 - 영향받은 쪽은 코드 스캐닝, CodeQL 액션 워크플로, 알림, 웹훅, 슬랙 연동 웹훅 쪽이었음 - 단순히 화면이 안 뜨는 장애라기보다는, 작업이 큐에 쌓이고 처리 완료가 늦어지는 형태에 가까웠음 - 가장 크게 튄 숫자는 코드 스캐닝 쪽임 - 코드 스캐닝 검사 실행의 53%가 완료까지 15분 넘게 걸렸음 - CodeQL 액션은 대기 상태에 오래 머물거나, 시간 초과 때문에 실패할 수 있는 상태였음 - 알림과 연동 계열도 같이 밀렸음 - 깃허브 알림은 평균 22분 늦게 전달됐음 - 슬랙 연동 웹훅은 평균 20분 지연됐고, 일반 웹훅도 한때 성능 저하가 확인됐음 > [!IMPORTANT] > 원인은 내부 데이터베이스 마이그레이션 중 발생한 복제 지연이었음. 이 지연 때문에 높은 작업 유입량을 처리할 워커 용량이 부족해졌고, 여러 공유 큐가 같이 밀린 구조임. - 복구 방식은 꽤 현실적임. 병목이 큐 처리였으니 워커를 늘려서 밀린 작업을 빼냈음 - 16:18 협정세계시쯤 대부분의 지연이 큐 서비스와 관련됐다고 파악했고, 스케일 아웃 초기 신호가 좋아졌다고 공지함 - 16:28에는 웹훅이 정상 동작한다고 했고, 16:59에는 CodeQL이 완전히 복구됐다고 알림 - 17:43에는 모든 서비스가 정상 처리 시간으로 돌아왔다고 마무리함 - 재발 방지책으로는 고사용량 공유 큐 일부에 전용 워커 풀을 만들겠다고 함 - 핵심은 “다 같이 쓰는 큐”에서 특정 작업군이 밀릴 때 다른 서비스까지 같이 흔들리는 걸 줄이겠다는 방향임 - CI, 보안 검사, 알림, 외부 연동이 한 큐 구조에 강하게 묶이면 장애 반경이 생각보다 커질 수 있다는 얘기임 --- ## 기술 맥락 - 이번 장애의 핵심은 깃허브 액션 자체가 망가졌다기보다, 비동기 작업 처리 계층이 밀렸다는 점이에요. 코드 스캐닝이나 웹훅 같은 기능은 사용자가 누른 즉시 끝나는 일이 아니라 큐에 작업을 넣고 워커가 처리하는 구조라서, 큐가 밀리면 겉으로는 여러 기능이 동시에 느려진 것처럼 보여요. - 원인으로 나온 복제 지연은 데이터베이스 마이그레이션 때 꽤 까다로운 변수예요. 읽기 복제본이나 내부 처리 시스템이 최신 상태를 제때 못 따라오면, 작업을 안전하게 처리하기 위해 기다리거나 재시도하는 흐름이 늘어나고, 그 결과 워커가 감당해야 할 부하가 커지거든요. - 깃허브가 워커를 늘려 복구한 건 병목 지점이 처리량이었다는 뜻이에요. 다만 워커만 계속 늘리는 방식은 비용과 운영 복잡도가 커지기 때문에, 사용량이 큰 공유 큐를 전용 워커 풀로 분리하려는 후속 조치가 나온 거예요. - 한국 개발팀 입장에서도 배울 게 있는 장애예요. 배포 파이프라인, 보안 스캔, 알림, 외부 웹훅이 같은 큐 인프라를 공유한다면, 하나의 마이그레이션이나 트래픽 급증이 여러 개발 워크플로를 동시에 늦출 수 있거든요. ## 핵심 포인트 - 코드 스캐닝 검사 실행의 53%가 완료까지 15분 넘게 걸렸음 - 알림은 평균 22분, 슬랙 연동 웹훅은 평균 20분 지연됐음 - 깃허브는 워커를 증설해 복구했고, 고사용량 공유 큐에는 전용 워커 풀을 만들 계획임 ## 인사이트 장애 자체보다 흥미로운 포인트는 병목이 코드 실행이 아니라 큐와 워커 용량에서 터졌다는 점임. 대형 플랫폼에서 내부 마이그레이션 하나가 코드 스캐닝, 알림, 웹훅까지 같이 흔드는 전형적인 공유 인프라 리스크 사례로 볼 만함.