AI가 디자인-코드 경계를 허무는 지금, 정작 무너지는 건 '프로세스'다
피그마 캔버스에 Claude가 직접 붙고, Gemini가 전체 기획을 총괄하며, AI 에이전트가 디자인 시스템을 읽고 컴포넌트를 뽑아낸다. 2026년 현재, 디자인-개발 사이의 번역 비용은 빠르게 0에 수렴하고 있다. 그런데 이 흥분 속에서 조용히 반복되는 실패 패턴이 있다. 도구는 완벽한데 결과물이 어느 순간 통제 불능이 되는 것. 속도는 얻었지만 왜 이렇게 만들었는지 설명할 수 없게 되는 것. AI 분업 워크플로우의 진짜 약점은 도구가 아니라 설계의 부재에 있다.
세 도구, 세 역할—올림플래닛의 실전 분업 구조
올림플래닛 디자인 총괄 김민우 씨가 KM저널에 공개한 'ABC승무원학원 AI 모의면접' 프로젝트 사례는 AI 분업 워크플로우의 가능성을 잘 보여준다. 핵심은 세 도구에 명확한 R&R을 부여한 것이다.
Gemini Pro는 아키텍트이자 QA 리드 역할을 맡는다. 사용자 여정 설계, UX 구조 정의, 기능 명세 작성, 디자인 시스템 문서화—그리고 가장 중요한 것, Claude를 움직일 프롬프트를 정교하게 설계하는 일. Claude(Figma MCP 연동) 는 그 설계도를 받아 피그마 캔버스와 직접 데이터를 주고받으며 React 코드베이스 표준에 맞게 UI를 즉각 구현한다. 디자인 토큰 오류를 스스로 검증하고 수정안까지 제시한다. Figma Make는 디자이너가 AI 결과물을 시각적으로 조율하는 최종 스테이지다. 브랜드 톤앤매너에 맞게 레이아웃과 텍스트를 다듬고, 픽셀 레벨의 완성도를 사람이 직접 통제한다.
이 구조에서 주목할 점은 단순히 '세 도구를 함께 쓴다'가 아니라는 것이다. 각 도구가 다음 단계의 입력 품질을 책임지는 파이프라인 구조라는 점이 핵심이다.
피그마가 캔버스를 열었다—플랫폼 차원의 변화
이 워크플로우가 가능해진 데는 플랫폼 차원의 변화도 있다. 피그마는 최근 AI 에이전트가 캔버스에서 디자인을 직접 생성·수정할 수 있는 use_figma 도구와 Skills 기능을 베타로 공개했다. Claude Code, OpenAI Codex 등 주요 MCP 클라이언트에서 바로 사용할 수 있다.
결정적인 포인트는 팀 디자인 시스템을 에이전트가 직접 이해하고 활용한다는 것이다. 기존에는 AI가 생성한 UI와 실제 디자인 시스템 사이의 괴리가 반복 발생했다. 이제는 명명 규칙, 구조 라이브러리, 디자인 토큰까지 에이전트가 동일한 컨텍스트에서 작업한다. Skills 기능은 마크다운 기반 지침으로 작업 순서와 규칙을 정의해 팀 맞춤형 워크플로우를 플러그인 없이 구성할 수 있게 한다. 스크린샷과 코드 결과를 비교해 반복 수정하는 '자기 수정 루프'까지 포함된다. 피그마 CPO 유키 야마시타는 "초기 디자인 구상부터 디자인 시스템 업데이트까지 에이전트 활용 범위를 한층 넓힐 수 있다"고 밝혔다.
도구와 플랫폼이 이 정도로 맞물리면, 실무 속도는 확실히 달라진다. 문제는 그 다음이다.
Vibe Coding 피로감—빠른 만큼 빠르게 무너진다
dev.to에서 D-MemFS 개발자가 공유한 'Spec-First AI Development' 방법론은 이 속도의 이면을 직격한다. AI에게 막연한 감(vibe)으로 코드를 맡기면 어느 순간 벽에 부딪힌다. AI가 생성한 코드를 이해하지 못하고, 버그를 고치면 다른 버그가 생기고, 코드 리뷰에서 "왜 이렇게 했냐"는 질문에 답할 수 없는 상태. 이것이 Vibe Coding Fatigue다.
이 개발자의 해법은 단순하지만 근본적이다. 코드보다 설계 문서를 먼저 써라. AI에게 코드를 맡기기 전에 명세와 설계 철학을 완전히 정리한다. 이유는 세 가지다. 첫째, AI가 생성한 수백 줄의 코드를 사람이 리뷰하는 것보다 설계 문서 한 장을 리뷰하는 것이 압도적으로 쉽다. 설계 문서는 AI가 리뷰할 수도 있다. 둘째, 코드는 '무엇을 하는지'는 말하지만 '왜 그렇게 했는지'는 말하지 않는다. 설계 철학을 명문화하면 AI가 엉뚱한 방향을 제안할 때 한 줄로 차단할 수 있다. 셋째, 설계 문서를 단계별로 분리하면 AI의 유한한 컨텍스트 윈도우를 낭비하지 않는다.
D-MemFS 프로젝트에서 이 개발자는 Gemini와 ChatGPT를 스파링 파트너로 삼아 설계 문서를 v1부터 v13까지 다듬었고, Claude Opus의 리뷰에서 기존 스파링으로 발견하지 못한 잠재적 레이스 컨디션과 롤백 설계 오류를 찾아냈다. 설계 문서가 가드레일이 된 것이다.
분업의 성공 조건: 속도가 아니라 '설계 철학의 공유'
두 사례를 겹쳐 보면 AI 분업 워크플로우가 작동하는 조건이 명확해진다. 올림플래닛 사례에서 Gemini가 단순한 기획 도구가 아니라 '아키텍트'인 이유는, Claude를 위한 프롬프트를 정교하게 작성하기 때문이다. 그 프롬프트는 결국 설계 의도를 AI가 실행 가능한 언어로 번역한 것이다. Spec-First 방법론에서 설계 문서가 하는 역할과 본질적으로 같다.
Figma MCP의 Skills 기능이 마크다운 기반 지침으로 에이전트의 작업 방식을 정의하는 것도 같은 맥락이다. 팀의 컨벤션, 디자인 철학, 작업 순서를 에이전트가 이해하는 언어로 명문화하는 것—이것이 없으면 아무리 강력한 도구도 팀 바깥의 방향으로 달린다.
결국 AI 분업 워크플로우의 핵심 레버는 도구 선택이 아니라 설계 문서와 철학을 먼저 확립하는 습관이다. 빠르게 만들 수 있다는 건, 잘못된 방향으로도 빠르게 달릴 수 있다는 의미이기도 하다.
전망: '설계하는 사람'의 가치가 올라가는 시대
피그마가 캔버스를 AI에게 열고, MCP로 코드와 디자인이 실시간으로 연결되는 지금, 프론트엔드 개발자에게 가장 중요한 질문은 바뀌고 있다. '어떤 도구를 쓸 것인가'보다 '무엇을 먼저 설계할 것인가'가 더 중요해졌다.
빠른 프로토타이핑 → 사용자 검증 → 고도화라는 흐름은 변하지 않는다. 달라지는 것은 각 단계의 속도다. 그 속도 속에서 통제권을 잃지 않으려면 Spec-First 사고방식—코드보다 설계 철학을 먼저 명문화하는 것—이 워크플로우의 전제가 되어야 한다. AI가 역할을 분담할수록, 그 역할을 설계하는 사람의 가치는 오히려 높아진다. 도구가 강력해질수록 설계의 책임은 더 선명하게 사람에게 남는다.