디자인에서 코드로란?

디자인에서 코드로는 Figma 같은 도구에서 내린 결정을 동작하는 프런트엔드 코드로 옮기는 과정을 말합니다. 오래가는 방식은 캔버스에서 마크업을 생성하는 것이 아니라 디자인 토큰을 전달하는 것입니다. 화면이 바뀌어도 토큰은 유효하지만 생성된 마크업은 그렇지 않기 때문입니다.

혼동되는 두 가지 접근

캔버스에서 코드를 생성하기. 도구를 Figma 프레임에 겨누면 JSX나 HTML이 돌아옵니다. 데모에서는 대단히 인상적이지만 실전에서는 실망스럽습니다. 결과물은 여러분의 컴포넌트 라이브러리와 아무 관계가 없고, 중첩 구조는 디자이너가 레이어를 어떻게 묶었는지를 반영하며, 디자인이 바뀌면 다시 생성하면서 손댄 부분은 사라집니다.

결정을 옮기기. 대신 토큰, 즉 색상·여백·타이포그래피·반경을 옮기고, 이를 참조하는 컴포넌트를 개발자가 만듭니다. 데모에서는 덜 화려합니다. 그러나 살아남는 쪽입니다. 레이아웃이 바뀌어도 토큰은 유효하고, 코드는 사람이 쓰고 사람이 유지보수할 수 있는 코드로 남기 때문입니다.

첫 번째를 시도한 팀은 거의 예외 없이 두 번째로 옮겨 갑니다.

핸드오프가 계속 실패하는 이유

실패는 넘겨주는 순간이 아닙니다. 그 이후의 전부입니다.

디자이너가 Figma에서 색을 수정합니다. 그 변경은 스타일시트에 닿아야 합니다. 자동 경로가 없으니 채널의 메시지를 통해 닿고, 누군가 읽거나 읽지 않습니다. 이것을 일 년 치 변경에 곱해 보세요.

양쪽 모두 제대로 일하고 있습니다. 둘을 잇는 것은 기억하고 있는 사람입니다.

Figma API의 제약

이 분야의 도구를 평가하기 전에 알아 둘 가치가 있습니다. 변수를 읽는 Figma REST API 엔드포인트는 Enterprise 플랜에서만 제공됩니다.

즉, Figma 변수를 REST API로 동기화하는 도구는 Enterprise 계정 위 데모에서는 작동하고, 대부분의 팀이 쓰는 Professional 플랜에서는 아무것도 하지 않습니다. 플러그인은 이 제약을 받지 않습니다. 플러그인 API로 파일 안쪽에서 변수를 읽기 때문입니다. 동기화 도구를 비교한다면 각각 어느 쪽을 쓰는지 물어보세요.

제대로 도는 루프의 모습

디자인 결정이 토큰으로, 양쪽이 참조하는 한 곳에 존재합니다.
디자인 쪽 변경이 덮어쓰기가 아니라 diff로 도착합니다.
편집 권한이 있는 사람이 검토하고 적용합니다.
저장소에 풀 리퀘스트가 열리고 평소의 코드 리뷰를 거칩니다.
AI 에이전트가 같은 토큰을 실시간으로 읽으므로, 생성된 코드가 시스템 옆이 아니라 안에 안착합니다.

가운데의 검토 단계는 없애야 할 마찰이 아닙니다. 팀의 토큰을 조용히 다시 쓰는 도구는 자동화가 돌려주는 것보다 더 많은 신뢰를 잃게 합니다.

Flash DS와의 관계

Flash DS는 Figma 플러그인을 전송 수단으로 쓰기 때문에 어떤 Figma 플랜에서도 작동합니다. 게시는 검토 가능한 토큰 diff가 되고, 승인된 diff는 풀 리퀘스트로 열 수 있습니다.