답변.

TypeScript는 정적(엄격한) 타입 검사를 구현하는 JavaScript의 확장입니다. 이는 타입 검사가 실행 시간 동안이 아니라 컴파일 시간에 이루어진다는 것을 의미합니다.

주요 차이점:

• 정적 타입 검사: 변수, 함수 매개변수, 반환 값을 명시적으로 설명할 수 있습니다.
• 기본 타입 추론(type inference): 할당된 값을 기반으로 변수의 타입을 암시적으로 정의합니다.
• API 통합: IDE 및 코드 분석 도구가 타입을 보여주고, 필드를 자동 완성하며, 오류를 경고할 수 있습니다.

대규모 프로젝트의 이점:

• 통일된 표준으로 버그 감소.
• 더 빠르고 안전한 리팩토링.
• 팀 작업이 간소화됩니다.

예제:

type User = {
  name: string;
  age: number;
}

function greet(user: User): string {
  return 'Hello, ' + user.name;
}

const u: User = { name: 'Ivan', age: 30 };
greet(u); // OK

까다로운 질문.

질문: TypeScript 프로젝트에서 any 타입의 변수를 선언할 수 있으며, 이 경우 프로젝트의 엄격한 타입 검사 이점을 잃지 않을까요?

답변:

네, TypeScript는 any 타입을 사용할 수 있게 허용하는데, 이는 이 변수에 대한 타입 검사가 없다는 것과 같습니다. any를 자주 사용하면 TypeScript의 주요 장점인 엄격한 타입 검사를 무의미하게 만들고, JavaScript와 마찬가지로 실행 시간에 일반적인 오류를 발생시킬 위험이 있습니다.

예제:

let data: any = 'test';
data = 42; // 오류는 발생하지 않지만 문제가 될 수 있습니다.

주제에 대한 세부사항 부족으로 인한 실제 오류 사례.

---

이야기

개발자가 복잡한 객체에 대해 any 타입을 자주 사용하여 "빠르게 진행하려" 했습니다. 결과적으로, 어느 날 필드가 누락된 객체가 도착하고 애플리케이션이 충돌했습니다: 타입 검사가 없어서 오류가 프로덕션으로 간과되었습니다.

---

이야기

대규모 프로젝트에서 두 개의 서로 다른 마이크로서비스 간의 메시지를 교환했습니다. 한 서비스가 객체 구조를 변경했지만, 타입이 명시적으로 any로 설정되어 있었기 때문에 TypeScript가 경고하지 않았습니다. 버그는 사용자의 불만으로 한 달 후에 발견되었습니다.

---

이야기

젊은 개발자가 공개 함수의 반환 값 타입을 설명하지 않고 자동 타입 추론에 의존했습니다. 리팩토링 후 다른 쪽에서 타입 기대가 작동하지 않아 프로젝트 전반에 걸쳐 버그의 연쇄가 발생했습니다.