Next.js 프로젝트에서 미사용 파일 338개 정리

프로젝트 안에는 리뉴얼 전 화면과 더는 참조되지 않는 컴포넌트가 남아 있었다. 파일 이름을 하나씩 검색하는 방식으로는 전부 찾기 어려웠다. 동적 import나 설정 파일에서 쓰는 코드까지 잘못 지울 수도 있었다.

Next.js가 실제로 실행하는 파일에서 시작해 import를 따라가 보기로 했다.

엔트리포인트부터 import를 따라갔다

분석을 시작할 파일은 page, layout, route처럼 Next.js가 정해둔 파일이었다. 여기에 middleware, 인증 설정, 서비스워커와 i18n 설정도 포함했다. SCSS는 빌드 설정의 prependData로 들어오는 파일까지 따로 넣었다.

Next.js 엔트리포인트와 설정 파일
  → import한 파일을 따라 이동
  → 한 번이라도 도달한 파일 표시
  → 도달하지 못한 파일을 후보로 분류

이렇게 찾은 후보는 423개였다. 숫자가 크다고 바로 전부 지우지는 않았다.

후보 423개를 다시 나눴다

미사용 후보에는 채팅 모바일 화면, 리뉴얼 전 스케줄 상세, 예전 수업 폼과 랜딩 페이지 코드가 섞여 있었다. 다시 열릴 가능성이 있어 남기기로 한 페이지도 있었다. 그 페이지에서 쓰는 데이터 코드와 수업 상세의 연동 코드는 후보에서 제외했다.

컴포넌트는 사용 중인데 스타일 파일만 참조되지 않는 경우도 있었다. 이런 SCSS 파일 26개는 자동으로 지우지 않고 따로 확인할 대상으로 남겼다.

PR을 올리기 전 연동 코드 20개를 다시 살렸다. 지금은 import되지 않지만 기능이 다시 열릴 가능성이 있었기 때문이다.

중간 커밋도 빌드가 되어야 했다

파일은 채팅, 스케줄, 수업, 커뮤니티처럼 기능별로 나눠 지웠다. 여기서 한 가지 문제가 있었다. tsconfig가 사용 여부와 상관없이 **/*.ts를 모두 타입 검사하고 있었다. 마지막 결과만 맞더라도 중간 커밋에 import가 끊긴 파일이 남으면 그 커밋은 빌드되지 않았다.

삭제할 파일끼리의 import 관계를 다시 확인했다. 다른 파일을 불러오는 쪽을 먼저 지우거나 같은 커밋에 묶었다. 각 단계마다 끊어진 import가 없는지 검사하고 yarn build를 돌렸다. rebase merge 뒤에도 어느 커밋에서든 빌드할 수 있게 하려는 목적이었다.

dev에서 주요 화면을 다시 확인했다

최종적으로 338개 파일을 제거했다. 정적 검사에서는 남은 파일이 삭제한 파일을 참조하는 경우가 없었다. 그래도 import graph만으로 실제 동작까지 확인할 수는 없었다.

dev에 배포한 뒤 대시보드, 수업 목록과 상세, 생성 폼, 스케줄, 채팅, 커뮤니티, 정산처럼 삭제한 코드와 가까운 화면을 직접 열어봤다. 페이지 렌더링과 주요 동작을 확인했고 콘솔 에러도 같이 봤다.

같은 빌드 환경에서 처음에는 2분 3초가 걸렸고 정리 뒤에는 61초가 걸렸다. 빌드 성능만 따로 측정한 테스트는 아니어서 항상 절반으로 줄었다고 말하기는 어렵다. 이번 작업의 목적은 오래된 코드를 걷어내는 것이었고 빌드 시간 감소는 정리 뒤 함께 확인한 변화였다.