GitHub, Copilot 에이전트 런타임을 Rust로 전면 재작성…80만 줄을 AI가 대부분 작성

GitHub가 Copilot의 핵심 실행 엔진인 'Copilot 에이전트 런타임'을 TypeScript에서 Rust로 전면 재작성했다. Copilot CLI, Copilot 앱, Copilot SDK 뒤에서 동작하는 에이전트 하네스가 대상이며, 결과물은 80만 줄이 넘는 프로덕션 Rust 코드다.

작업 방식도 눈에 띈다. 128개의 풀 리퀘스트가 main에 점진적으로 반영됐고, 마지막에 한 번에 갈아치우는 방식은 택하지 않았다. 코드의 상당 부분은 AI 에이전트가 작성했다. 이전 같으면 개발자 팀이 1~2년을 써야 했을 규모의 작업을 주로 개발자 한 명이 몇 달 만에 끝냈고, 그동안 나머지 팀원들은 런타임의 기능과 적용 범위를 넓히는 데 집중했다. 전환 과정에서 회귀 버그가 아예 없지는 않았지만 발견과 수정이 빨랐고, 런타임 성능은 자릿수가 달라질 정도로 개선됐다.

이 런타임은 CLI 전용 엔진이 아니다. VS Code, Visual Studio, Copilot cloud agent(CCA), Copilot Code Review(CCR), Copilot Cowork, Copilot Studio는 물론 Excel·Outlook·PowerPoint·Word까지 같은 런타임을 공유한다. 이들 제품은 대부분 처음에 자체 에이전트 루프를 구현했다가 GitHub Copilot SDK로 갈아탔다. SDK가 런타임으로 들어가는 관문 역할을 하면서, 각 제품은 자기 핵심 가치에 집중하고 에이전트 루프의 세부 구현은 런타임에 맡길 수 있게 됐다. 한 곳을 고치면 전체가 함께 고쳐지는 구조다.

문제는 공유 대상의 성격이었다. 기존 스택은 TypeScript + Node.js + V8, UI는 Ink와 React로 짜여 있었다. 콘솔 애플리케이션 하나만 놓고 보면 합리적인 선택이지만, 다른 환경에 임베드될 때 이야기가 달라진다. TUI와 런타임이 층으로 분리되지 않고 얽혀 있었고, SDK는 CLI 위에 얹히는 역전된 구조를 취했다. CLI에 headless 모드를 붙이고 stdin/stdout과 JSON-RPC로 외부 프로세스의 함수 호출을 중계하는 방식이었다. 그 결과 SDK로 클라이언트를 만들 때마다 CLI 서브프로세스가 새로 뜨고, Node와 V8을 실행하고, TypeScript가 뱉은 자바스크립트를 파싱해 바이트코드를 만들고, V8의 메모리 오버헤드를 그대로 떠안았다. 언어별 SDK(C#, Python, Go, Java, Rust)마다 최소 100MB 수준의 워킹셋이 추가로 필요했고, 모든 이벤트와 메시지, 세션 파일 시스템 입출력이 프로세스 경계를 넘었다. Node가 죽으면 세션도 같이 죽었고, 배포하는 쪽은 최소 두 개의 프로세스를 감독·모니터링·디버깅해야 했다.

Rust를 고른 이유는 명확하다. C ABI를 통한 인프로세스 임베딩, 낮은 시작 비용과 상주 오버헤드, 예측 가능한 자원 사용이 요구사항이었고, 6개 SDK 언어(C#, TypeScript, Python, Rust, Go, Java)가 각자의 FFI로 깔끔하게 붙을 수 있어야 했다. 의존성이 적고 공급망 위험이 낮으며, 올바른 코드를 구성 단계에서 강제하기 쉬운 툴체인도 고려 대상이었다.

실제 작업은 두 갈래로 진행됐다. 하나는 TUI 관련 코드를 런타임에서 떼어내 SDK의 공개 표면 위에만 계층화하는 일이다. 아직 CLI가 런타임 내부를 직접 호출하는 지점이 남아 있어 이 분리는 계속 진행 중이다. 다른 하나는 런타임 레이어를 100% Rust로 옮겨, C ABI를 노출하는 순수 네이티브 바이너리로 만드는 일이다.

개발자 입장에서 가장 직접적인 변화는 임베딩 방식이다. SDK 소비자는 더 이상 Node 프로세스를 별도로 띄울 필요 없이 런타임을 인프로세스로 품을 수 있게 됐다. 시작 시간, 메모리 사용량, 처리량이 모두 개선되고, 배포 시 감독해야 할 프로세스 수도 줄어든다. 다만 SDK 버전에 따라 동작이 달라질 수 있으므로 마이그레이션 노트를 확인하고, CLI가 아직 런타임 내부 API를 직접 호출하는 영역이 남아 있다는 점은 염두에 두는 편이 좋다.

원문은 이 선택이 모든 대형 TypeScript 프로젝트를 Rust로 바꿔야 한다는 주장은 아니라고 선을 긋는다. 목표 언어는 애플리케이션마다 달라질 수 있다. Rust를 택한 대가도 있었다. 수명과 공유 상태를 명시적으로 표현해야 했고, 그 과정에서 라이프사이클 관련 회귀가 나타나기도 했다. TUI를 SDK 공개 표면으로 완전히 옮기는 작업 역시 아직 끝나지 않았다.