2025년 상반기, 피그마(Figma)는 오픈 베타 버전을 공개하며 새로운 기능을 추가했다. 바로 ‘Figma MCP Server’ 기능이다. 기능이 공개된 이후 많은 개발자들이 직접 사용해 보았고, 이에 대한 다양한 후기가 나오기 시작했다. 아직은 베타 단계라 부족한 부분도 있지만, 올해 가장 큰 흐름 중 하나인 MCP(Multi-Context Protocol)의 등장에 피그마도 뒤처지지 않기 위해, 해당 기능을 선보인 것으로 보인다.

이 글을 작성하는 시점(2025년 10월)에도 여전히 오픈 베타 단계라, 정식 출시 여부는 아직 알 수 없다. 그럼에도 디자이너와 개발자의 협업 방식에 큰 영향을 주는 중요한 기능이기에, 이번 글에서 살펴보고자 한다.

피그마 MCP란?

먼저 피그마 MCP가 무엇인지 살펴보자. 피그마 공식 홈페이지에는 다음과 같이 설명하고 있다.

“피그마 MCP 서버는 피그마 디자인과 Make 파일로부터 코드를 생성하는 AI 에이전트에 중요한 컨텍스트를 제공함으로써, 개발자가 디자인을 빠르고 정확하게 구현할 수 있도록 돕는 서버이다. Figma MCP 서버에 포함된 도구들은 Figma의 추가적인 맥락을 워크플로우에 가져와, 코드가 기존 시스템에만 맞는 것이 아니라, 디자인에도 일치하도록 만들어 준다.”

쉽게 말하면, 피그마 애플리케이션과 우리가 작성하는 코드(이 코드를 작성하는 AI 에이전트) 사이에 서버를 하나 두는 것이다. 현재는 로컬에서 개발 서버를 띄워서 사용할 수 있고, 그 서버가 피그마의 작업 컨텍스트를 가지고, 디자인 작업물을 코드로 구현해 주는 개념이다.

Figma-Context-MCP 라는 이름으로 깃허브에서 소스코드를 제공하며, 문서가 한국어로도 작성되어 있어서 서버를 어렵지 않게 로컬에서 실행할 수 있다.

이미 피그마에는 데브 모드에서, 디자인 결과물을 코드로 변환해 주는 플러그인(e.g. Figma to Code, Anima 등)이 있었다. 그런데 왜 피그마는 MCP를 또 만든걸까? 나도 그렇고, 주변 동료들을 봐도 피그마에서 디자인 결과물을 일괄 코드로 변환해 주는 플러그인은 잘 사용하지 않는다. 단순 프로토타입을 한 번 만들어 볼 때가 아니라면 말이다.

그 이유는 현업에서 작성하는 코드는 보통 디자이너가 작성해 준 디자인 규칙 안에서 작성되기 때문이다. 색상, 컴포넌트, 길이 단위, 레이아웃 등 그냥 작성되는 것이 아니고, red-100, Button 컴포넌트, radius-200, Overlay 등과 같이 미리 작성된 규칙에 따라 다르게 작성된다. 이러한 규칙은 회사마다 다르다. 보편적으로 사용하는 디자인 시스템(e.g. Material UI, Radix, Chakra UI 등)을 사용하는 곳도 있다.

기존 플러그인들은 이러한 각각의 프로젝트마다 사용되는 “문맥(Context)”은 고려하지 않고, 코드를 만들었기에 개발자들의 필요를 충족시키지 못했다. 따라서 이러한 한계를 극복하기 위해, MCP 기능을 추가한 것으로 보인다.

피그마 MCP는 어떻게 동작할까?

우선 피그마 MCP의 사용 방법은 공식 문서에 자세히 나와 있다. 차근차근 따라 하면 어렵지 않게 사용할 수 있다.

로컬에서 개발 MCP 서버를 실행한다. (e.g. http://127.0.0.1:3456/sse)
Cursor, VS Code 같은 IDE/AI Agent에서 MCP 서버 설정해 준다.
명령 프롬프트를 작성한다. 예를 들면, 피그마의 어떤 레이어 링크를 복사해서 프롬프트에 붙여 넣은 뒤, react 코드로 구현해 달라고 하는 식이다.

그렇다면 피그마 MCP는 어떻게 작동할까? 피그마는 MCP 서버와 HTTP + SSE(Server-Sent Event) 방식을 통해 요청을 주고받는다. 양방향 모델을 지향하지만, 웹소켓처럼 완전한 실시간 양방향 통신을 요구하지는 않는다. 대신 클라이언트에서 서버로, 예를 들어 “A 페이지의 피그마 레이어를 React 코드로 구현해줘”와 같은 요청을 전달하면, 서버가 클라이언트로 스트리밍 형태의 응답을 푸시하는 구조가 더 효율적이다.

실제로 사용해 보면 핸즈온 과정이 매우 간단하다. HTTP 기반으로 통신하기 때문에, 프록시나 방화벽 환경에서도 제약이 적다는 장점이 있다. 또한 폴링 방식의 경우 요청 주기가 짧으면, 오버헤드가 쉽게 발생하지만, SSE(Server-Sent Event)는 하나의 연결로 여러 이벤트를 푸시할 수 있어, 폴링 대비 CPU와 네트워크 자원 낭비가 적다는 이점이 있다.

아래 그림은 MCP에서 SSE 방식 통신을 클라이언트와 서버가 어떻게 주고받는지를 나타낸 그림이다. 클라이언트는 IDE나 AI Agent, 서버는 우리가 로컬에서 띄운 MCP 서버라고 생각하면 된다.

업무에 이렇게 써봤습니다

나의 경우, 이미 실무에서 피그마(Figma)를 사용하고 있었는데, 이번에 웹 프론트엔드 개발 과정에서 피그마 MCP를 활용해 개발을 진행했다. 처음에는 명령을 단순하게 작성했다. 예를 들어, “A 페이지를 React, TypeScript 기반의 코드로 작성해줘.”라고 요청했더니, 실무에서는 사용할 수 없는 수준의 코드가 생성되었다. 누군가에게 간단히 시연하는 코드로는 가능했지만, 지속적으로 발전시키며 실제 서비스에 적용하기에는 적합하지 않은 결과물이었다.

그래서 컨벤션에 해당하는 문서를 추가로 작성해 주었다. 원래 커서를 쓰고 있었는데, 커서는 .cursor/rules 하위에 .mdc 파일 형식으로 문서를 작성하면 커서가 그 문서를 읽고 이걸 바탕으로 코드를 짜 준다. (자세한 내용은 참고 문서를 통해 확인할 수 있다.) 여기에 나는 우리 팀에서 사용하는 코딩 컨벤션이나, 디자인 시스템, 아키텍처 등을 추가했다. 이렇게 하니 조금 더 퀄리티가 좋아졌다.

그럼에도 여전히 현업 개발자가 짜는 코드 수준에는 아쉬운 부분들이 보였다. 예를 들어, 페이지 전체를 만들어 달라고 하면, 디테일한 부분에서 조금씩 차이가 발생해서 컴포넌트 단위로 요청하기도 했다. 그리고 이미지나 아이콘을 불러오지 못하는 경우가 있는데, 확인해 보니 환경 설정에서 get_image를 활성화해야 해당 이미지를 불러올 수 있었다.

반응형 레이아웃도 잘 만들어 주지 못했다. 이 경우에는 오토 레이아웃을 사용해 반응형 의도를 전달해야 한다. 이렇게 피그마 작업을 하는 부분에서 신경써야 하는 부분이 많다. 그래서 바람직한 방법은 디자이너와 개발자가 같이 피그마 MCP를 써서 생산성을 높이는 것에 합의하고, 디자인 작업도 이에 맞춰 전달해 주는 것이다. 디자이너가 피그마 MCP에 적합하지 않게 기존처럼 작업하면, 개발자가 아무리 프롬프트를 잘 작성해도 원하는 결과물을 얻는 데 한계가 있다.

따라서 피그마에서 디자인 시안을 일관성 있게 작업했다면, 피그마 MCP를 활용해 AI로 초안 코드를 빠르게 생성하고, 그 이후 세부적인 부분을 사람이 보완하는 방식이 적합하다. 다만 팀마다 작업 환경과 프로세스가 다르고, 피그마를 이런 방식으로 활용하지 않는 경우도 있다. 그런 상황에서는 피그마 MCP가 오히려 생산성을 떨어뜨릴 가능성도 있다. 결국 팀의 상황과 워크플로에 맞게 도입 여부를 판단하는 것이 매우 중요하다.

마치며

지금까지 피그마 MCP 소개와 동작 원리, 실무 사용기를 살펴보았다. 물론 아직 오픈 베타 버전이지만, 기대했던 것보단 다소 아쉬운 점이 많았다. 그래도 앞으로 디자이너와 개발자가 일하는 방식을 혁신적으로 변화시킬 수 있을 것이라는 점에는 동의한다. 이처럼 디자인 도구에서 코드로 이어지는 과정이 점점 더 고도화되고 자동화된다면, 프론트엔드 개발자의 역할도 변화할 것 같다.

과거에는 화면을 의도한 대로 정확하게 구현하는 능력이 핵심 역량이었다면, 이제는 그 역할을 AI에 맡기고, 화면을 어떤 사용자 경험(UX)으로 구성할지, 그리고 전체 설계를 어떻게 풀어낼지에 대한 기획적·창의적 사고가 더욱 중요해질 것 같다.

지금 당장은 피그마 MCP가 실무에 큰 도움이 되지 않을 수도 있다. 그러나 이런 새로운 기능들을 이해하고, 기회가 될 때마다 조금씩 직접 활용해 보는 자세가 결국 트렌드를 놓치지 않는 개발자로 성장하는 길이라고 생각한다.