Figma의 다음 싸움은 캔버스가 아니라 코드예요

Figma의 다음 싸움은 캔버스가 아니라 코드예요

AI 뉴스 썸네일

Figma는 디자인 파일을 혼자 여는 문서가 아니라, 팀이 동시에 보는 작업 공간으로 바꿨어요. 그런데 제품 개발의 무게중심이 코드와 실행 환경에 가까워지면, 같은 캔버스 전략이 계속 통할지는 따져봐야 해요.

728x90

핵심 요약

구분	핵심	왜 볼 만한가요
디자인 도구	Figma는 브라우저 기반 협업으로 Sketch 이후의 표준이 됐어요	디자인 파일을 공유 문서처럼 다루게 만든 변화가 제품 조직의 일하는 방식을 바꿨어요
제품 개발	AI가 디자인과 코드 사이의 번역 비용을 낮추고 있어요	화면을 그린 뒤 개발자에게 넘기는 방식보다, 시스템 맥락을 바로 실행 코드로 연결하는 흐름이 커질 수 있어요
협업 구조	앞으로의 병목은 화면 생성보다 조직의 기준과 신뢰예요	승인된 컴포넌트, 접근성 규칙, 코드 표준, 실제 배포 상태를 누가 기준으로 삼을지의 문제가 남아요

1. Figma의 다음 싸움은 캔버스가 아니라 코드예요

Figma가 이긴 이유는 단순히 더 예쁜 디자인 툴이라서가 아니에요. 브라우저에서 여러 사람이 같은 파일을 보고, 댓글을 달고, 화면 흐름을 함께 고칠 수 있게 만든 점이 컸어요. Robin Cannon의 글은 이 강점이 앞으로는 부담이 될 수 있다고 봐요. 디자인과 실제 제품 사이의 거리가 AI 때문에 줄어들면, 캔버스를 중심에 두는 전략이 예전만큼 자연스럽지 않을 수 있다는 이야기예요. 2

기존 제품 팀에서는 역할이 꽤 뚜렷했어요. 디자이너는 화면과 의도를 만들고, 엔지니어는 그것을 코드로 옮기고, PM은 범위와 우선순위를 조율했어요. 이때 캔버스는 모두가 제품을 상상하고 합의하는 장소였어요. 하지만 AI 도구가 디자인 시스템, 컴포넌트 코드, API, 엔지니어링 규칙을 함께 읽기 시작하면 화면은 더 이상 최종 기준이 아니에요. 코드와 런타임, 실제로 배포된 제품이 더 강한 기준이 돼요. 1

여기서 흥미로운 지점은 design-to-code 자체가 아니에요. 디자인을 코드로 바꾸는 기능은 이미 여러 도구가 시도해 왔고, 대부분은 기존 핸드오프를 빠르게 만드는 쪽에 가까웠어요. 글이 짚는 변화는 조금 달라요. 제품 맥락과 디자인 시스템이 AI 실행 환경에 직접 들어가면, 팀은 빈 캔버스에서 시작하지 않고 이미 승인된 구성요소와 규칙 안에서 인터페이스를 만들 수 있어요. 이때 디자인 시스템은 문서나 컴포넌트 모음이 아니라, AI가 제품을 만들 때 참고하는 실행 가능한 기준에 가까워져요. 2

Figma가 최근 code-to-canvas 같은 흐름을 강화하는 것도 이 맥락에서 볼 수 있어요. 작동하는 결과물을 다시 Figma 안으로 가져와 편집 가능한 프레임처럼 다루려는 방향이에요. 단기적으로는 팀 협업에 도움이 될 수 있어요. 다만 실제 제품의 기준이 코드와 배포 환경에 있다면, 모든 것을 다시 캔버스로 되돌리는 방식은 방향이 어긋날 수 있어요. 팀이 보고 싶은 것은 예쁜 프레임만이 아니라, 실제 사용자가 만질 제품의 상태예요. 1

앞으로 제품 조직의 병목은 "화면을 만들 수 있나"보다 "어떤 기준으로 만들고 믿을 수 있나"에 가까워져요. 어떤 컴포넌트가 승인됐는지, 어떤 패턴이 더 이상 쓰이면 안 되는지, 접근성 규칙과 규제 조건은 어디까지 적용되는지, 코드와 문서와 디자인 파일이 다를 때 무엇을 기준으로 볼지 같은 질문이 남아요. 이건 캔버스만의 문제가 아니에요. 제품 개발 인프라와 거버넌스의 문제예요.

그래서 Figma의 다음 선택지는 꽤 선명해 보여요. 캔버스를 더 강하게 확장해 모든 작업을 Figma로 모으는 길이 있고, 캔버스를 코드와 더 깊게 연결하는 길도 있어요. 더 어려운 길은 캔버스가 진실의 중심이 아니라는 점을 받아들이는 거예요. 코드, 런타임, 디자인 시스템, 분석, 배포 상태를 함께 보는 협업 인터페이스가 된다면 Figma는 다음 단계에서도 의미가 있어요. 반대로 모든 흐름을 기존 캔버스로 되돌리는 데 집중하면, Figma가 Sketch를 넘어섰을 때와 비슷한 변화가 이번에는 Figma 밖에서 일어날 수 있어요. 2

왜 중요한가요

디자인 도구 시장의 이야기는 곧 제품 팀의 업무 방식 이야기예요. AI가 화면 초안을 더 빨리 만들수록, 팀이 시간을 쓰는 곳은 픽셀 배치보다 기준 합의와 검증 쪽으로 옮겨가요. 디자이너에게는 디자인 시스템을 더 실행 가능한 형태로 관리해야 한다는 뜻이에요. 개발자에게는 코드와 디자인 사이의 경계가 흐려질 때, 어떤 규칙을 자동화하고 어떤 판단을 사람이 가져갈지 정해야 한다는 뜻이에요. 2

Figma는 여전히 강한 도구예요. 많은 팀이 이미 Figma 안에서 비평, 회의, 핸드오프, 문서화를 해요. 하지만 다음 제품 워크스페이스가 꼭 전통적인 디자인 파일처럼 생길 필요는 없어요. 라이브 제품, 코드, 디자인 시스템, PM 문서, 접근성 규칙을 한곳에서 다루는 환경이 더 자연스러울 수 있어요. Figma가 그 환경의 중심이 될지, 아니면 그 환경을 바라보는 여러 뷰 중 하나가 될지가 이번 글의 핵심 질문이에요. 1

참고 자료

1. Figma는 다음에 무엇을 할 것인가? — GeekNews
2. What does Figma do next? — Robin Cannon