GitHub의 Copilot Rust 재작성: AI 에이전트 마이그레이션 교훈

요약: GitHub가 Copilot 런타임을 Rust로 다시 만들다

GitHub는 GitHub Copilot을 지원하는 에이전트 런타임을 TypeScript와 Node.js에서 Rust로 이전했다고 밝혔습니다. 80만 줄이 넘는 운영 코드의 대부분은 AI 에이전트가 작성했지만, 설계와 검토, 테스트, 회귀 수정은 개발자가 맡았습니다. 작업은 수개월 동안 128개의 pull request로 나누어 병합되었고, 그동안 Copilot 기능도 계속 출시되었습니다. 핵심 교훈은 모든 JavaScript를 Rust로 바꾸라는 것이 아닙니다. 명확한 경계, 작은 변경, 자동 검증, 사람의 설계 책임이 대규모 이전을 안전하게 만든다는 점입니다.

런타임에서 달라진 점

이 런타임은 Copilot CLI, 앱, SDK, 클라우드 에이전트와 코드 리뷰를 지원합니다. 이전에는 TypeScript CLI가 별도 프로세스로 실행되어 SDK가 Node.js와 V8을 시작하고 JSON-RPC로 통신해야 했습니다. 통합마다 시작 시간, 메모리, 프로세스 경계 비용이 생겼습니다. 새 구조는 터미널 UI와 런타임을 분리하고 프로세스 내부 또는 외부 실행을 선택하게 합니다.

Rust는 낮은 시작 비용, 예측 가능한 메모리, 동시성, 임베딩, 그리고 C#, TypeScript, Python, Go, Java, Rust SDK와의 상호 운용성을 위해 선택되었습니다. GitHub 측정에서 클라이언트와 세션을 만들고 한 번의 작업을 수행한 뒤 정리하는 시간은 프로세스 내부에서 5.25초에서 55.3밀리초가 되었습니다. 처리량은 초당 7.55세션에서 120세션으로, 10개 클라이언트의 메모리는 1,383MB에서 126MB로 줄었습니다. 이는 GitHub의 작업 부하에 대한 측정이지 모든 이전의 보장은 아닙니다.

AI 에이전트가 도움이 된 이유

에이전트는 반복적인 변환과 구현을 수행했고, 개발자는 목표를 정하고 diff를 검토하며 빌드를 실행하고 실패를 분석했습니다. 작업은 세션과 하위 에이전트로 나뉘었고 빌드 자원이 검증의 관문이 되었습니다.

이 구분은 중요합니다. 에이전트는 패턴을 빠르게 바꾸지만 공개 계약, 위험한 경쟁 조건, 고객에게 중요한 호환성을 혼자 판단하지 못합니다. 사람은 불변 조건, 순서, 인터페이스와 완성도를 관리합니다. Rust와 TypeScript 사이의 임시 연결 계층도 사용되어 각 단계를 검토하고 출시하고 되돌릴 수 있었습니다.

AI 지원 이전 체크리스트

1. 경계를 먼저 그립니다. UI, 런타임, 저장소, 네트워크, FFI를 구분합니다.
2. 동작 테스트를 작성합니다. 타입뿐 아니라 외부 동작을 보존합니다.
3. 작게 이전합니다. 매 단계에서 빌드와 롤백을 유지합니다.
4. 에이전트 작업을 제한합니다. 한 번에 하나의 모듈이나 테스트 묶음만 요청합니다.
5. 검증을 관문으로 만듭니다. 컴파일, 테스트, diff와 자원 사용량을 확인합니다.
6. 임시 인터페이스를 추적합니다. 담당자와 제거 조건을 정합니다.
7. 실제 부하를 측정합니다. 시작 시간, 메모리, 지연, 처리량, 장애를 비교합니다.

개발, 테스트와 자동화 도구를 찾는다면 BTTC 소프트웨어 카탈로그를 참고할 수 있습니다. 도구는 검토를 대신하지 않지만 피드백을 빠르게 합니다.

자주 묻는 질문

Rust 코드를 모두 AI가 작성했나요? GitHub에 따르면 대부분은 에이전트가 작성했지만 사람이 지시하고 검토하고 테스트하고 수정했습니다.

왜 Rust를 선택했나요? 낮은 오버헤드, 예측 가능한 메모리, 네이티브 임베딩, 동시성과 SDK 상호 운용성이 목표였습니다.

모든 TypeScript를 이전해야 하나요? 아닙니다. 성능과 임베딩의 이점이 이전 및 유지보수 비용을 정당화할 때만 검토해야 합니다.

가장 transferable한 교훈은 무엇인가요? 작은 변경, 자동 테스트, 사람의 검토와 현실적인 벤치마크를 통제된 순환으로 묶는 것입니다.

결론

Copilot 런타임 사례는 AI 에이전트가 큰 이전을 빠르게 해도 엔지니어링 책임을 없애지 않는다는 것을 보여줍니다. 계약을 정의하고 작업을 제한하며 변경마다 검증하고 실제 부하로 측정하는 단계적 방식이 가장 재사용하기 좋은 출발점입니다.

운영에서 추가로 확인할 항목

대규모 이전에서는 첫 컴파일 성공을 최종 결과로 보면 안 됩니다. 패키지 크기, 시작 설정, 로그, 충돌 보고, 모니터링과 배포 절차까지 확인해야 합니다. 언어를 바꾸면 메모리 사용량은 좋아질 수 있지만 바인딩과 배포의 복잡성이 커질 수 있습니다. 따라서 이전 전에 성공 조건을 수치로 정하고 같은 벤치마크를 계속 반복해야 합니다.

검토자는 생성된 코드가 기존 계약을 보존하는지 확인해야 합니다. 이름이 같아도 오류 종류, 취소 동작, 타임아웃, 스레드 안전성 또는 파일 처리 방식이 달라지면 사용자가 영향을 받습니다. 테스트가 통과한 변경도 실제 부하, 예외 상황, 오래된 클라이언트와 여러 플랫폼에서 확인해야 합니다. AI 에이전트에는 명확한 입력, 제한된 권한과 검증 가능한 출력을 제공해야 합니다.

GitHub의 방식에서 얻는 또 다른 교훈은 이전을 한 번의 거대한 전환으로 만들지 않는 것입니다. 임시 연결 계층을 두고 기능을 하나씩 전환하며 문제가 생기면 작은 diff를 되돌립니다. 팀은 각 계층의 담당자, 제거 예정일과 호환성 기한을 기록해야 합니다. 이 기록이 있으면 AI가 생성한 많은 변경도 추적할 수 있습니다. 그 결과 속도와 안전성을 함께 달성하기 쉬워집니다.

운영에서 추가로 확인할 항목

대규모 이전에서는 첫 컴파일 성공을 최종 결과로 보면 안 됩니다. 패키지 크기, 시작 설정, 로그, 충돌 보고, 모니터링과 배포 절차까지 확인해야 합니다. 언어를 바꾸면 메모리 사용량은 좋아질 수 있지만 바인딩과 배포의 복잡성이 커질 수 있습니다. 따라서 이전 전에 성공 조건을 수치로 정하고 같은 벤치마크를 계속 반복해야 합니다.

검토자는 생성된 코드가 기존 계약을 보존하는지 확인해야 합니다. 이름이 같아도 오류 종류, 취소 동작, 타임아웃, 스레드 안전성 또는 파일 처리 방식이 달라지면 사용자가 영향을 받습니다. 테스트가 통과한 변경도 실제 부하, 예외 상황, 오래된 클라이언트와 여러 플랫폼에서 확인해야 합니다. AI 에이전트에는 명확한 입력, 제한된 권한과 검증 가능한 출력을 제공해야 합니다.

GitHub의 방식에서 얻는 또 다른 교훈은 이전을 한 번의 거대한 전환으로 만들지 않는 것입니다. 임시 연결 계층을 두고 기능을 하나씩 전환하며 문제가 생기면 작은 diff를 되돌립니다. 팀은 각 계층의 담당자, 제거 예정일과 호환성 기한을 기록해야 합니다. 이 기록이 있으면 AI가 생성한 많은 변경도 추적할 수 있습니다. 그 결과 속도와 안전성을 함께 달성하기 쉬워집니다.