▲

GitHub에서 Dillo 프로젝트 이전

 (dillo-browser.org)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 웹 브라우저 Dillo 프로젝트가 GitHub에서 자체 호스팅 서버로 이전을 진행 중임
  • GitHub의 JavaScript 의존성, 단일 통제 구조, 느린 성능 등이 주요 이전 이유로 제시됨
  • 새 서버는 dillo-browser.org 도메인에서 운영되며, cgit 기반 경량 Git 프런트엔드와 자체 제작 버그 트래커 ‘buggy’ 를 사용함
  • 모든 데이터는 git 저장소로 관리되어 Codeberg와 Sourcehut에 미러링되며, 데이터 손실 위험을 최소화함
  • OpenPGP 서명을 통해 DNS 손실 시에도 신뢰성을 유지할 수 있도록 설계되어, 프로젝트의 독립성과 지속성을 강화함

배경

  • 과거 Dillo의 원래 사이트는 dillo.org였으며, Mercurial 저장소, 메일 서버, 버그 트래커, 메일링 리스트 아카이브를 포함하고 있었음
    • 2022년에 도메인을 잃고, 제3자가 AI 광고로 가득한 유사 사이트를 개설함
    • 일부 자료는 복구되었으나 완전하지 않음
  • 이러한 경험으로 인해 단일 사이트 의존을 피하고, 분산된 백업 구조를 구축하기로 결정함
  • 초기에는 GitHub에 코드를 업로드했으나, 장기적으로 적합하지 않다고 판단함

GitHub의 문제점

  • GitHub는 CI 워크플로와 저장소 관리에 유용했지만, 여러 한계가 있음
    • JavaScript 없이는 프런트엔드가 작동하지 않아, Dillo 브라우저로 이슈나 PR을 열람할 수 없음
    • 페이지가 리소스를 과도하게 사용하며, 단순 HTML 렌더링에 불필요한 부하 발생
  • 단일 통제 주체에 의해 계정이 차단될 위험이 있어, 데이터 접근이 차단될 수 있음
  • 플랫폼이 점점 느려지고, 빠른 인터넷 연결을 요구함
  • GitHub의 “푸시 모델” 알림 방식은 오프라인 중심의 개발 방식과 맞지 않음
  • 비개발자 사용자 비율이 높은 프로젝트에서의 커뮤니티 관리 도구 부족으로 개발자 피로도가 증가함
  • GitHub가 LLM 및 생성형 AI 중심으로 전환하면서, 사이트들이 LLM 크롤러를 막기 위해 JavaScript 벽이나 브라우저 지문 추적을 강화함
    • 이로 인해 Dillo 사용자 접근이 차단되는 부작용 발생

자체 호스팅 구축

  • 기존 포지토리 서비스들이 단일 장애점 제거와 경량 운영을 동시에 만족하지 못함
    • 이에 따라 직접 서버를 운영하고, 여러 미러를 유지하기로 결정
  • dillo-browser.org 도메인을 구입하고, 소형 VPS 서버를 구축
    • 예상보다 안정적으로 운영 중이며, 주로 AI 봇 트래픽을 처리함
  • Git 프런트엔드로 cgit을 선택
    • C 언어로 작성되어 RAM과 CPU 사용량이 적고, JavaScript 없이 작동
    • Dillo에서 잘 보이도록 CSS를 일부 수정함
    • https://git.dillo-browser.org/ 에서 접근 가능
  • 버그 트래커는 직접 개발한 ‘buggy’ 사용
    • Markdown 파일을 파싱해 HTML 페이지 생성, 각 버그는 git 저장소에 저장
    • 커밋 시 git hook이 자동으로 페이지를 갱신
    • 오프라인 편집 가능, 보안 취약점 우려 없음
    • https://bug.dillo-browser.org/ 에서 확인 가능
  • 메일링 리스트 아카이브는 3개의 외부 서비스에 분산 저장, 향후 자체 복사본 추가 예정

미러 설정

  • 모든 핵심 데이터가 git 저장소 형태로 관리되어, Codeberg와 Sourcehut에 미러링됨
    • 특정 포지토리가 중단되더라도 낮은 전환 비용으로 다른 미러로 이동 가능
  • 단일 실패 지점은 DNS(dillo-browser.org)
    • DNS 손실 시 메일링 리스트, Fediverse, IRC 등을 통해 사용자에게 알림 가능
    • 데이터는 git에 복제되어 있어 치명적 손실은 발생하지 않음

OpenPGP 서명

  • 본 페이지는 Rodrigo Arias Mallo의 GPG 키(32E65EC501A1B6FDF8190D293EE6BA977EB2A253) 로 서명됨
    • Dillo의 최신 릴리스와 동일한 키이며, GitHub 계정에도 등록되어 있음
    • 서명 파일(index.html.asc)은 <link rel=signature>로 연결됨
  • OpenPGP 서명은 DNS 손실에도 신뢰 유지 가능
    • TLS 인증서 체인 대신 서명 신뢰 기반으로 소유권 증명
    • 모든 git 미러에 서명을 포함시켜 데이터 손실 내성 강화

마이그레이션 진행 및 전망

  • GitHub 저장소는 즉시 삭제되지 않으며, 마이그레이션 완료 전까지 계속 업데이트됨
    • 완료 후에는 저장소를 ‘archived’ 상태로 전환하고 공식 사이트에 공지 예정
    • 기존 커밋과 릴리스 파일은 하위 빌드 호환성을 위해 유지
  • 새 인프라는 낮은 비용과 에너지 소비로 독립 운영 가능
    • 현재 기부금과 서버 비용 기준으로 최소 3년간 유지 가능
    • 후원을 원할 경우 Liberapay를 통해 지원 가능 (https://liberapay.com/dillo/)
▲
GN⁺ 4일전  [-]
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 제약도 불편함. 여러 앱과 서버를 운영할 때 키를 각각 따로 설정해야 해서 번거로움

답변달기