왜 바닐라프론트를 만들었나!!
국내 UI Framework (Nexacro, WebSquare, eXBuilder) 와 VanillaFront 상세 비교
VanillaFront
2026. 9. 19. 09:48
시작하며
한국 엔터프라이즈 웹 개발 시장에서 자리 잡은 세 개의 상용 UI Framework와 VanillaFront를 항목별로 비교합니다.
- Nexacro (넥사크로) — 투비소프트(TOBESOFT)
- WebSquare (웹스퀘어) — 인스웨이브 시스템즈(Inswave Systems)
- eXBuilder (엑스빌더) — 토마토시스템(Tomatosystem)
세 제품은 국내 SI 시장에서 오랜 실적을 축적한 표준급 도구들이고, VanillaFront는 다른 축에서 같은 시장을 겨냥합니다. 각 제품이 서로 다른 특성을 가지므로 개별 제품으로 나눠서 특성을 정리한 뒤 항목별로 비교합니다.
1. 각 제품 개요
1.1 Nexacro (넥사크로) — 투비소프트
계보
- XPlatform·MiPlatform의 후속 제품
- 국내 SI 시장에서 오랜 실적, 특히 금융·공공 분야 강세
기술 스택
- HTML5 기반 (Nexacro14 이후)
- 자체 XFDL(XML) 화면 정의 파일
- Nexacro Studio 전용 IDE
- 자체 런타임 엔진이 브라우저 위에서 XFDL을 해석·렌더링
화면 정의 방식
- XML DSL 성격이 매우 강함
- <Form>, <Grid>, <Format>, <Cell> 등 벤더 정의 태그
- Script는 <Script><![CDATA[...]]></Script> 안에 embedded JavaScript
1.2 WebSquare (웹스퀘어) — 인스웨이브 시스템즈
계보
- 국내 SI 시장 광범위한 실적
- WebSquare5 세대, WebSquare Xenon으로 발전 진행
기술 스택
- HTML5 기반
- XForms + 벤더 정의 w2: 네임스페이스 XML
- WebSquare Studio 전용 IDE
- 자체 런타임 엔진이 XML을 파싱해 DOM으로 렌더
화면 정의 방식
- XML DSL 성격 강함
- <xf:group>, <w2:gridView>, <w2:column> 등
- JavaScript는 <script> 태그 안에 embedded
1.3 eXBuilder (엑스빌더) — 토마토시스템
정직한 고지: 제가 eXBuilder에 대해 확실히 아는 정보는 아래로 제한됩니다. 공식 자료·기술 문서로 크로스체크 필요합니다.
알려진 것
- 토마토시스템이 개발·공급하는 UI 개발 플랫폼
- Designer라는 시각 편집 도구 중심 워크플로우
- HTML5 기반의 웹 UI 개발 지원
- 화면 정의 파일 정확한 형식 (HTML+JS 조합)
정직한 접근: 아래 비교에서 eXBuilder 항목이 확실하지 않은 경우 "공식 자료 확인 권장" 으로 표시하겠습니다.
1.4 VanillaFront
기술 스택
- HTML5 기반, 브라우저 네이티브
- 순수 JavaScript ES6 클래스 + config 데이터 트리
- 런타임 엔진 없음 (표준 브라우저 API 직접 사용)
- Shadow DOM 기반 컴포넌트 격리
- No-Build (ES6 모듈 브라우저 직접 로드)
개발 도구
- VSCode Extension (WYSIWYG 에디터 통합, 선택적)
- 어떤 표준 편집기·AI 도구와도 호환
2. 화면 정의 방식 비교
| 제품파일 | 형식 | DSL | 성격언어 |
| Nexacro | XFDL (자체 XML) | 강함 | XML + embedded JS |
| WebSquare | XForms + w2: XML | 강함 | XML + embedded JS |
| eXBuilder | HTML5 + JS 기반 (공식 자료 확인 권장) | 공식사이트참조 | HTML + JS (추정) |
| VanillaFront | .js (ES6 클래스 + config 트리) | 없음 (순수 JS) | JavaScript |
Nexacro 화면 정의 예시
<Grid id="grdCustomer" binddataset="dsCustomer">
<Formats>
<Format id="default">
<Columns>
<Column size="100"/>
<Column size="200"/>
</Columns>
<Head>
<Cell text="고객코드"/>
<Cell text="고객명"/>
</Head>
</Format>
</Formats>
</Grid>
WebSquare 화면 정의 예시
<w2:gridView id="grdCustomer" dataList="dcCustomer">
<w2:header>
<w2:row>
<w2:column width="100" value="고객코드"/>
<w2:column width="200" value="고객명"/>
</w2:row>
</w2:header>
</w2:gridView>
eXBuilder 화면 정의: 공식 자료 참조. HTML + JavaScript 기반으로 알려져 있으나 정확한 컴포넌트 태그·속성 규격은 공식 문서 확인 필요. (구글 조회)
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://w3.org"
xmlns:cl="http://tomatosystem.co.kr"
xmlns:std="http://tomatosystem.co.kr/studio"
std:sid="html-abc12345" version="1.0.0.0">
<head std:sid="head-abc12345">
<title>샘플화면</title>
<!-- 1. 연결된 자바스크립트 소스코드 지정 -->
<screen std:sid="screen-def67890" id="default" name="default" width="1024px" height="768px"/>
<cl:model std:sid="model-12345678">
<!-- 2. 데이터셋 (Data 모델 정의) -->
<cl:dataset std:sid="d-set-0123" id="dsUser">
<cl:datacolumnlist>
<cl:datacolumn name="USER_ID" datatype="string"/>
<cl:datacolumn name="USER_NM" datatype="string"/>
<cl:datacolumn name="EMAIL" datatype="string"/>
</cl:datacolumnlist>
</cl:dataset>
<!-- 3. 통신 객체 (Submission 정의) -->
<cl:submission std:sid="submission-9999" id="subList" action="/api/user/list.do" mediatype="application/json">
<cl:responsedata dataid="dsUser"/>
</cl:submission>
</cl:model>
<cl:appspec title="사용자 관리 화면"/>
</head>
<body std:sid="body-abc12345" style="top:0px; left:0px; width:1024px; height:768px;">
<!-- 4. 화면 레이아웃 정의 (예: XYLayout) -->
<cl:xylayout std:sid="xylayout-0000"/>
<!-- 5. UI 컨트롤 배치 (버튼, 그리드 등) -->
<!-- 조회 버튼 -->
<cl:button std:sid="button-1111" id="btnSearch" value="조회">
<!-- 버튼에 걸려있는 자바스크립트 이벤트 연결 매핑 -->
<cl:listener std:sid="listener-2222" name="click" handler="onBtnSearchClick"/>
<cl:xylayoutdata std:sid="xy-data-1111" top="20px" left="20px" width="80px" height="30px"/>
</cl:button>
<!-- 데이터 출력용 그리드 컴포넌트 -->
<cl:grid std:sid="grid-3333" id="grdUser" datasetid="dsUser">
<cl:xylayoutdata std:sid="xy-data-3333" top="70px" left="20px" width="600px" height="300px"/>
<cl:gridcolumn std:sid="g-col-4444" width="100px"/>
<cl:gridcolumn std:sid="g-col-5555" width="150px"/>
<cl:gridcolumn std:sid="g-col-6666" width="250px"/>
<!-- 그리드 헤더 영역 -->
<cl:gridheader std:sid="gh-7777">
<cl:gridrow std:sid="g-row-7777" height="24px"/>
<cl:gridcell std:sid="gh-cell-1" rowindex="0" colindex="0" text="사용자 ID"/>
<cl:gridcell std:sid="gh-cell-2" rowindex="0" colindex="1" text="이름"/>
<cl:gridcell std:sid="gh-cell-3" rowindex="0" colindex="2" text="이메일"/>
</cl:gridheader>
<!-- 그리드 본문(디테일) 및 데이터 바인딩 영역 -->
<cl:griddetail std:sid="gd-8888">
<cl:gridrow std:sid="g-row-8888" height="24px"/>
<cl:gridcell std:sid="gd-cell-1" rowindex="0" colindex="0" columnname="USER_ID"/>
<cl:gridcell std:sid="gd-cell-2" rowindex="0" colindex="1" columnname="USER_NM"/>
<cl:gridcell std:sid="gd-cell-3" rowindex="0" colindex="2" columnname="EMAIL"/>
</cl:griddetail>
</cl:grid>
</body>
</html>
VanillaFront 화면 정의
import Va from '../../lib/va.js';
export default class CustomerList extends Va.View {
constructor(){ super(arguments); }
mounted(){ this.onSearch(); }
onSearch(){
CustomerService.getList(this, {}, (me, ok, res) => {
if(ok) me.getRef('refGrid').setData(res.data.list);
});
}
config(){
return {
tagName: 'grid',
ref: 'refGrid',
columns: [
{ key: 'custId', title: '고객코드', width: 100 },
{ key: 'custName', title: '고객명', width: 200 }
]
};
}
}
Va.registerView('/view/customer/CustomerList', CustomerList);
핵심 차이: Nexacro·WebSquare는 XML DSL을 코어로 삼고, VanillaFront는 순수 JavaScript로 완결됩니다. eXBuilder는 상대적으로 표준 웹에 가까운 접근으로 알려져 있으나 정확한 규격은 공식 자료 확인이 필요합니다.
3. 개발 IDE
| 제품 | IDE | 대체 편집기 사용 |
| Nexacro | Nexacro Studio (전용, 필수) | 실질적 불가 |
| WebSquare | WebSquare Studio (전용, 필수) | 실질적 불가 |
| eXBuilder | eXBuilder Designer (전용) — 세부는 공식 자료 확인 | 확인 필요 |
| VanillaFront | VSCode Extension (선택) | VSCode·WebStorm·Vim 등 자유 |
공통점 (상용 3사): 벤더 전용 IDE를 중심으로 개발이 이뤄지며, 라이선스에 IDE 사용권이 포함되고 개발자별 취향 선택 여지가 제한적입니다.
VanillaFront: VSCode를 표준으로 사용하며 Extension은 선택 사항. Copilot, Claude Code, Cursor 등 AI 코딩 도구와 자연스럽게 결합됩니다.
4. IDE ↔ 손코딩 완전 호환성
4.1 상용 3사 공통 이슈
Nexacro Studio
- XFDL 파일에 디자이너 전용 속성 (좌표, 탭 순서 등) 이 삽입됨
- 화면 구조를 손으로 짜는 것은 이론적으로 가능하나 실질적으로 비실용적
- Studio에서 화면 구성, 스크립트만 손코딩하는 워크플로우가 표준
WebSquare Studio
- XML 화면 파일이 verbose하고 수십 개 속성이 나열됨
- Studio 사용이 사실상 표준. 손코딩으로 화면 전체를 관리하는 팀은 드물음
eXBuilder Designer
- Designer 중심 워크플로우로 알려짐
- 손코딩과 Designer의 왕복 자유도는 공식 자료로 확인 필요
- Designer가 관리하는 메타데이터 존재 여부는 제품 세대에 따라 상이할 수 있음 (공식 자료 확인 권장)
4.2 VanillaFront의 차이
VSCode Extension WYSIWYG 에디터가 생성하는 코드가 개발자가 손으로 쓰는 코드와 완전히 동일합니다.
- IDE 전용 메타데이터(GUID, 좌표 등) 파일에 삽입되지 않음
- 시각 편집 결과와 손코딩 결과가 구별 불가능
- 어떤 편집기·AI 도구로도 자유롭게 왕복
5. AI ↔ IDE ↔ 손코딩 3-way 완전 호환
VanillaFront의 가장 결정적 강점 중 하나입니다.
AI 코딩 ←→ IDE (시각 편집) ←→ 손코딩
↓ ↓ ↓
└─────────── 같은 형태의 ES6 클래스 + config 트리 ───────────┘
- AI가 생성한 코드 → VSCode에서 열면 즉시 시각 프리뷰
- 시각 편집기에서 마우스로 수정 → 저장하면 표준 JS 파일
- 손코딩으로 이어서 편집 → 이후 다시 AI에게 후속 요청 가능
- AI 리팩토링 요청 → 결과가 다시 시각 편집·손코딩과 완전 호환
상용 3사에서 이게 어려운 이유:
- Nexacro·WebSquare는 XML DSL이 LLM 학습 데이터에 적어 AI 생성 품질 낮음
- 벤더 IDE와 AI 어시스턴트 (Copilot, Claude Code 등) 통합 제한
- eXBuilder의 AI 통합 현황은 공식 자료·최신 버전 기준 확인 필요
6. AI 개발 워크플로우
6.1 VanillaFront의 AI 이점
이점 1: AI 코드 생성이 자연스러움
- LLM이 순수 JS 객체 트리를 다루는 건 XML DSL·벤더 클래스 시스템보다 예측 가능
- 학습 데이터가 표준 JavaScript라 풍부
- 생성 결과 품질이 일관되게 높음
이점 2: 소량의 명세만으로 완결된 화면 생성
프롬프트 예시:
"고객 관리 화면 만들어줘. 이름, 지역, 가입일 컬럼이 있는 그리드 하나."
AI 생성 결과 (그대로 실행 가능):
import Va from '../../lib/va.js';
export default class CustomerList extends Va.View {
constructor(){ super(arguments); }
mounted(){
this.getRef('refGrid').setData([
{ name:'홍길동', region:'서울', joinDate:'2024-01-15' },
{ name:'김철수', region:'부산', joinDate:'2024-03-22' }
]);
}
config(){
return {
tagName: 'grid',
ref: 'refGrid',
style: { height:'400px', width:'100%' },
columns: [
{ key:'name', title:'이름', width:100 },
{ key:'region', title:'지역', width:100 },
{ key:'joinDate', title:'가입일', type:'date', width:120 }
]
};
}
}
Va.registerView('/view/customer/CustomerList', CustomerList);
VSCode에서 저장하면 즉시 시각 프리뷰가 뜨고, 라우트 방문하면 그대로 동작합니다.
이점 3: 반복 대화형 개발
- "여기에 조회조건 폼 추가해줘"
- "그리드 하단에 페이지네이션 붙여줘"
- "가입일 컬럼을 DatePicker로 편집 가능하게 해줘"
후속 요청이 자연스럽게 이어집니다.
이점 4: VSCode Extension 통합
- AI 생성 → VSCode 저장 → 에디터 영역 즉시 시각 프리뷰
- 마우스 미세 조정 → 파일 자동 저장
- AI ↔ IDE ↔ 손코딩 3축이 한 화면에서 동작
6.2 상용 3사의 AI 통합
- Nexacro·WebSquare: XML DSL이 LLM 학습 데이터에 적음, 각 회사의 노력으로 지원
- eXBuilder: AI 통합 여부·수준은 공식 자료·최신 버전 기준 확인 필요
- 세 제품 모두 벤더 자체 AI 기능 추가 개발 상황이 있을 수 있음 — 최신 로드맵 확인 권장
7. Shadow DOM의 이점
VanillaFront가 Shadow DOM을 프레임워크 표준 격리 방식으로 채택한 것은 실무적으로 큰 이점을 만듭니다.
7.1 무엇을 해결하나
전역 CSS의 오랜 고통
- 컴포넌트 라이브러리 A의 .btn 클래스와 B의 .btn 클래스가 충돌
- 개발자가 정의한 .grid-cell 이 우연히 다른 컴포넌트에 영향
- 특정 스타일 재정의 시 !important 남발
- 여러 프레임워크 얹으면 스타일이 뒤엉킴
이 문제가 20년간 웹 개발의 골칫거리였고, Shadow DOM은 브라우저 표준 차원의 해결책입니다.
7.2 VanillaFront의 Shadow DOM 활용 이점
1. 완전한 CSS 격리
- 컴포넌트 내부 스타일이 밖으로 새지 않음
- 밖의 스타일이 안으로 침투하지 않음
- 전역 CSS 오염·!important 남발 걱정 없음
2. 기존 시스템에 임베드 안전
- 사내 레거시 페이지에 VanillaFront 화면을 iframe 없이 넣어도 스타일 충돌 없음
- 다른 프레임워크로 구축된 페이지에 VanillaFront 컴포넌트 하나만 추가 가능
- 점진적 마이그레이션에 결정적 이점
3. 여러 테마 동시 사용 (추천하지는 않음)
- 한 페이지에 Light 테마 그리드와 Dark 테마 차트를 나란히 배치 가능
- 사용자별 테마 설정을 화면 일부에만 적용 가능
- 22개 테마가 서로 간섭 없이 공존
4. 컴포넌트 재사용성 극대화
- 한 번 만든 컴포넌트를 다른 프로젝트에 그대로 이식 가능
- 스타일 종속성 없이 독립 배포 가능
5. 유지보수성 향상
- CSS 클래스 이름 충돌 걱정 불필요
- 컴포넌트별 스타일을 컴포넌트 파일 안에서 완결 관리
- 리팩토링 시 스타일 부작용 예측 가능
6. 웹 표준 위에 서 있음
- 프레임워크 종속이 아닌 브라우저 표준
- 미래 브라우저 발전과 함께 자동으로 성능·기능 개선 혜택
7.3 상용 3사의 격리 접근
- Nexacro·WebSquare: 전역 CSS 클래스 기반 스타일링. 벤더 네임스페이스 규칙에 의존
- eXBuilder: 격리 방식은 공식 자료 확인 필요
- 공통 이슈: 다른 프레임워크와 같은 페이지에 두면 스타일 충돌 가능성. 여러 테마 동시 사용 제약
8. 런타임과 배포
Nexacro
- XFDL 파일 + 벤더 런타임 엔진 JS 배포
- 브라우저가 엔진 로드 후 XFDL 파싱·렌더링
WebSquare
- XML 화면 파일 + WebSquare 엔진 배포
- 유사한 런타임 로드 과정
eXBuilder
- Designer 산출물 + 런타임 배포로 알려짐
- 세부는 공식 자료 확인
VanillaFront
- ES6 모듈 파일 그대로 배포 (필요할 경우 gulp로 난독화, 압축 가능)
- 브라우저가 <script type="module"> 로 직접 로드
- 별도 런타임 엔진 없음
- 파일 복사만으로 배포
9. 컴포넌트 확장
상용 3사 공통 특성: 벤더 API 규격 안에서 상속·조합. 벤더 컴포넌트 카탈로그가 곧 개발 가능 범위.
VanillaFront: 표준 ES6 클래스 상속으로 커스텀 컴포넌트 정의·등록.
Va.MyComp = class extends Va.Component {
constructor(option) {
super('div', option);
this.tagName = 'myComp';
this.setOption();
}
update() { /* 상태 → DOM 반영 */ }
}
Va.registerComponent('myComp', Va.MyComp);
10. 폐쇄망·사내 인트라넷 지원
상용 3사
- 벤더 라이선스 서버·인증 절차
- 벤더 IDE 설치·배포 승인
- 벤더 도구 기반 배포 파이프라인
- 세부 절차는 각 벤더 정책 확인 필요
VanillaFront
- 파일 복사만으로 배포
- npm·Node 불필요
- 표준 웹 서버 (Nginx, Apache, Spring 정적 리소스) 로 서빙
- VSCode Extension은 선택 사항
11. 학습 곡선과 인력 시장
상용 3사 공통: 벤더 특정 지식이 인력의 핵심 자산. 벤더 특화 개발자 채용 시장 분리.
VanillaFront: 표준 JavaScript ES6 지식이 그대로 활용. 일반 프론트엔드 개발자 인력 풀 그대로 활용 가능. ExtJs개발자의 경우 빠른 학습가능 (JSON에 익숙)
12. 벤더 종속 (Lock-in)
상용 3사 공통 특성
- 벤더 화면 정의(XML/DSL)로 작성된 코드는 벤더 런타임 없이 실행 곤란
- 벤더 컴포넌트 API에 종속
- 벤더 로드맵·릴리스 주기에 의존
VanillaFront
- 표준 JavaScript 코드 — 프레임워크 없이도 가독성·유지보수 가능
- 오픈 표준 (ES6, Shadow DOM, ES Modules) 위에 구축
- 상대적으로 종속도 낮음
13. 가격
| 구분상용 | 3사 | VanillaFront |
| 배포 전용 | 별도 견적 | 250만원 (이미 만들어진 솔루션을 배포만 할경우) |
| 엔터프라이즈 그리드 기능 | 상위 티어 포함 | 기본 포함 |
| 편집기 도구 | 별도 라이선스 (경우에 따라) | Enterprise에 VSCode Extension 포함 |
| 개발 라이선스 | 프로젝트당 수천만 원 규모 | 550만원 (Enterprise + 배포 1개 포함됨) |
VanillaFront는 상용 3사 대비 수분의 일 ~ 십분의 일 수준입니다.
특히 주목할 점:
- 개발 없이 배포만 필요한 경우 250만원 — 이미 개발이 완료된 시스템을 새 서버·도메인에 배포하거나, 특정 환경에만 운영이 필요한 경우
- 550만원 Enterprise 티어에 VSCode Extension 포함 — AI 명세지원(+100만원) 이 가격 안에서 완결
- 엔터프라이즈 기능 (프로존·다중헤더·집계·필터 등) 기본 포함 — 상위 티어 추가 결제 없음
가격 차이가 만드는 실질적 의미:
- 중소 SI·스타트업이 검토조차 못 했던 통합 UI 프레임워크에 진입 가능
- 사내 소규모 팀도 부담 없이 도입 가능
- 개인 개발자·프리랜서 프로젝트에도 활용 가능
- 라이선스 비용 부담을 낮춰 프로젝트 마진 확보
정확한 견적·계약 조건은 각 벤더 공식 안내 기준으로 확인해주세요.
14. 종합 비교표
| 항목 | Nexacro | WebSquaree | XBuilder | VanillaFront |
| 개발 IDE | Nexacro Studio (필수) | WebSquare Studio (필수) | eXBuilder Designer | VSCode + Extension (선택) |
| 런타임 엔진 | 자체 엔진 | 자체 엔진 | 자체 엔진 (공식 확인) | 브라우저 네이티브 |
| IDE ↔ 손코딩 | Studio 중심 | Studio 중심 | Designer 중심 | 완전 자유 |
| AI ↔ IDE ↔ 손코딩 3-way | 제한적 | 제한적 | 공식 확인 | 100% 호환 (실시간 자유롭게 사용) |
| 소량 명세 AI 화면 생성 | 어려움 | 어려움 | 공식 확인 | 즉시 실행 가능 |
| 컴포넌트 격리 | 전역 CSS | 전역 CSS | 공식 확인 | Shadow DOM |
| 컴포넌트 확장 | 벤더 API | 벤더 API | 공식 확인 | 표준 ES6 상속·등록 |
| 빌드 파이프라인 | 벤더 도구 | 벤더 도구 | 벤더 도구 | 없음 (No-Build) |
| 폐쇄망 배포 | 벤더 인프라 | 벤더 인프라 | 벤더 인프라 | 파일 복사만으로 |
| 개발자 학습 | 벤더 DSL | 벤더 DSL | 벤더 규격 | 표준 ES6 |
| 인력 채용 | 벤더 특화 | 벤더 특화 | 벤더 특화 | 일반 프론트엔드 |
| 벤더 종속 | 높음 | 높음 | 높음 | 낮음 |
| 개발 라이선스 | 수천만 원 | 수천만 원 | 수천만 원 | 550만원 |
| 배포 라이선스 | 별도 견적 | 별도 견적 | 별도 견적 | 250만원 |
| 화면 정의 | XFDL (XML) | XForms + w2:XML | HTML+JS 기반 (공식 확인) | 순수 JSON |
주석: eXBuilder 관련 "공식 확인" 표시된 항목은 제품 세부 규격 파악이 부족해 서술을 유보한 부분입니다. 게시 전 공식 자료·제품 문서 대조 권장.
15. 어떤 팀에게 무엇이 맞나
Nexacro가 잘 맞는 경우
- 대형 금융·공공 프로젝트
- Nexacro 실적·경험자를 보유한 팀
- XPlatform/MiPlatform 계보 시스템 유지·확장
WebSquare가 잘 맞는 경우
- 국내 대기업·공공 SI 프로젝트
- WebSquare 실적·경험자를 보유한 팀
- 기존 WebSquare 시스템 유지·확장
eXBuilder가 잘 맞는 경우
- 토마토시스템 제품군을 이미 사용 중인 조직
- Designer 기반 워크플로우가 팀 문화에 맞는 경우
- (세부 판단 기준은 공식 자료 참조)
VanillaFront가 잘 맞는 경우
- 중소 SI·스타트업·사내 개발팀
- 모던 JavaScript 표준으로 개발하고 싶은 팀
- 그리드·폼·차트 중심의 관리자 페이지·사내 시스템·대시보드
- 빌드 파이프라인 없이 즉시 개발·배포하고 싶은 프로젝트
- AI 개발 워크플로우를 실무에 통합하고 싶은 팀
- AI + IDE + 손코딩을 자유롭게 왕복하고 싶은 팀
- 표준 JS 개발자 인력 풀을 활용하고 싶은 조직
- 벤더 종속을 낮추고 싶은 조직
- 사내 인트라넷·폐쇄망 환경에서 최소 인프라로 운영
- 라이선스 비용 부담을 낮추고 싶은 조직
- Shadow DOM 기반 격리로 다른 시스템·프레임워크와 공존이 필요한 프로젝트
16. 정리
상용 3사와 VanillaFront는 서로 대체 관계가 아니라 각자 잘 맞는 자리가 다릅니다.
- 상용 제품의 접근: 벤더가 통합 환경(IDE + 런타임 + 컴포넌트 + DSL)을 완전히 제공하고, 안정성·지원·실적 축적을 보장
- VanillaFront의 접근: 모던 웹 표준(ES6, Shadow DOM, Dynamic Import)을 직접 활용하고, 표준 개발자 도구·인력·워크플로우와 자연스럽게 결합. AI ↔ IDE ↔ 손코딩 3-way 완전 호환이라는 시대적 이점을 얹었습니다.
두 접근 모두 유효하고, 각자 잘 맞는 프로젝트가 다릅니다.