LLMs와 디자인 시스템을 MCP로 연결하기: 생성 디자인을 위한 커뮤니티 Figma MCP 서버 구현
Source: Dev.to
위 링크에 있는 글의 내용을 제공해 주시면, 해당 텍스트를 한국어로 번역해 드리겠습니다. 현재는 외부 웹사이트의 내용을 직접 가져올 수 없으니, 번역하고 싶은 본문을 복사해서 알려 주세요.
모델 컨텍스트 프로토콜 (MCP)
모델 컨텍스트 프로토콜 (MCP) 은 AI 모델이 외부 도구 및 데이터셋과 구조화되고 안전하게 상호작용할 수 있게 해주는 오픈‑표준 통신 프로토콜입니다. 전통적으로 에이전트의 지식은 학습 데이터에 한정되어 있었지만, MCP는 서버가 특정 기능(또는 도구)을 클라이언트(LLM)에게 제공하도록 표준을 정의함으로써 이 격리를 깨뜨립니다. 현대 소프트웨어 개발에서는 이를 통해 엔지니어나 디자이너가 AI 에이전트를 협업 파트너로 활용하여 코드베이스를 검사하고, 데이터베이스를 질의하며, 여기서 탐구된 바와 같이 실시간으로 디자인 파일을 조작할 수 있습니다.
격차 해소: 읽기 전용에서 생성형 디자인으로
대부분의 전문 디자인 도구는 보안과 안정성을 최우선으로 하여, API가 크게 제한되는 경우가 많습니다. 예를 들어 Figma는 강력한 REST API를 제공하지만, 주로 읽기 전용입니다. MCP 서버는 프레임이나 레이어의 속성을 쉽게 가져올 수 있지만, 단순한 HTTP 요청만으로 버튼을 이동시키거나 색상 코드를 변경할 수는 없습니다. Figma 문서를 프로그래밍 방식으로 수정할 수 있는 유일한 방법은 플러그인 API를 사용하는 것으로, 이는 사용자의 브라우저 환경에서 직접 실행됩니다.
Community Figma MCP Server는 단순한 API 래퍼를 넘어서는 해결책을 제공합니다. 이는 LLM과 Figma 내부 문서 객체 모델(DOM) 사이의 직접 연결이 활성 실행 컨텍스트를 필요로 한다는 점을 인식합니다. 플러그인 API를 활용함으로써 서버는 Auto Layout, 컴포넌트 속성, 좌표 시스템 등 Figma의 전체 편집 기능에 접근할 수 있게 되며, AI 에이전트가 인간 디자이너처럼 행동하여 텍스트 프롬프트만으로 복잡한 UI 구조(예: 로그인 폼이나 네비게이션 바)를 생성하는 명령을 내릴 수 있습니다1.
생성적 피드백 루프
생성적 디자인 도구를 구현하려면 단순히 “도형을 그리는” 것 이상이 필요합니다; 디자인 모범 사례에 대한 이해가 요구됩니다. 이 MCP 구현의 핵심 측면은 에이전트의 행동을 안내하는 구조화된 memory 파일 또는 시스템 프롬프트를 사용하는 것입니다. 구체적인 제약이 없으면 에이전트가 동일한 (0,0) 좌표에 요소를 겹치게 할 수 있습니다. 컨텍스트 인식 환경을 제공함으로써 에이전트에게 다음과 같이 지시할 수 있습니다:
- Auto Layout을 모든 새 프레임에 사용하여 반응성을 보장합니다.
- 전용 “Components” 페이지에 컴포넌트를 정리합니다.
- 기존 디자인 시스템을 기반으로 일관된 간격 및 정렬을 적용합니다.
이는 LLM을 단순 스크립트 실행기에서 의도를 이해하는 디자인 어시스턴트로 변환합니다. 사용자가 레이아웃에 만족하지 않을 경우, 에이전트에게 “버튼을 왼쪽으로 정렬”하거나 “주요 액션과 보조 액션을 교체”하라고 간단히 프롬프트할 수 있습니다. 그 후 MCP 서버는 이러한 고수준 의도를 일련의 툴 호출로 변환하여 실시간으로 Figma 문서를 수정합니다.
비하인드 씬: WebSocket 아키텍처 및 도구 연결
Community Figma MCP Server의 아키텍처는 Figma 플러그인의 샌드박스 제한을 우회하도록 설계되었습니다. 플러그인은 독립 실행형 서버 역할을 할 수 없기 때문에 3계층 시스템이 사용됩니다:
- MCP 서버 – AI 에이전트(예: Claude 또는 Opus)의 진입점.
createRect,setPadding,addComponentInstance와 같은 동작을 정의하는 23개 이상의 도구 세트를 노출합니다. - WebSocket 서버 – 메시지 브로커 역할을 하며 MCP 서버와 활성화된 Figma 플러그인 간에 지속적인 연결을 유지합니다.
- Figma 플러그인 – Figma 클라이언트 내에서 실행되며 WebSocket을 통해 메시지를 수신하고, Plugin API를 사용해 요청된 디자인 변경을 수행한 뒤 확인 또는 결과를 체인 뒤로 다시 전송합니다.
에이전트가 도구 요청을 시작하면 MCP 서버는 해당 호출을 큐에 넣습니다—이는 디자인 업데이트의 비동기적 특성을 관리하는 데 필수적입니다. 플러그인이 작업을 완료하면 업데이트된 컨텍스트를 WebSocket 서버에 반환하고, 서버는 MCP 환경에서 원래 도구 호출을 해결합니다. 이를 통해 에이전트는 다음 디자인 결정을 내리기 전에 항상 문서 상태에 대한 정확한 “뷰”를 유지할 수 있습니다1.
// Conceptual example of a tool call handling design logic
async function handleCreateComponent(name: string, properties: any) {
const message = {
type: 'EXECUTE_ACTION',
action: 'CREATE_COMPONENT',
payload: { name, properties }
};
// Send the message through the WebSocket bridge
websocket.send(JSON.stringify(message));
// Wait for the plugin to confirm execution
return await waitForPluginResponse();
}내 생각
Community Figma MCP Server는 AI‑보조와 AI‑자동화 워크플로우의 진화에서 중요한 순간을 나타냅니다. Figma 자체의 “Make Design” 기능과 같은 도구가 일회성 생성만 제공한다면, MCP 접근 방식은 반복적이고 대화형 편집을 가능하게 합니다—특히 깊은 디자인 전문 지식이 없지만 기능적인 프로토타입을 빠르게 구축해야 하는 개발자에게 큰 가치를 제공합니다.
하지만 몇 가지 고유한 제한 사항도 존재합니다:
- 맞춤형 WebSocket 브리지를 사용해야 하므로 배포 복잡성이 증가합니다; 사용자는 MCP 서버 와 로컬 플러그인 둘 다 실행해야 합니다.
- LLM은 매우 상세한 프롬프트나 추가 제약이 없을 경우, 픽셀‑정밀 레이아웃에 필요한 공간 추론을 여전히 어려워합니다.
전반적으로 Community Figma MCP Server는 AI‑구동 디자인 도구가 달성할 수 있는 한계를 넓히며, 보다 유연하고 협업적인 디자인 경험의 문을 열어줍니다.
“프로토콜이 성숙해짐에 따라, 이러한 ‘브리지’ 아키텍처가 최종 사용자에게 더 투명해지는 tighter integration을 보게 될 것이며, 디자인 플랫폼에서 양방향 API 접근에 대한 공식 지원을 통해 구현될 가능성이 있습니다.”
감사의 글
저는 Anton Tishchenko, CTO at EXDST,에게 Community Figma MCP Server 토크가 MCP Developers Summit에서 진행될 때 이 구현에 대한 상세한 walkthrough를 제공해 주신 것에 감사드립니다.
- Talk recording: YouTube – “Community Figma MCP Server”
- Related article: dev.to – “Community Figma MCP Server”
그의 Figma 환경에 필요한 아키텍처 우회 방법에 대한 통찰은 커뮤니티에 큰 도움이 되었습니다. 또한 도구 사용 표준의 경계를 지속적으로 확장해 온 광범위한 MCP 및 AI 연구 커뮤니티에도 감사를 표합니다.