개발 서버는 금방 뜬다. 파일을 저장하면 브라우저에도 수정 사항이 바로 반영된다. 그런데 편집기에서는 자동 완성이 늦게 나타나고, 터미널의 타입 검사는 한참 돌아간다. PR을 올리면 CI에서 다시 기다린다.
전부 같은 TypeScript 프로젝트에서 벌어지는 일이지만, 기다리는 이유는 서로 다르다.
2026년 10월 20일 공개된 TypeScript 7.1 베타를 보면서 먼저 짚고 싶은 것도 이 차이다. 이번 베타에는 새로운 컴파일러 API가 포함됐다. 지난 7월 TypeScript 7.0이 네이티브 컴파일러 전환을 실제 배포로 가져왔다면, 7.1은 그 기반을 주변 개발 도구가 활용할 수 있도록 넓히는 단계다. TypeScript 7.1 베타 발표
‘10배 빨라진 TypeScript’라는 설명은 매력적이다. 다만 이 숫자를 그대로 우리 서비스의 빌드 시간에 대입하면, 업그레이드한 뒤 실망하기 쉽다.
TypeScript가 빨라지는 것과 프론트엔드의 모든 작업이 빨라지는 것은 같은 말이 아니다.
브라우저에 코드가 뜨는 것과 타입 검사가 끝나는 것은 별개의 일이다
다음 코드는 타입 관점에서 잘못됐다.
1 2 3const price: number = "12000"; console.log(price);
하지만 타입 표기를 제거하면 JavaScript로 실행할 수 있는 코드는 남는다.
1 2 3const price = "12000"; console.log(price);
여기서 두 작업을 구분해야 한다.
하나는 TypeScript 문법을 브라우저가 실행할 수 있는 JavaScript로 변환하는 일이다. 다른 하나는 변수와 함수, 모듈 사이의 타입 관계를 살펴보고 잘못된 사용을 진단하는 일이다.
Vite는 이 구분을 명확하게 가져간다. .ts 파일을 처리하지만, 코드 변환 과정에서 프로젝트의 타입 검사까지 수행하지는 않는다. 공식 문서도 타입 검사를 편집기나 별도 빌드 단계에서 담당하도록 안내한다. Vite의 TypeScript 처리 방식
따라서 Vite 기반 프로젝트에서 TypeScript 버전을 올렸다고 해서 개발 서버 시작 시간이 같은 비율로 줄어들 이유는 없다. 파일 저장 후 화면이 바뀌는 속도, 타입 오류가 표시되는 속도, 프로덕션 번들이 생성되는 속도는 서로 다른 작업 경로에 놓여 있기 때문이다.
이 차이는 문제가 생겼을 때도 중요하다. 브라우저가 정상적으로 뜬다는 사실만으로 타입 검사까지 통과했다고 생각하면 안 된다. 반대로 타입 검사가 느리다고 해서 번들러부터 교체하는 것도 순서가 맞지 않을 수 있다.
TypeScript 7이 바꾼 곳은 어디인가
TypeScript 7.0은 기존 컴파일러를 Go 기반의 네이티브 구현으로 옮겼다. TypeScript로 작성되어 JavaScript로 실행되던 도구를 다른 실행 기반으로 전환한 것이다. 공식 발표는 네이티브 실행과 병렬 처리 등을 통해 전체 빌드에서 대체로 8~12배의 속도 향상을 설명한다. 이는 TypeScript 팀이 제시한 결과이지, 모든 프로젝트의 전체 CI 시간이 그 비율로 줄어든다는 보장은 아니다. TypeScript 7.0 발표
여기서 ‘네이티브’라는 표현도 오해하기 쉽다.
우리가 작성한 React 앱이 네이티브 앱으로 바뀐다는 뜻이 아니다. 브라우저에서 실행되는 결과물이 Go 코드가 되는 것도 아니다. 코드를 분석하고 진단하는 개발 도구의 구현과 실행 방식이 바뀐 것이다.
그러므로 이 변화로 기대할 첫 번째 효과는 사용자의 화면에서 버튼이 더 빨리 눌리는 것이 아니다. 개발자가 오류를 확인하고, 변경 사항을 검증하고, 다음 작업으로 넘어가기까지 기다리는 시간이 줄어드는 것이다.
서비스 실행 성능과 개발 도구 성능은 모두 중요하지만, 같은 지표에 섞어서는 개선 여부를 제대로 판단할 수 없다.
10배라는 숫자가 전체 빌드에서 작아지는 이유
실제 측정값이 아니라 계산을 위한 가정을 하나 두자.
어떤 프로젝트의 배포 준비 과정이 다음처럼 순서대로 실행된다고 해보자.
1 2 3 4 5타입 검사 40초 번들 생성 30초 테스트 30초 ------------------ 전체 100초
타입 검사만 10배 빨라져 4초가 되면 전체 시간은 64초다.
1 2 3 4 5타입 검사 4초 번들 생성 30초 테스트 30초 ------------------ 전체 64초
기다리는 시간은 36초 줄었다. 상당히 큰 개선이다. 하지만 전체 과정이 10배 빨라진 것은 아니다. 전체 속도 향상은 약 1.56배다.
더 중요한 것은 CI가 항상 이렇게 순차적으로 실행되지는 않는다는 점이다. 타입 검사와 테스트가 병렬 작업이라면, 배포 가능 시점을 결정하는 것은 더 오래 걸리는 경로다. 타입 검사가 줄어들어도 다른 작업이 계속 남아 있다면, 사용자가 보는 전체 대기 시간은 생각보다 적게 달라질 수 있다.
그래서 “업그레이드했는데 왜 빨라지지 않았지?”라는 질문에 답하려면 먼저 무엇을 재고 있는지 알아야 한다.
tsc 실행 시간인가. npm run build 전체 시간인가. CI 작업이 큐에서 기다린 시간까지 포함했는가. 의존성 설치와 원격 캐시 다운로드도 같은 숫자에 들어 있는가.
비교 대상을 정하지 않은 벤치마크는 도구가 빨라졌는지보다 그날 네트워크가 어땠는지를 더 크게 반영할 수도 있다.
이번 7.1 베타에서 눈여겨볼 것은 새 문법보다 API다
앱 개발자에게 TypeScript는 보통 tsc 명령이나 편집기의 오류 표시로 보인다. 하지만 주변 도구는 TypeScript를 프로그램 안에서 직접 호출하기도 한다. 소스를 읽고, 구문 트리를 탐색하고, 타입 정보를 얻어 다른 결과물을 만드는 방식이다.
따라서 명령줄 컴파일러를 교체할 수 있다는 것과, 그 컴파일러를 내부에서 사용하던 도구를 교체할 수 있다는 것은 별개의 호환성 문제다.
TypeScript 7.0 발표 당시에도 프로그램 방식의 접근을 필요로 하는 도구를 위해 6.0과 함께 사용하는 경로가 안내됐다. 7.1 베타의 새 API가 중요한 배경이다. TypeScript 7.0의 전환 안내
새 API에는 동기 방식의 typescript/sync, Promise 기반의 typescript/async, 구문 트리 관련 기능을 위한 진입점 등이 마련됐다. API 사용 예제에서는 API와 Program 같은 자원을 using으로 정리하는 방식도 등장한다. 단지 기존 패키지 안쪽의 실행 속도만 바뀐 것이 아니라, 도구를 만드는 쪽에서도 새 기반에 맞춰 살펴볼 부분이 생긴 셈이다. TypeScript 7.1의 API 설명
그렇다고 7.1 베타가 나왔다는 사실만으로 모든 린터, 프레임워크 플러그인, 문서 생성기가 이미 대응했다고 판단할 수는 없다.
앱의 .ts 파일을 검사하는 명령은 잘 돌아가는데 다른 도구에서 오류가 생긴다면, 앱 코드의 타입 문제인지 그 도구의 컴파일러 API 의존성 문제인지 나눠봐야 한다. 패키지 버전 하나를 올렸다는 이유로 두 문제가 항상 함께 해결되지는 않는다.
먼저 우리 프로젝트의 ‘빌드’를 분해해보자
업그레이드를 검토할 때 가장 먼저 열어볼 파일은 성능 비교표가 아니라 package.json이다.
예를 들어 다음과 같은 스크립트가 있을 수 있다.
1 2 3 4 5 6 7{ "scripts": { "typecheck": "tsc --noEmit -p tsconfig.app.json", "bundle": "vite build", "build": "npm run typecheck && npm run bundle" } }
이 프로젝트에서 build는 타입 검사와 번들 생성을 순서대로 실행한다. vite build만 실행했을 때와 npm run build를 실행했을 때의 시간은 애초에 비교 대상이 다르다.
위 스크립트는 구조를 설명하기 위한 예제다. 실제 프로젝트의 설정 파일 이름에 맞춰야 하며, 이미 프로젝트 참조를 사용해 tsc -b로 검사하고 있다면 그 명령을 무작정 tsc --noEmit으로 바꾸지 않는 편이 좋다. 비교 실험을 하면서 검사 범위까지 바꾸면 무엇이 빨라졌는지 구분하기 어렵다.
현재 설치된 컴파일러를 확인하고 각 작업을 따로 실행하면 출발점을 잡을 수 있다.
1 2 3 4npx --no-install tsc --version npm run typecheck npm run bundle
실행 시간 측정은 CI의 단계별 기록이나 사용하는 측정 도구로 별도 남긴다. 중요한 것은 명령 자체보다 조건이다. 같은 커밋, 같은 의존성, 같은 설정에서 비교해야 한다.
타입 검사 시간을 줄이기 위해 일부 파일을 검사 대상에서 뺐거나 검사 옵션을 완화했다면, 그 결과를 컴파일러 업그레이드 효과로 적어서는 안 된다. 빨라졌지만 검사하는 일이 줄어든 것일 수 있다.
한 번 실행해본 숫자로 결론을 내리지 않는다
프론트엔드에서 체감하는 기다림에는 최소한 세 종류가 있다.
처음 프로젝트를 열었을 때의 대기, 이미 실행 중인 상태에서 파일 하나를 수정했을 때의 대기, CI처럼 정해진 작업을 처음부터 수행할 때의 대기다.
이 중 어떤 상황이 불편한지에 따라 실험도 달라져야 한다.
CI가 문제라면 실제 CI와 유사한 자원과 캐시 조건에서 전체 검사를 봐야 한다. 로컬에서 여러 번 실행해 따뜻해진 캐시의 결과만 가져오면 실제 배포 환경과 차이가 생긴다.
개발 중 오류 표시가 늦는 것이 문제라면 전체 검사 시간만으로는 부족하다. 평범한 컴포넌트 수정뿐 아니라 여러 곳에서 사용하는 공용 타입을 바꿨을 때도 확인해야 한다. 영향 범위가 작은 수정과 큰 수정은 같은 작업이 아니다.
편집기가 느리다면 터미널에서 실행하는 tsc와 편집기에서 사용하는 언어 서비스가 같은 버전인지도 확인해야 한다. 작업 공간에 새 패키지를 설치했다고 편집기의 구성까지 모두 자동으로 바뀌었다고 가정하지 않는 편이 안전하다. TypeScript 7의 편집기 연동은 사용하는 편집기의 지원 방식과 설정을 함께 확인해야 한다. 공식 편집기 연동 안내
이 과정을 거치면 “TypeScript가 느리다”는 넓은 표현이 조금 더 정확해진다.
“공용 타입을 수정하면 진단 결과가 돌아오기까지 오래 걸린다”거나 “편집기는 괜찮지만 CI의 전체 타입 검사가 배포를 막고 있다”는 식으로 바뀐다. 그래야 업그레이드 후에도 같은 문제를 해결했는지 확인할 수 있다.
빨라진 검사기가 복잡한 타입 설계를 대신 정리해주지는 않는다
타입 검사가 느리면 복잡한 제네릭부터 줄여야 한다는 말을 듣기 쉽다. 반대로 새 컴파일러가 빨라졌으니 타입 설계는 더 신경 쓰지 않아도 된다는 반응도 나올 수 있다.
둘 다 지나치게 단순하다.
앱에서 필요한 제약을 정확히 표현하느라 타입이 복잡해질 수는 있다. 특정 타입 패턴이 검사 비용을 얼마나 만드는지도 측정하기 전에는 단정하기 어렵다. 성능 문제가 있다는 이유만으로 안전장치를 없애는 것은 조심해야 한다.
다만 컴파일러의 속도와 사람이 타입을 이해하는 비용은 다르다.
컴포넌트를 사용할 때마다 긴 타입 인수를 넣어야 하고, 오류 메시지에서 실제 문제가 어디인지 찾기 어렵고, 사소한 구현 변경이 소비자 코드의 타입까지 흔든다면 검사 시간과 별개로 API 설계를 검토할 이유가 있다.
네이티브 컴파일러 전환으로 검사 대기가 줄어들더라도 이런 문제는 남는다. 좋은 타입 API는 컴파일러가 처리할 수 있는 가장 복잡한 관계를 표현한 것이 아니라, 필요한 제약을 사용자에게 납득할 수 있는 형태로 전달하는 API에 가깝다.
업그레이드와 타입 리팩터링을 같은 PR에 섞지 않는 것도 이 때문이다. 둘을 함께 바꿔버리면 오류가 사라진 이유와 속도가 달라진 이유를 추적하기 어려워진다. 먼저 도구 변경의 영향을 분리해서 확인하고, 그다음 설계를 손보는 편이 비교하기 쉽다.
베타를 도입할 이유가 있는 팀과 아직 없는 팀
2026년 11월 4일 기준, 여기서 다룬 7.1 발표는 베타다. 새 API가 필요한 도구를 만들거나, 현재 프로젝트가 네이티브 컴파일러 기반 도구와 맞물리는 지점을 검증하려는 팀이라면 시험할 이유가 있다.
반면 일반적인 앱 개발 팀이 속도 개선만 원한다면 “최신 베타이기 때문”만으로 7.1을 선택할 필요는 없다. 정식 버전에서 얻을 수 있는 개선과, 베타에서만 해결되는 문제가 무엇인지 먼저 나누는 것이 맞다.
베타를 검토하더라도 일상적인 기능 개발 브랜치와 분리하는 편을 권한다. 컴파일러 버전과 잠금 파일을 고정한 뒤 기존 타입 검사, 번들 생성, 테스트, 린트, 편집기 작업을 각각 확인한다. 하나가 통과했다고 나머지를 대신 검증한 것으로 보지 않는다.
그 과정에서 발견한 차이는 다음 두 가지로 나눠 기록하면 좋다.
- 소스 코드에 대한 진단이나 결과가 달라졌는가.
- 주변 도구가 새 컴파일러나 API를 다루는 과정에서 문제가 생겼는가.
첫 번째는 언어와 설정의 변화에 가까울 수 있고, 두 번째는 생태계 통합의 문제일 수 있다. 해결해야 할 주체와 방법이 달라진다.
가장 큰 변화는 ‘더 자주 검사할 수 있다’는 데 있을지도 모른다
타입 검사가 오래 걸리면 개발 방식도 그 대기 시간에 맞춰진다. 전체 검사는 CI에 맡기고, 로컬에서는 일부만 확인한다. 큰 변경을 어느 정도 모은 뒤 한 번에 돌리기도 한다. 오류를 발견하는 시점이 뒤로 밀린다.
검사 비용이 충분히 낮아지면 반대로 할 여지가 생긴다. 공용 타입을 바꾼 직후 전체 영향을 확인하고, PR을 올리기 전에 한 번 더 검사하고, 큰 리팩터링을 작은 단계로 나눠 진행할 수 있다.
이것은 컴파일러를 바꾸면 자동으로 생기는 효과는 아니다. 기다리는 시간이 줄어든 만큼 검증을 작업 가까이 가져와야 얻을 수 있는 효과다.
TypeScript의 네이티브 전환을 볼 때 관심을 가져야 할 숫자도 결국 그쪽에 있다. 발표의 ‘10배’를 우리 프로젝트가 그대로 재현했는가보다, 어떤 기다림이 줄었고 그 덕분에 무엇을 더 일찍 확인할 수 있게 됐는가.
업그레이드 후 타입 검사가 40초에서 8초로 줄었는데 전체 빌드는 100초에서 68초가 됐다면, 발표만큼 빨라지지 않았다고 실망할 일은 아니다. 줄어든 32초가 어디에 있었는지 알고, 아직 남은 60초가 무엇인지 구분할 수 있다면 다음 개선의 대상도 분명해진다.
2026년 11월 4일 기준 공식 자료를 바탕으로 작성했다. 본문의 40초·100초 예시는 성능 향상 범위를 설명하기 위한 가정이며, 특정 프로젝트의 실측 결과가 아니다.