# TypeScript 7.0 발표

> Clean Markdown view of GeekNews topic #31249. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31249](https://news.hada.io/topic?id=31249)
- GeekNews Markdown: [https://news.hada.io/topic/31249.md](https://news.hada.io/topic/31249.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-09T09:13:05+09:00
- Updated: 2026-07-09T09:13:05+09:00
- Original source: [devblogs.microsoft.com](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/)
- Points: 4
- Comments: 2

## Topic Body

- TypeScript 7.0은 도구체인을 Go 기반 네이티브 코드로 이식한 릴리스로, 대형 프로젝트의 전체 빌드에서 보통 **8~12배 속도 향상**을 제공함
- 새 `tsc`는 기존처럼 npm의 `typescript` 패키지로 설치하며, 편집기 지원은 **LSP 기반 언어 서버**로 VS Code, Visual Studio, WebStorm 등에서 동작함
- `vscode`, `sentry`, `bluesky`, `playwright`, `tldraw` 같은 코드베이스에서 빌드 시간이 크게 줄었고, 일부 환경에서는 **총 메모리 사용량**도 낮아짐
- TypeScript 7.0은 아직 안정적인 **프로그래밍 API**가 없어 `typescript-eslint`, Vue, MDX, Astro, Svelte, Angular 템플릿 타입 검사 등 TypeScript를 내장하는 도구는 TypeScript 6.0 병행이 필요함
- 새 기본값과 제거된 옵션이 있어 TypeScript 6.0 변경 사항을 먼저 적용하는 편이 전환에 유리하며, **TypeScript 7.1**에서 새 API 제공이 예정됨

---

### Go 기반 네이티브 TypeScript
- TypeScript 7.0은 TypeScript 도구체인의 **네이티브 포트**로, Go로 작성된 새 코드베이스를 사용함
- 기존 코드베이스의 구조와 로직을 최대한 유지해 두 컴파일러 간 결과의 **일관성**과 호환성을 맞추는 방향으로 포팅됨
- 새 코드베이스는 네이티브 코드 속도, 공유 메모리 기반 멀티스레딩, 여러 최적화를 통해 전체 빌드에서 보통 **8~12배** 빠른 결과를 냄
- 설치는 기존처럼 npm으로 가능함

```bash
npm install -D typescript
```

- 설치 후 워크스페이스에서 새 `tsc` 실행 파일을 사용할 수 있으며, `npx tsc`로 실행 가능함

### 개발 피드백 루프 단축
- TypeScript는 편집기 로딩, 전체 참조 찾기, 자동 완성, 진단, `tsc`, `--watch` 모드 등 개발 과정 여러 단계에 관여함
- TypeScript 7은 이 과정 전반의 대기 시간을 줄여 **피드백 루프**를 짧게 만듦
- VS Code 코드베이스에서 오류가 있는 파일을 열었을 때 첫 오류가 보이기까지 걸리는 시간은 약 **17.5초**에서 **1.3초 미만**으로 줄어 13배 이상 빨라짐
- 편집기 지원은 LSP 기반이며, 새 언어 서버는 멀티스레딩을 활용해 동시 요청을 빠르게 처리함
- VS Code 사용자는 [TypeScript 7 전용 확장](https://marketplace.visualstudio.com/items?itemName=TypeScriptTeam.native-preview)을 설치할 수 있고, 향후 몇 주 안에 VS Code 자체에도 TypeScript 7 지원이 포함될 예정임
- Visual Studio 최신 버전은 워크스페이스에 따라 TypeScript 7을 자동 활성화함

### 빌드 성능과 메모리 결과
- TypeScript 6과 7을 대형 오픈소스 코드베이스에서 비교한 전체 빌드 시간은 다음과 같음

| 코드베이스 | TypeScript 6 | TypeScript 7 | 속도 향상 |
| --- | ---: | ---: | ---: |
| vscode | 125.7초 | 10.6초 | 11.9배 |
| sentry | 139.8초 | 15.7초 | 8.9배 |
| bluesky | 24.3초 | 2.8초 | 8.7배 |
| playwright | 12.8초 | 1.47초 | 8.7배 |
| tldraw | 11.2초 | 1.46초 | 7.7배 |

- 같은 빌드에서 TypeScript 7은 대체로 **총 메모리 사용량**도 더 낮았음

| 코드베이스 | TypeScript 6 | TypeScript 7 | 메모리 변화 |
| --- | ---: | ---: | ---: |
| vscode | 5.2GB | 4.2GB | -18% |
| sentry | 4.9GB | 4.6GB | -6% |
| bluesky | 1.8GB | 1.3GB | -26% |
| playwright | 1.0GB | 0.9GB | -11% |
| tldraw | 0.6GB | 0.5GB | -15% |

### 실제 코드베이스 검증과 팀 피드백
- TypeScript 프로젝트는 10년 이상 누적된 **수만 개 테스트**를 모든 `main` 브랜치 커밋에서 실행함
- TypeScript 7은 이 테스트 외에도 내부·외부 대형 팀의 실제 코드베이스에서 검증됨
- Microsoft 내부에서는 Loop, Office, PowerBI, Teams, Xbox 팀이 TypeScript 7을 검증함
- 외부에서는 Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero 등이 코드베이스에서 테스트하고 피드백을 제공함
- 새 언어 서버는 TypeScript 6.0 대비 실패한 언어 서버 명령을 **80% 이상**, 서버 크래시를 **60% 이상** 줄임
- 실제 팀 피드백에는 다음 사례가 포함됨
  - Slack은 TypeScript 7로 merge queue 시간이 **40%** 줄었고, CI 타입 검사 시간이 약 **7.5분에서 1.25분**으로 낮아졌다고 전함
  - Vanta는 큰 프로젝트 중 하나에서 최대 **9배** 빌드 속도 향상을 보임
  - Microsoft News Services 팀은 CI 빌드 대기 시간을 월 **400시간** 절감함
  - Canva는 편집기에서 첫 오류가 보이기까지 걸리는 시간이 약 **58초에서 4.8초**로 줄었다고 전함

### TypeScript 6.0과 병행 실행
- TypeScript 7.0은 아직 **API를 포함하지 않음**
- TypeScript 7.1에서 새롭고 다른 API를 제공할 예정임
- 그 전까지 컴파일러에 대한 프로그래밍 접근이 필요한 도구를 위해 TypeScript 6.0과 7.0을 병행 실행할 수 있음
- 새 호환성 패키지 `@typescript/typescript6`는 `tsc6` 실행 파일을 제공하고 TypeScript 6.0 API를 다시 내보냄
- `typescript-eslint`처럼 peer dependency로 `typescript`를 직접 import하는 도구에는 npm alias 사용을 권장함

```bash
npm install -D typescript@npm:@typescript/typescript6
```

- TypeScript 6 API와 TypeScript 7의 `tsc`를 함께 쓰려면 다음처럼 alias를 둘 수 있음

```json
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
```

- 기존 `@typescript/native-preview` 패키지는 TypeScript 7 새 코드베이스의 nightly 빌드를 제공해 왔고, 주간 다운로드가 **850만 회 이상**이었음
- 앞으로 nightly 빌드는 표준 `typescript` 패키지의 `next` 태그로 재개될 예정임

```bash
npm install -D typescript@next
```

### 병렬화 제어 옵션
- TypeScript 7.0은 파싱, 타입 검사, emit 등 여러 단계를 **병렬 실행**함
- 파싱과 emit은 파일별로 독립 실행이 쉬워 큰 코드베이스에서 비교적 적은 오버헤드로 확장됨
- 새 실험적 플래그 `--checkers`, `--builders`, `--singleThreaded`가 병렬화 동작을 조정함
- ## `--checkers`
  - TypeScript 7.0은 고정된 수의 타입 검사 워커를 만들고, 같은 입력 파일에 대해 항상 동일하게 작업을 나눠 동일한 결과를 내도록 함
  - 기본 타입 검사 워커 수는 **4개**이며, `--checkers`로 조정 가능함
  - `--checkers 8`을 사용한 같은 머신의 결과는 다음과 같음

  | 코드베이스 | TypeScript 6 | TypeScript 7 `--checkers 8` | 속도 향상 |
  | --- | ---: | ---: | ---: |
  | vscode | 125.7초 | 7.51초 | 16.7배 |
  | sentry | 139.8초 | 12.08초 | 11.6배 |
  | bluesky | 24.3초 | 2.01초 | 12.1배 |
  | playwright | 12.8초 | 1.16초 | 11배 |
  | tldraw | 11.2초 | 1.06초 | 10.6배 |

  - `--checkers`를 늘리면 더 많은 CPU 코어를 활용해 빌드가 빨라질 수 있지만, 보통 **메모리 사용량 증가**가 따름
  - CPU 코어와 메모리가 적은 CI runner에서는 값을 낮춰 불필요한 오버헤드를 피할 수 있음
  - `--checkers 1`은 타입 검사를 사실상 단일 스레드로 만들고 중복 작업을 제거함
  - 드문 경우 `--checkers` 수 변화가 순서 의존 결과를 드러낼 수 있어, 빌드 환경 전반에서 고정된 checker 수를 지정하는 방식이 도움이 될 수 있음
- ## `--builders`
  - `--builders`는 `--build` 실행 시 동시에 실행할 수 있는 **프로젝트 참조 빌더** 수를 제어함
  - 프로젝트가 많은 monorepo에서 특히 도움이 될 수 있음
  - 값을 늘리면 빌드가 빨라질 수 있지만 메모리 사용량도 증가할 수 있음
  - `--checkers`와 곱셈 효과가 있어 `--checkers 4 --builders 4`는 최대 **16개 타입 검사기**가 동시에 실행될 수 있음
  - `--builders` 수 변화는 `--checkers`와 달리 다른 결과를 만들지 않아야 함
  - 프로젝트 참조 빌드는 기본적으로 프로젝트 **의존성 그래프**에 의해 병목이 생김
- ## `--singleThreaded`
  - `--singleThreaded`는 컴파일러 전체를 단일 스레드로 실행하게 함
  - 디버깅, TypeScript 6과 7의 성능 비교, 외부 병렬 빌드 오케스트레이션, 리소스가 매우 제한된 환경에서 유용할 수 있음
  - 이 플래그는 타입 검사 워커 수를 1로 제한할 뿐 아니라 파싱과 emit도 단일 스레드에서 수행하게 함

### 새 `--watch` 모드
- TypeScript 7은 `--watch` 모드를 완전히 다시 만들었음
- 새 `--watch`는 [Parcel bundler의 file-watcher](https://github.com/parcel-bundler/watcher)를 기반으로 효율적이고 안정적인 크로스플랫폼 파일 감시 기능을 제공함
- Go 표준 라이브러리에는 내장 파일 감시 API가 없고, 검토한 서드파티 라이브러리들은 안정성, 성능, 크로스플랫폼 지원, 빌드 도구 통합에서 문제가 있었음
- 순수 polling 방식은 여러 운영체제에서 동작했지만, `node_modules` 의존성이 많은 대형 프로젝트에서는 계산 비용이 컸음
- TypeScript 팀은 VS Code에서 쓰여 온 [`@parcel/watcher`](https://www.npmjs.com/package/@parcel/watcher)를 Go로 포팅했고, C++ 툴체인 의존성을 피하기 위해 최소한의 어셈블리 shim을 사용함
- 이 watcher는 독립 패키지이며, TypeScript 7의 `--watch` 모드에서 플랫폼 전반의 **리소스 사용 개선**을 가져옴

### TypeScript 6.0 기본값과 호환성 변화
- TypeScript 7.0은 TypeScript 6.0의 타입 검사와 명령줄 동작과 호환되도록 만들어짐
- `stableTypeOrdering` 플래그가 켜져 있고 `ignoreDeprecations`가 설정되지 않은 상태에서 TypeScript 6.0으로 깨끗하게 컴파일되는 코드는 TypeScript 7.0에서도 동일하게 컴파일되어야 함
- TypeScript 7.0은 TypeScript 6.0의 새 기본값을 채택하고, TypeScript 6.0에서 deprecated된 플래그와 구문에는 **hard error**를 냄
- 주요 설정 기본값 변화는 다음과 같음
  - `strict` 기본값은 `true`
  - `module` 기본값은 `esnext`
  - `target` 기본값은 `esnext` 직전의 현재 안정 ECMAScript 버전
  - `noUncheckedSideEffectImports` 기본값은 `true`
  - `libReplacement` 기본값은 `false`
  - `stableTypeOrdering` 기본값은 `true`이며 끌 수 없음
  - `rootDir` 기본값은 `./`
  - `types` 기본값은 `[]`이며, 이전 동작은 `["*"]`로 복원 가능함
- `rootDir`과 `types` 변화가 가장 놀라울 수 있는 변경으로 꼽힘
  - `tsconfig.json`이 `src` 같은 소스 디렉터리 밖에 있는 프로젝트는 기존 디렉터리 구조 유지를 위해 `rootDir`을 명시해야 함
  - 특정 전역 선언에 의존하는 프로젝트는 필요한 `@types` 패키지를 `types`에 명시해야 함

```json
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}
```

```json
{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}
```

### 제거되거나 hard error가 된 동작
- TypeScript 7.0에서는 TypeScript 6.0에서 deprecated된 여러 옵션과 구문이 더 이상 지원되지 않음
- 주요 항목은 다음과 같음
  - `target: es5` 미지원
  - `downlevelIteration` 미지원
  - `moduleResolution: node/node10` 미지원, `nodenext`와 `bundler` 권장
  - `module: amd, umd, systemjs, none` 미지원, bundler 또는 브라우저 기반 모듈 해석과 함께 `esnext`나 `preserve` 권장
  - `baseUrl` 미지원, `paths`는 `baseUrl` 대신 프로젝트 루트 기준 상대 경로로 업데이트 가능함
  - `moduleResolution: classic` 미지원, `bundler` 또는 `nodenext` 권장
  - `esModuleInterop`과 `allowSyntheticDefaultImports`는 `false`로 설정할 수 없음
  - `alwaysStrict`는 `true`로 간주되며 `false`로 설정할 수 없음
  - namespace 선언에서 `module` 키워드 사용 불가
  - import에서 `asserts` 키워드 사용 불가, ECMAScript import attribute 문법 변화에 맞춰 `with` 사용 필요
  - `skipDefaultLibCheck` 아래에서 `/// <reference no-default-lib />` 지시문은 더 이상 존중되지 않음
  - 현재 디렉터리에 `tsconfig.json`이 있으면 명령줄 빌드에서 파일 경로를 받을 수 없고, 명시적 `--ignoreConfig`가 필요함

### 템플릿 리터럴 타입과 JavaScript 지원 변화
- TypeScript 7.0은 템플릿 리터럴 타입 추론에서 Unicode code point를 더 자연스럽게 처리함

```ts
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// 이전: ["\ud83d", "\ude00abc"]
```

- 이전에는 JavaScript의 UTF-16 indexing 동작을 따라 `"😀"`를 surrogate pair의 두 부분으로 나눴음
- 새 동작은 `for...of`나 `[...str]`처럼 `"😀"`를 하나의 단위로 다루는 직관에 맞음
- UTF-16 code unit을 의도적으로 모델링한 타입 수준 문자열 조작에는 **breaking change**가 될 수 있음
- JavaScript 지원은 TypeScript 파일 분석 방식과 더 일관되도록 재작업됨
  - 타입 위치에서 값을 사용할 수 없고 `typeof someValue`를 써야 함
  - `@enum`은 더 이상 특별 취급되지 않음
  - 단독 `?`는 타입으로 사용할 수 없고 `any`를 써야 함
  - `@class`는 함수를 생성자로 만들지 않으며 `class` 선언을 써야 함
  - postfix `!`는 지원되지 않음
  - 타입 이름은 `@typedef` 태그 안에서 정의해야 함
  - Closure 스타일 함수 문법은 더 이상 지원되지 않고 TypeScript 축약 문법을 써야 함
- `this` aliasing과 함수 `prototype` 전체 재할당 같은 일부 JavaScript 패턴도 더 이상 특별 취급되지 않음
- TypeScript 6.0과 7.0의 차이는 [`CHANGES.md`](https://github.com/microsoft/typescript-go/blob/main/CHANGES.md)에 더 자세히 정리되고 있음

### 편집기 기능과 제한
- TypeScript 7.0에는 beta 이후 누락됐던 여러 편집기 기능이 추가됨
- 자동 import, 확장 가능한 hover, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion 등이 포함됨
- semantic highlighting, “sort imports”, “remove unused imports” 등 TypeScript 7.0 beta에서 빠졌던 기능도 들어옴
- 언어 서버 품질을 위해 테스트와 진단 인프라를 재구축했고, GitHub의 주요 TypeScript·JavaScript 코드베이스를 대상으로 fuzz test를 수행할 수 있음

### 내장 언어 워크플로의 현재 제약
- Vue, MDX, Astro, Svelte 등을 사용하는 워크플로는 아직 TypeScript 7을 활용하지 못할 가능성이 높음
- Angular 템플릿 같은 특수 템플릿 타입 검사도 TypeScript 7을 사용하지 못할 가능성이 높음
- 주된 이유는 TypeScript 7이 아직 안정적인 **프로그래밍 API**를 노출하지 않기 때문임
- Volar처럼 TypeScript를 자체 컴파일러와 언어 서비스에 내장하는 도구는 현재 TypeScript 6.0에 의존할 수밖에 없음
- TypeScript 팀은 이 문제를 특정 시점의 제약으로 보고, 해당 프로젝트 유지관리자들과 협력해 TypeScript 7 지원을 확보할 계획임
- 그 전까지는 language server plugin이 필요 없는 시나리오에서 TypeScript 7 사용을 권장함
- Angular 프로젝트는 CLI에서 빠른 프로젝트 전체 오류 감지를 위해 TypeScript 7의 `tsc`를 쓰고, 편집기 지원에는 TypeScript 6.0을 함께 사용할 수 있음
- Vue, MDX, Astro, Svelte 등은 당분간 TypeScript 6.0을 계속 사용해야 함
- VS Code에서는 “Disable TypeScript 7 Language Server” 명령으로 TypeScript 6.0으로 되돌릴 수 있음

### 향후 계획
- TypeScript 7.0 출시는 TypeScript 프로젝트에서 1년 이상 주력한 네이티브 포트의 주요 마일스톤임
- 7.0 이후에는 새 기능 작업, 사용성 개선, 추가 성능 개선, 생태계를 위한 새 API 구현으로 돌아갈 예정임
- TypeScript 7.0 이전과 비슷하게 **3~4개월마다** 새 기능 릴리스를 낼 것으로 예상함
- TypeScript 7.1은 커뮤니티 전환을 돕기 위한 격차 해소와 새 API 제공이 예정되어 있음

## Comments



### Comment 61461

- Author: neo
- Created: 2026-07-09T09:43:22+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48833715) 
- 자체 테스트 기준 **TypeScript 7**의 속도 향상 수치는 다음과 같음
  
  Codebase | TypeScript 6 | TypeScript 7 | Speedup  
  ------------|--------------|--------------|--------  
  vscode | 125.7s | 10.6s | 11.9x  
  sentry | 139.8s | 15.7s | 8.9x  
  bluesky | 24.3s | 2.8s | 8.7x  
  playwright | 12.8s | 1.47s | 8.7x  
  tldraw | 11.2s | 1.46s | 7.7x
  
  책임 있게 마이그레이션하면서 이 정도 성과를 낸 팀이 대단함. Bun은 좀 보고 배웠으면 함. 궁금한 건 tsdown이나 esbuild처럼 TypeScript 코드베이스를 빌드해야 하는 하위 도구에는 어떤 영향이 있는지, **TS 7**과 현재 tsdown을 같이 쓸 수 있는지임
  - esbuild는 TypeScript에 전혀 의존하지 않으니 문제가 없음. tsdown은 `--isolatedDeclarations` 사용 여부에 따라 다르고, 아니라면 블로그 안내대로 **TypeScript 6**을 나란히 설치하면 됨
  - Bun의 마이그레이션이 무책임했다고 보는 건지 궁금함

- 예전엔 타입이 들이는 노력만큼 가치가 없다고 논쟁하던 시절도 있었음. TypeScript가 좋은 이유는 무엇보다 **타입을 대중화**했다는 데 있음
  - 타입을 싫어하는 사람은 잘 기억나지 않음. 많은 사람이 싫어했던 건 **정적 타이핑**, 더 정확히는 정적이고 명시적인 타이핑이었음  
    예를 들어 Python은 타입이 없어서 못 쓰겠다는 식의 말도 여러 번 들었는데, 그건 말이 안 됨. Python은 강타입 언어이고, 동시에 동적 타입 언어일 뿐임.  
    정말 타입이 없거나 보통 “문자열 기반 타입(stringly typed)”인 언어도 있음. 어릴 때 만졌던 AREXX는 숫자처럼 보여도 모든 값이 문자열이었고, sed 같은 Unix CLI 도구 대부분도 그렇게 볼 수 있음. 하지만 타입 관련 논쟁의 대부분은 Python 같은 동적 타입 언어를 둘러싼 것이었고, 약타입이나 무타입 언어가 대규모 프로젝트에 좋다고 말하는 사람은 거의 못 봄. 오히려 Python을 “타입이 없다”고 잘못 부르며 대규모 프로젝트에 쓸 수 없다고 하는 말을 많이 들었고, 실제로 Python으로 대규모 프로젝트를 만들던 입장에서는 혼란스러웠음
  - 예전의 **타입 시스템**이 그냥 별로였음. 합 타입(sum types) 같은 “OR” 타입을 표현하려고 클래스 계층을 강요하는 건 고통스러움. TypeScript, Rust, Swift, Kotlin처럼 합 타입이 있는 현대 언어들은 훨씬 쾌적함
  - 개인적으로 거의 그대로 “JavaScript에서 **타이핑 오류**를 겪어본 적이 없다”고 말한 사람과 세 번 대화한 적이 있음. 그중 두 명은 작업을 존중하던 사람들이라, 어떻게 그런 입장을 가질 수 있는지 이해하기 어려웠음
  - **대수적 자료형**과 패턴 매칭이 판을 바꿨다고 봄. Haskell처럼 과하게 가지 않아도 타입이 갑자기 훨씬 유용해졌음  
    예전 타입에 대한 노출은 C++/Java가 대부분이었고, 특히 C++는 지나치게 복잡한 언어를 만드는 법 말고는 무엇의 좋은 예시도 되기 어려움. 타입이 잘 적용된 모습을 한 번 보면 훨씬 설득하기 쉬움
  - 이제 **DependentTypeScript**만 기다리는 중임

- 여기서 진짜 인상적인 건 인류가 아는 가장 진보한 타입 시스템을 위해 두 개의 별도 코드베이스를 동시에 유지한 훌륭한 팀임. Rust 재작성도 기대됨
  - Rust 재작성이 의미 있을지는 잘 모르겠음. **Go**는 코딩이 빠르고, 코드를 보며 TypeScript를 1:1로 다시 구현하기 쉬움  
    Rust는 개발 시간이 훨씬 더 오래 걸릴 것임. Rust가 Go보다 20% 빠를 수는 있어도, TypeScript에서 Go로 얻은 향상만으로도 충분히 큼. vscode에서 Go의 11배 대신 Rust로 14배가 나올 수도 있겠지만, Go만으로도 이미 큰 차이를 만들기에 충분함
  - 가장 복잡하다고는 할 수 있어도 “가장 진보한” 타입 시스템인지는 모르겠음. 그 타이틀에 정답이 있지는 않겠지만, 증명 보조기 언어 중 하나가 더 그럴듯한 후보일 것 같음  
    TypeScript의 타입 시스템을 깎아내리려는 뜻은 아니고, 실제로 매우 흥미로운 작업임
  - Hugo와 여러 주요 Go 프로젝트를 만든 Steve Francia가 **에이전트 시대의 Go**에 관해 쓴 글이 있음: [https://spf13.com/p/go-the-agentic-language/](<https://spf13.com/p/go-the-agentic-language/>)
  - “인류가 아는 가장 진보한 타입 시스템”이 정확히 무슨 뜻인지 궁금함
  - Rust 등도 진지하게 검토한 뒤 **Go를 선택**한 것으로 알고 있음. 이유는 다 기억나지 않지만 원래 블로그 글에 자세히 나와 있었음

- 몇 년 TypeScript를 쓰고 나니 Python에서 타입 주석을 직접 달고 `abc` 같은 기본 언어 기능을 가져와야 하는 게 정말 번거롭게 느껴짐

- 흥미롭지만, 이제 Node가 TypeScript 타입 주석을 네이티브로 제거하므로 **TSC**를 거의 실행하지 않음. 큰 회귀 변경을 만들고 업데이트하지 못한 부분을 컴파일러의 정적 출력으로 확인해야 할 때 정도만 돌림  
  브라우저로 갈 프런트엔드 코드도 Node의 타입 제거에 의존함
  - 맞는 말이지만, 한편으로는 에디터가 하루 종일 **TypeScript 언어 서버**를 돌리고 있음. 아마 CI도 그렇고, AI 에이전트도 방금 한 작업에 확신을 갖기 전에 그럴 것임

- **JSDoc 타입 문법**이 계속 관심을 받는 게 반가움. 개인 프로젝트에서 TypeScript를 쓰는 가장 좋아하는 방식임. 일부 문법 변경은 업데이트가 귀찮겠지만, 대부분은 더 나아지는 방향으로 보임
  - TypeScript가 Microsoft의 다른 언어들이 쓰는 끔찍한 XML 형식이 아니라 **JSDoc**을 써서 다행임  
    [1] [https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...](<https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/recommended-tags>)

- TypeScript의 큰 고통은 프로젝트 일부에 대해 `lib`와 `types` 같은 **tsconfig 설정 범위**를 조정하기 어렵다는 점임  
  프로젝트는 웹앱인데 `vite.config.ts`, Playwright, 단위 테스트 때문에 IDE 도구 쪽에 Node 타입이 들어와 있음. React 컴포넌트에 Node API를 추가해도 `tsc`가 불평하지 않음.  
  현재 DOM 라이브러리와 Node 라이브러리를 격리하려면 프로젝트 참조 스파게티, 수많은 `tsconfig.json`과 `tsbuildinfo` 출력 파일이 필요하고, 프로젝트 참조를 쓰면서 타입 출력을 피하는 것도 번거로움
  - 정말 고통스러운 부분에 동의함. **nx**를 쓰고 있는데 이런 부분을 대신 처리해 줌. Playwright는 자체 tsconfig를 가진 별도 프로젝트이고, 모두 루트 tsconfig를 상속함  
    단일 애플리케이션에서도 nx를 선호하고, 공유 코드는 “라이브러리”로 옮김. 빌드하지 않는 라이브러리를 쓰는데 큰 프로젝트에서는 꽤 좋음

- 아직 **TypeScript 컴파일러 API**는 없지만, 작업 중이라고 하니 기대됨
  - 7.1에 들어올 예정임

- 메모리 사용량은 줄고 성능은 크게 오른 그래프를 보면, 서버 쪽에서 TypeScript가 아니라 **Go**를 써야 하는 것 아닌가 싶어짐
  - 우선 서버 쪽에서 TypeScript를 실행하는 건 아님. 어떤 실행 엔진을 쓰든 변환된 코드나 JavaScript를 실행하는 것임  
    그리고 요즘 선택지가 있는데도 TS/JS/Python으로 새 프로젝트를 시작하는 사람이 왜 있는지는 잘 모르겠음
  - 프런트엔드 프로젝트와 **타입이나 모듈을 공유**할 수 있기 때문일 수 있음. CPU 집약적이지 않은 애플리케이션에서는 거의 차이가 없기 때문일 수도 있고, 익숙하고 좋아해서일 수도 있음. 라이브러리 생태계가 엄청나게 크다는 점도 있음
  - 이건 **빌드 시간 성능**이지 실행 시간 성능이 아님
  - Go와 JS(Node 등)의 성능 차이가 중요한지는 용례에 따라 다름. TypeScript 컴파일러에는 확실히 중요하지만, CRUD 앱에는 전혀 중요하지 않을 수도 있음
  - 가능하다면 하나의 주 언어로 작업하는 편이 더 쉽기 때문임

- TypeScript 팀 축하함. 길게 글이나 오디오로 올릴 내용이 있지만, 짧게 말하면 JavaScript/TypeScript 생태계는 **나무로 작업하는 것**과 비슷함  
  싸구려 라미네이트 판지 목재, Ikea식 물건도 만들 수 있음. 코드로 치면 독창성 없는 바이브 코딩 앱일 것임.  
  반대로 고급 수제 가구나 목조 고층 건물도 가능함. 어린 목재를 써서 맞춤 결합과 라미네이션 기법으로 내화성 있는 보를 만드는 식임. JavaScript/TypeScript 생태계에서도 AI를 강력한 공작기계처럼 쓰되 장인정신을 갖고 만드는 고급 결과물이 나올 수 있음. 뭔가 만들고 실행할 용기가 있다면 TypeScript/JavaScript 생태계를 받아들이면 됨

### Comment 61458

- Author: neo
- Created: 2026-07-09T09:13:06+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/txmyod/announcing_typescript_7_0) 
- 이유는 이해하지만, **자체 호스팅 컴파일러**에서 자체 호스팅이 아닌 컴파일러로 옮긴 점이 흥미로움  
  보통은 거의 항상 반대 방향으로 가기 때문에 보기 드문 흐름임
  - 이런 방향을 더 자주 봐야 한다고 생각함. 모든 언어가 **컴파일러 작성**에 적합한 것은 아님  
    자체 호스팅은 언어가 컴파일러를 더 잘 작성하는 언어로 진화하도록 강한 압력을 주는데, 그게 항상 올바른 방향은 아닐 수 있음
  - 언어 설계자와 구현자가 자기 언어가 모든 용도에 완벽하지 않다는 걸 이해하다니, 놀라움

- TypeScript로 코딩하지 않더라도, VSCode 자체가 TypeScript로 작성되어 있으니 이 개선이 **VSCode 속도**에도 영향을 주는지 궁금함  
  아니면 TypeScript 언어 확장에만 영향을 주는 건지 궁금함
  - 컴파일러가 빨라지는 것이지, 마법처럼 더 빠른 코드를 만들어내는 건 아님
  - **TypeScript 언어 확장**에만 해당함
  - TypeScript는 JavaScript로 컴파일됨. VSCode가 실행될 때는 node.js와 Chromium이 **JavaScript 코드**를 실행함  
    여기서 빨라지는 것은 TypeScript 코드를 받아 JavaScript로 바꾸는 컴파일러뿐이고, 이 과정은 Microsoft가 VSCode 실행 파일을 배포하기 전 빌드 파이프라인에서 일어남  
    잠재적인 예외가 있다면 TypeScript LSP 서버도 빨라질 수 있다는 정도인데, 이건 실제로 실행 중에 TypeScript 코드를 파싱하기 때문임. 다만 VSCode가 TypeScript로 작성됐다는 사실과는 별개임
  - TypeScript 컴파일러는 실제로 하는 일이 많지 않음. `tsc`는 타입 제거 같은 최소한을 제외하고 처리 중인 코드를 건드리면 안 된다는 원칙 때문에 **WONTFIX**로 표시되는 것들이 꽤 있음  
    그래서 TypeScript로 만든 도구들의 성능 특성은 거의 변하지 않을 것으로 예상함

- 개인적으로 얻은 작은 팁임. 현재 맡은 프로젝트는 **TS 5**를 쓰지만, 예상대로 nvim에서는 그걸 쓰고 싶지 않았음  
  그래서 먼저 mise로 TS 7을 설치하고, `node_modules/.bin` 안에 mise로 설치한 TS를 가리키는 `tsgo` 심볼릭 링크를 만들었음  
  nvim-lspconfig가 아직도 기술 미리보기 시절의 예전 `tsgo` 파일명을 쓰기 때문에, nvim이 로컬 TS 대신 설치해둔 **TS 7**을 실행하게 됨