화면은 나왔는데, 그대로 개발자에게 넘겨도 될까요?
예를 들어 피그마 에이전트에 결제 화면을 요청해 빠르게 시안이 나와도, 버튼을 눌러보면 팀 컴포넌트가 아니라 새 도형일 수 있습니다. 같은 파란색처럼 보여도 엉뚱한 의미 변수가 연결돼 있을 수 있어요. 디자인 시스템을 운영하는 팀이라면 생성 속도보다 이 뒷정리가 더 걱정됩니다.
Figma 에이전트의 유용한 변화는 결과를 이미지로 건네는 대신, 사람이 작업하던 디자인 파일에서 편집 가능한 레이어를 만든다는 점입니다. 선택한 레이어를 기준으로 요청할 수 있고, 에이전트가 작업하는 동안 다른 부분을 직접 수정하거나 별도 프레임에서 여러 방향을 병렬로 탐색할 수도 있어요.
다만 같은 캔버스에서 일한다고 팀의 규칙까지 자동으로 이해하는 건 아닙니다. 프롬프트를 길게 쓰기 전에 에이전트가 참조할 발행 라이브러리와 컴포넌트 구조를 정리해야 하는 이유가 여기에 있습니다.
먼저 한 화면에서 라이브러리 준수 여부를 시험하세요
첫 시도는 새 제품 전체가 아니라 로그인이나 결제처럼 상태가 분명한 화면 하나면 충분합니다. 원본을 복제하고, 아래 절차로 편집 가능한 결과와 구조적 정확성을 함께 확인해보세요.
- 시험용 프레임을 만듭니다.
Figma Design 파일에서 기존 화면 하나를 복제하고 해당 프레임의 레이어를 선택하세요. 파일을 수정하려면 Full seat와 편집 권한이 필요합니다. - 선택 영역에서 에이전트를 엽니다.
Agents를 클릭하거나 Cmd/Ctrl+Enter를 누르면 선택 영역을 대상으로 프롬프트를 시작할 수 있습니다. 대화를 이어가려면 디자인 파일의 왼쪽 탐색 영역에서 Agents를 여세요. - 발행된 라이브러리를 컨텍스트로 연결합니다.
프롬프트 상자의 Add context에서 팀 라이브러리를 추가하고, 필요한 컴포넌트·변수·스타일은 @를 입력한 뒤 목록에서 실제 항목을 선택하세요. 라이브러리를 최근 수정했다면 먼저 다시 발행해야 최신 내용을 참조할 수 있습니다. - 허용 범위와 필요한 상태를 함께 요청합니다.
아래처럼 연결한 라이브러리만 사용하도록 제한하고, 세 방향을 각각 별도 프레임에 만들도록 요청하세요. 대괄호 부분은 그대로 보내지 말고, @를 입력해 목록에서 팀의 실제 컴포넌트와 의미 변수를 선택해 넣습니다.
Add context에서 연결한 Product UI 라이브러리만 사용해 선택한 결제 화면을 세 가지 정보 구조로 바꿔 주세요. 각 방향은 비교할 수 있도록 각각 별도 프레임에 생성해 주세요. [@로 선택한 결제 요약 컴포넌트]와 [@로 선택한 버튼 컴포넌트], [@로 선택한 배경·텍스트 의미 변수]만 사용하고, 새 색상이나 분리된 컴포넌트를 만들지 마세요. 각 방향에 default, loading, error 상태를 표시해 주세요.
- 예쁜 화면이 아니라 연결 구조로 성공을 판정합니다.
세 가지 변형이 각각 별도 프레임에 편집 가능한 레이어로 생겼는지, 팀 컴포넌트와 의미 변수를 사용했는지, 하드코딩 값과 필수 상태 누락이 없는지 확인하세요. Organization 또는 Enterprise 플랜에서는 Check designs로 잘못된 색상, 다른 라이브러리 요소, 변수로 바꿔야 할 하드코딩 값을 추가로 찾을 수 있습니다. - 틀린 부분만 되돌립니다.
원치 않는 변경은 채팅의 Undo나 Cmd/Ctrl+Z로 취소할 수 있습니다. 전후 결과를 비교하려면 AI 수정본을 먼저 복제한 다음 원본을 되돌리세요.
접근 문제는 보이는 상태에 따라 확인하세요
Agents 자체가 보이지 않는다면 관리자가 AI 기능을 비활성화했는지 먼저 확인하세요. 공식 도움말 사이에 제공 플랜과 drafts의 좌석 범위 설명이 일치하지 않으므로 현재 계정의 UI와 관리자 설정도 함께 확인하는 편이 안전합니다.
채팅은 되지만 파일을 편집할 수 없다면 Full seat와 해당 파일의 편집 권한이 있는지 확인하세요. View·Dev·Collab seat와 보기 전용 사용자도 채팅은 할 수 있지만 파일 편집은 제한됩니다. 월간 사용 한도에 도달하면 제품 안에 한도 안내가 표시되며, 한도는 매월 초기화됩니다.
에이전트가 조립할 수 있는 상위 블록을 주세요
좋은 디자인 시스템은 이제 사람을 위한 갤러리이면서 에이전트를 위한 작업 인터페이스이기도 합니다. Figma는 원자 컴포넌트만 나열하기보다 카드·헤더처럼 간격, 색상, 레이아웃 규칙을 이미 품은 상위 블록을 제공하라고 권장합니다. 그래야 에이전트가 작은 요소의 조합 규칙을 매번 추측하는 부담을 줄일 수 있어요.
준비할 항목은 구체적입니다. 의미 있는 레이어와 컴포넌트 이름, 오토 레이아웃, 명시적인 component properties와 variants, 용도가 드러나는 변수, 평문 설명을 갖추세요. 설명에는 “언제 쓰는지”, “비슷한 컴포넌트와 무엇이 다른지”, “어떤 상태가 필요한지”를 적는 편이 좋습니다.
정리 순서는 화면에서 자주 쓰이는 블록부터
버튼 이름을 모두 다듬는 데서 시작하기보다 결제 요약 카드, 검색 결과 행, 설정 섹션처럼 실제 화면에서 반복되는 블록 하나를 고르세요. 그 블록의 오토 레이아웃, 속성, 상태, 의미 변수를 정리하고 발행한 뒤 에이전트 결과가 얼마나 달라지는지 비교하면 준비 작업의 효과를 확인하기 쉽습니다.
에이전트를 시스템 정리에도 쓸 수 있습니다. 공식 워크플로에는 문서 초안 작성, 컴포넌트·스타일·변수의 일괄 변경, 반복 패턴의 컴포넌트 후보 추출, 누락 상태와 불일치의 초기 검토가 소개돼 있어요. 다만 이 결과 역시 발행 전 사람의 확인이 필요한 초안입니다.
화면이 닮았다고 시스템을 지킨 것은 아닙니다
독립적인 한 디자인 스튜디오의 테스트에서는 라이브러리를 연결하고 사용을 명시한 뒤 결과가 개선됐지만, 버튼에 다른 의미 변수가 연결되거나 텍스트용 색상 변수가 구분선에 쓰인 사례가 발견됐습니다. 밝은 배경에서 대비가 낮아진 결과도 있었어요.
이 테스트는 한 업체의 디자인 시스템으로 진행됐고 프롬프트 전문, 반복 횟수, 정량 오류율이 공개되지 않았습니다. 따라서 모든 계정과 최신 버전에서도 같은 오류가 난다고 일반화할 수는 없어요. 다만 시각적으로 비슷한 결과와 핸드오프 가능한 구조는 별도로 확인해야 한다는 실무 경고로는 유용합니다.
개발자에게 넘기기 전 네 가지를 확인하세요.
- 팀 컴포넌트의 인스턴스가 유지됐는가
- 색상·간격·타이포그래피에 올바른 의미 변수가 연결됐는가
- default·loading·error·disabled 등 필요한 상태가 있는가
- 하드코딩 값과 다른 라이브러리의 요소가 섞이지 않았는가
문제가 있다면 화면 전체를 다시 만들기보다 해당 레이어와 변수만 선택해 수정 요청을 보내세요.
Design 에이전트와 Make는 결과물이 다릅니다
화면 구조와 시각적 변형을 만들 목적이라면 Design 에이전트가 출발점입니다. Figma Design의 실제 레이어를 생성·편집하므로 사람이 캔버스에서 이어서 다듬을 수 있어요. 반면 Figma Make는 인터랙티브 앱과 프로토타입을 만들고 웹에 게시하는 작업에 초점을 둡니다. Design에서 정리한 화면을 Make로 보내 동작을 구체화하거나, Make의 프레임을 다시 Design으로 복사하는 왕복 흐름도 지원됩니다.
외부 코딩 에이전트에서 만든 콘텐츠를 Figma 파일로 가져오려는 경우에는 원격 Figma MCP 서버의 use_figma 도구로 제공되는 write to canvas가 별도 경로입니다. 기존 파일에 쓰려면 Full seat와 해당 파일의 편집 권한이 필요하며, 가져온 결과는 캔버스에서 직접 확인해야 합니다.
세 기능을 모두 쓸 필요는 없어요. 편집 가능한 화면 탐색은 Design 에이전트, 눌러보는 동작 검증은 Make, 외부 코드 작업과 캔버스 연결은 MCP로 목적을 나누면 선택이 쉬워집니다.
