2026년 4월 28일, HashiCorp 공동창업자이자 Ghostty 터미널 프로젝트 메인테이너인 Mitchell Hashimoto가 짧고 단호한 글을 올렸어요. "Ghostty is leaving GitHub". 이유는 한 줄로 정리됐어요. "반복되는 GitHub 장애가 우리 작업을 망가뜨리고 있다". 같은 날 Flask 창시자 Armin Ronacher는 'Before GitHub'을 발행했고, 다음 날 The Register는 "GitHub은 더 이상 진지한 작업을 위한 곳이 아니다"라는 헤드라인으로 받아 적었어요. Hacker News에서 세 글의 점수를 합치면 3,900점이 넘었고, 24시간 안에 GitNexus(33K★) 같은 클라이언트 사이드 코드 그래프 도구와 네덜란드 정부의 code.overheid.nl 자체 호스팅 플랫폼이 동시에 전면에 떠올랐어요.
한 사람의 짜증이 아니라, 산업 차원의 신호예요. 그리고 그 신호는 아주 보수적으로 봐도 우리 한국 스타트업에 직접 닿아요. 깃랩·코드버그·자체 호스팅 같은 단어를 1년 동안 한 번도 입에 올린 적 없는 팀이 대부분이거든요. 이 글은 4월 28일 흐름을 정리하고, 단일 코드 호스팅 의존을 끊는 5단계 마이그레이션 체크리스트를 드릴게요.
4가지 시그널이 한꺼번에 터졌기 때문이에요.
Hashimoto가 인용한 GitHub Status 기록만 봐도 1월부터 4월까지 4개월 사이에 incident가 연속으로 쌓였어요. Actions, Codespaces, Pull Requests, Webhooks가 번갈아 죽었고, 한국 시간으로 평일 오전·오후 코어 시간대에도 영향을 줬어요. 단순 다운이 끝이 아니에요. 웹훅이 늦게 도착해서 Vercel·CI/CD가 잘못된 SHA로 빌드하거나, PR 머지가 됐는데 status check가 stuck 되는 식의 데이터 정합성 문제까지 보고됐어요. 우리 팀의 배포 신뢰도가 GitHub의 SLO에 묶여 있다는 뜻이에요.
Hashimoto 글의 진짜 무게는 가용성보다 한 줄 아래 문장이에요. "GitHub은 코드 관리 도구가 아니라 AI 데이터 수집 파이프라인의 진입점이 되고 있다." 2026년 들어 GitHub은 Copilot 학습·코드 인덱싱·이슈 본문 인덱싱 옵션을 디폴트 ON으로 갱신했고, Org 어드민이 명시적으로 끄지 않으면 모든 비공개 메타데이터(이슈, PR 본문, 리뷰 코멘트)가 학습에 노출돼요. 한국 회사라면 영업비밀 보호와 PIPA(개인정보보호법) 정합성을 동시에 따져 봐야 해요.
Armin Ronacher의 'Before GitHub' 글은 코드 호스팅이 아주 옛날엔 분산형이었다는 사실을 상기시켜요. SourceForge, Google Code, Bitbucket 시절엔 OSS가 한 회사에 종속되지 않았어요. 지금은 GitHub 하나가 죽으면 OSS 절반이 일주일 멈춰요. 네덜란드 정부 code.overheid.nl 소프트 런칭, 독일·프랑스 GitLab 자체 호스팅, EU의 디지털 주권 정책이 모두 같은 방향이에요.
4월 28일 GitHub 트렌딩에 abhigyanpatwari/GitNexus가 33,129★로 올라왔어요. 브라우저에서 돌아가는 Graph RAG 코드베이스 인덱서예요. ComposioHQ/awesome-codex-skills, lukilabs/craft-agents-oss, mattpocock/skills(42K★)도 같은 흐름이에요. 코드와 컨텍스트가 클라우드에 묶일 필요가 없다는 합의가 빠르게 만들어지고 있어요.
대부분의 팀이 GitHub Org 하나에 아래를 다 묶어 둬요.
이 8가지가 한 회사에 묶이면 "GitHub이 죽었다"는 사실상 "회사가 죽었다"와 같아요. 4월에 두 번, 한국 시간 기준으로 코어 시간대에 Actions가 1시간 이상 멈췄을 때 어떤 회사는 배포 파이프라인이 24시간 밀렸어요. 시크릿 회전, 출시 일정, 고객 SLA가 다 흔들렸어요.
가장 빠른 방어는 main 브랜치 미러예요. Codeberg(Gitea 기반, 무료, EU 호스팅), GitLab.com Free, 또는 자체 Gitea 인스턴스 하나를 골라 GitHub Actions의 schedule 워크플로우로 매시간 push --mirror를 돌리면 끝이에요. 비용 0원, 작업 시간 30분이에요. 이게 디지털 보험이에요. "지금 GitHub이 죽어도 우리는 코드 받을 수 있고 배포 가능하다"는 상태부터 확보하세요.
가장 위험한 종속이 GitHub Actions예요. 의존을 줄이는 방법은 두 가지예요. (a) GitHub Actions 워크플로우를 컨테이너 기반으로 작성해서 act·Drone CI·Buildkite로도 돌아가게 만들기. (b) 핵심 배포 트리거(Vercel·Cloudflare)를 GitHub Webhook 단일 경로 말고 Git Push trigger 또는 별도 deploy hook로 다중화. 우리 팀의 dev 서버는 GitHub 외에 GitLab CI에서도 시간당 1회 헬스 체크 빌드를 돌려요. 진짜 사고 났을 때 회복 시간을 24시간에서 1시간으로 줄이는 차이가 여기서 나와요.
스타트업은 이슈 트래커를 GitHub Issues 하나에 다 욱여넣는 경우가 많아요. 그런데 제품 백로그, 고객 버그 리포트, ADR(아키텍처 결정 기록), 회의 노트는 본질이 달라요. 백로그·기획은 Linear·Plane(오픈소스)·Notion으로 옮기고, ADR은 docs/ 디렉토리에 마크다운으로 박고, 고객 리포트는 별도 헬프데스크 또는 자체 폼으로 받으세요. 이슈 데이터가 GitHub에 없으면, 호스팅을 갈아치우는 비용이 한 자릿수로 떨어져요.
의외로 사고가 나는 시점은 호스팅을 옮기는 그 순간이에요. CODEOWNERS, branch protection, environments, encrypted secrets, deploy keys, OIDC trust 정책이 GitHub에만 살아 있는 형태로 굳어 있어서 이전이 안 돼요. 한 페이지짜리 보안 인벤토리를 만드세요. (a) 누가 admin 권한을 가졌는지, (b) 시크릿이 몇 개고 어디서 참조되는지, (c) deploy key가 어느 서비스에 박혀 있는지. 이 표가 마이그레이션 RFC의 첫 페이지가 돼요.
모든 코드를 옮길 필요는 없어요. 우리 팀은 코드를 3티어로 나눠요. Tier 1(영업비밀·결제·고객 데이터 처리)은 자체 Gitea 또는 EU 호스팅에서만 다뤄요. Tier 2(앱 코어, 내부 도구)는 GitHub + 미러 이중화. Tier 3(공개 OSS, 데모)은 GitHub 그대로. 이 분류가 있으면 "다음 GitHub 장애가 났을 때 어디부터 살릴지" 의사결정이 자동이에요.
중요한 건 한 번에 다 옮기는 게 아니라, "다음 사고 때 24시간이 1시간이 되는 구조"를 빨리 만들어 두는 거예요. 한국 스타트업 대부분은 이 작업을 한 번도 한 적이 없어요.
외주 파트너를 고를 때부터 멀티 코드 호스팅 가능성을 합의해 두면 마이그레이션 비용이 절반으로 떨어져요. 견적·계약 단계에서 (a) 소스코드 소유권, (b) Git 저장소 위치 자유, (c) CI/CD 호환성 포맷, (d) 인수인계 시 미러 복제 권한을 명시하세요. 포텐랩은 모든 프로젝트에서 GitHub Org와 별도 미러(요청 시 Codeberg·GitLab·자체 Gitea)를 동시에 운영해요. 97% 수행완수율과 인수인계 12종 자산 체크리스트가 표준이라 호스팅 이전이 와도 24시간 안에 정상화돼요.
Mitchell Hashimoto가 GitHub을 떠난 건 Microsoft가 미워서가 아니에요. 자기 작업의 속도와 신뢰도를 한 회사 SLO에 영원히 묶어 두지 않겠다는 결정이에요. 우리 스타트업도 같은 결정을 작게 시작할 수 있어요. 30분짜리 미러 한 줄부터요.
2026년 4월 28일은 작은 분기점이에요. 우리는 GitHub을 사랑할 수 있어요. 그래도 의존도는 다른 문제예요. 오늘 30분 안에 Codeberg 미러를 만들고, 내일 1시간 안에 시크릿 인벤토리를 적고, 다음 주에 30분짜리 게임데이를 한 번 돌리세요. 그 90분이 다음 GitHub 장애 때 우리 팀의 24시간을 살려요. 외주 파트너와 처음부터 이 구조로 일하고 싶으시면 포텐랩 상담으로 편하게 말씀해 주세요.
2026년 4월 28일 HashiCorp 공동창업자이자 Ghostty 메인테이너인 Mitchell Hashimoto가 "Ghostty is leaving GitHub"을 올렸어요. 이유는 한 줄로 정리됐는데, "반복되는 GitHub 장애가 우리 작업을 망가뜨리고 있다"였어요. 같은 날 Flask 창시자 Armin Ronacher가 'Before GitHub'을 발행했고, 다음 날 The Register가 "GitHub은 더 이상 진지한 작업을 위한 곳이 아니다"라는 헤드라인으로 받아 적었어요. 세 글의 Hacker News 점수를 합치면 3,900점이 넘어서, 한 사람의 짜증이 아니라 산업 차원의 신호로 읽혔어요.
네 가지 시그널이 한꺼번에 터졌기 때문이에요. 2026년 1월부터 4월까지 Actions·Codespaces·Pull Requests·Webhooks 장애가 연속으로 쌓였고, GitHub이 Copilot 학습·코드 인덱싱·이슈 본문 인덱싱 옵션을 디폴트 ON으로 갱신했어요. 여기에 'Before GitHub' 같은 권력 분산 담론과 네덜란드 정부 code.overheid.nl·EU 디지털 주권 정책이 겹쳤고, GitNexus(33,129★) 같은 클라이언트 사이드·로컬 퍼스트 도구가 빠르게 떠올랐어요.
대부분의 팀이 GitHub Org 하나에 코드 저장소, CI/CD, 이슈 트래커, 코드 리뷰, 문서, 패키지, 배포 트리거, 2FA·SSO까지 8가지를 다 묶어 둬요. 이 8가지가 한 회사에 묶이면 "GitHub이 죽었다"는 사실상 "회사가 죽었다"와 같아요. 실제로 4월에 두 번, 한국 시간 코어 시간대에 Actions가 1시간 이상 멈췄을 때 어떤 회사는 배포 파이프라인이 24시간 밀렸고 시크릿 회전과 출시 일정, 고객 SLA가 다 흔들렸어요.
5단계로 나눠서 하면 돼요. 1단계는 Codeberg·GitLab.com·자체 Gitea 중 하나에 main 브랜치 Read-Only 미러를 만드는 것이고(비용 0원, 작업 30분), 2단계는 CI/CD를 호스팅과 분리해 컨테이너 기반 워크플로우와 별도 deploy hook으로 다중화하는 거예요. 3단계는 이슈·문서를 Linear·Plane·Notion과 docs/ 마크다운으로 분리하고, 4단계는 CODEOWNERS·branch protection·시크릿·deploy key를 한 페이지 인벤토리로 문서화해요. 5단계는 코드를 Tier 1~3으로 나누는 'Sovereignty Tier'를 정의하는 거예요.
월요일에 Codeberg 또는 GitLab.com 계정을 만들고 main 브랜치 미러 push를 1회 수동 실행하고, 화요일에 schedule cron으로 매시간 자동 미러 워크플로우를 추가해요. 수요일에는 Vercel·Cloudflare 배포 트리거에 deploy hook을 붙여 GitHub 외 경로를 1개 확보하고, 목요일에 Org admin·시크릿·deploy key 인벤토리를 1페이지로 정리해요. 금요일에는 'GitHub 1시간 다운'을 가정한 30분짜리 게임데이를 돌려 부족한 부분을 액션아이템으로 만들면 돼요. 한 번에 다 옮기는 게 아니라 다음 사고 때 24시간이 1시간이 되는 구조를 빨리 만들어 두는 게 핵심이에요.
외주 파트너를 고를 때부터 멀티 코드 호스팅 가능성을 합의해 두면 마이그레이션 비용이 절반으로 떨어져요. 견적·계약 단계에서 소스코드 소유권, Git 저장소 위치 자유, CI/CD 호환성 포맷, 인수인계 시 미러 복제 권한 네 가지를 명시하세요. 포텐랩은 모든 프로젝트에서 GitHub Org와 별도 미러(요청 시 Codeberg·GitLab·자체 Gitea)를 동시에 운영해요.