Figma에서 AI 에이전트가 디자인 파일을 읽고 텍스트·색·레이아웃을 바꾸게 하려면, 보통 MCP 서버와 클라이언트, Figma 플러그인을 차례로 연결해야 합니다. MCP Magic은 이 준비 과정을 데스크톱 앱으로 묶어, AI가 Figma를 처음 움직이는 순간까지 가는 길을 줄인 도구입니다.
Friends of Figma Seoul 운영진은 MCP Magic에 기여한 박주형님과 이서님에게 이 앱이 어떤 문제에서 출발했고 무엇을 남겼는지 물었습니다. 이 글은 두 운영자의 답과 프로젝트 데이터에, 초기 Talk To Figma 데스크톱 앱을 만든 진영님의 작업을 함께 엮은 기록입니다.
GA4에는 31,360명의 누적 사용자와 570,373건의 MCP 도구 호출이 남았습니다. 이 수치는 MCP Magic이 실제 사용자에게 닿은 프로젝트였다는 뜻입니다. 다만 두 운영자가 더 오래 붙잡은 질문은 따로 있었습니다. 사용자가 늘어난 뒤에도 이 경험을 어떻게 안정적으로 이어 갈지, 그리고 이 도구가 앞으로 어디에 남게 될지였습니다.
mcp_tool_call 이벤트를 남긴 활성 사용자는 1,633명이며, 두 값은 동일 사용자의 순서를 추적한 퍼널이 아닙니다. GA4 요청 범위는 2025.07.01–2026.06.30, 실제 유효 기록은 2025년 8월부터입니다. 성공률은 성공·실패 상태가 명시된 570,044건 기준입니다.Q. MCP Magic은 어떤 문제에서 시작했나요?
Figma에서 AI가 디자인을 읽고 고치는 장면은 처음부터 매력적이었습니다. 하지만 다른 사람에게 도구를 건네보면, 많은 이가 그 장면에 닿기도 전에 멈췄습니다. 런타임과 서버, MCP 클라이언트와 Figma 플러그인을 각각 설정해야 했고, 문제가 생기면 터미널과 플러그인 사이를 오가야 했기 때문입니다.
MCP Magic은 빈 곳에서 시작한 프로젝트가 아닙니다. 출발점에는 Grab Design 팀에서 사용하다 오픈소스로 공개한 Cursor Talk To Figma MCP가 있었습니다. 자연어로 Figma를 읽고 수정하는 핵심 기능은 이미 작동하고 있었습니다.
박주형님: “기능 자체가 부족한 게 문제는 아니었어요. 사용자가 처음 성공하기까지 거쳐야 하는 과정이 너무 복잡했습니다.”
2025년 7월, 박주형님과 진영님은 서비스 실행·설정·연결 상태·로그를 트레이 메뉴에 모은 Talk To Figma 데스크톱 앱을 GitHub에 공개했습니다. 이 간단한 앱은 현재 Grab의 공식 오픈소스이자 MCP Magic의 백본이 됐습니다.
이서님: “그 프로토타입을 봤을 때 ‘이거다’ 싶었어요. 처음에는 거창한 자동화보다 ‘딸깍’하면 서버가 뜨는 경험이 필요하다고 봤고요.”
이서님은 그 프로토타입을 계기로 프로젝트에 참여했습니다. 데스크톱 UI를 함께 다듬고, 복잡한 설정을 사용자 언어로 풀어내는 방식과 채널을 통한 홍보를 맡았습니다. 같은 해 10월, 팀은 이 기반을 MCP Magic이라는 패밀리 앱으로 확장해 출시했습니다. 사용자 의견을 들으며 여러 번 구조를 다시 썼지만, 붙들고 있던 질문은 바뀌지 않았습니다.
두 운영자가 붙들고 있던 질문: “어떻게 해야 더 많은 사람이 첫 연결을 지나 실제 작업까지 도달할 수 있을까요?”
앱이 MCP 자체를 더 강력하게 만든 것은 아닙니다. 이미 있던 기능에 도달하는 길을 짧고 분명하게 만든 쪽에 가깝습니다. 시작하기 전에 포기하게 된다면, 아무리 강력한 기능도 사용자에게는 없는 것과 다르지 않기 때문입니다.
Q. 실제로 사용되었다는 신호가 있었나요?
GA4의 실제 기록이 있는 11개월 동안 mcp_tool_call 이벤트를 한 번 이상 남긴 활성 사용자는 1,633명이었습니다. 이 값은 앱 전체 누적 사용자 31,360명과 이벤트별로 따로 집계됐으므로, 모든 사용자가 MCP 작업까지 갔다고 말할 수는 없습니다. 다만 이 핵심 사용층에서 570,373건의 MCP 도구 호출이 남았습니다. 이 가운데 536,267건은 성공, 33,777건은 실패로 기록됐습니다. 성공 또는 실패 상태가 명시된 호출만 보면 성공률은 94.1%였습니다.
이 1,633명은 AI와 Figma를 유료로 활용하는 프로 사용자층에 가까웠습니다. Cursor나 Claude Code 같은 AI 도구와 Figma 유료 플랜을 이미 업무에 쓰고 있었고, 그 위에서 MCP Magic까지 도입했습니다. 따라서 1,633명은 단순 설치나 무료 체험이 아니라, 새 워크플로를 실제 업무에 먼저 끌어들인 이른 초기 수용자층을 뜻합니다.
이 기록에서 가장 반가웠던 점은, 사용자가 연결 상태만 확인하고 떠나지 않았다는 사실입니다. create_text는 105,643회, set_fill_color는 92,561회 성공했습니다. 둘을 합치면 198,204회입니다. 도구 이름을 생성·복제와 스타일·콘텐츠 편집으로 묶으면 390,642건으로, 전체 성공 호출의 72.8%를 차지했습니다.
이서님: “정말 기뻤던 건, 사람들이 유행이라 한 번 찍어보고 떠나는 게 아니라 실제 작업에 쓰고 있다는 걸 체감했을 때였어요.”
박주형님과 진영님이 데스크톱 앱으로 연 가능성을, MCP Magic 팀은 더 많은 사람이 실제 작업까지 이어 갈 수 있도록 다듬었습니다. 호출 수만으로는 이들이 얼마나 깊게 사용했는지 알 수 없었지만, 적어도 AI가 Figma를 실제로 만지는 작업까지 도달했다는 흔적은 분명했습니다.
Q. 한 번 써보고 떠난 걸까요, 아니면 깊게 쓴 걸까요?
GA4가 도달 범위와 호출 규모를 보여줬다면, Aptabase export는 세션 안에서 MCP가 얼마나 깊게 쓰였는지를 보여줬습니다. 유행을 따라 가볍게 써보는 사용도 있었겠지만, 이 데이터에서 더 눈에 들어온 것은 오래 머물며 반복 작업을 이어 간 세션들이었습니다.
이미지의 수치가 보여주듯, 가볍게 연결을 확인하고 떠난 경우만 있었던 것은 아닙니다. 어떤 세션은 한 번 시작하면 꽤 오랫동안 이어졌고, AI에게 Figma 작업을 반복해서 맡겼습니다. MCP Magic은 일부 사용자에게 잠깐 시험해 보는 도구가 아니라, 길고 반복적인 디자인 작업 도구였습니다. 이서님이 체감한 ‘실제 사용’은 바로 이런 세션에서 가장 또렷하게 드러났습니다.
Q. 사용자가 늘면서 무엇이 달라졌나요?
Figma 인플루언서로 활동하며 여러 채널을 운영하는 이서님에게, Friends of Figma Seoul을 포함한 카카오톡 오픈채팅방과 여러 채널에서 다양한 질문이 들어오기 시작했습니다. 사용자가 늘면서 질문의 결도 달라졌습니다.
처음에는 신기해하는 반응이 많았습니다. 시간이 지나면서 설치 방법, 비용, 실제 활용법을 묻는 질문이 늘었습니다.
“정말 딸깍만 하면 디자인이 되나요?”
“이건 무료인가요?”
“Cursor에는 어떻게 설치하나요?”
정확한 이유를 단정할 수는 없습니다. 다만 AI나 MCP를 신기하지만 나와는 거리가 있는 일로 느끼던 시기는 빠르게 지나간 듯했습니다. 불과 1년 사이 많은 디자이너에게 이것은 업무에 바로 써야 할 도구가 됐고, 질문 사이에서는 급하게 배우고 써야 한다는 FOMO도 느껴졌습니다.
이 질문들은 결국 하나로 모였습니다.
서로 다른 사용자와 운영체제, MCP 클라이언트, 네트워크 환경에서도 계속 믿고 쓸 수 있게 만들 수 있는가?
사용자가 말하는 “안 된다”의 원인은 모두 달랐습니다. 서버나 포트, 플러그인의 채널, MCP 클라이언트 설정, 운영체제 보안 중 어디에서든 연결이 막힐 수 있었습니다. GA4에는 포트 바인드 문제를 만난 활성 사용자 1,539명, 서버 시작 핸들러 중복 1,231명, 요청 시간 초과 1,056명이 기록됐습니다.
원인은 달라도 사용자에게는 같은 말로 도착했습니다.
“안 돼요.”
호출 단위의 높은 성공률과 세션 단위의 마찰은 동시에 존재했습니다. GA4에서는 상태가 명시된 호출의 94.1%가 성공했지만, 별도 기간과 계측 방식의 Aptabase release 로그북에서는 MCP 세션 2,376개 중 1,424개(59.9%)에 실패 이벤트가 한 번 이상 남았습니다. 두 수치를 직접 비교할 수는 없습니다. 다만 관측된 MCP 세션 다수에 적어도 한 번의 실패 이벤트가 함께 남았다는 사실은, 호출 단위 성공률만으로 작업 중 마찰을 설명할 수 없다는 점을 보여줍니다.
이서님: “사용자가 늘면서 지원과 복구도 제품의 일부가 됐어요.”
이 과정에서 팀은 시작을 쉽게 만드는 것만으로는 충분하지 않다는 점을 확인했습니다. 사용자 수준에 맞는 진단과 복구, 연결 안정성, 지원 운영까지 갖춰야 했습니다. 이는 부가적인 운영 업무가 아니라, 다음에 만들어야 할 제품의 일부였습니다.
Q. 이 프로젝트는 앞으로 어떻게 되나요?
MCP Magic을 운영하며 팀은 언어 지원을 넓히고, 별도의 IDE 없이 로컬 LLM(Google Gemma 4)으로 작업하는 방식도 시험했습니다. 하지만 시간이 갈수록 큰 업데이트를 이어 갈 이유는 약해졌습니다. 사용량이 없어서가 아니라, 제품으로 만든 핵심 경험이 공식 플랫폼 안으로 들어가기 시작했기 때문입니다.
2026년 3월 Figma는 use_figma를 통해 에이전트가 캔버스에 직접 쓰는 베타를 공개했고, 5월에는 캔버스 안에서 바로 쓰는 Figma design agent를 발표했습니다. 문제 자체가 사라진 것은 아니었습니다. 그 문제를 푸는 기본 위치가 바뀌고 있었습니다.
독립 도구는 플랫폼의 경계가 얇은 곳에서 새 수요를 먼저 발견하곤 합니다. 수요가 충분히 분명해지면 파일, 권한, 디자인 시스템, 배포 기반을 이미 가진 플랫폼은 그 흐름을 더 짧은 경로로 자기 표면 안에 넣을 수 있습니다. 사용자에게는 자연스럽고 반가운 변화입니다. 반면 서드파티에는 기능의 성공과 독립 제품의 지속 가능성이 전혀 다른 문제라는 뜻이기도 합니다.
이것을 Figma가 MCP Magic을 보고 따라 했다는 이야기로 만들 수는 없습니다. 공식 기능이 사용자 감소를 일으켰다는 인과도 데이터로 증명하지 못합니다. 다만 MCP Magic이 증명한 것은 실제 수요였고, 플랫폼은 그 수요를 더 자연스럽게 풀 수 있는 구조적 위치에 있었습니다.
박주형님: “기능이 성공했다고 해서 독립 제품을 오래 운영할 수 있는 건 아니었어요.”
팀은 문제를 충분히 일찍 발견해 제품으로 만들었고, 수만 명과 57만 건의 호출로 수요를 증명했습니다. 하지만 그다음에 오래 책임질 진단·복구, 교차 플랫폼 연결, 특정 팀의 깊은 워크플로는 더 빨리 정하지 못했습니다. 단순히 늦어서 밀려난 게 아니라, 다음의 지속 가능한 자리를 늦게 정한 셈이었습니다.
그래서 MCP Magic은 종료보다 유지보수 모드에 가깝게 두기로 했습니다. 필요한 수정은 이어가되, 지금의 형태로 큰 기능 업데이트를 계속할 이유는 이전보다 작아졌습니다.
Q. 다음에는 무엇을 다르게 할까요?
두 운영자의 회고: “다음번에는 첫 문제를 푼 뒤에 무엇을 만들지 더 빨리 정해야 해요.”
돌이켜보면, 시작을 쉽게 만든 뒤 다음에 무엇을 할지 정하는 데 너무 오래 걸렸습니다. 두 운영자가 이 프로젝트를 돌아보며 남긴 메모는 세 가지입니다.
첫째, 다음 목표를 더 빨리 좁혔어야 했습니다. 설치 도우미로 남을지, 연결 진단과 복구 도구로 갈지, 반복 사용이 많은 Figma 작업을 하나의 워크플로로 묶을지 정하지 못했습니다. 첫 번째 문제가 풀린 뒤에는 새로운 제품 가설이 필요했습니다.
둘째, 지원의 경계를 분명히 했어야 했습니다. 어디까지가 앱의 책임이고 어디부터가 Figma 플러그인, MCP 클라이언트, 운영체제, AI 비용의 문제인지 더 명확히 했어야 했습니다. 반복되는 “안 된다”를 자가 진단과 복구 흐름으로 바꾸는 일도 기능 개발만큼 중요했습니다.
셋째, 사용 데이터를 다음 가설에 더 일찍 연결했어야 했습니다. 뒤늦게 데이터를 정리하고 나서야 넓은 발견, 호출이 집중된 일부 작업 세션, 높은 호출 성공률과 실패 이벤트가 함께 남은 세션이 동시에 보였습니다. 출시 초기부터 시작, 첫 성공, 반복 사용, 실패 이후의 행동을 나눠 봤다면 업데이트 우선순위도 달라졌을 것입니다.
Q. 57만 번의 호출은 무엇을 남겼나요?
이 프로젝트가 증명한 것은 수요였지, 그 수요를 영구히 소유할 권리는 아니었습니다.
MCP Magic은 사용자가 AI로 Figma를 실제로 다루는 지점까지 가는 첫걸음을 줄였습니다. 그 기록에는 텍스트를 만들고, 색을 입히고, 프레임을 만들고, 레이아웃을 다듬은 작업이 남았습니다.
동시에 마지막 20%에는 진단과 복구, 운영과 지원, 그리고 어디까지 책임질지에 대한 선택이 남았습니다. 공식 플랫폼이 같은 문제를 더 자연스럽게 풀기 시작한 뒤에는 무엇을 만들 수 있느냐보다 무엇을 오래 책임질 수 있느냐가 더 중요한 질문이 됐습니다.
박주형님과 이서님: “이건 실패의 기록도, 업데이트를 멈추는 변명도 아니에요. 성공한 기능과 유지보수 모드에 들어간 제품은 함께 존재할 수 있어요.”
57만 건의 호출은 박주형님과 진영님이 시작하고 이서님이 함께 확장한 일이 옳은 문제를 풀었다는 증거입니다. 동시에 다음에는 지속 가능한 자리를 더 일찍 정해야 한다는 청구서이기도 합니다.