▲

HashiCorp 공동 창업자, GitHub가 '더 이상 진지한 작업을 위한 장소가 아니다'라고 말해

 (theregister.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 속도와 성숙한 소프트웨어 범주에 새로운 요소를 더한 terminal emulator가 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 집착과 같은 시기에 나타남

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 회사가 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 # 몇 번인지 어떻게 알 수 있나?

  • 지난 거의 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가 있음
답변달기