Ghostty, GitHub을 떠나다
2026년 4월 28일, Ghostty 터미널 에뮬레이터의 창시자 Mitchell Hashimoto가 블로그에 짧은 글을 올렸습니다.
"이 글을 쓰는 게 비이성적으로 슬프다. 하지만 Ghostty는 GitHub을 떠날 것이다."
GitHub user #1299
Hashimoto는 GitHub 사용자 번호 1299번입니다. 2008년 2월에 가입했고, 그 이후 매일, 하루에도 여러 번 GitHub에 접속했다고 합니다. 18년입니다. 한 인간이 태어나서 성인이 되기에 충분한 시간입니다. 여러분은 18년 동안 한 종류의 일을, 혹은 취미를, 어떤 활동이건, 이어간 적이 있나요? 그에게 깃허브는 개발 플랫폼 이상의 의미일 겁니다.
가장 이성적인 인간이 가장 비이성적인 글을 씁니다. 힘든 이별을 겪었을 때도 GitHub 오픈소스에 매달렸고, 새벽 4시에 마지막 커밋을 올렸고, 신혼여행 중 아내가 잠든 새벽에도 북마크해둔 프로젝트를 뒤졌다고. "어떤 이들은 SNS를 둠스크롤하지만, 나는 GitHub 이슈를 둠스크롤해왔다."
Vagrant를 만든 것도 GitHub에서 일하고 싶어서였습니다. 첫 번째 공개 발표에서 20살의 그는 "잘 만들면 GitHub이 나를 채용할지도!"라고 농담했습니다. GitHub이 꿈의 직장이었고, 결국 그곳에서 일하지는 못했지만, 대신 18년 동안 매일 그곳에 살았습니다.
최근 그는 GitHub 장애로 피해를 입은 날에 X 표시를 하는 일지를 한 달간 써왔습니다. 거의 매일 X가 붙었습니다. 이 글을 쓴 날에도 GitHub Actions 장애로 PR 리뷰를 2시간 동안 할 수 없었습니다. 4월 27일의 대규모 Elasticsearch 장애와는 별개로 발생한 또 다른 장애였습니다.
"더 이상 진지한 작업을 할 수 있는 곳이 아닙니다. 매일, 몇 시간씩 막아버린다면."
"비이성적으로 개인적인 감정이다."
애정이 클수록 배신감도 크다는 게 이런 경우입니다. GitHub이 잘 되길 바라면서도, 코딩을 해야 하고, GitHub은 그걸 막고 있다고.
깃허브는 왜 이렇게 됐나
Hashimoto가 X 표시를 칠하는 동안, GitHub 측도 상황을 알고 있었습니다. 그런데 알면서도 왜 고쳐지지 않는 걸까요?
가장 중요한 원인은 AI 에이전트의 폭발적 증가입니다. 2025년 12월부터 코드를 자동으로 작성하고, PR을 열고, 커밋을 올리는 agentic 워크플로우가 급격히 늘었습니다. 사람이 하루에 열 번 커밋한다면, 에이전트는 하루에 수백 번 합니다. 저장소 생성, PR 활동, API 호출, 대형 저장소 작업이 동시에 폭발했습니다. GitHub은 2025년 10월에 10배 용량 확장 계획을 시작했지만, 2026년 2월에는 그것도 부족하고 30배 스케일의 재설계가 필요하다는 결론에 도달했습니다. AI가 GitHub를 먹어치우고 있다는 표현이 과장이 아닙니다.
4월 23일 사고는 대표적인 사례입니다. Merge Queue 기능에 버그가 생겨 squash merge 시나리오에서 잘못된 커밋이 만들어졌습니다. 230개 저장소, 2,092개의 PR이 영향을 받았습니다. PR을 잘못 병합하는 버그가 프로덕션에 배포됐다는 뜻입니다. 코드 히스토리 자체가 오염됩니다.
4월 27일 사고는 Elasticsearch 클러스터 전체가 과부하로 멈췄습니다. 일부는 봇넷 공격으로 의심했지만 확인되지는 않았습니다. Git 자체나 API는 영향이 없었지만, 검색에 의존하는 GitHub UI 전체가 먹통이 됐습니다. 이슈 검색, 코드 검색, 저장소 탐색 — 검색창이 없으면 GitHub은 생각보다 쓸 수 없는 도구입니다. Hashimoto가 이 글을 쓰던 날도 이 사고와 별개로 발생한 GitHub Actions 장애가 2시간 동안 PR 리뷰를 막았습니다.
GitHub Actions는 만성 문제입니다. 빌드 큐가 30분씩 밀리고, 러너가 이유 없이 실패하고, 캐시가 날아갑니다. CI 파이프라인이 믿을 수 없으면 릴리스 사이클 전체가 흔들립니다. 한 달 동안 기록을 해보면, 거의 매일 장애가 있다는 게 드러납니다. Hashimoto가 실제로 그걸 기록했고, 거의 매일 X 표시가 찍혔습니다.
GitHub은 뒤늦게 "Availability First"를 선언했습니다. 신뢰보다 속도를 우선하던 방식에서 가용성을 최우선에 두겠다는 방향 전환입니다. 선언이 나온 타이밍이 Ghostty 이탈 발표와 겹쳤다는 점이 아이러니합니다.
Ghostty는 어디로 가는가
아직 구체적인 이전 대상은 공개하지 않았습니다. 여러 상업용 및 FOSS 플랫폼과 논의 중이며, 몇 달 안에 세부 사항을 공유하겠다고 했습니다. 이전은 점진적으로 이루어질 예정이고, 현재 GitHub URL에는 read-only 미러가 유지됩니다.
Hashimoto의 개인 프로젝트와 다른 작업은 일단 GitHub에 남습니다. Ghostty가 메인테이너와 오픈소스 커뮤니티가 가장 직접적으로 영향받는 프로젝트이기 때문에 거기서부터 시작합니다.
툴 얘기를 이렇게까지 감정적으로 다루는 사람은 드뭅니다. 하지만 18년 동안 작업의 흔적이 다 담긴 곳이 믿을 수 없게 된다면, 그게 단순히 "서비스 품질 문제"로 느껴지지 않는 건 자연스럽습니다.
GitHub이 얼마나 오픈소스 생태계의 인프라가 됐는지를 보여주는 사건이기도 합니다. 대안이 있어도 쉽게 못 떠나는 이유, 그럼에도 결국 떠나게 만드는 이유가 모두 이 글에 담겨 있습니다.