GitHub 다운로드 속도가 왜 갑자기 느려졌을까?

오늘 봤던 문제: 1KB/s 수준의 다운로드 속도

Reddit r/github에 올라온 글을 확인해본 결과, 사용자들이 GitHub에서 저장소를 받을 때 매우 느린 속도를 경험하고 있다는 보고가 있습니다. 게시글의 제목이 “Microsoft, are you going broke?”라는 다소 신랄한 톤으로 시작되는 것을 보면, 단순한 일시적 지연이 아니라 사람들이 실질적인 불편을 느끼고 있다는 신호입니다.

이것이 중요한 이유는 단순히 “인터넷이 느리다”는 차원이 아니기 때문입니다. GitHub은 전 세계의 개발자, 특히 자동화 인프라를 운영하는 1인 팀들에게 매일같이 코드를 받아오고 배포하는 중추 역할을 합니다. n8n 같은 자동화 도구로 워크플로우를 만들 때도, CI/CD 파이프라인 속 각 단계마다 GitHub과 통신하는 구간이 있습니다. 그 구간이 느려지면 전체 자동화 체인이 영향을 받습니다.

이 문제가 정말 인프라 문제인가, 아니면 다른 원인인가?

35년을 가르치며 지켜본 것 중 하나는, 대규모 서비스의 성능 저하가 나타날 때 표면적 원인과 실제 원인이 다를 수 있다는 점입니다. 원문을 살펴본 결과 게시글에는 속도 측정 이미지만 있고, GitHub 공식 상태 페이지에서 장애를 인정했는지, 아니면 지역별·네트워크별 편차인지는 명확하지 않습니다.

이렇게 되면 여러 가능성이 동시에 열립니다. 첫째, 정말로 GitHub의 전역 CDN이나 핵심 인프라에 문제가 있을 수 있습니다. 둘째, 특정 지역이나 ISP의 라우팅 문제일 가능성도 있습니다. 셋째, 사용자 측의 네트워크 설정이나 VPN 사용 여부도 영향을 미칠 수 있습니다. 사람들이 Twitter나 Reddit에서 같은 증상을 동시 다발적으로 보고할 때, 그것이 반드시 중앙 서버의 문제를 의미하는 것만은 아닙니다.

자동화 운영자들에게 이것이 시사하는 바

Microsoft가 2018년 GitHub을 인수한 이후, 과거보다 훨씬 더 엄격한 SLA(서비스 수준 약정)와 모니터링 체계가 갖춰졌습니다. 동시에 무료 사용자를 포함한 사용량도 기하급수적으로 늘었습니다. 이 두 가지가 충돌할 때 어떤 일이 생기는가 하는 것은 기술 조직이라면 자주 마주치는 문제입니다.

자동화 인프라를 직접 n8n이나 유사 도구로 만들어 운영하는 분들이라면, 외부 서비스에 대한 의존도를 다시 한 번 검토해볼 시점입니다. GitHub Actions를 자동화 파이프라인의 핵심으로 삼고 있다면, 그것이 언제든 느려질 수 있다는 가정 위에서 설계를 다시 해봐야 할 수도 있습니다. 타임아웃(timeout) 설정, 재시도 로직, 대체 경로(fallback) 준비 같은 것들이 선택이 아니라 필수가 되는 상황입니다.

또한 이 문제는 단순한 기술 문제를 넘어, 대규모 클라우드 서비스에 얼마나 많은 조직이 의존하고 있는가 하는 구조적 질문으로도 이어집니다. 한 곳의 인프라 지연이 전 세계 개발팀의 배포를 지연시킬 수 있다는 것은, 기술 생태계의 단점과 편리함이 동전의 양면이라는 것을 보여줍니다.

계속 지켜봐야 할 지점

이 문제가 Microsoft의 인프라 투자 부족에서 비롯되었는지, 아니면 예상 외의 트래픽 급증 때문인지, 혹은 특정 지역의 네트워크 이슈인지에 따라 해석이 완전히 달라집니다. 공식 상태 공지나 추가 커뮤니티 보고가 있을 때까지는 명확한 판단이 어려운 상황입니다.

이 이슈가 실제로 어떻게 진행되었고, 커뮤니티에서는 어떤 해결책을 찾아냈는지는 다음 편에서 살펴보겠습니다.