저자丨정자메이
편집丨츠 펑
Git은 20년 넘게 소프트웨어 개발을 지탱해 왔지만, Anthropic은 이를 교체하기로 결정했다. Claude가 계속 생성하는 코드가 개발 흐름에 원활히 들어가도록 하기 위해, 7명의 엔지니어가 5개월에 걸쳐 버전 관리 시스템 Scion을 개발하고 핵심 코드 저장소를 그곳으로 마이그레이션했다. 올해 5월, Anthropic은 하루 평균 약 2500건의 코드 변경을 병합했고, 9월에는 3만 건을 넘어섰으며, CI 시스템만으로도 하루 약 2500만 회의 코드 체크아웃을 실행한다. 코드 작성 속도는 올라갔지만, 저장소 준비, 객체 동기화, 히스토리 조회는 점점 더 많은 머신 자원을 소모한다. 거의 같은 시기, GitHub는 시크릿 스캔의 범용 LLM 판단을 미세조정된 ModernBERT로 교체했다. 컬럼비아 대학교와 Google DeepMind 등 기관은 BTTF를 통해 칩 시뮬레이션 웨이브폼을 SQLite로 변환하여 Agent가 SQL로 이상을 조사하도록 했다. Scion은 기본적으로 온라인이고, BTTF는 웨이브폼을 쿼리 인터페이스로 바꾸며, GitHub는 고빈도 판단을 분류기에 맡긴다. 인간의 개발 리듬을 중심으로 설계된 시스템이 Agent가 가져오는 또 다른 부하를 견디기 시작한 것이다.
01
Git의 오프라인 기능, 왜 부담이 되었나
Git의 분산 설계 덕분에 엔지니어는 저장소를 클론한 후 오프라인 상태에서도 커밋, 병합, 히스토리 조회가 가능하다. 하지만 Anthropic의 대량 코드 읽기 작업은 항상 온라인인 CI 잡과 Agent 샌드박스로, 몇 분 실행 후 소멸하며 몇 개 파일,一份 diff, 또는 두 커밋의 조상 관계 확인만 필요할 수 있다. 이런 작업을 위해 로컬 저장소를 준비하는 반복 비용은 점점 커진다. Anthropic의 main 브랜치 히스토리는 약 100 GB, 압축된 작업 복사본은 25 GB를 넘는다. 하루 2500만 회의 체크아웃이 각각 전체 복사본을 가져온다면 이론상 트래픽은 600 PB를 초과한다. 회사는 얕은 클론, 스파스 체크아웃, 스냅샷, 수백 대의 Git 미러를 사용하지만, 미러는 여전히 동기화가 필요하고 스냅샷은 만료되며, 히스토리 조회에는 객체 보완도 필요하다. 저장소가 활발할수록 유지 비용이 커진다. Scion은 클라이언트를 가벼운 진입점으로 축소했다. 커밋 생성, 병합, 리베이스, 히스토리 조회는 중앙 서비스로 옮기고, 로컬은 파일 변화 감지와 소량 캐시 유지만 하며, 작업 디렉터리가 필요할 때 온디맨드로 펼친다. CI가 diff 계산만 원한다면 API를 직접 호출할 수 있어 전체 체크아웃이 필요 없다. 이는 오프라인 자율성을 희생하지만 반복 초기화를 줄인다. 커밋 형식도 바뀌었다. Git commit은 저장소 상태를 기술하는 디렉터리 트리를 가리키지만, Scion의 changeset은 첫 번째 부모 커밋 대상으로 수정된 파일을 월(write-ahead) 로그 항목으로 기록하고, 콘텐츠 주소 지정 포인터로 데이터를 참조한다. changeset 생성에는 Git packfile 생성이 필요 없고, 공유 브랜치를 즉시 이동할 필요도 없으며, main 등 참조가 갱신될 때만 시스템이 Spanner의 단일 행 레코드에 compare-and-swap을 실행한다. Agent는 변경을 동시에 생성할 수 있고, 경쟁은 브랜치 참조 이동 시점에 집중된다. 하지만 히스토리 조회에는 여전히 난제가 있다: 증분 레코드로는 어떤 줄을 누가 수정했는지, 파일이 무엇을 겪었는지 직접 답할 수 없다. Scion은 blame, 경로 히스토리, 커밋 그래프 스킵 리스트를 위해 derived data를 유지하고, 부모 커밋 관계에 따라 사전 계산하거나, 쿼리가 발생한 후에 생성한다. 쓰기와 히스토리 분석은 독립적으로 확장할 수 있다. 雷峰网(공중호：雷峰网) 체크아웃 시 scn 클라이언트는 대상 디렉터리 트리부터 시작해 누락된 tree와 blob만 요청한다. 요청은 노드상의 scion-daemon, 리전 scion-cache를 차례로 거쳐 scion-server가 Spanner 또는 객체 저장소로 원본 조회한다. 객체는 쓰인 후 불변이므로 캐시가 작업 간 재사용될 수 있어, 협상, 압축 및 반복 전송을 줄인다. Anthropic은 캐시 히트율이 99%를 넘는다고 하며, 장애 시 원본 조회 트래픽을 제한한다. 마이그레이션 후, Scion은 기존 Git 미러 체계 대비 CPU와 메모리 요구가 약 200배 축소되었고, 체크아웃은 분 단위에서 초 단위로 단축되었으며, CI는 약 25%의 CPU 용량을 확보했다. 200배는 인프라 자원 점유 기준이며, Git 작업 전체의 속도 향상을 의미하지 않는다. Anthropic은 또한 Antique 코드 리뷰, 소스 검색, IAM, 일괄 병합 도구를 동시에 구축해 새 프로토콜에 맞췄다. 온라인 서비스의 유지 보수도 새로운 비용이 되었다.02
데이터베이스가 웨이브폼을 읽게 해야 Agent가 장애를 추적할 수 있다
칩 검증은 또 다른 장애물에 직면한다. RTL 시뮬레이션이 생성하는 VCD, FSDB 웨이브폼은 시간에 따른 대량의 신호 상태 변화를 기록하며, 복잡한 설계의 덤프는 수십 GB, 심지어 TB급에 이를 수 있다. 雷峰网 엔지니어는 웨이브폼 뷰어에서 시간축을 따라 이상을 찾을 수 있지만, Agent가 원본 웨이브폼을 텍스트로 변환하면 컨텍스트는 금방 타임스탬프, 신호 이름, 반복 점프로 가득 찬다. 다른 신호를 추적하려면 파일을 반복해서 읽어야 할 수도 있다. 또한 인간은 눈으로 차트에서 “바늘 찾기”를 하는 데 익숙하지만, Agent는 아무리 큰 컨텍스트라도 수십 GB의 물리 파일을 담을 수 없다. 따라서 이런 “죽은 파일”을 SQL로 정밀하게 호출할 수 있는 “살아있는 인터페이스”로 바꾸는 것이 AI에 데이터를 공급하는 최적의 해법이다. BTTF는 데이터 접근을 SQLite에 맡긴다. signal_metadata는 신호 이름, 유형, 계층 등 정적 정보를 저장하고, signal_changes는 신호 ID, 타임스탬프, 변화 후 값을 기록하며, 두 테이블은 ID로 연관된다. 특정 신호의 지정 시점 상태를 조회할 때 SQL은 그 시점 이전의 가장 가까운 변화 레코드를 찾고, 일정 기간의 토글을 검사하려면 시간 창으로 필터링과 집계를 한다. 두 점프 사이에는 상태가 변하지 않으므로, 새 레코드가 없다는 것을 미지(未知)로 오인해서는 안 된다. 모델은 문제와 소량의 반환 이벤트만 처리하면 된다. 예를 들어 어떤 핸드셰이크 프로토콜이 타임아웃되면, Agent는 먼저 요청과 응답 신호의 변화를 검색한 뒤 이상 구간으로 좁혀 시간 관계를 검사할 수 있다. 데이터베이스가 검색을 담당하고, 모델이 다음에 무엇을 조회할지 결정한다. 쿼리는 신호 ID, 시간 단위, RTL 버전을 정렬해야 한다. 하지만 웨이브폼을 데이터베이스로 옮긴다고 압박이 자동으로 사라지지는 않는다. 고주파 클록은 밀집한 레코드를 만들고, 행 단위 INSERT에는 트랜잭션 비용이 든다. BTTF는 수집 시 웨이브폼 식별자에서 데이터베이스 ID로의 매핑을 구축하고, 신호 토글을 통계 내어 클록 필터링, 무토글 신호 잘라내기, 일괄 삽입을 결합한다. 잘라내기 전 데이터베이스는 1420 MB를 차지하고 쿼리에 약 410.5 밀리초가 걸리며, 클록과 무토글 신호를 필터링하면 규모가 395 MB로 줄고 소요 시간은 94.8 밀리초로 내려간다. 토글율이 평균 이하인 신호를 계속 삭제하면 데이터베이스는 185 MB까지 줄 수 있지만, 활동 커버리지는 64.23%만 남는다. 희귀 장애는 거의 토글하지 않는 제어 신호에서 정확히 나타날 수 있다. 데이터가 임포트 단계에서 삭제되면 이후의 Agent는 증거를 복구할 수 없다. 잘라내기는 어서션과 디버깅 요구에 복종해야 한다. SQL 인터페이스를 갖춘 후, BTTF는 서로 다른 Agent에게 분업을 배정한다: Orchestration Agent가 작업을 분해하고, Analysis Agent가 쿼리를 생성하며, Verification Agent가 어서션을 검사하고 RTL 소스와 연관 짓고, Evaluation Agent가 시간 범위, 필드 관계, 결과 완전성을 검증한다. 예를 들어 ASSERT_KNOWN이 신호에 X/Z 미지 상태가 나타났음을 발견하면, 시스템은 먼저 위반 시각을 고정한 뒤 관련 피연산자의 상태를 거슬러 검사하며 점진적으로 가능한 모듈을 특정한다. SQL 오류는 수정 후 계속할 수 있다. 연구팀은 4.2 GB 웨이브폼, 18450개 신호, 150건의 전문가 주석 쿼리 실험에서 95.33%의 실행 정확도를 얻었다. Multi-Agent 품질 점수는 단일 Agent보다 17.3% 향상되었고, 평균 지연도 약 1.96배로 증가했으며, 정적 SVA 검사 정확도는 84.62%였다. 이 방안은 포스트 시뮬레이션 분석을 지원할 수 있지만, 지속적인 수집과 복잡한 귀인에는 여전히 검증이 필요하다.03
왜 시크릿 스캔은 분류기로 되돌아갔나
고엔트로피 문자열은 진짜 자격 증명일 수도 있고, 테스트 데이터, 자리표시자, 체크섬일 수도 있다. 정규표현식은 의심스러운 형식을 빠르게 찾을 수 있지만 코드 컨텍스트 판단에는 서투르고, 범용 LLM은 구분을 도울 수 있지만 후보가 많아질수록 추론 비용과 지연이 계속 쌓인다. 코드 커밋이 수락되기 전에 결과를 내야 하는 Push Protection에게 이런 대기는 개발 경험에 직접 영향을 준다. GitHub는 정규식을 후보 진입점으로 유지하고, 이후 판단을 미세조정된 ModernBERT에 맡긴다. 이는 후보 문자열, 시크릿 유형, 변수명, 파일 경로, 인근 코드를 읽어 위험 분류 점수를 출력하고, 임계값이 경보 여부를 결정한다. 인코더는 포워드 계산만으로 클래스를 반환할 수 있어 생성형 LLM처럼 토큰별 설명을 출력할 필요가 없어, 동류 요청의 일괄 처리에 적합하다. 난점은 hard negatives에 있다: 문자열은 시크릿처럼 보이지만 무해한 예시라는 것이다. GitHub는 제품 피드백과 수작업 주석, 실제 저장소의 고재현율 후보, 특수 합성 어려운 음성 샘플을 조합하고, 저장소, 후보값, 연관 관계별로 학습·평가 집합을 나누어 유사 데이터로 인한 평가 편차를 줄였다. 그렇지 않으면 모델이 파일명을 암기할 수 있지만 낯선 프로젝트의 자격 증명을 식별하기 어렵다. 배포 시 모델은 ONNX로 내보내고 8비트 양자화를 거쳐 추론 자원 비용을 낮춘다. 임계값은 Precision, Recall과 온라인 트래픽을 결합해 보정해야 한다: 너무 느슨하면 오탐이 생기고, 너무 엄격하면 진짜 시크릿을 놓칠 수 있다. 새로운 시크릿 형식이 나타나면 학습 집합과 규칙도 갱신해야 한다. 기존 LLM 파이프라인 대비 새 방안의 오프라인 Precision은 13% 향상, Recall은 19% 향상되었다. 온라인 A/B 실험에서는 Post-push 스캔 실행 시간 중앙값이 86% 감소하고, 모델 서비스 비용은 98% 이상 감소했으며, 저장소 소유자별 가중 경보 수용 지표는 11.5% 향상되었다. 여기서 98%는 모델 서비스 비용을 의미하며, 보안 시스템 전체의 총비용이 아니다. 분류기는 정규식이 찾은 후보만 판단할 수 있어, 선행 규칙의 커버리지가 여전히 미탐 성능을 제한한다. 규칙이 단서를 발견하고, 분류기가 판단을 완수하며, 개방형 분석은 여전히 범용 LLM에 맡겨 매번의 고정 판단이 생성형 추론 비용을 부담하지 않도록 할 수 있다.04
다음은 CI의 차례일 수 있다
GitHub은 보안 검사의 피드백 시간을 단축했으며, 코드는 다음으로 여전히 빌드, 테스트 및 배포를 거쳐야 한다. Anthropic은 소스 코드 체크아웃 문제를 해결한 후에도 새로운 곤란에 부딪혔다: 한 차례의 테스트가 아직 끝나지 않은 사이에 메인 브랜치에 수백, 심지어 수천 건의 변경이 다시 병합될 수 있다는 것이었다. 전역 잠금에 계속 의존하면 변경이 끊임없이 쌓이고, 동시성을 풀어주면 새로운 위험이 생긴다. 어떤 테스트가 통과되었더라도, 그에 해당하는 코드 상태가 배포하려는 버전과 달라질 수 있기 때문이다. 이는 CI가 다음으로 처리해야 할 것이 고빈도 변경 속에서 검증 결과를 어떻게 유효하게 유지하느냐임을 의미한다. 빌드 캐시는 소스 코드와 의존성 관계의 변화를 식별해야 하고, 테스트 기록은 구체적인 커밋 및 빌드 산출물과 연관되어야 하며, 시스템은 어떤 결과를 재사용할 수 있고 어떤 수정이 이전 검증을 무효로 만드는지 판단해야 한다. 의존성이 복잡한 Monorepo의 경우, 테스트 머신을 단순히 늘리는 것만으로는 동시 수정이 가져오는 버전 일관성 문제를 해결하기 어렵다. Anthropic은 이미 병합 후 테스트와 배포 전 검증을 강화하기 시작했다. 일반 팀에게는 버전 관리 시스템을 직접 재구축하는 것보다 의존성 분석, 증분 테스트, 빌드 캐시를 먼저 완비하는 것이 더 현실적이다. Agent가 코드 산출량을 계속 높임에 따라 소프트웨어 엔지니어링의 병목은 전달 경로를 따라 계속 뒤로 이동할 것이다. 코드가 메인 브랜치에 들어가는 속도는 점점 빨라질 수 있지만, 빌드·테스트·배포 사이에는 신뢰할 수 있는 검증 관계가 반드시 유지되어야 한다. 앞으로 점점 더 많은 사례를 통해 다음 사실이 드러날 것이다.AI가 코드를 작성하는 급격한 질주는 결국 소프트웨어 엔지니어링 파이프라인 전체를 강제로 "다시 한번 다시 만들게" 만들고 있다.엔지니어링 인프라의 가치 또한, 고속으로 변화하는 코드가 지속적으로 신뢰할 수 있는 전달 근거를 얻게 할 수 있는지에 더 많이 담길 것이다.참고 링크:https://www.anthropic.com/engineering/redesigning-source-control탑승하세요, 전 세계 AI 정상 회의의 핵심을 모두 보여드립니다
독점적으로 감상 가능:
전문가 발표 PPT
컨퍼런스 보고서 전문
인기 논문 해설
학계 신성 인터뷰
위 QR 코드를 스캔하거나
"阅读原文(원문 보기)"을 클릭하여 전용 페이지를 팔로우하세요.
레이펑왕(雷峰网) 오리지널 기사이며, 무단 전재를 금지합니다. 자세한 내용은전재 안내를 참조하세요。