AI가 멋대로 추측하지 않게 만드는 디자인 시스템
AI로 UI를 만들다 보면 큰 사고보다 묘하게 어긋나는 것들이 더 자주 보입니다. 컬러가 살짝 다르고, 간격이 조금 다르고, 저장 방식이나 위험 영역 위치도 세션마다 은근히 달라지죠.
이번 주에는 디자인 시스템이 더 이상 사람만 보는 문서가 아니라, AI가 매번 참고해야 하는 작업 기준이 되고 있다는 신호를 모았습니다👇
📡 이번 주의 시그널
1️⃣ 디자인 시스템이 에이전트의 작업 계약서가 됨
AI 에이전트가 읽을 수 있는 디자인 시스템 만들기를 보면, Figma와 토큰을 넘겨주는 것만으로는 AI가 “왜 이렇게 써야 하는지”까지 알아서 이해하지 못합니다. 결국 `design.md`, `components.md`, 개별 spec 파일처럼 에이전트가 바로 읽을 수 있는 문서 구조가 필요해집니다.
2️⃣ 토큰과 spec은 LLM의 추측을 줄이는 장치가 됨
디자인 시스템을 LLM에 노출하세요에서 가장 공감됐던 건, LLM이 모르면 일단 그럴듯하게 채운다는 점입니다. 카드 패딩, 링크 컬러, radius가 매번 조금씩 달라지는 이유도 여기에 가깝죠. 그래서 닫힌 토큰, spec, audit script로 “대충 맞는 값”이 아니라 “정해진 값”을 쓰게 만드는 게 중요해집니다.
3️⃣ 컴포넌트 라이브러리만으로는 일관성이 부족함
디자인 시스템은 컴포넌트 라이브러리가 아니다는 버튼과 토큰이 같아도 화면이 다르게 느껴지는 이유를 잘 짚습니다. 설정 화면은 어떤 순서로 놓을지, 위험 영역은 어디에 둘지, 자동 저장을 쓸지 같은 판단은 컴포넌트만으로 해결되지 않으니까요.
4️⃣ MCP 기반 운영은 디자인 시스템을 실행 루프로 바꿈
컴포넌트 하나 고치는 데, 온 MCP가 다 필요하다를 보면 컴포넌트 하나 바꾸는 일도 사실 작은 운영 프로젝트에 가깝습니다. 현행 파악, Figma 반영, 문서화, Jira, Slack 공유까지 이어지니까요. 여기서 AI와 MCP는 결정을 대신한다기보다, 반복되는 실행을 묶어 디자이너가 검수와 결정에 더 오래 머물게 해줍니다.
