Figma MCP

금일에는 Figma에 대한 내용으로 특강을 듣고, 챌린저분들께 제가 이전에 Figma를 사용해본 경험에 대해서도 발표했던 뜻깊은 시간이었습니다. 발표 내용은 “’Framelink MCP for Figma’를 사용해본 경험”에 대해 말씀을 드렸는데요, 오늘은 간단하게 MCP가 무엇인지와 제가 Figma MCP를 사용해본 경험에 대해 말씀드리고자 합니다.

MCP?

우선 MCP란 ’Model Context Protocol’이라고 하는 일종의 통신 규약입니다. 각 서비스의 모델은 서비스마다 구현한 언어, 환경, 역할이 다 가지각색이기 때문에 다른 서비스에서 사용하기 위해서는 그 서비스의 모델을 해석해야 합니다. 이를 하나의 통신 규약으로서 제공하여 여러 서비스에서 사용할 수 있도록 하는 것이 MCP의 핵심 역할입니다. 강사님께서 말씀하신 ’젠더’라는 비유가 딱 적절한 것이죠.

프론트엔드 개발자로서 프로젝트에 들어가면 디자이너, 기획자가 Figma로 만든 디자인을 보고 화면을 구현해야 하는데요,

TMI로 예전에 ’토스(Toss)’의 프론트엔드 개발자 분을 뵌 적이 있었는데, ’간단한 UI를 만들고…’와 같은 질문에 ’우선 UI가 제일 어렵다’라는 답변을 들었던 적이 있습니다. 그만큼 처음부터 끝까지 레이아웃을 구성한다는 것이 보통 쉬운 일이 아니라고 생각합니다. 컴포넌트도 분리해야되고, 레이아웃도 만들어야하고, 노가다도 필요한 것 같구요.

저는 우선 처음 div를 짜놓고 ‘흠..’ 하고 고민합니다. 그러고 구조를 그려보거나 머릿속에 있는 것을 바탕으로 하나씩 시멘틱 태그를 작성합니다. (ReFlow) 그 다음 디자인을 입히고, 직접 검수를 합니다. (Repaint & Check) 제 경험상 처음 이 구조를 짰을 때 물론 결과가 잘 나왔던 적도 있지만, 하나씩 이상하게 구조화가 되어있는 부분도 있었습니다.

이 Reflow와 Repaint과정 자체를 고민하고, 구현하는 비용은 매우 컸습니다. 예전에 참여했던 ’해커톤’에서 크게 체감할 수 있었는데요, 아무리 제가 빠르게 UI를 그렸다고 해도, UI 구현에 너무 많은 시간을 쏟게 되었습니다.

또한 Figma에서도 기본적인 snippet을 주긴 하지만, 그렇다고 현재 프로젝트의 아키텍처를 파악하지는 못합니다. 결국 개발자가 기존 코드에서 변환해주는 작업을 하거나, tailwind같은 CSS 모듈을 사용한다면, 더욱 더 구현하기 힘들어집니다.

이러한 비용적인 리스크를 MCP는 간단하게 해결합니다.

Figma에서 공식적으로 제공하는 MCP는 ’Framelink MCP for Figma’인데요, Figma는 기본적으로 다양한 형식으로 복사하는 기능이 있어 URL로 특정 Frame의 영역을 복사해서 코드로 빠르게 변환합니다.

다른 MCP를 연결시켜주는 작업과 동일하게 Figma MCP도 연결 작업을 해줘야합니다.

절차

FIgma에서 private한 토큰을 발급한다. 토큰은 대개로 figd_dsdfq23ed... 이런식으로 주어집니다.
Smithery와 같은 mcp 제공 사이트(https://smithery.ai/)에서 ‘Framelink MCP for Figma’를 검색해서 “mcpServers”객체의 코드를 붙여넣습니다.
사용하는 텍스트 에디터(VSCode, Cursor, Windsurf, Zed, …)Agent에서 MCP를 등록합니다. --figma-api-key="" 여기서 Figma에서 발급한 토큰을 넣어줘야합니다.
Figma Dev모드로 들어가서 구현해야되는 Frame을 선택하고 우측 사이드바에 있는 mcp 코드를 붙여넣습니다. (없으면 Figma에서 mcp를 허용해주고, ’mcp를 활성화 하시겠습니까?’와 같은 문구가 떴을 때 확인을 눌렀던 것으로 기억합니다.)
Agent에 붙여넣습니다.

전반적으로 이렇게 진행이 되는데, 여러번 해보면서 느꼈던 점은 ‘잘 짜여진 Frame이 정말 중요하다.’ 였습니다.

디자인이 구현된 Frame은 어느정도 ‘우리 눈에는 잘 구현된 것처럼’ 보입니다. 보기에는 적절한 위치에 잘 배치되어 있으니까요. 여기서 MCP의 한계가 드러납니다.

AI는 시키는 일은 참 잘합니다. 하지만, 구체화된 컨텍스트를 넣지 않는다면 결국은 패턴화된 태스크 내에서만 수행합니다. (아직까지는.)

좀 더 구체적으로 말씀을 드려보자면,

모든 UI 구성은 전부 트리구조로 이루어져 있습니다. ’부모-자식’간의 관계로 밀접하게 연결되어있어서 계층 관계를 철저하게 지킵니다.

하지만, 이런 계층 관계를 정해주지 않았다면 어떻게 될까요? AI는 본인이 생각하는 나름의 창의성을 발휘해(?) 패턴화된 습관을 갖고옵니다. 그게 그들이 학습하는 방식이고, 원하는 결과가 안나오는 이유죠.

Figma는 코드의 snippets을 준다고 했었죠. 결국 계층화되지 않은 Frame은 이상한 코드(snippets)를 반환하기 마련입니다.

예시를 들어보겠습니다.

디자이너가 그룹화(Ctrl + G)나 프레임(Alt + A)을 잡지 않고, 그냥 캔버스 위에 아이콘, 텍스트, 배경을 흩뿌려 놓았다고 가정해봅시다. 눈으로 보기엔 버튼처럼 보이지만, 실제로는 그냥 겹쳐져 있는 상태입니다. 이에 Figma AI는 ’음… 좌표를 보니까 텍스트가 아이콘보다 5px 위에 있어. 하지만 둘은 아무 관계가 없어.’라는 추측을 합니다.

이번에는 디자이너가 아이콘과 텍스트를 하나의 ’Auto Layout Frame’으로 묶고, ’버튼’이라는 이름을 붙였다고 해봅시다. AI의 해석은 ’아! 이 두 요소는 부모 프레임 안에서 수평으로 정렬되어 있고, 간격은 8px이구나.’를 알게됩니다.

#1의 케이스는 AI의 창의성 공포로 인해서 제대로된 UI를 반환하지 않겠죠. (Garbage In Garbage Out) #2의 케이스는 확실한 컨텍스트를 주었기 때문에 AI가 제대로된 디자인을 구현하겠죠.

결국 제대로 된 Frame을 만들어야 제대로된 Return이 나온다는 점이 명확한 한계점이라고 할 수 있습니다. ’대충 만든 와이어프레임’과 ’오토레이아웃, 네이밍, 그룹화 등을 고려한 구조화된 와이어프레임’을 AI를 통해서라도 만들어보고, mcp를 사용하시면 큰 체감을 느끼실 수 있기 때문에 기회가 되시면 꼭 해보시는 것을 추천드립니다. (사실 요즘엔 와이어프레임 대충 짜도 위 과정처럼 링크도 받을 뿐만 아니라 직접 피그마 사이트로 접근해서 이미지 캡처하는 2중 체크를 하더라구요. 그래도 조금 부족하긴 한데..)

결론 : MCP를 사용하면 정말 많은 비용을 아낄 수 있고 확보한 비용을 비즈니스 로직을 구체화하는 데에 사용할 수 있습니다.

이러한 AI의 발전, MCP, 심지어 ’React Compiler’마저도 결국 비즈니스 로직에 초점을 둬서 서비스의 안정성을 확보하기 위한 전략이라고 생각하기 때문에 직접 구현하는 것도 좋지만, 다른 데에 초점을 맞춰야한다면 mcp를 연결해서 해결해보는 것도 좋은 방법이라고 생각합니다.