구글이 Stitch에서 쓰던 DESIGN.md 초안 명세를 오픈소스로 공개했다. 핵심은 단순하다. 디자인 규칙을 마크다운 한 파일에 담아, AI 에이전트가 색상·타이포·간격·컴포넌트 의도를 읽고 UI를 더 일관되게 만들게 하겠다는 것이다.12
하지만 진짜 질문은 "이게 영리한가"가 아니다. 슬랙에서 반복되는 디자인 설명, 피그마를 보고 각자 다르게 해석하는 구현, 컴포넌트마다 조금씩 다른 radius와 spacing을 이 파일 하나가 실제로 줄여주느냐다. 지금 중요한 이유도 여기에 있다. AI 코딩 도구가 늘어난 지금, 디자인의 문제는 더 이상 "누가 예쁘게 그리느냐"만이 아니라 "누가 같은 규칙을 계속 재사용하게 만드느냐"로 바뀌고 있기 때문이다.
DESIGN.md는 디자인 시스템이 아니라, 에이전트용 인터페이스에 가깝다
과장부터 걷어내자. DESIGN.md는 완전한 디자인 시스템의 대체재가 아니다.
구글이 공개한 저장소를 보면, 이 포맷은 YAML 프런트매터에 토큰을 넣고, 본문 마크다운에는 그 토큰의 의도와 적용 맥락을 적는 구조다. CLI도 함께 제공돼 lint, diff, export를 지원하고, 접근성 대비나 깨진 토큰 참조까지 점검할 수 있다.2 이건 분명 "아무 프롬프트나 잘 써보자" 수준보다 한 단계 진전된 접근이다.
다만 여기서 해결되는 것은 주로 "값의 일관성"이다. 예를 들어 primary color가 무엇인지, 버튼 텍스트 대비가 WCAG 기준에 맞는지, spacing scale을 무엇으로 잡을지 같은 문제다. 반면 "언제 primary 버튼을 쓰는가", "이 상태에서 카드보다 리스트가 맞는가", "복잡한 테이블 UX를 어떤 패턴으로 통일할 것인가" 같은 문제는 여전히 디자인 시스템, 컴포넌트 라이브러리, 그리고 팀의 의사결정이 담당한다.
즉, DESIGN.md를 디자인 시스템으로 보면 실망하고, 사람·디자이너·코딩 에이전트 사이의 API 계약서로 보면 꽤 쓸모 있어진다. 값과 의도를 한 파일에 고정해 두고, 에이전트가 매번 추측하지 않게 만드는 장치라는 뜻이다.
효과는 팀의 깔끔함이 아니라, 팀의 지저분함에서 판가름 난다
이 포맷이 좋은지 보려면 잘 정리된 팀이 아니라 어수선한 팀에 넣어봐야 한다.
혼자 만드는 사이드 프로젝트나 디자이너 없는 초기 스타트업에서는 효과가 바로 난다. 색상, 타이포, radius, 버튼 스타일만 정리해도 AI가 만드는 화면의 드리프트가 줄어든다. 실제로 커뮤니티에는 수십~100개 넘는 DESIGN.md 예시와 라이브러리가 이미 쌓이고 있고, "프로젝트 루트에 두고 AI에게 읽게 한다"는 사용 패턴도 빠르게 퍼지고 있다.34
하지만 팀이 커질수록 먼저 드러나는 건 포맷의 힘보다 팀 운영의 허점이다. 컴포넌트 이름이 제각각이면 button-primary가 누구에게는 CTA 버튼이고, 누구에게는 폼 제출 버튼이다. 디자인 토큰은 있는데 실제 코드베이스가 하드코딩 색상으로 가득하면, 파일 하나 추가한다고 일관성이 생기지 않는다. 결정권자가 없으면 더 심각하다. 에이전트가 DESIGN.md를 따라도, 리뷰어마다 "우리 스타일 아닌데?"라고 말하면 다시 슬랙 정치가 시작된다.
여기서 현실은 이렇다. DESIGN.md는 혼란을 정리해주는 도구이지, 혼란의 원인을 없애는 도구는 아니다. 네이밍 규칙, 컴포넌트 소유권, 토큰 반영 방식이 없는 팀에서는 좋은 프롬프트 파일 이상이 되기 어렵다.
도입 전 30분이면 된다: 같은 화면을 두 번 만들어보라
도입 판단은 철학이 아니라 비교 실험으로 해야 한다.
가장 안전한 방법은 한 화면만 고르는 것이다. 예를 들어 설정 페이지나 가격 카드 같은 반복 UI를 정한다. 먼저 DESIGN.md 없이 AI 에이전트에게 구현하게 하고, 다음에는 동일한 요구사항에 DESIGN.md를 넣고 다시 생성한다. 그리고 네 가지만 비교하면 된다.
첫째, 색상·간격·타이포 값이 얼마나 덜 흔들리는가.
둘째, 수정 요청 횟수가 얼마나 줄었는가.
셋째, 디자이너나 리뷰어가 남기는 코멘트가 "감각"에서 "명시된 규칙"으로 바뀌는가.
넷째, 이 파일의 내용을 Tailwind 토큰이나 기존 디자인 토큰 체계로 연결할 수 있는가.
구글 저장소는 export로 Tailwind나 DTCG 포맷 변환도 지원한다.2 이 점은 꽤 중요하다. DESIGN.md가 진짜로 유용하려면 프롬프트용 문서에 머물지 않고, 실제 코드 토큰 체계와 연결돼야 하기 때문이다. 반대로 이 연결이 안 되면 결국 "AI에게만 보이는 스타일 가이드"가 되고, 장기적으로는 또 하나의 문서 부채가 된다.
더 큰 변화는 파일 형식이 아니라, 디자인이 실행 가능한 정책이 된다는 점이다
이번 공개를 단순히 "마크다운 디자인 파일"로 보면 작아 보인다. 하지만 더 큰 변화는 디자인이 시각 자료에서 실행 가능한 정책으로 이동하고 있다는 데 있다.
구글은 DESIGN.md를 통해 에이전트가 색상의 "값"뿐 아니라 그 색이 무엇을 위한 것인지까지 알 수 있게 하려 한다.1 이것이 중요한 이유는, 앞으로 디자인 산출물이 피그마 화면보다 "기계가 읽을 수 있는 의도"에 더 가까워질 수 있어서다. 사람은 화면을 보고 이해하고, 에이전트는 정책을 읽고 구현하는 흐름이다.
물론 아직은 알파다. 구글도 포맷, 스키마, CLI가 계속 바뀔 수 있다고 밝히고 있다.2 그래서 지금 당장 전사 표준으로 걸기엔 이르다. 다만 하나는 분명하다. 앞으로의 디자인 운영은 보기 좋은 라이브러리만으로는 부족하고, 에이전트가 따를 수 있는 규칙 표현이 필요해진다.
지금 이 변화에 가장 민감해야 할 사람은 AI 코딩을 이미 쓰고 있는데 UI 일관성 때문에 고생하는 팀이다. 반대로 피그마 협업, 디자인 리뷰, 고급 컴포넌트 거버넌스가 더 중요한 조직이라면 DESIGN.md는 대체재가 아니라 보조 레이어로 보는 편이 맞다. 판단 기준은 간단하다. 이 파일이 당신 팀의 디자인 혼선을 "설명 가능한 규칙"으로 바꿔주는가. 그게 안 되면 유행이고, 되면 워크플로우다.
원문 참고: 5
참고
1Stitch app's DESIGN.md format is now open-source for designers
4DESIGN.md - Design Systems for AI Coding
5Google's open-source DESIGN.md gives AI agents a prompt-ready blueprint for brand-consistent design
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.