피그마의 새 디자인 에이전트는 이미지를 만들어 건네는 대신, 팀이 작업 중인 캔버스에서 실제 레이어를 함께 편집합니다. 다만 결과의 품질은 프롬프트 솜씨보다 컴포넌트·변수·문서가 얼마나 명확하게 정리돼 있는지에 더 크게 좌우돼요.
달라진 건 생성 기능보다 작업 장소예요
Figma 디자인 에이전트의 핵심은 AI와 사람이 같은 파일, 같은 레이어, 같은 디자인 시스템을 보며 일한다는 것이에요. 2026년 5월 공개된 이 에이전트는 Figma Design의 캔버스와 왼쪽 레일에 들어가며, 선택한 레이어에서 바로 프롬프트를 시작할 수 있습니다. 에이전트가 작업하는 동안 디자이너가 다른 부분을 직접 고칠 수도 있고, 여러 프롬프트를 병렬로 실행해 서로 다른 방향을 비교할 수도 있어요.
그래서 빈 화면에서 완성품 하나를 뽑는 용도보다 탐색과 반복 작업에서 더 실용적입니다. 같은 결제 화면에 대해 정보 구조 세 가지를 만들거나, 제목 배치와 이미지 구성이 다른 시안을 동시에 펼쳐놓고 비교할 수 있어요. 마음에 드는 방향이 나오면 프롬프트를 계속 덧붙이는 대신 캔버스에서 직접 레이어를 조정하면 됩니다. Figma 역시 직접 편집이 더 자연스럽고 AI 사용량도 아낄 수 있는 구간이 있다고 설명합니다.
| 구분 | Figma 디자인 에이전트 | Figma Make | Figma MCP |
|---|---|---|---|
| 주 작업 공간 | Figma Design 캔버스 | 코드 기반 프로토타입 편집기 | 외부 코딩 에이전트·터미널 |
| 주요 결과 | 편집 가능한 디자인 레이어 | 동작을 확인할 수 있는 프로토타입 | 디자인과 코드 사이의 읽기·쓰기 |
| 잘 맞는 일 | 시안 탐색, 일괄 편집, 피드백 반영 | 인터랙션과 동작 검증 | 코드와 캔버스 왕복 |
| 별도 설정 | 캔버스 안에서 바로 사용 | Figma 제품 안에서 사용 | MCP 서버 연결 필요 |
세 도구는 경쟁 관계라기보다 작업 단계를 나눠 맡습니다. Design 에이전트로 화면의 흐름·상태·문구를 정리하고, Make로 보내 동작을 확인한 뒤 다시 Design에 가져올 수 있어요. 코드에서 시작했다면 MCP의 use_figma 도구로 실제 컴포넌트와 변수를 사용한 레이어를 만든 다음 캔버스에서 다듬는 흐름도 가능합니다.
좋은 디자인 시스템은 이제 AI용 인터페이스이기도 해요
에이전트가 브랜드에 맞는 결과를 내게 하려면 디자인 시스템을 사람이 보기 좋은 전시장이 아니라 기계가 오해하기 어려운 작업 규칙으로 만들어야 합니다. Figma는 라이브러리가 구조적이고 완전할수록 에이전트가 디자인을 더 정확하게 해석하고 적용한다고 안내해요. 연결할 라이브러리를 직접 선택하고, 프롬프트에서 특정 토큰·변수·컴포넌트를 @멘션해 사용 범위를 좁힐 수도 있습니다.
특히 버튼과 입력창처럼 작은 원자 컴포넌트만 모아두면 에이전트가 조합 규칙을 추측해야 합니다. 카드, 헤더, 기능 행처럼 간격·타이포그래피·색상 규칙이 이미 담긴 상위 블록을 제공하는 편이 유리해요. 오토 레이아웃, 의미 있는 레이어 이름, 명시적인 variant와 state, 색상·간격·타이포그래피 변수도 함께 필요합니다. 최근 수정한 라이브러리는 반드시 발행해야 에이전트가 최신 버전을 참조합니다.
예쁜 설명 페이지보다 속성 설명이 더 중요할 수 있어요
사람은 캔버스에 배치된 사용 예시와 금지 표시를 한눈에 이해하지만, 에이전트는 프레임·텍스트·도형의 트리에서 의미를 추론해야 합니다. 컴포넌트 설명에 용도, 비슷한 컴포넌트와의 차이, 상태, 접근성 조건을 평문으로 적어두면 의도가 더 직접적으로 전달돼요.
문서 정리 자체도 에이전트에 맡길 수 있습니다. 기존 템플릿을 선택하고 컴포넌트 설명 초안을 만들게 하거나, 레이어 이름을 kebab-case로 통일하고, 누락된 상태와 variant를 찾고, 화면에서 반복되는 패턴을 새 컴포넌트 후보로 정리하게 할 수 있어요. CSS 변수 목록을 캔버스에 놓고 실제 코드와 Figma 변수 사이의 빠진 항목을 찾는 워크플로우도 공식 도움말에 제시돼 있습니다.
빠른 생성과 안전한 핸드오프는 다른 문제예요
현재 베타를 완성본 자동 제작기로 취급하면 위험합니다. Entify Design이 자체 디자인 시스템으로 진행한 공개 테스트에서는 연결된 라이브러리를 사용하라는 지시 뒤 결과가 나아졌지만, 버튼 내부에 잘못된 의미의 색상 변수가 들어가거나 텍스트용 변수가 구분선에 적용되는 문제가 관찰됐어요. 화면은 그럴듯해도 토큰 참조가 틀릴 수 있다는 뜻입니다.
같은 테스트에서는 밝은 배경에 대비가 낮은 색상이 적용된 사례도 나왔습니다. 단일 팀의 테스트이므로 모든 환경에 일반화할 수는 없지만, 적어도 생성 속도를 핸드오프 준비 완료의 증거로 보면 안 된다는 경고로는 충분해요. Figma도 라이브러리 발행 전 잘못된 색상, 다른 라이브러리의 컴포넌트·변수·스타일, 변수로 바꿔야 할 하드코딩 값을 별도로 점검하도록 안내합니다.
캔버스만 보고 승인하지 마세요
겉보기 색상과 간격이 맞아도 인스턴스가 분리됐거나 의미가 다른 변수가 연결됐을 수 있어요. 개발 핸드오프 전에는 컴포넌트 연결, 변수 출처, variant, 오토 레이아웃, 대비를 각각 확인해야 합니다.
접근 조건과 비용도 시험 전에 확인해야 합니다. 2026년 8월 기준 에이전트는 오픈 베타이며 Professional·Organization·Enterprise 플랜에서 제공됩니다. 공유 파일의 채팅은 Full seat가 사용할 수 있고, drafts에서는 Full·Dev·Collab·View seat가 시험할 수 있어요. 베타 동안 에이전트의 프롬프트와 작업은 AI 크레딧을 소비하지 않지만, 정식 출시 뒤에는 일반 AI 크레딧 정책이 적용될 예정입니다.
한 화면으로 안전하게 시험하는 4단계
- 작고 검증 가능한 대상을 복제하세요.
로그인, 검색 결과, 결제처럼 상태가 분명한 화면 하나를 별도 페이지에 복제합니다. 원본 대신 복제본에서 시작하고 성공 기준을 “오류·빈 화면·로딩 상태 포함”, “기존 라이브러리만 사용”처럼 적어두세요. - 라이브러리와 규칙을 프롬프트에 고정하세요.
Figma Design 왼쪽 레일에서 에이전트를 열고 대상 프레임을 선택합니다. 사용할 라이브러리를 지정한 뒤 필요한 컴포넌트와 변수를 @멘션하세요. “이 프레임을 세 가지 정보 구조로 복제하되 새 색상과 분리된 컴포넌트를 만들지 말 것”처럼 허용 범위도 함께 씁니다. - 생성과 일괄 수정을 분리하세요.
먼저 세 가지 방향을 별도 프레임으로 만들게 하고 사람이 하나를 고릅니다. 선택한 안에서만 실제 문구 입력, padding 통일, 컴포넌트 상태 변경 같은 반복 작업을 요청하세요. 탐색과 정리를 한 프롬프트에 섞지 않으면 어느 단계에서 규칙이 깨졌는지 찾기 쉬워집니다. - 구조 검수 뒤에만 핸드오프하세요.
레이어 패널과 Variables 패널에서 인스턴스 연결, 의미 토큰, 하드코딩 값, 오토 레이아웃을 확인합니다. hover·focus·error·disabled 상태와 색상 대비도 검사하세요. 오류가 하나라도 나오면 전체 재생성보다 해당 프레임과 변수만 선택해 수정시키고 다시 확인합니다.
이 실험에서 볼 지표는 “몇 분 만에 화면이 나왔나” 하나가 아닙니다. 첫 결과 중 유지한 레이어 비율, 잘못 연결된 변수 수, 분리된 인스턴스 수, 접근성 오류, 사람이 검수하고 고친 시간을 함께 기록하세요. 생성 시간이 줄어도 검수 시간이 늘었다면 아직 프로덕션 워크플로우가 빨라진 건 아니니까요.
.png)
