타입스크립트 컴파일러, 왜 Go 언어로 다시 쓰나? 마이크로소프트의 속내 분석

마이크로소프트가 또 한 건 했네요: 타입스크립트, 이제 Go로 새로 만든다?

2025년 3월 12일 — 어제 아침, 커피 마시다 말고 뉴스를 보고 눈이 휘둥그레졌어요. 마이크로소프트가 우리 모두가 애용하는 **TypeScript(타입스크립트)**를 싹 뜯어고친다네요. 그런데 더 놀라운 건... 새로 쓰는 언어가 C++도 아니고, Rust도 아니고, 바로 구글의 Go라는 사실!

진짜 처음엔 장난인 줄 알았어요. 마이크로소프트가 구글 언어를 쓴다니, 무슨 일이야 싶었죠. 그런데 천천히 내용을 읽어보니까, "어라? 이거 좀 괜찮은데?" 싶더라고요.

 

타입스크립트 컴파일러, 왜 Go 언어로 다시 쓰나? 마이크로소프트의 속내 분석

 

---

 

왜 타입스크립트를 다시 쓰려는 걸까?

• 타입스크립트 컴파일러가 타입스크립트로 작성되어 있어 구조상 성능 한계가 있음
• 저수준 성능 최적화가 어려워 대형 프로젝트에서 느린 속도 문제 발생
• 새로운 구조로 개선하여 더 빠르고 효율적인 개발 환경 마련 필요

 

타입스크립트 참 좋아요. 저도 매일 쓰다시피 하거든요. 그런데 알고 보니 타입스크립트 컴파일러가 타입스크립트로 만들어졌다는 사실, 듣고 좀 웃겼어요. 마치 거울 속 거울 같은 느낌이랄까.

문제는, 이 구조 때문에 속도나 성능에 한계가 있다는 점이에요. 메모리에 직접 접근도 힘들고, 멀티스레딩도 제대로 못 써요. 고성능 작업에는 좀 답답하죠.

저도 예전에 큰 프로젝트 할 때, 컴파일 돌릴 때마다 VS Code가 숨을 헐떡이는 걸 보며 속 터졌어요. 그래서 이번엔 아예 다시 제대로 만들어보자는 거예요. 신선하죠?

 

---

 

그런데 왜 하필 Go야?

처음엔 저도 그랬어요. "아니 왜 C++도 있고 Rust도 있는데... Go?" 근데 하나하나 뜯어보니까, 그 선택에 이유가 있더라고요.

 

▸ 컴파일? Go는 속도 미쳤어요

Go는 기계어로 바로 컴파일되니까 진짜 빠릅니다. Java처럼 중간에 가상 머신 끼는 것도 없고요. 그냥 직진이에요, 직진.

 

▸ 메모리? 알아서 치워줘요

Go는 자동 메모리 관리(GC) 덕분에, 메모리 누수 걱정 덜 해도 돼요. Rust처럼 머리 아픈 소유권 개념도 없고요.

 

▸ 기존 코드? 안 버려요

재밌는 건, 이번 작업이 "싹 갈아엎기"가 아니라는 점이에요. 기존 타입스크립트 코드를 하나하나 Go로 옮기는 작업이에요. 기능은 그대로 유지되면서 속도만 날개 달리는 거죠.

 

---

 

속도? 와... 진심 말도 안 돼요

• 새 컴파일러 성능이 기존 대비 획기적으로 향상됨 (VS Code 컴파일 시간 70초 → 7초)
• 실무에서 체감할 수 있는 빠른 개발 속도 제공
• 특히 자동완성 기능 등의 반응 속도가 크게 향상될 전망

 

테스트 결과 보는데, 그냥 헛웃음 나왔어요. VS Code에서 타입스크립트 컴파일 시간이 70초 → 7초. 무슨 치트키라도 쓴 줄 알았어요.

직접 써보진 못했지만, 이런 건 진짜 실무에서 체감되거든요. 특히 대형 프로젝트 할 때 자동완성 느릴 때, 그거 참 스트레스잖아요. 이제 그 답답함이 많이 사라질 거예요.

 

---

 

지금 바로 쓸 수 있냐고요? 아직은 조금 기다려야 해요

• 현재는 TypeScript 5.8 버전, Go 기반 컴파일러는 TypeScript 7부터 적용 예정
• 실제 사용까지는 몇 개월에서 1~2년 걸릴 수도 있음
• 기다릴 만한 충분한 가치가 있는 변화

 

지금은 TypeScript 5.8이고, Go 버전 컴파일러는 TypeScript 7부터라고 해요. 뭐, 몇 개월 혹은 1~2년 걸릴 수도 있죠. 그래도 기다릴 만한 변화라고 생각해요. 저는 벌써부터 기대돼요.

 

---

 

이 모든 아이디어의 주인공은 누구냐고요?

• 프로젝트를 이끄는 인물은 Turbo Pascal, C#, 타입스크립트의 창시자 앤더스 하일스버그
• 자사 언어 고집 없이 실용적인 선택을 한 결정이 주목받음
• 기술보다 실효성을 우선시한 판단으로 업계에 긍정적인 평가

 

바로 앤더스 하일스버그! 이름만 들어도 믿음직한 개발자죠. Turbo Pascal, C#, 타입스크립트까지 만든 진짜 레전드입니다.

그런데 이번에도 또 멋졌던 게, 자기 회사 언어 고집 안 하고 가장 실용적인 선택을 했다는 거예요. 구글 언어라도, 좋으면 쓰는 거죠. 그게 진짜 실력자의 마인드 아닐까요?

 

---

 

커뮤니티 반응? 좀 시끌시끌해요

• C++나 Rust 팬들 사이에서 아쉬움과 논란 존재
• 다양한 의견 속에서도 실용적인 선택이라는 평가 우세
• 언어 선택에 대한 다양성 존중 필요

 

물론 C++나 Rust 팬들은 서운하겠죠. 댓글 보니까 "그럴 거면 차라리 Rust 쓰지"라는 말도 많더라고요.

하지만 이건 인기투표가 아니잖아요. 실제로 문제 해결에 제일 적합한 언어를 선택한 것일 뿐이죠. 저도 이 선택에 한 표 던집니다.

 

---

 

앞으로 뭐가 달라질까?

• 단순한 속도 개선을 넘어 전체 개발 환경이 더 편리해질 전망
• 새로운 컴파일러 도입으로 생산성 향상 기대
• 오류 추적 및 해결을 돕는 Sentry 등의 툴 활용 중요성 부각

 

이번 변화는 단순한 성능 향상이 아니라, 개발 환경 전체를 더 쾌적하게 만들기 위한 시작 같아요. 나중에 이 변화 덕분에 작업 속도 빨라지고, 에디터 반응도 쾌적해지면, 얼마나 편할까요?

그리고 혹시라도 에러 터지면 어떻게 해야겠어요? 그럴 때는 Sentry 같은 툴이 진짜 빛나죠.

저도 요즘 프로젝트에서 Sentry 많이 쓰는데요, Trace Explorer 기능 하나만으로도 문제 파악 속도가 확 올라가요. 자잘한 오류 하나도 놓치지 않게 도와줘서, 팀원들이 저한테 엄지척 날려요.

 

---

 

마무리하면서

• 변화는 항상 낯설지만, 결국 큰 이점으로 돌아옴
• 마이크로소프트의 이번 결정도 미래에 긍정적인 평가 받을 가능성 높음
• 변화에 열린 태도와 호기심을 유지하는 것이 중요함

기술은 항상 변화무쌍하잖아요. 처음엔 낯설고 헷갈리더라도, 나중엔 "와, 그때 이거 해놓길 잘했다" 싶은 날이 오거든요.

이번 마이크로소프트의 선택도 딱 그런 느낌이에요. 처음엔 좀 의외였지만, 시간이 지나면 다들 이 선택에 고개 끄덕일 날이 올 거예요.