AI/Design

DESIGN.md 자동 생성 : DesignMD Style Extractor - 클릭 하나로 웹사이트 디자인 시스템을 추출하는 Chrome 확장 프로그램

안녕하세요! 갓대희 입니다.

Design.md를 만들때 Claude.design을 사용하며 테스트를 이것저것 해보는 와중이었다.

여러 유명한 유튜버, x.com의 빅테크 인사, 여러 한국 쓰레드를 즐겨보곤 하는데 그중 즐겨보는 @unclejobs.ai의 Threads 에서 하나의 아이디어를 보게되어 글을 작성하게 되었다.

내가 며칠 전 정리하던 Design.md 관련 글보다 핵심을 더 단정하게 짚고 있어 보였다.

2026.04.23 - [AI/Design] - DESIGN.md : Google Stitch가 도입한 DESIGN.md - DESIGN.md 도입 배경부터 적용해보기(VoltAgent awesome-design-md 컬렉션 활용 가이드)

한 문장으로 요약하면 "Google Stitch가 design-to-code 흐름을 정착시켰는데, 그 앞단(upstream)이 비어 있다"라는 지적이다.

AI는 디자인 명세를 받으면 코드를 꽤 잘 만든다. 문제는 그 명세를 누가 쓰느냐는 점이다. 디자이너가 없거나 피그마를 안 쓰는 바이브 코더에게 이 공백은 꽤 크다.

이 글에서 다루는 DesignMD Style Extractor는 그 빈 칸을 Chrome 확장 하나로 메우려는 시도다. 어떤 웹페이지든 클릭 한 번이면 페이지의 색·타이포·간격·모션을 추출해 DESIGN.md 또는 SKILL.md로 정리해 준다.

이번 글에서는 GitHub 소스를 직접 뜯어 이 확장이 어떻게 280개 요소를 샘플링하고, 어떤 기준으로 사이트의 성격을 추론하는지, 그리고 DESIGN.md/SKILL.md 두 출력 모드의 차이가 무엇인지까지 짚어본다. v0.4.0(2026-04-29 기준) 코드 기준이다.

너무 딥다이브한다는 느낌이 있다면 차라리 해당 피드를 보시는것을 추천 드립니다.

https://www.threads.com/@unclejobs.ai/post/DXLGC2hiZu4

DesignMD가 뭐고, 왜 쓰는가
설치: 1분이면 충분
실전 사용: 3단계로 끝내기
시나리오별 활용법
이것만 알고 쓰자 (주의사항)
트러블슈팅 Q&A
결론: 언제 쓰고, 언제 쓰지 않는가

1. DesignMD 가 뭐고, 왜 쓰는가

DesignMD Style Extractor는 GitHub에 공개된 MIT 라이선스 Chrome 확장프로그램다.

어떤 웹페이지든 클릭 한 번으로 색상, 폰트, 간격, 애니메이션을 읽어 DESIGN.md나 SKILL.md 파일로 만들어준다고 한다.

배경은 간단하다. 2026년 3월 Google Stitch와 함께 등장한 DESIGN.md 포맷은 Claude Code, Cursor, Codex 같은 AI 코딩 도구가 "이 파일을 보고 디자인에 맞춰라"는 식으로 참고할 수 있도록 설계됐다.

문제는 이 파일을 누가 만드느냐다. 피그마도 없고 디자이너도 없는 환경에서는 직접 써야 했는데, 이 확장프로그램을 통해 기존 웹사이트에서 역으로 추출해 만들어주는 방식으로 그 빈 자리를 채우고자 하는 컨셉이라고 한다.

vs 대안 비교

항목	DesignMD Style Extractor	직접 작성 (수기 DESIGN.md)	TypeUI Pro 스킬 풀
입력	임의의 웹페이지 URL	디자이너 가이드 + 개발자 정리	사전 큐레이션된 스킬
출력	DESIGN.md / SKILL.md	DESIGN.md	디자인 스킬 + 컴포넌트 마크다운
가격	무료 (MIT)	인건비	$30/월 또는 $120/년
데이터 처리	브라우저 내 로컬	로컬	CLI pull
적합 시나리오	기존 사이트 톤 복제, 빠른 프로토타입	신규 디자인 시스템 정의	정해진 스타일(Paper, Bento, Neobrutalism 등) 빠르게 적용

(가격 출처: TypeUI 공식, 데이터 처리 출처: Chrome Web Store 개인정보 선언)

세 방식은 같은 줄 위에 있지 않다. 직접 작성은 디자인 시스템을 새로 정의하는 작업이고, TypeUI Pro는 57개 이상의 사전 큐레이션된 스타일을 골라 쓰는 방식이다. 반면 DesignMD 확장은 이미 존재하는 사이트를 역방향으로 추출해 명세화한다. "내가 좋아하는 그 사이트처럼 만들고 싶다"라는 흔한 요구를 정면으로 받는다.

2. 설치 방법

Chrome Web Store 설치 (1클릭)

가장 간단한 경로는 https://chromewebstore.google.com/detail/designmd-style-extractor/ogpdnchdjiibhobphelbbkemnnemkfma에서 "Chrome에 추가"를 누르는 것이다. 카테고리는 Developer Tools다. 설치 후 임의의 웹페이지에서 확장 아이콘을 클릭하면 팝업이 뜬다.

ex) 나의 경우 이미 설치해서 삭제가 노출된다.

- 확장 프로그램에 설치되어있는것을 볼 수 있다.

개발자 모드 (소스에서 직접)

저장소를 직접 빌드해 쓰려면 README의 절차를 따른다. 단계는 4개다.

chrome://extensions에 접속한다.
우측 상단 Developer mode를 활성화한다.
Load unpacked를 선택한다.
클론한 프로젝트 폴더를 지정한다.

저장소가 47.06 KiB 수준이라 빌드 단계가 따로 없다. 클론 → 폴더 지정만으로 바로 동작한다.

권한은 activeTab, scripting, storage, downloads 4가지뿐이다. v0.2.0 단계에서 tabs 권한이 의도적으로 제거되었으며, 원격 서버로 데이터를 보내는 통신 권한이 없는것 같다.

실제로 Chrome Web Store 개인정보 선언에서도 "데이터를 수집하지 않으며, 제3자에게 판매하거나 핵심 기능 외 목적으로 사용하지 않는다. 추출은 브라우저 내에서만 동작한다"라고 개발자(Zoltan, typeui.sh 운영)가 직접 선언했다.

권한 목록과 현재 공개 소스의 처리 흐름을 보면 이 고지와 대체로 맞아떨어지지만, 개인정보 보장은 실제 배포본과 코드 흐름을 함께 봐야 한다.

3. 사용해보기

Step 1. 원하는 사이트에서 추출하기

따라 만들고 싶은 레퍼런스 사이트를 열고, 상단 확장 아이콘을 클릭한다.

팝업이 뜨면 Auto-extract 버튼을 누르면 된다. 수 초 안에 색상, 폰트, 간격, 모션 6개 카테고리를 자동으로 읽어온다.

팁: SPA나 모달이 있는 사이트라면, 먼저 원하는 화면 상태(모달 열린 상태 등)를 만들어 두고 Refresh를 누르면 그 시점 기준으로 다시 추출한다.

ex) 내 바이브 코딩용 사이트를 예시로 테스트 해 보았다.

- 우측 상단에 있는 플러그인 클릭

- 추출한 design.md 원문

# GodDaeHee Hub

## Mission
Create implementation-ready, token-driven UI guidance for GodDaeHee Hub that is optimized for consistency, accessibility, and fast delivery across content site.

## Brand
- Product/brand: GodDaeHee Hub
- URL: https://goddaehee.co.kr/
- Audience: readers and knowledge seekers
- Product surface: content site

## Style Foundations
- Visual style: structured, tokenized, content-first
- Main font style: `font.family.primary=Noto Sans KR`, `font.family.stack=Noto Sans KR, sans-serif, Arial, Helvetica, sans-serif`, `font.size.base=16px`, `font.weight.base=400`, `font.lineHeight.base=24px`
- Typography scale: `font.size.xs=14px`, `font.size.sm=16px`, `font.size.md=18px`, `font.size.lg=24px`, `font.size.xl=48px`
- Color palette: `color.text.primary=#171717`, `color.text.secondary=lab(35.6337 -1.58697 -10.8425)`, `color.text.tertiary=lab(7.78673 1.82345 -15.0537)`, `color.text.inverse=lab(48.0876 -2.03595 -16.5814)`, `color.surface.base=#000000`, `color.surface.muted=#ffffff`, `color.surface.raised=#6366f1`, `color.surface.strong=#f8fafc`, `color.border.muted=lab(91.7353 -0.998765 -4.76968)`
- Spacing scale: `space.1=4px`, `space.2=6px`, `space.3=8px`, `space.4=10px`, `space.5=12px`, `space.6=16px`, `space.7=20px`, `space.8=24px`
- Radius/shadow/motion tokens: `radius.xs=6px`, `radius.sm=8px`, `radius.md=32px`, `radius.lg=16777200px` | `shadow.1=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.1) 0px 1px 3px 0px, rgba(0, 0, 0, 0.1) 0px 1px 2px -1px`, `shadow.2=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, oklab(0.585387 0.0253055 -0.202469 / 0.25) 0px 10px 15px -3px, oklab(0.585387 0.0253055 -0.202469 / 0.25) 0px 4px 6px -4px`, `shadow.3=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, oklab(0.585387 0.0253055 -0.202469 / 0.3) 0px 10px 15px -3px, oklab(0.585387 0.0253055 -0.202469 / 0.3) 0px 4px 6px -4px` | `motion.duration.instant=150ms`, `motion.duration.fast=200ms`

## Accessibility
- Target: WCAG 2.2 AA
- Keyboard-first interactions required.
- Focus-visible rules required.
- Contrast constraints required.

## Writing Tone
Concise, confident, implementation-focused.

## Rules: Do
- Use semantic tokens, not raw hex values, in component guidance.
- Every component must define states for default, hover, focus-visible, active, disabled, loading, and error.
- Component behavior should specify responsive and edge-case handling.
- Interactive components must document keyboard, pointer, and touch behavior.
- Accessibility acceptance criteria must be testable in implementation.

## Rules: Don't
- Do not allow low-contrast text or hidden focus indicators.
- Do not introduce one-off spacing or typography exceptions.
- Do not use ambiguous labels or non-descriptive actions.
- Do not ship component guidance without explicit state rules.

## Guideline Authoring Workflow
1. Restate design intent in one sentence.
2. Define foundations and semantic tokens.
3. Define component anatomy, variants, interactions, and state behavior.
4. Add accessibility acceptance criteria with pass/fail checks.
5. Add anti-patterns, migration notes, and edge-case handling.
6. End with a QA checklist.

## Required Output Structure
- Context and goals.
- Design tokens and foundations.
- Component-level rules (anatomy, variants, states, responsive behavior).
- Accessibility requirements and testable acceptance criteria.
- Content and tone standards with examples.
- Anti-patterns and prohibited implementations.
- QA checklist.

## Component Rule Expectations
- Include keyboard, pointer, and touch behavior.
- Include spacing and typography token requirements.
- Include long-content, overflow, and empty-state handling.
- Include known page component density: links (31), buttons (13), cards (12), navigation (3), lists (3), inputs (1).

- Extraction diagnostics: Audience and product surface inference confidence is low; verify generated brand context.

## Quality Gates
- Every non-negotiable rule must use "must".
- Every recommendation should use "should".
- Every accessibility rule must be testable in implementation.
- Teams should prefer system consistency over local visual exceptions.

Step 2. DESIGN.md 또는 SKILL.md 선택하기

추출 후 두 가지 출력 모드를 고를 수 있다.

모드	언제 쓰나	특징
DESIGN.md	프로젝트에 디자인 문서로 두고 싶을 때	사람이 읽기 좋은 마크다운. AI가 컨텍스트로 통째 읽는 용도
SKILL.md	Claude 같은 AI 도구의 스킬로 등록하고 싶을 때	YAML frontmatter(name, description)가 붙어 스킬 등록에 바로 쓸 수 있는 형태

처음 쓴다면 DESIGN.md로 시작하는 게 낫다.

가장 범용적이고, Claude Code / Cursor / Codex 어디에나 붙일 수 있다.

ex) skills.md 로도 추출 가능하니 확인만 해보자.

- 추출한 skills.md 원문

---
name: design-system-goddaehee-hub
description: Creates implementation-ready design-system guidance with tokens, component behavior, and accessibility standards. Use when creating or updating UI rules, component specifications, or design-system documentation.
---

<!-- TYPEUI_SH_MANAGED_START -->

# GodDaeHee Hub

## Mission
Deliver implementation-ready design-system guidance for GodDaeHee Hub that can be applied consistently across content site interfaces.

## Brand
- Product/brand: GodDaeHee Hub
- URL: https://goddaehee.co.kr/
- Audience: readers and knowledge seekers
- Product surface: content site

## Style Foundations
- Visual style: structured, accessible, implementation-first
- Main font style: `font.family.primary=Noto Sans KR`, `font.family.stack=Noto Sans KR, sans-serif, Arial, Helvetica, sans-serif`, `font.size.base=16px`, `font.weight.base=400`, `font.lineHeight.base=24px`
- Typography scale: `font.size.xs=14px`, `font.size.sm=16px`, `font.size.md=18px`, `font.size.lg=24px`, `font.size.xl=48px`
- Color palette: `color.text.primary=#171717`, `color.text.secondary=lab(35.6337 -1.58697 -10.8425)`, `color.text.tertiary=lab(7.78673 1.82345 -15.0537)`, `color.text.inverse=lab(48.0876 -2.03595 -16.5814)`, `color.surface.base=#000000`, `color.surface.muted=#ffffff`, `color.surface.raised=#6366f1`, `color.surface.strong=#f8fafc`, `color.border.muted=lab(91.7353 -0.998765 -4.76968)`
- Spacing scale: `space.1=4px`, `space.2=6px`, `space.3=8px`, `space.4=10px`, `space.5=12px`, `space.6=16px`, `space.7=20px`, `space.8=24px`
- Radius/shadow/motion tokens: `radius.xs=6px`, `radius.sm=8px`, `radius.md=32px`, `radius.lg=16777200px` | `shadow.1=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.1) 0px 1px 3px 0px, rgba(0, 0, 0, 0.1) 0px 1px 2px -1px`, `shadow.2=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, oklab(0.585387 0.0253055 -0.202469 / 0.25) 0px 10px 15px -3px, oklab(0.585387 0.0253055 -0.202469 / 0.25) 0px 4px 6px -4px`, `shadow.3=rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, oklab(0.585387 0.0253055 -0.202469 / 0.3) 0px 10px 15px -3px, oklab(0.585387 0.0253055 -0.202469 / 0.3) 0px 4px 6px -4px` | `motion.duration.instant=150ms`, `motion.duration.fast=200ms`

## Accessibility
- Target: WCAG 2.2 AA
- Keyboard-first interactions required.
- Focus-visible rules required.
- Contrast constraints required.

## Writing Tone
concise, confident, implementation-focused

## Rules: Do
- Use semantic tokens, not raw hex values in component guidance.
- Every component must define required states: default, hover, focus-visible, active, disabled, loading, error.
- Responsive behavior and edge-case handling should be specified for every component family.
- Accessibility acceptance criteria must be testable in implementation.

## Rules: Don't
- Do not allow low-contrast text or hidden focus indicators.
- Do not introduce one-off spacing or typography exceptions.
- Do not use ambiguous labels or non-descriptive actions.

## Guideline Authoring Workflow
1. Restate design intent in one sentence.
2. Define foundations and tokens.
3. Define component anatomy, variants, and interactions.
4. Add accessibility acceptance criteria.
5. Add anti-patterns and migration notes.
6. End with QA checklist.

## Required Output Structure
- Context and goals
- Design tokens and foundations
- Component-level rules (anatomy, variants, states, responsive behavior)
- Accessibility requirements and testable acceptance criteria
- Content and tone standards with examples
- Anti-patterns and prohibited implementations
- QA checklist

## Component Rule Expectations
- Include keyboard, pointer, and touch behavior.
- Include spacing and typography token requirements.
- Include long-content, overflow, and empty-state handling.

## Quality Gates
- Every non-negotiable rule must use "must".
- Every recommendation should use "should".
- Every accessibility rule must be testable in implementation.
- Prefer system consistency over local visual exceptions.

<!-- TYPEUI_SH_MANAGED_END -->

Step 3. AI 도구에 연결하기

Download 버튼으로 파일을 받아 프로젝트 루트에 놓으면 된다.

v0.3.0부터는 팝업 안에 Claude Code / Codex / Cursor용 Quick Install 버튼이 생겨서 이 단계가 더 빨라졌다.

ex)

- 원하는 프로젝트 선택

- Design.md 파일을 생성해줄 줄 알았는데

- skill을 설치해 주었다.

- 차라리 난 DESIGN.md파일로 다운로드 하여 루트 경로에 추가해 보았다.

- DESIGN.md파일을 내 프로젝트 경로에 추가

파일을 루트에 둔 뒤 AI 도구에 이렇게 지시하면 된다:

DESIGN.md 파일을 참고해서 헤더와 버튼 스타일을 맞춰줘

참고: AI 도구가 DESIGN.md를 자동으로 읽는지는 도구와 설정마다 다르다. 자동으로 안 읽힌다면 프롬프트에서 "DESIGN.md 파일 참고해서"라고 명시적으로 언급하는 게 가장 확실하다.

4. 시나리오별 활용법

Claude Code · Codex · Cursor에 물리기

가장 단순한 사용법은 다운로드한 DESIGN.md를 프로젝트 루트에 두는 것이다.

DESIGN.md 포맷 자체가 프로젝트 파일로 읽히도록 설계되어 있어, Claude Code/Cursor/Windsurf 같은 도구에서 참조하기 쉽다. 다만 실제로 자동 컨텍스트에 포함되는지는 도구와 설정에 따라 달라질 수 있다.

Google Stitch에 연결하기

manifest의 description이 직접 Google Stitch를 명시한다. 다만 이 확장이 Stitch에 직접 import되는 연동 흐름까지 보여주지는 않는다. 안전하게 말하면 DesignMD가 만든 DESIGN.md를 Stitch 중심 워크플로에서 보조 디자인 명세로 활용할 수 있다는 정도다.

TypeUI 스킬 풀과 결합

Creative Tim 블로그의 워크플로 가이드에 따르면 TypeUI CLI는 npx typeui.sh pull [slug] 명령으로 큐레이션된 스킬 파일을 프로젝트에 내려받는다. 이후 AI 에이전트가 자동으로 그 파일을 읽어 디자인 시스템을 적용한다.

Chrome 확장은 정확히 그 반대 방향이다. 기존 웹사이트에서 스킬 파일을 역방향 추출한다. 두 도구를 같이 쓰면 "큐레이션된 스타일을 받아 쓰는 풀"과 "내가 좋아하는 사이트에서 추출하는 풀"을 모두 갖게 된다.

시나리오 A: 피그마 없이 일관된 화면 만들기

1인 개발자가 SaaS 랜딩 페이지를 만든다고 하자. 디자이너가 없고 피그마도 안 쓴다. 본인이 좋아하는 레퍼런스 사이트에서 확장을 누르고 DESIGN.md를 다운받는다. 그 파일을 프로젝트 루트에 두고 Claude Code에 "이 디자인 시스템을 따라 헤더와 가격표 섹션을 만들어줘"라고 지시한다.

이때 추출 결과의 siteProfile이 productSurface: marketing, audience: business, confidence: medium으로 나오면, 마크다운의 Mission 섹션은 자동으로 "marketing surface" 기준의 가이드를 생성한다. 색상 팔레트가 5개 이상이면 시각 스타일도 "clean, functional, implementation-oriented"로 라벨링되어 들어간다.

DESIGN.md를 참고해서 헤더, 히어로 섹션, 가격표를 만들어줘. 색상과 폰트는 이 파일 기준으로 맞춰줘.

시나리오 B: 바이브 코딩 중 디자인 일관성 유지

이미 만든 사이트의 톤을 새 화면이 깨지 않게 하고 싶을 때, 본인 사이트에서 확장을 한 번 돌려 DESIGN.md를 갱신한다. 이를 Cursor의 컨텍스트에 넣어 두면, 새 화면을 만들 때 기존 토큰을 다시 쓰는 빈도가 올라간다. 이는 DESIGN.md 포맷이 명시적으로 의도하는 "에이전트가 프로젝트 루트에서 직접 읽는다" 시나리오와 일치한다.

DESIGN.md의 color.text.primary와 spacing 토큰을 기준으로 새 대시보드 카드 컴포넌트 만들어줘.

시나리오 C: SKILL.md로 에이전트 큐 만들기

DESIGN.md 모드 대신 SKILL.md 모드로 출력하면 frontmatter의 name, description이 스킬 등록용 메타데이터로 쓰일 수 있다. Claude 같은 도구의 스킬 시스템에 맞게 배치해두면, 같은 디자인 명세를 여러 프로젝트에서 재사용 가능한 스킬로 관리하기 쉬워진다.

SKILL.md에 정의된 디자인 시스템을 기반으로 신규 프로젝트의 버튼, 카드, 네비게이션 컴포넌트를 생성해줘.

5. 이것만 알고 쓰자 (주의사항)

CSS 변수 원본은 못 가져온다

이 확장은 브라우저가 최종적으로 계산한 값(hex 색상, px 단위)만 읽는다. 원본 디자인 시스템이 --color-primary: #3b82f6처럼 변수로 정의되어 있어도, 추출 결과에는 그냥 color.text.primary: #3b82f6으로 나온다. 시각적 외형을 따라가기엔 충분하지만, 원본 토큰 구조 그대로를 복원하지는 못한다.

늦게 그려지는 요소는 직접 띄우고 Refresh

SPA 라우터로 늦게 그려지거나, 모달처럼 처음엔 숨겨진 요소는 추출 시점에 잡히지 않는다. 원하는 화면 상태를 먼저 만들어 두고 팝업의 Refresh를 다시 누르면 된다.

결과물은 출발점이지 정답이 아니다

공식 문서 어디에도 "정확도 N%"라는 수치는 없다. 나도 직접 확인하지 못했다. 추출 결과를 바로 운영에 투입하기보다는, 한 번 훑어보고 필요한 부분을 손봐서 쓰는 게 안전하다.

6. 트러블슈팅 Q&A

Q1. 추출 결과가 거의 비어 있다

isVisible() 검증이 모든 요소를 걸러냈을 가능성이 높다. SPA에서 첫 화면이 비어 있는 상태로 추출됐거나, display:none 요소가 많은 페이지가 그렇다. 화면을 충분히 그린 뒤 팝업의 Refresh를 다시 누르고, 모달이 들어간 디자인이라면 모달을 띄운 채로 다시 추출한다.

Q2. 폰트가 시스템 기본 폰트로 잘못 잡힌다

사용자 컴퓨터에 해당 웹폰트가 설치돼 있지 않으면 시스템 폴백 폰트가 computed style에 잡힌다. v0.3.0에서 폰트 패밀리 추출 로직이 보강되었지만, 근본 한계는 computed 기반이라는 점이다. mainFontStyle.familyStack을 확인하면 폴백 체인 전체가 들어가 있는지 점검할 수 있다.

Q3. 특정 사이트에서 확장이 동작하지 않는다

service-worker가 chrome:// URL에서의 추출을 차단한다. 확장 페이지, 크롬 설정 페이지, 일부 내부 페이지에서는 의도적으로 동작하지 않는다. 또 activeTab 권한 모델 때문에 백그라운드 탭에서는 동작하지 않으니, 추출하려는 탭을 활성 상태로 두고 아이콘을 눌러야 한다.

Q4. siteProfile의 confidence가 항상 low로 나온다

score >= 5 AND gap >= 1.4라는 high 임계값이 까다롭기 때문이다. 1·2위 점수 격차가 좁은 페이지(예: 마케팅과 SaaS가 섞인 메인 페이지)에서는 medium 이하가 자연스럽다. confidence가 low여도 productSurface/audience 1위 라벨은 계속 채워지므로, 그 라벨을 참고하되 너무 단정적으로 해석하지 않는 정도로 사용하면 된다.

Q5. Manifest V3 배경 워커 종료 후 동작이 끊긴다

MV3 service-worker는 idle 상태에서 종료된다. 다행히 이 확장의 통신은 사용자 클릭 → RUN_EXTRACTION 메시지 단발성이라 종료가 큰 문제가 되지 않는다. 다만 팝업을 닫지 말고 결과 다운로드까지 마치는 편이 안전하다.

7. 결론: 언제 쓰고, 언제 쓰지 않는가

DesignMD Style Extractor는 v0.1.0(2026-04-15)부터 v0.4.0(2026-04-17)까지 사흘에 걸쳐 네 번 릴리스된 프로젝트다.

v0.2.0에서는 보안 면에서 tabs 권한이 제거됐고, v0.3.0에서는 Quick Install 버튼과 폰트 추출이 보강됐으며, v0.4.0에서는 에셋 폴더 재구성과 manifest 정보 업데이트가 이루어졌다.

짧은 출시 사이클과 작은 배포 크기가 보여주는 것은 범위가 비교적 좁다는 점이다. 여러 문제를 한꺼번에 풀기보다, 기존 페이지의 스타일을 추출해 DESIGN.md/SKILL.md로 만드는 한 가지 흐름에 집중한 47.06 KiB짜리 단일 목적 확장에 가깝다.

도입 결정 매트릭스

상황	권장 여부	이유
디자이너 없는 1인 개발자가 레퍼런스 톤을 따라가고 싶다	적합	클릭 1회로 시작점 확보
Claude Code/Cursor/Stitch로 바이브 코딩 중이다	적합	manifest가 명시적으로 이들과의 연동을 가정
정확한 디자인 토큰 원본을 그대로 가져와야 한다	비적합	computed 값만 수집, CSS 변수 원본은 손실
동적 렌더링이 많은 SPA에서 한 번에 모든 화면을 추출	비적합	로드 시점 가시 요소만 표본
결과물을 그대로 운영에 바로 투입한다	비적합	정확도 보장 없음, 검수 단계 필요

DesignMD가 정확히 노린 자리는 "AI에게 넘길 디자인 명세를 누가 만드는가"라는 upstream 공백이다. 디자이너가 있고 토큰 시스템이 정착된 팀에는 보조 도구지만, 그렇지 않은 1인 개발자·바이브 코더에게는 빠진 단계 하나를 메우는 47.06 KiB짜리 다리다.

참고자료

저작자표시 비영리 변경금지 (새창열림)

'AI > Design' 카테고리의 다른 글

DESIGN.md : Google Stitch가 도입한 DESIGN.md - DESIGN.md 도입 배경부터 적용해보기(VoltAgent awesome-design-md 컬렉션 활용 가이드) (1)	2026.04.23

Contents

당신이 좋아할만한 콘텐츠

DESIGN.md : Google Stitch가 도입한 DESIGN.md - DESIGN.md 도입 배경부터 적용해보기(VoltAgent awesome-design-md 컬렉션 활용 가이드) 2026.04.23

새소식