설계 의도를 '문서'가 아닌 '계약'으로

디자인 시스템 권위자 Nathan Curtis가 컴포넌트의 설계 의도를 바라보는 틀을 바꾸자고 제안했습니다. 사람이 읽는 '설명 문서'가 아니라, React·iOS·Android·웹 컴포넌트·Figma가 다 함께 따르는 단일 '계약(contract)'으로 다루라는 것입니다. 그리고 그 계약을 어떻게 쓸 수 있는지를 규정하는 문법이 '스키마(schema)'입니다 — 스키마가 계약이 '말할 수 있는 것'을, 개별 스펙이 '실제로 말하는 것'을 정의합니다.

"설명은 알려줄 뿐이지만, 계약은 조정한다."Nathan Curtis

왜 중요한가

디자인 시스템이 수백 개 컴포넌트 × 여러 플랫폼으로 커지고 변경이 잦아지면, 진짜 병목은 디자인이 아니라 '핸드오프'입니다. 계약은 이 수작업 전달을 자동·검증 가능한 커뮤니케이션으로 대체합니다 — 플랫폼마다 회의를 여는 대신 단일 명령으로 스펙을 일괄 배포하고, 스키마가 계약을 코드·CSS·TypeScript 타입·컴포넌트 스캐폴드로 결정론적으로 변환해 수작업을 80~90% 줄입니다. 설계 의도가 흩어지지 않고 한곳에서 기록·진화·동기화됩니다.

실무 적용

Figma·프로토타입·코드가 제각기 '다른 버전의 진실'을 갖는 문제를, 계약이 중재자가 되어 정렬합니다. 팀은 컴포넌트 스펙을 anatomy·props·layout 같은 구조로 나눠 계약 단위로 관리하고, 변경을 문서가 아니라 기계가 읽는 소스로 남기는 것이 핵심입니다. 그러면 다중 플랫폼 동기화가 사람의 성실함이 아니라 파이프라인의 문제가 됩니다.

교차 참고

• Nielsen Norman Group: State of UX 2026 — Design Deeper to Differentiate — UI가 상품화되며 표면 디자인만으론 차별화가 어려워진다는 흐름을 짚습니다.
• Nielsen Norman Group: The Core Skill of Design in the AI Era — Critique — '무엇이 좋은가'를 정의하는 판단력이 AI 시대 디자인의 핵심이라는 관점입니다.

Wemeet의 관점

Wemeet은 계약이 디자인을 '설득'에서 '검증'으로 옮긴다고 봅니다. AI가 컴포넌트 코드를 대량으로 찍어낼수록, 무엇이 옳은지 기계가 확인할 수 있는 형식으로 의도를 적어둔 팀만이 일관성을 지킵니다 — 설계 의도를 계약으로 형식화하는 일이 곧 확장 가능한 품질의 전제입니다.