IT 및 AI

Atlassian DESIGN.md - Google이 만들고 Atlassian이 검증한 'AI Slop' 해결사

푸른강아지 2026. 7. 6. 14:52
반응형

Atlassian DESIGN.md — Google이 만들고 Atlassian이 검증한 'AI Slop' 해결사의 가능성과 한계

핵심 요약:
AI가 생성하는 UI가 모두 비슷해 보이는 'Slop' 문제를 해결하기 위해 Google의 Stitch 도구에서 시작된 DESIGN.md 포맷이 주목받고 있다. 브랜드 디자인 시스템의 핵심 요소를 단일 마크다운 파일로 포팅하여 AI 프롬프트에 포함시키면, 생성되는 UI가 브랜드 정체성을 유지한다는 아이디어다. Atlassian이 실제로 이를 테스트한 결과, 1회성 프로토타입에서는 효과적이었지만, 프로덕션 환경에서는 MCP 서버 방식보다 92% 더 많은 토큰을 소비하는 등 한계도 분명히 드러났다.

📌 'Slop'의 시대, DESIGN.md의 등장

AI가 사용자 인터페이스를 생성하면 어떤가? 그라데이션 버튼, 대문자 제목, 제네릭 카드 레이아웃, 아무도 요청하지 않은 호버 애니메이션 — 결과물은 기능적으로는 동작하지만, 어디서 본 듯한 디자인이 반복된다. 디자인 커뮤니티는 이 현상을 'Slop'이라고 부르기 시작했다. 밥맛 없는 죽처럼, 기능은 하지만 정체성은 없는 출력물을 뜻하는 신조어다.

문제의 원인은 명확하다. 브랜드와 컴포넌트에 대한 맥락 없이 AI는 학습 데이터의 평균을 출력할 수밖에 없다. Generic in, generic out.

Google의 Stitch 디자인 도구 팀은 이 문제를 해결하기 위해 DESIGN.md라는 오픈소스 마크다운 포맷을 개발했다. 디자인 시스템의 핵심 요소(디자인 토큰, 컴포넌트 사양, 디자인 의도)를 단일 이식 가능한 파일로 정의하여, AI가 브랜드 정체성을 유지한 UI를 생성할 수 있게 하는 것이 목표다.

🏗️ DESIGN.md의 구조

DESIGN.md는 두 부분으로 구성된다:

섹션 내용 대상
머신 리더블 (전반부) 디자인 토큰(YAML 형식): 색상, 간격, 타이포그래피, 그림자 등 AI 에이전트
휴먼 리더블 (후반부) 디자인 원칙, 컴포넌트 사용 가이드, 디자인 의도(design rationale) 사람 + AI

철학적으로 DESIGN.md는 디자인 시스템의 전체 명세가 아닌 '의도(intent)'를 캡처하는 데 초점을 맞춘다. 모든 구현 세부사항을 담으려 하지 않고, 브랜드의 시각적 정체성을 전달하는 데 필요한 최소한의 정보를 이식 가능한 형태로 제공한다.

🧪 Atlassian의 실제 테스트 결과

Atlassian 디자인 시스템 팀은 Team '26 컨퍼런스 키노트 데모에서 DESIGN.md를 실제 테스트했다. Figma Make가 Teamwork Graph를 사용해 커스텀 대시보드를 생성하는 데모에서, DESIGN.md를 프롬프트 컨텍스트로 추가한 결과를 비교했다.

결과: 1회성 프로토타입에서는 성공적이었다. DESIGN.md를 포함한 결과물은 제네릭 'Slop'에서 벗어나 Atlassian 제품처럼 보이는 UI를 생성했다. 예상된 색상, 간격, 형태, 타이포그래피가 적용되었고, 컴포넌트의 계층감(elevation)도 시스템에 맞게 적용되었다.

그러나 프로덕션 규모로 확장했을 때는 다른 결과가 나왔다:

방식 평균 토큰 평균 시간 평균 턴
컨텍스트 없음 4.20M 6m 19s 43
ADS MCP (추천) 3.75M 5m 01s 35.1
ADS Skill 4.43M 5m 23s 36
DESIGN.md 7.21M 6m 46s 45.3

DESIGN.md는 MCP 방식보다 약 92% 더 많은 토큰을 소비했고, 결과물의 디자인 시스템 정합성은 MCP의 80% 대비 약 30%에 그쳤다. 토큰 소비 변동성도 2.7배나 높았다.

🔧 DESIGN.md의 3가지 근본적 한계

Atlassian의 테스트에서 드러난 한계는 다음과 같다:

1. 모든 컨텍스트를 한 번에 로드

MCP 서버는 필요한 컴포넌트의 가이드만 온디맨드(on-demand)로 가져온다. 아이콘 수백 개, 방대한 시맨틱 디자인 토큰 중에서 실제로 필요한 것만 선택적으로 로드할 수 있다. 반면 DESIGN.md는 매번 모든 내용을 한 번에 로드하므로, 비용이 높고 응답이 느리며 컨텍스트 트렁케이션이 더 빨리 발생한다.

2. 파일 크기 제약으로 인한 정보 손실

Atlassian의 전체 디자인 시스템 가이드는 약 2.5MB지만, DESIGN.md로 축소하면 80KB(약 19,800 토큰)가 된다. 이 과정에서 50개 이상의 컴포넌트 사용 가이드, 다양한 디자인 토큰, 기초 가이드 등이 상당수 제거되었다. 빠진 맥락을 AI가 스스로 채우기 위해 컴포넌트 구현체를 읽는 부수 작업이 발생한다.

3. 기존 컴포넌트 활용보다 '처음부터 새로 만들기' 유도

DESIGN.md는 디자인 시스템의 의도를 설명하지만, "이 버튼을 직접 스타일링하지 말고, 기존 컴포넌트를 import 해서 사용하라"는 지침을 효과적으로 전달하지 못한다. 결과적으로 기존 라이브러리를 우회하여 기술 부채(tech debt)를 생성할 위험이 있다.

🔮 전망 — DESIGN.md는 누구를 위한 것인가

DESIGN.md의 진정한 가치는 MCP 서버나 복잡한 인프라 없이, AI에게 브랜드 맥락을 전달해야 하는 상황에서 빛을 발한다. Atlassian의 키노트 데모처럼 외부 도구(Figma Make)와 협업하거나, 새 프로젝트를 처음부터 시작할 때는 완벽한 선택이다.

Atlassian의 결론은 현실적이다: "이 블로그는 논문이 아니며, 모델과 환경에 따라 결과는 달라진다." DESIGN.md는 프로토타이핑과 1회성 생성에 탁월하지만, 프로덕션 규모의 애플리케이션 개발에서는 MCP 서버나 Skills 방식이 더 효율적이다.

Google이 만든 DESIGN.md 포맷은 오픈소스 생태계로 공개되어 있으며, designmd.co 같은 사이트에서 다양한 기업의 DESIGN.md 파일을 확인할 수 있다. 디자인 시스템이 AI에 '읽히는' 시대가 왔고, DESIGN.md는 그 시작을 알리는 신호탄이다.

 
💡 한 줄 요약: Google이 만든 DESIGN.md는 AI Slop 문제를 해결하기 위한 이식 가능한 디자인 시스템 포맷으로, 1회성 프로토타입에서는 브랜드 정체성을 효과적으로 전달하지만, Atlassian의 실제 테스트 결과 프로덕션 환경에서는 MCP 서버 방식 대비 92% 더 많은 토큰을 소비하고 정합성도 낮은 것으로 나타났다. '비용 대비 이식성'의 트레이드오프를 이해하고 적절한 사용처를 선택하는 것이 중요하다.
반응형