TypeScript 도구를 더 안전하고 똑똑하게 만들기

발행: 1개월 전 (2025년 12월 13일 오전 10:38 GMT+9)

6 min read

원문: Dev.to

Source: Dev.to

Overview

지난 몇 주 동안 저는 실제 TypeScript 개발자들에게 매일 영향을 주는 오픈소스 기여에 집중했습니다. 단순한 스타일링 수정 이상의 이슈들을 다루었습니다. 두 프로젝트에 참여했습니다:

typescript-eslint – TypeScript 코드를 안전하고 일관되게 유지해 주는 ESLint 규칙 모음.
publicodes/language-server – Publicodes 언어에 대한 언어 서버 기능(진단, 자동완성, 툴팁, 정의 이동)을 제공하는 VS Code 확장.

이 기여를 통해 정적 분석 규칙과 실제 언어 서버 양쪽을 작업할 수 있었습니다.

no-unsafe-* 규칙에 대해 객체 타입 내부의 위험한 any 값을 감지하도록 하는 기능 요청을 해결했습니다. 이제 최상위 수준뿐 아니라 중첩된 경우도 잡아냅니다.

기존 규칙(no-unsafe-argument, no-unsafe-assignment 등)은 파라미터나 변수가 직접 any 로 타입 지정된 경우, 혹은 전체 제네릭 타입에 any 가 사용된 경우를 이미 차단하고 있었습니다.
문제는 중첩된 any 프로퍼티가 더 엄격한 객체 타입 안으로 들어가도 경고가 발생하지 않는다는 점이었습니다.
이러한 규칙에서 사용하는 내부 헬퍼를 업데이트하여 객체, 배열 및 기타 컨테이너를 탐색하면서 숨겨진 위험한 any 를 찾아내도록 했습니다.
이슈에 나온 정확한 예제가 이제 보고되고, 안전한 버전은 여전히 통과하는지를 확인하는 테스트를 추가했습니다.
더 엄격한 검사로 인해 실패하던 저장소 일부를 정리했습니다.

하나의 워크스페이스에 여러 모델을 지원하도록 기능을 추가했습니다.

이 언어 서버는 Publicodes 언어를 VS Code 같은 편집기에 통합해 .publicodes 파일에 대한 의미 강조, 진단, 정의 이동 등을 제공합니다.
이전에는 워크스페이스 내 모든 .publicodes 파일을 하나의 거대한 모델로 취급했기 때문에, 별도의 모델이 격리되어야 하는 모노레포나 다중 폴더 워크스페이스에서 문제가 발생했습니다.
제 수정은 모델 경계(예: 가장 가까운 package.json 혹은 .publicodes.config 파일)를 도입하고, 파일들을 해당 경계별로 그룹화합니다.
각 그룹은 자체 내부 데이터 구조와 엔진 인스턴스를 갖게 되며, 따라서 파일에 대한 진단, 툴팁, 자동완성, 정의 이동이 전역이 아닌 해당 파일이 속한 모델을 통해 처리됩니다.

작업은 점진적으로 진행되었습니다:

익숙하지 않은 코드를 읽고 각 부분이 어떻게 맞물리는지 이해하는 데 상당한 시간을 투자했습니다.
typescript-eslint에서는 타입 유틸리티를 파악한 뒤 코드를 작성했고, 테스트 스위트를 반복 실행하며 새로운 실패가 나타날 때마다 조정했습니다.
언어 서버에서는 파일 탐색, 규칙 저장, 진단 생성 흐름을 추적한 뒤, 새로운 모델 정보를 그 경로들에 신중히 전달했습니다.
작업을 작은 단계(먼저 모델 추적, 그 다음 파싱 업데이트, 마지막으로 검증 업데이트)로 나누는 것이 핵심이었습니다.

돌이켜 보면 원래 목표를 달성했습니다:

TypeScript 도구 영역에 머물렀습니다.
약간은 제 편안함을 넘어서는 작업을 맡아 복잡한 로직을 포기하지 않고 진행했습니다.
지나치게 복잡한 이슈를 선택했을 때는 과도한 고민과 막힘이 발생한다는 단점을 인식했지만, 전반적으로 진지한 오픈소스 프로젝트에 기여하는 자신감을 얻었습니다.