컴포넌트 명세가 끝내 놓치는 것

디자인 시스템 분야의 오랜 실무자 Nathan Curtis가 컴포넌트 명세(spec)를 검증하는 방법으로 ‘라운드 트립’을 제안했습니다. 디자인 원본에서 명세를 뽑아내고(generate), 그 명세만으로 다시 화면을 그린 뒤(render), 원본과 결과를 나란히 놓고 차이를 재는 방식입니다. 그는 이 왕복에서 사라지는 것들을 손실(loss)·깊이(depth)·결산(reckoning)이라는 순서로 뜯어봅니다.

"변환과 스키마가 담아내지 못하는 것은 무엇이든 그대로 사라진다."Nathan Curtis

왜 중요한가

대부분의 팀은 명세를 ‘문서’로 다룹니다. 하지만 명세가 코드 생성기와 AI 에이전트의 입력이 되는 순간, 그것은 문서가 아니라 계약(contract)이 됩니다 — 계약이 담지 못한 의도는 구현자의 눈치와 관행으로 메워지고, 그 순간 디자인 시스템은 조용히 갈라지기 시작합니다. 흥미로운 지점은 왕복을 반복해도 차이가 0으로 수렴하지 않는다는 관찰입니다. 남은 차이는 재확인된 전제, 고쳐야 할 결함, 그리고 계약이 원리적으로 담을 수 없는 영역으로 나뉩니다.

실무 적용

지금 쓰는 컴포넌트 문서로 당장 한 번 시험해 보시기 바랍니다. 문서만 보고(원본 화면을 보지 않고) 컴포넌트를 다시 만들어 달라고 AI 에이전트나 신입 개발자에게 맡긴 뒤, 결과와 원본의 차이를 목록으로 적는 것입니다. 대개 상태 전이, 반응형 분기점, 여백의 근거, 접근성 요구사항이 가장 먼저 증발합니다. 그 목록이 곧 다음 스프린트에 채워야 할 명세의 구멍이며, 토큰·스키마 어느 층에서 메울지까지 정해 두면 같은 손실이 반복되지 않습니다.

교차 참고

• Nathan Curtis: Spec-Driven UI Component Development — 단일 진실 공급원 대신, 명세를 Figma·프로토타입·React/iOS/Android 코드 사이를 오가는 중계 허브로 두자는 앞선 논의입니다.
• Hardik Pandya: Expose your design system to LLMs — LLM이 토큰 이름을 지어내고 값을 추측하는 문제를 두고, 디자인 시스템을 기계가 읽을 수 있는 형태로 재구성하라고 제안합니다.

Wemeet의 관점

Wemeet은 디자인 시스템의 성숙도를 컴포넌트 개수가 아니라 ‘문서만 보고 얼마나 똑같이 복원되는가’로 봅니다 — 복원율이 낮은 시스템은 사람이 늘어날수록 더 빨리 무너집니다. 특히 홈페이지 제작처럼 여러 손을 거치는 작업일수록, 예쁜 컴포넌트 라이브러리보다 빈틈 없는 계약이 결과물의 품질을 지켜 줍니다.