# 타입스크립트 7 정식 출시 — 10배 빨라진 네이티브 컴파일러, 지금 갈아타도 될까

> Go로 다시 태어난 TypeScript 7이 정식 출시됐습니다. VSCode 125초→10초 실측 벤치마크, strict 기본값 등 달라진 설정, 6.x 병행 설치 마이그레이션까지 — 지금 갈아타도 되는지 판단 기준을 정리했습니다.

**Published:** 2026-07-09 | **Updated:** 2026-07-09

---


"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% 줄었다고 하고요.

{{< img src="images/contents/corsa-vs-strada.png" alt="TypeScript 6 Strada와 7 Corsa의 구조 비교 다이어그램 - 왼쪽 Strada는 Node.js 위에서 싱글스레드로 타입 체크를 수행하고, 오른쪽 Corsa는 Go 네이티브 바이너리가 4개의 체커 스레드로 병렬 검사하며 LSP로 에디터와 연결되는 구조가 그려져 있습니다" >}}

---

## 벤치마크, 체감으로 읽기

공식 발표의 실측 수치입니다.

| 프로젝트 | 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 |

{{< img src="images/contents/ts7-benchmarks.png" alt="TypeScript 6과 7의 타입 체크 시간을 비교한 가로 막대 차트 - VSCode 125.7초에서 10.6초, Sentry 139.8초에서 15.7초 등 다섯 개 프로젝트 모두에서 8배에서 12배 단축된 것을 보여줍니다" >}}

숫자가 커서 감이 안 온다면 이렇게 읽어보세요. 2분짜리 타입 체크는 **PR을 올리고 딴짓하게 만드는 시간**이고, 10초는 **자리에서 기다리는 시간**입니다. CI에서는 돈 단위로 바뀌죠 — Slack은 타입 체크 CI가 7.5분에서 1.25분이 됐고, Microsoft News 서비스 팀은 월 400시간의 CI 시간을 아꼈다고 합니다. 메모리도 6~26% 줄었어요.

여러분이 이 문단을 읽는 동안 VSCode 전체의 타입 체크가 끝났습니다. 예전엔 문단이 아니라 챕터였습니다.

이런! 커피 한잔 하면서 농땡이 피울 시간이 사라져버렸습니다!! ㅜㅜ

{{< img src="images/contents/ts7-coffee-break.png" alt="커피를 든 개발자 카툰 - 모니터에는 tsc가 10.6초 만에 0 에러로 끝났다는 터미널 출력이 떠 있고, 방금 탄 커피잔을 든 개발자가 시무룩한 표정과 땀방울로 '아니, 벌써 끝났다고…? 나 방금 물 부었는데…'라고 말하는 장면. 농땡이의 공식 명분을 잃었다는 캡션이 달려 있습니다" >}}

### 작은 프로젝트에서는? 직접 재봤습니다

발표 벤치마크는 전부 대형 코드베이스라, 평범한 크기에서는 어떤지 이 블로그의 [테스트 시리즈 데모 앱](https://github.com/IsaacEryn/frontend-testing-lab)(파일 763개, React+Vitest 소형 프로젝트)으로 직접 재봤습니다. 같은 머신, 각 3회 측정입니다.

```bash
# 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 서로게이트로 쪼개지지 않고 한 글자로 다뤄집니다.

---

## 접근성 관점에서 다섯 가지

이 블로그답게, 발표문이 크게 다루지 않은 각도를 짚고 갑니다.

{{< img src="images/contents/ts7-silent-diagnostics.png" alt="언어 서버 지연이 개발자에 따라 다르게 체감되는 것을 보여주는 2패널 비교 - 왼쪽은 화면의 스피너를 눈으로 확인하며 기다리는 개발자, 오른쪽은 아무 신호 없는 침묵 속에서 진단을 기다리는 스크린 리더 사용 개발자, 아래에는 TypeScript 7이 그 대기 자체를 17.5초에서 1.3초로 줄였다는 문구가 있습니다" >}}

**가장 큰 수혜자는 보조기술로 코딩하는 개발자일 수 있습니다.** 언어 서버 크래시가 60% 줄고 에디터 첫 진단이 17.5초에서 1.3초가 됐다는 수치 — 비장애 개발자에게는 "쾌적함"이지만, 스크린 리더로 코딩하는 개발자에게는 체감의 차원이 다릅니다. 화면의 스피너는 눈으로라도 보이지만, 진단이 조용히 늦어지는 언어 서버는 스크린 리더 사용자에게 **아무 신호도 주지 않는 침묵**이거든요. 도구가 빠르고 안정적이라는 것은 그 자체로 개발 환경의 접근성입니다.

**`strict: true` 기본화는 접근성 코드의 단골 버그를 잡아줍니다.** 포커스 관리 코드를 떠올려보세요 — `ref.current.focus()`에서 `current`가 null인 순간, 키보드 사용자의 포커스는 허공으로 떨어집니다. strict 모드의 널 체크는 이런 코드를 컴파일 타임에 막아서 `ref.current?.focus()`로 쓰게 만들죠. 지금까지는 "strict 켜기 귀찮아서" 이 안전망 없이 달리는 프로젝트가 많았는데, 이제 기본값입니다.

**서로게이트 변경에도 숨은 수혜가 있습니다.** 문자열을 자르다 이모지가 반토막 나면, 화면엔 깨진 네모가 뜨고 스크린 리더는 의미 없는 문자를 읽습니다. 멀티바이트 문자를 한 단위로 다루는 이번 변경은 이런 사고가 날 표면적 자체를 줄여줘요.

**빠른 피드백 루프는 인지적 접근성이기도 합니다.** 2분짜리 타입 체크는 단순한 지연이 아니라 **집중의 단절**이에요 — 기다리다 다른 탭을 열고, 돌아오면 아까의 맥락을 다시 쌓아야 하죠. 주의 전환 비용이 특히 큰 개발자(ADHD 등)에게 이 단절은 남들보다 훨씬 비쌉니다. 저장 즉시 결과가 오는 루프는 그 비용 자체를 없애줍니다.

**아낀 CI 시간은 접근성 검사의 예산이 됩니다.** "파이프라인이 이미 느려서 axe 스캔까지는 못 얹어요"라는 팀, 많습니다. 타입 체크가 분 단위에서 초 단위로 내려온 오늘이, 그 아낀 시간으로 [접근성 자동 검사를 파이프라인에 넣자](/series/프론트엔드-테스트-제대로-하기/)고 말 꺼내기 가장 좋은 날이에요.

---

## 지금 갈아타도 될까 — 판단 기준

{{< img src="images/contents/ts7-decision.png" alt="TypeScript 7 도입 여부 의사결정 플로차트 - Vue·Svelte·Astro·Angular 템플릿 의존이면 7.1까지 대기, 레거시 모듈 포맷이 필요하면 6.x 유지 또는 병행, 일반 TS·React·Node 프로젝트면 지금 업그레이드라는 세 갈래 경로를 보여줍니다" >}}

**바로 가도 좋은 경우.** 일반적인 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 별칭으로 나란히 설치할 수 있습니다.

```json
{
  "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분 마이그레이션 워크스루

실제 순서는 이렇게 됩니다.

```bash
# 1. 설치 (출시 직후엔 latest 태그 전파 전일 수 있으니 버전 명시가 안전)
npm i -D typescript@7

# 2. 버전 확인 — 7.0.x가 맞는지
npx tsc --version

# 3. 일단 돌려보기
npx tsc --noEmit
```

3번에서 에러가 나면 대부분 위 처방전 목록 중 하나입니다. 데모 앱 기준으로는 `types` 명시(`vitest/globals`)와 이미 `bundler`였던 모듈 해석 덕에 수정 없이 통과했고, 여러분 프로젝트도 최근 Vite/Next 템플릿 기반이라면 비슷할 확률이 높습니다. `src/` 구조에서 `rootDir` 에러가 나면 `"rootDir": "./src"` 한 줄이면 되고요.

마지막으로 전후 시간을 재서 팀에 공유하세요 — 숫자가 도입 논의를 끝내줍니다.

---

## 한 장 요약

{{< img src="images/contents/ts7-summary-card.png" alt="TypeScript 7 한 장 요약 카드 - 다섯 개 항목으로 구성: 1 무엇(같은 검사 다른 엔진, Go 네이티브 포팅) 2 얼마나(대형 8~12배, VSCode 125.7초에서 10.6초) 3 주의(strict 기본화 등 설정 대청소) 4 대기(7.0엔 공개 API 없음, Vue·typescript-eslint는 7.1까지) 5 병행(typescript6 별칭으로 tsc와 tsc6 공존, .bin 확인 필수)" >}}

- 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`으로 당분간 유지보수되니 서두르다 넘어질 이유는 없어요.

참고로 이 블로그의 [테스트 환경 세팅 글](/posts/frontend-testing-setup-vitest/)에서 다룬 `typecheck` 스크립트 같은 것들이 정확히 이번 수혜자입니다 — CI의 모든 `tsc --noEmit`이 오늘부터 몇 배씩 빨라질 수 있으니까요.

10년 넘게 "느리지만 정확한 친구"였던 tsc가 이제 빠르기까지 합니다. 커피는... 그냥 마시고 싶을 때 마시러 갑시다.

**출처**
- [Announcing TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) (Microsoft, 2026-07-08)
- [Announcing TypeScript 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- [TypeScript 7 native preview in Visual Studio 2026](https://developer.microsoft.com/blog/typescript-7-native-preview-in-visual-studio-2026)
- [GeekNews 논의 스레드](https://news.hada.io/topic?id=31249) — 한국 개발자 커뮤니티의 반응과 도입 경험담