TypeScript 7 정식 출시, 한국 웹팀이 속도보다 먼저 확인할 호환성 경계

TypeScript 7은 2026년 7월 8일 정식 출시됐습니다. 핵심 변화는 새 문법보다 컴파일러와 언어 서비스의 실행 기반입니다. Microsoft는 기존 TypeScript 구현을 Go로 이식해 네이티브 코드, 공유 메모리 다중 스레딩, Language Server Protocol(LSP)을 적용했습니다. 한국 개발팀에는 “바로 올릴 것인가”보다 “어떤 도구가 기존 TypeScript API에 묶여 있는가”를 먼저 확인하는 일이 중요합니다.

확인된 사실: 공식 발표는 TypeScript 7을 npm의 typescript 패키지로 제공하며, 전체 빌드에서 통상 8~12배 속도 향상을 측정했다고 설명합니다. 이는 Microsoft가 공개한 프로젝트 측정치이지 모든 저장소에 보장되는 수치가 아닙니다.

7월 8일 발표에서 실제로 바뀐 것

TypeScript 7의 tsc는 Go로 이식된 네이티브 실행 파일입니다. 공식 발표에 따르면 TypeScript 6.0의 타입 검사와 명령줄 동작에 맞추는 것을 목표로 했고, 새 기반은 네이티브 실행과 공유 메모리 병렬 처리를 사용합니다. 편집기 측면에서는 LSP를 채택해 명령줄과 같은 기반의 언어 서비스를 여러 편집기에서 연결할 수 있게 했습니다.

설치는 기존과 같은 명령입니다.

npm install -D typescript
npx tsc --version

그러나 설치 명령이 같다는 사실과 마이그레이션 위험이 없다는 뜻은 다릅니다. 공식 변경 문서는 JavaScript 검사, CommonJS 처리, 유니코드 위치 계산 등에서 이전 구현과 의도적으로 다른 동작을 기록합니다. 특히 소스 위치가 UTF-16 단위가 아니라 UTF-8 오프셋으로 표현되는 차이는 AST 위치를 직접 소비하는 사내 도구에 영향을 줄 수 있습니다.

속도 수치와 제품팀의 체감은 구분해야 한다

Microsoft는 여러 공개·대규모 코드베이스의 전체 빌드에서 7.7배부터 11.9배 범위의 결과를 제시하고, 통상 8~12배라고 요약했습니다. 이것은 발표사가 확인한 벤치마크입니다. 증분 빌드, 테스트 러너, 번들러, 린터까지 같은 비율로 빨라진다는 주장은 공식 자료에 없습니다.

POEMORA의 해석은 다음과 같습니다. 한국 SaaS나 커머스 팀에서 체감 효과가 큰 지점은 CI 전체 시간보다 로컬 타입 검사 대기와 대형 모노레포의 편집기 초기화일 가능성이 큽니다. 반대로 병목이 이미지 빌드, 네트워크 테스트, 서버 컴포넌트 렌더링에 있다면 TypeScript 교체만으로 배포 시간이 크게 줄지 않을 수 있습니다.

한국 웹팀이 먼저 확인할 호환성 경계

첫째, typescript를 직접 import하는 ESLint 플러그인, 코드 생성기, API 문서 도구를 목록화해야 합니다. TypeScript 팀은 7.0 RC 시점에 안정적인 프로그래밍 API가 적어도 7.1까지 제공되지 않을 수 있다고 안내했고, 6.0 API를 위한 호환 패키지를 병행할 수 있도록 했습니다. 명령줄 호환과 Node.js API 호환은 같은 문제가 아닙니다.

둘째, JavaScript와 CommonJS가 남아 있는 저장소를 별도로 시험해야 합니다. 공식 CHANGES 문서는 생성자 함수 형태, 중첩 expando, module.exports 혼합 할당처럼 새 구현에서 다르게 취급되는 사례를 열거합니다. 오래된 백오피스나 하이브리드 저장소일수록 순수 TypeScript 앱보다 차이가 먼저 드러날 수 있습니다.

셋째, 한국어 식별자나 이모지가 포함된 파일을 다루는 도구는 소스 위치 매핑을 확인해야 합니다. 변경 문서는 노드 위치가 UTF-8 오프셋을 사용한다고 밝힙니다. 진단 위치를 별도 서비스로 전달하거나 자체 편집기 확장을 운영한다면 한글 앞뒤의 위치가 정확한지 회귀 테스트가 필요합니다.

한 번에 교체하지 않는 전환 절차

1. 현재 TypeScript 6 기준의 tsc --noEmit 결과와 시간을 동일한 CI 머신에서 저장합니다.
2. 의존성 잠금 파일을 분리한 시험 브랜치에서 TypeScript 7을 설치합니다.
3. 타입 오류 개수만 보지 말고 생성 파일, 진단 위치, ESLint, 테스트 수집, Storybook과 IDE 동작을 비교합니다.
4. CommonJS·JavaScript·한글 소스가 있는 대표 패키지를 회귀 세트에 포함합니다.
5. 이상이 없으면 한 개 서비스의 CI부터 전환하고, 프로그래밍 API 소비 도구는 TypeScript 6 호환 경로를 유지합니다.

이 순서는 속도 개선을 부정하는 것이 아니라 측정 단위를 분리하는 방법입니다. 웹 개발 환경 개편이나 프런트엔드 빌드 파이프라인 점검이 필요하다면 POEMORA 웹 서비스에서 현재 병목과 호환성 경계를 함께 정리할 수 있습니다.

지금 결정할 것과 아직 단정할 수 없는 것

확인된 사실은 정식 패키지가 배포됐고, 컴파일러가 Go 기반 네이티브 구현으로 바뀌었으며, 공식 변경 문서에 이전 구현과의 차이가 기록돼 있다는 점입니다. 아직 단정할 수 없는 것은 각 팀의 실제 배포 시간 절감률, 모든 서드파티 플러그인의 호환 시점, 장기적인 프로그래밍 API 형태입니다.

따라서 의사결정 기준은 “공식 벤치마크가 빠르다”가 아니라 “우리 저장소의 타입 검사 비중이 크고, 직접 TypeScript API를 쓰는 도구의 대체 경로가 검증됐다”여야 합니다. 이 두 조건을 충족하면 TypeScript 7은 개발자 대기 시간을 줄일 현실적인 후보입니다. 하나라도 불명확하면 병렬 검증 기간을 두는 편이 안전합니다.