내가 아직 메이저 언어로 TypeScript를 쓰는 이유

얼마 전 다른 회사에 다니는 개발자분과 이야기를 나누다 조언을 하나 들었습니다. 이제 TypeScript는 접고 Go나 Rust로 갈아타는 게 좋지 않겠냐는 것이었습니다. 근거는 세 가지였습니다. 느리고 무겁다, 결국은 스크립트 언어다, 그리고 AI 시대에는 끝난 언어다.

사실 저도 어느 정도는 동의하는 이야기입니다. 저는 이미 Go와 Rust를 써봤고, 필요한 경우 쓰고 있습니다. 다만 그것들을 메이저로 승격시킬 생각이 없을 뿐입니다.

esbuild와 swc는 '세일즈부스트'에 다니던 무렵부터 눈여겨보고 있었습니다. 지금이야 Go와 Rust로 만든 번들러가 프레임워크에 기본으로 들어가 있지만, 그때는 webpack의 시대였습니다. 공식 지원도 없었고 이걸 써도 되는지 판단해줄 사람도 없었기에, GitHub에 들어가 코드를 직접 읽어가며 안정성과 적합성을 따져봤습니다. 그렇게 한참을 지켜보다 'TainAI'에서 사내 프로덕트에 직접 연결해 쓰기 시작했습니다.

그때 제가 본 것은 버그가 아니었습니다. 초기 프로젝트는 어차피 불안정하고, 그건 시간이 해결해주는 문제니까요. 제가 정말 확인하고 싶었던 건 구조였습니다. 이 코드가 앞으로 커질 수 있게 짜여 있는지, 더 정확히 말하면 만든 사람이 자기 코드에게 잡아먹힐 가능성이 있는지를 봤습니다.

그 시절 오픈소스가 중단되는 원인은 대체로 비슷했습니다. 기능 중심으로 계속 얹어가다가 어느 순간 대규모 리팩토링이 필요한 지점에 닿고, 초기 기여자가 거기서 그대로 손을 놓아버립니다. 저장소는 남아 있는데 이슈에는 답이 없고, 마지막 커밋이 반년 전인 채로 굳어버리죠. 그래서 기능 목록보다도 이 코드가 지속 가능한 형태인지를 먼저 확인했습니다.

모노레포 스택을 고를 때도 같은 것을 봤습니다. Nx와 Lerna, pnpm workspace를 두루 거쳐 지금은 Turborepo에 정착했습니다. 성능이 뛰어났고 설정도 간단했습니다. DX가 좋았죠. 하나 더 있다면 Vercel의 영향권 안에 있다는 점이었습니다. 그 무렵 Next.js 이슈 트래커에는 빌드가 느리다는 글이 계속 올라오고 있었습니다. 프로젝트가 조금만 커져도 빌드 시간을 감당하기 어렵다는 이야기였고, Vercel이 이 문제를 그냥 둘 리 없다고 봤습니다. 앞으로 어디에 힘을 쏟을지가 보였던 셈입니다.

그래서 지금 제 개발 환경이 어떤 모양이냐면, 이 블로그를 빌드하는 Turborepo는 Rust로 다시 쓰인 물건입니다. 포매터와 린터로 쓰는 Biome도 Rust이고, Next.js 16의 기본 번들러가 된 Turbopack 역시 Rust입니다. package.json을 열어보면 제 빌드 파이프라인은 이미 대부분 Rust 위에서 돌아가고 있습니다.

그리고 지난달, TypeScript도 변했습니다. 7.0의 컴파일러가 Go로 다시 쓰여 7월 8일에 정식으로 나왔고, 전체 빌드 기준으로 여덟 배에서 열두 배가 빨라졌습니다. (아직 7을 쓰지는 못합니다. 안정적인 프로그래밍 API가 없어서, 주변 도구들이 붙으려면 7.1을 기다려야 하거든요.) 느리다는 이유로 언어를 떠나라는 조언이 도착했을 무렵, 정작 그 언어는 이미 그 문제를 Go로 풀어내고 있었습니다.

제가 메이저를 바꾸지 않는 이유도 여기에 있습니다. 저는 언어를 하나 골라 거기에 머무르는 게 아니라, 자리마다 맞는 것을 쓰고 있습니다.

Flutter는 메이저 업데이트가 나올 때마다 한 번씩 만들어봅니다. Swift는 WWDC를 보고 새로 나온 기술을 그때그때 써봅니다. Java는 방송하는 친구가 마인크래프트 모드가 필요하다고 해서 썼습니다. Go와 Rust, Kotlin도 필요한 자리에서 꺼내 씁니다. 다만 필요할 때만 씁니다.

빠르게 돌아야 하는 자리는 진작에 Rust와 Go로 넘어갔고, 제가 TypeScript로 쓰는 부분은 그 도구들이 깔아둔 파이프라인 위에서 제품의 모양을 잡는 일입니다.

스타트업에서는 POC와 MVP를 얼마나 빨리 만들어 내놓느냐가 중요한데, 그 구간에서 TypeScript는 여전히 강력합니다. 물론 규모가 어느 선을 넘어가는 아키텍처라면 Go나 Rust로 옮겨야 한다는 주장에도 동의합니다.

'AI 시대에는 끝난 언어다'라던 말도 일리가 있습니다. AI가 새 언어를 배우는 비용을 거의 없애버렸으니까요. 굳이 익숙한 언어를 고집할 이유가 사라지면 언어 선택은 결국 성능으로만 갈리고, 네이티브가 먼저 오게 됩니다. 저도 그 방향은 보고 있습니다.

요즘 이 이야기가 여기저기서 오갑니다. AI가 코드를 써준다면 왜 파이썬을 쓰는가라는 글이 있었고, 해커뉴스 토론이 길게 붙었습니다. 원글은 어려운 언어가 먼저 쉬워졌으니 이제 Rust로 가라는 쪽이었는데, 토론을 읽으면서 제 생각과 가장 가까웠던 건 다른 이야기였습니다. 진짜 쟁점은 어떤 언어가 최고냐가 아니라, 언어를 고르는 기준이 '얼마나 빨리 쓰느냐'에서 '얼마나 쉽게 검증하느냐'로 옮겨가고 있다는 것이었습니다.

에이전트에게 코드를 맡기면 사람이 읽어 확인하는 속도보다 훨씬 빠르게 코드가 쌓이는데, 그때 잘못된 것을 걸러주는 건 리뷰가 아니라 타입 검사입니다. AI에게 타입은 엄청난 강점입니다. 또한 얼마나 쉽게 검증할 수 있느냐로 따지면 TypeScript도 밀리지 않습니다. 타입이 있고, 오픈소스가 거대하게 쌓여 있어 AI가 가장 많이 읽어본 언어이기도 하니까요. 훈련 데이터가 적은 언어에서는 같은 지시를 줘도 결과물이 다릅니다.

토론에 이런 말이 있었습니다. 파이썬을 십 년 넘게 써왔기 때문에 에이전트가 크게 잘못될 코드를 쓰면 십 초 안에 냄새를 맡을 수 있는데, 다른 언어였다면 그러기 어렵다고요. Go나 Rust로 했다면 AI 보조 프로그래밍이 아니라 바이브코딩에 가까웠을 거라는 이야기였습니다. 익숙한 언어라는 게 그저 편하다는 뜻이 아니라, 잘못된 것을 알아볼 수 있다는 뜻이었습니다.

앞서 말한 '코드에게 잡아먹히는' 이야기로 돌아가 보면, 사람이 감당하지 못해 포기하던 그 대규모 리팩토링을 이제는 잘게 쪼개어 맡길 수 있게 되었습니다. 그 작업을 안전하게 만들어주는 것 역시 타입입니다.

그래서 저는 아직 TypeScript를 쓰고 있는 게 아니라, 신생 도구를 프로덕션에 넣을지 판단하던 그때의 기준을 언어에도 똑같이 대고 있을 뿐입니다. TypeScript도 그 자리에 가만히 있지는 않습니다. 컴파일러를 Go로 다시 쓴 것이 그 증거고요.

다음 답이 꼭 Go나 Rust라는 법도 없습니다. Vercel Labs가 실험 중인 zerolang은 아예 에이전트를 위해 만들어진 언어입니다. 사람이 읽는 텍스트가 아니라 컴파일러가 검증한 그래프를 원본으로 두고, 에이전트는 검증을 통과한 수정만 밀어 넣을 수 있습니다. 사람은 그 그래프를 텍스트로 펼쳐 읽고요. 아직 실험 단계지만, 언어를 고르는 기준이 검증 쪽으로 옮겨간다는 말이 무슨 뜻인지는 이쪽이 훨씬 분명하게 보여줍니다.

언젠가 그 기준으로 봤을 때 다른 답이 나온다면, 그때 옮기면 됩니다.