📦 아이콘, 대체 넌 왜 이렇게 크니..

웹 성능 최적화: 아이콘 패키지 번들 크기 줄이기

2025년 9월 19일

🫣 아이콘, 대체 넌 왜 이렇게 크니..

이전 글에서 번들 크기를 분석하기 위해 @next/bundle-analyzer를 사용했습니다. 그 과정에서 아이콘이 차지하는 비율이 생각보다 크다는 사실을 발견했습니다.

스토리북 전용 기능과 번들 문제

아이콘 패키지는 두 가지 요소로 구성되어 있습니다.

• iconRegistry: 스토리북에서 검색 기능을 위해 아이콘을 등록해둔 데이터
• 개별 아이콘 컴포넌트: SVGR로 변환된 컴포넌트

스토리북에서는 tags를 이용해 "apple"이라고 검색하면 Apple 아이콘을 바로 찾을 수 있습니다. 팀원들이 아이콘을 빠르게 탐색할 수 있는 기능입니다.

문제는 실제 서비스 코드에서는 iconRegistry를 전혀 사용하지 않는데도 번들에 포함되고 있었다는 점입니다. 스토리북에서만 필요한 코드가 웹사이트 번들에 들어가지 않도록 설정해야 했습니다.

트리셰이킹: 꼭 필요한 아이콘만 남기기

트리셰이킹은 사용하지 않는 코드를 번들에서 제거하는 최적화 기법입니다. 수십 개 아이콘 중 + 아이콘 하나만 사용한다면, 최종 번들에는 + 아이콘 코드만 남고 나머지는 전부 제거됩니다.

Vite에서 모듈 구조 유지하기

번들러로 Vite를 사용하고 있었는데, 여기서 중요한 옵션이 preserveModules입니다. 이 옵션을 켜면 빌드 결과물이 하나의 큰 파일로 합쳐지지 않고, 각 모듈이 독립적으로 유지됩니다.

하나의 큰 번들로 합쳐지지 않기 때문에, 실제 사용되는 아이콘만 분리되어 포함됩니다.

sideEffects 설정으로 최적화 돕기

아이콘 컴포넌트는 DOM을 조작하거나 CSS를 불러오는 부수효과가 없습니다. package.json에 다음과 같이 설정해 트리셰이킹이 확실히 동작하도록 했습니다.

엔트리 분리와 Multi-entry 적용

iconRegistry가 필요하지 않은데 아래처럼 가져오면 모든 아이콘이 번들에 포함될 수 있습니다.

이를 막기 위해 엔트리 포인트를 분리했습니다. index와 registry를 각각 독립적인 진입점으로 설정해 필요한 곳에서만 import하도록 만들었습니다.

Vite에서도 Multi-entry 설정으로 아이콘 파일과 registry 파일을 독립적인 진입점으로 인식하도록 했습니다.

최적화 적용 결과, 실제로 사용하는 아이콘만 번들에 포함되는 것을 확인할 수 있었습니다.

마치며

이전에는 동작만 하는 코드를 만들었다면, 이번 작업을 통해 실제로 어떤 코드가 번들에 포함되고 어떤 설정이 성능에 영향을 미치는지 체감할 수 있었습니다. 좋은 계기가 되었습니다 😁