모두가 이걸 Microsoft 인수나 무능 탓으로 돌리고 싶어 하지만, GitHub가 공개한 자료를 보면 AI 때문에 GitHub에 커밋되는 코드량이 10배로 늘었고 그 여파가 CI, Actions, 코드 수집 등 전반에 퍼진 게 꽤 명확해 보임
글쓴이는 MS Copilot 같은 이상한 요소를 원인으로 잡는데, 인과관계라기보다 싫어하는 것들을 나열한 느낌임
정작 방 안의 코끼리인 AI발 코드 폭증은 무시하고 있음
본문 그래프를 보면 다운타임 패턴은 2020년 1월부터 시작됨
OpenAI가 GPT-3.5를 낸 건 2022년 11월, 사실상 12월이고, 설명한 식의 대규모 언어 모델/에이전트 코딩은 2024년에야 본격화됐고 실제로는 2025년에 더 가까움
그렇다면 AI 얘기가 시작되기 전, 인수 이후 약 4년 동안의 나쁜 가용성은 어떻게 설명할 수 있나?
글을 읽고 나도 정확히 같은 반응이었음
Microsoft 비판에 올라타는 건 좋지만, 방 안의 코끼리를 놓치면 안 됨
내일 완벽한 GitHub 대체제가 생긴다 해도, 수백만 줄의 AI 생성 코드가 그곳의 인프라를 망가뜨리는 걸 무엇이 막을 수 있나?
중앙집중식 코드 호스팅은 AI 때문에 거의 죽게 될 것 같음. 소셜 미디어에서 벌어지는 일과 비슷함
GitHub는 인수 이후 긍정적으로 바뀐 게 없음
10년은 긴 시간이고, 그 결과가 드러남
GitHub Actions, Copilot, 그리고 끌 수도 없는 못생긴 AI 검색. Azure로의 이전까지
Microsoft가 네트워크 효과를 망치는 데 성공했고, 장애는 낙타 등을 부러뜨린 마지막 지푸라기임
설령 그게 사실이어도 Microsoft는 클라우드 플랫폼 전체를 가진 회사임
자체적으로 거대한 코드베이스가 있고 직원도 약 20만 명임
특히 비공개 저장소 무료화 같은 결정을 의식적으로 내렸기 때문에, 이건 변명이 되기 어려움
Microsoft가 GitHub를 Azure 클라우드의 Windows 위에서 돌리고 있다고 상상하곤 함
GitHub가 내려갈 때마다 “누가 GH가 도는 Windows Server를 업데이트해서 전부 재부팅해야 했나 보다”라고 생각함
99% 사실이 아니라고 확신하지만, 그렇게 생각하면 마음이 편하고 장애가 날 때마다 조금 웃기기도 함
오늘 GitHub에서 저장소를 보려고 했음
“xxx commits” 링크를 눌러 커밋 기록을 보려 했더니 secondary rate limit에 걸렸으니 기다리라는 메시지가 나옴
이 네트워크에서 GitHub를 볼 사람은 나뿐이고, 연결도 CGN이 아닌 전용 IP임
사이트를 제대로 탐색하는 유일한 방법은 로그인한 상태로 보는 것임
나도 정확히 똑같고, 꽤 자주 겪음
Slack에 있는 정상 링크를 눌렀는데 나한테는 404가 뜨고 다른 사람들에게는 잘 열리는 일이 자주 있음
데스크톱이라면 Ctrl + Shift + R로 페이지 캐시를 새로고침하면 됨
그러면 페이지가 정상적으로 로드됨
이건 전형적인 테크브로식 가스라이팅임
실제로는 몇 년째 rate limit이 아니라 기본 거부에 가까운데, 문구를 현실에 맞게 바꾸길 거부하고 있음
“GitLab - 엔터프라이즈급이라는 뜻은 비대하고 헷갈리지만 상사에게는 인상적으로 보인다는 말이다. 선택하는 데 회의가 여러 번 필요하다면 이걸 고르면 된다.”
웃김
회사에서 GitLab을 쓰는데 솔직히 실망스러움
가장 단순한 일을 하려 해도 UI가 너무 복잡함. 예를 들어 MR을 승인하려면 사실상 메뉴인 버튼을 눌러야 하고, diff는 읽기 어렵고, ‘To-do list’에는 이미 병합된 MR도 들어가 있음. 그게 어떻게 실행 가능한 할 일인가?
이미 병합된 MR이 ‘To-do list’에 남는 문제는 몇 년 전에 올라왔는데도 개선이 빠르지 않아 보임
반대로 Bitbucket에 대한 반발은 좀 놀랍다. UI가 매우 단순하고 명확하고, 새로 합류한 사람들도 그렇게 느낌. Script Runner를 쓰면 꽤 놀라운 일도 가능하고, 거대한 저장소도 잘 처리함
웃기긴 하지만 사실은 아님
GitLab이 GitHub보다 특별히 더 비대하거나 헷갈리지는 않음
진짜 엔터프라이즈급 소프트웨어라고 보기도 어려움. 그런 걸 원하면 Jira나 Microsoft가 만드는 아무거나 보면 됨
피식했음
우리는 자체 호스팅 GitLab을 쓰는데, git과 컨테이너 레지스트리가 있어서 내가 골랐음
웹 UI를 자주 쓰지 않는다면 인터페이스가 확실히 헷갈릴 수 있음
월 5달러면 서버 하나를 호스팅해서 여러 프로젝트를 올릴 수 있음
저장소에 별이 백만 개 달리는 건 아니지만, 내 필요에는 충분히 동작하고 원하는 사람에게 접근 권한도 줄 수 있음
그래프를 어떻게 봐야 할지 잘 모르겠음
한편으로는 GitHub 인수 때문에 가용성이 나빠졌을 수도 있음
다른 한편으로는 인수 전 가용성이 100.00%로 나오는 게 수상하고, 단순히 상태 페이지가 더 잘 업데이트되기 시작한 건 아닌가 싶음
최근 GitHub 가용성 문제가 있다는 건 알지만, 그래프상 문제는 2020년에 시작되고 크게 악화되는 것처럼 보이지는 않음
주요 오픈소스 저장소는 결국 가만히 두기가 불가능한 것처럼 느껴짐
SourceForge가 망가져 가던 걸 기억하는데, GitHub에서도 같은 일이 벌어지는 걸 보는 건 정말 안타까움
덧붙이면 URL을 “dBus hell”로 읽었음. 다들 한 번쯤 겪어봤잖아
아니, dBu 단위 기반의 nushell이라서 dBu Shell임
내가 회사를 운영한다면 어떻게 할지 자주 생각함
모든 코드 리뷰를 이메일로 하면 어떨지 정말 보고 싶음
저장소는 git 전용 SSH 접근만 되는 단순한 VPS식 서버면 되고, 리뷰 대상 코드를 위한 for-review/ 브랜치 네임스페이스를 두고, CI는 브랜치가 나타나길 기다리는 봇으로 만들어 ref에 주석이나 태그를 달아 통과 여부를 표시하면 됨. 결과를 이메일 스레드에 답장할 수도 있음
메일링 리스트에는 당연히 웹 아카이브 뷰어를 붙이면 예전 리뷰를 볼 수 있음. 이미 이런 해법은 많고, 그냥 HTML임
채팅은 IRC로 하고 봇이 채널을 보관하면 됨. 엄청 쉬움
전체 시스템은, 더 강한 하드웨어가 필요한 CI 실행기를 제외하면 아주 싼 서버에서 돌릴 수 있음
GitHub는 소프트웨어 프로젝트 운영에 필요한 것보다 훨씬 과하게 설계되어 있음. Linux 커널을 보면 단순한 메일링 리스트를 쓰는데, 역대 가장 성공적인 소프트웨어 프로젝트라고 해도 논쟁의 여지가 크지 않음
다만 이슈/버그 추적은 좀 더 무서움. 직접 해법을 만들겠다고 삽질하다가 회사가 하는 일보다 거기에 더 빠질 것 같기 때문임. 어쩌면 버그 추적 소프트웨어 회사가 되면 되려나?
이상적으로는 코드 리뷰도 버전 관리되고 쉽게 접근 가능한 기록이 있으면 좋겠음
즉 코멘트가 정확히 어떤 줄에 붙어 있었는지, 그 줄이 언제 바뀌었는지 보고 앞뒤로 전환하고 싶음
이메일은 이 데이터를 교환하는 프로토콜로는 충분할 수 있지만, 이메일 클라이언트는 그걸 보기 좋은 방식은 아니라고 봄
어쩌면 분산형 코드 리뷰 시스템도 필요할지 모름
동유럽에 사는 데도 장점이 있음
시간대 덕분에 큰 GitHub 장애를 거의 알아차리지 못함
무료 호스팅과 Actions를 꽤 후하게 제공하는 점에도 만족함
집 서버에 Forgejo를 설치한 뒤로는 돌아보지 않았음
유일한 문제는 DigitalOcean App Platform이나 Vercel 등에 앱을 호스팅할 때인데, 이들은 GitHub에만 연결됨
DigitalOcean App Platform은 GitHub뿐 아니라 GitLab에서도 배포를 지원함
다만 자체 호스팅 GitLab 인스턴스가 아니라 gitlab.com 호스팅 인스턴스를 써야 함
이미 자체 호스팅 forge를 배포했다면 gitlab.com을 다리처럼 써서 DigitalOcean App Platform에 연결할 수 있음. gitlab.com 계정을 한 번 만들고, 자체 호스팅 forge가 gitlab.com으로 복제본을 보내게 하면 됨. 실제로 GitLab을 쓸 필요는 별로 없음
그렇다 해도 DigitalOcean이 IaaS/PaaS를 파는 회사인데, 자기 인프라에서 돌아가는 자체 호스팅 Forgejo 같은 것에 연결하게 해주지 않는 건 말이 안 됨
사실 자체 forge를 호스팅하고 싶은 사람은 많지만 직접 설정하고 운영하고 싶은 사람은 적다는 걸 생각하면, DigitalOcean이 Forgejo나 대안을 집어 와서 연 20달러 같은 큰 할인 가격의 준관리형 원클릭 배포 옵션을 제공하고 App Platform 연결을 1급으로 지원하지 않는 것도 이상함
GitHub를 피해야 하는 모든 이유는 DigitalOcean App Platform과 Vercel을 피해야 하는 이유이기도 함
DigitalOcean은 쓰지만 VPS만 씀
이런 중간 계층에 벤더 종속되지 말고, 통제권을 유지하면서 가능한 한 보편적인 스택 계층을 목표로 해야 함
비슷한 처지임
Forgejo 포크 이전인 몇 년 전부터 Gitea로 갈아탔고 후회 없음
GitHub가 필요한 경우에는 저장소를 거기로 미러링해서 동작하게 만들 수 있었음. 다만 코드를 동기화하는 건 귀찮음
Apple의 Xcode Cloud도 비슷한 상황임
GitHub가 힘들어하는 건 AI로 강화된 코딩 때문에 지난 1년간 커밋 수가 14배 늘었고, 그 속도가 아직도 가속 중이기 때문임
사이트가 따라잡기 힘들어하고 있음
GitHub COO가 여기서 확인해 줌: https://x.com/kdaigle/status/2040164759836778878
플랫폼 활동이 급증 중임. 2025년에 커밋 10억 개가 있었는데, 이제는 주당 2억 7,500만 개라서 성장이 선형으로만 유지돼도 올해 140억 개 페이스임. 물론 선형으로 끝나진 않을 것임
GitHub Actions는 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 이번 주는 현재까지 이미 21억 분임
그래서 더 많은 CPU, 서비스 확장, GitHub 핵심 기능 강화에 엄청나게 밀어붙이고 있음
Hacker News 의견들
모두가 이걸 Microsoft 인수나 무능 탓으로 돌리고 싶어 하지만, GitHub가 공개한 자료를 보면 AI 때문에 GitHub에 커밋되는 코드량이 10배로 늘었고 그 여파가 CI, Actions, 코드 수집 등 전반에 퍼진 게 꽤 명확해 보임
글쓴이는 MS Copilot 같은 이상한 요소를 원인으로 잡는데, 인과관계라기보다 싫어하는 것들을 나열한 느낌임
정작 방 안의 코끼리인 AI발 코드 폭증은 무시하고 있음
OpenAI가 GPT-3.5를 낸 건 2022년 11월, 사실상 12월이고, 설명한 식의 대규모 언어 모델/에이전트 코딩은 2024년에야 본격화됐고 실제로는 2025년에 더 가까움
그렇다면 AI 얘기가 시작되기 전, 인수 이후 약 4년 동안의 나쁜 가용성은 어떻게 설명할 수 있나?
Microsoft 비판에 올라타는 건 좋지만, 방 안의 코끼리를 놓치면 안 됨
내일 완벽한 GitHub 대체제가 생긴다 해도, 수백만 줄의 AI 생성 코드가 그곳의 인프라를 망가뜨리는 걸 무엇이 막을 수 있나?
중앙집중식 코드 호스팅은 AI 때문에 거의 죽게 될 것 같음. 소셜 미디어에서 벌어지는 일과 비슷함
10년은 긴 시간이고, 그 결과가 드러남
GitHub Actions, Copilot, 그리고 끌 수도 없는 못생긴 AI 검색. Azure로의 이전까지
Microsoft가 네트워크 효과를 망치는 데 성공했고, 장애는 낙타 등을 부러뜨린 마지막 지푸라기임
자체적으로 거대한 코드베이스가 있고 직원도 약 20만 명임
특히 비공개 저장소 무료화 같은 결정을 의식적으로 내렸기 때문에, 이건 변명이 되기 어려움
GitHub가 내려갈 때마다 “누가 GH가 도는 Windows Server를 업데이트해서 전부 재부팅해야 했나 보다”라고 생각함
99% 사실이 아니라고 확신하지만, 그렇게 생각하면 마음이 편하고 장애가 날 때마다 조금 웃기기도 함
오늘 GitHub에서 저장소를 보려고 했음
“xxx commits” 링크를 눌러 커밋 기록을 보려 했더니 secondary rate limit에 걸렸으니 기다리라는 메시지가 나옴
이 네트워크에서 GitHub를 볼 사람은 나뿐이고, 연결도 CGN이 아닌 전용 IP임
그러면 페이지가 정상적으로 로드됨
실제로는 몇 년째 rate limit이 아니라 기본 거부에 가까운데, 문구를 현실에 맞게 바꾸길 거부하고 있음
“GitLab - 엔터프라이즈급이라는 뜻은 비대하고 헷갈리지만 상사에게는 인상적으로 보인다는 말이다. 선택하는 데 회의가 여러 번 필요하다면 이걸 고르면 된다.”
웃김
가장 단순한 일을 하려 해도 UI가 너무 복잡함. 예를 들어 MR을 승인하려면 사실상 메뉴인 버튼을 눌러야 하고, diff는 읽기 어렵고, ‘To-do list’에는 이미 병합된 MR도 들어가 있음. 그게 어떻게 실행 가능한 할 일인가?
이미 병합된 MR이 ‘To-do list’에 남는 문제는 몇 년 전에 올라왔는데도 개선이 빠르지 않아 보임
반대로 Bitbucket에 대한 반발은 좀 놀랍다. UI가 매우 단순하고 명확하고, 새로 합류한 사람들도 그렇게 느낌. Script Runner를 쓰면 꽤 놀라운 일도 가능하고, 거대한 저장소도 잘 처리함
GitLab이 GitHub보다 특별히 더 비대하거나 헷갈리지는 않음
진짜 엔터프라이즈급 소프트웨어라고 보기도 어려움. 그런 걸 원하면 Jira나 Microsoft가 만드는 아무거나 보면 됨
우리는 자체 호스팅 GitLab을 쓰는데, git과 컨테이너 레지스트리가 있어서 내가 골랐음
웹 UI를 자주 쓰지 않는다면 인터페이스가 확실히 헷갈릴 수 있음
월 5달러면 서버 하나를 호스팅해서 여러 프로젝트를 올릴 수 있음
저장소에 별이 백만 개 달리는 건 아니지만, 내 필요에는 충분히 동작하고 원하는 사람에게 접근 권한도 줄 수 있음
그래프를 어떻게 봐야 할지 잘 모르겠음
한편으로는 GitHub 인수 때문에 가용성이 나빠졌을 수도 있음
다른 한편으로는 인수 전 가용성이 100.00%로 나오는 게 수상하고, 단순히 상태 페이지가 더 잘 업데이트되기 시작한 건 아닌가 싶음
최근 GitHub 가용성 문제가 있다는 건 알지만, 그래프상 문제는 2020년에 시작되고 크게 악화되는 것처럼 보이지는 않음
주요 오픈소스 저장소는 결국 가만히 두기가 불가능한 것처럼 느껴짐
SourceForge가 망가져 가던 걸 기억하는데, GitHub에서도 같은 일이 벌어지는 걸 보는 건 정말 안타까움
덧붙이면 URL을 “dBus hell”로 읽었음. 다들 한 번쯤 겪어봤잖아
내가 회사를 운영한다면 어떻게 할지 자주 생각함
모든 코드 리뷰를 이메일로 하면 어떨지 정말 보고 싶음
저장소는 git 전용 SSH 접근만 되는 단순한 VPS식 서버면 되고, 리뷰 대상 코드를 위한
for-review/브랜치 네임스페이스를 두고, CI는 브랜치가 나타나길 기다리는 봇으로 만들어 ref에 주석이나 태그를 달아 통과 여부를 표시하면 됨. 결과를 이메일 스레드에 답장할 수도 있음메일링 리스트에는 당연히 웹 아카이브 뷰어를 붙이면 예전 리뷰를 볼 수 있음. 이미 이런 해법은 많고, 그냥 HTML임
채팅은 IRC로 하고 봇이 채널을 보관하면 됨. 엄청 쉬움
전체 시스템은, 더 강한 하드웨어가 필요한 CI 실행기를 제외하면 아주 싼 서버에서 돌릴 수 있음
GitHub는 소프트웨어 프로젝트 운영에 필요한 것보다 훨씬 과하게 설계되어 있음. Linux 커널을 보면 단순한 메일링 리스트를 쓰는데, 역대 가장 성공적인 소프트웨어 프로젝트라고 해도 논쟁의 여지가 크지 않음
다만 이슈/버그 추적은 좀 더 무서움. 직접 해법을 만들겠다고 삽질하다가 회사가 하는 일보다 거기에 더 빠질 것 같기 때문임. 어쩌면 버그 추적 소프트웨어 회사가 되면 되려나?
즉 코멘트가 정확히 어떤 줄에 붙어 있었는지, 그 줄이 언제 바뀌었는지 보고 앞뒤로 전환하고 싶음
이메일은 이 데이터를 교환하는 프로토콜로는 충분할 수 있지만, 이메일 클라이언트는 그걸 보기 좋은 방식은 아니라고 봄
어쩌면 분산형 코드 리뷰 시스템도 필요할지 모름
동유럽에 사는 데도 장점이 있음
시간대 덕분에 큰 GitHub 장애를 거의 알아차리지 못함
무료 호스팅과 Actions를 꽤 후하게 제공하는 점에도 만족함
집 서버에 Forgejo를 설치한 뒤로는 돌아보지 않았음
유일한 문제는 DigitalOcean App Platform이나 Vercel 등에 앱을 호스팅할 때인데, 이들은 GitHub에만 연결됨
DigitalOcean App Platform은 GitHub뿐 아니라 GitLab에서도 배포를 지원함다만 자체 호스팅 GitLab 인스턴스가 아니라 gitlab.com 호스팅 인스턴스를 써야 함
이미 자체 호스팅 forge를 배포했다면 gitlab.com을 다리처럼 써서 DigitalOcean App Platform에 연결할 수 있음. gitlab.com 계정을 한 번 만들고, 자체 호스팅 forge가 gitlab.com으로 복제본을 보내게 하면 됨. 실제로 GitLab을 쓸 필요는 별로 없음
그렇다 해도 DigitalOcean이 IaaS/PaaS를 파는 회사인데, 자기 인프라에서 돌아가는 자체 호스팅 Forgejo 같은 것에 연결하게 해주지 않는 건 말이 안 됨
사실 자체 forge를 호스팅하고 싶은 사람은 많지만 직접 설정하고 운영하고 싶은 사람은 적다는 걸 생각하면, DigitalOcean이 Forgejo나 대안을 집어 와서 연 20달러 같은 큰 할인 가격의 준관리형 원클릭 배포 옵션을 제공하고 App Platform 연결을 1급으로 지원하지 않는 것도 이상함
DigitalOcean은 쓰지만 VPS만 씀
이런 중간 계층에 벤더 종속되지 말고, 통제권을 유지하면서 가능한 한 보편적인 스택 계층을 목표로 해야 함
Forgejo 포크 이전인 몇 년 전부터 Gitea로 갈아탔고 후회 없음
GitHub가 필요한 경우에는 저장소를 거기로 미러링해서 동작하게 만들 수 있었음. 다만 코드를 동기화하는 건 귀찮음
GitHub가 힘들어하는 건 AI로 강화된 코딩 때문에 지난 1년간 커밋 수가 14배 늘었고, 그 속도가 아직도 가속 중이기 때문임
사이트가 따라잡기 힘들어하고 있음
GitHub COO가 여기서 확인해 줌: https://x.com/kdaigle/status/2040164759836778878
플랫폼 활동이 급증 중임. 2025년에 커밋 10억 개가 있었는데, 이제는 주당 2억 7,500만 개라서 성장이 선형으로만 유지돼도 올해 140억 개 페이스임. 물론 선형으로 끝나진 않을 것임
GitHub Actions는 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 이번 주는 현재까지 이미 21억 분임
그래서 더 많은 CPU, 서비스 확장, GitHub 핵심 기능 강화에 엄청나게 밀어붙이고 있음