Skip to content
Published on

셀프호스팅 Git 플랫폼 2026 — Gitea / Forgejo / GitLab CE/EE / OneDev / SourceHut / Gitness 심층 비교

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — Git은 분산이지만 포지(forge)는 중앙집권이다

Git 자체는 1대 1로 push/pull하는 분산형 버전 관리 시스템이다. 그러나 우리가 "GitHub", "GitLab"이라고 부르는 것들 — issue, PR, code review, CI, 권한 관리, 위키, 디스커션 — 은 Git이 아니다. 그것은 포지(forge)다. 그리고 포지의 역사는 분산이 아니라 중앙집권의 역사다.

2008년 GitHub이 등장한 후 거의 모든 오픈소스가 GitHub으로 모였고, 2018년 Microsoft에 인수되면서 그 흐름은 굳어졌다. 2026년 시점에서 GitHub은 사실상 표준이다. 그러나 동시에 "기업 안에 두고 싶다", "한국/일본의 데이터 보호 규제를 지키고 싶다", "GitHub에 의존하지 않는 자체 운영 백엔드가 필요하다"는 요구도 여전하다. 셀프호스팅 Git 포지는 그 빈 자리에서 자라왔다.

2026년 봄, 그 풍경은 다음과 같이 나뉜다. 한쪽에는 가장 인기 있는 Gitea가 있다. 그러나 Gitea는 2022년의 거버넌스 논란을 거쳐 Codeberg-주도 커뮤니티 fork인 Forgejo로 갈라졌다. 다른 한쪽에는 오픈 코어의 거인 GitLab이 있다. CE는 무료/오픈소스, EE는 유료/소스 공개. 그리고 Java 기반의 OneDev가 단일 바이너리로 조용한 팬을 만들고 있다. 한때 강세였던 RhodeCode는 2024년 재정 위기로 사실상 사라졌고, Atlassian은 Bitbucket Server를 2024년 2월 EOL하며 Data Center만 남겼다.

미니멀리스트 진영도 굳건하다. Drew DeVault의 SourceHut은 "JavaScript 없이 동작하는 포지"라는 자기 선언을 지키며 작은 팬을 거느린다. Harness가 인수한 Gitness(구 Drone Code)는 CI를 코어에 박은 새 도전자다. 그리고 Cgit/Stagit 같은 정적 뷰어는 "포지가 아니라 그냥 코드를 보는 사이트"의 역할을 한다. 그 위에 ForgeFed가 ActivityPub 위에서 포지를 페더레이션하려 하고, ArgoCD/Flux는 GitOps로 포지의 의미를 다시 정의한다.

이 글은 그 풍경을 한 번에 정리한다. 같은 축으로 12개 도구를 비교하고, 한국/일본의 사례도 짧게 보고, 마지막에 "당신이 무엇을 골라야 하나"를 개인/팀/엔터프라이즈/미니멀 네 유형으로 답한다. 가격과 라이선스는 2026년 5월 기준이며, 자주 바뀌니 결정 전에 공식 사이트를 확인하라.

"Git은 분산이지만 포지는 늘 누군가의 서버다. 문제는 그 누군가가 누구냐는 것이다." — 익명의 Codeberg 운영자, 2023

1. 2026년 셀프호스팅 Git 지도 — Gitea / GitLab / 미니멀리스트 세 진영

2026년 셀프호스팅 Git 포지를 한 화면에 그리면 세 진영으로 나뉜다.

첫 번째 진영 — Gitea 계열 (Gitea + Forgejo)

가장 인기 있는 셀프호스팅 옵션. Go로 짠 단일 바이너리, MySQL/PostgreSQL/SQLite 백엔드, GitHub과 비슷한 UX. Gitea는 2014년 Gogs의 fork로 출발했고, 2022년 운영 회사 설립을 둘러싼 거버넌스 논란 후 커뮤니티 측이 Forgejo로 다시 fork했다. 두 프로젝트는 API 호환성을 유지하지만 거버넌스 모델이 다르다. Codeberg는 Forgejo의 가장 큰 사용처다.

두 번째 진영 — GitLab (CE / EE)

오픈 코어 모델의 대표. CE(Community Edition, MIT 비슷한 라이선스)는 무료/오픈소스, EE(Enterprise Edition)는 같은 코드베이스에 유료 기능을 추가한 상용판. 한 줄 명령으로 깔리는 Omnibus 패키지가 큰 강점. CI/CD가 코어에 박혀 있고, 보안·컴플라이언스·SAST/DAST 같은 엔터프라이즈 기능이 EE에 들어 있다. 무게가 무거운 게 단점.

세 번째 진영 — 미니멀리스트 (SourceHut / Cgit / Stagit / Gitness)

JavaScript 없이 또는 거의 없이 돌아가는, "포지의 본질만 남긴" 도구들. Drew DeVault의 SourceHut은 git.sr.ht가 호스팅 버전이고 코드는 AGPL. 메일 리스트 기반 패치 워크플로가 특징. Cgit은 kernel.org 등이 쓰는 정적 git 뷰어. Stagit은 한 단계 더 가서 git push 훅이 HTML을 다시 생성하는 진짜 정적 사이트. Gitness(Harness, 구 Drone Code)는 CI를 코어에 박은 새 도전자.

이 세 진영을 가르는 축은 명료하다 — 얼마나 GitHub처럼 보이는가, 얼마나 무거운가, 라이선스가 무엇인가. Gitea/Forgejo는 GitHub-스러우면서도 가볍다. GitLab은 GitHub-스러우면서 무겁다. 미니멀리스트는 GitHub과 일부러 다르게 보이려 하면서 가볍다. 이 셋 중 어느 진영이 당신에게 맞는지가 첫 번째 질문이다.

2. Gitea — 가장 인기, 2022년 거버넌스 논란

Gitea는 2014년 Gogs(Lunny Xiao 작)의 fork로 시작됐다. Go로 짠 단일 바이너리, SQLite/MySQL/PostgreSQL 백엔드, 약 100MB 메모리로 돌아가는 가벼움이 처음부터 강점이었다. 2020년경부터 라즈베리파이에도 깔리는 "취미용 Git 서버"의 사실상 표준이 됐다.

아키텍처와 설치

단일 Go 바이너리 + 데이터베이스 + 데이터 디렉토리. 가장 간단한 형태는 SQLite + 단일 컨테이너. 도커 한 줄로 깔린다.

docker run -d --name gitea \
  -p 3000:3000 -p 222:22 \
  -v /opt/gitea:/data \
  gitea/gitea:latest

소규모(10명 이하)는 SQLite로 충분히 돈다. 100명 이상이면 PostgreSQL + 별도 Redis 캐시를 쓰는 게 권장된다. 백업은 데이터 디렉토리와 DB만 챙기면 된다.

기능 깊이

  • Issue / PR / Code review / Wiki / Project board
  • Actions(GitHub Actions 호환, Gitea Actions라 부른다)
  • Packages(컨테이너/npm/Maven/Composer/PyPI 등)
  • LFS, OAuth 로그인, LDAP/SAML
  • API는 GitHub API와 거의 1:1 호환

2022년 무슨 일이 있었나

오랫동안 커뮤니티 운영이었던 Gitea가 2022년 10월 "Gitea Ltd."라는 영리 법인을 만들어 상표권과 도메인을 이관했다고 발표하자 일부 메인테이너와 커뮤니티가 반발했다. 절차적 투명성 부족, 기여자와의 사전 협의 부재가 핵심 비판이었다. 결국 Codeberg를 중심으로 한 그룹이 같은 해 12월 Forgejo로 fork했다.

이후 Gitea Ltd.는 운영을 정상화했고, 2026년 시점에서 Gitea는 여전히 가장 인기 있는 셀프호스팅 옵션이다. Gitea Cloud(SaaS)도 운영 중이고, 기업 지원 패키지도 판다. 라이선스는 여전히 MIT.

약점

  • 거버넌스 모델이 비영리 커뮤니티가 아니라는 점을 불편해하는 사람들이 있다
  • 사용자가 1000명 이상이 되면 GitLab만큼 정교한 권한·감사 도구가 부족
  • Actions가 GitHub Actions와 100% 호환은 아니다(특히 OIDC 토큰)

3. Forgejo — Codeberg-주도 커뮤니티 fork (2022)

Forgejo는 2022년 12월 Gitea fork로 시작됐다. "Forgejo"는 에스페란토로 "포지"라는 뜻. Codeberg가 주된 운영처이고, 비영리 협회 Codeberg e.V.가 거버넌스를 맡는다.

Gitea와의 차이

  • 동일한 코드베이스에서 출발했으나 점진적으로 갈라지고 있다
  • API 호환성은 유지 — Gitea 클라이언트(예: Tea CLI)는 대부분 작동한다
  • 거버넌스: 영리 법인 없음, 협회 기반
  • 라이선스: GPLv3+로 변경(원본 Gitea는 MIT). 이는 fork의 코드를 다시 클로즈드 소스로 가져갈 수 없게 하기 위한 의도적 선택
  • 일부 기능은 Forgejo가 먼저 들였다 — 예: Federation 실험, Quota 시스템

거버넌스 모델

  • 메인테이너 위원회 + 협회 이사회
  • 모든 결정이 공개 매트릭스(matrix.to) 채팅과 메일링 리스트로 진행
  • "한 사람/한 회사가 통제할 수 없는 구조"가 명시적 설계 목표

Codeberg와의 관계

Codeberg는 독일의 비영리 협회가 운영하는 무료 공개 git 호스팅. 2019년 출발 시점에는 Gitea를 그대로 썼고, fork 이후 Forgejo로 옮겨갔다. 2026년 현재 약 10만 명 이상의 사용자가 무료로 코드를 호스팅한다. 모금으로 운영되고, 일부 오픈소스 프로젝트(예: Codeberg에 mirror된 OBS Studio, KeePassXC 등)가 공식 또는 비공식적 미러로 쓴다.

설치는 Gitea와 거의 동일

docker run -d --name forgejo \
  -p 3000:3000 -p 222:22 \
  -v /opt/forgejo:/data \
  codeberg.org/forgejo/forgejo:latest

설정 파일 형식, 데이터베이스 스키마, 백업 절차가 Gitea와 호환된다. Gitea에서 Forgejo로 마이그레이션이 사실상 "이미지 교체"로 끝나는 이유다.

언제 Forgejo를 골라야 하나

거버넌스가 영리 법인이 아닌 협회/커뮤니티여야 한다는 정책이 있는 곳, 또는 GPL 호환성이 중요한 프로젝트. 기능은 Gitea와 사실상 같으니 "철학"이 선택 기준이다.

4. GitLab CE/EE — 오픈 코어의 거인

GitLab은 2011년 Dmitriy Zaporozhets가 시작한 오픈소스 git 포지. 이후 GitLab Inc.가 설립되며 오픈 코어 모델로 정착했다. CE(Community Edition)는 MIT 비슷한 라이선스, EE(Enterprise Edition)는 같은 코드베이스에 유료 기능을 더한 상용판.

아키텍처

거대하다. Ruby on Rails + Go 컴포넌트(Gitaly: git 스토리지, Workhorse: HTTP 프록시) + PostgreSQL + Redis + 선택적 Sidekiq + Elasticsearch + Container Registry + ... Omnibus 패키지는 이 모든 것을 한 데비안/RPM 패키지에 묶어 한 명령으로 깔리게 한다.

sudo apt install gitlab-ce
sudo gitlab-ctl reconfigure

쿠버네티스 차트도 공식 지원(GitLab Helm Chart). 다만 작은 환경에서 쿠버네티스 차트 전체를 굴리는 건 과하다 — Omnibus가 훨씬 가볍다.

기능

CE에 이미 들어 있는 것:

  • Issue / Merge request / Code review / Wiki
  • CI/CD(GitLab Runner)
  • Container Registry, Package Registry
  • 기본 SAML/LDAP

EE에서만:

  • 코드 오너십 강제(CODEOWNERS의 강제 승인)
  • 보안 스캐닝(SAST/DAST/Container/Dependency)
  • 컴플라이언스 프레임워크
  • 멀티-마스터/지리적 복제(Geo)
  • AI Duo(GitLab의 코드 어시스턴트)

가격

GitLab.com SaaS는 무료/Premium/Ultimate 세 단계. 셀프호스팅은 CE는 무료, EE는 사용자당 월 19 19~99(2026년 5월 시세, Premium / Ultimate). 큰 조직에는 비싸 보이지만 보안 스캐닝과 컴플라이언스 도구가 다 들어가 있다는 점을 감안하면 Snyk + Sonar + Checkmarx 같은 별도 도구 라이선스보다 싸다는 평가도 있다.

무게에 대한 솔직한 평가

GitLab CE를 4 vCPU + 8GB RAM 미만에 깔면 고생한다. 100명 이상이면 16GB+ 권장. Omnibus 패키지 업그레이드는 비교적 잘 굴러가지만, Helm 차트 업그레이드는 익숙해지는 데 시간이 걸린다. "GitLab CE는 무겁지만 안정적이다"가 일반적인 평이다.

한국에서의 위치

LGCNS·삼성 SDS·KT 등 대기업 SI/Enterprise 환경에 GitLab CE/EE 설치 사례가 많다. 금융권에서는 망분리 환경에 GitLab을 깔고 외부 GitHub과 일방향 동기화하는 패턴이 흔하다.

5. OneDev — Java 기반 모던

OneDev는 한 명의 개발자(Robin Shen)가 2018년부터 만드는 Java 기반 git 포지. 단일 jar 또는 도커 이미지로 굴리고, H2 임베디드 또는 PostgreSQL/MySQL을 쓴다. 라이선스는 MIT.

왜 OneDev를 보는가

  • 단일 바이너리/도커. 설정 한 곳에 모임
  • CI/CD가 코어. 별도 Runner 설치 없이 "build spec"이라는 자체 DSL로 파이프라인 정의
  • 이슈 트래커가 깊다 — 사용자 정의 필드, 마일스톤, 보드, 시간 추적
  • 코드 검색이 빠르다 — Lucene 기반, 의미 검색은 없지만 정규식·심볼 검색은 잘 됨
  • 풀 리퀘스트 동시 빌드/이슈 자동 연결 등 자잘한 편의가 많다

기능 비교

Gitea와 비교하면 CI/CD 깊이가 한 단계 위. GitLab CE와 비교하면 가볍다. GitLab과 Gitea 사이 어딘가에 자리잡은 도구다.

약점

  • 단일 메인테이너 리스크. Robin Shen이 거의 모든 코드를 짠다
  • 커뮤니티가 작다. Stack Overflow에 답이 적다
  • UI가 Gitea/GitLab과 미묘하게 달라서 처음 쓰는 사람이 적응 시간이 필요하다
  • Java 의존성(JDK 17+ 필요)

누가 골라야 하나

작은 팀(5~30명)인데 GitLab CE는 너무 무겁고, Gitea의 CI는 부족하다고 느낀다면 OneDev가 답일 수 있다. Java 운영에 익숙한 환경(은행, 보험 등)도 친화적이다.

6. RhodeCode — 2024년 재정 위기

RhodeCode는 2010년경부터 있던 Python 기반 git/mercurial 포지. Community Edition(CE)와 Enterprise Edition(EE)으로 나뉘었고, Mercurial과 Subversion까지 한 화면에서 다루는 게 강점이었다. 2010년대 중반에는 Atlassian Stash(Bitbucket Server) 대안으로 한자리 차지했다.

2024년 무슨 일이 있었나

2024년 중반 RhodeCode Inc.가 재정 어려움으로 사실상 운영을 줄였다. 공식 사이트는 살아 있지만 업데이트가 거의 멈췄고, GitHub 저장소도 사실상 동결됐다. 일부 메인테이너가 fork(Kallithea라는 더 오래된 fork도 있었으나 이쪽도 활동이 적다)를 시도했지만 2026년 시점에서는 새 사용자에게 권하기 어렵다.

남아 있는 사용자

레거시 Mercurial 저장소를 안고 있는 곳에서 여전히 RhodeCode를 굴린다. Mozilla, Facebook 일부 모노레포가 한때 Mercurial이었던 역사 때문에 RhodeCode를 쓴 적이 있고, 그 흔적이 남아 있다. 그러나 새 설치는 권장되지 않는다.

대안

Mercurial 지원이 필요하면 SCM-Manager(Cloudogu, Java 기반)나 Heptapod(GitLab CE fork에 Mercurial 지원을 다시 붙인 프로젝트)가 후보. Heptapod는 octobus.net이 유지하고 있다.

이 절은 "역사적 맥락"으로 두는 게 맞다 — 2026년에 새 사용자가 RhodeCode를 골라야 할 이유는 거의 없다.

7. Bitbucket Data Center — Atlassian의 마지막 셀프호스팅

Atlassian은 2010년 호주 스타트업 Bitbucket을 인수해 자사 협업 도구(Jira, Confluence)와 연결했다. 셀프호스팅 버전은 Bitbucket Server(원래 이름은 Stash)로 불렸다.

2024년 2월 — Bitbucket Server 단종

Atlassian은 2024년 2월에 Bitbucket Server의 모든 버전을 EOL(End of Life)했다. 이후 셀프호스팅 옵션은 Bitbucket Data Center 하나만 남았다 — 이쪽은 액티브-액티브 클러스터링과 대규모 조직 기능을 가진 더 비싼 라이선스다. 단일 노드 Bitbucket Server를 쓰던 작은 팀은 GitHub Enterprise나 다른 도구로 마이그레이션을 권유받았다.

Bitbucket Data Center의 특징

  • 액티브-액티브 클러스터, 지리적 분산
  • Jira/Confluence와 깊은 통합
  • 라이선스가 사용자 단위로 비싸다 — 500명 이상부터 시작하는 가격대(Atlassian이 그렇게 가격을 설계)
  • 운영 복잡도가 높다. DBA + JVM 튜닝 경험이 필요

왜 작은 팀은 옮겨야 했나

Atlassian이 클라우드(bitbucket.org SaaS) 중심으로 전략을 옮기면서, 단일 노드 셀프호스팅 시장을 사실상 포기했다. Bitbucket Server 사용자들이 가장 많이 옮겨 간 곳은 GitHub Enterprise, 그 다음이 GitLab CE/EE, 그리고 Gitea/Forgejo로 일부.

한국에서는

대기업 SI 환경에서 Bitbucket Server를 굴리던 곳이 꽤 있었다. 2024년 EOL 이후 GitLab CE/EE나 GitHub Enterprise로 옮겨 갔거나, Bitbucket Data Center를 그대로 유지하면서 라이선스 비용을 감수하는 두 패턴이 나뉘었다. 금융권은 후자가 많다 — Atlassian 생태계(Jira, Confluence) 락인이 강하기 때문.

8. SourceHut — Drew DeVault의 미니멀

SourceHut은 Drew DeVault가 2019년 시작한 git 포지. sr.ht 도메인(읽기는 "sir-hat"). 코드는 AGPL, 호스팅 버전은 유료(월 $2~ 시작), 셀프호스팅은 무료.

철학

  • JavaScript 없이 동작 — 진짜 한 줄도 안 쓴다(읽기 인터페이스 기준). 모든 UI가 HTML + CSS로만 그려진다
  • 메일링 리스트 기반 패치 워크플로 — git format-patch로 만든 패치를 메일로 보내고, git am으로 적용
  • 별도 컴포넌트로 분리: git.sr.ht(저장소), lists.sr.ht(메일링 리스트), todo.sr.ht(이슈), builds.sr.ht(CI), pages.sr.ht(정적 사이트), man.sr.ht(맨페이지/위키)
  • 추적 코드(트래커) 없음, 분석 없음

누가 쓰는가

Sway 윈도우 매니저(Drew 본인 작), wlroots, postmarketOS 등 Wayland/리눅스 데스크탑 생태계가 sr.ht를 자주 쓴다. 메일 워크플로에 익숙한 커널 스타일 개발자에게 친화적.

Builds.sr.ht — CI

이미지 정의가 단순한 YAML이고, FreeBSD/NetBSD/OpenBSD 빌드도 지원한다는 게 차별점. GitHub Actions가 리눅스 중심인 반면 builds.sr.ht는 BSD 친화적.

약점

  • UI가 의도적으로 보수적이라 GitHub에 익숙한 사용자는 처음에 길을 잃는다
  • PR 대신 메일 패치라는 점이 진입 장벽
  • 셀프호스팅 설치가 다른 도구보다 복잡(여러 컴포넌트가 각자 별도 데몬)

Drew DeVault에 대한 사족

Drew는 자기 의견이 매우 강한 개발자로 알려져 있고, 블로그에 자주 글을 올린다. 그의 글이 가끔 논쟁적이라 SourceHut의 평판에도 영향을 준다 — 그러나 코드와 운영의 일관성은 변함없이 유지되고 있다.

9. Gitness — Harness(구 Drone Code)의 새 도전자

Gitness는 Harness Inc.가 2023년에 발표한 git 포지. 원래는 Drone Code라는 이름이었지만 마케팅 통일을 위해 Gitness로 재명명됐다. Drone CI(같은 회사의 CI 제품)와 통합이 강점.

특징

  • Go로 짠 단일 바이너리
  • 도커 한 줄로 깔린다(Gitea처럼)
  • 코어에 파이프라인(CI)이 박혀 있다 — Drone CI YAML 구문 그대로 사용
  • 코드 검색이 빠른 편
  • 라이선스 Apache 2.0
docker run -d -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /opt/gitness:/data \
  harness/gitness

Harness 본 제품과의 관계

Harness는 원래 CI/CD/Feature Flag 같은 DevOps 플랫폼을 파는 SaaS다. Gitness는 그 입구 역할 — Harness 사용자가 Git 호스팅까지 한 화면에서 하게 하는 게 목적. Harness Cloud Plan(유료)에는 Gitness가 통합돼 있고, 셀프호스팅 Gitness는 무료/오픈소스.

약점

  • 2023년에 등장한 신생이라 검증 사례가 적다
  • 커뮤니티가 작다
  • 회사 전략 변경에 따라 운명이 바뀔 수 있는 위험(Drone Code → Gitness 재명명도 그런 신호 중 하나)
  • Gitea/Forgejo만큼 기능이 많지 않다

누가 보면 좋은가

CI 중심 워크플로가 절대적이고, Drone YAML에 익숙하며, Git 호스팅을 가볍게 같이 굴리고 싶은 팀.

10. Tea CLI — Gitea / Forgejo 친화

Tea는 Gitea/Forgejo의 공식 CLI 클라이언트. Go로 짠 단일 바이너리. GitHub의 gh CLI와 같은 자리다.

설치

brew install tea          # macOS
go install code.gitea.io/tea@latest

기본 사용

tea login add --name myserver \
  --url https://git.example.com \
  --token <YOUR_TOKEN>

tea repos list
tea issues list
tea pulls create --title "Fix bug" --description "..."
tea pulls checkout 42

왜 좋은가

  • gh CLI에 익숙한 사용자라면 거의 같은 멘탈 모델
  • Gitea와 Forgejo 양쪽 호환 — 같은 API라 동작이 같다
  • 셀(zsh/bash/fish) 자동완성 제공
  • 로컬 git remote에서 자동으로 어떤 Gitea/Forgejo 서버인지 추론

약점

  • 기능 깊이는 gh CLI보다 얕다(예: gh와 같은 풍부한 alias 시스템 부재)
  • GitHub API와 100% 호환 표면을 쓰는 게 아니라 일부 명령은 다르다
  • 커뮤니티가 작아 답변이 적다

누가 보면 좋은가

Gitea/Forgejo를 매일 쓰는 사람이라면 거의 무조건. 셀프호스팅 git의 가장 큰 불편 중 하나가 "GitHub만큼 매끄러운 CLI가 없다"는 것이었는데, Tea가 그 자리를 채워준다.

11. Cgit / Stagit — 정적 뷰어

읽기 전용 git 뷰어 두 도구. 둘 다 "포지가 아니라 그냥 코드 보는 사이트"의 역할을 한다.

Cgit

C로 짠 CGI 프로그램. 가볍고 빠르다. git.kernel.org가 Cgit으로 굴러간다. nginx + fcgiwrap + cgit이 일반적 조합.

location /cgit/ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
}

특징:

  • 한 화면에 commit/branch/diff/blame 표시
  • 검색은 단순한 grep
  • Atom 피드 지원
  • 인증·이슈·PR 없음. 진짜 읽기 전용

Stagit

Stagit(suckless 진영의 Hiltjo Posthuma 작)은 더 극단적이다. 동적 CGI도 아니다 — git push 훅이 HTML을 다시 생성한다. 그 결과 완전한 정적 사이트가 된다.

stagit -c .cache repo.git
# repo.git/index.html, log.html, files.html ... 생성

특징:

  • 진짜 정적 HTML, S3·CDN·정적 호스팅에 바로 올림
  • CSS는 한 파일, JavaScript 0줄
  • 검색 기능 없음(grep는 외부 도구로)
  • suckless.org가 자기 코드 호스팅으로 사용

누가 쓰는가

"내 dotfiles와 작은 라이브러리를 보여주는 사이트"가 필요한 개인 개발자, 그리고 메일링 리스트 기반으로 패치를 받는 커널 스타일 프로젝트. 협업 도구(이슈·PR)는 다른 곳에 있고, 코드 표시만 정적으로 하고 싶을 때 답이다.

12. ForgeFed — Federated Git

ForgeFed는 git 포지를 ActivityPub 위에서 페더레이션하려는 표준 초안. 2019년경 시작됐고, Forgejo와 일부 다른 포지가 실험적으로 구현 중이다.

무엇을 하려고 하나

  • gitea.example.com의 issue가 forgejo.other.org의 사용자에게 ActivityPub 메시지로 전달
  • A 인스턴스에 있는 사용자가 B 인스턴스 저장소를 follow / star / fork
  • A 인스턴스의 PR이 B 인스턴스의 저장소로 가로질러 열림
  • Mastodon이 트윗을 페더레이션하듯이, 포지가 코드 협업을 페더레이션

현재 상태(2026년 5월)

  • ForgeFed 표준 초안은 W3C Social Web Community Group에서 작업 중
  • Forgejo가 가장 적극적 — 실험적 기능으로 일부 인스턴스가 활성화
  • Gitea는 관심을 표명했으나 우선순위가 낮음
  • SourceHut은 자기 식 메일 기반 페더레이션을 더 선호

현실적 평가

ForgeFed가 실제로 동작하는 사례는 아직 적다. 메시지 형식, 권한, 충돌 해결 같은 어려운 문제가 남아 있다. 그러나 "GitHub이라는 한 회사에 코드 생태계가 통째로 갇혀 있는" 상황의 진짜 대안은 페더레이션밖에 없다는 인식이 점점 커지고 있다. 2027~2028년쯤이면 의미 있는 진전이 있을 것이라는 게 일반적 전망.

13. ArgoCD / Flux — GitOps가 포지의 의미를 다시 정의한다

GitOps는 "선언적 인프라 상태를 git에 두고, 컨트롤러가 그 상태로 클러스터를 수렴시킨다"는 패턴. ArgoCD(Intuit 발 CNCF 졸업)와 Flux(Weaveworks 발 CNCF 졸업)가 양대 도구다.

왜 이 글에서 다루는가

GitOps는 포지의 의미를 바꾼다 — 포지는 단순한 코드 호스팅이 아니라 "시스템 상태의 source of truth"가 된다. ArgoCD/Flux는 자기가 쓰는 포지가 무엇이든(GitHub, GitLab, Gitea, Forgejo, Bitbucket 등) 잘 동작하지만, 셀프호스팅 포지를 쓸 때 다음 두 가지가 중요해진다.

고려 사항 1 — 가용성

포지가 죽으면 ArgoCD가 sync를 못 한다. 따라서 포지를 고가용성으로 굴리거나, 적어도 빠른 복구 절차가 있어야 한다. GitLab CE의 Geo 기능(EE 전용), Gitea의 단순 SQL 백업, Forgejo의 활성-수동 구성 같은 옵션이 있다.

고려 사항 2 — Webhook과 폴링

ArgoCD가 변경을 감지하는 두 방식 — webhook(즉시) 또는 폴링(기본 3분). 셀프호스팅 포지가 webhook을 클러스터로 잘 보내는지 확인해야 한다. 네트워크 분리 환경에서는 폴링만 가능할 수 있다.

ArgoCD 설치 예

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Flux 설치 예

flux bootstrap gitea \
  --hostname=git.example.com \
  --owner=platform \
  --repository=flux-clusters \
  --branch=main \
  --path=clusters/prod

Flux는 부트스트랩 자체가 Git 저장소를 만들어 자기 매니페스트를 거기 푸시한다. Gitea/GitLab/GitHub/Bitbucket을 다 지원하지만, Forgejo와 Gitness는 Gitea 호환 모드로 굴린다(2026년 5월 기준).

14. 미러 도구 — git-mirror, gitea-mirror

셀프호스팅 포지의 흔한 사용 패턴 — "GitHub의 공식 저장소를 사내 git 서버로 미러링". 이를 위한 도구 몇 가지.

Gitea/Forgejo 내장 미러

저장소 생성 시 "Mirror this repository" 옵션을 체크하면 주기적으로 외부 git에서 pull. 가장 간단.

git-mirror (Python)

git-mirror --source https://github.com/foo/bar \
  --target ssh://git@internal.example.com/mirrors/bar.git \
  --interval 3600

조직 단위 미러 — gitea-mirror, forgejo-mirror

특정 GitHub Organization의 모든 저장소를 자동으로 미러. 새 저장소가 추가되면 자동으로 미러 등록.

source:
  type: github
  org: kubernetes
target:
  type: gitea
  url: https://git.example.com
  org: github-mirror-kubernetes
schedule: "0 */6 * * *"

왜 미러를 굴리는가

  • 망분리 환경에서 외부 코드를 안으로 가져오기
  • GitHub 장애 시 대비
  • 회사 정책상 의존성 코드를 사내에서 보관해야 할 때
  • LFS 객체 미러링까지 하면 큰 저장소도 안에서 빌드 가능

15. 한국 / 일본 — 토스, 카카오, 메르카리, Pixiv

한국 — 토스, 카카오

토스(비바리퍼블리카)는 사내 git 인프라를 운영한다고 공개적으로 언급한 바 있다. 정확한 구현은 비공개지만, 사내 GitLab 또는 GitHub Enterprise를 굴리는 한국 핀테크의 일반 패턴을 따른다. 토스 기술 블로그에는 사내 개발 환경 통합에 대한 글들이 올라온다.

카카오는 일부 팀이 GitHub Enterprise를, 일부가 GitLab을 쓴다고 알려져 있다. 그룹 차원에서 단일화하기보다 팀 자율을 인정하는 문화가 있다. 카카오 기술 블로그(tech.kakao.com)에 DevOps/플랫폼 글이 정기적으로 올라온다.

NAVER도 사내 git 호스팅을 운영한다. NAVER D2 블로그(d2.naver.com)에 개발 인프라 관련 글들이 가끔 올라온다. NAVER도 다양한 사내 도구를 자체 개발 또는 오픈소스를 자기 환경에 맞게 패치해 쓰는 패턴.

일본 — メルカリ, Pixiv

메르카리(Mercari)는 GitHub Enterprise를 메인으로 쓴다고 자사 엔지니어링 블로그에서 여러 차례 언급. 메르카리 엔지니어링 블로그(engineering.mercari.com)는 일본 IT 회사 중에서 가장 많은 영문 콘텐츠를 생산하는 곳 중 하나다.

Pixiv는 일본 일러스트 커뮤니티 회사로, 사내 git을 GitLab CE로 굴린다는 언급이 있다. inside.pixiv.blog에 개발 문화 관련 글이 정기적으로 올라온다.

LINE(현 LY Corporation)은 GitHub Enterprise를 메인으로, 일부 자체 도구를 같이 쓴다. engineering.linecorp.com에 DevOps/플랫폼 글들이 있다.

일반적 패턴

한국/일본 대기업은 다음 셋 중 하나를 고르는 게 일반적:

  1. GitHub Enterprise(망분리 환경에서는 GitHub Enterprise Server 셀프호스팅)
  2. GitLab CE/EE 셀프호스팅
  3. Bitbucket Server(2024년 EOL 이후 GitHub/GitLab으로 옮기는 추세)

Gitea/Forgejo는 한국/일본 대기업 메인 사례가 적다. 그러나 스타트업·중소기업의 사내 git 서버로는 점점 늘고 있다. 라즈베리파이에 Gitea 깔아 동아리 코드 호스팅을 하는 학생 사례도 흔하다.

16. 비교 표 — 12개 도구 한눈에

각 도구의 성격을 한 줄로 정리:

  • Gitea: 가장 인기 셀프호스팅, MIT, 가볍다
  • Forgejo: Gitea 커뮤니티 fork, GPLv3+, 거버넌스 명확
  • GitLab CE: 오픈 코어, 무겁지만 기능 풍부
  • GitLab EE: GitLab CE + 엔터프라이즈 기능, 비싸지만 보안/컴플라이언스 포함
  • OneDev: Java 기반, CI 강함, 단일 메인테이너
  • RhodeCode: 2024년 사실상 종료, 새 사용자 비권장
  • Bitbucket Data Center: Atlassian, 비싸고 Jira/Confluence 락인
  • SourceHut: JS 없음, 메일 기반, 미니멀리스트
  • Gitness: Harness 발, CI 코어, 신생
  • Cgit: 정적 동적 뷰어, kernel.org가 사용
  • Stagit: 진짜 정적, suckless.org가 사용
  • Tea CLI: Gitea/Forgejo 친화 CLI, gh와 같은 자리

축별 비교

라이선스 자유도 순: SourceHut/Forgejo(GPL) > Gitea/Gitness(MIT/Apache) > OneDev(MIT) > GitLab CE(MIT 비슷) > GitLab EE/Bitbucket DC(상용)

운영 무게 순 (가벼움): Cgit/Stagit > Gitea/Forgejo/Gitness > SourceHut > OneDev > GitLab CE > GitLab EE/Bitbucket DC

GitHub과의 UX 친숙도 순: Gitea/Forgejo/Gitness > OneDev > GitLab > Bitbucket > SourceHut > Cgit/Stagit

17. 누가 무엇을 골라야 하나 — 네 유형

유형 1 — 개인 / 취미 / 작은 동아리

답: Gitea 또는 Forgejo. SQLite 백엔드에 도커 한 줄로 깔리고, 100MB 메모리로 잘 돈다. 두 도구의 기능은 거의 동일하니, 거버넌스 철학에 신경 쓰면 Forgejo, "가장 큰 커뮤니티"가 좋으면 Gitea. Tea CLI도 같이 깔자. 라즈베리파이 4 정도면 충분.

유형 2 — 5~50명 팀, CI가 중요

답: OneDev 또는 GitLab CE. OneDev는 가볍고 CI가 코어. GitLab CE는 무겁지만 검증된 기능과 큰 커뮤니티. 사용자가 20명 이상이고 8GB+ RAM 인스턴스를 굴릴 여력이 되면 GitLab CE가 답. 그보다 작으면 OneDev. Gitea + 별도 Drone CI 조합도 가능한 선택.

유형 3 — 엔터프라이즈 (망분리, 컴플라이언스)

답: GitLab EE 또는 GitHub Enterprise Server 또는 Bitbucket Data Center. 보안 스캐닝·감사 로그·SAML/SCIM·CODEOWNERS 강제·지리적 복제가 필요하면 이 셋 중 하나. 비용은 비슷한 수준. Jira/Confluence 락인이 강한 곳은 Bitbucket DC, 그렇지 않으면 GitHub Enterprise 또는 GitLab EE. 한국 금융권은 GitLab EE 사례가 많다.

유형 4 — 미니멀리스트 / 메일 패치 / 정적 사이트

답: SourceHut 또는 Cgit/Stagit. 메일 기반 패치 워크플로를 좋아하고 JavaScript 없는 UI를 선호하면 SourceHut. 협업 도구는 다른 곳에 있고 코드 표시만 정적으로 하고 싶으면 Cgit(동적, CGI) 또는 Stagit(진짜 정적). 둘 다 dotfiles와 작은 라이브러리에 잘 맞는다.

유형 5 (보너스) — GitOps 중심

답: 위 어느 도구든 + ArgoCD/Flux. 포지 선택보다 GitOps 패턴이 더 중요하다. ArgoCD/Flux는 Git 포지를 가리지 않지만, 셀프호스팅 포지의 가용성을 챙겨야 한다. Flux는 Gitea/Forgejo를 잘 지원하니 작은 환경에서 GitOps 부트스트랩이 쉽다.

에필로그 — GitHub의 그림자 아래, 그러나 자기 자리

GitHub은 2026년에도 여전히 사실상 표준이다. 셀프호스팅 git이 GitHub을 대체할 가능성은 적다. 그러나 셀프호스팅이 사라질 가능성도 없다. 망분리, 데이터 주권, 컴플라이언스, "한 회사에 의존하기 싫다"는 의지 — 이 모든 것이 셀프호스팅의 자리를 만들어준다.

2026년 봄, 그 자리에 가장 단단하게 서 있는 것은 Gitea와 Forgejo다. 두 도구의 분기 자체가 "한 회사가 통제할 수 없는 포지가 필요하다"는 욕망의 증거다. GitLab CE/EE는 거대한 오픈 코어로 자기 자리를 굳혔고, OneDev/Gitness는 작은 팀에 새 옵션을 준다. SourceHut/Cgit/Stagit은 "포지가 GitHub처럼 보일 필요가 없다"는 또 다른 가능성을 지킨다. ForgeFed는 아직 실험이지만 진짜 페더레이션의 가능성을 열어두고, ArgoCD/Flux는 포지의 의미를 "코드 보관소"에서 "시스템 상태의 source of truth"로 확장한다.

자기 코드를 자기 서버에 두는 것은 사소한 결정처럼 보이지만, 결국 "누가 내 코드의 운명을 결정하는가"라는 큰 질문에 답하는 일이다. 그 답을 자기에게 두고 싶은 사람들에게, 2026년의 셀프호스팅 git 생태계는 어느 때보다 풍부한 선택지를 준다.

참고 / References

Discuss on Twitter • View on GitHub