한눈에 보기
- 한 줄 정의: Anthropic 의 Claude Design을 대체하기 위해 기획된 오픈소스 프로젝트로서, 자체 모델을 띄우지 않고, 사용자의 로컬에 설치된 코딩 에이전트를 호출해 디자인 산출물을 생성하는 Web - Local - Demon 아키텍처
- 핵심 흐름: 웹 UI (Prompt) → 로컬 데몬(Express API/SSE) → 에이전트 CLI 서브프로세스 실행 → 결과물 파싱 및 iframe 렌더링
- 차별점: 'AI 슬롭(AI Slop, 공장형 저품질 결과물)'을 막기 위해 파일 기반의 시스템 규칙 (Skill, Design System)을 강제 주입하여 LLM의 출력을 통제
- 현재 상태: 2026년 5월 4일 기준 main 브랜치, 기준 커밋 4de93fe, 최신 릴리스 open-design-v0.3.0
- 도입 전 체크리스트 (운영 리스크): 에이전트 CLI의 권한 우회 (Auto-approval) 플래그 사용으로 인한 로컬 보안 리스크, Windows/WSL 환경에서의 CLI 인지 파싱 에러, Node 24 및 pnpm 10.33 의 엄격한 버전 의존성
서론: AI 생성 UI 의 '제어권' 문제
최근 LLM을 활용한 프론트엔드 UI 생성이 대중화되었지만, 실무 레벨에서는 톤앤매너 불일치, 컴포넌트 규격 무시 등 퀄리티 컨트롤의 한계에 직면한다. 모델이 예쁜 첫 화면을 만들 수는 있어도, 브랜드 색상과 글꼴을 지키고, 슬라이드나 모바일 화면처럼 정해진 형식을 맞추고, 결과물을 파일로 저장해 계속 고치는 흐름은 아직 매끄럽지 않기 때문이다.
nexu-io/open-design은 "새로운 디자인 특화 모델을 만들자"는 접근을 버리고, "이미 개발자가 터미널에서 쓰고 있는 강력한 코딩 에이전트 CLI를 디자인 런타임으로 활용하자"는 실용적인 아키텍처를 취한다. 사용자가 Claude Code, Codex CLI, Cursor Agent, Gemini CLI 같은 도구를 이미 설치했다면, open-design은 그 도구를 직접 실행하고 결과 파일을 웹 UI에 보여 주는 형태가 된다.
사용자가 웹 UI에서 요청을 보내면, 백그라운드의 로컬 데몬이 에이전트를 실행하고 결과물을 파일 시스템에 기록한 뒤 웹으로 스트리밍한다.
Claude Design이 클라우드 제품이라면, open-design은 로컬에서 실행되는 웹 앱과 데몬을 중심으로 움직인다. 사용자는 브라우저에서 요청을 보내고, 데몬은 로컬 파일과 에이전트 CLI를 다룹니다.
이 글에서는 저장소의 핵심 Typescript 코드를 분석하여, 시스템이 LLM의 출력을 어떻게 통제하는지, 그리고 엔터프라이즈 환경 도입 시 어떤 리스크가 있는지 파악한다.
1. 아키텍처 흐름 및 핵심 모듈 (Hotspots)
open-design는 모노레포(Monorepo) 구조로, 크게 사용자가 조작하는 React 웹 앱(apps/web) 과 에이전트를 제어하는 Node.js 데몬(apps/daemon) 으로 나뉜다. 웹 앱은 사용자가 보는 화면, 입력 폼, 채팅, 파일 탭, 미리보기 등을 제공하고. 로컬 데몬은 실제로 파일을 만들고, 에이전트 CLI를 실행하고, 프로젝트 DB를 관리하고, 결과를 다시 웹 앱으로 스트리밍한다.
- 사용자 브리프: 만들고 싶은 웹 화면, 덱, 모바일 앱, 이미지, 영상 요청
- 웹 앱: apps/web의 React UI가 프로젝트, 스킬, 디자인 시스템, 채팅 상태를 관리
- 로컬 데몬: apps/daemon/src/server.ts가 REST API와 SSE 스트림을 제공
- 에이전트 실행: apps/daemon/src/agents.ts가 설치된 CLI를 찾아 실행 인자를 구성
- 스킬 주입: skills 폴더의 SKILL.md를 읽어 작업 방식과 체크리스트를 전달
- 디자인 시스템 주입: design-systems 폴더의 DESIGN.md를 읽어 색상과 타이포 규칙을 전달
- 산출물 저장: .od/projects 아래에 실제 HTML, Markdown, 이미지, 영상 파일을 저장
- 미리보기: 웹 앱이 파일을 iframe 또는 전용 렌더러로 보여 줌
여기서 중요한 점은 open-design이 에이전트 루프를 직접 다시 만들지 않는다는 것이다. Claude Code가 파일을 읽고 쓰는 방식, Codex가 명령을 실행하는 방식, Cursor Agent가 workspace를 다루는 방식은 각 CLI가 담당한다. open-design은 그 위에서 "어떤 스킬을 줄지", "어떤 디자인 시스템을 줄지", "어느 폴더에서 실행할지", "출력을 어떻게 미리보기로 보여 줄지"를 조율한다.
A. apps/daemon/src/server.ts: API 게이트웨이 및 데몬
로컬에서 Express 서버를 띄워 웹 앱과 통신한다.
- 설계 특징: 프로젝트 CRUD, 파일 업로드, 에이전트 탐지, 미디어 생성, 배포(Vercel) 등 대부분의 비즈니스 로직 경로를 제공하는 모놀리식(Monolithic) 엔드포인트다. 생성 과정은 SSE(Server-Sent Events) 스트림을 통해 클라이언트에 실시간으로 전달된다.
- 기술 부채: 기능이 빠르게 추가되면서 라우팅, 프록시, 파일 I/O 로직이 한 파일에 과도하게 집중되어 있다. 보안 및 실행 경계 분리를 위한 리팩토링이 필요한 상태다.
B. apps/daemon/src/agents.ts: CLI 어댑터 패턴
이 프로젝트의 가장 핵심적인 설계다. 자체 LLM 연동 로직을 짜지 않고, 사용자의 PATH에 설치된 CLI(Claude Code, Codex, Cursor Agent, Gemini CLI 등)를 탐지해 서브프로세스로 실행한다.
- 리스크 포인트 (보안): 웹 UI에서 터미널 승인 프롬프트(Y/N)를 처리할 수 없기 때문에, CLI 실행 시 --permission-mode bypassPermissions (Claude Code), --dangerously-skip-permissions (OpenCode) 같은 자동 승인(Auto-approval) 플래그를 강제로 주입한다. 샌드박싱이 안 된 환경에서 LLM이 로컬 파일 시스템을 마음대로 조작할 수 있는 심각한 보안 홀이 될 수 있다.
C. apps/daemon/src/skills.ts & design-systems.ts: 파일 기반 컨텍스트 주입
LLM의 환각(Hallucination)과 디자인 일관성 붕괴를 막기 위해 RAG와 유사한 파일 기반 규칙을 프롬프트에 주입한다.
- skills 폴더의 SKILL.md (예: 랜딩 페이지, 대시보드 제작 지침)와 design-systems 폴더의 DESIGN.md (색상, 글꼴 토큰)의 Frontmatter와 본문을 파싱하여 CLI의 초기 컨텍스트로 전달한다.
- 코드가 아닌 마크다운 파일 기반이므로 플랫폼 엔지니어링 팀이 사내 UI 컴포넌트 표준을 쉽게 주입하고 배포할 수 있는 뛰어난 확장성을 제공한다.
D. apps/web/src/artifacts/parser.ts: 스트림 파서 및 렌더러
에이전트가 뱉어내는 텍스트 스트림에서 <artifact> 태그를 실시간으로 파싱한다.
- 파일의 매니페스트와 확장자에 따라 HTML(iframe 격리), React Component, Markdown, SVG 등 전용 렌더러로 분기 처리하여 사용자에게 실시간 미리보기를 제공한다. 모델이 이 태그 형식을 이탈하면 UI가 깨지는 취약점이 있다 (관련 이슈 #312).
2. AI 슬롭을 줄이기 위한 제어 장치
open-design의 가장 흥미로운 부분은 "모델에게 디자인을 맡긴다"에서 끝나지 않는다는 점이다. 많은 AI 디자인 도구가 첫 화면은 화려하게 만들지만, 시간이 지나면 비슷한 보라색 그라데이션, 과장된 수치, 의미 없는 아이콘, 브랜드와 맞지 않는 글꼴을 반복한다. 업계에서는 이런 저품질 생성물을 AI 슬롭이라고 부른다.
open-design은 이 문제를 줄이기 위해 사전 질문, 시각 방향, 스킬, 디자인 시스템, 체크리스트, lint를 겹겹이 두어, 모델에게 빈 캔버스를 던지는 대신, 먼저 작업 brief를 확정하고, 쓸 수 있는 색과 글꼴을 고정하고, 산출 전 자기검토를 강제하는 구조를 가지고 있다.
- Turn-1 Discovery Form: 첫 턴에서 바로 코드를 만들지 않고 대상 독자, 톤, 브랜드 맥락, 규모, 제약을 묻는 구조화 폼
- Visual Direction: Editorial Monocle, Modern Minimal, Warm Soft, Tech Utility, Brutalist Experimental 같은 5가지 시각 방향
- OKLch 팔레트: 사람이 느끼는 색 차이를 더 균일하게 다루는 색상 체계로, 모델이 색을 즉흥적으로 고르는 문제를 줄이는 장치
- TodoWrite 진행 카드: 에이전트가 할 일을 UI에 실시간으로 보여 주는 계획 카드
- 5차원 자기비판: 철학, 위계, 세부 실행, 기능, 혁신성을 기준으로 결과를 다시 보는 절차
- P0/P1/P2 체크리스트: 반드시 고쳐야 할 문제, 고치는 편이 좋은 문제, 있으면 좋은 개선을 구분하는 품질 기준
- Artifact lint: 산출물의 구조, 색상 토큰, 흔한 AI풍 패턴, 외부 이미지 URL 등을 검사하는 API
open-design이 단순한 CLI 래퍼(Wrapper)를 넘어 디자인 도구로 기능하는 이유는 LLM의 결과물을 제어하는 다중 안전장치에 있다.
- OKLch 팔레트 강제: HEX나 RGB 대신 인간의 시각적 인지에 균일한 OKLch 색상 체계를 프롬프트에 강제하여 모델이 즉흥적으로 어색한 컬러를 선택하는 것을 막는다.
- 5차원 자기비판(Self-Critique): 에이전트가 코드를 작성한 후 '철학, 위계, 세부 실행, 기능, 혁신성'의 5가지 기준으로 스스로 코드를 리뷰하고 수정하도록 루프를 강제한다.
- Artifact Linting API: 산출물의 구조, 흔한 AI 디자인 패턴(보라색 그라데이션 남용 등), 외부 이미지 무단 참조 등을 검사하는 자체 Lint API를 거친다.
3. 실행 검증 가이드 (개발 환경 기준)
아래 예시는 문서와 소스 기준으로 재구성한 실행 방법이다. 이 글 작성 환경에서는 저장소 의존성을 설치해 앱을 띄우지는 않았으므로, 실제와 다를 수 있다.
빠른 시작: 로컬 웹 앱과 데몬 띄우기
QUICKSTART 기준 기본 실행은 Node 24와 pnpm 10.33을 전제로 진행
git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable
pnpm install
pnpm tools-dev run web
- 목적: 로컬 데몬과 Next.js 웹 앱을 함께 실행
- 기대 결과: tools-dev가 웹 URL과 daemon 상태를 출력
- 흔한 실패 지점: Node 24 미사용, pnpm 버전 불일치, native dependency 설치 실패
- 운영 메모: package.json은 Node ~24, pnpm 10.33.2를 명시
첫 사용: 에이전트 CLI 확인
웹 앱이 뜨면 데몬은 사용자의 PATH에서 코딩 에이전트 CLI를 찾습니다. 먼저 API로 탐지 결과를 확인할 수 있다
curl -s http://127.0.0.1:7456/api/health
curl -s http://127.0.0.1:7456/api/agents
- 목적: 데몬이 살아 있는지, 어떤 에이전트가 감지됐는지 확인
- 기대 결과: Claude Code, Codex, Cursor Agent 등 설치된 CLI가 available 상태로 표시
- 흔한 실패 지점: GUI 앱과 터미널의 PATH 차이, CLI 인증 만료, Windows 실행 경로
- 운영 메모: apps/daemon/src/agents.ts는 Homebrew, nvm, fnm, mise, Volta 경로도 보조로 탐색
실전 예제: 스킬과 디자인 시스템을 골라 생성하기
웹 UI에서는 왼쪽 패널에서 Skill과 Design system을 고른 뒤 요청을 보낸다.
Skill: saas-landing
Design system: Vercel
Prompt: AI 코딩 도구 스타트업의 투자자용 랜딩 페이지를 만들어줘.
- 목적: 특정 화면 유형과 브랜드 규칙을 묶어 한 번에 산출물 생성
- 기대 결과: 에이전트가 프로젝트 폴더에 HTML 파일을 만들고, 웹 앱이 미리보기로 표시
- 흔한 실패 지점: 에이전트가 artifact 태그를 지키지 않거나, 스킬 side file을 못 읽는 경우
- 해석 메모: 좋은 결과는 모델 능력뿐 아니라 스킬과 디자인 시스템 품질에 크게 좌우
실전 예제: 미디어 생성 경로 점검
미디어 기능은 에이전트가 로컬 od media generate 명령을 호출하는 방식으로 설계되어 있다. 실제 사용 전에는 provider 설정을 먼저 확인해야 한다.
curl -s http://127.0.0.1:7456/api/media/models
curl -s http://127.0.0.1:7456/api/media/config
- 목적: 이미지, 영상, 오디오 모델 목록과 API 키 설정 상태 확인
- 기대 결과: gpt-image 계열, Seedance 계열, HyperFrames 계열 등 표면별 모델 확인
- 흔한 실패 지점: API 키 미설정, provider별 baseUrl 오류, 미디어 stub 비활성화
- 운영 메모: 릴리스 빌드에서는 stub 결과를 성공처럼 보이지 않도록 막는 코드가 보임
한계 확인 예제: Windows와 CLI 프롬프트 전달
공개 이슈를 보면 Windows와 CLI 인자 전달 문제가 실제로 중요하다. Issue #380은 Codex CLI에서 예상치 못한 대시 인자 오류를 보고했고, Issue #367은 Copilot CLI에서 stdin EOF 문제를 보고했다.
pnpm tools-dev check
curl -s http://127.0.0.1:7456/api/agents
- 목적: 로컬 런타임 로그와 에이전트 감지 상태 확인
- 기대 결과: CLI별 경로, 인증 상태, 최근 에러 로그 확인
- 흔한 실패 지점: Windows native, 긴 프롬프트, CLI 버전별 인자 차이
- 해석 메모: WSL2가 더 안전한 기준이라고 QUICKSTART가 명시
4. 프로덕션 도입 시 리스크 및 트러블 슈팅
open-design은 저장소 성장 속도가 매우 빠르다. 프로제트도 아주 훌륭하지만 기업 내 개발자 플랫폼이나 팀 단위 도구로 도입하기 전 다음의 리스크를 반드시 해결해야 한다.
- 개발자 관점: 로컬 CLI와 API 키를 이미 다루므로 설치 이후 확장성이 큼
- 비개발자 관점: Node 24, pnpm 10.33, WSL2, CLI 인증이 모두 부담
- Windows 관점: native Windows 이슈가 계속 보고되어 WSL2 기준 검증이 더 안전
- 기업 관점: 편의성보다 권한, 로그, API 키, 내부망 접근 통제가 먼저
| 리스크 | 근거 | 영향 | 확인 방법 |
|---|---|---|---|
| Node 24 고정 | package engines와 QUICKSTART | 기존 Node 20 환경과 충돌 | nvm 또는 fnm으로 별도 환경 |
| 문서 수치 drift | README와 실제 파일 수 차이 | 기능 범위 오해 | CHANGELOG와 코드 기준 재확인 |
| 자동 승인 플래그 | **agents.ts**의 CLI 실행 인자 | 파일과 명령 권한 확대 | 사내 정책과 sandbox 검증 |
| Windows CLI 이슈 | Issue #383, #367, #380 | 에이전트 실행 실패 | Windows와 WSL2 각각 테스트 |
| CLI 호환성 이슈 | Issue #386, #389, #413 | Copilot, Codex, DeepSeek 경로 실패 | 에이전트별 smoke test |
| 질문 폼 raw text | Issue #312 | 첫 사용 UX 손상 | API fallback 경로 smoke test |
| 데스크톱 패키징 | Issue #416 | prompt template 누락 | 설치본과 소스 실행본 비교 |
| 외부 API 프록시 | baseUrl과 apiKey 전달 | SSRF와 키 관리 위험 | DNS, 프록시, allowlist 검증 |
| 미디어 과금 | 여러 이미지/영상 모델 | 비용 예측 어려움 | provider별 quota와 로그 확인 |
1) 런타임 종속성 및 Windows 환경 에러
- package.json 상 Node 버전을 ~24, pnpm을 10.33.2로 강력하게 강제한다. 기존 프로젝트 생태계(주로 Node 18~20)와 충돌할 수 있으므로 nvm, fnm 등을 통한 격리가 필수다.
- Windows 네이티브 환경에서 CLI를 서브프로세스로 실행할 때, 긴 프롬프트 문자열 처리 한계나 stdin EOF 이슈(Issue #367, #380)가 지속적으로 보고되고 있다. 프로덕션 적용 시 WSL2 환경 사용을 표준으로 강제해야 한다.
2) 로컬 보안 통제 부재 (Auto-Approval Risk)
- 앞서 언급했듯, 에이전트 CLI를 Non-interactive 모드로 강제 실행하기 위해 보안 프롬프트를 무력화시킨다. 사내망에서 사용할 경우, 악의적인 프롬프트 인젝션이나 할루시네이션으로 인해 로컬 .env 파일 유출, 소스코드 임의 삭제 등의 사고가 발생할 수 있다. 반드시 접근 권한이 통제된 디렉토리 워크스페이스 내부에서만 실행되도록 호스트 OS 레벨의 권한 제어가 필요하다.
3) 외부 API 프록시 (SSRF 취약점 검토 필요)
- server.ts에 구현된 외부 API(OpenAI, Anthropic) 프록시는 localhost, 10.x, 192.168.x 등의 로컬 IP 대역 접근을 문자열 기반으로 차단하고 있다. 하지만 DNS 바인딩 우회 등 정교한 SSRF 공격에는 취약할 수 있으므로, BYOK(Bring Your Own Key) 모델을 쓸 때는 사내 프록시나 방화벽 룰과 병행 검증해야 한다.
4) 문서 파편화 (Documentation Drift)
- README에서는 31개의 스킬과 129개의 디자인 시스템을 제공한다고 명시하나, 실제 트리 저장소를 확인하면 SKILL.md 59개, DESIGN.md 137개로 수치가 맞지 않는다. 버전업 속도가 너무 빨라 문서가 코드를 따라가지 못하는 상태이므로, 도입 시 반드시 실제 소스코드와 CHANGELOG를 기준으로 기능을 판단해야 한다.
5. AI 디자인 산출물의 실제 의미
AI 디자인 자동화의 가치는 "예쁜 화면을 빨리 만든다"만으로 설명되지 않는다. 실제 조직에서 디자인 산출물은 종종 노력의 신호이기도 하다. 투자자용 덱, 임원 보고서, 고객 제안서가 정교해 보이는 이유는 단지 보기 좋아서가 아니라, 작성자가 시간을 들여 논리를 정리했다는 신호를 보내기 때문이다.
AI가 몇 초 만에 멋진 덱과 화면을 만들 수 있게 되어 누구나 비슷하게 그럴듯한 화면을 만들면, 시각적 완성도는 차별점이 아니라 당연한 것이 된다. 이때 중요한 것은 디자인의 겉모습이 아니라, 메시지의 정확성, 데이터의 신뢰도, 사용자의 문제를 제대로 이해했는지가 중요한 척도가 된다.
그래서 open-design 같은 도구는 원샷 생성기보다 초안 정리와 시각화 도구로 보는 편이 현실적이다. 사람이 먼저 문제, 구조, 핵심 메시지를 정리하고, open-design이 이를 웹 화면이나 덱으로 빠르게 바꾸는 흐름이 더 안전하다. 반대로 사람이 내용을 이해하지 않은 채 AI에게 긴 문서와 슬라이드를 대량 생성하게 하면, 시간만 낭비하게 될 것이다.
6. 서비스로서의 의미
open-design을 서비스 관점에서 보면, 이 프로젝트는 "AI가 디자인을 대신한다"보다 "디자인 산출물 생산 라인을 로컬에 만든다"에 가깝다. 웹 앱은 작업대이고, 스킬은 공정표이며, 디자인 시스템은 브랜드 규격서입니다. 에이전트 CLI는 실제 작업자이다.
가장 현실적인 제품화 방향은 사내 디자인 생성 포털이다. 회사가 표준 디자인 시스템을 DESIGN.md로 구축해 두고, 자주 쓰는 랜딩 페이지, 제안서, 제품 소개 슬라이드, 대시보드 목업 등을 '스킬(Skill)'로 묶어둔다. 개발자와 PM은 웹 UI에서 브리프(Brief)만 입력하면, 로컬 에이전트가 알아서 사내 규칙에 맞는 초안을 만들어낸다.
두 번째 방향은 에이전트 번들 플랫폼이다. open-design은 Claude Code 전용 도구가 아니다. Codex, Cursor, Gemini, OpenCode 등 다양한 CLI를 탐지하고 스위칭할 수 있게 설계되어 있다. 기업 입장에서는 특정 AI 벤더 모델에 락인(Lock-in)되지 않고, 팀별로 선호하는 에이전트를 유지하면서도 동일한 디자인 작업대(Workspace)를 공유할 수 있다.
세 번째 방향은 템플릿 및 스킬 생태계 구축이다. HTML PPT, guizang-ppt, HyperFrames, awesome-design-skills 같은 외부 프로젝트를 가져오는 흐름이 이미 README와 소스코드 곳곳에 드러나 있다. 장기적으로는 "검증된 디자인 스킬을 사고파는 마켓플레이스"로 확장할 여지가 크다. 다만 이 단계로 가려면 악의적인 코드를 막기 위한 스킬 보안, 라이선스 검증, 품질 테스트, 미리보기 샌드박스(Preview Sandbox) 통제가 핵심 과제가 될 것이다
8. 대안 솔루션과 비교하면
open-design은 일반적인 노코드 디자인 도구와 같은 위치에 놓기 어렵습니다. 더 정확히는 디자인 도구, AI 코딩 에이전트, 로컬 개발자 플랫폼의 교차점에 있습니다.
| 비교 대상 | 문제 정의 | 강점 | 주의점 |
|---|---|---|---|
| open-design | 로컬 에이전트로 디자인 산출물 생성 | BYO CLI, 스킬, 디자인 시스템 | 초기 제품, CLI 호환성 리스크 |
| Claude Design | 클라우드에서 디자인 artifact 생성 | Claude와 제품 경험 통합 | 폐쇄형, Anthropic 중심 |
| Huashu Design | 터미널 중심 디자인 스킬 | CLI 친화적, 철학적 지침 강함 | GUI 미리보기와 편집 경험은 제한 |
| v0 | 자연어로 UI와 코드 생성 | Vercel 배포와 프론트엔드 코드 연결 | React와 Vercel 생태계 의존 |
프론트엔드 코드가 목적이면 v0가 더 직접적인 선택이 된다. Vercel 문서는 v0를 자연어로 아이디어를 설명하면 코드와 UI를 생성하고 Vercel에 배포할 수 있는 도구로 설명한다. 반대로 open-design은 React 컴포넌트 하나를 잘 뽑는 도구라기보다, 웹 화면, 모바일 mockup, 덱, Markdown, HTML, ZIP 같은 여러 산출물을 작업 공간 안에서 다루는 쪽에 가깝다. 전문 디자인팀은 또 다른 선택지가 있다.
| 도구 | 잘 맞는 상황 | open-design과의 차이 |
|---|---|---|
| Figma Make | Figma 안에서 prompt-to-app 초안과 코드 편집 | 기존 Figma 협업 흐름과 더 가까움 |
| Google Stitch | 자연어, 음성, 스케치 기반 UI 아이디어 탐색 | Google Labs 기반 AI 디자인 캔버스 |
| Magic Patterns | 제품팀의 인터랙티브 프로토타입과 Figma export | 팀 협업, GitHub sync, MCP 연동 강조 |
| Penpot | 오픈소스 디자인 협업과 self-host | AI 에이전트보다 디자인 툴 자체가 중심 |
Figma Make는 이미 Figma 중심으로 일하는 팀에게 자연스럽다. 팀의 컴포넌트, 토큰, 디자인 파일이 Figma에 모여 있다면, AI도 그 안에서 활용하는 편이 관리하기 훨씬 쉽다. Google Stitch는 Google Labs가 설명하는 AI 네이티브 디자인 캔버스에 가깝고, Magic Patterns는 제품팀의 프로토타입 생성, Figma Export, GitHub Sync, MCP 연동을 강조한다. 반면 Penpot은 AI 생성 기능보다는 오픈소스 디자인 협업과 셀프 호스팅(Self-hosting)이 핵심이다.
순수하게 코딩 보조가 목적이라면 굳이 open-design을 거칠 필요 없이 Codex CLI, Gemini CLI, Cline 같은 도구를 직접 쓰는 편이 낫다. Codex CLI는 로컬에서 파일을 읽고 수정하며, 승인 모드에 따라 자동 실행 범위를 조절할 수 있다. Cline은 VS Code 내부에 통합되어 코드를 읽고 명령을 실행하는 오픈소스 에이전트다. 즉, open-design은 코딩 에이전트를 대체하는 툴이 아니라, 기존 에이전트들을 '디자인 산출물 생산 파이프라인'으로 연결해 주는 인터페이스(Surface) 역할을 한다.
다른 툴들과 비교할 때 핵심은 "누가 에이전트 루프(Agent Loop)의 제어권을 갖는가"다. Claude Design은 Anthropic이 기반 모델과 제품을 모두 통제한다. Huashu Design은 터미널과 스킬을 중심으로 디자인 철학을 주입하는 성격이 강하다. 반면 open-design은 사용자가 로컬에 설치해 둔 기존 CLI를 그대로 호출한다. 이 아키텍처 덕분에 유연성은 극대화되지만, 반대급부로 각 CLI의 버전, 인증 상태, OS 권한, 출력 스트림 형식에 시스템 안정성이 크게 휘둘린다는 엔지니어링 리스크가 동반된다.
순수 디자인 퀄리티만 놓고 보면 Figma 같은 전문 디자인 툴과 직접 경쟁하는 구도는 아니다. open-design은 픽셀 단위로 조작하는 벡터 그래픽 편집기를 지향하는 프로젝트가 아니기 때문이다. 그 대신 "디자인 산출물을 코드(HTML/React 등)로 빠르게 찍어내고, 웹 기반 UI에서 즉시 미리보기를 한 뒤, 에이전트에게 피드백을 주어 코드를 다시 수정하게 만드는 빠른 이터레이션(Iteration) 흐름"을 로컬에 구축하는 데 압도적인 강점이 있다.
결론
open-design은 AI 디자인 도구를 보는 관점을 조금 바꿉니다. 더 좋은 모델 하나를 붙이면 끝나는 문제가 아니라, 스킬, 디자인 시스템, 로컬 파일, 미리보기, 배포, 에이전트 CLI를 하나의 작업 흐름으로 묶어야 한다는 관점입니다. 그래서 이 저장소의 핵심은 UI 생성 모델이 아니라 디자인 런타임입니다.
코드 구조를 보면 방향은 명확합니다. server.ts는 로컬 백엔드이고, agents.ts는 여러 CLI를 실행하는 adapter layer이며, skills.ts와 design-systems.ts는 파일 기반 작업 지침을 읽습니다. db.ts와 projects.ts는 작업 상태와 파일을 보존하고, artifacts 렌더러는 AI 답변을 실제 미리보기로 바꿉니다. media.ts와 deploy.ts는 디자인 초안을 이미지, 영상, 배포 흐름으로 확장합니다.
다만 지금 단계에서 기업 표준 도구로 바로 넣기에는 이릅니다. Node 24 고정, 빠른 릴리스 속도, 문서 drift, Windows CLI 이슈, 자동 승인 플래그, 외부 API 프록시 보안 검증이 필요합니다. 추천 경로는 분명합니다. 개인과 소규모 팀은 실험 가치가 높고, 기업은 한 디자인 시스템과 한두 개 스킬만 골라 파일럿을 먼저 돌리는 편이 안전합니다.
가장 중요한 결론은 이것입니다. open-design은 "AI가 혼자 디자인한다"는 환상보다 현실적입니다. 이미 잘 쓰는 코딩 에이전트에게 스킬과 브랜드 규칙을 주고, 로컬 파일 시스템 안에서 디자인 산출물을 만들게 합니다. AI 디자인의 다음 경쟁력이 모델 그 자체보다 작업 흐름과 규칙 파일에서 나온다면, open-design은 꽤 좋은 관찰 대상입니다.
