Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 AI 에이전트가 Figma 파일을 편집하는 과정에서 발생할 수 있는 잠재적인 결함들을 다룹니다. 특히, 캔버스 상에서는 정상적으로 보이지만 실제 파일 구조상 문제가 발생하는 '변수 바인딩 누락'이나 '분리된 컴포넌트' 등의 디테일을 지적합니다. 이는 AI가 디자인 파일을 수정하거나 생성할 때 속성 확인 및 구조적 무결성을 검증하는 것이 중요함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 에이전트가 Thiago Xikota가 제공한 사실과 figma-maxxing 리포지토리를 사용하여 이 글을 작성하고 편집했습니다. 이미지는 에이전트가 구축한 Figma 데모 파일의 실제 스크린샷이며, HTML로 주석이 추가되었습니다.
'Team members'라는 이름의 Figma 화면을 열어보세요. 여기에는 제목, 요약 카드, 목록에 있는 다섯 명의 사람, 그리고 'Add member' 버튼이 있습니다.
제목은 #111827를 사용합니다. 파일에는 color/text/primary라는 색상 변수가 있으며, 이 변수와 동일한 값을 가집니다. 또 다른 텍스트 레이어는 이 변수에 바인딩되어 있습니다. 하지만 제목은 그렇지 않습니다. 캔버스 위에서는 차이를 알 수 없습니다.
세 번째 줄(Sofia Martins)은 주변의 행들과 일치합니다. 그러나 더 이상 ListItem 컴포넌트의 인스턴스가 아닙니다. 단지 컴포넌트 이름을 유지한 평범한 프레임입니다.
색상 변수나 행 컴포넌트를 변경하면, 이 두 레이어는 그대로 남아 있게 됩니다.
에이전트가 구축한 Figma 데모의 실제 스크린샷이며, HTML로 주석 처리되었습니다. 마커 6은 제목을 가리키고; 마커 5는 분리된 행을 가리킵니다. 수정 후에도 어떤 감사 게이트(audit gate)도 통과하지 못했습니다.
에이전트가 아래 테스트를 위해 두 가지 결함을 심었습니다. 클립된 레이블(clipped label) 같은 다른 결함들도 이미지에서 볼 수 있습니다. 변수 바인딩 누락 및 분리된 컴포넌트는 속성 확인이 필요합니다.
저는 브라질의 AI 제품 디자이너 Thiago Xikota입니다. 저는 에이전트가 실제 Figma 파일을 편집하는 데 사용하는 규칙들을 바탕으로 figma-maxxing을 구축했습니다. 이 규칙들 중 대부분은 실제 파일에서 문제가 발생했던 것들로부터 나왔습니다.
하나의 field note는 figma-console bridge를 통해 작업하는 동안 실패한 변수 바인딩을 기록합니다. 영향을 받은 레이어들은 잠긴 조상(locked ancestor)을 가지고 있었지만, 각 레이어 자체는 locked: false로 보고했습니다. 호출은 오류 없이 반환되었습니다.
이는 잠금 상태가 실패의 원인임을 입증하지 못합니다. Figma의 타입 정의에 따르면 잠금 상태가 플러그인 쓰기(plugin writes)를 막지는 않습니다. 이 노트는 두 가지 사실을 기록하고 에이전트에게 바인딩 자체를 다시 읽어오도록 요청합니다. 색상만 읽어오는 것은 원색과 변수가 같은 값을 가졌기 때문에 문제를 놓쳤습니다.
프로토타입 반응(Prototype reactions)은 다른 실패 사례가 있습니다. 레거시 action 필드만 변경하면, 목적지는 변하지 않았음에도 불구하고 호출이 성공했다고 보고할 수 있습니다. Figma는 actions 배열을 읽습니다. 작동하는 수정 방법은 이 배열을 변경하고 목적지를 다시 읽어옵니다.
다른 호출들은 잘못된 것을 변경합니다. instance.resize()는 아이콘의 박스는 축소시키면서 내용물(contents)은 전체 크기로 남겨둘 수 있습니다. 기록된 수정 방법은 rescale()을 사용합니다. 섹션 채우기(section fill)는 변수에 바인딩되어도 여전히 바인딩 시 전달된 기본 색상(base color)을 렌더링할 수 있습니다. field note은 바인딩 전에 변수를 해결합니다.
데모의 제목(title)과 분리된 행(detached row)도 또 다른 사례입니다. 스크린샷은 일관성 있어 보이지만, 속성은 파일의 디자인 시스템과 불일치합니다.
figma-maxxing은 MIT 라이선스의 8가지 Agent Skill 세트입니다. 이는 에이전트가 Figma 파일 작업 중 로드하는 Markdown 명령어입니다. 여기에는 테스트에 사용된 스킬과 참조한 레퍼런스가 있습니다:
figma-preflight: 쓰기(write) 전에 실행됩니다. 8가지 검사를 수행하는 읽기 전용 게이트입니다.figma-slop-check: 쓰기 후에 실행됩니다. 생성된 것처럼 보이는 디자인과 파일의 토큰 및 스케일에서 벗어남(drift)을 확인합니다.figma-handoff-gate: 핸드오프 전에 실행됩니다. 17가지 검사는 모든 액션이 목적지(destination)와 되돌아갈 방법(way back)을 갖도록 요구합니다.figma-canon: 규칙과 90가지 함정(gotchas)을 담고 있습니다: 45개의 플러그인 API 이상 현상 및 45개의 필드 노트이며, 증상별로 인덱싱되어 있습니다.v1.2.0에서는 slop check가 5개 그룹에 걸쳐 8가지 slop check와 11가지 rigor check를 포함합니다. 아래 테스트는 이전의 rigor lens로 실행되었습니다. 그 결과는 수정된 lens에 대한 테스트가 아닙니다.
이 스킬들은 Figma의 공식 MCP 서버와 figma-console-mcp를 통해 경로를 설명합니다. 후자는 로컬 Desktop Bridge를 가진 Southleft의 MIT 라이선스 프로젝트입니다. 저는 이 브리지를 제 자체 프로덕션 작업에서 사용합니다. 지원 및 테스트 커버리지는 스킬과 서버마다 다르며, 저장소의 호환성 표에 그 제한 사항이 나열되어 있습니다.
2026년 10월 5일, 에이전트들이 Figma의 공식 MCP 서버를 통해 테스트를 실행했습니다:
figma-slop-check와 figma-handoff-gate를 실행했습니다.심어진 10개의 결함 모두 발견되었으며, 부분 일치(partial matches)는 0개, 놓친 것(missed)은 0개였습니다. 결함을 심은 에이전트는 스킬들을 읽었으며, 감사자의 프롬프트는 어디를 볼지 지시했고, 이것은 한 번의 실행에서 하나의 화면에 대한 내용입니다.
펀치 리스트(punch list)는 27개의 항목으로 구성되어 있었습니다. 그중 16개는 슬롭 체크(slop check)에서, 11개는 핸드오프 게이트(handoff gate)에서 나왔습니다. 이 중 13개는 의도적으로 심은 결함과 일치했습니다. 일부 결함은 여러 항목을 생성하기도 했습니다. 나머지 14개는 의도된 결함을 제외한 13가지의 개별적인 문제점을 기술했는데, 이는 두 체크 모두 동일한 이름 변경(rename)으로 인해 플래그를 지정했기 때문입니다. 그중 하나는 정답 키 자체에서 놓친, 14px 텍스트에 대한 4.32:1 대비 실패였습니다.
심사관은 이 추가 항목들을 키와 스크린샷과 대조해 보았습니다. 어떤 것도 증거와 모순되지 않았지만, 심사관이 파일을 열어보지 않았기 때문에 2개는 직접 검증할 수 없었습니다. 리포지토리의 테스트 보고서는 그 결과를 그리고 에이전트들이 수행한 적응을 기록하고 있습니다.
이는 체크가 준비된 파일에서 작동했다는 것을 보여줄 뿐입니다. 아무도 준비하지 않은 파일에서 결함을 얼마나 자주 포착하는지는 측정하지 못합니다.
에이전트가 구축한 데모의 실제 스크린샷으로 구성된 애니메이션입니다. 번호가 매겨진 발견 사항은 원래 화면을 참조하며, 마지막 프레임은 한 번의 수정 과정을 보여줍니다.
슬롭 보고서는 제목의 원본 헥스(raw hex)와 동일한 값을 가진 변수를 식별했습니다. 이를 바인딩하면 보이는 색상은 변경하지 않으면서 구조를 변경합니다.
핸드오프 보고서는 제거 경로(remove path)가 없는 '멤버 추가(Add member)' 액션을 발견했습니다. 또한 확인 상태(confirmation state)와 결과 상태(result state)도 요구했습니다. 누락된 흐름은 디자이너의 결정이 필요합니다.
v1.2.0 버전에서 제안된 슬롭(slop) 수정은 스왑(swap), 스냅(snap) 또는 애스크(ask)로 분류됩니다. 스왑은 동일한 값을 바인딩하거나 적용하여 화면을 변경하지 않습니다. 스냅은 값을 가장 가까운 알려진 프로젝트 단계로 이동시키고 거리를 기록합니다. 애스크는 디자인 결정을 소유자에게 남겨둡니다. 이 스킬은 에이전트에게 먼저 보고하고 수정하기 전에 승인을 기다리라고 지시합니다. 애스크는 절대 승인된 자동 수정 배치에 포함되지 않습니다.
게이트(gates)는 에이전트가 이러한 지침을 따르는 것에 의존합니다. 게이트 자체만으로는 쓰기 작업을 차단할 수 없습니다. README의 안전 참고 사항에서 경계를 설명합니다.
스킬 설치:
npx skills add thiagoxikota/figma-maxxing
Claude Code의 경우, 플러그인 경로는 다음과 같습니다:
/plugin marketplace add thiagoxikota/figma-maxxing
/plugin install figma-maxxing@figma-maxxing-skills
2026년 10월 5일에 설치는 Claude Code의 claude plugin CLI, Codex, Copilot CLI, Gemini CLI 및 위의 npx 명령을 통해 깨끗한 폴더에서 실행되었습니다. 각기 8개의 스킬이 설치되었습니다. 이 실행들은 설치를 테스트했을 뿐, 모든 스킬을 종단 간(end to end)으로 실행하지는 않았습니다. Cursor와 Claude 데스크톱 및 웹 앱에 대한 설치는 테스트되지 않았습니다.
에이전트를 두 서버 중 하나를 통해 Figma에 연결하고, 프레임에 포인팅한 다음 핸드오프 준비가 되었는지 물어보세요. README에 설치 경로와 연결 설정이 있습니다.
코딩 에이전트 없이, AI 도구에서 다음 프롬프트를 시도해 보세요:
Read and use this file as reference:
If you cannot open it, tell me and do not guess.
...
이 프롬프트는 Claude, Codex 및 Gemini 터미널 도구의 6개 테스트 중 6개에서 작동했습니다. 채팅 앱은 테스트되지 않았습니다. 이 프롬프트는 적용할 수 있는 짧은 체크리스트를 반환합니다. AI가 파일을 감사하려면 접근 권한이 필요합니다.
네 번째 에이전트가 figma-preflight을 실행하고, 화면을 수정했으며, 변경된 속성을 읽어왔습니다. 두 가지 감사 스킬(audit skills)이 다시 실행되었습니다:
figma-slop-check는 16개 발견 사항에서 6개로 줄었으며, 심각한(critical) 발견 사항은 버튼(Button)이나 리스트 항목(ListItem)에 포커스 상태(focus state)가 없다는 것이었습니다.figma-handoff-gate는 11개 문제에서 13개로 늘어났고, 주로 플로우와 스테이트(state)를 수정 패스가 그려내지 못한 블로커(blockers) 8개가 있었습니다.두 게이트 모두 통과하지 못했습니다. 이 수정 작업은 12개의 슬롭 발견 사항을 닫았으며, 남아있는 6개 발견 사항 중 2개는 수정 작업 자체에서 발생한 것이었습니다. 공개 실행 보고서에는 열려 있는 항목들이 나열되어 있습니다.
공식 서버 역시 실행에 영향을 미쳤습니다. 감사는 12개의 도구 호출(tool calls)을 사용했고, 수정 작업은 13개, 두 번째 감사는 13개를 사용했습니다. 에이전트들은 선택 도구(selection tool)나 브릿지 상태 도구(bridge-status tool)가 없었습니다. get_screenshot은 1배율(1x) 이상으로 렌더링되지 않았으며, 각 호출의 출력은 20 KB로 제한되었습니다. 실행 보고서에는 에이전트들이 적응하거나 건너뛴 내용이 기록되어 있습니다.
만약 에이전트가 gotchas가 다루지 않는 방식으로 Figma 파일을 손상시킨다면, 증상과 실제로 실행한 수정 작업을 포함하여 이슈를 열어주세요.
저장소(Repository): thiagoxikota/figma-maxxing. MIT 라이선스. Figma와는 관련이 없습니다.