디자인과 개발 사이의 벽은 오래된 숙제다. 디자이너는 Figma에서 픽셀을 다듬고, 개발자는 그것을 코드로 옮기는 과정에서 필연적으로 무언가가 어긋난다. 그런데 최근 몇 가지 움직임을 겹쳐 보면, 이 벽이 단순히 낮아지는 것이 아니라 구조 자체가 바뀌고 있다는 느낌이 든다. 공통 언어는 MCP(Model Context Protocol)다.
코드 → 디자인: Figma가 흐름을 뒤집다
Figma와 Anthropic이 공식 파트너십을 맺고 선보인 'Code to Canvas' 기능은 이름 그대로 코드를 캔버스로 가져온다. Claude Code로 브라우저 환경에서 UI를 구현하면, 그 라이브 상태를 캡처해 Figma의 편집 가능한 프레임으로 붙여넣을 수 있다. 단순 스크린샷이 아니다. 컴포넌트를 해체하고, 주석을 달고, 다른 버전과 나란히 놓고 비교하는 실제 협업 아티팩트가 된다.
전통적인 흐름은 '디자인 → 코드'였다. Figma에서 나온 스펙이 개발자에게 전달되고, 개발자가 구현하고, 다시 디자이너가 검토하는 왕복 루프. Code to Canvas는 이 방향을 반전시킨다. AI가 먼저 UI를 빠르게 찍어내고, 그 결과물을 팀 전체가 Figma 위에서 함께 다듬는다. 비개발자도 실제로 동작하는 UI에 피드백을 줄 수 있고, 디자인 시스템 토큰과의 정합성도 캔버스 위에서 바로 확인된다. 기술적으로는 Figma의 MCP 서버가 Claude Code와 연결 통로를 제공하는 구조다.
물론 현실적인 제약도 있다. 터미널 설정이 필요하고, 데스크톱 앱에서만 작동하며, 멀티 스크린 플로우는 개별 캡처가 요구된다. Claude Code가 프로덕션 코드베이스에 직접 접근한다는 점도 주의가 필요하다. 완성된 워크플로우라기보다는 '방향을 제시하는 프로토타입'에 가깝다. 그럼에도 Figma가 이 방향에 베팅했다는 사실 자체가 의미심장하다—AI는 디자인 캔버스를 대체하는 게 아니라, 더 빠르게 더 많은 옵션을 공급하는 역할을 맡는다는 선언이다.
에이전트가 늘어날수록 MCP 설정은 흩어진다
그런데 실무에서 AI 에이전트를 쓰다 보면 금방 다른 문제에 부딪힌다. Codex로 시작했다가 토큰 한도에 걸려 Cursor로 넘어가고, 특정 태스크에는 Claude Code가 더 낫다고 판단해 또 전환한다. 하나의 프로젝트 안에서도 에이전트를 여러 번 갈아타는 일이 생각보다 흔하다. 문제는 각 에이전트가 스킬, MCP 서버 설정, 로컬 툴 구성을 각자 관리한다는 점이다. 한 에이전트에 새 MCP를 설치해도, 다른 에이전트에는 수동으로 다시 설정해야 한다. 시간이 지날수록 환경이 조금씩 달라져 버린다.
dev.to에서 소개된 skills-sync는 이 문제를 정면으로 겨냥한다. 아이디어는 단순하다. 워크스페이스를 '단일 진실 공급원(single source of truth)'으로 삼고, 각 에이전트는 그 정의를 소비하는 구조로 만드는 것. 심링크(symlink)를 활용해 에이전트들이 동일한 파일을 가리키게 하기 때문에, 스킬을 업데이트하거나 MCP 설정을 변경하면 지원하는 모든 에이전트에 자동으로 반영된다. 현재 Codex, Cursor, Gemini, Copilot, Claude Code를 지원하며, skills-sync agents drift 명령으로 현재 에이전트들이 워크스페이스 정의에서 얼마나 벗어났는지 확인할 수도 있다.
아직 초기 단계의 도구지만, 이것이 시사하는 방향은 명확하다. 에이전트가 하나일 때는 설정이 문제가 아니다. 그런데 프로젝트 규모와 복잡도가 올라가면서 에이전트를 전략적으로 조합해 쓰는 게 일반화되면, MCP 설정의 일관성 유지는 개발 환경 관리의 핵심 과제가 된다. skills-sync는 그 문제를 CLI 하나로 추상화하려는 시도다.
이해 없는 구현: AI가 가능하게 만든 새로운 탐구 방식
세 번째 사례는 조금 다른 결을 보여준다. dev.to의 한 개발자는 매일 아침 받아보는 AI 리서치 리포트에서 'Active Inference'라는 개념에 걸렸다. 칼 프리스턴의 자유 에너지 원리에서 파생된 계산 신경과학 이론인데, 수식의 세 번째 줄부터 이해를 잃었다고 솔직하게 고백한다. 그럼에도 "일단 돌려보고 싶다"는 충동으로 Claude Code를 붙잡고 2시간 만에 PyTorch 기반 논문 코드를 순수 NumPy로 재작성하고, 누구나 브라우저에서 파라미터를 조절해볼 수 있는 Streamlit UI를 만들었다. 1,550줄, 테스트 커버리지 98%.
이 과정에서 흥미로운 장면이 있다. 수치가 발산해 NaN이 터지는 버그를 만났을 때, Claude Code는 처음 세 번의 제안이 모두 엇나갔다. 보통이라면 "그 근거가 뭐야?"라고 파고들겠지만, 이번엔 이론을 모르니 제안이 틀렸다는 확신도 가질 수 없었다. 결국 원본 코드와 구현을 diff해 VJP의 부호 오류를 찾아낸 것도 Claude Code였다. 이 경험이 말해주는 것은, AI 에이전트가 강력해질수록 '무엇을 만들지 결정하는 집착'이 차별화 요소로 남는다는 점이다. 구현 능력이 민주화된 세계에서, 아침 리포트의 낯선 용어에 손이 먼저 움직이는 사람은 대체되지 않는다.
MCP는 협업의 문법이 되고 있다
세 가지 이야기를 이어 붙이면 하나의 구조가 보인다. Figma의 Code to Canvas는 MCP를 통해 AI 코딩 도구와 디자인 캔버스를 연결한다. skills-sync는 MCP 설정을 에이전트 간에 동기화해 일관된 작업 환경을 유지한다. 그리고 Claude Code는 이해의 경계를 넘어 구현 자체를 가능하게 만든다. 각각은 독립적인 도구처럼 보이지만, 모두 'AI 에이전트가 여러 도구·서비스·맥락에 어떻게 연결되는가'라는 같은 질문에 답하고 있다.
MCP가 단순한 API 연동 표준이 아니라 협업의 문법으로 자리잡고 있다는 신호가 곳곳에서 감지된다. 디자이너가 Figma 캔버스 위에서 AI가 만든 코드를 다듬고, 개발자가 여러 에이전트를 일관된 환경으로 운용하고, 연구자가 이해 못 한 논문을 인터랙티브 툴로 만드는 일이 모두 같은 생태계 안에서 일어나기 시작했다. 지금은 각 도구가 조금씩 삐걱거리지만, 이 흐름의 방향은 분명하다. 빠른 프로토타입→팀 검증→고도화라는 사이클이 MCP라는 공통 레일 위에서 훨씬 짧아질 것이다. 그 레일 위에서 어떤 역할을 맡을지 지금 생각해두는 것이 좋다.