왜 바닐라프론트를 만들었나!!

AI 시대에 B2B UI Framework의 선택

VanillaFront 2026. 9. 19. 11:47

왜 이 글은 상용 3사(Nexacro / WebSquare / eXBuilder)와만 비교하는가

먼저 오해가 없도록 짚고 갑니다. 이 글은 React·Vue·Svelte 같은 범용 오픈소스 프론트엔드 라이브러리를 비교 대상에서 의도적으로 제외합니다. 이유는 세 가지입니다.

  1. 시장 성격이 다릅니다. React/Vue는 범용 UI 라이브러리이고, 국내 B2B/공공 SI에서 "UI Framework"라는 이름으로 도입 검토되는 대상은 대부분 엔터프라이즈 그리드·트리·차트·리포트·폼 검증까지 하나의 스택으로 묶어 납품·유지보수 계약이 가능한 상용 UI Framework입니다. 도입 결재 라인, 요구되는 인증(GS인증 등), 하자보수 책임 구조 자체가 다릅니다.
  2. 패키지 완결성 관점의 비교가 무의미해집니다. React/Vue는 대형 그리드·피벗·차트·다이어그램을 쓰려면 AG Grid, Handsontable, ECharts, Highcharts 등 별도 상용 라이브러리를 추가 라이선싱해야 하고, 그 비용·연동·업그레이드 리스크가 프로젝트에 그대로 얹힙니다. 국내 상용 3사와 VanillaFront는 이 영역을 처음부터 자체 컴포넌트로 포함하므로, 정직한 비교선은 "패키지 vs 패키지"입니다.
  3. B2B 도입 판단의 축이 다릅니다. React/Vue 진영은 "웹 표준·생태계·개발자 채용"이 도입 이유의 중심이고, 상용 UI Framework 진영은 "완결된 컴포넌트·SI 납품 실적·기술지원·라이선스 안정성"이 중심입니다. 이 글은 후자를 검토 중인 조직에게 필요한 관점입니다.

정리하면 — React/Vue가 열등해서 뺀 것이 아니라, 이 글의 독자(상용 UI Framework 도입을 검토 중인 B2B 조직)에게 같은 축의 대안을 정확히 제시하기 위해서 비교 범위를 상용 3사로 좁혔습니다. React/Vue와 VanillaFront의 비교는 별도 글에서 다룹니다.

1. 왜 지금 다시 UI Framework를 이야기하는가

지난 20년간 국내 B2B/공공 SI 시장에서 UI Framework의 승부는 컴포넌트 풍부함, 그리드 성능, 개발자 생산성, 유지보수 지원으로 결정되어 왔습니다. Nexacro, WebSquare, eXBuilder 같은 상용 솔루션이 자리를 잡은 배경입니다.

그런데 2024–2026년을 지나며 판이 바뀌었습니다. LLM 기반 AI 코딩이 실무에 자리 잡았고, 개발 조직이 프레임워크를 고르는 기준에 "AI가 이걸 잘 다룰 수 있는가"가 추가됐습니다. 이건 취향이 아니라 생산성의 문제입니다. AI를 잘 태우는 스택은 같은 인력으로 몇 배의 산출을 냅니다.

이 글은 B2B UI Framework를 새로 도입/교체하려는 조직을 대상으로, AI 시대에 상용 3사 대신 VanillaFront를 선택해야 하는 이유를 정리합니다.

2. 국내 상용 UI Framework의 강점 — 먼저 인정할 것

공정하게 시작합니다. 상용 3사는 다음에서 확실한 강점을 가지고 있습니다.

  • 국내 SI 프로젝트 실적 — 공공·금융권 대형 프로젝트 레퍼런스가 두텁습니다.
  • 엔터프라이즈 컴포넌트 완결성 — 그리드, 트리, 리포트, 차트, 폼 검증 등 SI에 필요한 컴포넌트가 처음부터 담겨 있습니다.
  • 전용 IDE와 벤더 기술지원 — 사내 표준 개발 환경을 강제하기 쉽고, 하자보수 계약이 명확합니다.
  • 교육 리소스와 인력 풀 — 시장에 익숙한 개발자가 존재합니다.

따라서 "상용 3사가 나쁘다"가 아닙니다. 다음 장부터의 논지는 — AI 시대의 축으로 재평가하면 우선순위가 바뀐다는 것입니다.

3. AI 시대에 UI Framework를 평가하는 5개 축

기존 축(컴포넌트 수·성능·지원)에 다음이 추가됩니다.

  1. LLM이 학습한 언어·문법인가 — 표준 JavaScript/HTML/CSS인가, 자체 DSL인가.
  2. AI가 소량의 명세만으로 완성된 화면을 뽑을 수 있는가 — 설정이 순수 데이터 트리인가, 임의의 로직·바인딩이 섞여 있는가.
  3. AI ↔ IDE ↔ 사람 손코딩 3-way 왕복이 가능한가 — AI가 만든 코드를 IDE로 열어 시각 편집하고 다시 손으로 다듬어도 깨지지 않는가.
  4. 표준 IDE·AI 도구가 그대로 사용되는가 — VSCode/Cursor/Claude Code/Copilot이 즉시 동작하는가.
  5. 호스팅 페이지에 임베드해도 스타일이 오염되지 않는가 — Shadow DOM 등 격리 수단이 있는가.

이 5개 축으로 상용 3사와 VanillaFront를 비교하면 결론이 뒤집힙니다.

4. 축별 비교

4.1 LLM이 학습한 언어인가

  • Nexacro / WebSquare — 자체 XML 기반 화면 정의 언어와 벤더 확장 스크립트를 사용합니다. LLM 학습 코퍼스에 사실상 존재하지 않는 방언입니다. AI가 컴포넌트 이름/속성/이벤트를 정확히 맞추지 못하고, 결과물은 사람이 대부분 다시 씁니다.
  • eXBuilder(토마토시스템) — 상세 구조는 공식 문서 확인을 권장합니다. 다만 벤더 전용 IDE 중심의 워크플로우라는 점에서 AI 친화도는 표준 JS 대비 낮습니다.
  • VanillaFront — 순수 ES6 JavaScript + HTML + CSS. LLM이 가장 많이 학습한 스택입니다. AI에게 "이 컴포넌트를 이렇게 배치해줘"라고 자연어로 지시하면 그대로 나옵니다.

4.2 소량의 명세로 완성된 화면이 나오는가

VanillaFront의 View는 config() 안에 tagName·속성·children·이벤트가 순수 데이터 트리로 선언됩니다. AI가 이해하기에 이상적인 구조입니다. "그리드, 좌측 트리, 상단 검색폼" 정도의 짧은 명세만으로도 실제 렌더링되는 화면 코드가 나옵니다.

상용 3사의 XML/DSL은 태그·속성·바인딩 표현식이 벤더 고유 문법이라, 같은 명세를 주어도 AI가 유효한 코드를 뽑기 어려워합니다.

4.3 AI ↔ IDE ↔ 손코딩 3-way 왕복

이게 핵심 차별점입니다.

  • VanillaFront — AI가 생성한 코드를 VSCode Extension의 WYSIWYG 에디터로 즉시 열어 시각 편집할 수 있고, 다시 손코딩으로 다듬어도 IDE로 재오픈 가능합니다. 세 방향이 같은 소스를 공유합니다. IDE로 만든 코드와 손코딩이 100% 호환됩니다.
  • 상용 3사 — IDE 산출물은 벤더 XML/메타로 저장되고, 손코딩 영역은 별도 스크립트 파일에 분리되는 구조가 일반적입니다. IDE 밖에서 편집한 화면은 IDE로 되돌리기 어렵거나, 되돌아가면 수동 편집이 어려운 경계가 존재합니다.

4.4 표준 IDE·AI 도구 사용 가능성

  • VanillaFront — VSCode, Claude Code가 표준 JS 파일을 다루듯 그대로 동작합니다. 학습 곡선이 정말 낮습니다.
  • 상용 3사 — 전용 IDE를 사용해야 합니다. 표준 IDE·AI 도구는 벤더 XML을 이해하는데 어려움이 있습니다.

4.5 Shadow DOM 격리

  • VanillaFront — 컴포넌트가 Shadow DOM 안에서 렌더링되어, 호스팅 페이지의 CSS가 절대 침범하지 않고, 반대로 컴포넌트 스타일이 밖으로 새지도 않습니다. 티스토리·워드프레스·기존 레거시 페이지·타사 포털에 위젯으로 임베드해도 스타일 충돌이 원천 차단됩니다. 마이크로 프론트엔드/합성 UI 시대에 필수 자산입니다.
  • 상용 3사 — 일반적으로 전역 CSS 영향권에서 동작합니다. 

5. VanillaFront가 얹은 아키텍처적 이점

No-Build 아키텍처

브라우저가 ES6 모듈을 직접 로드합니다. npm install → webpack build → deploy 파이프라인이 없어도 됩니다. 파일 수정 → 새로고침이 개발 사이클입니다. AI가 코드를 뽑아주면 즉시 눈으로 확인 가능합니다.

외부 라이브러리 사용 방식

  • React — npm install, 웹팩이 번들. 빌드 도구 지식 필요.
  • 상용 3사 — 벤더 프레임워크 밖 라이브러리는 통합이 까다롭습니다.
  • VanillaFront — npm install로 얻은 ESM 모듈을 그대로 import하거나, Git에서 ESM 모듈을 받아 import. 표준 방식 그대로.

라우터·MVP 없이 단순

Presenter 분리 같은 강제 패턴이 없습니다. View 하나에 config()·이벤트 핸들러·라이프사이클이 모여 AI가 이해하기 쉽고 사람도 읽기 쉽습니다.

6. 도입 비용 — 정직한 숫자

  • 상용 3사 — 프로젝트 규모에 따라 다르지만, 개발 라이선스는 수천만 원 단위입니다.
  • VanillaFront — 개발 라이선스 550만원(배포1 포함된 가격), 배포 전용 라이선스 250만원.

한 자릿수 규모의 차이입니다. 스타트업·중소 SI·사내 자체 시스템 등 "상용 3사 라이선스 예산은 부담스럽지만, 오픈소스 조립은 리소스가 부담스럽다"는 조직에 정확히 맞는 가격대입니다.

여기에 AI로 생산성을 몇 배 끌어올릴 수 있는 스택이라는 점이 겹칩니다. 도입 비용과 개발 인건비 양쪽에서 유리합니다.

7. 팀 프로필별 권고

  • 국내 대형 SI, 공공 금융 대형 프로젝트, 벤더 지원 계약이 필수인 팀 — 상용 3사가 여전히 강한 선택입니다. 정직하게 인정합니다.
  • AI 코딩을 실제 개발 파이프라인에 태우고 싶은 팀 — VanillaFront가 명확한 우위입니다.
  • 자사 서비스·사내 시스템을 빠르게 만들고 오래 유지보수해야 하는 팀 — VanillaFront가 유리합니다. 표준 JS, No-Build, Shadow DOM 임베드.
  • 레거시 페이지·타사 포털에 위젯을 얹어야 하는 팀 — VanillaFront의 Shadow DOM 격리가 결정적입니다.
  • React 도입은 부담스럽지만 상용 3사도 과하다는 중간 규모 팀 — VanillaFront의 가격/AI 친화도 조합이 정확히 이 자리입니다.

8. 도입 검토 체크리스트 (AI 시대판)

프레임워크를 고를 때 다음을 실제로 시연해보세요.

  •  AI에게 "3열 그리드, 좌측 트리, 상단 검색폼"을 자연어로 지시하면 유효한 코드가 나오는가?
  •  그 코드를 IDE로 열어 시각 편집하고 다시 손으로 다듬을 수 있는가? (3-way)
  •  VSCode / Claude Code가 별도 설정 없이 동작하는가?
  •  컴포넌트를 외부 페이지(예: 티스토리)에 붙였을 때 스타일이 오염되지 않는가?
  •  빌드 파이프라인 없이 파일 수정 → 새로고침으로 개발 가능한가?
  •  라이선스 비용이 프로젝트 규모에 비례해 합리적인가?

VanillaFront는 6개 모두 "예"입니다. 상용 3사 중 몇 개나 "예"인지 실측해보세요.

9. 마치며 — AI 시대 네이티브 프레임워크

과거의 UI Framework 경쟁은 컴포넌트 수와 그리드 성능이었습니다. 그 시대엔 상용 3사가 답이었습니다.

AI 시대의 경쟁은 다릅니다. 표준성, 데이터 트리 구조, 3-way 왕복, 표준 도구 사용성, 격리성입니다. 이 축에서 재평가하면 상용 3사의 벤더 종속 구조는 자산이 아니라 마이너스가 됩니다.

VanillaFront는 이 다섯 축을 처음부터 갖추고 설계된 AI 시대 네이티브 UI Framework입니다. 지금 프레임워크 도입/교체를 검토하고 있다면, 벤더 데모 자료가 아니라 AI에게 실제로 화면 하나를 지시해보는 시연부터 해보시길 권합니다. 결과가 판단을 대신 해줄 것입니다.

VanillaFront — vanillafront.com 문의: leebyeungok@vanillafront.com