Open Design 분석 — Claude Design을 로컬·오픈소스 방식으로 다시 읽는 법
PyTorchKR가 소개한 Open Design은 단순한 “Claude Design 대체재”라기보다, 디자인 작업을 코딩 에이전트의 작업 공간으로 끌어오는 흐름을 보여준다. 핵심은 예쁜 화면 자동 생성이 아니라 질문 폼, 디자인 시스템, 스킬, 로컬 에이전트, 미리보기, 내보내기를 하나의 루프로 묶는 방식이다.
먼저 결론
- Open Design은 Claude Design의 아이디어를 로컬·오픈소스·BYOK 방식으로 풀어낸 프로젝트로 볼 수 있다.
- 현재 GitHub 원문 기준으로 PyTorchKR 글에 적힌 수치보다 프로젝트 규모가 더 커져 있다. 따라서 숫자는 고정값이 아니라 빠르게 변하는 지표로 봐야 한다.
- 실무 도입은 “디자인 툴 교체”보다 작은 산출물부터 권한을 제한해 테스트하는 방식이 안전하다.
1. Claude Design이 먼저 보여준 것
Anthropic 공식 발표에 따르면 Claude Design은 Claude와 대화하면서 디자인, 프로토타입, 슬라이드, 원페이지 자료 같은 시각 산출물을 만드는 Anthropic Labs 제품이다. Claude Opus 4.7 기반 연구 미리보기로 소개됐고, Pro·Max·Team·Enterprise 구독자에게 제공된다고 안내됐다. 공식 글은 텍스트 입력, 이미지·문서 업로드, 코드베이스 참조, 웹 캡처, 인라인 댓글, 직접 텍스트 편집, 슬라이더 조정, Canva·PDF·PPTX·독립 HTML 내보내기, Claude Code로 넘기는 핸드오프를 언급한다.
이 발표의 의미는 “AI가 그림을 그린다”가 아니다. Claude가 산문형 답변을 넘어, 실제로 보고 고칠 수 있는 디자인 아티팩트를 만든다는 점이다. 특히 팀 디자인 시스템을 읽고 프로젝트마다 자동 적용한다는 설명은 기업 사용자에게 중요하다. 디자인 산출물이 예뻐 보이는 데서 끝나지 않고, 색상·타이포그래피·컴포넌트 규칙을 따라야 하기 때문이다.
2. Open Design은 무엇을 다르게 제안하나
PyTorchKR 글은 Open Design을 Claude Design의 클라우드 전용, 유료, 비공개 소스 제약을 줄이려는 오픈소스 대안으로 소개한다. 로컬 우선 구조, BYOK, 사용자가 이미 설치한 Claude Code·Codex·Cursor Agent·Gemini CLI·OpenCode 같은 코딩 에이전트 연결, 스킬 기반 디자인 워크플로, 디자인 시스템 라이브러리가 핵심이다.
Open Design GitHub README의 현재 main 브랜치는 더 공격적인 포지션을 잡고 있다. “오픈소스, 로컬 우선 Claude Design 대안”이라고 밝히며, PATH에서 16개 코딩 에이전트 CLI를 자동 감지하고, 조합 가능한 스킬과 브랜드급 디자인 시스템을 디자인 엔진으로 쓴다고 설명한다. 저장소를 직접 확인한 시점에는 SKILL.md 132개, DESIGN.md 150개가 들어 있었다. README 상단의 배지와 본문 수치가 서로 빠르게 바뀌는 점까지 보면, 이 프로젝트는 안정 제품이라기보다 빠르게 확장 중인 개발 흐름에 가깝다.
| 구분 | Claude Design | Open Design | 실무 판단 |
|---|---|---|---|
| 소유 구조 | Anthropic 서비스 | Apache-2.0 오픈소스 저장소 | 통제권은 Open Design이 넓지만 운영 책임도 사용자가 진다. |
| 실행 위치 | claude.ai 중심 | 로컬 브라우저·데몬·CLI 조합 | 보안·네트워크·설치 환경을 먼저 정해야 한다. |
| 모델 선택 | Anthropic 모델 중심 | 기존 코딩 에이전트 또는 BYOK 프록시 | 모델 자유도는 커지지만 결과 품질 편차도 커진다. |
| 확장 방식 | 서비스 내 기능 확장 | SKILL.md와 DESIGN.md 파일 확장 | 팀 표준을 파일로 남기는 조직에 유리하다. |
3. Open Design의 핵심은 에이전트를 새로 만들지 않는 데 있다
Open Design 문서에서 가장 중요한 문장은 “전체 에이전트 루프를 사용자의 기존 코딩 에이전트 CLI에 위임한다”는 취지다. 즉 Open Design은 또 하나의 AI 코딩 도구를 만들기보다, 이미 설치된 Claude Code, Codex, Gemini CLI, OpenCode 같은 런타임을 감지해 디자인 작업의 엔진으로 쓰는 구조다.
이 접근은 현실적이다. 좋은 코딩 에이전트는 이미 파일 읽기, 쓰기, 셸 명령, 컨텍스트 관리, 권한 승인, 작업 재개 같은 복잡한 기능을 갖고 있다. Open Design은 그 위에 질문 폼, 스킬, 디자인 시스템, 아티팩트 미리보기, 내보내기를 얹는다. 그래서 “디자인 앱”이면서 동시에 “에이전트 오케스트레이션 UI”에 가깝다.
4. SKILL.md와 DESIGN.md가 중요한 이유
AI 디자인 도구의 약점은 매번 다른 스타일을 내놓는다는 점이다. 사용자는 “깔끔하게”, “전문적으로”, “애플처럼”이라고 말하지만, 모델은 그때그때 다른 색상과 카드, 이모지, 그라데이션을 섞기 쉽다. Open Design이 스킬과 디자인 시스템을 파일로 관리하는 이유는 이 변동성을 줄이기 위해서다.
스킬은 산출물의 작업 절차를 담는다. 예를 들어 웹 프로토타입, SaaS 랜딩 페이지, 대시보드, 모바일 앱, 주간 업데이트, 재무 보고서, 인보이스, 칸반 보드처럼 산출물마다 필요한 구조가 다르다. DESIGN.md는 색상, 타이포그래피, 간격, 컴포넌트, 모션, 보이스, 안티패턴 같은 브랜드 규칙을 담는다. 둘을 결합하면 AI에게 “무엇을 만들지”와 “어떤 기준으로 만들지”를 동시에 줄 수 있다.
작업 절차를 고정한다
보고서, 대시보드, 발표자료, 앱 화면처럼 산출물별 체크리스트를 파일로 남겨 모델이 즉흥적으로 구조를 만들지 않게 한다.
스타일 기준을 고정한다
색상, 폰트, 여백, 컴포넌트, 금지 패턴을 정해 산출물마다 다른 분위기로 흔들리는 문제를 줄인다.
5. 로컬 우선 구조의 장점과 부담
Open Design의 로컬 구조는 분명 매력적이다. 산출물 폴더가 로컬에 남고, 기존 CLI 에이전트를 쓸 수 있으며, 필요하면 BYOK 방식으로 특정 API 키를 연결할 수 있다. 기업이나 개인 입장에서는 클라우드 서비스 하나에 모든 디자인 흐름을 맡기지 않아도 된다는 장점이 있다.
하지만 로컬 우선은 공짜 장점만 있는 구조가 아니다. Node 버전, pnpm, 로컬 데몬, 포트, SQLite, 브라우저 프록시, 각 에이전트 CLI 로그인 상태, API 키 관리, 저장소 권한까지 사용자가 운영해야 한다. Open Design QUICKSTART는 Node 24와 pnpm 10.33.x를 요구한다고 안내한다. 기술팀이 없는 일반 사무 조직에서는 이 설치·운영 부담이 진입장벽이 될 수 있다.
| 점검 항목 | 확인할 내용 | 권장 기준 |
|---|---|---|
| 키 관리 | BYOK API 키가 어디 저장되고 누가 접근하는지 | 개인 키보다 프로젝트별 제한 키 사용 |
| 저장소 권한 | 에이전트가 읽고 쓸 수 있는 디렉터리 범위 | 테스트 저장소와 별도 브랜치에서 시작 |
| 산출물 보관 | HTML, PDF, PPTX, ZIP 파일의 저장 위치 | 민감자료 없는 샘플부터 검증 |
| 품질 기준 | 접근성, 반응형, 브랜드 규칙, 출처 표시 | 디자인 시스템과 리뷰 체크리스트를 먼저 작성 |
6. 바로 써볼 만한 업무
Open Design을 처음 시험한다면, 회사의 핵심 서비스 화면보다 실패 비용이 낮은 산출물부터 시작하는 편이 좋다. 예를 들어 내부 교육자료, 제안서용 원페이지, 기능 설명 랜딩 페이지, 간단한 관리자 대시보드, 모바일 앱 첫 화면, 블로그 인포그래픽 같은 작업이다. 이런 작업은 빠른 비교와 시각적 탐색의 이점이 크고, 잘못돼도 수정 비용이 낮다.
보고서형 HTML
표, 요약, 체크리스트가 있는 내부 설명자료를 만들고 디자인 시스템을 적용해 본다.
프로토타입 화면
앱 또는 관리자 페이지의 첫 화면을 여러 방향으로 만들어 의사결정 속도를 본다.
발표자료 구조
스토리라인, 표지, 핵심 슬라이드, 내보내기 품질을 비교한다.
7. 아직 조심해야 할 부분
오픈소스 AI 디자인 도구는 빠르게 발전하지만, 실무에서는 세 가지를 조심해야 한다. 첫째, 최신 README의 숫자와 기능 설명이 빠르게 변한다. 둘째, 모델과 CLI 조합에 따라 결과 품질이 달라진다. 셋째, 로컬 에이전트가 파일 시스템과 명령 실행 권한을 갖기 때문에 보안 경계를 분명히 해야 한다.
- 기능 숫자 과신 금지: PyTorchKR 글은 19개 스킬과 71개 디자인 시스템을 소개하지만, 현재 저장소 원문은 더 큰 수치를 언급한다. 빠르게 변하는 프로젝트라는 뜻이다.
- 결과물 품질 점검: 반응형, 접근성, 표·차트 정확성, 실제 데이터 표시, 저작권 이미지 사용 여부를 별도로 봐야 한다.
- 권한 제한: 실서비스 저장소, 고객자료, 계약서, 내부 보안 문서를 바로 넣지 않는다.
- 팀 표준화: 좋은 결과가 나왔다면 자연어 지시만 저장하지 말고 SKILL.md와 DESIGN.md처럼 재사용 가능한 기준으로 남긴다.
8. 결론: 디자인도 에이전트 운영 문제가 된다
Claude Design과 Open Design이 동시에 보여주는 방향은 분명하다. AI 디자인의 경쟁은 단순 이미지 생성이나 예쁜 템플릿 경쟁에서, 산출물 생성 루프 전체를 누가 장악하느냐로 이동하고 있다. 질문을 잘 받고, 팀 기준을 읽고, 여러 방향을 빠르게 만들고, 브라우저에서 확인하고, HTML·PDF·PPTX로 내보내고, 필요하면 코드 작업으로 넘기는 흐름이 중요해졌다.
Open Design이 흥미로운 이유는 이 흐름을 특정 클라우드 서비스 안에 가두지 않고, 로컬 데몬과 기존 코딩 에이전트, 스킬, 디자인 시스템 파일로 풀어내기 때문이다. 이 방식이 완전히 안정적이라고 단정할 수는 없다. 다만 Hermes, Codex, Claude Code, OpenCode 같은 도구를 이미 쓰는 사람에게는 “디자인도 에이전트가 처리할 수 있는 작업 단위로 나눠야 한다”는 중요한 힌트를 준다.
한 줄로 정리하면, Open Design은 Claude Design의 대체재라기보다 AI 디자인 업무를 로컬 에이전트 운영 체계로 가져오는 실험이다.
출처 및 참고자료
- PyTorchKR, Open Design 소개 글 — Open Design의 개요, Claude Design과의 비교, 설치 흐름, 스킬·디자인 시스템 설명을 확인했습니다.
- Anthropic, Introducing Claude Design by Anthropic Labs — Claude Design의 공식 발표, 제공 범위, 사용 흐름, 내보내기와 Claude Code 핸드오프 설명을 확인했습니다.
- nexu-io/open-design GitHub 저장소 — Open Design의 현재 README, 라이선스, 지원 에이전트, 스킬·디자인 시스템 구조를 확인했습니다.
- Open Design QUICKSTART — Node.js, pnpm, 로컬 실행 요구사항과 BYOK 모드 안내를 확인했습니다.
- Open Design Agent Adapters 문서 — 기존 코딩 에이전트 CLI에 에이전트 루프를 위임하는 구조를 확인했습니다.
- Open Design Skills Protocol 문서 — Claude Code의 SKILL.md 규약과 Open Design 확장 필드의 관계를 확인했습니다.