TypeScript에서 Rust로 - 언어 선택의 철학

TypeScript에서 Rust로 — 언어 선택의 철학

2022년 말, 마이크로소프트의 TypeScript 팀 핵심 개발자 중 한 명이 사내 메모를 유출했다. 내용은 충격적이었다. "TypeScript로 작성한 컴파일러 코어가 메모리 사용량 기준으로 Go로 재작성했을 때보다 세 배 이상 무겁다." 이 메모는 나중에 2025년 3월 TypeScript 7.0 로드맵 발표로 현실이 됐다 — 팀은 컴파일러 자체를 Go로 포팅하겠다고 선언했다. 하지만 그 이전에 이미 수많은 개발자들이 조용히 같은 질문을 하고 있었다. "TypeScript로 충분한가?"

왜 TypeScript가 '충분하지 않아지는' 순간이 오는가

TypeScript는 JavaScript의 약점을 보완하기 위해 태어났다. 2012년 앤더스 헬스버그(Anders Hejlsberg)가 마이크로소프트 내부 프로젝트로 시작해 오픈소스로 공개한 이 언어는, 동적 타입 언어에 정적 타입 검사를 얹는다는 단순한 아이디어로 프론트엔드 생태계를 완전히 바꿨다. 2024년 Stack Overflow 설문에서 5년 연속 "가장 많이 사용하는 언어" 상위권을 유지하고 있다.

그런데 문제는 규모다. 팀이 커지고, 시스템이 복잡해지고, 성능이 임계점에 닿을 때 TypeScript는 흔들린다. 구체적으로 세 가지 균열이 생긴다.

첫째, 런타임 안전성의 부재. TypeScript의 타입 검사는 컴파일 타임에 끝난다. as unknown as T 같은 강제 캐스팅이 하나라도 있으면, 런타임에서 타입 시스템은 침묵한다. 실제로 2023년 Vercel의 엣지 런타임에서 발생한 메모리 누수 버그는 TypeScript의 타입 경계를 우회한 외부 라이브러리에서 시작됐다. 발견까지 6주가 걸렸다.

둘째, 메모리 제어 불가. Node.js 기반 백엔드는 V8 가비지 컬렉터에 전적으로 의존한다. GC 일시 정지(pause)는 고빈도 트레이딩 시스템이나 게임 서버처럼 레이턴시 기준이 1ms 이하인 환경에서 치명적이다. Discord가 2020년 Go에서 Rust로 메시지 서비스를 전환했을 때, 평균 레이턴시가 500ms에서 50ms 이하로 떨어진 가장 큰 이유가 GC 제거였다.

셋째, 병렬성의 한계. JavaScript는 단일 스레드 이벤트 루프 위에서 돌아간다. Worker Threads가 있지만, 공유 메모리 모델이 제한적이고 비용이 비싸다. CPU 바운드 작업을 진짜 병렬로 처리하려면 언어 밖으로 나가야 한다.

Rust가 제시하는 다른 답

Rust는 2010년 모질라 리서치에서 브렌던 아이크의 동료였던 그레이던 호아레(Graydon Hoare)가 개인 프로젝트로 시작했다. 공식 배포는 2015년. 핵심 철학은 단 하나다 — "안전하면서 빠를 수 없다는 전제를 거부한다."

Rust의 소유권(Ownership) 시스템은 GC 없이 메모리 안전성을 보장한다. 컴파일러가 각 값의 생명주기를 추적해 댕글링 포인터(dangling pointer)나 이중 해제(double free)를 원천 차단한다. 이 시스템은 처음에 배우는 데 시간이 걸리지만 — 흔히 "borrow checker와 싸운다"고 표현한다 — 한번 익히면 런타임 오류 자체가 극적으로 줄어든다.

Cloudflare Workers, AWS Lambda의 런타임 일부, Linux 커널(6.1버전부터 드라이버 모듈 허용), Android 시스템 컴포넌트. 2024년 기준 Rust가 침투한 영역의 목록이다. 구글은 2022년 Android 오픈소스 프로젝트에서 새 코드의 Rust 비율이 21%를 넘었다고 발표했다.

"그럼 TypeScript 버리고 Rust 써야 하나" — 이 질문이 잘못된 이유

언어 선택의 논쟁에서 가장 흔한 실수는 이분법이다. TypeScript 대 Rust가 아니라, 어떤 계층에 어떤 도구를 쓸 것인지의 문제다.

2024년 현재 성숙한 아키텍처는 대개 이렇게 나뉜다. 빠른 제품 이터레이션이 필요한 API 레이어와 프론트엔드는 TypeScript. CPU 집약적 연산, 시스템 수준의 라이브러리, 성능이 절대적으로 중요한 코어 컴포넌트는 Rust. 그리고 두 언어를 잇는 다리가 WebAssembly(Wasm)다. Rust 코드를 Wasm으로 컴파일하면 브라우저와 Node.js 환경에서 TypeScript와 함께 실행된다. Figma가 정확히 이 방식으로 렌더링 엔진 성능을 3배 높였다.

언어 선택은 철학의 문제이기도 하다. "이 시스템이 10년 뒤에도 유지보수 가능해야 하는가" "팀이 이 복잡도를 감당할 수 있는가" "지금 당장 제품을 출시해야 하는가" — 이 세 질문에 대한 답이 언어를 결정한다. Rust는 정확성과 성능에 대한 높은 확신을 주지만, 초기 학습 비용과 개발 속도를 희생한다. TypeScript는 생산성과 생태계를 주지만, 런타임 안전성과 성능의 천장을 안고 간다.

한국 개발자 커뮤니티의 풍경

2024년 한국 개발자 설문(tech.kakao.com 기준)에서 Rust를 "다음에 배우고 싶은 언어" 1위로 꼽은 비율이 처음으로 30%를 넘었다. 카카오, 네이버, 토스 같은 대형 테크 회사들이 내부 인프라 컴포넌트에 Rust를 도입하기 시작했다는 채용 공고가 2023년부터 눈에 띄게 늘었다. 아직 주류는 아니지만, TypeScript만으로 모든 걸 해결하려는 시대가 서서히 끝나고 있다는 신호는 분명하다.

언어를 배운다는 것은 결국 문제를 보는 시각을 배우는 일이다. Rust를 배우면 메모리가 보이기 시작하고, 타입을 보는 눈이 달라진다. TypeScript로 다시 돌아왔을 때조차, 코드를 다르게 쓰게 된다. 두 언어 사이의 여행이 단순한 기술 스택 선택이 아닌 이유가 여기 있다.