연결을 제품으로 만든 시간: MCP Magic 앱 회고

첫 실행의 불안을 줄인 작은 데스크톱 앱이 실제 디자인 작업까지 도달하기까지

MCP Magic 앱의 핵심 가치는 기능을 하나 더 추가하는 것이 아니었다. 첫 실행과 첫 연결까지의 불안을 줄이는 것이었다.

Figma를 AI와 연결해 실제 디자인 작업을 시키는 일은 재미있고 유용했다. 하지만 다른 사람에게 직접 써보게 하는 순간 문제가 보였다. 많은 사람이 가치에는 공감했지만 첫 실행과 첫 연결 앞에서 멈췄다.

Bun을 설치하고, setup을 실행하고, WebSocket 서버를 띄우고, Cursor의 MCP 설정을 고치고, Figma 플러그인을 연결하고, channel을 맞춰야 했다. 문제가 생기면 터미널 로그와 플러그인의 상태를 함께 봐야 했다. 개발자에게도 번거로운 과정이었고, 디자이너나 비개발자에게는 시작하기 전부터 불안한 과정이었다.

그래서 이 과정을 설치 가능한 데스크탑 앱으로 만들었다. 앱 안에서 서버를 실행하고, 상태를 보고, 설정을 복사하고, 로그를 확인할 수 있게 했다. 한국에서 유행하는 표현을 빌리면, 앱에서 “딸깍”하면 서버가 뜨는 경험을 만들고 싶었다.

2025년 7월 18일, 먼저 KMP 기반 TalkToFigma Desktop v1을 공개했다. 같은 해 10월에는 MCP Magic이라는 이름의 패밀리 앱과 배포 페이지로 확장했다. 사용자 의견을 받은 뒤 2026년 1월 20일부터 Electron 재작성을 시작했고, 1월 28일 KMP와 Gradle 코드를 걷어낸 Electron-only v2.0.0을 공개했다. 다음 날에는 전체 기능을 옮긴 v2.0.1이 이어졌다. 이 과정은 공동 기여자인 Yiseo, Jin과 함께했다. 이후 언어 지원을 넓혔고, 베타 단계에서는 로컬 LLM을 사용해 별도의 IDE 없이도 쓸 수 있는 방식까지 시도했다.

결과부터 말하면 이 방향은 맞았다.

이 프로젝트는 아무도 쓰지 않은 실험이 아니었다. 더 중요한 것은 사람들이 앱을 열어보기만 한 것이 아니라, 실제로 Figma를 만들고 수정했다는 점이다.

다운로드 수는 활성 사용자 수와 같은 뜻이 아니다. 같은 사람이 Store와 GitHub에서 각각 내려받거나, 업데이트와 재다운로드로 여러 번 기록될 수 있다. 그래도 이 수치는 앱이 실제로 여러 배포 채널을 통해 넓게 도달했다는 보조 근거가 된다.

Keep: 첫 연결을 제품 경험으로 바꿨다

MCP Magic은 빈 곳에서 시작한 프로젝트가 아니다. 그 출발점에는 이미 Grab Design 팀에서 반복적인 Figma 작업을 줄이는 데 쓰이던 Cursor Talk To Figma MCP가 있었다. 이 도구는 Cursor와 Figma를 연결해, 자연어로 디자인을 읽고 수정하고 반복 작업을 자동화할 수 있게 했다. 어떻게 만들어졌고 왜 오픈소스로 공개됐는지는 Grab의 공식 소개 글에서 확인할 수 있다.

즉 이 프로젝트의 출발점은 “Cursor와 Figma를 연결할 수 있는가?”가 아니었다. 이미 유용하게 작동하던 워크플로를, 더 많은 사람이 첫 실행부터 실제 사용까지 무리 없이 이어갈 수 있게 만들 수 있는가였다.

하지만 코드와 터미널을 중심으로 한 도구를 처음 쓰는 사람에게는 시작 전 준비가 많았다. Bun 설치, WebSocket 서버 실행, MCP 클라이언트 설정, Figma 플러그인 연결, channel join이 각각 다른 도구와 상태에 걸쳐 있었다. Windows와 WSL 환경에서는 추가 설정도 필요했다.

MCP Magic이 하려던 일은 이 복잡도를 하나의 제품 표면으로 가져오는 것이었다.

• 앱을 실행한다.
• 앱에서 서비스를 시작한다.
• 서버와 연결 상태를 본다.
• MCP 설정을 복사한다.
• 문제가 생기면 로그를 확인한다.
• 시스템 트레이에서 실행 상태를 유지한다.

작아 보이는 변화지만 중요한 변화였다. MCP가 아무리 강력해도 첫 연결 전에 사용자가 포기하면 아무 일도 일어나지 않는다. 우리는 스크립트를 하나 더 만드는 대신, 첫 성공 호출까지 갈 수 있는 설치 가능한 제품을 만들었다.

실제 사용자에게 도달했다

2025년 7월 1일부터 2026년 6월 30일까지 GA4에는 31,360명의 활성 사용자가 기록됐다. Windows 활성 사용자는 21,090명, macOS 활성 사용자는 10,444명이었다. 한국에서 만든 작은 데스크탑 앱이었지만 GA4에는 (not set)을 포함한 165개의 country 값과 37개의 언어 값이 남았다.

영어 사용자가 18,875명으로 가장 많았고, 러시아어 4,094명, 한국어 2,766명, 프랑스어 1,209명, 중국어 990명 순이었다. 나중에는 러시아어와 힌디어를 지원하는 하드포크 앱도 등장했다. 이 문제는 한국이나 특정 커뮤니티의 호기심에만 머물지 않았다.

사람들은 실제 디자인 작업에 사용했다

1년 동안 기록된 MCP 호출은 570,373건이었다. 이 가운데 536,267건은 성공, 33,777건은 실패로 기록됐다. 성공 또는 실패 상태가 명시된 호출만 놓고 보면 성공률은 약 94.1%였다.

사람들이 남긴 사용 흔적은 바이브 코딩으로 디자인을 만드는 가장 일반적인 흐름에 가까웠다. 먼저 AI가 현재 Figma 문서와 선택한 요소를 읽어 맥락을 파악한다. 그다음 그 결과를 바탕으로 텍스트를 채우고, 화면의 구조를 만들고, 색과 형태를 다듬는다.

읽기와 상태 확인은 더 많은 사람에게 넓게 쓰였지만, 실제 사용량을 끌어올린 것은 생성과 수정의 반복이었다. 텍스트 레이어 생성은 105,643회, 색상 적용은 92,561회, 화면 구조 생성은 52,509회 성공했다. 전체 성공 호출의 72.85%가 생성·복제·스타일·콘텐츠 편집에 몰렸다.

사용자가 좋아한 것은 단순한 연결이 아니라 AI가 Figma를 실제로 만지는 순간이었다.

이 차트가 보여주는 것도 같은 흐름이다. 사용자는 AI에게 현재 디자인을 반복해서 읽히고, 읽은 내용을 바탕으로 텍스트와 화면 요소를 채우고 수정했다. 한 번의 명령으로 끝나는 연결이 아니라, AI가 Figma의 상태를 계속 확인하면서 결과물을 만들어 가는 작업 환경이었다.

잠깐 열어본 앱에 그치지 않았다

GA4가 도달 범위와 호출 규모를 보여줬다면, 최근 약 5개월의 Aptabase export는 작업 세션의 깊이를 보여줬다.

• 전체 세션 9,852개 중 2,399개에 MCP 호출이 포함됐다.
• batch size를 반영한 추정 내부 MCP 호출은 203,850회였다.
• MCP 세션의 평균 관측 span은 41분 11초, P95는 2시간 13분 22초였다.
• 세션당 추정 MCP 호출 중앙값은 11회, P95는 366회였다.

가장 오래 이어진 MCP 세션은 12시간 36분 41초의 관측 span 안에 추정 1,383회의 내부 호출을 남겼다. 호출량이 가장 많았던 세션은 3시간 48분 57초 동안 추정 9,631회의 내부 호출을 남겼다.

물론 세션 span은 첫 이벤트와 마지막 이벤트 사이의 관측 구간이다. 사용자가 그 시간 내내 앱 앞에 있었다는 뜻은 아니다. 그래도 같은 세션 안에서 Figma 관련 작업이 길고 반복적으로 이어졌다는 사실은 확인할 수 있었다.

Problem: 모두 다른 문제, 같은 “안 된다”

초기 질문은 단순했다.

이걸 작동하게 만들 수 있는가?

실제 사용자가 들어오자 질문이 달라졌다.

서로 다른 사용자, 운영체제, MCP 클라이언트와 네트워크 환경에서도 계속 믿고 쓸 수 있게 만들 수 있는가?

기능을 하나 더 만드는 것보다 사용자가 어디서 막혔는지 설명하고 복구시키는 일이 더 커졌다.

주요 기여자인 Yiseo가 운영하는 채널을 통해서도 많은 질문이 들어왔다. 이걸로 정말 “딸깍” 디자인이 되는지, 연결되는 AI는 전부 무료인지, Cursor나 Claude Code 연결을 우리가 대신 해줄 수 있는지, 앱을 켰는데 왜 안 되는지 묻는 질문들이었다.

문제는 사용자가 말하는 “안 된다”가 하나의 문제가 아니었다는 점이다.

• 서버가 실행되지 않는다.
• 포트나 WebSocket 연결이 막힌다.
• Figma 플러그인이나 channel 연결이 맞지 않는다.
• MCP 클라이언트 설정이 잘못됐다.
• 운영체제의 보안 설정이 실행을 막는다.
• 사용자가 앱과 AI 모델의 비용 관계를 다르게 이해하고 있다.
• 기본 연결을 넘어 더 깊은 제어와 디버깅이 필요하다.

원인은 전부 달랐지만 사용자에게는 같은 말로 도착했다.

안 된다.

일반적인 제품이라면 서로 다른 숙련도의 사용자를 지원하는 일은 익숙한 문제일 수 있다. 하지만 개발자와 디자이너를 위한 생산성 도구라는 맥락에서는 조금 당황스러웠다. 비개발자도 쓸 수 있는 제품을 만들고 싶었지만, 그 “비개발자”의 범위가 너무 넓었다.

어떤 사람에게는 IDE라는 말부터 낯설었다. 어떤 사람은 터미널을 여러 개 띄워놓고 MCP를 깊게 사용했다. 최근 1년 사이 AI 도구가 개발자 도구와 디자인 도구의 경계를 흔들면서, 원래라면 개발자 제품에 들어오지 않았을 사용자와 개발자보다 더 깊게 자동화를 쓰는 사용자가 같은 제품 안에 들어왔다.

이 프로젝트는 첫 연결의 불안을 줄여 사용자를 0에서 80까지 밀어줬다. 하지만 마지막 20%에는 사용자 수준에 맞는 진단, 복구, 연결 안정성, 지원 운영이 필요했다. 작은 팀이 흥미만으로 계속 감당하기에는 넓은 문제였다.

그 사이 플랫폼도 움직였다

우리는 언어 지원을 추가하고, 베타 버전으로 로컬 LLM을 사용해 Cursor나 다른 IDE 없이도 쓸 수 있는 방식도 시도했다. 하지만 큰 업데이트의 이유는 점점 약해졌다. 사용량이 없어서가 아니었다. 핵심 경험이 공식 플랫폼 안으로 이동하기 시작했기 때문이다.

Figma는 자체 MCP 서버에서 디자인 컨텍스트를 읽는 것뿐 아니라 캔버스에 네이티브 콘텐츠를 만들고 수정하는 기능까지 제공하기 시작했다. Figma Agent도 캔버스 안에서 직접 프롬프트하고 편집하는 흐름을 내놓았다. 사용자 입장에서는 공식 기능이 가장 자연스럽고 친화적인 방법일 수 있다. 서드파티 앱에는 자연스러운 한계가 있다.

그 방향이 맞다는 판단과 만든 사람의 감정은 별개였다. 비슷한 문제를 앞서 제품으로 만들 때마다 얼마 지나지 않아 더 큰 플랫폼의 기본 기능이 되는 경험이 반복됐다. 기술을 몰라서 무엇을 만들어야 할지 모르는 것이 아니라, 너무 많은 것이 너무 빨리 움직여 무엇을 계속 붙잡아야 할지 모르겠다는 허무함이 있었다.

그래서 MCP Magic은 종료가 아니라 유지보수 모드에 가깝게 두려고 한다. 필요한 수정은 이어가겠지만, 지금의 형태로 큰 기능 업데이트를 계속할 이유는 이전보다 작아졌다.

Try: 다음 목표를 더 빨리 정했어야 했다

성과는 분명히 나왔다. 생산성 향상을 직접 체험했고, 워크숍을 열었고, 유튜브 클립을 만들었다. 다운로드가 늘고 피드백이 도착하는 것도 기뻤다. 하지만 그 시기가 지나자 커뮤니티 제품으로서 다음 동력을 빠르게 잃었다.

첫 번째 아쉬움은 “설치와 첫 연결을 쉽게 만든다” 다음의 목표를 더 빨리 좁히지 못한 것이다. 수익 모델까지는 아니더라도, 설치 도우미로 남을지, 연결 진단과 복구 도구로 갈지, 반복 사용이 많았던 Figma 작업을 워크플로우 제품으로 묶을지 더 일찍 결정했어야 했다.

두 번째는 지원 범위와 운영 모델을 명확히 하지 못한 것이다. 어떤 운영체제와 클라이언트까지 지원할지, 어디까지가 앱의 책임이고 어디부터가 Figma 플러그인, MCP 클라이언트, OS, AI 비용의 문제인지 더 분명하게 정했어야 했다. 반복되는 “안 된다”를 자가 진단 흐름과 문서로 바꾸는 일도 기능 개발만큼 중요했다.

세 번째는 사용 데이터를 다음 제품 가설에 더 일찍 연결하지 못한 것이다. GA4와 Aptabase를 뒤늦게 정리하니 사람들이 어떤 도구를 반복했고, 긴 세션에서 어떤 작업을 했고, 첫 실행과 실제 MCP 사용 사이에 얼마나 큰 낙차가 있었는지가 보였다.

동일 기간의 이벤트별 활성 사용자를 단순 비교하면 app_start는 30,912명, start_websocket_server는 21,115명, mcp_tool_call은 1,633명이었다. 엄밀한 순차 퍼널은 아니지만, 앱 실행에서 실제 MCP 사용까지 큰 낙차가 있었다는 힌트는 충분했다. 이 지표를 출시 초기부터 추적했다면 다음 업데이트의 우선순위도 달라졌을 것이다.

Learning: 딸깍은 0에서 80까지를 해결한다

이 프로젝트에서 가장 크게 배운 것은 사용자가 원하는 것이 강력한 기능만은 아니라는 점이다. 기능을 믿고 첫걸음을 뗄 수 있는 제품 경험이 필요했다.

MCP Magic은 그 첫걸음을 “딸깍”으로 줄였다. 데이터를 보면 그 시도는 실제로 작동했다. 31,360명의 활성 사용자가 있었고, 57만 건이 넘는 MCP 호출이 쌓였다. 도달한 사람들은 텍스트를 만들고, 색을 입히고, 프레임을 만들고, 레이아웃을 다듬었다.

하지만 0에서 80까지는 자동화할 수 있어도 마지막 20%는 자동으로 사라지지 않았다. 제품화는 작동하는 기능을 앱 안에 넣는 데서 끝나지 않는다. 사용자가 어디서 막혔는지 이해하고, 자신의 수준에 맞게 복구할 수 있도록 진단과 회복의 경험을 설계해야 한다.

그리고 성공한 프로젝트도 유지보수 모드로 갈 수 있다. 데이터는 이 프로젝트가 잘됐다는 쪽에 가깝다. 동시에 다음 단계는 기능 추가보다 운영과 지원에 가까웠고, 공식 플랫폼은 같은 문제를 더 자연스럽게 풀기 시작했다. 두 판단은 함께 성립한다.

아쉬운 것은 그 다음 목표를 더 빨리 정하지 못했다는 점이다. Grab의 TalkToFigma, MCP 클라이언트와 AI 모델, Figma의 공식 기능까지 프로젝트가 기대고 있던 거의 모든 층이 빠르게 움직였다. 적은 사람이 흥미만으로 그 변화를 계속 따라가는 데에는 분명한 한계가 있었다.

앞으로는 더 작더라도 사용자를 더 잘 알고, 맥락을 더 깊게 이해하고, 일반 플랫폼의 업데이트만으로 쉽게 사라지지 않는 문제를 봐야 할지도 모른다. 아직 결론은 없다. 다만 이 회고는 그 질문을 더 오래 미루지 않기 위한 기록이다.

이 글은 실패의 기록도, 업데이트를 멈추는 변명도 아니다. 무엇이 잘됐고, 무엇이 생각보다 어려웠고, 무엇을 더 빨리 결정했어야 했는지를 남기는 회고다. 허무함은 여전히 있지만 그것만 남은 것은 아니다. 이 프로젝트는 실제로 작동했고, 실제 사용자와 작업과 숫자가 남았다. 이제 그 숫자를 들고 다음 질문으로 넘어갈 차례다.

데이터와 참고 자료

GA4 집계 기간은 2025년 7월 1일부터 2026년 6월 30일까지다. 활성 사용자, 운영체제, 국가, 언어, MCP 호출과 도구별 성공/실패 데이터를 사용했다. 165는 (not set)을 포함한 country 값의 수이며 정확한 국가 수를 뜻하지 않는다. 94.1%는 성공 또는 실패 상태가 명시된 호출 기준이다.

Aptabase 분석 기간은 2026년 2월 1일부터 2026년 7월 1일까지다. 중복 export를 제외해 익명 세션 단위로 집계했다. batch size 반영 호출 수는 추정값이고, 세션 시간은 첫 이벤트와 마지막 이벤트 사이의 관측 span이다.

부록: 다운로드 집계 기준

본문의 다운로드 수는 배포 채널별 설치·다운로드 횟수를 합산한 값이다. 고유 사용자 수가 아니므로 GA4의 활성 사용자 수와 직접 비교하지 않는다.

Mac App Store 수치는 앱 ID 6751596669의 App Store Connect Analytics에서 확인했다. Lifetime 기간은 2025년 10월 21일부터 2026년 7월 10일까지다. Microsoft Store 수치는 2025년 7월 7일부터 2026년 7월 6일까지의 주간 Apps and Games Installs export 두 개를 합산했다. GitHub Release의 DMG와 Setup EXE는 공개 릴리즈 asset의 누적 다운로드 수다.

공개 가능한 집계와 차트, 스토어 원본은 연구 자료 아카이브에 보관했다. GitHub Release 집계는 grab/TalkToFigmaDesktop의 공개 릴리즈 asset을 기준으로 다시 확인했다.

• Grab 공식 소개 글: 팀을 위한 디자인 도구에서 오픈소스 프로젝트로
• Cursor Talk To Figma MCP 저장소
• MCP magic 프로젝트 페이지
• Figma MCP 서버 개발자 문서
• Figma Agent 소개