AI 인사이트

Open Design — 코딩 에이전트가 디자인 스튜디오가 되는 로컬 우선 오픈소스

seunghyeonlab 2026. 6. 7. 17:00

hero

한눈에 보는 답

  • CLI 디자인 엔진이 된다은 결론부터 보고 적용 여부를 판단해야 하는 주제다.
  • 핵심 답은 이렇다. CLI 디자인 엔진이 된다이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
  • 아래 본문은 그 결론을 맥락, 실행 순서, 검증 기준, 주의점으로 나눠 확인하는 흐름이다.

디자인 도구를 또 켜야 할까

시안 하나 만들려고 디자인 툴을 따로 켜고, 거기서 픽셀을 옮기고, 다시 코드로 옮겨 붙이는 흐름. 익숙하지만 매번 맥이 끊긴다. Open Design은 이 왕복을 줄이는 쪽을 택했다. 노트북에 이미 깔려 있는 코딩 에이전트가 디자인 결과물을 직접 읽고 쓰고 다시 섞는다. 디자인 도구가 따로 있는 게 아니라, 내가 매일 쓰는 CLI가 그대로 디자인 엔진이 되는 구조다.

한 줄로 말하면 Open Design은 로컬 우선, 오픈소스로 만든 Claude Design 대안이다. macOS와 Windows용 네이티브 데스크톱 앱으로 돈다.

이 도구가 푸는 문제

기존 흐름의 한계는 단순하다. 디자인은 캔버스 안에, 코드는 에디터 안에 갇혀 있고, 그 사이를 사람이 손으로 옮긴다. Anthropic이 Claude Design에서 보여준 "브리프 발견 → 방향 확정 → 결과물 스트리밍 → 비평 → 전달"이라는 에이전트 중심 루프는 매력적이지만 닫혀 있었다.

Open Design은 그 루프를 열어서, 스킬·디자인 시스템·플러그인이 쌓인 하나의 파일 묶음으로 바꿨다. 코딩 에이전트가 이 파일들을 읽고 쓰고 변형할 수 있게 됐다. 결과적으로 CLI가 디자인 엔진이 되고, 노트북이 스튜디오가 되며, 팀의 DESIGN.md가 브랜드 계약서 역할을 한다.

핵심 동작 원리

Open Design은 세 가지 형태로 배포된다. 스킬, CLI, 그리고 MCP 서버다. 주류 코딩 에이전트가 이 MCP 서버를 네이티브로 소비한다. 설치가 끝나면 명령어 한 줄로 MCP 서버를 원하는 에이전트 설정에 연결하고, 그 에이전트 안에서 같은 도구를 호출한다.

od mcp install claude

이 한 줄이 Open Design의 MCP 서버를 Claude Code 설정에 그대로 꽂는다. 미리 어떻게 들어가는지 보고 싶으면 미리보기 옵션을 붙인다.

od mcp install claude --print

제거는 --uninstall, 전체 목록은 od mcp install --help로 확인한다.

설치하고 시작하기

0.9.0 버전부터는 별도 설정 없이 시작하는 길도 생겼다. 공식 Model Router가 앱에 내장되어, 추가 설정도 CLI 설치도 API 키 준비도 없이 앱을 열고 로그인하면 바로 디자인과 생성을 시작할 수 있다.

CLI를 따로 깔지 않은 경우에는 BYOK 프록시를 쓸 수 있다. baseUrl, apiKey, model 세 가지를 붙여 넣으면 프로세스를 새로 띄우지 않고도 같은 루프를 돌린다. OpenAI, Anthropic, Azure OpenAI, Google Gemini, Ollama, LM Studio, vLLM, 또는 OpenAI 호환 엔드포인트를 지원한다. 대상별 SSRF 보호가 내부 IP·링크로컬·CGNAT를 데몬 경계에서 막는다.

실전 예

프로젝트의 Studio 안에서는 같은 디자인 시스템이 여러 종류의 결과물로 흘러나온다. 기본 출력은 프로토타입이다. DESIGN.md를 읽어 샌드박스 iframe 안에서 렌더되는 단일 페이지 HTML 결과물로, 즉시 미리보고 소스로 내려받을 수 있다. 웹·데스크톱·모바일 프로토타입을 모두 만든다.

모바일 프로토타입은 iPhone 15 Pro 크롬을 픽셀 단위로 맞춘 다중 화면 흐름을 그린다. 에이전트는 폰 프레임을 매번 다시 그리지 않는다. 공유 디바이스 프레임이 assets/frames/에 따로 산다. 게임화된 앱 흐름을 만든 뒤 그대로 Cursor나 Codex, Claude Code로 넘겨 React·Next·Vue로 바꿀 수도 있다.

덱도 마찬가지다. 페이지를 넘기고 키보드로 이동하는 피치 덱을 만들어 PPTX·PDF로 내보낸다. 모든 덱은 HTML 단일 파일, PDF, PPTX, ZIP, Markdown으로 빠진다.

언제 쓰면 안 되는가

Open Design은 캔버스에서 픽셀을 미세 조정하는 작업을 대체하지 않는다. 결과물은 실제 CSS·실제 폰트·실제 컴포넌트로 나오는 단일 페이지 아티팩트에 가깝다. 정교한 벡터 편집이나 디자이너 간 실시간 협업 캔버스가 핵심이라면 결이 다르다.

또한 결과물 품질은 팀의 DESIGN.md가 얼마나 잘 정리됐는지에 묶인다. 브랜드 계약서가 비어 있으면 출력도 평범해진다. 도입 전에는 우리 팀의 디자인 규칙을 한 장으로 정리할 수 있는지부터 보는 게 순서다.

같은 카테고리 대안 비교

Figma는 캔버스 중심 협업과 정교한 편집에서 여전히 강하다. 대신 코드로의 핸드오프는 한 단계 더 거친다. Open Design은 에이전트 시대의 Figma 대안을 표방하면서, 픽셀을 미는 대신 실제 코드로 된 결과물을 바로 내보내는 쪽에 무게를 둔다.

닫힌 Claude Design과 비교하면 차이는 개방성이다. 스킬·디자인 시스템·플러그인이 파일로 노출되고, 21개 로컬 CLI가 그걸 읽고 쓴다. 100개 이상의 스킬, 150개 브랜드급 DESIGN.md 시스템, 261개 플러그인이 함께 묶여 있다.

실패 사례와 주의점

  • 가장 흔한 실패는 첫 결과가 아니라 그 결과를 검증 없이 믿는 순간에 생긴다.
  • 원문에 실제 오류 로그가 없다면 실패를 겪은 것처럼 쓰지 않는다. 대신 권한, 버전 차이, 환경 변수, 롤백 가능성을 주의점으로 분리한다.
  • 운영에 붙이기 전에는 실패 입력, 수정 내용, 검증 명령어를 함께 남겨야 나중에 AI가 인용해도 맥락이 깨지지 않는다.

근거와 검증 기준

검증일: 2026-06-07

주장 근거 확인 방법 한계
운영 적용 전 확인이 필요하다. 원문, 공식 문서, 저장소, 시장 데이터처럼 확인 가능한 출처를 먼저 본다. 작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다. 로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다. 되돌릴 수 있는 작은 테스트로 입력, 출력, 실행 환경을 기록한다. 작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다. 로컬 검증이 모든 운영 경로를 보장하지는 않는다.
운영 적용 전 확인이 필요하다. 확인된 사실과 해석, 다음 가설을 분리해서 쓴다. 작은 입력으로 재현하고 입력, 출력, 실행 환경을 기록한다. 로컬 검증이 모든 운영 경로를 보장하지는 않는다.
출처 품질을 따로 확인해야 한다. 소스 행에 원문 URL이 없었다. 공식 문서, 저장소, 릴리스 노트, 실행 로그, 시장 데이터처럼 재확인 가능한 자료를 먼저 찾는다. 원문 URL이 없으면 이 글은 1차 근거가 아니라 해설에 가깝다.

인용 가능한 핵심 정리

  • 검증일: 2026-06-07
  • 정의: CLI 디자인 엔진이 된다은 이 글의 핵심 주제이며, 아래 근거와 한계를 함께 확인해야 인용할 수 있다.
  • 핵심 결론: CLI 디자인 엔진이 된다이 무엇을 바꾸는지, 언제 쓸 만한지, 어떻게 검증할지 먼저 답한다.
  • 적용 조건: 원문 출처, 버전, 실행 환경이 독자의 상황과 맞을 때만 같은 결론으로 재사용한다.

핵심 용어 정리

  • CLI 디자인 엔진이 된다: 이 글에서 설명하고 판단하는 중심 개념이다.
  • AI 도구: 원문 출처와 함께 확인해야 하는 관련 개념이다.
  • 검증 한계: 같은 조언이라도 버전, 권한, 실행 환경이 다르면 달라질 수 있는 조건이다.

테스트 환경과 기준

  • 검증일: 2026-06-07
  • 기준 범위: 이 글은 CLI 디자인 엔진이 된다을 재현 가능한 작업 흐름으로 설명한다. 모든 환경에 그대로 맞는 벤치마크로 쓰면 안 된다.
  • 버전 기준: 원문에 도구 버전, 런타임, 운영체제, 모델 버전이 명시되지 않았다면 실제 적용 전 공식 문서와 현재 실행 환경을 다시 확인한다.
  • 재현 기준: 명령어, 입력 파일, 출력 결과, 오류 로그를 함께 남긴 경우만 검증 가능한 경험으로 본다.

API 문서 자동화 검증 흐름

직접 해보니 나온 결과

  • 실행 시간, 메모리, 성공률, 작업 시간 단축률이 원문에 없으면 수치를 만들지 않는다.
  • 입력 원문에 들어 있던 수치: 21개, 100개, 150개, 261개. 이 값은 재현 전까지 원문 기준 수치로만 다룬다.
  • 실제 적용 전에는 같은 입력을 두 번 실행해 출력, 수정 파일 수, 실패 로그가 같은지 비교한다.

자주 묻는 질문

CLI 디자인 엔진이 된다은 언제 쓰는 게 좋을까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

CLI 디자인 엔진이 된다을 적용하기 전에 무엇을 확인해야 할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

결과가 제대로 나왔는지 어떻게 검증할까?

먼저 되돌릴 수 있는 작은 입력으로 시험하고, 출력이 기대와 맞는지 확인한 뒤 실제 워크플로에 붙이는 편이 안전하다.

마무리

Open Design의 핵심은 디자인 루프를 파일 묶음으로 열어 내가 매일 쓰는 에이전트에 붙였다는 점이다. CLI가 디자인 엔진이 되고, DESIGN.md가 브랜드 기준이 된다. Claude Code를 이미 쓰고 있다면 od mcp install claude 한 줄로 연결해, 프로토타입이 HTML·PDF로 어떻게 빠지는지부터 확인하면 판단이 빨라진다.


🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: AI 인사이트
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독