MCP — Model Context Protocol — 은 AI 에이전트가 외부 서비스에 런타임 도구 호출을 할 수 있게 합니다. Figma는 공식 MCP 서버를 제공하며, 커뮤니티는 여러 추가 서버를 만들었습니다. 제안: 에이전트는 대화 중간에 온디맨드로 Figma에서 디자인 데이터를 직접 요청할 수 있습니다. 내보내기 단계 없음. 항상 라이브.

figmascope는 반대의 아키텍처 방향으로 배팅합니다: 한 번 내보내고, 번들을 전달하며, 다시는 연결하지 않습니다. 이것들은 다른 함의를 가진 진정으로 다른 선택입니다. 각각이 실제로 무엇을 희생하고 얻는지 살펴보겠습니다.

Figma의 MCP 서버란

Model Context Protocol은 Anthropic의 오픈 스탠다드로, 서버 인터페이스를 통해 AI 에이전트를 외부 도구에 연결합니다. MCP 서버는 에이전트가 호출할 수 있는 타입된 도구를 노출합니다: "get_file," "get_node," "get_styles" 등. 에이전트가 디자인 컨텍스트가 필요하면 도구를 호출하고, MCP 서버가 Figma API를 호출하며, 결과가 현재 프롬프트의 컨텍스트로 돌아옵니다.

Figma의 공식 MCP 서버는 파일 읽기, 노드 검사, 컴포넌트 검색, 댓글 접근을 지원합니다. 커뮤니티 MCP 서버(GitHub에 여러 개 있음)는 사용자 정의 스키마, 추가 변환, 또는 특정 에이전트 워크플로에 최적화된 더 좁은 범위로 이를 확장합니다.

어떤 Figma MCP 서버를 사용하든, 에이전트 클라이언트(Claude Desktop, Cursor, Continue 등)에서 구성하고, Figma PAT를 제공하면 서버가 로컬 프로세스로 실행됩니다. 에이전트가 Figma 컨텍스트가 필요하면 도구를 호출합니다. 명시적으로 아무것도 내보낼 필요가 없습니다 — 에이전트가 필요할 때 필요한 것을 가져옵니다.

실제 MCP 모델

전형적인 MCP 기반 Figma 워크플로는 이렇습니다: Cursor를 열고, 대화를 시작하고, "이 Figma 파일에서 체크아웃 화면을 구현하세요"라고 하면, 에이전트가 get_file을 호출하고, 노드 트리를 가져오며, 디자인 데이터를 컨텍스트에 넣습니다. 그런 다음 "디자이너가 버튼 토큰을 업데이트했어요"라고 하면 에이전트가 다시 호출하여 신선한 데이터를 얻을 수 있습니다.

이 라이브 연결 모델은 일부 워크플로에서 실재하고 매력적입니다. 에이전트는 현재 데이터로 작업합니다. 내보내기 아티팩트를 관리할 필요가 없습니다. "디자이너가 변경 사항을 푸시했다"와 "에이전트가 그것을 가지고 있다" 사이에 수동 단계가 없습니다.

MCP가 우위를 점하는 곳

라이브 데이터, 내보내기 단계 없음. 에이전트가 온디맨드로 현재 상태를 가져옵니다. 디자인이 10분 전에 변경되었다면 에이전트가 볼 수 있습니다. figmascope는 변경 사항을 캡처하기 위해 수동 재내보내기가 필요합니다.

대화형 디자인 탐색. "CTA 버튼의 색상은 무엇인가요?" "이 컴포넌트를 참조하는 화면이 몇 개인가요?" MCP를 사용하면 에이전트가 Figma를 호출하여 이것들에 답할 수 있습니다. 번들을 사용하면 답변은 마지막 내보내기만큼만 신선합니다.

Figma 직접 편집. 일부 MCP 서버는 쓰기 작업을 노출합니다 — 노드 생성, 속성 업데이트, 댓글 게시. 이것은 라이브 연결로만 가능합니다. 정적 번들에는 쓰기 경로가 없습니다.

수동 워크플로 없음. 이미 MCP 연결 에이전트 설정을 사용하는 개발자에게는, 내보내기 단계가 없다는 것은 잊어버릴 것이 하나 줄어든다는 것을 의미합니다. 컨텍스트 관리가 에이전트에게 위임됩니다.

MCP가 지는 곳

라이브 연결 모델에는 과소평가하기 쉬운 아키텍처 비용이 있습니다.

세션 바운드 상태. MCP 호출은 대화 세션의 컨텍스트에서 일어납니다. 세션 A에서 에이전트가 검색한 데이터는 다시 가져오지 않고는 세션 B에서 사용할 수 없습니다. 새 채팅을 시작하면 에이전트가 처음부터 시작합니다. figmascope 번들은 세션 간, 개발자 간, 도구 간에 지속됩니다 — 그냥 파일입니다.

git에 불투명. 아티팩트가 없습니다. 커밋할 것이 없습니다. 코드를 알린 디자인 컨텍스트가 레포지토리에 있지 않습니다. 6개월 후에 컴포넌트가 빌드될 때 디자인이 어떻게 보였는지 이해하고 싶다면 기록이 없습니다. 레포지토리에 번들이 있으면 디자인 의도의 커밋 기록이 있습니다.

연결 필요. MCP는 실행 중인 서버, 라이브 Figma API 연결, 접근 권한이 있는 PAT가 필요합니다. 네트워크 다운, Figma API 다운, PAT 만료 — 에이전트에게 컨텍스트가 없습니다. 번들은 비행기에서도 작동합니다.

모델 의존적 검색. 에이전트가 MCP를 통해 요청하는 것은 무엇을 요청하기로 결정하는지에 달려 있습니다. 토큰 값을 가져오지 않을 수 있습니다. 컴포넌트 인벤토리를 가져오지 않을 수 있습니다. 인접 노드의 공간적 컨텍스트를 놓치면서 필요하다고 생각하는 노드 서브트리만 요청할 수 있습니다. 검색은 확률적이며 결정론적이지 않습니다. figmascope는 고정된 스키마로 매번 모든 것을 가져옵니다.

테스트 및 재현이 어려움. "내 에이전트가 이 시점에 이 Figma 데이터로 이 컴포넌트를 만들었다"는 MCP로는 검증할 수 없습니다. 가져오기는 덧없습니다. 번들을 사용하면 정확하게 재현할 수 있습니다: 동일한 번들, 동일한 에이전트, 동일한 프롬프트 — 결정론적 출력. 이것은 디버깅, 코드 리뷰, 릴리스 책임에 중요합니다.

컨텍스트 윈도우 압력. 복잡한 Figma 파일에 대한 단순한 get_file 호출은 엄청난 JSON 트리를 반환합니다. 에이전트는 컨텍스트 예산 내에 있기 위해 선택적 도구 호출을 해야 합니다. 이것은 잘못될 수 있는 휴리스틱과 판단 호출을 도입합니다. figmascope는 필요한 것만 알려진 제한된 크기의 구조화된 IR로 트리를 사전 처리합니다.

figmascope의 번들 모델: 한 번 캡처, 영원히 전달

figmascope는 Figma REST API에서 일반 파일의 .zip을 내보냅니다 — 플러그인도, 서버도 없이, 브라우저에서 실행됩니다. 번들에는:

내보내면 번들은 자급자족하고 불변입니다. 그것이 설명하는 코드와 함께 레포지토리에 들어갑니다. 어떤 에이전트든, 어떤 세션이든, 어떤 개발자든, 어떤 CI 작업이든 읽을 수 있습니다. 어떤 것에도 연결이 필요하지 않습니다.

버전 관리 가능한 diff: 코드처럼 번들 비교

이것이 번들 모델의 가장 강력한 주장입니다. 출력이 구조화된 JSON과 Markdown이기 때문에 diff할 수 있습니다.

디자인 스프린트 전에 번들을 내보냅니다. 그 후에 또 내보냅니다. tokens.json에 diff를 실행합니다:

- "spacing.4": "16px"
+ "spacing.4": "14px"

이것은 간격 스케일의 브레이킹 체인지입니다. 가시적이고, 검토 가능하며, 커밋으로 추적할 수 있습니다. MCP를 사용하면 동일한 변경이 조용히 일어납니다 — 에이전트가 다음에 가져올 때 새 값을 얻으며, 무엇이 변경되었는지 기록이 없습니다.

이것을 PR 게이트로 실행할 수 있습니다: 디자인 핸드오프의 일환으로 번들을 내보내고, 커밋하며, 구현 시작 전에 diff에 대해 디자이너와 개발자의 승인을 요청합니다. 그것이 코드로서의 디자인 사양입니다. MCP에는 이에 해당하는 것이 없습니다.

결정론 주장

동일한 Figma 파일 버전 + 동일한 figmascope 내보내기 = 동일한 번들. 매번. IR 스키마는 고정되어 있습니다. 토큰 소싱 로직은 결정론적입니다. 문자열 키 추출은 규칙 기반입니다.

MCP 검색은 결정론적이지 않습니다. 에이전트가 무엇을 가져올지 결정합니다. 다른 에이전트, 다른 프롬프트 표현, 다른 컨텍스트 예산 — 다른 가져오기 동작. 출력은 모델 의존적입니다.

프로덕션 UI 코드 생성에서 결정론이 중요합니다. 컴포넌트를 생성한 사양이 재현 가능하기를 원합니다. 동일한 입력에서 컴포넌트를 재생성하고 일관된 결과를 얻을 수 있기를 원합니다. 번들은 이를 지원합니다. MCP 세션은 그렇지 않습니다.

비교

항목 Figma MCP figmascope 번들
데이터 신선도 항상 라이브 — 현재 Figma 상태 가져옴 스냅샷 — 마지막 내보내기만큼 신선
내보내기 단계 필요 아니요 예 — 디자인 버전당 한 번
버전 관리 가능 아니요 — 아티팩트 없음 예 — 번들은 diff 가능한 JSON + Markdown
세션 간 지속 아니요 — 각 세션마다 재가져오기 필요 예 — 파일이 무기한 지속
오프라인 작동 아니요 예
결정론적 출력 아니요 — 모델 의존적 검색 예 — 동일한 입력 → 항상 동일한 번들
컨텍스트 윈도우 압력 높음 — 원시 Figma JSON은 크고 비구조적 낮음 — IR은 사전 처리되어 제한된 크기
Figma 쓰기 작업 예 (일부 MCP 서버) 아니요 — 읽기 전용 내보내기
git 기록의 디자인 사양 아니요 예 — 번들 커밋, 디자인 기록 추적
에이전트 설정 필요 예 — 에이전트 클라이언트당 MCP 서버 구성 아니요 — 파일을 읽는 어떤 에이전트든 작동
i18n 문자열 키 기본 Figma MCP 스키마에 없음 예 — IR의 stringRef.key + strings.json
공간 / 레이아웃 IR 원시 Figma 노드 트리 (의미론적 레이아웃 타입 없음) 타입된 IR: stack / overlay / absolute / leaf
토큰 소싱 설정된 경우 변수; 그렇지 않으면 원시 값 변수 → 빈도에서 추론 → 없음

MCP는 "Figma 라이브 편집"에 빛나고 — 번들은 "프로덕션 UI 구축"에 빛납니다

이것이 솔직한 요약입니다. 대화형 디자인 탐색 — "이 컴포넌트를 변경하세요," "이 화면에 주석을 달아주세요," "이 프레임의 색상 토큰은 무엇인가요" — 이 워크플로라면 MCP의 라이브 연결이 올바른 모델입니다. 에이전트는 디자인 프로세스의 협업자이며, 그것을 하기 위해 현재 데이터가 필요합니다.

최종(또는 거의 최종) 디자인에서 프로덕션 UI를 구축하는 — 컴포넌트 구현, 상태 연결, 테스트 작성 — 워크플로라면 번들 모델이 더 낫습니다. 사양이 레포지토리에 고정되고, 디자인 반복 전반에 걸쳐 diff 가능하며, 구성 없이 어떤 에이전트든 읽을 수 있고, 기반으로 삼을 만큼 충분히 결정론적이기를 원합니다.

두 모델은 상호 보완적입니다. 디자인이 유동적이고 협업적으로 반복할 때 MCP를 사용하세요. 디자인이 안정적이고 구현을 위해 엔지니어에게 전달할 때 figmascope 번들을 내보내세요. 번들은 구현이 만들어지는 진실의 소스가 됩니다 — 추적 가능하고, 검토 가능하며, 재현 가능한.