깃허브 엔지니어 스티븐 토웁(Stephen Toub)은 9월 16일, 코파일럿 에이전트가 주도한 대규모 재작성 작업을 회고하는 글을 올렸다. 코파일럿 에이전트의 런타임을 타입스크립트/Node.js에서 러스트로 통째로 옮기는 작업이었다. 원래 약 43만 줄이던 프로덕션 타입스크립트 코드는 최종적으로 83만 2378줄의 프로덕션 러스트 코드가 됐고, 여기에 러스트 단위 테스트 46만 8000줄과 엔드투엔드 테스트 17만 4000줄이 추가됐다.
작업 기간은 5월 12일부터 8월 21일까지, 약 14.5주였다. 이 기간 동안 128건의 풀 리퀘스트가 순차적으로 메인 브랜치에 병합됐고, 그 와중에도 릴리스는 계속 이어졌다. 누적 135개 버전(사전 릴리스 100개, 정식 버전 35개)으로, 하루 평균 약 1.3개꼴이었다.
코드 대부분은 모델이 짰다, 그럼 사람은 뭘 했나
토웁은 이번 작업에 대해 직설적으로 이렇게 정리했다.
"A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months."
에이전트가 등장하기 전이었다면 개발팀 전체가 1~2년은 매달렸을 프로젝트가, 이번에는 개발자 한 명이 주도해 불과 몇 달 만에 완성됐다.
주로 사용된 모델은 클로드 오퍼스(Claude Opus) 4.8, GPT-5.6 Sol, 그리고 클로드 하이쿠(Claude Haiku) 계열이었다. 처리량 최적화를 담당한 서브에이전트는 오퍼스 4.8과 GPT-5.6 Sol 비중이 높았다. 눈에 띄는 대목은, 마이크로소프트 산하 깃허브가 자사 핵심 컴포넌트를 프로덕션 수준으로 재작성하면서 오픈AI 일변도가 아니라 경쟁사인 앤스로픽의 모델을 주력으로 썼다는 점이다.
사람이 맡은 역할은 명확히 구분돼 있었다. 프로젝트를 이끈 엔지니어 본인의 작업 내역에 따르면, 시간의 31%는 "리뷰, 테스트, CI"에, 17.4%는 "기술적 결정에 이의 제기"에, 15%는 "작업을 끝까지 밀어붙이는 데" 쓰였다. 아키텍처, 설계상의 트레이드오프, 최종 병합 여부에 대한 판단은 처음부터 끝까지 사람의 몫이었다. 모델이 코드량을 만들어내면, 사람이 방향과 수용 기준을 붙잡고 있었던 셈이다.
검증은 기존 테스트로, 드러난 결함은 약 50건
이번 재작성은 별도의 새로운 수용 기준을 만들지 않고, 기존에 있던 엔드투엔드 테스트를 새로 짠 러스트 코드에 계속 돌리면서 점진적으로 배포해 회귀 문제를 작은 범위에서 조기에 드러내는 방식을 택했다. 눈여겨볼 만한 수치도 몇 가지 있다. 프롬프트 캐시 적중률은 96.22%였고, 컨텍스트 압축은 세션 전체에서 5,116번 발생했다.
실패 사례도 있는 그대로 기록됐다. 프로젝트 전체에서 확인된 알려진 문제는 50여 건으로, 다섯 가지로 분류된다. 마이그레이션이 불완전한 경우, 상태·생명주기 관련 문제, 동작 계약이 일치하지 않는 경우, 호스트 경계 문제, 그리고 테스트 자체의 기대값이 잘못돼 있던 경우다. 대부분은 정식 버전에 이르기 전에 고쳐졌다. 마지막 범주는 비슷한 마이그레이션을 하는 사람들에게 특히 새겨둘 만하다. 오래된 테스트로 새 구현을 검증할 때, 때로는 코드가 아니라 그 테스트 쪽이 틀렸을 수도 있다는 것이다.
다른 엔지니어링 팀에 주는 의미
자사 핵심 컴포넌트를 AI로 대대적으로 손본 이번 사례는, 어떤 벤치마크 순위표보다 지금 코딩 에이전트의 실제 한계를 잘 보여준다. 그대로 가져다 쓸 수 있는 교훈은 세 가지다. 첫째, 단번에 전체를 다시 짤 수 있으리라 기대하지 말 것. 128건의 풀 리퀘스트를 순차적으로 병합하고 하루에도 여러 번 릴리스하는 방식으로 지속적 통합이 위험을 잘게 분산시켰다. 둘째, 수용 기준을 미리 못 박아 둘 것. 이번 작업 전체가 기존 E2E 테스트를 잣대로 삼았고, 이런 잣대가 없으면 "모델이 제대로 짰는지"를 판단할 방법이 없다. 셋째, 사람의 작업이 코드 작성에서 리뷰·의사결정·누락 발견으로 옮겨가면서, 한 사람이 감당할 수 있는 재작성 규모가 한 단계 커졌다.
다만 유의할 점도 있다. 아키텍처상의 이점(프로세스 내 임베딩, 낮아진 메모리 오버헤드, 빨라진 구동 속도)은 원문에서 정성적으로만 설명돼 있을 뿐, 메모리·지연 시간·처리량에 대한 전후 비교 수치는 나오지 않는다. 이번 재작성으로 실제 성능이 얼마나 개선됐는지는 이 회고 글만으로는 검증할 수 없다. 타입스크립트에서 러스트로 옮기는 경로 역시 대다수 팀에 표준 답안은 아니다. 이 방식이 통했던 건 의지할 만큼 탄탄한 테스트 체계와 매일이라도 릴리스할 각오가 있었기 때문이다.
참고 출처: CocoLoop, GitHub Blog(스티븐 토웁). 83만 2000줄, 풀 리퀘스트 128건, 14.5주, 캐시 적중률 96.22%, 알려진 문제 약 50건 등의 수치는 공식 회고 글을 기준으로 확인했다.