Claude Code 도입 후 주간 PR이 65개에서 694개로 폭증하여 CI가 감당을 못 함

우리는 원래 순수 트렁크 기반 병합 팀/프로세스를 썼었음. 근데 이렇게 자주 변경사항이 쏟아지니까 그게 안 되더라고.

그래서 사양 "단계"/기능 브랜치 방식으로 바꿨음. 참고로 말하자면 - PR 개수 자체를 줄여주진 않음, 오히려 트렁크로 가는 단계가 추가돼서 조금 더 늘어날 수도 있음. 하지만 - 배포 파이프라인이랑 CD 단계들을 보호하고, 부분적인 기능 작업이 프로덕션 빌드를 깨뜨리는 문제를 완화해 줬음.

결국 우리한테는 엄청난 수의 PR로부터 배포 프로세스를 보호하는 게 핵심이었음

탄력적 스케일링이랑 저렴한 버스터블 SKU 기반의 에페메랄 컴퓨팅을 쓰는 운영 클러스터로 옮겼음

개발이 늘어나서 CI가 마비되는 건 완전히 정상 아님? 2024년 이전에도 사람만으로 프로젝트 할 때 겪었던 일임. 별거 아님.

개발자를 더 뽑거나, 테스트를 더 꼼꼼하게 하거나 둘 중 하나겠지..

무슨 말인지 이해함, 나도 20대의 러너를 관리하는 봇 시스템을 만들어서 주당 800개의 PR을 처리하고 있음. 작업당 CI 시간은 약 4시간 정도. 내 코드 팩토리로 러너를 항상 100% 풀가동함.

개발 환경에 빌드 에이전트 10대가 있는데, 각각 8코어에 16gb 램인데도 감당이 안 됨.

컴파일 속도가 더 빠른 플랫폼을 선택해야 할 강력한 이유가 생김...

30개 넘는 자바 마이크로서비스가 우리를 죽이고 있음 (우리 선택도 아니었음)

GitHub CI용으로 Blacksmith를 선택했는데 만족하며 쓰고 있음.

에이전트에게 재사용 가능한 테스트 블록을 제공하려고 나만의 소스 제어 시스템을 만들었음. 앤스로픽, 구글, 메타의 연구를 기반으로 함: https://github.com/rawritude/patchweft

우리는 빌드랑 CI 실행용으로 꽤 사양 좋은 헤츠너 전용 서버를 돌리고 있음.

맞음, 우리도 슬롯이 제한적이라 ADO용 로컬 CI 에이전트를 설정했는데, 지금 10시간 정도 밀려있는 상태임.