Figma 플러그인 생태계는 방대합니다. 토큰 내보내기, 코드 주석, 스타일 가이드, 접근성 검사, 코드 생성을 위한 플러그인들이 있습니다. 누군가 "Figma-to-code 도구"라고 하면, 거의 항상 플러그인을 의미합니다. figmascope는 플러그인이 아닙니다. 이것이 중요한 이유와 중요하지 않은 경우를 설명합니다.
플러그인 모델
Figma 플러그인은 Figma 데스크톱 또는 웹 앱 내의 샌드박스 iframe에서 실행됩니다. 현재 파일의 노드 트리, 스타일, 컴포넌트, 변수를 노출하는 JavaScript 인터페이스인 Figma 플러그인 API에 접근할 수 있습니다. 플러그인은 이 데이터를 읽고, 변환하며, 결과를 파일에 다시 쓰거나 Figma 저장 대화상자를 통해 사용자의 로컬 시스템으로 파일을 내보낼 수 있습니다.
플러그인 API는 풍부합니다. 모든 노드를 순회하고, 계산된 스타일을 읽으며, 컴포넌트 정의에 접근하고, 변수를 조회하며, 심지어 플러그인의 UI 레이어에서 네트워크 요청도 할 수 있습니다. "디자인 데이터를 읽고 뭔가를 한다"는 대부분의 작업에는 플러그인 API로 충분합니다.
플러그인은 Figma 커뮤니티 스토어나 비공개 팀 플러그인으로 배포됩니다. 사용자는 Figma 인터페이스를 통해 설치합니다. 업데이트는 Figma의 플러그인 호스팅을 통해 제공됩니다. 플러그인을 게시한 개발자 계정이 업데이트를 푸시할 수 있으며, 사용자는 다음에 플러그인을 실행할 때 받습니다.
인기 있는 Figma-to-code 플러그인: Locofy (Locofy 비교에서 다룸), Tokens Studio(디자인 토큰 동기화), Figma to Code(오픈 소스 Flutter/SwiftUI/Jetpack Compose), 그리고 수십 가지 더 전문화된 도구들.
플러그인의 한계
Figma 내부에서만 실행됩니다. 플러그인을 실행하려면 Figma를 열고, 파일을 열고, 플러그인을 열고, 내보내기를 트리거해야 합니다. 플러그인은 터미널, CI 작업, 스크립트, 또는 Figma 앱 외부의 어떤 컨텍스트에서도 호출될 수 없습니다. CLI가 없습니다. 호출할 API도 없습니다. 전체 실행 컨텍스트는 Figma UI입니다.
런타임 전용 실행. 플러그인은 백그라운드에서 실행되지 않습니다. 사람이 플러그인을 열고 버튼을 클릭할 때 실행됩니다. 예약된 내보내기, 자동화된 파이프라인, 프로그래밍 방식의 통합은 플러그인 모델로는 불가능합니다.
플러그인 스토어 게이트키퍼. 공개 Figma 플러그인을 게시하려면 Figma의 검토와 승인이 필요합니다. 업데이트도 재검토가 필요합니다. Figma가 검토 정책을 변경하거나 플러그인이 자신의 이익과 충돌한다고 판단하면, 플러그인이 제거되거나 제한될 수 있습니다. 비공개 팀 플러그인은 스토어를 우회하지만 여전히 Figma의 샌드박스 내에서 실행되며 Figma의 플러그인 인프라에 의존합니다.
리소스 제약. 플러그인 샌드박스는 메모리와 실행 시간이 제한됩니다. 복잡한 계층 구조를 가진 대용량 Figma 파일은 타임아웃이 발생하거나 플러그인이 충돌할 수 있습니다. 플러그인 UI는 제한된 접근 권한을 가진 iframe에서 실행됩니다 — Figma의 내보내기 대화상자를 제외한 로컬 파일 시스템 접근 없음, 메인 스레드에서 임의 네트워크 접근 없음.
크로스 플랫폼 불일치. Figma 데스크톱 앱과 웹 앱은 일부 엣지 케이스에서 약간 다른 플러그인 API 동작을 가집니다. 한 쪽에서 완벽하게 작동하는 플러그인이 다른 쪽에서 문제가 생길 수 있습니다.
팀 배포 마찰. 플러그인을 실행해야 하는 모든 개발자가 별도로 설치합니다. 팀 전체의 버전 일관성은 Figma의 자동 업데이트 메커니즘에 달려 있습니다. 특정 버전을 고정해야 한다면 그것은 쉽지 않습니다.
figmascope의 외부 접근 방식
figmascope는 플러그인 시스템을 전혀 사용하지 않습니다. 표준 브라우저 탭에서 실행됩니다 — 어떤 브라우저든, Figma 앱 불필요 — 그리고 사용자가 제공하는 PAT를 사용하여 Figma REST API를 직접 호출합니다. PAT는 메모리에만 보관되며, 어떤 서버에도 전송되지 않습니다.
Figma REST API는 플러그인 API가 사용하는 것과 동일한 데이터 소스이지만, 외부에서 접근합니다. figmascope는 파일 JSON을 가져오고, 클라이언트 사이드에서 노드 트리를 처리하며(모든 계산이 여러분의 브라우저에서 일어남), 컨텍스트 번들을 생성합니다. API 호출은 여러분의 브라우저에서 Figma 서버로 직접 갑니다. figmascope 자체 인프라는 데이터 경로에 없습니다.
이것은 여러 가지 의미를 가집니다:
설치 없음. 탭을 열고, Figma URL과 PAT를 붙여넣고, 내보내기를 클릭합니다. 설치할 것도, 만들 계정도, 커뮤니티 스토어에서 찾을 플러그인도 없습니다. 브라우저가 있는 누구나 사용할 수 있습니다 — Figma 사용자가 아니고 앱을 설치하지 않은 개발자도 포함합니다.
원칙적으로 스크립터블. figmascope가 REST API 기반으로 구축되어 있기 때문에, 그것이 만드는 동일한 호출이 프로그래밍 방식으로 재현될 수 있습니다. MIT 코드베이스는 공개적으로 검사 가능합니다. 브라우저를 열지 않고 명령줄에서 번들을 내보내는 스크립트를 만들고 싶다면, figmascope 소스가 API를 호출하고 응답을 처리하는 방법을 정확히 보여줍니다.
원칙적으로 CI/CD 호환. 헤드리스 내보내기 파이프라인이 가능합니다: Figma REST API 호출, 동일한 IR 처리 로직, 동일한 번들 형식. figmascope의 브라우저 앱은 CI에서 직접 실행되지 않지만(브라우저 도구이므로), 아키텍처 접근 방식 — REST API, 결정론적 처리, 일반 파일 출력 — 은 설계상 CI 친화적입니다. 모델의 어떤 것도 GUI를 필요로 하지 않습니다.
플러그인 스토어 의존성 없음. figmascope는 도메인에 호스팅되고, GitHub에 오픈 소스로 있습니다. Figma의 플러그인 인프라나 검토 과정에 의존하지 않습니다. Figma는 스토어에서 그것을 제거할 수 없습니다. 도메인이 다운되면, 레포지토리에서 로컬로 실행할 수 있습니다 — 완전한 정적 HTML/JS입니다.
Figma 앱 불필요. 개발자는 공유 Figma URL과 PAT만 사용하여 Figma 앱에서 한 번도 열어본 적 없는 Figma 파일의 컨텍스트를 내보낼 수 있습니다. 엔지니어가 Figma를 직접 사용하지 않지만 디자인 사양이 필요한 워크플로에 중요합니다.
플러그인이 더 잘하는 것
공정하게 말하겠습니다. 플러그인에는 외부 API 접근 방식이 복제할 수 없는 실제 장점이 있습니다.
캔버스 내 주석. 플러그인은 Figma 파일에 다시 쓸 수 있습니다 — 주석 추가, 컴포넌트 속성 설정, 프레임을 준비 완료로 표시, 댓글 게시. figmascope는 읽기 전용입니다. Figma 내부에서 디자인 사이드 작업을 하는 도구가 필요하다면 플러그인이 필요합니다.
라이브 캔버스 컨텍스트. 플러그인은 무엇이 선택되어 있는지 알고 있습니다. 선택 변경에 반응하고, 노드 업데이트를 감시하며, 진행 중인 디자인 작업에 반응할 수 있습니다. figmascope는 스냅샷을 찍습니다. 라이브 캔버스 접근이 없습니다.
Figma 조직을 통한 팀 배포. 팀 전체가 Figma 조직 플랜에 있다면, 비공개 플러그인을 팀에 푸시하는 것이 간단합니다. 모두가 Figma 인스턴스에 그것을 가집니다. 조직 내 크로스 팀 배포에서 플러그인 모델은 잘 지원됩니다.
Figma UI에서 더 풍부한 인터랙션. 플러그인은 패널 내에 커스텀 UI를 렌더링하고, 사용자 인터랙션에 응답하며, 디자이너의 기존 워크플로 내에서 즉각적인 피드백을 제공할 수 있습니다. figmascope의 인터페이스는 별도의 브라우저 탭입니다 — 컨텍스트 전환.
비교
| 항목 | Figma 플러그인 (일반) | figmascope |
|---|---|---|
| Figma 내부에서 실행 | 예 — 샌드박스 iframe | 아니요 — 외부 브라우저 탭 |
| Figma 앱/계정 필요 | 예 | PAT만 필요 (무료 Figma 계정으로 작동) |
| 설치 필요 | 예 — Figma 커뮤니티 또는 팀 설치 | 아니요 — 브라우저에서 열기 |
| 스크립터블 / 자동화 가능 | 아니요 — GUI 전용 실행 | 원칙적으로 예 — REST API 기반 |
| CI/CD 호환 | 아니요 | 아키텍처가 CI 친화적 |
| Figma에 다시 쓰기 | 예 — 노드 생성/업데이트 가능 | 아니요 — 읽기 전용 |
| 캔버스 내 주석 | 예 | 아니요 |
| 라이브 캔버스 선택 컨텍스트 | 예 | 아니요 — 스냅샷만 |
| 플러그인 스토어 검토에 의해 제한 | 예 (공개 플러그인) | 아니요 |
| 데이터 프라이버시 | 플러그인에 따라 다름 — 플러그인 벤더 서버로 데이터 전송 가능 | 모든 처리가 브라우저에서; PAT는 절대 기기를 떠나지 않음 |
| 출력 형식 | 다양 — JSON, 코드 파일, 주석, 클립보드 | 구조화된 번들: CONTEXT.md, tokens.json, screens/*.json, *.png |
| 에이전트 최적화 IR | 드묾 — 대부분의 플러그인은 인간 소비를 대상으로 함 | 예 — componentId와 stringRef가 있는 stack/overlay/absolute/leaf |
| 버전 관리 가능한 출력 | 플러그인에 따라 다름 | 예 — 번들은 diff 가능한 JSON + Markdown |
| 오픈 소스 | 일부는 그렇지만; 많은 것이 아님 | 예 — MIT |
데이터 프라이버시 측면
Figma 플러그인이 네트워크 요청을 할 때, 여러분의 디자인 데이터가 브라우저를 떠나 플러그인 벤더의 서버로 갈 수 있습니다. 플러그인의 개인정보 보호 정책과 인프라를 신뢰하는 것입니다. 많은 팀에게 이것은 허용 가능합니다. 일부 — NDA로 보호된 디자인을 가진 엔터프라이즈 팀, 민감한 클라이언트 파일을 다루는 에이전시 — 에게는 중요한 우려 사항입니다.
figmascope의 외부 접근 방식은 다릅니다. 모든 처리가 여러분의 브라우저 탭에서 일어납니다. REST API 호출은 여러분의 브라우저에서 Figma 서버로 갑니다(Figma를 정상적으로 사용할 때 브라우저가 만드는 것과 동일한 호출). figmascope 자체 서버는 경로에 없습니다. 여러분의 디자인 데이터는 Figma의 API 외에 어디에도 가지 않습니다. PAT는 메모리에 있으며 탭을 닫으면 지워집니다.
이것은 백엔드 벤더에 의존하는 플러그인에 비해 외부 브라우저 접근 방식의 구조적 장점입니다.
언제 무엇을 선택할지
Figma 플러그인을 사용할 때: 파일에 주석을 달거나 다시 써야 할 때, 디자이너 워크플로의 일환으로 캔버스 내 인터랙션을 원할 때, 팀이 완전히 Figma에 있고 플러그인 메커니즘을 통한 배포가 편리할 때, 또는 필요한 플러그인이 REST API 접근 방식이 복제할 수 없는 특정 Figma UI를 가질 때.
figmascope를 사용할 때: AI 에이전트 코드 생성을 위한 포터블하고 버전 관리된 컨텍스트 번들이 필요할 때, 설치도 스토어 의존성도 없기를 원할 때, 데이터 프라이버시를 중요시하고 디자인 데이터가 서드파티 플러그인 벤더에게 전송되지 않기를 원할 때, 출력이 코드와 함께 git 레포지토리에 있기를 원할 때, 또는 내보내기 과정이 설명 가능하고 재현 가능하기를 원할 때.
AI 에이전트를 사용한 대부분의 프로덕션 UI 코드 생성 워크플로에서, 플러그인 모델은 되돌릴 수 없는 마찰을 추가합니다. 플러그인은 Figma에서 실행됩니다. 에이전트는 여러분의 에디터에서 실행됩니다. 플러그인을 통해 디자인 사양을 한 쪽에서 다른 쪽으로 가져오려면 수동 복사-붙여넣기나 디스크에 쓰는 플러그인이 필요합니다 — 그러면 불투명한 파이프라인에서 불투명한 파일이 생깁니다. figmascope의 출력은 검사 가능하고, 구조화되어 있으며, 에이전트 핸드오프를 위해 명시적으로 설계되었습니다.