만약 당신이 정적 사이트(static sites)를 배포하거나 표준 디자인 시스템(design system)을 기반으로 구축하고 있다면, Figma MCP 서버가 아마 당신을 위해 훌륭한 역할을 수행하고 있을 것이며, 이 글은 건너뛰셔도 좋습니다. 이 글은 마찰(friction)에 부딪힌 사람들을 위한 것입니다. 즉, 디자인-투-코드(design-to-code) 파이프라인을 더 모듈화되고, 유지보수가 용이하며, 견고하고, 도구에 구애받지 않게(tool-agnostic) 만들고, 결과물로 더 나은 코드를 얻으려는 모든 이들을 위한 것입니다.

나는 이것을 비판하기 위해 쓰기 시작했다.

계획은 간단했다: Figma-to-code는 과대평가되었고, 데모는 매끄럽지만, 대부분의 팀에서 현실은 엉망이라는 것이었다. 나는 그것이 얼마나 엉망인지 보여주려 했다: 하드코딩된 색상들, 모델이 임의로 만들어낸 컴포넌트들, 그리고 실제로 읽어보기 전까지는 괜찮아 보이는 결과물들 말이다.

그러다 monday.com의 디자인-투-코드(design-to-code) 파이프라인1을 접하게 되었고, 나는 진심으로 감명받았다.

monday가 나에게 보여준 것은, 비록 개발자가 데모 뒤의 코드를 여전히 정리하고 있더라도, 이 작업이 잘 수행될 수 있다는 점이었다.

더 자세히 들여다볼수록, 이 글은 도구에 관한 것이 아니게 되었다. 도구, 파이프라인, 가격 책정, 이 모든 것은 계속해서 변한다. 하지만 그 소음 아래에는 더 조용한 변화, 즉 내가 예상하지 못했고 계속해서 생각하게 만드는 변화가 있다: 실제로 누가 작업을 수행하는가, 그리고 아마도 더 중요한 것은, 도구가 우리를 대신해 조용히 내리는 결정들을 누가 _소유(owns)_하는가에 대한 변화다. 이것이 이 논의의 결론이며, 나는 이것이 코드 품질과 책임에 대해 더 깊은 질문을 던진다고 생각한다.

표면적으로는 해결된 것처럼 보인다

MCP 서버를 통해 대규모 언어 모델(Large Language Model, LLM)을 Figma 파일에 연결하면, 모델은 컴포넌트를 돌려준다. 이것이 업계 전체가 수렴하고 있는 파이프라인이다. 디자인은 Figma에서 이루어지고, 코드는 Copilot, Cursor, Claude Code, Codex와 같은 소수의 AI 에이전트(AI agents)에 의해 생성된다.

그러한 수렴은 실재하며, 그 이면의 수치는 한쪽으로 쏠려 있다. Figma는 기본 인터페이스이며, 디자이너의 82.3%가 주요 UI 디자인 도구로 지목했다.2 Figma 자체의 코드 생성(codegen) 기능인 Figma Make는 이미 연간 10만 달러 이상을 지출하는 Figma 고객의 약 60%가 매주 사용하고 있다.3 입력값(inputs)이 하나의 도구로 통합되고 있는 것이다.

포맷 또한 마찬가지다. 디자인 토큰 (Design tokens)은 2025년 말, Adobe, Google, Microsoft, Meta, Amazon, Figma 등 업계 최대 규모의 기업 약 24곳의 지원을 받으며 첫 번째 안정적인 표준인 DTCG에 도달했다.4 빌드 툴링 (Build tooling)도 이를 채택하고 있다. 가장 널리 사용되는 토큰 변환기 (token transformer)인 Style Dictionary는5 이제 DTCG를 퍼스트 클래스 (first-class)로 지원한다. Terrazzo6와 같은 더 작은 도구들은 처음부터 이 포맷을 중심으로 구축된 DTCG 네이티브 (DTCG-native) 도구들이다. Google은 코딩 에이전트 (coding agent)에게 디자인 시스템을 설명하는 방법인 DESIGN.md를7 발행한다. 모두가 같은 방향을 향하고 있다. 심지어 Figma조차 이 표준을 지지한다. Figma에서 널리 사용되는 커뮤니티 토큰 플러그인인 Tokens Studio는8 DTCG 포맷을 읽고 쓸 수 있다. 기존의 지배적 사업자 (incumbent)가 자신의 도구를 떠나기 더 쉽게 만드는 오픈 포맷 (open format)의 뒤에 줄을 서고 있는 것이다.

멀리서 보면 문제는 해결된 것처럼 보인다. 디자인을 위한 하나의 도구, 토큰을 위한 수렴하는 표준, 그리고 코드를 작성할 수 있는 몇몇 유능한 에이전트들. 이를 모두가 이미 눈치챈 변화, 즉 '툴링의 수렴 (tooling converged)'이라고 부를 수 있다. 안정화된 것이다.

하지만 실제로 실행해 보면

스캐폴딩 (scaffolding)되지 않은 모델을 실제 Figma 파일에 적용하면, 읽어보기 전까지는 결과물이 그럴싸해 보인다. 하지만 모델은 당신의 시스템에 없는 컴포넌트 (components)를 찾으려 하고, 토큰이 되어야 할 색상들을 하드코딩 (hard-codes)하며, 버전 간의 컨벤션 (conventions)을 뒤섞어 버린다 (Tailwind v3 패턴이 v4 프로젝트에 투입되는 식이다).9 때로는 브라우저가 이해하지 못하는 fit-parent와 같은 값을 만들어내며 CSS를 완전히 날조하기도 한다.10 이것은 기술의 문제나 잘못된 프롬프트 (prompt)의 문제가 아니다. 이는 단순한 파이프라인 (naive pipeline)이 누구에게나 행하는 방식이다.

Figma 스스로도 그렇게 말한다. Figma의 자체 MCP 설정 가이드(MCP setup guide)11는 그 한계에 대해 직설적이다. 당신의 Figma 컴포넌트를 실제 코드와 연결해 주는 Code Connect가 없다면, "모델은 추측하고 있는 것(the model is guessing)"이라고 말이다. 디자인 도구 공급업체 본인으로부터 나온 이 인정은 그 어떤 제3자 벤치마크 (third-party benchmark)보다 더 가치가 있다.

왜 모델은 추측할까요? 파일이 아무런 의미도 없는 순수 값(bare value)을 전달하기 때문입니다. 예를 들어, 이것이 10픽셀인지, z-index인지, 아니면 10밀리초인지 알려주는 정보 없이 단순히 10이라는 FLOAT 값만 전달됩니다. 저는 Even Figma isn't sure about its own design tokens에서 이러한 실패의 원인을 깊이 파고들었습니다. 요약하자면, 원시 값(raw value)에서 의미론적 의미(semantic meaning)로 넘어가는 단계, 즉 해석(resolve) 단계가 소유자 없이 손실이 발생하는 구조라는 점입니다. 파일이 명시하지 않기 때문에 모델은 디자인의 의도가 무엇이었는지 추론해야만 합니다.

공정하게 말하자면, Figma도 이 문제의 일부를 해결하고 있습니다. 네이티브 DTCG 내보내기(export) 기능이 출시되고 있어, 이제 토큰을 값이 드디어 그 의미를 담고 있는 타입 지정된 JSON(typed JSON) 형태로 추출할 수 있습니다.12 하지만 이는 내보내는 토큰에 타입을 지정하는 것일 뿐, 모델이 컴포넌트로부터 코드를 생성할 때 다시 읽어들이는 값에 적용되는 것은 아닙니다. 그 과정에서 모델은 토큰이 붙어 있지 않은 순수하게 해석된 숫자(bare resolved number)를 받게 되는 경우가 많으며, 스스로 즉흥적으로 처리해야 하는 상황에 놓입니다. 이 간극은 로드맵 상의 미래가 아니라 현재 실재하는 문제이며, monday가 메우고자 하는 지점이기도 합니다.

토큰은 그 문제의 가시적인 단면일 뿐입니다. "LLM을 Figma에 연결하여 UI를 얻는다"는 것은 하나의 작업처럼 보이지만, 실제로는 모델이 단 한 번의 패스(pass) 내에서 조용히 해결하는, 압축된 결정들의 스택(stack)입니다. Amrutha Kollu13는 이 분리를 잘 설명합니다. 이러한 결정 중 일부는 결정론적(deterministic)이며 정답이 존재합니다. 즉, 어떤 토큰을 쓸지, 어떤 간격(spacing)을 사용할지, 어떤 컴포넌트를 사용할지와 같은 것들입니다. 다른 결정들은 진정한 판단(judgment calls)의 영역입니다. 실수는 이 두 가지 종류의 결정을 모델에게 한꺼번에 넘겨주고 요행을 바라는 것입니다. 이 결정론적인 계층, 즉 제가 이전에 언급했던 missing middle을 관리하는 주체가 없기 때문에, 모델이 그 빈칸을 채우게 되는 것입니다.

제 말을 그대로 믿으실 필요는 없습니다. Yi Gui와 동료들이 실제 Figma 파일을 코드로 변환하기 위한 벤치마크인 Figma2Code,14를 구축했을 때, 가장 강력한 폐쇄형 모델(proprietary models)들은 시각적으로는 충실한 결과물을 만들어냈지만 레이아웃 반응성(layout responsiveness)과 유지보수성(maintainability) 측면에서는 취약한 모습을 보였습니다. 이는 모델들이 구조를 복원하지 않고 Figma 메타데이터에서 기본값(primitive values)을 그대로 매핑하기 때문입니다. 충실한 픽셀, 그러나 추측된 아키텍처(architecture)인 셈입니다.

만약 이것이 프롬프팅(prompting)의 문제였다면, 전체 스택(stack)을 소유한 벤더가 이미 해결했을 것입니다. Figma는 해결하지 못했습니다. Figma의 자체 생성기인 Figma Make는 기본적으로 독립적인(standalone) 코드를 생성합니다. 이를 사용자의 디자인 시스템(design system)에 맞춰 구축하게 하려면, 먼저 컴포넌트(components), 토큰(tokens), 가이드라인(guidelines)을 패키징하여 생성기가 실제로 작업할 수 있는 근거를 제공하는 "Make kits"15를 직접 제작해야 합니다. 즉, 전체 스택을 소유한 기업조차도 생성기가 사용자의 디자인 시스템에 자동으로 맞춰지도록 만들지는 못합니다. 그들은 도구(tooling)를 제공할 뿐이며, 현재로서는 그 도구가 매우 빈약합니다. 여전히 키트(kits)를 직접 제작하고 유지보수해야 하며, 이는 공짜가 아닙니다. 이는 실제적이고 지속적인 작업이며, 이제 막 시작하려는 소규모 또는 중견 팀에게 가장 큰 부담이 됩니다. 설상가상으로, 이러한 키트들은 Figma 전용이기 때문에, 이러한 노력은 사용자를 이식 가능(portable)하게 만드는 대신 특정 벤더에 강력하게 종속(tie)시킵니다.

이 중 그 어느 것도 기술적인 장벽은 아닙니다. DTCG는 표준이며, 어떤 모델이든 깔끔하게 내보내진 시스템으로부터 불가지론적(agnostic) 토큰을 읽을 수 있습니다. 당신을 가두는 것은 기술이 아니라, 모든 벤더가 당신을 자사의 울타리 안에 머물게 해야 할 이유가 있다는 점입니다. 그것은 변할 수 있습니다. 하지만 지금은 그렇지 않으며, 그것이 바로 증거입니다. 문제는 프롬프트가 아닙니다. 아키텍처(architecture)입니다.

monday가 대신 구축한 것

내가 본 팀들 중 디자인-투-코드(design-to-code) 파이프라인이 탄탄한 곳들은 프롬프트 만지작거리는 것을 멈추고 파이프라인 자체를 재구축했습니다. monday.com의 팀도 정확히 이 문제에 직면했고, 더 열심히 프롬프트를 입력하는 대신, 그들이 공개적으로 어디에서든 찾은 표준 파이프라인 중 가장 날카로운 버전을 구축했습니다. 이것은 새로운 종류의 것이 아닙니다. 모든 사람이 이미 추구하고 있는 것—실제 멀티-에이전트(multi-agent) 파이프라인과 토큰 문제에 대한 간단하지만 효과적인 우회책—을 훨씬 더 잘 설계한 버전일 뿐입니다. 그들의 엔지니어링 팀은 이를 정리했습니다. 초기 버전은 모두가 실패하는 방식 그대로 실패했습니다. 그들은

그 마지막 선택이 영리한 방식입니다. 내부적으로 monday는 서로 다른 React 및 디자인 시스템 (design-system) 버전을 사용하는 수백 개의 마이크로 프론트엔드 (microfrontends)를 운영하고 있기 때문에, 단일한 생성 코드 스타일을 강제하는 것은 소유권 (ownership)을 깨뜨릴 수 있습니다. 코드가 아닌 컨텍스트 (context)를 반환함으로써, 그들은 코드 생성 (codegen) 모델을 모델 불가지론적 (model-agnostic)으로 유지하고 권한을 각 팀에 남겨두었습니다. 심지어 에이전트 (agent) 전체를 MCP 도구로 노출하여, Cursor 측면에서는 그저 또 다른 도구 호출 (tool call)일 뿐입니다. 그들의 표현을 빌리자면, 이것은 "마법이 아니라 오케스트레이션 (orchestration)"입니다.1

워크플로우 하단에서 제가 높게 평가하는 두 번째 요소가 있습니다. 개발자가 최종적으로 얻게 되는 것은 단순한 컴포넌트가 아니라 완전한 Storybook 항목입니다. 스토리 (stories), 테스트 (tests), 그리고 문서화 (documentation)가 컴포넌트와 함께 생성되며, props 테이블은 수동으로 채워지는 것이 아니라 실제 컴포넌트로부터 추출됩니다.17 결과물은 단순히 렌더링만 되는 코드가 아니라, 문서화되고 테스트된 컴포넌트입니다.

이것이 작동하는 이유는 단 하나입니다. 거의 모든 다른 사람들이 운에 맡겨버리는 해결 (resolve) 단계를 누군가가 책임지고 있기 때문입니다. 또한 이를 해결하기 위한 성숙한 디자인 시스템 (design system), 전용 파이프라인 (pipeline), 그리고 이를 구축하고 운영할 엔지니어들이 필요했습니다. 이 점을 기억하세요, 왜냐하면 여기서부터 이야기가 반전되기 때문입니다.

monday조차 멈추는 지점

이 모든 노력에도 불구하고, 여전히 완전히 손을 뗄 수 있는 수준은 아닙니다. 솔직하게 말하자면 그들 스스로도 그렇게 말합니다.

워크스루 (walkthrough) 강연에서,18 monday의 디자인 시스템 리드인 Elad Mizrahi는 컴포넌트 코드의 7090%가 생성된다고 밝히며, 단순한 컴포넌트는 더 높고 복잡한 것은 더 낮지만, 그 이후에는 "우리 개발자들이 거기서부터 이어받습니다"라고 말했습니다. 인상적이긴 하지만, 완전 자동화와는 거리가 멉니다. 누군가는 여전히 마지막 1030%를 직접 작성해야 합니다.

그 수치가 어떤 비용을 수반하는지도 주목해야 합니다. 70~90%라는 수치는 성숙한 디자인 시스템, 전용 파이프라인, 그리고 엔지니어 팀을 통해 얻을 수 있는 결과물이며, 아직 구체적인 액수를 밝히지 않은 AI 비용은 말할 것도 없습니다. 이것은 이 방에서 가장 자원이 풍부한 설정이 도달할 수 있는 천장이지, 다른 모든 이들을 위한 출발선이 아닙니다.

Mizrahi의 관찰 중 하나는 앞날을 예견합니다. 모델은 기존 컴포넌트 (components)를 수정하는 것보다 **새로운 컴포넌트 (new components)**를 다룰 때 더 나은 성능을 보입니다.19 그는 그 이유를 밝히지 않았습니다. 제 추측으로는, 기존 컴포넌트에는 수정을 위한 불완전한 기록된 추론 (reasoning) 정보가 포함되어 있어, 모델이 원래의 결정이 무엇이었는지 다시 추측해야 하는 상황에 놓이기 때문인 것 같습니다.

카메라를 통해 그 한계를 직접 확인할 수 있습니다. 컴포넌트의 색상 체계를 반전시켜 달라는 요청을 실시간으로 받았을 때, 모델은 실패했습니다. 그가 예시를 입력해 주었지만, 모델은 다시 실패했습니다. 그는 이 컴포넌트에 대해 "작동하게 만들려면 몇 가지 오버라이드 (overrides)를 수행해야 합니다"라고 설명하며, "누군가에게 보여줄 때 항상 제대로 작동하는 것은 아닙니다"라고 솔직하게 말했습니다.20 그래서 그는 모델이 수행하지 못한 오버라이드를 직접 수동으로 적용하여 스스로 수정했습니다. 파이프라인 (pipeline)이 그를 근처까지 데려다주었지만, 마지막 간극은 사람이 메웠습니다.

결함이 있음에도 불구하고, 시간이 흐를수록 이 기술은 계속해서 좋아질 것이라고 주장할 수 있습니다. 여기서의 진정한 강점은 코드의 마지막 단계 (last mile)가 아니라, 멀티 에이전트 파이프라인 (multi-agent pipeline)의 형태와 그들이 자신들의 생태계 주변에 구축한 가드레일 (guardrails) 및 규칙들입니다. 모든 기능은 여전히 수동 디자인 리뷰 (manual design review)와 수동 코드 리뷰 (manual code review)를 거칩니다. 즉, 변경 사항은 "여전히 사람의 승인을 받아야 합니다." 그가 말했듯, "우리는 단순히 AI에 맹목적으로 의존하고 싶지 않습니다."21 이것은 매우 좋은 출발점이지, 자율 주행 (autopilot)이 아닙니다.

벽은 월요일의 문제가 아닙니다