대부분의 프로덕트 팀에서는 프로덕트 디자이너(Product Designer)가 Figma에서 디자인 시스템을 업데이트한 시점부터 해당 변경 사항이 프로덕션(production)에 반영되기까지 2주에서 4주 정도의 시간이 걸립니다. 심지어 변경 사항이 반영되기는커녕, 어떤 수정 사항들은 아예 범위(scope)에 포함되지 않아 디자이너가 설계한 것과 사용자가 실제로 보는 것 사이에 영구적인 격차가 발생하기도 합니다. Claude Code와 MCP Figma의 등장으로 이제 이 지연 시간은 단 몇 분 단위로 줄어들 수 있습니다.

기술 및 프로덕트 팀을 위한 AI

이 기사는 프로덕트 디자이너(Product Designer)를 위한 AI의 영향에 초점을 맞춥니다. 기술 팀 내 AI에 대한 더 넓은 관점은 IA au service de la DX를 참조하세요. 그리고 프로덕트 디자이너의 역할을 더 잘 이해하려면 Product Designer : bien plus que la couleur des boutons를 확인하세요.

한눈에 보는 문제점

Figma와 프로덕션 사이의 간극

이 문제는 모든 CPO(최고 제품 책임자)들에게 잘 알려져 있지만, 여전히 지속되고 있습니다. Product Designer는 Figma에서 새로운 토큰 (tokens), 업데이트된 컴포넌트 (components), 추가된 베리에이션 (variations) 등을 통해 디자인 시스템을 발전시킨 후, 프론트엔드 (frontend) 팀이 이러한 변경 사항을 통합할 수 있도록 티켓을 생성합니다. 이 티켓은 백로그 (backlog)에 추가되어 우선순위 결정을 기다리고, 스프린트 플래닝 (sprint planning)을 거쳐 개발, 리뷰 (review), 배포 (deploy) 과정을 밟습니다. 가장 낙관적인 경우에도 1~2 스프린트가 소요됩니다. 현실에서는 비즈니스 기능에 비해 우선순위가 낮다고 판단되어 일부 수정 사항이 누락되기도 합니다. 결국 디자이너는 현장의 실상과 단절됩니다. 즉, 아직 프로덕션 (production)에 존재하지 않는 컴포넌트로 다음 목업 (mockups)을 설계하게 되는 것입니다.

반대편에서는 프론트엔드 개발자들이 Figma보다 몇 주 뒤처진 버전의 디자인 시스템을 가지고 작업합니다. 그 결과, 목업과 실제 제품 사이에는 지속적인 불일치가 발생하고, 두 가지를 일치시키기 위한 불필요한 커뮤니케이션이 반복되며, 양측 모두에서 명백한 좌절감이 나타납니다. 시간이 흐를수록 격차는 더 벌어지고, 이를 따라잡기 위한 비용은 더욱 증가합니다. 이는 제가 컨설팅하는 조직의 규모나 성숙도와 관계없이 거의 모든 프로덕트 조직에서 관찰되는 악순환입니다. 그리고 지금까지 지속적인 동기화 (synchronization) 비용이 너무 높았기 때문에, 누구도 진정으로 만족스러운 해결책을 찾지 못했습니다.

Claude Code, Figma MCP, 그리고 새로운 워크플로우 (workflow)

몇 달 전부터 Claude Code와 같은 도구들을 통해 자연어 명령으로 코드를 조작할 수 있게 되었습니다. 우리 주제의 판도를 바꾸는 것은 Figma MCP (Model Context Protocol)의 등장입니다. 이는 Claude Code가 Figma 파일의 콘텐츠—컴포넌트 (components), 토큰 (tokens), 변형 (variants), 스타일 (styles)—에 직접 접근할 수 있게 해주는 커넥터입니다. 이 두 가지를 결합하면, 프로덕트 디자이너 (Product Designer)가 직접 코드를 한 줄도 작성하지 않고도 코드 내의 디자인 시스템을 업데이트할 수 있는 워크플로우 (workflow)를 얻게 됩니다. 구체적인 과정은 다음과 같습니다:

1. 프로덕트 디자이너가 기존 방식대로 Figma에서 컴포넌트나 토큰을 업데이트합니다.
2. Claude Code Desktop을 열고 자연어로 해당 컴포넌트를 코드에서 업데이트해 달라고 요청합니다.
3. Claude Code가 MCP를 통해 Figma 사양을 읽고, 기존 코드와의 차이점을 식별한 뒤 수정 사항을 제안합니다.
4. 디자이너는 Claude Code Desktop 인터페이스에서 수정된 컴포넌트의 시각적 미리보기를 통해 결과를 직접 확인합니다.
5. 승인하면 변경 사항이 머지 (merge)될 준비가 완료됩니다.

Claude Code 데스크톱 버전의 등장은 이 워크플로우의 핵심 요소입니다. CLI (Command Line Interface)는 디자이너들에게 생소하며 정당하게 두려움을 줄 수 있는 도구입니다. 검은 화면에 흰 글씨가 나오는 터미널은 그들의 일상과는 거리가 멉니다. Claude Code Desktop의 그래픽 인터페이스는 판도를 완전히 바꿉니다. 자연어로 상호작용하고, 결과를 시각적으로 확인하며, 결과를 얻기 위해 git이나 터미널을 숙달할 필요가 없습니다. 디자이너는 익숙한 환경에 머물면서도 코드에 직접적인 영향을 미칠 수 있습니다. 이는 매우 근본적인 지점인데, 디자이너의 채택 여부가 이 워크플로우의 성공을 결정짓는 핵심 요인이기 때문입니다. 만약 도구가 적대적이거나 너무 기술적이라고 느껴진다면, 이론적인 이점은 이론에만 머물게 될 것입니다.

디자인 시스템의 확장된 수호자로서의 디자이너

이 새로운 워크플로우는 프로덕트 디자이너 (Product Designer)를 프론트엔드 개발자 (frontend developer)로 바꾸는 것이 아닙니다. 이는 디자이너의 자연스러운 영역을 확장하는 것입니다. 생각해 보면, 디자이너는 이미 Figma 내에서 디자인 시스템 (design system)의 수호자 역할을 하고 있습니다. 규칙을 정의하고, 시스템을 발전시키며, 일관성을 보장합니다. 디자이너가 이러한 변화를 코드에 직접 반영할 수 있도록 허용하는 것은, 그가 가장 정당성을 갖는 작업에서 중간 단계를 제거하는 것뿐입니다. Product Owner는 더 이상 티켓 (ticket)을 생성할 필요가 없고, 개발자는 토큰 (tokens)이나 표준 컴포넌트 (components)의 변경 사항을 위해 디자인 시안 (maquette)을 코드로 번역할 필요가 없습니다. 모두가 시간을 절약하게 됩니다.

그 이면에는 더 전략적인 과제가 있습니다. 개발자가 5~10배 더 빠르게 작업할 수 있게 해주는 에이전틱 AI (l'IA agentique)와 같은 AI 도구들로 인해 개발 속도가 가속화됨에 따라, 프로덕트 디자이너들 또한 가속화할 방법을 찾지 못한다면 제품 조직 내에서 병목 현상 (goulot d'étranglement)이 될 위험이 있습니다. 해결책은 바로 디자인 시스템에 있습니다. 디자인 시스템을 엄격하게 최신 상태로 유지하고 성장시킴으로써, 디자이너는 개발자와 프로덕트 오너가 모든 단순한 인터페이스를 자율적으로 설계하는 데 필요한 팔레트를 제공하게 됩니다. 상황이 더 복잡해지고 기존 디자인 시스템의 깊이가 부족해지는 순간, 디자이너는 다시 주도권을 잡고 팀 내 그 누구도 상상할 수 없는 사용자 경험 (user experience)을 설계함으로써 자신의 진정한 가치를 증명하게 됩니다.

타협할 수 없는 전제 조건: 견고한 디자인 시스템

이 워크플로우가 아무리 유망해 보일지라도, 명확하게 정의되고 잘 구조화된 디자인 시스템 (design system)이 있어야만 작동합니다. 이러한 토대가 없다면, AI는 질서 대신 혼돈을 가속화할 것입니다. 이러한 도구들의 공통된 특성은 AI가 '가속기'라는 점입니다. 기반이 탄탄하면 모든 것이 매우 빠르게 개선되지만, 기반이 취약하면 모든 것이 매우 빠르게 무너집니다. 이러한 용도에 '준비된' 디자인 시스템이란 최소한 잘 정의된 토큰 (tokens) (색상, 타이포그래피, 간격), Figma에 명확하게 문서화된 아토믹 컴포넌트 (atomic components), 그리고 동일한 구조를 따르는 프론트엔드 (frontend) 구현을 의미합니다. 만약 여러분의 Figma가 재사용 가능한 컴포넌트가 없는 모형 (mockups)의 집합이거나, 프론트엔드 코드가 공통된 로직 없이 스타일을 중복 구현하고 있다면, Claude Code는 기적을 일으킬 수 없습니다. 오히려 해결하는 문제보다 더 많은 문제를 일으키는 일관성 없는 코드를 생성할 뿐입니다.

이는 아직 디자인 시스템에 제대로 투자하지 않았다면, 디자인 시스템에 진지하게 투자해야 할 추가적인 이유이기도 합니다. 제가 CPO 팀 지표 (métriques d'équipe CPO)에 관한 글에서 언급했듯이, 디자인 시스템의 커버리지 (coverage)는 프로덕트 팀의 성숙도를 나타내는 핵심 지표입니다. 이 새로운 워크플로우와 함께라면, 이는 단순한 품질 지표를 넘어 주요 가속 레버리지를 해제하기 위한 전제 조건이 됩니다. 디자인 시스템에 올바르게 문서화된 각 컴포넌트는 디자이너가 개발자를 동원하지 않고도 자율적으로 업데이트할 수 있는 컴포넌트가 됩니다. 이 투자는 매우 빠르게 수익을 창출할 것입니다.

요약

Figma의 디자인 시스템 (Design System)과 실제 프로덕션 (Production) 구현 사이의 간극은 누구도 진정으로 해결하지 못했던 오래된 문제입니다. 이는 기술적으로 불가능해서가 아니라, 지속적인 동기화 비용이 너무 높아서 지속적으로 수행하기 어려웠기 때문입니다. Claude Code와 MCP Figma를 사용하면 디자인 시스템 업데이트를 위한 이 비용이 거의 제로(0)에 가깝게 줄어듭니다. 이는 디자인 팀의 속도를 높이는 동시에 제품의 일관성 (Consistency)을 개선하고자 하는 CPO(최고 제품 책임자)들에게 구체적인 기회입니다. 물론, 언제나 그렇듯 기초가 잘 갖춰져 있다는 전제하에 말이죠.

제품 팀을 구조화하고 싶으신가요?

기술 및 제품 팀 구축 (création d'équipe tech & produit)을 통해, 저는 여러분의 디자인 팀을 조직하고, 탄탄한 디자인 시스템을 구축하며, 제품 워크플로우 (Workflow)에 적절한 AI 도구를 통합할 수 있도록 도와드립니다.