Figma MCP 워크플로우 공부 정리 | 코드 상태가 캔버스에 올라오면
Figma가 MCP로 코드 상태를 디자인 캔버스에 끌어오는 워크플로우를 소개했다. 디자이너가 모르던 엣지 케이스를 바로 볼 수 있다는 게 흥미로워서 정리해봤다.
Figma 블로그에서 MCP를 활용한 워크플로우 소개글이 올라왔다. 제목이 “Expanding the canvas with Figma MCP”였는데, 처음엔 FigJam MCP랑 비슷한 얘기겠지 싶었다.
읽어보니 방향이 달랐다. FigJam이 에이전트와 팀이 함께 쓰는 시각적 공간이었다면, 이건 코드에 있는 실제 상태를 Figma 캔버스로 직접 끌어오는 이야기였다. 개발팀이 코드를 빠르게 치는 사이 디자인 의도와 구현이 벌어지는 문제, 그걸 어떻게 좁힐 수 있냐는 거다.
1️⃣ 이게 뭐냐?
핵심은 코드와 캔버스가 연결된다는 거다. generate_figma_design 도구를 쓰면, 코드베이스에 있는 상태들을 캔버스에 자동으로 배치해준다.
글에서 소개된 사례가 꽤 구체적이었다. 어떤 영상 편집 앱에서 디자이너가 만들어둔 프레임은 4개였는데, MCP로 코드를 읽혀봤더니 실제 상태가 14개라는 게 나왔다. 디자이너가 존재조차 몰랐던 상태들이 코드 안에 이미 있었던 거다.
그 상태들을 캔버스에 올려놓고 각각을 다듬었다. 복구 경로 없이 그냥 멈추는 에러 화면, 진행률 없이 스피너만 도는 로딩 화면 같은 것들이었다. 원래라면 개발팀이 그냥 알아서 처리했을 엣지 케이스들이다.
/sync-figma-token도 있는데, 디자인 토큰과 코드 사이의 불일치를 잡아주는 도구다. 색상이나 간격이 언제부턴가 달라져 있는 걸 Visual Diff로 확인하고 맞출 수 있다. 드리프트가 쌓이는 걸 모르고 지나치는 상황을 막아주는 방식이다.
2️⃣ 내가 든 생각
디자이너 입장에서 흥미로웠던 건 “내가 설계하지 않은 상태”를 볼 수 있다는 점이었다. 보통 디자이너는 프로덕션에 어떤 상태가 존재하는지 전부 알기 어렵다. 코드를 직접 읽기도 번거롭고, 매번 물어보기도 애매하다. 그게 쌓이면 엣지 케이스는 디자인 없이 개발팀이 알아서 처리하게 된다.
👉🏻 코드 상태를 캔버스로 가져온다는 건, 디자이너가 모르고 있던 상태를 눈앞에 펼쳐준다는 뜻이다.
프론트엔드를 배우는 입장에서는 다른 게 눈에 들어왔다. 상태를 분리해서 관리하는 게 중요하다는 건 알고 있었는데, MCP가 그걸 캔버스로 옮기려 할 때 분리가 제대로 안 돼 있으면 그냥 엉망이 된다는 생각이 들었다. 도구를 잘 쓰려면 코드 구조가 먼저라는 얘기다.
💡 여기서 드는 질문? 이 워크플로우가 잘 돌아가려면 코드 쪽 상태 관리가 충분히 정리돼 있어야 할 것 같다. 레거시 코드베이스에서 끌어오면 14개가 아니라 140개가 나오는 건 아닐까.
3️⃣ 앞으로 어떻게 쓸까?
지금 당장 Figma MCP를 셋업해서 써볼 수준은 아니다. 그래도 개념 자체는 눈에 담아두고 싶었다. 디자이너-개발자 협업에서 “설계 의도와 구현이 왜 어긋나냐”는 질문을 자주 마주치는데, 이 접근법이 어디서 그 간격을 줄이려는지 보여주는 것 같아서다.
써봐야 알겠지만, 도구보다 “어느 타이밍에 실제 코드 상태를 캔버스에 올려볼 것인가”라는 판단이 더 중요할 것 같다. 쓰는 시점이 빠를수록 나중에 고칠 게 줄어드는 편이니까.
⭐️ 마지막으로, 협업 도구를 공부하며 느낀 점
이런 류의 도구를 볼 때 자꾸 같은 질문을 하게 되는 것 같다 — 도구가 갭을 메우는 건지, 아니면 갭이 있다는 걸 더 잘 보이게 해주는 건지.