핵심 요약
AI 요약
기사 목차 펼치기 / 접기
AI 코딩 도구가 자신의 심장부인 실행 엔진을 직접 다시 썼다. 깃허브(GitHub)와 번(Bun)의 런타임 전환 기록에는 극단적인 성능과 안정성을 확보하려는 시스템 요구, 그리고 AI가 극적으로 낮춘 코드 재작성 비용이 맞물려 있다.
운영 중단 없는 엔진 교체, 83만 줄을 다시 쓴 코파일럿
깃허브가 지난 9월 16일 공개한 공식 엔지니어링 리포트의 주인공은 코파일럿(Copilot)의 핵심 실행 엔진이다. 전체 코드 대부분은 AI 에이전트가 작성했으며, 프로젝트를 전담한 엔지니어 1명이 팀의 전폭적인 지원을 받아 수개월간 전환을 이끌었다. 8월 21일 기준 실전에 투입된 운영 코드는 무려 83만2378줄에 달했다. 사람의 코드를 고쳐주던 AI가 이제 자신의 작동 기반까지 재구축한 상징적 사건이다.
기존 엔진은 타입스크립트(TypeScript)로 작성돼 노드(Node.js) 런타임 환경에서 실행됐다. 문제는 파이썬(Python)이나 C++ 등 다른 프로그래밍 언어로 개발된 도구에 코파일럿 기능을 붙일 때마다 무거운 Node.js 런타임을 통째로 함께 패키징해야 했다는 점이다. 깃허브 개발팀은 프로세스 간 통신 오버헤드와 메모리 점유율을 획기적으로 줄이고, 엔진 자체를 이종 프로그램 안에 가볍게 직접 내장(Embedding)할 수 있는 대안을 찾아야 했다.
러스트(Rust)는 런타임에 메모리 정리를 전담하는 가비지 컬렉터(GC) 없이, 독창적인 소유권(Ownership) 규칙으로 메모리 생명주기를 직접 통제한다. 컴파일러는 바이너리 실행 파일을 생성하기 전에 이 엄격한 규칙을 사전 검증한다. 깃허브가 절실히 원했던 최소한의 시스템 자원 소모와 뛰어난 언어 간 호환성이라는 두 마리 토끼를 완벽히 충족하는 선택지였다.
엔진 교체는 상용 서비스 개발을 중단하지 않은 채 점진적으로 단행됐다. 미세한 모듈 단위부터 러스트로 변환한 뒤 레거시 코드를 제거하는 방식을 취했으며, 전체 작업은 총 128개의 정밀한 풀 리퀘스트(PR)로 나뉘어 안전하게 배포됐다. 웹 인터페이스 전체를 갈아엎은 것이 아니라, 전 세계 수백만 개발자가 의존하는 코파일럿의 런타임 엔진을 교체한 것이다.
코드를 고쳐주던 도구가 자신의 기반까지 다시 짰다.
반복되는 메모리 누수와 1년짜리 재작성의 딜레마
그보다 앞선 지난 7월, 번의 창업자이자 수석 개발자인 재러드 섬너(Jarred Sumner) 역시 러스트 전환 공식 회고록을 공개했다. 번은 자바스크립트와 타입스크립트 생태계의 초고속 대안 런타임으로, 앤트로픽의 개발 도구인 클로드 코드(Claude Code) 내부 엔진으로도 채택됐으며 원래 핵심 구현 언어는 지그(Zig)였다.
섬너가 회고록 서두에 나열한 것은 화려한 신기술이 아닌 고질적인 메모리 결함 목록이었다. 이미 메모리에서 해제된 주소에 접근해 프로세스가 뻗어버리는 유즈 애프터 프리(Use-After-Free) 현상과, 예외 처리 도중 메모리를 반환하지 못해 발생하는 자원 누수가 반복됐다. 번 개발진은 정적 분석 도구와 수많은 테스트를 상시 가동했지만, 유사한 메모리 오염 버그는 끝없이 재발했다.
러스트는 데이터의 소유권과 참조 대여(Borrowing) 유효 범위를 컴파일러 규칙으로 강제해 이러한 메모리 결함을 빌드 시점에 원천 차단한다. 물론 하드웨어 직접 제어나 성능 최적화를 위해 컴파일러 검사를 우회하는 언세이프(Unsafe) 블록이 존재하는 만큼 모든 구현이 저절로 무결해지는 것은 아니지만, 언어 차원의 안정성 안전망은 차원이 다르다.
문제는 천문학적인 전환 비용이었다. 섬너는 기존의 수작업 엔지니어링 방식이었다면 코드베이스에 정통한 시니어 개발자 3명이 달라붙어 최소 1년을 온전히 투입해야 했을 것으로 추산했다. 그 기간 동안 기능 개선과 보안 패치 역량이 동결될 수밖에 없기에, AI가 없었다면 버그를 계속 땜질하며 버티는 쪽을 택했을 것이라는 고백이 이어졌다.
알면서도 손대지 못했던 1년짜리 장벽이 무너졌다.
까다로운 규칙이 작업 지시서로… 64개 클로드가 넘은 컴파일의 벽
섬너는 클로드 코드에 작업을 모듈별로 쪼개 위임했다. 기존 지그 코드를 러스트로 변환하는 정밀 아키텍처 지침을 작성하고, 한 AI 에이전트가 코드를 작성하면 다른 AI 에이전트가 이를 교차 검증하는 다중 파이프라인을 구축했다. 개발자는 그 실행 결과를 분석하며 작업 프롬프트와 아키텍처 설계를 지속해서 튜닝했다.
전환 과정이 순탄했던 것만은 아니다. 방대한 코드를 분할하고 패키지 의존성을 정리하는 순간 컴파일 에러만 무려 1만6000여 건이 한꺼번에 쏟아져 나왔다. 개발팀은 이 에러 로그를 모듈별로 구조화해 분배한 뒤, 최대 64개의 클로드 세션을 동시 가동해 자동 수정과 검토 루프를 병렬로 돌렸다.
여기서 러스트의 악명 높은 까다로움이 완전히 새로운 강점으로 변모했다.
인간 개발자에게는 진입 장벽이었던 깐깐한 컴파일러 규칙이, AI 에이전트에게는 더없이 명확하고 기계적인 작업 지시서가 된 것이다. 컴파일러가 오류의 정확한 위치와 원인을 짚어주면 AI는 즉각 코드를 수정해 다시 제출할 수 있다. 코드 생성 속도가 기하급수적으로 빨라질수록 결함을 걸러내는 결정론적 검증 장치의 가치는 더욱 빛을 발한다.
집중 전환 작업은 단 11일 만에 완결됐으며, 기존 테스트 스위트를 단 하나도 누락하거나 생략하지 않고 모두 통과했다. 러스트 엔진을 정식 탑재한 번 1.4 버전은 지난 8월 20일 공식 배포됐다.
깃허브 역시 과거 방식이었다면 팀 전체가 1~2년을 매달려야 했을 거대 런타임 재작성 프로젝트를 단 수개월 만에 성공시켰다고 자평했다. 물론 두 회사의 비교 수치가 엄격한 대조군 실험 결과는 아니지만, 개발자가 엄두조차 내지 못했던 대규모 시스템 재작성이 AI 협업을 통해 현실의 프로덕션 배포로 이어진 역사적 기록이다.
컴파일 통과가 만능은 아니다, 논리 결함과 언어 선택의 본질
하지만 컴파일 통과가 곧 소프트웨어의 완전무결성을 보장하지는 않는다. 공식 기술 백서와 개발 일지의 부록(Appendix)에 명시된 한계점과 실패 케이스를 살펴보면 자가 교정의 명암이 드러난다. 앤트로픽은 공식 기술 분석을 통해 번이 단위 테스트를 모두 통과한 이후에도, 메인 브랜치 병합 과정에서 기존 동작을 깨뜨린 퇴행 결함 19건이 발견돼 추가 수정 작업을 거쳤다고 밝혔다. 깃허브 역시 9월 14일까지 런타임 전환에 따른 수십 건의 잠재 결함을 추적해 해결했다. 두 회사의 오류 집계는 측정 기간과 분류 기준이 달라 단순 오류율로 직접 대조할 수는 없지만, 컴파일러가 잡아내지 못하는 사각지대를 명확히 보여준다.
실제로 깃허브에서는 작업 완료 플래그가 기록됐음에도 런타임 상태 객체에 제때 반영되지 않아 AI 에이전트가 무한 루프를 돌며 연산을 지속했던 상태 불일치 실패 케이스가 보고되기도 했다. 메모리를 아무리 안전하게 다뤄도 엉뚱한 비즈니스 로직을 수행하는 프로그램은 얼마든지 존재한다. 컴파일러는 개발자가 의도한 핵심 기능의 누락 여부나 비즈니스 룰의 위반까지는 판별하지 못한다.
단위 경제학(Unit Economics) 측면에서도 실리콘밸리 시니어 시스템 엔지니어 3명의 1년 치 인건비(통상 연간 150만달러 안팎)와 11일간 투입된 수천 달러 수준의 AI API 추론 비용을 대조하면 전환 장벽이 붕괴했음을 체감할 수 있다. 다만 확인된 사실과 마케팅 수사를 엄격히 분리할 필요가 있다. 두 프로젝트 모두 전환 이후에도 지속적인 최적화와 결함 추적이 수개월간 병행됐으며, “11일 만에 완벽한 시스템이 완성됐다”는 식의 홍보성 주장은 현장의 복잡성을 지나치게 단순화한 평가다.
모든 시스템이 러스트를 정답으로 택하는 것도 아니다. 마이크로소프트(MS)는 차세대 타입스크립트 컴파일러 포팅 과정에서 러스트와 C++을 다각도로 검토한 끝에 Go(Golang)를 최종 채택했다. 기존 자바스크립트 특유의 가비지 컬렉션 구조와 추상 구문 트리(AST) 메모리 모델을 1:1에 가깝게 보존하고 개발 생산성을 유지하는 것이 러스트의 까다로운 소유권 모델보다 유리하다는 현실적 판단이었다. AI가 재작성을 전폭 지원하더라도 시스템의 본질적 목적에 부합하는 도구를 고르는 안목은 여전히 인간 엔지니어의 몫이다.
컴파일러가 메모리를 지켜도 아키텍처는 사람이 결정한다.
추천 알고리즘에서 GPU 커널까지, AI 인프라의 척추가 된 러스트
러스트의 영토 확장은 단순한 개발 도구를 넘어 AI 핵심 인프라 전반으로 가속화되고 있다. 일론 머스크의 xAI가 오픈소스로 공개한 X 추천 알고리즘에서 핵심 랭킹 모델 피닉스(Phoenix)는 고속 수치 연산에 JAX를 쓰고, 대규모 실시간 트래픽을 처리하는 서빙 계층에는 러스트를 결합했다. 엔비디아 역시 대규모 분산 GPU 추론 프레임워크인 다이나모(Dynamo)의 아키텍처를 성능을 위한 러스트와 모델 확장성을 위한 파이썬의 결합으로 구현했다.
나아가 엔비디아는 지난 9월 8일 공식 기술 블로그를 통해 GPU 내부에서 실행되는 연산 커널 자체를 러스트로 작성하는 차세대 개발 툴체인인 쿠다-옥사이드(cuda-oxide)와 큐타일-rs(cutile-rs)를 전격 공개했다. 러스트에서 C++ 기반 쿠다 커널을 단순히 호출하는 차원을 넘어, GPU 하드웨어 연산 자체를 메모리 안전한 러스트 문법으로 직접 컴파일하겠다는 야심 찬 시도다. 다만 엔비디아는 두 프로젝트 모두 연구 초기 단계로 프로덕션 환경 투입에는 시간이 필요하다고 선을 그었다.
클라우드플레어(Cloudflare)가 하루 수조 건의 웹 트래픽을 처리하던 NGINX 기반 프록시를 대체하기 위해 핑고라(Pingora)를 러스트로 개발해 공개한 것이 2022년의 일이다. 극단적인 성능과 안정성을 이유로 러스트를 선택해 온 역사는 최근의 AI 열풍보다 훨씬 길다. 다만 지금의 거대한 전환 흐름은 러스트 본연의 기술적 우수성에 AI가 제공하는 강력한 자동화 레버리지가 더해지며 한층 탄력을 받고 있다.
다시 깃허브의 엔지니어링 일지로 돌아오면, 결론부에는 중요한 과제가 남아 있다. AI가 타입스크립트의 기존 클래스·객체 구조를 기계적으로 옮겨놓은 잔재를 러스트 고유의 데이터 소유권과 경량 동시성(Concurrency) 모델에 맞게 근본적으로 리팩터링하고 메모리 프로파일을 최적화하는 일이다.
언어를 옮긴 엔지니어들의 작업 목록은 아직 끝나지 않았다.
