GitHub: Git 작업 장애

 (githubstatus.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 2025년 11월 18일(UTC) GitHub에서 모든 Git 작업 실패가 발생해 SSH·HTTP 클라이언트와 원시 파일 접근이 중단됨
  • 문제의 원인은 내부 서비스 간 통신에 사용된 TLS 인증서 만료로 확인됨
  • GitHub은 만료된 인증서를 교체하고 영향을 받은 서비스를 재시작해 정상 복구를 완료함
  • 이후 인증서 만료 감시 알림을 강화하고, 수동으로 관리되는 인증서를 제거하는 자동화 전환 작업을 진행 중임
  • 이번 장애는 GitHub의 Git Operations와 Codespaces에 영향을 미쳤으며, 복구 후 모든 서비스가 정상 상태로 돌아옴

Git 작업 장애 보고서

  • 2025년 11월 18일 20:30~21:34 UTC 동안 GitHub에서 모든 Git 작업 실패가 발생

    • SSH 및 HTTP Git 클라이언트 상호작용, 원시 파일 접근이 모두 영향을 받음
    • Git 작업에 의존하는 제품들도 동일하게 장애를 겪음

  • 원인은 내부 서비스 간 통신에 사용된 만료된 TLS 인증서로 확인

    • GitHub은 인증서를 교체하고 영향을 받은 서비스를 재시작하여 문제를 해결
    • 서비스 재시작 후 완전한 복구가 이루어짐

  • GitHub은 향후 동일 문제 방지를 위해 인증서 만료 알림 시스템을 보강

    • 관련 영역의 다른 인증서에 대해서도 감시 및 자동화 점검을 수행 중
    • 남아 있는 수동 관리 인증서 제거와 자동화된 서비스 간 통신 체계 구축을 가속화

장애 진행 및 복구 단계

  • 20:39 UTC: Git 작업 및 Codespaces에서 가용성 저하 발생 보고
  • 20:52 UTC: 일부 Git HTTP 작업 실패 확인
  • 21:11 UTC: 모든 Git 작업 실패 현상 확인
  • 21:25 UTC: Codespaces의 가용성 저하 지속
  • 21:27 UTC: 원인 파악 완료, 수정 작업 진행
  • 21:36 UTC: 수정 배포 후 일부 복구 시작
  • 21:55 UTC: 모든 서비스 정상화, Codespaces 복구 완료
  • 21:56 UTC: Git 작업 정상 운영 확인
  • 21:59 UTC: 사건 종료 및 보고서 게시

영향받은 서비스

  • Git Operations
    • SSH 및 HTTP 기반 Git 작업 전반
  • Codespaces
    • 일시적 가용성 저하 발생

후속 조치

  • 인증서 만료 감시 및 자동화 강화
    • 만료 전 경고 알림 체계 확립
    • 모든 내부 인증서의 자동 갱신 프로세스 점검
  • 보안 및 운영 자동화 확대
    • 수동 인증서 관리 제거
    • 최신 보안 관행에 부합하는 자동화된 서비스 간 통신 구축

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 최근 주요 소프트웨어 시스템 장애가 너무 자주 발생하는 것 같아 걱정스러움
    작년에는 업무에 영향을 준 장애가 네 번뿐이었는데, 이번 분기에는 이미 네 번째임
    네트워크 소프트웨어의 복원력(resiliency) 이 점점 사라지고 있는 느낌임
    우리 팀은 모놀리식 구조지만 Redis, S3, 외부 통합 서비스 등 여러 의존성이 많음
    그래서 장애 조건을 문서화하고, 테스트와 배포 자동화를 강화하고, 클라우드 대신 VPS로 옮기는 등 단순화를 진행했음
    그 결과 시스템이 훨씬 안정적이고 예측 가능해졌음
    이런 지루하지만 필수적인 작업이 없었다면 복잡성만 늘어 더 취약해졌을 것임
    최근 겪은 장애는 AWS us-east-1, Azure Front Door, Cloudflare, 그리고 GitHub 장애였음

    • 결국 문제는 돈이라고 생각함
      고객들은 복원력이나 중복 인프라에 돈을 쓰려 하지 않음
      2008년 이후 10여 개 프로젝트를 해왔지만, 대부분 “그냥 운에 맡기자”는 태도였음
    • 동의함. 비용 절감이 결국 “장애가 와도 버티는 시스템을 만드는 법을 잊어버리는” 결과로 이어지고 있음
    • 일부러 도발적으로 말하자면, LLM 사용 증가도 이런 현상에 일조하고 있다고 봄

  • Git은 분산 버전 관리 시스템이라 GitHub가 없어도 작업은 가능함
    GitHub는 단지 편리한 허브일 뿐임

    • 단, GitHub Actions에 전적으로 의존한 회사라면 지금처럼 완전히 막힘
    • “이 에스컬레이터는 임시로 계단이 되었습니다. 불편을 드려 죄송합니다” 같은 상황임
    • 문제의 본질은 GitHub가 다운된 것이지, git 자체가 다운된 게 아님
    • GitHub가 없으면 다른 사람과의 협업 허브 기능을 잃게 됨
    • 지금 Hacker News에 있는 이유는, 일을 못 하고 있기 때문임

  • GitHub의 신뢰성 부족이 심각하다고 느낌
    CI/CD에 의존하는 사람들에게는 치명적임
    내부에서는 “우리 팀의 CI/CD가 깨졌다” 수준으로만 인식하고, “전 세계 절반이 멈췄다”는 관점이 부족함
    이런 사일로 문화와 “우리 문제 아님” 태도가 신뢰성 저하로 이어짐
    게다가 독점적 지위 덕분에 고객들도 어쩔 수 없이 참고 쓰는 구조임
    예전 Verio, Verisign에서도 봤던 “어차피 다른 데 못 가잖아”식 태도와 같음

  • 요즘 클라우드/SaaS 장애가 정말 더 자주 발생하는지 궁금함
    단순히 보도가 많아진 건지, 실제로 빈도가 늘어난 건지 모르겠음
    혹시 예산 삭감, 인력 감축, AI 도입, 과도한 성장 때문일까?

    • Microsoft는 GitHub를 Azure로 옮기면 해결될 거라고 믿는 듯함
    • 오래 써온 입장에서 보면 확실히 장애 빈도 증가를 체감함
      예전엔 1년에 한두 번이었는데, 요즘은 거의 매달, 최근엔 매주 수준임
    • 어떤 사람은 Cloudflare 장애 때 “AI 기반 코딩 문화”가 이런 문제를 키운다고 말했음
      작은 AI 코드 조각이 도미노식 장애를 유발할 수도 있음
    • Techrights 기사처럼,
      대규모 해고가 신뢰성 저하에 영향을 줬다고 봄
    • AI로 인한 FOMO(놓칠까 두려움) 때문에 프로젝트 일정이 더 빡빡해지고,
      결국 마지막 10%의 안정성 작업이 무시되는 것 같음

  • 푸시가 안 돼서 처음엔 내 문제인 줄 알았음
    그냥 오늘은 포기하고 내일 다시 하기로 함

    • 인증은 되는데 푸시가 안 돼서 정말 머리 쥐어뜯는 경험이었음
    • SSH 키를 새로 추가해도 소용없었음. 처음엔 이상한 에러만 나오더니 결국 “upstream unhealthy” 메시지
    • 나도 거의 환경을 처음부터 다시 세팅할 뻔했음

  • 오늘은 일하기 싫었는데, Cloudflare에 이어 GitHub까지 터지니 그냥 쉬라는 신호 같음

    • 미국 중심의 집중화된 기술 의존이 문제임
      더 많은 기술 주권과 분산화가 필요함

  • 지난 5년간 써본 서비스 중 GitHub가 가장 불안정했음
    GitLab이 더 나은지 궁금함. 이제 GitHub에 대한 신뢰는 거의 0임

    • 우리 회사는 GitLab을 셀프호스팅 중인데, Gitaly 서버가 자주 터짐
      대형 모노레포 환경이라 그런 듯하지만 확실히 확장성 문제 있음
    • GitLab은 기능은 많지만 통합이 엉성하고 완성도가 낮음
      그래도 리포지토리, CI/CD, 이슈, 위키를 한곳에 둘 수 있는 건 장점임
    • GitHub.com과 셀프호스팅 GitLab을 둘 다 쓰는데,
      GitHub는 클라우드 장애에 취약하고, GitLab은 자동 업그레이드 중단이 잦음
      각각 장단이 있음
    • GitLab은 느리고 무겁다는 게 문제임
      JS를 몇 MB씩 불러오느라 저속 네트워크에서는 페이지가 거의 안 뜸
    • 온프레미스에 두면 원하는 만큼 안정성 확보가 가능함

  • 긴급 상황에서는 GitHub 웹 UI에서 직접 파일을 수정할 수 있음
    하지만 GH Actions의 actions/checkout@v4는 현재 git 문제로 작동 안 함

    • 사실 어떤 SSH 가능한 호스트로도 git push/pull이 가능함
    • 우리도 프로덕션 핫픽스 중이었는데 막혀버림. 요즘 인터넷에 무슨 일이 있는지 모르겠음
    • CircleCI도 GitHub SSH 키 인식 문제로 git 작업 실패 중임
    • 이번엔 GitHub AI가 githubstatus.com을 확인하라고 알려줘서 의외로 도움이 됨
    • GitHub UI에서 브랜치 생성은 가능한지 궁금함

  • 지난 10년간 대기업과 스타트업을 오가며 본 공통 패턴이 있음
    스타트업 → 엔터프라이즈 고객 대응 → 복잡한 재설계 → 이상주의 → 이익 추구 → 제품 비대화 → 핵심 엔지니어 이탈 → 품질 저하
    이런 사이클이 클라우드 대기업들(AWS, Cloudflare, GCP 등)에도 반복됨
    내부적으로도 각 서비스가 작은 비즈니스 단위로 쪼개져 이익 중심으로 움직임
    결국 기초 인프라조차 이윤 압박으로 인해 약화되고 있음
    “AWS나 GCP는 너무 커서 망하지 않겠지”라는 믿음이 위험하다고 느낌

    • 동의함. 엔터프라이즈 대응 과정에서 제품이 복잡하고 둔해지는 건 필연적임
      하지만 초기 스타트업의 기술 부채와 보안 문제도 심각했음
      결국 대규모 성장 과정에서 시스템의 균열이 드러나는 건 자연스러운 일임

  • GitHub 상태 페이지에 “일부 사용자에게 문제가 발생할 수 있음”이라는 문구가 또 등장했음
    하지만 실제로는 HTTPS뿐 아니라 SSH 푸시도 전부 실패 중임

    • 상태 페이지 담당자들이 “일부 사용자”라는 표현을 벗어나지 못하는 듯함
      PR식 완곡어법 대신 투명한 정보 공개가 오히려 신뢰를 높일 텐데 말임
      게다가 상태 페이지 업데이트조차 늦는 경우가 많음
    • 내 친구는 잠깐 푸시가 됐다고 하지만, 대부분은 여전히 fatal 에러 상태임
답변달기