Figma의 MCP 업데이트가 더 큰 산업 변화를 반영한다

Source: Hacker News

Figma의 새로운 AI 쓰기 접근

이번 주 초에 Figma는 프롬프트에 따라 AI 에이전트가 Figma 캔버스에서 직접 디자인할 수 있는 방법을 소개했습니다. Figma 자체 블로그 게시물에 따르면:

With Figma’s MCP server, agents can now write directly to your Figma files, extending the standards you’ve carefully established over time. Via the use_figma tool, Claude Code, Codex, and other MCP clients can generate and modify design assets that are linked to your design system.

여기서 주목할 점은 Figma가 이미 MCP 도구를 가지고 있었지만 읽기 전용이었다는 것입니다. 실제로는 AI 에이전트가 Figma 파일을 읽을 수는 있었지만, 파일에 쓸 수는 없었습니다. 이번 업데이트는 에이전트에게 쓰기 권한을 부여합니다—표면적으로는 작은 업데이트처럼 보이지만, 그게 전부일까요?

왜 이것이 중요한가

제가 추측하자면, 피그마는 Figma Make와 같은 자체 AI 제작 도구를 “바이브 디자인”(프롬프트를 통한 디자인)의 주요 인터페이스로 삼고 있었던 것 같습니다. 개인적인 경험과 업계 동료들의 경험을 토대로 보면, Figma Make의 결과물은 **“그저 그저”**라는 평가가 나옵니다. 데모용으로는 괜찮지만, 특정 비전을 구현하려고 하면 금세 한계에 부딪힙니다. 대부분의 디자이너는 디자인 부사장이 모든 사람이 AI 도구를 사용하도록 강제한 뒤 이 도구를 시도했지만, 다시 돌아오지 않았습니다.

동시에, 제품 개발에서도 또 다른 근본적인 변화가 일어나고 있습니다. 이제는 Claude Code / Codex / Antigravity(또는 사용자가 선택한 AI 에이전트)에서 시작하는 경우가 많아졌습니다. Claude Code로 열 가지 방향을 프로토타이핑하는 것이 피그마에서 와이어프레임 하나를 만드는 것보다 빠릅니다. 이는 피그마에게 정말 위험한 상황인데, 피그마는 한때 제품 개발이 시작하고 엔지니어링 인계가 이루어지기까지 진행되던 장소였기 때문입니다.

피그마는 다수의 SaaS 도구와 마찬가지로 이 두 현상을 명확히 볼 수 있습니다—자체 AI 에이전트는 UI 안에서 먼지를 쌓아가고 있는 반면, 사람들은 Claude Code에 푹 빠져 모든 작업에 활용하고 있습니다.

두 가지 흥미로운 힘

1. Claude Code가 빌더들 사이에서 소비자 선호도가 되고, 따라서 다른 도구들의 통합 지점이 되고 있다.
   Ben Thompson’s framework에서, 그들은 집계자(aggregator)가 되고 있다.

2. Claude Code의 차별점은 자체 모델과 독점적인 에이전트 하네스를 깊게 통합한 데 있다.
   Figma, Canva, Slack 등 모든 다른 도구들은 Anthropic이 사용하는 동일한 모델(현재 최첨단인 Opus 4.6)에 접근할 수 있지만, 자체 도구 안에서 Claude Code의 마법을 재현하지 못하고 있다.

SaaS 기업이 직면한 가혹한 현실

1. 모든 SaaS 도구에서 가장 가치 있는 데이터는 귀사의 컨텍스트이며, 이는 거의 항상 다른 도구가 사용할 수 있도록 API를 통해 노출됩니다.
   해당 데이터와 도구의 실제 사용 패턴에 관한 메타데이터는 AI 에이전트를 의미 있게 더 유용하게 만들 정도로 충분히 가치가 있을 가능성이 낮습니다.

2. 개별 SaaS 기업의 컨텍스트는 보다 넓은 조직적 컨텍스트 없이는 대부분 쓸모가 없습니다.
   컨텍스트는 네트워크 효과를 가지며—그 완전성이 높을수록 기하급수적으로 가치가 상승하고, 제한적일 때는 거의 무용지물입니다. Figma 파일, Slack 채팅, Amplitude 대시보드, JIRA 티켓만으로는 AI 에이전트에게 귀사의 비즈니스 전체 모습을 제공하지 못합니다. 하지만 이들을 모두 합치면 매우 높은 가치를 지닙니다.

3. 소프트웨어 개발 프로세스가 이산 모델(각 단계마다 명확한 절차와 명시적인 인계)에서 보다 유동적인 모델로 전환되고 있습니다. 이 모델은 AI가 점점 더 프로세스를 흡수함에 따라 게이트, 단계, 인계가 없습니다.
   대부분의 SaaS 도구는 특정 단계를 단순화하거나 그 사이의 인계를 개선하도록 설계되었습니다. 그렇다면 이러한 단계들이 인계가 필요 없는 하나의 프로세스로 합쳐지면 어떻게 될까요?

갈림길

이 현실이 모든 SaaS 기업에게 서서히(혹은 급속히?) 구체화됨에 따라, 그들은 갈림길에 서게 된다:

• **“모든 것을 아우르는 도구”**가 되어 이 새로운 유동적인 프로세스를 장악하거나, 또는
• Claude 또는 ChatGPT에 또 다른 플러그인으로서 상품화되는 것.

Figma와 대부분의 다른 기업들은 뒤쪽 선택을 피할 수 없다. Claude와 다른 주요 에이전트가 이 속도로 수요를 계속 집계한다면, Figma와 같은 기업은 사용자와의 직접적인 관계를 잃게 된다 – 브랜드 목적지가 아니라 공급자가 된다.

예를 들어 Linear와 같은 기업은 스스로를 혁신하려 하고, 보편적인 컨텍스트 저장소와 그 위에 존재하는 에이전트 두 역할을 동시에 수행하려 한다. 현실적으로, 이들 모두는 주된 목적지를 유지하려는 목표를 간절히 추구하면서도, 베팅을 대비해 마지못해 도구를 제3자 AI 에이전트에 개방할 것이다.

존재론적 질문

몇몇은 보다 존재론적인 질문에 직면하게 될 것입니다: 당신의 도구가 어제의 소프트웨어 개발 프로세스에서 특정 단계에 맞춰 설계되었고 AI가 그 단계를 선택 사항으로 만들고 있다면, 앞으로의 전망은 어떻게 될까요?

지난 10년을 Figma(그 이전에는 Sketch)에서 디자인 작업을 하며 보낸 디자이너로서, 이제는 Figma를 전혀 사용하지 않거나 아주 간접적으로만 사용하면서 제품을 출시하고 있습니다. 더 이상 작업의 출발점이자 유일한 진실의 원천이 아닙니다(제가 혼자만은 아닙니다).

어제의 프로세스를 위해 구축된 모든 SaaS 기업은 이제 같은 이분법에 직면합니다: 스스로를 재창조하든지, 혹은 스스로가 되어가고 있는 모습을 받아들이든지.
옛 세계가 다시 돌아오는 제3의 선택지는 없습니다. 지난 10년 동안 우리가 소프트웨어를 구축하는 방식을 정의해 온 도구들은 근육 기억에만 의존해 오래 지속될 수 없습니다. 에이전트가 새로운 출발점이 됩니다. 당신이 그 역할을 하지 못한다면, 당신은 공급자일 뿐입니다. 그리고 공급자는 …
정의상, 교체 가능합니다.

P.S. 이 글은 다음 주간 Metedata Digest에 실릴 세 가지 생각 중 하나로 시작되었습니다. 하지만 글을 쓰다 보니 스스로 살아 움직이게 되었고, 그래서 별도로 분리하기로 했습니다. 내일 Digest는 더 간결하고 읽기 쉽게 유지하려 합니다. 이 형식이 더 마음에 드는지(혹은 그렇지 않은지) 알려 주세요!

게시물 없음