스킬 31개, 시스템 72개: Open Design 라이브러리는 어떻게 작동하는가

Open Design는 구조적으로 보면 서로 차곡차곡 쌓아 올린 네 가지 기본 요소로 이루어져 있습니다:

1. 스킬(Skills) — 에이전트가 무엇을 해야 하는가
2. 시스템(Systems) — 결과물이 어떤 모습이어야 하는가
3. 어댑터(Adapters) — 어떤 에이전트가 그 작업을 하는가
4. daemon — 이들을 서로 엮어 주는 루프

각 기본 요소는 파일들이 담긴 폴더 하나입니다. 그중 어느 것도 데이터베이스, 플러그인 런타임, 호스팅 서비스를 필요로 하지 않습니다. 이것이 라이브러리의 전부입니다 — 로그인 장벽 뒤에 숨어 있는 다섯 번째 개념 같은 건 없습니다. 이 글은 각 요소를 차례로 짚어 보고, 실제 브리프를 에이전트에게 던졌을 때 어떤 일이 벌어지는지 보여 줍니다. 어떻게 만들었는지보다 왜 이런 형태로 만들었는지에 대한 논거가 먼저 궁금하다면, 우리가 Open Design를 제품이 아니라 스킬 레이어로 만든 이유부터 읽어 보세요.

스킬: 역량의 단위

스킬은 하나의 SKILL.md와 0개 이상의 보조 파일을 담은 폴더입니다. 이 Markdown 파일이 에이전트의 계약서이며 — 폴더 안의 다른 모든 것은 에이전트가 그 계약을 충족하도록 돕기 위해 존재합니다.

스킬 폴더의 해부

전형적인 스킬은 다음과 같이 생겼습니다:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md는 스킬의 이름, 트리거 조건, 입력 형태, 출력 형태, 그리고 에이전트를 위한 인라인 안내를 선언합니다. templates/와 examples/ 폴더는 선택 사항이지만 큰 역할을 합니다: examples는 에이전트가 패턴을 맞춰 참고할 수 있는 검증된 좋은 산출물로, "덱 하나 만들어 줘"가 일관성 있는 결과물을 내놓느냐 즉흥적인 결과물을 내놓느냐를 가르는 차이를 만듭니다.

front matter는 daemon이 스킬을 등록하기 위해 읽는 부분이고, 본문은 에이전트가 실행하기 위해 읽는 부분입니다:

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

파일이 곧 레지스트리인 이유

daemon이 부팅하면 skills/를 스캔해 SKILL.md가 들어 있는 모든 폴더를 등록합니다. 플러그인 매니페스트도 없고, 버전 필드도 없습니다. 업로드 단계도, 리뷰 큐도, 빌드도 없습니다. 파일이 있을 뿐이며, 그 파일이 곧 단일 진실 공급원입니다. 새 폴더를 넣고 daemon을 재시작하면 스킬이 피커에 나타납니다. 폴더를 지우면 사라집니다 — 더 이상 존재하지 않는 코드를 가리키는 고아 레지스트리 항목 같은 건 없습니다.

현재 우리는 스킬 31개를 제공합니다. 어떤 것은 덱 생성기이고, 어떤 것은 모바일 목업을 만들며, 어떤 것은 에디토리얼 페이지를 만들고, 어떤 것은 오피스 문서(Word, Excel, PowerPoint)를 작성합니다. 각각은 포크하거나, 편집하거나, 교체할 수 있는 폴더입니다. 계약이 평문 텍스트이기 때문에 "스킬을 작성하는 것"과 "스킬이 무엇을 하는지 이해하기 위해 읽는 것"은 같은 활동입니다 — 파일을 열어 보는 것만으로 감사할 수 있습니다.

시스템: 취향의 단위

스킬이 무엇을 만들지를 기술한다면, 시스템은 그것이 어떤 모습이어야 하는지를 기술합니다. 시스템은 DESIGN.md 파일과 선택적인 참조 에셋으로 구성됩니다. 시스템은 시각적 정체성을 기계가 읽을 수 있는 형태로 기술합니다:

• 색상 — 전경, 배경, 강조, 오류 등에 대한 OKLch 값
• 타이포그래피 — 폰트 스택, 굵기, 타입 램프, 행간 규칙
• 여백 — 기본 단위, 간격 스케일, 컨테이너 너비, 거터 규칙
• 레이아웃 태도 — 그리드 선택, 비대칭 규칙, 밀도 선호
• 보이스 — 말의 타이포그래피: 톤, 어휘, 문장의 리듬

DESIGN.md는 컴포넌트 라이브러리가 아니라 계약서다

실제로 DESIGN.md는 에이전트가 잘못 해석할 수 없는, 짧고 분명한 브랜드 브리프처럼 읽힙니다:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

색상은 OKLch이기 때문에 밝은 표면과 어두운 표면을 가로질러 지각적으로 균일하게 유지됩니다. 타입 램프는 에이전트가 벗어나지 않는 사다리이고, 태도 규칙은 생성된 화면 열 개가 하나의 제품처럼 느껴지느냐, 아니면 서로 다른 인턴 열 명처럼 느껴지느냐를 가르는 차이입니다. 에이전트는 이것을 한 번 읽고 작업 전체에 걸쳐 지킵니다.

시스템은 Figma 라이브러리가 아닙니다. 컴포넌트도, 변형도, 중첩된 인스턴스도, 규칙과 당신 사이를 가로막는 바이너리 포맷도 없습니다. 시스템은 어떤 에이전트든 읽을 수 있고 어떤 사람이든 감사할 수 있는 계약서입니다. 우리는 기본 제공으로 시스템 72개를 제공하며, 여기에는 Linear, Vercel, Stripe, Apple, Cursor, Figma의 이식 가능한 버전과 에디토리얼 및 브랜드 시스템의 긴 꼬리가 포함됩니다.

섞고, 포크하고, 소유하라

시스템은 그저 텍스트이기 때문에, 하나를 포크해 그 자리에서 편집하거나, 변형을 만들어 배포하거나, 집중해서 작업하면 대략 30분 만에 자신만의 것을 처음부터 작성할 수 있습니다. 심지어 프로젝트 도중에 시스템을 섞을 수도 있습니다 — 타이포그래피는 Linear에서, 색상 로직은 Vercel에서, 레이아웃은 사내 사양에서 — 아무것도 독점 바이너리에 묶여 있지 않기 때문입니다. skills/ 폴더와 design-systems/ 폴더를 나눈 것은 의도적입니다: 역량과 취향은 서로 직교하므로, 어떤 스킬이든 어떤 시스템 아래에서 실행될 수 있고, 어떤 시스템이든 어떤 스킬을 구동할 수 있습니다.

어댑터: 에이전트의 단위

스킬과 시스템은 그 자체로는 비활성 텍스트입니다. 어댑터는 그것들을 실제로 작업을 수행하는 에이전트에 연결하는 소량의 코드입니다. 어댑터는 adapters/ 안에 있는 짧은 TypeScript 파일로, 다음을 할 줄 압니다:

• 해당 에이전트가 사용자의 $PATH에 설치되어 있는지 감지
• 그 에이전트로 세션 시작
• 스킬 호출을 파이프로 전달
• 출력을 다시 수집

오늘날 우리는 12개 에이전트에 대한 어댑터를 제공합니다: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. daemon은 어느 것이 존재하는지 자동으로 감지하고 첫 부팅 시 드롭다운으로 제시합니다 — 아무것도 설정할 필요 없이, 이미 가지고 있는 에이전트가 그냥 보일 뿐입니다.

기본 요소	위치	파일	단일 진실 공급원
스킬	skills/	SKILL.md	디스크 위의 파일
시스템	design-systems/	DESIGN.md	디스크 위의 파일
어댑터	adapters/	.ts 파일 하나	register() 호출

새 어댑터를 추가하고 싶다면, 그 파일은 대략 80줄의 TypeScript와 단 한 번의 register() 호출입니다. 배워야 할 SDK도, 요청해야 할 권한도, 게시해야 할 중앙 레지스트리도 없습니다. 노트북에서 이미 신뢰하고 있는 바로 그 에이전트가 엔진이 됩니다 — Open Design는 결코 그것을 대체하지 않습니다. (동반 글 BYOK 디자인 워크플로에서 어댑터를 당신의 키에 연결하는 방법을 짚어 봅니다.)

daemon: 모든 것을 엮는 루프

daemon은 시스템에서 실행되는 유일한 프로세스입니다. pnpm tools-dev로 시작하는 작은 Node 프로세스이며, 다음 네 가지를 순서대로 수행합니다:

1. 감지(Detect) — 부팅 시 설치된 에이전트를 찾기 위해 $PATH를, 설치된 스킬을 찾기 위해 skills/를 스캔합니다
2. 발견(Discover) — 인터랙티브 질문 양식을 열어 현재 브리프의 매체, 대상, 톤, 규모, 브랜드 맥락을 확정합니다
3. 방향 설정(Direct) — 5개의 결정론적 시각 방향(OKLch 팔레트, 폰트 스택, 레이아웃 태도 단서)을 제시하고 사용자에게 하나를 고르게 합니다
4. 전달(Deliver) — 확정된 시스템과 함께 선택된 스킬을 호출하고, 에이전트가 디스크에 쓰게 한 뒤, 샌드박스화된 iframe에서 출력을 미리 보여 줍니다

전체 루프는 대략 1500줄의 코드에 들어맞습니다. 의도적으로 작게 만들었습니다. 영리함은 런타임이 아니라 스킬에 있습니다 — daemon의 일은 폴더를 스캔하고, 브리프를 네 단계로 라우팅하며, 방해되지 않게 비켜서 있는 것입니다. 그 작음이 핵심입니다: 여기에는 썩을 수 있는 것이 거의 없고, 당신의 작업을 인질로 잡을 수 있는 것은 거의 전무합니다.

실제로는 어떤 느낌인가

새로운 제품 기능을 위한 출시 덱을 원한다고 가정해 봅시다. 흐름은 다음과 같습니다:

1. 터미널에서 pnpm tools-dev를 실행합니다. daemon이 localhost:7780에서 시작됩니다.
2. 그 URL을 엽니다. daemon이 찾아낸 에이전트(예: Claude, Cursor, Codex)를 보여 줍니다.
3. 스킬 목록에서 guizang-ppt를 고릅니다.
4. 30초짜리 질문 양식이 뜹니다: 대상은 누구인지, 톤은 어떤지, 브랜드 맥락은 무엇인지.
5. 5개의 시각 방향이 제시됩니다 — 서로 다른 팔레트, 타입 페어링, 레이아웃 태도. 하나를 고릅니다.
6. 에이전트가 디스크에 씁니다. 샌드박스화된 iframe이 결과를 보여 줍니다. HTML, PDF, PPTX, ZIP, Markdown으로 내보낼 수 있습니다.

이를 기본 요소들로 거슬러 추적해 보면 전체가 명료하게 읽힙니다: 3단계는 스킬을 골랐고, 5단계는 시스템을 확정했으며, 그 뒤의 에이전트는 어댑터를 통해 들어왔고, daemon이 네 단계 루프를 실행했습니다. 출력은 실재합니다. 파일은 당신의 것입니다. 어떤 에디터로든 편집하거나, 디자이너에게 건네거나, 다른 스킬에 다시 집어넣을 수 있습니다.

왜 데이터베이스가 아니라 파일인가

모든 기본 요소 — 스킬, 시스템, 어댑터 — 는 텍스트 파일이 담긴 폴더입니다. 중앙 데이터베이스는 없습니다. "Open Design 계정" 같은 것도 없습니다. 당신의 작업이 계속 작동하려면 계속 작동해야만 하는 호스팅 서비스 같은 것도 없습니다.

이것은 의도적인 맞교환입니다. 우리는 영리한 사용자 간 분석, 프로젝트 간 메모리, 호스팅 협업의 가능성을 포기합니다. 그 대가로 얻는 것은: 이식성, 수명, 감사 가능성, 그리고 누구든 라이브러리 전체를 포크해 자신만의 변형을 배포할 수 있는 능력입니다. 오늘 작성한 SKILL.md는 2년 뒤의 에이전트에게도, 어떤 도구도 없는 사람에게도 똑같이 읽힙니다 — 작년의 API에 고정된 플러그인에 대해서는 같은 말을 할 수 없습니다.

한 세대의 디자인 도구가 당신의 파일을 함께 끌고 사라지는 것을 지켜본 적이 있다면, 이 맞교환이 왜 그만한 가치가 있는지 이해할 것입니다.

함께 읽기

• 우리가 Open Design를 제품이 아니라 스킬 레이어로 만든 이유 — 네 가지 기본 요소 뒤에 있는 베팅
• BYOK 디자인 워크플로: Claude, Codex, Qwen을 당신의 키로 실행하기 — 어댑터가 이미 당신이 비용을 내고 있는 에이전트에 연결되는 방식
• 캔버스가 숨겨 온 레이아웃 레이어 — DESIGN.md의 태도 규칙이 캔버스 위에서 박스를 끌어다 놓는 것을 이기는 이유