오즈코딩스쿨 디자인 캠프 - 한 번 고치면 다 바뀐다 — 컴포넌트와 프로퍼티 (day15)

 

 

오늘 수업이 끝나고 강사님이 말했다. 이제 피그마의 주요 기능은 거의 다 배운 셈이라고. 어제 쌓아둔 디자인 토큰 위에, 오늘은 컴포넌트와 프로퍼티를 얹었다. 그런데 다 듣고 나서 가장 크게 남은 건 단축키도 아이콘도 아니었다. 원본 하나만 고치면 전부 바뀐다는, 그 구조 자체였다. 간호할 때 늘 부딪혔던 표준화 이야기가 자꾸 겹쳐 보였기 때문이다. 병동에서 욕창 드레싱 절차를 환자마다 새로 그리지 않는다. 표준 프로토콜이 하나 있고, 지침이 바뀌면 그게 모든 환자에게 적용된다. 오늘 배운 컴포넌트가 딱 그랬다.

수업은 크게 세 파트였다. 어제 배운 디자인 시스템 설계 구조를 실제 기업 사례로 복습하고, 컴포넌트의 본질과 활용법을 익히고, 마지막으로 컴포넌트를 더 유연하게 쓰게 해주는 프로퍼티까지. 이론과 실습을 계속 오갔다.

다시 보는 디자인 시스템 — 실제 기업은 어떻게 쓰고 있나

본격적인 컴포넌트 이야기에 앞서 어제 배운 토큰 구조를 복습했다. 로우 밸류 → 프리미티브 → 시멘틱 → 컴포넌트로 이어지는 네 계층. 강사님은 어제처럼 포켓몬에 비유했다. 야생의 포켓몬이 로우 밸류(순수한 헥스코드, 의미 없는 색상값)라면, 거기에 'Blue 600' 같은 이름을 붙인 게 프리미티브, 'Color/Button/Primary'처럼 역할을 부여한 게 시멘틱, 그리고 이 토큰들을 조합해 실제 전장에 내보내는 UI 단위가 컴포넌트다.

중요한 건 이 구조가 100% 정답이 아니라는 점이었다. 기업마다, 조직마다, 프로덕트 규모마다 다 다르다고 했다. 규모가 큰 프로젝트는 계층이 잘게 나뉘어 있고, 작은 서비스는 더 적은 단위로 시작했다가 점점 세분화된다. 그 말이 무슨 뜻인지 직접 확인하려고 네 곳의 디자인 시스템을 같이 뜯어봤다.

디자인 시스템주체·성격특징

LINE	글로벌 메신저	메신저·패밀리 서비스 두 제품군으로 구분, iOS/안드로이드 색상 분리, 다국어(영어·일본어) 타이포 정의
G마켓	국내 이커머스	브랜드 에센스부터 정의, 구매 동선 전용 CTA 색상을 따로 분리, 서브 서비스별 색 정의
Carbon (IBM)	오픈소스	누구나 무료 접근, 접근성·다크모드까지 상세, 피그마 커뮤니티에서 학습용으로 활용 가능
Atlassian	협업 툴	구조는 유사하나 컴포넌트 명칭에 차이(Date Picker vs Calendar 등)

특히 G마켓이 인상 깊었다. 보이는 걸 그대로 따라 하기 전에 '우리 브랜드는 사용자가 이렇게 느끼길 원한다'는 브랜드 에센스부터 정의해둔 점이 좋았다. 색상도 그냥 나열한 게 아니라 의미로 묶여 있었다. 그린은 쿠폰·혜택 같은 긍정 신호, 블루는 별점·공식 태그 같은 신뢰, 레드는 취소·탈퇴 같은 주의, 오렌지는 배송 지연. 어제는 그냥 '색상이네' 했을 화면이, 토큰을 직접 세팅해보고 나니 의미가 읽혔다.

흥미로웠던 건 G마켓이 구매 동선 전용 색상을 프라이머리와 따로 뒀다는 점이다. 구매하기 같은 핵심 CTA에는 배경색을 꽉 깔고, 덜 중요한 버튼에는 텍스트와 선에만 색을 썼다. Carbon(IBM의 오픈소스 디자인 시스템)은 접근성까지 상세히 다뤘다. 저시력, 색각 이상 사용자에게 화면이 어떻게 보이는지, 다크모드는 어떻게 분기하는지까지. 모든 화면에서 매번 접근성을 점검할 수 없으니 디자인 시스템 단계에서 정의하고 넘어간다는 설명이 와닿았다.

이런 디자인 시스템 문서를 하나하나 외울 필요는 없다. '아, 이 회사는 이런 방식으로 정의해뒀구나'를 빨리 파악하는 눈만 기르면 된다.

실습으로는 피그잼에 하나를 기준으로 두고, 같은 컴포넌트(버튼·카드·인풋 등)를 다른 시스템은 어떻게 정의하는지 나란히 캡처해 비교했다. 같은 요소인데 어디는 'Date Picker', 어디는 'Calendar'로 부르는 식의 명칭 차이를 보는 것도 재미있었다. 더 깊이 파보고 싶다면 머티리얼 디자인과 애플 휴먼 인터페이스 가이드라인이 이 분야의 바이블이라고 했다. 다만 워낙 공고히 구축돼 있어 처음엔 복잡할 수 있으니, 오늘 본 네 곳부터 보라고 권했다.

컴포넌트란 무엇인가 — 붕어빵 틀과 붕어빵

드디어 오늘의 핵심, 컴포넌트. 정의는 이렇다. 일관된 디자인을 유지하면서, 수정이 필요할 때 한 번의 수정만으로 그 컴포넌트를 따르는 모든 인스턴스가 업데이트되는 기능. 어제 베리어블에서 토큰 하나를 바꾸니 그걸 쓰던 화면이 한 번에 다 바뀌었는데, 컴포넌트도 똑같은 원리였다.

강사님은 붕어빵에 비유했다. 컴포넌트는 붕어빵 틀, 인스턴스는 붕어빵이다. 틀이 있으면 반죽만으로 같은 모양을 계속 찍어낼 수 있고, 틀 모양을 바꾸면 그 뒤에 찍는 붕어빵이 다 바뀐다. 즉 메인 컴포넌트(원본 틀)를 수정하면 그걸 복사한 인스턴스(붕어빵)가 함께 바뀐다. 반대로 인스턴스를 수정해도 메인은 변하지 않는다. 수정은 늘 메인 → 인스턴스 한 방향으로만 흐른다.

구별법도 알려줬다. 레이어 패널에서 일반 프레임이나 그룹은 검은색인데, 컴포넌트와 인스턴스는 보라색으로 표시된다. 아이콘도 다르다. 보라색 다이아몬드 네 개가 메인 컴포넌트, 테두리만 있는 빈 다이아몬드가 인스턴스다.

이게 왜 강력한가. 서비스 전체에서 CTA 버튼이 200개 화면에 들어가 있다고 해보자. 브랜드 색이 바뀌면 200개를 일일이 고치는 게 아니라, 메인 컴포넌트 하나만 고치면 200개가 동시에 바뀐다. 작업 속도도 빨라지고, 무엇보다 모든 화면의 일관성이 유지된다.

아이콘 → 모듈 → 템플릿 → 페이지

컴포넌트는 계층으로 쌓인다.

단계정의예시

아이콘	더 이상 쪼갤 수 없는 가장 작은 단위	사람 아이콘 하나
모듈	아이콘 + 텍스트의 최소 조합	아이콘과 짧은 설명
템플릿	여러 모듈을 배열한 형태	모듈 + 모듈 + 모듈
페이지	템플릿이 모여 구성된 최종 화면	하나의 완성된 화면

아이콘 하나를 컴포넌트로 만들어두면 그게 모듈에 쌓이고, 모듈이 템플릿에, 템플릿이 페이지로 이어진다. 그래서 아이콘 하나만 수정해도 그걸 쓰는 모든 모듈·템플릿·페이지가 한 번에 바뀐다. 작은 단위부터 컴포넌트로 관리해야 하는 이유다. 레고 블록에 비유하면, 미리 만들어둔 블록을 조립해 다양한 결과물을 빠르고 일관성 있게 만드는 방식이다.

왜 써야 하는가 — As-Is vs To-Be

상황As-Is (이전 방식)To-Be (컴포넌트 방식)

버튼 높이 수정	적용된 모든 화면에 일일이 들어가 수정	원본만 수정하면 인스턴스에 자동 반영
새 상태 추가	기존 화면과 정렬이 어긋나기 쉬움	하나의 기준이 있어 상태 정의가 쉬움
디자인 핸드오프	무엇을 기준 삼았는지 구구절절 설명	컴포넌트 명 자체가 기준이 됨

컴포넌트는 보기 좋게 정리하는 기능이 아니라, 수정 비용은 줄이고 기준을 맞추는 작업 방식이다.

이 문장이 오늘 제일 와닿았다. 컴포넌트는 팀 전체의 수정 비용을 줄이고, 디자인 기준을 하나로 정리하고, 개발자와 소통할 공통 언어를 만드는 기반이라고 했다.

직접 만들어보며 익힌 것들

이론만큼이나 손으로 익히는 게 많았다. 어제 세팅한 파운데이션(색상·텍스트 스타일)을 활용해 예약 화면을 만들면서 컴포넌트로 묶어봤다. 텍스트는 우측 타이포그래피 영역의 동그라미 네 개 아이콘을 눌러 어제 만들어둔 스타일을 그대로 입혔고, 화면은 컨스트레인츠로 잡았다.

컴포넌트로 만드는 단축키는 ⌘ + ⌥ + K(윈도우는 Ctrl + Alt + K)다. 자주 쓰게 될 거라 외워두라고 했다. 프레임을 선택하고 우측 패널의 컴포넌트 아이콘을 눌러도 된다.

가장 흥미로웠던 건 인스턴스의 연결이 끊기는 순간이었다. 인스턴스에서 배경색을 직접 바꾸면, 그 뒤로는 메인의 배경색을 더 이상 따라가지 않는다. 텍스트를 바꿔도 마찬가지. 다만 수정한 그 부분만 끊어진다. 텍스트만 고쳤다면 텍스트만 끊기고, 색상은 여전히 메인을 따라간다. 다시 연결하고 싶으면 우클릭 → Reset Instance를 누르면 원본을 따라 돌아온다.

여러 요소를 한꺼번에 컴포넌트로 만들 때는 주의가 필요했다. 그냥 'Create Component'를 하면 선택한 전체가 하나의 컴포넌트가 되어버린다. 각각을 개별 컴포넌트로 만들고 싶으면 드롭다운에서 Create Multiple Components를 골라야 한다. 그리고 이렇게 만든 컴포넌트는 좌측 에셋(Assets) 패널에 등록되어, 원본 페이지까지 찾아가지 않아도 다른 화면에서 검색해 바로 인스턴스로 꺼내 쓸 수 있었다.

알아두면 좋은 실무 팁 몇 가지

슬래시로 폴더 묶기. 레이어 이름에 슬래시를 넣으면 자동으로 폴더가 나뉜다. Icon/Heart, Icon/Star처럼 지으면 에셋에서 'Icon' 폴더 안에 하트와 스타가 정리된다. 어제 파운데이션을 세팅할 때 슬래시로 계층을 나눴던 것과 같은 방식이다. 아이콘이 수십 개로 늘어날 때 유용하다.

한 번에 이름 바꾸기(Rename). ⌘ + R(윈도우는 Ctrl + R)을 누르면 여러 레이어 이름을 한꺼번에 바꿀 수 있다. 현재 이름을 유지할지, 숫자를 오름차순·내림차순으로 붙일지도 고를 수 있다.

삭제한 메인 컴포넌트 복구. 누군가 메인 컴포넌트를 실수로 지워도, 그걸 따르던 인스턴스를 선택하고 우클릭 → Restore Main Component를 누르면 원본이 되살아난다. 인스턴스를 클릭해야 이 옵션이 뜬다는 점만 기억하면 된다.

프로퍼티 — 인스턴스를 더 유연하게

마지막 챕터는 프로퍼티였다. 컴포넌트를 더 쉽게 변경하게 해주는 기능이다. 프로퍼티가 없으면 버튼 텍스트 하나 바꾸려고 인스턴스 레이어 안쪽으로 계속 파고들어가야 하는데, 프로퍼티를 설정해두면 컴포넌트만 선택하고 우측 창에서 바로 바꿀 수 있다. 종류는 세 가지였다.

타입기능비고

텍스트 프로퍼티	인스턴스에서 텍스트만 바로 교체	텍스트 요소 자체를 프로퍼티로 지정
불리언 프로퍼티	토글로 요소를 보이거나 숨김	오늘은 개념만, 실습은 내일
인스턴스 스왑	아이콘·이미지를 다른 것으로 교체	교체 대상도 컴포넌트여야 함

이 중 인스턴스 스왑에는 중요한 전제가 있었다. 교체하려는 아이콘이나 이미지도 미리 컴포넌트로 만들어둬야 한다는 것. 컴포넌트끼리만 교체되기 때문에, 일반 이미지나 아이콘을 그대로 두면 스왑 목록에 아예 나타나지 않는다. 그래서 헤더를 만들고, 그 안의 하트 아이콘을 별 아이콘으로 바꿔보는 실습을 했다. 다이아몬드 가운데 줄이 그어진 아이콘을 눌러 Preferred Instances에 교체 후보들을 등록하고, Create Property까지 하면 인스턴스에서 드롭다운으로 손쉽게 바꿀 수 있었다. 이미지 교체(프로필 사진 베리에이션)나 텍스트 프로퍼티도 같은 원리로 이어졌다. 텍스트 프로퍼티가 특히 유용한 건, 타이틀·가격·위치처럼 텍스트가 잔뜩 든 카드에서 일일이 파고들지 않고 우측 창에서 한 번에 바꿀 수 있기 때문이라고 했다.

다만 불리언 프로퍼티는 오늘 개념만 듣고 실습은 내일로 미뤄졌다. 토글로 요소를 켜고 끄는 기능인데, 카드 UI에 스탬프나 'NEW' 텍스트, 이벤트 배지를 보이거나 숨기는 식으로 내일 직접 다뤄본다고 했다. 내일은 오늘 배운 컴포넌트·프로퍼티에 오토 레이아웃까지 복합적으로 얹어 카드 UI를 만든다고 하니, 오토 레이아웃이 아직 헷갈리는 나로서는 오늘 밤 복습이 숙제다.