# HashiCorp 공동 창업자, GitHub가 '더 이상 진지한 작업을 위한 장소가 아니다'라고 말해 > Clean Markdown view of GeekNews topic #29048. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29048](https://news.hada.io/topic?id=29048) - GeekNews Markdown: [https://news.hada.io/topic/29048.md](https://news.hada.io/topic/29048.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-30T23:33:53+09:00 - Updated: 2026-04-30T23:33:53+09:00 - Original source: [theregister.com](https://www.theregister.com/2026/04/29/mitchell_hashimoto_ghostty_quitting_github/) - Points: 1 - Comments: 1 ## Topic Body - **Ghostty**가 GitHub에서 다른 협업 코드 저장소로 이전 중임 - Mitchell Hashimoto는 2008년 2월 GitHub 사용자 1299번으로 가입한 뒤 거의 매일 사용해 왔고, 한때 GitHub를 **가장 행복하게 만든 곳**으로 여겼음 - 최근 한 달 동안 **서비스 신뢰성 저하**가 작업에 영향을 준 날이 거의 매일 기록됐고, 글을 쓰는 날에도 GitHub Actions outage로 약 2시간 동안 PR review를 하지 못함 - GitHub는 더 이상 즐거운 장소가 아니며, 18년 사용 후 떠나기로 했지만 **real results and improvements**가 있으면 돌아올 가능성은 열려 있음 - Ghostty 이전은 여러 commercial·FOSS provider와 논의하며 **incremental**하게 진행되고, GitHub에는 read-only mirror를 남기는 방식으로 추진됨 --- ### Ghostty와 GitHub 사용 배경 - 현재 주력 프로젝트는 [Ghostty]()이며, **terminal emulator**로 속도와 성숙한 소프트웨어 범주에 “interesting new wrinkles”를 더한 프로젝트임 - Ghostty 개발에는 GitHub를 사용해 왔고, Mitchell Hashimoto는 2008년 2월 GitHub 사용자 1299번으로 가입한 뒤 거의 매일 사용해 왔음 - GitHub는 “가장 행복하게 만든 곳”이었고, 신혼여행 중에도 시간을 냈을 만큼 오래 애정을 가진 서비스였음 - 소셜 미디어를 doom scrolling하는 대신 GitHub issues를 오래 전부터 살펴봤고, 휴가 중에도 GitHub 프로젝트의 소스코드와 OSS 프로세스, maintainer 대응을 공부했음 ### 매일 작업을 막는 장애 - 최근 GitHub에 대한 감정은 크게 바뀌었고, GitHub가 매일 자신을 실패하게 만들며 그 문제가 개인적으로 느껴지는 상태가 됨 - 핵심 원인은 **서비스 신뢰성 저하**이며, 지난 한 달 동안 GitHub 장애가 작업 능력에 부정적 영향을 준 날짜마다 일지에 “X”가 표시됨 - 그 일지에는 거의 매일 “X”가 있었고, 글을 쓰는 날에도 **GitHub Actions outage** 때문에 약 2시간 동안 PR review를 하지 못함 - 해당 글은 pull request가 Elasticsearch SNAFU 때문에 완료되지 못한 4월 28일 [incident]() 며칠 전에 작성됨 - 이런 장애가 매일 몇 시간씩 작업을 막는다면 GitHub는 더 이상 “serious work”를 위한 장소가 아님 ### 개발 흐름과 감정적 단절 - GitHub는 더 이상 즐거운 장소가 아니며, “I want to ship software and it doesn't want me to ship software”라는 문장처럼 소프트웨어 배포를 막는 존재가 됨 - GitHub가 개선되기를 바라지만, 동시에 코드를 작성해야 하고 GitHub로는 더 이상 코딩할 수 없는 상태임 - 18년 사용 후 떠나야 한다는 결론에 도달했으며, **real results and improvements**가 있다면 돌아올 가능성은 열려 있음 - 단순한 말이나 약속이 아니라 실제 결과와 개선이 GitHub 복귀 조건임 ### Ghostty 이전 방식 - Ghostty는 다른 **collaborative code locker**로 이전 작업을 진행 중임 - 여러 provider와 논의 중이며, 대상에는 commercial provider와 FOSS provider가 모두 포함됨 - GitHub 의존성을 모두 제거하는 데 시간이 걸리며, 가능한 한 **incremental**하게 진행할 계획임 - GitHub에는 Ghostty의 read-only mirror를 남기고, 개인 프로젝트도 Microsoft 소유 서비스에 계속 둘 예정임 - Ghostty는 본인, maintainer, open source community가 가장 큰 영향을 받는 프로젝트라 이번 변경의 초점이 됨 ### GitHub의 위치와 Microsoft 맥락 - Microsoft가 GitHub를 인수한 뒤, Windows나 Azure 생태계에 묶이지 않은 개발자에게 덜 편한 Redmond 중심 서비스가 될 것이라는 우려가 있었음 - 그 우려는 대체로 현실화되지 않았고, GitHub는 코드를 작업하고 공유하는 **de facto place**로 자리 잡음 - Hashimoto의 경험은 그 지위가 흔들릴 수 있음을 보여주며, Microsoft가 [Windows has serious quality problems]()를 인정한 시점과도 겹침 - Windows 품질 문제의 일부 원인으로 너무 많은 도구에 AI를 강제로 주입한 점이 나왔고, Hashimoto가 본 GitHub 흔들림 증가도 Microsoft의 AI 집착과 같은 시기에 나타남 ## Comments ### Comment 56621 - Author: neo - Created: 2026-04-30T23:33:54+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47946958) - 회사가 **CircleCI에서 GitHub Actions**로 모든 걸 옮기는 바로 그 시점에 GitHub 안정성이 무너져서 너무 화남 심지어 Azure Repos/Pipelines가 이보다 나았다는 게 제일 황당함 GitHub가 아직 **Azure 인프라**로 이전 중이라 어중간한 상태일 수 있다는 얘기도 들었지만, 신뢰가 생기지는 않음 - GitHub는 **vibe coding 프로젝트** 때문에 트래픽이 크게 늘었다고 주장함 핑계일 수도 있지만, 꽤 그럴듯하게 들리긴 함 - 2주 전에는 더 나은 AI 통합을 위해 **self-hosted GitLab에서 GitHub**로 옮기는 검토를 맡았는데, 어젯밤 GitHub 장애 때문에 그 프로젝트가 취소됐고 대신 자체 호스팅 서버를 업그레이드하기로 함 Forgejo 같은 걸 쓰고 싶기도 하지만 개발자가 12명 정도이고, 솔직히 혼자서만 써본 적 있음 - **Azure Repos**는 꽤 괜찮음 정말 기본적이라 망가질 게 별로 없고, 같은 이유로 티켓 시스템도 아주 좋아함 필요한 기능만 있고, 관리직들이 필드를 백만 개 추가해서 리포팅이나 burndown chart 같은 걸로 괴롭힐 수 없음 - **sunk cost fallacy**에 빠질 필요 없이 마이그레이션은 취소하면 됨 - 서로 상관없는 점들을 연결하는 걸 수도 있지만, **Azure로의 마이그레이션**이라는 말을 보니 이게 떠올랐음 [https://news.ycombinator.com/item?id=47616242]() [https://isolveproblems.substack.com/p/how-microsoft-vaporize...]() - **GitLab**도 딱히 낫지 않음 릴리스에서 심각한 버그는 무시하면서, 현실적 개선은 0인 멍청한 UI 수정에는 예산이 무한히 있는 듯함 - 정말 아쉬움 8~9년 전쯤 처음 GitLab을 쓰기 시작했을 때는 정말 좋아했고, 몇 년 뒤 회사가 GitHub로 옮겼을 때는 큰 퇴보처럼 느껴졌음 GitLab에는 작은 **UX 편의 기능**이 많았고 거친 부분은 있었지만 전체적으로 잘 설계된 것처럼 보였음 그런데 그 뒤로는 상황이 훨씬 나빠졌고, UX는 셀 수 없을 만큼 바뀌었으며 바뀔 때마다 더 나빠지는 듯함 거친 부분은 고쳐지지 않고 새 거친 부분만 계속 생김 최근 몇 년간 유용한 기능이 추가되거나 개선된 게 떠오르기 어렵고, GitHub도 엉망인 만큼 GitLab이 확실히 더 나은 대안이 되어 시장을 가져갔으면 했는데 정말 아쉬움 - 더 나쁘게는, self-hosted 버전에서 한 업데이트가 **마이그레이션을 망쳐놓고도 오류를 내지 않아서** 설치가 묘하고 미묘하게 깨졌음 며칠 동안 원인을 몰라 헤맸고, 다음 업데이트에서야 문제를 경고해줘서 repair command를 실행해 다시 정리함 사용자 약 10명, 저장소 최대 50개 정도의 아주 작은 서버였음 - 여러 계정의 **SSH 키**를 갱신하던 중 GitLab에 완전히 질려버렸음 GitHub, Bitbucket, Codeberg 등은 괜찮았는데 GitLab은 정말 버그가 많았고, Firefox에서 SSH 키를 업데이트하는 게 불가능했으며 GitLab-Firefox 호환성 버그라는 명확한 표시도 없었음 새 SSH 키 업로드를 Chrome으로 시도해봐야겠다고 떠올리기까지 거의 한 시간이 걸렸고, 그 뒤로 GitLab은 다시 건드리지 않겠다고 봄 - **Ghostty**가 GitHub를 떠난 최신 프로젝트가 되니 다음은 누가 떠날지 궁금해짐 모두가 다음 수요일까지 GitHub를 떠나 자기 Forgejo 서버를 띄울 거라고 보진 않지만, 사람들이 드디어 GitHub에서 벗어나는 걸 검토하기 시작했다는 점은 GitHub가 걱정해야 한다고 봄 - 여기서의 **고착 효과**는 말도 안 될 정도임 평균적인 소프트웨어 엔지니어는 VCS나 forge에 전혀 관심이 없고, 둘에 대한 지식도 매우 얕음 그냥 일하고 자기 삶으로 돌아가고 싶은 사람들에게는 크게 중요하지 않음 - 요즘 흐름을 잘 못 따라가고 있는데, 왜 사람들이 **GitHub를 떠나는** 건가? - 이미 HN 사용자가 **who-left-gh.net** 같은 걸 만들었나? 도메인은 비어 있음 - 나만 그런가, 아니면 **MSFT 인수** 이후로 이슈가 훨씬 나빠졌나? - 인수는 1년 전이 아니라 **8년 전**이었음 그동안 얼마나 커졌을까? 10배? 100배? 그 이상? - 인수 과정에서는 이런 일이 여러 번 생길 수 있음 어떤 회사가 뭔가를 사면, 그다음 문제는 그걸 누가 소유하느냐임 새 회사 안에서 누가 “계속 좋게 유지하기”를 책임질 것인가가 핵심이고, 인수 후 기존에 그 일을 하던 사람들이 남아 있어도 동기 문제는 별개임 Microsoft는 심각한 문제가 있음 최소 10개 회사를 접착제로 붙여놓고 Microsoft라고 부르는 듯한 빈틈이 보이고, Xbox 부서의 장애가 도구 부서에 악영향을 주거나 그 반대가 될 수 있는 **평판 리스크**도 큼 많은 항목에서 초점이 부족하고, 언론 발표를 멈춘 뒤 이 에베레스트 같은 **기술 부채**를 고치는 “service pack 2” 순간이 필요했음 - 이건 **vibe coding**과 더 관련 있어 보임 - 맞음, 물론이고, 더 최근에는 새 **CoreAI 조직** 아래에서도 그렇다고 봄: [https://www.businessinsider.com/microsoft-ai-coding-rivals-o...]() - 수십 년이 지나도 정책은 같음 **Embrace, extend, and extinguish** - “GitHub user 1299, 2008년 2월 가입”이라고 하는데, 자기가 **GitHub user #** 몇 번인지 어떻게 알 수 있나? - `curl [https://api.github.com/users/YOUR_USER_HERE]()`를 실행한 뒤 payload에서 id를 보면 됨 `"id": 2851` 또는 아바타 HTML 소스를 보면 됨: [https://avatars.githubusercontent.com/u/2851?v=4]() - 나는 15만 번대 후반이었음 솔직히 수백만 번대일 줄 알았음 - 프로필에서 이미지를 새 탭으로 열면 URL이 `/u/#` 형태임 나는 약 400만 번대임 - 자기 사용자 정보를 조회하면 **API 응답**에 나옴 - 지난 거의 20년 동안 수집한 사용자 활동 통계를 기준으로 보면, 꾸준하고 장기간의 작업량과 실제로 타인이 쓰는 소프트웨어를 매일 작성하는 면에서 나는 상위 1% 사용자이거나 그에 가까울 거라고 확신함 나도 GitHub의 꽤 이른 사용자지만 아주 초기 사용자는 아니고, GitHub 지표가 나빠도 여전히 배포하고 있음 소프트웨어 작성에는 **GitHub가 필요하지 않기 때문**임 Hashimoto의 코멘트는 불안정해 보이고 그가 평온을 찾길 바라지만, 그 사람이 그 사람이 아니었다면 이런 코멘트를 읽고 문제가 있다고 생각했을 것 같고, 그래서 실제로도 그렇다고 봄 - “나는 GitHub의 **non-git 기능**을 하나도 안 쓰니까, 그걸 쓰는 사람은 문제가 있다”는 식으로 들림 - “소프트웨어 작성에는 GitHub가 필요하지 않다”는 말은, 최근 신뢰성 문제가 있었던 기능들, 심지어 기본적인 협업 기능 일부까지 필요 없는 워크플로라면 GitHub가 애초에 그 작업에 맞는 도구인지도 의문임 그렇지 않다면 장애를 불평하는 사람들을 판단하는 건 꽤 주제넘고 불쾌하게 느껴짐 - “Hashimoto의 코멘트가 불안정해 보이고 그가 평온을 찾길 바란다”는 식의 **가짜 정신건강 걱정**으로 사람을 “disturbed”처럼 보이게 만드는 완전히 빗나간 인신공격은 HN에서 자주 보지 못했음 그런 건 주로 Reddit에서나 보던 방식임 - GitHub 다운타임은 **이슈 트래킹**, PR 병합, 기여, PR 리뷰 등 여러 작업에 문제가 됨 “자기 머신에서 코딩하는 걸 막는 게 아니다”라는 식으로 핵심을 놓칠 사람이 너무 예측 가능해서, 원문 블로그 글에서도 이미 그 지점을 선제적으로 다뤘음 누군가의 정신건강을 두고 하는 저런 역겨운 인신공격은 하지 말아야 함 - 처음에는 GitHub를 방어하려고 Hashimoto를 깎아내리는 줄 알았음 그런데 글을 읽고 나니 그의 감정적 반응이 상황과 잘 맞지 않는 것처럼 보이긴 함 그래도 프로젝트 규모에 따라 이슈 대응, 리뷰 처리 등으로 **GitHub가 풀타임 일**이 될 수 있고, PR 설명과 코멘트를 커밋 메시지 대신 문서 일부로 쓰는 것도 드문 일이 아님 그래서 GitHub 가용성은 많은 회사에 정말 큰 장애가 될 수 있음 - 지금 이 순간에도 **GitHub API** 문제가 진행 중임 - 핵심 질문은 최고의 **대안**이 무엇이냐임 - 우리는 **self-hosted GitLab**을 씀 무료 버전이어도 큰 불만 없음 - 코드를 저장할 곳이라면 그냥 GitHub에 두면 됨 공개 코드는 전부 거기에 미러로 올려도 괜찮음 테스트를 돌릴 곳이라면 **자체 인프라**를 만들면 됨 그 어느 때보다 쉬운데, 왜 그런 블랙박스에 의존하나? - 나는 취미나 사이드 프로젝트에만 쓰지만, 전문 업무에서 의존하려는 사람들이 왜 화내는지는 이해됨 - **Forgejo**가 있음 GitLab보다 훨씬 빠름 - 기업이라면 **GitHub Enterprise**가 있음