TypeScript 7.0 RC: 빠른 컴파일러보다 먼저 CI 리허설을 시작할 때
TypeScript 7.0 RC가 나왔다. 이 소식의 표면은 “Go 기반 컴파일러가 훨씬 빠르다”이지만, 실무팀이 오늘 해야 할 일은 속도 벤치마크를 공유하는 것이 아니다. RC는 이제 호기심 단계가 아니라 릴리스 리허설 단계다. `typescript@rc`를 설치하면 새 컴파일러가 `tsc`로 들어오고, 곧 안정 버전이 같은 경로를 차지한다.
이미 이 블로그에서는 TypeScript 7 Beta와 `tsgo`를 “빠른 컴파일러보다 전환 검증이 중요하다”는 관점으로 다룬 적이 있다. 이번 RC는 그 주제를 한 단계 밀어붙인다. 패키지 이름, 실행 파일, 병렬화 옵션, TypeScript 6 병행 패키지, 하드 에러 전환이 구체화됐기 때문에 이제는 실제 저장소에서 CI 리허설을 돌릴 수 있다.
무슨 일이 있었나
Microsoft TypeScript 팀은 2026년 6월 18일 TypeScript 7.0 RC를 발표했다. RC는 `npm install -D typescript@rc`로 설치하고, `npx tsc --version`에서 7.0 RC 계열 버전을 확인하는 방식이다. Beta 시점의 `@typescript/native-preview`와 `tsgo` 중심 실험에서, 안정 릴리스에 가까운 `typescript` 패키지와 `tsc` 진입점으로 이동한 것이 중요하다.
TypeScript 7.0은 기존 TypeScript/JavaScript 코드베이스를 Go로 옮긴 새 기반 위에 있다. 팀은 이 포팅이 새 언어 설계를 처음부터 다시 쓴 것이 아니라 기존 구현을 구조적으로 맞춘 작업이라고 설명한다. 공식 글은 TypeScript 6.0과 같은 의미론을 유지하도록 설계됐고, 대규모 코드베이스와 긴 테스트 스위트로 검증됐다고 밝힌다.
RC에서 특히 실무적인 변화는 병행 운영 방식이다. TypeScript 7의 `tsc`와 TypeScript 6 계열 API 의존 도구를 함께 써야 하는 팀을 위해 `@typescript/typescript6` 패키지와 `tsc6` 실행 파일이 제공된다. 일부 도구가 `typescript` peer dependency를 직접 import하기 때문에, npm alias로 6.x API를 유지하고 별도 alias로 7 RC를 실행하는 전략도 제시됐다.
왜 중요한가
큰 저장소에서 TypeScript 속도는 생산성 그 자체다. 하지만 컴파일러가 빨라졌다는 사실만으로 업그레이드를 결정하면 위험하다. TypeScript는 언어이자 빌드 도구이며, 에디터 언어서버이고, ESLint·문서 생성기·코드 생성기·테스트 러너가 기대하는 API이기도 하다. 따라서 전환 판단은 “우리 코드가 통과하는가”와 “우리 도구가 같은 방식으로 동작하는가”를 나눠 봐야 한다.
RC가 중요한 이유는 안정 릴리스 전 마지막으로 팀 CI에서 현실 데이터를 얻을 수 있는 시점이기 때문이다. 공식 글은 TypeScript 7.0 안정 버전을 다음 달 안에 내는 것이 현재 계획이라고 설명한다. 이 일정은 약속된 계약이라기보다 현재 계획이지만, 개발팀 입장에서는 충분히 가까운 신호다. 지금 실패를 발견하면 upstream issue를 열거나 내부 migration backlog를 만들 시간이 있다.
또 하나의 실무 포인트는 TypeScript 6.0의 새 기본값과 deprecated flag가 7.0에서 더 직접적인 마찰로 나타난다는 점이다. `strict`, `module`, `target`, `noUncheckedSideEffectImports`, `types`, `rootDir` 같은 설정은 “컴파일러가 빨라졌다”는 이야기보다 실제 PR을 더 많이 막을 수 있다. 특히 `rootDir`과 `types` 변경은 기존 monorepo나 테스트 글로벌 타입 설정에서 의외의 실패를 만들기 쉽다.
커뮤니티 신호
커뮤니티 반응은 대체로 “속도가 충분히 체감되면 pre-commit이나 에디터 경험이 바뀐다”와 “TypeScript API에 기대는 도구는 언제 따라오나” 사이에 놓여 있다. Reddit과 Hacker News류 토론은 공식 사실 근거로 쓰기보다, 실무자가 무엇을 걱정하는지 보여주는 신호로 보는 편이 맞다. 반복되는 질문은 출시일보다도 “내 도구 체인이 깨지는가”, “6.x와 7.x를 얼마나 오래 같이 가져갈 수 있는가”에 가깝다.
GitHub의 TypeDoc 이슈처럼 TypeScript API를 직접 쓰는 도구 생태계도 전환 리스크를 일찍 드러내고 있다. TypeScript 7.0은 CLI와 언어서버 관점에서는 RC 단계에 왔지만, 공식 글은 안정적인 programmatic API가 적어도 TypeScript 7.1 이후에야 가능하다고 설명한다. 즉 애플리케이션 컴파일은 빨리 시험해볼 수 있지만, 빌드 도구 작성자와 플러그인 작성자는 더 긴 병행 기간을 예상해야 한다.
개발·운영 영향
개발팀의 첫 번째 영향은 CI 설계다. 기존 `tsc --noEmit` 잡을 바로 교체하지 말고, 같은 커밋에서 TypeScript 6과 7 RC를 나란히 돌리는 별도 잡을 만든다. 결과가 다르면 빌드를 즉시 막기보다 차이를 분류한다. 실제 타입 오류인지, 6.0 기본값 채택으로 드러난 설정 문제인지, JS/JSDoc 분석 차이인지, TypeScript API 의존 도구 문제인지 나눠야 한다.
두 번째 영향은 리소스 튜닝이다. TypeScript 7.0은 parsing, type-checking, emit, project reference build 일부를 병렬화한다. `--checkers`는 type-checking worker 수를, `--builders`는 project reference builder 수를 제어한다. 큰 monorepo에서는 빨라질 수 있지만, 작은 CI 러너에서는 메모리와 CPU 경합으로 오히려 불안정해질 수 있다. CI에서는 “가장 빠른 값”보다 “재현 가능한 고정값”이 더 중요하다.
세 번째 영향은 에디터 경험이다. VS Code 사용자는 TypeScript Native Preview 확장으로 RC 기반 언어서버를 시험할 수 있고, TypeScript 7의 새 기반은 LSP를 사용한다. 에디터가 빨라지면 개발자의 체감은 크지만, auto-import, semantic highlighting, sort imports, remove unused imports 같은 기능이 기존 워크플로와 같은지 실제 프로젝트에서 확인해야 한다.
팀이 바로 실행할 체크리스트
✓ CI에 TypeScript 6과 7 RC를 나란히 실행하는 별도 잡을 만든다.
✓ tsconfig에서 rootDir, types, moduleResolution, target, baseUrl 사용 여부를 먼저 스캔한다.
✓ JS/JSDoc 프로젝트는 TypeScript 파일보다 더 보수적으로 검증한다.
✓ --checkers와 --builders를 CI 러너 코어·메모리에 맞춰 고정값으로 실험한다.
✓ typescript-eslint, TypeDoc, transformer, codegen처럼 TypeScript API를 직접 import하는 도구를 분리 점검한다.
✓ 실패를 “컴파일 오류”, “도구 API 의존”, “성능/메모리”, “에디터 UX”로 나눠 이슈를 만든다.
리스크와 반론
반론은 분명하다. 모든 팀이 RC를 production CI의 필수 관문으로 바로 올릴 필요는 없다. 사용 중인 프레임워크나 플러그인이 TypeScript API에 깊게 기대고 있다면, 7.0 안정 릴리스가 나온 뒤에도 TypeScript 6 라인을 당분간 유지하는 편이 합리적일 수 있다. 특히 custom transformer, TypeDoc, typedoc-plugin, 타입 기반 codegen을 많이 쓰는 팀은 컴파일 성공만으로 전환 완료를 선언하면 안 된다.
또 다른 리스크는 “빠른 컴파일러” 기대가 품질 회귀를 가리는 것이다. 공식 글은 의미론적 호환성을 강조하지만, RC는 피드백을 받기 위한 릴리스다. 병렬 checkers 수가 달라졌을 때 드문 순서 의존 결과가 드러날 수 있고, JS 지원은 TypeScript 파일 분석 방식과 더 일관되게 바뀌면서 기존 JSDoc 관용구를 더 이상 인정하지 않을 수 있다.
따라서 실무 결론은 간단하다. TypeScript 7.0 RC를 메인 브랜치의 유일한 컴파일러로 바꾸지 말고, 오늘부터 매일 돌아가는 리허설로 붙인다. 통과하면 속도 이득을 측정하고, 실패하면 원인을 분류해 6.x 유지가 필요한 구간을 문서화한다. 안정 릴리스가 나왔을 때 당황하지 않는 팀은 RC 기간에 실패 목록을 만든 팀이다.