Open Design: Claude Design의 로컬 퍼스트 오픈소스 대체제

Claude Design은 “프롬프트 → 시각 산출물 → 핸드오프” 흐름을 꽤 선명하게 보여준 제품입니다. 다만 닫힌 클라우드 제품이고, Anthropic 생태계 안에서 움직인다는 한계도 있습니다.

GeekNews에 올라온 Open Design 소개 ↗는 이 지점을 정면으로 겨냥합니다. Open Design ↗은 Claude Design의 로컬 퍼스트·오픈소스 대체제를 표방하며, 사용자의 PATH에 설치된 코딩 에이전트 CLI를 디자인 엔진처럼 연결합니다.

Open Design은 무엇인가

Open Design은 한 줄로 말하면 로컬 코딩 에이전트를 디자인 작업용 런타임으로 묶어 주는 도구입니다. 자체 모델을 내장하기보다, Claude Code·Codex CLI·Gemini CLI·Cursor Agent·OpenCode 같은 이미 설치된 CLI를 감지해 작업 엔진으로 사용합니다.

공식 README는 Open Design을 “Claude Design의 오픈소스 대체제”라고 설명합니다. 차이는 명확합니다. Claude Design이 Anthropic이 제공하는 닫힌 제품이라면, Open Design은 로컬 데몬·웹 앱·데스크톱 앱·Skills·디자인 시스템을 묶은 오픈소스 프로젝트입니다.

흐름은 대략 이렇습니다.

flowchart TB
    A["사용자 요청"] --> B["질문 폼<br/>요구사항 고정"]

    subgraph Context["작업 문맥"]
        C["Skill<br/>무엇을 만들지"]
        D["Design System<br/>어떤 톤과 규칙인지"]
    end

    B --> C
    B --> D
    C --> E["로컬 CLI<br/>또는 BYOK API"]
    D --> E

    subgraph Output["결과 확인과 내보내기"]
        F["HTML artifact"] --> G["샌드박스 iframe<br/>미리보기"]
        G --> H["HTML · PDF · PPTX<br/>ZIP · Markdown"]
    end

    E --> F

핵심은 “AI에게 예쁘게 만들어 달라”가 아닙니다. 요구사항을 먼저 고정하고, Skill과 디자인 시스템을 문맥으로 넣고, 에이전트가 파일시스템에서 실제 산출물을 만들게 하는 구조입니다.

Claude Design과 닮은 점, 다른 점

Claude Design과 Open Design은 둘 다 텍스트 설명에서 시각 산출물로 바로 가려는 제품입니다. 프로토타입, 랜딩 페이지, 슬라이드, 포스터, 모바일 화면 같은 결과물을 대화로 만들고 수정한다는 점도 비슷합니다.

하지만 운영 모델은 다릅니다.

Claude Design 글에서 봤던 핵심이 “아이디어를 빨리 시각화하고 구현으로 넘기는 흐름”이었다면, Open Design은 그 흐름을 내 로컬 에이전트와 내 파일시스템 위에 다시 짠 시도에 가깝습니다.

1) 로컬 CLI를 디자인 엔진으로 씁니다

Open Design README는 16종 코딩 에이전트 CLI를 자동 감지한다고 설명합니다. Claude Code, Codex CLI, Gemini CLI, Cursor Agent, OpenCode, Qwen Code, GitHub Copilot CLI 등이 여기에 포함됩니다.

이 접근이 흥미로운 이유는 모델보다 작업 환경에 있습니다. 에이전트가 단순히 채팅 답변을 내는 것이 아니라, 로컬 프로젝트 폴더에서 파일을 읽고 쓰고, 필요한 명령을 실행하고, 결과물을 실제 파일로 남깁니다.

flowchart TB
    A["1. 디자인 요청 입력"] --> B["2. Web UI가<br/>로컬 데몬에 전달"]
    B --> C["3. 데몬이 선택된<br/>Agent CLI 실행"]
    C --> D["4. Agent가 프로젝트에서<br/>Read · Write · Bash · WebFetch 수행"]
    D --> E["5. artifact 출력"]
    E --> F["6. SSE로 스트리밍"]
    F --> G["7. iframe에서<br/>결과 미리보기"]

공식 Quickstart에 따르면 로컬 개발 모드는 다음처럼 실행합니다.

corepack enable
pnpm install
pnpm tools-dev run web

Docker로는 deploy 디렉터리에서 Compose를 띄우고, 기본적으로 http://localhost:7456에서 접근하는 방식도 제공합니다.

cd deploy
docker compose up -d

http://localhost:7456

2) Skills와 디자인 시스템을 조합합니다

Open Design의 중요한 단위는 Skill입니다. README 기준으로 web-prototype, saas-landing, dashboard, mobile-app, social-carousel, magazine-poster, pm-spec, invoice, team-okrs 같은 Skill이 포함됩니다.

Skill은 “무엇을 만들지”를 정합니다. 디자인 시스템은 “어떤 톤과 규칙으로 만들지”를 정합니다. 이 둘을 조합하면 같은 요청이라도 완전히 다른 결과물을 만들 수 있습니다.

예를 들어 “신규 AI 도구 랜딩 페이지를 만들어줘”라는 요청도 이렇게 갈라질 수 있습니다.

이 구조는 Figma AI Agent Design에서 다뤘던 “디자인 시스템이 AI 출력 품질을 결정한다”는 흐름과도 이어집니다. 프롬프트만 잘 쓰는 것보다, 재사용 가능한 규칙과 컴포넌트 문맥을 주는 쪽이 더 안정적입니다.

3) Anti-AI-slop 장치를 명시합니다

Open Design이 마음에 드는 지점은 “AI가 대충 예쁜 화면을 뽑는다”는 문제를 직접 이름 붙인다는 점입니다. README와 GeekNews 요약 모두 Anti-AI-slop 장치를 강조합니다.

대표적으로 다음 장치가 언급됩니다.

• 첫 턴에서 인터랙티브 질문 폼으로 표면, 대상, 톤, 브랜드, 스케일을 먼저 확정
• 5가지 비주얼 디렉션 중 하나를 고르고 deterministic OKLch 팔레트와 폰트 스택 적용
• TodoWrite 계획을 UI에 스트리밍
• 5차원 자기 비평과 체크리스트 게이트 사용
• 브랜드 색상, 지표, 디자인 의도를 추측하지 않도록 제한

이건 꽤 현실적인 방향입니다. AI 디자인 도구의 실패는 보통 “못생겼다”보다 “그럴듯하지만 우리 맥락과 안 맞다”에서 옵니다. Open Design은 그 문제를 질문 폼, Skill, 디자인 시스템, 체크리스트로 줄이려는 쪽입니다.

4) 결과물을 미리보고 내보내는 데 집중합니다

Open Design은 생성 결과를 <artifact> 형태로 받아 샌드박스 iframe에서 렌더링합니다. 결과물을 채팅창 텍스트로 끝내지 않고, 실제 화면으로 확인하는 구조입니다.

내보내기도 중요합니다. README는 HTML, PDF, PPTX, ZIP, Markdown export를 언급합니다. 여기에 이미지·영상·HyperFrames 같은 미디어 생성 흐름도 함께 다룹니다.

이 지점은 Claude Code HTML Artifacts에서 봤던 문제의식과 닮았습니다. Markdown은 설명에는 좋지만, 디자인 비교·스펙 검토·프로토타입 확인처럼 시각 판단이 필요한 작업에는 금방 한계가 옵니다. Open Design은 처음부터 HTML artifact를 중심에 둡니다.

Google Stitch, Claude Design과 함께 보면 더 선명합니다

요즘 AI 디자인 도구는 비슷한 방향으로 수렴하고 있습니다. 자연어로 UI를 만들고, 디자인 시스템을 참조하고, 코드나 export로 넘기는 흐름입니다.

다만 각 도구의 무게중심은 다릅니다.

그래서 Open Design은 Google Stitch나 Claude Design의 단순 경쟁작이라기보다, “이런 워크플로우를 내 환경에서 직접 조립하고 싶다”는 개발자에게 더 맞는 선택지입니다.

바로 써볼 때 확인할 것

Open Design을 바로 실험한다면 저는 아래 순서로 확인하겠습니다.

1. 내 CLI가 감지되는지 확인합니다. Claude Code, Codex CLI, Gemini CLI 등 실제로 쓰는 에이전트가 Settings에서 잡히는지가 첫 관문입니다.
2. 기본 Skill로 작은 artifact를 만듭니다. 처음부터 거대한 서비스 디자인을 맡기기보다 랜딩 한 장, 대시보드 한 장처럼 작게 시작하는 편이 낫습니다.
3. 디자인 시스템을 바꿔 봅니다. 같은 프롬프트에서 디자인 시스템만 바꿨을 때 결과가 얼마나 일관되게 달라지는지 봐야 합니다.
4. export 품질을 확인합니다. HTML 미리보기는 좋아도 PDF, PPTX, ZIP으로 넘겼을 때 실제 업무에 쓸 수 있는지는 별도 문제입니다.
5. 보안 경계를 봅니다. 로컬 데몬이 파일시스템과 CLI를 다루기 때문에, 팀 환경에서는 프로젝트 범위와 API 키 취급 방식을 반드시 확인해야 합니다.

마무리

Open Design은 “Claude Design을 무료로 베꼈다”보다 조금 더 흥미로운 프로젝트입니다. 핵심은 Claude Design류 작업 방식을 로컬 에이전트, Skill, 디자인 시스템, artifact preview라는 조립 가능한 구조로 풀었다는 데 있습니다.

완성된 디자인 툴로 보기엔 아직 초기 프로젝트에 가깝습니다. 하지만 개발자 입장에서는 꽤 매력적입니다. 이미 쓰는 CLI를 그대로 활용하고, 결과물을 파일로 남기고, Skill과 디자인 시스템을 바꿔 가며 워크플로우를 실험할 수 있기 때문입니다.

AI 디자인 도구의 다음 경쟁은 “누가 더 예쁜 첫 화면을 뽑나”보다 “누가 팀의 맥락을 더 잘 고정하고, 반복 가능한 산출물로 연결하나”가 될 가능성이 큽니다. Open Design은 그 질문에 오픈소스 쪽에서 던진 꽤 직접적인 답입니다.

참고 자료

• Open Design GitHub README ↗ — 프로젝트 개요, Skills, 디자인 시스템, 실행 구조
• Open Design Quickstart ↗ — 로컬 실행, Docker, CLI 감지 방식
• Open Design v0.6.0 Release ↗ — 작성 시점 최신 릴리즈
• GeekNews: Open Design - Claude Design의 로컬 퍼스트 오픈소스 대체제 ↗ — 한국어 요약