나만의 GitHub를 만든다면

• GitHub, GitLab, Gitea 같은 현대 forge는 GitHub식 모델을 공유하지만, 실제 업무의 핵심은 git보다 PR, Actions, Issues, Releases 같은 forge 기능 안에서 더 많이 일어남
• 새 forge는 커밋 이후가 아니라 push 전에 피드백을 주는 강제 pre-commit hook을 원격 실행해, Feature, fix, actually fix, asdfasdf 같은 반복 커밋을 줄일 수 있어야 함
• PR 승인은 승인/거부의 이분법을 넘어 Gerrit처럼 약한 승인과 나중에 다시 볼 표시를 지원하고, 작성자가 유지관리자이며 LLM이 낮은 위험으로 판단한 작은 변경은 더 유연하게 통과시킬 수 있어야 함
• Stacked PR은 forge와 VCS의 일급 기능이어야 하며, 로컬 저장소는 코드뿐 아니라 PR 승인과 이슈까지 포함한 전체 저장소 상태를 표현해야 함
• 원하는 조합은 VCS로 JJ, 작은 단위로 호스팅 가능한 새 forge, 서명·SHA·오프라인 실행을 지원하는 Actions이며, 단일 거대 forge인 GitHub가 기본값인 시대에 아직 뚜렷한 대체품은 없음

현대 forge의 문제

• GitHub, GitLab, Gitea는 세부 차이는 있지만 거의 같은 설계 모델을 따르며, GitHub가 만든 업계 패턴을 다른 도구들이 옮겨온 형태에 가까움
• 현재 forge의 기능 대부분은 git 자체와 직접적인 관계가 거의 없고, 클라이언트는 실제 사용 방식과 동떨어져 있음
• git은 커널 개발 같은 환경에 잘 맞는 분산 버전 관리 시스템으로, 이메일로 패치를 유지관리자에게 보내고 유지관리자가 자신의 영역을 관리하며 병합 여부를 판단하는 높은 신뢰 기반 워크플로에 적합함
• 하지만 대부분의 직장에서는 git이 중앙 forge에 저장된 저장소에서 코드를 pull/push하는 수단에 가깝고, 중요한 작업은 forge 안에서 일어남
  • Pull Request는 four-eyes 원칙을 강제하는 수단이 됨
  • GitHub Actions는 Pull Request에서 테스트와 린팅을 실행해 기능성과 조직 요구사항 충족 여부를 확인함
  • forge 안의 사용자 신원은 사용자를 검증하는 기준이 됨
  • Issues는 코드 문제 추적에 쓰이고, Releases는 사용자가 다운로드할 릴리스를 만드는 데 쓰임
• 이런 워크플로에는 git 자체보다 git 위에 얹힌 forge 기능이 더 많으므로, 새 forge를 만든다면 git이라는 제약에 반드시 묶일 이유가 줄어듦

새 forge에 바라는 기능

• 피드백은 커밋 이후가 아니라 커밋 이전에 와야 함

  • 흔한 PR에는 Feature, fix, fix, actually fix, please, asdfasdf 같은 커밋이 이어짐
  • 피드백 루프가 커밋 이후에 오면 사용자는 늦은 시간까지 고치며 고통받게 됨
  • forge에서 원격으로 작업을 실행하는 강제 pre-commit hook을 제공해, 사용자가 push하기 전에 피드백을 받을 수 있어야 함

• PR 승인은 너무 이분법적임

  • 현재 PR은 승인되었거나 승인되지 않은 상태로 나뉘지만, 실제 코드 리뷰에는 그 사이의 영역이 많음
  • “일단 괜찮고 나중에 처리하자” 같은 인간적인 반응도 버튼으로 표현될 수 있어야 함
  • Gerrit은 이 부분에서 더 나은 모델을 제공함
  • 유지관리자가 약하게 승인할 경우, 나중에 다시 볼 수 있도록 표시할 수 있어야 함

• PR 정책은 더 유연해야 함

  • 모든 변경에 네 눈 검토가 필요한 것은 아니며, 특히 LLM이 존재하는 환경에서는 더 그렇다고 봄
  • 네 줄짜리 PR에 시니어 엔지니어가 LGTM을 남기기만 기다리는 비용은 지나치게 큼
  • 작성자가 유지관리자이고 LLM이 낮은 위험 또는 무위험으로 판단한다면 바로 진행할 수 있도록 더 쉽게 제어할 수 있어야 함

• Stacked PR은 일급 기능이어야 함

  • Stacked PR은 리뷰와 이해를 더 쉽게 만듦
  • VCS 외부 도구를 통한 부가 기능이 아니라 forge와 VCS에서 일급 시민으로 다뤄져야 함

• forge는 모든 것을 하려 해서는 안 됨

  • 이슈 추적은 필요하지만 Kanban 보드는 아마 필요하지 않음
  • Wiki도 필요성이 의심됨
  • 모든 기능을 넣는 도구는 결국 품질이 떨어지며, 기능 추가는 쉬워도 유지보수 비용은 채택률과 무관하게 계속 발생함
  • 누군가 어딘가에서 쓰기 시작하면 그 기능에 묶이게 됨

• 호스팅 단위는 너무 큼

  • GitHub Enterprise 운영은 큰 작업이고, GitLab 운영도 비교적 큰 부담임
  • 이 제품들은 움직이는 부분이 많은 복잡한 시스템임
  • 더 작은 개별 호스팅 단위를 만들고, 이를 연결해 하나의 조직을 구성할 수 있어야 함
  • 전역 federation이 아니어도 되고 조직마다 계정을 만들어야 해도 괜찮지만, 조직은 “이 12대의 Raspberry Pi가 내 조직”이라고 말할 수 있을 만큼 유연해야 함

• 로컬 저장소는 코드만이 아니라 전체 저장소를 표현해야 함

  • 로컬 복사본은 코드뿐 아니라 PR 승인과 이슈 같은 저장소 전체를 표현해야 함
  • 코드를 체크인하는 동일한 VCS에서 PR을 승인할 수 있어야 함
  • 로컬 파일을 훑어보듯 이슈를 살펴볼 수 있어야 함

• 항상 전체 히스토리 저장 비용을 치를 필요는 없음

  • 팀과 제대로 일하려면 온라인 상태가 필요하므로, 항상 모든 저장 비용을 부담하게 만들 필요는 없음
  • VCS와 forge가 함께 작동해야 함
  • 저장소를 clone할 때는 제한된 히스토리만 받고, 과거로 돌아가려 할 때 워커를 띄워 필요한 내용을 VCS에서 가져오면 됨
  • 사용자가 언젠가 전체 프로젝트 히스토리로 forge를 재구축할 수도 있다는 가정만으로 거대한 clone 요청을 forge에 계속 보내게 할 필요는 없음

• Actions는 서명되고 SHA가 붙으며 오프라인에서도 쓸 수 있어야 함

  • Actions는 중요하므로 서명, SHA, 오프라인 사용 가능성이 필요함
  • 원한다면 모든 action의 tarball을 받아 저장소에 넣고, checkout action을 외부에서 가져오지 말고 로컬 저장소 안의 것을 쓰라고 시스템에 지시할 수 있어야 함
  • latest를 지정하면 현재 Dependabot처럼 최신 tarball을 저장소에 넣는 PR을 열어주는 방식으로 동작해야 함
  • Actions는 원한다면 같은 VCS를 통해 로컬 머신에서도 실행할 수 있어야 함

이미 일부를 하는 도구는 있지만 조합이 필요함

• 이런 요구사항의 일부를 수행하는 도구는 이미 많이 있음
• 필요한 것은 이 도구들을 가져와 함께 묶고 제대로 맞추는 일임
• 원하는 조합은 VCS로 JJ, forge로 새 시스템, 그리고 사용자가 Raspberry Pi 하나를 forge로 오래 만족스럽게 쓸 수 있다는 기대임
• 새 forge는 객체 저장소, shallow clone, LLM bot의 지속적인 요청 같은 현대적 개념을 중심으로 설계되어야 함

GitHub가 기본값인 시대의 균열

• GitHub가 잘하고 있었다면 이런 구상을 쓸 필요가 없었을 것임
• GitHub는 기본값이고, 기본값을 넘어서자고 설득하는 일은 보통 시간 낭비에 가까움
• 2026년까지 forge를 쓴다면 모두가 쓰는 도구를 선택하지 않을 아주 강력한 이유가 필요했음
• 최근까지 다른 forge들은 실제로 원하는 선택지가 아니라 대체재처럼 여겨졌음
• 하지만 단일 거대 forge가 무너지고 있으며, 아직 대체품은 만들어지지 않았음
• 돈이 있는 사람들은 로켓에 바쁘고, 취향이 있는 사람들은 본업에 바쁘며, 나머지는 자정에 asdfasdf라는 PR을 열고 로봇 검사를 기다리며 하루 종일 쓰는 도구가 언제부터 사용자를 위해 만들어지지 않게 되었는지 묻게 됨