팀에 TypeScript 도입하면서 마주친 any 남용 문제

문제 상황

지난 달부터 Express 기반 API 서버에 TypeScript를 도입했다. 기존 JavaScript 코드를 점진적으로 마이그레이션하는 방식으로 진행했는데, 팀원들이 타입 정의가 복잡해지면 any로 우회하는 경향이 나타났다.

function processUserData(data: any) {
  return data.user.profile.name; // 런타임 에러 가능
}

이러면 TypeScript를 쓰는 의미가 없었다.

적용한 해결책

1. ESLint 규칙 강화

@typescript-eslint/no-explicit-any 규칙을 error로 설정했다.

{
  "rules": {
    "@typescript-eslint/no-explicit-any": "error"
  }
}

2. 타입 정의 템플릿 공유

자주 사용하는 API 응답 구조에 대한 타입 정의를 미리 만들어 공유했다.

interface ApiResponse<T> {
  status: number;
  data: T;
  error?: string;
}

interface UserProfile {
  id: string;
  name: string;
  email: string;
}

function getUser(): Promise<ApiResponse<UserProfile>> {
  // ...
}

3. unknown 활용 권장

정말 타입을 알 수 없는 경우 any 대신 unknown을 사용하도록 가이드했다.

function parseData(json: unknown) {
  if (typeof json === 'object' && json !== null) {
    // 타입 가드로 안전하게 접근
  }
}

결과

2주 정도 지나니 팀원들이 타입 정의에 익숙해졌다. 린트 에러를 피하려다 보니 자연스럽게 제대로 된 타입을 작성하게 됐고, 덕분에 런타임 에러도 줄었다. 초기 러닝 커브는 있지만 장기적으로는 확실히 생산성 향상에 도움이 된다.