TypeScript 7이 정식 출시됐다. 가장 눈에 띄는 변화는 새로운 타입 문법이 아니다. TypeScript로 작성했던 컴파일러와 언어 서비스를 Go 기반 네이티브 구현으로 옮겼고, 공식 사례에서는 전체 빌드가 대체로 8~12배 빨라졌다.

그렇다면 팀은 바로 버전을 올리면 될까? 결론부터 말하면 TypeScript 7은 충분히 시험해볼 만하다. 다만 타입 안정성 개선과 타입 검사 속도 개선을 구분해서 도입해야 한다.

한 줄 요약

TypeScript 7의 핵심 가치는 JavaScript 실행 결과를 빠르게 만드는 것이 아니라, 타입 검사와 코드 탐색의 비용을 줄여 개발자가 안전망을 더 자주 사용할 수 있게 만드는 데 있다.

어차피 실행되는 것은 JavaScript인데

TypeScript에 관해 자주 나오는 질문이 있다.

브라우저에서 실행되는 것은 결국 JavaScript인데 TypeScript를 사용하면 무엇이 좋아지는가?

TypeScript는 런타임을 개선하지 않는다. 페이지 실행 속도나 번들 크기를 자동으로 개선하지 않으며, 서버가 잘못된 값을 반환하는 것도 막지 못한다. 사용자 입력과 API 응답처럼 프로그램 외부에서 들어오는 값은 별도의 런타임 검증이 필요하다.

TypeScript가 개선하는 대상은 프로그램 자체보다 프로그램을 변경하는 과정에 가깝다.

  • 존재하지 않는 속성이나 잘못된 함수 호출을 실행 전에 발견한다.
  • 자동완성, 참조 찾기, 이름 변경을 통해 코드 탐색과 리팩터링을 돕는다.
  • 데이터 구조와 허용 가능한 상태를 코드에 남긴다.
  • 사람과 코딩 에이전트가 변경할 수 있는 범위를 기계가 검사할 수 있게 한다.

즉 타입은 빌드 후 사라지지만, 코드를 만들고 변경하는 동안에는 강한 작업 경계로 작동한다.

TypeScript 7에서 달라지는 것

TypeScript 7 공식 발표에 따르면 새 컴파일러는 네이티브 코드와 공유 메모리 기반 멀티스레딩을 사용한다. 공개된 대규모 프로젝트의 전체 빌드 결과는 약 7.7배에서 11.9배까지 빨라졌고, 메모리 사용량도 대체로 감소했다.

속도 개선은 명령행의 tsc에만 한정되지 않는다. 프로젝트를 처음 열었을 때 진단이 표시되기까지의 시간, 자동완성, 참조 찾기, --watch 모드 같은 일상적인 피드백 루프도 개선 대상이다.

여기서 중요한 것은 더 빠른 TypeScript가 더 엄격한 TypeScript를 뜻하지는 않는다는 점이다.

TypeScript 7 도입       = 타입 검사와 개발 도구의 속도 개선
strict 설정과 any 축소 = 정적 타입 안전성 개선
런타임 스키마 검증     = 외부 데이터 경계 보호

세 가지는 서로 보완하지만 같은 작업은 아니다. TypeScript 7로 올려도 any와 과도한 타입 단언이 그대로라면 기존의 빈틈도 그대로 남는다.

모든 빌드가 10배 빨라지는 것은 아니다

공식 수치를 그대로 팀의 기대치로 사용해서는 안 된다.

Next.js처럼 SWC나 다른 도구가 JavaScript 변환과 번들링을 담당하는 환경에서는 전체 애플리케이션 빌드가 10배 빨라지는 것이 아니다. 직접적인 개선 대상은 tsc --noEmit 타입 검사와 에디터 언어 서비스다. 저장소 규모, 프로젝트 참조 구조, CI 머신의 CPU와 메모리에 따라 결과도 달라진다.

따라서 도입 제안에는 다음 기준의 전후 측정이 포함되어야 한다.

측정 항목 확인할 내용
전체 타입 검사 최초·반복 tsc --noEmit 실행 시간
CI 타입 검사 작업과 전체 파이프라인 시간
에디터 프로젝트 로딩 후 첫 진단 시간
코드 탐색 Find References와 Rename 반응 시간
자원 최대 메모리와 CPU 사용량
정확성 기존 버전과 오류·선언 파일 차이

목표 역시 “공식 사례처럼 10배”보다 “개발자가 로컬 타입 검사를 생략하지 않을 정도로 줄었는가”로 잡는 편이 현실적이다.

7.0에서 특히 조심할 호환성

TypeScript 7.0에는 아직 안정적인 컴파일러 API가 없다. typescript-eslint처럼 TypeScript를 라이브러리로 불러오는 도구는 당분간 TypeScript 6이 필요할 수 있다. 이를 위해 공식적으로 6과 7을 함께 설치하는 호환 패키지와 npm 별칭 방식이 제공된다.

Vue, Svelte, Astro, MDX와 Angular 템플릿 도구처럼 TypeScript를 자체 언어 서비스에 포함하는 생태계도 7.0을 온전히 사용하기 어렵다. 이런 도구를 사용한다면 7.1의 새 API와 각 프로젝트의 지원 상태를 기다리는 편이 낫다.

설정 변화도 확인해야 한다. TypeScript 7은 TypeScript 6의 변경사항과 새 기본값을 이어받는다.

  • strict와 noUncheckedSideEffectImports가 기본적으로 활성화된다.
  • rootDir와 types의 기본 동작이 달라진다.
  • target: es5, baseUrl, 오래된 moduleResolution 설정 등이 더는 지원되지 않는다.
  • JavaScript와 JSDoc 분석의 일부 오래된 동작이 제거됐다.

현재 버전이 낮다면 TypeScript 7로 한 번에 이동하기보다 먼저 TypeScript 6 호환성을 맞추는 것이 문제 원인을 구분하기 쉽다.

팀 도입은 병행 실행부터

처음부터 기본 버전을 교체할 필요는 없다. 다음 순서면 효과와 위험을 분리해 확인할 수 있다.

  1. TypeScript 7을 기존 버전과 병행 설치한다.
  2. CI의 비차단 작업에서 두 버전의 진단 결과를 비교한다.
  3. 대표 프로젝트와 전체 저장소의 시간·메모리를 측정한다.
  4. 희망자를 대상으로 새 언어 서버의 에디터 경험을 확인한다.
  5. 호환성 문제가 없다면 CLI 타입 검사를 TypeScript 7로 전환한다.
  6. 컴파일러 API 의존 도구는 TypeScript 6을 유지하고 7.1 이후 다시 판단한다.

멀티스레딩 설정도 처음부터 공격적으로 높이지 않는 편이 좋다. TypeScript 7은 --checkers와 --builders로 병렬도를 조절할 수 있지만, 둘을 함께 높이면 동시에 실행되는 검사 작업과 메모리 사용량이 크게 늘 수 있다. 개발자 머신과 CI 실행 환경에서 각각 측정한 뒤 고정값을 정해야 한다.

마치며

TypeScript 7은 JavaScript를 더 빠르게 실행하는 버전이 아니다. 타입 검사를 기다리는 시간을 줄이고, 개발자와 도구가 코드베이스를 탐색하고 변경한 뒤 검증받는 시간을 줄이는 버전이다.

그래서 도입 논의의 핵심 질문은 “공식 벤치마크처럼 10배 빨라지는가?”가 아니다.

타입 검사가 충분히 빨라지면 우리 팀은 지금보다 더 자주, 더 넓은 범위를 로컬에서 검증할 수 있는가?

이 질문에 실제 측정으로 답할 수 있다면 TypeScript 7은 단순한 도구 업그레이드를 넘어 개발 피드백 루프를 개선하는 투자가 될 수 있다.

참고 자료