'디자인을 코드로' 변환하는 일은 오랫동안 개발자의 손에 달려 있었다. Figma 화면을 보며 spacing을 측정하고, 컴포넌트 명칭을 추측하고, 디자이너와 Slack을 오가며 의도를 확인하던 그 루틴. AI가 이 중간 지점을 가져가기 시작하면서, 흥미로운 질문이 생겼다. AI는 정말 디자인과 코드 사이의 간극을 메울 수 있는가, 아니면 그 간극이 어디 있는지조차 모르는 채 빠르게 움직이고 있는 건가.
최근 세 가지 실험이 이 질문을 서로 다른 각도에서 조명한다. UX 디자이너 출신 프론트엔드 개발자 Olena Ivlieva의 Figma MCP 실험, 오픈소스 React 비디오 에디터 Timeline Studio에 MCP를 접목한 사례, 그리고 인스웨이브가 일본 시장에 제시한 '명세 기반 개발(SDD)' 전략. 이 세 사례를 함께 놓으면, 단순한 도구 소개를 넘어 '스펙/디자인 → AI → 코드'로 이어지는 워크플로우 전반의 윤곽이 보이기 시작한다.
AI가 Figma 파일을 읽을 수 있게 된 세계
2026년 Figma가 MCP(Model Context Protocol)를 통해 캔버스를 외부 AI 에이전트에게 열면서, 에이전트가 Figma 파일 안에서 직접 컴포넌트를 생성하고 수정하는 일이 가능해졌다. Codex를 비롯한 MCP 클라이언트들이 이제 디자인 시스템의 맥락을 읽고, 코드베이스와의 연결점을 찾을 수 있다. 기술적으로 보면 꽤 극적인 변화다.
Ivlieva는 이 환경에서 직접 실험을 수행했다. PhpStorm에서 Codex를 Figma MCP에 연결하고, 기존에 이미 완성된 디자인 시스템·프론트엔드·컴포넌트 라이브러리를 갖춘 상태에서 에이전트에게 구체적인 미션을 줬다. "코드베이스의 컴포넌트를 Figma로 옮기되, 디자인 시스템의 구조를 유지하라." 반응형 그리드, 중첩 컴포넌트, 다양한 breakpoint 상태를 포함한 복합 컴포넌트를 대상으로 삼았다.
결과는 나쁘지 않았다. 에이전트는 약 29분 만에 컴포넌트를 이전했고, 계층 구조·레이어·인스턴스·토큰·spacing·타이포그래피를 보존한 채 편집 가능한 구조를 유지했다. 하지만 그녀가 강조한 것은 그 29분 이전의 이야기다. 수차례의 실패, 문서 재작성, 반복 리뷰가 축적된 이후에야 그 결과가 나왔다. "Working with AI does not start with a prompt. It starts with rules." 프롬프트 이전에 규칙이 있었고, 규칙 이전에 시스템이 있었다.
컨텍스트가 없으면 에이전트는 해석을 만들어낸다
이 실험에서 드러난 핵심은 에이전트의 성능이 아니라 '시스템의 명확성'이 결과를 결정한다는 점이다. Ivlieva는 Figma 파일 안에서 Atomic Design 원칙에 따라 컴포넌트-코드 간 매핑을 수동으로 정의했다. 어떤 Figma 컴포넌트가 코드베이스의 어느 파일에 대응하는지, variant와 props는 어떻게 연결되는지, 어떤 토큰을 써야 하는지. AI는 이 구조 위에서 기계적인 작업을 대신했을 뿐이다.
그녀가 Code Connect(Organization/Enterprise 플랜 이상에서만 사용 가능)를 쓰지 않고 네이밍, 설명, 경로, 에이전트 규칙 문서로 대체한 것도 의미 있는 선택이다. 도구가 없어도 구조가 명확하면 에이전트가 따라온다는 걸 증명한 셈이다. 반대로 구조가 없으면? 에이전트는 맥락을 재구성하려 하고, 그 과정에서 오류가 생긴다. 디자인 시스템이 허술할수록 에이전트가 메꿔야 할 공백이 커지고, 그 공백은 일관성 없는 컴포넌트와 임의적인 값으로 채워진다.
에이전트를 '안전하게' 편집 루프에 올리려면
Timeline Studio 사례는 다른 각도에서 같은 문제를 파고든다. 오픈소스 브라우저 기반 React 비디오 에디터인 Timeline Studio에 AI 에이전트가 타임라인 마커를 읽고 수정할 수 있는 MCP 인터페이스를 추가한 이 실험은, 에이전트가 편집 루프 안에서 안전하게 작동하기 위해 필요한 구조적 조건을 잘 보여준다.
핵심 아이디어는 단순하다. 에이전트가 프로젝트를 inspect하고, diff를 확인하고, 적용하고, 다시 inspect하는 루프를 명시적으로 설계한 것이다. CLI와 MCP 어댑터는 동일한 커맨드 엔진을 공유하므로, 검증 규칙을 한 곳에서 수정하면 양쪽 진입점 모두에 적용된다. revision conflict가 발생하면 단순히 번호를 덮어쓰는 게 아니라 새 inspect부터 다시 시작하게 강제한다. 부분 적용 실패 시 배치 전체가 롤백된다.
이 설계에서 눈에 띄는 건 에이전트에게 '자유'를 주지 않았다는 점이다. 에이전트는 정해진 operation 타입으로만 편집하고, 입력 파일을 덮어쓸 수 없으며, ID 충돌과 부동소수점 경계 오류까지 엔진 레벨에서 사전 차단된다. 에이전트를 협업자로 대우하되, 그 협업이 예측 가능한 범위 안에 있도록 구조가 설계되어 있다. 빠른 자동화를 원한다면, 먼저 실패 경계를 명확히 정의해야 한다는 원칙이 코드 레벨에서 구현된 사례다.
'명세'가 있어야 AI가 검증할 수 있다
인스웨이브의 웹스퀘어 AI(WebSquare AI)는 또 다른 관점을 더한다. 단순히 '코드를 생성하는 AI'가 아니라 '명세를 기반으로 결과물을 생성하고 검증하는 AI'를 지향한다는 점에서, 앞선 두 사례와 같은 문제의식을 엔터프라이즈 맥락에서 풀어낸다. 퍼블리싱·코딩·테스트·운영 관리까지 개발 전 과정을 하나의 환경에서 지원한다고 설명하지만, 핵심 전략으로 제시된 건 명세 기반 개발(Specification-Driven Development)이다.
명세가 있어야 AI가 '맞다/틀리다'를 판단할 기준이 생긴다. 코드를 빠르게 생성하는 것과, 명세에 부합하는 코드를 신뢰할 수 있게 생성하는 것은 다른 문제다. 금융·공공처럼 안정성과 보안이 우선되는 환경에서 이 구분은 더 중요해진다. 일본 주요 IT 기업 32명이 서울 본사를 직접 방문해 이 접근법을 확인했다는 사실은, 'AI가 코드를 짠다'는 메시지보다 '어떤 근거로 짜고 어떻게 검증하는가'라는 질문이 엔터프라이즈 시장에서 더 큰 설득력을 갖는다는 걸 시사한다.
공통 언어: 시스템이 먼저, 에이전트는 다음
세 사례를 관통하는 단 하나의 원칙이 있다면 이것이다. 에이전트에게 일을 맡기기 전에 시스템이 먼저 명확해야 한다. Figma 파일의 구조, 컴포넌트-코드 매핑, 에이전트 규칙 문서 — Ivlieva의 실험에서 29분의 성공을 만든 것은 그 이전의 수십 시간짜리 시스템 정의였다. Timeline Studio에서 에이전트가 타임라인을 안전하게 편집할 수 있는 것은 커맨드 엔진의 검증 규칙과 revision 체계 덕분이다. 웹스퀘어 AI가 '단순 생성'을 넘어서려는 것도 명세라는 사전 구조 위에서다.
AI가 디자인과 코드 사이를 빠르게 채워갈수록, 그 사이에 '무엇이 올바른가'를 정의하는 일이 오히려 더 중요해진다. 디자인 시스템, 컴포넌트 명세, 에이전트 규칙, 검증 루프 — 이것들은 AI 시대에 사라지는 것들이 아니라, AI가 쓸모 있으려면 반드시 먼저 갖춰져야 하는 것들이다. 속도가 올라갈수록 기반이 더 단단해야 한다는 역설이, 세 실험 모두에서 반복된다.