Anthropic은 9월 14일 엔지니어링 블로그에 글을 올렸다. 작성자 Sachin Malhotra는 사내의 한 서비스가 부하에 짓눌려 다시 만들어진 과정을 설명했다. 이 서비스의 이름은 테스트 영향 분석(test impact analysis)으로, 역할은 단순하다. 코드 변경이 들어오면 어떤 테스트를 반드시 실행하고 어떤 테스트를 건너뛸 수 있는지 판단하는 것이다. 언뜻 백엔드 구성 요소처럼 보이지만, 이 서비스가 버티지 못한 이유는 상당히 대표적이다.
먼저 배수부터 보면
블로그가 제시한 첫 번째 수치는 산출 쪽이다. Anthropic 엔지니어가 분기마다 커밋하는 코드량은 2021~2025년 구간 대비 평균 8배에 달하며, 이 중 80%는 Claude가 작성한 코드다. Claude는 PR 리뷰와 승인 과정에서도 상당한 비중을 차지한다.
두 번째 수치는 부하 쪽이다. 코드베이스 내 테스트 총수는 10배로 늘었고, 6개월 사이 CI 작업 수는 25배가 됐다.
세 번째 수치가 사태의 진행 속도를 가장 잘 보여준다. 팀은 부하를 버티기 위해 세 차례 임시 완화 조치를 취했는데, 매번 벌어준 시간이 70일, 29일, 하루 미만으로 점점 짧아졌다. 세 번째 방안은 출시 당일에 이미 한계에 도달했다.
기존 서비스는 어디서 막혔나
기존 아키텍처에는 각 테스트 결과를 순서대로 저장소에 기록하는 단일 프로세스 리스너가 있었다. 단일 쓰기 구조라 수평 확장이 불가능했고, PR이 처리 속도보다 빠르게 몰리면 큐가 쌓이기 시작했다. 블로그 원문은 이 리스너가 "starts to increasingly fall behind the PR queue(PR 큐에 점점 더 뒤처지기 시작한다)" 상태가 된다고 표현했다.
지연의 여파는 누적됐다. 글에서 든 예시로는, 20분의 지연이 수만 건의 테스트 결과 업데이트가 저장소에 반영되지 않은 상태에 해당했다. 테스트 선택 자체가 과거 결과를 근거로 판단하는 작업이다 보니, 이력이 부정확하면 선택된 테스트 집합도 신뢰할 수 없게 된다. 설상가상으로 이 프로세스에는 메모리 누수까지 있어 매일 오후가 되면 한계치에 도달했다.
무엇으로 바꿨나
재작성의 발상은 상태를 프로세스 밖으로 빼내는 것이었다. 새 아키텍처는 인메모리 데이터 스토어를 도입해, 어떤 리스너 워커든 어떤 결과든 처리할 수 있게 했다. 워커 자체는 상태를 갖지 않고 로그에 추가하는 역할만 하므로 필요에 따라 머신을 늘릴 수 있다. 이와 별도로 몇 초마다 로그를 접어 테스트별 이력으로 정리하는 독립된 소비 프로세스가 있으며, 셀렉터가 판단을 내려야 할 때는 이 이력을 직접 조회한다.
대가는 비용 상승이다. 블로그는 이를 솔직히 인정하면서, 그 대신 확장성과 관측 가능성을 얻었다고 설명한다. 어느 단계가 느린지, 어디서 느려지는지를 이제 개별적으로 측정할 수 있다. 전체 재설계는 엔지니어 한 명이 3주 만에 완료했다.
25배라는 곡선
6개월에 25배라는 수치는 월 복리 증가율로 환산하면 약 1.71배(25의 6제곱근)에 해당한다. 이 기울기를 다시 6개월 앞으로 연장하면 625배가 된다. 글 말미의 "always plan for the exponential(항상 기하급수적 증가를 염두에 두라)"이라는 문장은 수사가 아니라, 이미 실측된 이 곡선을 가리키는 표현이다.
다만 이 곡선의 외삽은 당연히 신뢰하기 어렵다. 내부 정책, 쿼터, 엔지니어링 관행의 변화에 따라 증가율은 꺾일 수 있고, Anthropic은 CI 비용의 절대치도, 새 서비스가 테스트를 몇 퍼센트 걸러냈는지도, 재작성 이후 지연이 어느 수준까지 낮아졌는지도 공개하지 않았다. 비용을 얼마나 절감했는지는 공개된 정보만으로는 알 수 없다.
다만 부하가 어느 단계에서 다음 단계로 옮겨가는지는 분명하다. 올해 4월 GitHub는 Copilot의 개인용 요금제 세 종류에 대해 신규 가입을 중단했는데, 에이전트의 장시간 작업이 소모하는 연산량이 요금제 설계 범위를 넘어섰다는 이유였다. 더 앞서는 AI 커밋 급증이 GitHub에 장애를 일으켜 Microsoft가 한때 AWS에서 용량을 빌려와 버틴 적도 있었다. 세 사건은 형태는 다르지만 같은 것을 가리킨다. 코드 생성 단계가 먼저 빨라지고, 그다음이 리뷰이며, 그 뒤로 "사람이 코드를 짜는 속도"를 기준으로 용량을 설계한 모든 시스템이 차례로 부딪히게 된다는 것이다. 테스트 영향 분석은 이번 라운드에서 비교적 일찍 경보를 울린 시스템일 뿐이다.
참고 출처: CocoLoop, Anthropic 엔지니어링 블로그. 코드량 배수, 테스트 및 CI 작업 증가율, 세 차례 완화 방안의 유효 기간은 모두 해당 게시물이 밝힌 수치를 따른다.