Microsoft TypeScript Native 프로젝트 분석: Go 기반 성능 혁신의 새로운 전환점
안녕하세요, 쌍팔년생 개발자입니다.
작년에 저희 팀에서 대규모 TypeScript 프로젝트를 진행하면서 정말 고생했던 기억이 있어요. 코드베이스가 점점 커질수록 빌드 시간이 말도 안 되게 오래 걸리더라고요... 😰
특히 Visual Studio Code에서 프로젝트를 열 때마다 "Type checking..." 로딩이 10초 가까이 걸려서 팀원들이 커피 한 잔씩 마시고 기다리는 게 일상이 되었거든요. "이게 정상인가?"라는 의문이 계속 들었어요.
그러던 중 TypeScript 공식 블로그에서 "Microsoft에서 TypeScript를 Go로 재구현한다"는 소식을 발견했어요. 처음에는 "정말? 그게 가능해?"라며 반신반의했는데...
TL;DR: 마이크로소프트가 TypeScript Native 프로젝트를 통해 TypeScript 컴파일러를 Go로 재구현하여 빌드 시간 10배 단축, 메모리 사용량 대폭 감소, 에디터 응답 시간 8배 향상을 목표로 하는 혁신적인 프로젝트입니다. 2025년 중반 미리보기 버전, 후반 완전 기능 버전 출시 예정입니다.
실제로 자료를 찾아보니 정말 놀라운 프로젝트였어요. 이 글에서는 저희가 겪었던 TypeScript 성능 문제와 Microsoft TypeScript Native 프로젝트가 어떻게 이를 해결하려고 하는지, 그리고 개발자인 저희에게 어떤 의미인지 공유해드리려고 해요.
저희가 겪었던 TypeScript의 현실적인 문제들
1. 개발 시작부터 막히는 로딩 시간
매일 아침 프로젝트를 열 때마다 느꼈던 답답함이 있었어요. VS Code에서 TypeScript 프로젝트를 열면 "Initializing TypeScript..."라는 메시지와 함께 거의 10초를 기다려야 했거든요.
팀원 중 한 분이 "이거 매번 기다리는 시간만 계산해도 하루에 몇 분은 날아가는 것 같은데"라고 하셨는데, 정말 공감이 갔어요.
2. 빌드할 때마다 긴 대기 시간
CI/CD 파이프라인에서도 문제였어요. TypeScript 컴파일과 타입 체크가 끝날 때까지 기다리는 시간이 점점 길어지더라고요.
개발팀장님이 "빌드 시간이 너무 오래 걸려서 개발 속도가 떨어지고 있어. 뭔가 방법이 없을까?"라고 하셨을 때 정말 마음이 무거웠어요.
3. 메모리 사용량도 문제
노트북 메모리가 16GB인데도 TypeScript Language Server가 상당한 메모리를 잡아먹어서 다른 프로그램들이 느려지는 경우가 많았어요.
"개발 도구가 개발을 방해하는 아이러니한 상황"이라고 동료분이 농담 반 진담 반으로 말씀하셨는데, 정말 그랬어요.
Microsoft TypeScript Native 프로젝트 발견
동료의 놀라운 소식
그때 저희 팀의 테크 리드분이 "Microsoft에서 TypeScript를 Go로 재구현하는 프로젝트를 시작했다고 해. 성능이 엄청나게 좋아진다던데"라고 알려주셨어요.
처음에는 "Microsoft가 자기들이 만든 TypeScript를 다시 만든다고? 왜?"라는 생각이 들었죠.
공식 발표를 보고 놀란 점
Microsoft 공식 블로그와 GitHub 레포지토리를 확인해보니 정말 대단한 프로젝트였어요:
- 빌드 시간 10배 단축
- 에디터 응답 시간 8배 향상 (9.6초 → 1.2초)
- 메모리 사용량 대폭 감소
"이게 진짜라면 저희가 겪는 문제들이 모두 해결되겠는데?"라는 생각에 정말 기대가 되었어요.
Go 언어를 선택한 이유가 흥미로웠던 점
Microsoft의 전략적 선택
Microsoft TypeScript 팀의 Ryan Cavanaugh가 설명한 Go 선택 이유를 보니 정말 합리적이더라고요:
왜 Go인가?
- 구조적 타입 호환성: JavaScript의 동적 특성과 유사
- 빠른 컴파일 속도: Go 자체가 컴파일이 빠름
- 자동 가비지 수집: TypeScript의 메모리 모델과 잘 맞음
- 교차 플랫폼 지원: 다양한 환경에서 동작
다른 대안들과 비교한 이유
왜 Rust나 C#이 아닌 Go인지도 설명되어 있었어요:
- Rust: 너무 복잡하고 TypeScript의 직접적인 번역에 부적합
- C#: 객체 지향 패러다임 때문에 TypeScript 아키텍처 변경 필요
- C++: 메모리 관리 복잡성으로 개발 생산성 저하
"Microsoft 엔지니어들이 정말 깊이 있게 고민했구나"라는 생각이 들었어요.
목표 성능 지표가 정말 인상적이었던 점
구체적인 개선 목표
Microsoft가 제시한 성능 목표를 보니 정말 야심찬 프로젝트더라고요:
| 항목 | 현재 성능 | 목표 성능 | 개선 배율 |
|---|---|---|---|
| 빌드 시간 | 기준값 | 기준값의 1/10 | 10배 단축 |
| 에디터 응답 시간 | 9.6초 | 1.2초 | 8배 향상 |
| 메모리 사용량 | 기준값 | 기준값의 50% 이하 | 대폭 감소 |
| 타입 검사 속도 | 기준값 | 기준값의 1/5 | 5배 향상 |
"이 정도면 저희가 겪던 문제들이 정말 해결되겠는데?"라는 생각에 기대가 컸어요.
내부 벤치마크 결과
Visual Studio Code에서 9.6초 걸리던 프로젝트 로딩이 1.2초로 단축되었다는 벤치마크 결과를 보고 정말 놀랐어요. "이게 진짜라면 매일 아침 커피 마시며 기다릴 필요가 없겠네!"
개발 진행 상황을 직접 확인해본 경험
GitHub 레포지토리 살펴보기
호기심에 GitHub 레포지토리를 직접 들어가봤어요. CI/CD 파이프라인이 정말 체계적으로 구축되어 있더라고요.
CI/CD 테스트 항목들:
lint- 코드 품질 검사test- 단위 테스트 및 통합 테스트build- 빌드 검증format- 코드 포맷팅baselines- 기준선 테스트 (가장 오래 걸림, 3분 30초)
총 실행 시간이 10분 31초인데, "Microsoft가 정말 꼼꼼하게 품질 관리를 하고 있구나"라는 생각이 들었어요.
최근 커밋 활동
2025년 4월에도 "Fix some bugs in tsc -w" 관련 Pull Request가 올라오는 걸 보니 활발하게 개발이 진행되고 있는 것 같아서 안심이 되었어요.
출시 일정과 저희 팀의 계획
단계적 출시 계획
Microsoft의 출시 계획을 보니 정말 신중하게 접근하고 있더라고요:
🚀 2025년 중반 - 미리보기 버전
- 명령줄 타입 검사 지원
- 기존 워크플로우에 최소한의 변화
- 개발자 피드백 수집
🎯 2025년 후반 - 완전 기능 버전
- Visual Studio Code 완전 통합
- 실시간 타입 검사
- 모든 기능 지원
저희 팀의 도입 계획
팀 미팅에서 이 소식을 공유했더니 모든 분들이 관심을 보이셨어요.
팀장님: "미리보기 버전이 나오면 테스트 프로젝트에서 먼저 써보자" 시니어 개발자: "안정성이 검증되면 점진적으로 도입해보는 게 좋겠네"
저희도 2025년 하반기부터는 새로운 프로젝트에 적용해볼 계획이에요.
기존 버전과의 호환성에 대한 안심
이중 유지 관리 전략
Microsoft가 기존 JavaScript 기반 TypeScript를 바로 폐기하지 않고 병행 유지한다고 해서 안심이 되었어요:
| 버전 | 구현 언어 | 상태 | 지원 기간 |
|---|---|---|---|
| TypeScript 6.x | JavaScript | 지속 유지 | 최소 3년 |
| TypeScript Native 7.x | Go | 신규 출시 | 장기 지원 |
"기존 프로젝트들을 급하게 마이그레이션할 필요 없이 천천히 전환할 수 있겠네"라는 생각에 부담이 덜했어요.
다른 성능 도구들과의 관계
보완적인 관계
동료분과 이야기해보니 TypeScript Native가 다른 도구들과 경쟁하기보다는 보완적인 관계가 될 것 같다는 의견이었어요:
- SWC, esbuild: 번들링과 빌드 도구
- TypeScript Native: 타입 검사와 언어 서비스 개선
"각자 역할이 다르니까 함께 쓰면 더 좋은 개발 환경이 될 것 같아"라는 의견에 모두 동의했어요.
저희 팀에게 기대되는 변화
일상적인 개발 경험 개선
TypeScript Native가 도입되면 저희 일상이 어떻게 바뀔지 상상해봤어요:
아침에 프로젝트 열 때:
- 현재: "로딩 중..." 하며 커피 마시기 → 앞으로: 바로 개발 시작!
빌드할 때:
- 현재: 긴 대기 시간 → 앞으로: 빠른 피드백으로 개발 속도 향상
메모리 사용량:
- 현재: 노트북 팬 소리 → 앞으로: 더 쾌적한 개발 환경
팀 생산성에 미칠 영향
팀장님이 "이 정도 성능 개선이면 우리 개발 속도가 정말 많이 빨라질 것 같은데"라고 하시면서 기대하시더라고요.
특히 CI/CD 시간 단축으로 배포 주기도 빨라질 수 있을 것 같아서 기대돼요.
우려되는 점들도 솔직히
초기 안정성 문제
새로운 도구다 보니 초기에는 버그나 예상치 못한 문제들이 있을 수 있겠죠. 시니어 개발자분이 "미리보기 버전부터 차근차근 테스트해보자"고 하신 이유도 그 때문인 것 같아요.
학습 곡선
Go로 구현된다고 해서 저희가 Go를 배워야 하는 건 아니지만, 새로운 도구에 적응하는 시간은 필요할 것 같아요.
생태계 적응 시간
TypeScript 관련 도구들이 TypeScript Native를 완전히 지원하는 데까지는 시간이 걸릴 것 같아요.
결론
저희 팀의 TypeScript 성능 문제를 겪으면서 Microsoft TypeScript Native 프로젝트를 알게 되었는데, 정말 혁신적인 시도라고 생각해요. 빌드 시간 10배 단축, 에디터 응답 시간 8배 향상이라는 목표가 달성된다면 개발자들의 일상이 완전히 바뀔 것 같아요.
물론 새로운 도구다 보니 초기에는 안정성이나 호환성 문제가 있을 수 있지만, Microsoft의 체계적인 접근 방식을 보면 신뢰할 만한 것 같아요. 특히 기존 버전을 병행 유지한다는 점에서 안심이 되고요.
저희 팀은 2025년 미리보기 버전부터 차근차근 테스트해보고, 안정성이 검증되면 점진적으로 도입할 계획이에요. 매일 아침 TypeScript 로딩을 기다리며 커피를 마시던 일상이 바뀔 날이 기대됩니다!
혹시 비슷한 성능 문제로 고민하고 계신 분들이 있다면 함께 지켜보면 좋겠어요. 동료분이 알려주신 덕분에 희망적인 소식을 알게 되었는데, 더 많은 개발자들과 이런 정보를 공유하고 싶어요.
궁금한 점이나 TypeScript 성능 관련 경험을 공유하고 싶으시면 언제든 댓글로 남겨주세요! 함께 이야기해보면 좋겠어요.