# GitHub에서 Dillo 프로젝트 이전

> Clean Markdown view of GeekNews topic #24750. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24750](https://news.hada.io/topic?id=24750)
- GeekNews Markdown: [https://news.hada.io/topic/24750.md](https://news.hada.io/topic/24750.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-01T13:33:10+09:00
- Updated: 2025-12-01T13:33:10+09:00
- Original source: [dillo-browser.org](https://dillo-browser.org/news/migration-from-github/)
- Points: 2
- Comments: 1

## Topic Body

- 웹 브라우저 **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)은 `&lt;link rel=signature&gt;`로 연결됨  
- **OpenPGP 서명은 DNS 손실에도 신뢰 유지 가능**  
  - TLS 인증서 체인 대신 **서명 신뢰 기반**으로 소유권 증명  
  - 모든 git 미러에 서명을 포함시켜 **데이터 손실 내성 강화**  

### 마이그레이션 진행 및 전망
- **GitHub 저장소는 즉시 삭제되지 않으며**, 마이그레이션 완료 전까지 계속 업데이트됨  
  - 완료 후에는 저장소를 **‘archived’ 상태로 전환**하고 공식 사이트에 공지 예정  
  - 기존 커밋과 릴리스 파일은 **하위 빌드 호환성을 위해 유지**  
- 새 인프라는 **낮은 비용과 에너지 소비로 독립 운영 가능**  
  - 현재 기부금과 서버 비용 기준으로 **최소 3년간 유지 가능**  
  - 후원을 원할 경우 **Liberapay를 통해 지원 가능** (<https://liberapay.com/dillo/>)

## Comments



### Comment 47033

- Author: neo
- Created: 2025-12-01T13:33:11+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=46096800) 
- 몇 년 동안 **GitLab**을 셀프호스팅 대안으로 써왔음. 마음에 들지만 **리소스 소모가 심함**  
  최근에는 Codeberg 팀이 만든 **Forgejo**를 테스트 중인데, 정말 훌륭함  
  가장 큰 차이는 메모리 사용량임. GitLab은 Ruby on Rails 기반이라 여러 서비스가 동시에 돌아가지만, Forgejo는 Go로 작성된 단일 바이너리 구조임  
  GitLab은 16GB VM의 메모리를 점점 다 써버리지만, Forgejo는 서버와 runner를 함께 돌려도 300MB 정도만 사용함  
  GraphQL은 없지만 REST API가 충분히 괜찮아 보임  
  gitea와 forgejo의 차이를 잘 모르겠는데, [Forgejo의 비교 문서](https://forgejo.org/compare-to-gitea/#why-was-forgejo-created)를 보니 2022년에 거버넌스 문제로 soft fork된 것 같음
  - 우리 스튜디오는 약 50명의 사용자가 매일 git을 쓰는데, 2년 전 **Forgejo로 완전히 이전**했음  
    Go 기반의 단순한 구조라 **유지보수와 비용이 매우 적음**. 내부 툴도 Forgejo 위에 직접 구축했음  
    온프레미스 호스팅이라 인터넷이 끊겨도 개발과 CI가 멈추지 않음. 패키지 매니저 캐시도 지원해서 의존성 관리가 쉬움
  - 유지보수 편의성은 gitea가 압도적임. 5년 넘게 쓰고 있는데, 업그레이드는 새 버전 pull 후 데몬 재시작으로 끝남  
    GitHub보다 **다운타임이 10배 적었음**, 그것도 대부분 계획된 점검이었음  
    GitHub의 가용성이 더 낫다고 주장하는 글을 보면 웃음이 나옴
  - 개인 프로젝트라면 단순히 SSH 서버와 파일 시스템만으로 충분하다고 생각함  
    새 저장소를 만들 때 `git init --bare`로 끝나고, 백업도 자동으로 돌아감  
    혼자 개발한다면 UI가 굳이 필요 없다고 느낌
  - [Forgejo Actions 기본 개념 문서](https://forgejo.org/docs/latest/user/actions/basic-concepts/)를 보면 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](https://tangled.org)
  - JavaScript 없이도 잘 작동하는 게 인상적임
  - Git 외의 버전 관리 시스템도 지원했으면 좋겠음

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

- VM에 Forgejo를 설치하고 싶다면, 서버와 runner를 한 번에 세팅할 수 있는 스크립트를 만들어둠 → [easyforgejo](https://wkoszek.github.io/easyforgejo/)

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