TypeScript 7 Beta와 tsgo: 빠른 컴파일러보다 중요한 것은 전환 검증이다
TypeScript 7.0 Beta가 나온 뒤 개발팀이 먼저 물어야 할 질문은 “얼마나 빨라졌나”가 아니라 “우리 코드베이스에서 어디까지 안전하게 바꿀 수 있나”입니다. Microsoft는 이번 베타를 Go로 포팅한 새 네이티브 기반 위에 올렸고, TypeScript 6.0과 같은 타입 체크 의미론을 유지하도록 포팅했다고 설명합니다. 동시에 @typescript/native-preview@beta와 tsgo라는 별도 진입점을 제공해 기존 tsc와 나란히 검증할 수 있게 했습니다.
이 조합은 중요합니다. TypeScript는 단순한 컴파일러가 아니라 CI의 품질 게이트, 에디터의 언어 서버, 선언 파일 생성기, 빌드 파이프라인의 일부, 때로는 AST와 타입 정보를 읽는 내부 도구의 런타임입니다. 그래서 TypeScript 7은 “업그레이드할 패키지”라기보다 “팀의 타입 인프라를 다시 계측할 기회”로 봐야 합니다.
무슨 일이 있었나
2026년 4월 21일 공개된 TypeScript 7.0 Beta는 기존 TypeScript 코드베이스를 Go로 포팅한 네이티브 구현입니다. Microsoft는 네이티브 코드 속도와 공유 메모리 병렬성을 통해 TypeScript 6.0 대비 대체로 큰 폭의 속도 개선을 기대할 수 있다고 설명하며, 베타 패키지는 npm install -D @typescript/native-preview@beta로 설치한 뒤 npx tsgo로 실행할 수 있다고 안내합니다.
중요한 설계는 “동시 운영”입니다. 안정 릴리스가 나중에 typescript 패키지와 tsc 엔트리로 이동하더라도, 현재 베타는 @typescript/native-preview와 tsgo로 분리되어 있습니다. 이는 팀이 기존 tsc --noEmit, project references, declaration emit, 에디터 경험을 한 번에 갈아엎지 않고 비교할 수 있게 해 줍니다.
왜 실무 개발자에게 중요한가
대형 TypeScript 프로젝트에서 타입 체크 시간은 단순 대기 시간이 아닙니다. CI 큐 길이, PR 리뷰 속도, 에디터 인덱싱 시간, AI 코딩 도구가 의미 정보를 읽는 비용까지 연결됩니다. 타입 체크가 빨라지면 “로컬에서는 생략하고 CI에서만 확인”하던 습관을 줄일 수 있고, 여러 패키지를 가진 모노레포에서 더 자주 전체 검증을 돌릴 수 있습니다.
하지만 속도 개선이 곧 무조건적인 기본값 전환을 뜻하지는 않습니다. typescript-go README는 API가 아직 준비되지 않았고, watch mode는 prototype 상태이며, LSP는 진행 중이라고 표시합니다. CHANGES 문서도 JavaScript와 JSDoc, declaration emit, CommonJS/expando 패턴에서 의도적인 차이를 설명합니다. 순수 TypeScript 코드가 대부분인 팀과 오래된 JS+JSDoc을 함께 관리하는 팀의 리스크 프로파일은 다릅니다.
커뮤니티와 현장 신호
공식 블로그는 이미 여러 대규모 코드베이스에서 사전 검증이 이뤄졌다고 밝힙니다. 반면 GitHub의 typescript-go 작업 흐름을 보면 언어 서비스, 파일 감시, UTF-8/UTF-16 위치 처리, LSP 요청 같은 주변부 개선이 계속 이어지고 있습니다. 이 신호는 베타가 “무시해도 되는 장난감”이라는 뜻도 아니고 “오늘 전체 조직 기본값으로 바꾸라”는 뜻도 아닙니다. 실무적으로는 컴파일러 경로부터 먼저 검증하고, 에디터와 자동화 도구는 별도의 체크포인트로 분리하는 것이 맞습니다.
팀에 미치는 개발·운영 영향
- CI: 처음에는
tsc결과를 기준으로 유지하고tsgo를 non-blocking job으로 추가합니다. 진단 차이가 반복적으로 0이거나 설명 가능해질 때만 실패 게이트로 승격합니다. - 에디터: VS Code Native Preview 확장은 한 팀이나 한 저장소에서 먼저 켭니다. 자동 완성, rename, find references, diagnostics가 업무 흐름에 충분한지 확인합니다.
- JS/JSDoc: 오래된 CommonJS, Closure 스타일 JSDoc, expando 패턴이 많은 저장소는 CHANGES.md를 먼저 읽어야 합니다. TypeScript 파일보다 JS 기반 선언 생성에서 차이가 날 가능성이 큽니다.
- 빌드 도구: TypeScript compiler API를 직접 호출하는 린터, 코드 생성기, 문서화 도구, 커스텀 빌드 스크립트는 아직 전환 대상에서 분리합니다.
- 모노레포: project references와 incremental build가 실제 패키지 그래프에서 잘 동작하는지 확인하고, watch mode가 릴리스 흐름에 필수라면 기본값 전환을 늦춥니다.
오늘 바로 할 수 있는 체크리스트
- 대표 저장소 하나를 골라
tsc --noEmit시간, 에러 수, declaration emit 결과를 기록합니다. npm install -D @typescript/native-preview@beta후npx tsgo --noEmit을 별도 CI job으로 추가합니다.- 진단 메시지의 개수뿐 아니라 파일 위치, JSDoc 기반 타입,
.d.ts출력 차이를 샘플링합니다. - VS Code Native Preview를 일부 개발자에게만 켜고, 에디터 기능 회귀를 이슈 템플릿으로 모읍니다.
- compiler API 의존 도구 목록을 작성하고, 해당 도구는 TypeScript 6 경로를 유지합니다.
- 전환 기준을 “빠른 느낌”이 아니라 “CI 차이 없음, 에디터 주요 기능 통과, 롤백 경로 확보”로 문서화합니다.
반론과 리스크
첫 번째 반론은 “베타를 왜 지금 보나”입니다. 답은 간단합니다. 기본값으로 채택하라는 뜻이 아니라, 큰 저장소일수록 차이를 찾는 데 시간이 걸리기 때문입니다. 베타 기간에 non-blocking 검증을 시작하면 안정 릴리스가 왔을 때 감으로 결정하지 않아도 됩니다.
두 번째 리스크는 성능 수치의 과대 일반화입니다. 공식 블로그의 수치는 대표 코드베이스에서의 결과이지, 모든 프로젝트의 보장값이 아닙니다. 특히 빌드 시간이 타입 체크가 아니라 번들링, 테스트, 코드 생성, 네트워크 캐시에 묶여 있다면 체감 개선은 제한적일 수 있습니다.
세 번째 리스크는 JavaScript 프로젝트입니다. CHANGES.md는 JS/JSDoc 해석에서 의도적인 정리를 많이 담고 있습니다. 현대적인 TypeScript 중심 코드베이스라면 큰 문제가 없을 수 있지만, 오래된 JSDoc 관습으로 타입을 유지하는 패키지는 별도 마이그레이션 비용을 계산해야 합니다.
결론
TypeScript 7 Beta의 핵심은 “Go로 만든 빠른 tsc”가 아닙니다. 더 정확히는 TypeScript 생태계가 컴파일러 성능 병목을 줄이는 새 운영 모델로 이동하고 있다는 신호입니다. 좋은 팀은 이 변화를 기다렸다가 한 번에 바꾸지 않습니다. 지금 tsgo를 병렬로 돌리고, 차이를 기록하고, 에디터와 API 의존성을 분리해 검증합니다. 그렇게 해야 안정 릴리스가 왔을 때 업그레이드는 모험이 아니라 이미 검증된 스위치가 됩니다.