Frameout은 이용자의 개인정보를 소중히 여기며, 개인정보 보호법 등 관련 법령을 준수합니다. 수집된 개인정보는 서비스 제공 및 상담, 제안서 접수 등 정해진 목적 외에는 사용되지않습니다. 또한, 이용자의 동의 없이는 개인정보를 외부에 제공하지 않습니다.
Frameout은 입사지원 및 제안 요청/상담을 위해 이름, 연락처, 이메일 주소 등의 정보를 수집합니다. 수집된 정보는 입사지원 및 채용전형 진행, 입사지원정보 검증을 위한 제반 절차 수행과 제안서 작성, 상담 응대 등 업무 처리 목적에 한해 이용됩니다. 해당 정보는 제3자에게 제공하거나 입사 진행 절차 이외에는 사용하지 않습니다. 이용자는 개인정보 제공에 동의하지 않을 수 있으며, 미동의 시 일부 서비스 이용이 제한될 수 있습니다.
수집된 개인정보는 수집 목적 달성 후 즉시 파기되며, 보관이 필요한 경우 관련 법령에 따라 일정 기간 보관됩니다. 기본 보유 기간은 1년이며, 이후에는 지체 없이 안전하게 삭제됩니다. 이용자는 언제든지 개인정보 삭제 요청이 가능합니다.
2024년 11월, Anthropic이 발표한 MCP(Model Context Protocol)는 처음엔 기술 커뮤니티에서 조용히 주목받았다. 하지만 지난 3개월간 개발자들과 기업들이 실제 사례를 공개하면서, 이것이 단순한 API 표준이 아니라 AI 워크플로우 자동화의 '새로운 기준'임을 깨닫기 시작했다.
MCP의 등장 이전, AI를 사용해서 업무를 자동화하려는 팀들은 항상 같은 문제에 부딪혔다. ChatGPT나 Claude에게 '이 Figma 파일을 분석해서 Webflow로 만드는 CSS를 생성해줘'라고 요청해도, AI가 실제로 Figma에 접근할 수 없다는 것이다. 개발자가 Figma 파일을 다운로드해서 AI에게 보여주고, AI의 출력을 다시 Webflow에 복붙하고... 이 반복이 결국 인간만큼 느린 '자동화'를 만들었다.
MCP는 이 문제를 우아하게 해결한다. 간단히 말해서, MCP는 AI가 도구를 직접 사용할 수 있도록 해주는 프로토콜이다. Figma, GitHub, Slack, Webflow, Airtable 등의 서비스와 연결된 '리소스'에 AI가 접근하고, 필요할 때 직접 조작할 수 있다는 뜻이다.
초기 AI 자동화 시도들은 매우 제한적이었다. Zapier, IFTTT, Make(구 Integromat) 같은 플랫폼들이 '조건부 자동화'를 가능하게 했지만, 이들도 결국 '미리 정의된 워크플로우'만 자동화할 수 있었다.
예를 들어, 당신이 'Figma에서 디자인이 업데이트되면 Slack에 알림을 보내기' 같은 자동화를 원한다면 가능했다. 하지만 'Figma의 최신 디자인을 분석해서 자동으로 Webflow 페이지를 업데이트하기'는 불가능했다. 왜냐하면 이는 '스마트한 의사결정'을 요구하기 때문이다. 단순히 '이벤트 발생 → 액션 실행'의 구조가 아니라, '상황을 이해 → 적절한 변환 수행 → 검증 → 배포' 같은 복합적 사고가 필요하다.
ChatGPT 시대가 오면서, 기업들은 새로운 방식을 시도했다. API를 통해 ChatGPT를 호출하고, 프롬프트로 복잡한 작업을 지시하는 것이다. 한 디자인 에이전시는 다음과 같은 워크플로우를 구축했다고 보고했다:
이것이 '자동화'처럼 보였지만, 실제로는 '90%만 자동화된' 워크플로우였다. 마지막 10%인 Webflow 업데이트는 여전히 사람이 해야 했다. 또한 ChatGPT의 응답을 신뢰할 수 없었다. 때로는 CSS가 틀렸거나, 마크업이 이상하거나, Webflow의 제약을 고려하지 못한 경우가 많았다.
더 큰 문제는 '반복 불가능성'이었다. 프롬프트의 미세한 변화, ChatGPT의 모델 업데이트, 맥락 손실 등으로 인해 같은 입력이 다른 출력을 만들어냈다. 팀이 이 자동화를 믿고 의존할 수 없었던 이유다.
2023년, Anthropic의 Claude, OpenAI의 GPT-4 Vision, Google의 Gemini 같은 강력한 모델들이 등장하면서, 개발자들은 더 야심찬 자동화를 시도하기 시작했다. 함수 호출(Function Calling) 기능을 사용해서, AI가 도구를 호출할 수 있게 만들었다.
예를 들어, 한 금융 기술 회사는 Claude를 'AI 에이전트'로 설정했다. 사용자가 'Slack에 우리 팀의 Q1 목표를 업로드해줘'라고 말하면, Claude가 다음을 수행했다:
하지만 이것도 완전하지 않았다. 각 서비스(Airtable, Slack, GitHub 등)마다 API를 다르게 연결해야 했고, 에러 처리, 인증, 레이트 리미트 관리 모두가 매번 새로 구현되어야 했다. 또한 수백 개의 서비스에 각각 다른 방식으로 연결되어 있으면, AI가 모든 API를 '이해'하기 어려웠다.
MCP는 매우 간단한 아이디어로 시작한다. '모든 서비스가 같은 방식으로 AI와 대화할 수 있도록 하자'는 것이다.
기존 방식: AI ↔ [API 1] [API 2] [API 3] ... (각각 다른 형식)
MCP 방식: AI ↔ [MCP 표준] ↔ [Figma] [Webflow] [Slack] [GitHub] (모두 같은 프로토콜)
MCP를 사용하는 서비스들은 표준화된 인터페이스를 제공한다:
이미 여러 서비스들이 MCP 지원을 발표했다. 특히 디자인 업계에서 주목할만한 것들이 있다:
Figma MCP: Figma는 2025년 초 공식적으로 MCP 서포트를 발표했다. 이제 AI 에이전트는 다음을 할 수 있다:
중요한 것은 이 모든 것이 '동일한 프로토콜'로 이루어진다는 것이다. AI 에이전트 개발자가 Figma API의 세부사항을 알 필요가 없다. MCP 표준에 따라 'Resources'와 'Tools'를 요청하면 된다.
Webflow MCP: Webflow는 초기부터 'No-Code 플랫폼에서 AI와의 통합'을 중시했고, 2025년 MCP 지원을 추가했다. 이제 AI는 다음을 할 수 있다:

한 콘텐츠 마케팅 회사의 실제 사례를 보자. 이 회사는 매주 새로운 랜딩페이지를 만든다. 과거에는:
MCP 기반의 자동화를 도입한 후:
이것이 가능한 이유는, MCP가 AI에게 '진정한 손과 발'을 준 것이기 때문이다. 단순히 '문서로 지시하는 것'이 아니라, 실제로 Figma와 Webflow에 접근해서 직접 조작할 수 있다.
한 전자상거래 회사의 경우, 상황이 더 복잡했다. 이들은 매월 1000개 이상의 상품 페이지를 만들어야 했다. 각 상품마다 다른 레이아웃, 다른 이미지, 다른 설명이 필요했다.
MCP 기반 솔루션은 다음과 같이 작동했다:
이 과정이 자동으로 1000개 상품마다 수행된다. 과거에는 디자이너 4명이 2주 정도 걸렸던 작업이 이제는 AI가 밤사이 완료한다. 디자이너들은 '예외 케이스 처리'와 '디자인 품질 검수'에만 집중하면 된다.

과거 디자인 시스템은 '정적인 컴포넌트 라이브러리'였다. 디자이너가 필요한 컴포넌트를 찾아서 조합했다.
MCP 시대에는 디자인 시스템이 '지능형'이 될 수 있다. 예를 들어:
이는 자동 레이아웃, 변수, 컴포넌트의 조합이 AI 에이전트의 문맥 이해와 만나면서 가능해진다.
한국의 한 SaaS 회사는 12개 언어로 마케팅 웹사이트를 유지해야 했다. 기존에는 번역 후 각 언어별로 따로 디자인을 조정했다. 텍스트 길이가 언어마다 다르기 때문이다. (예: 독일어는 영어보다 길다)
MCP 기반 솔루션:
이 과정이 '1회'만 수행되어야 하는 것이 아니라, 마케팅팀이 영어 버전을 업데이트할 때마다 자동으로 12개 사이트가 모두 동기화된다.
한 금융 서비스 회사는 실시간으로 변하는 시장 데이터에 따라 대시보드를 업데이트해야 한다. 예를 들어, 특정 상품의 수익률이 급변하면, 그에 맞춰 대시보드의 강조 색상, 경고 레벨, 정보 구조가 변경되어야 한다.
MCP 없이는 이를 자동화할 수 없었다. 하지만 MCP를 사용하면:
이제 '사람이 개입할 여지'가 거의 없다. 데이터 → 디자인 → 배포까지 완전히 자동화되는 것이다.
MCP가 AI에게 강력한 권한을 주는 만큼, 보안이 가장 큰 우려사항이다. 만약 AI 에이전트가 해킹되면, 모든 연결된 서비스(Figma, Webflow, GitHub 등)가 위험에 노출될 수 있다.
현재 MCP 구현들은 '토큰 기반 인증'을 사용한다. 하지만 더 세밀한 권한 관리 (예: '이 Figma 팀의 파일만 읽기')가 필요하다는 의견이 커지고 있다.
MCP를 통해 AI가 도구를 사용할 수 있지만, 여전히 '단순한 작업'에만 효과적이다. 예를 들어:
후자는 여전히 사람의 전략적 판단이 필요하다.
자동화된 워크플로우가 실패하면 어떻게 하는가? 예를 들어, Webflow API가 일시적으로 응답하지 않으면? 현재 MCP 표준은 '기본적인 재시도' 정도만 정의하고 있고, 더 정교한 에러 처리는 각 구현에 맡겨져 있다.
초기 단계 스타트업의 가장 큰 문제는 '느린 반복'이다. 디자인-개발 사이클에 계속 병목이 생긴다. MCP는 이를 극적으로 단축한다. 몇몇 Y Combinator 스타트업들이 이미 MCP 기반 내부 도구를 만들어서 사용 중이라고 보고했다.
디자인 에이전시는 수백 개의 프로젝트를 동시에 진행한다. 각 프로젝트마다 디자이너-개발자 협력이 필요하면 스케일이 안 된다. MCP를 사용하면 소수의 개발자가 AI 에이전트들을 관리하면서도 수백 개의 프로젝트를 병렬 처리할 수 있다.
대규모 기업의 과제는 수백 개의 마이크로사이트, 랜딩페이지, 내부 도구가 모두 브랜드 가이드라인을 따르도록 유지하는 것이다. MCP를 통해 'AI 가버넌스'를 구현할 수 있다. 모든 디자인과 배포가 중앙의 브랜드 정책을 통과해야 하도록 한다.
미래의 디자인 시스템은 '사람과 AI가 함께 사용하는 시스템'이 될 것이다. 현재는 디자이너가 컴포넌트를 선택하고, AI가 배치하는 수준이지만, 미래에는 AI가 '어떤 컴포넌트가 최적인가'를 판단하고 제안하는 수준으로 진화할 것이다.
현재는 여전히 사람이 AI의 결과를 검수해야 한다. 하지만 블록체인, 영지식 증명 같은 기술과 결합되면, '신뢰하지 않고도 자동화된' 시스템이 가능할 수 있다. 예를 들어, AI가 생성한 디자인이 정말 브랜드 가이드라인을 준수했는지 자동으로 검증하는 것이다.
한 개의 AI 에이전트가 전체 워크플로우를 하는 것보다, 여러 전문화된 에이전트들이 협력하는 것이 더 효과적일 것이다. '디자인 검증 에이전트', '성능 최적화 에이전트', '접근성 감시 에이전트' 같은 것들이 각자의 역할을 하면서 협력한다.
MCP는 기술적으로는 '표준 프로토콜'이지만, 그것이 가져오는 의미는 훨씬 더 깊다. 이것은 '디자인이 더 이상 최종 산출물이 아니라, 배포 가능한 시스템의 일부'가 된다는 뜻이다.
과거: 디자인 → 개발 → 배포 (선형, 느림, 오류 많음)
현재: 디자인 ↔ 개발 (협력, 빠르지만 복잡)
미래: 디자인 = 코드 = 배포 (통합, 빠르고 신뢰할 수 있음)
MCP의 등장은 이 '통합'을 가능하게 하는 첫 번째 진지한 시도다. 디자이너와 개발자의 경계가 흐려지고, AI가 이 둘 사이의 번역자 역할을 하는 시대가 온다. 이는 기술적 진보일 뿐만 아니라, UX 실무의 근본적인 변화를 의미한다.
빠르게 변하는 시장에서 경쟁 우위를 가지려면, 기업은 '생각이 구현되는 속도'를 최소화해야 한다. MCP는 그 속도를 획기적으로 줄여주는 도구다. 아직은 초기 단계지만, 이 기술을 먼저 이해하고 도입하는 조직들이 미래의 주도권을 쥐게 될 것이다.
Where AI Drives UX, FRAMEOUT