워크플로우 랩: Figma MCP로 캔버스 확장하기 | 피그마 블로그

빠르게 코드를 작성하는 팀에서는 구현 과정에서 새로운 상태와 예외가 생기며 디자인과 실제 제품 사이의 간극이 커질 수 있다. 이 글은 Figma MCP를 사용해 코드에만 존재하던 제품 상태를 Figma 캔버스로 가져오고, 디자이너가 이를 직접 검토·수정하는 워크플로를 소개한다. 결과적으로 캔버스가 초기 화면을 넘어 실제 제품 전체의 상태와 구현 결과를 다루는 공간으로 확장된다.

빠른 개발이 만드는 디자인 사각지대

• Astra라는 가상의 AI 영상 제작 플랫폼은 에이전트 코딩 도구를 활용해 매주 기능을 출시한다.
• 초기 영상 내보내기 플로우는 다음 네 단계로 시작한다.
  • 시퀀스 선택
  • 포맷 선택
  • 설정 확인
  • 영상 내보내기
• 실제 코드와 데이터에 연결되면서 다음과 같은 상태가 추가된다.
  • 인코딩 오류
  • 렌더링 진행 중 상태
  • 선택 항목이 없는 상태
  • 지원하지 않는 포맷
• 이러한 상태는 디자이너가 초기 설계에서 누락한 것이 아니라, 기능이 실제 구현되는 과정에서 새롭게 드러난 디자인 결정 사항이다.
• 캔버스가 초기 플로우만 담고 있으면 디자이너 역시 제품의 일부만 보고 작업하게 된다.

Figma MCP로 캔버스 확장

• Figma MCP를 통해 에이전트가 코드를 읽고 Figma 캔버스에 결과를 작성할 수 있다.
• 에이전트는 구현된 내보내기 플로우를 분석해 개발자가 처리한 모든 상태를 식별한다.
• 각 상태를 Figma의 편집 가능한 프레임으로 생성하고, Astra의 디자인 시스템 컴포넌트를 적용한다.
• 초기에는 4개였던 프레임이 구현된 전체 상태를 반영하며 14개로 늘어난다.
• 사용된 주요 도구는 다음과 같다.
  • Figma Design
  • Dev Mode
  • Figma MCP server
  • use_figma
  • generate_figma_design
  • /sync-figma-token 스킬

코드에 드러난 상태를 디자인으로 발전시키기

• 인코딩 오류 화면에는 단순한 빨간색 오류 메시지만 있었지만, 디자이너가 다음 내용을 추가한다.
  • 오류 원인
  • 사용자가 시도할 수 있는 해결 방법
  • 이전 단계로 돌아가는 방법
• 렌더링 중 화면에는 스피너만 있었지만, 디자이너가 진행률과 예상 소요 시간을 추가한다.
• 선택 항목이 없는 화면은 비어 있었지만, 기능 사용을 유도할 수 있는 안내 문구와 개성을 부여한다.
• 이 방식은 작업 티켓이나 요구사항 문서 중심의 피드백보다, 코드와 디자인이 캔버스에서 직접 대화하는 형태에 가깝다.
• 구현 후 발견된 예외 상태를 별도의 긴 탐색 세션을 거치지 않고 바로 디자인 대상으로 전환할 수 있다.

디자인과 구현 결과 비교

• Figma 캔버스에서 원본 디자인과 코드로 구현된 화면을 나란히 비교할 수 있다.
• 시각적 차이를 찾아내는 비교 결과에는 심각도별 불일치가 표시된다.
• 예시로 다음과 같은 차이가 발견된다.
  • 모달 제목 크기 차이
  • 구현본에만 추가된 “Post share link” 버튼
  • 설정 패널의 배경 또는 표면 스타일 제거
  • 설정 헤더의 시각적 우선순위 하락
• 이를 통해 디자인 검토가 “의도한 화면이 구현되었는가”뿐 아니라, 실제 구현 과정에서 추가·변경된 요소까지 포함하도록 확장된다.

실용적인 결론

Figma MCP는 코드를 디자인으로 자동 변환하는 도구라기보다, 구현 중 발생한 모든 제품 상태를 디자인 의사결정의 영역으로 되돌리는 연결 장치다. 빠르게 개발하는 팀이라면 에이전트로 코드의 상태를 캔버스에 동기화한 뒤, 디자이너가 오류·로딩·빈 상태·시각적 불일치를 직접 검토하는 절차를 구축하는 것이 유용하다.