10월 17일 토요일
에이전트가 코드 생산을 가속한 뒤의 병목은 생성 자체가 아니라 변경을 저장하고 탐색하고 검증하며 안전하게 복구하는 기반 구조로 이동한다.
코드를 더 만드는 시스템에서, 변경을 더 잘 흘리는 시스템으로
소스 컨트롤의 기본 단위를 바꾸는 Scion과 명세·컨텍스트·샌드박스를 묶어 보면, 에이전트 규모의 개발은 생성기보다 경계와 복구 경로를 먼저 설계해야 한다.
병목은 코드 작성에서 변경 처리량으로 옮겨 갔다
Anthropic 사례에서 하루 머지 변경량은 2026년 5월 약 2,500건에서 9월 30,000건 이상으로 늘었다. 같은 환경의 메인 브랜치 이력은 거의 100GB이고, CI는 하루 약 2,500만 번 코드를 체크아웃한다. 에이전트가 기능 전체를 맡아 코드 이해, 테스트, 병합까지 이어 가면 기존의 완전한 로컬 복제와 사람 중심 순차 검토가 먼저 포화된다. 직접 구현이 희소했던 시절에는 변경 앞의 승인과 마찰이 안전장치였지만, 변경 생성 비용이 낮아진 뒤에는 저장소 이력 전송, 작업 사본 준비, 병합 조정, 실패 복구가 처리량을 결정한다. 그러므로 에이전트 도입을 모델 성능 문제로만 보면 실제 병목을 놓친다. 목표와 산출물을 명세로 고정하고, 여러 작업이 동시에 들어와도 막히지 않는 변경 흐름을 함께 설계해야 한다.
Scion은 로컬 저장소가 아니라 서버 질의를 기본 단위로 삼는다
Scion은 항상 온라인인 에이전트와 CI를 전제로 이력, blame, 커밋, 머지, 리베이스 같은 연산을 서버에 둔다. 클라이언트는 제한된 객체 캐시와 필요한 작업 사본만 유지하고, diff만 필요하면 전체 체크아웃 없이 API에 질문한다. 저장 단위도 전역 ref를 자주 움직이는 대신 첫 번째 부모 대비 바뀐 파일 목록과 불변 콘텐츠 주소를 기록하는 append-only 변경 세트다. blame과 경로 이력 같은 질의는 그 위의 파생 데이터로 분리한다. 희소 체크아웃은 필요한 디렉터리만 받고, 가상 체크아웃은 실제로 읽을 때까지 파일 물질화를 미룬다. 권위 서버, 지역 캐시, CI 데몬이 같은 RPC에 답하되 계층을 분리해 장애가 상위로 번지는 것을 막는다. 원문이 제시한 결과는 캐시 적중률 99% 이상, 기존 Git 미러링 대비 CPU·메모리 200분의 1, CI 용량 25% 회수다. 핵심은 빠른 명령 하나가 아니라 불변 객체와 서버 API로 조정 범위를 줄인 구조다.
에이전트 실행 경계는 컨텍스트와 권한을 함께 제한해야 한다
실행 계층에서는 프롬프트보다 요구사항과 기대 결과를 명세로 전달하고, 사람이 목적을 정하면 에이전트가 종료 조건까지 반복하는 루프를 만든다. 이때 컨텍스트 윈도우는 코드만 담는 공간이 아니다. 도구, 재사용 가능한 스킬, MCP 서버가 같은 자원을 차지하므로 무엇을 언제 제공할지 정해야 한다. 권한 설계는 더 직접적이다. 민감 데이터 접근, 웹 노출, 외부 전송 능력이 한 에이전트에 동시에 모이면 온라인 풀 리퀘스트 같은 입력의 프롬프트 인젝션으로 자격 증명이 빠져나갈 수 있다. 그래서 코딩 에이전트를 일회용 샌드박스에 격리해 침해됐을 때의 공격 표면을 줄이는 원칙이 필요하다. 컨텍스트 관리와 샌드박스는 별개 기능이 아니라, 에이전트가 볼 수 있는 것과 할 수 있는 것을 나눠 제한하는 같은 경계 설계다.
처리량이 커질수록 완벽한 차단보다 검증과 복구를 짧게 만든다
수백 개의 동시 변경을 인간 규모의 전역 머지 큐에 세우면 테스트 중에도 새 변경이 쌓여 잠금이 병목이 된다. Anthropic의 선택은 모든 실패를 머지 전에 제거하려는 대신 머지 후·배포 전 자동 테스트, 제한된 배포, 빠른 되돌리기로 피해 범위를 줄이는 것이다. Scion 구축 과정에서는 비자명한 인프라 상호작용을 hermetic simulation으로 재현하고 퍼징과 rate limiting을 적용했다. 사람의 역할도 사라지지 않는다. 에이전트가 커밋 로그를 선형으로 읽는 쉬운 우회로처럼 핵심 제약을 위반하면 올바른 API 경계로 되돌리고, 적대적 리뷰가 가상의 위험까지 키워 복잡도를 늘릴 때 범위를 줄여야 한다. 이 구조는 일반적인 작은 저장소에 곧바로 적용할 범용 Git 대체안이 아니다. 코드 리뷰, 검색, CI까지 함께 바꿀 만큼 변경량과 저장소 규모가 실제로 임계점을 넘었는지 먼저 입증해야 한다.
검색 전략은 정답률 하나로 고를 수 없다
같은 테스트 정확도를 낸 두 검색이 비용과 문맥 복원에서 갈린 실험은, 데이터셋·도구 제약·trace·반복 실행을 한 묶음으로 검증해야 하는 이유를 보여준다.
코딩 에이전트의 검색 전략을 정확도, 비용, 문맥, trace, 실험 한계까지 포함해 어떻게 비교해야 하는가?
Braintrust 실험은 Microsoft TypeScript-Go 저장소에서 제목에 fix가 포함된 병합 PR의 부모 커밋을 체크아웃해 버그가 남은 상태를 만들고, 수정 전후 diff로 약 20개의 bug task를 구성했다. Agentic Search와 Vector Search는 같은 Claude Code harness에서 실행했다. Vector 조건에서는 프롬프트로 에이전틱 검색을 금지하는 데 그치지 않고 관련 도구를 disallowed tools로 차단했다. 결과 채점은 저장소 테스트 스위트 통과면 100%, 실패면 0%인 결정론적 기준이었다. 이 조건에서 두 방식의 정확도는 같았지만 Vector Search의 비용은 네 배였다. 결론은 벡터 검색이 본질적으로 열등하다는 선언이 아니라, 같은 정확도 뒤에 숨은 반복 호출과 문맥 누락을 trace로 확인해야 한다는 것이다.
- 01
비교 가능한 실험은 실행 권한까지 고정한다
검색 전략만 바꾸려면 모델과 harness를 같게 두고 사용할 수 있는 도구를 실제로 제한해야 한다. 프롬프트 지시만으로는 모델이 grep, find, ls 같은 기본 탐색으로 되돌아갈 수 있어 조건이 섞인다. 데이터셋, 작업, 채점 기준을 고정하고 구성 변경을 별도 실험으로 기록해야 정확도 변화와 회귀를 구분할 수 있다.
- 02
근접성과 연결 관계는 다른 품질이다
Vector Search는 의미적으로 가까운 코드 조각을 제시하지만 import, 호출자, 상위 흐름이 청크에서 빠질 수 있다. 한 실행에서는 26번 검색하고도 한 파일의 세 함수가 어떻게 상호작용하는지 연결하지 못했다. Agentic Search는 함수 이름을 찾고 전체 파일을 읽은 뒤 호출 경로를 따라가며 연결 조직을 복원했다. 검색 결과의 유사도뿐 아니라 문맥 완전성과 추가 호출 횟수를 평가해야 한다.
- 03
trace가 비용 차이를 설명하게 만든다
subprocess 안의 실행이 부모와 연결되지 않으면 상위 단계만 보이고 LLM 호출과 터미널 명령은 고아 trace가 된다. 실험은 부모 span ID를 환경 변수로 넘겨 모든 턴과 명령을 한 trace에 연결했다. 그 결과 Vector Search가 문맥 부족 때문에 다시 검색하고 LLM 호출 비용을 누적하는 경로를 확인할 수 있었다. 점수표는 무엇이 달랐는지 보여주지만 trace는 왜 달랐는지 설명한다.
- 04
네 배라는 수치에는 명시해야 할 경계가 있다
작업당 한 번만 실행해 비결정성의 평균과 분산을 재지 않았고, 데이터셋도 약 20개 작업으로 작았다. 사용한 Vector Search 구현은 상대적으로 약해 더 나은 청크 전략, 재랭킹, 호출 관계 보강, 문맥 확장에서 결과가 달라질 수 있다. 따라서 다음 실험은 여러 trial, 더 큰 데이터셋, 다른 언어와 저장소, 정확도·비용·실행 시간·문맥 완전성의 분리 지표를 포함해야 한다.
도입 판단은 ‘어느 검색이 더 좋다’가 아니라 우리 코드베이스의 대표 작업에서 어떤 방식이 테스트를 통과하고, 필요한 문맥을 복원하며, 얼마의 호출과 비용을 쓰고, 같은 결과를 반복해서 내는가로 바뀌어야 한다. 작은 평가는 최종 판결이 아니라 다음 데이터셋과 계측을 설계하는 출발점이다. 정확도가 같으면 비용과 trace를 보고, 비용이 낮아도 실패 유형과 분산을 확인해야 한다. 그래야 에이전트 하네스의 변경을 감이 아니라 재현 가능한 출시 기준으로 연결할 수 있다.
아직 못 읽은 북마크
북마크를 고르는 중…