# GitHub 가용성에 대한 업데이트 > Clean Markdown view of GeekNews topic #29010. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29010](https://news.hada.io/topic?id=29010) - GeekNews Markdown: [https://news.hada.io/topic/29010.md](https://news.hada.io/topic/29010.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-29T16:35:01+09:00 - Updated: 2026-04-29T16:35:01+09:00 - Original source: [github.blog](https://github.blog/news-insights/company-news/an-update-on-github-availability/) - Points: 1 - Comments: 1 ## Topic Body - **최근 두 차례 장애** 이후 GitHub는 가용성을 최우선에 두고, 급증한 개발 워크로드와 **agentic development workflows**에 맞춰 인프라와 구조를 다시 손보고 있음 - pull request 하나도 Git 저장소, Actions, 검색, 알림, 권한, webhooks, APIs, 백그라운드 작업, 캐시, 데이터베이스까지 넓게 연결돼 있어, 작은 비효율이 커지면 **큐 적체**와 **의존성 전파**로 이어질 수 있음 - 단기적으로는 webhooks의 **백엔드 이전**, 사용자 세션 캐시 재설계, 인증·권한 부여 흐름 조정, Azure 기반 컴퓨트 확대로 병목과 데이터베이스 부하를 줄이는 데 집중 중임 - 장기적으로는 **핵심 서비스 격리**, 단일 장애점 축소, Ruby monolith 일부의 Go 이전, public cloud 전환과 **multi cloud 경로** 확보를 통해 회복력과 유연성을 높이고 있음 - 4월 23일 merge queue 회귀와 4월 27일 Elasticsearch 과부하 모두 **데이터 손실은 없었고**, GitHub는 status page에 availability 수치를 넣고 작은 장애까지 공개 범위를 넓히며 투명성도 함께 강화 중임 --- ### 가용성 대응 배경 - GitHub는 **최근 두 차례 장애** 이후 가용성과 신뢰성 개선 작업 현황을 정리함 - 2025년 10월부터 **용량 10배 확대 계획**을 실행했으며, 2026년 2월에는 현재 규모의 30배를 전제로 설계해야 할 필요가 분명해짐 - 소프트웨어 개발 방식 변화가 주요 배경이며, 2025년 하반기 이후 **agentic development workflows**가 급격히 가속됨 - 저장소 생성, pull request 활동, API 사용량, 자동화, 대형 저장소 워크로드가 모두 빠르게 증가 중임 ### 확장 과정에서 드러난 구조적 부담 - pull request 하나가 **Git 저장소**, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, databases까지 함께 건드릴 수 있음 - 높은 규모에서는 작은 비효율도 누적돼 **큐 적체**, 캐시 미스의 데이터베이스 부하 전환, 인덱스 지연, 재시도 트래픽 증폭, 느린 의존성의 다중 제품 영향으로 이어질 수 있음 - 우선순위는 **가용성 우선**, 그다음 용량, 그다음 신규 기능으로 정리됨 - 불필요한 작업 감소, 캐시 개선, 핵심 서비스 격리, 단일 장애점 제거, 성능 민감 경로의 전용 시스템 이전을 병행 중임 - 한 서브시스템에 압력이 걸려도 전체가 무너지지 않도록 **숨은 결합도 축소**와 blast radius 제한, graceful degradation 확보가 핵심 과제가 됨 ### 현재 진행 중인 개선 작업 - 단기적으로는 예상보다 빠르게 드러난 병목 해소에 집중함 - **webhooks를 MySQL 밖의 다른 백엔드로 이동**했고, 사용자 세션 캐시를 재설계했으며, 인증·권한 부여 흐름도 다시 손봐 데이터베이스 부하를 크게 줄임 - Azure 이전을 활용해 **더 많은 컴퓨트 자원**도 확보함 - 이후에는 git과 GitHub Actions 같은 **핵심 서비스 격리**와 단일 장애점 축소에 집중함 - 의존성과 트래픽 계층을 세밀하게 분석해 무엇을 분리해야 하는지 파악했고, 각종 공격이 정상 트래픽에 미치는 영향을 최소화하는 방향으로 위험도 순서에 따라 조치함 - 성능이나 규모에 민감한 코드 일부를 **Ruby monolith에서 Go로 이전**하는 작업도 가속함 - 기존의 소규모 자체 데이터센터에서 public cloud로 옮기는 작업을 진행하던 중, 더 장기적으로는 **multi cloud 경로**도 함께 추진하기 시작함 - 이 장기 조치는 앞으로 필요한 회복력, 낮은 지연 시간, 유연성을 확보하는 데 필요함 ### 대형 저장소와 merge queue 대응 - 저장소 수 증가보다 더 어려운 확장 과제로 **대형 monorepo 증가**를 꼽음 - 최근 3개월 동안 git 시스템과 pull request 경험 양쪽에서 이 추세에 대응하는 투자를 크게 늘림 - 더 높은 효율과 확장성을 위한 **새 API 설계** 관련 작업도 진행 중이며, 별도 블로그 글로 공개할 예정임 - 하루 수천 건의 pull request가 발생하는 저장소에 중요하다는 점에서 **merge queue 작업 최적화**에도 투자함 ### 최근 장애 1: 4월 23일 merge queue 문제 - 4월 23일에는 pull request의 **merge queue 동작 회귀**가 발생함 - squash merge 방식을 쓰는 merge queue에서, merge group에 pull request가 둘 이상 포함되면 **잘못된 merge commit**이 생성됨 - 영향받은 경우 이후 병합이 앞서 병합된 pull request와 기존 커밋의 변경을 의도치 않게 되돌리는 상태로 이어짐 - 영향 구간 동안 **658개 저장소와 2,092개 pull request**가 영향을 받음 - 초기 수치는 보수적으로 잡았기 때문에 처음 공유한 수치가 이보다 약간 높았음 - merge queue 밖에서 병합된 pull request에는 영향이 없었고, merge 또는 rebase 방식을 쓰는 merge queue 그룹도 영향받지 않음 - **데이터 손실은 없었음**. 모든 커밋은 Git에 저장된 상태로 남아 있었음 - 다만 영향받은 저장소의 기본 브랜치 상태는 잘못됐고, 모든 저장소를 자동으로 안전하게 복구할 수는 없었음 - [incident root cause analysis](https://github.blog/news-insights/company-news/an-update-on-github-availability/#h-recent-incidents): 추가 세부 사항을 볼 수 있음 - 이번 장애로 여러 **프로세스 실패**가 드러났고, 같은 종류의 문제가 재발하지 않도록 해당 프로세스를 바꾸는 중임 ### 최근 장애 2: 4월 27일 검색 관련 문제 - 4월 27일에는 여러 검색 기반 경험을 담당하는 **Elasticsearch 서브시스템** 장애가 발생함 - 영향 범위에는 pull requests, issues, projects의 일부 검색 기반 UI가 포함됨 - 근본 원인 분석은 아직 마무리 중이며 곧 공개될 예정임 - 현재까지 파악된 바로는 클러스터가 **과부하 상태**가 됐고, 그 결과 검색 결과를 반환하지 못하게 됨 - 과부하 원인으로는 **botnet attack일 가능성**도 열려 있지만, 근본 원인 분석은 아직 완료되지 않음 - 데이터 손실은 없었고, **Git 작업과 APIs는 영향받지 않음** - 다만 검색에 의존하는 UI 일부는 결과를 전혀 표시하지 못해 큰 혼란을 일으킴 - 이 시스템은 단일 장애점을 없애기 위한 완전한 격리가 아직 끝나지 않은 영역이었고, 그전까지는 다른 영역의 위험 우선순위가 더 높았음 - 같은 방식의 의존성 분석과 blast radius 축소 작업을 적용해 이런 실패의 가능성과 영향을 줄이는 중임 ### 장애 투명성 강화 - 장애 중 고객이 더 큰 **투명성**을 원한다는 점이 분명해짐 - 최근 [GitHub status page](https://www.githubstatus.com/)를 업데이트해 **availability 수치**를 포함하도록 바꿈 - [관련 업데이트](https://github.blog/news-insights/company-news/bringing-more-transparency-to-githubs-status-page/) - 큰 장애뿐 아니라 작은 장애도 status에 올리기로 했으며, 사용자가 문제가 자기 측인지 GitHub 측인지 추측하지 않도록 하려는 목적임 - 장애 분류 방식도 계속 개선 중이며, 규모와 범위를 더 쉽게 이해할 수 있게 만드는 중임 - 장애 중 고객이 신호를 공유하고 문제를 보고하는 방식도 더 낫게 만드는 작업을 함께 진행 중임 ### 앞으로의 약속 - GitHub는 **가용성 개선**, 회복력 확대, 미래 소프트웨어 개발 규모에 맞는 확장, 더 투명한 커뮤니케이션을 약속함 - 4월 23일 장애의 영향 저장소 수는 2026년 4월 28일 기준으로 업데이트됨 ## Comments ### Comment 56551 - Author: neo - Created: 2026-04-29T16:35:02+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47932422) - GitHub는 올해 들어서만도 **수십 차례 장애**를 냈고, 작년보다도 가용성과 신뢰성이 눈에 띄게 나빠졌음 이 정도면 대시보드와 히트맵이 돌 정도로 심각하고, HN이나 Reddit 같은 곳에서 **GitHub 불안정성**이 밈이 될 수준까지 왔다고 봄 그런데도 우선순위가 "availability, capacity, new features"라고 말하는 건 현실 인식이 너무 느슨함 지금 우선순위는 1, 2, 3 전부 availability여야 하고, 최소 6개월은 다른 얘기 꺼내지 말고 그것만 고쳐야 함 - 6개월 전에는 **Azure 이전**이 최우선이라며 기능 개발을 미루겠다고 하더니, 지금은 또 가용성이 최우선이라고 하니 앞뒤가 잘 안 맞음 당시엔 AI와 Copilot 수요 때문에 버지니아 데이터센터 용량 제약이 "existential"하다고 했는데, 아직도 같은 문제로 비틀거리는 걸 보면 더 황당함 기능 개발이 미뤄졌다면서도 매주 새 기능과 UI 변경은 계속 나오고, 얼마 전에도 이슈 단일 뷰를 바꿨음 Microsoft 정도 자원을 가진 회사가 이렇게 계속 같은 데서 발목 잡히는 건 믿기 어려울 정도고, 인기 있는 개발자 서비스를 사들여 전부 같은 플랫폼으로 옮기는 전략도 불안해 보임 - 이건 너무 **악의적으로 해석**하는 느낌도 있음 큰 엔지니어링 조직에서는 우선순위가 배타적이지 않고, 핵심 우선순위에 직접 기여하지 못하는 팀은 다른 기능 작업을 계속할 수도 있음 - 그 **single issues view** 변경은 성능 완화를 위한 패닉성 해킹에 가까웠음 [https://news.ycombinator.com/item?id=47912521](https://news.ycombinator.com/item?id=47912521) - **Azure 이전**이 오히려 가용성 문제를 더 악화시켰을 가능성도 충분함 전용 하드웨어가 클라우드보다 예측 가능성이 높고, "Azure로 가지 말고 랙 몇 개 더 사자" 같은 판단은 GitHub 경영진 선에서 결정할 수 없는 일이었을 수도 있음 - 지난 **5년간 기능 변경이 전혀 없었어도** 아무도 화내지 않았을 텐데, 굳이 계속 뜯어고치고 있음 GitHub는 5분마다 재설계할 사이트가 아니고, 관리자들이 자기 존재 이유를 증명하려고 새 기능을 위한 새 기능을 밀어붙이는 것처럼 보일 때가 있음 그 결과 더 많이 망가뜨릴수록 오히려 사용자를 끌어들이는 데 역효과가 남 검색도 크게 너프됐고, Google 검색이나 YouTube처럼 왜 멀쩡하던 검색을 다들 계속 망가뜨리는지 모르겠음 게다가 Microsoft는 거의 버려진 듯한 **Azure DevOps**도 있고 GitHub도 있는데, 둘 다 특히 티켓 시스템이 싫음 Jira 프로젝트마다 설정이 제각각이라 질렸는데도, 이제는 "차라리 Jira가 그립다"는 말까지 나오게 됨 - 저 글은 **정색하고 읽기 어렵다**는 느낌임 숫자만 크게 올려놓은 라벨 없는 그래프, 실제 체감과 맞지 않는 우선순위, 그리고 지난 12개월의 끔찍한 업타임을 제대로 인정하지 않는 태도가 너무 거슬림 - 그래프가 아주 최악은 아님 왼쪽 아래 축 라벨이 없긴 해도, 2023→2024→2025→2026으로 성장 속도가 매우 빠르다는 핵심은 전달됨 2026 초·말쯤에는 이전 3년을 합친 것보다 더 큰 성장을 말하는 것처럼 읽히고, 축 숫자를 몰라도 대략의 추세는 볼 수 있음 선형 그래프라는 가정은 필요하지만, 문맥상 그 정도 가정은 무리 없어 보임 계획보다 훨씬 큰 성장을 겪는 회사라면 용량 문제가 생길 수밖에 없고, 이제는 하드웨어만 더 넣는 수준을 넘어 **백엔드 효율화**가 필요해 보임 적어놓은 목표들도 대체로 그쪽을 겨냥하고 있음 - 숫자는 여기에도 더 있음 [https://x.com/kdaigle/status/2040164759836778878](https://x.com/kdaigle/status/2040164759836778878) 지금 성장이 **지수적**이라는 걸 못 믿는 건지, 아니면 연간 10배 성장도 별로 안 어렵다고 보는 건지 모르겠음 - 인수 후 **6년 내내** 그랬다고 봐야 할지도 모름 [https://damrnelson.github.io/github-historical-uptime/](https://damrnelson.github.io/github-historical-uptime/) - 요약하면 300단어쯤 되는 "**우리가 듣고 있다**" 메시지로 보임 - 이런 식의 꾸밈 그래프는 많은 클라이언트가 다 비슷하게 씀 - "**multi cloud 경로**를 시작했다"는 문장을 보면, Microsoft가 Azure만으로는 원하는 수준의 신뢰성을 못 뽑는다고 사실상 인정한 것처럼 들림 - 꽤 치명적인 시그널처럼 보이고, Azure를 써본 입장에선 충분히 납득도 감 - 이건 다운타임 때 돈을 잃는 **엔터프라이즈 고객**을 겨냥한 대응 같기도 함 유지율 방어에는 도움이 될 수 있음 - 저 정도 규모의 복잡한 시스템이라면 **단일 공급자 의존**을 피하는 게 상식적이기도 함 - 예전에 여기서 **Dave Cutler의 Azure 비전**이 우선순위, 압박, 관리 때문에 훼손됐다는 글을 본 기억이 있음 원래는 사람 개입이 거의 없는 운영을 지향했는데, 지금은 누가 랙이나 VM에 시리얼 붙여 직접 건드리는 식이 일상적인 절차라는 얘기였음 지금은 링크를 못 찾겠지만 - Show HN은 **올리는 시간대**가 생각보다 중요함 월~목 오전 9~11시 Pacific에 가장 적극적인 독자가 많고, 주말은 경쟁은 적지만 참여도도 낮음 - GitHub CTO가 **Codepath.org** 이사회에도 있고, 거기 설명이 "첫 번째 AI-native 세대의 엔지니어, CTO, 창업자를 만든다"는 식이라면, 어디가 문제인지 대충 감이 옴 - 체감상 **GitHub 안정성**이 많이 나빴고, 최근엔 웹에서 보여주는 데이터조차 믿기 어려움 어제부터 나와 동료 몇 명이 여러 저장소에서 PR 목록이 불완전하게 보이는 걸 확인했음 예를 들어 [https://github.com/gap-system/gap/pulls](https://github.com/gap-system/gap/pulls)에서는 탭엔 "Pull requests 78"이라고 나오는데, 목록 뷰에는 "35 open"만 보임 78이 맞는 숫자인 건 `gh pr list`로도 확인되는데도 [https://www.githubstatus.com](https://www.githubstatus.com)은 여전히 "all systems operational"이라고 표시함 - 내 프로젝트들 중 상당수는 최근 **6일간 닫힌 PR**이 하나도 안 보임 CLI로는 목록이 나오는데, 검색을 거치는 웹 경로에서는 전부 사라짐 지원팀도 이 이슈를 인정하긴 했지만 그 뒤로 조용하고, 상태 페이지에도 27일의 아마 관련 있어 보이는 이슈 말고는 아무것도 없음 일부 저장소에서는 중간에 해결된 듯하지만, 여전히 여러 org와 repo에서 계속 재현됨 [https://github.com/orgs/community/discussions/193388](https://github.com/orgs/community/discussions/193388) - 나도 같은 현상을 봤고, **status page**에는 여전히 안 올라와 있음 빠진 PR은 브랜치 페이지를 뒤져서 겨우 찾았음 - 이건 확장성 때문에 **추정 쿼리**를 써서 100% 정확하지 않은 결과를 반환하게 만든 해킹일 가능성이 커 보임 완전한 버그라기보다, 인프라 부하를 줄이려고 제품 관점에서 아주 나쁜 선택을 했을 수도 있음 - 지난 몇 년간의 **새 repo/issues/commits 데이터**를 공개한 건 그래도 흥미로웠음 다들 바깥에서 짐작하던 대로, 에이전트들이 GitHub에 갑작스럽고 큰 추가 부하를 주고 있다는 걸 확인시켜 줌 이미 거대한 사용자 기반을 서비스하면서도 스타트업처럼 지수 성장하는 셈이라 표적이 될 수밖에 없고, 조직이 빠르게 움직이기도 쉽지 않을 것 같음 반대로 인재, 인프라, 자금은 스타트업보다 훨씬 많다는 점도 있음 - 무슨 데이터를 말하는지 모르겠음 라벨 없는 그래프 하나와 현재 피크 숫자만 있을 뿐임 - 저 **그래프들**은 도대체 뭘 해놓은 건지 모르겠고, 거의 아티스트의 인상화처럼 보임 커밋 그래프를 보면 왜 큰 계단이 생긴 뒤 완만하게 꺼지는지, 왜 그 계단이 일정한 지점에서 발생하지 않는지, 왜 더 큰 점프가 때로는 더 작은 기울기를 가지는지 설명이 안 됨 다른 그래프들은 또 전혀 다른 형태로 움직여서 더 이상함 - 전형적인 **PowerPoint 그래프**라서 그럼 실제 데이터나 데이터의 의미를 보여주기보다 그냥 "뭔가가 오른다"만 전달하는 용도임 - **federated forges**가 결국 미래라고 봄 저장소는 각자 sovereign infra에 호스팅하고, 전역 ID와 federated metadata 이슈·PR 등을 얹는 구조가 맞아 보임 이런 전역 인덱스는 띄우기도 쉬워서 가용성이 큰 걱정거리가 아니게 만들 수 있고, 우리도 그 방향으로 작업 중임 - 아이디어는 귀엽지만, 대부분은 **직접 호스팅**하고 싶어 하지 않음 결국 제3자 호스팅을 쓰게 되면 1~3개의 큰 사업자가 다시 등장할 가능성이 큼 그리고 가용성 문제를 피하려고 셀프호스팅해도, 의존성이 GitHub 같은 대형 서비스에 걸려 있으면 그쪽 장애는 여전히 피할 수 없음 그래서 현실적 해법은 지금과 마찬가지로 쓰는 걸 전부 프록시하거나 미러링하는 쪽임 - 사실 이미 그렇게 할 수는 있음 GitHub, Codeberg, 셀프호스트에 같은 repo를 두고 메인 브랜치 일관성만 관리하면 됨 그다음부터는 어디서든 업데이트할 수 있고, README에 링크만 잘 걸어두면 됨 - 코딩 에이전트들이 깊은 **VCS 통합**을 할 때 GitHub를 기본값으로 두지 않았으면 좋겠음 decent API나 webhook만 제공하는 다른 forge를 연결해서 같은 편의성을 얻을 수 있다면 전부 셀프호스트로 가고 싶음 에이전트 쪽에서도 인터페이스를 열어줘야겠지만, 플러그인 구조라면 GitHub 의존성을 떼어내고 나머지는 MCP나 skills로 처리할 수 있을 것 같음 - 좋은 아이디어고, 우리 사이트의 **LLM 생성 콘텐츠**도 이것으로 대체하고 싶음 나는 큰 러너는 셀프호스팅해도 괜찮아서 최근 Codeberg로 옮겼고, 작은 cron 작업은 Codeberg가 제공하는 러너를 씀 거긴 이런 용도로 lazy runner까지 있음 - 처음 들어보는 개념인데, 가입해서 한번 써볼 생각임 - 지금 하는 일은 이거처럼 보임 **토큰 보조금**은 충분한 학습 데이터를 빨아들였고 agentic junkies 비즈니스도 이제 플라이휠을 굴릴 만큼 커졌으니 끊고, 손실 유도 상품은 정리하겠다는 것 같음 [https://news.ycombinator.com/item?id=47923357](https://news.ycombinator.com/item?id=47923357)