Go로 재작성된 TypeScript 7.0 설치와 6.x 병행 사용 방법

개요

본 포스트는 Go로 재작성된 TypeScript 7.0 설치와 기존 TypeScript 6.x 병행 사용 과정을 설명합니다.
TypeScript 7.0은 기존 JavaScript 코드베이스 구조를 최대한 유지하면서 Go 네이티브 포트로 옮긴 릴리스입니다. 공식 발표에서는 전체 빌드 기준 보통 8~12배 빠른 결과와 언어 서버 실패 명령 80% 이상 감소, 서버 크래시 60% 이상 감소를 함께 언급했습니다.

TypeScript 프로젝트를 Docker 기반 Node.js 빌드와 같이 운영한다면 기존 글인 Docker MongoDB Replica Set 구축하기처럼 개발 환경과 실행 환경을 분리해서 관리하는 흐름과 같이 보시면 됩니다. 여기서는 서버 구축이 아니라 TypeScript 컴파일러 전환 점검만 다룹니다.

전체 구성 흐름

• TypeScript 7.0: Go 네이티브 포트로 작성된 tsc와 LSP 중심 컴파일러입니다.
• TypeScript 6.x: 기존 compiler API가 필요한 도구를 위한 병행 패키지입니다.
• Editor LSP: VS Code, Visual Studio, WebStorm 같은 에디터에서 새 언어 서버를 붙이는 구간입니다.
• CI 빌드: npx tsc 실행 시간과 watch 모드 반응을 비교하는 구간입니다.
• 마이그레이션 점검: API 의존 도구, rootDir, types 설정 차이를 먼저 확인합니다.

TypeScript 7.0은 7.1 전까지 compiler API를 제공하지 않습니다. typescript-eslint처럼 typescript 패키지를 import하는 도구가 있으면 6.x 병행 구성을 먼저 잡아야 합니다.

적용 대상

• TypeScript 프로젝트 빌드 시간이 긴 저장소.
• VS Code 진단, 자동완성, find-all-references 대기 시간이 긴 저장소.
• tsc --watch 피드백을 자주 보는 프론트엔드 또는 Node.js 프로젝트.
• 기존 compiler API 기반 도구가 있어 TypeScript 6.x를 당장 지우기 어려운 저장소.
• 작은 개인 스크립트처럼 빌드 시간이 짧은 프로젝트는 우선순위가 낮습니다.

사전 준비 사항

• Node.js와 npm이 설치된 개발 환경.
• package.json과 lock 파일을 commit한 Git 저장소.
• 기존 npx tsc --noEmit 성공 기준.
• 사용 중인 에디터의 TypeScript 7 또는 LSP 설정 확인.
• CI에서 Node.js 버전과 npm alias 지원 여부 확인.

설치 절차

1.1. 기본 설치

새 프로젝트이거나 compiler API 의존이 없다면 일반 패키지처럼 설치합니다.

npm install -D typescript

설치 뒤 버전을 확인해주시면 됩니다.

npx tsc --version

TypeScript 7.x가 나오면 기본 설치는 끝납니다.

1.2. TypeScript 6.x 병행 설치

기존 도구가 TypeScript 6.x API를 계속 요구하면 npm alias를 사용합니다.

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

이 방식은 typescript import를 6.x 쪽으로 유지하고 tsc6 실행 파일을 제공합니다.

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

TypeScript 7.0의 tsc도 같이 써야 한다면 별도 alias를 추가합니다.

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

이 구성에서는 도구 호환성은 6.x로 남기고, 네이티브 컴파일러 점검은 7.x 별도 경로로 나눠주시면 됩니다.

1.3. nightly 빌드 확인

기존 @typescript/native-preview를 쓰던 프로젝트는 앞으로 표준 typescript 패키지의 next tag 쪽으로 옮겨갑니다.

npm install -D typescript@next

운영 브랜치에 바로 넣지 말고 별도 브랜치에서 lock 파일 변화를 확인합니다.

1.4. 설정 차이 확인

TypeScript 7.0에서는 일부 JavaScript 혼합 프로젝트와 타입 자동 탐색 동작이 더 엄격하게 보일 수 있습니다. 소스 루트가 명확하지 않으면 rootDir를 지정합니다.

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

필요한 @types 패키지도 명시합니다.

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

설정을 고친 뒤에는 기존 6.x와 7.x 결과를 나눠서 확인하시면 됩니다.

npx tsc6 --noEmit
npx tsc --noEmit

1.5. 에디터 설정

VS Code는 TypeScript 7 전용 확장을 쓸 수 있고, Visual Studio는 workspace 기준으로 TypeScript 7을 켜는 흐름을 제공합니다. WebStorm 같은 에디터는 LSP 설정 또는 내장 TypeScript 버전 선택 메뉴를 확인합니다.

• 에디터 TypeScript 버전: workspace 설치 버전 또는 TypeScript 7 확장 선택.
• 언어 서버 확인: diagnostics, auto-completion, find-all-references 반응 시간 확인.
• CI 확인: 로컬 npx tsc --noEmit과 CI 명령이 같은 패키지를 보는지 확인.

주요 오류 및 해결 방안

1.1. compiler API 의존 도구 오류

제 경우 원인은 대부분 typescript 패키지를 import하는 린트나 코드 생성 도구가 7.0 API를 기대하지 못한 상태였습니다. 7.1 전까지는 API가 없으므로 typescript alias를 6.x로 두고, 7.0 컴파일러는 별도 alias나 전용 명령으로 분리합니다.

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

1.2. rootDir 추론 차이

소스와 설정 파일이 섞인 저장소에서는 rootDir를 명시하지 않으면 출력 경로나 포함 파일 범위가 달라질 가능성이 높습니다. src만 컴파일하려면 아래처럼 고정합니다.

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

1.3. 타입 패키지 자동 탐색 차이

테스트 도구나 런타임 타입이 자동으로 잡히지 않으면 types 값을 직접 지정합니다.

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

확인

npx tsc --version
npx tsc --noEmit

TypeScript 7.x 버전이 나오고 기존 프로젝트 타입 검사가 통과하면 기본 전환은 정상입니다.

npx tsc6 --noEmit
npx tsc --noEmit

병행 구성에서 두 명령이 모두 통과하면 기존 도구 호환성과 새 컴파일러 점검 경로가 분리된 것입니다.