코딩 에이전트가 CI 부하를 25배로 불리자 Anthropic이 테스트 선택 서비스를 재설계한 이유

코딩 에이전트가 코드를 대량으로 쓰면서 Anthropic의 CI 부하가 6개월 만에 25배로 늘었습니다. 테스트 선택 서비스가 세 번의 임시방편 끝에 stateless 구조로 재설계된 과정을 실측 수치로 정리합니다.

코딩 에이전트가 CI 부하를 25배로 불리자 Anthropic이 테스트 선택 서비스를 재설계한 이유 대표 이미지

핵심 요약

  • 코딩 에이전트가 코드를 대량으로 쓰기 시작하면서 Anthropic의 CI 잡 볼륨이 6개월 만에 25배로 늘었습니다.
  • 엔지니어 1인당 분기 코드 작성량은 2021~2025년 대비 8배, 그중 80%는 Claude가 작성했습니다.
  • 병목은 코드 작성이 아니라 "어떤 테스트를 돌릴지 결정하는" 테스트 임팩트 분석 서비스로 이동했습니다.
  • 임시방편 3연속(머신 확장→샤딩→매일 재시작)의 수명은 각각 70일, 29일, 1일 미만으로 점점 줄었습니다.
  • 최종 해법은 단일 프로세스를 stateless 워커와 인메모리 저널로 재설계해 수평 확장이 가능하게 만든 것입니다.
  • 재설계는 단일 엔지니어가 3주 만에 완성했습니다. 1년 전이면 분기 수준이 걸렸을 작업입니다.

코드 작성이 병목이 아니게 되면 병목은 어디로 이동하는가

테스트 임팩트 분석(test impact analysis)이란 모든 변경에 모든 테스트를 돌리는 대신, 과거 테스트 성과와 패키지 연관성을 바탕으로 "이 변경에는 어떤 테스트만 돌리면 되는지"를 결정하는 시스템을 말합니다. Anthropic은 이 서비스가 코딩 에이전트의 코드 폭증에 어떻게 병목이 됐고 어떻게 재설계했는지를 실측 수치와 함께 공개했습니다(Anthropic).

코딩 에이전트가 보편화되면서 가장 먼저 무너지는 것은 "코드를 쓰는 속도가 병목"이라는 전제입니다. Anthropic 엔지니어들은 분기당 2021~2025년 대비 8배의 코드를 작성하고 있으며, 그 코드의 80%는 Claude가 생성한다고 합니다(Anthropic). Claude는 PR 리뷰와 승인 과정에도 깊숙이 관여합니다(Anthropic).

이런 상황에서 테스트 수는 10배로 늘었고 CI 잡 볼륨은 6개월 만에 25배로 증가했습니다. 핵심은 분명합니다. 코드를 쓰는 속도가 더 이상 제약이 아니게 되면, 다음 제약은 반드시 "그 코드가 맞는지 검증하는 단계"로 이동합니다. CI와 테스트가 바로 그 자리입니다.

단일 프로세스라는 근본 한계

Anthropic의 테스트 임팩트 분석 서비스는 두 결정적(deterministic) 컴포넌트로 이뤄져 있습니다. 첫째는 모든 CI 실행의 테스트 결과를 기록하는 listener, 둘째는 그 이력을 읽어 어떤 PR에 어떤 테스트를 돌릴지 결정하는 selector입니다.

문제는 이 서비스가 단일 프로세스로 동작했다는 점입니다. 테스트별 실행 이력을 유지하려면 단일 writer가 결과를 순서대로 적용해야 했고, 이 때문에 수평 샤딩이 원천적으로 불가능했습니다. CI 잡이 매초 여러 개씩 실행되면 listener가 PR 큐를 따라잡지 못하고 뒤처집니다(Anthropic).

이 지연은 20분만 쌓여도 수만 건의 테스트 업데이트가 selector에 반영되지 않는 결과를 낳습니다. 나쁜 변경이 병합되면 그 테스트가 모두에게 실패하기 시작하고, 의존성이 플레이크해지면 병합이 막히며, 테스트를 수정하거나 새로 추가해도 listener가 따라잡을 때까지 실행되지 않아 회귀가 발생할 위험이 커집니다.

임시방편 3연속과 그 수명

저자는 재설계에 도달하기 전에 세 번의 땜빵을 거쳤고, 각각의 수명을 구체적으로 공개했습니다. 이 수치가 이 글에서 가장 값진 부분입니다.

첫 번째 조치는 머신 확장이었습니다. 서비스를 돌리는 코어를 두 배로 늘렸고, 결과는 70일을 버티는 데 그쳤습니다. 두 번째는 샤딩이었습니다. listener가 단일 writer가 아니라 패키지별 단일 writer를 갖도록 각 패키지 상태를 shard와 워커로 분리했고, 이 코드는 Claude가 생성했습니다. 이번에는 29일만 버텼습니다.

세 번째는 매일 재시작이었습니다. 3월에는 대부분의 평일에 오후가 되면 프로세스가 메모리 한계에 도달했습니다. 메모리 할당자를 바꾸는 것도, GC를 튜닝하는 것도 효과가 없었고 버그는 4개밖에 찾지 못했습니다. 재시작으로 버틴 시간은 하루도 되지 않았고, 재시작 때문에 listener가 뒤처져 결과가 누락되는 부작용까지 생겼습니다(Anthropic).

이 세 단계를 보면 수명이 70일에서 29일, 1일 미만으로 급감합니다. 지수적으로 늘어나는 부하 앞에서 "더 큰 머신, 더 많은 프로세스, 재시작" 같은 선형적 조치는 갈수록 짧게 버틸 수밖에 없다는 것을 실측이 보여줍니다.

재설계: 저널과 stateless 워커

최종 해법은 서비스를 통째로 재설계하는 것이었습니다. 핵심은 단일 writer라는 제약을 제거하는 일입니다.

새 설계에서는 모든 listener 워커가 어떤 결과든 처리해 인메모리 데이터 스토어의 저널(journal)에 append하기만 하면 됩니다. 메모리에 아무것도 들고 있지 않은 stateless 상태라 수평 확장이 가능해집니다. 별도의 소형 consumer 프로세스가 몇 초마다 저널을 테스트별 이력으로 roll-up하고, selector는 그 이력을 빠르게 조회합니다(Anthropic).

이 분산 아키텍처는 운영 비용이 더 들지만, 흔들리는 싱글턴보다 확장과 메모리 프로파일링이 훨씬 쉽습니다. 저널 크기와 워커 수를 튜닝하는 작업은 Claude가 대부분 자율적으로 수행했습니다.

가장 눈에 띄는 수치는 소요 시간입니다. 이 재설계 프로젝트는 단일 엔지니어가 3주 만에 완성했습니다. 저자는 1년 전이었다면 분기(quarter) 수준이 걸렸을 것이라고 말합니다. 코드 작성 속도가 빨라졌기에 재설계 같은 큰 작업도 그만큼 빨라진 것입니다.

실무에 적용할 교훈

저자가 강조하는 첫 교훈은 "항상 지수 성장을 계획하라(plan for the exponential)"입니다. CI 잡은 엔지니어당 에이전트 수가 늘고 PR 승인이 가속될수록 지수적으로 증가합니다. 그는 2분기 안에 25배 부하가 올 것이라고 가정하고, v0 설계부터 10~20배 스케일을 염두에 두라고 조언합니다. 예산이 허락한다면 말입니다.

둘째 교훈은 계측(instrumentation)입니다. 저자는 서비스를 계측해 Claude의 눈과 귀로 쓰라고 말합니다. 구체적으로는 CI 잡 유입 수와 유출 수가 일치하는지 확인하는 것부터 시작합니다. 저자 자신도 listener 지연이 5만 잡을 넘으면 Claude가 페이지를 보내 대화를 재개하도록 장기 세션을 운영했습니다. 지수 성장 트렌드를 에이전트가 직접 인지하고 점진적으로 고치게 만든 것입니다.

셋째 교훈은 에이전트와 테스트의 상호작용입니다. 인간은 어떤 테스트 실패가 자신과 무관한지 잘 판단하지만, 에이전트는 더 많은 맥락과 방향이 필요합니다. 유효한 테스트 집합을 명확히 주면 에이전트가 자기검증하고 반복하는 효율이 크게 올라갑니다.

우리 블로그의 관점에서 이 글의 가치는 벤더 마케팅이 아니라 실측 수치를 공개했다는 데 있습니다. 25배, 8배, 80%, 10배 같은 숫자와 70일·29일·1일 미만 같은 땜빵 수명은 외부에서도 검증 가능한 회고 데이터입니다.

결론

코딩 에이전트를 도입하면 병목은 코드 작성에서 코드 검증으로 이동합니다. Anthropic의 사례는 이 전이가 실제로 어떤 모습인지 수치로 보여줍니다.

에이전트 코딩을 운영 중이거나 도입하려는 팀이 지금 할 수 있는 일은 다음과 같습니다.

  • 테스트 임팩트 분석(변경별 테스트 선택) 도입 여부를 검토합니다. 모든 테스트를 모든 PR에 돌리는 방식은 에이전트가 PR 수를 늘리면서 곧바로 한계에 부딪힙니다.
  • 신규 서비스를 설계할 때 지수 성장을 전제로 10~20배 스케일을 처음부터 고려합니다.
  • CI와 테스트 파이프라인을 계측해 잡 유입·유출 수치가 일치하는지 모니터링하고, 그 지표를 코딩 에이전트가 읽을 수 있게 노출합니다.
  • 에이전트에는 유효한 테스트 집합과 맥락을 명시적으로 제공해 자기검증 효율을 높입니다.

시작점으로 권하는 것 — 지금 사용하는 CI에서 잡 유입 수와 유출 수가 일치하는지부터 확인해보세요. 다음 서비스를 설계할 때 10~20배 스케일을 전제로 잡아두는 것도 함께 시작할 수 있습니다. 이 두 가지가 에이전트 코딩 시대에 검증 병목을 값싸게 막는 가장 확실한 보험입니다.

참고 링크