클라우드플레어의 공개 초대장
클라우드플레어가 블로그에 꽤 도발적인 제목의 글을 올렸어요. “다음 Git 플랫폼을 클라우드플레어 위에서 만들어 달라”는 내용인데요, 제목만 보면 자기들이 직접 GitHub 대항마를 내놓겠다는 게 아니에요. 그런 걸 만들 개발자와 스타트업에게 판을 깔아 주겠다는 메시지로 읽혀요.
왜 하필 지금 Git 호스팅일까요? 지난 십수 년 동안 Git 호스팅은 사실상 GitHub의 독무대였고, GitLab과 Bitbucket이 뒤를 잇는 구도였어요. 그런데 최근 이 판을 흔들 만한 변화가 두 가지 생겼어요.
첫째는 AI 코딩 에이전트예요. 사람 개발자는 하루에 몇 번 push하지만, 에이전트는 작업 하나에도 브랜치를 여러 개 만들고, 커밋을 수없이 하고, 저장소를 계속 클론해요. 에이전트 여러 개를 동시에 돌리는 게 흔해지면서 Git 서버가 받는 트래픽의 성격 자체가 바뀌고 있어요. 기존 플랫폼은 사람의 속도에 맞춰 설계됐다는 게 문제죠.
둘째는 GitHub 자체의 변화예요. 2025년에 GitHub은 마이크로소프트의 AI 조직으로 편입됐고, Azure 인프라 이전을 우선 과제로 삼았다는 보도도 나왔어요. 잦은 장애에 대한 개발자들의 불만도 꾸준했고요. 대안을 찾는 사람이 늘어날 수밖에 없는 상황이에요.
Git은 사실 클라우드와 궁합이 좋다
이 제안이 왜 그럴듯한지 이해하려면 Git이 내부적으로 어떻게 생겼는지 알면 좋아요.
Git은 내용 주소 기반 저장소(content-addressable storage)예요. 이게 뭐냐면, 파일 내용을 해시 함수에 넣어 나온 값(SHA)을 그 파일의 이름표로 쓰는 창고라고 보면 돼요. 내용이 한 글자라도 바뀌면 이름표도 바뀌니까, 한 번 저장된 객체는 절대 바뀌지 않아요. 파일 내용인 blob, 폴더 구조인 tree, 스냅샷 기록인 commit 모두 이런 불변 객체예요.
반면 ref, 즉 브랜치 이름은 달라요. main 브랜치가 어떤 커밋을 가리키는지는 push할 때마다 바뀌죠. 두 사람이 동시에 push하면 누가 먼저인지 정확히 판정해야 하니까 강한 일관성이 필요해요.
이 두 가지 성격을 클라우드플레어 제품에 대응해 보면 꽤 깔끔한 그림이 나와요. 아래는 제품 구성을 바탕으로 정리해 본 예시예요.
| Git 구성 요소 | 특징 | 어울리는 클라우드플레어 제품 |
|---|---|---|
| Git 객체 (blob, tree, commit) | 불변, 대용량 | R2 (객체 스토리지) |
| ref (브랜치, 태그) | 자주 변경, 동시성 제어 필요 | Durable Objects |
| clone/push 프로토콜 처리 | 전 세계에서 요청 수신 | Workers |
| 무거운 압축 연산 | CPU와 메모리 많이 사용 | Containers |
| 이슈, PR, 사용자 정보 | 관계형 데이터 | D1 (SQLite 기반 DB) |
여기서 핵심은 Durable Objects예요. 전 세계에 딱 하나만 존재하도록 보장되는 작은 상태 보관 서버라고 생각하면 돼요. 저장소 하나마다 Durable Object 하나를 배정하면, 그 저장소로 들어오는 push는 모두 한 곳에서 순서대로 처리돼요. 복잡한 분산 락 없이도 동시 push 충돌을 자연스럽게 막을 수 있는 거죠. 불변 객체는 R2에 넣어 두면 캐싱하기 쉽고, R2는 데이터 전송(이그레스) 요금이 없어서 clone이 잦은 Git과 잘 맞아요.
다만 쉬운 길만 있는 건 아니에요. git clone 요청이 오면 서버는 필요한 객체를 모아 압축한 packfile을 만들어 보내야 하는데, 이 작업이 CPU와 메모리를 꽤 써요. Workers 같은 서버리스 환경은 실행 시간과 메모리 제한이 있어서 거대한 모노레포를 다루기엔 빡빡할 수 있어요. 그래서 Containers 같은 보완재가 필요해 보이고요. 클라우드플레어가 구체적으로 어떤 지원을 내걸었는지는 원문에서 꼭 확인해 보세요.
업계 흐름 속에서 보면
GitHub 대안은 이미 여럿 있어요. GitLab은 셀프 호스팅과 CI/CD 통합이 강점이고, Gitea와 그 포크인 Forgejo는 직접 설치해 가볍게 쓰는 오픈소스예요. 비영리 호스팅 서비스인 Codeberg도 Forgejo 기반이고요. 좀 더 실험적인 쪽으로는 P2P 방식의 Radicle, 블루스카이의 AT Protocol 위에 만든 Tangled 같은 프로젝트도 있어요.
이들과 비교하면 클라우드플레어의 접근은 결이 달라요. 기존 대안들이 대부분 ‘서버나 클러스터에 설치하는 애플리케이션’이라면, 클라우드플레어는 전 세계 엣지에 퍼져 있는 빌딩 블록을 조립하는 방식을 제안하는 거예요. 에이전트가 저장소를 쉴 새 없이 만들고 지우는 시대라면 이런 구조가 유리할 수 있어요. 대신 특정 플랫폼에 깊이 묶이는 벤더 종속 위험은 감수해야 하고요.
한국 개발자에게 주는 시사점
국내 기업은 보안 정책 때문에 GitLab을 직접 설치해 운영하는 경우가 많은데요, 당장 갈아탈 이유는 없어요. 하지만 이런 분들에게는 눈여겨볼 만한 소식이에요.
- AI 에이전트 기반 개발 도구를 만드는 팀: 에이전트마다 임시 저장소를 대량으로 만들고 지워야 한다면, 기존 호스팅의 API 한도에 막히는 대신 직접 가벼운 Git 백엔드를 꾸리는 선택지가 생겨요.
- Git을 깊이 이해하고 싶은 주니어: 아무 저장소에서나
git cat-file -p HEAD를 쳐 보면 커밋 객체가 실제로 어떻게 생겼는지 볼 수 있어요. Pro Git 책의 Git Internals 장도 추천해요. - 사이드 프로젝트 소재를 찾는 분: Workers와 R2로 미니 Git 서버를 만들어 보면 분산 시스템, 프로토콜, 스토리지를 한 번에 배울 수 있어요.
마무리
정리하면, 불변 객체와 가변 ref로 나뉘는 Git의 구조는 엣지 클라우드와 잘 맞고, AI 에이전트가 Git 트래픽의 판을 바꾸면서 새로운 Git 플랫폼이 나올 틈이 생겼다는 거예요.
GitHub에서 옮겨 간다면 가장 아쉬울 기능은 뭔가요? 에이전트 시대의 Git 플랫폼이라면 꼭 갖춰야 할 기능은 뭐라고 생각하세요?
🔗 출처: Hacker News