← 목록으로

Fallow로 코드베이스 진단하기

2026-08-03

AI가 만든 코드, 어디부터 손대야 할까

AI로 코드를 작성하다 보면 어느새 알아보기 힘든 코드들이 쌓여 있는 경우가 생긴다. 어디가 문제인지 파악하는 것부터가 일인데, 이럴 때 쓸 만한 도구가 Fallow다.

Fallow는 fallow.tools에서 상세 기능을 확인할 수 있고, TypeScript 또는 JavaScript 프로젝트의 코드베이스를 분석해 중복되는 코드, 사용하지 않는 코드, 복잡한 코드를 알려준다. 이렇게 얻은 결과물을 AI 에이전트에게 넘겨 리팩토링을 진행하면 AI 비용이나 시간을 절약할 수 있다.


사용법

npx fallow 를 입력하면 세 개의 섹션으로 나뉜 결과가 나타난다.

Dead Code

사용하지 않는 코드와 패키지, 중복된 export 코드, 모듈 또는 파일 간 export된 코드 등을 요약해 표기해준다. 아래 사진에서는 총 10개의 사용되지 않는 코드가 있고, 2개의 중복된 타입이 export되고 있다는 정보를 보여주고 있다.

해당 정보만 보려면 npx fallow dead-code 를 사용한다.

Fallow Dead Code 섹션 출력

Duplication

중복된 코드베이스를 찾아 요약된 정보를 표시해준다. 아래 그림에서는 총 5개의 파일에서 중복된 코드가 존재하며 73개의 줄에서 사용 중이다.

해당 정보만 표시하려면 npx fallow dupes 명령어를 사용한다.

Fallow Duplication 섹션 출력

Health

리팩토링이 필요한 코드, 복잡도가 높은 코드 등 코드베이스에서 읽기 어려운 로직을 중심으로 알려준다. 해당 정보만 표시하려면 npx fallow health 명령어를 사용한다.

특히 중요하게 볼 지표는 cyclomatic, cognitive, CRAP 세 가지다.

지표의미
cyclomatic코드에 존재하는 분기점 개수. if, switch 등 조건문이 많을수록 점수가 높아진다
cognitive코드 가독성이 높은지 판단하는 지표. 중첩된 코드가 있을 경우 점수가 높아진다
CRAP복잡도와 테스트 커버리지의 상관관계를 이용해, 해당 코드를 수정할 때 버그가 발생할 위험성을 나타내는 지표

CRAP은 복잡한 코드의 테스트 커버리지가 낮으면 점수가 높게 측정되고, 코드의 복잡성을 낮추거나 테스트 커버리지를 높이면 점수가 낮아진다.

아래 결과를 보면 src/core/transform.ts:36resizeLocalBox 파일 하나에만 분기 조건이 27개 존재하는 것을 볼 수 있다.

Fallow Health 섹션의 복잡도 지표

파일별 요약 지표

마지막으로 아래 스크린샷의 지표는 모든 파일의 요약된 정보를 나타낸다.

지표의미
LOC코드 줄 수
fan-in해당 파일을 참조하는 외부 모듈 개수
fan-out해당 파일이 참조하는 외부 모듈 개수
dead사용하지 않는 코드의 비율
density복잡도 밀도. 코드 줄 수 대비 조건문 및 복잡도 비중
risk종합 점수

risk100에서 999 사이면 테스트 코드와 간소화 작업이 필요하고, 999점 이상이면 반드시 리팩토링이 필요한 파일이라고 알려준다.

Fallow 파일별 요약 지표


익스텐션으로 더 편하게 보기

터미널에 npx fallow 를 입력해 매번 검사하기보단, 익스텐션을 설치하면 측정 지표들을 한눈에 볼 수 있다. 검색어에 fallow를 치고 아래 로고의 익스텐션을 설치해주면 된다.

Fallow 익스텐션

설치하면 좌측 패널에 해당 로고가 그려진 항목이 생기는데, 클릭해보면 터미널에 입력했던 내용을 요약해서 보여준다.

Fallow 익스텐션 좌측 패널

또한 아래와 같이 코드베이스에서 경고 표시를 통해 어떤 문제가 있는지 알려주어 쉽게 조정이 가능하다.

코드베이스에 표시되는 Fallow 경고


정리

Fallow는 코드베이스의 문제를 찾아주는 도구이지, 고쳐주는 도구가 아니다. 하지만 리팩토링에서 가장 오래 걸리는 작업이 "어디가 문제인지 파악하는 일"이라는 점을 생각하면, 이 단계를 정적 분석으로 대신할 수 있다는 것만으로도 충분히 가치가 있다.

특히 AI 에이전트와 함께 작업할 때 효과가 크다. "이 프로젝트를 리팩토링해줘" 처럼 막연하게 요청하면 에이전트가 코드베이스 전체를 훑느라 토큰과 시간을 낭비하지만, Fallow의 리포트를 근거로 risk 점수가 높은 파일부터, 구체적인 지표와 함께 요청하면 범위가 좁혀져 비용과 시간을 아낄 수 있다.

정기적으로 돌려보면서 risk 점수가 999를 넘는 파일이 생기지 않도록 관리하는 정도로만 활용해도 코드베이스가 무너지는 속도를 늦출 수 있을 것이다.