프롭스의 공유 언어 | (새 탭에서 열림)

컴포넌트와 props는 디자인과 코드 양쪽에서 사용되지만, 환경에 따라 의미와 목적이 달라질 수 있다. 같은 이름의 컴포넌트라도 디자이너는 시각적 일관성과 표현 방식을, 개발자는 렌더링·상호작용·데이터 처리를 중심으로 생각한다. 따라서 디자인과 개발의 협업을 개선하려면 용어를 단순히 통일하기보다 각 환경의 맥락과 차이를 함께 이해해야 한다.

디자인과 개발에서 달라지는 언어

• 컴포넌트는 재사용 가능한 요소이며, props는 컴포넌트가 표현될 수 있는 방식과 규칙을 정의한다.
• 컴포넌트의 인스턴스는 원본 컴포넌트를 실제로 사용한 결과이며, props 값을 변경해 다양한 상태와 모양을 표현한다.
• 디자인과 개발 모두 boolean 같은 개념을 사용하지만, 디자이너는 이를 주로 시각적 차이를 표현하는 수단으로 접한다.
• Figma의 대표적인 prop 유형은 다음과 같다.
  • Variant: 컴포넌트의 변형
  • Boolean: 표시 여부나 켜짐/꺼짐 상태
  • Instance swap: 내부 인스턴스 교체
  • Text: 텍스트 값 변경
• 개발자는 이러한 시각적 props 외에도 이벤트 핸들러, 데이터, 동작 제어 등 비시각적 속성을 함께 다룬다.
• 같은 단어를 사용하더라도 서로 다른 의미를 떠올릴 수 있으므로, 용어의 일치만으로 공통 이해가 형성되지는 않는다.

버튼 사례에서 드러나는 차이

• Figma의 버튼은 시각적 일관성과 디자인 파일 안에서의 구현 방식이 중요하다.
• 코드의 버튼은 시각적 표현뿐 아니라 렌더링 방식, 사용자 상호작용, 접근성, 이벤트 처리까지 포함한다.
• 따라서 Figma의 Button과 코드베이스의 Button은 이름과 기본 개념은 같아도 실제 책임과 props 구성이 다를 수 있다.
• 글의 사례에서는 Figma에 Button과 IconButton 두 컴포넌트가 있었지만, 코드베이스에는 버튼 관련 컴포넌트가 다섯 개 존재했다.
• Figma의 두 컴포넌트는 코드베이스처럼 공통 primitive를 상속하지 않았다.
  • Figma에서는 코드와 같은 방식의 컴포넌트 상속이 존재하지 않는다.
  • 디자인 관점에서 모델링하기에 두 컴포넌트를 분리하는 편이 더 적절했다.
  • 크기와 색상 같은 props가 중복되었지만, 동기화가 어렵지 않고 일관성을 해치지 않아 허용할 수 있었다.
• 반면 코드베이스의 버튼 컴포넌트는 더 많은 props와 기능을 제공했으며, Figma 컴포넌트에는 그중 일부만 반영되어 있었다.
• 이는 디자이너와 개발자가 컴포넌트를 최적화하는 기준이 다르다는 점을 보여준다.
  • 디자이너: 시각적 표현, 디자인 시스템 내 일관성, 파일에서의 사용성
  • 개발자: 구현 편의성, 재사용 구조, 상호작용, 데이터와 접근성

공통 어휘를 만들 때 필요한 관점

• 디자인과 코드의 컴포넌트를 무조건 동일한 구조로 맞추기보다, 각각의 환경에서 컴포넌트가 수행하는 역할을 먼저 구분해야 한다.
• 같은 이름을 사용하는 컴포넌트라도 실제 목적과 지원하는 props가 다르면 그 차이를 명시적으로 설명해야 한다.
• 협업에서는 “이 prop이 존재하는가”보다 다음 질문이 중요하다.
  • 어떤 시각적 또는 기능적 문제를 해결하는가?
  • 디자인에서의 변화가 코드에서는 어떤 prop이나 상태에 대응하는가?
  • 코드의 비시각적 기능을 디자인 시스템에서는 어떻게 표현하거나 문서화할 것인가?
• 서로 다른 용어를 사용하는 사실 자체는 문제가 아니다. 문제는 동일한 의미라고 가정한 채 대화하는 것이다.

디자인 시스템을 운영할 때는 Figma와 코드 컴포넌트의 이름을 가능한 한 연결하되, props 목록과 의미가 완전히 같다고 가정하지 않는 것이 좋다. 각 prop의 목적과 대응 관계를 문서화하고, 시각적 속성과 동작·데이터 속성을 구분하면 디자이너와 개발자 사이의 오해를 줄일 수 있다.