TypeScript 7.0 RC 2026, 프런트엔드 빌드 비용·전환 기준

TypeScript 7.0 RC 전환 전 프런트엔드 빌드 속도와 CI 비용을 점검하는 릴리스 랩 장면 — TypeScript 7.0 RC 전환은 속도 숫자보다 CI runner, 설정 변경, 롤백 경로를 함께 봐야 한다.

TypeScript 7.0 RC를 검색하는 팀은 보통 “정말 10배 빨라지나”부터 확인한다.

하지만 기업 프런트엔드 전환 판단은 체감 속도보다 CI 비용, 메모리 한도, 설정 기본값 변화, 도구 호환성, 롤백 명령에서 갈린다.

Microsoft TypeScript 팀은 7.0 RC가 Go 기반 네이티브 포트이며 TypeScript 6.0과 구조적으로 같은 type-checking logic을 유지한다고 설명한다.

이 글은 TypeScript 7.0 RC 발표를 옮기는 글이 아니라, 대규모 코드베이스가 RC를 검증할 때 필요한 비용·보안·운영 기준을 정리한 실무 메모다.

핵심 요약

TypeScript 7.0 RC는 npm의 typescript@rc로 설치해 tsc처럼 실행할 수 있지만, 전면 교체 전에 TypeScript 6.0 기준선을 고정해야 한다.
--checkers와 --builders는 대형 monorepo에서 빌드 시간을 줄일 수 있지만, CI runner 메모리와 곱셈 효과를 먼저 측정해야 한다.
TypeScript 6.0의 strict, module, target, rootDir, types 기본값 변화와 deprecated flag hard error를 통과하지 못한 repo는 7.0 RC 전환 대상이 아니다.
RC 단계에서는 production hotfix repo가 아니라 design system, admin console, internal dashboard처럼 롤백이 쉬운 저장소부터 시작하는 편이 안전하다.

이 글이 필요한 사람

TypeScript 7.0 RC를 사내 프런트엔드 monorepo에 먼저 붙여 보려는 웹 플랫폼팀
CI 시간이 길고 runner 비용이 커져 type-check 단계부터 줄이고 싶은 DevOps 담당자
TypeScript 6.0 기본값 변화와 7.0 RC 네이티브 포트를 함께 검토해야 하는 프런트엔드 리드
VS Code Native Preview extension이나 LSP 기반 편집 경험을 사내 보안 기준에 맞춰 승인해야 하는 보안팀
AI 코딩 도구가 큰 TypeScript 코드베이스를 읽을 때 언어 서비스 지연과 비용을 줄이고 싶은 개발 생산성팀

TypeScript 7.0 RC 공식 발표에서 먼저 볼 사실

Microsoft TypeScript 블로그의 7.0 RC 글은 기존 TypeScript 코드베이스를 Go로 포팅했고, native code speed와 shared memory parallelism으로 TypeScript 6.0보다 often about 10 times faster라고 설명한다.

같은 글은 새 컴파일러를 npm install -D typescript@rc 명령으로 설치하고, 이후 npx tsc --version에서 7.0.1-rc 계열을 확인할 수 있다고 안내한다.

TypeScript 7.0 RC는 기존 구현을 새로 설계한 rewrite가 아니라 methodically ported from existing implementation이라는 점이 중요하다.

이 말은 전환 검증이 필요 없다는 뜻이 아니라, 같은 type-checking semantics를 목표로 삼았으니 차이를 측정할 기준선을 만들 수 있다는 뜻이다.

공식 항목	확인한 내용	실무 판단	놓치면 생기는 문제
설치	typescript@rc 설치 후 tsc 실행	별도 branch에서 lockfile을 고정한다	개발자마다 다른 RC 버전을 쓰면 결과가 흔들린다
호환성	TypeScript 6.0과 구조적으로 같은 type-checking logic 지향	ts6 결과와 ts7 결과를 같은 commit에서 비교한다	새 오류가 실제 breaking인지 설정 차이인지 모른다
병렬화	--checkers와 --builders 제공	CI runner core와 memory를 기준으로 값을 정한다	속도만 보고 올리면 OOM과 queue 지연이 생긴다
단일 스레드	--singleThreaded 제공	디버그와 성능 비교 기준으로 보관한다	병렬화 문제와 설정 문제를 분리하지 못한다
편집기	Native Preview extension과 LSP 기반 경험 제공	보안팀 승인 전에는 선택 적용으로 둔다	확장 설치 정책과 telemetry 검토가 늦어진다

검토할 만한 조건은 명확하다.

repo가 TypeScript 6.0에서 깨끗하게 통과하고, CI runner 메모리 여유가 있고, typecheck 시간이 전체 pipeline의 병목이라면 TypeScript 7.0 RC 파일럿 가치가 있다.

보류가 맞는 조건도 분명하다.

deprecated flag를 아직 쓰거나, tsconfig가 여러 앱에 흩어져 있거나, build artifact와 typecheck 책임이 분리되지 않았다면 먼저 TypeScript 6.0 정리부터 끝내야 한다.

CI 비용은 빌드 시간만이 아니라 runner 메모리와 재시도까지 본다

TypeScript 7.0 RC 발표는 parsing, type-checking, emitting, project reference build의 병렬화 구조를 설명한다.

특히 --checkers는 type-checker worker 수를 조절하고, --builders는 동시에 실행할 project reference builder 수를 조절한다.

문제는 두 값을 같이 올릴 때 생긴다.

공식 글도 --checkers 4 --builders 4 조합이 최대 16개의 type-checker를 만들 수 있어 과도할 수 있다고 경고한다.

측정 항목	TypeScript 6.0 기준선	TypeScript 7.0 RC 후보	의사결정 기준
typecheck 시간	main branch에서 5회 평균을 기록	같은 commit에서 5회 평균을 기록	2배 이상 줄어도 오류 차이를 먼저 본다
peak memory	runner별 최대 메모리 기록	--checkers와 --builders 값을 바꿔 기록	runner 한도의 85%를 넘기면 확대하지 않는다
CI 비용	typecheck job 분 단가와 재시도율 포함	새 값의 job 분 단가와 재시도율 포함	단순 초 단축보다 실패 재시도 비용을 더 본다
오류 차이	ts6 error count와 주요 error code 저장	ts7 error count와 주요 error code 저장	차이가 있으면 사람이 분류하기 전까지 보류한다
개발자 체감	editor startup과 completion 지연 기록	Native Preview 적용군에서 비교	보안 승인 없는 전체 배포는 막는다

실무 시나리오 하나.

40개 패키지를 가진 admin monorepo가 typecheck만 7분 걸리고, runner는 8GB 메모리 제한을 가진다.

이 팀은 --checkers 4 --builders 2부터 시작하고, 속도가 줄어도 peak memory가 7GB에 가까워지면 ci-lowmem script를 별도로 둬야 한다.

실무 시나리오 둘.

design system repo는 빠르게 통과하지만 product app repo는 JSDoc과 오래된 moduleResolution 설정이 섞여 있다.

이 경우 design system에서 RC를 먼저 검증하고, product app은 TypeScript 6.0 default migration과 deprecated flag 제거가 끝날 때까지 보류하는 편이 맞다.

TypeScript 6.0 정리가 7.0 RC 전환의 선행 조건이다

TypeScript 7.0 RC 글은 7.0이 TypeScript 6.0의 새 defaults와 no-op deprecated flag hard error를 채택한다고 설명한다.

따라서 TypeScript 5.x에서 곧장 7.0 RC로 뛰는 전환은 속도 테스트가 아니라 설정 부채 폭로가 되기 쉽다.

대표 변화는 strict 기본값, module 기본값, target 기본값, noUncheckedSideEffectImports, libReplacement, stableTypeOrdering, rootDir, types 기본값이다.

또 es5 target, downlevelIteration, node/node10 moduleResolution, classic moduleResolution, baseUrl 같은 항목은 hard error 또는 교체 검토 대상이 된다.

점검 영역	먼저 할 일	TypeScript 7.0 RC에서 보는 신호	담당자
tsconfig defaults	TypeScript 6.0 release note 기준으로 기본값 차이를 목록화	새 오류가 설정 기본값 변화와 연결되는지 확인	웹 플랫폼팀
moduleResolution	node10과 classic 사용 여부 검색	bundler 또는 nodenext 전환 영향 확인	앱 리드
rootDir	src 밖 tsconfig 구조 확인	출력 경로와 declaration 경로 차이 확인	빌드 담당자
types	전역 @types 의존을 명시 목록으로 전환	테스트 전역과 런타임 전역 누락 확인	테스트 담당자
baseUrl	paths를 project root 상대 경로로 정리	alias 해석과 bundler 설정 차이 확인	인프라 담당자

먼저 확인할 것은 성능 수치가 아니다.

TypeScript 6.0에서 clean build가 되고, 설정 변경을 문서화했으며, 오류 차이를 분류할 owner가 있는지다.

이 순서를 뒤집으면 7.0 RC가 나빠서 실패한 것인지, 오래된 tsconfig가 드러난 것인지 구분하지 못한다.

사이드바이사이드 전환은 tsc6와 tsc를 분리한다

Microsoft 발표는 TypeScript 6.0과 7.0을 나란히 실행할 수 있도록 @typescript/typescript6 compatibility package와 tsc6 executable을 안내한다.

이 구조를 쓰면 기존 tooling이 TypeScript 6.0 API에 의존하는 동안, 별도 script에서 TypeScript 7.0 RC의 tsc를 시험할 수 있다.

아래 package.json 예시는 공식 글의 alias 방향을 실무 전환용 script로 정리한 것이다.

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc"
  },
  "scripts": {
    "typecheck:ts6": "tsc6 --noEmit --extendedDiagnostics",
    "typecheck:ts7": "tsc --noEmit --extendedDiagnostics --checkers 4 --builders 2",
    "typecheck:ts7:ci-lowmem": "tsc --noEmit --extendedDiagnostics --checkers 2 --builders 1",
    "typecheck:ts7:debug": "tsc --noEmit --singleThreaded --extendedDiagnostics"
  }
}

중요한 점은 package manager와 lockfile을 같이 고정하는 것이다.

같은 alias라도 npm, pnpm, yarn workspace 정책이 다르면 bin resolution과 peer dependency 결과가 달라질 수 있다.

그리고 typescript-eslint, build tool plugin, custom transformer, codegen이 TypeScript API를 import한다면 tsc 결과만 보고 끝내면 안 된다.

보안과 공급망 기준은 RC 패키지와 편집기 확장까지 포함한다

TypeScript 7.0 RC 전환은 보안 제품 도입은 아니지만, 개발자 환경과 CI 공급망을 건드리는 변경이다.

npm registry에서 RC 패키지를 가져오고, VS Code Native Preview extension을 적용하고, CI runner에서 새 binary를 실행하기 때문이다.

보안 항목	초기 차단 기준	허용할 수 있는 시작점	증빙
패키지 소스	비공식 registry와 임의 tarball 금지	승인된 registry의 typescript@rc와 lockfile만 사용	lockfile diff와 dependency review
편집기 확장	전체 조직 자동 배포 금지	파일럿 그룹에만 Native Preview extension 허용	확장 승인 기록과 rollback 방법
CI artifact	로그에 source map과 secret 경로 노출 금지	extendedDiagnostics만 수집하고 원본 파일 업로드 금지	CI artifact 보존 정책
권한	release branch와 hotfix branch 직접 적용 금지	별도 migration branch에서만 실행	branch protection과 reviewer 기록
롤백	typescript@rc 제거 경로 미정 금지	tsc6 script와 lockfile rollback 커밋 준비	rollback PR과 owner

보안팀 설득 포인트는 “컴파일러니까 괜찮다”가 아니다.

어떤 registry에서 어떤 binary가 들어오고, 어떤 branch와 runner에서 실행되고, 어떤 artifact가 남는지를 좁히는 것이다.

이 범위를 좁히면 RC 단계에서도 제한된 파일럿은 가능하다.

범위를 넓게 열면 속도 개선보다 공급망 변경 승인 리스크가 먼저 커진다.

전환 순서는 작은 repo, 같은 commit, 같은 명령에서 시작한다

최근 2주 안에 main branch에서 TypeScript 6.0 typecheck가 깨끗하게 통과한 repo를 고른다.
source lockfile과 package manager 버전을 기록하고, typescript@rc 설치 branch를 따로 만든다.
baseline으로 npx tsc6 --noEmit --extendedDiagnostics를 3~5회 실행한다.
candidate로 npx tsc --noEmit --extendedDiagnostics --checkers 4 --builders 2를 3~5회 실행한다.
error count, error code, peak memory, elapsed time, CI retry, runner queue delay를 같은 표에 적는다.
차이가 생기면 TypeScript 6.0 default 변화, 7.0 RC behavior, tool API 의존성, JSDoc 차이로 분류한다.
확대는 design system과 internal dashboard에서 같은 기준을 통과한 뒤 product app으로 넘어간다.
production hotfix branch에는 stable release와 rollback 기준이 정해지기 전까지 적용하지 않는다.

이 절차는 느려 보이지만 실제로는 장애 시간을 줄인다.

성능 개선을 증명하려면 같은 commit과 같은 runner에서 비교해야 하고, 오류 차이를 사람이 분류해야 한다.

성급한 전환은 CI 시간을 줄여도 release 차단 오류 하나로 팀 전체 시간을 되돌릴 수 있다.

TypeScript 7.0 RC 운영 정책 스켈레톤

아래 YAML은 TypeScript 7.0 RC를 개인 실험이 아니라 팀 전환 파일럿으로 다룰 때 필요한 운영 기준 예시다.

실제 적용 전에는 공식 문서, 사내 보안 정책, package manager 정책, CI runner 사양에 맞게 값과 담당자를 바꿔야 한다.

# typescript70-rc-migration-gate.yaml
# 목적: TypeScript 7.0 RC를 대규모 프런트엔드 저장소에 적용하기 전 빌드, 메모리, 보안, 롤백 기준을 고정한다.
# 실제 값은 각 회사의 CI runner, monorepo 구조, lockfile 정책, 보안 규정에 맞게 조정한다.

owner:
  frontend_owner: web-platform-team
  ci_owner: devops-platform
  security_owner: application-security
  cost_owner: finops-owner

scope:
  primary_package: typescript@rc
  fallback_package: '@typescript/typescript6'
  first_repositories:
    - design-system
    - admin-console
    - internal-dashboard
  blocked_repositories:
    - payment-frontend
    - customer-data-workbench
    - release-critical-hotfix

compatibility_gate:
  baseline_command: npx tsc6 --noEmit --extendedDiagnostics
  candidate_command: npx tsc --noEmit --extendedDiagnostics
  require_same_error_count: true
  require_same_emit_artifacts: false
  allow_jsdoc_behavior_review: true
  require_typescript6_clean_before_typescript7: true

parallelism_gate:
  default_checkers: 4
  default_builders: 2
  ci_low_memory_checkers: 2
  single_threaded_debug_command: npx tsc --noEmit --singleThreaded
  fail_if_runner_memory_pressure: true

security_gate:
  lockfile_required: true
  package_manager_approved_registry_only: true
  dependency_review_required: true
  no_secret_files_in_ci_artifacts: true
  editor_extension_optional_until_security_review: true

exit_criteria:
  expand_if:
    - same_type_errors_or_reviewed_diff
    - ci_minutes_reduced
    - memory_peak_within_runner_limit
    - rollback_command_verified
  stop_if:
    - unexplained_type_error_delta
    - unstable_project_reference_order
    - ci_oom_or_runner_queue_spike
    - unreviewed_config_default_change

비용 점검은 빠르다는 주장보다 같은 작업당 CI 분과 실패 재시도율을 비교해야 한다.

아래 Python 예시는 TypeScript 6.0과 TypeScript 7.0 RC 실행 결과를 CI 비용과 확대 기준으로 바꾸는 검사용 스켈레톤이다.

#!/usr/bin/env python3
# ts70_ci_compare.py
# 목적: TypeScript 6.0과 TypeScript 7.0 RC의 CI 결과를 같은 저장소에서 비교한다.
# 실제 운영 전에는 runner 종류, 캐시 정책, lockfile, branch 보호 규칙을 함께 기록한다.

from dataclasses import dataclass

@dataclass
class Run:
    name: str
    seconds: float
    peak_memory_mb: int
    error_count: int
    ci_minutes_price: float = 0.008


def estimate(row: Run) -> dict:
    ci_cost = row.seconds / 60 * row.ci_minutes_price
    return {
        "name": row.name,
        "seconds": row.seconds,
        "peak_memory_mb": row.peak_memory_mb,
        "error_count": row.error_count,
        "estimated_ci_cost": round(ci_cost, 4),
    }


def gate(baseline: Run, candidate: Run) -> dict:
    speedup = baseline.seconds / candidate.seconds if candidate.seconds else 0
    same_errors = baseline.error_count == candidate.error_count
    memory_ok = candidate.peak_memory_mb <= 0.85 * 8192
    return {
        "speedup": round(speedup, 2),
        "same_errors": same_errors,
        "memory_ok": memory_ok,
        "expand": speedup >= 2.0 and same_errors and memory_ok,
        "manual_review": not same_errors or not memory_ok,
    }


if __name__ == "__main__":
    ts6 = Run("typescript6", seconds=420, peak_memory_mb=5300, error_count=0)
    ts7 = Run("typescript7-rc", seconds=96, peak_memory_mb=6100, error_count=0)
    print(estimate(ts6))
    print(estimate(ts7))
    print(gate(ts6, ts7))

AI 코딩 도구와 함께 볼 때의 추가 기준

Microsoft의 native port 발표는 빠른 language service가 AI tools에도 더 큰 semantic window를 줄 수 있다고 설명한다.

이 지점 때문에 TypeScript 7.0 RC는 단순 typecheck 개선이 아니라 코딩 에이전트와 IDE 응답성까지 함께 검토할 만하다.

비교 축	TypeScript 7.0 RC에서 볼 항목	코딩 도구에서 볼 항목	판단 기준
언어 서비스	LSP 기반 editor experience와 command latency	Claude Code, Codex, Copilot이 큰 repo를 읽는 시간	첫 응답보다 반복 탐색 시간이 줄었는가
정확성	ts6와 ts7 error delta	AI가 제안한 수정의 typecheck 통과율	사람이 되돌린 PR이 줄었는가
비용	CI minute와 runner memory	토큰 재시도와 파일 재방문	전체 개발 비용이 줄었는가
보안	확장, registry, artifact 범위	MCP server와 repo 권한 범위	승인 없이 production 파일을 건드리지 않는가
운영	--checkers, --builders, --singleThreaded 기준	agent task boundary와 rollback 기준	실패 원인을 추적할 로그가 있는가