마침내 TypeScript를 Rust로 포팅했다

URL: https://www.youtube.com/watch?v=ND_kRgU_WlY 날짜: 2026-10-10 채널: t3dotgg

---

📌 핵심 질문 / 이 프로젝트가 던지는 핵심 논점

==TypeScript의 컴파일러·타입 체커·LSP를 Go를 거쳐 Rust로 옮기면, 단순한 속도 개선을 넘어 에이전트가 V8 isolate 안에서 완전한 TypeScript 개발 루프를 실행할 수 있는가?==

• TSC RS(TS Rust)는 TypeScript 6보다 12.5배, Microsoft의 TypeScript 7(TSGO)보다 약 2배 빠르다.
• Go 버전을 한 줄씩 Rust로 옮기는 중간 경로를 택했기 때문에, JavaScript에서 Rust로 바로 번역할 때 생기는 의미 차이와 호환성 문제를 피했다.
• Rust와 WebAssembly(WASM)의 조합은 가비지 컬렉션(Garbage Collection)과 운영체제 수준의 VM을 제거해, 에이전트·앱·컴파일러를 수백 MB 이하의 V8 isolate에 함께 넣을 가능성을 연다.

TypeScript를 JavaScript로 지우는 일 자체는 쉽지만, JavaScript의 기묘함을 충실히 반영하는 타입 검사(Type Checking)는 훨씬 어렵고 느리다. Rust 포트의 가장 큰 가치는 빠른 TSC 대체품 자체보다도, 파일 시스템·Docker·전용 VM 없이 브라우저와 Cloudflare 같은 V8 환경에서 에이전트가 코드를 만들고 실행하는 새로운 개발 인프라에 있다.

1. 불가능해 보였던 포트와 완성 결과

1.1. 출발점과 극적인 비용 차이

1. TSC RS의 범위

   1. 대상 컴포넌트: TypeScript 컴파일러(Compiler), 타입 체커(Type Checker), 언어 서버 프로토콜(Language Server Protocol, LSP)을 모두 Rust로 다시 작성했다.
   2. 개발 방식: 에이전트들이 약 5개월 동안 작업했으며, 완성된 코드의 한 줄도 직접 읽지 않은 상태에서 테스트·목표·환경을 관리했다.

2. 두 번의 시도

   1. 실패한 대규모 시도: Codex 토큰에 약 40만 달러를 소모했지만 대략 84% 호환성에서 멈췄다. 남은 16%는 가장 복잡한 경계 사례라서 호환성이 100%에 가까워질수록 난도가 급격히 높아졌다.
   2. 성공한 시도: Opus 5.5에 약 2만 달러 상당의 사용량을 투입했고, 두 주 만에 실제 npm 패키지로 배포 가능한 결과에 도달했다. 첫 시도와 성공 시도를 합쳐 도입부에서 약 42만 달러의 토큰 비용을 강조했지만, 실제 성공 작업은 구독으로 보조되어 체감 비용이 훨씬 낮았다.

1.2. 성능과 호환성의 결과

1. 비교 기준

   1. TSC 6: TypeScript와 JavaScript로 작성된 마지막 공식 버전이며, TSC RS가 약 12.5배 빠르다.
   2. TSGO/TSC 7: Microsoft가 Go로 다시 만든 공식 차세대 버전이며, TSC RS가 약 2배 빠르다.
   3. Bun check: Rust로 작성한 Bun의 TypeScript checker는 TSC RS보다도 빠른 경우가 많지만, 아래의 충실도와 통합 검사에는 중요한 차이가 있다.

2. 실제 호환성

   1. 드롭인 대체품: TSGO와 TSC 7을 거의 100% 대체하는 것을 목표로 했고, npm에서 실제로 사용할 수 있는 패키지로 공개됐다.
   2. 버그의 상속: 지금까지 열린 이슈는 한때 5개에서 4개로 줄었고, 전체 6개 이슈를 감사한 결과 TSC RS 고유 문제는 1개뿐이었다. 나머지 5개는 목표 버전인 TSC 7 자체에 존재하던 버그가 Rust 버전에도 그대로 재현된 것이다. 의도한 동작뿐 아니라 원본의 버그까지 포팅한 셈이다.

2. TypeScript 컴파일러가 어려운 이유

2.1. 변환과 타입 검사의 분리

1. TypeScript의 기본 역할

   1. 브라우저의 한계: 브라우저와 Node.js 같은 JavaScript 런타임은 TypeScript의 타입 문법을 이해하지 못한다.
   2. 간단한 제거: function logUser(user: { name: string }) { console.log(user.name) } 같은 코드에서 타입 선언을 제거하면 실행 가능한 JavaScript가 된다. TypeScript를 JavaScript로 바꾸는 변환은 본질적으로 타입 표식을 잘라내는 작업이어서, 경계적인 의미의 컴파일은 쉽다.

2. ESBuild가 해결한 문제

   1. 빠른 개발 루프: Figma CTO였던 Evan Wallace가 편집기에서 변경한 파일을 UI에 빠르게 반영하려고 Go 기반 ESBuild를 만들었다.
   2. 번들링: ESBuild는 타입 제거뿐 아니라 CSS와 각종 자산을 묶고, 흩어진 파일을 브라우저가 받을 하나의 산출물로 만드는 일까지 처리했다.
   3. 남은 병목: 실제 타입이 올바르게 사용됐는지 검사하는 작업은 ESBuild가 제공하지 않는다. 그래서 대형 코드베이스는 브라우저에 결과를 보내는 변환 경로와 타입을 검증하는 경로를 분리한다.

3. 개발 현장의 체감

   1. Twitch 사례: 과거 개발 명령이 시작되는 데 2분, 파일을 저장한 뒤 브라우저에 반영되는 데 30초에서 1분이 걸렸다.
   2. 분리의 효과: 타입 검사를 브라우저 반영 경로에서 분리해 반영 시간을 5초 아래로 낮췄고, ESBuild는 이 핫 리로드(hot reload)를 더 빠르게 만들었다. 대신 빠른 변환만으로는 타입 검사가 제대로 끝났는지 알 수 없다.

2.2. JavaScript의 기묘함을 옮기는 일

1. 타입 시스템의 복잡성

   1. Turing complete: TypeScript 타입 시스템은 튜링 완전(Turing complete)하고 유연하다. 한 지인은 TypeScript 언어가 아니라 TypeScript 타입만 사용해 Doom 전체를 포팅했다.
   2. JavaScript 표현력의 대가: 실행 중 변수의 타입을 바꾸는 방식, 객체의 상속과 프로토타입(prototype) 체계, 런타임의 온갖 예외를 TypeScript 타입 시스템이 표현해야 한다.

2. 동일 언어가 주는 이점

   1. 직접 포트의 어려움: JavaScript의 의미를 다른 언어로 옮기면 원래 언어의 이상한 동작을 모두 다시 인코딩해야 한다. 영어의 작동 방식을 영어로 설명하는 일이 스페인어로 설명하는 것보다 쉬운 것과 같으며, 이 복잡성이 100배쯤 커진 상황이다.
   2. 초기 모델의 한계: GPT-5.6 Soul과 Astra를 포함한 초기 모델들은 JavaScript/TypeScript에서 Rust로 직접 옮기는 작업에서 크게 고전했다. TypeScript의 규모와 JavaScript의 의미를 동시에 보존하는 일이 단순 문법 변환이 아니기 때문이다.

3. Go를 거친 Rust 포트의 설계

3.1. Microsoft가 Go를 선택한 이유

1. Go의 적합성

   1. 동시성(Concurrency): Go routine과 동시성 기본 기능은 TypeScript 컴파일러의 여러 코어 활용에 적합하다. 채널에는 단점이 있지만 핵심 동시성 모델은 유용하다.
   2. JavaScript와 닮은 문법: Go의 문법은 JavaScript와 비교해 읽기 쉬워 두 언어의 대응 함수를 이해하기 좋다.
   3. 가비지 컬렉션: Go의 가장 큰 실용적 강점은 메모리 관리를 직접 하지 않아도 된다는 점이다. 작성자가 2024년 2월에 “JavaScript 빌드·개발 도구에는 Go가 아마 가장 맞는 언어”라고 썼다가, 3년 뒤 Rust로 몰려갈 것이라는 후속 예측이 틀린 방식으로 현실화됐다.

2. 가비지 컬렉션의 트레이드오프

   1. 지연 시간의 불확실성: Go의 가비지 컬렉터가 실행되면 평소 빠른 요청도 순간적으로 대기해 지연 시간이 튄다. 25밀리초 안에 모든 요청을 처리해야 하는 서버라면 이 특성이 문제가 된다.
   2. 긴 컴파일 작업의 평균 효과: 25밀리초 요청 1,000개 중 1개가 가비지 컬렉션 때문에 300밀리초가 되어도 전체 합계는 1% 미만만 느려진다. 거대한 앱을 수 초 또는 수 분 동안 컴파일하는 작업에서는 가비지 컬렉션이 수차례 발생해도 전체 시간에서 차지하는 비중이 작다.
   3. 결론: 초저지연 웹 서비스에는 Go가 항상 맞지 않지만, JavaScript로 작성되어 수 분 걸리는 작업을 줄이고 동시성을 높이는 컴파일러에는 Go가 훌륭한 선택이다. JavaScript와 TypeScript 자체도 가비지 컬렉션 언어라는 점은 동일하다.

3.2. Go에서 Rust로 가는 중간 다리

1. TSGO RS의 내부

   1. Go 표준 라이브러리 포팅: Opus는 Go 코드를 Rust다운 방식으로 재작성하지 않고, Go 포트의 각 줄을 충실하게 Rust로 번역했다. 그 결과 Go 표준 라이브러리를 담은 go_std가 생겼다.
   2. Go routine의 이식: runtime.rs에는 Go routine을 Rust로 옮긴 구현이 들어 있다. 이 구현은 Go의 동작을 충실히 흉내 내야 했기 때문에 초기 Rust 버전이 Go 버전보다 오히려 2~3배 느렸다.

2. 두 단계 포팅의 의미

   1. 더 좋은 출발점: Microsoft가 TypeScript의 모든 코드를 손으로 Go에 포팅한 뒤 Go에서 정제하고 빠르게 만든 덕분에, Go는 JavaScript보다 Rust 포트에 훨씬 좋은 중간 표현이 됐다.
   2. 에이전트의 역할: 에이전트는 Microsoft가 만든 Go 버전의 구조와 의미를 보존하면서 Rust로 옮겼고, 이후 “모든 방식에서 최소 2배 빠르게 만들라”는 목표를 받았다.

3. 성공 작업의 실제 비용

   1. API 환산 비용: Opus 5.5로 TS Rust를 처음부터 다시 시작한 작업은 정가 API 기준 약 2만 4천 달러다.
   2. 구독 사용량: 한 계정의 주간 한도 대비 925~983%를 사용했으며, 이는 Claude Code 구독 약 2개월 반에 해당한다.
   3. 실제 체감 비용: 무료 리셋을 포함하면 구독 사용량의 환산 비용은 약 500달러 정도다. TypeScript보다 메모리를 덜 쓰고 Go 버전보다 2배 빠른 컴파일러를 약 500달러에 얻었다는 점에서 비용 대비 가치가 높다.

4. 성능 검증과 두 가지 목적

4.1. 실사용 프로젝트에서의 비교

1. T3 Code와 Effect

   1. Effect의 특수성: Effect는 안정적인 동시성 시스템을 조합하기 위한 TypeScript 라이브러리이며, TypeScript를 매우 공격적으로 사용한다. 자체 TypeScript fork를 만들어 TypeScript 설정과 패키지에 패치를 적용해야 할 정도로 타입 검사 기능을 확장한다.
   2. 통합 구현: T3 Code가 의존하는 Effect 검사를 TS Rust에 직접 넣었다. 따라서 TSC 7의 Effect 플러그인보다 빠르고, Bun check 뒤에 Effect 검사를 추가로 돌리는 전체 시간보다 약 4배 빠르다. Bun check 단독이 느려서가 아니라 Bun에서도 별도 Effect 검사가 필요하기 때문이다.

2. 다른 코드베이스

   1. 검증 대상: tRPC 서버, Sentry, Excalidraw 전체 코드베이스와 Effect 저장소를 확인했다.
   2. 충실도 문제: Bun check는 Effect 코드베이스를 통과하지 못하거나 Sentry와 tRPC에서 잘못된 오류를 낸 사례가 있었다. 매우 빠르지만 대형 프로젝트에서 원본 TypeScript와 같은 판정을 내린다고 신뢰하기 어렵다.
   3. 속도 수치: TSC 6에서 TSC RS로 바꾸면 많은 프로젝트에서 13배 이상 빨라지고, Go 버전과 비교하면 보통 2배 빨라진다. 새 프로젝트를 Bun 도구 전체로 시작할 때는 유지보수 가능성을 더 높게 평가해 Bun을 권장하지만, 기존 TypeScript의 충실한 재현에는 TS Rust가 적합하다.

4.2. 속도보다 중요한 첫 번째 목적: 모델이 못 하던 일

1. 불가능의 기준점

   1. 오래된 논쟁: TypeScript를 C++ 같은 다른 언어로 한 달 안에 포팅할 수 있다는 주장과 온라인에서 논쟁했고, 그런 주장이 불가능하다고 말하다가 상대에게 차단당한 일도 있었다.
   2. 무제한 토큰 실험: 지금까지 LLM이 할 수 없는 일의 기준점으로 TypeScript 포트를 남겨 두었다. Anthropic 모델은 사용량을 너무 빨리 태울 것 같아 시도하지 않았지만, Opus 5.5가 사용량을 천천히 소모하자 실험을 시작했다.

2. 모델 능력의 변화

   1. 예상을 뛰어넘은 성공: 불가능하다고 생각했던 포트를 모델이 완성했고, 이제는 LLM에게 던질 “너무 큰” 엔지니어링 과제가 무엇인지 떠올리기 어려워졌다.
   2. 목표의 재정의: 성능 경쟁보다 “모델이 할 수 없다고 여긴 작업을 실제로 맡길 수 있는가”를 확인하는 실험이 먼저였다.

5. 두 번째 목적: V8 isolate 안의 에이전트 개발 환경

5.1. 추론 비용과 실행 컴퓨트의 역전

1. AI 비용 곡선

   1. 지능의 가격 하락: Artificial Analysis의 비용 효율 차트는 같은 지능 점수를 얻는 가격이 빠르게 내려가는 모습을 보여준다. 50점대에 처음 진입한 Opus 5는 작업당 5.86달러였지만, 같은 점수를 얻는 “61 Soul” 계열 모델은 32센트 수준으로 내려갔다고 설명했다.
   2. 감소 속도: 같은 수준의 지능 비용이 4개월 만에 약 10분의 1이 됐고, 연간 10배 하락은 보수적인 추정으로 제시됐다. 30점대 모델은 올해 2월 작업당 2.50달러에서 여름에는 약 0.30달러로 내려가 연환산 약 1,000배에 해당하는 급격한 감소를 보였다.

2. VM의 반대 곡선

   1. 에이전트가 필요한 자원: 모델 추론뿐 아니라 에이전트가 코드를 편집·실행·테스트할 VM, RAM, 파일 시스템, 터미널도 비용이 든다.
   2. Cursor Cloud 사례: Cursor의 클라우드 스레드는 실제 Linux 머신과 CPU를 가진 VM에서 실행되며, 32GB RAM이라고 기억하지만 16GB일 가능성도 언급했다. 네 개 스레드를 띄우면 128GB가 예약되는 구조이고 현재는 이 VM 사용료를 따로 받지 않는다.
   3. 비용 역전: 추론 비용은 연 10~100배씩 하락하는 반면 16~32GB 박스 임대료는 AI가 RAM 수요를 끌어올려 연 25~30%씩 오를 수 있다. 곧 한 시간 동안 모델을 실행하는 비용보다 모델이 실행되는 VM 비용이 더 비싸진다. Claude Cloud도 이미 클라우드 컴퓨트 크레딧을 구독자에게 제공하는 방식으로 바뀌었다.

3. 현재 에이전트 추상화의 한계

   1. 실제 시스템 의존: 에이전트는 터미널, Bash, ripgrep, 파일 검색·이동, Git, CPU 사용량 확인, 편집 도구를 사용할 수 있는 실제 Linux 또는 Mac 환경을 전제로 훈련된다.
   2. 샌드박스의 비용: 격리를 강하게 만들수록 추가 계층과 메모리가 필요해진다. 미래에는 에이전트가 저렴해져도 에이전트를 실행하고 코드를 시험할 환경이 병목이 될 수 있다.

5.2. Cloudflare와 V8의 효율적인 추상화

1. 전통적 호스팅과 Cloudflare의 차이

   1. VM·컨테이너 방식: AWS, Heroku, Hetzner, Vercel 같은 전통적 호스팅에서는 코드가 서버의 파일 시스템과 운영체제 위에서 Docker나 유사 계층을 거쳐 실행된다. 컨테이너마다 운영체제와 메모리 계층을 유지해야 한다.
   2. V8 isolate 방식: Cloudflare Workers는 요청이 들어올 때 코드를 저장소에서 가져와 V8(JavaScript 엔진) isolate에서 실행한 뒤 제거한다. Linux나 커널 전체가 아니라 Chrome 탭처럼 격리된 실행 영역을 공유하므로, 사용자 코드는 같은 Linux 인스턴스에서 서로 간섭하지 않고 실행된다.
   3. 저렴한 이유: Cloudflare가 마진을 포기해 싸게 파는 것이 아니라, 운영체제·VM 대신 V8 계층에서 가상화하기 때문에 RAM과 실행 자원이 실제로 적게 든다.

2. isolate의 제한

   1. 접근 불가 영역: 파일 시스템을 읽고 쓸 수 없고, 네이티브 코드를 실행하거나 커널을 호출할 수 없다. 전통적인 지속 서버와 다른 언어 실행도 어렵다.
   2. 적합한 시점: 빌드가 끝난 JavaScript를 실행하기에는 isolate가 훌륭하지만, 파일을 만들고 TypeScript를 컴파일하며 개발 서버를 띄우는 빌드 단계에는 맞지 않았다.

3. Just Bash가 만든 단서

   1. 가짜 Bash: Vercel의 Malte가 만든 Just Bash는 JavaScript 메모리 안에 가짜 파일 시스템·프로세스·Bash 명령을 구현해 에이전트가 실제 터미널에서 작업하는 것처럼 보이게 한다.
   2. 남은 퍼즐: 탐색용 가상 파일 시스템만으로는 실제 앱을 만들 수 없다. 타입 검사와 컴파일러가 필요하며, 기존 TSC나 TSGO는 isolate에 넣기 어렵다. Rust와 WASM은 이 조합에 적합하다.

5.3. V8 안에서 완성한 개발 루프

1. 시연된 구조

   1. 전체 구성: 한 모델에게 완전히 작동하는 앱을 만들게 하고, 에이전트·앱 실행·TypeScript 타입 검사·컴파일을 모두 하나의 V8 isolate 안에서 수행했다. 현재는 서버의 Node에서 돌지만 브라우저에서도 실행할 수 있다.
   2. 자원 사용량: 전체 사용량은 RAM 260MB 미만, CPU 피크 약 4%였다. 에이전트가 쓰는 컴퓨트와 앱이 실행되는 컴퓨트, 타입 검사·번들링에 필요한 자원을 모두 합친 수치다.

2. ESBuild 기반 버전과의 비교

   1. Astra의 선택: Astra가 만든 버전은 번들러로 ESBuild를 선택했고, 유휴 상태에서도 Go 기반 패키지와 더 큰 번들을 로드하느라 다른 버전보다 RAM을 2배 사용했다.
   2. Rust/WASM의 적합성: Go 기반 TSGO를 JavaScript/WASM으로 옮기면 가비지 컬렉션과 자원 오버헤드가 따라오지만, Rust는 WASM과 자연스럽게 결합되어 이 문제를 줄인다.

3. 시연의 본질

   1. 읽기 전용 파일 시스템: 서버의 파일 시스템을 읽기 전용으로 바꿔도 개발 루프가 그대로 실행된다. 앱과 에이전트가 호스트 파일을 변경하거나 V8 밖으로 나가지 않고 RAM 안에서만 동작하기 때문이다.
   2. Cloudflare 배포 가능성: Cloudflare, Chrome, Node는 모두 V8 isolate를 사용한다. 따라서 같은 구조를 Cloudflare Worker로 옮기면 수백 MB의 예약 RAM과 전용 CPU 없이 거의 비용을 들이지 않고 실행할 수 있다.
   3. 다른 서비스와의 차이: 단순히 Bolt를 다시 만든 것이 아니라, 파일 시스템이 없는 V8 안에서 파일·컴파일·검사·실행의 전체 개발 루프를 유지한 점이 핵심이다. 데이터베이스 회사의 임의 코드 실행 서비스와는 다른 문제를 해결한다.

5.4. 운영체제 계층과 이벤트 루프의 경제성

1. 전통적 계층

   1. 아래에서 위로: 하드웨어(CPU·RAM) 위에 드라이버, 커널, 운영체제, 파일 시스템, 애플리케이션이 쌓인다.
   2. Docker의 비용: Docker나 하이퍼바이저 계층은 운영체제 위에 추가 실행 환경을 만들며, 한 호스트에서 Ubuntu·Windows Server·Debian을 각각 실행하려면 각 계층이 RAM을 소비한다. 새 Docker 컨테이너가 새 Chrome 탭보다 훨씬 무거운 이유다.

2. Chrome/V8 계층

   1. isolate 공유: Chrome 안의 V8에는 여러 isolate가 있고 각 isolate는 다른 JavaScript 파일과 함수를 실행한다. 서로 허용된 경우에만 통신하고 서로의 상태를 침범하지 않는다.
   2. 오랜 최적화의 결과: Google은 웹을 매력적인 플랫폼으로 만들고 Google Earth 같은 Windows 전용 앱을 줄이려고 V8에 막대한 비용을 투자했다. 그 결과 Chrome 탭과 Cloudflare Workers가 운영체제·VM 계층보다 훨씬 효율적인 실행 단위를 얻었다.
   3. 명확한 한계: V8 isolate에는 커널·파일 시스템·네이티브 코드 권한이 없으므로, TypeScript Rust 같은 도구가 없으면 개발 자체를 수행하기 어렵다.

3. 공유 이벤트 루프

   1. 유휴 시간의 비용: 두 개의 vCPU를 가진 VM 두 대가 동시에 대기 중이면 네 개의 vCPU가 낭비된다. 반면 Cloudflare의 이벤트 루프는 코드가 대기할 때 CPU를 거의 사용하지 않는다.
   2. 토큰 단위 스케줄링: 에이전트가 추론 제공자의 다음 토큰을 기다리는 동안 CPU는 다른 앱이 쓴다. 토큰이 도착할 때만 다음 작업을 실행하고, 여러 앱이 스케줄러를 공유한다.
   3. 미래의 개발 방식: 추론 비용이 계속 하락하면 에이전트가 실행되는 시간 전체가 아니라 실제 토큰 처리 순간에만 비용을 내는 구조가 중요해진다. 에이전트 실행과 에이전트가 코드를 시험하는 환경을 모두 저렴하게 만들 수 있다.

6. 에이전트 오케스트레이션과 개발 방식의 변화

6.1. 프롬프트보다 환경을 관리한 작업

1. 실제로 사용한 지시

   1. 초기 지시: code-sandbox-ts에서 작업하게 하고 AGENTS.md, 타입 검사·책임성 파일, 16시간 실행 감사 노트를 먼저 읽게 했다. Cargo 작업 수를 설정 가능하게 만들고, 스크립트 상태를 추가하고, 작업을 분리하고, 더 많은 병렬 작업이 가능하도록 에이전시를 업데이트하게 했다.
   2. 계속 진행시키기: 현재 상태를 얻어 즉시 main 브랜치로 옮기고, 호환성과 성능을 계속 개선하라는 지시를 반복했다. 시스템 메모리가 부족해 Ultra Code가 Medium으로 내려가고 systemd가 계속 죽자 운영체제 수준에서 문제를 고친 뒤 Ultra Code를 다시 적용했다.
   3. 새 종료 조건: “Go 빌드보다 최소 2배 빠르게”를 명시하고, 그 상태에 도달할 때까지 반복하라고 했다. 목표가 단순히 호환성 완성으로 끝나지 않게 만들어 두 주 동안 계속 작업하게 했다.

2. 분산된 실행 환경

   1. 병렬성: 여러 워크플로와 서브에이전트가 항상 실행되도록 오케스트레이션해 독립적인 작업을 동시에 수행하게 했다.
   2. 외부 머신: 한 머신에서 컴퓨트가 부족해지자 보유한 다른 VPS인 Cup 2와 Alvin을 SSH로 연결해 작업 공간을 확장했다.
   3. 감독 루프: 별도의 스레드에서 병목, 반복되는 실패 모드, 진행을 막는 요소를 계속 감사하고, 그 결과를 환경 설정에 반영했다.

6.2. 관리자처럼 일하는 에이전트 개발자

1. 핵심 노동의 위치

   1. 코드 작성이 아닌 조건 조성: 결과를 만든 것은 화려한 프롬프트가 아니라 에이전트들이 서로 밟지 않고 병렬로 실행되며, 실패 후 회복하고, 필요한 컴퓨트를 확보할 수 있는 환경이었다.
   2. 관리자 비유: 직접 코드의 참호에 들어가기보다 팀이 효율적으로 일하는 데 필요한 것을 준비하고, 병목을 찾아 제거하는 관리자처럼 일했다.

2. Mega Dev 과정

   1. 대상: 취업에 필요한 정보는 무료 채널에 계속 공개하고, 이미 고용된 개발자가 실제 소프트웨어를 만들 때 AI를 최대한 활용하도록 돕는 유료 과정이다.
   2. 강사진: Angie, React 학습에 큰 영향을 준 Kent, Egghead 창립자 John Lindquist와 함께 진행한다.
   3. 권장 조건: 개인 돈으로 결제해야 한다면 추천하지 않으며, 회사 교육비 승인을 받을 수 있을 때 적합하다고 밝혔다. 실시간 워크숍도 포함할 예정이다.

7. 주요 발언 모음

“My complete rewrite of the TypeScript compiler, Type Checker, and LSP all in Rust.”

“I burned $400,000 of Codex tokens and got nowhere. I burned $20,000 of Opus 5.5 and I got there in 2 weeks.”

“I have not read a single line of code.”

“It’s much easier to explain how English works in English than it would be to explain how English works in Spanish.”

“I did not make TypeScript Rust because I wanted something faster than TypeScript Go.”

“The things I did here were not around the prompts. It was around the environment and setup to allow it to do this stuff.”

“Nothing here left RAM. Nothing here left V8.”

“The engineering we know and love is dead.”

“I think we’re peering into the future with some of this stuff.”

8. 핵심 데이터 & 수치

• 약 5개월: 에이전트들이 전체 프로젝트를 작업한 기간.
• 약 40만 달러: Codex 토큰을 사용한 초기 시도의 비용 환산액. 약 84% 호환성에서 정체됐다.
• 약 2만 달러: Opus 5.5의 성공 작업을 API 정가로 계산한 금액.
• 약 500달러: 구독과 무료 리셋을 반영한 성공 작업의 환산 비용.
• 12.5배: TSC 6 대비 TSC RS의 전체 속도 향상.
• 약 2배: TSGO/TSC 7 대비 TSC RS의 속도 향상.
• 13배 이상: 여러 실제 프로젝트에서 TSC 6에서 TSC RS로 바꿨을 때의 향상 폭.
• 약 4배: Effect 검사를 포함한 T3 Code의 전체 처리 시간에서 TSC RS가 Bun 조합보다 빠른 정도.
• 925~983%: 한 계정의 주간 구독 한도 대비 TS Rust 작업 사용량.
• 2~3배: 최초 Go→Rust 직역 버전이 Go 버전보다 느렸던 정도.
• 260MB 미만 / CPU 피크 4%: V8 isolate 데모에서 에이전트·앱·컴파일·타입 검사를 모두 합친 자원 사용량.
• 2배: ESBuild를 포함한 Astra 버전이 유휴 상태에서 사용한 RAM이 최적화된 버전보다 많았던 정도.
• 16~32GB, 4개 스레드 128GB: Cursor Cloud VM의 스레드당 메모리로 언급된 범위와 네 개 스레드의 예약량.
• 연 25~30% 대 연 10~100배: VM 비용 상승과 모델 추론 비용 하락의 대비.

9. 결론 및 시사점

1. 포팅 전략: 복잡한 런타임을 JavaScript에서 저수준 언어로 바로 번역하는 일보다, 이미 사람이 검증하고 정제한 Go 버전을 중간 표현으로 삼는 편이 에이전트에게 훨씬 유리하다.
2. 속도와 충실도의 분리: Bun check처럼 빠른 도구가 항상 원래 TypeScript와 같은 오류를 내는 것은 아니다. 대형 코드베이스에서는 성능뿐 아니라 잘못된 오류를 내지 않는 호환성이 핵심이다.
3. Rust/WASM의 인프라 가치: Rust로 작성한 TypeScript 컴파일러는 단순한 네이티브 바이너리가 아니라 V8 isolate에 들어갈 수 있는 개발 도구가 된다. 파일 시스템과 VM 없이도 타입 검사·컴파일·실행을 연결할 수 있다.
4. 비용 구조의 변화: 모델 추론이 싸질수록 에이전트가 실행되는 VM과 RAM이 전체 비용의 중심이 된다. 운영체제 계층을 매번 예약하는 구조보다 공유 이벤트 루프와 isolate가 경제적이다.
5. 에이전트 개발자의 역할: 앞으로의 생산성은 긴 프롬프트를 쓰는 능력보다 목표를 명확히 정의하고, 병렬 작업 환경을 설계하고, 컴퓨트·메모리·실패 모드를 관리하는 능력에 더 크게 좌우된다.
6. 아이디어 검증의 가속: 과거에는 V8 안에서 완전한 풀스택 개발 환경을 만들겠다는 생각이 몇 년 뒤 누군가가 구현해주길 바라는 상상이었다. 이제는 모델에게 “해봐”라고 지시해 직접 가능성을 시험할 수 있다.
7. 현재의 권고: 모든 프로젝트가 TS Rust로 바뀌어야 하는 것은 아니다. 새 프로젝트에서 유지보수 신뢰성이 중요하면 Bun이 더 현실적일 수 있지만, TypeScript 호환성과 isolate 기반 에이전트 개발 루프를 실험하려면 TS Rust가 강력한 기반이다.
8. 남은 질문: 이런 구조가 실제 Cloudflare Worker에서 어느 정도까지 동작하고, isolate의 보안·권한·CPU 제약을 어떤 방식으로 해결할지는 후속 실험의 대상이다. 그럼에도 에이전트가 소프트웨어를 만드는 미래가 VM 중심일 필요는 없다는 실증이 이미 나왔다.