한 줄 요약: 2026년 기준, 팀 규모 5명 이상이거나 코드베이스가 3개월 이상 유지될 프로젝트라면 TypeScript가 기본값이다. 단독 개발 소규모 스크립트나 빠른 프로토타이핑이라면 JavaScript에서 시작해도 늦지 않는다. TypeScript의 정적 타입 시스템이 실제로 잡아내는 버그 유형을 구체적으로 파악해야 전환 가치를 판단할 수 있다. 단순히 "타입 오류를 잡는다"는 설명은 실무 판단에 부족하다.
한 줄 요약: 2026년 기준, 팀 규모 5명 이상이거나 코드베이스가 3개월 이상 유지될 프로젝트라면 TypeScript가 기본값이다. 단독 개발 소규모 스크립트나 빠른 프로토타이핑이라면 JavaScript에서 시작해도 늦지 않는다.
TypeScript의 정적 타입 시스템이 실제로 잡아내는 버그 유형을 구체적으로 파악해야 전환 가치를 판단할 수 있다. 단순히 "타입 오류를 잡는다"는 설명은 실무 판단에 부족하다.
TypeScript가 컴파일 타임에 잡는 버그:
user.name에서 user가 null일 수 있음setRange(end, start) 실수user.adress 오타JavaScript에서도 잡을 수 있는 것: ESLint + JSDoc 타입 주석 + // @ts-check를 조합하면 TypeScript 없이도 IDE 레벨 타입 힌트와 일부 정적 분석이 가능하다. 단, 복잡한 제네릭·조건부 타입·exhaustive check는 JSDoc으로 표현하기 어렵다.
TypeScript가 실제로 잡는 버그 예시// JavaScript에서 런타임 오류가 될 코드 function processUser(user) { return user.profile.avatar.url; // user.profile이 null이면 런타임 오류 } // TypeScript — 컴파일 타임에 오류 감지 interface User { profile: UserProfile | null; } interface UserProfile { avatar?: AvatarInfo; // 선택적 필드 } interface AvatarInfo { url: string; } function processUser(user: User): string | undefined { return user.profile?.avatar?.url; // 옵셔널 체이닝 강제 } // Union 타입 exhaustive check type Status = 'pending' | 'success' | 'error'; function handleStatus(status: Status) { switch (status) { case 'pending': return '처리 중'; case 'success': return '완료'; // 'error' 누락 시 TypeScript가 오류 발생 default: const _: never = status; // exhaustive guard } }
TypeScript 도입의 초기 비용과 장기 이득을 정직하게 비교해야 한다. 타입 정의 작성, 빌드 설정, 서드파티 타입 패키지(@types/...) 관리가 추가된다. 반면 장기적으로는 리팩토링 안전성, IDE 자동완성, 코드 리뷰 시간이 줄어든다.
TypeScript가 생산성을 실제로 올리는 시나리오:
JavaScript가 더 빠른 시나리오:
2026년 기준 에코시스템 현황에서 몇 가지 중요한 변화가 있다.
TypeScript 네이티브 지원 확산: Deno는 TypeScript를 트랜스파일 없이 직접 실행한다. Bun도 TypeScript를 빌드 없이 실행 지원. Node.js 22+는 --experimental-strip-types 플래그로 .ts 파일을 직접 실행 가능하다. 빌드 단계 없이 TypeScript를 사용하는 환경이 늘어났다.
타입 정의 커버리지: DefinitelyTyped에는 8,000개 이상의 @types 패키지가 있다. 주요 라이브러리 대부분이 자체 타입 정의를 번들링한다. 단, 오래된 라이브러리나 틈새 라이브러리는 여전히 타입 정의가 없거나 부정확할 수 있다.
번들러 지원: Vite, esbuild, Rollup, webpack 모두 TypeScript를 기본 지원한다. 별도 설정 비용이 3~4년 전보다 크게 줄었다.
Node.js에서 TypeScript 직접 실행 (Node 22+)# Node.js 22+ — 실험적 TypeScript 직접 실행 node --experimental-strip-types script.ts # tsconfig.json 없이도 동작 (기본 설정으로) # 타입 오류는 무시하고 실행 (타입 체크는 tsc --noEmit으로 별도 실행) # 권장 워크플로우 (타입 체크 + 실행 분리) npx tsc --noEmit # 타입 오류만 확인 node --experimental-strip-types src/index.ts # 실행 # Bun — 빌드 없이 TS 실행 bun run src/index.ts # Deno — 빌드 없이 TS 실행 deno run src/index.ts
TypeScript를 처음 배울 때 진짜로 어려운 부분은 기본 타입 지정이 아니다. 오히려 다음 개념에서 막히는 경우가 많다.
1. 제네릭: 함수나 클래스가 다양한 타입을 처리할 때 사용하는 타입 매개변수. 기존 JavaScript 개발자가 처음 접하는 추상화 레벨이라 직관적이지 않다.
2. 조건부 타입: T extends U ? X : Y 형태로 타입을 분기. 라이브러리 코드나 복잡한 유틸리티 타입을 이해할 때 필요하다.
3. 타입 가드: 유니온 타입에서 특정 타입을 좁히는(narrowing) 패턴. typeof, instanceof, 사용자 정의 타입 가드 함수.
4. Declaration merging / Module augmentation: 서드파티 라이브러리 타입을 확장할 때 필요. 프레임워크 플러그인 개발 시 자주 등장.
기본 타입 지정과 인터페이스 정의만으로 시작하면 학습 부담이 크지 않다. 제네릭은 직접 작성하기보다 라이브러리 타입을 읽는 것부터 익히는 것이 효율적이다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 1인 프로토타입 (2주 이내) | JavaScript | 타입 설정 비용 대비 이득이 없음 |
| 1인 장기 프로젝트 (3개월+) | TypeScript | 혼자여도 미래의 자신이 코드를 못 알아봄 |
| 팀 2~4인, 6개월+ | TypeScript | 리뷰·온보딩 비용 절감이 타입 정의 비용 초과 |
| 팀 5인 이상 | TypeScript 필수 | JS 코드베이스는 규모 커질수록 수정 위험 증가 |
| 공개 라이브러리/패키지 | TypeScript 필수 | 사용자 IDE 지원을 위해 타입 정의 필수 |
| Node.js 스크립트/자동화 | JavaScript or JSDoc | 빌드 없이 실행 가능한 단순함이 중요 |
| 주니어 온보딩용 프로젝트 | TypeScript (strict 아닌 기본) | 타입 오류가 학습 피드백 역할을 함 |
마이그레이션 전략: 기존 JS 프로젝트를 전환할 때는 tsconfig.json에서 allowJs: true + checkJs: true로 시작해 파일 단위로 .ts로 변환하는 점진적 전환이 현실적이다. 한 번에 전환하면 타입 오류가 수백 개 쏟아져 팀 사기가 꺾인다.
any를 무분별하게 쓰면 JS보다 나을 게 없다. tsconfig.json에서 "noImplicitAny": true와 "strict": true를 켜야 타입 시스템이 실제로 작동한다. 처음에 어렵더라도 strict 모드로 시작하는 것이 장기적으로 낫다.tsconfig.json에서 strict와 noImplicitAny를 처음부터 켜고 시작하세요. 이걸 끄고 도입하면 any가 코드 전반에 퍼져 타입 시스템이 사실상 무력화되고, 나중에 strict로 전환하려면 오류가 수백 개 쏟아집니다. 기존 JS 프로젝트를 옮기는 경우라면 allowJs와 checkJs를 true로 두고 파일 단위로 .ts로 바꾸는 점진적 전환이 현실적입니다. 빌드 부담이 걱정이면 Node.js 22+의 --experimental-strip-types나 Bun·Deno의 직접 실행으로 빌드 단계 없이 먼저 돌려볼 수 있습니다.
단연 any 남발입니다. TypeScript를 켜놓고 타입 오류가 날 때마다 any로 막아버리면 컴파일러가 잡아주는 게 사라져 JS보다 나을 게 없습니다. 두 번째 함정은 2주 안에 폐기될 프로토타입에까지 타입을 꼼꼼히 붙이며 시간을 쓰는 것으로, 이런 단기 코드는 JS가 더 빠릅니다. 반대로 6개월 넘게 갈 코드베이스를 JS로 시작했다가 규모가 커진 뒤 전환을 미루는 것도 흔한 실수인데, 미래의 본인이 낯선 함수를 수정할 때 타입이 없으면 탐색 비용이 급격히 늘어납니다.
판단 기준은 '이 코드를 몇 명이, 얼마나 오래 유지하느냐' 한 축으로 좁혀집니다. 2주 안에 폐기될 1인 프로토타입, 타입 정의가 없는 서드파티를 많이 묶어 쓰는 작업, 빌드 없이 바로 돌려야 하는 단발성 Node.js 스크립트라면 JavaScript가 더 빠릅니다. 반대로 3개월 이상 갈 프로젝트, 2명 이상 팀, 공개 라이브러리·패키지라면 TypeScript가 유리합니다. 혼자 하는 장기 프로젝트도 미래의 본인이 코드를 못 알아보기 때문에 TypeScript 쪽입니다. 다만 any를 남발하면 어느 쪽이든 타입 시스템이 무력화되니, 도입하면 strict 모드로 시작해야 의미가 있습니다.
먼저 공식 핸드북(typescriptlang.org/docs/handbook)으로 기본 타입과 인터페이스를 잡은 뒤, 막히는 지점인 제네릭과 조건부 타입(T extends U ? X : Y), 타입 가드(narrowing)를 집중해서 보면 됩니다. 유틸리티 타입을 손으로 다루며 익히고 싶다면 Type Challenges 깃허브 저장소가 좋은 연습장입니다. tsconfig.json의 strict·noImplicitAny 옵션이 정확히 무엇을 켜는지는 typescriptlang.org/tsconfig 레퍼런스에서 옵션별로 확인하시면 strict 모드 전환 작업에 바로 쓸 수 있습니다.
한 문장으로 줄이면, 코드 수명과 사람 수가 늘어날수록 TypeScript가 기본값입니다. 팀 5명 이상이거나 3개월 넘게 유지될 프로젝트, 공개 패키지라면 TypeScript로 시작하고, 2주 안에 끝날 1인 프로토타입이나 빌드 없이 돌려야 하는 단순 스크립트라면 JavaScript가 빠릅니다. 2026년에는 Node.js 22의 --experimental-strip-types와 Bun·Deno의 직접 실행 덕에 빌드 부담이 크게 줄어, 명확한 이유가 없으면 TypeScript를 strict 모드로 시작하는 편이 안전합니다.
