2026년 6월 Config 행사에서 디자인 도구 Figma는 “코드 레이어"를 발표했다. 디자인 레이어를 한 번의 클릭(또는 한 문장의 지시)으로 상호작용하는 코드로 바꿔 캔버스에 바로 놓을 수 있다. 여러 개로 복제해 상호작용 방향을 나란히 비교할 수도 있고, 편집할 수 있는 디자인 레이어로 되돌린 뒤 한 번의 클릭으로 코드에 반영할 수도 있다. 함께 나온 Figma Motion은 애니메이션 타임라인과 키프레임을 Figma 안에 두고, 개발자 모드에서 CSS, JSON, React 코드로 바로 복사할 수 있게 한다. 공식 블로그는 애니메이션 프레임을 MCP를 통해 코딩 에이전트에게 바로 넘겨 구현하게 할 수 있다고도 적었다. MCP는 AI 도구끼리 연결하는 규약이고, 코딩 에이전트는 코드를 읽고 파일을 고치는 AI 도우미다.

이제 디자인, 애니메이션, 코드가 마침내 한 캔버스에 모였다. 하지만 새로운 문제도 생긴다. 캔버스 위의 것이 이미 돌아가고 제품처럼 보이면 그대로 만들어지기 쉽다. 중간에 무엇이든 곧이곧대로 받아들이는 코딩 에이전트가 있다면 더욱 그렇다.

그래서 인계할 때 디자이너는 한 가지를 분명히 표시해야 한다. 무엇이 확정된 디자인 의도이고, 무엇이 탐색 중의 실험인지. 어떤 코드를 그대로 쓰고 어떤 것을 다시 쓸지는 엔지니어가 판단한다. 프로토타입이 돌아가느냐로 정할 일이 아니다.

프로토타입이 돌아간다고 그대로 만들어도 되는 것은 아니다

Figma 공식 설명은 코드를 탐색하고 반복하기 위한 새로운 디자인 “재료"로 표현할 뿐, 캔버스 위의 코드를 그대로 출시해도 된다고 말하지 않는다. 캔버스에서 효과가 움직인다고 코드가 제품 구조에 맞는 것도, 애니메이션이 모든 기기와 브라우저에서 매끄러운 것도 아니다. AI가 만든 플러그인이나 효과를 누군가 유지보수할 수 있다는 보장도, 엔지니어가 어떤 세부가 의도적이고 어떤 것이 가볍게 시도한 것인지 안다는 보장도 없다.

공식 설명은 상호작용하는 셰이더 효과의 성능을 아직 조정 중이라고도 밝혔다. 캔버스에서 매끄럽다고 중급 휴대폰에서도 매끄러운 것은 아니다.

인계할 때 의도와 실험을 하나씩 표시한다

코드: 이 코드가 상호작용 방향을 비교하려던 것인지, 엔지니어가 그대로 쓰기를 바라는 것인지 표시한다. 기본적으로는 프로토타입으로 다루고, 다시 쓸지 이어받을지는 엔지니어가 정한다.

애니메이션: 시간, 시작 조건, 움직임에 민감한 사용자에게 보여 줄 대안(움직임 줄이기 설정 등)을 적는다. 성능 제약은 인계할 때 분명히 전한다.

AI가 만든 내용: 어떤 효과, 플러그인, 버전을 AI가 만들었는지 표시하고, 담당자가 유지보수 가능성, 라이선스, 브랜드 일관성을 확인한다.

외부 데이터: Figma의 AI 에이전트는 Notion, Slack, GitHub 같은 도구에 연결해 맥락을 가져올 수 있다. 어떤 문서는 읽어도 되고 어떤 것은 디자인에 자동으로 끌어오면 안 되는지 확인한다.

최종 책임: 인계 범위, 변경 기록, 반려 조건을 정할 담당자를 한 명 정한다.

애니메이션을 코딩 에이전트에게 넘기기 전에도 이번에 무엇을 하고 무엇을 하지 않을지 적어 둔다. 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다를 참고하자.

광고

탐색 영역과 인계 영역을 나눈다

Figma 파일 안에서 자유롭게 탐색하는 페이지와 인계를 준비하는 페이지를 나눈다. 탐색 영역은 마음껏 어지럽히고 여러 버전을 복제해도 된다. 인계 영역에는 의도를 표시하고 확인을 마친 내용만 둔다. 엔지니어는 인계 영역에서만 재료를 가져가고, 탐색 영역의 것은 옮겨서 표시한 뒤에야 인정한다.

같은 방식은 AI로 만드는 시각 소재에도 적용된다. 생성 전에 용도와 제약을 확인할 수 있는 조건으로 적어 둔다. 디자인 AI는 말한 대로 움직이지만, “무엇을 만들지"는 여전히 직접 적어 줘야 한다를 참고하자.

기능은 아직 대기 명단 단계다

코드 레이어는 7월부터 대기자 명단 방식으로 제공이 시작될 예정이라, 실제로 써 보면 발표 때와 다를 수 있다. 이 글이 다루는 것은 인계의 원칙이지 기능 사용법이 아니다. 구체적인 설정은 Figma의 최신 설명을 따른다.

또 표시는 의도를 분명하게 할 뿐, 구현이 맞는다는 보장은 하지 않는다. 애니메이션, 접근성, 성능은 결국 실제 기기에서 시험해야 한다.

AI 정리 카드

우리 디자이너들이 Figma 캔버스에서 코드 레이어, 애니메이션, AI 효과로 프로토타입을 만들기 시작했다. 엔지니어에게 넘길 때의 확인 방식을 먼저 정하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/figma-canvas-code-handoff-review/
글의 관점은 이렇다. 프로토타입이 완성품처럼 보일수록 그대로 만들어지기 쉽고, 코딩 에이전트에게 넘길 때는 특히 그렇다. 인계할 때 무엇이 확정된 디자인 의도이고 무엇이 탐색 중의 실험인지 분명히 표시하고, 어떤 코드를 그대로 쓸지는 엔지니어가 판단한다.

먼저 나에게 물어 달라. 이 프로토타입의 용도(탐색, 내부 결정, 엔지니어 인계), 어떤 새 기능을 썼는지, 누가 구현하는지.
그다음:
1. 인계 목록을 만들 것. 코드, 애니메이션, AI가 만든 내용, 외부 데이터, 최종 책임마다 무엇을 표시할지;
2. 엔지니어가 "디자인 의도"와 "탐색 실험"을 한눈에 구분할 수 있는 표시 방식을 만들 것;
3. 누가 확인할지 적을 것. 엔지니어링, 디자인 시스템, 접근성, 브랜드와 각자가 볼 것;
4. 애니메이션을 인계할 때 붙일 정보를 적을 것. 시간, 시작 조건, 움직임 줄이기 대안, 성능 제약.
어떤 코드를 바로 출시할 수 있는지는 판단하지 말고, 엔지니어 확인이 필요한 곳만 적을 것.
광고

Share

이 미니 클래스 공유

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

참고 자료