2026년 4월 24일, GitHub의 모델 학습 정책 개인용 Copilot 요금제에 대해 변경되었습니다. 이제 GitHub는 사용자가 옵트아웃하지 않는 한 Copilot Free, Pro, Pro+, Max의 상호작용을 입력, 출력, 코드 조각, 관련 컨텍스트까지 포함해 AI 모델 학습과 개선에 사용할 수 있습니다. Copilot Business와 Enterprise 데이터는 GitHub의 데이터 보호 계약에 따라 계속 보호됩니다. 중요한 점은 이것이 Copilot 상호작용 데이터에 관한 것이지, GitHub에 그냥 방치된 비공개 저장소에 관한 것이 아니라는 점입니다.
같은 시기에 다른 이유로 이전 논의가 다시 불붙었습니다. 공개된 자체 호스팅 Git 인스턴스가 대량의 자동화 트래픽을 감당하고 있었던 것입니다. 한 Hacker News 토론이 그 문제에 관한 운영자들의 유용한 보고를 모았습니다. 나에게는 한 시대의 끝: 더 이상 자체 호스팅 git은 없다.
그러면 "GitHub이냐 자체 호스팅이냐?"보다 유용한 질문이 남습니다. 당신이 실제로 해결하려는 문제는 무엇인가요?
요약
답은 세 가지입니다. 자신의 상황에 맞는 것을 고르세요.
- A: 옵트아웃하고 남기. Copilot 학습 변경이 유일한 걱정거리이고 GitHub이 팀의 운영 요구에 여전히 맞을 때 선택합니다. 계정 수준 설정을 끄고 하던 일을 계속하세요.
- B: 하이브리드로 운영하기. 네트워크 효과를 위해 공개 오픈소스는 GitHub에 남깁니다. 비공개 코드는 VPN이나 IP 허용 목록 뒤에 있는 자체 호스팅 Forgejo, Gitea, GitLab CE 인스턴스로 옮깁니다. 공개적 도달 범위와 비공개 통제가 동시에 중요할 때 선택합니다.
- C: 완전히 이전하기. 모든 것을 GitHub 밖으로 옮깁니다. 규제, 데이터 소재지, 거버넌스, 또는 자유 소프트웨어 전용 정책 때문에 GitHub이 배제되고 팀이 운영 비용을 감당할 수 있을 때 선택합니다.
대부분의 독자는 A 또는 B 입장에 해당합니다. C 입장은 더 엄격한 거버넌스, 주권, 가치 요구사항으로 정당화되는 것이지 Copilot 설정 하나만으로는 아닙니다.
2026년 4월에 실제로 바뀐 것
기계적인 변경 자체는 작습니다. Copilot 설정에서 개인 구독자는 "Allow GitHub to use my data for AI model training"을 Disabled로 바꿀 수 있습니다. GitHub은 대상 자료를 자사 기능과 서비스와의 상호작용, 즉 입력, 출력, 코드 조각, 관련 컨텍스트로 설명하며, Copilot을 거친 적이 없는 비공개 저장소의 내용은 여기에 해당하지 않습니다.
Copilot Business와 Enterprise에는 이 토글이 나타나지 않습니다. 해당 데이터는 GitHub의 데이터 보호 계약으로 보호되기 때문입니다. 개인용 요금제에서는 설정을 끄면 학습 정책에 대한 우려는 해소되지만, 공급업체가 통제하는 정책에 의존한다는 더 큰 반론까지 해결되지는 않습니다.
Copilot 변경은 계기가 될 수는 있어도 근거 전부는 아닙니다. 팀은 플랫폼 종속, GitHub에 묶인 신원, Actions를 중심으로 짠 워크플로, 데이터 소재지, 나중에 다시 옮기기가 얼마나 쉬운지에도 신경 쓸 수 있습니다. 이런 것들이 이전에 관한 질문이고, 학습 토글은 설정 하나일 뿐입니다.
이 구분이 중요합니다. 옵트아웃은 데이터 사용 설정 하나를 바꾸지만, 이전은 호스팅, 신원, 통합, 정책을 누가 통제하는지를 바꿉니다. 두 번째 결정에 따르는 운영 비용이 훨씬 큽니다.
세 가지 입장 자세히 보기
의사결정을 세 줄로 압축했습니다. 자세한 내용은 아래에 있습니다.
| 당신의 관심사 | 답 | 할 일 |
|---|---|---|
| 내 Copilot 상호작용 데이터가 학습에 쓰이는 것 | 옵트아웃하고 남기 (입장 A) | 설정을 끄고 하던 일로 돌아가기 |
| 미국 업체에 두고 싶지 않은 비공개 코드 + 숨기고 싶지 않은 활발한 오픈소스 | 하이브리드 (입장 B) | 비공개 저장소는 VPN 뒤에서 자체 호스팅하고, 공개 오픈소스는 GitHub에 남기기 |
| 데이터 주권, 규제 산업, 원칙에 따른 자유 소프트웨어 전용, 완전한 공급업체 독립 | 전면 이전 (입장 C) | 전부 옮기고 운영 비용을 예산에 넣기 |
입장 A: 옵트아웃하고 남기
비공개 저장소를 쓰는 1인 개발자나 소규모 팀이고 불만이 학습 기본값 하나뿐이라면, 이것이 답입니다. 설정 하나 바꾸기: 1분, 한 번이면 끝. 자체 호스팅: 소액의 VPS 청구서, 실제로 검증하는 백업 전략, GitHub 인증을 전제로 짜여 있어서 다시 만들어야 하는 연동들, 그리고 하필 최악의 순간에 닥치는 업그레이드나 복구 작업.
자체 호스팅이 여전히 가치 있을 수 있지만, 그 반복 작업이 정말 필요한 무언가를 사 줄 때만 그렇습니다.
가장 강력한 반론은 이것입니다. 그 토글 역시 공급업체의 결정이라는 점. GitHub은 2026년에 이 상호작용 데이터를 기본적으로 학습에 쓰지 않던 방식에서 기본적으로 쓰는 방식으로 바꿨고, 정책을 또 바꿀 수도 있습니다.
당신의 근본적인 걱정이 "내 코드에 대해 미국 업체가 일방적으로 결정하는 일은 절대 없었으면 한다"라면, 체크박스로는 해결되지 않으며 입장 A는 당신에게 틀린 답입니다. 입장 C로 건너뛰세요.
하지만 걱정이 정확히 "지금의 Copilot 상호작용 데이터가 학습에 들어가는 건 싫다"이고, 다음 변화가 있기 전까지는 GitHub의 설정을 믿겠다면, 입장 A가 가장 저렴한 정답입니다. 싸고 정확한 것에 부끄러워할 이유는 없습니다.
입장 B: 하이브리드 모델로 운영하기
하이브리드 호스팅은 공개적 도달 범위와 비공개 통제를 분리합니다.
역할 분담은 단순합니다. 공개 오픈소스는 GitHub에 남습니다. 네트워크 효과, 기여자 유입, Dependabot, Actions 생태계는 실질적인 가치입니다. 비공개 코드는 VPN이나 IP 허용 목록 뒤에 있는 자체 호스팅 인스턴스로 옮겨, 공개 인터넷에서는 절대 닿을 수 없게 합니다.
이것이 통하는 이유는 위협 모델의 성질에 있습니다. Copilot 학습에 대한 우려는 GitHub을 통해 보낸 Copilot 상호작용 데이터에만 해당합니다. AI 스크레이퍼 트래픽 문제(다음 절)는 공개적으로 접근 가능한 인스턴스에만 해당합니다. 비공개 하이브리드 구성은 둘 다 피해 갑니다.
2~10명 규모의 비공개 팀이라면 Forgejo나 Gitea에는 2 vCPU와 4 GB RAM이 더 안전한 출발점이며, 검색 색인, 패키지, CI가 같은 호스트를 쓴다면 여유를 더 두세요. 이는 GitLab CE가 아니라 Forgejo/Gitea 기준의 사이징으로 보시면 됩니다. GitLab의 단일 노드 설치 튜토리얼 은 CI 작업 부하를 빼고도 8 vCPU와 메모리 7.2 GB에서 시작합니다.
웹 UI를 80이나 443 포트에 그대로 노출하지 마세요. 방화벽, 프록시, VPN, 메시 네트워크 계층에서 제한하십시오. CI 러너는 양쪽 모두를 처리할 수 있습니다.
플랫폼 선택은 하이브리드 모델 자체보다 기능 구성을 더 크게 바꿉니다. Forgejo와 Gitea는 더 가벼운 비공개 포지에 어울리고, GitLab CE는 통합 CI/CD와 레지스트리 스택까지 필요할 때 더 합리적입니다.
백업은 감당할 만하지만, git bundle 하나로 축소하지는 마세요. Forgejo의 공식 업그레이드 안내 는 Forgejo가 사용하는 모든 스토리지의 동기화된 특정 시점 스냅샷을 신뢰할 수 있는 백업으로 보며, 그것이 현실적이지 않을 때는 Forgejo 덤프에 별도의 PostgreSQL 또는 MySQL 덤프를 함께 두라고 합니다. Forgejo든 Gitea든 저장소, 데이터베이스, 설정, 첨부파일, LFS 데이터를 함께 보관하고, 사본을 서버 밖에 두고, 복원을 실제로 시험해 보세요.
개발자의 로컬 클론은 코드는 복구할 수 있어도 이슈, 사용자, PR 메타데이터, 첨부파일, 모든 LFS 객체까지는 복구하지 못합니다. 비공개 포크가 나중에 공개된다면, 그때 GitHub 미러로 푸시하세요.
입장 C: 통제가 요구사항일 때의 전면 이전
전면 이전은 공급업체 독립이 선호가 아니라 요구사항일 때 가장 분명하게 들어맞습니다.
세 부류가 두드러집니다. 감사, 데이터 소재지, 공급업체 통제 규정 때문에 GitHub이 배제되는 규제 산업 팀. 주권 요구사항이 취향이 아니라 방침인 공공 부문 또는 EU 팀. 그리고 Microsoft 소유 인프라에서 벗어나고 싶으면서 이미 Linux 서비스를 운영할 인력을 갖춘 자유 소프트웨어 전용 조직입니다.
비용은 작은 VPS, 지속적인 유지보수, 그리고 연동 손실입니다. 사람들이 잊는 부분이 바로 이 연동 손실입니다. "Sign in with GitHub"으로 인증하는 것은 모두 GitHub에 남거나 별도의 아이덴티티 공급자가 필요합니다.
이전 계획은 저장소가 아니라 의존성을 중심으로 세우세요. PR 미리보기, 서드파티 Actions, 봇, 웹훅, 패키지 레지스트리, "Sign in with GitHub" 연동은 새 자격 증명, 새 워크플로, 또는 대체 서비스를 필요로 할 수 있습니다. 스타와 워처는 새 포지에서 네이티브 레코드가 되지 않으므로, 공개 프로젝트는 기존 발견 신호의 일부도 함께 포기하게 됩니다.
정식 원격 저장소를 바꾸기 전에 예행연습을 하세요. 대표 저장소 하나를 옮기고, 그 연동들을 다시 구성하고, 이슈와 PR 이력을 확인하고, 롤백 경로를 문서로 남기십시오. 플랫폼 비교는 그 의존성 점검 다음 순서입니다.
서버를 직접 운영하지 않으면서 비영리 거버넌스를 원하는 팀이라면 Codeberg를 고려해 볼 만합니다.
주권에 관한 팁. EU 데이터 소재지 때문에 자체 호스팅을 택하는 것이라면 데이터센터 위치가 중요합니다. 프랑크푸르트나 암스테르담 같은 곳이 재미없지만 옳은 선택입니다. 버지니아의 가장 싼 VPS는 당신의 DPA에 아무 도움이 되지 않습니다.
공개 Git 호스팅의 운영 비용
공개 자체 호스팅은 인터넷에 노출된 모든 애플리케이션이 겪는 것과 같은 자동화 트래픽에 포지를 노출시킵니다. 다만 저장소 페이지에는 blame 화면, 아카이브, 커밋 이력처럼 비용이 큰 경로가 들어 있습니다. 아래 보고들은 개별 운영자의 경험이며 벤치마크가 아닙니다.
앞서 언급한 자체 호스팅 Git 토론에서 한 운영자는 60일 동안 cgit 인스턴스에 들어온 요청이 37,212,377건이었고 그중 99% 이상이 봇으로 분류됐다고 보고했습니다.
같은 토론에서 kstrauser는 Forgejo 인스턴스를 하루 약 600,000건의 요청에서 대략 1,000건까지 줄였다고 전했는데, 그것도 표준적인 완화책 위에 자바스크립트와 쿠키 기반 챌린지를 얹은 뒤에야 가능했습니다.
다른 운영자들은 fail2ban, GeoIP 차단, 자율 시스템 단위 블랙홀 처리, 그리고 저장소를 다시 호스팅형 플랫폼으로 되돌리는 방법을 언급했습니다. 이런 보고는 있을 수 있는 실패 양상을 보여줄 뿐, 보편적인 트래픽 기준치는 아닙니다.
이것이 어려운 기계적인 이유는 이렇습니다. 단순한 IP별 속도 제한은 주거용 프록시를 돌려 쓰는 트래픽 앞에서 무력할 수 있습니다. 스크레이퍼 무리는 요청을 충분히 많은 IP에 흩뿌려서 개별 주소는 어느 것도 남용처럼 보이지 않게 만들 수 있고, 그러는 동안 서버는 총량으로 무너집니다.
자바스크립트나 쿠키 챌린지는 정교하지 않은 스크래핑을 줄일 수 있지만, 자바스크립트를 쓰지 않는 사용자를 막고 모든 경로에 적용하면 HTTPS 상의 Git 동작을 방해할 수도 있습니다. CDN 캐싱은 반복적인 읽기에는 도움이 되지만, 아카이브, blame 화면, 커밋별 페이지처럼 고유하거나 비용이 큰 엔드포인트에는 훨씬 덜 도움이 됩니다.
챌린지가 바꾸는 것은 경제성입니다. Anubis 는 포지 앞단에 자리 잡고, 서버가 보호된 페이지를 돌려주기 전에 클라이언트에게 챌린지를, 이를테면 작은 작업 증명 연산을 완료하게 합니다. 그 결과 대량 크롤링의 비용이 올라갑니다. 이는 완화책이지 보장이 아닙니다.
브라우저 챌린지는 선별적으로 적용하세요. Git 작업용으로 SSH는 계속 열어 두고, 그 경로를 보호하기 전에 HTTPS 상의 Git을 시험해 보십시오. Git 클라이언트에 돌아간 챌린지 페이지는 쓸모 있는 검증이 아니라 실패한 clone이 됩니다.
GitHub은 이런 부류의 트래픽을 호스팅 서비스의 일부로 흡수합니다. 공개된 Forgejo나 cgit 인스턴스는 용량 계획, 남용 통제, 캐싱, 완화책을 모두 당신에게 남깁니다. 이전 결정에서 중요한 대목은 소프트웨어의 순수 비용이 아니라 바로 이 운영 부담의 이전입니다.
하이브리드 모델이 차선책이 아니라 일급 선택지인 이유가 여기 있습니다. 비공개 코드는 VPN 뒤에 있으니 스크레이퍼가 닿을 수 없습니다. 공개 오픈소스는 GitHub에 있으니 봇 트래픽은 GitHub의 남용 대응 인프라가 처리합니다.
그래도 공개된 자체 호스팅 포지를 원한다면, 로그, 속도 제어, 캐싱, 봇 대응, 모니터링, 그리고 브라우저 챌린지에 의존하지 않는 검증된 Git 트래픽 경로까지 예산에 넣으세요. 스크레이퍼 방어는 예외 상황이 아니라 평시 운영의 일부로 다루십시오.
오픈소스 메인테이너를 위한 네트워크 효과 문제
여기서는 아주 구체적인 독자에게 말하고 있습니다. 당신은 오픈소스 프로젝트를 관리합니다. 기여자 스무 명, 별 이백 개, 그리고 살아 있는 이슈 트래커. 그리고 이것을 GitHub 밖으로 옮길까 고민 중입니다.
무엇을 맞바꾸는지 솔직해지세요. 기여자에게 발견될 가능성, github.com이 주는 암묵적인 신뢰의 표식, Dependabot, CodeQL, 그리고 GitHub 인증에 기대어 돌아가는 서드파티 생태계입니다. 어느 것도 다른 곳에서 불가능하지는 않지만, 전부 마찰이 됩니다.
제가 제안하는 경험칙은 이렇습니다. 프로젝트의 가치가 대부분 코드 자체에 있다면, 자체 호스팅을 정당화하기가 더 쉽습니다.
코드는 어디로든 따라갑니다. 하지만 그 가치가 기여자, 이슈, 검색 노출, github.com을 둘러싼 신뢰에 크게 기대고 있다면, 떠나는 일은 프로젝트를 굴러가게 만드는 요소의 일부를 메인테이너의 마음이 편해지는 것과 맞바꾸는 셈입니다. 이유가 충분히 크다면 정당한 거래입니다. 뭔가를 증명하려고 하는 것이라면 나쁜 거래입니다.
Codeberg의 플랫폼 소개 는 비영리 단체 Codeberg e.V.가 운영하는 Forgejo 기반 서비스를 설명합니다. 오픈소스 메인테이너에게 이는 포지를 직접 운영하는 유지보수 부담 없이 커뮤니티 거버넌스를 얻는다는 뜻입니다.
업그레이드 의무 없이 커뮤니티 거버넌스를 원하는 오픈소스 성향의 팀에게, 이는 공개 포지를 직접 운영하는 것보다 운영상 도약의 폭이 작습니다. SourceHut은 훨씬 더 의식적인 워크플로 전환이라 별도의 평가가 필요합니다.
문제를 해결하는 가장 작은 변화를 택하세요
원격 저장소를 바꾸기 전에 요구사항을 한 문장으로 적어 보세요. Copilot 상호작용 데이터 학습을 멈추는 것, 공개 호스팅과 비공개 호스팅을 분리하는 것, 아니면 아키텍처에서 GitHub을 걷어내는 것. 요구사항을 이름 붙일 수 없다면 아직 이전할 때가 아닙니다.
이전을 한다면 먼저 대표 저장소 하나로 시범 운영을 하세요. 정식 원격 저장소를 바꾸기 전에 인증, Actions, 웹훅, 패키지 배포, 미리보기 환경, 이슈 이력, LFS 데이터, 롤백 절차를 목록으로 정리하십시오.
Cloudzy의 원클릭 Forgejo 배포 는 하이브리드 모델의 비공개 쪽을 빠르게 마련하는 방법이고, 아무 Linux VPS 에 수동으로 설치해도 됩니다. 어느 길을 택하든 웹 UI는 비공개로 두고, 애플리케이션 상태 전체를 백업하고, 중요한 저장소를 옮기기 전에 복원을 시험해 보세요.
루트 액세스, NVMe, AMD EPYC 성능을 갖춘 Linux VPS에서 개발하세요.
Linux 요금제 보기통제는 팀이 감당할 수 있는 운영 비용으로 요구사항을 해결할 때에만 쓸모가 있습니다.
자주 묻는 질문
Copilot 학습 정책 변경 때문에 GitHub에서 이전해야 하나요?
자동으로 그렇지는 않습니다. 걱정이 Copilot 상호작용 데이터가 모델 학습에 쓰이는 것뿐이라면, 계정 수준 설정을 끄는 것이 가장 작은 올바른 해법입니다. 이전은 데이터 소재지, 거버넌스, 공급업체 독립, 자유 소프트웨어 전용 같은 더 강한 통제까지 필요할 때 의미가 있습니다.
GitHub이 내 모든 비공개 저장소로 학습하나요?
아닙니다. 여기서 다룬 정책 변경은 Copilot을 통해 전송된 해당 상호작용 데이터, 즉 입력, 출력, 코드 조각, 관련 컨텍스트를 대상으로 합니다. GitHub에 저장된 모든 비공개 저장소가 자동으로 모델 학습에 쓰인다는 뜻은 아닙니다.
Git을 자체 호스팅하면 항상 더 사적인가요?
그렇게 운영할 때만 그렇습니다. VPN이나 IP 허용 목록 뒤에 있는 비공개 포지는 노출을 줄일 수 있지만, 공개적으로 접근 가능한 인스턴스는 패치, 모니터링, 봇 대응, 접근 제어, 백업 같은 책임을 더합니다. 평소 GitHub이 대신 떠맡던 것들이죠.
어떤 자체 호스팅 Git 플랫폼을 골라야 하나요?
더 가벼운 비공개 포지를 원한다면 Forgejo나 Gitea를 고르세요. 통합 CI/CD와 패키지 또는 컨테이너 레지스트리가 더 높은 자원 및 유지보수 요구를 감수할 만큼 중요하다면 GitLab CE를 고르세요.
소규모 팀이라면 Forgejo나 Gitea에 어느 정도 크기의 VPS가 필요한가요?
2명에서 10명 규모의 비공개 팀이라면 2 vCPU와 4 GB RAM이 더 안전한 출발점입니다. 검색 색인, 패키지, 큰 저장소, CI 러너가 같은 호스트를 나눠 쓴다면 용량을 늘리세요. GitLab CE는 자원을 더 요구하므로 따로 계산하십시오.
정식 원격 저장소를 바꾸기 전에 무엇을 시험해 봐야 하나요?
대표 저장소 하나로 시범 운영을 하세요. 전부 옮기기 전에 이슈와 PR 이력, 인증, Actions 또는 대체 CI 워크플로, 웹훅, 패키지 배포, LFS 데이터, 미리보기 환경, 백업, 복원, 롤백 경로를 확인하십시오.
