Figma 워크플로를 Open Design 플러그인으로 옮기는 방법

Figma 워크플로는 대개 몸에 밴 습관으로 시작합니다. 이 프레임들을 내보내고, 저 토큰들을 동기화하고, 그 덱 템플릿을 다시 만들고, 사양을 엔지니어링 팀에 넘긴다. 누군가의 머릿속에만 존재하다가 새 프로젝트가 시작될 때마다 다시 설명해야 하는 종류의 작업입니다.

0.8.0-preview 스레드는 더 날카로운 요청을 합니다. 그 몸에 밴 습관을 플러그인으로 옮기라는 것입니다. 캔버스에 덧붙인 패널이 아닙니다. 한 팀만 실행할 수 있는 비공개 스크립트도 아닙니다. 에이전트가 집어 들고, 실행하고, 검토하고, 다른 디자인 작업과 동일한 로컬 우선 루프를 통해 넘길 수 있는 재사용 가능한 Open Design 워크플로입니다.

이것이 0.8.0-preview 플러그인 모집의 실용적 버전입니다. 오늘 당신의 팀에 반복 가능한 디자인 워크플로가 하나 있다면, 이 글은 그것을 플러그인 형태의 기여로 바꾸는 모습을 보여줍니다. 어떤 파일이 필요한지, 에이전트가 어떻게 집어 드는지, 그리고 게시된 후 어디에 안착하는지 말입니다.

옮길 가치가 있는 워크플로는 생각보다 작습니다

“Figma를 대체하자”로 시작하지 마세요. 짜증나는, 반복 가능한 작업 하나로 시작하세요.

좋은 첫 플러그인 후보:

현재 워크플로	플러그인 형태 버전
Figma 마케팅 페이지를 내보내 코드로 다시 만들기	레이아웃을 추출하고, 토큰을 매핑하고, 웹 아티팩트를 생성하는 `figma-migration` 플러그인
매달 브랜드 키트를 런칭 슬라이드로 만들기	`SKILL.md`, 예시 에셋, 잠긴 디자인 시스템을 갖춘 덱 플러그인
모든 고객사를 위해 동일한 모바일 온보딩 목업 만들기	대상, 톤, 기능 목록, 플랫폼 입력 필드를 갖춘 모바일 화면 플러그인
컴포넌트 사양을 Storybook 대응 UI로 변환하기	저장소를 읽고, 컴포넌트를 매핑하고, 검토 가능한 diff를 작성하는 코드 마이그레이션 플러그인

단위는 디자인 부서 전체가 아닙니다. 단위는 누군가 이미 일주일에 두 번 반복하는 워크플로 하나입니다. 한 문장으로 설명할 수 없다면 — “이런 제약 조건으로 X를 Y로 바꾼다” — 그것은 아마 하나가 아니라 두 개의 플러그인이며, Markdown 한 줄을 쓰기 전에 나눠야 합니다.

그래서 Open Design의 스킬 레이어가 여기서 중요합니다. 플러그인은 불투명한 런타임 확장이 아닙니다. 파일들이 담긴 폴더입니다. SKILL.md 계약, 선택적 디자인 시스템, 선택적 예시, 그리고 Open Design에게 워크플로를 어떻게 표시하고 적용할지 알려주는 open-design.json 사이드카입니다. 당신과 규칙 사이에 바이너리 포맷이 없으므로, 누구나 플러그인을 읽고, 포크하고, 나중에 고칠 수 있습니다.

거의 흰색에 가까운 편집 디자인풍 바탕에서 초록색 프레임으로 선택된 채, 캔버스에서 추출되어 휴대 가능한 모듈 상자에 담기는 디자인 프레임 — 워크플로를 옮긴다는 것은 반복 가능한 부분을 캔버스에서 들어내 휴대 가능한 플러그인으로 옮긴다는 뜻입니다.

Open Design의 핵심은 이식성입니다

플러그인 사양은 계약을 명확하게 규정합니다. SKILL.md는 실행 가능한 에이전트 계약으로 남고, open-design.json은 마켓플레이스 메타데이터, 입력 필드, 기본값, 미리보기, 컨텍스트 연결을 추가합니다.

이로써 하나의 워크플로가 두 개의 삶을 갖습니다. Open Design에서는 미리보기, 입력, 출처, 그리고 원클릭 “사용” 경로를 갖춘 플러그인으로 나타납니다. Claude Code, Cursor, Codex, Gemini CLI, OpenClaw, 또는 다른 스킬 카탈로그에서는, 핵심 동작이 Markdown 안에 있기 때문에 동일한 폴더가 평범한 에이전트 스킬로도 여전히 작동합니다. 내년에 사라질 런타임을 위해 작성하는 것이 아닙니다. 2년 뒤에도 에이전트가 똑같은 방식으로 읽을 파일을 작성하는 것입니다.

라이브러리 둘러보기는 이미 기본 원시 요소들을 설명합니다. 스킬, 시스템, 어댑터, 그리고 daemon입니다. 플러그인은 그 원시 요소들 주위에 배포와 반복 가능성을 더합니다. 에이전트가 디스크에서 우연히 발견하는 원시 스킬이 아니라, 팀이 출하하고, 검토하고, 재사용하는 단위입니다.

Figma-투-코드 워크플로의 경우, 표면은 대개 다음과 같습니다:

표면	구체적 파일
에이전트 동작	`SKILL.md`
Open Design 메타데이터	`open-design.json`
브랜드 또는 비주얼 계약	`design-systems/{brand}/DESIGN.md`
예시 출력	플러그인 폴더 내부의 `example.html` 또는 `examples/{plugin-id}/example.html`
미리보기 미디어	플러그인 폴더 내부의 `preview/poster.png` 또는 `preview/index.html`

결과물은 스크린샷 생성기가 아닙니다. 눈에 보이는 계약을 갖춘 재사용 가능한 에이전트 워크플로입니다. 에이전트가 따르는 모든 규칙이 사람이 읽고 편집할 수 있는 폴더 안에 자리하고 있습니다.

구체적인 이식 경로

여기 하나의 Figma 랜딩 페이지 워크플로를 옮기는 플러그인을 위한 최소 경로가 있습니다. 전체는 여섯 단계이며, 대부분이 Markdown입니다.

1. 반복 가능한 작업의 이름을 짓기

작업을 설명하는 한 문장을 적으세요. “하나의 Figma 마케팅 프레임을 하우스 브랜드 시스템으로, 검토 준비가 된 반응형 Astro 페이지로 바꾼다.” 한 문장에 담을 수 없다면, 담을 수 있을 때까지 좁히세요. 그 이름이 당신의 플러그인 id(figma-workflow)가 되고 마켓플레이스에 표시되는 제목이 됩니다.

2. 스킬 계약 작성하기

SKILL.md는 에이전트가 읽는 실행 가능한 계약입니다. 프런트매터는 스킬과 그 트리거의 이름을 짓고, 본문은 브리프입니다. 입력 형태, 출력 경로, 제약 조건, 그리고 에이전트가 넘기기 전에 스스로 적용해야 할 검토 체크리스트입니다.

---
name: figma-workflow
description: Turn one Figma marketing frame into a responsive Astro page in the house brand system.
trigger: When the user provides a Figma frame URL, screenshot, or exported assets for a marketing page.
---

## Input
- A Figma frame URL, a screenshot, or a folder of exported assets.
- The target brand system (defaults to `house`).

## Output
- An Astro page at `src/pages/<slug>.astro`, plus extracted tokens.

## Constraints
- Map Figma styles to the brand system's tokens. Do not invent colors or type.
- Preserve section order and copy. Flag any text that does not fit the grid.
- Mobile-first: every section must reflow at 360px before desktop.

## Review checklist
- [ ] Section IDs match the source frame.
- [ ] No raw hex values — tokens only.
- [ ] Responsive behavior verified at 360 / 768 / 1280.

3. Open Design 사이드카 추가하기

open-design.json은 벌거벗은 스킬을 마켓플레이스 플러그인으로 바꿔주는 것입니다. 제목, 설명, 선언된 입력, 미리보기, 그리고 소스 저장소입니다. 이것이 “사용” 패널과 출처 라인을 구동하는 메타데이터입니다.

{
  "id": "figma-workflow",
  "title": "Figma workflow",
  "description": "Port one Figma marketing frame into a responsive Astro page.",
  "inputs": [
    { "key": "figmaSource", "label": "Figma URL or screenshot", "type": "string", "required": true },
    { "key": "brand", "label": "Brand system", "type": "string", "default": "house" }
  ],
  "preview": "preview/poster.png",
  "source": "https://github.com/your-org/your-plugins"
}

4. 디자인 시스템 연결하기

워크플로가 브랜드 규칙에 의존한다면, 색상과 타이포그래피를 산문 속에 묻어두는 대신 design-systems/ 아래에 DESIGN.md 파일을 추가하세요. 에이전트는 그 시스템을 계약으로 흡수합니다. OKLch 팔레트, 타입 램프, 레이아웃 자세 — 그래서 생성된 열 개의 화면이 여전히 하나의 제품처럼 느껴집니다. 프로젝트 중간에 시스템을 섞는 것도 가능합니다. 그것들은 그저 텍스트이기 때문입니다.

5. 실제 예시 하나 포함하기

검토자가 약속이 아니라 출력을 판단할 수 있도록 생성된 아티팩트를 examples/ 아래에 저장하세요. 검증된 example.html 하나가 한 단락의 설명보다 더 가치 있습니다. 에이전트에게는 패턴 매칭할 대상을 주고, 메인테이너에게는 승인할 대상을 줍니다.

다 합치면, 플러그인은 읽기 쉬운 하나의 폴더입니다:

plugins/community/figma-workflow/
  SKILL.md              # the agent contract: trigger, output, constraints, review
  open-design.json      # marketplace metadata: title, inputs, preview, source
  design-systems/
    house/
      DESIGN.md         # the brand contract the agent must respect
  examples/
    figma-workflow/
      example.html      # one known-good artifact reviewers can judge
  preview/
    poster.png          # marketplace preview media

6. 검증하고 패키징하기

PR을 열기 전에 플러그인 명령을 실행하세요. 현재 CLI 경로는 소문자 플러그인 id를 사용합니다. 스캐폴드 시점에 슬래시로 구분된 레지스트리 이름은 피하세요. od plugin scaffold는 <out>/<id>/...를 생성하므로, 후속 명령들은 그 생성된 폴더를 가리킵니다:

od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
od plugin validate ./plugins/community/figma-workflow --no-daemon
od plugin pack ./plugins/community/figma-workflow

플러그인이 레지스트리 검토 준비가 되면, od plugin login과 od plugin whoami --json으로 GitHub를 통해 인증한 다음, 현재 검토 경로에 대한 게시 문서를 따르세요. Open Design은 당신의 GitHub 자격 증명을 저장하지 않습니다.

실제 디자인 팀에서는 어떤 모습일까

런칭 페이지를 위한 Figma 프레임, 하우스 브랜드 시스템, 그리고 매월 릴리스 리듬을 갖춘 작은 제품 팀을 상상해 보세요.

플러그인이 있기 전, 워크플로는 인계 사슬입니다. 디자이너가 프레임을 내보내고, 엔지니어가 레이아웃을 다시 만들고, PM이 카피를 다시 쓰고, 누군가는 토큰 드리프트를 확인하고, 또 다른 누군가는 버그를 제기합니다. 익숙한 작업이지만, 그 기억은 사람들 안에 살아 있습니다 — 그리고 누군가 자리를 비우거나, 팀을 옮기거나, 중요했던 그 한 가지 제약을 잊을 때마다 새어 나갑니다.

플러그인이 있은 후, 워크플로는 실행 가능한 아티팩트가 됩니다:

단계	누가 지시하는가
플러그인 선택	디자이너 또는 PM
Figma URL / 스크린샷 / 로컬 에셋 첨부	디자이너
브랜드 시스템 선택	디자이너 또는 디자인 엔지니어
웹 아티팩트 생성	Claude Code, Cursor, Codex, Gemini CLI, 또는 감지된 다른 에이전트
섹션 ID, 카피, 밀도, 반응형 동작 검토	Open Design 미리보기 안의 사람
파일 내보내기 또는 인계	동일한 로컬 프로젝트 폴더

팀은 여전히 안목이 필요합니다 — 검토 단계가 바로 그것이 머무는 곳이며, 어떤 플러그인도 그것을 대체하지 못합니다. 플러그인이 없애는 것은 다시 설명하는 일입니다. 제약 조건, 토큰 맵, 출력 경로가 부족 지식이기를 멈추고 저장소 안의 파일이 됩니다.

다음에 할 일

당신의 팀에 계속 돌아오는 Figma 내보내기, 토큰 동기화, 브랜드 키트, 또는 덱 템플릿이 있다면, 가장 작은 반복 가능한 조각을 먼저 옮기세요. SKILL.md로 시작하고, open-design.json을 추가하고, 브랜드 DESIGN.md를 연결하고, 실제 예시 하나를 넣고, 검증한 다음, 그 워크플로가 아무도 재사용할 수 없는 비공개 도구로 자라기 전에 PR을 여세요. 스크린샷-투-프로토타입 예시는 플러그인 형태 버전을 처음부터 끝까지 보여줍니다. 휴대 가능한 스킬 더하기 Open Design 사이드카입니다.

이 워크플로를 시도해 보세요.