피드로 돌아가기
5 Reasons Why I Built an ERP in Vanilla JavaScript
Dev.toDev.to
Frontend

프레임워크 없이 Lighthouse 100% 달성, Vanilla JS ERP 구축기

5 Reasons Why I Built an ERP in Vanilla JavaScript

Pavel L.2026년 4월 4일7intermediate

Context

모던 프레임워크의 제약 사항으로 인한 개발 자유도 저하 발생. 복잡한 의존성 체계로 인한 유지보수 난이도 상승 및 버전 업데이트 시 예기치 못한 장애 위험 존재. 프런트엔드와 백엔드 간 로직 중복 작성으로 인한 데이터 정합성 유지의 어려움.

Technical Solution

  • ES Module 기반의 네이티브 import 구조를 채택하여 컴파일 단계 없는 모듈화 설계
  • 모든 페이지 클래스에 constructor → init → html → render → listeners 순의 반복 가능한 표준 패턴 적용
  • Root 경로의 packages 폴더에 세금 계산 로직을 통합하여 PDF 인보이스와 프런트엔드 간 Single Source of Truth 확보
  • 페이지별 독립적 UI 섹션 분리로 고부하 기능(Three.js 기반 3D 뷰어)의 영향 범위를 해당 페이지로 한정하는 격리 전략
  • 이벤트 리스너를 JS가 아닌 HTML에 직접 선언하여 DOM 부분 업데이트 시 발생하는 리스너 유실 및 중복 실행 문제 해결
  • Rollup 스크립트를 도입하여 브라우저 캐싱 이슈 해결 및 프로덕션 환경의 번들링 최적화

Impact

  • 대부분의 페이지에서 Lighthouse 점수 100% 달성
  • 인벤토리 페이지 기준 단일 JS 파일 크기 30KB 수준 유지

Key Takeaway

단순한 프로젝트 구조에서는 프레임워크의 추상화 계층보다 언어 자체의 기본 기능을 활용한 직접적인 제어가 런타임 성능과 개발 생산성을 동시에 높이는 전략이 될 수 있음.


단일 개발자 중심의 소규모 프로젝트이며 데이터 구조가 명확한 경우, 의존성 최소화를 위해 Vanilla JS와 표준 패턴 도입을 검토할 것

원문 읽기