요약
앤트로픽이 하루 병합 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으로 변경 이유를 찾는다는 반론이 나왔습니다.
- 그 속도로는 결과물을 통제할 수 없다는 우려와 함께, 정작 계정 이메일 변경 같은 기본 기능은 안 된다고 꼬집는 댓글도 나왔습니다.
Claude가 짠 코드를 리뷰하지 않고 넘어갈 때마다, 나중에 꼭 엉성한 쓰레기가 나와요. 리뷰할 때마다 나오는 건 아니지만 모든 걸 리뷰하지 않을 수 없을 만큼은 자주 나오죠.
이 정도 속도 얘기가 저한테 와닿지 않는 이유가 이거예요. 그 사람들은 대체 어떻게 엉성한 쓰레기를 피하고 있는 걸까요? 아니면 그냥 감수하면서 너무 심해지지 않기를, 아니면 빨리 발견되기를 바라고 있는 걸까요?
Anthropic 내부 사정은 전혀 모르지만 아마 후자일 것 같고, 그래서 더 우울해요.
그냥 감수하는 거예요. 제품 품질에도 그대로 드러나고요. 예를 들어 Claude Code에는 기능을 엄청 많이 내놓지만, 바이브 코딩으로 만든 엉망진창이라는 게 뻔히 보여요.
+1입니다. 가장 강력한 모델조차 (제 짐작으로는) 시간이 지나 쌓이면 문제를 일으킬 만한 결과물을 여전히 만들어 냅니다.
제 의심이 틀린 걸까요? 모델이 충분히 빠르게 좋아져서, AI 기술 부채의 산더미[1] 속에서도 새 기능을 추가하고(또는 버그를 고치고) 정리까지 해낼 수 있게 될까요?
[1]: 굳이 AI 기술 부채라고 부르는 이유는 사람이 만든 기술 부채와는 다른 특징이 있기 때문입니다. 예를 들어 의도가 있었는지조차 알 수 없어서 체스터턴의 울타리(Chesterton's fence) 식 검토가 훨씬 어렵습니다. 어쩌면 AI가 각 코드 덩어리를 왜 그렇게 썼는지 최대한 짧게라도 어딘가에 적어 두게 하면 될지도 모르겠습니다...
어떻게 엉성한 쓰레기를 피하냐고요? 지금까지 있었던 몇 차례 소스 코드 유출을 보면, 못 피하고 있어요.
Anthropic은 무엇보다 먼저 여러분에게 뭔가를 팔려는 회사라는 걸 잊지 마세요.
이 문장이 계속 머리에 남습니다. Scion을 만드는 엔지니어들은 이 말을 어떻게 받아들일지 궁금합니다. 정말 그게 미래라면 저는 다른 직업을 찾아야 할 것 같습니다. 은퇴하기에는 아직 너무 멀었으니까요.
Anthropic의 엔지니어링 작업을 깎아내리려는 건 아니지만, AI 덕분에 코드 작성이 훨씬 싸지면 작은 스타트업에서도 바퀴를 다시 발명하는 일이 크게 늘 것 같습니다.
직접 만들지, 기존 솔루션을 가져다 쓸지를 따지는 저울이 바뀌고 있습니다. 다만 그렇게 만든 자체 소프트웨어를 유지보수하는 비용도 똑같이 쌀지는 별개의 문제입니다.
LLM으로 늘어난 생산성이 다 어디로 가느냐고 다들 궁금해하는데, 이것도 그 답의 일부라고 봅니다.
다들 LLM으로 코드를 훨씬 더 많이 만들어 낸다는 건 의심할 여지가 없습니다. 그런데 그 생산성의 상당 부분이 이런 데 들어가고 있습니다. Grafana의 한계가 늘 거슬렸다고요? 나한테 딱 맞는 대시보드 솔루션을 새로 만들어 내면 됩니다. 느리고 짜증 나는 그 배포팀이 있죠? 이제 내 배포 엔진을 직접 만들면 됩니다. kubectl이 한 번에 k8s 클러스터 하나씩만 관리하게 해서 싫었다고요? 이제 AI한테 fleetctl을 만들어 달라고 하면 됩니다. DynamoDB로 프로젝트를 시작했다가 MySQL로, 다시 Postgres로, 다시 DuckDB로 갈아엎을 수도 있습니다. Python으로 시작했다가 Golang으로 갈아타고, 다시 Rust로 넘어가도 됩니다. AWS에 배포했다가 Azure로 옮기고, 하이브리드로 바꾸고, 거기에 코로케이션까지 섞을 수도 있고요. 소스 컨트롤이 마음에 안 든다고요? 새로 만드세요. JSON이 너무 제한적이라고요? JSON과 HCL을 섞은 언어를 발명하세요. 브라우저 샌드박스가 답답하다고요? 데스크톱 앱을 만들고, 언어를 만들고, OS를 만들고, 커널을 만드세요.
저는 저 목록에 있는 것 중 몇 가지를 최근 3주 사이에 해 봤어요. 정말 놀라워요. 뭔가 만드는 게 이렇게 신난 적이 없었어요.
제가 LLM 과대광고를 싫어하는 핵심 이유가 바로 이겁니다. 다들 이미 있는 걸 다시 만들고 있고, 이유를 물어보면 사실 아주 주관적인 이유입니다. 각자 자기 시간으로 하고 싶은 걸 하는 거야 괜찮습니다. 문제는 남들더러 자기 뒤를 따라오라고 한다는 점입니다.
참신한 아이디어가 있어야만 가치 있다는 말은 아닙니다. 다만 그렇게 아무렇게나 만든 프로젝트들은 대충 해 본 테스트 말고는 보증해 주는 게 아무것도 없습니다. 모든 소프트웨어에 버그가 있다는 건 압니다. 그렇다고 마구잡이로 만들어진 물건을 제가 써 볼 수는 없습니다.
지금 엄청난 낭비와 소음이 있는 건 분명해요. 그런데 소수의 사람에게만 쓸모 있는 데스크톱 앱의 코드가 어떻게 생겼는지가 정말로 중요할까요? 어떤 구현이든 아무리 올바르고 완벽해도 최소 한 명은 쓰레기라고 생각하기 마련이에요. 이제는 거기서 벗어나야 해요. 정말 못 참겠다면 직접 만들거나, 그걸 붙들어 줄 결정론적인 레일을 만들면 되죠.
게다가 자기가 뭘 하는지 아는 사람들이 예전에는 못 하던 걸 만들어 내고 있기도 해요.
이 상황은 결국 순이익이고, 예전과 그렇게 크게 다르지도 않아요. 그 소음 속에서 길을 찾는 건 각자의 몫이에요.
뭐가 문제인지 모르겠네요.
저는 바퀴를 다시 발명하는 사람 중 하나예요. 기존 물건이 제 사용 사례에 안 맞으니까요.
이제는 어떤 소프트웨어든 포크해서, 늘 하고 싶었지만 시간이 없던 수정을 할 수 있다는 게 저한테는 정말 놀라워요.
그걸 팔거나 공유할 생각은 없어요. 사실상 아무 가치도 없는 물건이니까요.
말씀하시는 그 언어도 다시 발명할 수 있다는 건 아시죠? 그런데 공용어의 가치는 다른 사람들과 소통하는 데 쓸 수 있다는 데 있어요. 소프트웨어도 마찬가지로, 공통된 이해가 만들어 내는 시너지가 가치예요.
그건 괜찮습니다. 하지만 기존 제품의 무엇이 정확히 안 맞았는지 제대로 설명하는 사람은 아직 못 봤습니다. 늘 “90%를 다시 짜거나 새로 만들고, 거기에 아주 사소한 변형을 얹자”는 식입니다. 그 변형은 흥미로울 수 있지만, 다시 발명한 부분 때문에 손댈 수 없는 물건이 됩니다. 작성자를 포함해 아무도 그게 제대로인지 확인할 시간이 없으니까요.
패치나 플러그인은 괜찮습니다. 하지만 미심쩍은 주장을 내건 통째로 새 프로젝트는 아닙니다.
전제죠. 저는 추론 엔진을 여러 개 다시 만들어서 윈도에서 돌리고, 공간을 아끼려고 의존성 venv를 최신 버전으로 통일하고, 16GB 카드에 들어가도록 모델 블록을 풀어 놓기도 했어요. 전에는 막혀 있던 일이 많이 가능해졌어요. 이제 다른 사람이 정해 놓은 불변 조건에 발목 잡히지 않고, 일을 끝내려고 시간을 쏟을 필요도 없으니까요. 게임을 덜 노가다스러운 루프로 바꾸고, 기능을 추가하고, 배우기 쉽게 만들기도 했어요. 드라이버를 고치고, 버전에 패치를 넣고, DLSS5를 지원하지 않는 게임에도 붙여 봤고요.
획기적인 건 아니지만 해방감이 있어요.
음, 저는 저를 움직이게 하는 “안 맞는 점”을 꽤 구체적으로 자세히 말할 수 있어요. 제 프롬프트 대부분이 그중 적어도 하나를 적극적으로 고민해야 하는 내용이거든요.
왜 신경 쓰세요? 누가 억지로 당신 컴퓨터에 밀어 넣는 것도 아닌데요.
제가 보기에 요점은 이래요. 과대광고는 AI가 엄청난 돈의 가치가 있다고 말하는데(Anthropic, OpenAI 같은 곳의 기업가치를 보세요), 정작 이득의 상당 부분은 경제적으로 하찮은 쪽, 그러니까 개발자 한 명의 삶을 조금 더 편하게 해 주는 정도라는 거죠.
“주식 시장에서 누군가가 틀렸다.” 이거 관련된 xkcd 있지 않나요?
맞는 말이에요. 다들 말씀하신 것처럼 자기 컴퓨터에서만 그런다면 문제될 게 없겠죠.
그런데 사람들이 직장의 다른 팀, 오픈소스의 다른 사람들, 업무 현장의 다른 사람들에게 그러기 시작하면 여러 이유로 문제가 돼요. 제가 7만 5천 줄짜리 Python 코드를 선물이랍시고 건네면서 “그냥 돌려 보세요”, “당신 에이전트한테 손보라고 하세요”라고 하는 정도는 괜찮을 수도 있죠(말씀하신 대로 누가 신경 쓰겠어요). 그런데 그런 프로젝트가 한 달에 47개씩 쏟아진다고 생각해 보세요.
그 사람들은 모든 오픈소스 프로젝트에 파고들려고 하고, 그래서 메인테이너들의 부담이 늘고 있습니다. 그러다 금지가 발표되면 또 몰려와서 항의하고요.
직접 만든 맞춤 솔루션은 사실 네모난 바퀴를 다시 발명하는 경우가 많아요. 직장을 옮겼는데 LLM이 만든 소프트웨어 판 이런 걸 마주하게 될까 봐 벌써 겁나요. 테리 프래쳇의 『Small Gods』에 나오는 “평범한 광기라면 그도 감당할 수 있었다... 하지만 보르비스는 그 붉은 장벽을 곧장 통과해 저편에 일종의 논리 구조를 세워 놓았다. 미친 부품으로 만든 합리적인 생각이었다.” 같은 걸요.
문제는 이걸 할 수 있느냐 없느냐였던 적이 없습니다. 늘 이걸 하는 게 현명한가였죠. 자체 에디터, 컴파일러, 데이터베이스 엔진, 운영체제, 소스 코드 관리 시스템, 티켓 시스템, CMS, ERP를 직접 만들다가 망한 회사가 한둘이 아닙니다.
이 부분을 이렇게 아주 객관적으로 인식하고 있다는 점이 마음에 듭니다.
저는 가끔 Claude Code 릴리스 노트를 훑어보면서, 시간이 지나면서 그 제품의 변경 사항이 얼마나 되는지 감을 잡아 보곤 합니다. 정량화하려면 글머리 기호를 세는 것 말고는 방법이 없긴 한데, 시간에 따른 그 개수가 이 글의 차트들과 어떻게 비교되는지 보면 흥미롭습니다.
https://imgur.com/a/M30pFLc
저는 교차 비교를 해서 항목 중 Fixed나 Added로 표시된 게 몇 개인지 보는 걸 좋아해요.
https://i.imgur.com/NEhgPTa.png
멋지네요!
이 시각화들 전부에서 한 가지는 일관돼 보여요. 바늘을 움직였다는 거죠. 그 바늘이 무엇을 가리키는지, 레드라인이 어디인지는 말하기 어렵지만, 함대 전체의 변화가 진행 중인 건 분명해요.
그 그래프를 버그 수정과 변경으로 나눠 보면 흥미로울 것 같습니다. 그리고 의미 있는 변경과 사소한 변경으로도 나눠 보면 좋겠고요.
버전 관리에서 극단적으로 높은 변경 빈도(churn rate)를 지원하면 뭐가 좋은 건가요? 그 코드는 대체 무슨 일을 하는 거죠? 어떤 문제를 풀고 있나요? 요구사항 변화가 원동력이라면, 요구사항 변화는 왜 빨라지고 있는 걸까요?
목표가 실제 문제를 푸는 소프트웨어를 만드는 것이라면, 코드에 대한 수요가 어떻게 무한히 늘어날 수 있죠?
무식하게 밀어붙이는 방식(brute force)으로 해법을 찾는 거죠. 그래서 토큰을 극단적으로 쓰고, 결과물을 검증하려고 하루에 CI/CD 작업을 수억 개씩 돌릴 필요가 생기는 거고요.
저도 이 부분이 가장 의아해요.
코드베이스를 계속 갈아엎다 못해 그 변경을 감당할 시스템까지 발명해야 한다면, 앞서 6번이나 한 리팩터링이 좋지 않았고 이번에야 비로소 제대로 했다고 최소한 인정하는 셈이잖아요.
제 생각에 좋고 잘 설계된 코드는 다시 쓰기가 아니라 덧붙이는 식으로 변해요. 오랫동안 안정적으로 유지되는 코드가, 계속 다시 써야 하는 코드보다 아마 더 나았을 거예요(적어도 사람이 쓴 경우에는요).
그런데 이건 좋은 코드가 뭔지에 대한 지나치게 사람 중심적인 시각일지도 모르겠네요. LLM의 “될 때까지 슬롭을 만든다” 식 개발에서는 품질이 어떤 모습인지 기준이 다를 수도 있잖아요?