MCP로 바뀐 디자인 작업의 흐름
팀스파르타 디자인팀에는 5개 브랜드가 함께 사용하는 멀티브랜드 디자인시스템, 'STACK'이 있어요.
올해 1월, 이 시스템이 어떻게 쓰이고 있는지 살펴보기 위해 디자이너 8명, 개발자 11명을 대상으로 설문을 진행했어요. 만족도는 디자이너 4.5점, 개발자 4.7점으로 꽤 높은 편이었죠.
인터뷰를 진행하며 가장 흥미로웠던 점은, 개발자분들이 이미 MCP(Model Context Protocol)를 실무에 깊숙이 활용하고 계셨다는 거예요.
프론트 작업을 할 때 두 가지 MCP를 함께 사용해 업무 시간을 크게 단축하고 있었어요.
Figma MCP: Figma에서 공식 제공하는 MCP로, Figma 파일의 구조와 속성을 읽어오는 역할을 해요.
Stack MCP: STACK 디자인시스템의 컴포넌트 문서와 가이드를 코드에 매칭하는 역할을 해요.
디자이너가 디자인 파일을 넘기면, 개발자는 이를 AI에게 읽혀서 코드를 짜는 방식이에요. 이 조합을 통해 UI 마크업의 약 70~80%가 자동으로 생성되고 있었습니다. 설문에 참여한 개발자 11명 전원이 Figma MCP를, 8명은 Stack MCP까지 함께 사용하고 있었어요.
이전의 개발 방식
1. Figma 파일을 열고 디자인을 눈으로 확인해요.
2. 어떤 컴포넌트를 쓸지 고민하고, 스토리북에서 Props를 일일이 찾아봐요.
3. 직접 코드를 작성한 뒤, 디자인과 대조하며 수정해요.
지금의 개발 방식
1. Figma MCP가 디자인 파일의 구조와 속성을 자동으로 읽어와요.
2. Stack MCP가 디자인 요소와 실제 코드를 매칭해 줘요.
3. UI 마크업의 70~80%가 자동으로 생성돼요.
"두 MCP를 함께 사용하고 나서 단순 마크업 작업 시간이 50% 이상 줄었어요. 지금은 로직에 더 집중할 수 있게 됐습니다." — 프론트엔드 개발자 인터뷰
실제로 디자이너인 저도 MCP를 활용해 직접 구현해봤어요. 5분 만에 디자인시스템을 활용한 화면을 뚝딱 만들어줬습니다. 버튼 컬러를 primary 대신 error로 잘못 적용하거나, 아이콘을 빠뜨리거나 시스템 내에 유사한 아이콘을 대신 사용하는 등 손볼 부분들이 있기는 했지만요.
AI를 통해 80%를 자동화했지만, 완성도를 위해 개발자가 추가로 개입해야 하는 상황은 여전히 남아 있었어요. 크게 세 가지 경우에서 추가 작업이 필요했습니다.
① AI가 불필요한 신규 컴포넌트를 만들어냈어요
기존 시스템으로 충분히 구현할 수 있는 화면인데도, AI가 새로운 컴포넌트를 만들어버리는 경우가 있었어요. 규칙을 벗어나지 않도록 개발자분이 계속해서 제약을 걸거나 수정을 요청해야 하는 번거로움이 생겼습니다.
② 한 끗 차이의 네이밍이 발목을 잡았어요
이름이 달라지면 MCP는 둘을 서로 다른 객체로 인식해요. 예를 들어 Figma의 속성명이 color로 되어 있어도 코드에서는 colorScheme으로 쓰이는 경우, AI가 이 둘을 같은 것으로 연결하지 못했습니다. 그러다 보니 중간에서 개발자가 이름을 매칭해야하는 상황이 생기곤 했어요.
③ 디자이너의 의도가 AI에게 온전히 전달되지 않았어요
Figma와 똑같이 구현했는데도 문제가 되는 경우가 있었어요.
기존에는 디자이너가 Fixed / Fill / Hug 설정을 Figma에서 꼼꼼히 지정하기보다, 별도 주석으로 반응형이나 옵션 정보를 전달하는 방식을 사용했어요. 개발자분들은 화면과 주석을 함께 살펴보시면서 맥락을 자연스럽게 파악해 주셨거든요.
그런데 MCP로 화면을 구현할 때는 화면을 하나씩 분석하다 보니, 전체 흐름보다 화면 하나하나의 데이터에 집중해요. 주석의 의도는 읽지 못한 채, 적혀 있는 수치 그대로를 코드로 옮겨버리는 거예요. 결국 개발자분들이 다시 주석을 읽고 의도에 맞게 수정하는 과정이 반복됐습니다.
저희는 이 20%의 간극을 줄이는 것이 디자인시스템 TF의 다음 과제라고 생각했어요. AI가 디자인 의도를 정확하게 읽을 수 있도록 3가지를 개선했어요.
반복을 줄이는 '스킬(Skill)' 정의
매번 같은 지시를 반복하지 않아도 되도록 자주 쓰는 패턴을 Claude 스킬로 정의했어요. 디자인시스템 TF 개발자 혜성님이 작업해 주셨어요.
스킬의 핵심은 간단해요. AI가 코드를 짜기 전에 MCP로 실제 컴포넌트 스펙을 먼저 확인하게 하고, 그 스펙에서 벗어나지 않도록 규칙을 명시해두는 거예요.
덕분에 존재하지 않는 props를 넣어 타입 오류를 내는 현상, STACK 컴포넌트 대신 div로 직접 구현해버리는 현상, props 대신 인라인 스타일로 CSS를 주입하는 현상, 컬러값을 하드코딩하거나 토큰을 vars로 가져오지 않는 현상 등 매번 수정 요청을 반복해야 했던 작업들이 눈에 띄게 줄었어요.
디자이너인 저도 직접 사용해봤는데, 스킬 없이 MCP만 사용했을 때와 비교해보니 차이가 꽤 컸어요. 확실히 STACK 컴포넌트를 훨씬 더 적절하게 사용하고, 원본 디자인과의 유사도도 높아졌거든요.
컴포넌트 네이밍 일치
Figma의 Props 이름과 코드의 속성명을 1:1로 맞추는 것이 이상적이지만, 기존에 맞지 않던 이름들은 코드 전체를 바꿔야 하는 작업이라 현실적으로 쉽지 않았어요.
그래서 택한 방법은 스킬에 매핑 지침을 넣어두는 것이었어요. 예를 들어 Figma의 color는 코드의 colorScheme을 참고하면 된다는 식으로요. 기존 코드는 그대로 두되, AI가 스스로 연결할 수 있도록 다리를 놓아준 거예요. 이후 새로 만드는 컴포넌트부터는 처음부터 이름을 통일해 나가기로 했습니다.
피그마 핸드오프 가이드 제작
마지막으로 디자이너의 작업 방식 자체에 변화가 필요하다고 생각했어요. 설명과 주석을 꼼꼼히 다는 것보다, Figma 화면의 데이터만으로 의도를 전달하는 것이 중요해진거죠. 그래서 AI 친화적으로 디자인을 전달할 수 있는 핸드오프 가이드를 정리했습니다.
예를 들면 반응형이 필요한 요소는 Fixed 프레임 대신 Auto Layout으로 구성하거나 연관된 컴포넌트는 하나로 묶어 AI가 맥락을 파악할 수 있도록요. 사람이라면 맥락으로 읽어낼 수 있는 것들을, AI도 데이터로 정확하게 읽을 수 있도록 디자인 방식 자체를 다듬었어요.
단, 규칙이 많아지면 디자이너의 부담도 커지기 때문에 AI 품질에 실질적인 영향을 미치는 것들만 가이드로 만들었어요. 예를들어 레이어 네이밍은 작업 품질에 큰 영향을 주지 않아서, 여전히 디자이너 자율로 남아있어요.
디자인시스템은 앞으로 더 중요해질 거예요.
잘 만들어진 디자인시스템은 사람만이 아니라 AI도 잘 읽을 수 있어요. 그리고 그게 가능해지면 직무의 경계도 자연스럽게 허물어지기 시작해요. 팀스파르타에서는 지금도 디자이너뿐 아니라 PM, 피플매니저 등 다양한 직군이 STACK을 활용해 직접 제품을 만들고 있고요.
물론 아직 완벽하진 않아요. AI가 놓치는 디테일도 있고, 사람의 판단이 필요한 순간도 여전히 많아요. 그래서 팀스파르타는 지금도 더 정교한 디자인시스템을 만들기 위해 계속 고민하고 있어요.
앞으로 소개드릴 이야기들도 기대해 주세요.
by 조정한, 프로덕트 디자이너