Figma Config 2026은 캔버스를 제품 제작 환경으로 바꾸려 합니다

Figma의 Config 2026 발표를 신기능 목록으로만 읽으면 Code Layers, Figma Motion, 셰이더, 생성형 플러그인, Weave가 서로 다른 방향처럼 보입니다. Figma가 공식 블로그에서 반복해서 말하는 문장은 따로 있습니다. 더 표현력 있는 캔버스, 그리고 캔버스 위에서 코드와 움직임을 함께 다루는 환경입니다.

이 변화의 핵심은 “디자이너가 코드를 쓰게 된다”가 아닙니다. 디자인 파일의 지위가 바뀐다는 데 있습니다. 예전 파일은 결과물을 설명하고 전달하는 문서에 가까웠다면, 이제 파일은 실제 동작을 실험하고 팀의 결정을 검증하는 작업장이 되려 합니다.

기능보다 먼저 봐야 할 것은 캔버스의 경계입니다

디자인 도구는 오랫동안 정적 화면을 만드는 방식에 최적화되어 있었습니다. 화면은 프레임과 레이어로 구성되고, 개발자는 그 화면을 다시 제품 코드로 옮겼습니다. 프로토타입은 간극을 줄였지만, 여전히 실제 제품의 구조와는 다른 별도의 표현이었습니다.

Config 2026의 발표는 이 경계를 여러 방향에서 얇게 만듭니다. Code Layers는 캔버스 안에서 코드로 만든 결과를 다루는 방향을 제시하고, Figma Motion은 같은 파일 안에 타임라인을 가져옵니다. Weave와 생성형 플러그인은 캔버스가 단순한 도형 편집기를 넘어 계산과 생성의 환경이 될 수 있음을 보여줍니다.

다만 이것을 프로덕션 코드와 디자인 파일이 자동으로 양방향 동기화된다는 뜻으로 읽어서는 안 됩니다. 발표된 방향과 모든 사용자에게 제공되는 기능, 실제 배포 가능한 코드 사이에는 여전히 거리가 있습니다. 이 구분을 지키는 것이 이번 발표를 정확하게 읽는 첫 번째 조건입니다.

Code Layers가 줄이는 것은 번역 비용입니다

디자인과 코드의 문제는 어느 한쪽이 일을 못해서 생긴 것이 아닙니다. 두 환경이 서로 다른 방식으로 같은 의도를 표현하기 때문에 생깁니다. 디자이너는 화면의 관계와 우선순위를 보고, 개발자는 상태·데이터·성능·유지보수의 구조를 봅니다.

Code Layers는 이 둘을 하나로 합친다기보다 번역을 시작하는 위치를 캔버스 쪽으로 당깁니다. 아이디어를 더 빨리 작동하는 형태로 만들어 보고, 그 결과를 다시 디자인 판단에 사용할 수 있게 하는 것입니다. 이는 특히 정적인 목업만으로 판단하기 어려운 복잡한 상태, 인터랙션, 반응형 레이아웃에서 유용할 수 있습니다.

하지만 실행되는 결과물이 있다고 해서 제품이 완성된 것은 아닙니다. 접근성, 실제 데이터, 오류 상태, 보안, 로딩, 현지화, 유지보수는 여전히 별도의 검토가 필요합니다. 작동하는 데모와 운영 가능한 제품을 같은 말로 부르면 핸드오프 문제를 해결하는 대신 다른 오해를 만듭니다.

Motion은 프로토타입의 장식이 아니라 시간의 명세가 됩니다

Figma가 별도로 소개한 Figma Motion의 공식 설명은 “캔버스에 타임라인을 가져온다”는 방향에 가깝습니다. 컴포넌트와 변수, 팀의 작업이 있는 같은 파일에서 움직임을 다루면 모션은 나중에 붙이는 효과가 아니라 처음부터 설계해야 하는 상태가 됩니다.

이것은 디자인 시스템에 새로운 질문을 추가합니다. 버튼이 눌렸다는 사실을 어떤 속도로 보여줄 것인가. 카드가 목록에 추가될 때 위치 변화는 어떻게 설명할 것인가. 로딩과 완료 사이의 관계를 사용자가 놓치지 않게 하려면 얼마만큼의 시간이 필요한가. 색과 간격을 토큰으로 관리하듯, 모션도 목적·시간·이징·감소 모드를 함께 관리해야 합니다.

툴이 쉬워지는 만큼 과잉도 쉬워집니다. 모든 요소가 움직이는 화면은 처음에는 풍부해 보이지만, 반복 사용하는 제품에서는 집중력을 빼앗습니다. prefers-reduced-motion을 고려하지 않거나 정보가 애니메이션에만 의존한다면 파일 안에서 잘 보이는 모션이 실제 사용자에게는 장애가 됩니다.

AI는 파일을 깨끗하게 만들지 않습니다

생성형 플러그인과 AI 기능이 캔버스에 들어오면 디자인 파일의 위생이 더 중요해집니다. 레이어 이름이 제각각이고 컴포넌트의 상태가 정리되지 않았으며 어떤 결정이 확정안인지 실험안인지 구분되지 않는 파일은 사람에게도 어렵습니다. AI에게는 더 어렵습니다.

AI가 빠르게 평균적인 결과를 만드는 환경에서는 사람이 만들어야 할 차이가 “얼마나 많이 생성했는가”가 아니라 “무엇을 버리고 왜 선택했는가”에 남습니다. 컴포넌트 구조, 토큰, 콘텐츠 규칙, 접근성 기준, 금지 사례가 파일과 문서에 연결되어 있어야 생성 결과가 제품의 맥락 안에 머뭅니다.

좋은 점

Figma는 디자인과 구현 사이의 오래된 번역 비용을 줄이는 방향을 일관되게 보여줍니다. 움직임과 코드가 같은 작업공간에서 검토되면 디자이너와 개발자가 결과물을 더 일찍 함께 볼 수 있고, 말로만 설명하던 의도를 실제 동작으로 확인할 기회도 늘어납니다.

한계

캔버스가 더 많은 일을 맡는다고 해서 제품의 복잡성이 사라지지는 않습니다. 실행되는 데모, 편집 가능한 코드, 운영 가능한 제품은 서로 다릅니다. 또한 새로운 기능의 공개 범위가 계속 바뀌는 단계에서는 팀의 프로세스를 특정 베타 기능에 너무 빨리 걸기 어렵습니다.

남는 긴장

하나의 파일이 디자인, 모션, 코드, 생성까지 담으면 협업은 가까워지지만 책임의 경계는 흐려집니다. 누가 최종 품질을 판단하고, 어떤 결과를 제품의 기준으로 채택하며, 생성 결과의 실패를 누가 검수할 것인지가 더 중요해집니다. 도구의 통합은 역할의 통합이 아닙니다.

질문

• 우리 Figma 파일은 사람뿐 아니라 AI와 개발자도 읽을 수 있게 구조화되어 있나요?
• 작동하는 프로토타입과 프로덕션 코드 사이에서 아직 검증되지 않은 것은 무엇인가요?
• 모션을 디자인 시스템의 토큰·접근성 규칙과 함께 관리하고 있나요?
• 캔버스에 넣지 않아야 할 결정과 문서는 무엇인가요?

Config 2026은 Figma에 기능이 많이 추가됐다는 소식보다, 디자인 파일을 무엇으로 볼 것인지에 대한 제안에 가깝습니다. 파일이 작업장이 될수록 가장 중요한 능력은 더 빠른 제작이 아니라, 그 안에서 무엇이 사실이고 무엇이 실험인지 구분하는 판단입니다.