프롬프트 한 줄이 dev server 를 띄운다
프롬프트 한 줄이 dev server 를 띄운다
Stitch 는 이미지를 만든다. Figma AI 는 아트보드를 만든다. v0.dev 는 스니펫을 만든다. VibeSynth 는 ~/VibeSynth/projects/ 에 실제 프로젝트 폴더를 만들고, 그걸 vite dev 로 띄우고, 옆 윈도우에 라이브로 렌더링한다.
이미지와 실행 사이의 간격
"AI 로 UI 를 만든다" 는 툴이 폭발적으로 늘었지만, 대부분의 결과물은 여전히 정적 입니다.
Google Stitch — HTML 로 export 되는 디자인 이미지. 로직은 없음
Figma AI, Galileo — Figma 프레임, 아트보드. 개발자가 다시 구현해야 함
v0.dev — Next.js 컴포넌트 스니펫. 프로젝트 구조는 사용자가 만듦
lovable.dev — 클라우드 호스팅된 full 앱, 하지만 로컬 개발 환경 밖에 격리됨
공통점은 하나입니다. "디자인을 보는 창" 과 "앱을 실행하는 창" 이 분리되어 있습니다. 디자이너는 이미지를 보고, 개발자는 그 이미지를 다시 코드로 옮긴 뒤 따로 돌려봅니다. 이 간격 사이에서 많은 것이 사라집니다. 반응형 동작, 상태 변화, 실제 여백 감각, 마찰 지점.
VibeSynth 는 이 간격을 닫는 걸 설계 목표로 삼았습니다. 프롬프트 한 줄을 쓰면 같은 디스크 위에 실제 React 프로젝트가 생성 되고, Vite dev server 가 즉시 구동 되고, 팝업 윈도우가 그 localhost 에 붙어 라이브로 렌더링 됩니다. 보고 있는 것이 곧 빌드 결과물입니다. 디자이너가 프롬프트를 수정하면 HMR 이 100ms 안에 반영됩니다.
이 글은 VibeSynth 의 두 가지 핵심 설계를 설명합니다.
두-윈도우 모델 + Stitch-호환 디자인 시스템 — 왜 이 구조인가
banya-cli 코드 생성 파이프라인 — 왜 Gemini 를 직접 부르지 않는가
1. 두 개의 윈도우: 캔버스와 라이브
VibeSynth 는 Electron 앱이지만 구조가 특이합니다. 창이 두 개 이고, 각각 다른 역할을 합니다.
메인 캔버스 윈도우
electron/main.ts 의 primary window:
크기: 1400×900 (풀스크린 모드 지원), 최소 900×600
macOS titleBarStyle: 'hiddenInset'
내용: 디자인 캔버스, 프롬프트 바, 디자인 시스템 카드, Agent Log
라이브 앱 팝업 윈도우
이게 결정적 선택입니다. 라이브 프리뷰가 메인 윈도우의 sidebar 가 아니라 별도 BrowserWindow 입니다.
듀얼 모니터 사용자가 한 모니터엔 캔버스, 다른 모니터엔 앱 을 띄울 수 있음
디바이스 프레임 전환이 자연스러움 (iPhone, iPad, Desktop)
창 크기를 사용자가 자유롭게 드래그 → 반응형 테스트가 "진짜 창 크기 변경" 으로 일어남
DevTools 별도 토글 (Console / Network / Elements)
Vite dev server 는 Electron 바깥에서 별도 node 프로세스 로 돕니다. 결과적으로 — VibeSynth 가 렌더링하는 것이 아니라, 진짜 Vite + React 런타임이 렌더링하는 것 을 보여주는 구조입니다.
2. Stitch-호환 디자인 시스템 — 왜 자유도를 일부러 제약했는가
LLM 에게 "예쁜 UI 를 만들어" 라고 하면 매번 다른 디자인 토큰이 나옵니다. VibeSynth 는 이 문제를 Stitch 의 디자인 시스템을 그대로 도입 해서 풉니다.
4 역할 × 12 톤
colors: {
primary: { base: string; tones: string[12] } // T0~T100
secondary: { base: string; tones: string[12] }
tertiary: { base: string; tones: string[12] }
neutral: { base: string; tones: string[12] }
}
Material Design 3 호환 톤 스케일. LLM 이 48개의 hex 값 만 결정하면 되고, 그 이후로는 모든 컴포넌트가 이 팔레트의 조합으로 그려집니다.
13개 Pinterest-inspired 추천 디자인
레퍼런스
분위기
Ornate Quartz
dark, tech
Finance Oasis
dark, premium
Clean SaaS
minimal, professional
Airy Mint
fresh, calm
3. 코드 생성 엔진 — banya-cli 를 거치는 이유
VibeSynth 는 Gemini API 를 직접 호출하지 않고, banya-cli 를 자식 프로세스로 spawn 합니다.
banya run \
--prompt-file <tmpPrompt> \
--workspace <project-dir> \
--llm-backend gemini \
--auto-approve=true
이유는 명확합니다. LLM 의 단일 응답 출력 토큰 한계 를 우회하기 위해서입니다. banya-cli 는 Multi-turn Agent 모드 로 작동하며, 여러 번의 대화를 통해 실제 디스크에 수십 개의 파일을 직접 생성하고 수정합니다.
Pre-Scaffold 패턴
VibeSynth 는 package.json , vite.config.ts 같은 결정론적인 빌드 설정 파일을 미리 작성해둡니다. LLM 은 오직 UI 컴포넌트와 비즈니스 로직 에만 집중할 수 있게 하여 생성 성공률을 극대화합니다.
4. Live Editor — 디자이너와 개발자의 관점 차이
같은 라이브 편집 요청이라도 사용자의 역할에 따라 다르게 보여줍니다.
Designer 모드 : "주황 계열 톤을 더 부드럽게 조정했습니다" (자연어 설명)
Developer 모드 : 실제 Diff 블록 및 코드 변경 사항
5. 설계의 요약
결정
얻는 것
두-윈도우 모델
듀얼 모니터 활용, 실제 브라우저 환경 테스트
별도 프로세스 Vite server
HMR(Hot Module Replacement) 무결성 유지
디자인 시스템 제약
멀티스크린 앱의 시각적 일관성 확보
banya-cli 활용
토큰 한계 극복, 실제 파일 시스템 기반의 풀 앱 구축
닫으며
AI UI 툴의 다음 단계는 "이미지를 만드는 것" 에서 "실행되는 것을 만드는 것" 으로의 이동입니다. VibeSynth 는 프롬프트와 실제 실행 환경 사이의 장벽을 허무는 실험입니다. 이제 프롬프트를 쓴 다음 줄에서 앱이 돕니다.
참고 링크
VibeSynth 저장소: kr-ai-dev-association/vibesynth
banya-cli: DAIOSFoundation/banya-cli