knip 개요
사용되지 않는 종속성, 내보내기 파일을 찾아 수정하고 코드 및 종속성 관리를 향상시키는 정적 분석 도구이다.
프론트엔드 프로젝트 규모가 커질 수록 새로운 도구, 라이브러리를 대체하거나 사용하지 않는 함수들이 생겨나기 마련인데 knip는 이러한 경우 사용하지 않는 항목들을 검진하고 수정해준다.
knip(닢)은 2022년에 v1버전(Exportman)을 출시하여 2025년 기준 v5(Knip)까지 출시하였으며 성능향상, Auto-Fix 기능도 제공하는데 최소한의 코드만 제거하는 식으로 동작한다고 한다.
(https://knip.dev/)
knip로 확인 가능한 항목, eslint와의 차이점 설명
knip을 확인하기 전에 biome.js나 eslint에서 이미 제공하고있는 기능인것은 아닐까?하는 마음에 찾아보았지만,
가장 유사한 기능으로 미사용 import 탐지 기능만 존재했다.
eslint가 있는데 왜 사용하면 좋은것인가? → 목적과 분석 대상범위가 다름
- eslint → 단일 파일 내 코드가 잘 쓰였는지 확인
- knip → 프로젝트 전체를 대상으로 파일 간 의존성 흐름을 분석하고 코드가 불필요하지 않은지 확인.
| 구분 | ESLint (Linter) | Knip (Dead Code Finder) |
|---|---|---|
| 주요 목적 | 코드 품질 및 일관성 향상 (스타일, 잠재적 버그 방지) | 프로젝트 최적화 및 경량화 (미사용 자원 제거) |
| 분석 대상 범위 | 주로 단일 파일 내부 | 프로젝트 전체 (파일 간의 의존성 및 외부 의존성) |
| 분석 대상 항목 | • 문법 및 구문 오류 (no-undef) • 코드 스타일 규칙 ( indent, semi) • 훅/API 사용 규칙 ( react-hooks/exhaustive-deps) • (일부) 미사용 import 변수 | • 미사용 의존성 (package.json) • 미사용 파일 및 폴더 • 미사용 export (함수/변수/타입) • (일부) 미사용 import 모듈 |
| 탐지 Dead Code | 로컬 Dead Code (파일 내에서 선언 후 미사용) | 글로벌 Dead Code (프로젝트 전체에서 참조 없음) |
| 효과 | 코드 리뷰 시간 단축, 잠재적 런타임 버그 감소 | 번들 크기 감소, 빌드 시간 단축, 유지보수 효율 증대 |
knip 기본 사용법 및 주요 옵션 사용 예시
autoFix가 존재하지만 AI Agent와 함께 사용하여 수정하는 방안을 가장 권장한다. 완벽하게 수정하지 못하는 케이스가 있기 때문
prompts 사용해서 탐지된 내역을 수정해야하는 이유와 함께 사용자에게 물어보고 수정하게 끔 도입하는것도 좋을것으로 보임
설치 및 fix 사용방법
// 설치
pnpm add -D -w knip
루트 최상단 설정 파일 예시(knip.json)
{
"$schema": "https://unpkg.com/knip@latest/schema.json",
// workspaces 모노레포 환경에서 각 패키지 앱을 독립적으로 분석 entry는 진입점, project는 탐색 대상 범위를 정하는 개념
"workspaces": {
"apps/host": {
"entry": ["src/main.tsx", "vite.config.ts"],
"project": ["src/*/.{ts,tsx}", "*.config.{ts,js}"]
},
"apps/remote": {
"entry": ["src/index.tsx", "rsbuild.config.ts"],
"project": ["src/*/.{ts,tsx}", "*.config.{ts,js}"]
},
"shared/ui": {
"entry": ["src/index.ts"],
"project": ["src/*/.{ts,tsx}"]
},
"shared/i18n": {
"entry": ["src/index.ts"],
"project": ["src/*/.{ts,tsx}"]
}
},// 분석에서 완전히 제외할 경로 패턴
"ignore": [
"*/.test.{ts,tsx}",
],// 패키지에 있지만 직접 impoort되지 않아도 used로 간주
"ignoreDependencies": ["@module-federation/*"],// 같은 파일 내에서 사용되는 export는 used로 간주
"ignoreExportsUsedInFile": true
}
탐지 및 수정 방법
// 탐지
pnpm knip// 탐지된 항목 AutoFix, 사용하지 않는 파일을 제거하려면 --allow-remove-files 옵션 추가
// trace와 performance, 실시간 watch 옵션 외 다른 옵션들이 존재하지만 사용할이 없을것으로 보임
pnpm knip --fix
pnpm knip --fix --allow-remove-files// 일부만 AutoFix가 가능하며 5가지 항목 중 검사하고싶은 항목만 수정이 가능하다.
// 이 중 catalog는 플러그인으로 확장하여 지원하는 Eslint, Vitest 같은 특정 도구의 설정 파일 내 사용되지 않는 설정 항목 제거 역할
pnpm knip --fix-type files,exports,types,dependencies,catalog
도입 유의사항
-
dynamic import나 모노레포 환경에서 MF를 사용해 런타임으로 remote를 불러 사용하는 케이스 감지하는지 확인 필요
→ MF에서 expose되는 컴포넌트인데 knip이 "미사용"으로 오탐지할 수 있는 상황이 존재하기에 knip옵션에 entry, ignore 옵션을 지정해 해결이 가능
-
ignore 범위 설정 시 유의사항
→ 범위를 과도하게 넓게 설정할 경우, 실제 정리 가능한 dead code까지 탐지 대상에서 제외할 수 있어서 파일 유형 혹은 명확한 역할 단위로만 설정해야 함(아래 예시)
전체 ignore 말고도 workspaces 패키지별 ignore 처리가 가능"ignore": [
"/*.test.{ts,tsx}",
"/mocks/**"
] -
탐지 및 dependency 제거 이후 작업
→ 제거 후 pnpm install 실행 및 로컬 테스트
→ 제거 후 반드시 build 실행하여 이상 없는지 확인 -
근데 AutoFix는 정상적으로 동작하는가? → 직접 사용해본 결과 Fix된 내용은 사용자의 확인이 필수이며, autoFix의 영향 범위를 제한하거나 사용자가 직접 수정하는것이 나을 수 있다.
→ AI Agent에게 pnpm knip 결과를 통해 수정 부탁하는것이 가장 손이 덜 가면서 빠른 수정이 가능한것으로 보임, (fix후에 또 fix가 필요한 상황 발생)
결론 및 기대효과
- knip은 프로젝트가 구조적으로 건강 상태를 유지하고 있는지 확인하는 도구
- 신규 프로젝트에 도입한다고 가정하면 프로젝트 초기 개발 단계에서는 참고용으로만 활용하고,
안정된 버전 이후의 PR 단계부터 husky를 통해 dead code 유입을 차단하는 쪽으로 가는것이 좋을걸로 보임
(GPT는 PR CI과정에서 팀 기준으로 막는것이 강제력을 부여하여 추천한다고는 함 → 사람들이 우회할까봐 걱정(?) ,공식문서에는 Github Action가이드만 존재) - 초기 정리와 함께 entry, ignore 설정을 하여 baseline을 잡아놓아야, 간단한 commit에도 dead code가 넘쳐 fail이 뜨는 현상을 방지 가능
- 사용 중 너무 잦은 탐지가 발생한다면 분기or패치 별로 탐지 및 수정을 진행하는것도 방법으로 보임
- AutoFix는 불안정하여 사용하지 않는게 낫고 knip로 탐지 → AI Agent와 함께 수정을 권장한다, 수정 후에는 로컬 및 빌드 테스트 필요
