사용자가 만든 도구의 공유와 편집을 확장한다
피그마는 디자인 에이전트로 만든 생성형 플러그인과 셰이더의 새 기능을 소개했다. 만든 도구를 커뮤니티에 게시하거나 Organization·Enterprise 조직에 비공개로 공유하고, 셰이더에 애니메이션과 상호작용을 넣는 방향이다. 코드 확인·다운로드와 MCP를 통한 수정, HTML·React에서 셰이더를 구현하는 연결도 발표했다. Config에서 공개한 기반 기능의 후속 확장이다.
로지 킹 제품 디자이너는 셰이더를 레이어의 채우기나 효과로 사용해 픽셀을 바꾸는 GPU 프로그램이라고 설명한다. 처음에는 Figma와 비슷한 WebGPU 실험 환경을 만들어 효과의 조합과 동적 제어를 보여 줬다. 하지만 이런 데모와 대규모 실제 캔버스는 다른 조건이므로 렌더링·애니메이션 엔지니어와 성능, 실행 구조를 함께 검토했다고 밝혔다.
작동하는 시제품과 상태를 보여 주는 목업을 나눴다
팀은 셰이더의 WebGPU 파이프라인을 실제 Figma에 구현하고 생성 도구를 하나의 방향으로 묶었다고 설명한다. 플러그인은 기존 API를 사용하고 셰이더는 새 API가 필요했다. 디자이너는 에이전트가 피그마의 표현에 맞는 제어 화면을 만들도록 웹 컴포넌트 기반 UI 도구도 만들었다. 자체 데모를 완성된 제품의 구현으로 바로 간주하지 않은 개발 과정이다.
원출처는 작동하는 시제품으로 모든 디자인을 시작하려던 접근이 다른 직군의 참고 자료로는 충분하지 않았다고 돌아본다. 이후 가능한 상태를 펼쳐 보여 주는 정적 목업으로 주요 기능을 먼저 합의하고 코드 시제품으로 실제 동작을 시험했다. 출시 직전에는 복잡한 색상 제어를 선택 목록으로 줄이는 등 범위를 조정했다고 밝혔다. 모든 기능을 한 번에 완성했다는 사례가 아니다.
게시와 에이전트 편집에는 서로 다른 조건이 있다
공식 도움말은 어떤 플랜에서도 셰이더 게시를 지원하되 만들고 게시하려면 디자인 에이전트 접근이 필요하다고 설명한다. 커뮤니티에 공개하는 셰이더는 피그마의 검토를 거쳐야 하며 조직 안의 비공개 공유는 해당 검토 대상이 아니다. 승인 뒤 공개 버전과 로컬 버전을 볼 수 있다. 공개 게시 버튼을 누르는 즉시 검토 없이 목록에 올라가는 흐름은 아니다.
원출처는 발표 당시 에이전트를 공개 베타로 소개하고 무료 사용 뒤 AI 크레딧을 쓰게 될 예정이라고 밝혔다. 현재 도움말은 작업 복잡도에 따라 크레딧이 달라진다고 설명한다. Full 좌석과 파일 편집 권한이 있으면 파일을 수정하도록 요청할 수 있고, 다른 좌석이나 읽기 권한에서는 대화가 가능하다. 개인 Draft 파일에서는 좌석에 관계없이 수정할 수 있다는 조건도 명시한다.
생성할 수 있는 도구를 검토할 수 있는 도구로 만든다
코드에 접근하고 바깥 에이전트에서 수정할 수 있으면 프롬프트 결과를 반복해서 요청하는 것 외에 구체적인 변경 경로가 생긴다. 그러나 생성된 화면과 코드가 존재한다는 사실만으로 원하는 효과가 모든 상황에서 작동하는 것은 아니다. 도구를 공유하려는 팀은 어떤 레이어와 입력에 효과를 적용하고 어떤 제어가 필요한지 확인할 수 있다. 상호작용과 움직임이 더해지면 검토할 상태도 늘어난다.
커뮤니티의 게시 검토와 조직 내부 검토는 같은 과정이 아니다. 비공개 공유가 회사의 커뮤니티 검토를 받지 않는다는 조건을 이해하면 도구의 목적과 사용 안내를 누가 확인할지 정할 수 있다. HTML·React 구현을 연결하는 기능도 실제 적용 환경에서 결과를 확인하는 단계가 필요하다. 원출처의 확장은 재사용과 편집의 선택지를 늘린 발표이며 모든 실행 환경의 동등한 성능을 측정한 발표는 아니다.
시제품은 질문에 맞춰 서로 다른 형태로 쓴다
개발 과정에서 정적 목업으로 돌아간 장면은 AI 시제품의 가치가 목적에 따라 달라진다는 점을 보여 준다. 작동하는 데모는 효과를 체감하는 데 유용하지만 보이지 않는 오류 상태나 모든 제어 선택을 한눈에 전달하기는 어렵다. 다른 직군이 같은 결정을 내리려면 가능한 상태를 펼친 자료가 더 유용할 수 있다. 이후 코드를 시험하는 단계와 경쟁하는 작업으로 볼 필요는 없다.
같은 방향의 제품을 만드는 팀은 지금 답해야 할 질문을 먼저 정할 수 있다. 표현이 매력적인지, 제어 방식이 이해되는지와 실제 렌더링이 가능한지는 다른 증거를 요구한다. 엔지니어의 구현 검토와 디자이너의 시각 판단, 제품 관리자의 범위 조정을 연결한 과정이 이번 사례의 의미다. 생성 도구가 더 쉬워져도 어떤 상태와 요구를 출시 범위에 넣을지 결정하는 일은 제품 개발의 중심에 남는다.
출처
Figma Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Behind the build: Generative plugins and shaders at Figma (새 창)
