2026. 7. 17.

TypeScript 7.0으로 바로 올려도 될까? Vue·Svelte와 일반 프로젝트를 가르는 기준

TypeScript 7.0 정식 출시 뒤 내 프로젝트를 바로 올려도 되는지, Vue·Svelte 같은 임베디드 언어와 컴파일러 API 의존을 확인해 전환·병행·대기를 고르는 방법입니다.

4 min read
TypeScript 7.0으로 바로 올려도 될까? Vue·Svelte와 일반 프로젝트를 가르는 기준 대표 이미지

TypeScript 7.0이 정식으로 나왔다는 소식을 보면 typescript 버전부터 올리고 싶어진다. 공식 발표의 대형 프로젝트 사례에서는 전체 빌드가 8~12배 빨라졌지만, 내 프로젝트가 바로 전환 가능한지는 속도가 아니라 TypeScript를 사용하는 방식이 가른다.

먼저 답부터 정리하면 세 갈래다. 일반적인 TypeScript·JavaScript 프로젝트에서 주변 도구가 tsc 실행만 이용한다면 작은 브랜치에서 7.0을 시험할 수 있다. 도구가 TypeScript 컴파일러 API를 직접 불러온다면 6과 7을 병행한다. Vue, Svelte, Astro, MDX처럼 파일 안에 언어가 섞이는 프로젝트는 해당 도구의 지원 안내가 나올 때까지 6.0 유지 또는 제한적인 혼합 사용을 먼저 검토한다.

TypeScript 7 업그레이드 경로를 고르는 판단 흐름

TypeScript 7, 누구는 올리고 누구는 기다릴까

TypeScript 팀은 2026년 7월 8일 TypeScript 7.0 정식 출시를 발표했다. 이제 프리뷰 패키지 이름을 찾아 설치하는 단계가 아니라, 워크스페이스의 typescript 패키지를 설치하면 새 tsc를 받는 구조다. 다만 7.0에는 아직 안정적인 프로그래밍 API가 없고, 새 API는 7.1에서 제공될 예정이다.

이 차이 때문에 프로젝트를 다음처럼 나누는 편이 안전하다.

프로젝트 상황먼저 고를 경로확인할 것
도구가 tsc 명령만 실행하는 일반 TS/JS 프로젝트작은 브랜치에서 7.0 시험기존 typecheck와 build가 같은 결과를 내는지
ESLint 플러그인, 빌드 도구, 사내 스크립트가 typescript API를 import함6.0 API와 7.0 CLI 병행도구의 peer dependency와 공식 지원 버전
Vue, Svelte, Astro, MDX 등 임베디드 언어를 사용함도구 지원 안내까지 6.0 유지 또는 제한적 혼합프레임워크·언어 서버의 TypeScript 7 지원 공지
Angular 템플릿 타입 검사를 사용함CLI 시험과 에디터·템플릿 검사를 분리프로젝트 전체 오류와 템플릿 오류가 모두 유지되는지

여기서 "일반 프로젝트"는 React나 Node라는 이름만으로 결정되지 않는다. 같은 React 프로젝트라도 커스텀 변환기나 TypeScript API 기반 도구가 있으면 병행 경로가 필요할 수 있다. 프레임워크 이름보다 typescript 패키지를 누가 import하는지 확인하는 것이 먼저다.

설치 전에 프레임워크와 API 의존부터 확인하세요

업그레이드 전에는 작업 브랜치와 기준 출력을 만든다. 다음 명령은 코드를 바꾸기 전에 현재 상태를 기록하려는 절차다.

git switch -c chore/typescript-7-trial
npx tsc --version
npm ls typescript
npm run typecheck

첫 명령은 시험 변경을 분리해 되돌리기 쉽게 만든다. npx tsc --version은 실제로 실행되는 컴파일러 버전을 보여 준다. npm ls typescript는 워크스페이스에 TypeScript가 여러 버전으로 들어왔는지 확인한다. 마지막 명령은 이 저장소에서 쓰던 검사 결과를 기준선으로 남긴다. typecheck 스크립트가 없다면 프로젝트 설정에 맞춰 npx tsc --noEmit을 사용할 수 있다.

API 의존은 package.json만 보고 끝내기 어렵다. 빌드 도구, 린터, 코드 생성기, 커스텀 스크립트가 typescript를 직접 불러오는지 검색한다.

rg 'from ["'"']typescript["'"']|require\(["'"']typescript["'"']\)' . \
  -g '!node_modules' -g '!dist' -g '!build'

Windows PowerShell에서 rg를 쓴다면 같은 패턴을 한 줄로 실행하면 된다. 결과가 없다고 호환성이 자동 보장되는 것은 아니다. 의존 패키지의 공식 지원 범위와 peer dependency도 함께 확인해야 한다.

AI에게 업그레이드를 맡길 때도 "TypeScript를 7로 올려줘" 한 줄로 끝내지 않는다. 아래처럼 변경 범위와 검증을 묶어 요청한다.

현재 브랜치에서 TypeScript 7 업그레이드 가능성을 조사해줘.
먼저 TypeScript 컴파일러 API를 직접 사용하는 코드와 도구를 찾고,
기존 typecheck 결과를 저장한 뒤 package.json과 lockfile만 변경해.
업그레이드 후 같은 typecheck와 build를 실행하고 오류 차이를 표로 보고해.
지원이 불명확한 프레임워크 플러그인은 임의로 교체하지 마.

AI가 수정한 파일을 믿기 전에 확인하는 습관은 AI 코드 저장 전 변경 범위 점검법과 함께 쓰면 좋다.

작은 브랜치에서 버전과 오류를 비교하세요

즉시 전환 경로라면 정식 7 계열을 설치하고 같은 명령을 다시 실행한다.

npm install -D typescript@^7
npx tsc --version
npm run typecheck
npm run build
git diff -- package.json package-lock.json

확인 시점의 npm latest는 7.0.2였지만, 글을 읽는 시점에는 달라질 수 있다. 그래서 설치 뒤의 npx tsc --version 출력이 중요하다. 성공 기준은 "설치 명령이 끝남"이 아니다. 기존과 같은 검사 명령이 통과하고, 새 오류가 있다면 각각 설정 변화·지원 제한·실제 코드 오류 중 무엇인지 설명할 수 있어야 한다.

API 의존 도구 때문에 6과 7을 함께 써야 한다면 TypeScript 팀이 안내한 호환 패키지를 사용할 수 있다. 공식 예시는 다음처럼 6.0 API를 typescript 이름에 남기고, 7.0 CLI를 별도 alias로 둔다.

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

설치 뒤에는 두 실행 파일을 모두 확인한다. VS Code의 언어 서비스도 함께 시험한다면 Microsoft의 TypeScript 7 확장 안내에 따라 에디터에서 실제로 활성화된 언어 서버를 별도로 확인한다.

npx tsc --version
npx tsc6 --version

이 구성은 모든 프로젝트의 기본 답이 아니다. 도구가 6.0 API를 요구하지만 CLI에서는 7.0의 속도를 시험하고 싶을 때 쓰는 전환 장치다. 패키지 관리자가 TypeScript 7 지원을 발표했다면 단순한 7.0 설치가 더 낫다.

TypeScript 7 설치 전후 버전과 타입 검사 결과를 비교하는 체크리스트

새 오류가 뜨면 버전 결함보다 설정 변화부터 나누세요

TypeScript 7.0은 6.0에서 예고된 새 기본값과 제거 항목을 이어받는다. 업그레이드 뒤 오류가 늘었다면 모두 새 컴파일러의 버그라고 묶지 말고 다음 순서로 나눈다.

  1. npx tsc --version이 예상한 7.0인지 확인한다.
  2. tsconfig.jsontypes, rootDir, strict를 명시했는지 본다.
  3. baseUrl, 오래된 moduleResolution: node, target: es5처럼 7.0에서 더 이상 지원되지 않는 설정을 찾는다.
  4. Vue·Svelte·Astro·MDX·Angular 템플릿 도구의 공식 TypeScript 7 지원 범위를 확인한다.
  5. 마지막으로 실제 코드 오류를 수정하고 같은 typecheck를 다시 실행한다.

특히 types의 기본값은 빈 배열이 되었기 때문에 Node 전역이나 테스트 전역을 자동으로 기대하던 프로젝트에서 process, describe 같은 이름 오류가 나타날 수 있다. 필요한 타입만 명시하는 방향이 우선이며, 모든 타입을 다시 전역으로 불러오는 설정은 원인을 확인한 뒤 선택한다.

{
  "compilerOptions": {
    "types": ["node", "jest"],
    "rootDir": "./src"
  }
}

새 엄격성 오류를 !로 한꺼번에 숨기면 업그레이드가 끝난 것처럼 보일 뿐이다. 값이 실제로 없을 수 있는 오류는 TypeScript possibly undefined를 빈 값 동작으로 고르는 방법처럼 런타임 행동부터 정한다.

오늘 남길 결과는 업그레이드가 아니라 판단 기록입니다

TypeScript 7.0의 속도 이점은 매력적이지만, 정답은 모든 저장소에서 같지 않다. 오늘 할 일은 패키지를 무조건 바꾸는 것이 아니라 다음 네 줄을 남기는 것이다.

  • 현재 tsc 버전
  • 기존 typecheck와 build 결과
  • TypeScript API 또는 임베디드 언어 도구 의존 여부
  • 즉시 전환, 6·7 병행, 대기 중 선택한 경로와 이유

이 네 가지가 기록되어 있으면 AI나 팀원이 다음 변경을 이어 받아도 같은 기준으로 판단할 수 있다. 시험 브랜치에서 오류 차이를 설명할 수 있을 때만 업그레이드를 합치고, 도구 지원이 불명확하면 현재 6.0 환경을 유지한 채 공식 지원 공지를 기다린다.

참고 출처

이 글은 AI 코딩과 개발 학습의 일반 정보 제공 목적입니다. 도구, 모델, 커리큘럼, 요금은 버전과 시점에 따라 달라질 수 있으므로 실습이나 도입 전 공식 문서와 최신 릴리스 노트를 확인하세요.

다음으로 읽을 기사

같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.

댓글 0

이 글을 읽은 독자들의 생각을 나눠보세요.

비밀번호(선택)

첫 번째 댓글을 남겨보세요

여러분의 생각이 다른 독자에게 도움이 됩니다.