AI프롬프트 효율화 명세서, DESIGN.md 정체와 활용법

AI 코딩 도구로 작업하다 보면 같은 프로젝트인데 화면마다 색상과 폰트가 달라지는 경험, 한 번쯤 겪어봤을 겁니다. 구글이 2026년 4월 공개한 DESIGN.md는 이 문제를 단 한 줄로 해결하는 AI프롬프트 효율화 명세서입니다. 마크다운 파일 한 장으로 AI에게 디자인 일관성을 보장하는 방법, 그리고 왜 이게 W3C 국제 표준과 연결되는지까지 정리해봤습니다.

 

AI한테 디자인 설명하다 지친 적 있으신가요?

Claude Code나 Cursor로 프론트엔드 작업을 해본 개발자라면 이런 상황이 낯설지 않을 겁니다. 로그인 화면은 인디고 계열로 만들었는데, 다음 날 대시보드를 만들면 보라색이 되어 있고, 그다음 날 설정 화면에는 회색 버튼이 등장합니다. 같은 프로젝트, 같은 AI 도구인데 결과물이 매번 다릅니다.

 

이건 AI 잘못이 아닙니다. 우리가 매번 다르게 말했기 때문입니다. "파란색 계열로 해줘"라고 했다가, "모던한 느낌으로"라고 했다가, "이전에 쓰던 색 기억해?"라고 물어보기도 하죠. AI는 기억이 없으니 매번 새롭게 해석할 수밖에 없습니다.

 

비유하자면 인테리어 업자에게 도면도 색상표도 없이 말로만 시공을 맡기는 것과 같습니다. "거실은 따뜻한 분위기로, 주방은 모던하게"라고만 하면 업자마다, 날마다 해석이 달라지는 건 당연합니다. 반면 시방서 한 장이 있으면 어떤 업자가 와도 같은 결과가 나옵니다.

 

AI 코딩 에이전트에게도 그 시방서가 필요했습니다. 그리고 구글이 그 포맷을 공식적으로 만들었습니다. 이름이 DESIGN.md입니다.

 

DESIGN.md가 뭔가요? AI용 디자인 시방서

한 줄로 정의하면 이렇습니다. AI 코딩 에이전트에게 주는 디자인 시방서. 마크다운 파일 한 장으로 프로젝트의 색상, 폰트, 간격, 컴포넌트 스타일을 한 번 정의해두면 AI가 이 파일을 참조해서 일관된 UI를 만들어냅니다.

 

구글의 AI UI 디자인 도구인 Stitch가 내부적으로 쓰던 포맷입니다. 2026년 4월 21일 Apache 2.0 라이선스로 오픈소스로 공개하면서 누구나 사용할 수 있게 됐습니다.

 

"A format specification for describing a visual identity to coding agents. DESIGN.md gives agents a persistent, structured understanding of a design system."

출처: GitHub 공식 저장소

파일 구조는 이중 구조로 되어 있습니다. 상단에는 YAML 프론트매터가 있는데, 컴퓨터가 읽는 디자인 토큰입니다. HEX 코드, px 값, 폰트 패밀리처럼 정확한 숫자 데이터가 들어갑니다. 하단에는 마크다운 본문이 있는데, 사람이 읽는 설계 의도입니다. "이 보라색은 강조 버튼에만 쓰세요"처럼 색상이나 타이포그래피의 맥락을 설명합니다.

 

이게 핵심 혁신입니다. 단순히 '#B8422E'라는 HEX 코드만 전달하면 AI는 임의로 판단합니다. 그런데 "Boston Clay: 상호작용의 유일한 드라이버"라는 설명이 함께 있으면, AI는 그 색을 인터랙티브 요소에만 사용합니다. 색 코드만 있을 때와 의미가 설명되었을 때의 결과물은 완전히 달라집니다.

 

8개 카테고리 구조

한식집 메뉴판이 어느 집이나 밥류, 면류, 찌개류 카테고리를 갖추고 있듯, DESIGN.md도 표준 8개 카테고리로 구조화되어 있습니다.

카테고리	내용
Overview	브랜드 성격과 디자인 철학 요약
Colors	색상 팔레트 및 각 색상의 역할
Typography	폰트 패밀리, 크기, 굵기, 줄 간격
Layout	그리드, 여백, 컨테이너 너비
Elevation & Depth	그림자, 레이어, 깊이감 표현
Shapes	버튼, 카드, 모달의 모서리 둥글기
Components	버튼, 인풋, 카드 등 UI 컴포넌트 스타일
Do's and Don'ts	해도 되는 것, 절대 안 되는 것 명시

CLAUDE.md나 .cursorrules처럼 프로젝트 폴더 최상위에 함께 존재하는 파일입니다. 이 파일들과 형제 파일로 놓이면 AI 에이전트가 코딩할 때 자동으로 참조합니다.

 

왜 게임체인저인가? W3C 국제 표준의 힘

단순히 "마크다운 파일을 프로젝트에 추가하는 것"이라면 이미 누구나 하고 있을 겁니다. DESIGN.md가 다른 이유는 세 가지입니다.

 

AI프롬프트 길이 30분의 1 단축

DESIGN.md를 적용한 실제 사용자들이 공통적으로 말하는 효과가 있습니다. 매번 30줄씩 써야 했던 디자인 설명이 단 1줄로 줄어들었다는 겁니다. "로그인 페이지 만들어줘"라는 한 문장만으로 색상, 폰트, 간격, 버튼 스타일이 전부 맞게 나옵니다. @design.md 한 줄을 AI 설정 파일에 추가하는 순간부터 이게 가능해집니다.

 

어제 만든 페이지와 오늘 만든 페이지가 같아진다

신입직원에게 사수 없이 일을 맡겨도 업무 매뉴얼 한 장이 있으면 일관된 결과물이 나오는 것처럼, AI도 DESIGN.md가 있으면 어제 생성한 UI와 오늘 생성한 UI의 색, 폰트, 간격이 동일하게 유지됩니다. 세션이 끊겨도, 다른 AI 도구를 써도, 파일 한 장이 기준이 되기 때문에 결과가 달라지지 않습니다.

 

W3C DTCG 국제 표준 채택

이게 가장 중요한 포인트입니다. DESIGN.md는 W3C DTCG(Design Tokens Community Group)의 국제 표준을 따릅니다. DTCG는 디자인 토큰, 즉 색상·간격·타이포그래피 값의 정의와 교환 방식을 표준화하는 W3C 커뮤니티 그룹으로, 2025년 10월 첫 안정 버전(v2025.10)을 발표했습니다.

 

콘센트 표준으로 생각하면 이해가 빠릅니다. 집집마다 콘센트 모양이 다르면 충전기를 따로 들고 다녀야 하듯, 디자인 데이터도 표준이 없으면 Figma에서 만든 값을 코드에서 쓰려면 손으로 일일이 옮겨야 했습니다. W3C 표준이 확립되면서 Figma, Sketch, Framer 등 10개 이상의 도구가 같은 포맷을 지원합니다. DESIGN.md가 이 표준을 채택했다는 건, 디자인 도구에서 클릭 한 번으로 export한 파일을 프로젝트에 바로 넣을 수 있다는 뜻입니다.

 

옛날에는 가게마다 한두와 말이 달라서 바가지를 썼는데, 표준 도량형이 생긴 후에는 어딜 가도 1L는 1L가 된 것과 같은 변화입니다. 디자이너, 개발자, AI가 드디어 같은 언어로 말할 수 있게 됩니다.

 

실제 워크플로우를 그려보면 이렇습니다. 디자이너가 Figma에서 디자인 시스템을 만들고 DESIGN.md로 export합니다. 개발자가 이 파일을 프로젝트 폴더에 넣습니다. 그러면 Claude Code, Cursor, GitHub Copilot 같은 AI 에이전트가 이 파일을 읽고 코딩합니다. 슬랙에서 핑퐁할 필요 없이 파일 한 장이 모두의 기준이 됩니다.

 

구분	DESIGN.md 적용 전	DESIGN.md 적용 후
AI 지시 방식	색, 폰트, 간격 매번 30줄 설명	"로그인 페이지 만들어줘" 1줄
결과 일관성	화면마다 색·폰트 제각각	모든 페이지 동일 스타일 유지
토큰 비용	매번 디자인 설명으로 낭비	파일 자동 참조로 절감
협업 효율	디자이너-개발자 슬랙 핑퐁	파일 한 장으로 싱크

 

솔직한 단점 3가지

좋은 얘기만 하면 신뢰가 가지 않죠. 단점도 있습니다. 알고 쓰면 오히려 더 잘 활용할 수 있습니다.

 

첫 번째, 아직 알파 단계입니다. 2026년 4월 공개된 만큼 아직 개발 중인 기능이 많습니다. 다크모드 토큰, 애니메이션, 반응형 규칙은 현재 미지원이고, 사양이 앞으로 변경될 가능성이 있습니다. "현재 기준"이라는 전제를 항상 달고 써야 합니다.

 

두 번째, 코드와 자동 동기화가 되지 않습니다. DESIGN.md를 먼저 작성하고 AI가 코딩했는데, 나중에 코드를 직접 수정하면 DESIGN.md는 업데이트되지 않습니다. 문서와 코드가 따로 노는 함정이 있습니다. DESIGN.md를 항상 최신 상태로 유지하는 건 결국 사람의 몫입니다.

 

세 번째, 소규모 프로젝트에는 오버스펙입니다. 1페이지짜리 토이 프로젝트에 8개 카테고리를 관리하는 건 본말전도입니다. DESIGN.md는 다음 상황에서 빛을 발합니다.

• 디자이너와 개발자가 함께 일하는 SaaS 제품
• AI 에이전트로 프론트엔드를 반복 생성하는 환경
• 브랜드 일관성이 중요한 회사 프로젝트

반대로 개인 포트폴리오 사이트나 빠르게 프로토타입만 만들어보는 환경이라면 굳이 도입할 필요는 없습니다.

 

지금 바로 시작하는 실전 3단계

처음 시작할 때 가장 많이 하는 실수가 있습니다. 빈 파일을 열고 "어디서부터 채우지?"라며 8개 카테고리를 다 완성하려다 포기하는 겁니다. 순서가 있습니다.

 

Step 1. 시안 먼저 뽑기

빈 종이에 인테리어 시방서를 쓸 수 없듯, DESIGN.md도 색과 폰트가 정해진 다음에 채워야 합니다. AI 도구로 색과 폰트 후보를 여러 시안으로 뽑아보고 마음에 드는 것을 선택하는 게 먼저입니다. 시스템을 구축하기 전에 방향을 정하는 단계입니다.

 

Step 2. 공식 사양 보면서 핵심만 채우기

8개 카테고리를 다 채우려 하지 마세요. 처음에는 꼭 필요한 것만으로 시작하는 게 훨씬 낫습니다. 메인색 1개, 강조색 1개, 글자색 1개, 배경색 1개, 경고색 1개, 폰트 2~3개면 충분합니다. 옷 사이즈 표처럼 S=95cm/165cm이라고 한 번 정의해두면 누가 봐도 같은 사이즈를 알 수 있는 것처럼, 핵심 값 몇 가지가 정해지는 것만으로 AI의 출력이 눈에 띄게 달라집니다.

 

공식 GitHub 저장소(github.com/google-labs-code/design.md)에 구조와 예시가 정리되어 있습니다. 커뮤니티 레퍼런스도 있습니다. VoltAgent의 Awesome Design.md에는 Stripe, Vercel, Notion, Linear 등 유명 브랜드 71개 이상의 DESIGN.md 파일이 공개되어 있어서 그대로 복사해서 시작할 수 있습니다.

 

Step 3. AI 설정 파일에 한 줄 추가

파일을 만들었으면 AI 에이전트에게 알려줘야 합니다.

• Claude Code: CLAUDE.md에 @DESIGN.md 추가
• Cursor: .cursorrules에 추가
• GitHub Copilot: CLI로 첫 설정 시 스펙 컨텍스트 주입

이 한 줄이 추가되는 순간부터 AI가 알아서 DESIGN.md를 읽습니다. 처음 파일을 만드는 데 약 1시간 정도 걸리지만, 이후 모든 AI 코딩 작업에 자동으로 적용됩니다.

 

AI 코딩 시대의 새로운 표준

DESIGN.md의 타임라인을 보면 속도가 상당합니다.

시기	이벤트
2025.10	W3C DTCG 디자인 토큰 사양 첫 안정 버전(v2025.10) 발표
2026.03	Google Stitch, DESIGN.md 도입 (무한 캔버스, 디자인 에이전트 업데이트)
2026.04.21	Google Labs, DESIGN.md 오픈소스(Apache 2.0) 공개. GitHub에서 누구나 사용 가능
2026.04~	VoltAgent의 Awesome Design.md 등 커뮤니티 프로젝트 급속 성장. 71개 이상 브랜드 파일 수집
2026.05 현재	Claude Code, Cursor, Copilot 등 주요 AI 에이전트 통합 진행 중 (알파 단계)

W3C 표준이 뒷받침하는 만큼, DESIGN.md는 알파 단계지만 AI 코딩 시대의 기본 파일이 될 가능성이 높습니다. 지금은 도입하는 사람이 적으니 오히려 검색 결과에서 차별화가 쉽고, 커뮤니티 반응도 빠릅니다.

 

구글 공식 블로그에서 전체 발표 내용을 확인할 수 있고(Google Labs 공식 블로그), 사양과 예시는 공식 GitHub 저장소에서 바로 확인할 수 있습니다.

 

AI한테 디자인 설명하다 가장 답답했던 게 뭔가요? 색이 매번 바뀌는 건지, 폰트가 달라지는 건지, 버튼 둥글기가 제각각인 건지. 댓글로 알려주시면 DESIGN.md로 해결할 수 있는지 같이 확인해봐요. 이 글이 유용했다면 AI 도구 쓰는 분들께 공유해주세요.