TypeScript 3.x 프로젝트 마이그레이션 후기

배경

회사 프로젝트의 JavaScript 코드베이스가 10만 라인을 넘어서면서 타입 관련 버그가 빈번하게 발생했다. 팀 내에서 TypeScript 도입 논의가 있었고, 3월부터 본격적으로 마이그레이션을 시작했다.

점진적 마이그레이션 전략

한 번에 전환하는 것은 리스크가 크다고 판단해 단계적 접근을 택했다.

// tsconfig.json
{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "strict": false,
    "target": "es5",
    "module": "commonjs"
  }
}

초기에는 allowJs를 켜고 .js와 .ts 파일을 공존시켰다. 새로운 파일은 TypeScript로 작성하고, 기존 파일은 수정할 때마다 조금씩 전환하는 방식이었다.

주요 이슈들

any 타입 남용

초반에는 빠른 전환을 위해 any를 많이 사용했는데, 이는 TypeScript 도입 취지와 맞지 않았다. 코드 리뷰 시 any 사용을 제한하는 규칙을 만들었다.

// Before
function processData(data: any) {
  return data.items.map(item => item.value);
}

// After
interface DataResponse {
  items: Array<{ value: number }>;
}

function processData(data: DataResponse) {
  return data.items.map(item => item.value);
}

서드파티 라이브러리 타입

일부 라이브러리는 @types 패키지가 없거나 오래되어 있었다. 필요한 경우 직접 .d.ts 파일을 작성했다.

// types/legacy-lib.d.ts
declare module 'legacy-lib' {
  export function doSomething(param: string): void;
}

효과

• 배포 전 타입 에러로 잡히는 버그 증가
• IDE 자동완성으로 개발 속도 향상
• 리팩토링 시 사이드이펙트 파악 용이

다만 초기 학습 곡선과 빌드 시간 증가는 트레이드오프였다. 전체적으로는 긍정적이라고 평가한다.