# 자동화를 전제로 한 컴포넌트 설계

디자인 시스템을 만들면서 계속 하나의 질문에 부딪혔습니다. 디자인 팀은 어디까지 책임져야 할까

기존 방식대로라면 시안을 보기 좋게 만들고, 구조 해석과 구현은 개발 단계에서 알아서 진행하도록 두는 것도 가능했습니다.

디자인은 결과물을 만들고, 시스템은 코드에서 완성되는 구조였습니다.

하지만 사내 프로젝트로 Figma MCP, Code Connect처럼 시안을 그대로 코드로 연결하는 환경을 전제로 하다 보니

이 방식이 더 이상 충분하지 않다는 점을 점점 체감하게 되었습니다.

---

그래서 이번 Select 컴포넌트를 설계하면서, DS를 새로 만들어보며 처음으로 시안 구조 자체를 코드 구조에 가깝게 가져가는 방향을 선택했습니다.

이 시점부터 Figma 시안을 단순한 화면 디자인이 아니라, 앞으로 반복적으로 재사용될 시스템 정의로 바라보기 시작했습니다.

디자인 팀 내부에서도 "이건 그냥 화면 디자인이 아니라, 앞으로 계속 재사용될 시스템 정의에 가깝다"는 이야기를 자주 나누게 되었습니다. 그 결과 시안을 설계할 때의 기준도 달라졌습니다.

"이게 예쁜가 저게 예쁜가"보다 **"이 레이어가 어떤 역할을 맡고 있는가"**를 먼저 정리하게 되었습니다.

컴포넌트를 구성하는 레이어들은 시각적 그룹이 아니라 역할 기준으로 나누어 정의했습니다.

클릭을 담당하는 영역은 ListboxButton 옵션 패널은 ListboxOptions 반복되는 옵션 단위는 ListboxOption

레이어 이름과 annotation 역시 DOM 구조를 직접 지시하는 방식은 의도적으로 피하고, Headless UI에서 정의하는 역할 단위와 맞추는 방향을 선택했습니다.

이 방식은 Figma MCP 기준에서도 효과적이었고, 디자인 팀 입장에서도 "이 컴포넌트의 구조를 우리가 정의하고 있다"는 감각을 가질 수 있었습니다.

이 과정에서 또 하나의 태도 변화가 있었습니다.

코드 구조를 시안에서 굳이 숨길 필요는 없다고 판단하게 된 점입니다.

Select 컴포넌트는 Headless UI의 구조를 시안과 코드 양쪽에서 그대로 드러내도록 설계했습니다.

Listbox

Listbox.Button

Listbox.Options

Listbox.Option

이렇게 구조를 맞추니, 디자인 팀에서 정의한 part와 variant가 개발 단계에서 다시 해석되지 않고 거의 그대로 props와 상태로 연결되었습니다. 

Code Connect를 적용했을 때도 텍스트, 아이콘, 옵션 데이터가 "이 값이 어디로 가야 하는지"를 다시 고민하지 않아도 될 정도로 이미 위치가 정해진 상태였습니다.

DS를 만들면서 느낀 점 중 하나는 자동화를 고려한 설계가 디자인 팀의 역할을 줄이지는 않는다는 점이었습니다.

오히려 단기적으로는 작업량이 늘어났습니다.

레이어를 더 세분화하고

variant를 더 명확하게 정의하고

placeholder와 value를 하나의 텍스트 레이어로 묶는 작업들이 필요했습니다.

하지만 그 결과로 AI가 잘못 생성할 수 있는 여지를 줄일 수 있었고, 디자인 의도가 코드로 전달되는 과정에서 왜곡될 가능성도 낮출 수 있었습니다.

시스템이 커질수록 관리 비용 역시 줄어드는 구조를 만들 수 있었습니다.

이 선택은 개발을 편하게 해주기 위한 배려라기보다는, 디자인 시스템의 품질을 디자인 팀이 끝까지 책임지겠다는 판단에 가까웠습니다.

---

**정리하며**

DS를 만들면서 다시 한 번 확신하게 된 점이 있습니다.

디자인 시스템에서 중요한 것은 얼마나 자유로운 구조를 허용하느냐가 아니라, 어디까지를 디자인 팀이 미리 결정해 두었는가라는 점이었습니다.

이번 컴포넌트 설계처럼 시안 구조를 코드 구조와 의도적으로 닮게 만든 방식은 디자인, 개발, 자동화 사이의 번역 비용을 눈에 띄게 줄여주었습니다.

이 기준은 컴포넌트 하나에만 적용되는 것이 아니라, 앞으로 우리 제품 DS 전체 컴포넌트 설계의 기본 원칙으로 가져갈 예정입니다.

For the site tree, see the [root Markdown](https://slashpage.com/yj-archive.md).