디자인시스템 + MCP로 UI 마크업 80%를 자동화한 팀의 기록

팀스파르타 디자인팀에는 5개 브랜드가 함께 쓰는 멀티브랜드 디자인시스템 'STACK'이 있어요. 올해 1월, 이 시스템이 실제로 어떻게 쓰이고 있는지 알아보려고 디자이너 8명, 개발자 11명을 대상으로 설문을 돌렸는데요. 만족도가 디자이너 4.5점, 개발자 4.7점이었어요. 꽤 높은 편이죠.

근데 설문보다 인터뷰가 더 흥미로웠어요. 개발자분들이 이미 MCP를 실무에 깊숙이 쓰고 있었거든요. "아, 이 정도까지 왔구나" 싶었답니다.

Figma MCP + Stack MCP 조합이 만들어낸 70~80%

프론트 작업에 두 가지 MCP를 함께 쓰고 있었어요. Figma MCP는 피그마 파일의 구조와 속성을 읽어오는 역할이고, Stack MCP는 STACK 디자인시스템의 컴포넌트 문서와 가이드를 실제 코드에 매칭해주는 역할이에요.

디자이너가 디자인 파일을 넘기면, 개발자는 이걸 AI에게 읽혀서 코드를 짭니다. 이 조합으로 UI 마크업의 약 70~80%가 자동 생성되고 있었어요. 설문에 참여한 개발자 11명 전원이 Figma MCP를, 8명은 Stack MCP까지 함께 쓰고 있었고요.

이전이랑 비교하면 차이가 확실해요.

예전에는 Figma 파일을 열고 디자인을 눈으로 확인한 다음, 어떤 컴포넌트를 쓸지 고민하고, 스토리북에서 Props를 일일이 찾아보고, 직접 코드를 작성한 뒤 디자인과 대조하며 수정했어요. 지금은? Figma MCP가 디자인 파일의 구조와 속성을 자동으로 읽어오고, Stack MCP가 디자인 요소와 실제 코드를 매칭해주고, UI 마크업의 70~80%가 자동으로 생성돼요.

"두 MCP를 함께 사용하고 나서 단순 마크업 작업 시간이 50% 이상 줄었어요. 지금은 로직에 더 집중할 수 있게 됐습니다." — 프론트엔드 개발자 인터뷰

디자이너인 글 작성자도 직접 MCP를 활용해 구현해봤다고 해요. 5분 만에 디자인시스템을 활용한 화면을 뚝딱 만들어줬는데, 버튼 컬러를 primary 대신 error로 잘못 적용하거나 아이콘을 빠뜨리는 등 손볼 부분들이 있기는 했다고요.

80%가 자동화됐다. 괜찮은 숫자죠. 근데 나머지 20%가 문제였어요.

나머지 20%를 잡아먹는 세 가지 함정

AI를 통해 80%를 자동화했지만, 완성도를 위해 개발자가 추가로 개입해야 하는 상황이 여전히 남아 있었어요.

첫 번째. AI가 불필요한 신규 컴포넌트를 만들어내는 경우예요.

기존 시스템으로 충분히 구현할 수 있는 화면인데도 AI가 새로운 컴포넌트를 만들어버려요. 규칙을 벗어나지 않도록 개발자가 계속 제약을 걸거나 수정을 요청해야 했습니다. 솔직히 이건 좀 웃긴 상황이에요. 자동화를 했는데 "자동화가 만든 실수를 잡는 작업"이 추가된 거니까요.

두 번째. 한 끗 차이의 네이밍이 발목을 잡았어요.

이름이 달라지면 MCP는 둘을 서로 다른 객체로 인식합니다. Figma의 속성명이 `color`로 되어 있어도 코드에서는 `colorScheme`으로 쓰이면, AI가 이 둘을 같은 것으로 연결하지 못해요. 사람이라면 "아, 이거 같은 거지"라고 바로 알텐데. 결국 중간에서 개발자가 이름을 매칭하는 수작업이 생겼어요.

세 번째. 디자이너의 의도가 AI에게 온전히 전달되지 않았어요.

기존에는 디자이너가 Fixed / Fill / Hug 설정을 피그마에서 꼼꼼히 지정하기보다, 별도 주석으로 반응형이나 옵션 정보를 전달하는 방식이었거든요. 개발자분들은 화면과 주석을 함께 보면서 맥락을 자연스럽게 파악해 주셨고요.

근데 MCP는 다릅니다. 화면 하나하나의 데이터에 집중하다 보니 주석의 의도는 읽지 못한 채, 적혀 있는 수치 그대로를 코드로 옮겨버려요. 개발자분들이 다시 주석을 읽고 의도에 맞게 수정하는 과정이 반복됐습니다. 사람 사이에서는 "말 안 해도 아는" 맥락이, AI에게는 전달되지 않는 거죠.

20%를 줄이기 위해 바꾼 세 가지

팀스파르타는 이 간극을 줄이는 것이 디자인시스템 TF의 다음 과제라고 봤어요. AI가 디자인 의도를 정확하게 읽을 수 있도록 3가지를 개선했습니다.

반복을 줄이는 '스킬(Skill)' 정의.

매번 같은 지시를 반복하지 않도록 자주 쓰는 패턴을 Claude 스킬로 정의했어요. AI가 코드를 짜기 전에 MCP로 실제 컴포넌트 스펙을 먼저 확인하게 하고, 그 스펙에서 벗어나지 않도록 규칙을 명시해두는 거예요.

덕분에 존재하지 않는 props를 넣어 타입 오류를 내는 현상, STACK 컴포넌트 대신 div로 직접 구현해버리는 현상, props 대신 인라인 스타일로 CSS를 주입하는 현상, 컬러값을 하드코딩하는 현상 등이 눈에 띄게 줄었어요. 스킬 없이 MCP만 사용했을 때와 비교하면 차이가 꽤 컸다고 합니다. STACK 컴포넌트를 훨씬 더 적절하게 사용하고, 원본 디자인과의 유사도도 높아졌고요.

컴포넌트 네이밍 일치. Figma의 Props 이름과 코드의 속성명을 1:1로 맞추는 게 이상적이지만, 기존에 맞지 않던 이름들은 코드 전체를 바꿔야 하는 작업이라 현실적으로 쉽지 않았어요. 그래서 스킬에 매핑 지침을 넣어뒀어요. "Figma의 color는 코드의 colorScheme을 참고하면 된다"는 식으로요. 기존 코드는 그대로 두되, AI가 스스로 연결할 수 있도록 다리를 놓아준 겁니다. 새로 만드는 컴포넌트부터는 처음부터 이름을 통일해 나가기로 했고요.

피그마 핸드오프 가이드 제작.

마지막으로 디자이너의 작업 방식 자체를 바꿨어요. 설명과 주석을 꼼꼼히 다는 것보다, Figma 화면의 데이터만으로 의도를 전달하는 게 중요해진 거죠. 반응형이 필요한 요소는 Fixed 프레임 대신 Auto Layout으로 구성하고, 연관된 컴포넌트는 하나로 묶어 AI가 맥락을 파악할 수 있도록 했습니다.

단, 규칙이 많아지면 디자이너 부담도 커지기 때문에 AI 품질에 실질적인 영향을 미치는 것들만 가이드로 만들었어요. 레이어 네이밍 같은 건 작업 품질에 큰 영향을 주지 않아서 디자이너 자율로 남겨뒀고요. (전부 규칙으로 묶어버리면 "AI를 위해 일하는 디자이너"가 되는 거니까요.)

디자인시스템은 이제 사람만 읽는 게 아니다

잘 만들어진 디자인시스템은 사람뿐 아니라 AI도 잘 읽을 수 있어요. 그리고 그게 가능해지면 직무의 경계가 허물어지기 시작합니다. 팀스파르타에서는 지금도 디자이너뿐 아니라 PM, 피플매니저 등 다양한 직군이 STACK을 활용해 직접 제품을 만들고 있다고 해요.

물론 아직 완벽하진 않아요. AI가 놓치는 디테일도 있고, 사람의 판단이 필요한 순간도 여전히 많습니다. 80%를 자동화했다고 나머지 20%가 쉽다는 뜻은 아니거든요. 오히려 그 20%가 "진짜 디자인시스템의 품질"을 결정짓는 영역이에요.