TypeScript 프로젝트에서 @typescript-eslint/no-explicit-any 린트 에러는 단순 규칙 비활성화로 해결할 문제가 아닙니다. 눈 앞 문제는 해결할 수 있지만, TypeScript를 사용하는 가장 중요한 이유를 위배하게 됩니다.

any 타입은 모든 타입을 허용하는 '만능키' 같지만, 실제로는 버그를 잡을 수 있는 TypeScript 기능을 스스로 포기하게 됩니다. 

 

any를 피해야하는 이유

any를 사용하면 변수에 어떤 타입의 값이든 할당할 수 있고, 어떤 속성이나 메서드에도 에러 없이 접근할 수 있습니다. 이는 당장의 에러는 해결하지만, 실제 코드가 실행될 때 예상하지 못한 타입 버그를 유발하는 주요 원인이 됩니다.

 

any 사용을 최소화하고 타입 안정성을 높이는 방법

가장 좋은 방법은 구체적입 타입 설정

변수나 데이터 구조를 파악하고, 정확한 타입을 명시하는 것이 좋습니다.

• 기본 타입: string, number, boolean[] 등

• 객체 타입: interface 또는 type을 사용하여 객체의 구조를 명확히 정의합니다.

// 👎 나쁜 예
function printUser(user: any) {
  console.log(user.name, user.age);
}

// 👍 좋은 예
interface User {
  name: string;
  age: number;
}

function printUser(user: User) {
  console.log(user.name, user.age);
}

 

예측할 수 없다면 unknown 타입을 활용

값의 타입을 전혀 예측할 수 없을 때, any 대신 unknown을 사용하는 것이 훨씬 안전합니다. unknown은 변수를 사용하기 전에 타입 가드를 통해 타입을 먼저 확인하도록 강제합니다.

// 👍 좋은 예
function processData(data: unknown) {
  if (typeof data === 'string') {
    // data가 string임이 확인된 안전한 블록
    console.log(data.toUpperCase());
  } else if (Array.isArray(data)) {
    // data가 배열임이 확인된 안전한 블록
    console.log(data.length);
  }
}

 

"any는 타입스크립트(TypeScript)의 안전 장치를 스스로 해제하는 것과 같아 가능한 한 사용하지 않는 것이 좋습니다. 제네릭(<T>)을 사용하는 등 any를 피할 수 있는 방법은 다양하지만, 촉박한 개발 일정에 쫓겨 any를 남용하며 빠르게 개발하는 경우가 많습니다. 이렇게 쌓여가는 any 타입은 언젠가 기술 부채가 되어 돌아옵니다. 시간을 내어 유지보수한다면 장기적인 비용을 줄일 수 있을 뿐만 아니라, 동료와 자신을 위해 미래 지향적인 개발 습관을 기를 수 있습니다."