자바스크립트와 타입스크립트의 차이점

타입스크립트에 입문할 때 가장 자주 생기는 오해는 문법이 거의 같으니 큰 차이도 없겠지라는 판단입니다.

실제로 파일 확장자만 바꾸면 돌아가는 코드도 많아서, 처음엔 차이를 체감하기 어렵습니다.

하지만 프로젝트 규모가 커질수록 두 언어의 차이는 문법이 아니라 개발 방식 전체에서 드러납니다.

오류를 언제 발견하는지, 리팩터링을 얼마나 안전하게 할 수 있는지, 협업 중 의사소통 비용이 얼마나 줄어드는지가 달라지기 때문입니다.

이 절에서는 자바스크립트와 타입스크립트의 차이를 기능 표로만 비교하지 않고, 실제 개발 과정에서 어떤 선택이 어떤 결과를 만드는지까지 연결해 설명합니다.

읽고 나면 같은 코드에서 어떤 오류가 정적 검사로 드러나고 어떤 조건은 실행 중에 확인해야 하는지 구분할 수 있습니다.

핵심은 '정적 타입' 시스템

자바스크립트와 타입스크립트의 가장 근본적인 차이점은 바로 타입 시스템에 있습니다.

• 자바스크립트: 동적 타입 언어 (Dynamically Typed Language) 자바스크립트는 동적 타입 언어입니다.

  이는 변수의 타입이 프로그램이 실행되는 시점(런타임)에 결정된다는 의미입니다.

  코드를 작성할 때는 변수에 특정 타입을 지정할 필요가 없으며, 같은 변수에 숫자, 문자열, 객체 등 어떤 타입의 값이라도 자유롭게 할당할 수 있습니다.

  let value = 10; // 숫자
  value = "hello"; // 문자열
  value = true; // 불리언

  이러한 유연성은 개발 초기 단계에서 빠른 프로토타이핑을 가능하게 합니다.

  하지만 코드의 규모가 커지고 복잡해질수록, 예상치 못한 타입 오류로 인해 프로그램이 비정상적으로 동작할 위험이 커집니다.

  타입 계약을 표현하지 않은 이 예제에서는 실행값을 추적해야 합니다. JavaScript에도 테스트, JSDoc 기반 검사 같은 별도 도구를 적용할 수 있습니다.

• 타입스크립트: 정적 타입 언어 (Statically Typed Language) 반면 타입스크립트는 정적 타입 언어의 특성을 가집니다.

  즉, 변수의 타입이 프로그램이 실행되기 전(컴파일 시점)에 검사됩니다.

  개발자는 변수나 함수의 매개변수, 반환값 등에 타입을 명시할 수 있고, 많은 경우에는 타입스크립트가 초기값과 사용 문맥을 보고 타입을 추론합니다.

  let value: number = 10; // 숫자
  // value = "hello"; // 오류: 'string' 형식은 'number' 형식에 할당될 수 없습니다.

  보시는 것처럼, value를 number 타입으로 선언한 후 문자열을 할당하려 하면, 타입스크립트 컴파일러가 즉시 오류를 알려줍니다.

  이런 정적 검사는 타입 불일치를 컴파일 단계에서 드러내며, 런타임에 뒤늦게 발견되는 버그를 줄입니다.

컴파일 과정의 차이

두 언어의 또 다른 중요한 차이점은 컴파일 과정에 있습니다.

• 자바스크립트: 자바스크립트 코드는 웹 브라우저나 Node.js와 같은 런타임 환경에서 바로 실행 대상이 됩니다. 런타임 내부에서는 파싱과 최적화가 일어나지만, 개발자가 타입 제거를 위한 별도 변환 단계를 거칠 필요는 없습니다.

• 타입스크립트: 웹 브라우저는 타입스크립트 문법을 직접 실행하지 않습니다. 보통 타입스크립트 컴파일러(TypeScript Compiler, tsc)를 통해 먼저 자바스크립트 코드로 변환(Transpile)합니다. 이 과정에서 타입 검사가 이루어지고, 타입 선언 같은 타입스크립트 문법이 제거된 순수 자바스크립트 코드가 생성됩니다.

  최신 Node.js에는 타입 표기만 제거해 실행하는 제한적 type stripping 기능도 있지만, 이 기능은 tsconfig 기반 변환이나 타입 검사를 대신하지 않습니다.

이러한 컴파일 과정 덕분에 타입스크립트는 자바스크립트의 모든 기능을 활용하면서도, 타입 검사라는 추가적인 안정성을 확보할 수 있게 됩니다.

최종적으로 실행되는 코드는 여전히 자바스크립트이므로, 기존 자바스크립트 생태계의 풍부한 라이브러리와 프레임워크를 그대로 사용할 수 있다는 큰 장점이 있습니다.

타입을 생략한 변수도 검사됩니다 아래 예제를 별도의 파일에서 확인하세요. 값에서 추론한 타입도 이후 대입을 제한합니다.

let attempts = 1;
attempts = 2;
// attempts = "두 번";
console.log(attempts);

주석 그대로는 2가 출력됩니다. 마지막 대입 주석을 해제하면 attempts에 추론된 number와 문자열이 맞지 않아 진단을 받습니다. JavaScript의 실행값은 여전히 동적이지만, TypeScript의 이름 사용에 대한 정적 계약은 별도로 검사합니다.

스스로 확인하기 다음 두 상황을 “타입 불일치 진단”과 “검사는 통과하지만 실행값·업무 조건 확인 필요”로 나누세요. 덧셈 함수의 매개변수는 둘 다 number라고 가정합니다.

1. sumNumbers(10, "20")를 호출한다.
2. 두 number의 나눗셈을 반환하는 함수에 10과 0을 전달한다.

tsc의 기본 출력 정책에서는 타입 오류가 있어도 JavaScript가 생성될 수 있습니다. noEmit은 파일을 만들지 않고 검사하며, noEmitOnError는 오류가 있을 때 새 출력을 막습니다. 기존에 만들어 둔 JavaScript까지 자동으로 지우지는 않습니다. 공식 noEmitOnError 설명을 참고하세요.

개발 경험의 변화

정적 타입 시스템과 컴파일 과정의 차이는 개발자의 개발 경험에 지대한 영향을 미칩니다.

• 오류 조기 발견: 타입스크립트는 코드를 작성하는 즉시, 혹은 컴파일 시점에 타입 오류를 알려주기 때문에 런타임 오류로 인해 디버깅에 소모되는 시간을 획기적으로 줄여줍니다.
• 강력한 도구 지원: IDE(통합 개발 환경)는 타입스크립트의 타입 정보를 활용하여 훨씬 더 정확하고 강력한 코드 자동 완성, 코드 탐색, 리팩터링 기능을 제공합니다. 이는 개발 생산성을 크게 향상시킵니다.
• 코드의 명확성 및 협업 용이성: 타입 정보는 코드의 의도를 명확하게 드러내어 코드 가독성을 높이고, 여러 개발자가 함께 작업할 때 발생할 수 있는 소통의 오류를 줄여줍니다. 마치 코드에 상세한 사용 설명서가 붙어 있는 것과 같습니다.
• 리팩터링의 안정성: 코드를 변경할 때, 타입 시스템이 변경으로 인해 발생할 수 있는 잠재적인 오류를 미리 경고해주므로, 더욱 안심하고 대규모 리팩터링을 진행할 수 있습니다.

요약하자면, 타입스크립트는 자바스크립트의 유연성을 유지하면서 타입 안정성과 도구 지원을 추가하는 언어입니다.

규모가 큰 코드베이스에서는 공개 API, 데이터 모델, 리팩터링 범위를 타입으로 확인할 수 있지만, 타입 설계와 빌드 설정 비용도 함께 고려해야 합니다.

물론 도입 비용도 분명히 존재합니다.

초기에 타입 설계와 설정에 시간이 들고, 팀이 타입 시스템에 익숙해질 때까지 학습 부담이 생깁니다.

그래서 좋은 도입 전략은 전체를 한 번에 전환하는 것보다 경계가 명확한 모듈부터 점진적으로 타입을 강화하는 방식입니다.

아래 다이어그램은 자바스크립트 코드베이스에 타입스크립트를 점진적으로 적용할 때의 현실적인 전환 순서를 보여줍니다.

자바스크립트와 타입스크립트의 차이는 실행 결과보다 피드백을 받는 시점에서 더 크게 느껴집니다.

타입을 먼저 적어두면 함수와 모듈의 계약이 에디터와 빌드 단계에서 확인되어 리팩터링과 협업의 불확실성이 줄어듭니다.

다음 절에서는 타입스크립트 개발을 위한 환경을 어떻게 설정해야 하는지 구체적으로 알아보겠습니다.