Figma MCP 공부 정리 | AI가 Figma를 읽으면 뭐가 달라질까

Figma 블로그에서 Decagon이라는 팀의 사례를 읽었다. 빠르게 성장하는 고객 지원 플랫폼인데, Figma MCP와 Figma Make를 활용해서 디자인 시스템을 빠르게 확장해온 방식을 정리한 글이었다. 읽어보니 “AI가 Figma 파일을 직접 읽는다”는 게 구체적으로 어떤 의미인지 궁금해져서 조금 더 파봤다.

내가 이해한 건 이 정도다.

1️⃣ Figma MCP가 뭐가 다른가

Figma MCP는 코딩 에이전트가 Figma 파일에서 디자인 사양을 직접 읽어가도록 연결해주는 방식이다. 기존에는 디자이너가 스펙을 내보내고, 개발자가 그걸 다시 해석하고, 결과물을 서로 확인하는 과정이 반복됐는데, MCP를 쓰면 에이전트가 Figma 링크만 받아도 어떤 컴포넌트를 써야 하는지 스스로 찾아온다고 한다. 글에서는 이걸 “왕복 검토 제거”라고 표현했다.

Figma Make는 결이 다르다. 디자인 화면을 복사해서 프롬프트에 붙이면 코드로 만들어준다. Decagon 팀은 PM이 그래프나 대시보드를 고객에게 빠르게 보여줄 때 이 방식을 쓴다고 했다. 완성된 코드보다는 시각적 프로토타입을 빠르게 루프에 올리는 용도에 가까운 것 같았다.

👉🏻 핵심은 속도보다 정확도인 것 같았다. AI가 Figma 구조를 얼마나 정확히 읽느냐가 결국 아웃풋의 품질을 결정하는 구조였다.

2️⃣ 내가 든 생각

디자이너 입장에서 흥미로웠던 건 따로 있었다. AI를 잘 활용하려면 Figma 파일이 잘 정돈돼 있어야 한다는 점이었다. 컴포넌트 이름, 상태 정의, 라이브러리 조직 방식 — 이게 엉망이면 에이전트도 엉뚱한 걸 가져오고, 반대로 구조가 잡혀 있으면 알아서 맞는 컴포넌트를 찾아온다는 논리였다.

Decagon 팀이 자체 컴포넌트 라이브러리(Deco)를 만들어서 한 달 동안 팀 내에서 수만 번 삽입됐다고 했는데, 그게 단순히 “라이브러리를 잘 만들었다”는 얘기가 아니라 AI가 그 라이브러리를 정확히 참조할 수 있도록 구조를 맞췄기 때문이라는 인상이 들었다.

💡 여기서 드는 질문: AI 도구를 더 잘 활용하려면, 결국 내 파일 구조부터 먼저 정리해야 한다는 거 아닐까?

Storybook 연동 얘기도 나왔다. 디자인 컴포넌트와 코드 컴포넌트가 같은 이름으로 연결돼 있을 때 에이전트의 정확도가 높아진다고 했다. 디자이너-개발자 사이의 네이밍 간극이 AI 아웃풋에도 영향을 준다는 얘기여서 꽤 인상적으로 읽혔다. 디자이너가 컴포넌트 이름을 지을 때 코드와 맞추는 일이 AI 시대에는 더 직접적인 의미를 갖는 것 같다는 생각이 들었다.

⭐️ 마지막으로, 디자인 시스템 공부하면서 느낀 점

정리해보니 이 글이 말하는 건 AI 도구 자체보다 디자인 시스템을 얼마나 체계적으로 유지하느냐에 가까운 것 같았다. Figma MCP나 Figma Make가 아무리 좋아도, 기반이 되는 파일 구조가 허술하면 아웃풋도 허술해진다는 논리였으니까.

공부 끝에 남은 건 “AI 도구의 정확도는 결국 내 디자인 파일의 품질을 따라간다”는 한 줄짜리 인상이다.

---

참고 원문: How Decagon uses AI for design system saturation