'바이브 코딩'이 일상이 된 것처럼, 이제 'AI가 UI를 만든다'는 개념도 더 이상 SF가 아니다. 그런데 여기서 오래된 난제가 하나 있다. AI가 만들어낸 UI는 그럴듯하지만, 일관성이 없다. 색상 토큰이 어긋나고, 타이포그래피 규칙이 무너지고, 새 화면을 생성할 때마다 이전 결과물과 서서히 어긋나기 시작한다. 디자인 시스템이 AI에게 '읽히지 않는' 탓이다. Google Stitch가 오픈소스로 공개한 DESIGN.md는 바로 이 간극을 겨냥한다.
DESIGN.md: 마크다운이 계약서가 되는 순간
DESIGN.md는 스타일 가이드 문서가 아니다. 정확히는 AI 에이전트와 디자인 의도 사이의 기계 가독형 계약서다. Stitch에서 내보내면 색상 토큰, 스페이싱 단위, 라운딩 규칙, 타이포그래피 스케일이 YAML 구조로 마크다운 안에 담긴다. 사람도 읽을 수 있고, Claude Code·Cursor·Gemini CLI 같은 에이전트도 읽을 수 있다. Apache 2.0 라이선스로 공개됐으니 특정 도구에 종속되지도 않는다.
dev.to에 공개된 실험 결과에 따르면, DESIGN.md만 주입했을 때 에이전트는 색상과 스페이싱은 충실히 따랐지만 레이아웃 구조는 재현하지 못했다. 이른바 '벽돌은 맞지만 집 모양은 모르는' 상태—약 60% 지점이다. 나머지 40%는 MCP가 채운다.
MCP로 에이전트에게 '눈'을 달다
Stitch를 Gemini CLI에 MCP 서버로 연결하면 상황이 달라진다. 에이전트가 스펙 파일을 읽는 것을 넘어, Stitch 프로젝트의 실제 레이아웃 데이터를 직접 쿼리할 수 있게 된다. DESIGN.md가 '규칙집'이라면, MCP 연결은 '실제 설계도면 열람권'이다. 이 두 레이어가 결합했을 때 생성 결과물의 일관성이 눈에 띄게 달라졌다는 게 실험의 핵심 관찰이다.
실용적인 시사점은 명확하다. primary 색상 토큰 하나를 수정하면 tailwind.config.js와 컴포넌트가 동시에 업데이트된다. 디자이너가 Stitch에서 수정한 내용이 코드베이스에 자동 전파되는 구조다. 디자인-개발 핸드오프 비용이 구조적으로 줄어드는 첫 번째 현실적인 사례처럼 보인다.
여기서 흥미로운 프로덕트 사고 포인트가 생긴다. 기존 디자인 시스템 워크플로우에서 가장 큰 마찰은 '컴포넌트가 소스 오브 트루스에서 이탈하는 드리프트'였다. DESIGN.md + MCP 구조는 에이전트가 항상 체크해야 할 레퍼런스를 명시적으로 갖게 함으로써, 드리프트 자체를 구조적으로 억제한다. 단순한 생성 도구가 아니라 일관성 유지 메커니즘으로서의 AI라는 관점이다.
브라우저가 AI를 내장할 때 생기는 표준화 전쟁
같은 시기, 브라우저 레이어에서는 전혀 다른 긴장이 펼쳐지고 있다. Chrome의 Prompt API는 브라우저 내장 언어 모델을 웹 API로 노출하는 시도다. 개발자가 LanguageModel.create()로 온디바이스 LLM을 호출하고, UI에 바로 AI 기능을 붙일 수 있게 된다. 백엔드 없이, API 키 없이.
그런데 Mozilla가 이 제안에 공식적으로 'negative' 입장을 표명했다. 핵심 우려는 두 가지다.
첫째, 프롬프트와 모델의 강결합 문제. 개발자가 Edge의 Phi-4-mini나 Chrome의 Gemma에 맞춰 시스템 프롬프트를 조정하면, 다른 브라우저나 모델에서는 결과 품질이 달라지거나 사이트 자체가 차단될 수 있다. Mozilla가 제시한 사례는 직관적이다—홈 자동화 알림용 시스템 프롬프트를 Gemini에 맞춰 조정했더니 다른 모델에서는 과보정이 발생했다. 한 모델의 quirk를 위한 보정이 다른 모델에게는 독이 된다.
둘째, 단일 모델 고착화의 도미노. 특정 모델의 quirk에 맞춰진 시스템 프롬프트가 웹 전반에 퍼지면, 새로운 더 나은 모델이 등장해도 기존 사이트에서 '나쁘게 보이는' 역설이 생긴다. 심지어 개발자가 model.prompt('give a single string representing your LLM ID...')로 모델을 식별하고 특정 모델 전용 분기를 만드는 패턴—이건 2000년대 초 브라우저별 코드 분기의 재현이다. 그 시절이 얼마나 괴로웠는지를 기억하는 사람이라면 이 우려가 공허하게 들리지 않을 것이다.
표준화의 타이밍 문제
Mozilla의 대안은 웹 API로 직접 출하하는 대신 Web Extension 형태로 먼저 검증하자는 것이다. 확장 설치는 사용자에게 '일반 웹 기능의 경계를 벗어난다'는 신호를 준다. 실사용 패턴을 빠르게 탐색하되, 세 브라우저 엔진이 아직 굳지 않은 의미론을 억지로 맞춰 출하하는 조율 비용을 치르지 말자는 논리다.
Chrome 측은 JSON schema·정규식 기반 응답 제약을 완화책으로 제시했다. 예측 불가능한 출력을 구조화해 모델별 핵을 줄이겠다는 것이다. Google과 Microsoft 모델 모두에서 어느 정도 호환성을 확인했다는 점도 강조한다. 그러나 Mozilla의 시각에서 이건 충분하지 않다—Google Generative AI Prohibited Uses Policy에 동의해야만 API를 쓸 수 있는 구조 자체가 웹 플랫폼의 중립성 원칙에 어긋난다는 지적도 있다.
이 논쟁의 본질은 사실 기술적 문제가 아니다. 표준화의 타이밍이다. 너무 이르게 굳히면 나쁜 패턴이 웹 전체에 고착되고, 너무 늦게 가면 사실상의 표준이 된 Chrome 독점 구현을 나머지가 복사하는 상황이 된다. EME(Encrypted Media Extensions) 논쟁이 10년 뒤 어떻게 평가됐는지를 떠올리면, 지금 이 논쟁이 가볍지 않다는 걸 알 수 있다.
두 흐름이 만나는 지점
DESIGN.md와 Prompt API 논쟁은 표면적으로 별개처럼 보이지만, 같은 질문을 공유한다. AI가 컨텍스트를 어떻게 안정적으로 유지하는가.
DESIGN.md는 에이전트에게 설계 의도를 명시적 스펙으로 제공함으로써 일관성을 확보한다. Prompt API 논쟁은 반대로, 브라우저가 AI 컨텍스트를 제공할 때 그 컨텍스트가 모델마다 달라지면 개발자가 어떤 전략을 취할 수밖에 없는지를 보여준다—그리고 그 전략이 웹 생태계를 어떻게 망가뜨릴 수 있는지를.
프론트엔드 개발자 관점에서 실용적인 결론은 이렇다. 지금 당장 할 수 있는 것은 DESIGN.md 방식처럼 AI에게 읽힐 수 있는 명시적 설계 계약을 만드는 것이다. 디자인 토큰을 YAML로 구조화하고, 컴포넌트 규칙을 에이전트가 참조할 수 있는 형태로 관리하는 것—이건 지금 당장 적용 가능한 워크플로우 개선이다.
Prompt API 표준화 논쟁은 조금 더 지켜볼 필요가 있다. Extension API 경로로 실험이 충분히 쌓인 뒤 표준화되는 시나리오가 웹 생태계 건강성 측면에서 더 낫다. 브라우저 AI를 지금 당장 프로덕션에 의존하는 코드를 짜는 것은, 적어도 현재 시점에서는 기술 부채를 선불로 사는 셈이다.
전망: '일관성 레이어'가 AI 워크플로우의 핵심 인프라가 된다
DESIGN.md가 흥미로운 이유는 도구 자체가 아니라 개념 때문이다. AI 에이전트가 UI를 생성할 때 참조할 '소스 오브 트루스'를 기계 가독 형태로 명시화하는 패턴—이게 앞으로 디자인 시스템 설계의 기본 요건이 될 가능성이 높다. Figma Variables가 코드와 연결되고, Tokens Studio가 CI/CD 파이프라인에 연결되는 흐름의 연장선이다.
브라우저 내장 AI는 결국 어떤 형태로든 표준화될 것이다. 문제는 그 표준이 얼마나 열려 있느냐, 모델 중립적이냐다. Mozilla의 저항이 불편하게 느껴질 수 있지만, 2000년대 초 IE 독점 시대를 겪은 웹이 왜 표준 기반으로 돌아왔는지를 생각하면—이 저항은 필요한 마찰이다.
디자인-개발 경계를 AI가 재편하는 건 이미 진행 중이다. 관건은 그 재편이 특정 도구나 모델에 고착되느냐, 아니면 열린 표준 위에서 이뤄지느냐다. DESIGN.md의 Apache 2.0 공개와 Mozilla의 Prompt API 반대는, 서로 다른 방향에서 같은 원칙을 가리키고 있다.