Figma 디자인 에이전트 베타: 한국 제품팀이 먼저 세울 디자인 시스템 운영 원칙

Figma는 2026년 5월 20일 디자인 에이전트를 베타로 발표했습니다. 핵심은 캔버스 안에서 팀의 컴포넌트·토큰·표준 맥락을 활용해 여러 방향을 탐색하고 대량 편집을 수행한다는 점입니다. 확인된 사실은 제한적 베타가 순차 제공되며 정식 출시 전 기능과 요금이 달라질 수 있다는 것입니다. POEMORA의 해석은 이를 ‘디자이너 대체’가 아니라 디자인 시스템의 품질과 책임 구조를 시험하는 운영 변화로 봐야 한다는 것입니다.

무엇이 발표됐고 어디까지 확정됐나

Figma 공식 발표에 따르면 에이전트는 선택한 디자인 레이어에서 프롬프트를 시작하고, 여러 아이디어를 병렬로 탐색하며, 사람이 직접 수정하는 동안 함께 반복할 수 있습니다. 자주 또는 최근 사용한 컴포넌트를 출발점으로 삼고 특정 라이브러리·토큰·변수·컴포넌트를 지정할 수도 있습니다. 타이포그래피 변경, 컴포넌트 상태 교체, 변수 이름 정리, 문서화 같은 반복 작업도 예시로 제시됐습니다.

공개 범위에는 제약이 있습니다. 발표 시점 기준으로 Professional·Organization·Enterprise의 Full seat 사용자를 중심으로 베타가 순차 배포되며, 대기 명단 등록이 접근을 보장하지 않습니다. 베타 동안 크레딧을 소모하지 않지만 일반 제공 시 AI 크레딧이 적용될 예정입니다. 따라서 지금 예산이나 납기 계획을 정식 제공 조건처럼 확정해서는 안 됩니다.

사실과 전망의 경계: ‘컴포넌트와 토큰 맥락을 활용한다’는 설명은 공식 기능 범위입니다. 그 결과가 언제나 팀 규칙을 준수하거나 접근성을 만족한다는 보장은 공식 발표에 없습니다.

한국 제품팀에는 생성보다 승인 흐름이 중요하다

국내 제품팀은 브랜드, 앱, 웹, 운영 화면을 한 라이브러리로 공유하면서도 담당 조직과 외주 파트너가 자주 달라집니다. 에이전트가 같은 파일에서 대량 수정을 수행하면 탐색 비용은 낮아지지만, 잘못된 토큰이나 폐기 예정 컴포넌트도 더 빠르게 퍼질 수 있습니다.

POEMORA는 생성 결과를 곧바로 ‘완료’ 상태로 보내지 말고 ‘실험 → 디자인 검토 → 접근성 검토 → 개발 검토 → 승인’ 상태를 파일과 이슈 트래커에 명시할 것을 권합니다. 특히 결제·인증·상담 신청처럼 실패 비용이 큰 흐름은 한 화면의 완성도보다 전체 여정의 상태와 예외를 함께 검토해야 합니다.

디자인 시스템을 에이전트가 읽기 좋게 만드는 법

Figma의 공식 워크플로 문서는 MCP(Model Context Protocol) 서버가 코드와 캔버스 사이에서 디자인·변수·컴포넌트 맥락을 주고받는 방식을 설명합니다. 코드 기반 프로토타입을 캔버스로 가져오고, 변수를 검토한 뒤 다시 코드로 반영하는 왕복 흐름도 제시합니다. 이때 도구보다 먼저 정리할 것은 시스템의 의미입니다.

1. 토큰 이름에 역할을 담습니다. ‘blue-500’만 두기보다 ‘action-primary-background’처럼 용도를 구분하고, 라이트·다크 모드 매핑을 문서화합니다.
2. 컴포넌트 상태를 빠짐없이 둡니다. 기본·호버·포커스·비활성·오류·로딩 상태를 변형으로 관리합니다.
3. 승인 자산과 실험 자산을 분리합니다. 에이전트가 초안 컴포넌트를 제품 표준으로 오인하지 않게 라이브러리와 페이지 경계를 세웁니다.
4. 코드 연결에 변경 기록을 남깁니다. 토큰 변경이 어떤 화면과 저장소에 반영되는지 pull request에서 추적합니다.

이 정리가 없다면 에이전트는 모호한 시스템을 빠르게 복제할 뿐입니다. 반대로 의미 있는 토큰, 사용 지침, 금지 사례가 갖춰져 있으면 반복 업무 자동화의 품질 기준도 명확해집니다.

접근성은 프롬프트가 아니라 검증 단계다

공식 워크플로 예시는 코드에서 가져온 다크 모드의 색 강도와 보조 텍스트 대비를 캔버스에서 비교하고 변수를 조정하는 과정을 보여줍니다. 이는 유용한 출발점이지만, 색 대비만으로 접근성이 완성되지는 않습니다.

• 키보드만으로 모든 조작을 완료할 수 있는지 확인합니다.
• 포커스가 보이고 모달을 열고 닫은 뒤 합리적인 위치로 돌아오는지 검사합니다.
• 스크린 리더가 이름·역할·상태·오류를 이해할 수 있는지 확인합니다.
• 확대, 긴 한국어 문구, 동적 글자 크기에서 잘림과 겹침을 점검합니다.
• 자동 검사 뒤 실제 보조기술과 사용자 관찰을 이어갑니다.

디자인 단계에서는 주석에 성공 기준을 적고, 개발 단계에서는 해당 기준을 테스트 항목으로 옮겨야 합니다. AI가 만든 화면에 ‘접근성 고려’라는 라벨만 붙이는 것은 검증이 아닙니다.

도입 전 2주 파일럿 체크리스트

첫 주에는 위험이 낮은 내부 화면 하나를 골라 탐색과 대량 정리만 맡깁니다. 기존 방식과 비교할 때 시간 절감 수치만 보지 말고, 잘못된 컴포넌트 사용 건수, 사람이 되돌린 변경, 접근성 결함, 코드 재작업을 기록합니다. 둘째 주에는 디자인 시스템 담당자와 개발자가 함께 코드-캔버스 왕복을 한 번 수행하고 변경 이력을 확인합니다.

• [ ] 베타 대상 좌석과 데이터 취급 정책을 확인했다.
• [ ] 사용할 라이브러리와 금지할 실험 자산을 분리했다.
• [ ] 생성 결과의 검토자와 최종 승인자를 지정했다.
• [ ] 접근성 성공 기준을 디자인 주석과 QA 항목에 연결했다.
• [ ] 코드 반영은 별도 브랜치와 리뷰를 거치게 했다.
• [ ] 기능·요금 변경에 대비한 수동 대체 절차를 남겼다.

도구 도입과 함께 웹 경험의 컴포넌트 구조를 정리해야 한다면 POEMORA 웹 서비스처럼 디자인과 구현을 한 흐름에서 검토하는 접근이 효율적입니다. 중요한 것은 에이전트를 많이 쓰는지가 아니라, 팀의 판단과 시스템 변경이 추적 가능한가입니다.

지금 결정할 것과 보류할 것

지금 결정할 수 있는 것은 파일럿 범위, 승인 역할, 디자인 시스템 정비 순서, 접근성 검증 절차입니다. 반면 전사 좌석 비용, 정식 기능 범위, 검색·맞춤화 능력은 일반 제공 조건이 확정될 때까지 보류하는 편이 안전합니다.

Figma 에이전트는 초안을 늘리고 반복 편집을 줄일 가능성을 보여줍니다. 그러나 제품 품질은 생성량이 아니라 올바른 문제 정의, 승인된 시스템 사용, 실제 사용자 여정 검증으로 결정됩니다. 한국 제품팀이 먼저 자동화해야 할 것은 화면 생산보다 검토 근거와 변경 이력입니다.