디자인과 개발은 오랫동안 '번역 비용'을 치러왔다. 디자이너가 Figma에서 완성한 화면을 개발자가 코드로 옮기고, 그 코드가 다시 디자인과 어긋나면 또 한 번 동기화 작업이 반복됐다. 이 비용은 단순한 시간 낭비가 아니라, 제품이 실제 사용자에게 닿기까지의 마찰 그 자체였다.
그런데 최근 세 가지 신호가 거의 동시에 등장하면서, 이 구조가 근본적으로 흔들리기 시작했다. Figma의 MCP 기반 AI 에이전트 통합, Anthropic의 상시 가동 에이전트 프로젝트 '콘웨이', 그리고 MCP가 CLI보다 43배 비싼 토큰을 소비한다는 실측 데이터. 이 세 가지는 각각 따로 읽으면 단편적인 기술 뉴스처럼 보이지만, 함께 놓으면 하나의 방향을 가리킨다—MCP가 디자인-개발 워크플로우의 공통 언어가 되고 있다는 것.
Figma 캔버스 안으로 들어온 AI 에이전트
Figma가 최근 공개한 MCP 서버 통합은 표면적으로는 'AI가 디자인을 도와준다'는 이야기처럼 들린다. 하지만 핵심은 그게 아니다. 이전까지 AI 도구는 디자인 워크플로우 바깥에 있었다. 이미지를 생성해주거나, 코드를 따로 뱉어주거나, 제안을 텍스트로 던져주는 방식이었다. Figma의 새 접근은 AI 에이전트가 실제 캔버스 안에서 기존 디자인 시스템의 컴포넌트를 쓰고, 토큰을 참조하고, 레이아웃을 직접 수정하게 만든다.
특히 주목할 것은 'Skills'라는 개념이다. 마크다운으로 작성된 워크플로우 명세서인데, AI 에이전트에게 어떤 컴포넌트를 언제 써야 하는지, 어떤 스페이싱 규칙을 따라야 하는지, 어떤 순서로 작업을 진행해야 하는지를 알려준다. 이건 단순한 프롬프트가 아니다. 팀이 오랫동안 축적해온 디자인 시스템의 의도를 AI가 이해할 수 있는 형태로 인코딩하는 것이다.
실무적으로 이게 의미하는 바는 크다. 개발자가 코드에서 UI 컴포넌트를 변경했을 때, AI가 그 변화를 Figma 캔버스에 자동으로 반영할 수 있다. 반대로 디자이너가 새 화면을 구성하면, 그 구조가 개발 환경과 동기화된 상태를 유지한다. '번역 비용'이 줄어드는 게 아니라, 번역 자체가 사라지기 시작하는 것이다.
콘웨이: MCP를 '항상 켜진 상태'로 만들다
Figma의 에이전트가 캔버스 안에서 작동한다면, Anthropic이 준비 중인 코드명 '콘웨이'는 한 발 더 나아간다. 테스팅카탈로그의 내부 빌드 분석에 따르면, 콘웨이는 사용자가 먼저 질문을 입력해야 반응하는 기존 Claude 방식과 달리, 외부 이벤트—이메일 수신, 데이터 변경, 웹훅 트리거—를 스스로 감지해서 움직이는 상시 가동 에이전트다.
MCP와의 관계가 흥미롭다. MCP가 AI와 외부 도구를 연결하는 '방법'을 정의한다면, 콘웨이는 그 연결을 24시간 유지하는 '환경' 자체를 Anthropic이 직접 제공하겠다는 시도다. 디자인-개발 맥락에서 풀어보면, 기존에는 Figma MCP 서버를 켜두고 AI가 작업하는 동안만 에이전트가 활성화됐다. 콘웨이 구조가 적용되면, 팀원이 디자인 파일을 열지 않아도 에이전트가 변경사항을 감지하고 관련 작업을 자율적으로 처리할 수 있게 된다.
Anthopic이 .cnw.zip이라는 자체 확장 포맷을 준비 중이라는 점도 눈여겨볼 필요가 있다. 외부 도구를 플러그인처럼 연결하는 구조인데, 이는 콘웨이 위에 별도 생태계를 구축하겠다는 의도로 읽힌다. MCP를 표준으로 설계한 것은 Anthropic이지만, 그 위에 올라타는 오케스트레이션 레이어까지 직접 장악하면 디자인 툴 통합의 주도권 역시 플랫폼 쪽으로 더 기울게 된다.
43배 비용의 의미: MCP는 공짜가 아니다
여기서 냉정한 질문 하나를 던져야 한다. MCP 기반 워크플로우는 실제로 얼마나 효율적인가? Velog에서 공유된 실측 데이터는 불편한 진실을 직시하게 만든다. 동일한 작업을 MCP 방식으로 수행하면 CLI 방식 대비 토큰을 43배 더 소비하고, 비용은 94% 더 높다.
왜 이런 차이가 생기는가? MCP는 AI 에이전트가 사용 가능한 도구 정보를 시스템 컨텍스트에 계속 올려놓아야 한다. 22개 도구를 연결하면, 아무것도 하기 전에 이미 전체 토큰의 8.1%가 소진된다. 응답 자체도 텍스트 형태로 돌아오기 때문에 추가 토큰을 먹는다. MCP 프로토콜이 상대적으로 새롭고 서버 구현 품질이 들쑥날쑥하다 보니 에러도 잦다—이건 근거 없는 불만이 아니라 실제 오버헤드다.
그렇다고 MCP를 무조건 피해야 하는 건 아니다. 핵심 질문은 하나다: LLM이 이미 알고 있는 도구인가, 아닌가? git, kubectl, npm 같은 도구는 LLM 학습 데이터에 수없이 등장한다. 이런 경우 CLI가 압도적으로 효율적이다. 반면 Figma의 디자인 시스템처럼 팀 내부에서 정의된 도구나 새로 생겨난 서비스의 인터페이스는 LLM이 전혀 모른다. 이 경우 MCP로 도구 정의를 넘겨주는 방식이 오히려 적합하다.
디자인-개발 협업에서 MCP를 쓸 때의 실제 트레이드오프
세 가지 신호를 종합하면, 디자인-개발 워크플로우에서 MCP의 포지션이 명확해진다. MCP는 '팀 단위로 공유해야 하는 컨텍스트가 있고, 그 컨텍스트가 LLM에게 낯선 도메인일 때' 가장 강력하다. Figma 디자인 시스템, 회사 내부 컴포넌트 라이브러리, 팀만의 스페이싱 규칙—이런 것들은 정확히 그 조건에 해당한다.
반면 비용과 안정성은 여전히 현실적인 제약이다. 불필요하게 연결된 MCP 서버를 끊는 것만으로도 응답 속도가 체감적으로 달라진다. 실무에서는 디자인 관련 MCP와 개발 관련 MCP를 분리하고, 현재 작업에 필요한 도구만 활성화하는 방식이 비용과 안정성을 동시에 잡는 접근이다.
콘웨이 같은 상시 가동 에이전트가 보편화되면 이 비용 구조는 더욱 중요해진다. 에이전트가 항상 켜진 상태로 디자인 파일의 변경을 감지하고, 개발 환경과 동기화하는 작업을 자율적으로 수행한다면—토큰 소비는 세션 단위가 아니라 시간 단위로 쌓인다. MCP 서버 설계와 도구 최소화는 선택이 아니라 운영 필수 조건이 될 것이다.
경계가 사라지는 방향, 그 속에서 설계자의 역할
디자인과 개발의 경계가 사라진다는 말은 두 역할이 하나로 합쳐진다는 의미가 아니다. 오히려 정반대다. AI 에이전트가 기계적인 번역과 동기화를 담당하게 되면, 사람이 해야 할 일은 더 명확해진다—어떤 디자인 결정이 사용자 문제를 진짜로 푸는가를 판단하는 것.
Figma Skills를 정의하는 사람, MCP 서버에서 어떤 도구를 어떤 권한으로 노출할지 결정하는 사람, 에이전트가 생성한 디자인이 실제 사용자 여정에 맞는지 검증하는 사람—이 역할들은 AI가 대체하는 게 아니라 AI를 올바르게 작동시키기 위해 더욱 중요해지는 위치다. 프로토콜이 경계를 지우는 속도만큼, 그 경계 너머를 설계하는 사람의 판단력이 제품의 실질적인 차별점이 된다.