GitHub는 2026년 9월 16일 블로그에서 Copilot 런타임을 TypeScript에서 Rust로 옮긴 작업을 공개했습니다. 이 런타임은 Copilot CLI, Copilot 앱, Copilot SDK의 기반입니다. 소개 글이 많이 퍼진 것은 최근이지만, 원문의 발표일은 9월입니다.

이 글은 원문에 적힌 내용을 근거로 삼습니다. 원문에는 성능 수치가 거의 없어서, 그 부분은 원문이 말하는 범위까지만 다룹니다.

문제: 런타임이 CLI의 TUI에 묶여 있었다

원문의 설명을 요약하면 구조는 이렇습니다.

  • CLI의 TUI와 런타임이 긴밀하게 얽혀 있었습니다.
  • 그래서 SDK는 CLI를 서브프로세스로 띄우고 통신하는 방식으로 위에 얹혀 있었습니다. 원문은 이를 "함수를 호출하기 위해서만 강제된 프로세스 간 통신"이라고 표현합니다.
  • SDK를 쓰는 쪽은 Node.js 또는 번들된 V8을 함께 배포하거나 찾아야 했습니다. 원문은 C#, Python, Go, Java, Rust SDK가 클라이언트마다 "최소 약 100MB 규모의 작업 메모리에 해당하는 두 번째 언어 런타임"을 지불했다고 적고 있습니다. 이 100MB는 추정치로 표시되어 있으며 측정 조건은 제시되지 않았습니다.
  • Node 프로세스가 충돌하면 세션 전체가 끊길 수 있었고, 배포 환경에서는 두 프로세스를 감독해야 했습니다.

목표는 TUI와 분리되고, 오버헤드가 낮으며, 프로세스 안에 임베드할 수 있고, 여섯 개 SDK 언어에서 쓸 수 있는 C ABI를 제공하는 런타임이었습니다.

방식: 병렬로 다시 쓰지 않고 모듈을 하나씩 교체

원문에 따르면 작업 일정은 다음과 같습니다.

  • 2026년 5월 초에 이전 계획을 세웠습니다.
  • 5월 12일부터 8월 21일까지 이전 PR이 main에 병합되었습니다. 원문은 약 14.5주의 기간이라고 적습니다.
  • 8월 21일에 런타임이 완전히 Rust로 바뀌었습니다.
  • 그 기간에 main은 릴리스 135개(정식 35개, 프리릴리스 100개)를 냈습니다.

즉 런타임을 멈추지 않고 제품을 계속 배포하면서 바꾼 것입니다. 이 방식이 가능했던 이유는 TypeScript 모듈을 하나씩 Rust로 대체해 나갔기 때문입니다.

규모: 원문이 밝힌 숫자

항목 원문 수치
최종 프로덕션 Rust 코드 832,378줄
Rust 단위 테스트 468,689줄
TypeScript E2E 테스트 174,675줄
이전 과정을 거친 TypeScript 프로덕션 코드 약 430,000줄 (초기 추정은 약 130,000줄)
main에 병합된 PR 128개

이 표에서 눈여겨볼 점은 테스트 코드의 양입니다. 재작성 대상 코드와 맞먹는 규모의 테스트가 있어야 기능 동등성을 주장할 수 있습니다. 원문도 AI 보조 도구를 활용해 작업했다고 밝히고 있으므로, 생성된 코드를 검증하는 비용이 얼마나 들었는지는 이 표만으로는 알 수 없습니다.

성능 주장은 어디까지 검증되었나

원문의 성능 관련 문장은 "런타임 성능이 몇 배수준으로 좋아졌다(orders of magnitude)"는 한 줄이 전부입니다. 기준 상태, 워크로드, 하드웨어, 측정 방법은 제시되지 않았습니다.

2차 보도에는 시작 시간 5.25초에서 292밀리초로, 여러 클라이언트 배치의 메모리가 1,383MB에서 126MB로 줄었다는 수치가 나옵니다. 이 글을 쓰면서 확인한 원문에서는 이 수치를 찾지 못했습니다. 따라서 이 글은 해당 수치를 사실로 인용하지 않습니다. 인용하려면 원문 또는 공개 벤치마크 자료를 먼저 확인해야 합니다.

실무 개발자가 가져갈 판단 기준

이 사례는 Copilot을 쓰는 사람보다 SDK나 CLI 런타임을 만드는 사람에게 더 직접적인 교훈을 줍니다.

  • 프로세스 구조가 기능에 영향을 줍니다. 함수 호출이 IPC를 거치면 지연과 장애 지점이 함께 늘어납니다. 임베드 가능한 런타임은 이 문제를 줄입니다.
  • 언어 런타임은 배포 비용입니다. SDK를 여러 언어로 제공할 때 각 클라이언트가 런타임을 함께 배포해야 한다면, 설치 크기와 보안 패치 부담이 커집니다.
  • 점진적 교체에는 테스트 자산이 필요합니다. 모듈을 하나씩 바꾸려면 교체 전후의 동작을 같은 테스트로 비교할 수 있어야 합니다.

자신의 프로젝트에서 같은 종류의 이전을 검토한다면, 시작 시간, 프로세스 수, RSS 메모리, 충돌 격리 여부, 배포 바이너리 크기를 교체 전과 후에 같은 조건으로 측정하는 것이 우선입니다.

한계

  • 근거는 GitHub 자사 블로그 글입니다. 독립된 제3자 벤치마크를 확인하지 못했습니다.
  • 런타임은 Copilot 제품의 내부 구조이므로, 외부 개발자가 같은 조건으로 재현할 수 없습니다.
  • 코드 줄 수는 생산성이나 품질을 말해주지 않습니다. 줄 수가 많다고 더 좋은 구현이라는 뜻이 아닙니다.
  • 원문은 이전 과정의 실패 사례나 되돌린 변경을 자세히 다루지 않았습니다.

결론

이 사례에서 가장 실용적인 부분은 "Rust가 빠르다"는 주장보다 구조 변경의 순서입니다. 제품 구조(TUI와 런타임의 결합)를 먼저 분리하고, 모듈을 하나씩 교체하고, 그동안 릴리스를 멈추지 않았습니다. 성능 수치는 원문에 없으므로 독자가 직접 확인해야 합니다. 같은 고민이 있다면, 언어를 바꾸기 전에 프로세스 경계와 배포 단위를 먼저 측정해 보시길 권합니다.

참고