Typescript 6: 리허설

Source: Dev.to

1969년 5월 18일, NASA는 아폴로 10호를 발사했습니다.
세 명의 우주비행사 — 톰 스태포드, 존 영, 그리고 진 서넌 — 은 달로 향해 달 궤도에 진입한 뒤, 달 착륙선 **“스누피”**를 이용해 지표면에서 14.4 km 떨어진 곳까지 내려갔습니다. 이는 평온의 바다(Sea of Tranquillity)에서 바위를 볼 수 있을 만큼 가까운 거리였으며, 착륙하기에도 충분히 가까운 거리였습니다.

하지만 그들은 착륙하지 않았습니다. 착륙은 절대 일어나지 않을 예정이었습니다. NASA는 상승단에 연료를 의도적으로 부족하게 넣어, 승무원들이 상황에 휩싸여도 물리적으로 시도할 수 없게 만들었습니다. 아폴로 10호는 바로 리허설이었습니다. 모든 시스템이 테스트되고, 모든 절차가 검증되었으며, 모든 위험이 표면화되었습니다 — 단, 최종 위험만은 제외되었습니다. 59일 후, 아폴로 11호는 그 과정을 손쉽게 보여주었습니다.

Source:

TypeScript 6.0이 2026년 3월 23일에 출시되었습니다

아직 크게 신경 쓰지 않으셨다면 이해합니다. 버전 업데이트는 계속해서 나오니까요. 하지만 이번 버전은 다릅니다. 왜 중요한지 알아볼 가치가 있습니다.

마지막 종류

• TypeScript 6은 JavaScript 기반으로 구축된 TypeScript 컴파일러의 최종 릴리스입니다.
• 다음 주요 버전인 TypeScript 7(내부명 Project Corsa)은 Go 언어로 완전 재작성됩니다. 포팅도, 점진적 마이그레이션도 아니라, 다른 언어로 컴파일러를 처음부터 다시 만든 것입니다.

TypeScript 팀의 공식 발표는 이렇게 말합니다:

“TypeScript 6.0은 TypeScript 5.9와 7.0 사이의 다리 역할을 합니다.”

이는 제3자의 추측이 아니라, Microsoft가 이번 릴리스를 통해 다음 단계에 대비하라고 알려주는 것입니다.

다음 단계는 상당히 중요합니다. Go 기반 컴파일러는 VS Code의 150만 라인에 달하는 TypeScript를 약 8.7 초에 컴파일합니다. 현재 JavaScript 기반 컴파일러는 같은 작업에 89 초가 걸리며, 이는 10배 정도의 속도 향상입니다. 이는 선택적인 벤치마크가 아니라 실제 작업 환경에서 체감할 수 있는 개선이며, 작업 방식을 바꿔줍니다:

• 에디터 반응 속도 향상
• CI 파이프라인 시간 단축
• 코드를 작성하고 올바른지 확인하는 피드백 루프 가속

모두가 더 빨라집니다.

TypeScript 7의 정확한 출시일은 아직 정해지지 않았지만, 공식 입장은 **“몇 달 안에”**라는 것입니다. 프리뷰 컴파일러는 이미 @typescript/native-preview를 통해 사용할 수 있으며, 기존 테스트 스위트의 **99.6 %**를 통과했습니다. 이는 공상 과학이 아니라, 실제로 가까워진 상황입니다.

TS 6이 실제로 바꾸는 것

TypeScript 7이 달 착륙이라면, 실제 연습은 어떻게 보일까요? 중요한 변화는 세 가지 범주로 나뉩니다.

1. 새로운 기본값

tsconfig.json이 관대한 기본값과 암시적 해석에 의존하고 있었다면, 이제 그 가정이 깨집니다. 이는 의도된 변화이며, TypeScript 6은 TypeScript 7이 요구할 설정으로 여러분을 미리 안내합니다.

2. 폐기 예정 기능

TypeScript 6에서는 아직 동작하지만, TypeScript 7에서는 완전히 제거될 기능들:

• target: es5 → 최소 버전이 ES2015로 변경
• --baseUrl → 대신 paths 사용
• --outFile 번들링
• --moduleResolution node 및 --moduleResolution classic (둘 다 폐기)
• AMD, UMD, SystemJS 모듈 타깃
• --downlevelIteration

다음과 같이 설정하면 이러한 경고를 억제할 수 있습니다:

{
  "ignoreDeprecations": "6.0"
}

하지만 이 회피 방법은 TypeScript 7에서는 존재하지 않을 것입니다. 일시적인 방편일 뿐, 근본적인 해결책은 아닙니다.

3. TypeScript 7 동작 미리보기

--stableTypeOrdering 플래그를 사용하면 지금 바로 TypeScript 7의 유니온 멤버 정렬 방식을 선택할 수 있습니다. 오류 메시지나 툴팁에 표시되는 타입 순서에 민감한 테스트가 있다면, 컴파일러가 전환되기 전에 이 플래그로 미리 확인할 수 있습니다.

마이그레이션이 생각만큼 나쁘지는 않아요

TypeScript 팀은 **ts5to6**이라는 도구를 만들어 두 가지 가장 파괴적인 변경 사항—baseUrl 제거와 rootDir 추론—을 자동으로 처리합니다. 대부분의 프로젝트에 대한 업그레이드 경로는 다음과 같습니다:

1. tsconfig를 업데이트하여 moduleResolution을 명시적으로 설정합니다.
2. 남아 있는 모든 폐기 경고를 수정합니다.
3. 테스트 스위트를 실행합니다.

TypeScript 릴리스를 비교적 최신 상태로 유지해 왔다면, 이는 몇 시간 정도의 작업에 불과합니다—대규모 모노레포의 경우 하루 정도 걸릴 수도 있습니다. 파괴적인 변화는 실제로 존재하지만, 이는 구성 변경이며 언어 자체의 변화는 아닙니다. 실제 TypeScript 코드는 거의 변경할 필요가 없을 것입니다.

도구 관련 고려 사항

더 어려운 질문은 컴파일러 주변 도구에 무엇이 일어나는가입니다. TypeScript 7의 Go 기반 컴파일러는 현재 ESLint, 사용자 정의 트랜스포머, IDE 플러그인 등이 의존하고 있는 동일한 JavaScript API를 제공하지 않을 것입니다. 전환 기간 동안 Microsoft가 권장하는 접근 방식은 다음과 같습니다:

• API에 의존하는 도구를 위해 TypeScript 6을 유지합니다.
• 타입 검사와 빌드를 위해 네이티브 프리뷰(@typescript/native-preview)를 사용합니다.

우아하진 않지만 작동하며, 생태계가 따라잡을 시간을 제공합니다.

왜 그냥 기다리지 않을까?

여기서 Apollo 10은 단순히 좋은 이야기를 넘어서는 이유가 드러납니다.

NASA는 리허설을 건너뛸 수 있었습니다. 연료를 절약하고, 임무를 절약하고, 8일을 절약해서 바로 Apollo 11 착륙으로 넘어갈 수 있었죠. 하드웨어는 준비돼 있었고, 소프트웨어도 준비돼 있었으며, 승무원도 준비돼 있었습니다.

하지만 그들은 그렇게 하지 않았습니다. 복잡한 시스템에 대해 문제를 생각만으로 발견하지 않는다; 전체 시퀀스를 실행해 보아야 문제를 발견한다는 것을 이해했기 때문입니다. Apollo 10의 달 착륙선은 상승 단계에서 내비게이션 모드 오류가 발생해 달 표면 위에서 통제되지 않은 회전(카트휠) 8번을 하면서 무서운 순간을 맞았습니다. Cernan은 라디오로 실시간으로 욕설을 퍼부었고, Stafford는 수동으로 제어권을 잡아 15초 만에 복구했습니다. 그 오류는 발견되고, 이해되고, 수정되었습니다 — 그들이 리허설을 수행했기 때문이죠.

TypeScript 6을 건너뛰고 TypeScript 7을 기다린다면 두 세트의 변경 사항을 겹쳐 놓는 셈입니다. 모든 폐기된 옵션, 모든 기본값 변경, 모든 설정 가정 — 모두가 근본적으로 새로운 컴파일러 런타임과 동시에 충돌합니다. 어떤 문제가 TS 6 설정 문제이고 어떤 문제가 TS 7 호환성 문제인지 알 수 없게 됩니다. 두 차원에서 동시에 디버깅을 해야 하게 됩니다.

지금 바로 TypeScript 6으로 업그레이드하면 다음과 같이 관심사를 분리할 수 있습니다:

• 설정을 수정합니다.
• 레거시 옵션을 정리합니다.
• tsconfig를 TypeScript 7이 기대하는 형태로 맞춥니다.

그 후 TypeScript 7이 출시되면 마이그레이션은 단일, 깔끔한 단계가 됩니다 — 새 컴파일러 바이너리 하나만 교체하면 되며, 파편적인 깨지는 변화들의 연쇄는 없습니다.

Go 컴파일러가 떨어진다, 교체다

한 변수만 바뀌고, 스무 개는 아니다.

리허설에 대한 이야기

Apollo 10에 관한 한 가지 세부 사항이 조용히 뛰어나다고 생각합니다. 연료를 적게 넣은 것은 단순히 안전 조치가 아니라 의도적인 선언이었습니다. 승무원이 착륙할 수 없게 함으로써 NASA는 임무가 실제 목적에 집중되도록 했습니다: 다른 모든 것을 검증하는 것이죠. 앞당길 유혹도, 범위가 늘어나는 일도 없었습니다. 제약이 리허설을 더 좋게 만들었습니다.

TypeScript 6도 비슷한 특성을 가지고 있습니다. 실제로는 Go 컴파일러가 아니라 여전히 JavaScript이지만, 바로 그 제약이 전환 단계에서 유용하게 만듭니다. 익숙한 런타임 위에서 TypeScript 7의 기대치에 맞춰 프로젝트를 테스트할 수 있습니다. 무언가 깨지면, 그것이 컴파일러 문제라기보다 설정 문제라는 것을 바로 알 수 있습니다. 진단이 깔끔합니다.

--stableTypeOrdering 플래그는 전체 릴리스 중 가장 Apollo 10 같은 요소입니다. 새 컴파일러가 타입을 어떻게 정렬할지 미리 볼 수 있게 해 주어, 스위치 전에 테스트를 고칠 수 있습니다. 이것은 당신의 리허설을 위한 리허설입니다.

리허설 자체는 거의 기억되지 않습니다. 스태퍼드, 영, 그리고 서넌은 달에 갔다가 돌아왔지만, 대부분 사람들은 그들의 이름을 하나도 떠올리지 못합니다. Apollo 11이 퍼레이드를 얻었듯이, TypeScript 6도 빠른 버전으로 가는 길에 스쳐 지나가는 버전 번호가 될 가능성이 높습니다. 하지만 바로 그 리허설이 착륙을 가능하게 만든 것이죠.

Apollo 11은 Apollo 10 발사 후 59일 뒤에 출발했습니다. TypeScript 7이 정확히 언제 착륙할지는 모르지만 “몇 달 안에”라는 공식적인 말이 있고, 프리뷰는 이미 테스트 스위트의 거의 모든 테스트를 통과하고 있습니다.

리허설 창은 열려 있습니다. 영원히 열려 있지는 않을 겁니다.

원본은 markbasford.info에 2026년 3월 30일에 게시되었습니다.