깃허브 의존을 끊어야 할 때: IT 에이전시가 셀프호스팅 Git으로 전환하는 이유 (jorijn.com)

한줄 요약

클라이언트 코드를 깃허브에 두는 순간, 그 코드의 관할권은 미국 기업에 넘어간다.

본문

IT 개발 에이전시가 깃허브(GitHub)를 코드 저장소로 사용하는 것은 더 이상 단순한 인프라 선택이 아니다. 클라이언트의 소스코드, 비즈니스 로직, 민감한 설정값이 어떤 법적 환경 아래 놓이는지를 결정하는 일이다. 최근 글로벌 IT 업계에서 깃허브 의존도를 줄이고 자체 호스팅 Git 플랫폼으로 이전하는 움직임이 뚜렷해지고 있다. 에이전시 입장에서는 이 흐름을 단순한 유행으로 볼 수 없다.

클라이언트 코드를 깃허브에 두면 생기는 법적 리스크

깃허브는 미국 기업이 소유한 플랫폼이다. 여기에 올라간 데이터는 미국 연방법의 적용을 받는다. 서버가 어디에 있든 상관없다. 미국 정부는 미국에 본사를 둔 기업이 전 세계 어디에 저장한 데이터든 법적으로 열람을 강제할 수 있다.

국내 에이전시가 금융, 의료, 공공기관 고객의 프로젝트를 수행할 때 깃허브를 사용한다면, 해당 코드는 이 관할권 안에 들어간다. 클라이언트에게 "코드는 안전하게 관리됩니다"라고 말하지만, 정작 그 코드가 어떤 법적 환경에 있는지 제대로 설명하는 에이전시는 드물다. GDPR이나 국내 개인정보보호법 준수를 선언하더라도, 저장 위치와 법적 관할은 별개 문제다.

AI 학습 데이터로 활용되는 코드, 에이전시는 알고 있나

깃허브는 코파일럿(Copilot) 기능과 연동해 사용자 상호작용 데이터를 AI 모델 학습에 활용한다. 기본 설정은 수집 허용이고, 사용자가 직접 꺼야 한다. 더 중요한 점은 개별 개발자가 옵트아웃을 해야 한다는 것이다. 에이전시 리드가 저장소 단위로 막을 수 없다.

클라이언트 코드베이스를 다루는 개발자 10명 중 한 명이라도 기본 설정을 그대로 사용한다면, 그 코드 조각들은 AI 학습 데이터로 흘러간다. 에이전시가 클라이언트에게 NDA를 받고, 보안 서약을 받아도 플랫폼 레벨에서 이 경로를 막을 수단이 없다. 코드 기밀 유지를 계약으로 약속했지만 기술적으로는 보장하지 못하는 구조다.

플랫폼 의존성이 에이전시 운영에 주는 실질적 타격

지난 1년간 깃허브는 수십 차례의 장애를 겪었다. 그 중 여러 건은 단순 접속 불가가 아니라 머지된 커밋이 되돌려지거나 풀 리퀘스트 데이터가 유실되는 수준이었다. 에이전시 입장에서 납기가 걸린 날 저장소가 수시간 다운되는 것은 단순한 불편이 아니다. 클라이언트와의 신뢰 문제다.

더 근본적인 문제는 플랫폼의 방향성이다. 깃허브는 현재 마이크로소프트의 AI 사업 부문 산하에서 운영되고 있다. 독립 CEO 없이 AI 스택 확장을 핵심 목표로 삼는 조직의 일부가 된 것이다. 에이전시가 사용하는 코드 관리 플랫폼이 AI 제품 판매를 위한 데이터 파이프라인과 점점 겹쳐지는 구조다. 앞으로 정책이 어떻게 바뀌든 에이전시에게는 선택권이 없다.

셀프호스팅 Git, 에이전시에게 현실적인 선택인가

Forgejo, Gitea, 자체 호스팅 GitLab CE 같은 대안은 이미 충분히 성숙했다. CI/CD 파이프라인, 이슈 트래커, 코드 리뷰, 접근 권한 관리 등 에이전시 운영에 필요한 기능은 모두 갖추고 있다. 클라우드 서버 한 대에 설치하면 월 몇만 원으로 전체 팀이 사용할 수 있다.

셀프호스팅으로 얻는 건 단순한 비용 절감이 아니다. 클라이언트에게 "귀사의 코드는 저희 인프라에서만 관리됩니다"라고 말할 수 있는 근거가 생긴다. 계약서에 명시할 수 있고, 감사에서 증명할 수 있다. 특히 금융, 공공, 헬스케어 분야 클라이언트를 다루는 에이전시라면 이는 단순한 기술 선택이 아니라 영업 경쟁력이 된다.

물론 운영 부담은 생긴다. 백업, 보안 패치, 모니터링은 직접 챙겨야 한다. 그러나 이 부담을 감수하는 것과 클라이언트 코드의 법적 관할을 외부 기업에 맡기는 것 사이에서 에이전시는 명확한 선택을 해야 할 시점이 됐다.