▲

나만의 GitHub를 만든다면

 (matduggan.com)
6P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 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을 열고 로봇 검사를 기다리며 하루 종일 쓰는 도구가 언제부터 사용자를 위해 만들어지지 않게 되었는지 묻게 됨

함께 보면 좋은 글 β

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

  • PR 승인은 너무 이분법적이라는 비판은 모순처럼 보임. PR 승인은 권한 부여라서 결국 불리언일 수밖에 없고, 코드를 병합할 수 있거나 없거나 둘 중 하나임
    여기서 말하는 건 싫어하는 코드를 승인하면서 “나중에 다시 봐야 함...” 같은 말로 마음을 조금 편하게 만드는 장치에 가까움. 그냥 새 티켓을 열면 됨

    • Gerrit에는 -2부터 +2까지 있음
      -2: 나쁜 아이디어니 하지 말 것
      -1: 좋은 아이디어지만 개선 필요
      +1: 좋아 보이나 승인할 지식이나 권한이 부족함
      +2: 승인
    • “이 3개 커밋은 지금 승인하고 병합, 이 2개는 재작업 필요”라고 말하는 버튼이 있었으면 함
    • 코드가 승인됐지만 병합되지는 않는 경우도 있음. 이때 관리자가 변경을 더해 수동으로 적용하고, 그 변경 커밋의 공동 저자로 PR 작성자를 올릴 수도 있음
    • 더 큰 문제는 GitHub가 이슈 추적 시스템과 너무 분리돼 있다는 점으로 보임. 계속 수동으로 동기화해야 하는 부담이 크고, Linear가 어느 정도 해주긴 하지만 이상적이진 않음
    • “코드를 병합할 수 있거나 없거나 둘 중 하나”라니, 직관주의자는 아닌 듯함

  • “Y도 그중 일부를 한다”는 말은 맞지만, tangled.org는 실제로 그 대부분을 함

    1. 버전 관리 시스템으로 JJ 사용: tangled는 jj change-id로 누적 PR을 지원함. https://blog.tangled.org/stacking tangled 자체도 이 방식으로 많이 만듦: https://tangled.org/tangled.org/core/pulls
    2. Raspberry Pi에서 오래 돌릴 수 있는 forge: 이것도 가능함. git 서버 shim은 매우 가볍고, git 저장소 위의 XRPC 계층과 sqlite3 데이터베이스일 뿐임. RAM 512MB짜리 RISC-V 보드에서 돌리는 사람도 있음
    3. Actions는 중요하고 로컬 머신에서 실행 가능해야 함: 이 요구는 약간 빗나갔다고 봄. 밀폐적이고 어디서나 실행되며 교차 빌드를 처리하는 건 대체로 빌드 시스템의 일임. 그런 빌드 결과를 forge 자체로 “승격”할 수 있으면 정말 좋을 것 같음
    • 워크플로에 핵심인 데이터를 호스팅하는 데 Raspberry Pi가 나온 게 의외임. 예전에 SD 카드 손상으로 너무 많이 당했는데, 요즘은 NVME 드라이브를 쓰는지 궁금함
    • 맞음, 그건 빌드 시스템의 일임. 다만 사람들이 로컬 실행 가능한 Actions로 풀고 싶어 하는 문제는 대부분 빌드 실패 자체가 아니라 전체 통합임
      YAML 정의, 비밀값, 정확히 어떤 명령을 실행하는지, 도구와 캐시를 어떻게 복원하는지 같은 부분임. 빌드 시스템이 일부 처리할 수도 있지만, GHA에서 제공하는 원시 기능은 매우 빈약함. 결국 전체 시스템을 다른 곳에서 돌려야 하는 문제로 귀결되기 때문에, 이런 시스템들은 대개 시행착오 방식이 되는 듯함
    • 맞고, 더 나아가 밀폐 빌드 개념을 확장해서 로컬이나 계산 자원이 있는 어디서든 쉽게 돌릴 수 있으면 좋겠다는 뜻임
      여기서 부르는 근본 문제는 변경, 커밋, 네트워크 호출이 끼어 있는 순환 속에서 CI가 초록불이 될 때까지 돌리는 일이 매우 고통스럽다는 점임. 이 반복을 피하는 최고의 방법은 버그를 절대 쓰지 않는 것뿐임! 농담임
    • Radicle과 Tangled는 둘 다 핵심을 놓침. 이들은 공개 협업 작업용인데, 비공개 저장소는 어떻게 할 건가? 많은 사용자가 사이드 프로젝트를 하고, 이를 위해 GitHub private을 씀
      GitHub를 배우면 공개 프로젝트도 GitHub에서 시작하게 됨. 사이드 프로젝트용 비공개 저장소를 만들 수 있게 해주기 전에는 널리 쓰이기 어려움. 사람들이 원하는 건 비공개 저장소를 만들고 몇 달 떠났다가 돌아와도 그대로 기다리고 있는 것임
    • 와, Tangled의 jujutsu 지원이 정확히 찾던 것임. 이번 주말은 셀프 호스팅 세팅으로 사라지겠음

  • 제한된 이력만 클론하고 필요할 때 과거 데이터를 가져오고 싶다면 blobless clone을 쓰면 됨
    git clone --filter=blob:none
    이력은 가져오고 blob은 필요할 때만 가져옴. GitHub에 좋은 글이 있음: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • 해법이 문제가 되면 파괴적 혁신의 기회가 열림. 요즘 이 이야기가 꽤 많고, GitHub가 방향을 고치기 전에 새로 뜨는 많은 대안 중 하나라도 탄력을 받을지 궁금함

    • 문제는 Microsoft가 AI에 완전히 올인했다는 점이라고 봄. 되돌아갈 길이 없고, GitHub도 그 영향을 받을 수밖에 없음
      Microsoft 홍보는 AI가 모든 것의 해법이라고 말하겠지만, 현실에서는 같은 문제가 계속 반복될 것임. GitHub 서비스 장애가 AI와 직접 관련 없을 수는 있어도, Microsoft의 전략이 이미 바뀌었기 때문에 대부분의 판단은 AI 중심의 하향식 통제에 맞춰질 것임. GitHub를 쓰는 사람들의 워크플로가 깨지는지는 Microsoft에겐 기껏해야 부차적인 관심사이고, 그 문제는 계속 다시 나타날 것임. 3개월쯤 조용할 수는 있어도 머지않아 GitHub가 쇠퇴한다는 새 드라마가 100% 또 나올 거라고 봄. Ghostty가 마지막은 아닐 것임. 대안이 나올지는 흥미롭지만, 그 대안들이 구리면 안 되는데 많은 웹사이트들이 꽤 별로임
    • 내 도구는 직접 만들고 있음. 사람들도 자기 도구를 직접 만들어야 한다고 생각함
      미래에는 유료 소프트웨어나 오픈소스 소프트웨어 대신 코드 forge를 위한 요구사항 문서 묶음, 일종의 레시피를 받게 될지도 모름. 각자 직접 굽고, 자기 용도와 취향에 맞게 바꾸는 방식임

  • 훨씬 단순한 git 서비스에 시장의 빈틈이 있다고 봄. 필요한 건 다른 사람들이 볼 수 있도록 프로젝트를 push할 원격 호스트뿐이고, PR이나 Actions 같은 건 딱히 원하지 않음
    로컬에서 빌드한 바이너리 자산을 올리는 “릴리스” 기능 정도는 있으면 좋겠음. 포크는 사람들이 저장소를 클론해서 새 프로젝트로 올리면 처리 가능함

    • 필요 없는 기능을 끄면 이 중 많은 걸 해결할 수 있지 않나? 방금 내 Forgejo 인스턴스를 보니 저장소별로 Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis를 끄는 옵션이 있음
    • https://sr.ht/
    • 그럼 다시 cgit으로 돌아가는 건가?

  • 리뷰 데이터도 소스처럼 git 저장소에 넣을 수 있다는 주장은 꽤 설득력 있음
    알려진 접두사를 붙여 리뷰마다 브랜치를 두면 아주 쉽게 구현할 수 있지만 기본 브랜치 이름공간이 금방 지저분해질 것임. git namespaces로 메인 이름공간과 분리하거나, 각 리뷰 브랜치의 끝 커밋 ID만 담는 .reviews 같은 특별 브랜치를 둘 수도 있음. 누군가 충분히 관심을 갖고 명세와 실사용 가능한 구현을 만들면 사람들이 채택하기 시작할지도 모름. GitHub와 여러 forge가 이 방식을 택하지 않은 이유는 리뷰 메타데이터를 자기 생태계 안에 묶어두는 것이 플랫폼 가치이기 때문일 것 같음. 누구나 원하는 로컬 도구로 남의 코드를 리뷰할 수 있다면 공급자 고착이 줄어듦. 다만 접근 제어나 저장소 간 리뷰처럼 리뷰 메타데이터를 다른 저장소에 두고 싶은 다른 이유도 있겠음

  • PR이 아니라 차이를 리뷰하는 Gerrit 워크플로를 정말 좋아함. 하지만 gitea 같은 것과 비교하면 이슈, 프로젝트 계획 등 git 호스팅에서 기대하게 된 나머지 기능이 부족해서 많은 사람에게 설득하기 어려워 보임
    Phabricator 같은 괜찮은 차이 리뷰 플랫폼이 있으면 좋겠지만 아쉬움

    • 그런데 왜 Gitea는 그걸 추가하지 않을까? 이미 나머지는 다 있는데, 왜 이런 forge들은 항상 GitHub 복제판에 머물고 더 나아가지 않는지 모르겠음

  • PR, 리뷰 댓글, 이슈 같은 모든 메시지 저장의 기본 형식으로 RFC2822를 쓰고, 메시지를 표시할 때는 CommonMark로 꾸미면 된다고 봄
    모든 메타데이터는 헤더에 넣고, Message-ID/In-Reply-To/References 헤더로 서로 연결할 수 있음. 이렇게 잘 정의된 형식을 쓰면 모든 메시지를 어떻게 저장하고 전송할지 선택할 수 있음. git 저장소에 넣거나, 이메일을 쓰거나, 다른 맞는 방식을 쓰면 됨. 코드 리뷰는 개인적으로 Gerrit이 GitHub 등보다 훨씬 낫다고 생각함. CI는 가능한 한 밖에 두고, 파이프라인을 시작하고 결과를 표시하며 병합 허용 여부를 결정하는 훅 정도만 두고 싶음

    • GitHub의 매력 중 하나는 코드 리뷰, 소스 탐색, 티켓 추적, CI 네 가지를 통합한다는 점이라고 봄
      네 가지 모두에서 대단히 잘하지는 못하지만, 한데 묶는 일은 잘함. Gerrit이 더 나은 코드 리뷰 모델이라는 데는 동의하지만, 나머지 세 조각이 없으면 제품이 되지 않음. Google에서 Gerrit을 매일 쓰던 때에도 코드 검색과 코드 리뷰, CI 사이의 빈약한 통합이 불만이었음. Google3/Critique/Forge 같은 Google 내부 도구는 이 모든 걸 훨씬 잘 엮어줬음

  • 이메일 기반 워크플로의 장점 하나가 떠오름. 이메일을 보기 시작했다면 보통 그럴 마음 상태일 때이고, 그 상태에서는 다른 방해가 없을 거라고 예상하므로 더 집중하게 됨
    알림의 문제는 뜨는 대로 치우고 싶어지는 힘이 있다는 것임. 하지만 그 순간에 그걸 처리할 에너지가 있다는 보장은 없음. 웹의 알림 시스템 대부분은 이메일 클라이언트가 수십 년 전에 이미 달성한 것을 서투르게 흉내 낸 것처럼 보임. 어쩌면 옛사람들이 이메일을 쓴 게 정말 맞았던 것 같음

    • 이메일도 알림인데, 도착하는 순간 어떻게 그걸 받을 기분이 된다는 건지 더 명확히 설명해줄 수 있나

  • Microsoft가 GitHub를 흡수했을 때 이미 많은 사람이 짜증났음. 다만 현실적으로 대안들이 자주 별로였음. Sourceforge는 이슈 만들기가 끝없이 짜증나고, GitLab은 Sourceforge보다는 낫지만 거기서도 이슈 만들기가 싫음. Codeberg는 최근 UI가 바뀐 것 같지만 여전히 꽤 불편함
    GitHub가 처음에 잘한 건 UI와 GitHub를 쓰는 사람들에게 초점을 맞춰 일을 쉽거나 더 쉽게 만든 점임. 다만 전부 잘한 건 아니고, 위키 지원은 끔찍하다고 봄. 너무 별로라 위키는 거의 쓰지 않음. 정말 큰 문제는 상업적 이해관계, 즉 사적 이해관계라고 생각함. Microsoft는 한 예일 뿐이고, 비슷한 사이트들 거의 어디에나 있는 문제임. 예전에 xz 백도어 유틸 관련 이슈 토론을 예로 들었고 나도 토론에 참여했는데, 다음 날 Microsoft가 전부 내렸음. Microsoft였는지 저장소 소유자였는지는 중요하지 않음. 문제는 개인이 잠재적으로 유용한 정보를 너무 쉽게 검열할 수 있다는 점임. 그 이슈 토론은 유용했고 검열됐음. 당시 정보가 전부 복원되지는 않았던 것으로 기억함. 누군가 미러했을 수도 있지만 링크는 못 봤음. 이는 하향식 통제가 정말 해로울 수 있음을 보여줌. 솔직히 Microsoft를 얼마나 신뢰할 수 있나? 탈중앙적이고, 안정적으로 잘 동작하며, 기본 UI가 좋고, 단순하거나 최소한 좋은 워크플로가 필요함. 사적 행위자가 모두를 인질로 잡는 상황도 피해야 함. 어떻게 풀지는 전혀 모르겠고, 여러 접근이 동시에 필요할지도 모름. 웹은 변했고, 특히 거대 초대형 기업의 사적 이해관계가 지난 10~15년 동안 상황을 훨씬 나쁘게 만들었다고 느낌. 바뀌어야 함

    • 문제는 SaaS 제품 운영에 돈이 많이 든다는 점임
      거대 기업은 그 비용을 댈 수 있지만, 예산이 작은 개발자가 많이 모여도 같은 일을 할 돈은 없음. 그래서 어떤 상업 프로젝트든 결국 평균적인 사람보다 거대 기업의 이해를 더 지원하는 방향으로 갈 수밖에 없음
답변달기