Hacker News 의견

• 몇 년 동안 GitLab을 셀프호스팅 대안으로 써왔음. 마음에 들지만 리소스 소모가 심함
  최근에는 Codeberg 팀이 만든 Forgejo를 테스트 중인데, 정말 훌륭함
  가장 큰 차이는 메모리 사용량임. GitLab은 Ruby on Rails 기반이라 여러 서비스가 동시에 돌아가지만, Forgejo는 Go로 작성된 단일 바이너리 구조임
  GitLab은 16GB VM의 메모리를 점점 다 써버리지만, Forgejo는 서버와 runner를 함께 돌려도 300MB 정도만 사용함
  GraphQL은 없지만 REST API가 충분히 괜찮아 보임
  gitea와 forgejo의 차이를 잘 모르겠는데, Forgejo의 비교 문서를 보니 2022년에 거버넌스 문제로 soft fork된 것 같음

  • 우리 스튜디오는 약 50명의 사용자가 매일 git을 쓰는데, 2년 전 Forgejo로 완전히 이전했음
    Go 기반의 단순한 구조라 유지보수와 비용이 매우 적음. 내부 툴도 Forgejo 위에 직접 구축했음
    온프레미스 호스팅이라 인터넷이 끊겨도 개발과 CI가 멈추지 않음. 패키지 매니저 캐시도 지원해서 의존성 관리가 쉬움
  • 유지보수 편의성은 gitea가 압도적임. 5년 넘게 쓰고 있는데, 업그레이드는 새 버전 pull 후 데몬 재시작으로 끝남
    GitHub보다 다운타임이 10배 적었음, 그것도 대부분 계획된 점검이었음
    GitHub의 가용성이 더 낫다고 주장하는 글을 보면 웃음이 나옴
  • 개인 프로젝트라면 단순히 SSH 서버와 파일 시스템만으로 충분하다고 생각함
    새 저장소를 만들 때 git init --bare로 끝나고, 백업도 자동으로 돌아감
    혼자 개발한다면 UI가 굳이 필요 없다고 느낌
  • Forgejo Actions 기본 개념 문서를 보면 CI 시스템이 잘 정리되어 있음
    GitHub Actions보다 GitLab식 CI가 훨씬 낫다고 생각함, GitHub는 인기에 힘입어 표준이 되었지만 설계가 아쉬움
  • 더 미니멀한 대안을 원한다면 Gerrit도 있음. Java 앱으로 외부 DB 의존성이 없고, 설정과 런타임 정보를 git repo에 저장함
    공유 파일시스템만으로도 확장과 백업이 간단함

• 지역에서 수학 동아리를 운영하는데, 아이들이 LaTeX와 Python 과제를 제출할 때 Forgejo를 사용함
  로그인 관리와 비밀번호 초기화가 쉬워서 교육용으로도 매우 유용함

• GitHub의 푸시 알림 모델이 싫어서 직접 확인할 때만 업데이트를 보고 싶다는 의견에 공감함
  이메일 필터링을 이용하면 푸시 알림을 풀 모델처럼 바꿀 수 있음. 전용 폴더에 알림을 모아두고 필요할 때만 보면 됨

  • 그래도 불만족스럽다면 GitHub UI의 자체 알림 기능을 쓰면 됨. 사실상 문제를 찾기 위한 문제처럼 느껴짐

• 단순한 버그 트래커 ‘buggy’ 를 직접 만든 사람의 이야기가 흥미로움. Markdown을 파싱해 HTML 페이지를 생성하는 C 도구라고 함
  해커 정신이 살아있음

  • 하지만 그런 접근은 거의 아무도 하지 않을 것 같음. 나였다면 오히려 문제만 늘어날 것 같음
  • 장단이 모두 있는 접근임

• “푸시 모델”과 “풀 모델”의 차이를 묻는 질문이 있었음

  • Source Hut이나 Linux 커널처럼 이메일 기반 워크플로우를 말하는 것 같음. IMAP으로 패치를 로컬에 가져와 오프라인에서도 작업 가능함
  • 푸시는 ‘지금 바로 하라’는 식의 시간 압박이 있고, 풀은 내가 정한 주기에 맞춰 확인하는 시간 관리 방식의 차이임

• 지금은 여러 GitHub 대안이 쏟아지는 분산기(디아스포라) 단계라고 생각함
  몇 달 안에 주류가 하나로 정리될 수도 있다고 봄. 유명 기업이나 인물이 새 플랫폼을 내놓으면 시장을 주도할 가능성도 있음

  • 이런 흐름은 10년 전부터 있었음. 예전엔 GitLab으로 옮기던 시기였고, 지금도 GitHub의 발견성(discoverability) 은 여전히 독보적임
    GitHub를 떠나는 프로젝트는 극소수라 아직은 이르다고 봄
  • 개발자마다 협업 방식이 다르기 때문에 하나의 솔루션으로 수렴하긴 어려움
    오히려 재분산(re-decentralization) 이 일어나고 있음. 각자 통제권, 관할권, 워크플로우에 맞는 forge를 선택하는 시대임
  • 앞으로는 GitHub처럼 중앙집중형이 아닌 연합형(federation) 구조로 가는 게 목표임. 하나의 엔티티에 의존하지 않게 됨
  • 중요한 건 ‘하나의 대체재’를 원하느냐, 아니면 5년 뒤 또 같은 상황을 반복하느냐의 문제임
  • 우리는 바로 그걸 시도 중임. Tangled라는 인디 중심 협업 플랫폼을 준비 중이고, 곧 큰 발표가 있을 예정임

• Dillo 프로젝트를 Tangled에 초대하고 싶음 → tangled.org

  • JavaScript 없이도 잘 작동하는 게 인상적임
  • Git 외의 버전 관리 시스템도 지원했으면 좋겠음

• GitHub의 느려진 사용성이 가장 큰 문제라고 생각함

  • “more and more slow”라는 표현이 자연스러운지 궁금함. “slower and slower”가 더 일반적인가?
  • 예전엔 괜찮았는데 최근엔 페이지 로딩이 너무 느림. React 때문만은 아닌 듯함
    코드 탐색은 github.dev로 해결하지만, PR과 Actions는 여전히 느리고 답답함

• VM에 Forgejo를 설치하고 싶다면, 서버와 runner를 한 번에 세팅할 수 있는 스크립트를 만들어둠 → easyforgejo

• 이 주제에 전문성은 없지만 흥미롭게 읽었음
  버전 관리 시스템 하나 세팅하는 데 이렇게 많은 요소가 있다는 게 놀라움
  나는 Fossil을 쓰는데, 소규모 조직에서 개발자·시스템 관리자·지원 담당을 혼자 맡을 때 훨씬 단순함
  GitHub의 deploy key 제약도 불편함. 여러 앱과 서버를 운영할 때 키를 각각 따로 설정해야 해서 번거로움