대상: GitHub의 "실수로 공개 저장소"와 시크릿 누출 사고가 꺼림칙해, 자체 호스팅 Git 서버(bare git, 또는 Gitea/Forgejo/GitLab)를 돌릴지 저울질하는 1인 개발자와 소규모 운영자. 공격 절차는 없습니다 — 오직 당신의 환경에 어느 쪽이 안전한가의 결정뿐입니다.
본 사이트의 견해: 자체 호스팅은 그 대가와 묶일 때만 작동한다
본 사이트 자신도 자체 호스팅 Git 서버를 돌립니다. 하지만 그 이유는 "실수 노출이 무서워서"만이 아니라 — 폭발 반경 분리입니다: 침해된 한 서비스가 다른 것으로 연쇄해선 안 됩니다. 그리고 자체 호스팅하기에, 우리는 늘 별도 서버로의 외부 백업, 시크릿을 git에 절대 두지 않기, 자동 의존성 CVE 모니터링을 함께 묶습니다. 자체 호스팅의 안전은 "GitHub를 안 쓰는 것"에서 오는 게 아니라 — 사라진 위임이 남긴 틈을 메우는 것에서 옵니다.
1. 자체 호스팅이 진짜로 없애는 것
당신의 걱정에는 타당한 근거가 있습니다. GitHub의 고전적 "공개 사고"는 자체 호스팅 서버에서 그냥 일어날 수 없습니다.
공개 저장소는 자동 스캐닝 봇이 끊임없이 크롤링합니다. .env나 API 키를 실수로 커밋하면 사람이 알아채기 전에 봇이 집어가며 — 몇 분 만에 악용이 흔합니다(실제 사례 → 공개 저장소로 키가 새어 부정 청구됨 · .env 전체가 노출됨). 자체 호스팅은 그 공개 표면을 없앱니다. "비공개여야 했는데 공개였다", "지웠다고 생각한 시크릿이 공개 포크에 남았다" — 그런 부류가 설계상 일어날 수 없습니다. 그것은 막연한 위안이 아니라 실제 이점입니다.
2. 대신 떠안는 것(맹점)
여기가 핵심입니다. GitHub는 기본값으로, 보이지 않는 곳에서 많은 방어를 대신해줬습니다. 자체 호스팅하면 그 방어들이 당신이 만들지 않는 한 존재하지 않습니다.
GitHub가 처리해줬던 것
- 시크릿 커밋 차단(푸시 보호)
- 자동 의존성 CVE 경보(Dependabot)
- 서버 운영, 패치, TLS
- 2FA, 세밀한 접근, 감사 로그
- 고가용성, 이중화 백업
이제 당신의 일
- 커밋 전 시크릿 탐지 훅 추가
- 의존성 CVE 모니터링 직접 실행(cron)
- Git 서버 자체의 취약점 패치
- 키 관리 = 사실상 모든 접근 제어
- 사라지면 끝 — 복원을 준비
특히 놓치기 쉬운 두 가지. 첫째, 역설: 당신이 가장 두려워하는 시크릿 누출을 GitHub는 실제로 기계로 막아줍니다. GitHub의 푸시 보호는 API 키처럼 보이는 것을 담은 커밋을 거부합니다. 맨 bare 자체 호스팅 git에는 그런 그물이 없습니다. 실수로 인한 노출은 사라지지만 실수로 인한 커밋은 사라지지 않으므로 — 자체 호스팅한다면 커밋 전 시크릿 훅이 필수입니다.
둘째, Git 서버 자체가 표적이 됩니다. GitLab 같은 기능 풍부한 서버는 여러 심각한 취약점(미인증 원격 코드 실행, 즉 RCE 부류)을 겪었으며, 미패치 자체 호스팅 서버가 침입 경로가 됩니다. 기능이 많을수록 공격 표면이 큽니다. 순수 bare git + SSH가 표면이 가장 작습니다; GitLab/Gitea는 편리하지만 패치를 직접 쫓는 부담을 더합니다.
3. 자체 호스팅을 GitHub보다 안전하게 만드는 법
자체 호스팅을 겉치레가 아니라 진짜로 안전하게 만드는 최소 세트. 이것들이 있어야만 "GitHub보다 안전"이 참입니다.
커밋 전에 시크릿을 막는다
Git 서버를 최소화하고 패치한다
외부 백업 + 테스트된 복원
별도 키, 최소 권한, 비루트
의존성 CVE 모니터링을 직접 실행한다
4. 어느 쪽을 골라야 하나?
자체 호스팅이 "프로"고 GitHub가 "아마추어"인 것이 아닙니다. 계속 운영할 수 있는가로 결정하세요.
자체 호스팅이 맞는 경우(기준을 충족한다면)
- 공개 노출 표면 자체를 없애고 싶다
- 서버를 계속 패치하고 백업할 수 있다
- 코드를 제3자가 쥐는 것이 싫다 / 폭발 반경 분리를 원한다
- 시크릿 훅과 의존성 모니터링을 한 묶음으로 채택할 수 있다
GitHub가 더 안전할 수 있다
- 패치/백업을 계속할 여력이 없음 → 방치된 자체 호스팅이 가장 위험
- 푸시 보호 / Dependabot 자동 방어에 기대고 싶다
- 가용성 / 이중화 백업을 직접 제공할 수 없다
- 비공개 저장소를 엄격히 관리할 수 있다(노출은 규율로 예방 가능)
요컨대 자체 호스팅은 GitHub가 대신해주던 일을 떠안겠다는 계약입니다. 떠안고 해내면, 큰 사고 부류 하나를 없앱니다. 떠안고 방치하면, GitHub보다 나빠질 수 있습니다: 미패치 서버, 잘못 커밋된 시크릿, 복원할 수 없는 백업. 그리고 공급망 오염(예: xz-utils 백도어)은 코드가 어디 있든 지속적 의존성 모니터링으로 방어합니다.
본 사이트는 직접 어떻게 하는가
본 사이트는 자체 호스팅 Git 서버(순수 bare git + SSH)를 돌리며, 모든 푸시가 별도 서버의 백업으로도 확산되도록 엮어 놓았습니다. 시크릿(키, 비밀번호, 접속 문자열)은 git이나 문서에 절대 들어가지 않으며, 의존성 CVE 모니터링은 모든 배포 전과 매일 pnpm audit으로 돕니다. "GitHub를 안 쓰는 것"이 목표가 아니라 — 실수 노출 부류를 없애면서 사라진 위임이 남긴 모든 틈을 메우는 것이 목표입니다. 둘 다 해야 비로소 자체 호스팅이 안전합니다.
다음으로 읽기
- 용어집: .env 파일과 시크릿
- 사고: 공개 저장소로 키가 새어 나감 · .env 전체가 노출됨
- 스택: osv-scanner로 의존성 CVE 머신 모니터링 · CVE를 놓치지 않기
FAQ
Q자체 호스팅 Git 서버가 GitHub보다 더 안전한가요?
본질적으로는 아닙니다. 자체 호스팅은 '실수로 인한 공개 노출' 부류를 구조적으로 없애지만, GitHub가 대신 처리해주던 책임 — 서버 패치, 백업, 커밋 전 시크릿 탐지 — 이 당신에게 넘어옵니다. 그 대가를 치르면 좋은 선택이고, 방치하면 GitHub보다 나쁩니다.
Q사람들이 GitHub를 두려워하는 이유는 무엇인가요?
대개 두 사고입니다: 비공개여야 할 저장소가 공개로 설정된 것, 그리고 API 키가 공개 저장소에 커밋되어 몇 분 만에 악용된 것. 공개 저장소는 자동 스캐닝 봇이 끊임없이 크롤링하므로, 샌 시크릿이 즉시 실제 피해가 됩니다. 자체 호스팅은 그 공개 표면을 통째로 없앱니다.
Q자체 호스팅한다면 최소한 무엇을 해야 하나요?
1) 시크릿을 탐지하는 커밋 전 훅(gitleaks 등), 2) Git 서버와 OS의 패치·최소화, 3) 테스트된 복원이 있는 외부 백업, 4) 별도 키, 비루트, 최소 권한, 5) 의존성 CVE 모니터링을 직접 실행(osv-scanner / pnpm audit). 그래야 비로소 'GitHub보다 안전'이 참이 됩니다.