✅ Item 5: any 타입 지양하기

1️⃣ any 타입에는 타입 안정성이 없다

any는 모든 타입과 호환되며, 타입 안정성(type safety) 을 제공하지 않는다.

function greet(user: any) {
  console.log(user.toUpperCase());
}

greet('hello'); // ✅ 정상 동작
greet(123); // ❌ 런타임 에러 (toUpperCase is not a function)

타입 검사가 비활성화되어 런타임 오류로 이어질 수 있다.

2️⃣ any는 함수 시그니처를 무시해버린다

함수의 입력 타입이 any이면, 실제 어떤 값이 들어오든 타입 검사를 통과함.

function add(x: any, y: any) {
  return x + y;
}

add(1, 2); // ✅ 3
add('a', 'b'); // ✅ "ab"
add({}, []); // ✅ "[object Object]"

모든 조합이 허용되므로 의도와 다른 호출도 막을 수 없다.

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

any는 IDE의 자동완성, 타입 추론, 문서 확인 등의 언어 서비스를 사용할 수 없다.

let config: any = getConfig();

config. // ← 자동완성 없음

협업과 유지보수 시 생산성 하락으로 이어짐

4️⃣ any는 코드 리팩터링 시 버그를 감춘다

변수나 함수가 any 타입이면, 코드 변경 시 오류가 감지되지 않아 런타임 에러를 유발한다.

function fetchUser(): any {
  return { name: 'Boohi', age: 27 };
}

const user = fetchUser();
console.log(user.fullName); // ❌ 존재하지 않는 속성도 허용됨

구조 변경 시에도 타입 오류가 발생하지 않기 때문에, 버그가 숨어 있게 됨

5️⃣ any는 타입 설계를 감춰버린다

any를 사용하면, 그 값이 어떤 구조를 가지는지 파악하기 어려워짐.

function render(data: any) {
  // data의 구조가 불명확하여 문서화도 어려움
  console.log(data.title);
}

타입은 코드의 설계도입니다. any는 그 설계도를 숨겨버린다.

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

코드베이스의 일부가 any로 작성되면, 타입스크립트가 제공하는 정적 분석 능력을 신뢰할 수 없게 됩니다.

function process(value: any) {
  return value.id + 1;
}

const result = process('abc'); // ❌ 컴파일은 되지만, 런타임 오류

타입 시스템이 있어도 실제 안정성은 확보되지 않음 → 팀원 간 신뢰도 저하

✅ 결론

any는 빠른 개발에는 도움이 되지만, 장기적인 유지보수와 팀 협업에는 큰 리스크를 안고 있다. unknown, 명시적 타입, 타입 가드 등을 적극 활용해 타입 안전성과 가독성을 유지하는 것이 좋다.