한 줄 정의
TypeScript는 JavaScript 코드 위에 타입 문법과 정적 검사를 얹는 언어야. 공식 홈페이지가 바로 그렇게 설명하듯이, 목표는 JavaScript를 버리고 다른 세계로 옮겨 가는 게 아니라 기존 코드베이스에 에디터 경고, 자동 완성, 리팩터링 안전장치를 더하는 쪽에 가까워.
중요한 구분은 하나 있어. TypeScript는 런타임이 아니야. 빌드 결과물은 결국 JavaScript고, 그 JavaScript가 브라우저나 Node.js 같은 실행 환경에서 돌아가. 그래서 “TypeScript로 작성했다”와 “실행 환경이 바뀌었다”는 같은 말이 아니야.
어떻게 작동하나
보통은 .ts 파일을 작성하고 tsc로 타입 검사를 돌린 뒤 JavaScript를 출력해. 다만 처음부터 전체 프로젝트를 갈아엎을 필요는 없어. Handbook 입문처럼 JavaScript 파일에 // @ts-check를 붙이거나 JSDoc 타입 힌트를 더하는 식으로 점진적으로 들어오는 경로도 공식 문서가 직접 안내해.
AI 쪽 코드에서 TypeScript가 자주 보이는 이유도 여기서 이어져. 브라우저 UI, Node.js 서버, SDK 호출 코드를 한 언어로 이어서 관리하기 쉽기 때문이야. 예를 들어 Vercel AI SDK는 TypeScript 자체가 아니라 그 위에서 쓰는 SDK고, 프런트엔드와 백엔드 경계를 넘나드는 호출 타입을 정리하기 좋게 잡아 줘. Activepieces는 부족한 연결을 TypeScript piece로 구현하는 구조를 써. 반대로 데이터 정리, 일회성 eval 스크립트, 연구용 노트북은 아직 Python 쪽이 더 흔해.
왜 중요한가
TypeScript를 알면 “이 도구가 모델 자체인가, 아니면 JavaScript 코드베이스에 AI 기능을 연결하는 층인가”를 빨리 가를 수 있어. AI 제품 문서에서 SDK, agent UI, workflow builder가 섞여 나올 때 이 구분이 안 되면 런타임과 언어, 프레임워크를 한 덩어리로 읽기 쉬워. 여기서 비교 축은 분명해. TypeScript는 언어고, 런타임은 그 결과물을 돌리는 실행 층이야. Vercel AI SDK는 그 위에서 호출 구조를 정리하는 SDK고, Activepieces는 TypeScript로 확장 코드를 작성할 수 있는 제품이야. Python은 같은 문제를 다른 생태계에서 푸는 대안에 가깝고.
채택 규모도 무시하기 어려워. 2026-05-03 기준 microsoft/TypeScript 저장소는 109k stars와 13.4k forks를 보여 주고, 공식 사이트 첫 화면은 TypeScript 6.0 계열 공개 상태를 안내해. 이 정도면 “웹과 Node.js 쪽에서 지금도 계속 쓰이는 기본 선택지인가”를 판단하는 데 충분한 신호야. 다만 그걸로 끝은 아니야. TypeScript를 도입한다고 바로 안전해지는 게 아니라, 큰 코드베이스를 더 잘 관리할 수 있는 조건이 생긴다고 보는 쪽이 더 정확해.
주의해서 볼 점
TypeScript가 있다고 실행 중 버그가 전부 사라지는 건 아니야. 타입 정보는 빌드 뒤 JavaScript에서 사라지기 때문에 외부 API 응답, 폼 입력, JSON 파일처럼 런타임에 들어오는 값은 별도 검증 코드가 계속 필요해.
실무에서 더 자주 막히는 부분도 문법 자체보다 설정이야. tsconfig, 모듈 해석, 번들러, Node.js 버전, 라이브러리 타입 정의가 엇갈리면 문법보다 빌드 설정에서 시간을 더 많이 써. 그래서 TypeScript를 볼 때는 “문법이 어렵나”보다 “이 코드베이스가 타입 검사와 빌드 설정을 얼마나 안정적으로 운영하나”를 같이 보는 편이 맞아.