요약
앤트로픽이 하루 병합 3만 건을 감당하려고 git을 버리고 자체 버전 관리 시스템 Scion을 만들었습니다.
앤트로픽 소스 관리 팀이 엔지니어링 블로그에 쓴 글입니다. Claude가 코드 대부분을 쓰면서 모노레포(회사 코드 전체를 담은 단일 저장소)의 하루 병합이 5월 약 2,500건에서 9월 3만 건 넘게 늘었고, 사람 규모로 설계된 git이 가장 큰 병목이 됐습니다.
왜 중요한가
- 코드를 쓰는 일보다 소스 관리, 빌드, CI 같은 개발 인프라가 새 병목이 됐다는 사례입니다.
- 오프라인 분산 작업을 전제로 한 git의 설계가 늘 온라인인 에이전트 환경과 맞지 않는다는 점을 짚었습니다.
- 일곱 명이 다섯 달 만에 이전을 마쳐, 큰 인프라 이전도 몇 년이 아니라 몇 달이면 된다고 봤습니다.
핵심 내용
- 서버가 이력, 블레임(줄마다 누가 고쳤는지 보는 기능), 커밋, 병합을 처리하고 클라이언트는 읽는 파일만 받아 옵니다.
- 기존 git 미러보다 CPU와 메모리 사용량이 약 200분의 1로 줄고, CI 체크아웃은 몇 분에서 몇 초로 빨라졌습니다.
- CI 체크아웃만 하루 2,500만 번이라, git으로 그대로 받으면 하루 600PB가 넘는 트래픽이 생길 상황이었습니다.
- Claude Mythos Preview가 git에서 Scion으로 옮기는 파이프라인을 다시 써서 메모리는 20분의 1, 속도는 4배가 됐습니다.
- 범용 git 대체재가 아니어서 공개하지 않고, 서버 쪽 처리 같은 아이디어를 GitHub, GitLab과 나누겠다고 했습니다.
HN 반응
- 하루 3만 건씩 바뀌는 저장소에서 이력이 쓸모 있느냐는 의문에, 에이전트도 git blame으로 변경 이유를 찾는다는 반론이 나왔습니다.
- 그 속도로는 결과물을 통제할 수 없다는 우려와 함께, 정작 계정 이메일 변경 같은 기본 기능은 안 된다고 꼬집는 댓글도 나왔습니다.
바보 같은 생각을 꺼내서 죄송한데요, 단위 시간당 코드 변경량이 이 속도로 계속 늘고, 끝없는 머지 수요 때문에 줄어들 기미도 없다면, 이 저장소는 끊임없이 변하는 상태가 되고 우리는 사람의 직접적인 감독도 없이 자동화된 코드를 계속 앞으로 밀어붙이게 될 텐데, 그러면 소스 컨트롤은 대체 왜 있어야 하죠? 소프트웨어를 그냥 흐르게 두고, 헤라클레이토스의 강처럼 같은 저장소에 두 번 발을 담그는 일이 없게 하면 안 되나요?
에이전트도 소스 컨트롤을 씁니다. 코드가 어떻게 바뀌어 왔는지 이해하는 것은 개발 과정에서 꽤 중요한 부분입니다.
극단적인 예로, 에이전트가 코드 변경의 순환에 빠질 수 있다고 상상해 보세요. 어떤 변경이 적절해 보여서 적용했는데, 알고 보니 외부 요인 때문에 적절하지 않아서 되돌립니다. 그러면 같은 변경이 다시 적절해 보이고, 이런 일이 반복됩니다.
물론 인프라를 조금 더 갖추면 이런 일을 막을 수 있겠지만, 그 지경이 되면 사실상 소스 컨트롤을 새로 만드는 셈입니다.
이론상으로는 에이전트가 git-bisect로 버그가 언제 들어왔는지 찾아낼 수 있어요. 다만 그러려면 운영하는 사람이 지금 모습의 버그를 고치는 것보다 근본 원인을 이해하는 데 더 관심이 있어야겠죠...
저는 Claude가 버그를 찾아내면 git blame을 보고, 커밋 메시지와 그 커밋의 다른 변경 사항을 읽어서 그 동작이 왜 그렇게 들어갔는지 맥락을 파악하는 걸 자주 봐요. git bisect를 꺼내 들어도 놀랍지 않을 것 같고요.
그러고 보니 제 기본 지시문이 "{버그 설명}. 근본 원인을 찾고 가능한 해결책을 제안해 줘" 같은 식이니, 말씀하신 사람에 제가 딱 들어맞네요.
저도 그래요. 버그를 고치기 전에 주요 차원마다 버그를 미분해 보는 게 기본이거든요.
코드베이스가 큰 경우에는 현실적인 선택지가 아닙니다. bisect 한 단계가 컴파일에 몇 시간씩 걸릴 수 있으니까요. 예를 들어 12단계짜리 단순한 bisect에서 전체 리빌드로 6/8번째까지만 가도 이미 하루 일과를 통째로 쓴 겁니다.
원인을 이해하지 않고도 후자가 가능하기는 한가요?
"고칠" 수는 있죠(지금 쓰는 재현 방법으로는 더 이상 재현되지 않게 만드는 거요).
그런 경우를 늘 봐요. 보통은 증상만 고치는 거죠. 안 되기 전까지는 어떻게든 돌아가다가, 안 되기 시작하면 처참하게 무너져요.
그러니까 가능하긴 하고, 가끔은 먹히기도 해요...
소스 컨트롤을 없애자는 건 아니지만, 이런 순환은 아키텍처 결정 기록(Architectural Decision Record, ADR)으로 피할 수 있습니다. 정말 귀찮다면 에이전트가 ADR을 관리하게 하세요. 보통 "막다른 길에 몰린" 상황이 생기면 에이전트가 알려 주니, 그때 어떻게 돌파할지 같이 따져 보면 됩니다.
(번역: 흠, 파일을 또 망가뜨렸네요. 이상하군요. 압축된 컨텍스트를 바탕으로, 원래 뭘 하던 파일이었는지 어렴풋한 기억에 의지해서 다시 만들어 볼게요.)
토큰을 파는 게 사업이고 고객이 잘 모른다면 그게 맞는 접근이죠.
맞아요. 그런데 같은 코드베이스에서 일하는 적대적인 에이전트들이 ADR 목록을 악의적인 메시지 교환 수단으로 쓰는 건 어떻게 막죠?
적대적인 에이전트를 코드에 손대게 두지 마세요?? 어차피 엄청나게 정교하게 난독화한 'rm -rf windows32'를 심어 넣을 수 있는데, ADR을 적대적인 에이전트로부터 지킨다고 뭐가 해결되나요.
(에이전트도 소스 컨트롤을 씁니다.)
맞는 말이지만, 하루 3만 건 머지면 한 달에 거의 100만 건이고, 완전히 자율적인 에이전트의 머지는 잡음이 많기 마련입니다. 에이전트에게조차 이게 여전히 다룰 수 있는 문제일까요? 릴리스 스냅숏 정도를 빼면, 며칠 지난 리비전이 이런 프로세스에서 의미가 있기는 할까요?
오래 못 갈 거예요. 저는 터지기를 기다리는 재난으로 봐요. 그 속도로 만들어지는 결과물을 그들이 통제할 방법은 절대로 없어요.
(그 속도로 만들어지는 결과물을 그들이 통제할 방법은 절대로 없어요.)
저는 그 정도 변경량이 전진이 아니라 코드 변동(churn)이라고 봅니다.
그리고 이건 스파게티 코드를 다루고 있다는 확실한 신호이기도 합니다.
모든 머지가 똑같지는 않습니다. 모노레포라 해도 새 기능을 구현하거나 버그의 근본 원인을 찾으려고 코드베이스 전체를 볼 일은 아마 드물 겁니다. 특정 폴더의 이력만 놓고 보면 훨씬 다루기 쉬워집니다.
물론 어느 정도 폴더 구조가 있어야 하고 에이전트가 그런 일에 특별히 뛰어나지는 않지만, 그래도 충분히 쓸 만해서 시간 단위, 심지어 하루 단위로도 영향을 받지 않는 폴더가 많이 남게 됩니다.
이 규모에서는, 특히 코드의 핫스팟에 대해서는 동의하기 어렵습니다. 다만 저도 추측하고 있는 것은 인정합니다.
Git 분산 버전 관리의 많은 부분은 좋은 결정의 결과물입니다. 앤트로픽 소스 컨트롤 팀은 자신들에게 필요한 트레이드오프가 다른 기업들과 크게 다르다고 생각할 뿐입니다. 글에서 이런 이야기도 했습니다.
내부적으로 토큰 사용량 상한이 없습니다.
위 1번 때문에, 에이전트 군집의 규모가 가장 크거나 최소한 가장 큰 축에 듭니다.
git 저장소가 엄청나게 큽니다(main의 git 이력이 압축 전 100GB, 압축 후 25GB).
하루 머지 횟수가 5월부터 9월까지 한 자릿수 배(10배)로 늘어 하루 3만 건이 됐고, 둔화될 조짐이 없으며 앞으로 더 빨라질 가능성이 큽니다.
모든 코드 에이전트가 네트워크에 연결되어 있고 네트워크에 접근할 수 있어서, 전체를 로컬로 내려받을 필요가 전혀 없고 너무 느립니다(위 3번 참고).
Scion의 설계는 구글의 Piper와 메타의 Sapling이라는 선행 사례에 기반합니다.
그들만의 제약과 특성을 감안하면, 선행 사례를 바탕으로 자체 솔루션을 만드는 게 합리적입니다. 다만 처음부터 완전히 다시 설계한 것은 아니고, 필요한 것만 내려받는 완전 온라인 방식의 소스 컨트롤 시스템입니다. 문제는 버전 관리 소프트웨어 자체가 아니라, 그 소프트웨어의 기존 트레이드오프가 이들의 확장 요구와 맞지 않는다는 점입니다.
추신. 눈치채신 분이 있을지 모르겠지만, 앤트로픽이 직원의 전체 이름을 숨기기 시작해서 이름만 쓰고 성은 이니셜로만 표기합니다. 이유는 모르겠습니다.
추추신. Scion이라는 프로젝트 이름은 너무 별로고, scn은 최악입니다. 그 자체로도 별로였던 옛 SVN이 떠오릅니다.
제가 둔한 걸 수도 있는데, 그 얘기 중에 "소스 컨트롤이 대체 왜 필요하냐"는 질문에 답이 되는 게 뭔지 모르겠어요.
제 생각엔 답은 사실 소스 컨트롤이 필요 없다는 거예요. 에이전트가 편집 충돌을 해결할 수단만 있으면 되는 거죠. 말하자면 또 하나의 게시판일 뿐이에요.
(main의 git 이력이 압축 전 100GB, 압축 후 25GB)
제가 맥락을 완전히 놓치고 있는 걸 수도 있지만, 왜 압축률이 겨우 4배일까요? 바이너리를 많이 커밋하나요? 코드가 왜 이렇게 압축이 안 되는지 이해가 안 됩니다.
전체 이름을 쓰지 않는 것은 인재 빼가기를 막기 위한 대응입니다.
그 흐름의 다음 단계로 이름을 아예 넣지 않는 조직들도 있습니다.
애플은 예전부터 그랬어요.
제게는 이게 제가 진화적 아키텍처(Evolutionary Architecture)라고 부르는 것으로 이어질 수 있다는 이론이 있습니다(굳게 믿는 건 아니고, 믿음이 아니라 그냥 아이디어입니다). 코드의 취약점이 발견되기를 기다리는 대신, 시스템이 에이전트에 의해 너무 빠르게 코드가 바뀌고 다시 구현되어서 공격자가 취약점을 탐색할 수 없게 되는 겁니다. 탐색한 결과가 돌아올 즈음이면 프로덕션의 그 코드는 다른 언어 등으로 옮겨져 이미 존재하지 않으니까요. 취약점을 막는 것이 변경의 이유는 아니지만, 변경이 방어적인 부수 효과를 낳는 셈입니다.
이 모든 생각은 사이버펑크 2077의 밀리텍 신경 매트릭스에서 약간 영감을 받았을 수도 있습니다.
저는 대규모 아키텍처 기능의 코드 리뷰를 두고 이 생각의 약한 버전을 발전시켜 오고 있습니다.
아키텍처를 제대로 깊이 고민하는 가장 큰 동기는, 소프트웨어가 지금은 잘 돌아가더라도 좋은 아키텍처라면 1년 뒤에 기능을 추가하기 쉽고, 나쁜 아키텍처라면 상당한 재작성이 필요하다는 점입니다.
하지만 요즘은 대규모 재작성이 싸졌기 때문에, 저는 코드 리뷰에서 지금 동작하는지를 훨씬 더 중요하게 보고, 다른 변경을 할 때 이걸 바꿔야 할지는 훨씬 덜 중요하게 봅니다.
"이게 이 컴포넌트에 있어야 하나, 따로 분리해야 하나" 같은 부류의 문제는 이제 아예 중요하지 않습니다. 의존하는 게 잔뜩 생긴 뒤에 바꾸는 일이 아무리 지루하더라도, 그런 건 AI가 문제없이 해내는 일이니까요.
"난독화에 의한 보안(Security by Obscurity)"이 "속도에 의한 보안(Security by Velocity)"으로 바뀌는 건가요?
하루에 코드 변경이 3만 건인데, 아직도 제 계정의 이메일 주소는 못 바꾼다고요?
그러니까요. pi는 램이 20MB 정도면 되는데 Claude Code는 최소 수백 MB, 심하면 기가바이트 단위가 필요해요. 어떻게 이럴 수가 있죠? 하는 일이 몇 배는 더 낫다고들 하는데 정작 핵심 제품(API, 결제, 계정, CLI 코딩)은 제대로 작동시키지 못한다고요? 사람들이 터무니없는 돈을 내고 쓰는 바로 그 제품인데요???
ㅋㅋ 저도 ChatGPT를 보면 똑같은 생각이 들어요. 코드를 얼마나 써 대는지 모르겠지만, 메인 채팅 화면은 로딩 중에 세 번쯤 위치가 바뀌어서 계속 엉뚱한 버튼을 누르게 되잖아요. 거기서 일하는 사람 중에 이게 열받지 않는 사람이 어떻게 있죠? 저는 이제 쿼리를 더 많이 보낼 땐 claude 모바일 사이트로 갈아탔어요.