Transcript
00:00:00타입스크립트 7 버전의 릴리즈 후보가 나왔습니다. 이번 버전은
00:00:04기존의 타입스크립트와는 완전히 다른 타입스크립트가 될 것입니다. 혹시 모르셨던 분들을 위해 말씀드리면
00:00:07타입스크립트 컴파일러를 타입스크립트 자체에서 Go 언어로 다시 작성해 왔는데, 결과적으로 10배나 더 빨라졌다고 합니다.
00:00:12다음 달에 타입스크립트 7이 출시될 예정이니, 실제로 무엇이 바뀌었는지
00:00:17얼마나 빨라졌는지, 그리고 설치하기 전에 알아야 할 호환성 문제가 있는지 알아보겠습니다.
00:00:26Go로의 이식에 관한 소식을 놓치셨다면, 사실 그들은 약 1년 전부터 시작했습니다.
00:00:29결론부터 말하자면, 자바스크립트가 타입 체커와 같은 무거운 CPU 집약적인 작업
00:00:34수행을 위해 만들어지지 않았다는 것을 깨달았기 때문입니다. 그래서 Go로 다시 작성하기 시작했고, 초기부터 큰 성공을 거두었죠.
00:00:39기본적으로 기존 타입스크립트 구현을 거의 한 줄 한 줄 포팅했기 때문에, 타입
00:00:44체크 로직은 구조적으로 완전히 동일하며 동작 방식도 같습니다. 심지어 일부
00:00:48함수들은 언어만 다를 뿐 거의 똑같아 보입니다. 제가 기억하기로 이건 아마
00:00:52클로드(Claude)에게 코드베이스를 주고 원하는 언어로 마이그레이션하라고 시키기 전이었을 겁니다.
00:00:56번(Bun)을 보면서 하는 말입니다. 이식의 결과는 확실합니다. 여기 제가
00:01:00플레이라이트(Playwright) 저장소를 가지고 있는데, 이전 버전의 타입스크립트로 타입 체크를 해보면
00:01:04완료하는 데 약 6초가 걸립니다. 1,400개의 파일과 50만 줄의
00:01:08코드를 처리했죠. 이제 이 명령어를 제외하고 아무것도 바꾸지 않은 채 릴리즈 후보 버전으로 전환해 보겠습니다.
00:01:12총 0.87초가 걸렸습니다. 정말 엄청난 개선이죠. 똑같은 개수의
00:01:18에러를 발견했고, 똑같은 파일과 똑같은 코드 라인을 처리했으니 타입스크립트 6와 정확히
00:01:23동일하게 작동합니다. Go의 네이티브 코드가 이런 작업에 대해 자바스크립트보다 기본적으로 훨씬 더 빠르기 때문입니다.
00:01:27하지만 Go는 공유 메모리 병렬 처리를 사용할 수 있게 해 줍니다. 자바스크립트 컴파일러는
00:01:32단일 스레드였지만, Go는 여러 코어에 걸쳐 타입 체크 작업을 분산할 수 있습니다. 타입스크립트
00:01:377에서는 플래그를 사용하여 단일 스레드로 강제할 수도 있습니다. 디버깅을 하거나
00:01:41제한된 리소스를 가진 머신에서 실행하는 경우에 대비해서죠. 플레이라이트 코드베이스에서
00:01:46타입스크립트 7로 단일 스레드 실행 시 약 2초가 걸리는데, 이는
00:01:50이전보다 여전히 3배나 빠른 속도입니다. 병렬 처리 이야기가 나와서 말인데, 새로운 체크 플래그도 공개되어
00:01:54타입 체커 워커를 병렬로 몇 개나 실행할지 설정할 수 있게 되었습니다.
00:01:58기본값은 4인데, CPU 코어가 많은 환경이라면 이 값을 늘려 대규모 코드베이스에서의 빌드 속도를 높일 수 있습니다.
00:02:03하지만 메모리 사용량이 늘어난다는 점은 감수해야 합니다. 만약 플레이라이트 저장소에서 체크 값을
00:02:08기본값의 두 배로 설정하면, 실제로 시간을 3분의 1 정도 더 단축할 수 있습니다.
00:02:12프로젝트 참조 빌드(여러 프로젝트를 동시에 빌드)를 병렬화하기 위한 새로운 빌더 플래그도 추가되었습니다.
00:02:16이 플래그로 동시에 실행할 병렬 빌더의 수를 조절할 수 있습니다.
00:02:20이를 방금 본 체크 플래그와 조합하면, 예를 들어 각각 4개씩 설정할 경우
00:02:24최대 16개의 타입 체커를 동시에 실행할 수 있게 됩니다. 네이티브 코드 변경 사항과 병렬 처리 외에도
00:02:29타입스크립트 7의 또 다른 큰 재작성 부분은 감시(Watch) 모드입니다.
00:02:34Go로 포팅할 때 표준 라이브러리에는 기본적으로 파일 감시 API가 제공되지 않아서 좀 까다로웠습니다.
00:02:38사용해 본 서드 파티 라이브러리들도 안정성, 성능, 크로스 플랫폼 지원 면에서 문제가 있었습니다.
00:02:43그래서 팀에서는 파셀(Parcel) 번들러의
00:02:47파일 워처를 살펴보았는데, 이건 마이크로소프트가 VS Code에서 조금 사용하는 것이기도 합니다. 하지만 C++로 되어 있어서
00:02:53필요한 부분들을 Go로 다시 포팅해야 했습니다. 다행히도 그들은
00:02:57모든 작업을 완료했고, 이전보다 훨씬 부드럽고 잘 작동하는 것 같습니다. 다음으로, 이번은
00:03:01메이저 버전 업데이트인 만큼, 대규모 재작성이 포함되어 있어서 깨지는 변경 사항이 많을 것이라 예상하실지도 모르겠습니다.
00:03:05하지만 타입스크립트 6에서 7로 업그레이드할 때는 별다른 변경 사항이 없을 것으로 보입니다. 만약
00:03:105에서 7로 가려면 변경 사항이 꽤 있을 겁니다. 그래서 6까지 먼저 올린 후에
00:03:14정상적으로 작동하는 것을 확인하고 7로 올리는 것을 추천하는 것 같습니다. 몇 가지
00:03:19타입스크립트 6의 큰 변경 사항은 ES5 타겟 제거, baseUrl 제거, module
00:03:24시스템 AMD, UMD, SystemJS 지원 중단이었습니다. 또한 strict를 기본값으로 true 설정하고, module 기본값을 ESNext로,
00:03:31target 기본값은 ESNext 바로 이전의 현재 안정적인 ECMAScript 버전으로 설정했습니다.
00:03:36기본적으로 과거를 뒤로하고 현대적인 타입스크립트로 나아가는 과정이라 저는 아주 좋게 생각합니다.
00:03:40모든 버전을 지원하려고 하면 도구의 발전 속도가 느려질 수 있기 때문입니다.
00:03:45나머지 블로그 글을 읽어봐도 실제로 타입스크립트 언어 자체와 관련하여
00:03:49관심이 가는 새로운 기능이나 변경 사항은 템플릿 리터럴
00:03:53타입이 이제 유니코드 코드 포인트를 보존한다는 점입니다. 이전까지 타입스크립트는 UTF-16 코드
00:03:59단위로 분리해서 이모지를 반으로 나누기도 했고, 헤드와
00:04:04테일에서 이상한 타입이 생성되곤 했습니다. 타입스크립트 7에서는 전체 코드 포인트 단위로 분리하여 온전한 문자,
00:04:09즉 이모지가 보존되며 예상대로 분리가 이루어집니다. 사실 저는
00:04:13여러분 중 누구라도 타입스크립트를 사용하면서 이 문제를 겪어보셨다면 정말 대단하다고 생각할 겁니다.
00:04:18결론적으로 이런 변화들 덕분에 타입스크립트를 사용하는 모든 것이 훨씬 더 빠르게 느껴질 것입니다.
00:04:22특히 대규모 프로젝트에서의 에디터 반응 속도가 그렇겠죠. 안정적인 릴리즈는 약 한 달 내로 예상됩니다.
00:04:27하지만 도구 작성자들이 컴파일러 위에 무언가를 빌드할 때 사용하는 안정적인 프로그래밍 API는
00:04:327.1 버전에 포함될 예정입니다. 그래서 6과 7 버전을 충돌 없이 나란히 사용할 수 있는
00:04:36호환성 패키지도 있습니다. 이 모든 변경 사항에 대해 어떻게 생각하시나요?
00:04:41혹시 타입스크립트가 느리다고 느껴본 적이 있으신지 궁금합니다. 댓글로 알려주세요.
00:04:44아래에 있는 구독 버튼도 눌러주시고, 늘 그렇듯 다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video