“tsc 돌려놓고 커피 타러 간다"는 농담, 프론트엔드 개발자라면 한 번쯤 해보셨을 거예요. 그 농담의 수명이 이제 끝날지도 모르겠습니다. 2026년 7월 8일, Microsoft가 TypeScript 7.0을 정식 출시했습니다. 컴파일러와 언어 서비스 전체를 Go로 포팅한 네이티브 버전 — 프리뷰 시절 tsgo(@typescript/native-preview)라는 이름으로 미리 써보신 분도 있을 그것의 정식판입니다. 프리뷰만으로 이미 주간 850만 다운로드를 넘겼던 물건이에요. 발표 기준으로 대형 프로젝트 타입 체크가 8~12배 빨라졌습니다.
이 글에서 세 가지를 챙겨가실 수 있게 정리했습니다. 왜 이렇게 빨라졌는지, 업그레이드하면 내 tsconfig에서 무엇이 깨지는지, 그리고 지금 갈아타도 되는지(스포일러: 프로젝트 유형에 따라 답이 갈립니다). 작은 프로젝트에 직접 돌려본 실측도 붙였어요.
무엇이 발표됐나 — 3줄 요약#
- 컴파일러·언어 서비스 전체가 Go 네이티브로 다시 태어났습니다(내부 코드명 Corsa — 기존 JS 구현은 Strada). 밑바닥부터의 재작성이 아니라 기존 구현의 체계적 포팅이라, 타입 검사 의미는 6.0과 구조적으로 동일합니다.
- 실측 기준 8~12배: VSCode 코드베이스 타입 체크가 125.7초에서 10.6초가 됐습니다.
- 다만 설정 대청소가 함께 왔습니다.
strict가 기본값이 되고,target: es5같은 구식 옵션은 아예 에러가 됩니다 — 그래서 이 글 후반부가 필요해요.
왜 이렇게 빨라졌나#
속도의 출처는 세 갈래입니다.
첫째, 네이티브 코드. 지금까지 tsc는 TypeScript로 작성되어 Node.js 위에서 돌았습니다. 매 실행마다 JS 엔진을 깨우고, 코드를 해석하고, JIT가 데워질 때까지 기다렸죠. Go로 컴파일된 바이너리는 그 과정 전체가 사라집니다. 왜 하필 Go였냐는 질문에 팀은 “기존 구현과의 구조적 호환성"을 이유로 들었어요 — 다른 언어였다면 포팅이 아니라 재작성이 됐을 거라는 거죠. 그리고 그 선택 덕분에 ‘검사 결과가 6.0과 동일하다’는 보증이 가능해졌습니다. 커뮤니티에서도 “자기 언어로 자기 컴파일러를 짜야 한다는 셀프호스팅 도그마를 버린 실용적 결정"이라는 평이 많았고요.
둘째, 공유 메모리 멀티스레딩. 기존 컴파일러는 사실상 싱글스레드였습니다. TS 7은 타입 체커를 병렬로 돌립니다 — 기본값으로 4개의 체커(--checkers 4)가 프로그램을 나눠 검사하고, --singleThreaded로 끌 수도 있어요. 코어가 남으면 더 밀어붙일 수도 있습니다 — --checkers 8이면 VSCode 기준 16.7배까지 올라갑니다. 8코어가 놀고 있던 시대의 종료입니다.
덤으로 --watch 모드도 파일 워처(Parcel의 워처를 Go로 포팅)를 새로 깔아 다시 지어졌습니다 — 저장할 때마다 도는 그 루프가 통째로 빨라진 거예요.
셋째, 에디터의 세대교체. 언어 서버가 LSP(Language Server Protocol) 기반으로 재구축됐습니다. VS Code에서 대형 프로젝트를 열 때 에러 표시까지 17.5초 걸리던 것이 1.3초로 — 컴파일보다 이쪽 체감이 더 클 수 있습니다. 언어 서버의 명령 실패는 80%, 크래시는 60% 줄었다고 하고요.
벤치마크, 체감으로 읽기#
공식 발표의 실측 수치입니다.
| 프로젝트 | TS 6.0 | TS 7.0 | 배속 |
|---|---|---|---|
| VSCode | 125.7s | 10.6s | 11.9x |
| Sentry | 139.8s | 15.7s | 8.9x |
| Bluesky | 24.3s | 2.8s | 8.7x |
| Playwright | 12.8s | 1.47s | 8.7x |
| Tldraw | 11.2s | 1.46s | 7.7x |
숫자가 커서 감이 안 온다면 이렇게 읽어보세요. 2분짜리 타입 체크는 PR을 올리고 딴짓하게 만드는 시간이고, 10초는 자리에서 기다리는 시간입니다. CI에서는 돈 단위로 바뀌죠 — Slack은 타입 체크 CI가 7.5분에서 1.25분이 됐고, Microsoft News 서비스 팀은 월 400시간의 CI 시간을 아꼈다고 합니다. 메모리도 6~26% 줄었어요.
여러분이 이 문단을 읽는 동안 VSCode 전체의 타입 체크가 끝났습니다. 예전엔 문단이 아니라 챕터였습니다.
이런! 커피 한잔 하면서 농땡이 피울 시간이 사라져버렸습니다!! ㅜㅜ
작은 프로젝트에서는? 직접 재봤습니다#
발표 벤치마크는 전부 대형 코드베이스라, 평범한 크기에서는 어떤지 이 블로그의 테스트 시리즈 데모 앱(파일 763개, React+Vitest 소형 프로젝트)으로 직접 재봤습니다. 같은 머신, 각 3회 측정입니다.
# TS 6.0.3
$ time tsc6 -p tsconfig.test.json --noEmit # 0.57s / 0.58s / 0.58s
# TS 7.0.2 (기본, 체커 4)
$ time tsc -p tsconfig.test.json --noEmit # 0.09s / 0.09s / 0.10s
# TS 7.0.2 --singleThreaded
$ time tsc ... --singleThreaded # 0.17s / 0.16s / 0.17s소형 프로젝트에서도 약 6배. 흥미로운 건 분해입니다 — 싱글스레드로만 돌려도 3.5배가 나오는데(네이티브 코드+기동 오버헤드 제거의 몫), 멀티스레딩이 나머지를 벌어줍니다. “우리 프로젝트는 작아서 상관없겠지” 하셨다면, 0.6초와 0.1초의 차이는 watch 모드와 에디터 반응성에서 계속 복리로 쌓입니다.
달라진 것들 — 내 tsconfig가 놀라지 않게#
속도는 공짜지만, 업그레이드는 공짜가 아닙니다. TS 7은 낡은 기본값과 옵션을 대청소했어요. 기본값이 바뀐 것부터:
| 옵션 | 6.0 기본값 | 7.0 기본값 |
|---|---|---|
strict | false | true |
module | 상황별 | esnext |
target | es5 계열 | esnext 직전 안정 ES |
types | 자동 수집 | [] (명시 필수) |
rootDir | 계산값 | ./ |
noUncheckedSideEffectImports | false | true |
그리고 아예 에러가 되는 것들 — 만나면 이렇게 처방하세요.
target: es5를 지원하지 않는다는 에러 → 대상을es2017이상으로. ES5 출력이 정말 필요하면 트랜스파일은 별도 도구(babel/swc)에 맡기는 시대입니다.baseUrl을 모른다는 에러 →paths의 기준이 tsconfig 위치로 통일됐습니다.baseUrl줄을 지우고paths를 상대 기준으로 조정하세요.moduleResolution: node(node10) 에러 →bundler또는nodenext로. Vite 계열 프로젝트는 대부분 이미bundler라 무풍지대입니다.downlevelIteration에러 → ES5 시대의 이터레이터 변환 옵션입니다. target을 올렸다면 그냥 지우면 됩니다.amd/umd/systemjs모듈 에러 → 이 포맷들이 필요한 레거시라면 6.x에 머무는 게 맞습니다(아래 병행 전략 참고).- 전역 타입이 갑자기 사라졌다면 →
types기본값 변화입니다."types": ["node", "vitest/globals"]처럼 쓰는 것만 명시하세요. - JS 파일 검사에서 JSDoc
@enum, 후위!등 Closure 스타일 문법 지원이 사라졌습니다.
소소하지만 반가운 변화 하나 — 템플릿 리터럴에서 이모지 같은 멀티바이트 문자가 이제 UTF-16 서로게이트로 쪼개지지 않고 한 글자로 다뤄집니다.
접근성 관점에서 다섯 가지#
이 블로그답게, 발표문이 크게 다루지 않은 각도를 짚고 갑니다.
가장 큰 수혜자는 보조기술로 코딩하는 개발자일 수 있습니다. 언어 서버 크래시가 60% 줄고 에디터 첫 진단이 17.5초에서 1.3초가 됐다는 수치 — 비장애 개발자에게는 “쾌적함"이지만, 스크린 리더로 코딩하는 개발자에게는 체감의 차원이 다릅니다. 화면의 스피너는 눈으로라도 보이지만, 진단이 조용히 늦어지는 언어 서버는 스크린 리더 사용자에게 아무 신호도 주지 않는 침묵이거든요. 도구가 빠르고 안정적이라는 것은 그 자체로 개발 환경의 접근성입니다.
strict: true 기본화는 접근성 코드의 단골 버그를 잡아줍니다. 포커스 관리 코드를 떠올려보세요 — ref.current.focus()에서 current가 null인 순간, 키보드 사용자의 포커스는 허공으로 떨어집니다. strict 모드의 널 체크는 이런 코드를 컴파일 타임에 막아서 ref.current?.focus()로 쓰게 만들죠. 지금까지는 “strict 켜기 귀찮아서” 이 안전망 없이 달리는 프로젝트가 많았는데, 이제 기본값입니다.
서로게이트 변경에도 숨은 수혜가 있습니다. 문자열을 자르다 이모지가 반토막 나면, 화면엔 깨진 네모가 뜨고 스크린 리더는 의미 없는 문자를 읽습니다. 멀티바이트 문자를 한 단위로 다루는 이번 변경은 이런 사고가 날 표면적 자체를 줄여줘요.
빠른 피드백 루프는 인지적 접근성이기도 합니다. 2분짜리 타입 체크는 단순한 지연이 아니라 집중의 단절이에요 — 기다리다 다른 탭을 열고, 돌아오면 아까의 맥락을 다시 쌓아야 하죠. 주의 전환 비용이 특히 큰 개발자(ADHD 등)에게 이 단절은 남들보다 훨씬 비쌉니다. 저장 즉시 결과가 오는 루프는 그 비용 자체를 없애줍니다.
아낀 CI 시간은 접근성 검사의 예산이 됩니다. “파이프라인이 이미 느려서 axe 스캔까지는 못 얹어요"라는 팀, 많습니다. 타입 체크가 분 단위에서 초 단위로 내려온 오늘이, 그 아낀 시간으로 접근성 자동 검사를 파이프라인에 넣자고 말 꺼내기 가장 좋은 날이에요.
지금 갈아타도 될까 — 판단 기준#
바로 가도 좋은 경우. 일반적인 TS/React/Node 프로젝트, 특히 CI 타입 체크가 분 단위라 고통받는 팀이라면 지금이 적기입니다. 타입 검사 의미가 6.0과 동일하게 유지되는 포팅이라, 위 tsconfig 정리만 통과하면 코드 쪽 서프라이즈는 적은 편이에요. 검증 규모도 안심 재료입니다 — Microsoft 내부의 Office·Teams·Xbox 코드베이스와 Bloomberg·Canva·Figma·Google·Slack 등 외부 13개 이상 조직에서 미리 두들겨본 뒤의 정식 출시거든요.
기다리는 게 맞는 경우. TS 7.0은 공개 API 없이 출시됐습니다(새 API는 7.1 예정). 그래서 TypeScript를 라이브러리로 임베드하는 도구들 — Vue·Svelte·Astro·MDX·Angular 템플릿의 타입 지원(Volar 계열), 그리고 typescript-eslint — 은 아직 6.x에 묶여 있습니다. 이런 프레임워크가 주력이라면 7.1 소식까지 관전이 정답입니다.
typescript-eslint는 사실상 모든 프로젝트가 쓰니 “그럼 아무도 못 가는 것 아니냐” 싶지만, 그렇진 않습니다. lint는 6.x 기반으로 그대로 돌리고, tsc 타입 체크와 에디터만 7로 올리는 조합이 가능해요 — 아래 병행 전략이 정확히 그 시나리오를 위한 겁니다.
둘 다인 경우 — 병행 전략. 6.x가 @typescript/typescript6 패키지로 계속 제공되므로, npm 별칭으로 나란히 설치할 수 있습니다.
{
"devDependencies": {
"typescript": "^7.0.2",
"@typescript/typescript6": "^6.0.2"
}
}이러면 실행 파일이 두 개 나란히 생깁니다 — tsc를 부르면 7이, tsc6를 부르면 6이 돌아요. 예컨대 CI의 타입 체크는 빠른 7로 돌리고, 아직 6에 묶인 typescript-eslint 쪽 작업은 그대로 두는 식으로 상황별로 골라 쓸 수 있습니다. 한 가지 직접 밟아본 함정 — 설치 구성에 따라 node_modules/.bin/tsc가 6 쪽 바이너리로 덮이는 경우가 있었습니다. 병행 설치 후엔 npx tsc --version으로 7이 맞는지 꼭 확인하세요. (전 이걸로 첫 벤치마크를 통째로 다시 돌렸습니다.)
에디터는 더 간단합니다. VS Code 명령 팔레트에서 “Enable/Disable TypeScript 7 Language Server"로 전환하면 되고, WebStorm 등 다른 에디터는 LSP로 붙습니다.
10분 마이그레이션 워크스루#
실제 순서는 이렇게 됩니다.
# 1. 설치 (출시 직후엔 latest 태그 전파 전일 수 있으니 버전 명시가 안전)
npm i -D typescript@7
# 2. 버전 확인 — 7.0.x가 맞는지
npx tsc --version
# 3. 일단 돌려보기
npx tsc --noEmit3번에서 에러가 나면 대부분 위 처방전 목록 중 하나입니다. 데모 앱 기준으로는 types 명시(vitest/globals)와 이미 bundler였던 모듈 해석 덕에 수정 없이 통과했고, 여러분 프로젝트도 최근 Vite/Next 템플릿 기반이라면 비슷할 확률이 높습니다. src/ 구조에서 rootDir 에러가 나면 "rootDir": "./src" 한 줄이면 되고요.
마지막으로 전후 시간을 재서 팀에 공유하세요 — 숫자가 도입 논의를 끝내줍니다.
한 장 요약#
- TypeScript 7 = 컴파일러·언어 서비스의 Go 네이티브 포팅(2026-07-08 정식 출시) — 타입 검사 의미는 6.0과 동일
- 속도는 세 갈래에서: 네이티브 코드 + 체커 4개 멀티스레딩 + LSP 에디터 — 대형 8~12배, 소형(직접 실측)도 약 6배
strict: true·types: []등 기본값 변경 +es5/baseUrl/node10등 구식 옵션 제거 — 에러별 처방은 본문 표- 언어 서버의 속도·안정은 보조기술로 코딩하는 개발자에게 더 큰 개선 — 도구의 접근성도 접근성
- 7.0엔 공개 API가 없다 — Vue·Svelte·Astro·Angular 템플릿과 typescript-eslint는 7.1까지 관전(단, lint만 6으로 두는 병행 가능)
- 병행 설치(
@typescript/typescript6) 가능하되,.bin/tsc가 어느 쪽인지--version으로 확인할 것
자주 묻는 질문#
TypeScript 6.x는 언제까지 쓸 수 있나요?
@typescript/typescript6 패키지로 계속 제공됩니다. 공개 API가 필요한 도구 생태계가 아직 6.x에 의존하고 있어서, 당분간 유지보수는 이어질 수밖에 없는 구조예요. 다만 신기능의 무게중심은 7로 넘어갔습니다.
기존 프로젝트를 꼭 올려야 하나요? 급할 것 없습니다. 6.x가 갑자기 멈추는 게 아니니까요. 다만 CI에서 타입 체크가 분 단위라면, 업그레이드 비용(대부분 tsconfig 몇 줄)보다 절약이 훨씬 큽니다 — 이 글의 처방전대로면 보통 10분 안쪽이에요.
Vite·esbuild로 빌드하는데도 의미가 있나요?
네, 오히려 정확히 그 구성이 수혜자입니다. 번들러가 트랜스파일을 맡는 프로젝트에서 tsc의 역할은 --noEmit 타입 검사뿐인데, 그 검사가 바로 이번에 8~12배 빨라진 부분이거든요. 에디터의 반응 속도 개선은 빌드 도구와 무관하게 모두가 받고요.
관전 포인트는 7.1#
정리하면 — 일반 앱 프로젝트라면 지금 올려서 속도를 챙기고, 프레임워크 도구 체인에 얹혀 있다면 7.1의 새 API가 관전 포인트입니다. 6.x는 @typescript/typescript6으로 당분간 유지보수되니 서두르다 넘어질 이유는 없어요.
참고로 이 블로그의 테스트 환경 세팅 글에서 다룬 typecheck 스크립트 같은 것들이 정확히 이번 수혜자입니다 — CI의 모든 tsc --noEmit이 오늘부터 몇 배씩 빨라질 수 있으니까요.
10년 넘게 “느리지만 정확한 친구"였던 tsc가 이제 빠르기까지 합니다. 커피는… 그냥 마시고 싶을 때 마시러 갑시다.
출처
- Announcing TypeScript 7.0 (Microsoft, 2026-07-08)
- Announcing TypeScript 7.0 RC
- TypeScript 7 native preview in Visual Studio 2026
- GeekNews 논의 스레드 — 한국 개발자 커뮤니티의 반응과 도입 경험담