[TS] any타입을 지양해야하는 이유

임효진·2023년 3월 15일

any타입 지양하기

타입스크립트의 타입 시스템은 점진적이고 선택적이다.
코드에 타입을 조금씩 추가할 수 있기 때문에 점진적이고, 언제든지 타입 체커를 해제할 수
있기 때문에 선택적이다.
그리하여 일부 특별한 경우를 제외하고는 any를 사용하면 타입스크립트의 수많은 장점을 누릴 수 없게된다.
부득이하게 any를 사용하더라도 그 위험성을 알고 있어야 한다.

any타입에는 타입 안정성이 없다.

만약 let age를 number타입으로 선언한 경우에도, as any를 사용하여 string타입을 할당할 수 있게된다.
타입체커는 선언에 따라 number 타입으로 판단할 것이고 혼돈은 걷잡을 수 없게 된다.

any는 함수 시그니처를 무시한다.

함수를 작성할 때는 시그니처를 명시해야한다. 호출하는 쪽은 약속된 타입의 입력을 제공하고
함수는 약속된 타입의 출력을 반환한다. 그러나 any타입을 사용하면 이런 약속을 어길 수 있다.

function calculateAge(birthDate:Date): number {
  // ...
}
let birthDate: any = '1990-01-19';
calculateAge(birthDate); //정상

birthDate 매개변수는 string이 아닌 Date 타입이어야한다.any타입을 사용하면
calculateAge의 시그니처를 무시하게된다. JS에서는 종종 암시적으로 타입이 변환되기 때문에
이런 경우 특히 문제가 될 수 있다. string 타입은 number 타입이 필요한 곳에서 오류 없이 실행될 때가 있고, 그럴 경우 다른 곳에서 문제를 일으킬 수 있다.

any타입에는 언어 서비스가 적용되지 않는다.

어떤 심벌에 타입이 있다면 타입스크립트 언어 서비스는 자동완성 기능과 적절한 도움말을 제공한다.
그러나 any타입인 심벌을 사용하면 아무런 도움을 받지 못한다.
(자동완성으로 속성이 나타나지 않음)
타입스크립트의 모토는 '확장 가능한 자바스크립트'다. 확장의 중요한 부분은 타입스크립트의 경험의 핵심요소인 언어서비스다.

any타입은 코드 리팩토링때 버그를 감춘다.

구체적인 타입을 사용했다면 오류를 발견했을 수 있을 코드를 any타입에서는 발견하지 못한다.

any타입은 설계를 감춘다.

애플리케이션 상태 같은 객체를 정의하려면 꽤 복잡한 과정이다. 상태 객체 안에 있는
수많은 속성의 타입을 일일이 작성해야하는데 any타입을 사용하면 간단히 끝내버릴 수 있다.
객체를 정의할 때 특히 문제가 발생하는데 상태 객체의 설계를 감춰버리기 때문이다.
깔끔하고 정확하고 명료한 코드 작성을 위해 제대로된 타입 설계는 필수적이다.
any타입을 사용하면 타입 설계가 불분명해진다. 설계가 잘 되었는지 설계가 어떻게 되어 있는지
전혀 알수가 없다. 만약 동료가 코드를 리뷰해야한다면 동료는 어플리케이션 상태를 어떻게 변경했는지
코드부터 재구성해봐야한다. 그러므로 설계가 명확히 보이도록 타입을 일일이 작성하는 것이 좋다.

any는 타입시스템의 신뢰도를 떨어뜨린다.

사람은 항상 실수를 한다. 보통은 타입 체커가 실수를 잡아주고 코드의 신뢰도가 높아진다.
그러나 런타임에 타입 오류를 발견하게 된다면 타입 체커를 신뢰할 수 없을거다.
any타입을 쓰지 않으면 런타임에 발견된 오류를 미리 잡을 수 있고 신뢰도를 높일 수 있다.
타입스크립트는 개발자의 삶을 편하게 하는데 목적이 있지만 코드 내에 존재하는 수많은 any타입으로 인해
자바스크립트보다 일을 더 어렵게 만들기도 한다. 타입 오류를 고쳐야하고 머릿속에 실제 타입을 기억해야하기 때문이다.타입이 실제 값과 일치하다면 타입 정보를 기억해둘 필요가 없다. 타입스크립트가 타입을 기억해주기 때문이다.