Figma Agent 기능, AI와 캔버스 사이에 디자인 규칙을 두다

Figma는 기술의 예측하기 어려운 특성에도 불구하고 팀이 AI 결과물을 더 효과적으로 통제할 수 있도록 하는 새로운 Figma agent 기능을 공개했다. 이번 출시로 에이전트는 동일한 플랫폼 안에서 문서화된 사양, 디자인 라이브러리, 코드 소스, 작동하는 프로토타입과 연결된다.

이는 단순히 또 하나의 어시스턴트에 명령어가 더해진 일이 아니다. Figma는 생성된 인터페이스가 제품 팀 전반으로 퍼지기 전에 에이전트를 둘러싼 작업 환경을 정의하려 한다. Figma는 제한 없는 생성보다 공유 컨텍스트, 가시적인 작업, 강제 가능한 디자인 규칙이 더 중요하다고 본다.

이러한 입장은 Figma를 디자이너와 Claude Code, Codex, GitHub Copilot, Cursor 같은 외부 코딩 에이전트 사이에 놓는다. Figma는 모델 성능만으로 경쟁하는 대신, 팀이 에이전트가 무엇을 만들어야 하는지 결정하는 제어 평면으로 캔버스를 만들고자 한다.

새로운 Figma Agent 기능은 생성 전에 규칙을 정의한다

Figma는 에이전트 제어를 개별 프롬프트에서 공유 제품 인프라로 옮기고 있다.

회사는 인도에서 처음 열린 Config 행사에서 확장된 워크플로를 발표했다. 핵심 추가 기능은 제품 요구사항, 결정 사항, 참고 자료, 기술적 컨텍스트를 기록하는 Markdown 기반 작업 공간인 Figma Specs다.

사양은 독립적인 Figma 파일로 존재하거나 캔버스 작업과 함께 배치될 수 있다. 팀은 모든 정보를 분리된 텍스트로 축소하지 않고도 디자인, FigJam 다이어그램, 코드 레이어, 기타 자료를 참조할 수 있다.

이 구조는 중요하다. 에이전트는 언어 생성 능력이 부족해서만 실패하는 경우가 드물기 때문이다. 흔히 요구사항, 시각 컴포넌트, 코드 구현, 이전 팀 결정 사이의 관계를 파악하지 못한다.

일반적인 Markdown 파일도 이러한 관계를 설명할 수는 있지만, 이를 자동으로 보존하지는 않는다. 링크는 오래되어 쓸모없어지고, 이미지는 맥락을 잃으며, 서로 다른 파일은 상충하는 지침을 제시할 수 있다.

Figma Specs는 이러한 연결을 기본 기능으로 만들기 위해 설계됐다. 회사의 출시 개요에 따르면, 팀은 대략적인 아이디어를 세부 사양으로 발전시킨 뒤 Figma의 MCP 서버를 통해 코딩 에이전트에 전달할 수 있다.

Model Context Protocol, 즉 MCP는 AI 시스템이 외부 도구 및 구조화된 컨텍스트와 연결될 수 있도록 하는 표준이다. Figma 구현에서는 이를 통해 캔버스와 지원되는 개발 에이전트 사이에서 제품 정보를 이동할 수 있다.

워크플로는 에이전트가 코드를 작성하기 전부터 시작된다. 팀은 사양 안에 요구사항, 다이어그램, 디자인 참고 자료, 코드 컨텍스트를 모은 뒤 생성 과정에서 이 자료를 활용할 수 있다.

동일한 컨텍스트는 Figma 캔버스에서 실행되는 코드로 구동되는 인터랙티브 프로토타입인 코드 레이어도 지원할 수 있다. 이를 통해 프로토타입은 그것을 만들어낸 디자인과 결정 사항 옆에서 검토할 수 있다.

Figma는 디자인 시스템을 통해 활용 가능한 정보도 확장했다. 팀은 게시된 라이브러리에 문서화된 가이드라인을 추가하고 GitHub 리포지토리 또는 npm 패키지의 코드 소스를 연결할 수 있다.

가이드라인은 규칙, 권장 패턴, 금지된 처리 방식, 구현 세부사항을 문서화할 수 있다. 관련 라이브러리가 활성화되면 에이전트는 이 자료를 읽을 수 있다.

코드 소스는 또 다른 기반 컨텍스트 계층을 추가한다. 에이전트가 스크린샷이나 시각적 프레임에서 모든 인터페이스 요소를 추론하도록 강요하는 대신, 이미 구현된 컴포넌트에 접근할 수 있게 한다.

이 조합은 컨텍스트의 위계를 만든다. Specs는 팀이 만들고자 하는 것을 설명하고, 디자인 라이브러리는 시각 언어를 정의하며, 코드 소스는 요소가 소프트웨어에서 어떻게 작동하는지 보여준다.

에이전트 발표에서는 디자인 라이브러리, 코드 라이브러리, 가이드라인을 위한 중앙 집중식 관리도 강조됐다. Figma는 에이전트가 작업을 만들거나 편집하는 동안 이 시스템을 참조할 수 있다고 밝혔다.

이러한 제어 기능은 생성형 인터페이스에서 반복되는 문제를 겨냥한다. 모델은 조직의 컴포넌트 규칙, 인터랙션 패턴, 접근성 관행을 무시하면서도 그럴듯한 화면을 만들 수 있다.

다듬어진 결과물이 반드시 유효한 제품 결과물인 것은 아니다. 올바르게 보이더라도 중복 컴포넌트, 지원되지 않는 상태, 또는 개발자가 나중에 교체해야 하는 구현 작업을 만들어낼 수 있다.

Figma의 해답은 프롬프트를 없애는 것이 아니다. 하나의 채팅을 시작한 개인이 아닌 팀에 속하는 지속적인 컨텍스트로 프롬프트를 둘러싸는 것이다.

이는 프롬프트 자체의 역할을 바꾼다. 프롬프트는 에이전트와 제품 사이에 놓인 유일한 지시가 아니라, 관리되는 작업 공간 안의 요청이 된다.

Figma Code Layers는 실행 중인 소프트웨어를 캔버스로 가져온다

Figma code layers는 캔버스를 시각적 표현을 검토하는 공간에 그치지 않고, 동작을 시험하는 공간으로 바꾼다.

이번 출시의 일부로 code layers는 비공개 베타에서 공개 베타로 전환됐다. Figma는 개별 계정마다 접근 권한을 받는 시점은 다를 수 있지만, 이 기능이 요금제 전반에 걸쳐 점진적으로 배포되고 있다고 밝혔다.

코드 레이어에는 실행 중인 코드로 구동되는 작동 가능한 인터페이스가 포함된다. 팀은 이를 일반적인 디자인 프레임 옆에 배치하고, 복제하고, 다양한 방향을 시험하며, 인터랙티브 상태를 살펴볼 수 있다.

이 구분은 중요하다. 전통적인 프로토타입은 연결된 프레임을 따라가는 경로를 시뮬레이션할 수 있지만, 실제 컴포넌트의 동작을 나타내지 못할 수 있다.

실행 중인 구현은 로딩 동작, 빈 상태, 오류, 반응형 레이아웃, 복잡한 인터랙션을 드러낼 수 있다. 이런 세부사항은 정적인 화면이 해결하지 못한 제품 관련 질문을 자주 드러낸다.

code layers 가이드는 여러 시작점을 설명한다. 사용자는 Figma agent를 통해 레이어를 생성하고, 디자인을 변환하고, 코드를 가져오거나, 기존 팀 코드베이스에서 시작할 수 있다.

디자이너는 확립된 결제 흐름을 선택한 뒤 에이전트에게 대체 배송 옵션을 추가해 달라고 요청할 수 있다. 그 결과로 생성된 코드 레이어는 유효성 검사, 로딩, 성공, 실패 동작을 보여줄 수 있다.

팀은 그 버전을 복제한 뒤 다른 인터랙션을 옆에서 시험할 수 있다. 제품 관리자, 디자이너, 엔지니어는 하나의 공유 파일에서 작동하는 옵션을 비교하게 된다.

Figma는 변경 사항이 코드 레이어로 다시 이동할 수 있으며, 지원되는 워크플로에서는 연결된 코드베이스에도 반영될 수 있다고 밝혔다. 이 약속은 단순한 디자인-코드 내보내기보다 더 중요한 의미를 지닌다.

내보내기는 보통 핸드오프 산출물이다. 연결된 코드 레이어는 디자인 탐색과 구현 사이의 반복적 순환 과정에 계속 참여하도록 의도됐다.

Figma는 2026년 6월 code layers를 처음으로 비공개 베타로 공개했다. 이전 캔버스 프리뷰는 GitHub 가져오기, 로컬 폴더, 템플릿, Figma Make 결과물, 에이전트가 생성한 시작점을 지원했다.

공개 베타는 이 모델을 더 폭넓은 사용자층에 제공한다. 또한 코드 기반 협업이 신중하게 선정된 팀 밖에서도 작동하는지 더 큰 시험대에 올린다.

당장의 사용 사례는 생성된 코드를 자동으로 출시하는 일이 아니다. 제품 탐색 과정에서 코드를 사용할 만큼 저렴하게 만드는 것이다.

Figma 최고디자인책임자 Loredana Crisan은 코드 생성과 실제 출시 사이의 격차가 커지고 있다고 설명했다. 그는 TechCrunch에 조직이 17배 더 많은 코드를 생산하는 반면, 출시는 1.3배 증가하는 데 그쳤다고 말했다.

이 수치는 회사가 제공한 것이므로 독립적인 업계 벤치마크로 취급해서는 안 된다. 그럼에도 Figma code layers 전략의 배경을 설명해 준다.

생성된 코드는 점점 더 프로덕션에 도달하지 않을 가능성을 탐색하는 데 사용되고 있다. Figma는 팀이 함께 보고, 논의하고, 다듬을 수 있는 곳에서 이러한 탐색 작업이 이뤄지기를 바란다.

이는 코드를 최종 구현 매체에서 디자인 재료로 재구성한다. 제품 팀은 프로덕션 아키텍처에 전념하기 전에 작동하는 소프트웨어를 활용해 무엇을 만들어야 하는지 명확히 할 수 있다.

이 접근 방식은 터미널 기반 에이전트 세션이 공유하기 까다로운 경우가 많다는 점도 인정한다. 개발자는 여러 인터페이스를 빠르게 생성할 수 있지만, 협업자는 나중에 링크나 녹화본만 받게 될 수 있다.

그 과정은 결과물 뒤에 있는 대안, 프롬프트, 트레이드오프를 숨긴다. 작동하는 버전을 캔버스에 올리면 탐색 과정이 가시화되고 이의를 제기하기도 쉬워진다.

다만 가시성이 프로토타입 코드를 프로덕션 수준으로 만들지는 않는다. 팀에는 여전히 엔지니어링 검토, 테스트, 보안 통제, 접근성 검증, 유지보수 가능한 아키텍처가 필요하다.

따라서 code layers의 가치는 팀이 결과물을 어떻게 분류하느냐에 달려 있다. 탐색용 산출물로 활용한다면, 생성된 프로토타입이 완성된 소프트웨어인 척하지 않으면서 피드백 주기를 단축할 수 있다.

진짜 경쟁은 공유 컨텍스트와 고립된 에이전트 채팅의 대결이다

Figma는 가장 빠르게 첫 초안을 생성하는 에이전트보다 관리되는 컨텍스트가 더 중요해질 것이라고 보고 있다.

이 이야기에서 주된 상대는 다른 디자인 공급업체가 아니다. 제품 작업을 비공개 채팅, 터미널, 또는 분리된 브라우저 세션 안에 두는 고립된 에이전트 워크플로다.

코딩 에이전트는 이미 텍스트와 이미지에서 인터페이스를 생성한다. 그러나 모든 참여자가 서로 다른 지침과 로컬 컨텍스트를 바탕으로 작업할 때, 그 속도는 새로운 조정 문제를 만든다.

어떤 디자이너는 최신 컴포넌트 라이브러리를 첨부할 수 있다. 개발자는 이전 리포지토리 브랜치를 사용할 수 있고, 제품 관리자는 별도 문서에서 복사한 요구사항을 제공할 수 있다.

각 에이전트는 그럴듯한 답을 반환할 수 있다. 하지만 시스템이 동일한 단일 정보 원천을 받지 못했기 때문에 결과물은 여전히 충돌할 수 있다.

Figma Specs는 컨텍스트에 가시적인 거처를 제공해 이러한 분절을 줄이려 한다. 요구사항을 참조 대상인 다이어그램, 디자인, 코드 레이어, 결정 사항 가까이에 유지한다.

디자인 시스템 확장은 관련 문제를 해결한다. Figma는 에이전트가 사용할 수 있는 컴포넌트뿐 아니라, 그 사용을 지배하는 규칙도 이해하기를 바란다.

라이브러리에는 여러 버튼 변형이 포함될 수 있지만, 파괴적 작업에 어떤 변형을 사용해야 하는지는 설명하지 않을 수 있다. 가이드라인은 이렇게 빠진 의사결정 논리를 제공할 수 있다.

마찬가지로 코드 소스에 접근하면 에이전트는 컴포넌트가 이미 존재하는지 알 수 있다. 이는 호환되지 않는 동작을 가진 시각적으로 유사한 대체물을 생성하려는 유혹을 줄일 수 있다.

Figma의 기존 agent는 이제 파일 전반 검색, 플랫폼 콘텐츠 첨부, 라이브러리 요소 참조, 여러 프롬프트 동시 실행을 지원한다. agent 문서는 내장 agent와 외부 MCP 클라이언트도 구분한다.

내장 agent는 디자인 파일에서 직접 작동한다. 외부 에이전트는 Figma의 write-to-canvas 기능을 사용해 코드베이스나 다른 AI 프로젝트의 콘텐츠를 플랫폼으로 가져올 수 있다.

이 구분을 통해 Figma는 하나의 어시스턴트가 모든 작업을 처리하도록 요구하지 않고도 여러 에이전트를 지원할 수 있다. 회사는 변화하는 모델 및 개발 도구 집단 아래의 공유 계층으로 남을 수 있다.

회사에 따르면 MCP 지원에는 현재 20곳이 넘는 새로운 파트너가 포함된다. 발표된 목록에는 OpenCode, Dia, Meta Muse, 인도의 AI 스타트업 Sarvam이 포함된다.

Figma는 이미 Claude Code, Codex, GitHub Copilot, Cursor를 파일에 쓸 수 있는 외부 에이전트 사례로 언급한 바 있다. 확장된 파트너 지원은 모델 중립성을 플랫폼 전략의 일부로 만든다.

모델 순위는 빠르게 바뀌기 때문에 이는 방어 가능한 입장이다. 팀은 인터페이스 코드에는 한 에이전트를, 리서치, 문서화, 이미지 생성에는 다른 에이전트를 선호할 수 있다.

Figma는 공유된 제품 맥락을 통제할 수 있다면 모든 모델 비교에서 이길 필요는 없다. 에이전트가 Figma의 파일, 라이브러리, 규칙을 권위 있는 입력값으로 다루게 하면 된다.

회사의 MCP canvas update는 이러한 목표를 분명히 드러낸다. 스킬은 외부 에이전트에게 워크플로를 실행하는 방법, 단계의 순서, 팀 관례를 따르는 방식을 지시할 수 있다.

여기서 스킬이란 에이전트의 행동을 형성하는 재사용 가능한 지침 모음이다. 그렇지 않다면 한 직원의 프롬프트 이력 안에만 남을 운영 지식을 담을 수 있다.

디자인 시스템 팀은 폼 구축을 위한 스킬을 만들 수 있다. 지침에는 승인된 필드 컴포넌트, 접근성 라벨, 문서화된 검증 상태, 특정 간격 토큰의 사용이 요구될 수 있다.

외부 코딩 에이전트는 자산을 만들거나 업데이트하면서 이러한 규칙을 적용할 수 있다. Figma의 캔버스에는 더 넓은 팀이 이미 협업하는 위치에 그 결과물이 표시된다.

이는 구조화된 engineering knowledge base와 닮았지만, 맥락이 제품 아티팩트에 직접 연결된다는 점에서 다르다. 차이는 의사결정이 실행 가능한 형태가 되는 위치에 있다.

따라서 새롭게 부상하는 경쟁은 오케스트레이션에 관한 것이다. 디자인 도구, 코드 편집기, 리포지터리, 문서화 시스템 모두 에이전트가 신뢰할 수 있는 맥락을 받는 장소가 되고자 한다.

많은 인터페이스 의사결정이 이미 Figma의 캔버스에 존재한다는 점에서 Figma는 유리하다. 다만 플랫폼이 그러한 결정을 프로덕션 코드와 동기화할 때에만 그 이점은 유지된다.

예측 가능한 에이전트도 불완전한 입력에 의존한다

Figma는 에이전트의 행동을 제한할 수 있지만, 모든 규칙이 완전하고 최신이며 올바르게 해석된다고 보장할 수는 없다.

회사가 이러한 제어 기능을 도입하는 이유는 생성형 AI가 여전히 비결정적이기 때문이다. 같은 요청도 실행할 때마다 서로 다른 구조, 세부 사항, 구현 선택을 낼 수 있다.

가이드라인은 이러한 편차를 줄일 수 있다. 그러나 특히 지침이 충돌하거나 새로운 상황을 다루지 못할 때 이를 없앨 수는 없다.

한 팀은 에이전트에게 선호하는 컴포넌트를 사용하라고 지시할 수 있지만, 연결된 리포지터리에는 두 가지 구현이 있을 수 있다. 디자인 라이브러리는 한 버전을 가리킬 수 있지만, 프로덕션 코드는 다른 버전에 의존할 수 있다.

명세는 또 다른 유지관리 의무를 만든다. 잘 구조화된 명세도 요구사항이 현재의 의사결정을 반영할 때에만 도움이 된다.

오래된 맥락은 에이전트를 일관되게 잘못된 방향으로 이끌 수 있다. 결과물이 관리되고 신뢰할 만해 보일 수 있기 때문에, 이 실패는 명백한 환각보다 더 위험하다.

디자인 시스템 팀에는 에이전트 지침에 대한 소유권 규칙이 필요하다. 누가 가이드라인을 게시하고, 코드 소스를 연결하며, 충돌을 해결하고, 변경을 승인할지 결정해야 한다.

Figma는 맵과 시스템 검사를 포함한 중앙집중식 디자인 시스템 관리를 미리 공개하고 있다. 이 도구들은 누락된 설명이나 인터랙션 상태를 포함해 의존성과 공백을 드러내기 위한 것이다.

에이전트 접근은 취약한 시스템 문서화의 영향을 키우므로 이러한 관리 계층은 필요하다. 문서화되지 않은 컴포넌트는 과거에는 사람이 올바르게 사용하기 더 어려웠다.

이제 에이전트는 몇 분 안에 여러 화면에 걸쳐 같은 오해를 재현할 수 있다. 더 빠른 생성은 좋은 표준과 방치된 표준 모두를 증폭한다.

접근 제어도 또 다른 우려 사항이다. 에이전트를 디자인, 명세, 리포지터리, 외부 서비스에 연결하면 독점적인 제품 정보가 포함된 영역이 넓어진다.

Figma는 MCP 기능이 자사의 보안 및 신뢰성 제어 기능의 혜택을 받는다고 말한다. 기업 팀은 여전히 권한, 데이터 보존, 연결된 클라이언트, 리포지터리 접근을 검토해야 한다.

플랫폼은 관리자가 AI 기능을 비활성화할 수 있게 하지만, 일부 조직에는 제공되는 제어 범위가 지나치게 넓을 수 있다. Figma의 지원 문서에 따르면 코드 레이어를 비활성화하면 다른 AI 기능도 비활성화될 수 있다.

팀은 프로젝트 민감도, 리포지터리, 모델 제공업체 또는 사용자 역할을 기준으로 더 세분화된 정책을 원할 수 있다. 거버넌스의 효과는 그러한 제어 기능이 어떻게 발전하는지에 달려 있다.

도입 여부도 여전히 불확실하다. 디자이너는 에이전트 지침을 유지하거나 가져온 리포지터리의 문제를 해결하고 싶지 않으면서도, 코드 기반 탐색은 반길 수 있다.

개발자는 그럴듯해 보이지만 기존 아키텍처와 충돌하는 생성 구조에 저항할 수 있다. 제품 관리자는 동기화가 필요한 또 하나의 문서가 되는 상세 명세를 만들 수 있다.

초기 사용자 논의에서는 이미 리포지터리 가져오기, 인프라 오류, AI 기능이 오랫동안 이어진 제품 요청에서 관심을 분산시키는지에 관한 의문이 제기됐다. 이러한 일화만으로 광범위한 제품 품질을 입증할 수는 없다.

다만 공개 베타가 무엇을 검증해야 하는지는 보여 준다. Figma는 코드 레이어가 실제 리포지터리 및 일상적인 팀 제약 속에서 안정적으로 작동한다는 점을 증명해야 한다.

플랫폼은 개념적 위험에도 직면한다. 요구사항, 디자인, 코드, 콘텐츠, 에이전트 제어 기능을 결합하면 파편화를 줄일 수 있지만, Figma 자체를 더 복잡하게 만들 수도 있다.

공유 캔버스는 각 참여자가 모든 기반 시스템을 숙달하지 않고도 관련 상태를 이해할 수 있을 때 성공한다. 지나치게 많은 중첩된 표면은 하나의 제품 안에서 조정 문제를 다시 만들 수 있다.

더 높은 품질과 브랜드 정합성을 갖춘 생성에 대한 Figma의 주장도 독립적인 근거가 필요하다. 회사는 맥락이 워크플로에 어떻게 들어가는지는 보여 줬지만, 에이전트가 이를 얼마나 일관되게 따르는지는 보여 주지 않았다.

팀은 이를 가정하기보다 결과를 측정해야 한다. 유용한 지표에는 컴포넌트 재사용, 접근성 결함, 재작업, 검토 시간, 프로토타입과 프로덕션 코드 간의 차이가 포함된다.

핵심 질문은 에이전트가 매력적인 화면을 생성할 수 있는지가 아니다. 그 화면이 실제 디자인 시스템 및 코드베이스와 맞닿았을 때도 살아남는지다.

Figma Specs는 플랫폼을 디자인 파일 너머로 확장한다

Specs는 Figma의 에이전트 전략을 캔버스 전후의 제품 의사결정을 소유하려는 더 폭넓은 시도로 전환한다.

제품 명세는 전통적으로 문서 도구, 티켓 관리 시스템 또는 리포지터리에 존재했다. 이후 시각 작업은 Figma로 이동하고, 기술적 구현은 다른 곳에서 이뤄졌다.

각 전환은 번역 단계를 만들었다. 요구사항은 뉘앙스를 잃을 수 있고, 디자인은 승인된 동작에서 벗어날 수 있으며, 개발자는 불완전한 핸드오프 노트를 서로 다르게 해석할 수 있었다.

Figma Specs는 이러한 분리를 문제 삼는다. Markdown을 유연한 매체로 다루면서도 Figma의 시각적·기술적 아티팩트 네트워크 안에 포함한다.

제품 관리자는 요구사항을 초안으로 작성하고 FigJam 다이어그램을 참조할 수 있다. 디자이너는 관련 화면을 연결하고, 엔지니어는 GitHub의 코드 맥락을 추가할 수 있다.

이후 에이전트는 결합된 자료를 사용해 코드 레이어를 만들거나 MCP를 통해 명세를 전달할 수 있다. 명세는 사람이 검토만 하는 문서가 아니라 능동적인 입력값이 된다.

이는 Figma가 다룰 수 있는 워크플로를 확장한다. 플랫폼은 더 이상 인터페이스 디자인을 만들고 이를 개발 팀에 넘기는 일에만 국한되지 않는다.

Figma는 제품 정의, 프로토타이핑, 구현 맥락, 콘텐츠 운영에 참여하고자 한다. 추가되는 각 표면은 에이전트에게 공유 맥락의 가치를 높인다.

Figma의 Payload 통합은 이러한 방향을 강화한다. Payload는 2025년에 Figma에 합류한 오픈소스 헤드리스 콘텐츠 관리 시스템이다.

새 통합은 Payload를 플랫폼의 프롬프트 기반 애플리케이션 및 웹사이트 빌더인 Figma Make와 연결한다. 팀은 시각 프로토타입을 콘텐츠 모델과 분리하지 않고도 데이터 기반 경험을 만들고 콘텐츠를 관리할 수 있다.

Figma는 이전 12개월 동안 Payload 다운로드가 6배 증가했다고 말한다. 이는 회사가 보고한 지표이며, 새 통합을 사용하는 프로젝트 수는 드러내지 않는다.

그럼에도 이 조합은 생성된 웹사이트의 실질적인 한계를 해결한다. 세련된 페이지도 콘텐츠가 하드코딩되어 있거나 게시 워크플로와 분리되어 있으면 활용도가 떨어진다.

Payload는 콘텐츠 저장소, API, 워크플로, 관리 인터페이스를 제공한다. Figma는 마케터가 콘텐츠를 관리하는 동시에 개발자는 오픈소스 프레임워크에 계속 접근할 수 있다고 말한다.

이는 탐색을 위한 구축과 출시를 위한 구축의 차이도 더 분명하게 만든다. 일회용 프로토타입은 아이디어를 검증할 수 있을 만큼의 동작만 필요하다.

프로덕션 사이트에는 영속적인 콘텐츠, 권한, 데이터 구조, 운영 워크플로가 필요하다. CMS를 통합하면 Figma Make는 두 번째 범주에 더 가까워진다.

회사는 이탈 경로를 유지하는 데 신중하다. 팀이 Payload 기반 작업물을 Figma 밖으로 가져갈 수 있다고 말하는데, 이는 플랫폼 종속을 우려하는 개발자에게 중요하다.

그러나 이식성은 실제 프로젝트를 통해 평가해야 한다. 내보낼 수 있는 코드가 이를 생성한 환경 없이도 자동으로 유지관리하기 쉬운 것은 아니다.

더 폭넓은 전략은 여러 범주에 동시에 압박을 가한다. 문서 도구는 명세를 호스팅하고, 코딩 에이전트는 구현을 생성하며, 웹사이트 빌더는 시각 편집과 배포를 결합한다.

Figma는 이들 모두를 하나의 모델로 대체하려는 것이 아니다. 대신 그 결과물이 연결되는 공유 기반이 되려 한다.

이 접근은 회사의 기존 협업 모델과 맞아떨어진다. Figma는 파일이 멀티플레이어 편집, 댓글, 컴포넌트, 공유 라이브러리를 지원했기 때문에 제품 팀의 중심이 됐다.

에이전트는 새로운 유형의 참여자를 추가한다. 인간 협업자와 달리 이들은 큰 영역을 빠르게 수정하고 기계가 읽을 수 있는 인터페이스를 통해 여러 도구에서 작업할 수 있다.

따라서 플랫폼은 협업과 제약을 모두 지원해야 한다. 잘못된 지침이 얼마나 멀리 확산될 수 있는지 제한하면서 에이전트 작업을 가시화해야 한다.

Figma Specs, 코드 소스, 가이드라인은 별개의 기능이지만 함께 사용하면 가치가 누적된다. 각각은 맥락 문제의 서로 다른 부분을 해결한다.

Specs는 의도를 설명한다. 라이브러리는 재사용 가능한 디자인 의사결정을 표현하고, 코드 소스는 그러한 의사결정을 구현에 근거하게 한다.

코드 레이어는 결과를 검증할 수 있는 실행 가능한 공간을 제공한다. MCP는 이후 이 과정을 다른 곳에서 작동하는 에이전트와 연결한다.

이것이 회사의 새로운 모델에서 Figma 에이전트가 작동하는 방식이다. 이들은 단순히 프롬프트를 받고 화면을 생성하지 않는다.

이들은 제품 맥락, 공유 규칙, 작업 아티팩트, 사람의 검토로 이어지는 사슬 안에서 작동한다. 그 사슬이 제품 전략이다.

Figma의 에이전트 전략이 효과적인지 보여 줄 세 가지 신호

다음 검증 과제는 관리된 에이전트 워크플로가 또 다른 유지관리 계층을 더하지 않고 실제 팀의 성과를 개선하는지 여부다.

첫 번째 신호는 공개 베타 출시 이후의 코드 레이어 도입이다. 접근 권한만으로는 가치를 입증할 수 없다.

팀은 캔버스에서 실행 중인 프로토타입을 반복해서 만들고, 복제하고, 검토하고, 다듬어야 한다. 지속적인 사용은 코드 기반 탐색이 실제 협업 문제를 해결한다는 점을 시사할 것이다.

가장 유용한 근거는 도입 전후의 워크플로를 비교하는 것이다. 더 짧은 검토 주기, 더 적은 핸드오프 수정, 인터랙티브 상태의 더 나은 표현은 Figma의 주장을 뒷받침할 수 있다.

포기된 가져오기, 불안정한 실행, 외부 도구에서의 잦은 재생성은 이를 약화할 것이다. 공개 베타는 Figma에 그러한 문제를 발견할 더 큰 사용자 집단을 제공한다.

두 번째 신호는 디자인 가이드라인과 코드 소스가 에이전트 오류를 줄이는지 여부다. 팀은 승인된 컴포넌트의 재사용이 늘고 브랜드 또는 구현 불일치가 줄어드는 모습을 봐야 한다.

Figma의 10월 release notes는 에이전트가 라이브러리 가이드라인을 읽고, 파일을 검색하며, 플랫폼 맥락을 첨부하고, 맞춤형 스킬을 지원할 수 있음을 확인한다. 이러한 기능은 결과가 아니라 작동 방식을 확립한다.

결정적인 근거는 반복적인 프로덕션 사용에서 나올 것이다. 성공적인 시스템은 사용자가 모든 프롬프트에서 관례를 다시 설명하지 않아도 에이전트가 이를 따르도록 도와야 한다.

또한 충돌도 드러나야 합니다. 디자인 라이브러리와 코드 저장소의 내용이 다를 경우, 시스템은 어느 쪽이 기준인지 팀이 식별하도록 도와야 합니다.

그렇지 않으면 맥락이 늘어날수록 모호성도 커질 수 있습니다. 에이전트는 더 많은 정보를 받으면서도 어떤 지침을 따라야 할지 오히려 더 확신하지 못할 수 있습니다.

세 번째 신호는 외부 에이전트 지원이 어떻게 발전하는지입니다. 팀이 디자인 맥락을 다시 구축하지 않고도 모델을 바꿀 수 있을 때 Figma의 플랫폼 주장은 더욱 설득력을 얻습니다.

더 많은 MCP 클라이언트를 지원하면 배포 범위는 넓어지지만, 호환성은 기본적인 쓰기 권한을 넘어야 합니다. 외부 에이전트는 컴포넌트, 변수, 가이드라인, 이미지, 코드 관계에 안정적으로 접근할 수 있어야 합니다.

Figma는 Plugin API와의 더 폭넓은 기능 동등성을 향해 작업하고 있다고 밝혔습니다. 이 영역의 진전은 외부 에이전트가 완전한 협업자가 될지, 제한적인 가져오기 도구에 머물지를 결정할 것입니다.

경쟁 측의 대응도 중요합니다. 코드 에디터와 개발 플랫폼은 자체 디자인 통합을 강화할 수 있고, 문서 시스템은 사양을 에이전트가 더 쉽게 읽을 수 있도록 만들 수 있습니다.

그러한 도구들이 작업을 Figma를 거치게 하지 않으면서도 맥락을 보존한다면, 팀은 분산형 워크플로를 선호할 수 있습니다. Figma는 통합이 단지 플랫폼 의존도를 높이는 데 그치지 않고 더 명확한 의사결정을 만든다는 점을 입증해야 합니다.

디자이너에게 실질적인 질문은 캔버스가 계속 판단의 공간으로 남느냐입니다. 에이전트는 디자인 검토를 결과물 정리 작업으로 바꾸지 않으면서 변형안 제작과 반복적인 편집을 가속해야 합니다.

개발자에게는 코드 레이어가 유용한 구현 맥락을 보존하는지가 핵심입니다. 생성된 프로토타입은 검토를 거친 프로덕션 코드로 오인되지 않으면서도 선택지 간의 절충점을 보여줘야 합니다.

제품 리더에게 가치는 추적 가능성에 있습니다. 하나의 요구사항은 이를 형성한 디자인, 프로토타입, 코드 소스, 그리고 의사결정과 연결되어야 합니다.

Figma의 에이전트 기능은 이제 그러한 워크플로를 위한 요소를 제공합니다. 앞으로 몇 달은 팀이 일상적인 압박 속에서도 이 요소들을 동기화된 상태로 유지할 수 있는지 보여줄 것입니다.

오픈 베타를 운영 실험으로 다루세요. 범위가 명확한 워크플로 하나를 선택하고, 현재 소스를 연결하며, 책임자를 정한 뒤 확장하기 전에 재작업을 측정하세요.

중요한 질문은 더 이상 AI 에이전트가 인터페이스를 그릴 수 있는지 여부가 아닙니다. 중요한 것은 그 인터페이스가 왜 팀의 기준을 따르는지 설명할 수 있는지, 그렇지 않을 때 이를 바로잡을 수 있는지입니다.