Figma MCP 서버가 캔버스를 열었다, AI 에이전트가 디자인을 직접 그리는 시대

Figma가 MCP 서버 write-to-canvas 베타를 공식 출시했습니다. 3월 25일부터 AI 코딩 에이전트가 Figma 캔버스에 직접 디자인을 생성하고 수정할 수 있게 되었습니다. 지금까지 Figma MCP는 읽기 전용이었습니다. 에이전트가 디자인 파일을 참조해서 코드를 생성하는 일방향 흐름만 가능했습니다. 이제 그 벽이 허물어졌습니다. 에이전트가 코드에서 디자인으로, 디자인에서 코드로 양방향으로 이동할 수 있습니다. 함께 출시된 Skills 프레임워크는 마크다운 파일만으로 에이전트에게 디자인 시스템 규칙을 가르칠 수 있는 구조입니다. 16개의 MCP 도구가 노출되고, 14개 이상의 MCP 클라이언트에서 바로 사용할 수 있습니다.

이 변화가 왜 중요할까요? 디자인과 개발 사이의 "핸드오프"는 지난 10년간 프론트엔드 워크플로우에서 가장 비효율적인 구간으로 꼽혀 왔습니다. Figma가 이 구간을 AI 에이전트로 직접 연결하겠다는 선언을 한 것입니다.

읽기 전용에서 양방향으로, Figma MCP의 진화

Figma MCP 서버의 진화를 이해하려면 MCP(Model Context Protocol) 생태계의 맥락부터 짚어야 합니다. Anthropic이 주도한 MCP는 AI 에이전트가 외부 도구와 표준화된 방식으로 소통하는 프로토콜입니다. 2025년 하반기부터 Claude Code, Cursor, Windsurf, VS Code 등 주요 AI 코딩 도구들이 MCP 클라이언트를 내장하기 시작했고, 각종 서비스들이 MCP 서버를 제공하면서 생태계가 급성장했습니다.

Figma도 이 흐름에 일찍 합류했습니다. 초기 Figma MCP 서버는 읽기 전용이었습니다. 에이전트가 Figma 파일의 디자인 토큰, 컴포넌트 구조, 레이아웃 정보를 읽어와서 이를 기반으로 코드를 생성하는 용도였습니다. "디자인을 보고 코드를 짜라"는 단방향 워크플로우입니다. 디자이너가 Figma에서 디자인을 완성하면, 개발자의 에이전트가 이를 참조해 구현하는 구조. 핸드오프 자체를 없앤 것이 아니라, 핸드오프를 자동화한 것에 가까웠습니다.

이번 write-to-canvas 베타는 근본적으로 다릅니다. 에이전트가 캔버스에 쓸 수 있게 되었습니다. use_figma라는 새로운 도구를 통해 Figma Plugin API 컨텍스트에서 JavaScript를 직접 실행하고, 캔버스를 조작할 수 있습니다. 프레임 생성, 컴포넌트 인스턴스 배치, 스타일 적용, 레이아웃 조정 모두 에이전트의 코드 한 줄로 가능해졌습니다.

핵심 기능 분석: write-to-canvas, Skills, Code-to-Canvas

이번 출시의 핵심은 세 가지 축으로 나뉩니다. 하나씩 살펴보겠습니다.

write-to-canvas와 16개 MCP 도구

Figma MCP 서버는 총 16개의 도구를 노출합니다. 이 중 가장 핵심적인 것이 use_figma입니다. 이 도구는 Figma Plugin API의 전체 컨텍스트를 에이전트에게 제공합니다. 에이전트는 이 안에서 JavaScript를 실행하여 캔버스를 직접 조작합니다. 단순히 도형을 그리는 수준이 아닙니다. Figma의 실제 컴포넌트를 인스턴스로 생성하고, 변수(Variables)를 적용하며, Auto Layout 규칙을 설정할 수 있습니다.

Ali Shouman(Bitovi)은 실제 사용 후 이렇게 평가했습니다.

"놀랍게도 사려 깊은 출력물을 생성했습니다. 에이전트가 실제로 일반 프레임 대신 실제 컴포넌트를 사용하고, 값을 하드코딩하는 대신 변수를 적용했습니다."

(원문: "It produced surprisingly thoughtful output. The agent actually used real components instead of generic frames and applied variables instead of hardcoding values.")

이것은 중요한 구분입니다. 에이전트가 디자인 시스템의 구조를 이해하고 시맨틱한 방식으로 캔버스를 조작한다는 의미이기 때문입니다. 단순히 픽셀을 찍는 것이 아니라, Figma의 컴포넌트 체계를 활용하는 것입니다.

14개 이상의 MCP 클라이언트를 동시 지원한다는 점도 주목할 만합니다. Claude Code, Cursor, Windsurf, VS Code(Copilot), Cline, Zed 등 주요 AI 코딩 도구에서 바로 연결됩니다. 특정 에디터에 종속되지 않는 프로토콜 레벨의 통합입니다.

Skills 프레임워크: 마크다운으로 에이전트를 교육하다

Skills 프레임워크는 이번 출시에서 가장 흥미로운 요소일 수 있습니다. 핵심 아이디어는 단순합니다. 마크다운 파일로 에이전트에게 디자인 규칙을 가르친다는 것입니다.

현재 공식 7개 + 커뮤니티 9개, 총 16개의 Skills가 제공됩니다. 공식 Skills는 Figma가 직접 작성한 것으로, 기본적인 캔버스 조작과 디자인 시스템 활용 방법을 에이전트에게 알려줍니다. 커뮤니티 Skills는 실제 기업들이 자신의 디자인 시스템에 맞게 작성한 것입니다. Uber의 접근성 Skill, Edenspiekermann의 디자인 시스템 Skill 등이 대표적입니다.

왜 이것이 중요할까요? 기존에 Figma 플러그인을 만들려면 TypeScript/JavaScript 개발 능력이 필요했습니다. Skills 프레임워크는 이 장벽을 없앱니다. 디자이너가 마크다운으로 "우리 디자인 시스템에서는 버튼 간격을 8px로 유지하라", "Primary 색상은 #2563EB이다" 같은 규칙을 작성하면, 에이전트가 이를 따릅니다. 플러그인 개발 없이도 에이전트의 행동을 커스터마이즈할 수 있게 된 것입니다.

이는 AI 에이전트 생태계에서 반복되는 패턴과 일치합니다. Claude Code의 CLAUDE.md, Cursor의 .cursorrules, GitHub Copilot의 커스텀 인스트럭션. 에이전트를 제어하는 가장 효과적인 방법이 결국 자연어 규칙 파일로 수렴하고 있습니다.

Code-to-Canvas: 역방향 워크플로우의 완성

세 번째 축인 Code-to-Canvas는 디자인-코드 워크플로우를 진정한 양방향으로 만드는 기능입니다. 브라우저에서 렌더링된 라이브 UI를 캡처하여 편집 가능한 Figma 프레임으로 변환합니다.

이것이 스크린샷 캡처와 다른 점은, 결과물이 편집 가능한 Figma 네이티브 객체라는 것입니다. 프레임, 텍스트, 레이아웃이 모두 분리된 상태로 변환됩니다. 개발자가 코드로 빠르게 프로토타입을 만들고, 이를 Figma로 보내서 디자이너가 세밀하게 다듬는 워크플로우가 가능해집니다.

기존 워크플로우: 디자이너가 Figma에서 완성 → 개발자가 코드로 구현 새로운 워크플로우: 에이전트가 코드로 프로토타입 → Figma로 변환 → 디자이너가 정제 → 에이전트가 최종 코드 생성

핸드오프의 방향이 고정되어 있던 것에서, 순환 구조로 바뀐 것입니다.

가격 정책과 제한

베타 기간에는 무료로 사용할 수 있지만, Figma는 이미 향후 유료화 계획의 윤곽을 공개했습니다.

• Starter 플랜: 월 6회 호출. 사실상 체험 수준입니다
• Professional Dev/Full: 일 200회 호출
• Enterprise: 일 600회 호출

이 숫자가 충분한지는 실제 사용 패턴에 따라 달라질 것입니다. 에이전트가 캔버스를 조작할 때마다 여러 번의 API 호출이 발생할 수 있다는 점을 고려하면, 일 200회가 넉넉하다고 보기 어려울 수 있습니다. 특히 반복적인 시행착오가 필요한 초기 단계에서는 더욱 그렇습니다.

실무에 미치는 영향

프론트엔드 개발자에게

가장 직접적인 영향을 받는 것은 프론트엔드 개발자입니다. Bitovi의 사례에 따르면, Figma MCP를 활용한 반응형 개발에서 50-70% 시간 단축이 보고되었습니다. 이는 주로 디자인 스펙을 코드로 변환하는 반복 작업에서 절감되는 시간입니다.

하지만 현실적인 제약도 명확합니다. 에이전트가 연결된 디자인 시스템을 자동으로 감지하지 못합니다. 명시적으로 "이 파일에 연결된 디자인 시스템을 사용하라"고 지시해야 합니다. 이것은 Skills 프레임워크의 존재 이유이기도 합니다. 에이전트에게 맥락을 제공하지 않으면, 올바른 컴포넌트 대신 일반 프레임으로 디자인을 구성할 수 있습니다.

디자이너에게

디자이너의 역할이 실행자에서 감독자로 변화할 조짐이 보입니다. 에이전트가 초안을 생성하고, 디자이너가 이를 검수하고 정제하는 워크플로우입니다. 이것은 코딩 에이전트가 개발자의 역할을 바꾸고 있는 것과 정확히 같은 패턴입니다. Claude Code나 Cursor를 사용하는 개발자가 "코드를 직접 작성하는 시간보다 에이전트의 출력을 리뷰하는 시간이 더 길다"고 말하는 것처럼, 디자이너도 같은 변화를 겪게 될 수 있습니다.

Skills 프레임워크를 통해 디자이너가 마크다운으로 에이전트를 교육할 수 있다는 것은, 디자이너의 새로운 역량으로 "에이전트 교육 능력"이 추가된다는 의미이기도 합니다. 디자인 시스템의 규칙을 에이전트가 이해할 수 있는 형태로 구조화하는 능력이 중요해질 것입니다.

디자인-개발 핸드오프의 변화

지난 10년간 디자인 핸드오프를 개선하려는 시도는 수없이 있었습니다. Zeplin, InVision, Figma의 Dev Mode까지. 하지만 이 모든 도구는 핸드오프의 마찰을 줄이는 것이었지, 핸드오프 자체를 없애는 것은 아니었습니다.

Figma MCP의 양방향 워크플로우는 핸드오프라는 개념 자체를 약화시킵니다. 디자인과 코드가 에이전트를 매개로 실시간으로 동기화될 수 있다면, "여기서 디자인이 끝나고 여기서 개발이 시작된다"는 경계가 흐려집니다. 물론 현재 베타 단계에서 이 비전이 완전히 실현된 것은 아닙니다. 하지만 방향은 분명합니다.

커뮤니티 반응: 기대와 우려의 교차

긍정적 반응

실제로 write-to-canvas를 사용한 개발자들의 초기 반응은 조심스러운 낙관입니다. 앞서 인용한 Bitovi의 사례처럼, 에이전트가 디자인 시스템의 컴포넌트와 변수를 활용하는 수준에 도달한 것은 의미 있는 진전입니다.

특히 반응형 레이아웃 작업에서 시간 단축 효과가 두드러진다는 보고가 있습니다. 브레이크포인트별 레이아웃을 수동으로 조정하는 반복 작업을 에이전트가 대신 처리할 수 있기 때문입니다.

부정적 반응과 한계

하지만 품질에 대한 우려도 상당합니다. Figma 포럼의 한 사용자는 이렇게 보고했습니다.

"85-90%의 스타일이 틀렸고, 때때로 심각하게 틀렸습니다."

(원문: "85-90% of styles were wrong, and sometimes seriously wrong.")

에이전트의 비결정적 동작도 문제로 지적됩니다. 같은 프롬프트로 같은 작업을 요청해도 매번 다른 결과가 나올 수 있습니다. 디자인 시스템의 일관성을 유지해야 하는 환경에서 이 비결정성은 심각한 제약입니다. 코드에서는 린터와 테스트로 일관성을 강제할 수 있지만, 디자인 출력물에서는 그런 자동화된 검증이 아직 부족합니다.

서드파티 MCP 차단 논란

Hacker News에서는 별도의 논란이 벌어졌습니다. "Figma blocks userland MCP tool"이라는 제목의 게시물이 올라왔습니다. Figma가 커뮤니티가 만든 비공식 MCP 도구를 차단하고, 자체 공식 MCP 서버만 허용하는 정책을 취하고 있다는 것입니다.

이 논란은 MCP 생태계의 근본적인 긴장을 보여줍니다. MCP는 개방형 프로토콜이지만, 각 서비스 제공자가 자신의 API 접근을 통제할 수 있습니다. Figma 입장에서는 품질 관리와 보안을 위해 공식 채널만 허용하는 것이 합리적일 수 있습니다. 하지만 개발자 커뮤니티에서는 이를 생태계 통제로 볼 여지가 있습니다. 과연 MCP의 개방성과 플랫폼의 통제권 사이에서 어떤 균형이 만들어질까요?

경쟁 구도: 디자인-코드 브릿지 전쟁

Figma MCP의 포지션을 이해하려면 경쟁 환경을 함께 봐야 합니다.

v0(Vercel)은 프롬프트에서 직접 UI 코드를 생성합니다. Figma를 거치지 않고 텍스트 프롬프트만으로 React 컴포넌트를 만드는 접근입니다. Locofy는 Figma 디자인을 코드로 변환하는 데 특화되어 있지만, 방향은 디자인→코드 단방향입니다. Builder.io는 양방향 변환을 지원하지만, 자체 에디터 생태계에 묶여 있습니다.

Figma MCP의 차별점은 두 가지입니다. 첫째, MCP 프로토콜 네이티브라는 점. 특정 에디터에 종속되지 않고 14개 이상의 클라이언트에서 동시에 작동합니다. 둘째, Figma 생태계 네이티브라는 점. 이미 전 세계 디자이너의 표준 도구인 Figma 안에서 작동하므로, 별도의 도구 전환이 필요 없습니다.

이것은 결국 네트워크 효과의 문제입니다. Figma의 기존 사용자 기반 위에 AI 에이전트 기능을 얹는 것과, 새로운 도구를 처음부터 채택하게 하는 것은 진입 장벽이 근본적으로 다릅니다.

전망과 시사점

단기: 베타에서 프로덕션으로

현재 write-to-canvas는 베타입니다. "85-90% 스타일이 틀렸다"는 피드백이 보여주듯, 품질 개선이 급선무입니다. 베타 졸업과 유료화 시점에서 Figma가 어떤 수준의 품질을 보여주느냐가 이 기능의 성패를 가를 것입니다. Skills 프레임워크의 커뮤니티 생태계 확장도 중요합니다. Uber, Edenspiekermann 같은 초기 파트너를 넘어, 더 많은 기업이 자사 디자인 시스템을 Skills로 공유해야 실질적인 네트워크 효과가 발생합니다.

중기: 디자인 도구의 AI 플랫폼화

Figma의 이번 행보는 디자인 도구가 AI 플랫폼으로 진화하는 흐름의 일부입니다. 단순히 디자이너가 사용하는 도구에서, AI 에이전트가 연결되는 플랫폼으로의 전환입니다. "디자인 핸드오프"라는 개념이 약화되면서, Figma는 디자인 도구를 넘어 디자인-개발 워크플로우 전체를 통합하는 플랫폼이 되려 하고 있습니다.

이 전환은 Figma의 사업 모델에도 영향을 줍니다. 기존에는 디자이너 수 기반 과금이었다면, MCP 호출 횟수 기반 과금은 개발자와 에이전트를 새로운 과금 대상으로 추가하는 것입니다. 디자이너 도구에서 개발자 플랫폼으로의 확장이, 매출 다변화의 기회이기도 합니다.

장기: 디자이너 역할의 재정의

가장 근본적인 질문은 이것입니다. 에이전트가 디자인을 생성하고 수정할 수 있는 세상에서, 디자이너의 역할은 무엇인가?

코딩 에이전트의 발전이 개발자의 역할을 "코드 작성자"에서 "아키텍트 + 리뷰어"로 전환시키고 있는 것처럼, 디자인 에이전트도 디자이너의 역할을 "실행자"에서 "감독자, 큐레이터, 시스템 설계자"로 전환시킬 가능성이 있습니다. 픽셀 단위의 수동 작업 대신, 디자인 시스템의 규칙을 정의하고, 에이전트의 출력을 평가하며, 브랜드 일관성을 관리하는 역할로의 이동입니다.

Skills 프레임워크는 이 변화의 초기 형태입니다. 디자이너가 마크다운으로 규칙을 작성하면 에이전트가 실행한다. 이 패턴이 성숙해지면, 디자이너의 핵심 역량은 "좋은 디자인을 만드는 것"에서 "좋은 디자인이 무엇인지 정의하는 것"으로 이동할 수 있습니다.

물론 이 전망은 아직 먼 미래의 이야기일 수 있습니다. 현재 에이전트의 디자인 품질은 프로덕션에 바로 쓸 수 있는 수준이 아닙니다. 하지만 방향은 분명합니다. 그리고 그 방향에서 가장 먼저 움직인 것이 Figma라는 사실이, 이 발표의 의미입니다.

---

Figma MCP write-to-canvas는 아직 베타이고, 품질 문제가 있으며, 가격 정책도 확정되지 않았습니다. 하지만 이것이 가리키는 방향은 명확합니다. 디자인과 코드 사이의 벽이 무너지고 있습니다. 에이전트가 그 벽 양쪽을 자유롭게 오가는 시대가 열리고 있습니다. 프론트엔드 개발자와 디자이너 모두, 이 변화에 어떻게 적응할지 고민을 시작해야 할 때입니다.