Git 저장소 하나가 초당 수백 건의 push를 받는다면 여러분의 인프라는 버틸 수 있을까요? Git 확장성 문제는 20년 가까이 알려진 숙제인데, 최근 GeekNews에 소개된 소식에 따르면 코드 에디터 기업 Cursor가 이 문제에 답하기 위해 자체 Git 호스팅 시스템 ‘Continuity’를 새로 만들었습니다.
단순한 기술 뉴스로 넘기기엔 아쉬운 이야기예요. 이 사례에는 AI 에이전트가 개발 워크플로를 어떻게 바꾸고 있는지, 그리고 그 변화 속에서 시니어 개발자가 왜 여전히 필요한지에 대한 신호가 담겨 있습니다.
Spokes 방식의 한계: 복제본을 늘릴수록 느려지는 합의 구조
GitHub가 2013년경 개발해 업계 표준이 된 Spokes 구조는 저장소를 여러 서버에 복제하고, 3단계 커밋(3PC) 합의 알고리즘으로 모든 복제본을 항상 일치시키는 방식입니다. Cursor 공식 블로그(Git at any scale)에 따르면, 이 구조는 복제본이 3대 정도일 때는 안정적이지만, 복제본을 늘릴수록 push 처리 속도가 오히려 떨어지는 구조적 한계를 갖고 있습니다.
2026년 현재 기업의 평균 저장소는 거대한 모노레포로 바뀌었고, CI 트래픽만으로도 복제본 3대로는 부족한 경우가 많아졌습니다. 그런데 복제본을 늘리면 합의에 필요한 왕복 통신이 늘어 커밋 처리량이 떨어지는 딜레마가 생깁니다.
Continuity의 해법: S3 기반 WAL로 조회 성능을 선형 확장
Cursor의 해법은 합의 알고리즘을 없애는 것이었습니다. Continuity는 push를 S3 호환 오브젝트 스토리지에 write-ahead log(WAL)로 저장하고, 이 WAL을 유일한 진실의 원천으로 둡니다. 각 서버는 로컬 NVMe 디스크에 저장소를 캐시처럼 보관하다가, 필요하면 WAL에서 다시 만들어 냅니다.
Agents have fundamentally changed the way we work with software… More code, more PRs, more CI runs.
Vicent Martí, Cursor 공식 블로그 ‘Git at any scale’
같은 글에 따르면, 이 구조로 Cursor는 100대 복제본까지 읽기 성능이 선형으로 늘어나는 것을 자체 스트레스 테스트에서 확인했고, S3 Standard 기준 초당 최대 120건, 지연이 더 낮은 S3 Express One Zone 기준으로는 초당 300건 이상의 push를 처리했다고 밝혔습니다. 합의를 위한 왕복 통신이 없으니 복제본을 늘려도 쓰기 성능이 떨어지지 않는 셈입니다.
에이전트가 만드는 트래픽 패턴이 인프라를 바꾼다
여기서 흥미로운 지점은 ‘왜 지금’이라는 질문입니다. Git 호스팅의 확장성 문제는 20년 가까이 알려진 이야기인데, Cursor는 왜 이 시점에 처음부터 새로 만들었을까요.
답은 AI 코딩 에이전트입니다. 사람 개발자 한 명이 하루에 만드는 커밋과 PR의 수는 한계가 있지만, 여러 에이전트가 동시에 브랜치를 만들고 커밋하고 PR을 여는 지금은 그 한계가 사라졌습니다. 트래픽의 절대량뿐 아니라 패턴 자체가 바뀐 거예요. 수백만 개의 일회성 저장소가 생겼다가 버려지는 상황은 사람 중심 워크플로에서는 상상하기 어려웠던 부하입니다.
결국 인프라 설계의 전제 자체가 바뀐 겁니다. “복제본은 몇 개면 충분한가” 같은 질문이 “복제본 수와 무관하게 항상 안전한가”로 바뀌었다는 점이, 이 사례를 단순한 스타트업 기술 자랑이 아니라 업계 신호로 봐야 하는 이유입니다.
한국 개발팀이 지금 챙겨야 할 신호
후배님 팀이 당장 자체 Git 호스팅을 만들 필요는 없어요. 대부분은 GitHub나 GitLab을 그대로 쓰는 게 맞습니다. 그런데 이 사례가 주는 실무 신호는 따로 있어요.
- 사내에 AI 에이전트 기반 자동 PR·자동 커밋 도구를 도입한다면, CI 러너 수와 저장소 트래픽이 예상보다 훨씬 빠르게 늘어날 수 있다는 점을 미리 감안해야 해요.
- 모노레포를 쓰는 팀이라면 Git 서버(온프레미스든 SaaS든)의 처리량 한계를 한 번쯔음 실측해보는 게 좋아요. 장애가 나서야 한계를 아는 것보다 낫거든요.
- 플랫폼 엔지니어링 조직이라면 “합의(consensus) 기반” vs “WAL 기반” 같은 아키텍처 선택지가 다시 논의될 가능성이 커요. 신입 면접에서 분산 시스템 트레이드오프를 묻는 질문도 늘어날 수 있습니다.
인프라를 이해하는 시니어가 여전히 대체되지 않는 이유
저는 이 사례를 보면서 오히려 안심이 되는 부분이 있었어요. AI 에이전트가 코드를 아무리 많이 써내도, “이 아키텍처를 왜 이렇게 설계했는가”를 판단하고 트레이드오프를 짚어내는 역할은 결국 사람, 그중에서도 인프라를 이해하는 시니어에게 남거든요.
사람인·원티드랩 같은 국내 채용 플랫폼의 채용 공고를 보면 “AI 도구 활용 경험”을 우대 조건으로 거는 곳은 많아졌지만, 그 도구가 만들어내는 부하를 감당할 인프라를 설계할 사람을 뽑는 공고는 여전히 시니어·리드급에 집중돼 있어요. 코드를 빠르게 뽑아내는 능력과, 그 코드가 쌓였을 때 시스템이 버티게 만드는 능력은 완전히 다른 역량이기 때문입니다.
그러니 후배님이 지금 커리어를 어디로 끌고 갈지 고민 중이라면, AI 도구를 잘 쓰는 것만큼이나 “AI가 만들어내는 결과물을 감당하는 시스템을 어떻게 설계하는가”를 공부하는 쪽도 눈여겨보세요. 이 영역은 당분간 대체되기 어렵거든요.
판단 체크리스트
- 우리 팀 CI/Git 서버가 에이전트 기반 도구 도입 이후 트래픽이 얼마나 늘었는지 측정하고 있는가
- 저장소 확장성 문제를 “복제본 늘리기”로만 해결하려 하고 있지 않은가
- 분산 시스템 기초(합의 알고리즘, WAL, 일관성 모델)를 이력서·면접에서 설명할 수 있는가
- AI 도구 활용 경험 외에, 그 도구가 만든 부하를 다룰 줄 아는지도 스스로 점검하고 있는가
넷 중 두 개 이상에 자신 있게 답하지 못했다면, 이번 기회에 팀 인프라 로드맵에 이 주제를 한 줄이라도 올려보세요. 나중에 장애로 배우는 것보다 훨씬 싸게 먹혀요.
관련 글
AI 에이전트가 개발자에게 요구하는 역량이 프롬프트 작성을 넘어선다는 이야기는 이전에도 다룬 적이 있어요.
- 개인용 AI 에이전트 확산, 개발자에게 필요한 건 프롬프트 실력만이 아닙니다 — 에이전트 시대에 개발자에게 요구되는 역량 전반을 정리한 글입니다.
- 스트라이프의 오픈라우터 인수, 개발자 커리어에 남긴 신호 — AI 인프라 업계의 통합이 개발자 커리어에 주는 신호를 다룹니다.
- 사이드 프로젝트 API 선택, 채용 인터뷰에서 드러나는 이유 — 기술 선택 하나가 면접에서 어떻게 드러나는지 살펴본 글입니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요