Anthropic의 소스 제어 재설계: Claude가 Git의 한계를 넘어섰다
Anthropic은 Claude의 도움으로 모노레포의 일일 병합 건수가 2026년 5월 약 2,500건에서 9월 3만 건 이상으로 늘어난 뒤 Git을 대체했다. 이 급증은 Anthropic의 소스 제어 재설계를 단순한 인프라 마이그레이션 사례 이상으로 만든다. AI가 개발 시스템이 안전하게 수용할 수 있는 속도보다 더 빠르게 코드를 생성할 때 어떤 일이 벌어지는지를 보여준다.
이 회사는 온라인 에이전트, 서버 측 작업, 거대한 리포지토리에 대한 희소 접근을 중심으로 설계한 내부 소스 제어 시스템 Scion을 구축했다. 7명의 엔지니어는 새로운 코드 리뷰 시스템 Antique와 여러 관련 서비스도 만들었다. Anthropic은 팀이 5개월 만에 마이그레이션을 완료했다고 밝혔다.
중요한 대립 구도는 단순히 Scion 대 Git이 아니다. 인간의 주의를 전제로 설계된 개발 관행과 에이전트 규모의 코드 생산 간의 충돌이다. Google과 Meta는 이미 초대형 모노레포를 위한 특수 시스템을 구축했다. Anthropic은 오프라인 작업이 전혀 필요 없는 소프트웨어 에이전트 군집이라는 다른 압력원으로 인해 비슷한 목적지에 도달했다.
Anthropic의 소스 제어 재설계는 하루 3만 건의 병합에서 시작됐다
Anthropic이 Git을 포기한 이유는 엔지니어들이 Git을 싫어해서가 아니다. Claude가 리포지토리 트래픽의 형태와 규모를 바꿨기 때문이다.
Anthropic의 엔지니어링 설명에 따르면, 일일 병합 건수는 2026년 5월부터 9월 사이 10배 이상 증가했다. 회사는 이 증가를 일시적인 마이그레이션 급증이 아니라 지속적인 수요로 제시한다.
그 결과의 작업량은 커밋 생성에 훨씬 그치지 않았다. Anthropic의 메인 브랜치 이력은 100 GB에 육박했고, 압축된 작업 사본은 25 GB를 넘었다. 개발자 환경, 에이전트 샌드박스, 연구 작업을 제외하고도 지속적 통합, 즉 CI는 매일 약 2,500만 건의 코드 체크아웃을 수행했다.
Anthropic의 계산에 따르면 이러한 체크아웃을 단순하게 가져올 경우 매일 600페타바이트 이상의 Git 트래픽이 발생한다. 회사는 이 비용을 관리하기 위해 얕은 클론, 희소 체크아웃, 리포지토리 스냅샷, 수백 개의 내부 Git 미러를 사용했다.
이 조치들은 시간을 벌어줬지만, 리포지토리 변화 속도는 계속 빨라졌다. 스냅샷은 새로 고치는 사이에 오래된 상태가 됐다. 부분 클론은 마지막으로 한 줄을 수정한 사람을 식별하는 blame을 비롯해 이력 검색, diff 같은 작업도 복잡하게 만들었다.
회사의 문제는 Git의 강점과 Anthropic의 주된 클라이언트 간 불일치에서 비롯됐다. Git은 각 클론이 독립적인 리포지토리로 작동할 수 있을 만큼의 정보를 제공한다. 이 설계는 오프라인 개발, 로컬 이력, 분산 협업을 지원한다.
Anthropic의 에이전트와 자동화 작업은 이미 온라인 상태였다. 이들에게는 완전한 로컬 이력이나 독립 서버처럼 작동할 능력이 필요하지 않았다. 그러나 인프라는 모든 클라이언트가 노트북을 쓰는 인간 개발자인 것처럼 리포지토리 데이터를 반복적으로 배포하고 유지했다.
Scion은 이 가정을 뒤집는다. 서버가 이력 질의를 수행하고, 커밋을 생성하며, diff를 계산하고, 병합 또는 리베이스를 처리한다. 경량 클라이언트는 제한된 캐시를 유지하고 현재 작업에 필요한 파일만 구체화한다.
이 차이는 연구 작업이 전체 모노레포가 아니라 하나의 디렉터리만 필요로 할 때 중요하다. CI 서비스가 diff나 병합 기준점 계산만 필요로 할 때도 마찬가지다. Scion은 전통적인 작업 사본을 만들지 않고 API를 통해 이러한 요청에 응답할 수 있다.
Anthropic에 따르면 새 아키텍처는 상당한 내부 성과를 냈다. 각 캐시 계층은 보고된 바에 따르면 99퍼센트 이상의 적중률을 유지한다. 이 인프라는 기존 Git 미러 플릿보다 CPU와 메모리를 200배 적게 사용한다.
Anthropic은 또한 CI와 연구 체크아웃 시간이 몇 분에서 몇 초로 줄었다고 말한다. 이 변화로 더 폭넓은 컴퓨팅 플릿에 CI CPU 용량의 25퍼센트가 반환됐다.
이는 내부 시스템에 대해 회사가 보고한 측정치다. 외부 연구자는 Anthropic의 워크로드, 리포지토리, 인프라에 접근하지 않고서는 이를 재현할 수 없다. 그럼에도 이 수치는 왜 Git 튜닝을 한 번 더 하는 것만으로는 충분해 보이지 않았는지를 설명한다.
이 시스템은 단순히 큰 리포지토리 이상을 지원해야 했다. 주된 작성자, 독자, 자동화 소비자가 기계 속도로 작동하는 리포지토리를 지원해야 했다.
Claude는 소프트웨어 인프라를 병목으로 만들었다
Scion의 진정한 의미는 코드 생성이 더 이상 Anthropic의 희소 자원이 아니라는 점이다. 리뷰 역량, 인프라, 판단이 제약 조건이 됐다.
AI 코딩 보조 도구는 처음에는 익숙한 개발 프로세스 안에 들어맞았다. 사람이 함수를 요청하고, 출력을 검토하고, 테스트를 실행한 뒤 풀 리퀘스트를 제출했다. 보조 도구는 주변 시스템을 바꾸지 않고 개별 개발자의 타이핑 속도를 높였다.
Anthropic은 더 진전된 운영 모델을 설명한다. Claude는 연구 루프를 반복하고, 복잡한 프로그램을 최적화하며, 서비스를 만들고, 프로덕션 구성 요소를 모니터링하고, 대규모 마이그레이션을 지원하는 것으로 알려졌다. 각 활동은 새로운 변경을 만들거나 새로운 리포지토리 접근을 요구할 수 있다.
이 패턴은 곱셈식 압력을 만든다. 한 에이전트는 앞선 변경이 테스트를 통과하는 동안 다른 작업을 시작할 수 있다. 자동화 리뷰어는 수정을 요청할 수 있고, 이는 추가 변경을 만들어낸다. 이후 CI 시스템은 각 후보에 대해 체크아웃을 생성하고 더 많은 리포지토리 질의를 호출한다.
Simon Willison이 강조한 그래프는 2026년 중 급격한 증가를 보여준다. Willison은 이러한 가속을 Anthropic의 최신 내부 모델 세대와 연결하면서도, 내부 사용 가능 시점과 공개 출시일은 신중하게 구분했다.
Anthropic은 더 구체적인 연결을 제시한다. Scion 개발은 Claude Mythos Preview와 Claude Tag가 내부적으로 제공되기 시작한 시점 무렵에 시작됐다고 한다. 이 모델들은 Scion의 필요성을 키우는 동시에 팀의 구축 작업을 도운 것으로 알려졌다.
한 사례는 Git에서 Scion으로 데이터를 옮기는 파이프라인과 관련된다. Anthropic의 엔지니어들은 초기 프로토타입을 직접 작성했다. 이후 Claude Mythos Preview의 초기 내부 버전이 추가 지시를 거의 받지 않고 이 파이프라인을 다시 작성했다.
대체 구현은 보고된 바에 따르면 메모리를 20배 적게 사용하면서 4배 빠르게 실행됐다. Anthropic은 수집 순서와 데이터 구조에 관한 암묵적 요구사항을 보존했다고 말한다. 이 주장은 주목할 만하지만, 독립 벤치마크가 아닌 회사의 설명에 기반한 결과다.
더 넓은 피드백 루프는 더 쉽게 확인할 수 있다. 더 빠른 코드 생성은 리포지토리 활동을 증가시켰다. 이 활동은 새로운 인프라를 정당화했다. Claude는 다시 그 인프라 구축을 도왔고, 이는 코드 생성의 또 다른 한계를 제거했다.
이 루프는 개발 수명 주기의 모든 부분에 압력을 가한다. 인간 속도의 변경을 처리하던 빌드 서비스는 에이전트가 수천 개의 동시 작업을 만들면 비용이 많이 들 수 있다. 테스트 스위트가 실행되는 동안 리포지토리가 수백 건의 변경을 거치면 리뷰 대기열의 효용도 떨어진다.
지식 접근 역시 제약의 일부가 된다. 에이전트는 소스 파일뿐 아니라 사양, 아키텍처 결정, 인시던트 이력, 담당 맥락이 필요하다. 유사한 워크플로를 구축하는 팀에는 더 빠른 코드 인프라와 함께 검색 가능한 엔지니어링 지식 베이스가 필요하다.
Anthropic은 이제 개별 Scion 구성 요소를 위해 “superfans”라고 부르는 상시 Claude 모니터를 사용한다고 말한다. 이 에이전트들은 전용 Slack 채널을 통해 텔레메트리와 로그를 관찰한다. 기존 알림은 그대로 유지되며, 에이전트는 고정 임계값이 놓칠 수 있는 패턴을 찾는다.
이 운영 모델은 엔지니어링 업무를 더 상위 단계로 옮긴다. 사람은 불변 조건을 정의하고, 아키텍처 경계를 선택하며, 장애를 해석하고, 무엇을 프로덕션에 배포할지 결정한다. 에이전트는 이러한 경계 안에서 구현을 생성하고 텔레메트리를 조사한다.
이 변화가 엔지니어를 없애는 것은 아니다. 희소한 기술의 중심이 코드를 생산하는 일에서 어떤 코드가 존재할 가치가 있는지 결정하는 일로 바뀐다.
Scion은 Git의 오프라인 모델을 에이전트 규모 서비스로 대체한다
Scion은 Git의 결정적 대칭성, 즉 클라이언트가 더 이상 리포지토리의 모든 지능을 갖지 않는다는 점을 포기해 처리량을 얻는다.
Git 커밋에는 완전한 디렉터리 트리를 가리키는 포인터가 포함된다. 클라이언트는 packfile이라 불리는 압축 객체 모음을 교환해 로컬 리포지토리가 이력을 보존하고 독립적으로 작동할 수 있게 한다. 이 모델은 대부분의 소프트웨어 프로젝트에 여전히 적합하다.
Scion은 부모에 상대적인 변경 파일을 기록하는 쓰기 전 로그의 항목인 changeset을 사용한다. 파일 내용은 압축되고 콘텐츠 주소화되며 별도로 저장된다. 콘텐츠 주소화는 저장 키가 데이터에서 파생된다는 뜻이므로, 불변 객체를 안전하게 캐시할 수 있다.
Changeset은 서버에서 생성돼 시스템 전반에서 사용할 수 있게 된다. 클라이언트가 대형 packfile을 구성해 업로드할 필요가 없다. 또한 모든 커밋 작업에서 전역 브랜치 포인터를 이동시키는 일도 피한다.
Scion은 브랜치와 태그 같은 포인터를 의미하는 reference도 계속 지원한다. 그러나 Anthropic은 메인 라인과 릴리스 브랜치 외 대부분의 reference 사용을 권장하지 않는다. 커밋 속도가 높아질수록 전역 조정 상태는 점점 더 비용이 커진다.
이 시스템은 이력 정보를 파생 데이터로 별도로 계산한다. 파일 이력, blame, 복사, 커밋 그래프 내부 관계를 위한 전용 인덱스를 구축한다. 이 인덱스는 즉시 생성하거나 소비자가 요청할 때까지 미룰 수 있다.
이 분리를 통해 Anthropic은 모든 클라이언트를 변경하지 않고도 인덱스를 바꿀 수 있다. 또한 어떤 작업도 필요로 하지 않는 데이터의 계산을 피할 수 있다.
Scion의 체크아웃 프로토콜도 같은 원칙을 따른다. 클라이언트는 이미 보유한 대상의 전체 그림을 협상하는 대신 특정 트리와 파일 객체를 요청한다. 저장된 객체는 절대 변하지 않기 때문에 지역 캐시 서버가 대부분의 요청을 처리할 수 있다.
각 컴퓨팅 노드의 데몬은 로컬 작업 간에 캐시된 객체를 공유한다. 이후 지역 캐시 서비스가 이 데몬과 권위 있는 Scion 서버 사이에 위치한다. Anthropic은 지역 캐시 장애가 중앙 서비스를 압도하지 못하도록 이 계층 구조를 강제한다.
희소 체크아웃은 선택된 디렉터리만 요청한다. 가상화된 체크아웃은 프로세스가 파일을 읽을 때 파일을 생성한다. 일부 작업은 파일 시스템을 완전히 건너뛰고 API에 diff, 이력 결과, 병합 기준점을 요청한다.
이 설계는 모노레포 규모에 대응한 이전 방식과 닮았다. Google은 거대 중앙화 코드베이스를 지원하는 인프라의 일부로 Piper를 설명했다. 공개된 모노레포 분석은 공유 코드, 통합 의존성, 조직 전체 변경의 장점을 문서화했다.
Meta는 내부 리포지토리 규모에 맞춰 확장하면서도 익숙한 분산 소스 제어 개념을 유지하는 Sapling이라는 다른 경로를 택했다. Meta는 자사 서버가 수천만 개의 파일, 커밋, 브랜치를 처리할 수 있다고 말한다. 공개된 Sapling 설계는 Git 리포지토리와 로컬 개발자 워크플로도 지원한다.
Scion은 두 역사에서 모두 교훈을 얻었지만, 핵심 전제는 더 좁다. 지배적인 클라이언트는 항상 온라인 상태이고, 자동화된 경우가 많으며, 전체 리포지토리가 필요할 가능성은 낮다. 이 때문에 서버는 동기화 파트너가 아니라 소스 제어 데이터베이스이자 연산 서비스가 된다.
그 대가는 의존성이다. Scion 클라이언트는 의도적으로 더 적은 데이터를 보유하고 로컬에서 더 적은 작업을 수행하기 때문에 Git의 완전한 오프라인 동작을 재현할 수 없다. 따라서 네트워크나 중앙 서비스 장애의 영향도 달라진다.
마이그레이션 비용은 명령줄 클라이언트에만 국한되지 않는다. Anthropic은 코드 검색, ID 및 액세스 제어, CI 통합, Antique까지 구축해야 했다. 같은 설계를 채택하는 기업이라면 개발 플랫폼의 상당 부분을 교체해야 할 것이다.
이것이 Scion이 일반 팀을 위한 Anthropic식 Git 대안이 아닌 이유다. 이는 하나의 예외적인 워크로드를 위한 수직 통합 시스템이다.
더 빨라진 병합이 코드 리뷰를 더 어려운 문제로 만든다
해결되지 않은 질문은 Scion이 3만 건의 변경을 수용할 수 있는지가 아니다. Anthropic이 그 속도에서도 책임성을 유지할 수 있는지가 핵심이다.
Anthropic은 모든 Scion 변경이 여전히 사람의 검토를 받는다고 말한다. 이제 검토자는 모든 줄을 읽는 대신 변경의 의도에 집중한다. 이는 물량에 따른 선택이지만, 동시에 테스트, 에이전트의 설명, 자동화된 분석 쪽으로 신뢰를 옮기는 일이기도 하다.
의도 검토는 제안된 변경이 시스템의 목표와 아키텍처 규칙에 부합하는지를 묻는다. 줄 단위 검토는 구현이 올바르게 동작하는지를 묻는다. 강력한 자동화 검사는 두 수준을 연결할 수 있지만, 어떤 테스트 스위트도 모든 숨은 요구사항을 포착하지는 못한다.
Anthropic은 엔지니어들이 종종 Claude에게 “안 된다”고 말해야 했다고 인정한다. 에이전트는 때때로 국소적으로는 그럴듯하지만 시스템 전반의 제약을 위반하는 패턴을 선택했다. 일부 생성된 구성 요소는 권위 있는 병합 시간을 위해 Antique에 질의하는 대신 커밋 로그를 선형적으로 스캔하려 했다.
적대적 검토는 또 다른 실패 모드를 만들었다. Claude는 가상의 위험에 과도한 검증과 복잡성으로 대응할 수 있었다. 방어적 프로그래밍이 언제 시스템 개선을 멈추는지는 인간 엔지니어가 판단해야 했다.
이 사례들은 더 나은 모델이 곧바로 더 나은 소프트웨어를 만든다는 단순한 주장을 복잡하게 만든다. 에이전트는 가치 있는 최적화를 찾아내는 동시에 불필요한 메커니즘을 만들 수도 있다. 높은 산출량은 두 행동 모두를 증폭시킨다.
Anthropic은 팀이 Scion을 위해 시뮬레이션, 퍼징 테스트, 속도 제한을 구축했다고 말한다. 퍼징은 결함을 드러내기 위해 예상하지 못한 입력을 제공하고, 밀폐형 시뮬레이션은 격리된 환경에서 인프라 동작을 재현한다. 이러한 제어 장치는 병합 건수만으로 얻을 수 있는 것보다 더 강한 근거를 제공한다.
그럼에도 병합량은 품질 지표가 아니다. 변경은 작을 수도, 실험적일 수도, 생성된 것일 수도, 되돌려진 것일 수도, 고객 대면 진전과 무관할 수도 있다. 하루 3만 건의 변경은 이례적인 활동량을 보여주지만, 신뢰성이나 비즈니스 가치를 독립적으로 입증하지는 않는다.
공개 개발자 반응은 이 구분에 집중됐다. Hacker News discussion에서 일부 독자는 Anthropic이 모노레포를 재검토해야 하는지 의문을 제기했다. 다른 이들은 의도, 출처, 지속적인 검증이 전통적인 커밋 메커니즘보다 더 중요하다고 주장했다.
해당 스레드에 응답한 Anthropic 엔지니어는 모노레포의 일관된 도구 체계와 원자적 변경을 옹호했다. 같은 엔지니어는 Scion이 텍스트 충돌은 막지만, 동시에 일어나는 변경 간의 의미적 충돌까지 없앨 수는 없다고 설명했다.
의미적 충돌은 각각은 유효한 두 편집이 함께 적용되었을 때 잘못된 동작을 만드는 경우다. 한 변경이 함수를 수정하고 호출자를 업데이트하는 동안, 다른 변경이 동시에 새 호출자를 추가할 수 있다. 파일은 깔끔하게 병합되더라도 결합된 프로그램은 잘못될 수 있다.
전통적인 병합 큐는 다음 배치를 수용하기 전에 제안된 리포지토리 상태를 테스트해 이 위험을 낮춘다. Anthropic은 테스트 실행 중 수백 또는 수천 건의 변경이 반영되는 환경에서는 전역 리포지토리 잠금이 비현실적이라고 말한다.
회사는 투자 방향을 병합 후 및 배포 전 테스트로 옮겼다. 이 방식은 검사가 무엇을 안전하게 프로덕션에 도달시킬 수 있는지 판단하는 동안에도 리포지토리 처리량을 계속 유지하게 한다.
이것이 Anthropic의 소스 제어 재설계에서 핵심적인 절충점이다. Scion은 소스 제어에서 직렬화를 제거하지만, 어떤 형태의 직렬화는 여전히 배포, 데이터 마이그레이션 또는 사람의 의사결정 지점에 존재한다. 위험은 사라지기보다 이동한다.
Anthropic은 Claude가 사람들이 동시 충돌을 식별하는 것보다 더 빠르게 이를 해결할 수 있다고 말한다. 이 대응은 복구 속도를 다루지만, 감지되지 않은 상호작용의 비용을 다루지는 않는다. 안전성은 모니터링이 문제를 얼마나 빨리 감지하는지, 그리고 시스템이 이를 얼마나 효과적으로 격리하거나 되돌리는지에 달려 있다.
디렉터리 수준의 액세스 제어와 의미 기반 승인 규칙이 도움이 된다. Anthropic에 따르면 Antique는 주석만 변경한 사항과 민감한 로직 변경을 구분할 수 있다. 그러면 사람의 주의는 더 큰 결과를 초래할 변경에 집중될 수 있다.
남은 검증 공백은 상당하다. Anthropic은 독립적인 결함률, 롤백 빈도, 인시던트 추세, 또는 에이전트가 작성하고 검토한 변경의 비율을 공개하지 않았다. 이러한 지표 없이는 외부인이 처리량 향상과 후속 위험을 비교할 수 없다.
따라서 다른 팀에 가장 유용한 교훈은 Anthropic의 병합 건수를 좇지 않는 것이다. 대신 명세에서 배포까지의 전체 경로를 측정해야 한다. 유용한 지표에는 프로덕션으로 유출된 결함, 검토 지연 시간, 실패한 변경, 롤백, 중복 작업, 맥락을 복원하는 데 드는 시간이 포함된다.
개인 AI workflow는 에이전트가 더 많은 자료를 생성할수록 엔지니어가 의사결정과 출처를 보존하는 데 도움을 줄 수 있다. 그러나 저장된 맥락은 팀이 이를 강제 가능한 테스트, 책임 체계, 검토 정책과 연결할 때만 도움이 된다.
Anthropic의 소스 제어 실험이 다음에 바꿀 것
다음 단계는 에이전트 규모의 개발이 전이 가능한 엔지니어링 모델이 될지, 아니면 비용이 많이 드는 Anthropic만의 예외로 남을지를 시험하게 될 것이다.
첫 번째로 지켜볼 신호는 Anthropic이 예고한 Antique 관련 논의다. 소스 제어는 변경이 어떻게 저장되고 검색되는지를 설명하지만, 코드 리뷰는 극단적인 물량 속에서 의도, 책임, 승인이 어떻게 유지되는지를 결정한다.
Antique의 리뷰 모델에 관한 세부 사항이 명확한 출처 추적과 위험 기반의 인간 개입을 보여준다면 Anthropic의 주장은 더 강해질 것이다. 측정 가능한 검증 없이 대부분 모델 요약에 의존한다면 주장은 약해질 것이다.
두 번째 신호는 시간에 따른 소프트웨어 품질이다. Anthropic의 인프라 주장은 병합 처리량과 함께 롤백률, 유출된 결함, 서비스 인시던트 또는 기타 결과 지표를 공개한다면 더 설득력을 얻을 것이다.
안정적이거나 개선되는 신뢰성은 에이전트가 위험을 비례적으로 늘리지 않고 변경량을 높일 수 있다는 생각을 뒷받침할 것이다. 회귀나 긴급 복구가 증가한다면, Scion이 거버넌스보다 더 빠르게 프로덕션을 가속했다는 뜻일 수 있다.
세 번째 신호는 Git 플랫폼과 대규모 엔지니어링 조직의 대응 방식이다. 대부분의 기업은 Git을 대체하지 않겠지만, 서버 측 메타데이터 API, 가상화된 작업 공간, 위험 인지형 리뷰, 병렬 에이전트에 대한 더 나은 지원을 도입할 수 있다.
Meta의 Sapling은 익숙한 워크플로와의 호환성을 유지하는 한 가지 경로를 이미 보여준다. Microsoft의 Scalar 및 관련 Git 개선은 데이터 모델을 대체하는 대신 대규모 리포지토리를 위해 Git을 확장하는 또 다른 경로를 보여준다.
Anthropic 자체도 이러한 압력이 6개월에서 12개월 내에 확산될 것으로 예상한다. 이 전망은 측정된 시장 추세가 아니라 회사의 판단이다. 다른 조직들이 Anthropic의 내부 토큰 접근성과 이례적으로 집중된 Claude 사용 없이도 비슷한 한계에 도달하는지에 따라 그 관련성이 결정된다.
Scion은 경쟁사가 피하려 할 전략적 의존성도 도입한다. Anthropic은 모델, 리포지토리 서비스, 리뷰 인터페이스, 관측성 에이전트, 배포 워크플로를 통제한다. 이러한 통합은 반복 속도를 높이지만, 개발 환경을 재현하거나 대체하기 어렵게 만든다.
대부분의 조직에서 Git은 여전히 합리적인 기본 선택지로 남을 것이다. 폭넓은 상호운용성, 성숙한 도구, 이식 가능한 이력, 오프라인 복원력을 제공한다. Scion의 아키텍처는 리포지토리 트래픽이 이미 이러한 장점을 압도했을 때만 매력적이 된다.
더 즉각적인 변화는 관리 방식과 관련된다. 엔지니어링 리더는 생성된 코드의 양을 목표로 취급하는 일을 멈춰야 한다. 더 많은 산출물은 팀이 이를 안전하게 검토, 테스트, 배포, 관찰, 되돌릴 수 있을 때만 가치를 만든다.
개발자 역시 자신의 업무가 바뀔 것을 예상해야 한다. Anthropic의 설명은 시스템 설계, 아키텍처 제약, 평가, 거부에 더 큰 비중을 둔다. 엔지니어는 점점 더 에이전트가 빠르게 움직일 수 있는 경계를 정의하게 된다.
따라서 Anthropic의 소스 제어 재설계는 성능 이야기에 더해 경고도 제시한다. 코드가 저렴해지면 모든 부실한 명세, 누락된 테스트, 불명확한 책임 경계가 기계 속도로 재현될 수 있다.
유용한 질문은 당신의 팀에 Scion이 필요한지 여부가 아니다. 다음 분기에 에이전트가 열 배 더 많은 변경을 만들어 낸다면 기존의 리뷰, CI, 지식 시스템이 여전히 신뢰할 수 있는지 여부다. 지금 그 역량을 측정하고, 가장 먼저 실패할 통제를 찾아 더 많은 병합량이 오기 전에 강화해야 한다.
