Skip to content
←

필사 모드: TypeScript 7이 GA됐다 — 8~12배는 진짜지만, 오늘 못 옮기는 사람들이 있다

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 7월 8일, tsgo는 그냥 tsc가 됐다

2026년 7월 8일, TypeScript 7.0이 GA됐습니다. 1년 넘게 미리보기로 돌던 Go 네이티브 포트가 정식 릴리스에 들어왔습니다.

지난 1년간 이 프로젝트를 따라온 사람이라면 tsgo라는 이름에 익숙할 겁니다. 별도 패키지(@typescript/native-preview)에서 별도 바이너리로 나이틀리가 나왔고, 기존 tsc와 나란히 돌려 보는 게 표준 절차였습니다. GA에서 그 구도가 사라졌습니다. 공식 발표문에는 tsgo라는 단어가 한 번도 나오지 않습니다. 대신 이렇게 적혀 있습니다 — npm install -D typescript을 하면 "새로운 tsc 실행 파일"이 들어온다고.

즉 네이티브 포트는 옵트인이 아니라 기본값입니다. npm 레지스트리를 직접 확인해 보면 typescript의 latest 태그는 7.0.2이고 발행일은 2026년 7월 8일 — 발표문의 GA 날짜와 정확히 일치합니다. 그리고 @typescript/native-preview의 마지막 발행은 7월 7일, GA 하루 전에서 멈춰 있습니다. 나이틀리는 이제 typescript@next로 넘어왔습니다(현재 7.1.0-dev 계열).

릴리스 타임라인은 이렇게 흘렀습니다 — 베타 4월 21일, RC 6월 18일, GA 7월 8일.

이 글은 "Go 포트가 빠르다"를 다시 설명하는 글이 아닙니다. 그건 TypeScript 6과 tsc-go 포트 편에서 미리보기 시절 기준으로 이미 다뤘고, 솔직히 말하면 그때 예상했던 배포 형태(tsc --go 같은 백엔드 플래그, 한 메이저 버전이 두 컴파일러를 같이 출하하는 그림)와 실제 GA는 다릅니다. 실제로는 메이저 버전 자체가 갈렸습니다 — 6은 JS 구현, 7은 Go 구현입니다. 이 글은 GA에서 확정된 사실만 놓고, 헤드라인 숫자가 가리는 실제 이전 비용을 봅니다.

숫자부터 정확히 — 무엇을 잰 것인가

발표문의 표현은 "10x faster native port"이고, 본문의 조건부 문장은 이렇습니다 — 네이티브 코드 속도, 공유 메모리 멀티스레딩, 여러 최적화가 전체 빌드(full builds)에서 통상 8배에서 12배 사이의 속도 향상을 낸다.

Microsoft가 직접 측정해 공개한 전체 빌드 시간표입니다. 이건 벤더 자체 보고 수치이고, 같은 머신에서 TypeScript 7의 기본 설정으로 잰 것입니다.

코드베이스      TS 6       TS 7       속도 향상
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

주목할 점 두 가지. 첫째, 표의 하한은 7.7배로 "8~12배"라는 자기 진술보다 살짝 낮습니다. 둘째, 속도 향상이 코드베이스마다 다릅니다 — vscode의 11.9배와 tldraw의 7.7배는 1.5배 차이입니다. 큰 코드베이스일수록 병렬화 이득이 커지는 경향이 보입니다.

메모리도 같이 공개됐는데, 여기가 오히려 기대를 낮춰야 하는 부분입니다.

코드베이스      TS 6      TS 7      변화
vscode         5.2GB     4.2GB     -18%
sentry         4.9GB     4.6GB      -6%
bluesky        1.8GB     1.3GB     -26%
playwright     1.0GB     0.9GB     -11%
tldraw         0.6GB     0.5GB     -15%

미리보기 시절에 돌던 "메모리 절반" 이야기와는 다릅니다. 실제 GA 수치는 6%에서 26% 감소이고, sentry는 사실상 거의 그대로입니다. 속도가 한 자릿수 배율로 뛴 것에 비하면 메모리는 완만한 개선입니다. 발표문 자신도 "통상 전체 빌드에 걸쳐 더 적은 총 메모리를 요구한다"는 정도로만 말하고, 그 이상을 주장하지 않습니다.

에디터 쪽 숫자도 있습니다. VS Code 코드베이스에서 에러가 있는 파일을 열었을 때 첫 에러가 보이기까지, 같은 컴퓨터에서 예전에는 약 17.5초가 걸렸고 TypeScript 7에서는 1.3초 미만 — 13배 이상 빠르다는 것입니다.

기업 사례로 보고된 수치들은 한 단계 더 조심해서 읽어야 합니다. 이건 Microsoft가 각 팀에게서 전해 들었다고 밝힌 값들입니다.

  • Slack — CI 타입 체크 시간이 약 7.5분에서 1.25분으로. 머지 큐 시간의 40%가 사라졌다고. 이전에는 에디터의 언어 서버 로드 시간 때문에 로컬 개발이 거의 "쓸 수 없는" 수준이라 엔지니어들이 전체 타입 체크를 CI에 맡겼는데, 이제 같은 코드베이스가 몇 초 만에 로드된다고 합니다.
  • Canva — 에디터에서 첫 에러를 보기까지 약 58초에서 약 4.8초로.
  • Vanta — 가장 큰 프로젝트 하나에서 최대 9배.
  • Microsoft News Services 팀 — CI 빌드 대기로 쓰던 시간을 월 400시간 절약.

그리고 안정성 수치. Microsoft는 자체 데이터 인사이트 기준으로 7.0의 새 언어 서버가 6.0 대비 실패하는 언어 서버 커맨드를 80% 이상, 서버 크래시를 60% 이상 줄였다고 밝혔습니다. 이건 텔레메트리 기반 자체 측정이고 외부에서 재현할 수 있는 종류의 숫자는 아닙니다.

"10배"에는 손잡이가 달려 있다 — --checkers

여기가 GA에서 새로 드러난, 그리고 대부분의 요약 기사가 빠뜨린 부분입니다. 저 벤치마크 숫자는 특정 병렬화 설정의 결과입니다.

TypeScript 7.0은 파싱, 타입 체크, 이미터를 병렬로 돌립니다. 파싱과 이미팅은 파일 단위로 거의 독립적이라 병렬화가 잘 먹습니다. 문제는 타입 체크입니다 — 파일 간 의존이 복잡하고, 대부분의 파일이 같은 전역 스코프와 의존성의 타입 정보에 기댑니다. 게다가 타입 체크는 때때로 프로그램 내 정보의 상대적 순서에 의존해서, 결과를 동일하게 유지하려면 항상 같은 순서로 체크해야 합니다.

그래서 TypeScript 7은 고정된 수의 타입 체커 워커를 만듭니다. 각 워커가 자기만의 세계관을 갖고, 공통 작업 일부를 중복해서 하되, 같은 입력이면 항상 동일하게 파일을 나눠 동일한 결과를 냅니다.

기본 워커 수는 4입니다. 앞의 표는 전부 기본값인 --checkers 4로 잰 것이고, 발표문은 같은 머신에서 --checkers 8로 다시 잰 표를 나란히 실었습니다.

코드베이스      TS 6       TS 7 (--checkers 8)    속도 향상
vscode         125.7s     7.51s                  16.7x
sentry         139.8s    12.08s                  11.6x
bluesky         24.3s     2.01s                  12.1x
playwright      12.8s     1.16s                  11x
tldraw          11.2s     1.06s                  10.6x

체커를 8로 올리면 vscode가 16.7배까지 갑니다. 하지만 이건 공짜가 아닙니다 — 발표문의 표현대로 체커를 늘리면 통상 메모리 사용량 증가라는 대가가 따릅니다. 그리고 결과는 프로젝트와 머신에 따라 달라집니다.

방향은 반대로도 갑니다. CPU 코어와 메모리가 적은 환경 — 발표문이 직접 예로 든 게 CI 러너입니다 — 에서는 오히려 이 값을 낮춰서 불필요한 오버헤드를 피하는 편이 나을 수 있습니다. --checkers 1까지 지정할 수 있고, 그러면 타입 체크가 사실상 단일 스레드가 되면서 중복 작업이 사라집니다.

여기서 실무적으로 가장 중요한 문장이 나옵니다.

드문 경우지만, --checkers 수를 바꾸면 순서 의존적인 결과가 드러날 수 있습니다.

즉 체커 수가 진단 결과에 영향을 줄 수 있다는 것을 팀이 직접 인정한 것입니다. 발표문의 권고는 빌드 환경 전반에 고정된 체커 수를 지정해서 모두가 같은 결과를 받게 하라는 것이고, 다만 그건 팀 재량이라고 덧붙입니다. 로컬은 8, CI는 2 같은 식으로 제각각 두면 "내 머신에서는 통과하는데 CI에서는 에러"가 나올 여지가 원리상 열려 있다는 뜻입니다. 저라면 tsconfig.json이든 CI 스크립트든 한 곳에 못을 박아 두겠습니다.

관련 플래그가 둘 더 있습니다. --builders는 --build 모드에서 동시에 돌릴 프로젝트 참조 빌더 수를 조절합니다(모노레포용). 주의할 건 --checkers와 곱셈으로 작용한다는 점입니다 — 발표문의 예시 그대로, --checkers 4 --builders 4는 최대 16개의 타입 체커가 동시에 도는 걸 허용하고, 이건 과할 수 있습니다. --singleThreaded는 병렬화를 아예 끕니다(디버깅, 6과 7의 성능 비교, 외부에서 병렬 빌드를 조율하는 경우, 자원이 아주 빠듯한 환경용). --checkers와 --builders는 현재 실험적(experimental) 플래그로 소개돼 있습니다.

--builders는 --checkers와 달리 수를 바꿔도 결과가 달라지지 않아야 한다고 명시돼 있습니다. 대신 프로젝트 참조 빌드는 근본적으로 프로젝트 의존 그래프에 병목이 걸립니다.

진짜 비용 (1) — 6의 폐기 목록이 전부 하드 에러가 됐다

이제 돈을 내는 부분입니다.

호환성 자체는 좋습니다. 발표문의 조건부 문장은 이렇습니다 — stableTypeOrdering 플래그를 켜고 ignoreDeprecations 플래그를 설정하지 않은 상태에서 TypeScript 6.0으로 깨끗하게 컴파일되는 코드는 사실상 무엇이든 7.0에서 동일하게 컴파일돼야 한다.

문제는 저 전제입니다. 7.0은 6.0의 새 기본값을 그대로 채택하고, 6.0에서 폐기 예고된 플래그와 구문에 대해 하드 에러를 냅니다. 발표문 스스로 인정하듯 "6.0은 상대적으로 아직 새롭고, 많은 프로젝트가 그 새 동작에 적응해야" 합니다. 그래서 공식 권고는 7로 바로 뛰지 말고 6.0을 먼저 도입해서 전환을 쉽게 만들라는 것입니다.

기본값 변경부터 봅시다.

strict                        -> 기본 true
module                        -> 기본 esnext
target                        -> esnext 바로 앞의 안정 ECMAScript 버전
noUncheckedSideEffectImports  -> 기본 true
libReplacement                -> 기본 false
stableTypeOrdering            -> 기본 true, 그리고 끌 수 없음
rootDir                       -> 기본 ./ (내부 소스 디렉터리는 명시해야 함)
types                         -> 기본 [] (예전 동작은 ["*"])

발표문이 "가장 놀랄 만한" 변경으로 꼽은 건 rootDir과 types 둘입니다. 둘 다 완화는 쉽습니다. tsconfig.json이 src 같은 디렉터리 바깥에 있는 프로젝트는 디렉터리 구조를 유지하려면 rootDir을 명시하면 됩니다.

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

types 쪽은 전역 선언에 의존하는 프로젝트가 필요한 걸 직접 나열해야 합니다.

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

무해해 보이지만 이게 조용한 지뢰입니다. types 기본값이 []가 되면 자동 탐색이 꺼집니다 — 지금까지 @types/node나 @types/jest를 설치만 해 두고 자동으로 주워 오길 기대했다면, 7에서는 갑자기 전역 심볼이 없다는 에러가 쏟아집니다. 코드가 잘못된 게 아니라 설정이 바뀐 것이고, 고치는 법도 한 줄이지만, 큰 모노레포에서 이걸 패키지마다 밟아 나가는 건 지루한 작업입니다.

strict이 기본 true가 된 것도 마찬가지입니다. 지금까지 non-strict으로 살아온 레거시 코드베이스라면 이건 "컴파일러를 바꾸는 일"이 아니라 "타입을 다시 쓰는 일"입니다. 8배 빠른 컴파일러를 얻으려고 몇 달치 strictNullChecks 작업을 선불로 치러야 하는 상황이 생길 수 있습니다.

그리고 아예 없어진 것들 — 무동작(no-op)이 아니라 하드 에러입니다.

  • target: es5 지원 종료
  • downlevelIteration 지원 종료
  • moduleResolution: node 및 node10 지원 종료 (nodenext 또는 bundler 권장)
  • module: amd, umd, systemjs, none 지원 종료 (esnext 또는 preserve 권장)
  • baseUrl 지원 종료 (paths를 프로젝트 루트 기준 상대 경로로 갱신)
  • moduleResolution: classic 지원 종료
  • esModuleInterop과 allowSyntheticDefaultImports를 false로 설정 불가
  • alwaysStrict은 항상 참으로 간주되고 false로 설정 불가
  • 네임스페이스 선언에서 module 키워드 사용 불가
  • import에서 asserts 키워드 사용 불가 — ECMAScript import attribute 구문에 맞춰 with를 써야 함
  • skipDefaultLibCheck 하에서 /// <reference no-default-lib /> 지시문이 더 이상 존중되지 않음
  • 현재 디렉터리에 tsconfig.json이 있으면 명령줄 빌드가 파일 경로를 받을 수 없음 (--ignoreConfig 플래그를 명시하지 않는 한)

이 목록에서 실무를 가장 아프게 할 건 baseUrl과 target: es5입니다. baseUrl은 오래된 프로젝트의 절대 경로 import에 광범위하게 깔려 있고, target: es5는 아직 구형 브라우저를 지원해야 하는 팀에게는 협상 불가능한 요구일 수 있습니다. es5가 필요하면 7은 당신의 것이 아닙니다. 이건 설정을 고쳐서 넘어갈 수 있는 종류의 벽이 아닙니다.

마지막 항목도 의외로 잘 밟힙니다. npx tsc src/foo.ts 같은 걸 스크립트에 넣어 둔 팀이 꽤 있는데, 프로젝트 루트에 tsconfig.json이 있으면 이제 그냥 에러입니다.

진짜 비용 (2) — API가 없다, 그래서 Vue·MDX·Astro·Svelte는 오늘 못 옮긴다

이게 GA 발표문에서 가장 중요한데 가장 적게 인용되는 부분입니다.

TypeScript 7.0이 나왔지만, API를 출하하지 않습니다.

프로그래밍 API가 없습니다. 7.1에서 새로운(그리고 다른) API를 출하할 것으로 예상한다고 적혀 있고, 그때까지는 6과 7을 나란히 돌릴 수 있게 하는 걸 우선순위로 삼았다고 합니다.

여파는 직접적입니다. 발표문의 "TypeScript and Embedded Languages" 절을 그대로 옮기면 — Vue, MDX, Astro, Svelte 등을 쓰는 워크플로는 아직 TypeScript 7을 활용하지 못할 가능성이 큽니다. Angular처럼 템플릿 내부의 특화된 타입 체크도 마찬가지입니다. 이유는 7이 아직 안정적인 프로그래밍 API를 노출하지 않아서, TypeScript를 자기 컴파일러와 언어 서비스에 임베드하는 도구들 — Volar 같은 — 이 현재로서는 TypeScript 6.0에만 의존할 수 있기 때문입니다.

이건 "조금 느릴 수 있다"가 아니라 못 쓴다입니다. 프런트엔드 생태계의 상당 지분이 여기 걸립니다. Vue 팀, Astro 팀, Svelte 팀, 그리고 MDX 기반 문서/블로그 파이프라인 전부 Volar 위에 서 있습니다.

권고안은 이렇게 나뉩니다.

  • 언어 서버 플러그인이 필요 없는 시나리오에서 7을 쓰라 — 이게 기본 권고입니다.
  • Angular — CLI에서 tsc로 빠른 프로젝트 전역 에러 탐지를 하고, 에디터 지원은 6.0을 쓰는 조합이 가능합니다. 즉 반쪽은 가져갈 수 있습니다.
  • Vue, MDX, Astro, Svelte 등 — 당분간 6.0을 계속 써야 합니다. VS Code에서는 "Disable TypeScript 7 Language Server" 커맨드로 6.0으로 되돌릴 수 있습니다.

Microsoft는 이걸 "특정 시점의 문제(point-in-time issue)"로 보며 해결책 제공을 약속했고, 해당 프로젝트 메인테이너들과 적극 협력하겠다고 밝혔습니다. 믿을 만한 약속이라고 봅니다 — 다만 약속은 오늘의 빌드를 고쳐 주지 않습니다. 7.1의 새 API가 나오고, Volar가 거기 맞춰 포팅되고, Vue/Astro/Svelte 툴링이 각각 그걸 채택하는 데까지는 릴리스 사이클이 여러 번 돕니다. 발표문 자신이 밝힌 릴리스 주기가 3~4개월마다이니, 여기에 다운스트림 채택 시간이 더 붙습니다.

6과 7을 같이 두기 — tsc6와 npm 별칭

그래서 현실적인 답은 대개 "둘 다 둔다"입니다. 이걸 위해 Microsoft가 호환 패키지를 새로 냈습니다.

@typescript/typescript6은 tsc6이라는 실행 파일을 제공합니다. 그래서 자기 tsc 바이너리를 갖고 오는 7.0을 이름 충돌 없이 나란히 설치할 수 있습니다. 이 패키지는 TypeScript 6.0 API를 다시 export하기도 해서, tsc는 7로 쓰면서 다른 툴링은 계속 6.0에 의존하게 둘 수 있습니다. npm 레지스트리에서 확인해 보면 이 패키지의 latest는 6.0.2이고 bin 항목은 정확히 tsc6 하나입니다.

typescript-eslint 같은 도구는 peer dependency를 통해 typescript에서 직접 import하길 기대하기 때문에, 권장 방법은 npm 별칭입니다.

npm install -D typescript@npm:@typescript/typescript6

다만 이렇게만 하면 tsc6 실행 파일만 남습니다. 7.0의 tsc도 같이 얻으려면 별칭을 하나 더 겁니다.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

이러면 npx tsc는 7.0으로 동작하고, typescript를 import하는 도구들은 6.0을 봅니다.

솔직히 말하면 이건 우아한 해법이 아닙니다. package.json에 별칭 두 개가 얽혀 있고, typescript라는 이름이 실제로는 6을 가리키는 상태는 처음 보는 사람에게 확실히 헷갈립니다. 하지만 typescript-eslint를 쓰면서 tsc는 빠르게 돌리고 싶다면 — 그러니까 현실의 상당수 프로젝트라면 — 지금은 이게 공식 경로입니다.

조용히 바뀐 것들 — JSDoc과 유니코드

성능 헤드라인에 가려졌지만 실제로 코드를 깨뜨릴 수 있는 변경이 둘 더 있습니다.

JavaScript 지원이 재작업됐습니다. 원래 TypeScript는 JSDoc 주석과 특정 코드 패턴을 인식해서 JS 파일을 지원했는데, 그게 종종 Closure나 JSDoc 문서 생성 도구가 이해하던 것에 기반한 특수 케이스 덩어리였습니다. 7.0은 이걸 .ts 파일 분석 방식과 일관되게 다시 짰습니다. 결과적으로 사라진 것들이 있습니다.

  • 타입이 와야 할 자리에 값을 쓸 수 없음 — typeof someValue로 써야 함
  • @enum이 더 이상 특별 취급되지 않음
  • 단독 ?를 타입으로 쓸 수 없음 — any를 쓸 것
  • @class가 함수를 생성자로 만들지 않음 — 클래스 선언을 쓸 것
  • 후위 ! 미지원
  • 타입 이름은 @typedef 태그 안에서 정의해야 함 (식별자 옆에 두는 형태는 불가)
  • Closure 스타일 함수 구문 미지원 — TypeScript 축약형을 쓸 것

this를 별칭으로 두거나 함수의 프로토타입을 통째로 재할당하는 패턴도 특별 취급이 사라졌습니다. JSDoc으로 타입을 붙인 큰 JS 코드베이스를 갖고 있다면 여기가 진짜 이전 작업입니다. TypeScript 팀은 6.0과 7.0의 차이를 담은 CHANGES.md 파일을 따로 관리하고 있다고 밝혔고, JS 지원은 아직 유동적(in flux)이라고 표현합니다.

템플릿 리터럴 타입이 유니코드 코드 포인트를 보존합니다.

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
//   7.0에서: ["😀", "abc"]
//   이전:    ["\ud83d", "\ude00abc"]

예전에는 JavaScript의 UTF-16 인덱싱 동작을 따라 서로게이트 쌍을 반으로 쪼갰습니다. 기술적으로는 JS 인덱싱과 일관됐지만 대개 의도한 바가 아니었고, 의미 없는 짝 없는 서로게이트를 담은 문자열 리터럴 타입이 나올 수 있었습니다. 새 동작은 for...of로 순회하거나 스프레드할 때의 직관과 같습니다.

발표문은 이걸 UTF-16 코드 유닛을 의도적으로 모델링한 타입 레벨 문자열 조작에 대한 파괴적 변경이라고 정직하게 라벨합니다 — 일부 문자열 Length 유틸리티가 예로 나옵니다. 타입 레벨 문자열 프로그래밍을 깊게 하는 라이브러리를 쓰거나 만든다면 확인이 필요합니다.

한 가지 더. --watch 모드가 완전히 다시 만들어졌습니다. Parcel 번들러의 파일 워처를 Go로 포팅한 게 새 기반입니다(원래 C++이라 전체 C++ 툴체인이 필요했던 걸 최소한의 어셈블리 심으로 Go에 옮겼습니다). Go 표준 라이브러리에 파일 감시 API가 없고, 폴링 기반 해법은 node_modules 의존성이 많은 대형 프로젝트에서 너무 비쌌다는 게 이유입니다. 발표문은 플랫폼 전반에서 --watch의 자원 사용이 크게 개선됐다고 보고합니다.

그래서, 당신은 오늘 옮겨야 하나

정리하면 이렇게 갈립니다.

오늘 옮겨서 값을 하는 경우

  • 이미 TypeScript 6.0을 쓰고 있고, stableTypeOrdering을 켠 채 ignoreDeprecations 없이 깨끗하게 빌드된다 — 이게 공식 호환성 문장이 보장하는 정확한 조건입니다. 이 경우 이전은 대체로 무난합니다.
  • 순수 .ts/.tsx 코드베이스이고 Volar 계열 임베디드 언어 툴링을 쓰지 않는다.
  • CI 타입 체크가 실제 병목이다 — 8배는 여기서 바로 현금화됩니다.
  • 에디터 응답성이 팀의 실질적 고통이다.

아직 못 옮기는 경우

  • Vue, MDX, Astro, Svelte를 쓴다 — 선택의 문제가 아닙니다. 7.1의 API와 그 뒤의 Volar 포팅을 기다려야 합니다.
  • Angular — 반쪽만 가능합니다. CLI 타입 체크는 7, 에디터는 6.
  • target: es5가 필요하다 — 벽입니다.
  • 아직 TypeScript 5.x이고 non-strict이다 — 7로 바로 뛰지 마십시오. 6을 먼저 거치는 게 공식 권고이고, 이유가 있습니다. 폐기 목록을 한 번에 다 밟는 대신 6에서 경고로 받아 가며 정리할 수 있습니다.
  • typescript-eslint 등 API 의존 툴링이 핵심 워크플로다 — 앞의 별칭 조합으로 가능은 하지만, 그 복잡도를 감수할 가치가 있는지는 팀이 판단할 문제입니다.

그리고 순서에 대한 조언 하나. 옮긴다면 --checkers 값을 명시적으로 고정하고 시작하십시오. 로컬과 CI가 서로 다른 기본 병렬도로 도는 상태에서 순서 의존적 진단 차이를 만나면, 그건 디버깅하기 가장 싫은 종류의 버그입니다. 팀이 직접 "드문 경우지만 드러날 수 있다"고 적어 둔 이상, 값을 못 박는 비용은 한 줄이고 안 박는 비용은 반나절입니다.

마치며

TypeScript 7.0의 성능 이야기는 진짜입니다. 벤더 자체 보고이긴 하지만 재현 가능한 오픈소스 코드베이스로 측정됐고, 조건(기본 --checkers 4, 전체 빌드)도 공개돼 있고, --checkers 8 표까지 같이 실어서 숫자가 설정에 따라 움직인다는 걸 스스로 드러냈습니다. 이 정도면 벤더 벤치마크로서는 정직한 축입니다. Slack의 7.5분 → 1.25분 같은 수치가 재현된다면, 큰 코드베이스에서 이건 삶의 질 문제입니다.

하지만 헤드라인은 "10배 빨라졌다"이고, 실제 이야기는 "10배 빨라졌고, 그 대가로 6의 폐기 목록을 전부 청산해야 하며, 프런트엔드 생태계의 큰 조각은 API가 나올 때까지 초대받지 못했다"입니다.

그래서 저는 이걸 이렇게 봅니다 — 7.0은 완성된 이주가 아니라 시작된 이주입니다. 7.1이 API를 갖고 나오고 Volar가 그 위에 서기 전까지, 이 생태계는 당분간 6과 7로 갈라져 삽니다. @typescript/typescript6과 tsc6이라는 호환 패키지가 존재한다는 사실 자체가 그걸 인정하는 것입니다. Microsoft도 이걸 알고 있고, 그래서 발표문 마지막에 "7.1로 어떤 간극이든 메워 커뮤니티를 앞으로 데려가고 싶다"고 적었습니다.

당신이 순수 TS 코드베이스라면 오늘이 좋은 날입니다. Vue나 Astro 위에 서 있다면, 이번 릴리스는 당신 것이 아직 아닙니다 — 그리고 그건 당신이 뭘 잘못해서가 아닙니다.

참고 자료

현재 단락 (1/151)

2026년 7월 8일, [TypeScript 7.0이 GA됐습니다](https://devblogs.microsoft.com/typescript/announcing-typescrip...

작성 글자: 0자원문 글자: 10,863자작성 단락: 0/151