최근 MCP(Multimodal Contextual Prompting) 라는 기술이 여러 곳에서 활발하게 언급되고 있는 것을 보았다. 문득 프론트엔드 분야에 적용할 수 있는 부분이 있을까? 하는 궁금증이 생겼다.
조금 찾아보니, Figma-Context-MCP라는 라이브러리를 통해 Figma와 AI 에디터를 연동해 사용하는 방법을 확인하여 이번 기회 적용하고자 한다.
Cursor 에디터 MCP 서버 셋팅하기
이전에는 해당 라이브러리를 클론한 뒤 로컬에서 직접 서버를 실행하고, MCP 서버를 별도로 구성하는 방식이었으나, 최근에는 설정 방식이 표준 입력(STDIN)과 표준 출력(STDOUT)을 활용하는 구조로 변경된 것을 확인하였다.
이제는 JSON 설정 파일에 MCP 명령어를 정의하면, Cursor가 해당 명령어를 실행하여 로컬에서 MCP 프로세스를 직접 구동하고, 별도의 서버를 띄우지 않고도 Cursor와 MCP 간의 통신이 가능해졌다.
우선 MCP와 연동할 피그마 토큰값이 필요하며, 사내 피그마의 디자인 UI를 테스트할 예정이라 회사 계정을 통해 토큰값을 설정하였다.
피그마 토큰값 셋팅 화면
피그마 토큰값을 수령한 후 MCP settings JSON에 아래와 같은 코드를 작성한다.
{
"mcpServers": {
"Framelink Figma MCP": {
"command": "npx",
"args": [
"-y",
"figma-developer-mcp",
"--figma-api-key=피그마 토큰값",
"--stdio"
]
}
}
설정을 완료했다면 아래와 같은 캡쳐 화면이 나타나며 녹색 알림불이 뜬 것은 MCP 서버가 정상적으로 동작 중이라는 것을 의미한다.
Figma MCP 적용해 본 결과
Figma 디자인 요소 영역의 링크를 복사하여 Cursor AI 에디터에 붙여 넣고 컴포넌트를 만들어 달라고 요청하면 위 첨부된 이미지 화면처럼 70% 정도의 비슷한 결과물이 나왔다.
(적용 전에 AI에게 불필요한 작업 및 재질문을 할수도 있는 우려가 발생할 수도 있기 때문에 필히 AI 제너레이터 규칙에 관한 마크다운 글을 하나 생성하고 같이 첨부 하는게 좋다!!)
예시는 아래와 같다.
# 피그마 MCP AI 자동 코드 생성 규칙
## MCP 실행 설정 이름
@name Framelink Figma MCP
## 파일 생성 경로
@Folder: 파일 생성 경로
- UI 컴포넌트 파일: `src/components`
- 아이콘 파일: `src/icons`
## AI 작업 규칙
@File 파일 생성 규칙
1. 상위 폴더는 UI의 역할 기준으로 생성한다. (예: `Sidebar`, `LoginForm` 등)
2. 모든 파일명은 PascalCase 사용한다. (예: `Sidebar.tsx`)
3. 컴포넌트 파일과 Storybook 파일은 필수이다.
4. 파일 종류별 명명 예시
- 컴포넌트: `Sidebar.tsx`
- 스토리북: `Sidebar.stories.tsx`
- 상수 데이터: `sidebar.data.ts`
- 타입 정의: `sidebar.type.ts`
5. 아이콘 생성 시 예제 파일 참고
- 참조 파일 경로: `/SampleIcon.tsx`
🔎 확인된 주요 단점 및 제약
- 상태/입력 의존 UI에 적용 난이도 높음
- 회원가입, 필터/조건 선택 등 상태 변수가 많은 UI와 입력 필드가 많은 페이지에서는 오히려 자동 완성된 코드 수정하는데 시간적 소요 발생
- 타 라이브러리 (예: React Hook Form)와의 연동을 위해 디테일한 의견을 정리하여 AI에게 전달 필요
- 디자이너 리소스 추가 발생 가능
- Figma에서 컴포넌트 구조/명칭/속성 정합성 유지가 필요
- 이는 디자이너가 Cursor 연동을 염두에 두고 작업해야 하기 때문에 기획 외 리소스 발생 가능
- SVG 아이콘 등 복잡한 UI 컴포넌트 처리 실패
- 특히 아이콘이 다수 포함된 UI에서 아이콘 다운로드 누락 또는 깨진 아이콘 형태가 종종 발생(깃헙에서 여전히 문제 있는 이슈로 확인)
🔎 확인된 장점
- 정적 페이지의 빠른 스케치 작업
- 상태 변수나 API 호출이 없는 정적인 페이지에서는 AI가 컴포넌트 구조와 스타일을 빠르게 자동 생성하므로 간단한 수정만으로 빠르게 화면을 구성할 수 있어, 기본 틀 구조가 필요한 1차 스케치 속도를 높이는 데 효과적
이해가 안가는 의문점
사내 Figma 디자인 컴포넌트는 디자이너분들이 디자인 시스템을 기반으로 컬러 및 타이포그래피 토큰을 잘 설정해두었다. 그러나 MCP를 통해 컴포넌트를 생성할 때마다 컬러의 HEX 코드나 폰트 크기를 임의로 지정해야 했고, 디자인 시스템에 정의된 컬러 토큰 및 타이포그래피 토큰 값을 제대로 불러오지 못하는 문제가 발생하고 있었다.
사실 위 문제만 해결되어도 MCP를 활용하여 생성된 컴포넌트 결과물은 70%에서 90% 정도로 향상될 것이 보이니 매우 답답했다.
Figma-Context-MCP 라이브러리 이슈 글들을 찾아보니 내가 겪고 있는 동일한 문제의 글이 발견 되었다.
Github 이슈 글
확인 결과, 해당 라이브러리 제작자에 따르면 “변수를 검색하는 API는 Figma 엔터프라이즈 플랜 구독자에게만 제공된다”고 한다.
결국 현재 사용 중인 Figma 디자인 시스템에서 설정된 토큰 변수값들은 MCP를 통해 가져올 수 없는 상황이었다. 즉, 디자인 시스템 기반으로 구축된 Figma 작업 환경에서 MCP 방식을 적용하기에는 아직 기능적인 제약이 많고, 실무에 활용하기에는 부족한 부분이 있다고 판단되었다.
결론
이러한 여러 문제를 깊이 있게 고려해보았을 때, 현시점에서 MCP를 통한 UI 자동 생성 방식은 실무에서 활용하기에 다소 무리가 있다는 결론에 도달했다.
- 디자인 가이드는 완전한 결과물이 아니며, 실제 개발 과정에서 예외 상황을 개발자가 직접 찾아내거나, 디자이너의 의도를 해석해 보완하는 작업이 빈번하게 발생한다. 특히 반응형 UI처럼 다양한 뷰포트를 고려해야 하는 경우, 개발자가 여러 디자인 요소를 조합해 구현해야 하므로 정성적인 판단이 요구된다. 이러한 특성상, UI를 AI로 생성하는 것은 적합하지 않다고 판단된다.
- UI 컴포넌트를 개발할 때 가장 중요하게 고려해야 하는 부분은 시각적 뷰보다는 그 내부 로직이다. 이 로직을 구현하기 위해 컴포넌트 설계가 선행되며, 많은 경우 개발자는 그 설계를 코드로 바로 옮긴다. 그러나 MCP를 활용하면 이 설계를 먼저 문장으로 정리하고, 다시 MCP에 전달해야 하며, 기대한 대로 동작하지 않을 경우 오히려 시간적 손실이 발생할 수 있다.
- Figma-Context-MCP는 아직 공식적으로 릴리스된 지 오래되지 않은 초기 단계의 도구이기 때문에, 실무에 완전히 적용하기 위해서는 기능적 안정성과 개선을 위한 시간적 여유가 필요하다.
디자이너, 개발자, 기획자 등 다양한 포지션이 협업하여 만들어내는 조직 내 Figma 결과물에 Figma MCP를 그대로 반영하기에는 아직 한계가 있다. 그러나 명확한 디자인이 확립되지 않은 제로베이스에 가까운 프로젝트이거나, 빠르게 프로토타입을 제작해 시연하거나 내부 공유가 필요한 상황에서는 Figma MCP가 충분히 효율적인 도구로 활용될 수 있다고 본다!