Typescript 6: 드레스 리허설

I’m happy to translate the article for you, but I’ll need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.

TypeScript 6.0 shipped on March 23 , 2026

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

The last of its kind

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

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

“TypeScript 6.0 acts as the bridge between TypeScript 5.9 and 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 팀은 가장 파괴적인 두 가지 변화—baseUrl 제거와 rootDir 추론—를 자동으로 처리해 주는 ts5to6 라는 도구를 만들었습니다. 대부분의 프로젝트에 대한 업그레이드 순서는 다음과 같습니다:

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이 언제 착륙할지는 정확히 알 수 없지만, “몇 달 안에”가 공식적인 예상이며, 프리뷰는 이미 테스트 스위트의 거의 모든 테스트를 통과하고 있습니다.

리허설 기간은 열려 있습니다. 하지만 영원히 열려 있지는 않을 것입니다.

Originally published at markbasford.info on March 30, 2026.