TypeScript 5 신기능 정리: 5.0부터 5.9까지 한눈에

타입 안정성으로 자바스크립트 생태계를 바꿔 놓은 TypeScript는 2023년 3월 5.0 메이저 버전을 내놓은 뒤 약 3년간 5.1부터 5.9까지 분기별로 꾸준히 진화해 왔다. 그런데 막상 “버전마다 뭐가 달라졌나”를 정리해 둔 한국어 자료는 흩어져 있거나 옛 정보에 머물러 있는 경우가 많다. 이 글은 TypeScript 5 라인의 핵심 신기능을 데코레이터부터 import defer까지 공식 릴리스 노트 기준으로 짚고, 2026년 현재 등장한 6.0·7.0이 5.x와 어떤 관계인지까지 한눈에 정리한다. TypeScript 5 버전을 쓰는 팀이 무엇을 활용할 수 있고 무엇을 준비해야 하는지가 핵심이다.

TypeScript 5는 어디까지 왔나 — 2026년 현재 위치

먼저 큰 그림부터 잡는 편이 좋다. TypeScript의 메이저·마이너 버전은 약 3개월 주기로 출시되는데, 5.0 이후 흐름을 시간순으로 보면 다음과 같다.

버전 출시(대략) 한 줄 요약
5.0 2023년 3월 표준 데코레이터, const 타입 파라미터, moduleResolution bundler
5.1~5.4 2023~2024 using 자원 관리, NoInfer, JSX 개선
5.5 2024년 타입 술어(predicate) 자동 추론, 정규식 검사, isolatedDeclarations
5.6~5.8 2024~2025 의심스러운 비교 차단, ESM require(), erasableSyntaxOnly
5.9 2025년 8월 1일 import defer, --module node20, 간소화된 tsc --init
6.0 2026년 3월 23일 자바스크립트 기반 마지막 메이저(전환 릴리스)
7.0 2026년(RC 6월) Go로 다시 쓴 네이티브 컴파일러(“Corsa”), 약 10배 속도

여기서 중요한 포인트 하나. 마이크로소프트는 공식 블로그에서 6.0을 “현재 자바스크립트 코드베이스 기반의 마지막 릴리스”로 못 박았고, 그 다음 7.0은 Go 언어로 처음부터 다시 작성한 네이티브 포트다. 즉 5.x 시리즈는 “JS로 작성된 TypeScript 컴파일러”가 기능을 쌓아 올린 마지막 황금기에 해당한다. 지금 5.x를 쓰는 프로젝트라면 이 글에 정리된 기능들이 사실상 안정적으로 누릴 수 있는 기능 세트 전부라고 봐도 무방하다.

TypeScript 5.0 — 데코레이터와 모듈 해석의 분기점

5.0은 메이저 버전답게 두 가지 큰 변화를 가져왔다.

첫째는 표준 데코레이터(Stage 3 Decorators)다. 그동안 experimentalDecorators 플래그 뒤에 숨어 있던 데코레이터가 TC39 표준 문법으로 정식 지원되기 시작했다. @를 붙여 클래스와 메서드를 재사용 가능하게 꾸미는 그 문법이다.

function logged(value, context) {
  if (context.kind === "method") {
    return function (...args) {
      console.log(`호출: ${context.name}`);
      return value.call(this, ...args);
    };
  }
}

class Service {
  @logged
  fetchData() { /* ... */ }
}

둘째는 const 타입 파라미터다. 예전에는 리터럴 타입을 그대로 추론하게 하려면 호출부마다 as const를 붙여야 했는데, 이제 타입 파라미터에 const를 선언하면 함수 정의 한 곳에서 이를 강제할 수 있다.

function getNames<const T extends readonly string[]>(arg: T): T {
  return arg;
}
// 추론 결과: readonly ["Alice", "Bob"]  ← as const 불필요
const names = getNames(["Alice", "Bob"]);

이 밖에 5.0은 모든 enum을 유니온 enum으로 취급해 좁히기(narrowing)를 지원하고, 번들러 환경을 위한 --moduleResolution bundler, 모듈 출력 동작을 단순화한 --verbatimModuleSyntax를 도입했다. 패키지 용량도 약 59% 줄었다. Vite·esbuild 같은 현대 번들러를 쓰는 프로젝트라면 bundler 모듈 해석만으로도 설정이 한결 깔끔해진다.

5.1~5.5 — 타입 추론이 똑똑해진 구간

5.0 이후 마이너 버전들은 화려한 신문법보다 “타입 추론을 사람의 직관에 가깝게 만드는” 방향으로 다듬어졌다. 마치 내비게이션이 매년 길 안내를 더 똑똑하게 다듬는 것과 비슷하다.

  • 5.2 — using 선언(명시적 자원 관리): 파일 핸들이나 DB 커넥션처럼 다 쓰면 정리해야 하는 자원을, 스코프를 벗어날 때 자동으로 Symbol.dispose를 호출해 해제한다.
  • 5.4 — NoInfer<T>: 제네릭에서 특정 타입 인자가 멋대로 추론되는 것을 막아 의도한 타입만 흐르게 한다.
  • 5.5 — 타입 술어 자동 추론: 가장 체감이 큰 변화다. filter(x => x !== undefined) 같은 함수의 반환 타입을 컴파일러가 알아서 타입 가드로 추론한다.
// 5.5 이전: (Bird | undefined)[]
// 5.5 이후: Bird[]
const birds = countries
  .map((c) => birdMap.get(c))
  .filter((bird) => bird !== undefined);

5.5는 이 밖에도 정규식 리터럴의 문법 오류를 컴파일 단계에서 잡아 주고(/...))?/ 같은 괄호 짝 오류 검출), 병렬로 .d.ts를 빠르게 생성하는 --isolatedDeclarations, 그리고 union·intersection 등 새 Set 메서드 타입을 추가했다. 큰 코드베이스일수록 추론 정확도 향상의 누적 효과가 크다.

5.6~5.9 — 런타임 실행과 노드 정렬

후반부 버전들은 “TypeScript를 별도 빌드 없이 그대로 실행”하려는 런타임 흐름(Node.js의 타입 스트리핑)에 발맞춰 설계됐다.

  • 5.6 — 의심스러운 비교 차단: 항상 참/거짓이 되는 무의미한 &&·|| 비교를 컴파일 에러로 잡는다.
  • 5.8 — ESM require() 지원 + --erasableSyntaxOnly: Node.js 22가 CommonJS에서 ESM 모듈을 require()로 불러오는 것을 허용하면서, --module nodenext가 이를 지원한다. 동시에 --erasableSyntaxOnlyenum·namespace·파라미터 프로퍼티처럼 “지우면 런타임 의미가 달라지는” 문법을 금지해, Node가 타입만 떼어내고 바로 실행하는 모드와 호환되게 만든다.
class C {
  // --erasableSyntaxOnly 켜면 에러: 파라미터 프로퍼티 금지
  constructor(public x: number) {}
}
  • 5.9 — import defer: 5.x 라인의 마지막 정식 기능 릴리스(2025년 8월 1일)에서 나온 기능. import defer * as feature from "./module.js" 문법으로, 해당 모듈은 export 중 하나에 처음 접근하는 순간까지 실행이 미뤄진다. 초기화 비용이 큰 모듈을 조건부로 늦게 로드해 시작 속도를 끌어올리는 용도다. 5.9는 이 밖에 --module node20(고정형 Node 20 모델), 군더더기를 걷어낸 tsc --init 기본값, 에디터 호버 확장 미리보기도 함께 도입했다.

버전별 핵심 신기능 한눈에

지금까지의 내용을 표 하나로 압축하면 다음과 같다.

버전 대표 신기능 어떤 문제를 풀었나
5.0 표준 데코레이터, const 타입 파라미터 실험 플래그 의존 탈피, as const 반복 제거
5.2 using 자원 관리 자원 해제 누락 방지
5.4 NoInfer<T> 제네릭 오추론 차단
5.5 타입 술어 자동 추론, 정규식 검사 filter 후 타입 좁히기 자동화
5.6 의심스러운 비교 차단 항상 참/거짓인 조건 버그 검출
5.8 ESM require(), erasableSyntaxOnly Node 타입 스트리핑 실행 호환
5.9 import defer, --module node20 지연 로딩·시작 성능, 노드 버전 고정

6.0과 7.0 — TypeScript 5 이후의 길

2026년 현재 TypeScript를 정리할 때 6.0·7.0을 빼놓을 수 없다. TypeScript 5 라인이 끝난 뒤의 그림이 꽤 달라지기 때문이다.

6.0(2026년 3월 23일 공식 발표)은 기능 추가보다 “정리”에 가깝다. 공식 블로그 표현 그대로 자바스크립트 코드베이스 기반의 마지막 메이저이며, 7.0으로 넘어가기 위한 다리 역할을 한다. 주요 변화는 기본값 전환과 정리다.

  • strict 모드가 기본 활성화, module 기본값 esnext, target 기본값 es2025
  • --outFile 제거, import assertion(assert) 문법 제거(→ with 속성으로 대체)
  • target: es5·--moduleResolution node·레거시 네임스페이스 문법 등 사용 중단(deprecation) 경고

기존 프로젝트가 경고 폭탄을 맞지 않도록 "ignoreDeprecations": "6.0" 옵션으로 한시적으로 유예할 수 있다.

7.0은 차원이 다르다. 코드명 “Corsa”로 불린 이 프로젝트는 컴파일러와 언어 서비스를 Go로 처음부터 다시 작성한 네이티브 포트다. 마이크로소프트는 7.0이 6.0 대비 약 10배 빠른 컴파일, 약 8배 빠른 에디터 시작, 약 50% 메모리 절감을 보인다고 밝혔다. 네이티브 포트는 2026년 초 출시 목표로 진행됐고, RC가 2026년 6월 공개되면서 정식 출시가 가시권에 들어왔다(InfoWorld 보도).

실무 업그레이드 체크리스트

버전을 따라가는 것과 실제 업그레이드는 별개 문제다. 5.x 안에서, 또는 6.0으로 올릴 때 확인할 점을 정리하면 다음과 같다.

  1. 현재 버전 확인: npx tsc --version으로 프로젝트가 어느 마이너에 묶여 있는지부터 본다.
  2. deprecation 경고 먼저 점검: 6.0으로 올리기 전에 --moduleResolution node, --outFile, import assertion 사용처를 grep으로 찾아 둔다.
  3. 번들러 환경이면 moduleResolution: bundler: 5.0+ 프로젝트가 아직 node에 머물러 있다면 전환을 검토한다.
  4. 데코레이터 사용 시 표준 문법 여부 확인: experimentalDecorators에 의존하던 코드는 5.0 표준 데코레이터와 동작이 다를 수 있다.
  5. 점진적 업그레이드: 마이너 한 단계씩 올리며 strict 관련 신규 에러를 흡수하는 편이 안전하다.

이 글에서 다루는 TypeScript 5 기능 대부분은 호환성을 깨지 않는 점진적 개선이라, 마이너 업그레이드 자체는 비교적 매끄러운 편이다. 다만 6.0의 기본값 전환(특히 strict 기본 활성화)은 기존 코드에서 새 에러를 대거 발생시킬 수 있어, 시간을 따로 잡아 두는 편이 현실적이다.

한 가지 솔직한 한계도 짚어 두자. 위 표의 마이너 버전별 출시 시점은 분기 주기 기준의 근사치이며, 일부 기능은 프리뷰 단계에서 정식으로 승격되는 과정을 거쳤다. 정확한 동작과 플래그 조합은 프로젝트의 Node·번들러 환경에 따라 달라질 수 있으니, 도입 전 공식 릴리스 노트를 한 번 더 대조하는 것을 권한다. 그렇다면 우리 팀은 지금 5.x에 머물러 기능을 안정적으로 쓰는 편이 나을까, 아니면 6.0 정리 작업을 미리 시작해 7.0 시대를 준비하는 편이 나을까?

정리하며

정리하면 TypeScript 5는 데코레이터·const 타입 파라미터(5.0)로 문을 열어, 타입 술어 자동 추론(5.5)으로 추론을 똑똑하게 다듬고, import defer(5.9)로 런타임 성능까지 챙긴 한 편의 완결된 시리즈다. 그리고 그 뒤에는 자바스크립트 기반 마지막 메이저인 6.0과, Go로 다시 태어나 10배 빨라진 7.0이 기다리고 있다. 지금 5.x를 쓰는 팀이라면 이 글의 기능들을 충분히 활용하면서, 6.0의 deprecation 경고를 미리 점검해 두는 것이 7.0 전환의 가장 부담 없는 준비가 된다.

프론트엔드 프레임워크의 버전 변화가 궁금하다면 Next.js 15 신기능 정리 글도 함께 참고할 만하다.


참고 자료

댓글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다