Figma 디자인-코드 루프 공부 정리 | 캔버스가 코드를 받아오면

디자이너에서 프론트엔드로 공부하다 보면 항상 비슷한 지점에서 막힌다. 디자인 파일이 있고, 코드가 있는데, 둘 사이를 메우는 건 결국 손으로 해야 하는 일이었다. 뭔가 빠진 링크가 있는 것 같은 느낌이 계속 있었다.

Figma 블로그에서 그 지점을 다루는 글을 봤다. “What the design-to-code loop unlocks”라는 제목이었는데, 읽어보니 단순히 새 기능을 나열하는 게 아니라 디자인과 코드 사이의 워크플로우 자체가 어떻게 달라지고 있는지에 대한 얘기였다. 방향이 하나가 아니라는 점이 읽으면서 흥미로웠다.

1️⃣ 이게 뭐냐?

기존에는 디자인 → 코드 방향이 주였다. 디자이너가 Figma에서 작업하면 개발자가 그걸 보고 구현하는 식. 한쪽이 앞서고 한쪽이 뒤따르는 구조였다. 이 글에서 소개하는 건 그 반대 방향도 된다는 것이었다.

구체적으로 세 가지가 소개됐다. 첫째, Claude Code에서 실행 중인 코드를 Figma 캔버스 안에 편집 가능한 디자인 프레임으로 불러올 수 있다. 둘째, 반대 방향으로 캔버스의 디자인에서 실무용 코드를 생성할 수 있다. 셋째, Storybook이나 블로그, 그래픽 같은 외부 소스를 Figma에 라이브로 임포트할 수 있다.

이 중에서 첫 번째가 가장 인상적이었다. 코드가 돌아가고 있는 상태에서 그 결과물을 Figma 안으로 가져오는 거다. 예전에는 코드 결과물을 Figma로 가져오려면 스크린샷을 찍거나 따로 레이아웃을 다시 그려야 했다. 그냥 이미지를 붙여넣는 게 아니라 편집 가능한 프레임으로 들어온다는 게 어떤 차이를 만드는지가 궁금해졌다.

내가 이해한 바로는, 이 루프의 핵심은 흐름이 어느 쪽에서도 시작될 수 있다는 것이다. 그 사이를 수동으로 번역해야 했던 과정이 줄어드는 방향이라고 보면 되는 것 같다.

2️⃣ 내가 든 생각

디자이너 입장에서 보면, “시작점”의 자유가 생긴다는 점이 흥미로웠다. 지금까지는 디자인이 코드보다 앞에 있어야 한다는 전제가 있었다. 어느 정도 디자인이 확정돼야 구현이 시작되는 식. 그런데 코드에서 디자인으로 오갈 수 있다면, 그 순서가 꼭 고정될 이유가 없어지지 않을까 싶었다.

글에서 소개된 예시 중에 “실제 데이터가 들어간 와이어프레임”이 언급됐다. 공부하면서 정리해보니, 실제 데이터가 없는 프로토타입은 현실과 동떨어진 판단을 만들기 쉽다는 게 꽤 오래된 문제인 것 같았다. 라이브로 연결된다면 그 갭이 좁아지는 방향인데, 이게 단순한 편의 기능 이상일 수도 있겠다는 생각이 들었다.

👉🏻 프론트엔드를 배우는 입장에서는 이 루프가 학습 방식에도 영향을 줄 수 있겠다는 생각이 들었다. 글에서 “실제 프로젝트 맥락에서 라우팅이나 React를 이해하게 됐다”는 얘기가 나오는데, 추상적인 예제가 아니라 실제 화면과 연결해서 배우는 게 어떻게 다른지가 궁금해졌다. 지금 단계에서는 직접 확인하기 어렵지만, 맥락이 있는 학습과 없는 학습의 차이는 꽤 클 것 같다는 인상이었다.

디자이너-개발자 갭을 줄인다는 이야기는 꽤 오래된 얘기다. Figma가 생기고, Dev Mode가 생기고, 이제 이 루프가 생겼다. 계속 같은 방향을 향하고 있는 것처럼 보이는데, 이번엔 어디까지 좁혀지는 건지가 궁금해졌다.

💡 여기서 드는 질문? 디자인과 코드가 양방향으로 오가게 되면, 한쪽에서 수정한 것과 다른 쪽에서 수정한 것이 충돌할 때 어떻게 처리하는 걸까. 루프가 매끄러울수록 그 충돌 지점에서의 판단은 누가 하게 되는 건지, 공부 중에 남은 물음표였다.

⭐️ 마지막으로, 디자인-코드 루프를 공부하며 든 생각

이런 류의 도구를 볼 때마다 자꾸 같은 질문을 하게 되는 것 같다 — 두 세계가 가까워질수록, 그 경계에 있는 사람의 역할은 어떻게 달라지는 걸까.

---

참고 원문: What the design-to-code loop unlocks