Figma는 다음에 무엇을 할 것인가?

• 디자인을 멀티플레이어 협업으로 만든 문제를 해결하며 지난 10년간 가장 중요한 제품 도구로 자리 잡았으나, 무게 중심이 캔버스에서 코드로 이동하는 시점에 캔버스에 묶인 전략적 상상력이라는 문제를 안고 있음
• Figma는 디자인 파일을 브라우저 기반 공유 공간으로 바꿔 협업·비평·탐색·핸드오프를 한 화면에서 가능하게 하며 Sketch를 빠르게 구식으로 만들었음
• 캔버스는 시각적 의도와 동작하는 소프트웨어 사이의 번역 문제를 다루는 추상화이지만, AI가 그 간극을 좁히면서 디자인 시스템·API·패턴을 직접 코드로 해석하는 실행 시스템으로 전환 중
• AI로 실행 비용이 저렴해지면서 한계 요인은 "인터페이스를 만들 수 있는가"가 아니라 "올바른 인터페이스를 조직이 신뢰할 방식으로 만들 수 있는가" 라는 조정(coordination) 문제로 이동
• 무게 중심이 다시 이동하는 지금, Figma가 캔버스를 확장해 다음 시대를 담으려는 시도는 혁신가의 딜레마에 해당하며, 진실로 향하는 협업 인터페이스로 전환할지가 핵심 (incumbent trap)

Figma가 처음 이긴 방식

• Figma의 첫 성취는 기술적인 것으로, 브라우저를 디자인에서 누구도 가능하다고 생각하지 못한 수준으로 중요하게 만듦
  • 크로스 플랫폼 접근성, 성능, 멀티플레이어가 모두 중요하게 작용
• 더 깊은 변화는 문화적 차원임
  • Figma 이전에는 협업이 로컬 파일, 레드라인, PDF, 그리고 "이게 맞는 버전인가"를 묻는 회의로 파편화됨
  • Figma는 그 거리를 붕괴시켜, 단순히 더 나은 캔버스가 아니라 더 나은 조정 모델(coordination model) 을 제공
• 다만 추상화는 여전히 추상화이며, 캔버스는 제품이 아니라 표현(representation) 일 뿐이고 실제 제품은 코드에 존재
  • 캔버스는 구현의 비용이 커지기 전에 사고를 돕는 도구였으나, 시각적 의도와 동작 소프트웨어 사이에 큰 간극이 있는 세계에 의존
  • AI가 그 거리를 붕괴시키는 중

캔버스는 번역 문제에 대한 답

• 캔버스 모델은 명확한 역할 분담 위에 성립
  • 디자이너는 의도를 표현, 엔지니어는 의도를 코드로 번역, 프로덕트 매니저는 우선순위와 범위를 조율
  • 상상한 것을 이용해 실제로 출시할 것을 만듦
• 이 모델은 곧 사라지지 않으며, 많은 조직이 앞으로도 수년간 이 방식으로 일할 가능성 있음
• 그러나 진행 방향은 바뀜
  • Design-to-code는 더 빨라졌지만, 이는 기존 작업 방식(핸드오프·번역)을 그저 더 빠르게 압축한 것에 불과
  • 진짜 다른 점은 구조화된 디자인·제품 맥락, 컴포넌트 코드, 규칙이 직접 코드화된 동작 인터페이스로 해석된다는 것
  • 프롬프트가 디자인 시스템·API·패턴·엔지니어링 제약에 접근하면 더 이상 백지에서 시작할 필요 없음
• 이때 디자인은 AI 실행 시스템이 사용하는 맥락(context) 이 됨
  • 팀은 여전히 시각적 비교·비평, 비즈니스 결정을 위한 공유 공간이 필요
  • 터미널 창이나 IDE는 다수 이해관계자가 참여할 장소가 아님
  • 그럼에도 이것이 캔버스를 중심으로 만들지는 않음

다시 캔버스로

• Figma의 최근 움직임은 현재 강점 위에 구축되어 이해 가능함
  • 더 많은 작업이 Figma에서 일어나고, 더 많은 산출물이 Figma에서 나오며, 워크플로가 Figma로 돌아오고, 제품 개발이 Figma 생태계 안에서 이뤄져야 한다는 방향
• 가장 단순화하면 전략은 "모든 것을 캔버스로, 우리 캔버스로 되돌리기" 로 보임
  • 그러나 다음 시대는 그 축으로 조직되지 않음
• "code-to-canvas" 가 이를 드러냄 — 실제 결과물을 만든 뒤 이를 편집 가능한 프레임으로 Figma에 되가져오는 방식
  • 단기 협업 문제는 해결할 수 있으나 방향성 측면에서 이상하며, 미래에 대해서는 잘못됨
  • Figma는 협업이 어떻게 작동하는지 아는 자기 방으로 사용자를 되돌리는 데 더 신경 쓰고, 그것이 미래에 옳은 협업 모델인지에는 덜 신경 씀

캔버스는 진실의 원천이 아님

• Figma가 현실을 반영하는 협업 인터페이스, 즉 렌즈(lens) 로서 더 설득력 있는 미래로 향할 가능성도 있음
  • 동작하는 시스템을 점검하고, 변형을 비교하며, 실제 대상에 주석을 달고, 디자인 시스템의 드리프트를 확인하며, 방향을 잡고 통제하는 장소가 될 수 있음
• 다만 이는 캔버스가 더 이상 중심이 아님을 받아들이는 것을 의미
  • 캔버스가 중요하게 남으려면 오직 진실로 향하는 인터페이스로서만 가능
  • 여기서 진실은 코드, 런타임, 실제로 존재하고 실제로 출시되는 것
• Figma의 위험은 모든 것을 옛 모델을 거치게 만들어 중심을 유지하려는 시도이며, 이는 incumbent trap(기존 강자의 함정) 에 해당
  • 처음 지배력을 만든 것을 바라보며 그것만 개선하는 행위이고, 경쟁의 기준이 바뀌는 순간까지만 옳음
  • Figma는 무게 중심이 바뀔 수 있음을 깨달아 Sketch를 이겼으나, 이제 그 중심이 다시 바뀌며 혁신가의 딜레마의 반대편에 서 있음

실행은 저렴하고, 조정은 그렇지 않음

• AI는 실행을 더 저렴하게 만듦 — 무료는 아니지만 실무자 관점에서는 그렇게 느껴질 수 있음
  • AI가 화면을 스캐폴딩하고, 컴포넌트를 사용하며, 연결하고, 리팩터링하며, 변형을 제공해 기존 병목을 바꾸는 속도로 생성
• 따라서 한계 요인은 "인터페이스를 만들 수 있는가"가 아니라 "올바른 기준·사용자·조직 신뢰 하에서 올바른 인터페이스를 만들 수 있는가" 임
  • AI 지원을 통한 조정은 캔버스 추상화 속 협업과 동일하지 않으며, 구조화되고 순위가 매겨진 맥락이 필요
• 판단이 필요한 질문들이 존재
  • 어떤 컴포넌트가 승인되었는가, 어떤 패턴이 폐기되었는가
  • 문서·코드·Figma가 서로 다를 때 어떤 구현이 권위 있는가
  • 어떤 접근성 규칙이 적용되는가, 어떤 규제 제약이 중요한가, 어떤 엔지니어링 표준이 타협 불가인가
  • 이는 캔버스 문제가 아니라 인프라 문제
• 이 세계에서 디자인 시스템은 더욱 중요
  • 컴포넌트 라이브러리나 자산 저장소, 사람이 수동 참조하는 문서가 아니라, 조직이 어떻게 만드는지를 AI 시스템에 알려주는 실행 가능한 지능(executable intelligence)
  • 캔버스는 배열하고 비평을 유도할 수 있으나, 제품 전달의 통제 계층과 깊이 연결되지 않으면 실제는 다른 곳에 있고 캔버스는 예쁜 그림에 그칠 위험 (전략적 문제)

Figma가 믿는 것으로 보이는 것

• 외부에서 볼 때 Figma는 캔버스를 확장해 다음 시대를 담을 수 있다고 믿는 것으로 보임
  • 이는 외부의 해석일 수 있고, Figma에는 변화를 이해할 유인을 가진 똑똑한 사람들이 많으며, 상업적으로 영리한 결정일 수도 있음
  • 다만 그것이 다음 시대 작업에 옳은 제품 모델임을 뜻하지는 않음
• 제품 전략은 태도를 드러내며, Figma의 태도는 캔버스로의 회귀에 집중된 것으로 보임
  • 생성된 작업을 되가져오고, 코드 산출물을 되가져오고, 개발자를 Figma로 데려오고, AI를 캔버스로 데려오기
  • 조직의 더 많은 부분을 Figma가 소유한 장소로 넣기
• 이는 반드시 어리석은 것은 아님
  • 기업은 역사적으로 통합(consolidation) 을 선호했고, 사람들은 Figma에 익숙하며, 시장 지배력에서 오는 중력이 존재
  • Figma는 유용한 기능을 계속 추가할 수 있으나, 그 기능들이 동작하는 산출물과 조직적 맥락이 디자인 파일보다 더 중요해진 세계에 적응하도록 돕는지가 관건
  • Figma의 베팅은 "그렇다, 그 모든 것이 결국 Figma로 돌아올 것이기 때문"이며, 이는 캔버스가 핵심이라는 베팅

우리가 일하는 공간이 바뀐다면

• 다음 지배적 제품 워크스페이스는 AI 기능이 더 붙은 Figma처럼 보이지 않을 것이며, 전통적 디자인 도구처럼 보이지도 않을 것
  • 더 가능성 있는 형태는 공간적 협업이 가미된 IDE, 또는 라이브 소프트웨어를 직접 편집·점검·배포 가능한 브라우저 기반 제품 환경
  • 디자인 시스템·리포지토리·문서·분석·제품 관리 도구를 가로지르는 AI 오케스트레이션 계층이 필요
  • 캔버스, 코드 에디터, 스테이징 환경, 거버넌스 및 규칙 시스템의 통합 형태
• 이런 형태는 처음에는 나빠 보일 것
  • 올바른 것의 초기 버전은 과거의 성숙한 버전보다 더 나빠 보이며, 어색하고 불완전하며 무시하기 쉬움
  • Figma는 이를 누구보다 잘 이해해야 함 — 지난 라운드를 이긴 이유가 더 나은 디자인 도구가 아니라 작업을 위한 다른 환경이었기 때문
• 캔버스는 필수로 남을 수 있으나 추상화로서의 캔버스는 그렇지 않음
  • 캔버스는 현실을 평면화하는 곳이 아니라 현실을 논의하는 곳이어야 함 (어렵고 흥미로운 문제)

Figma는 다음에 무엇을 하는가

• 세 가지 경로가 존재

• 방어적 경로

  • 캔버스를 계속 확장해 점점 더 많은 작업이 Figma 안에서 일어나게 구축
  • 유용한 기능과 강한 매출을 낼 수 있고, 지배적 위치에서 더 끈끈하고 깊이 자리 잡을 수 있음

• 전환적 경로

  • 캔버스를 더 코드 인식적(code-aware) 이고 상호작용적으로 만들며, 더 나은 생성·워크플로·임포트·익스포트 제공
  • 현재 Figma의 움직임이 있는 지점으로, 매우 유용하지만 여전히 캔버스를 제품 환경의 축으로 조직함

• 피벗 경로

  • 캔버스와 Figma가 진실의 중심이 아님을 받아들이고, 그 진실로 향하는 최고의 협업 인터페이스 중 하나가 되도록 구축
  • 코드·제품 맥락·디자인 시스템·라이브 동작을 실제 작업으로 취급하고, 캔버스는 이미 살아 있는 시스템을 시각적으로 추론하는 하나의 뷰(view)로 삼음
  • Figma가 이 피벗을 원하는지는 불분명
• 전략적 변화는 미래를 내다보는 것이라기보다 현재 사업을 성립시키는 가정을 포기하는 것에 관한 문제
  • 멀티플레이어 디자인은 사라지지 않고 여전히 중요
  • 관건은 코드에 훨씬 가깝게 생성·수정·검토·출시할 수 있게 될 때 그 작업이 어디에 존재할 것인가
  • Figma는 지난번 무게 중심의 변화를 이해했고, 이제 그 중심이 다시 이동하는 중