디자인 토큰 정리했고, 컴포넌트도 다듬었고, design.md도 만들었다. 이제 프롬프트 몇 줄이면 우리 서비스의 UI가 뚝딱 나올 것이라고 기대했다. 그런데 현실은? AI가 없는 색을 써오고, 이미 있는 컴포넌트는 무시하고 제3의 덩어리를 창조한다. 몇 번 고쳐도 결국 원점이다. 도구를 바꿔봐도, MCP 연결을 다시 시도해봐도 비슷하다.
요즘IT의 아티클 「AI가 읽는 디자인 시스템에 필요한 것」은 이 익숙한 좌절의 원인을 정확히 짚는다. AI가 디자인 시스템을 '무시'한 게 아니라, 우리가 AI에게 너무 많은 것을 눈치껏 해달라고 맡겼다는 것이다. 이 진단은 단순히 문서를 더 잘 쓰라는 조언이 아니다. 디자인 시스템 자체를 어떻게 바라볼 것인지의 패러다임 전환에 가깝다.
단어장이 아니라 문법이 필요하다
우리가 흔히 '디자인 시스템'이라고 부르는 것의 실체를 들여다보면 대부분 단어장 수준이다. 색상, 폰트, 버튼, 인풋, 체크박스 — 요소들이 나열되어 있다. 그런데 말을 할 때 단어만 늘어놓는 사람은 없다. '가방·무게·넣다·노트북·어깨·통증'처럼 나열해도 상대방이 알아듣는다면, 그건 상대방이 맥락을 눈치껏 추론했기 때문이다.
AI는 그 눈치가 없다. 그리고 안 답답하니까 묻지도 않는다. 그저 내가 시킨 것을 과하게 정확하게 해올 뿐이다. 색상도 얼추 맞고, 모서리도 둥글고, 폰트도 맞는데 '우리 서비스 같지 않은' 결과가 나오는 건 이 때문이다. 토큰은 맞는데 문장이 어색한, 외국인이 쓴 한국어처럼.
단어 다음엔 용법과 문법이 필요하다. 이 버튼은 어떤 문맥에서 쓰는지, Primary Button이 한 화면에 네 개 늘어서면 왜 안 되는지, 취소와 삭제 중 무엇을 더 조심스럽게 다뤄야 하는지. 사람 디자이너는 기존 화면을 보며, 동료에게 물으며 이 암묵지를 습득한다. AI에게는 그걸 명시적으로 써줘야 한다.
AI용 디자인 시스템 문서, 어디서부터 시작해야 하나
문서 형식 이야기부터 꺼내는 사람이 많다. md냐 JSON이냐, 피그마 변수를 어떻게 추출하냐. 그런데 형식은 인피니티 스톤이 아니다. hwp를 docx로 바꾼다고 내용이 달라지지 않듯, 모호한 디자인 시스템을 JSON으로 변환하면 '기계가 읽기 좋은 형식으로 아주 정갈하게 모호해질 뿐'이다.
제대로 된 시작점은 피그마에서의 완성도다. 디자인 토큰과 스타일이 정교하게 정의되어 있어야 하고, 컴포넌트의 배리언츠·프로퍼티·최대 너비·글자 수·에러 케이스(로딩, 빈 상태, 권한 부족 등)가 모두 갖춰져 있어야 한다. 그다음이 how-to-use 가이드라인이다. 이 버튼은 이렇게 쓰세요, 이런 경우엔 쓰지 마세요, 예외는 이런 케이스들입니다. 우리가 디자인할 때 꺼내 쓰는 원칙들을 전부 텍스트로 꺼내야 한다.
문서를 다 만들었다고 끝이 아니다. 이제서야 시작점에 선 것이다. 생성 → 피드백 → 재학습 → 재생성의 루프를 지속해야 한다. 퀄리티가 안 나오는 이유 두 가지: 첫째는 애초에 피그마 디자인 시스템이 부실했던 것, 둘째는 이 반복 루프를 하지 않는 것. 그리고 이 과정에서 가장 큰 비용은 AI 토큰 비용이 아니라 시간이다. 며칠이 걸릴 수도, 몇 주, 몇 달이 될 수도 있다.
Blast Radius Rule: 무엇을 AI에게 맡기고 무엇을 내가 쥘 것인가
디자인 시스템 문서를 갖췄다면, 다음 질문은 이것이다. AI에게 실제로 무엇을 위임할 것인가? dev.to에 게재된 「The Blast Radius Rule for AI Coding」은 이 질문에 대해 명쾌한 사고 프레임을 제시한다. 핵심은 단 하나의 질문으로 수렴된다: "이게 잘못 출시됐을 때, 되돌리는 비용이 얼마인가?"
저자는 작업을 세 구역으로 나눈다. Zone 1은 git revert 하나면 2분 안에 되돌릴 수 있는 것들 — 페이지 카피, 스타일, 빌드 스크립트, 블로그 포스트, 대부분의 리팩토링. 여기서는 AI가 혼자 작업하게 두어도 된다. 틀려도 금방 고친다. Zone 2는 기술적으로는 리포에 있지만 실패해도 눈에 보이지 않는 것들 — 캐시 헤더, robots.txt, 리다이렉트 맵, 캐노니컬 URL, 구조화 데이터. 이건 '사이트가 완벽해 보이는데 3주 후에 트래픽이 이상하다'는 식으로 발각된다. 더 많이 읽는 게 해법이 아니라, 실제 응답값을 검증하는 것이 해법이다.
Zone 3는 되돌리기가 git 바깥에 있는 것들이다. DNS 레코드, 앱스토어 스토어 메타데이터, 이미 외부에 공개된 URL, 시크릿·토큰·권한 범위, '삭제' 버튼이 달린 모든 것. 여기선 위임하지 않는다. 역량의 문제가 아니라 책임의 소재의 문제다. AI는 이 작업이 얼마나 되돌리기 어려운지 알지 못한다. 리포에 아무것도 적혀 있지 않으니까.
저자가 실제로 한 것은 README 상단에 이 한 문장을 써놓는 것이었다: "이 URL들은 Google Play Console 리스팅에서 참조되고 있으며 절대 깨져서는 안 됩니다." 미래의 사람을 위해 쓴 문장이 AI에게도 그대로 작동했다. 이건 디자인 시스템 가이드라인을 작성하는 원리와 정확히 같다. 명시되지 않은 것은 AI에게 존재하지 않는다.
MCP, 연결 전에 '어디까지 연결할 것인지'를 먼저
디자인 워크플로우에 AI를 통합할 때 자연스럽게 MCP 이야기가 나온다. dev.to의 「10 MCP Servers Worth Adding to Your AI Coding Workflow in 2026」은 Cursor·Claude Code·Kiro 등에서 실제로 쓸 만한 MCP 서버 10개를 정리했다. Context7(라이브러리 문서), Chrome DevTools MCP(브라우저 디버깅), Playwright MCP(자동화 테스트), GitHub MCP(소스 컨트롤), Vercel MCP(배포·로그), Cloudflare API MCP(DNS·Workers 등)가 특히 프론트엔드 워크플로우와 직결된다.
그런데 이 목록을 보면 Blast Radius Rule이 즉각 겹쳐 보인다. Cloudflare API MCP는 DNS를 포함한 2,500개의 API 엔드포인트에 접근한다. GitHub MCP는 리포지토리 쓰기와 워크플로우 실행 권한이 있다. Vercel MCP는 실제 배포를 생성한다. 저자 스스로도 각 서버의 'Access level to watch' 열을 별도로 표시했다. MCP를 연결하는 것은 능력을 확장하는 동시에 Blast Radius를 넓히는 일이다. 설치 전에 비프로덕션 환경에서 먼저 테스트하라는 권고는 그냥 관례적 경고가 아니라 실질적인 위험 관리다.
피그마 MCP나 Excalidraw MCP처럼 다이어그램·디자인 영역의 MCP는 상대적으로 Zone 1에 가깝다. 반면 Supabase MCP(스키마·마이그레이션)나 AWS MCP(IAM 권한 범위)는 Zone 3에 걸쳐 있다. 어떤 MCP를 어떤 권한 범위로 연결할 것인지를 Blast Radius 프레임으로 분류해두는 것이 실무적으로 유용하다.
위임의 경계를 쓰는 것이 디자인 시스템의 일부다
세 소스를 하나의 흐름으로 엮으면 같은 결론에 닿는다. AI에게 금을 넣는다는 건 거대한 프롬프트를 준비하는 일이 아니다. 우리 팀이 무엇을 어떻게, 왜 디자인하고 개발하는지 설명할 수 있게 만드는 일이다. 그리고 동시에, 어느 지점까지는 AI에게 맡기고 어느 지점부터는 내가 직접 쥐어야 하는지를 명시적으로 정의하는 일이다.
흥미로운 역설이 하나 있다. AI가 자꾸 엉뚱한 화면을 만든다는 사실은 우리 디자인 시스템에 빠진 논리적 빈칸을 가장 성실하게 드러내주는 사용성 테스트의 결과다. AI가 잘못 만든 화면을 고치면서 디자이너는 자신의 시스템에서 무엇이 명시되지 않았는지를 배운다. AI를 훈련시키는 과정에서 다시 배우게 되는 건 결국 디자이너 자신이다.
새로운 AI 도구가 나왔다고 바로 갈아타지 말자. 내가 무엇을 담았고, AI가 그 빈칸을 어떻게 채웠는지를 먼저 파악하는 게 맞다. 디자인 시스템도, Blast Radius 분류도, MCP 권한 설정도 — 모두 결국 같은 질문의 다른 표현이다. 이게 잘못됐을 때, 나는 알 수 있는가? 그리고 되돌릴 수 있는가?