TS017. 타입스크립트에서 Any 타입 사용의 문제점

Any 타입의 문제점

1: 타입 세이프티가 손실된다.

• Silent Type Errors: 컴파일 타임 타입 검사에서 에러를 받아보지 못하고 런타임에 에러가 발생하게 된다.
  • 서비스 운영에 치명적이다.
• Masking Bugs: 타입 에러는 종종 잠재적 버그를 나타내주는 지표가 되는데 이런 지표가 마비된다. 결국 디버깅하기 어려운 버그가 발생할 수 있다.

function addNumbers(a: any, b: any) {
  return a + b;
}

const result = addNumbers("10", 5); // Expected number, but gets string "105"

2: 자동완성과 툴링에 있어서 손해를 많이 본다.

• 아래와 같이 any 타입으로 변수를 선언하면 IDE 에서 primitive 지원 기본 메서드들이 추천되지 않는다.
• 결국 직접 타이핑하다가 에러가 발생한다.

let any: any = "abc";
// any. // 메서드가 뭐가 있었지?

3: 잘못된 타입의 인자를 넘겼을 때 알기 힘들다.

• 코드 분석 도구는 잠재적 문제를 해결하는데 도움을 주는데 이런 도움을 받기 어렵다.

function foo(x: number, y: number) {
  return x * y;
}

let v1: any = true;
let v2: any = false;

foo(v1, v2); // 에러가 검출되지 않는다.

4: 가독성 및 유지보수에서 손해를 많이 본다.

• 불분명한 의도: 코드의 의도를 이해하는데 많은 어려움을 겪을 수 있다.
• 리팩토링 위험: 타입 안정성을 보장할 수 없기 때문에 코드 리팩토링 과정이 위험해진다. 리팩토링 중 새로운 버그가 발생할 수도 있다.

let userDetails: any = { name: "John", age: 30 };
// Later in the code
userDetails = "Logged Out"; // Unclear why a user object becomes a string

의도를 알기 어려운 코드 예시이다.

5: 확장성 및 팀 협업에 문제가 발생한다.

• 일관성 없는 코드 표준: any 를 사용하는 개발자가 있다는 것만으로 컨벤션이 깨질 수 있다.
• 기술 부채: any 타입은 기술 부채가 되어 가까운 미래에 문제를 발생시킬 수 있다.

6: 의도치 않은 보안 문제를 일으킬 수 있다.

• 함수와 메서드가 처리하도록 설계되지 않은 값을 받아들여 외부 소스에서 입력이 들어오는 경우 보안 취약점이 발생할 수도 있다.

베스트 프랙티스

• 유형을 알 수 없는 동적 콘텐츠를 다룰 때만 한정적으로 사용하기
• 제네릭 같은 보다 구체적인 타입을 사용하도록 노력하기
• 구조가 복잡하더라도 타입 정의 잘하기
• 단기적인 편의성에 속지 말기