쉬운 설명
순수 자바스크립트로 큰 프로젝트를 짜다 보면, 어떤 함수가 무엇을 받아 무엇을 돌려주는지 머릿속에서 헷갈리는 순간이 옵니다. TypeScript는 함수 선언에 '여기는 숫자, 여기는 문자열의 배열'이라고 적어 두게 강제해서, 잘못된 타입을 넣으면 에디터가 즉시 빨간 줄로 알려줍니다.
이게 왜 강력한가 하면, 실행 시점이 아니라 작성 시점에 오류가 잡히기 때문입니다. 자바스크립트에서는 'undefined is not a function' 같은 오류가 사용자가 버튼을 눌렀을 때 비로소 터지지만, TypeScript에서는 그런 코드는 빌드가 안 됩니다. 그래서 큰 코드베이스일수록 효과가 큽니다. '사용자가 화면에서 발견하는 오류'를 '개발자가 키보드에서 발견하는 오류'로 옮기는 일과 같습니다.
TypeScript 코드는 빌드 시점에 일반 자바스크립트로 변환되어 브라우저·서버에서 평소처럼 실행됩니다. 즉 'TS는 작성용, JS는 실행용'이라고 생각하면 됩니다. 런타임에는 타입 정보가 사라지므로 성능에 영향이 없고, 자바스크립트 생태계의 모든 도구·라이브러리를 그대로 쓸 수 있습니다.
장점: ① 에디터가 자동완성·리팩토링을 매우 정확하게 해 줍니다. ② 라이브러리의 사용법을 코드만 보고 알 수 있어 문서를 덜 봐도 됩니다. ③ 새 동료가 코드를 더 빨리 이해합니다. ④ 큰 변경(리네임·인터페이스 수정)에서 영향 범위를 컴파일러가 알려 줍니다. 마이크로소프트가 만들었고, 지금은 거의 모든 새 프런트엔드 프로젝트와 많은 백엔드 프로젝트의 기본값입니다.
주의할 점: TypeScript는 100% 안전을 보장하지 않습니다. 'any' 타입으로 우회하면 자바스크립트와 같아지고, 외부 라이브러리의 타입 정의가 부정확하면 거짓 안심을 줄 수 있습니다. 또 타입을 너무 엄격하게 잡으면 코드가 무거워지니, '실수가 자주 생기는 곳'을 중심으로 적당히 잡는 것이 실무 감각입니다. 점진적 도입이 가능해서, 기존 JS 프로젝트에 TS를 조금씩 섞어 가는 전략도 잘 동작합니다.
비유로 보면
자바스크립트가 식당에서 손님이 입으로 주문하는 방식이라면, TypeScript는 주문서에 양식을 정해 두고 받는 방식과 비슷합니다. '돈가스 × 2, 매운맛, 음료는 콜라'라고 적힌 주문서는 주방이 잘못 만들 여지를 줄입니다. 손님은 양식을 작성하는 데 약간의 수고를 들이지만, 결과적으로 주방의 실수와 컴플레인이 크게 줄어듭니다.
어디에서 만나나
대부분의 새 프런트엔드 프로젝트(Next.js·React·Vue·Svelte 모두 TS 지원이 기본), 백엔드(Node·Deno·Bun), 모바일(React Native), 데스크톱(Electron), 라이브러리 개발. 회사가 자랄수록 TS 도입 비율이 올라갑니다. 페이스북·구글·마이크로소프트·아마존이 자기 큰 코드베이스에 TS(또는 비슷한 타입 시스템)를 도입했습니다.
작은 예시
사용자 객체를 받는 함수 sendInvoice(user)에서, TypeScript가 user.email이 문자열이라고 적혀 있는데 코드가 user.emial(오타)이라고 쓰면 빨간 줄을 그어 줍니다. 자바스크립트라면 이 오타는 서비스 중에 실제 사용자가 영수증을 못 받고서야 발견될 수 있습니다.
자주 하는 오해
한 줄 정리
TypeScript의 비결은 '오류를 사용자에게서 개발자에게로 옮기는' 일입니다. 처음 한 주만 견디면, 그다음부터는 거의 모든 프로젝트에 쓰고 싶어집니다.