스펙에서 컴포넌트 코드가 자동으로 나온다면

디자인 시스템 문서화로 알려진 네이선 커티스가 피그마 스펙에서 리액트 컴포넌트 코드를 생성한 실험을 공개했다. 컴포넌트마다 scaffold.tsx·contract.ts·styles.css·stories.tsx가 예측 가능한 폴더 구조로 떨어지는 프로토타이핑 키트를, 몇 주가 아니라 몇 초 만에 만들어냈다는 보고다. 여러 피그마 라이브러리를 대상으로 시각 회귀 테스트를 돌렸고 마지막 라이브러리는 손질에 한 시간이면 충분했다고 한다. 다만 흥미로운 건 결과물보다 부산물이다.

"코드를 카탈로그가 아니라 계약(contract)에 맞춰라."Nathan Curtis

왜 중요한가

코드를 실제로 생성해보자 스펙에 무엇이 빠져 있는지가 드러났다. 그래서 상태 매핑, 역할 주석, 디자인 레이어를 시스템 컴포넌트로 승격하는 프로모티드 프리미티브 세 기능이 스펙 프레임워크에 새로 추가됐다. 결과적으로 즐겨찾기 버튼 하나가 "충실한 시각적 재현"을 넘어 눌림 상태와 선택 토글, aria 속성까지 갖춘 컴포넌트로 나온다. 자동 생성의 진짜 효용이 속도가 아니라 스펙 품질의 검증이라는 뜻이다.

실무 적용

그래서 코드 생성을 산출물이 아니라 테스트로 쓰는 편이 낫다. 생성된 컴포넌트에 비활성·눌림·오류 상태가 없다면 그건 모델의 한계가 아니라 디자인 원본이 그 정보를 담지 않았다는 신호다. 피그마에서 상태와 역할을 어디에 어떤 이름으로 기록하는지 규칙을 먼저 세워두면, 같은 규칙이 나중에 코드 생성의 입력이 된다. 반대로 규칙 없이 쌓인 라이브러리는 사람에게도 기계에게도 해석이 안 된다.

교차 참고

• Nathan Curtis: Design System Conventions in Figma — 피그마가 기본 제공하지 않는 구조적 의도를 아이콘·서브컴포넌트·이미지 명명 규칙으로 표현하고 config/conventions/figma.yaml에 모아 관리한 사례다.
• Nielsen Norman Group: Creating Design Specs for Development — 디자인 스펙이 외형만이 아니라 기능과 동작까지 담아야 개발이 성립한다는 기본 원칙을 정리한 글이다.

Wemeet의 관점

Wemeet은 이 실험의 교훈을 "디자인 산출물을 기계가 읽을 수 있게 쓰면 사람에게도 더 정확해진다"로 읽는다. 웹사이트 제작에서 개발자가 가장 많이 되묻는 항목은 색이나 여백이 아니라 상태와 예외다. 버튼이 눌린 동안 어떻게 보이는지, 목록이 비었을 때 무엇을 띄우는지를 디자인 파일 안에 규칙적으로 남겨두는 팀이 결국 자동화의 수혜도 먼저 받는다.