디자이너와 같은 Figma 파일에서 새 화면을 보고 있다. 예전에는 그 안에 주로 frame, 버튼, 텍스트, 컴포넌트, 프로토타입 연결이 있었다. 화면이 어떻게 보이는지, 누르면 어디로 가는지를 설명하는 재료였다.

code layer가 바꾸는 것은 이 일상적인 장면이다. 어떤 상호작용 자체가 실제로 실행되는 UI code로 Figma 캔버스 위에 놓인다. 디자이너는 그것을 복제하고, 다른 버전을 만들고, 여러 상호작용 방향을 비교할 수 있다. 엔지니어나 제품 관리자도 같은 캔버스에서 “실제로 움직이면 어떤 느낌인지” 볼 수 있다.

디자인 파일, 인터랙티브 프로토타입, 애니메이션 실험, 엔지니어링 실험이 서로 다른 도구에 흩어져 있었다는 점을 생각하면 편리하다. 하지만 편리함은 새로운 질문도 만든다. 캔버스 위의 것이 이미 실행되고 제품처럼 보일 때, 이것이 아직 탐색인지 아니면 엔지니어링에 넘겨도 되는 상태인지 누가 판단할까?

Figma는 2026년 Config에서 code layers, Figma Motion, shader fills/effects, generative plugins, Weave tools, 더 많은 맥락을 읽는 Figma agent를 발표했다. code layers는 실행 가능하거나 편집 가능한 코드를 캔버스 위의 디자인 재료처럼 다루는 기능이다. shader fills/effects는 코드로 실시간 계산되는 시각 효과나 재질을 뜻한다. Weave tools는 AI 이미지 처리 과정을 재사용 가능한 도구로 묶는다. 여러 기술 매체도 Figma가 디자인, 코드, 애니메이션, AI 워크플로를 하나의 협업 캔버스로 끌어들이고 있다는 점에 주목했다.

이 미니 클래스는 새 기능을 지금 바로 도입해야 하는지 판단하려는 글이 아니다. 필요한 것은 인계 기준이다. “탐색 캔버스”와 “전달 명세”를 분리하는 것이다.

먼저 구분하기: 캔버스는 자유로워도 되지만, 전달은 모호하면 안 된다

Figma는 code layers를 코드를 새로운 디자인 재료로 다루는 방식이라고 설명한다. 핵심은 “Figma가 CSS를 조금 내보내 준다”가 아니다. 코드가 이미지, 컴포넌트, 텍스트처럼 캔버스 위에서 논의하고, 복제하고, 비교할 수 있는 재료가 된다는 점이다. 디자인 레이어를 인터랙티브한 code layer로 바꾸고, 여러 방향을 복제해 비교하고, 코드 속 흐름을 다시 편집 가능한 디자인 레이어로 가져올 수 있다. Motion은 타임라인, 키프레임, 내보내기 형식을 Figma 안에 둔다. shader와 generative plugins는 프롬프트로 시각 효과나 맞춤 도구를 만들게 해 준다.

이 기능들은 탐색에 적합하다. 팀은 “이렇게 하면 어떻게 보일까”를 더 빨리 확인할 수 있다. 디자이너, 제품 관리자, 엔지니어는 모든 세부사항이 확정될 때까지 기다리지 않고 상호작용 방향을 논의할 수 있다.

하지만 탐색 단계가 완성품처럼 보일수록 인계 위험은 과소평가되기 쉽다. 캔버스 위 효과가 동작한다고 해서 다음이 보장되는 것은 아니다.

  • 그 코드가 제품 아키텍처에 맞는다.
  • 애니메이션이 모든 기기와 브라우저에서 안정적이다.
  • AI가 만든 플러그인이나 효과를 팀이 유지보수할 수 있다.
  • 엔지니어가 어느 부분이 디자인 의도이고 어느 부분이 임시 실험인지 안다.

그래서 공식 인계에는 명확한 검수 항목이 필요하다.

한 장의 표로 탐색 캔버스와 전달 명세를 나누기

완성도 높아 보이는 Figma 프로토타입을 보았다면, 곧바로 “엔지니어에게 넘길 수 있을까”라고 묻기 전에 아래 표로 분류해 보자.

검수 항목탐색 캔버스에서 허용되는 것전달 명세에서 반드시 보완할 것
코드code layer로 상호작용 방향을 비교하고 가능성을 확인한다어떤 코드는 프로토타입용이고 어떤 로직은 정식 엔지니어링에서 다시 작성하거나 소유해야 하는지 밝힌다
애니메이션Motion으로 리듬, 전환, 3D 변화, 분위기를 먼저 보여 준다시간, 트리거 조건, 접근성 대안, 성능 제한을 적는다
AI 생성 콘텐츠agent가 효과, 플러그인, 여러 버전 생성을 돕는다AI 생성 부분을 표시하고 유지보수성, 라이선스, 브랜드 일관성을 검토할 담당자를 정한다
외부 도구 연결Notion, Slack, GitHub 등에서 맥락을 가져와 시험한다데이터 출처, 권한 경계, 자동으로 읽거나 가져오면 안 되는 문서를 확인한다
최종 책임팀이 함께 댓글을 달고 방향을 시험한다전달 범위, 변경 기록, 반려 조건을 결정할 책임자를 지정한다

이 표의 목적은 절차를 느리게 만드는 것이 아니다. “완성되어 보인다”를 “전달 가능하다”로 오해하지 않게 하려는 것이다.

광고

도입한다면 먼저 격리된 테스트 구역으로 다루기

비교적 안전한 방법은 이런 새 캔버스 기능을 “격리된 테스트 환경”으로 보는 것이다. 그 안에서 상호작용, 애니메이션, AI 생성 효과를 실험할 수 있다. 하지만 그것이 정식 제품 코드나 디자인 시스템을 곧바로 대체하게 해서는 안 된다.

작은 팀은 세 가지 규칙부터 둘 수 있다.

첫째, 모든 code layer를 “탐색”, “엔지니어링에서 재작성”, “참고용” 중 하나로 표시한다. 코드를 던져 주고 엔지니어가 무엇을 쓸 수 있는지 추측하게 만들지 않는다.

둘째, 모든 Motion 또는 shader 효과에는 “실패하면 어떻게 할 것인가”를 한 줄 붙인다. 성능이 낮은 기기에서는 꺼야 하는가, 스크린 리더에는 다른 설명이 필요한가, 애니메이션이 멈춰도 페이지를 조작할 수 있는가를 확인한다.

셋째, AI가 만든 플러그인, 효과, 소재에는 사람이 검수할 책임자를 둔다. 브랜드, 라이선스, 유지보수 비용, 엔지니어링 인계가 괜찮은지 판단할 수 있는 사람이어야 한다.

서둘러 전환하지 말아야 할 때

  • 팀에 명확한 인계 템플릿이 없다면 새 도구보다 먼저 명세 항목을 보완한다.
  • 프로토타입 코드를 정식 제품에 넣어도 되는지 디자인과 엔지니어링의 합의가 없다면 책임을 먼저 나눈다.
  • 제품에 높은 접근성, 성능, 보안 요구사항이 있다면 애니메이션, shader, 외부 도구 연결을 먼저 제한 테스트한다.
  • 디자인 시스템이 이미 혼란스럽다면 AI는 표준을 정리해 주는 것이 아니라 더 많은 변형을 더 빨리 만들 뿐이다.

이 미니 클래스의 결론

Figma가 코드, 애니메이션, shader, 플러그인, AI agent를 같은 캔버스에 넣은 것은 디자인 협업에 큰 변화다. 초기 탐색을 더 빠르게 하고, 제품 관리자, 디자이너, 엔지니어가 더 이른 시점에 같은 방향을 보게 만들 수 있다.

하지만 인계 품질은 자동으로 좋아지지 않는다. 시간을 정말 아끼는 것은 캔버스가 완성품처럼 보이는 것이 아니다. 팀이 무엇은 탐색이고, 무엇은 전달 가능하며, 무엇은 다시 작성해야 하고, 무엇은 사람이 확인해야 하는지 명확히 말할 수 있는 것이다.

Figma의 이번 기능들을 시험해 보려면 “도구를 바꿔야 할까”라고 묻기 전에 이렇게 묻는 편이 낫다. 우리는 같은 캔버스에서 탐색하면서도 모호하지 않은 전달 명세를 남길 수 있을까?

생활 4컷 만화

4컷 만화: 디자인과 엔지니어링 팀이 공유 캔버스에서 상호작용과 AI 효과를 탐색한 뒤, 전달 명세, 다시 작성할 항목, 인간 검수 항목으로 나눈다.

  1. 공유 캔버스는 상호작용, 애니메이션, AI 효과를 완성품에 더 가깝게 보이게 한다.
  2. 팀은 데모를 출시 가능한 것으로 여기기 전에 탐색과 전달을 나눈다.
  3. 각 효과는 코드, 모션, 권한, 책임자, 실패 시 대안이라는 검수 항목으로 돌아간다.
  4. 엔지니어에게 전달되는 것은 숨은 전제가 많은 예쁜 프로토타입이 아니라 정리된 명세 패키지다.

AI 정리 카드

이 글의 상황에 맞춰 AI에게 정리하게 하기

자신의 AI 채팅 도구에 붙여 넣으면 이 미니 클래스를 개인용 체크리스트로 바꿀 수 있습니다. BMC는 사용자가 AI에 붙여 넣은 내용을 볼 수 없습니다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료