왜 VanillaFront를 만들었나?
한국 UI 프레임워크 시장의 현실
한국의 사내 시스템·엔터프라이즈 웹 개발에는 오랜 관행이 있다. 그리드·차트·다이어그램 같은 전문 컴포넌트가 필요하면 사실상 몇 개 안 되는 상용 UI 프레임워크 중 하나를 고른다. 대안이 없어서가 아니다. 이 도구들이 오래 자리를 잡아서 "일단 이거로 시작" 이 표준이 되어버렸기 때문이다.
문제는 이 표준의 진입 비용이다.
라이선스 벽
정확한 가격은 벤더별·계약별로 다르지만, 시장에서 통용되는 대략의 감각은 이 정도다:
카테고리대표 제품가격대 (대략)
| 종합 UI 플랫폼 | 국내의 N제품, W제품, eX제품 | 프로젝트/도메인당 수천만 원 ~ 수억 원 |
이 가격표를 보는 세 부류의 개발팀이 있다:
- 대기업·공공 SI — 프로젝트 예산에 라이선스가 이미 편성되어 있음. 문제 없음
- 중소 SI·스타트업 — 라이선스 비용 하나가 프로젝트 마진을 통째로 잡아먹음. 부담스럽지만 대안이 마땅하지 않음
- 1인 개발자·사내 소규모 팀 — 아예 시야에 안 들어옴. "그건 회사가 사주면 쓰는 것"
두 번째와 세 번째 그룹이 시장의 대다수다. 그리고 지금까지 가장 간과되어 왔다.
"그럼 오픈소스 쓰면 되지 않나?"
React + AG Grid Community, Vue + Handsontable — 조합 자체는 가능하다. 하지만 한국형 엔터프라이즈 화면의 실전 요구를 채우려면 벽이 있다:
- 각각의 특징이 있기때문에 이를 연동하는 것은 또다른 문제.
결국 "한국형 엔터프라이즈 화면에 실전 투입 가능하면서 접근 가능한 라이선스" 라는 조합이 시장에 통째로 비어 있었다.
VanillaFront가 채우려는 자리
이 빈자리를 겨냥해 만들었다.
- 바닐라 자바스크립트 기반 — React·Vue·npm 없이 브라우저에서 직접 실행
- 120개 이상의 컴포넌트 — Grid, TreeGrid, DynamicGrid, PivotGrid, Chart, Diagram, ColorPicker 등 실전 컴포넌트를 자체 구현
- 한국형 화면 관행 내장 — Page > Panel 표준 구조, 폼 그리드, 분할 레이아웃, 다중 테마 (Light·Dark·Paper·Titan 등)
- No-Build 아키텍처 — ES6 모듈 직접 로드. Webpack·번들러·CI 파이프라인 없이 즉시 배포
- VSCode Extension 통합 — AI가 만든 화면을 그 자리에서 보고 저장. WYSIWYG 에디터 연동
- 접근 가능한 라이선스 — 개인·소규모 팀이 부담 없이 시작할 수 있는 구조
핵심 원칙
"라이선스 때문에 못 쓰는 개발자"가 없어야 한다.
대기업이 수천만 원짜리 그리드로 만든 화면과, 1인 개발자가 만드는 화면이 기술적으로 대등해야 한다. 사내 관리 시스템 하나 짜려는 소규모 팀이 "우린 예산이 없어서 그냥 부트스트랩 폼으로..." 하는 상황이 이 시장에서 사라져야 한다.
이게 VanillaFront가 존재하는 이유다.
지금 어디까지 왔나
- 120개 이상의 컴포넌트 카탈로그 완성
- 멀티 테마 적용 가능
- 업체 내부 시스템에서 실전 사용 중, VanillaSchedule 개발
- VSCode Extension 배포
- AI 개발 워크플로우 (AI 생성 → 즉시 시각화 → 저장) 통합 완료
대형 벤더의 지원 조직도 없고, 공개 사용 사례도 축적 중이다. 하지만 "가격 때문에 검토조차 못 했던 팀"에게 실제로 쓸 수 있는 선택지를 주는 것 — 그게 이 프로젝트의 첫 번째 약속이다.
- https://vanillafront.com 홈페이지에서 확인