any 타입 지양하기

타입스크립트의 타입 시스템은 다음과 같습니다.

점진적(Gradual) - 프로젝트 전체에 타입을 추가할 필요 없이, 일부에 대해서만 사용할 수 있습니다.
선택적(Optional) - 언제든지 타입 체커를 해제할 수 있습니다.

위 기능들의 핵심은 any 타입입니다.

타입스크립트가 발견해내는 대부분의 오류들은 사실 any 타입을 사용한다면 거의 대부분 넘어갈 수 있습니다. 하지만, 일부 특별한 경우를 제외하고는 any 타입의 사용은 TS의 수많은 장점을 누릴 수 없게 만듭니다.

any 타입에는 타입 안전성이 없습니다

let age: number;
age = "12" as any; // 문제 없음

분명 age는 number 타입이지만, any 타입을 통해 string을 할당했습니다. 이 경우 타입을 지정한 의미 자체가 없어진 셈입니다.

any는 함수 시그니처를 무시해버립니다

함수 작성 시에는 시그니처를 명시해야 합니다. 즉, 함수의 호출과 출력에는 각각 약속된 타입이 정해져있어야 합니다. any는 이 자체를 무시합니다. JS에서는 암묵적인 Type Coercion이 빈번하게 일어나기 때문에, 이런 상황에서 특히 문제가 될 수 있습니다.

any 타입은 IDE 상의 피드백을 받을 수 없습니다

기본적으로 적절한 타입을 지정해준다면 에디터는 상황에 따라 적절한 자동완성 기능과 도움말을 제공합니다. 그런데 any 타입의 사용은 이러한 피드백을 전혀 받아볼 수 없게 만듭니다.

any 타입은 코드 리팩토링 시 버그를 감춥니다

리팩토링 시 적절한 타입의 유추가 어렵다는 이유로 any를 사용하게 되면, 리팩토링을 진행하는 도중에 발견해야할 에러를 알아내기 어렵습니다. 리팩토링에 앞서 구체적인 타입의 지정이 요구되는 이유입니다.

any는 타입 설계를 감춰버립니다

애플리케이션의 상태 객체의 정의는 상당히 복잡합니다. 상태 객체 안의 수많은 프로퍼티 타입을 일일이 작성해야 하는데, 이는 사실 any 하나로 뚝딱 해결해버릴 수도 있습니다. 물론 이 때도 any를 사용해선 안 됩니다. 상태 객체가 어떻게 구성되어 있는지에 대한 인터페이스 자체를 감춰버리기 때문이죠.

사람은 누구나 실수를 합니다. 그런 상황에서 타입스크립트를 도입한다는 것은 곧 실수를 줄이기 위하여 신뢰할 만한 타입 체커를 구축해나간다는 것입니다. 헌데, any 타입의 사용은 이러한 타입 시스템 자체를 신뢰할 수 없게 만들어, TS를 쓰는 의미 자체를 잃어버리게 만듭니다. 코드에 존재하는 수많은 any 타입은 오히려 JS보다도 개발을 어렵게 만들 수 있습니다.

다만, 어쩔 수 없이 any를 써야만 하는 상황도 있습니다. 이에 대해서는 추후에 다뤄보도록 합시다.

Shubi Docs