[번역] 디자인 핸드오프를 위한 MCP 클라이언트

원문
https://www.builder.io/blog/mcp-client-for-design-handoffs

The MCP Client for Design Handoffs

---

지난 몇 달 동안 우리는 Model Context Protocol(MCP)을 기초부터 다뤄왔습니다. MCP가 무엇인지, 왜 중요한지부터 시작해서 AI 에이전트를 위한 MCP 서버 도구를 직접 만드는 방법까지 살펴봤습니다.

 

MCP 서버 생태계는 빠르게 확장되고 있습니다. 하지만 여기서 더 흥미로운 다음 질문이 생깁니다. 이렇게 강력한 도구들이 많아진 지금, 우리는 이걸 실제 웹 개발에 어떻게 활용할 수 있을까요?

 

그 해답은 MCP 클라이언트에 있습니다.

MCP 클라이언트란 무엇인가?

MCP 아키텍처에서 사용자가 직접 상호작용하는 애플리케이션 — 예를 들어 Cursor 같은 IDE, Claude Desktop 같은 챗봇, 또는 Builder의 Fusion과 같은 시각적 웹 캔버스 — 는 호스트(host)라고 불립니다. MCP 클라이언트는 이러한 호스트 내부에 존재하는 구성 요소이며, 하나의 주요 역할을 가지고 있습니다. 바로 MCP 서버와의 전용 1:1 연결을 관리하는 것입니다.

 

MCP 클라이언트는 모든 중요한 통신을 처리합니다: 서버가 어떤 도구와 데이터를 제공하는지 탐색하고, 해당 서버로 요청을 전달하며, 그 응답을 다시 호스트 애플리케이션으로 전달합니다.

 

관심 있는 분들을 위해 Model Context Protocol과 그 구성 요소에 대한 완전한 분석이 제공되어 있습니다.

오늘날 개발을 위한 MCP 클라이언트의 현황

그렇다면 웹 개발자에게 오늘날 이러한 MCP 클라이언트는 어떤 모습일까요? 이들은 일반적으로 두 가지 범주로 나뉘며, 각각 자체적으로는 강력하지만 웹을 구축하는 데 있어서는 중요한 사각지대를 가지고 있습니다.

대화형 MCP 클라이언트

첫 번째로, Claude Desktop 앱과 같은 채팅 기반 호스트가 있습니다. 이들은 대화형 질의에 매우 적합합니다. 회사의 데이터베이스를 MCP 서버로 연결해두고, "지난주에 신규 사용자가 몇 명이었나요?"라고 물으면 즉시 정확한 답변을 받을 수 있습니다.

 

하지만 요청에 UI가 포함되는 순간 한계에 부딪힙니다. "해당 사용자 데이터를 시각화하는 반응형 대시보드를 만들어 주세요"라고 요청하면 더 이상 진행할 수 있는 곳이 없습니다. 해당 클라이언트에는 시각적 캔버스도 없고, 컴포넌트 개념도 없으며, 요청한 내용을 렌더링할 방법도 없습니다. 즉, 이 인터페이스는 시각적으로 무언가 만드는 작업에는 단순히 적합하지 않습니다.

IDE 기반 MCP 클라이언트

두 번째 범주는 IDE 기반 호스트로, Cursor와 Windsurf와 같은 것들입니다. 이 영역은 개발자들에게 정말 흥미로운 부분입니다. Notion 서버를 연결해 팀 문서를 최신 상태로 유지하고, 이후 프롬프트로 개선 작업을 할 때 그 컨텍스트를 자동으로 활용할 수 있습니다. 또한 Figma MCP 서버를 연결하여 스크린샷이 아닌 실제 디자인 컴포넌트를 기반으로 코드를 생성할 수도 있습니다.

 

이러한 방식은 MCP의 핵심 약속인 "이식성"을 작업 흐름 안으로 직접 가져옵니다. 조직은 내부 디자인 시스템을 위한 MCP 서버를 한 번만 구축하면 되고, 모든 개발자가 이를 사용할 수 있습니다. 개발자 입장에서는 매우 세련되고 강력한 구성입니다.

 

하지만 제품 관리자나 디자이너가 해당 티켓들의 모음을 기반으로 새로운 기능을 시각적으로 프로토타입하고 싶어 한다면 어떻게 될까요? 그들에게는 동일한 IDE가 텍스트만 가득한 위압적인 벽처럼 느껴지고, 결국 실제 소스의 진실인 코드 저장소와 동기화되지 않는 Figma나 채팅 앱에 머물 수밖에 없습니다. 그 결과 더 많은 작업이 개발자에게 넘어가게 됩니다.

MCP만으로 컨텍스트를 공유할 때의 문제

이상적으로는 MCP의 세계가 휴대 가능한 팀 컨텍스트 덕분에 팀원들을 더 잘 연결하고 디자인 핸드오프를 더 쉽게 만들어야 합니다. 하지만 실제로는 각 역할이 여전히 비교적 분리되어 있으며, 공유되는 컨텍스트는 실행 가능한 코드보다는 주요 텍스트와 이미지 형태로 존재합니다.

 

개발자는 실제 코드를 만들면서 엣지 케이스를 발견하고, 디자이너는 다양한 상태를 목업으로 만들어야 합니다. 실제로 기능을 사용하는 방식은 이상적으로 정의된 사용자 스토리와 크게 다를 수 있으며, 팀은 컴포넌트가 개발된 이후에야 사용성을 테스트할 수 있기 때문에 중요한 시간을 낭비할 수 있습니다.

Fusion: 디자인 핸드오프를 위한 MCP 클라이언트

해결책은 또 하나의 과하게 특화된 클라이언트가 아닙니다. 대신, 팀 전체가 함께 사용할 수 있는 공유된 시각적 코드 컨텍스트를 만들고, 모두가 이미 사용하고 있는 도구들과 연결할 수 있는 MCP 기능을 갖춘 클라이언트입니다.

 

이러한 이유로 저희는 Fusion을 만들었습니다. Fusion은 웹을 위한 시각적 AI 캔버스로, 제품 팀을 위한 오케스트레이션 허브 역할을 합니다. 이 도구는 웹 애플리케이션과 VS Code 확장으로 모두 동작하며, 기존 저장소에 연결되어 누구나 브랜치를 생성하고 기여할 수 있게 합니다.

 

그렇다면 Fusion이 각 팀 구성원에게 자신의 역할에 맞는 적절한 인터페이스를 어떻게 제공하는지, 그리고 동시에 다른 팀원들과의 번거로운 반복적인 소통을 어떻게 줄이는지 살펴보겠습니다.

제품 관리자

제품 관리자는 새로운 기능, 컴포넌트 또는 페이지에 대해 명확한 비전을 가지고 있는 경우가 많습니다. 일반적으로 이들은 PRD를 디자이너와 개발자에게 전달하지만, 그 말이 실제 디자인과 코드로 변환되는 과정에서 많은 반복 작업이 발생할 수 있습니다.

 

보다 숙련된 PM들은 Bolt, Lovable, v0와 같은 AI 프로토타이핑 도구를 사용할 수도 있습니다. 하지만 이러한 도구들의 문제는 항상 처음부터 시작해야 한다는 점이며, 실제 코드 저장소를 기반으로 작업하는 것이 아니라는 점입니다.

 

Fusion에서는 PM이 실제 컴포넌트가 존재하는 기존 브랜치 위에서 자신의 아이디어에 대한 모든 엣지 케이스를 구체화할 수 있습니다. 전체 페이지를 새로 만드는 것부터 버튼 텍스트를 수정하는 것까지, 다양한 수준의 변경을 프롬프트로 요청할 수 있습니다.

 

또는 MCP 클라이언트 기능을 활용하여, AI가 까다로운 티켓에 대해 먼저 1차 작업을 수행할 수 있도록 할 수 있습니다.

중요한 점은 Fusion이 조직의 저장소 위에 AI 기반 추상화 계층을 제공한다는 것입니다. 이를 통해 각 주요 변경 세트마다 브랜치를 생성하고, 모든 PR에 대해 미리보기 URL을 생성합니다.

 

새로운 기능이 여전히 픽셀 단위의 정교함을 위해 디자이너를 필요로 하거나, 최종 최적화를 위해 개발자를 필요로 하더라도, PM은 이미 실제와 동일한 캔버스 위에서 전체 사용자 스토리를 모두 구체화할 수 있게 됩니다.

디자이너

디자이너는 이제 PM으로부터 전달된 텍스트 문서에서 시작하는 대신, 모든 상태가 이미 준비된 동작하는 프로토타입에서 작업을 시작하게 됩니다.

 

많은 팀의 경우, 이것만으로도 충분할 수 있습니다. 디자이너는 Figma와 유사한 인터페이스에서 시각적인 조정을 직접 수행하여 원하는 수준으로 다듬을 수 있고, 이후 AI가 해당 변경 사항을 GitHub 브랜치에 적용하도록 할 수 있습니다.

또는, Figma로 다시 돌아가야 하는 경우에도 문제없습니다. Fusion은 Figma 토큰과 동기화할 수 있어서, 디자인을 가져올 때 픽셀 단위로 정확한 프레임을 코드베이스에 직접 추가할 수 있습니다.

어떤 방식이든, 이제 디자이너는 자신의 역량을 직접 저장소에 기여할 수 있으며, Figma 프레임이 웹으로 변환되는 과정에서 왜곡되거나 훼손될 것을 더 이상 걱정하지 않아도 됩니다.

개발자

PM이나 디자이너로부터 전달받은 결과를 통해, 개발자는 이제 단순히 시각적으로 완성된 상태뿐 아니라 익숙한 컴포넌트와 스타일로 구조화된 핸드오프를 받게 됩니다. 개발자의 역할은 처음부터 다시 만드는 것이 아니라 기능을 다듬고 완성도를 높이는 것입니다.

 

이 지점에서 Fusion이 MCP 오케스트레이션 허브로서 가지는 강점이 더욱 흥미롭게 드러납니다. 예를 들어 개발자가 회원가입 폼을 여러 백엔드 서비스와 연결해야 하는 상황을 생각해보면:

"For this sign-up form:
- On submit, use the Stripe MCP server to create a new trial customer. 
- Use the HubSpot MCP server to add that customer to our 'New Trial Users' marketing list.
- Use the Linear MCP server to close the original feature ticket and post a comment that the page is live."

 

Fusion 내에 모든 데이터 소스가 연결되어 있는 한, 가능한 조합에는 제한이 없습니다.

 

또는 필요한 변경이 훨씬 작은 경우도 있습니다. 이때 개발자는 GitHub 안에 머무른 상태로 비동기 Builder 에이전트를 사용할 수 있습니다.

전체 워크플로우가 조직의 실제 저장소에 있는 실제 코드를 중심으로 구성되어 있기 때문에, 개발자는 더 정교한 작업이 필요한 경우 언제든지 IDE로 이동할 수 있습니다.

팀 전체를 위한 MCP 클라이언트

Fusion은 이러한 공통 기반 역할을 합니다. 코드베이스와 디자인 자산에 대한 깊고 네이티브한 이해를 Model Context Protocol의 무한한 확장성과 결합함으로써, 모든 팀원이 효과적으로 기여할 수 있는 단일 환경을 만들어냅니다.

 

이로써 디자인, 제품, 엔지니어링 사이의 간극을 마침내 연결하며, 우리는 고립된 도구들을 만드는 단계에서 벗어나 진정으로 협업적인 에이전트 기반 워크플로우를 구축하는 방향으로 이동하게 됩니다.

 

지금 Fusion을 사용해 보십시오.