내가 직접 GitHub를 만들 수 있다면
Source: Hacker News
위에 제공된 소스 링크만으로는 번역할 본문이 없습니다. 번역을 원하는 전체 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.
내 억달러 포지 아이디어
친구와 나는 부자가 된다면 무엇을 할지 이야기하는 게임을 합니다. “주택 담보 대출을 갚을 정도”의 부가 아니라, 잠수함을 소유했지만 한 번도 들어본 적 없는 사람 같은 부, 세 번째 아내가 스킨케어 라인을 운영하는 사람 같은 부. 기술 거물 수준의 부 — 와이오밍에 별장을 살 수 있을 정도의 돈이면서, 같은 회색 티셔츠를 입고 국회 청문회에 참석할 자신감까지 주는 부.
오랫동안 내게 있었던 꿈 중 하나는 새로운 포지를 만드는 것이었습니다. 이 글을 쓰게 된 계기는 Ghostty가 GitHub를 떠난다는 좋은 글을 읽고 난 뒤였지만, 몇 년 동안 써오고 이야기해 온 내용이기도 합니다. GitHub가 핵심 업무를 수행하는 데 점점 못 미치게 된 상황을 보니, 억만장자적인 포지(그런 포지라면) 구상이 어떤 모습일지 적어 보는 재미있는 기회가 될 것 같았습니다. 이 포지는 나이 든 연예인들로 가득 찬 “음경 로켓”이 적을 것입니다.
현대 포지의 문제점은 무엇인가?
GitHub, GitLab, 그리고 Gitea(내가 가장 많이 사용한 세 가지)는 사실상 동일한 설계 방식을 기반으로 합니다. 차이는 있겠지만, GitHub가 업계 표준을 정하고 그 기능들이 다른 두 서비스에 다양한 성공률로 이식된다고 볼 수 있습니다. 이 모든 서비스의 문제는 Git가 하지 않는, 여러분이 필요로 하는 기능들을 추가하려고 설계되었다는 점입니다.
Git는 설계된 대로라면 훌륭하지만, 대부분 사람들이 사용하는 방식과는 다릅니다. Git는 커널 개발에 최적화된 도구입니다. 패치를 이메일로 유지보수자에게 보내는 방식을 전제로 하는 분산형 버전 관리 시스템이죠. 유지보수자는 자신의 파트를 관리하고, 의미 있는 변경만 병합하며, 나머지는 병합하지 않는 높은 신뢰 환경을 전제로 합니다. 2010년형 노트북을 일주일에 한 번만 인터넷에 연결한다 하더라도 이런 워크플로우에서는 의미 있는 기여를 할 수 있습니다.
하지만 대부분의 직장에서는 Git가 사실상 중앙 저장소(포지)에서 pull·push 하는 방법에 불과합니다. 중요한 일은 포지 안에서 일어나고, 클라이언트에서는 거의 일어나지 않죠.
- Pull Request는 네 눈 원칙(4‑eyes principle)을 적용하는 방법입니다.
- GitHub Actions는 해당 Pull Request에 대해 테스트와 린팅을 실행해 기능성과 조직 요구 사항을 충족하는지 확인하는 수단입니다.
- 포지와 연결된 사용자의 신원은 그 사용자를 검증하는 방법입니다.
- Issues를 통해 코드와 관련된 이슈를 추적하고, Releases를 통해 사용자에게 배포 파일을 제공합니다.
이 워크플로우에는 Git 자체가 많이 들어 있지 않으며, 대부분 Git 위에 얹힌 형태라고 할 수 있습니다.
아래는 내가 현대 포지에서 보고 있는 주요 문제이며, 해결하고 싶은 부분들입니다.
| # | 문제 | 기대하는 개선 |
|---|---|---|
| 1 | 작업 순서가 잘못됨 – 피드백이 커밋 후에 온다, 전에 오지 않는다. | 원격 포지에서 작업을 실행하고 푸시 전에 피드백을 제공하는 사전 커밋 훅을 강제 적용. |
| 2 | PR 승인 방식이 너무 이분법적 – PR은 승인되든 안 되든이다. | Gerrit 모델처럼 “약한 승인”, “추후 검토 필요” 등 중간 단계(옵션)를 두어 유지보수자가 PR을 나중에 검토하도록 표시할 수 있게 함. |
| 3 | PR이 지나치게 경직됨 – 모든 변경은 4‑eyes 검증을 통과해야 한다, 비록 LLM이 위험을 안전하게 평가할 수 있더라도. | 맞춤형 승인 정책: 작성자가 유지보수자이고 LLM이 변경 위험을 낮다고 판단하면 자동 병합을 허용. |
| 4 | 스택형 PR이 더 좋다 – 리뷰와 이해가 쉬워진다. | 스택형 PR을 부가적인 외부 도구가 아니라 VCS의 핵심 기능으로 만든다. |
| 5 | 포지는 모든 일을 다 해서는 안 된다 – 이슈 트래킹은 괜찮지만, 칸반 보드, 위키 등은 종종 저품질 잡동사니가 된다. | 핵심을 가볍게 유지하고, 사용자가 원치 않는 구성 요소를 유지하도록 강요하는 “기능 남용(feature creep)”을 피한다. |
Source: …
forever. | | 6 | The standard unit of hosting is too large – GitHub Enterprise and GitLab require heavyweight infrastructure. | 작은, 조합 가능한 호스팅 단위를 제공하여 서로 연결해 조직을 구성할 수 있게 합니다 (예: “이 12개의 라즈베리 파이가 내 조직이다”). | | 7 | Local clone should represent the entire repo, not just the code. | 사용자가 동일한 로컬 VCS 뷰에서 코드를 체크인하듯 PR을 승인하고 이슈를 탐색할 수 있게 합니다. | | 8 | Don’t force constant storage costs – I need to be online all the time, but I shouldn’t pay for full history on every clone. | 기본적으로 얕은 히스토리를 클론하고, 필요에 따라 백그라운드 워커가 더 깊은 히스토리를 지연 로드하도록 합니다. | | 9 | Actions need to be signed, SHA‑hashed, and usable offline – reproducibility and security are essential. | 라이브 연결 없이도 실행 가능한 서명된, 결정론적 액션 메커니즘을 제공합니다. |
…and the list continues.
These are the pain points I’d like to address in a next‑generation forge that respects both the power of Git and the realities of modern development workflows.
# Action Tarballs and a Self‑Hosted Forge
I should be able to get tarballs of all my actions, stick them in the repo, and tell my system “don’t go anywhere for checkout action, that’s right here.”
If I say **latest**, have that work like Dependabot does now—opening a PR to put the latest tarballs in my repo. Actions are critical, and they should be runnable on my local machine through the same VCS if I want to.
### Well Y Does Some Of That
Absolutely. There are a lot of tools that do parts of this. I want someone to take them, put them all together, and fit them up. I want **JJ** as the VCS, I want this as the forge, and I want the expectation that I, as a user, could live happily with a Raspberry Pi as a forge for a long time. I want those forges designed around modern concepts like object storage, shallow clones, and getting constantly hammered by LLM bots.
Now, in a universe where GitHub was doing a good job, I wouldn’t even bother writing this up. GitHub is the default, and talking to people about overcoming the default is usually a waste of time. Heinz is the default ketchup; when I order a Coke I don’t want a Pepsi. If I’m going to use a forge up until 2026, there would have to be an amazing reason for me not to choose the one that everyone uses. Up until recently, other forges have been like sweet‑potato french fries—that is, never the thing you actually want.
But we live in a world where the monolithic forge is breaking down and nobody has built the replacement. The people with the money are busy with the rockets. The people with the taste are busy with their day jobs. And the rest of us are opening PRs titled “asdfasdf” at midnight, waiting for a robot to check them, wondering when the tool we spend our whole working lives inside stopped being built for us.
If I ever get the submarine money, I’ll let you know.