당신의 디자인 시스템에 MCP 서버가 필요한 이유

지금 여러분의 디자인 시스템을 위해 할 수 있는 가장 좋은 투자 중 하나는 Model Context Protocol (MCP) 서버를 구축하는 것입니다. AI 모델이 진화함에 따라 그 능력은 점점 더 강력해지고 있지만, 이를 효과적으로 사용하는 데에는 비용이 따릅니다. AI가 여러분의 컴포넌트(component)가 어떻게 작동하는지 추측하는 데 낭비하는 모든 토큰(token)은 곧 손실되는 비용입니다. MCP 서버는 AI가 여러분의 디자인 시스템을 정확히 어떻게 사용하는지 찾아볼 수 있는 일련의 도구 세트를 제공합니다. 이를 AI가 추측하는 대신 호출할 수 있는 API라고 생각하면 됩니다. 이 글에서는 이것이 왜 중요한지, 그리고 어떻게 자신만의 MCP 서버를 시작할 수 있는지에 대해 이야기해 보겠습니다.

본론으로 들어가기에 앞서, AI 사용에 대해 짚고 넘어가야 할 몇 가지 사항이 있습니다. 저 또한 과거에는 회의적인 시각을 가졌던 적이 있지만, 최근의 모델 출시들은 사용자 인터페이스(UI) 구축을 포함한 대부분의 워크스트림(workstreams)에서 AI가 실행 가능한 도구가 아니라고 주장하기를 점점 더 어렵게 만들고 있습니다. 대부분의 대규모 언어 모델(Large Language Models, LLM)은 인터넷에서 스크래핑한 공개 데이터로 학습되는데, 이는 여러분의 내부 디자인 시스템이 AI에게는 거의 보이지 않는다는 것을 의미합니다. 특히 여러분의 문서(documentation)가 기업 네트워크 뒤에 있다면 더욱 그렇습니다. MCP가 없다면 GitHub Copilot이나 Claude와 같은 에이전틱 코딩 도구(agentic coding tool) 내의 AI 에이전트는 여전히 여러분의 시스템을 사용하려고 시도할 것이며, 종종 node_modules 폴더를 뒤져보며 최선의 추측으로 빈틈을 채우려 할 것입니다. 바로 여기서 환각(hallucination)된 컴포넌트 API가 발생합니다. MCP 서버는 단순히 디자인 시스템에 대해 AI를 더 유용하게 만드는 것에 그치지 않고, 추측을 정확하고 구조화된 컨텍스트(context)로 대체함으로써 신뢰성 문제를 직접적으로 해결합니다.

결국, 디자인 시스템의 사용자들은 브랜드 가이드라인을 최대한 빠르게 준수하는 UI를 원합니다. 그렇다면 사용자들의 에이전트(agent)에게 여러분의 시스템을 위한 레시피 북을 제공함으로써, 그들이 AI를 더 효과적으로 사용할 수 있도록 힘을 실어주는 것은 어떨까요? 이는 모두에게 이득이 되는 일입니다. 사용자들은 처음부터 올바른 컴포넌트(component)와 디자인 토큰(design token)을 사용하는 레이아웃을 얻게 되고, 여러분은 평소와 같은 일일이 가이드하는 과정 없이도 더 높은 채택률을 얻을 수 있습니다. MCP 서버는 AI 에이전트에게 이러한 질문들을 해결할 수 있는 구체적인 도구(tool)를 제공함으로써 이를 가능하게 하며, 추측에 기반한 결과가 아닌 여러분의 의도를 실제로 반영하는 코드 샘플과 디자인 토큰 사용법을 생성해냅니다.

MCP 서버 만들기

MCP 서버를 시작하는 것은 생각보다 훨씬 간단합니다. MCP 서버는 엔드포인트(endpoint) 대신, AI가 정보가 필요할 때 이름으로 호출할 수 있는 "도구(tools)"를 노출합니다. 전통적인 API와의 핵심적인 차이점은 응답이 엄격한 스키마(schema)를 따를 필요가 없다는 것입니다. 데이터의 형태가 바뀌면 클라이언트가 작동을 멈추는 REST API와 달리, MCP 도구는 느슨하게 구조화된 텍스트나 JSON을 반환할 수 있으며 AI는 이를 이해할 수 있습니다. 여러분이 할 일은 단순히 AI가 올바른 정보를 가리키도록 안내하는 것뿐입니다.

Node를 사용 중이라면 @modelcontextprotocol/sdk 패키지를 사용하여 시작할 수 있습니다:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
...

디자인 시스템의 경우, 다음과 같은 방향으로 도구를 노출하는 것을 고려해야 합니다:

• List Components (컴포넌트 목록 조회): AI에게 사용 가능한 모든 항목의 인덱스를 제공하여, 단 한 줄의 코드를 작성하기 전에 무엇을 가져다 써야 할지 알 수 있게 합니다.
• Get Component (컴포넌트 가져오기): 특정 컴포넌트에 대한 상세 정보(props, slots, events 및 모든 사용 제약 사항)를 반환합니다. 이는 환각 (hallucination)된 API를 제거하는 지점이 됩니다.
• List Documentation (문서 목록 조회): AI가 어떤 문서 가이드가 존재하는지 발견할 수 있게 하며, 패턴이나 페이지 수준의 구성에 관한 광범위한 질문에 유용합니다.
• Get Documentation (문서 가져오기): 속성 타입 (prop types)만으로는 전달할 수 없는 권장 가이드라인(opinionated guidance) 및 예외 케이스 (edge cases)를 포함하여, 문서 페이지의 실제 내용을 가져옵니다.
• Get Component Examples (컴포넌트 예시 가져오기): 실제 Storybook 스토리를 가져와서, AI가 컴포넌트 시그니처 (component signature)로부터 사용 패턴을 추론하는 대신 실제로 작동하는 사용 패턴을 볼 수 있게 합니다.

이를 통해 AI는 귀하의 디자인 시스템 전체를 쿼리(query)하고, 필요에 따라 특정 컴포넌트의 세부 사항을 심층적으로 파고들 수 있는 능력을 갖게 됩니다. 이러한 도구들을 어떻게 구축할지는 기존 설정에 따라 달라집니다. 주로 Web Components를 구축하고 있다면, 이미 모든 컴포넌트와 옵션을 기계 판독 가능한 형식으로 포함하고 있는 Custom Elements Manifest에 직접 연결할 수 있습니다:

import fs from "fs";
import { z } from "zod";

...

Storybook을 사용 중이라면, 추상 구문 트리 (Abstract Syntax Tree, AST)를 탐색하여 스토리를 쿼리 가능한 예시로 재구성할 수 있습니다. 저는 서버 사이드 렌더링 (server-side rendering) 검증 맥락에서 이 내용을 다른 기사에서 다룬 적이 있지만, 동일한 원칙이 여기에도 적용됩니다. 또는, 지원하는 언어를 사용 중이라면 별도의 커스텀 코드를 작성할 필요 없이 Storybook MCP 서버 플러그인을 사용하여 스토리를 도구로 노출할 수도 있습니다.

import ts from "typescript";
import fs from "fs";
import path from "path";
...

더 세밀하게 가져가기

당신의 서버는 대부분의 에이전트 기반 코딩 도구 (agentic coding tools)에서 사용될 수 있지만, 사용하는 도구에 따라 설정 형식이 달라집니다. VS Code의 경우, .vscode/mcp.json 파일을 추가하고 HTTP 주소나 stdio 경로를 지정하면 됩니다:

{
  "servers": {
    "my-design-system-mcp": {
...

MCP 서버를 실행하고 나면, 이제 문서가 인간과 AI 에이전트 모두에 의해 읽히기 때문에 문서화가 훨씬 더 중요해집니다. 이는 구체적인 내용을 작성할 좋은 기회입니다. 단순히 Button 컴포넌트가 variant 프롭 (prop)을 받는다고 기록하기보다는, 왜 특정 조합을 피해야 하는지를 기록하세요. 예를 들어, variant="ghost"는 의도적으로 대비가 낮게 설계되었으므로 폼 (form) 내부에서 주요 호출 동작 (primary call to action)으로 사용해서는 안 됩니다. 이러한 맥락 (context)이 없는 AI는 그것이 유효한 옵션처럼 보이기 때문에 어쨌든 이를 선택할 것입니다. 구전으로 전해 내려오는 임시방편 (workarounds)에도 동일한 원칙이 적용됩니다. 만약 그 정보가 누군가의 머릿속이나 Slack 스레드에만 존재한다면, AI는 절대 그것을 찾아낼 수 없습니다. 문서가 더 집중적이고 주관적 (opinionated)일수록, AI의 출력물 또한 더 집중적이고 주관적이 될 것입니다. 맥락이 탄탄하다면, 평소라면 몇 주가 걸렸을 리팩터링 (refactors)을 현실적으로 며칠 또는 몇 시간 만에 끝낼 수 있습니다.

더 많은 잠재력을 끌어올리고 싶다면, MCP 서버를 Figma Code Connect와 결합하는 것은 투자할 가치가 있습니다. Figma는 디자인 사양 (design specs)을 직접 읽을 수 있는 자체 MCP 서버를 가지고 있습니다. 여러 개의 MCP 서버를 동시에 연결할 수 있으므로, AI는 디자인 사양을 가져와 사용할 적절한 컴포넌트를 식별한 다음, 구현 세부 사항과 예외 케이스 (edge cases)를 파악하기 위해 당신의 디자인 시스템 MCP에 질의할 수 있습니다. 그 결과, AI가 디자인에서 코드로 넘어갈 때 훨씬 적은 상호작용 (back and forth)만으로 작업이 이루어지는 워크플로 (workflow)를 얻게 됩니다.

결론 (Conclusion)

AI 도구로부터 가장 큰 이득을 얻을 팀은 AI에게 작업에 필요한 최상의 컨텍스트 (context)를 제공하는 팀입니다. MCP 서버를 갖춘 잘 관리된 디자인 시스템 (design system)이 바로 그러합니다. 이는 여러분의 표준과 엔지니어가 매일 사용하는 도구 사이의 직통 연결선 역할을 합니다. 디자인 시스템이 항상 제공해 온 추상화 (abstraction)와 일관성 (consistency)은 AI가 이를 안정적으로 소비할 수 있게 될 때 훨씬 더 가치 있어집니다. 이는 디자인 시스템을 넘어, 잘 문서화된 라이브러리 (library)라면 무엇이든 동일한 접근 방식의 혜택을 누릴 수 있습니다.

디자인 시스템은 항상 팀에게 공유된 언어를 제공하는 것이 목적이었습니다. MCP 서버는 단지 AI 또한 그 언어를 말할 수 있게 된다는 것을 의미합니다.