코드 다이어트 - Knip으로 불필요한 코드 줄이기
서비스에 기능 추가 및 리뉴얼을 거듭 할 수록 보면 사용하지 않는 코드, 파일, 패키지(= 데드코드)가 생기게 됩니다. 물론 눈에 띄지 않겠지만, 번들 크기, 가독성 그리고 온보딩에 영향을 줍니다.
이번 글은 knip을 활용하여 데드코드를 탐지하는 것에 대해서 작성해보고자 한다.
데드코드 방치해도 괜찮을까?
트리쉐이킹 단계에서 배제될거기도 하고, 프로젝트 실행에는 직접 영향이 없어 보여 굳이 제거 안 해도 괜찮지 않나? 라고 생각할 수 있다. 하지만 방치하게 되면 아래 문제가 발생한니다.
- 온보딩/리뷰 비용 증가: 시스템을 이해하고 유지보수 하기 어렵게 만든다.
- 빌드/테스트 시간 증가: 대부분 체감은 안되겠지만 빌드/테스트 진행시 스캔해야될 양이 증가하여 완료소요 시간이 증가한다.
- 리팩토링 안전망 축소: 불필요한 코드가 많을수록, 리팩토링 진행시 위험도가 증가한다.
- 실수 유도: 더 이상 사용하지 않는 deprecated 된 api/컴포넌트를 사용하게 될 가능성이 있다.
Knip은 뭔가?
Knip은 TypeScript/JavaScript 프로젝트를 정적 분석해 미사용 항목을 찾아준다.
- Unused code / Unused exports
- dependencies / devDependencies / peerDependencies 미사용 점검
사용 방법이 단순해 문서만 조금 읽어보면 바로 적용 가능하다.
설치 및 실행
knip.json 설정
테스트/스토리 등 ‘사용 의도는 있지만 앱 번들엔 포함되지 않는’ 파일은 제외하는 것이 핵심이다.
실제 탐지 예시
위와 같은 컴포넌트들이 있을 때 knip을 실행하면
LegacyComponent 는 export가 미사용이어서 제거 후보로 출력이 되게 됩니다. 아래 같이 말이다.
점진적 도입
- 탐지 위주로 진행: 로컬에서만 실행하여 목록 체크 (CI 적용도 가능, 파이프라인 실패x)
- 범위 제한: 한 번에 다 정리하기 보다는 작은 범위 부터 정리 진행 - 부작용 최소화
- 강화 전환: 합의 된 시점 부터는
--exitCode를 지정하여 요소 감지시 실패 처리 (예: unused exports 혹은 unused files 감지 시 실패)
현재 팀에서는 1·2단계로 가볍게 운영 중이고, 양이 꽤 많아 3단계 전환 시점은 팀 합의를 해나갈 예정이다.
결론
서비스가 커질수록 눈에 잘 띄지 않는 데드코드는 점점 쌓이게 됩니다. 이를 방치하면 단순히 번들 크기 문제를 넘어, 온보딩 비용 증가·리뷰 난이도 상승·리팩토링 리스크 확대 등 여러 부작용이 뒤따른다.
Knip은 이러한 문제를 예방하기 위한 “가벼운 안전망” 역할을 한다.
- 초기에는 탐지 위주로 운영하여 부담을 줄이고,
- 점차 범위를 좁혀가며 정리를 진행하고,
- 팀의 합의가 이뤄지는 시점에 강화 모드(CI 실패 조건) 로 전환하는 것이 가장 안정적인 도입 방법이다.
즉, 단순한 미사용 코드 탐지 도구를 넘어, 코드베이스 건강 상태를 지속적으로 관리하는 도구 로 활용할 수 있다.
작은 정리 습관은 장기적으로는 개발 생산성과 유지보수성을 크게 높여준다.
참고: